RE: Cloning and sharing of MediaStreamTracks - worth it?

If we agree on the model that a Track represents processing done by the UA to media coming from the source device, then it's easy enough to re-create a Track by creating a new one and then applying the settings from the original Track to it.  (Cloning may be more convenient in some cases, but it's not necessary.) And it's clear that the settings in the different Tracks are independent of each other.    

The thorny question that I don't think we've dealt with is determining which constraints/settings apply to the Track and which apply to the underlying device.  When we discussed 'zoom' on the call yesterday, people said that they expected zoom to use the device's native capabilities, and _not_ postprocessing/faking at the Track level.  That would imply that all Tracks based on that source would be zoomed (unless it's a very sophisticated device that can deliver multiple copies of the same underlying media with different settings applied to them.)  

Do we need two kinds of constraints/settings - one to apply to the device and the other to the Track?  If we say that all constraints/settings apply to the Track, but some also effect the device while others don't, then it's no longer clear what the Track represents.  

- Jim

-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Wednesday, May 08, 2013 3:33 AM
To: robert@ocallahan.org
Cc: Jim Barnett; Harald Alvestrand; public-media-capture@w3.org
Subject: 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 12:28:39 UTC