h264 screenshare from Chrome, not as good as with VP8 . need help with constrains / params

[bell...@gmail.com]

Hi Folks,

I have a system where I use Janus as a webrtc media server, and I am experimenting with the new h264 support in Edge and iOS.

 I  switched codecs from a VP8 based video room to an H264 room and changed nothing else (just the codecs )

The screen-share quality is significantly worse than on the VP8 room, text looks blurry, and it takes a few seconds to become sharp, then when a new FIR is sent, it goes blurry again, and so on and so for.  

I have my Janus video room fir_rate at 5s (one fir request every 5 s) , and my getUserMedia constrains to only do 1 frame per second (maxFrameRate:1, minFrameRate: 1) This with VP8 gives very sharp text and images. Not so with h264.

Does anybody have any suggestion on how to make h264 screen-share better quality? I am sure I am missing something, as from what I read here, h264 should work very nicely for a screen capture.

Any help appreciated.

[Brian Baldino]

what platform is the sharer on? i'd look at the cpu usage, that'll tell you if it's using software (cpu will be very high), assembly (cpu use will be very low) or hardware (cpu will be 0).  depending on which it's using there, that might explain something.  i also remember a while ago that scaling the image (sharing at a resolution other than the native screen resolution) on windows was very costly.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5d9af748-f2d7-4694-aeb3-f02fc6041ebd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bell...@gmail.com]

Hi,

In this case , I am sharing from latest Chrome (61.0.3163.100 (Official Build) (64-bit)) on Mac os X. I'll take a look at the CPU.

I've been experimenting with more spaced out fir_rates for h264 and the images get sharper and sharper as times goes by, but still not nearly as shar as with the same setting son VP8.

On Monday, October 30, 2017 at 6:17:43 PM UTC-4, Brian Baldino wrote:

what platform is the sharer on? i'd look at the cpu usage, that'll tell you if it's using software (cpu will be very high), assembly (cpu use will be very low) or hardware (cpu will be 0).  depending on which it's using there, that might explain something.  i also remember a while ago that scaling the image (sharing at a resolution other than the native screen resolution) on windows was very costly.

On Mon, Oct 30, 2017 at 12:37 PM, <bell...@gmail.com> wrote:

Hi Folks,

I have a system where I use Janus as a webrtc media server, and I am experimenting with the new h264 support in Edge and iOS.

 I  switched codecs from a VP8 based video room to an H264 room and changed nothing else (just the codecs )

The screen-share quality is significantly worse than on the VP8 room, text looks blurry, and it takes a few seconds to become sharp, then when a new FIR is sent, it goes blurry again, and so on and so for.  

I have my Janus video room fir_rate at 5s (one fir request every 5 s) , and my getUserMedia constrains to only do 1 frame per second (maxFrameRate:1, minFrameRate: 1) This with VP8 gives very sharp text and images. Not so with h264.

Does anybody have any suggestion on how to make h264 screen-share better quality? I am sure I am missing something, as from what I read here, h264 should work very nicely for a screen capture.

Any help appreciated.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[bell...@gmail.com]

Brian thanks!!! your comments made me think, and I switched ot share to the same server using FF and the screenshare is perfect on h264, so it has to be somehting with Chrome. I am sure I have a few "goog" optional constrains in there that are provably screwing things up, like 

optional: [

{ googSkipEncodingUnusedStreams: true },

                                            { googScreencastMinBitrate: 400 },

                                            { googDscp: true},

                                            { googImprovedWifiBwe: true },

                                            { googHighBitrate: true },

                                            { googVeryHighBitrate: true },

                                            { googCpuOveruseDetection: false },

                                            { googNoiseReduction: false},

                                            { googTemporalLayeredScreencast: true}

                                        ]

[Brian Baldino]

Interesting, I've never tried any of those constraints before but probably a good place to start between removing those and checking if anything looks odd in webrtc-internals.

-brian

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/94ae2a76-1ebf-429c-a0bd-d338216a3a07%40googlegroups.com.

[bell...@gmail.com]

Thanks a lot Brian, you were right. I checked chrome://flags and long time ago apparently this mac had the h264 software decoder enabled. now the screen-share quality in h264 is good!

thanks!

[Leo Agle]

hi Brian,

    I am working on screen sharing of chrome on mac os X. I found the cpu usage always very high. How can I set params to switch to using assembly or hardware?  thanks in advance

On Tuesday, October 31, 2017 at 6:17:43 AM UTC+8, Brian Baldino wrote:

what platform is the sharer on? i'd look at the cpu usage, that'll tell you if it's using software (cpu will be very high), assembly (cpu use will be very low) or hardware (cpu will be 0).  depending on which it's using there, that might explain something.  i also remember a while ago that scaling the image (sharing at a resolution other than the native screen resolution) on windows was very costly.

On Mon, Oct 30, 2017 at 12:37 PM, <bell...@gmail.com> wrote:

Hi Folks,

I have a system where I use Janus as a webrtc media server, and I am experimenting with the new h264 support in Edge and iOS.

 I  switched codecs from a VP8 based video room to an H264 room and changed nothing else (just the codecs )

The screen-share quality is significantly worse than on the VP8 room, text looks blurry, and it takes a few seconds to become sharp, then when a new FIR is sent, it goes blurry again, and so on and so for.  

I have my Janus video room fir_rate at 5s (one fir request every 5 s) , and my getUserMedia constrains to only do 1 frame per second (maxFrameRate:1, minFrameRate: 1) This with VP8 gives very sharp text and images. Not so with h264.

Does anybody have any suggestion on how to make h264 screen-share better quality? I am sure I am missing something, as from what I read here, h264 should work very nicely for a screen capture.

Any help appreciated.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Harald Alvestrand]

When the text goes blurry on FIR (which causes sending an I-frame), it likely means that the generated I-frame isn't big enough to represent the picture.

I know there's controls for the size of the I-frame way down in the codebase, but I have no idea what they're set to. Can you figure out what the size of the I-frame is?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/88e0d871-51c4-4bd0-b66d-d72f34c6f339%40googlegroups.com.

[Brian Baldino]

I don't think this is configurable at runtime, it would involve a recompile.  Though I think this bug may be the fix for using hardware on mac.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/88e0d871-51c4-4bd0-b66d-d72f34c6f339%40googlegroups.com.