Re: API or spec to limit a certain sending track

Another option (though not currently available) is limiting the
per-encoding bitrate on the sender side with
RTCRtpEncodingParameters.maxBitrate
<https://www.w3.org/TR/webrtc/#dom-rtcrtpencodingparameters-maxbitrate>.

On Fri, Jul 28, 2017 at 7:38 AM, Cullen Jennings (fluffy) <fluffy@cisco.com>
wrote:

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