New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 836411 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Apr 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

13.9% regression in browser_tests at 553091:553100

Project Member Reported by niklase@chromium.org, Apr 24 2018

Issue description

https://webrtc-review.googlesource.com/70740 seems like the most likely cause.
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Apr 24 2018

All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=836411

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=35e9e4b1660c0844199caca0e24232e521fa7c2d4982f7d4fe093c73da7c107d


Bot(s) for this bug's original alert(s):

chromium-webrtc-rel-linux

Comment 2 by nisse@google.com, 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?
Cc: sprang@chromium.org
For software codecs WebRTC in Chrome use more or less the same codecs as standalone WebRTC, chat with sprang@ to learn more.

Comment 4 by nisse@chromium.org, 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'

Comment 5 by nisse@chromium.org, Apr 26 2018

Cc: phoglund@chromium.org
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?
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?

Comment 7 by nisse@chromium.org, 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?
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.

Comment 9 by nisse@chromium.org, Apr 27 2018

Status: WontFix (was: Assigned)
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