Low WebRTC screenshare performance using h264
Reported by
mjans...@gmail.com,
Sep 5 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Use WebRTC to screenshare with h264 codec running Windows 10 (tried both Chrome versions 59 and 60) 2. Witness very low performance and resolution in output video stream What is the expected behavior? Low latency and high quality video stream of the shared screen What went wrong? The encoder seems to take a lot of CPU resources (seen as an initial spike in encoder CPU usage at start of screen share). The CPU limiter then seems to kick in, resulting in a very low resolution and blocky video stream. Running the same screen share on the same machine but using Ubuntu 17.10 it performs as expected, the encoder can keep up using much less CPU resources and the resulting stream as high quality and low latency. Attached are two screenshots from webrtc-internals from the same machine, one running Windows 10 (bad) and one running Ubuntu 17.10 (good). Did this work before? N/A Does this work in other browsers? Yes Chrome version: 60.0.3112 Channel: stable OS Version: 10 Flash Version:
,
Sep 6 2017
,
Sep 6 2017
Can you take a first look at this and see if there's anything we can and should do here?
,
Sep 6 2017
I don't think CPU adaptation has kicked in (it's filtered in order to no trigger on spikes). The adaptation changes should have gone up then. Even so, in screen content mode we will adapt frame rate rather than resolution. Looking at the graphs, it looks like the rate control in the encoder is misbehaving. The spikes in bucket delay and dips in encode frame rate indicates very large frames are generated and so the frame dropper kicks in to avoid overshooting the bitrate limits too much. Do you have something shareable which easily repros this?
,
Sep 18 2017
We have put together a simple test to showcase this: https://github.com/CertusOp/windows-chrome-screensharing-h264-issue Run under Linux and both h264 and vp8 (which you get when unchecking the checkbox) works just fine. Run under Windows, and h264 will show significantly lower quality than when unchecking the checkbox to get vp8, or compared with h264 under Linux. For testing I usually scroll around in a window with lots of text content.
,
Oct 17 2017
Have you had any chance to check out the test case and been able to replicate the issue?
,
Oct 18 2017
Sorry, I haven't had time to prioritize this yet. ssilkin@ any chance you can have a look?
,
Oct 19 2017
I can't reproduce such slow ramp-up of bandwidth as I see on provided screenshot. I wonder if this is 100% reproducible? I noticed couple of things which affect H264 quality in negative way: 1. Lower bitrate. 1.5Mbps using H264 and 2Mbps using VP8. Target bitrate is the same, 2Mbps, for both codecs according to the stats. This means H264 always underutilizes bandwidth, using 25% less than VP8; 2. Lower frame rate. 20fps using H264 and 30fps using VP8. I will check if there is anything we can do to make H264 bitrate and framerate on pair with VP8.
,
Dec 15 2017
Any updates on this?
,
Dec 18 2017
Do you still see the issue with later Chrome versions (beta M63, canary M64)? |
||||
►
Sign in to add a comment |
||||
Comment 1 by mjans...@gmail.com
, Sep 5 2017