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

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 19 Mar 2013 08:57:01 -0700
Message-ID: <CABkgnnVf=PkC4ef=w9NaheMHv-Me5ESDfBmXL67tzMDgBs1U2Q@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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.

> On 2013-03-18 15:47, Adam Bergkvist wrote:
>> Hi
>>
>> As the spec is currently written, the MediaStream() constructor and
>> the
>> addTrack() method create a new MediaStreamTrack instance to represent
>> a given track argument. Some of the changes we done lately, like
>> removed the ordered track list attributes, have made this API harder to work with.
Received on Tuesday, 19 March 2013 15:57:28 UTC

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