Re: Track cloning behavior of MediaStream() constructor and addTrack()

On 03/20/2013 12:44 PM, Jim Barnett wrote:
> There's also a question of what it means for a Track to be attached to a sink.  The MediaRecorder class takes a MediaStream as its input, not an individual Track.  Does the Recorder serve as a sink for both the MediaStream and its Tracks?  My guess is that it does, and that in general whenever a MediaStream is attached to a sink, all its Tracks are as well, but we would need to make this explicit.

That's been the only meaning I have been able to attach to "A 
MediaStream is attached to a sink". Being explicit is always good.

BTW, if we are able to attach one MediaStream to multiple sinks (which I 
think we want to do), by that logic we also are attaching one 
MediaStreamTrack to multiple sinks; we've discussed usage cases for that 
multiple times in the past (sending the same stream to multiple 
PeerConnections + a local preview window + a recorder, for instance).


>
> - Jim
>
> -----Original Message-----
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> Sent: Wednesday, March 20, 2013 3:25 AM
> To: Martin Thomson
> Cc: Jim Barnett; Stefan Håkansson LK; public-media-capture@w3.org
> Subject: Re: Track cloning behavior of MediaStream() constructor and addTrack()
>
> On 2013-03-19 16:57, Martin Thomson wrote:
>> Maybe an explicit .clone() is the right answer, with one additional wrinkle:
>>
>> Throw an exception if a track is already attached to a sink.
>>
>> Then we can enforce a strict 1 source, 1 track, 1 sink cardinality
>> without strange and opaque behaviour.  Each track could have a 'sink'
>> attribute that exposes any existing attachment so that this limitation
>> is discoverable.  You can add text to the exception that recommends
>> .clone()-ing.
> Can you be more specific about the strange and opaque behavior?
>
> I see a track as an instance of a control surface for a source used to, e.g., mute/unmute and direct the source output to a sink. I don't see a clear reason why we should limit how many sinks a track can direct its output to.
>
> [Source] ---> [Track] ---> [Sink]
>                         \--> [Sink]
>
> Two sinks rendering data from a source with the same control surface.
>
> [Source] ---> [Track] ---> [Sink]
>            \--> [Track] ---> [Sink]
>
> Two sinks rendering data from a source with different control surfaces.
>
> /Adam

Received on Wednesday, 20 March 2013 12:38:41 UTC