
A short talk (YouTube transcript) by Tsahi Levent‑Levi explaining how to choose video bitrate in WebRTC. He frames bitrate as one leg of a three-legged stool (bitrate, resolution, frame rate), discusses trade-offs between display resolution, frame rate and content motion, codec choice (compression vs CPU/support), and prioritizing bitrate asymmetrically across participants based on importance.
Chapters
Lets check what is a good video bitrate. For me, when I think about bitrate, I think of a three legged stool. Each leg of this tool stands for something. There is bitrate resolution and frame rate. When we change or tweak one of them, we need to play with the others. Otherwise the chair won't be stable anymore. Let's see what affects each one of them. We'll start with resolution. The first question to ask is what's the display resolution of the user? If the resolution is low, then the bitrate that we need to send should be relatively low. Why is that? We don't want to send a bitrate that is too high, that is good for a high resolution. Because then we send a lot of data. The receiver needs to decode a lot of data. But then it scales it down. If I scale it down, I use a lot of energy for sending, for receiving, for encoding, for decoding, for scaling, for displaying. So what we want to do is to try and send a resolution that will be close to the resolution that we want to receive and display. Next comes frame rate. And then frame rate depends on the content that we have. If what we have is something that moves fast, then we need more frames, a higher frame rate. If what we have is relatively static like this presentation, then a lower frame rate can be good enough. So based on the type of content, you might want to tweak the frame rate. Also remember, higher frame rate means that for the same bitrate I can have lower resolution because each frame requires bits. So if I lower the frame rate, I can increase the resolution. If I increase the frame rate, I need to lower the resolution. Next let's go and talk about bitrate. Something that we actually control with bitrate is what codec are we using? If this is VP8 or 264, it means that the compression rate are not going to be as good as VP9 or AV1, for example. The better the codec, the higher the compression rate and the more we can get in quality for a given bitrate. The downside of that is that we need more CPU and memory to run this codec. And the better the codec, the less devices we have that support it today. One more thing that we want to do with bitrate is to understand how important is this video. While bitrate is set over the network, we cannot send more than a given amount of bitrate, okay, because of network CPU and other things. What we do need to understand is the importance of that video. Let's say that we're showing displaying 20, 30 participants in a room. Some of them are not speaking at all. So for them, we might be able to reduce the bitrate or the resolution or the frame rate. If there is someone speaking, we would want to give him more bitrate out of the total that we have. So it's not as if everyone needs to get the same bitrate from everyone else. Okay. It doesn't need to be symmetric. It's asymmetric in nature. And it depends on on both the sender and the receiver, and what the receiver wants to see, and on the context, which is the importance of the video. If you want to learn more, check testrtc.com where we run testing and monitoring for WebRTC applications, including understanding what bitrate you're sending for video and the ramifications of that, and webrtccourse.com where you can learn more about WebRTC in general, but also bitrates and media quality. Thank you.
More from Tsahi

Meta rebuilt AV1 for mobile scale. Should smaller teams follow? | Chats with Arin









