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.

>
> 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:35:29 UTC