Re: Cloning and sharing of MediaStreamTracks - worth it?

On 2013-05-08 08:47, Robert O'Callahan wrote:
> On Tue, May 7, 2013 at 3:30 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     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).
>
>
> We should never ever allow a single MediaStream to be accessed by
> different threads.

I guess that is right. So, then I think (if my thinking is correct) that 
we could quite easily redefine MediaStream's constructor and behavior at 
addStream so that a MediaStreamTrack could never be part of more than 
one MediaStream.

What we have not discussed are the advantages of allowing a 
MediaStreamTrack to be part of more than one MediaStream, and if those 
would weigh heavier than the re-implementation effort.

Off-hand, I can think of two advantages:
* For situations when the same behavior for source (e.g. disabling) that 
is represented in many MediaStream's is wanted, it could do it once (and 
not have to do it for all).
* For situations when the media is sent over the network (via a 
PeerConnection) there could be efficiency gains (since it would be sent 
only once)

I think the first one is very minor. The second one is harder to value, 
but applications concerned with transmission efficiency could probably 
accomplish the same saving by sending only one version and clone at the 
receiving end.

Are there other advantages?

>
> Rob
> --
> q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
> qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
> qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q
> qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq
> qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq
> qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

Received on Wednesday, 8 May 2013 07:33:00 UTC