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

Issue 835332 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

WebRtcGetUserMediaBrowserTest.SrcObjectRemoveVideoTrack is flaky

Project Member Reported by emir...@chromium.org, Apr 20 2018

Issue description

Comment 1 by wzang@chromium.org, Apr 20 2018

Cc: jdufault@chromium.org wzang@chromium.org
Affecting linux-chromeos-rel as well https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/
Cc: mstensho@chromium.org patricia...@chromium.org jwd@chromium.org steimel@chromium.org
 Issue 835460  has been merged into this issue.
Owner: guidou@chromium.org
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

Comment 4 by guidou@chromium.org, Apr 25 2018

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

Comment 7 by guidou@chromium.org, Apr 26 2018

Let's disable the test. I'll take a look at it next week.
chfremer@: Can you disable the test?
Project Member

Comment 8 by bugdroid1@chromium.org, 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

Bug 848330 is probably related.

Sign in to add a comment