Quality limitation stats in WebRTC

🎻 January 2022 fiddle

Want to learn more about WebRTC?

Look us up here for the WebRTC Fiddle of the Month, created… once a month.

Or just enroll to one of our excellent WebRTC training courses.

Resources

• The fiddle: https://jsfiddle.net/fippo/jebpk9r8/20/
• The stats: qualityLimitationReason
• Current bug in Chrome: https://bugs.chromium.org/p/webrtc/issues/detail?id=13548

Transcription

Tsahi: Hi and happy New Year. We’re again in WebRTC Fiddle of the Month. And this time, we’re going to talk about the new quality limitations and statistics that exist in WebRTC. Philipp, lead us through.

Philipp: Yes, let me share the tab. So we have a very simple fiddle once again. The first thing we do is we create the peer connections, we wire up the on ICE candidates with the other sides add ICE candidates, then we negotiate as we usually do. We do a 720p getUserMedia() stream only for video, because I don’t want echo on this. We add the track to the peer connection, we create an offer, then we exchange offers, we exchange answers, and then it negotiates. That is fairly standard so far. What we do here is we set an interval. So we have things that we call each second and which will then call getStats(), the API to get statistics from the peer connection. And we’re looking at the outbound RTP stats. And one thing we can get from that statistics is the resolution, which is the frame width and the frame height. And the more interesting thing is something that came recently in Chrome 93, and that is the quality limitation durations. And that is a somewhat unusual statistic because it’s not a number or string, but a record. So it’s an object to JavaScript. And that is an enumeration. You can have several values, you can see them here. We have the other reason, which is a catch all for something is wrong. We have CPU limitations, we have bandwidth limitations, and we have none here. And statistics is currently a bit buggy, because it’s counting in its values in milliseconds and it should be seconds, according to the spec that will change soon in Chrome 99. And let’s take a look at what happens if we run that fiddle.

So we start we are starting in 320×180, and you can see the bandwidth quality limitation is active right now. And we’re now at 960×540, so it ramped up a bit. And it should soon ramp up to 1280×720 pixels. And now we see a non-quality limitation reason is incrementing.

Tsahi: So that took 22 seconds.

Philipp: Well, it’s a known bug in WebRTC. It affects only peer to peer connections, and nobody’s interested in fixing it it seems. 

Tsahi: Okay.

Philipp: What we also have is a close button here. And what I did, there was to close the connections and then this is what you typically do if you want to measure a quality metric for the whole call. So we calculate the total. So the sum of all the things, the other, CPU bandwidth, non then we divide each of the values by the total. Then we get the percentage of times that the call was quality limited for some reason.

Tsahi: So in this case, because it was a short call, half of it was limited by bandwidth.

Philipp: Yes. And typically, you would expect this to be for good quality connections, they should rarely be bandwidth limited.

Tsahi: Why is that?

Philipp: Well, you won’t like to have the full resolution that you want to send being sent out all the time.

Tsahi: Not necessarily. I mean, that would depend, let’s say we’re in the group call. And in a group call, I would like to send whatever the other side is even willing to receive or can receive or should receive based on what he’s showing on his screen. Let’s say in this call that we have now, which is a call, which ourselves in your small boxes here. I don’t want full resolution or full bandwidth. I’m fine with less unless I change it to this.

Philipp: Yes, but then you might want to adapt the resolution that you send by using apply constraints on the track.

Tsahi: And that then would not fit as a bandwidth constraint, it would become none. 

Philipp: Yes. 

Tsahi: Okay, so I guess that’s what we’re looking for here is to look at the new stats from Chrome 99, more probably, and then try to figure out when we have CPU issues or bandwidth issues, do that either dynamically to understand what’s going on instead of trying to pick and choose for seven different places. And then do it at the end of the call as well, just to understand how the call went. And then we have these other thing. What falls under other?

Philipp: Well, it’s a catch all. It’s basically, we don’t know yet. 

Tsahi: Okay. 

Philipp: And I’m not even sure if that’s implemented.

Tsahi: Well, we’ll know in a few months. 

Philipp: Yes. 

Tsahi: Okay. So, Philipp, thank you for this. And for all of you have a Happy New Year, and we’ll see you in the next fiddle in February.