PSA: Support for RTCRtpSender.getParameters() and setParameters()

1,702 views
Skip to first unread message

Seth Hampson

unread,
Jun 28, 2018, 8:52:54 PM6/28/18
to discuss-webrtc

Application developers can now view and alter parameters for how tracks are encoded and transmitted by using GetParameters/SetParameters with the RtpSender.


Of the RtpParameters, the current implementation returns the read-only RtcpParameters and RTPCodecParameters after negotiation and allows changing the active, max_bitrate_bps and bitrate_priority RtpEncodingParameters. The encoding parameters can be used for simulcast layers and are explained in more detail below.

  • active - Indicates if a stream is actively being encoded/sent. This can be set for a simulcast layer encoding or the RtpSender as a whole by setting the value at encodings[0].

  • max_bitrate_bps - Sets a stream’s max bitrate. This can be set for a simulcast layer encoding or the RtpSender as a whole by setting the value at encodings[0].

  • bitrate_priority - Sets the relative bitrate priority for the RtpSender. This is implemented for the RtpSender as a whole by setting the value at encodings[0].


This is supported in Chrome M68 with RTCRtpSender.get/setParameters, with the RTCRtpEncodingParameters. The maxBitrate and priority encoding parameters are not supported for simulcast layers, but the maxBitrate will be supported for simulcast layers in M69.


Sergio Garcia Murillo

unread,
Jun 29, 2018, 4:53:21 AM6/29/18
to discuss...@googlegroups.com
Hi Seth,

I am testing and Canary and it seems that RTPSender.setParameters does not allow to setup simulcast encodings, is this expected or i am doing anything wrong?

Best regards
Sergio
--

---
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/251d9332-0b84-4f6b-85b3-665c23d68473%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Seth Hampson

unread,
Jun 29, 2018, 12:20:03 PM6/29/18
to discuss...@googlegroups.com
Hi Sergio,

This is expected. setParameters can be used to modify simulcast encoding parameters, but cannot be used to create simulcast encoding layers.  As stated in step 7.1 of setParameters, you cannot change the length of parameters.encodings with setParameters. If you would like to setup simulcast it still must be done so by munging the SDP.


I would like to also clarify how max_bitrate_bps/active can be set for an individual simulcast layer or for the RtpSender as a whole in the case of only one encoding in use.
Case 1: Using simulcast
In this case the RtpSender has multiple encodings, and the parameters can be set by modifying parameters.encodings[i]. Setting the parameters.encodings[0], will only affect that particular encoding layer.
Case 2: Not using simulcast
In this case there is only one encoding. Therefore, setting values for parameters.encodings[0] affects the RtpSender as a whole.

Best,
Seth

Brian Baldino

unread,
Jul 13, 2018, 2:51:21 PM7/13/18
to discuss-webrtc
Is the ability to set max bitrate for simulcast layers in m69 yet?  I'm trying it out but it doesn't seem to have an effect.  Is there a bug I can track for the implementation of it?

Seth Hampson

unread,
Jul 13, 2018, 3:08:23 PM7/13/18
to discuss...@googlegroups.com
Hi Brian,

It should be available in M69. The value can be overridden by setting the max bitrate in the SDP ("b=AS" attribute, or codec specific max bitrate set with "x-google-max-bitrate"). 

I have a fix for this logic out now: https://webrtc-review.googlesource.com/c/src/+/88520

Best,
Seth

Brian Baldino

unread,
Jul 13, 2018, 4:11:49 PM7/13/18
to discuss...@googlegroups.com
Thanks Seth, so something like:

var videoSender = pc.getSenders()[1]
var params = videoSender.getParameters()
params.encodings[0].maxBitrate = 0
videoSender.setParameters(params);

Should take effect immediately? Or does something else need to be done?  I don't see the send bitrate change when trying that.  This is on Canary 69.0.3489.0.

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

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAF3dAjjDjQcwErY%2Bo-VH4ZrKNDgg0sWjkazFP7PUtG5S14gD2g%40mail.gmail.com.

Seth Hampson

unread,
Jul 13, 2018, 5:28:14 PM7/13/18
to discuss...@googlegroups.com
Hi Brian, yes that looks correct. Have you tried setting a different value other than 0? If you would like to turn off the stream I suggest setting "params.encodings[0].active = false;" instead. It looks like in the code 0 is treated as an "unset" value and is not used:

-Seth

--

---
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.

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.

Seth Hampson

unread,
Jul 13, 2018, 5:29:41 PM7/13/18
to discuss...@googlegroups.com

Philipp Hancke

unread,
Jul 13, 2018, 5:37:15 PM7/13/18
to WebRTC-discuss
setting the bitrate to 1 instead of 0 works for me. Makes me wonder what the encoder makes of that target bitrate though :-)

