- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Fri, 28 Jul 2017 12:17:45 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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, 28 July 2017 10:18:34 UTC