How to set max bandwidth?

[andj222]

Hello,

Can one of the webrtc devs please describe how to set the maximum bandwidth for a call assuming the following?

• I'm using peerconnection_client in a sendonly capacity.
  
• Other peer is chromium and is recvonly.
• I would prefer to set the maximum bandwidth from the sending side (the peerconnection_client).

I've tried a number of things, but nothing seems to work -- the sending peer ultimately still always seems to limit itself to 2500 kbps. Particularly, I would like this max bandwidth setting to continue working properly with the new send side BWE code that is going (or already as gone) in.

Thanks.

[Dag-Inge Aas]

I don't know about the sending side, but you can achieve limiting
bandwidth through setting the b=AS flag in the SDP from the receiving
side. See an example of this here:
https://tools.ietf.org/html/rfc3556#page-5

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to discuss-webrt...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/discuss-webrtc/ae1ab55a-0b09-4818-a21e-058237b4e4b8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Dag-Inge Aas
Tech Lead @ appear.in

[andj222]

I did try that at one point several months back and it didn't actually seem to work - the call would still never go above 2500kbps or so despite setting it to 5000kbps.

Has anyone actually successfully used b=AS with video recently, like within the last month or two?

If b=AS actually works, I can always munge the remote SDP on the sending side.

[andj222]

I gave b=AS another shot, and it seems to work now! Thanks.

[andj222]

How can b=AS be adjusted dynamically in the middle of a call?

[Taylor Brandstetter]

That would be difficult without another offer/answer exchange. You may be able to get around this by setting an offer with a modified "b=AS", then setting an answer that's simply your current remote description.

Note that this will be possible in the future without an offer/answer exchange, by using RtpSender.setParameters and modifying the maxBitrate field: https://www.w3.org/TR/webrtc/#widl-RTCRtpEncodingParameters-maxBitrate

We've recently started to add support for some of these parameters in the native API. Though it's still in the early/experimental stages, and may not be available in Chrome for a while.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c414bbcb-f99a-4eda-84b7-5a6469661f85%40googlegroups.com.

[andj222]

Thanks Taylor,

Assuming that I don't care about a Javascript way to do this and am willing to simply modify the C++ webrtc library and/or peerconnection example on the sender side, what function(s) should I be calling to adjust the maximum bitrate (from conductor.cc or the like) on the fly?

Additionally:

From the sender side, what is the proper way to set the starting bitrate through the C++ API? I tried adding the following to my conductor.cc just prior to CreatePeerConnection:

constraints.AddOptional(webrtc::MediaConstraintsInterface::kScreencastMinBitrate, 3000);

(Note: My session is a screencast)

But this doesn't seem to have any effect -- my calls still ramp up from a low starting point of 300kbps. I ended up hardcoding kDefaultStartBitrateKbps to a different value in various places (video_coding_defines.h, bitrate_controller.h, and call.cc) throughout the native webrtc library in order to get the start bitrate to properly change.

I also looked at using googHighStartBitrate, but I'm not even sure how to pass that in from conductor.cc -- the MediaConstraints header doesn't have reference to anything resembling kGoogHighStartBitrate or similar.

[Taylor Brandstetter]

It looks like the min/max/start bitrate are settable via an "a=fmtp" line in the remote description. The parameters are "x-google-start-bitrate", "x-google-min-bitrate" and "x-google-max-bitrate" and are in units of kilobits.

For example, if payload type 100 represents the codec you wish to modify, you could insert:

"a=fmtp:100 x-google-start-bitrate=4000; x-google-max-bitrate=5000; x-google-min-bitrate=3000"

Or if you don't want to munge SDP, you could insert these parameters directly in the cricket::VideoCodec in the SessionDescription object.

To adjust the maximum bitrate on the fly using setParameters, the intended method is:

1. Wait until an offer/answer exchange finishes.

2. Call RtpSender::GetParameters to get the current set of parameters.

3. Modify maxBitrate in the encoding(s) of the returned parameters.

4. Call RtpSender::SetParameters with the modified parameters.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3b2fba0c-e37c-4c4d-a277-9902026e6818%40googlegroups.com.

[Brian Baldino]

What does "x-google-min-bitrate" control? Does this mean that, if video can't be sent at at least that bitrate (due to bandwidth constraints), chrome will stop the video streams? And presumably resume it if bandwidth improves?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0aPvM0PkB%3DOSwGMnvTKYSPwXO6g02HgfmR_LTOM9CnJnA%40mail.gmail.com.

