Re: Update of Doohickey/AddTrack proposal

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 Monday, 10 February 2014 17:02:30 UTC