Issue metadata
Sign in to add a comment
|
13.9% regression in browser_tests at 553091:553100 |
||||||||||||||||||||
Issue descriptionhttps://webrtc-review.googlesource.com/70740 seems like the most likely cause.
,
Apr 25 2018
To me it looks correlated to webrtc cl https://webrtc-review.googlesource.com/72000 and the revert https://webrtc-review.googlesource.com/72220. I don't quite understand the regression, though. Where in the chromium code are the related encoders? How do they respond to GetScalingSettings?
,
Apr 25 2018
For software codecs WebRTC in Chrome use more or less the same codecs as standalone WebRTC, chat with sprang@ to learn more.
,
Apr 26 2018
Note to self: To try to reproduce locally, use this command line ./out/Release/browser_tests --ui-test-action-max-timeout=350000 --run-manual --gtest_filter='WebRtcVideoQualityBrowserTests/WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQualityVp8/1'
,
Apr 26 2018
When I run the above test locally, prior to the revert of my cl, the remote video is scaled down by a factor of two. After the revert, the remote video is full size. I suspect that the change is because my cl unbreaks the feature where downscaling kicks in right at the start, if the estimated or configured bitrate is too low (at most qvga, 320x240, for bitrates below 300kbit/s, at most vga, 640x480 for bit rates below 500kbit/s). See VideoStreamEncoder::DropDueToSize. I've had a look at the testcode under src/chrome/test/data/webrtc/ in the chromium tree, but I don't see where and how bitrate is configured. Patrik, do you know which bitrates are used in this test, and how it's configured?
,
Apr 27 2018
You can see the constraints for the /1 (720p) test here: https://cs.chromium.org/chromium/src/chrome/browser/media/webrtc/webrtc_browsertest_base.cc?sq=package:chromium&l=65 i.e. {audio: true, video: {mandatory: {minWidth: 1280, maxWidth: 1280, minHeight: 720, maxHeight: 720}}} so, it doesn't configure bitrate anywhere, at least to my knowledge. Where can bitrate be configured, in the constraints? Anywhere else?
,
Apr 27 2018
There's a x-google-start-bitrate value, e.g, set here: https://cs.chromium.org/chromium/src/chrome/test/data/webrtc/webrtc-simulcast.html?q=x-google-start-bitrate&sq=package:chromium&dr=C Not entirely sure that's a working and appropriate tool to use. Question is, is it fine with the purpose of the test that video is scaled down? If so, we can close this issue as works as intended. Or should we tweak the test to disable scaling?
,
Apr 27 2018
The test should reflect what happens in the default case here. If the behavior you're seeing is intentional and won't be bad for our users and downstream projects, please go ahead and WontFix the bug. If you think it makes sense to cover the case where x-google-start-bitrate is set, feel free to create a new case for that.
,
Apr 27 2018
Ok, I'll close this and go ahead with reland. It would be good to have the test also produce some stats on received frame size, then it will be easier to see if any later perf alerts are caused by changes to the scaling. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Apr 24 2018