W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2013

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 20 Mar 2013 08:24:45 +0100
Message-ID: <5149643D.60408@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Jim Barnett <Jim.Barnett@genesyslab.com>, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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 07:25:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:15 UTC