- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 21 Nov 2013 12:55:03 -0800
- To: Jan-Ivar Bruaroey <jib@mozilla.com>
- Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 21 November 2013 12:49, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: > It's also a better fit with Constrainable.applyConstraints() since optional > constraints don't really make sense in that case. I'm imagining feeding > applyConstraints() with the same type as the elements in the array given to > getUserMedia(). > > > Interesting. To be clear, I wasn't proposing that, but I'm glad the > decoupling opens up the discussion. Feeding it the array itself would match > how it works today. > > You have a point. Constraints let you be imprecise, saying things like "give > me something like 40 - 50 fps, but no lower than 1024x768". This abstraction > seems like overkill when you can read the capabilities of the device. > > Just to be sure: track. applyConstraints() can never pick a different > camera, right? That seems obvious inside a stream with other tracks, but > it's never spelled out. If it can't then I don't see why we need constraints > here, setSettings() would suffice. One of the reasons I'd become comfortable with constraints to a certain extent was the way that it can potentially manage concurrent access to a media source. This would remove that property, which I would be a little sad about.
Received on Thursday, 21 November 2013 20:55:31 UTC