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