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