Bug 209673 – Background tabs playing audio or broadcasting via WebRTC should not throttle video elements

• Component: WebRTC
• Status: NEW

Created attachment 394742 [details]
Video file generated by following the provided steps to reproduce

Note 1) Given the same steps to reproduce, Chrome does not have this issue
Note 2) Mozilla has the same problem and is looking into fixing it. Here is my bug report with them https://bugzilla.mozilla.org/show_bug.cgi?id=1624453

Stept to reproduce:

1. In Safari, enable MediaRecorder by going to Develop > Experimental Features > MediaRecorder (PLEASE BE AWARE that this reproduction uses MediaRecorder simply to save the recorded video. The WebKit issue reported here is independent of MediaRecorder.)
2. Visit https://jsfiddle.net/fj8yv47x/
3. Click "RECORD"
4. Switch to a different Safari tab
5. Move something back and forth in front of your camera
6. Return to the original browser tab
7. Click "STOP/DOWNLOAD"
8. Go to your downloads folder and play the resulting video file
While watching the output video, notice that after switching away from the first Safari tab, the output video begins outputting about 1 frame per second

Actual results:

I'm using canvas to combine multiple MediaStreams (in this simple demo I'm only combining camera and microphone) into a single output stream. However, when the user switches away from the tab controlling the canvas, the video element to which the canvas is subscribing in order to render the output stream stop rendering despite both an audio and WebRTC stream being active in the tab.

For context, in our production application we allow users to share their screen, camera, and microphone. We then combine all three streams, placing the camera feed in the bottom right of the output using canvas. Screen capture is the primary reason our users switch away from our browser tab while capturing streams.

When I switch away from a browser tab with an active video element, the element stops rendering (understandable behavior for battery/performance savings).

However, because canvas does not accept a MediaStream as an input and must therefore rely on output rendered to a video element, when the video element stops rendering, so too does my canvas output stream.

Expected results:

Video elements in background tabs that are exempt from throttling based on the criteria in the MDN link below should continue rendering as normal. If this is not possible, it would be great to continue rendering frames to video elements that Firefox can detect are in use by canvas elements.

https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API#Policies_in_place_to_aid_background_page_performance

[Radar WebKit Bug Importer]

<rdar://problem/60991087>

Hi, has there been any progress here? Is there any information I can help provide? Thank you!