Issue metadata
Sign in to add a comment
|
Low framerate for H264 when webrtc hardware encode/decode is enabled
Reported by
e...@highfive.com,
Jan 18 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2985.0 Safari/537.36 1. Join https://appr.tc/r/<meeting_id>?vrc=H264&vsc=H264 on two tabs 2. See the video periodically freeze for multiple seconds. What is the expected behavior? If you relaunch the browser with the flags --disable-webrtc-hw-encoding --disable-webrtc-hw-decoding then the rendered framerate is smooth and expected What went wrong? The video freezes periodically for multiple seconds. If you bring up the information panel in apprtc, you'll see the end-to-end delay metric spike. I've attached the diagnostic output from webrtc-internals. Did this work before? N/A Chrome version: 57.0.2985.0 Channel: canary OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 24.0 r0 No visible error messages in the chrome standard output. I noticed that the framesDecoded rate stalls and the googPlisSent increases. Occurrence of PLI should be unexpected due to the peer-to-peer connection. In contrast when I run with the HW encode/decode disabled, the googPlisSent is a constant 0 and the framesDecoded rises at a near constant rate.
,
Jan 20 2017
Th URL provided in the summary gives a 404 Not found error page. @ ed: could you please help us with another test URL, so as to triage the issue further. Thanks.!
,
Jan 20 2017
,
Jan 20 2017
Replace the <meeting_id> with any identifier. For example: https://appr.tc/r/chrome_bug_682443?vrc=H264&vsc=H264
,
Jan 24 2017
,
Jan 31 2017
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 22 2017
Anything I can help with to move this along?
,
Feb 27 2017
Able to reproduce the issue on Windows 10 and MAC 10.12.3 for chrome beta version 57.0.2987.74. Hard to find the bisect as chrome video freezes in between for some milliseconds, but later unfreezes (This occurs when switching tabs). Not sure to consider if it as Bad builds. Bisecting Results: ================== 55.0.2860.0 - good build 55.0.2873.0 - Bad build. Change Log: https://chromium.googlesource.com/chromium/src/+log/55.0.2860.0..55.0.2873.0?pretty=fuller&n=10000 Using Per Bisect revision invokes chrome which for many revisions do not navigate to any url, throws an internal error. CC'ing few people who have committed some changes in between this build range related to webrtc who can help triage this: Untriaged it so that it gets addressed. Thanks.!
,
Feb 27 2017
,
Mar 6 2017
,
Mar 6 2017
,
Mar 6 2017
I cannot repro this in the latest canary 59.0.3032.0. I ran a session between two tabs for ~5 mins. Frame rate is low but there is no freeze for multiple seconds as described. Can you give more info on how to reproduce it? Low frame rate can be explained via the limited number of captured buffers alive. we have a limit of 3 capture buffers being alive at once. Between two tabs that uses HW, that is easily saturated and we might drop frames.
,
Mar 22 2017
,
Apr 3 2017
I reproduced a similar problem on issue 707309 . Marking it as duplicate, but feel free to re-open if you think it is a different problem. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by e...@highfive.com
, Jan 18 2017