- From: Adam Roach <abr@mozilla.com>
- Date: Fri, 14 Aug 2015 15:51:29 -0500
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>, Adam Roach <abr@mozilla.com>
- CC: Byron Campen <docfaraday@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <55CE54D1.5050905@mozilla.com>
On 8/14/15 15:23, Bernard Aboba wrote: > > On Aug 14, 2015, at 1:02 PM, Adam Roach <abr@mozilla.com > <mailto:abr@mozilla.com>> wrote: > >> Regardless of how you differentiate the simulcast encodings, what I'm >> proposing for the API works just fine. > > [BA] I understand why it is useful to have maxSimulcasts as a > capability, but not as a setting on RtpSender the way you have > proposed it. What benefit does this have beyond track cloning? It's not just track cloning; it's sending multiple stream encodings according to unified plan and according to the way the IETF is defining simulcast. > >> What's important /here/, in the W3C WebRTC working group, is that my >> simple proposal works regardless of the outcome of those IETF >> discussions. > > [BA] There is no need to drag in the MMUSIC draft to solve the simple > case you describe, so in that sense you are correct. However since > what you need to do seems possible with additional capabilities but > without an RtpSender addition, and more complex support requires > something more like Peter's RtpEncodingParameters PR, the case for a > half measure is pretty weak. Let's back up. The way SDP handling works for RTCWEB is that each m-line represents a single MST. Simulcast deals with transmitting multiple encodings of that same MST simultaneously. The kind of simulcast that implementors have been expressing an interest in is that which conforms to the IETF's simulcast specification (and I mean that in a platonic ideal sense of "whatever the IETF reaches consensus on", not in the sense of "exactly what the current draft says"). Any proposal that one could float that is consistent with unified plan -- and, for that matter, most that I can imagine that don't -- need some indication in the offer about how many encodings an implementation is willing to send. So the question to answer is: "what is the minimal thing we can do to the WebRTC 1.0 spec that allows us to support implementors' requirements to use the IETF-specified simulcast mechanism?" I think this is it. -- Adam Roach Principal Platform Engineer abr@mozilla.com +1 650 903 0800 x863
Received on Friday, 14 August 2015 20:51:59 UTC