Codec statistics changes

🎻 October 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

Transcription

Tsahi: Hi, and welcome to our WebRTC Fiddle of the Month. This time we are going to talk about codec statistics changes, and especially what has happened in Chrome 107, and the changes that Google has done there. Philipp.

Philipp: Right. What Google changed was to reduce the number of codec objects, and these codec objects in the statistics describe what codecs are used by the  peer connection that are negotiated in the SDP. And they did 2 changes:

  1. The first was to fix a bug where chrome generated separate objects for each media section in the SDP. So, if you had a multi-party call with 50 participants, you had 50 times the objects of all the codecs used by the end lines and these objects were different. So this wasn’t adding any value, it just created a lot of objects,  it took a lot of memory allocations and low down performance. So that was fixed
  2. And then they made another change to just generate objects for for data that is actually used for codecs that are actually in use, because in SDP, you negotiate a lot of codec like VP8, VP9 if you want, but you technically only use one of them at a time.

Tsahi:  And I guess we’re seeing a lot of changes that Google is now making in the statistics. And it feels like they’re trying to squeeze the lemon, wherever it comes to the performance because they’ve done most of the work that they could do elsewhere like in the codec Implement changes themselves, the rendering, all of that pipeline. So they’re getting to the nuances of optimizations.

Philipp: Yes yes. And I mean this is mainly about getStats() which is quite frequently used. So, we typically call it at least once a second and the problem here was that it created a lot of memory allocations and memory allocations are slow, and this was optimizing things.

Tsahi:  So, what do you have for us in the fiddle this time?

Philipp: So of course the fiddle that we have is a comparison between Chrome Canary on the left and Edge stable on the right. So on the right is M106 on the left M108. And what we do is we simply create a peer connection add audio and video, and then call getStats() once, after 5 seconds. Then we look at two things; the first is the number of object in the statistics and the second is the size of a JSON blob, if you serialize the statistics.

Tsahi:  Okay.

Philipp: And what you see is currently we have 103 objects in the stats object, and these take up around thirty thousand bytes. And if you look at the M108 that is greatly reduced, we are down to 31 objects and ~13,000 bytes. And that is quite a bit. That means every time you’re iterating over the statistics, you have less objects to iterate over. And the browser also has less objects to create, and then throw away after you’re done with them. All of this is quite a nice performance improvement.

Tsahi:  And then is just for the default audio and video devices that you have?

Philipp: Yes, yes. I know we can try adding a couple more transceivers just for the sake of doing something interactive, so pc-1 and transceiver… And let’s see if that changes in number of Statistics we get. So we had 103, and we’re waiting for it… Now we have 197. And if we do the same in Canary, we shouldn’t see an increase any more because that has the M107 changed to… squeeze everything into links that are into one m-line, so we still should get these 31 ish objects.

Tsahi:  This is fine, it is 33 this time.

Philipp: Yes. Because we have more objects for the transceivers.

Tsahi:  Yes. But it’s not like double the number.

Philipp: Yes. And if you go to things like 50 transceivers, then obviously you’re getting a lot of big objects. That is pretty heavy, and no more as of chrome 108.

Tsahi:  Okay, thanks for this Philipp and see you next month in our next fiddle of the month.

[]