Unable to reproduce this issue on reported version 66.0.3359.45 using Ubuntu 17.10 with steps mentioned in comment#0.

1. Started video call in appear.in and joined in another tab.
2. Muted video of first tab and didn't observe video on both first and second tabs. Attaching screenshot for reference. 

@Reporter: Could you please let us know if we miss anything from steps. Any further information on reproducing the issue will be helpful.

Thanks!

Deleted: 824866.png 1.7 MB

	824866.png 1.7 MB View Download

#2: you need to run this in the JS console:
document.querySelectorAll(".jstest-video-frame").forEach(e => e.classList.remove("ng-hide"))
and check that the upper left and lower right videos are black. Also unclear if this works with real hardware or if its just with the --use-fake-device-for-media-stream command line flag.

Also reproducibility is somewhere between 10 and 20%. I can attach a screen recording if that helps.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

As per comment#3 checked the issue on reported version 66.0.3359.45 using Ubuntu 17.10 and is not reproducible.

1. Launched chrome using --autoplay-policy=no-user-gesture-required
2. Started video call in appear.in and joined in another tab.
3. Muted video of first tab and didn't observed black video on both first and second tabs. Attaching screenshot for reference. 

Tried the same scenario for almost 10 times and able to see black video on both ends. Also as per comment#0 and #3 reproducibility chance is very less. As issue is not reproducible from TE end and as issue is inconsistent from reporter end removing Needs-Bisect label.

Also cc'ing mlamouri@ from similar  bug 804091  for further inputs on this.

Could someone from Blink>GetUserMEdia team please have a look at this issue.

Thanks!

Deleted: 824866 _M66.png 374 KB

	824866 _M66.png 374 KB View Download

Regarding similarity to  bug 804091 , it was discussed over there and this bug was created because it was different. Is there something that makes you think that might not be true?

#6: the only similarity is that it does not happen with the old autoplay policy. 

This is a case of continuing to play a stream while/after hiding the video element and not getting the expected result.

As per comment#2 and #5 issue is not reproducible from TE end. Could someone from Blink>GetUserMedia team please have a look at this issue. Hence adding TE-NeedsTriageHelp label.

Thanks!

there is a change in behaviour here which seems related and is much easier to reproduce (always!). Many thanks Guido for making me look at the right thing.

1. go to appear.in in a single tab
2. mute the camera
3. observe document.querySelectorAll("video").forEach(v => console.log(v.currentTime))

In M65 or with the --autoplay-policy=no-user-gesture-required flag currentTime advances. In M66+ v.currentTime does not advance.

If *for some reason* the video stops playing before the track.enabled comes into effect this might explain the behaviour I am seeing.

and the video's paused is true.

I can explain what happens at least for the remote video element. This is a race between hiding the video element (which now seems to cause it to be paused because it is muted?) which is signaled via the appearin signaling servers and the black frame being rendered. I bet this is much easier to reproduce in a network which includes udp packet loss.

I do not have a good explanation for the local behaviour. This is possibly a race between hiding the video element (which causes a pause) and telling webrtc.org to generate black frames.

I've managed to somewhat reproduce this in a simpler environment. On 
https://webrtc.github.io/samples/src/content/peerconnection/pc1/
run the following script after making a call:
localStream.getVideoTracks()[0].enabled = false;
var remoteVideo = document.querySelectorAll("video")[1];
remoteVideo.style.display = 'none';
setTimeout(() => {
  var canvas = document.createElement("canvas");
  canvas.width = remoteVideo.videoWidth;
  canvas.height = remoteVideo.videoHeight;
  var context = canvas.getContext("2d");
  context.drawImage(remoteVideo, 0, 0, canvas.width, canvas.height);
  canvas.style.width = '320px'; canvas.style.height = '240px';
  document.body.appendChild(canvas);
}, 1000)

In M66 this *sometimes* gives a non-black canvas element.

on https://webrtc.github.io/samples/src/content/peerconnection/pc1/
paste the following:
  var v = document.querySelector("video");
  v.muted = true;
then click "start" and paste this:  
  v.style.display = 'none';
and then run this a couple of times:
  console.log(v.paused, v.currentTime, v.webkitDecodedFrameCount)

this changes behaviour of the following:
1) videoElement.currentTime
2) videoElement.webkitDecodedFrameCount
3) drawing videoElement to a canvas

I don't see this kind of stuff being mentioned in https://developers.google.com/web/updates/2017/09/autoplay-policy-changes or anywhere else. 

So the issue is that the default autoplay policy pauses the muted video element when doing 
   v.style.display = 'none'

Assigning to mlamouri@ for further analysis/triaging from the autoplay policy side.

Yes this is being paused by AutoplayPolicy because we do not allow videos to play if they are not visible.

You can get around this by using play() instead of the "autoplay" attribute.

beccahughes: i disagree but lets continue discussion in 835767. No point in having the same discussion in two different issues.