Local and remote video goes black when foregrounded after being backgrounded.

• Component: WebRTC
• Status: RESOLVED CONFIGURATION CHANGED

[Manjesh Malavalli]

Steps to reproduce:

1. Join a room in https://appr.tc/ from desktop Chrome.
2. Join the same room in iOS Safari.
3. Background iOS Safari, and play a YouTube video for a few seconds.
4. Foreground iOS Safari.

Expected behavior:

Local and remote video should resume rendering.

Actual behavior:

Local and remote video are black.

Note:

I created this codepen: https://codepen.io/manjeshbhargav-the-scripter/pen/LYjOGWg to investigate, and at least in the local video case, the video is black only if audio is also acquired. It actually resumes rendering if only video is acquired.

[Radar WebKit Bug Importer]

<rdar://problem/85179799>

[Phong Le]

I also got this issue but I know exact reason: "The local video stream has not been resumed to play"

I did some investigation on this and can confirm this bug on 15.1.1.

What I found is that the camera stream goes to muted in both cases if you background and foreground quickly. It works ok if you do it after some time.

Further investigation using https://codepen.io/daginge/pen/jObpmVq shows that if you do it fast, the visibilitychange event doesn't fire as expected in this case.

I suspect what happens is that the OS mutes the camera stream, but the browser doesn't yet know that it was backgrounded. And you have the chance to open the browser again before the browser has time to fire its internal state, and never requests the video stream back. I'm not too familiar with the specifics of Webkit and iOS here though.

To replicate:
- Go to https://codepen.io/daginge/pen/jObpmVq
- Verify that you can see and hear yourself
- Quickly go to the home screen and back (<1 seconds)
- See that the camera is muted, but never unmuted
- Note that the visibilitychange event is not in the logs as expected. If you do it and background for >2 seconds the visibility change event is there and the camera stream works.

Sadly this means that detecting this bug might be hard. Could have a listener for the muted event and see if a visibilitychange is detected, and if nothing happens after 5 seconds prompt the user to restart the stream

We (Nienke @ Confrere) tested 15.2 (19C56) on an iPad Air 4th Gen. Seems the issue has been fixed there at least. Would love for someone else to confirm though, I don't have access to my test device currently.

Never mind, we were able to replicate on 15.2 as well. It's just a faster processor we think than my device, so it's a bit harder to trigger properly.

[youenn fablet]

@Daginge, I cannot reproduce locally on 19C56 with your steps.
We did a fix in that area where track would not get unmuted.
Since you can repro, can you tell what the state of the video track is (still muted?).
You can send me a sysdiagnose ([e-mail]) as well.
Thanks

You're right youenn, tested it now on my iPhone XR (19C56) and could not replicate using the steps described in this bug report.

If we do figure out what caused the video to fail in the other case we'll file a separate issue.

I think this can safely be closed as fixed in 15.2.

[PhungDuong]

(In reply to youenn fablet from comment #6)
> @Daginge, I cannot reproduce locally on 19C56 with your steps.
> We did a fix in that area where track would not get unmuted.
> Since you can repro, can you tell what the state of the video track is
> (still muted?).
> You can send me a sysdiagnose ([e-mail]) as well.
> Thanks

Hi @youenn,

We can confirm and reproduce this bug on iOS/iPadOS  15.1, 15.2, 15.3, 15.4, 15.4.1 & 15.5
Here are steps to reproduce:
1. Open the link using webRTC (https://it.dev-akameet.link/video/room/videocall)
2. Allow micro and camera.
3. Click the button to join the meeting.
Expected: The local video is normal.
Actual: The local video is black.

Note: From step 2 to step 3 do with speed as fast as possible. When you can't repo it, close the safari, open it again, and repeat the steps above, because the frequency isn't 100%.