- 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>
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) controls.
Received on Sunday, 16 August 2015 15:25:59 UTC