Too many WebMediaPlayers intervention

🎻 August 2021 fiddle

Want to learn more about WebRTC?

Look us up here for the WebRTC Fiddle of the Month, created… once a month.

Or just enroll to one of our excellent WebRTC training courses.

Resources

• Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1232649
• Peer Connection sample: https://webrtc.github.io/samples/src/content/peerconnection/pc1/
• Peer Connection Audio only sample: https://webrtc.github.io/samples/src/content/peerconnection/audio/
• Fiddle: https://jsfiddle.net/fippo/pvmLdex5/2/
• chrome://media-internals

Transcription

Tsahi: Hi and welcome to the WebRTC Fiddle of the Month, and this time we’re going to talk about WebMediaPlayer and the intervention – or the intervention that happened around that in Chrome 92. So, Phillip, can you guide us through or let’s see what the problem exactly is.

Philipp: Yes, let me share my screen and demonstrate the problem. So in Chrome 92, there was a change which causes an exception to be thrown. If you created new media elements or audio or video element and attached the source object to it. And if you did that too often, it started throwing an exception. So we can see that we have a media element playing and created a lot of them – 100, which kind of worked before, but in Chrome 92 it was showing this error: “intervention blocked attempts to create the WebMediaPlayer as there are too many media players already in existence”.

Tsahi: and I think the magical arbitrary number was 75.

Philipp: Yes. Which is the reason we have 26 errors here, because we have 1 element. We created 75. Or 74 -and the rest threw an error.

Tsahi: But 70-something seems like a good enough number. What’s the problem with that?

Philipp: Well, you might be supporting more participants in your WebRTC application. And apparently there was a bug where actually destroying them properly didn’t decrements that count.

Tsahi: OK.

Philipp: So if we look at this, how to do it properly, we can use the WebRTC audio sample as a good starting point and we make a call. Prepare to mute the element. So we see the audio level is decoded here.

Tsahi: OK, so what we see is getStats() information about the audio session that we now have.

Philipp: And if we just remove the element from the DOM, it stops playing the audio. So you think, oh, the element is gone, but you can see it actually continues to have the audio level. And that is a sign that Chrome is continuing to process the audio in the background. And if we actually set the source object to null. We can see that it just drops and it won’t go back up again. So this the proper way to remove the element: To set the source object to null and then removing it from the DOM.

Tsahi: OK, I guess that’s important even for small calls, because people join and leave and that might create additional video and audio elements that we are just creating whenever someone rejoins a session.

Philipp: Yes. And we can see in chrome://media-internals/ the lifecycle. So here we Started to play in the beginning, then after 23 seconds, it went into pause mode when we removed the element from the DOM to stop the playout and only when we removed the source object at 49 seconds, it destroyed the WebMediaPlayer. And the WebMediaPlayer is a memory heavy object which you don’t want to keep around for too long.

Tsahi: OK, so what do we learn out of all of this? I mean. We had an issue, let’s say Google screwed up a bit by making the change and putting the limit, the reasons for putting the limits might be OK. They wanted to limit the memory allocation and using chrome, which makes sense. It’s a memory hog anyway. So let’s limit what developers can do.

Philipp: Yes. I mean, you need to deal with that if you have a large number of audio elements. It just doesn’t work to say: “oh, we support one hundred participants” and then never tested because you don’t notice when someone runs out of memory easily. So you’re doing this very carefully, considering how many source objects do you need to attached at a given point in time. So if you have video participants, you can easily detach the source objects and thereby freeze the player.

Tsahi: OK, so developers will start to figure out how to use less elements that are being displayed or part of the DOM and then recycle them as they move forward.

Philipp: Yes

Tsahi: I guess the best thing the best advice here is to just test on Canary and Beta, because this is where you’re going to find issues and you don’t want them to roll out in production has happened in this bug for all the vendors involved which were like gazillion of them.

Philipp: Yes, this is affected a lot of people and it couldn’t be changed until those Chrome stable refresh, which happened two weeks after the first release. So your application might have been broken for two weeks. But then you should have tested in Beta and Canary and if you didn’t…

Tsahi: OK, so thank you and let’s meet up in the next WebRTC Fiddle of the Month.