RE: Cloning and sharing of MediaStreamTracks - worth it?



-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Wednesday, May 08, 2013 8:35 AM
To: Jim Barnett
Cc: robert@ocallahan.org; Harald Alvestrand; public-media-capture@w3.org
Subject: Re: Cloning and sharing of MediaStreamTracks - worth it?

On 2013-05-08 14:28, Jim Barnett wrote:
> 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.)

My (probably way to naïve) model was that all constraints where applied on the device itself. If you want to do it in postprocessing, that is something that can be done with other tools (Web Audio, Canvas, ...).

I'm sure there are things I have overlooked.

>> If all constraints/settings apply to the device, then is enabled/disabled the only setting that is specific to the Track?  
>> Jim

>
> 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 14:22:12 UTC