Re: Explicit track cloning

On 4/9/13 6:30 PM, 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.

Yes, it can have surprising effects, but it can also be a feature.

But my point was, that if we do not want to allow that, then I see 
little need to change the current spec (currently it is specified that 
addTrack as well as constructing a MediaStream always clones).

>
> ... 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.

This is an option we never considered. There was for some time a 
discussion if we should remove enable/disable from tracks, and instead 
do it on the consumer (Recorder, PeerConnection, media element), but a 
recent discussion concluded we should not.

> 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 12:17:26 UTC