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