WebRtcGetUserMediaBrowserTest.SrcObjectRemoveVideoTrack is flaky |
||||
Issue descriptionhttps://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_browsertests&tests=WebRtcGetUserMediaBrowserTest.SrcObjectRemoveVideoTrack https://ci.chromium.org/buildbot/chromium.webrtc/Mac%20Tester/79096 First instance looks like corresponding to https://chromium.googlesource.com/chromium/src/+/6ffaac8d772617cc56ffdfecbba507cede2b5a5d.
,
Apr 20 2018
Issue 835460 has been merged into this issue.
,
Apr 24 2018
guidou@ can you PTAL? This test still fails with the suspect CL reverted, so I am not sure if the flake started there any more. AFAIU, this will call removeTrack() and expect an onresize event which sets video size to 0. However, onresize() event seems to be never triggered. https://cs.chromium.org/chromium/src/content/renderer/media/stream/webmediaplayer_ms.cc?type=cs&q=reloadvideo&l=409
,
Apr 25 2018
,
Apr 25 2018
This is related to https://chromium-review.googlesource.com/c/chromium/src/+/632957 When test fails, this seems to be happening: - Compositor thread receives the first frame and posts task to main thread for WebMediaPlayerMS::TriggerResize()[0]. - Main thread runs WebMediaPlayerMS::ReloadVideo() in the meantime with RendererReloadAction::REMOVE_RENDERER as stream.removeTrack() call comes from JS[1]. - Then, Main thread runs the scheduled task WebMediaPlayerMS::TriggerResize(). Since HasVideo() is false, no event is scheduled.[2] We can argue that TriggerResize() is late here, but that is the best effort as |current_frame_| is controlled on compositor thread. i.e. that frame might not even be displayed based on the render smoothness algorithm. CL makes sense too by not sending any event after video is stopped. guidou@ is it OK to not send any resize event, WDYT? [0] https://cs.chromium.org/chromium/src/content/renderer/media/stream/webmediaplayer_ms_compositor.cc?l=453 [1] https://cs.chromium.org/chromium/src/content/renderer/media/stream/webmediaplayer_ms.cc?dr=C&l=442 [2] https://cs.chromium.org/chromium/src/content/renderer/media/stream/webmediaplayer_ms.cc?dr=C&l=1000
,
Apr 26 2018
guidou@: Any update on this? If we cannot find a quick fix, we may need to consider disabling the test to avoid it messing with the webrtc bots.
,
Apr 26 2018
Let's disable the test. I'll take a look at it next week. chfremer@: Can you disable the test?
,
May 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0f25bc6ab6df509f64816f13866078caa72aaa6a commit 0f25bc6ab6df509f64816f13866078caa72aaa6a Author: Guido Urdaneta <guidou@chromium.org> Date: Wed May 02 10:47:53 2018 Disable flaky WebRtcGetUserMediaBrowserTest.SrcObjectRemoveVideoTrack Bug: 835332 Change-Id: Iceff1dcd64b2273e54097fb6a9e75becd156052a TBR: emircan@chromium.org Reviewed-on: https://chromium-review.googlesource.com/1039189 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Commit-Queue: Guido Urdaneta <guidou@chromium.org> Cr-Commit-Position: refs/heads/master@{#555343} [modify] https://crrev.com/0f25bc6ab6df509f64816f13866078caa72aaa6a/content/browser/webrtc/webrtc_getusermedia_browsertest.cc
,
Jun 4 2018
Bug 848330 is probably related. |
||||
►
Sign in to add a comment |
||||
Comment 1 by wzang@chromium.org
, Apr 20 2018