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

Re: Simulcast V1

From: Byron Campen <docfaraday@gmail.com>
Date: Fri, 14 Aug 2015 11:01:09 -0500
To: public-webrtc@w3.org
Message-ID: <55CE10C5.1040309@gmail.com>
On 8/14/15 1:19 AM, Stefan Håkansson LK wrote:
> On 14/08/15 01:05, Adam Roach wrote:
>> I've been involved in a number of recent conversations around simulcast
>> for WebRTC, and a several implementors have indicated that it's an
>> important feature for the initial release of WebRTC.
>>
>> As I understand the state of play:
>>
>>    * Chrome has a form of simulcasting implemented using undocumented SDP
>>      mangling
>>    * Firefox has no simulcasting implemented, but will soon
>>    * The WebRTC 1.0 API has no simulcast-related controls whatsoever
>>    * The IETF MMUSIC working group is nearing completion on a document
>>      (draft-ietf-mmusic-sdp-simulcast-01) that allows negotiation of
>>      simulcast in SDP
>>
>>
>> I also understand and sympathize with the goal to stop adding any
>> non-trivial modifications to the existing WebRTC spec, so that we can
>> finally publish an initial version of the document.
>>
>> At the same time, the vast majority of the use cases that make sense for
>> simulcast involve browsers talking to an MCU (or similar server),
>> sending multiple encodings per track in the browser-to-MCU direction,
>> but receiving only one encoding per track in the MCU-to-browser direction.
>>
>> This is interesting, because it means that we don't really require any
>> controls that indicate the desire for a browser to /receive/ simulcast
>> -- all we need is the ability to indicate a willingness to send it. At
>> the same time, the MCU will know what resolutions (and other variations)
>> it wants to receive, and can inform the browser of this information via SDP.
> We already have a form of "poor man's" simulcast: create several tracks
> that connect to the same source, attach them to individual RtpSender's,
> and apply different constraints and different sender settings to them.
>
> In my personal opinion we should determine whether or not this would be
> sufficient before adding new functionality.
>
>
>
    There is a PR that would let you set a max bitrate, but what we 
really want is to be able to set a max resolution (or maybe a range) and 
framerate. We don't have this feature right now, even in a PR. On the 
flipside, we don't actually need the simple knob Adam described; as long 
as the MCU is willing to send a reoffer, and both ends support 
draft-ietf-mmusic-sdp-simulcast, we're good to go with no additional w3c 
work. Lastly, any object-oriented simulcast API would need support for 
draft-ietf-mmusic-sdp-simulcast anyway, so this is a nice incremental step.

Best regards,
Byron Campen
Received on Friday, 14 August 2015 16:01:36 UTC

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