Re: API or spec to limit a certain sending track

Hi Inaki,

to sum things up, what I see as available tools from an API perspective are:

on MediaStreamTrack:
--------------------
- constrain framerate, width, height, etc.
-- reducing those would presumably reduce the bitrate (as there is less 
data to encode)
- put enabled to false
-- extreme! would lead to blackness being encoded (and there is even a 
discussion if the framerate as a result could drop) which would be a 
very low bitrate

on RTCRtpSender:
----------------
- put a ceiling on outgoing bitrate (maxBitrate)
-- seems like a perfect match to your use case!?
- scale down resolution (scaleResolutionDownBy) or limit framerate 
(maxFramerate)
-- would presumably reduce the bitrate (as there is less data to encode)
- use priority
-- in your use case, putting hinger prio to the deskstop share track, 
and lower (while the sharing happens) to the webcam track should work
- set active to false
-- extreme! would stop sending the web cam track

On a signaling level there is b=AS. And in the media plane TMMBR.

I understand the problem that implementations are not yet supporting all 
of the above, but from a spec perspective it looks to me like we got the 
tools you would need.

One possible problem can be that things like priority and congestion 
control as well as how bitrate is affected by limiting framerate or 
resoltion is quite loosely specified and likely implementation (and even 
perhaps codec) specific, so you could get different results for 
different implementations. But again, to me it looks like maxBitrate on 
the sender would be a perfect fit to your question "...which is the 
WebRTC proposed solution to dynamically limit the bitrate of one of them?".

Br,
Stefan

On 28/07/17 12:21, Iñaki Baz Castillo 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.
>
>

Received on Thursday, 3 August 2017 12:09:01 UTC