Re: Explicit track cloning

On 2013-04-09 18:30, Martin Thomson wrote:
> 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.

I would say that most properties of a track only have meaning when the 
track is in a MediaStream and to that add - when that stream is being 
consumed. But that's the way our MediaStreamTracks are used so I think 
that's OK.

Regarding the surprising side effect; I think that's a documentation 
thing. In Jim's example this was a feature. There's sometimes a fine 
line between the two. :)

/Adam

> ... 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 Wednesday, 10 April 2013 06:09:05 UTC