Re: Update of RTCRtpSender "doohickey" proposal

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)

and I'm wondering whether we want a one-to-many relationship between MST 
and RtpSender/PeerConnection, especially since, looking at 
MediaStreamTrackState's "new", "live" and "ended", there's no talk about 
multiple sinks or how that would work.

Cloning is cheap since that's what gUM does, so maybe there's some 
benefit to saying:

Source -+-> MST ---> <video/>
         +-> MST ---> <video/>
         +-> MST ---> RtpSender ---> DtlsTransport ---> (The Internet)
         '-> MST ---> RtpSender ---> DtlsTransport ---> (The Internet)

I don't know, just wanted to mention it. If there's no advantage then 
fine, I suppose in JS we should let people connect whatever works.

There's a bit of redundancy in that one can pause an MST (seems like the 
only thing one can do with an MST!) and you have pausing per 
EncodingParams as well, but maybe that's ok?

.: Jan-Ivar :.

> On Tue, Apr 29, 2014 at 4:54 PM, Jan-Ivar Bruaroey <jib@mozilla.com 
> <mailto:jib@mozilla.com>>wrote:
>
>     On 4/29/14 7:07 PM, Martin Thomson wrote:
>
>         I was talking about clone-on-RTCPeerConneciton::addStream
>
>
>     Forcing me, as a user, to clone my MST if, and only if, I want to
>     add it to more than one PeerConnection seems to have little to no
>     cost to me, and seems like a reduction in complexity.
>
>     It removes one of the arguments I heard for needing the dohickey.
>     The others may be sound, I don't recall them all.
>
>     .: Jan-Ivar :.
>