- 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>
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.
+1
>
> 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.
Stefan
Received on Thursday, 1 May 2014 07:23:21 UTC