Low resolution / resolution drops when streaming H264 video in desired 720p
Reported by
fho...@nanocosmos.de,
Sep 29 2016
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Example URL: https://apprtc.appspot.com/?vsc=h264&vrc=h264 Steps to reproduce the problem: 1. go to https://apprtc.appspot.com/?vsc=h264&vrc=h264 with two chrome browsers 2. join the same room 3. look at chrome://webrtc-internals What is the expected behavior? Resoluton should be stable (when using VP9 it is stable: https://apprtc.appspot.com/?vsc=VP9&vrc=VP9) What went wrong? 1. resolution drops will be visible in googFrameHeightSent and googFrameWidthSent 2. Shaking the camera (applying movement to the sent stream) can increase the sent resoltuion but it drops again after a while 3. Please see the attached screenshots, the first is H264 where we shaked the camera around 10:49. One can see that the resolution went higher after that but dropped again. The second shows the same use case with VP9 codec (https://apprtc.appspot.com/?vsc=VP9&vrc=VP9) and its stable. Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? N/A Chrome version: 53.0.2785.116 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 Is there a way to keep resoltuion from varying/dropping too much/at all? Instead maybe adopt the bitrate as preferred adoption strategy? We have read about RTCDegradationPreference in https://www.w3.org/TR/webrtc but that doesnt seem to have been implemented yet
,
Sep 30 2016
OK, this is CPU adaptation, you can googAdaptionChanges going up as the resolution changes up and down. The current version of openH264 isn't multithreaded so performance isn't good for HD content. Your testing revealed another thing that I was able to confirm, the complexity of open264 is highly content dependent. If I shake my hand in front of the camera I can easily make encode time go from 25ms to 80ms per frame. Harald, can you add this to the list of things to discuss with Cisco? (Improving perf for H264 will be tracked by other bugs, closing this one)
,
Oct 4 2016
Ok, but can webrtc be configured to use bitrate adaptation instead of resolution adaptation? What about RTCDegradationPreference (https://www.w3.org/TR/webrtc/#idl-def-rtcdegradationpreference)
,
Oct 7 2016
Checking back on this: we understand the performance issues with openH264, but the actual question is if there a way to disable the adaption features? When will RTCDegradationPreference be implemented? Which bug tracks the H264 performance issue? Thanks, Oliver -- Oliver Lietz <lietz@nanocosmos.de> http://www.nanocosmos.de
,
Oct 10 2016
You should be able to use the custom constraint "googCpuOveruseDetection" to disable scaling for now - but you will see low frame rate and get some extra delay instead.
,
Dec 14 2016
We still have the same issue, also with the latest Chrome 55 on Windows.
googCpuOveruseDetection does not avoid frame size / Resolution adaption.
See attached images.
We would like to have more control over the encoding process, i.e. less auto-adaption.
It seems to be more related to bitrate settings than CPU load.
will the w3c standard RTCDegradationPreference be implemented soon?
The configuration "maintain-resolution" would be what we need:
enum RTCDegradationPreference {
"maintain-framerate",
"maintain-resolution",
"balanced"
};
Any idea?
|
||
►
Sign in to add a comment |
||
Comment 1 by fho...@nanocosmos.de
, Sep 29 2016