Short transcript of a technical conversation (two speakers) about whether a group video service can be built without media servers. Speakers contrast the historical ‘‘full mesh’’ approach (direct peer-to-peer connections) with using media servers (SFUs), arguing full mesh fails to scale beyond a few participants and has two main problems: (1) high upstream bandwidth requirements (tens of Mbps) for real-time streams, and (2) heavy client CPU usage because browsers encode a separate video stream per peer. The speakers conclude that using a media server is the practical choice for serious group chats.
Chapters
Can you build a group video service without media servers.
In the past? So in 2012, everyone was like, yes, let's do this. Let's use this full mesh approach. And for a couple of years that was quite in vogue. But since we have now good open source SFUs, everyone who wants to do a serious group chat does that. Problem with full mesh is that it doesn't scale. So you can get at most four participants, maybe eight if you know how to tweak it properly. But quality won't be as good as asfu.
Yep, I think there are. There are two problems and people focus on one of them. The one that they focus on is the fact that in a mesh solution where you don't have a media server, so I'm going to send my video to all other participants in the call. I need the higher uplink connection, so I can't use one or two megabits per second. I need 10 or 20 megabits per second to begin with. And these are megabits that are, let's call it, more expensive. They're not like the ones that we need for Netflix or Google Drive or YouTube. They're ones that run in real time and we have a lot less of them. Nobody tells us that, but that's true. The second problem is that WebRTC isn't optimized for that use case in the browser, which means that WebRTC will use a separate encoder for each and every one of these participants. So if I'm in a call with 10 people, I'm going to actually encode the video nine times, one for each one of the participants. The encoder is the part that takes the most amount of cpu. And that means that we're hurting the machine a lot further than we should.
Yes, yes, we can. I mean, it won't be possible to optimize, but nobody did that in the last 10 years because if you solve that problem, you still have the other problem of limited upstream bandwidth. It remains surprisingly popular to ask for this use case, but just get over it. Pay for your media service, be done with it.
