- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 9 May 2013 15:13:14 +0200
- To: Jim Barnett <Jim.Barnett@genesyslab.com>
- CC: "robert@ocallahan.org" <robert@ocallahan.org>, Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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:14:16 UTC