This content was created by Tsahi Levent-Levi. This content was uploaded by Tsahi Levent-Levi. This is a YouTube video titled "In which WebRTC scenarios you shouldn't use simulcast in your application?" created on June 8, 2024. It features a technical discussion between two speakers about the use of simulcast in WebRTC applications, specifically addressing scenarios like one-on-one calls, audio-only calls, and screen sharing.
Chapters
Okay. In which WebRTC scenarios you shouldn't use simulcast in your application.
So the answer to that is typically in one on one calls because simulcast has an overhead. So you have encode the high resolution, then you encode a quarter of that and then a 16th of the original resolution. That means your bandwidth is going to be 1.4 ish of the bandwidth you would usually use.
And if we are in a one on one call and you're generating three video streams that are relatively the same but different bit rates. I only need one of them, not all three of them.
Yes. Basically why are you doing it? Because simulcast typically solves adaptation problems and we don't have an adaptation problem because I can just adapt to what you want to receive.
Okay, so one on one calls, we don't use simulcast.
Yes.
What about audio only calls?
Well, no videos there and we don't have audio simulcast.
Okay, and then screen sharing. Screen sharing is video.
It is video. And you might argue that you can send multiple resolutions, but I haven't seen that used much in practice because you want the full resolution in simulcast. So the only thing you do is temporal scalability. So adapting frame rates.
I think there is another thing to to notice here. If I'm using a webcam, I'll do anywhere between 720p VGA, maybe 1080p. There is not much 4k. Unless this is a very dedicated application for a very specific reason. Screen sharing today would start with 4k or 5k depending on the laptop that you have.
Yes.
So you're starting for a resolution that is already too high for the machine to deal with. And now you're saying, well, let's do simulcast with multiple bitrates, resolutions, frame rates and whatever.
Yes. That's not going to fly with your cpu.
Yeah. Okay, so screen sharing probably not a good idea.
Just go for temporal scalability.
Okay. Anywhere else we shouldn't be simulcasting.
Other than that, it's basically you would use simulcast in all group call scenarios.
But I might not send multiple layers. Although I'm using simulcast.
Yes. If nobody is watching your high resolution layer, you could just turn it off dynamically while using simoncast and just not encode that. That way you would save the CPU for encoding and the network traffic for uploading it.
Yep. Okay, so to sum things up, simulcast, we don't use in one on one in audio, probably in screen sharing. And when we're trying to optimize the network of a group call and not send things that nobody is watching.
