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

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.

- 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 11:45:25 UTC