RE: Cloning and sharing of MediaStreamTracks - worth it?

Could we pass the source IDs to the MediaStream constructor, instead of the Tracks?  Does the UA know enough about the types of the devices (given the source id) to create the right type of Track?

- Jim

-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Monday, May 06, 2013 3:32 PM
To: Harald Alvestrand
Cc: public-media-capture@w3.org
Subject: 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 21:24:45 UTC