Re: API or spec to limit a certain sending track


Another approach is to use the priority API.

It also depends on which side end wants to controls this. If the SFU is makeing the decisiong on what is important, then the best option is much differnt than if the JS in the browser is making the decision. Lots of SFU do use SDP to controls this thought I would not suggest that the client JS munging SDP was a good approach to this. 


> On Jul 28, 2017, at 4:17 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> Hi,
> 
> 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.
> 
> 
> 
> b) REMB
> 
> 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
> 
> NO
> 
> 
> 
> d) MediaStreamTrack API
> 
> Dynamically call webcamTrack.applyConstraints(options) by setting low
> height/width/frameRate values. AFAIK this does not even work in
> current implementations.
> 
> 
> 
> e) TMMBR
> 
> 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
> <ibc@aliax.net>
>

Received on Friday, 28 July 2017 14:38:41 UTC