🎻 January 2022 fiddle
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.
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.
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.
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.
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.
Philipp: And I’m not even sure if that’s implemented.
Tsahi: Well, we’ll know in a few months.
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.