Re: Update of Doohickey/AddTrack proposal

On 2014-02-11 00:26, Justin Uberti wrote:
> I tend to agree with Harald. There may be other options in the future,
> but for now, I think a track needs to signal what stream(s) it is a part
> of, so that the simple send-audio-and-video-as-synchronized case works.

I think that signaling could lead to something that is quite messy (as 
Adam pointed out), and the simple send-audio-and-video-as-synchronized 
case could work anyway. Assuming one audio and one video track belonging 
to the same MediaStream on the sending side: the app at the receiving 
end could just construct a MediaStream and add the incoming tracks to it.

>
> Regardless, I'd like to advance this proposal so that we can start
> nailing down any necessary details on the RTCRtpSender/Receiver objects
> (AKA doohickeys).

Agree fully to this.

>
>
> On Mon, Feb 10, 2014 at 9:01 AM, Harald Alvestrand <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> wrote:
>
>     On 02/10/2014 03:01 PM, Adam Bergkvist wrote:
>      > On 2014-02-06 19:31, Harald Alvestrand wrote:
>      >> On 02/04/2014 02:13 PM, Adam Bergkvist wrote:
>      >>> Hi
>      >>>
>      >>> How should we proceed with this proposal? I don't think we will
>     gain
>      >>> as much when it comes to simplicity if we just remove
>     addStream(), but
>      >>> keep the concept of tracks belonging to a MediaStream when they are
>      >>> sent over an RTCPeerConnection (as Stefan argues in a branch of
>     this
>      >>> thread). That was at least what I had in mind when I argued against
>      >>> addStream() in [1].
>      >>
>      >> I think communicating the stream concept (which streams exist
>     that have
>      >> this track as part of it) is important; if we don't communicate
>     it, it's
>      >> impossible to reconstruct the streams on the receiving side.
>      >
>      > Just because *we* don't signal it, doesn't mean that such information
>      > can't be sent (if necessary for the app). Simple (and legacy
>      > compatible) apps would perhaps use a single stream for all incoming
>      > tracks, and multi MediaStream apps could signal a list of track id's
>      > that makes up a MediaStream.
>      >
>      > Which streams exist and what tracks they contain is subject to
>     change.
>      > If that's something we want to reflect to the other side then that
>      > could involve a lot of signaling (that needs to be specified but
>     could
>      > be made easier if it was app specific).
>
>     This would mean abandoning the current feature that you can set up a
>     connection without signallling anything but the messages made by
>     CreateOffer/CreateAnswer.
>
>     I thought we had finished that debate 1-2 years back.
>
>
>
>     --
>     Surveillance is pervasive. Go Dark.
>
>
>

Received on Tuesday, 11 February 2014 14:51:16 UTC