W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2017

API or spec to limit a certain sending track

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 28 Jul 2017 12:17:45 +0200
Message-ID: <CALiegfkq1dM8s49tycSOy_UaPrYAyOfMDEEe6vT9vAdY9tKGaw@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>

Assuming I'm talking to a SFU by sending mic audio + webcam video +
desktop sharing video over the same PeerConnection with BUNDLE, which
is the WebRTC proposed solution to dynamically limit the bitrate of
one of them?

Use case (assuming I have a really great uplink connection):

1) I am sending webcam video in VGA or HD.

2) At some time, I add desktop sharing video in Full HD.

3) So I want to lower my webcam video bitrate (resolution and/or
framerate) to the minimum, so others can focus on receiving the bits
of my desktop sharing.

4) Then I finish the desktop sharing so I want my webcam in VGA or HD again.

Possible approaches:

a) Transport-CC

This is just valid for the sender to limit its sending bitrate based
on transport feedback provided by the remote endpoint. However, no way
to artificially limit such a bitrate via API or RTCP from the remote,
and overall, this is related to the whole transport and all the tracks
carried on it.

Anyhow, transport-cc is always useful as it prevents the peer from
sending more than he can.


REMB feedback messages originated by the remote endpoint can,
theoretically, limit the sending bitrate of a set of SSRCs. So, the
server could limit the SSRC of my webcam video while, at the same
time, tell me that my BWE for my desktop sharing SSRC is very high.

Problems with REMB are the fact that it's not a standard (despite all
the browsers implement it), and worse: It seems that current
implementation apply the BWE constrain to the whole transport and not
per SSRC list (as the draft states).

c) SDP a=b:AS


d) MediaStreamTrack API

Dynamically call webcamTrack.applyConstraints(options) by setting low
height/width/frameRate values. AFAIK this does not even work in
current implementations.


Real standard valid for a server to limit the bitrate of a specific
SSRC. IMHO this could perfectly satisfy this use case.

However, Chrome does not want to properly implement it (they are about
dropping support for it) and others do not even implement it.

f) Simulcast / SVC

Sure this helps in this scenario, but I hope it's not 100% needed.

g) Split PeerConnections

Use separate PeerConnections for sending the webcam video and the
desktop sharing video, so transport based limitation (real world REMB
implementations) can be used.

If this is the best we have, this is so sad.

Do I miss any other approach? Which would be the WebRTC API/spec to
achieve this goal?

Thanks a lot.

Iñaki Baz Castillo
Received on Friday, 28 July 2017 10:18:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:35 UTC