Starting chrome with --enable-webrtc-h2-h264-encoding flag results in unreliable framerate
Reported by
brian@highfive.com,
Mar 22 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 Steps to reproduce the problem: 1. Start (very recent) chrome with --enable-webrtc-h2-h264-encoding 2. Go to the sdp-munge demo at https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/ 3. After doing 'create offer', modify the offer to swap the order of payload types "100" and "107" (to make it use h264) 4. Do the rest of the offer/answer flow to get media flowing 5. Open chrome://webrtc-internals and look at the sender page, particularly at the send_video stats What is the expected behavior? Even with software encoding, we see a pretty solid 30fps framerate. I'd expect we should see the same for hardware encoding. What went wrong? See frequently low framerate. Framerate starts very low (~5fps). Will eventually climb up to ~30 if there's no motion, but as soon as there is motion it drops down to ~10-15fps. Attached an image of the stat. It shows the initial slow ramp-up, then a period where there's no motion. Then some periods of me forcing motion where you can see the framerate drop. Did this work before? N/A Chrome version: 51.0.2688.0 Channel: n/a OS Version: OS X 10.9.5 Flash Version: Shockwave Flash 21.0 r0
,
Mar 23 2016
I filed this bug from a discussion with "emir...@chromium.org" (I can't see his entire email) over in this bug https://bugs.chromium.org/p/chromium/issues/detail?id=500605&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort= so I'd cc him.
,
Mar 23 2016
,
Apr 27 2016
any progress been made on this?
,
May 16 2016
@emircan saw you committed some hw acceleration changes so just tried the latest build, but still running into framerate and bitrate problems. I ran this with the "--enable-webrtc-hw-h264-encoding" flag. Attached a screenshot of webrtc-internals for the send stream. (tested on apprtc with loopback set and vsc/vrc set to h264).
,
May 16 2016
Thanks for checking Brian. I tried to eliminate the bitrate problem in this CL: https://codereview.chromium.org/1818903004/ I was hoping that it would also help this framerate issue. What I am getting is a drop between 20-30 sometimes, but I cannot reproduce the constant <10 fps that you get. What are the steps? Also which Apple device are you testing on?
,
May 16 2016
Ah that graph is pretty interesting. I thought maybe this looked like an issue we saw on iOS where the hw encoder just doesn't cooperate and oversends, so the frame dropper ends up dropping things. I tried always forcing the bitrate that gets set on the hw encoder to 60% of what the bitrate controller thought it should to check if that was true, but that doesn't seem to be the case. Attached a screenshot of the results we see with that setting. I'm on a macbook pro running 10.9.5. Processor 2 GHz Intel Core i7 Memory 8 GB 1600 MHz DDR3 Graphics Intel Iris Pro 1536 MB
,
May 19 2016
Issue 612992 has been merged into this issue.
,
May 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2e5139a27bc056aecb53df143b85ee191f6a86e6 commit 2e5139a27bc056aecb53df143b85ee191f6a86e6 Author: emircan <emircan@chromium.org> Date: Fri May 20 23:47:09 2016 Fix BitrateAdjuster issues in VTVideoEncodeAccelerator This CL addresses the bug below, where BitrateAdjuster would continue dropping the frame rate when bandwidth estimator kicks in. BUG= 597095 Review-Url: https://codereview.chromium.org/2000853002 Cr-Commit-Position: refs/heads/master@{#395208} [modify] https://crrev.com/2e5139a27bc056aecb53df143b85ee191f6a86e6/media/gpu/vt_video_encode_accelerator_mac.cc [modify] https://crrev.com/2e5139a27bc056aecb53df143b85ee191f6a86e6/media/gpu/vt_video_encode_accelerator_mac.h
,
May 23 2016
,
May 23 2016
Your change meets the bar and is auto-approved for M52 (branch: 2743)
,
May 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0b14f8e58b0601ac00aeae6a55a2ef1d8f588c90 commit 0b14f8e58b0601ac00aeae6a55a2ef1d8f588c90 Author: emircan <emircan@chromium.org> Date: Mon May 23 18:12:31 2016 Fix BitrateAdjuster issues in VTVideoEncodeAccelerator This CL addresses the bug below, where BitrateAdjuster would continue dropping the frame rate when bandwidth estimator kicks in. BUG= 597095 Review-Url: https://codereview.chromium.org/2000853002 Cr-Commit-Position: refs/heads/master@{#395208} (cherry picked from commit 2e5139a27bc056aecb53df143b85ee191f6a86e6) NOTRY=true NOPRESUBMIT=true TBR=sandersd@chromium.org Review-Url: https://codereview.chromium.org/2008583002 Cr-Commit-Position: refs/branch-heads/2743@{#7} Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939} [modify] https://crrev.com/0b14f8e58b0601ac00aeae6a55a2ef1d8f588c90/media/gpu/vt_video_encode_accelerator_mac.cc [modify] https://crrev.com/0b14f8e58b0601ac00aeae6a55a2ef1d8f588c90/media/gpu/vt_video_encode_accelerator_mac.h
,
May 23 2016
@emircan built it locally, so far looks good! nice job. gonna distribute this build out and get some more usage on it...exciting to see it working.
,
May 23 2016
,
May 24 2016
Verified in M52 52.0.2743.5 in Mac 10.11.5 with the original repro steps. The framerate stays at 30 fps, drops down to 10-15 fps when there's motion, but bounces back up to 30 fps screenshot - https://screenshot.googleplex.com/WQE3U7HnoSR.png |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rsesek@chromium.org
, Mar 23 2016