RE: Cloning and sharing of MediaStreamTracks - worth it?

Stefan,
  This is what confuses me in our discussion of  Track sharing and/or cloning.  If constraints are ultimately applied to the source, then the _only_ thing that applies at the Track level is enabled/disabled.  We've been having a discussion about whether to share Tracks or to clone them or whether to simply create new ones - but there's almost no difference between those options.  In particular, the only difference between cloning a Track and creating a new one is whether it inherits the original Track's enabled state (which it can change at any point.)  

If it's true that all settings apply to the source, then the Track object isn't doing much work at all.  Wouldn't it be clearer to get rid of it and apply the settings directly to the source?  We'd have to find some other place for 'enabled' to apply, but that wouldn't be hard.

- Jim

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

On 2013-05-09 14:31, Jim Barnett wrote:
> Stefan, In an earlier email you said that all constraints/settings 
> applied to the source.  So it sounds like they're all shared.  Is 
> 'enabled' the only setting that is Track-specific?  If there are 
> others, which are they?  We should be very clear which settings apply 
> to the Track and which apply to the source.

I agree, this needs to be clarified, and whatever I've said in the past is probably wrong to a large degree...

But when responding Robert below, I was specifically thinking about mute state vs. enabled/disabled. To me, both of them are track attributes, but the former is just an indication of the source state - is it muted or not - and cannot be changed by the application, and would also be the same for all tracks sharing that source.

Enabled/disabled is on the other hand something that is individual per track, and something the application can manipulate. It won't ripple down to the source, disable would just stop the track from outputting data.

If we move on to constraints/settings, then things get a bit more blurry for me. My understanding (but I think Dan should be talking about this
really) is that

* constraint's are applied on the track (applyConstraints)
* they are in turn used as a request to the source to deliver accordingly (the Editor's draft uses the words "applied to the source")
* what the source actually delivers can be checked by the SourceState
* (what the current constraints applied to the track can be checked by
constraints)

This can get messy when several tracks are attached to the same source. 
If one of the tracks ask for a minimum framerate of 10, and another 30, then it would be ok, but if one asks for max 10 and the other for min 30 there could be problems (unless the source can actually deliver two streams with different characteristics), and I guess that's why we got the overconstrained event.

Stefan
>
> - Jim
>
> -----Original Message----- From: Stefan Håkansson LK 
> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Thursday, May 09,
> 2013 7:46 AM To: robert@ocallahan.org Cc: Martin Thomson; Jim Barnett; 
> Harald Alvestrand; public-media-capture@w3.org Subject: Re:
> Cloning and sharing of MediaStreamTracks - worth it?
>
> On 2013-05-09 09:02, Robert O'Callahan wrote:
>> Having some attributes affect all tracks but others affect just one 
>> of the clones sounds confusing.
>
> All that is shared belongs to the source - and that must be shared.
>
>> Maybe it would be simpler to prevent cloning and share track objects 
>> when necessary.
>
> I think the current design is quite OK.
>
>>
>> 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 Thursday, 9 May 2013 13:25:15 UTC