Re: Cloning and sharing of MediaStreamTracks - worth it?

On 5/6/13 5:16 PM, Harald Alvestrand wrote:
> Just a quick question....
>
> I have checked with the implementors, and the change to allow both
> cloning and copying of MediaStreamTracks is going to be quite a
> significant burden - there's quite a bit of code there that is written
> with the assumption that one MediaStreamTrack belongs to one and only
> one MediaStream, because the previous version of the API guaranteed that.
>
> I have understood that Adam feels strongly that the design where a
> MediaStreamTrack (with its muted state, constraints and everything else)
> can be a member of multiple MediaStreams is a better design.
>
> I just want to verify that the rest of the group shares the consensus
> (and that our partners at Mozilla are also willing to implement this
> change).

I think the design where cloning, or adopting an existing track, is made 
clearer makes for a better API. But that said, if it is a huge 
implementation burden, perhaps we should do it differently.

What was particularly ugly IMO with the previous design was that if you did:

var TrackA = new AudioStreamTrack();
var TrackB = new AudioStreamTrack();

var newMediaStream = new MediaStream([TrackA, TrackB]);

then, TrackA and TrackB would be unused objects and replaced with new 
cloned tracks in newMediaStream.


Another bad thing were that if you had two tracks, and you knew what 
they represented, but then created a new MediaStream with those two 
tracks you would not know which of the cloned tracks that corresponded 
to which one of the original tracks, but would have to look up sourceIds.


Perhaps we could find other ways around these problems.
>
>                  Harald
>
>
>

Received on Monday, 6 May 2013 19:32:26 UTC