Re: Cloning and sharing of MediaStreamTracks - worth it?

Jim,

inline.

On 2013-05-09 15:24, Jim Barnett wrote:
> 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.

I was earlier pursuing something like this (you may remember me mumbling 
about moving enable/disable to the sink from time to time...). But I 
don't have a strong view really, it on one hand seems cleaner, on the 
other hand we have the MediaStream's and MediaStreamTrack's in 
implementations and in people's mind. I'm not sure the benefits of 
changing are bigger than the work to re-spec and re-implement - but it 
is really up to this TF to decide.

>
> - 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:49:46 UTC