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

Re: API or spec to limit a certain sending track

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 4 Aug 2017 09:01:09 +0000
To: Iñaki Baz Castillo <ibc@aliax.net>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <HE1PR07MB09703EDF8F3C44EBC233D8F2C9B60@HE1PR07MB0970.eurprd07.prod.outlook.com>
On 04/08/17 09:56, Iñaki Baz Castillo wrote:
> 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).

What you say above matches my understanding. I guess 
RTCRtpEncoding.priority can also be used to stop one track from eating 
(too much) bitrate from another track you think is more important.

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

I fully understand the pain trying to do magic with a toolbox that is 
not complete and with defects on some of the tools available - but I 
guess that is what you can expect at this stage!

>
> 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.
>>>
>>>
>>
>
>
>
Received on Friday, 4 August 2017 09:01:40 UTC

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