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

Re: Update of Doohickey/AddTrack proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 10 Feb 2014 18:01:53 +0100
Message-ID: <52F90601.2060507@alvestrand.no>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>, public-webrtc@w3.org
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC