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: Sun, 16 Aug 2015 15:25:31 +0000
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
CC: Adam Roach <abr@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B34235ADC@ESESSMB209.ericsson.se>
On 15/08/15 18:56, Bernard Aboba wrote:
> On Aug 14, 2015, at 22:51, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> 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 produced by the browser? On 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.
> [BA] The media would have similar transport characteristics and could
> be signaled on the wire in a similar way, but there is still the
> question of how to control characteristics of the simulcast streams
> being sent. In track cloning, constraints are used for this, in which
> characteristics of each track are individually specified.  In ORTC
> RtpEncodingParameters are used, which allows the relationship between
> the streams to be explicitly described (e.g. Low-res is 1/4 the
> resolution of hi-res).  Implementations of these control mechanisms
> could produce the same result with similar performance, but they
> might not.

I understand, but the proposal from Adam had nothing like that IIUC, it 
was just a simulcastCount on the RtpSender which in turn would lead to a 
SDP O/A cycle where the remote end would decide the relationships via 
the SDP answer. Quite different to the ORTC API where the sender (JS) 

Received on Sunday, 16 August 2015 15:25:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC