You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All Daily.co resources, including MediaStreamTrack, should be cleaned up:
after successful call on destroy() in the Daily.co Call Object
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).
Click the Options (Kebab Icon) > More tools > Media -- to open the Media panel.
Click "Click to start a call" in the web page.
Notice that there should now be 1 media player in playing state.
Copy the URL and join from a different tab or window.
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.
Click the Leave call button in the second tab.
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.
Try opening again a second tab or window and join the existing call. On the original tab, share a screen.
Take note of the media players active in the page.
Quit share screen in the original tab.
Take note that the media players just doubled. This is due to re-rendering when switching views.
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)
The following was originally reported by @ahlrenzarqueza here
Expected behavior
All Daily.co resources, including
MediaStreamTrack
, should be cleaned up:destroy()
in the Daily.co Call ObjectDescribe 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 thepaused
state, instead ofstopped
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/playing
state.Leave call
button in the second tab.paused
state.Leave call
in the original tab that we are debugging. All media players are still visible in thepaused
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:
srcObject
tonull
/undefined
;.stop()
onMediaStreamTrack
given in theparticipants()
object.The above procedure causes a black screen (stopped video and audio tracks) as I believe it affects the original
MediaStreamTrack
provided by Daily.coI 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.coMediaStreamTrack
.System information
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/
The text was updated successfully, but these errors were encountered: