Re: Simulcast V1

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.

Received on Friday, 14 August 2015 06:19:41 UTC