"WebRtcGetUserMediaBrowserTest.TwoGetUserMediaWithFirst1080pSecondVga" is flaky |
||
Issue description"WebRtcGetUserMediaBrowserTest.TwoGetUserMediaWithFirst1080pSecondVga" is flaky. This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label. We have detected 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyTwsSBUZsYWtlIkRXZWJSdGNHZXRVc2VyTWVkaWFCcm93c2VyVGVzdC5Ud29HZXRVc2VyTWVkaWFXaXRoRmlyc3QxMDgwcFNlY29uZFZnYQw. Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs
,
Oct 31 2016
,
Oct 31 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/311334d067565ebc59bb40e29028db2c324fcb7c commit 311334d067565ebc59bb40e29028db2c324fcb7c Author: phoglund <phoglund@chromium.org> Date: Mon Oct 31 10:50:19 2016 Disabling flaky WebRtcGetUserMediaBrowserTest.TwoGet...1080pSecondVga. BUG=660656 TBR=perkj@chromium.org Review-Url: https://codereview.chromium.org/2464783002 Cr-Commit-Position: refs/heads/master@{#428680} [modify] https://crrev.com/311334d067565ebc59bb40e29028db2c324fcb7c/content/browser/webrtc/webrtc_getusermedia_browsertest.cc
,
Oct 31 2016
I don't know why this would be flaky now but I assume we do some analysis on the received frames that might be slow. There is another test TwoGetUserMediaWithFirstHdSecondVga that still run.
,
Nov 1 2016
Yeah, but hd=720p right, so maybe that's fast enough.
,
Nov 1 2016
The time for the 1080p test on my Linux workstation is around 8 seconds. The "FirstHd" variant takes around 5 seconds. What's the time limit for these tests?
,
Nov 8 2016
The logs provided by phoglund and the stack indicate that the video element contains video of size 2.
"Aspect ratio corrupted. X 1 Y 1 width 2 height 2"
So I wonder what it is that can cause that? The js detectAspectRatio called from here.
videoElement.onloadedmetadata = function () {
detectAspectRatio(callback, videoElement);
};
,
Nov 8 2016
I should add that I have tried running this test under asan 60 times without beeing able to repro. |
||
►
Sign in to add a comment |
||
Comment 1 by phoglund@chromium.org
, Oct 31 2016Owner: perkj@chromium.org
Status: Assigned (was: Untriaged)
Per, can you help with an owner? Looks like the test has been flaky for a while. At typical error is: Value of: ExecuteJavascriptAndReturnResult(command) Actual: "Error: Aspect ratio corrupted. X 1 Y 1 width 2 height 2 at failTest (http://127.0.0.1:45251/media/webrtc_test_utilities.js:40:15) at detectorFunction (http://127.0.0.1:45251/media/getusermedia.html:514:11)" Expected: expected_result Which is: "w=1920:h=1080-w=640:h=480" With diff: @@ -1,1 +1,3 @@ -w=1920:h=1080-w=640:h=480 +Error: Aspect ratio corrupted. X 1 Y 1 width 2 height 2 + at failTest (http://127.0.0.1:45251/media/webrtc_test_utilities.js:40:15) + at detectorFunction (http://127.0.0.1:45251/media/getusermedia.html:514:11) AFAIK none of the other tests are flaky, so it could be that the 1080p case is just too slow for some of the bots? There was also a note that this test timed out on win7. There may be ways to make the test faster to help resolve this, like making the pixel processing faster here: https://cs.chromium.org/chromium/src/content/test/data/media/getusermedia.html?type=cs&q=%22Aspect+ratio+corrupted%22&sq=package:chromium&l=461. With that said, it appears the code has time to finish at least in the above case. Could there be glitches in 1080p rendering, or is the test more sensitive to 1080p video in som other way?