2018-07-13 14:29 GMT-07:00 'Seth Hampson' via discuss-webrtc <discuss-webrtc@googlegroups.com>:
On Fri, Jul 13, 2018 at 2:27 PM Seth Hampson <sham...@google.com> wrote:
Hi Brian, yes that looks correct. Have you tried setting a different value other than 0? If you would like to turn off the stream I suggest setting "params.encodings[0].active = false;" instead. It looks like in the code 0 is treated as an "unset" value and is not used:

-Seth

On Fri, Jul 13, 2018 at 1:11 PM Brian Baldino <br...@jitsi.org> wrote:
Thanks Seth, so something like:

var videoSender = pc.getSenders()[1]
var params = videoSender.getParameters()
params.encodings[0].maxBitrate = 0
videoSender.setParameters(params);

Should take effect immediately? Or does something else need to be done?  I don't see the send bitrate change when trying that.  This is on Canary 69.0.3489.0.

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

--

---
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-webrtc+unsubscribe@googlegroups.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-webrtc+unsubscribe@googlegroups.com.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAF3dAjgof-borkX9AEN%2BFw5d%2B__Fdo_oHFDrf5zztVdgPrR0Ew%40mail.gmail.com.

Seth Hampson

unread,
Jul 13, 2018, 5:50:25 PM7/13/18
to discuss...@googlegroups.com
Yeah, this was brought up in this bug (https://bugs.chromium.org/p/webrtc/issues/detail?id=9141) and the decision was made for the application to get what they want. Even if that's an undesirably low bitrate.

On Fri, Jul 13, 2018 at 2:37 PM 'Philipp Hancke' via discuss-webrtc <discuss...@googlegroups.com> wrote:
setting the bitrate to 1 instead of 0 works for me. Makes me wonder what the encoder makes of that target bitrate though :-)

--

---
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.

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.

--

---
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.

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.

Brian Baldino

unread,
Jul 13, 2018, 6:25:23 PM7/13/18
to discuss...@googlegroups.com
Ah ha! Yeah that must be it.  I did play with active = false a bit too and that works really well.  Thanks.

On Fri, Jul 13, 2018 at 2:50 PM, 'Seth Hampson' via discuss-webrtc <discuss...@googlegroups.com> wrote:
Yeah, this was brought up in this bug (https://bugs.chromium.org/p/webrtc/issues/detail?id=9141) and the decision was made for the application to get what they want. Even if that's an undesirably low bitrate.
On Fri, Jul 13, 2018 at 2:37 PM 'Philipp Hancke' via discuss-webrtc <discuss-webrtc@googlegroups.com> wrote:
setting the bitrate to 1 instead of 0 works for me. Makes me wonder what the encoder makes of that target bitrate though :-)

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

--

---
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-webrtc+unsubscribe@googlegroups.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-webrtc+unsubscribe@googlegroups.com.

--

---
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-webrtc+unsubscribe@googlegroups.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-webrtc+unsubscribe@googlegroups.com.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAF3dAji31HUU3p3kLhudif2et2ZNDsu_ec247BSbCC4c30Snsg%40mail.gmail.com.

Brian Baldino

unread,
Jul 19, 2018, 8:28:36 PM7/19/18
to discuss...@googlegroups.com
I was playing with this some more and saw that with 3 simulcast layers (720, 360, 180) and then disabling (what I assume?) are the top two layers via: 

parameters.encodings[1].active = false
parameters.encodings[2].active = false

the bitrate only drops to ~1.2meg, even though it's only sending 180p.  From what I can tell the target bitrate for 180p is only 200kbps.  Is the rest probing maybe?




On Fri, Jul 13, 2018 at 3:25 PM, Brian Baldino <br...@jitsi.org> wrote:
Ah ha! Yeah that must be it.  I did play with active = false a bit too and that works really well.  Thanks.
bitrate drop with rtpsender.png

Philipp Hancke

unread,
Jul 20, 2018, 1:16:17 AM7/20/18
to WebRTC-discuss
on the wire I don't see much more bitrate so that seems like a stats bugs. The bitrate for the lowest resolution goes a bit over 150kbps (~200kbps) though which might be padding.

Harald Alvestrand

unread,
Jul 20, 2018, 8:08:36 AM7/20/18
to WebRTC-discuss
You might want to check out various combinations of "disable 2 streams". I remember at one point there being confusion about which encoding is listed first - the smallest or the biggest. And I can't remember offhand how it was resolved.


Brian Baldino

unread,
Jul 20, 2018, 12:45:31 PM7/20/18
to discuss...@googlegroups.com
I did confirm that the layers appear to go from smallest to biggest (0 = 180p, 1 = 360p, 2 = 720p) but it does seem like some other data is getting put in there, check this bweforvideo graph with only the lowest layer enabled:



