We’re using mediasoup for a room based video chat application with mediasoup code roughly based on the demo app. We’re using H264 and simulcast to try and keep cpu & bandwidth requirements low, and all clients are typically running chrome 83+ on a variety of desktop OS. The clients usually encode 2 simulcast streams at 360p and 180p, ~600kb/s and ~100kb/s respectively.
We see a few problems with the WebRTC BandWidth Estimation, and have been using the bwe trace events to try and monitor what’s going on. We’re mostly testing on >=100Mb links with a server hosted at a local data centre so not really expecting to have bandwidth issues.
The most annoying problem is that intermittently a client will seem to get locked in a low available bandwidth situation with the mediasoup server flipping between sending a null spatial layer and layer zero. Simply rejoining the room and hence recreating all transports typically fixes the issue.
We’ve recently un-commented the following line in RTC/TransportCongestionController.cpp:50, anecdotally this seems to have improved this particular situation.
// TODO: Let's see. this->rtpTransportControllerSend->EnablePeriodicAlrProbing(true);
Is there a good reason not to enable this?
More generally, we often see from the bwe trace events that available < desired bitrate even on supposedly reliable, high bandwidth, low latency, links and as a result low bandwidth streams are getting forwarded when there should be plenty of bandwidth available for the high quality one. Before investigating further, I’m wondering if there’s any value trying to update the
libwebrtc code that seems to be used for some of this Bandwidth Estimation. As far as I can see it’s taken from something around m78 and the libwebrtc code gets re-organised a bit after that point so I’m not sure how straightforward updating it would be.
Also wondering if anybody else sees similar issues, or whether I’m barking up the wrong tree looking at the BWE code at all.
Thanks in advance