Re: Cloning and sharing of MediaStreamTracks - worth it?

On 2013-05-06 23:24, Jim Barnett wrote:
> 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?

If the essence of the problem is if a MediaStreamTrack is a member of 
more than one MediaStream, I guess we could keep the current behavior 
(i.e. the MediaStreamTrack is adopted, not cloned) but fire an error if 
the MediaStreamTrack in question is part of another MediaStream.

So, if the application wants (a clone of) a MediaStreamTrack that is 
already part of a MediaStream to be present in another MediaStream it 
could clone that particular MediaStreamTrack before incorporating it in 
the other MediaStream.

This should work as there is a single thread in JS, but we could later 
face problems if we allow workers to use these APIs (as there could be 
race conditions).



>
> - 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 Tuesday, 7 May 2013 10:31:07 UTC