It has a low encode rate, but a much higher overall transmit rate.  Now, if this is some kinda of probing which is used to allow for ramping up extremely quickly when the layers are re-enabled I'd say that is worth it, as without that I think disabling simulcast streams becomes a lot less useful.  Just wondering if that is the case.

On Fri, Jul 20, 2018 at 5:08 AM, 'Harald Alvestrand' via discuss-webrtc <discuss...@googlegroups.com> wrote:
You might want to check out various combinations of "disable 2 streams". I remember at one point there being confusion about which encoding is listed first - the smallest or the biggest. And I can't remember offhand how it was resolved.

Chen Yang

unread,
Nov 28, 2018, 10:29:41 PM11/28/18
to discuss-webrtc
Hi, i try to set max_bit_rate in M70 but not effect.

for (const auto &sender : peer_connection->GetSenders()) {
if (std::string("video_track") == sender->id()) {
webrtc::RtpParameters rtpParameters = sender->GetParameters();
for(auto encoding : rtpParameters.encodings) {
encoding.max_bitrate_bps = bitrate;
PEER_CONNECTION_LOG("Find a encoding" + std::to_string(encoding.max_bitrate_bps.value()), INFO);
}
if (sender->SetParameters(rtpParameters).ok()) {
PEER_CONNECTION_LOG("Peer connection sender {" + sender->id() + "}change bitrate:" + std::to_string(bitrate), INFO);
}
}
}

Log:
2018-11-29 11:24:52,070 INFO  [clientInboundChannel-10] c.l.g.r.c.PeerConnection:45-Native log from PeerConnection, Find a encoding2097152
2018-11-29 11:24:52,070 INFO  [clientInboundChannel-10] c.l.g.r.c.PeerConnection:45-Native log from PeerConnection, Peer connection sender {video_track}change bitrate:2097152

在 2018年6月29日星期五 UTC+8上午8:52:54,Seth Hampson写道:

Alex Artushin

unread,
Jul 31, 2019, 2:27:13 AM7/31/19
to discuss-webrtc
Is maxBitrate for layers below the highest still settable?

With the following sdp state:

a=rtpmap:96 VP8/90000
a=rtpmap:97 rtx/90000
a=fmtp:96 x-google-max-bitrate=5000000
...
a=rid:l recv
a=rid:m recv
a=rid:h recv

and the following sendEncodings:

sendEncodings: [
{ rid: "l", active: true, maxBitrate: 450000 },
{ rid: "m", active: true, maxBitrate: 1200000 },
{ rid: "h", active: true, maxBitrate: 2500000 },
]

rid 'l' isn't going above around 150kbps and rid 'm' isn't going above around 450kbps?

Using 

params.encodings[1].maxBitrate = 1100000
videoSender.setParameters(params);

to reset rid 'm' midstream doesn't appear to change anything either. I've tried with H264 as well. 

Altering the highest bitrate rid works fine. For example, params.encodings[2].maxBitrate = 1300000; drops the highest encoding's bitrate to 1.3mbps.

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

--

---
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...@googlegroups.com.

Harald Alvestrand

unread,
Jul 31, 2019, 2:39:45 AM7/31/19
to discuss...@googlegroups.com
This sounds like a bug. Can you file one at crbug.com (component webrtc)?
If you have a repro script, that would be wonderful (I don't know if this is easy to reproduce without an SFU).


Florent Castelli

unread,
Jul 31, 2019, 6:54:12 AM7/31/19
to discuss...@googlegroups.com
Hi Alex, 

It could be linked to the frame size of each stream.

What is the source size?
Also, can you specify the scaleResolutionDownBy factor in your parameters for each layer instead of relying on some old non-spec conformant behavior we haven't (yet) changed?

Alex Artushin

unread,
Jul 31, 2019, 10:48:35 AM7/31/19
to discuss-webrtc
I've tried scaleResolutionDownBy with values of 1.1 and 2.0. Resolution is scaled correctly, however, the bitrate remains unaffected. Are you saying that maxBitrate is non-spec?

--

---
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...@googlegroups.com.

Alex Artushin

unread,
Jul 31, 2019, 10:49:05 AM7/31/19
to discuss-webrtc
Thanks, I'll try to figure out a reduced case scenario.

Harald Alvestrand

unread,
Jul 31, 2019, 11:51:15 AM7/31/19
to discuss...@googlegroups.com
The conformant behavior of maxBitrate is here:


So it's worth filing a bug if behavior is not what you think it should be.
Note the paragraph that says "The user agent is free to allocate bandwidth between the encodings, as long as the maxBitrate value is not exceeded. The encoding may also be further constrained by other limits (such as maxFramerate or per-transport or per-session bandwidth limits) below the maximum specified here." - you may see some overall limit that prevents increasing the bitrates allocated to layers 1-2.

Reply all
Reply to author
Forward
0 new messages