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

Re: Simulcast V1

From: Adam Roach <abr@mozilla.com>
Date: Fri, 14 Aug 2015 15:51:29 -0500
Message-ID: <55CE54D1.5050905@mozilla.com>
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>
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

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