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

Re: API or spec to limit a certain sending track

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 4 Aug 2017 09:55:16 +0200
Message-ID: <CALiegf=YN09V1woL+BzAqxrtgFxY_+t+tOegTGKEVqKmJC-Niw@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Thanks Stefan, really excellent points.

So, the "real" ways to limit the sending bitrate of a track (rather
than constraining its resolution or framerate) are:

1) RTCP TMMBR (assuming correctly implemented).

2) RTCRtpEncoding.maxBitrate (assuming it's implemented).

3) b=AS (assuming browsers implement Unified-Plan).

None of them is feasible today, but it's good to know which future
features to track.

Thanks a lot.


On Thu, Aug 3, 2017 at 2:08 PM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> 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.
>>
>>
>



-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Friday, 4 August 2017 07:56:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC