New issue
Advanced search Search tips

Issue 7225 link

Starred by 6 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

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

Reported by mparisd...@gmail.com, 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



 
This issue may be related to https://bugs.chromium.org/p/webrtc/issues/detail?id=5727
Project Member

Comment 2 by oprypin@chromium.org, Mar 3 2017

Components: Network
Project Member

Comment 3 by deadbeef@chromium.org, Mar 7 2017

Components: -Network Video
Project Member

Comment 4 by anatolid@chromium.org, Sep 27 2017

Cc: sprang@webrtc.org
Project Member

Comment 5 by anatolid@chromium.org, Sep 27 2017

Ping for triaging. Is this still valid?
Hello,
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
Project Member

Comment 7 by brandtr@webrtc.org, Oct 16 2017

Cc: -sprang@webrtc.org
Owner: sprang@webrtc.org
Status: Assigned (was: Unconfirmed)
Erik, can you take a look and see if there is something that we should improve here?
Project Member

Comment 8 by sprang@webrtc.org, Oct 16 2017

Cc: sprang@webrtc.org
Owner: stefan@webrtc.org
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?
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?
Project Member

Comment 10 by sprang@webrtc.org, Oct 17 2017

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.
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 https://bugs.chromium.org/p/webrtc/issues/detail?id=7103

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"?
this is becoming more of an issue now that the upper layers can be disabled in the browser. See Brian's comments in https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!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 https://fippo.github.io/simulcast-playground/chrome
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;
pc1.getSenders()[0].setParameters(p)

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.
inactive.png
86.6 KB View Download

Sign in to add a comment