New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users

Issue metadata

Status: Assigned
Last visit 15 days ago
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Issue 7225: [WebRTC] Simulcast: forever sending RTP padding packets if REMB received is fixed to 1mbps

Reported by, Feb 24 2017

Issue description

What steps will reproduce the problem?
1. Enable simulcast with 3 qualities.
2. Fix REMB reports sent by the receiver to 1mbps.

What is the expected result?
Chrome should be more smart and detect this situation to avoid wasting BW forever sending RTP padding packets (in order to raise the REMB).

What do you see instead?
Chrome forever sends RTP padding packets.

What version of the product are you using? On what operating system?
57.0.2987.74 beta (64-bit) - Linux

Comment 1 by, Feb 24 2017

Comment 2 by, Mar 3 2017

Project Member
Components: Network

Comment 3 by, Mar 7 2017

Project Member
Components: -Network Video

Comment 4 by, Sep 27 2017

Project Member

Comment 5 by, Sep 27 2017

Project Member
Ping for triaging. Is this still valid?

Comment 6 by, Oct 5 2017

this still happens.
Another way to reproduce it is fixing the bitrate used for encoding just munging the SDP to add the next attrs:
a=fmtp:96 x-google-start-bitrate=1000
a=fmtp:96 x-google-min-bitrate=1000
a=fmtp:96 x-google-max-bitrate=1000

Comment 7 by, Oct 16 2017

Project Member
Status: Assigned (was: Unconfirmed)
Erik, can you take a look and see if there is something that we should improve here?

Comment 8 by, Oct 16 2017

Project Member
I'm not sure this counts as bug, if I understand the issue correctly.

If we have configured three streams (HD, VGA, QVGA) and the bandwidth estimate is high enough to exceed the max configured bitrate for VGA + QVGA, but is not yet high enough to reach the target bitrate for VGA + QVGA plus the minimum bitrate for HD, then we send padding in order to be able to ramp up the bandwidth estimate. Otherwise we risk being stuck at VGA, and never enable the HD stream.
By default this padding will happen in the range 850-1250kbps for a 720p stream and three layers.

What is your use case when you fixate the REMB at 1Mbps? Then I would rather just not configure an HD stream as we would never be able to enable it.
I think there's a plan to get rid of the padding at some point, if we have send-side bwe enable, since then we can use probing instead.

However, if we set the max bitrate via constraints, I agree it would be a good idea to not send padding as we can know on the send-side that it won't help.

stefan@, can you triage/prioritize that part?

Comment 9 by, Oct 17 2017

Hello @sprang,
there are several case where the BW limit could be "fixate", for example:
  - the BW estimation is stuck at 1Mbps
  - explicit BW constraints from app (eg: set by user)

In the case of using send-side bwe, how the probing works unlike using RTP padding?

Comment 10 by, Oct 17 2017

Project Member
If the BW estimation is "stuck" I would say it's the right call to keep pushing and trying to keep the estimate high.

Setting artificial limits on the receive side, sending synthetic remb messages that can't be distinguished from actual network condition sounds like a bad decision. It should in that case be explicitly signaled out of band instead.

But I said before, if the constraint is explicitly set on the send side we should probably not pad up to this limit.

Probing works by sending short bursts of RTP packets, at a rate we wish to see if the connection can handle, rather than continuously sending packets.

Comment 11 by, Oct 17 2017

Hello again!!

Regarding artificial limits on receiver side, I agree with you about that REMB should not be used, even more, it will be deprecated in favor of send-side bwe. So, following the standards and in order to have a responsiveness system TMMBR should be used instead being signaled out of band. The discussion is opened in

In relation to constraints set on send side, yes I totally agree with you.

If the BW estimation is "stuck", what do you think about following the same approach that "send-side bwe probing"?

Comment 12 by, Jul 20 2018

this is becoming more of an issue now that the upper layers can be disabled in the browser. See Brian's comments in!msg/discuss-webrtc/ORJdeoFAaBE/6gyk3-6TAgAJ
I *think* this issue is the root cause.

Fortunately, there is now a browser-only way to test this. Steps to reproduce:
1) go to
2) run wireshark
3) wait a minute, then paste this into the console:
var p = pc1.getSenders()[0].getParameters();
p.encodings[1].active = false;
p.encodings[2].active = false;

This disables the two high resolution layers. In wireshark its quite visible that the extra bandwidth is comsumed by rtx/padding
In the attached graph the orange line starts at the time i executed the JS snippet above.

Trying to keep the bitrate estimate that high with two layers disabled makes not much sense.
86.6 KB View Download

Sign in to add a comment