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

Re: Explicit track cloning

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 9 Apr 2013 09:30:03 -0700
Message-ID: <CABkgnnVxrN03nHFKBbdeL0r=Wi6B+yVm3LiT61390cC+=vee9Q@mail.gmail.com>
To: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 9 April 2013 07:43, Stefan HÃ¥kansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> My preference would be *1*. I don't really see why we would do any changes
> if we do not allow the same track to be part of more than one MediaStream -
> the current text says that constructing a MediaStream, or doing addTrack,
> clones the tracks.

Not taking any position here, but I can't parse your rationale here.


Just to be perfectly clear, the reason we are discussing this is:
Tracks are mutable, their settings can change.  Tracks can be grouped
in multiple MediaStreams.  Certain properties of tracks were perceived
as only being relevant in the context of a MediaStream.

I'm speaking here of enabled/disabled specifically, the other settings
are less problematic.  Changing enabled/disabled only has meaning in
the context of the MediaStream.  As a consequence, a change to a Track
has surprising side effects if that Track is used in two places.

... An alternative that hasn't been considered (at least publicly) is
to have enabled/disabled as a Track-indexed property of a MediaStream.
 Then Tracks don't need this property.  Two possible embodiments:
split Tracks into enabled and disabled sets, or have a map (something
like stream.enabled[track]). That's almost too ugly to contemplate
though.
Received on Tuesday, 9 April 2013 16:30:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:40 UTC