remote video is also frozen and no video rtp packets are received.

note that this updates the picture:
var v = document.querySelectorAll("video")[0];
v.srcObject = v.srcObject

as does (sometimes?) moving the mouse between the buttons and the main ui or the js console.

 Issue 804092  has been merged into this issue.

this seems to be related to devtools being open. If devtools is open, video does not render...

(see also 803004 which turned out to be this really)

hrm wait. the original steps don't require devtools to be open... I can get 803004 without this and this without devtools.

\_(ʘ_ʘ)_/

so here is an interesting variant (but it requires devtools while the original report does not)
1. go to https://webrtc.github.io/samples/src/content/getusermedia/canvas/
2. observe video.
3. open devtools.
4. if video is not frozen, close devtools, go to (3)
5. have someone else wave into the camera, take a snapshot. Note that the video does not show the person waving
6. close devtools
7. look at snapshot image which should contain person (and only be updated after closing devtools)

This suggests something is wrong with rendering

Is there a chance that this is platform dependent? I'm unable to reproduce this on a mac with the current canary. I'm using cmd+alt+I to toggle devtools on/off, but there's no freeze.

i've seen it on windows too in latest canary there.

I was able to repro on Linux and Mac using the instructions in the original report.

I tracked the problem to r524987.
If I revert that change locally, the problem disappears.
mlamouri@: Can you take a look?

The problem disappears if chrome is started with --autoplay-policy=no-user-gesture-required

note that we *might* reset srcObject which was a workaround for https://bugs.chromium.org/p/chromium/issues/detail?id=720258 which doesn't apply anymore.

i'll check if removing that woarkaround avoids the problem but not change our production code yet to allow an easier repro.

\o/

while webkitDecodedFrameCount increases, so does webkitDroppedFrameCount which might be a way to write regression tests for this. Thanks guido!

Autoplay changes will not launch in M65. Though, I'm not sure how this is related to autoplay. I seem to be able to get some frames to show up sometimes.

Are there x-origin iframes involved by any chance?

there are probably some on appear.in but not in the case of #7
But I wonder if this is the same issue or just looks the same.
guido: have you tried #7 with the flag (or bisecting)?

from fun things to try: appear.in does allow drag+drop with the video by clicking it, holding and dragging. While dragging the frozen video it is rendered...

guidou@, can you have another look at this based on the recent comments?

My guess (totally unbased on trying anything) is that resuming play after setting a new srcObject is now defined to consume an user gesture, and the way things are wired together in appear.in, it's not getting one.

well, there are weird non-appear.in issues as well.

mlamouri@: Is it OK to revert r524987?

I don't think so. Though, as I pointed out, it's not obvious this is related to this change as there is no autoplay error in the console and I was able to get the video to update a couple of frames with the autoplay restrictions.

Well, the error started with that CL and gets fixed by reverting it.
Shouldn't we revert and investigate why the change triggers this regression before relanding?

This change is known to break websites, we will not revert it on Canary/Dev because of this as it's the best way for us to actually hear about the breakages.  

Though, there is nothing in the STR that sounds like a clear autoplay issue as there are user gestures on the page and there is no iframe involved. The autoplay policy doesn't use user gesture consumption so hta@'s guess in comment #22 might not work either.

If it's not clear how this CL breaks appear.in, how can you decide if this is an acceptable consequence of autoplay restrictions?

This is an "intervention" in the sense that we know we will break websites as we are reducing what they can do. This is the kind of things that can't be discovered in any other way that actually having the code enabled. It's currently breaking high profile websites in some way or another (Twitch for example).

The fact that I haven't seen yet how it's related to the autoplay restrictions is orthogonal.

fippo@, you got quite unlucky. Your <video> is marked as muted and has the autoplay attribute which makes it take a very specific path. When the camera is toggled on and off, it changes the video src and for some reasons, we never acknowledge that the video is actually visible.

FWIW, this bug should appear on your mobile website if you are using the same code.

This is a test case FWIW: https://mounirlamouri.github.io/sandbox/autoplay/autoplay-muted-reuse.html

mlamouri: thank you! I don't think this whole behaviour makes sense for videos which have a local mediastream attached though (and those are typically muted since otherwise you get feedback if there is an audio track from getUserMedia)

I think I an fix us resetting the srcObject which was a woraround for <M61.

What are we going to do about #7 which has less clear steps to reproduce? Go back to  issue 803004 ?

Actually #7 is one of the reasons why I thought it may not be related to autoplay. I would recommend to wait for the fix to land and see if it helps and file another bug if it doesn't.

I wouldn't recommend to use a workaround as a fix should be in soon unless you Chrome Dev population is high enough to be worth the extra work on your side.

#34: this is caused by us resetting srcObject because of https://bugs.chromium.org/p/chromium/issues/detail?id=720258 and this is no longer required in 65. Removing that reset resolves the issue. Can I move ahead since you seen to have a good minimal repro?

I'm not sure what you mean here. We don't need to test the issue on appear.in as we indeed even have an automated test now.

we're good then, thank you :-)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ef28e2a3c5bceaeff46da187529966bdeb194394

commit ef28e2a3c5bceaeff46da187529966bdeb194394
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Tue Jan 30 10:25:14 2018

Autoplay muted: fix visibility detection when the source was changed.

The autoplay visibility observer is reset in various situations but
wasn't when the source of the video was change which broke use cases
such as playing A then switching to B. B would freeze to the first frame
and never update.

Bug:  804091 
Change-Id: I984d4c5d67c575d3c45f50877d329264c1a6020e
Reviewed-on: https://chromium-review.googlesource.com/890942
Reviewed-by: apacible <apacible@chromium.org>
Commit-Queue: Mounir Lamouri (slow) <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532828}
[add] https://crrev.com/ef28e2a3c5bceaeff46da187529966bdeb194394/third_party/WebKit/LayoutTests/media/autoplay/muted-change-src.html
[modify] https://crrev.com/ef28e2a3c5bceaeff46da187529966bdeb194394/third_party/WebKit/Source/core/html/media/HTMLMediaElement.cpp