Issue metadata
Sign in to add a comment
|
When using "Hardware-accelerated video decode" flags option, WebRTC H.264 codec bitrate is very unstable.
Reported by
dodor...@gmail.com,
Apr 14 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. Connect video meeting in 1:1 or 1:n. 2. This symptom occurs frequently When Camera Pause and Play in MAC OS. 3. Turn off the camera and wait 10 seconds before turning on the camera 4. My video on other people's screen seems to be very frame-breaking. () 5. If you turn off the hardware option, it works smoothly. What is the expected behavior? If the option is turned on for a Windows PC as well as a MAC, the screen is exposed rather slowly when the camera is turned on and off. What went wrong? If you turn off the Hardware-accelerated video decode option, it works smoothly. This symptom is a capture attachment in webrtc-internal Did this work before? Yes Yes, chrome 57, canary 59 symptom is same. Chrome version: 57.0.2987.133 Channel: stable OS Version: 10.0 Flash Version:
,
Apr 14 2017
,
Apr 17 2017
emircan@: Could you please take a look?
,
Apr 17 2017
Does it happen in both Win 10 and Mac, or when the connection is in between two? Can you describe it in more detail? For Mac, it is a known problem that HW is mostly overshooting or undershooting. It might take a bit to stabilize the bitrate through our custom BitrateAdjuster. Can you also send framerateinput and frameratesent stats from when this happens?
,
May 23 2017
,
Jun 2 2017
This is a pretty critical issue for most MacOs users since muting their webcam, and then unmuting results in completely unusable performance. Any update on a resolution to this issue?
,
Jun 5 2017
I tried reproducing the issue on mbp using https://apprtc.appspot.com/?debug=loopback&vsc=h264. What I see is that, there is a ~5 second window right after unmuting video where frame rate drops to ~2. It recovers after that short window though. Is that also your observation? As I explained on #4, this is related to bitrate adjustment for Hw encode. During the muted window, we keep producing and encoding black frames. Bitrate falls to tiny values in that frame, whereas the target bitrate is actually higher. Therefore, we start overshooting and that applies to the first set of real frames coming after unmute. After a short while, it adjusts back.
,
Oct 25 2017
Is this still valid?
,
Oct 25 2017
Closing it based on #8. Feel free to reopen if you think it is still valid. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dodor...@gmail.com
, Apr 14 2017