Re: Simulcast V1

Hey Adam, Stefan,

On Fri, Aug 14, 2015 at 1:19 AM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> 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.

I very much agree with this observation.

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

I like the object oriented approach but it might be trickier than it
sounds. You would need to make sure the browser can distinguish
between the simulcast case and a scenario where the app just needs two
RTP senders for some other appy reason.

Ultimately I don't care that much about, which exact way we go as long
as we pick something (which I think is very important that we do).

Emil


-- 
https://jitsi.org

Received on Friday, 14 August 2015 15:14:33 UTC