[Alvaro Gil]

Brian, those parameter will not cause the stream stop if are not satisfied.

I think the best way you have to test is to open webrtc-internals from Chrome and see the charts about how it chance the bandwidth sent/received.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAAEyqM595u4uQnYc9QUYZCWb9MvwcOLj72918Tpg0y9pBLJZtg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alvaro

[Taylor Brandstetter]

Alvaro is correct; the stream won't stop, it will just continue attempting to send at the minimum bitrate. Also, this value can't go below 10kbps, it seems.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGM%2B_3a2LUua2az2KJ%2BQOuB8KD-k939Au_Fxxo4OLoZrboNAWQ%40mail.gmail.com.

[Brian Baldino]

That's good to know.  What's the use case around that sort of behavior?  Seems like it'd be nice to be able to set the 'stop trying to send this stream' bitrate to have clients go audio only when bandwidth is limited.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0YgXCy-rnNHWHKTCZLzxuYKH-ErgYBaTg8DVJHJ29m10Q%40mail.gmail.com.

[Andrew J]

Thanks for the information, Taylor.

Brain: I'm not 100% sure, but I think that's what the suspend-below-min-bitrate option is for:

https://webrtc-codereview.appspot.com/17989004

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/u7k1_hASS4Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAAEyqM5%2Bmzz_8vRRqt0XmKX7fA%2BhvOm9X5y0MohGADXbwdNdLQ%40mail.gmail.com.

[Brian Baldino]

Oh, very cool...didn't know about that, will look into it.  Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAH6n4TcG7RMVnZ7hu1zeaox3Cz6J8Jk4YboZeMijkvHPhOR-jw%40mail.gmail.com.

[Andrew J]

Taylor,

I just tried munging the SDP (both offer and answer, from both peers), and I still start out at a very low bitrate even with x-google-start-bitrate, x-google-min-bitrate, and x-google-max-bitrate set to high values (10000).

This mirrors my experience last time I tried changing these parameters, and I just ended up hardcoding everything inside of the webrtc library. I'd really like to stop having to do that.

Are there tests somewhere that make sure these parameters actually work, or do you have any other suggestions?

On Mon, Apr 18, 2016 at 10:50 AM, 'Taylor Brandstetter' via discuss-webrtc <discuss...@googlegroups.com> wrote:

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/u7k1_hASS4Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0aPvM0PkB%3DOSwGMnvTKYSPwXO6g02HgfmR_LTOM9CnJnA%40mail.gmail.com.

[andj222]

Reading over this bug, I'm seeing some information that conflicts with what I've seen on this thread --

"It should be using the currently estimated bitrates instead of bumping the initial send rates." -- pbos

Does this mean the x-google-start-bitrate is not intended to actually set the initial send bitrate?

On Tuesday, April 19, 2016 at 8:06:22 PM UTC-7, andj222 wrote:

Taylor,

I just tried munging the SDP (both offer and answer, from both peers), and I still start out at a very low bitrate even with x-google-start-bitrate, x-google-min-bitrate, and x-google-max-bitrate set to high values (10000).

This mirrors my experience last time I tried changing these parameters, and I just ended up hardcoding everything inside of the webrtc library. I'd really like to stop having to do that.

Are there tests somewhere that make sure these parameters actually work, or do you have any other suggestions?

On Mon, Apr 18, 2016 at 10:50 AM, 'Taylor Brandstetter' via discuss-webrtc <discuss-webrtc@googlegroups.com> wrote:

It looks like the min/max/start bitrate are settable via an "a=fmtp" line in the remote description. The parameters are "x-google-start-bitrate", "x-google-min-bitrate" and "x-google-max-bitrate" and are in units of kilobits.

For example, if payload type 100 represents the codec you wish to modify, you could insert:

"a=fmtp:100 x-google-start-bitrate=4000; x-google-max-bitrate=5000; x-google-min-bitrate=3000"

Or if you don't want to munge SDP, you could insert these parameters directly in the cricket::VideoCodec in the SessionDescription object.

To adjust the maximum bitrate on the fly using setParameters, the intended method is:

1. Wait until an offer/answer exchange finishes.

2. Call RtpSender::GetParameters to get the current set of parameters.

3. Modify maxBitrate in the encoding(s) of the returned parameters.

4. Call RtpSender::SetParameters with the modified parameters.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3b2fba0c-e37c-4c4d-a277-9902026e6818%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/u7k1_hASS4Q/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

