(v2 vs. v3 question) initial Bitrate behavior

First off: I know mediasoup v2 is not supported anymore, so I understand if this question is just ignored. I wanted to try my luck though :).

Background: I still have an Android implementation for mediasoup that had the issue that the bitrate never went beyond 2.5Mbit/s. I’m doing calls with the H264 codec if that is relevant. Upon further analysis I noticed that this is the case because the b=AS default setting of the SDP is essentially linked to a percentage of the available bandwidth. So to increase that, I added a b=AS line to all SDPs to increase the total bandwidth in my Android SDPs.

The problem is: The moment I am doing this, the initial bitrate seems to drop. So instead of starting with 2.5Mbit/s and staying there, it starts with 0.1Mbit/s and slowly crawls up until it reaches the maximum after about a minute.

For direct calls, this was solved with the x-google-start-bitrate flag, but this unfortunately doesn’t seem to be the case with mediasoup despite providing this flag in the codec’s parameters.

Upon further tests it seemed like doing the same actually works perfectly fine with mediasoup v3 as it specifically allows setting an initial outgoing bitrate (I suppose that is the relevant part). I also noticed that the Transport.cpp seems to have stuff regarding that that was not implemented yet in v2.

So tl;dr and the final question: Was there already a way to get an initial bitrate in with mediasoup v2, or is this a new feature of v3 and I’d have no easy way if I want to update an old v2 project with this functionality? Even if the answer is “you have to update” I’d at least know for sure :).

Thanks!

The x-google-start-bitrate codec parameter must exist in the SDP answer and not in the SDP offer. That’s what mediasoup-client v3 does.

AFAIR in mediasoup v2 you can also achieve that by adding that x-google-start-bitrate parameter into the video codec of mediaCodecs:

The answer to this is always yes.

1 Like

Yup, that’s what I tried. It definitely is part of the Android’s SDP as well and I saw it on the browser end receiving it. But no dice unfortunately. It’s nice to know this would be what to look out for though, so I can verify one final time and abort further attempts otherwise.

I know :). It was just a special case updating some dedicated old software, so I hoped to get around a more thorough update. Thanks a bunch for responding anyway. I’ll mark this as solved.

Just for the rare chance that someone stumbles upon this:

Setting the x-google-start-bitrate parameter was enough concerning mediasoup - in fact I’m not even sure if adding this made any difference. The core problem was more in the Android implementation of WebRTC - setting higher bitrate values in the encoder initialization (rather than taking what the native part tells it) and for the PeerConnection itself seems to have resolved it. I suppose the issue was that the initial connection to the mediasoup server was so bad in comparison to direct calls that the encoding algorithm started with much lower bitrates as it falsely assumed it cannot go higher. Not quite sure why it seemed fine in v3 in comparison, but having good results with both now.

Because mediasoup v3 implements transport-cc which makes the client estimate available uplink bandwidth much faster than using REMB (as in mediasoup v2).

1 Like

Thanks a lot for all the clarifications and background explanations, I’m learning tons in this discourse.

1 Like