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

Re: Simulcast V1

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sat, 15 Aug 2015 05:51:43 +0000
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
CC: Adam Roach <abr@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B342308C7@ESESSMB209.ericsson.se>
On 14/08/15 19:31, Bernard Aboba wrote:
> On Aug 13, 2015, at 23:21, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>>
>> 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.
>
> [BA] That depends on what assumptions are being made about Selective
> Forwarding Unit (SFU) behavior and simulcast multiplexing.
>
> As an example, if the SFU is assumed to send only a single stream to
> the receiver, there is only "simulcast" being sent, not received. In
> that case the only potentially relevant parameter is the maximum
> number of streams that can be sent.

I agree, and my understanding is that it was this use case Adam's 
proposal addresses.

Trying to get my head around it: would it be fair to say that the main 
difference between Adam's proposal and track cloning relates to the 
SDP's produced by the browser? One the media plane it's the same (given 
Bundle is used): the different simulcast streams travel on the same 
ports with the same encodings etc.


>
> Of course it is also possible for the SFU to send multiple streams
> and SSRCs to the receiver, with or without distinct payload types for
> each.  In that case an RtpReceiver needs to be able to receive
> multiple streams and produce a single track from them, so it is
> considerably more complex.

Agreed.
Received on Saturday, 15 August 2015 05:52:10 UTC

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