[Peter Boström]

That means that if start bitrates aren't set then it should be using the current bitrate estimates. I can't say I've touched the start-bitrate code for a long while though.

On Wed, Apr 20, 2016 at 8:02 AM andj222 <andj...@gmail.com> wrote:

Reading over this bug, I'm seeing some information that conflicts with what I've seen on this thread --

"It should be using the currently estimated bitrates instead of bumping the initial send rates." -- pbos

Does this mean the x-google-start-bitrate is not intended to actually set the initial send bitrate?

On Tuesday, April 19, 2016 at 8:06:22 PM UTC-7, andj222 wrote:

Taylor,

I just tried munging the SDP (both offer and answer, from both peers), and I still start out at a very low bitrate even with x-google-start-bitrate, x-google-min-bitrate, and x-google-max-bitrate set to high values (10000).

This mirrors my experience last time I tried changing these parameters, and I just ended up hardcoding everything inside of the webrtc library. I'd really like to stop having to do that.

Are there tests somewhere that make sure these parameters actually work, or do you have any other suggestions?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3b2fba0c-e37c-4c4d-a277-9902026e6818%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/u7k1_hASS4Q/unsubscribe.

To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0aPvM0PkB%3DOSwGMnvTKYSPwXO6g02HgfmR_LTOM9CnJnA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7ee1c61c-30aa-40fe-a9ed-6796440d8070%40googlegroups.com.

[andj222]

Thanks for the clarification Peter.

So to add a bit more detail here on what I'm seeing:

Even after including x-google-min-bitrate, x-google-max-bitrate, and x-google-max-bitrate with higher values in the SDP, CongestionController::SetBweBitrates() is only ever called with the default start value of 300000, and BitrateControllerImpl::SetStartBitrate is also only ever called with the default of 300000.

Should I expect to see the bandwidth estimator's SetStartBitrate method getting passed the higher value I specified in x-google-start-bitrate, or is this an invalid expectation?

[Peter Boström]

I don't think that's expected, assuming you didn't set max twice but rather start one of them. I don't think it's much in use though, so it might/could have broken without it being detected, feel free to file a bug if you think that's the case.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/98bf35d0-7bf5-4828-b45e-4a891aa601c4%40googlegroups.com.

[andj222]

The double -max was just a typo in my message. I've created a bug report with repro steps: https://bugs.chromium.org/p/webrtc/issues/detail?id=5811

[Taylor Brandstetter]

I just commented on the bug. I think this is just an issue with the repro steps which use AppRTC, as all of the bitrate parameters are working for me.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3bd831ba-8f25-4cc8-9d4d-6561a03ca057%40googlegroups.com.

[Andrew J]

Hi Taylor,

AppRTC does have the issue you described, but I still think there's a deeper bug in webrtc. I added more detailed comments to the issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0ZZ4KZ7NJY%3DdkMfCxkgCtNtV6Q_f5BrE%2B904m1T-7-UUQ%40mail.gmail.com.

[Philipp Hancke]

since there was no sample for this I just added one: https://webrtc.github.io/samples/src/content/peerconnection/bandwidth/

;-)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAH6n4TfBQNGJv%2B_tLPqk3MdJa-3-96__Z9oq5dMet%2BqBKxCESg%40mail.gmail.com.

[Andrew J]

Hi Taylor,

1. Wait until an offer/answer exchange finishes.
2. Call RtpSender::GetParameters to get the current set of parameters.
3. Modify maxBitrate in the encoding(s) of the returned parameters.
4. Call RtpSender::SetParameters with the modified parameters.

I'm looking at doing this now, but I'm not clear on #2 here. From the peerconnection_client conductor.cc, after the Offer/Answer completes,  I can call GetSenders on the PeerConnectionInterface to retrieve the senders, but I get back a vector of RtpSenderInterfaces. This RtpSenderInterface appears to be a proxy class, and has a very limited set of methods from RtpSender -- and GetParameters is not one of them. From an API user's perspective, how do I get at the GetParameters method using this limited interface?

Thanks.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiLmZ5LcUCypHPWSmoXh3F1UCd%3DUUzoXasr_znLJArWwYA%40mail.gmail.com.

[Taylor Brandstetter]

The method is there in the current version of RtpSenderInterface. As I mentioned, this was a very recent addition.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAH6n4TfJWqsdP5VowMoKRtGOGZ8PxEqhs2To6Ag4VMEnUbNM9Q%40mail.gmail.com.