BUG: Chrome encounters `Too many WebMediaPlayers` due to Daily.co not cleaning up MediaTracks

[ahlrenzarqueza]

Expected behavior

All Daily.co resources, including MediaStreamTrack, should be cleaned up: 1) after successful call on destroy() in the Daily.co Call Object 2) after participant leaves a call

Describe the bug (unexpected behavior)

After calling destroy(), Chrome's Media Player debug tool still shows playable streams that was involved in the call. They are in the paused state, instead of stopped state, thus occupying a resource.

Because of these undisposed media players, our custom UI faces Chrome's limitation outlined here. We face the Too many WebMediaPlayers issue when our end-users have a long session with 5-10 participants that ran for over an hour. I believe we overcome the limit due to the nature of our custom UI where Participant video tiles are re-rendered when switching back and forth to our layouts (we currently have three layouts in our Call UI).

Steps to reproduce

You can reproduce this on the Daily React Demo Netlify app: https://call-object-react.netlify.app/

1. Visit https://call-object-react.netlify.app/
2. Open Chrome Debugger Tools.
3. Click the Options (Kebab Icon) > More tools > Media -- to open the Media panel.
4. Click "Click to start a call" in the web page.
5. Notice that there should now be 1 media player in playing state.
6. Copy the URL and join from a different tab or window.
7. When the other tab has successfully joined the call, Media panel in the first page should now display >3 media players on the app (I believe these are the video and audio tracks of the newly joined participant.
8. Click the Leave call button in the second tab.
9. Take note of the Media players on the original tab. The players of that recently left participant was not disposed and stuck in paused state.
10. Try opening again a second tab or window and join the existing call. On the original tab, share a screen.
11. Take note of the media players active in the page.
12. Quit share screen in the original tab.
13. Take note that the media players just doubled. This is due to re-rendering when switching views.
14. Click also Leave call in the original tab that we are debugging. All media players are still visible in the paused state.

Steps 8-13 is a general flow in most video calls. Imagine this happens a lot especially in a real-world call. So it is technically a ticking time-bomb once a user reaches the Chrome limit of 1000 Media Players. Not to mention, a user can have other MediaPlayers opened in a different tab.

Screenshots

After doing all the steps, a total of 18 media players has been used, on a call of max. 2 participants.

Things I tried to circumvent on the issue

I tried:

• disposing the MediaPlayers by setting video and audio elements srcObject to null / undefined;
• call .stop() on MediaStreamTrack given in the participants() object. The above procedure causes a black screen (stopped video and audio tracks) as I believe it affects the original MediaStreamTrack provided by Daily.co

I also tried cloning the MediaStreamTrack but that causes a black screen too at times (very seldom). I think cloning does not fetch exactly the full state of Daily.co MediaStreamTrack.

System information

* Device: MacBook Pro 2021, 14-inch * OS, version: macOS Monterey Version 12.3.1 * Browser, version: Chrome Version 102.0.5005.61 (Official Build) (arm64) # Daily.co Version v0.26.0 # Additional context ## Issue of WebMedia Players https://chromium-review.googlesource.com/c/chromium/src/+/2816118 https://stackoverflow.com/questions/68480528/blocked-attempt-to-create-a-webmediaplayer-as-there-are-too-many-webmediaplayers ## Media Player Chrome Debugging tool https://developer.chrome.com/docs/devtools/media-panel/

[mattieruth]

Thanks @ahlrenzarqueza ! Ahh... the infamous Too Many WebMediaPlayers on chrome issue. Remember when that suddenly dropped to 75/40mobile? Those were fun days 😂 😭 . The good news, is that daily-js and the underlying daily logic is not actually what creates those players. The players are created when the track is attached to a media Element and the way to avoid leaking those is to make sure you set the srcObject to null before destroying the Element.

So this issue appears to be a bug on our call-object-react demo rather than daily itself. I'm going to see if I can move this there. Thank you for submitting!