YouTube tutorial (Tsahi Levent-Levi) on measuring and reducing RTC CPU usage on client devices. Covers using RTCPeerConnection.getStats() to estimate per-frame encode/decode times, interpreting the "quality limitation reason" encoder metric ("cpu"), and mentions the experimental Compression Compute Pressure API in Chrome as a future solution. Provides a calculation example for 30 fps: 1000 ms / 30 = 33 ms per frame, suggesting encode time per frame should be below ~11 ms (one-third of frame budget) to leave headroom for other tasks.
Chapters
Hi, my name is Sahil Lewandlevi. I'm the owner of Bloggic Me and WebRTC courses and I'm here to break down real time communications so you don't have to. This time we're going to look at five different action items for RTC CPU optimization on the device. The first one is we need to understand if there is a problem and that we can do using get stats. Why looking at get stats as a way to do that? Because inside the browser there is no good way today to know what is the CPU performance of the device. So we need to estimate. How do we have that estimations? Well, we can check the encode time per frame. We take the total encode time from get stats and then divide that by the frames encoded and then we reach the average of time that it takes to encode each frame. We can do that second by second, for example, and get the numbers that we need. Now what would we would number here? Likely below a third of the time that we have per frame. So let's assume that we're doing 30 frames per second, which is usually what we do in WebRTC and in video conferencing. With 30 frames per second there are 33 milliseconds per frame within a second. I took 1000 milliseconds, divided that by 30. So a good encode time per frame would be below 11 milliseconds, for example. Why that's 33 divided by 3. We want to have that at that place so we will have more room for other things that we need to do like decoding and other things. We can also look at decode time. Sometimes we don't encode or we decode multiple different streams. So we can take the total decode time, divide that by frames decoded and reach the time that it takes us to decode each frame. Again with the same kind of an approach, calculation and understanding of what it means to be too high or too low. There is another way. In WebRTC you can go and check the encoder limits if you are actually encoding video. If you are an active participant in the video, there is a metric called quality limitation reason which tells you why the encoder decided to limit the bitrate that it is sending out and to encode less than it could or that the network allows. If that reason is going to be cpu, then we know that there is not enough CPU to encode, which means that might be a problem there with how we've balanced the system. So we need to work on that A new API that is coming out likely is Compression Compute Pressure API. That's an experimental API that is available today in Chrome. Go check it out. That might be the solution long term. Go and follow me at Blogic Me. Thank you.
