WebRTC bandwidth requirements

Question

Does anyone know what are WebRTC bandwidth minimal requirements? I'm interested in what are the values with or without video and for different video resolutions. I'm especially interested in a two party conference, but if you know the values per party it's also good.

If you have actual metrics is nice, but also if you know how can I theoretically calculate this is also good.

Also, different browsers have different bandwidth requirements?

Puppis

Answer 1

The bandwidth requirements are almost the same as the bandwidth requirement for opus and vp8. Real time audio typically has a bitrate of 40-200kbit/s. Video requires at least 200 kbit/s (500kbit/s if you want to see people's faces).

According to webrtc-experiment the minimum bandwidth for opus is 6kbit/s and for vp8 100kbits/s. So in total that makes 106kbit/s but when you account for the overhead of the webrtc protocol stack and constantly varying network conditions I would guess that 200kbit/s is the minimum if one wants stable video and audio.

Chrome and Firefox both use opus and vp8 so the bandwidth requirements should be the same. Although I don't have any hard data to prove it.

You can see the current traffic generated by webrtc by going to chrome://webrtc-internals and inspecting all the charts.

Headpiece

Do you know if the webrtc-experiment refers to Chrome only or it is about other browsers as well? – Puppis

opus and vp8 are separate not-connected to webrtc projects so the results in webrtc-experiments regarding these two technologies should be browser independent. I don't know about the rest of the results. I guess that they refers to both Chrome and Firefox. After all the two implementation share some code and the testing looks quite thorough. – Headpiece

why P2P video call need bandwidth for turn and stune server?? I think after connected, the turn and stune server no need to do any thing? – Gannie

Answer 2

For two-party conferences, 500 kbit/s for good conference-quality should be enough (per stream, so 1 Mbit/s load on a user's line). I'm in line with the other answer about that.

However, multi-party WebRTC bandwidth can be bottlenecked not just because of participants' Internet bandwidth, but also due to potential bandwidth limits of a TURN media relaying server, if you use one – ­which is needed where no P2P connections are possible due to difficult NAT setups. (All the details here.)

I attempted a rough calculation of how many users a TURN server can serve before maxing out its bandwidth:

• Let's say we have 100 Mbit/s server bandwidth in total (in + out), and we want at most 60 Mbit/s used up by WebRTC traffic.

• So for example when configuring the coturn TURN server, we'd set input and output stream each to 30 Mbit/s (3,750,000 Byte/s, using bps-capacity=3750000).

• The output stream will experience the higher load, because given n participants, there will be 1 video input stream and n-1 video output streams per participant for the TURN server to handle. Means the bottleneck will be the 30 Mbit/s combined output stream.

• In the worst case (where no STUN negotiated P2P connections at all are possible), this bandwidth will suffice for: 30 Mbit/s / 500 kbit/(s*stream) = 60 video streams.

• Given n participants, there will be n-1 output streams per participant, which means a total of n * (n-1) = n^2 - n streams. Our max. 60 streams are then enough for: n^2 - n = 60 <=> n = 8.26 = ~8 participants (calculation).

Not sure yet how accurate this is, though.

Gamber