W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Update of RTCRtpSender "doohickey" proposal

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 1 May 2014 07:22:56 +0000
To: Jan-Ivar Bruaroey <jib@mozilla.com>, Justin Uberti <juberti@google.com>
CC: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFDC663@ESESSMB209.ericsson.se>
On 30/04/14 17:41, Jan-Ivar Bruaroey wrote:
> On 4/30/14 12:54 AM, Justin Uberti wrote:
>> MSTs are about raw media. They know nothing about encoding, bitrates,
>> recvonly/sendonly, etc. Jamming such parameters into a MST is a
>> complete layer violation.
>> A RtpSender, on the other hand, converts the raw media from a MST into
>> packets, which then go over a Transport. These packets are then
>> reconstituted into a MST on the remote side by a RtpReceiver.
> Makes sense, especially when one is in gUM and the other in webRTC.
>>  Please, let's not rewind 6 months of consensus on the need for
>> doohickeys.


> It sounds like there are other benefits, so I wouldn't worry.
> My observation was more upstream, that we are flush with one-to-many
> relationships:
> Source -+-> MST -+-> <video/>
>          |        '-> <video/>
>          '-> MST -+-> RtpSender ---> DtlsTransport ---> (The Internet)
>                   '-> RtpSender ---> DtlsTransport ---> (The Internet)

Doesn't it look more like (S = Source):

S -> MS(MST) ----+-> <video/>
          |       '-> <video/>
          |       '-> Recorder
          +---------> (PerConnX)RtpSender --> DtlsTransp --> (Internet)
          '->MST -+-> (PerConnX)RtpSender --> DtlsTransp --> (Internet)
                  '-> (PerConnY)RtpSender --> DtlsTransp --> (Internet)
                  '-> (PerConnZ)RtpSender --> DtlsTransp --> (Internet)

to illustrate that:
* MS's, not MST's, is what we use for video elements and Recorders
* MST's (in this proposal) is what we use for PCs
* MSTs can be cloned (MSs can be too, not part of fig)
* A single MST can (simultaneously) source several sinks
** Sinks include: Recorders, video elements, PCs
** When the sink is an audio or video element, or a Recorder, the MST is 
embedded in a MS
* There is no point in assigning the same MST (perhaps embedded in a MS) 
as source to one sink more than once - nothing changes

Of course we could consider removing the ability for a MST (MS+MST) to 
source more than one sink. But I am very hesitant - if we talk about 
polyfill, what about all apps that makes gUM create one MS, and uses 
that as source both for a PC and for a video element for a selfview. It 
would break a lot of apps.


Received on Thursday, 1 May 2014 07:23:21 UTC

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