- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Fri, 22 Nov 2013 10:23:52 +0100
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-11-21 21:49, Jan-Ivar Bruaroey 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 Even with applyConstraints() you might still want express something as an acceptable range and then check the setting what you're actually getting. Also, even though the applyConstraints() call succeeded, there might be changing circumstances that prevents the UA from living up to the developers wishes. The constraint concept has a way to deal with that. /Adam
Received on Friday, 22 November 2013 09:24:15 UTC