In group video calls, effectively managing bandwidth is 90% of the battle

The biggest challenge you will have when implementing WebRTC group calling is estimating optimizing bandwidth use.

[In this list of short articles, I’ll be going over some WebRTC related quotes and try to explain them]

Video is a resource hog. Some say that WebRTC is a great solution for 1:1 calls, but is lacking when it comes to group calling. To them I’d say that WebRTC is a technology and not a solution. In this case, it simply means that you need to invest some effort in getting group video calling to work well.
See also the article on Video Calling API.

What does that mean exactly? That you need to think about bandwidth management first and foremost.

Why?

Let’s assume a 25 participants video call. And we’re modest - we just want each to encode his video at 500kbps - reasonable if we plan on having everyone at a mere VGA resolution (640x480 pixels).

🧮 Want to do the math together?

We end up with 12.5Mbps. That’s only for the video, without the overhead of headers or  audio. Since we only need to receive media from 24 participants, we can “round” this down to 12Mbps.

I am sure you have a downlink higher than 12Mbps, but let me tell you a few things you might not be aware of:

• A downlink of 100Mbps doesn’t mean you can really get sustainable 12Mbps for a long period of time
• It also doesn’t mean you can get 12Mbps of incoming UDP traffic (and you prefer UDP since it is better for sending real-time media)
• Most likely, your device won’t be able to decode 12Mbps of video content at reasonable CPU use
• And if you have hardware acceleration for video decoding, it usually is limited to 3 or 4 media streams, so handling 24 such streams means software decoding - again running against the CPU processing limit
• The larger the group the more diverse the devices and network connections. So you’ll be having people joining on old devices and smartphones, or with poor network connections. For them, 12Mbps will be science fiction at best
• As a rule of thumb, I’d look at any service that uses over 3-4Mbps of downlink video traffic for video group calls as something that wasn’t properly optimized
• Group calls means more bandwidth management. And that usually mean simulcast. And that means understanding how simulcast works and what optimizations are available with it

You can get better at it, trying to figure out lower bitrates, limit how much you send and receive and do so individually per participant in the video group meeting. You can take into consideration the display layout, the dominant speaker and contributing participants, etc.

💪 That’s exactly what 90% of your battle here is going to be - effectively managing bandwidth. It is part of how you deal with packet losses

Going for a group video calling route? Be sure to save considerable time and resources for optimization work on bandwidth estimation and management. Oh - and you are going to need to do that continuously. Because WebRTC is a marathon not a sprint 😀

👉 Scaling WebRTC is no simple task. There are a lot of best practices, tips and tricks that you should be aware of. My WebRTC Scaling eBooks Bundle can assist you in figuring out what more you can do to improve the quality and stability of your group video calling service.