- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 10 Jun 2014 12:42:37 +0200
- To: public-media-capture@w3.org
I like this! Do you have a different proposal in the works to figure out an exemplar algorithm for how to resolve multiple "ideal" constraints together? I guess we also need to have a reworked algorithm for describing exactly how the pieces fit together in the New World Order (including "advanced"). Some comments on thread: - I have come to like "advanced" because the name tells you "unless you've read the documentation, you have little chance of figuring out what goes on here". Sad in a way, but realistic, and useful. - "exact" is better than "required" because "min" and "max" are also required, so we shouldn't be using that word for something different - the WebIDL already permits multiple DOMString values in "exact" and "ideal" On 06/09/2014 11:08 PM, Peter Thatcher wrote: > At the interim meeting in DC, we reached a consensus for a form of > getUserMedia constraints that has the following form: > > var supports = DeviceManager.getSupportedConstraints("video"); > if(!supports["aspectRatio"] || !supports["facingMode"]) { > // Treat like an error. > } > getUserMedia({“video”: { > “width”: {"min": 320, “ideal”: 1280, “max”: 1920}, > “height”: {"min": 240, “ideal”: 720, “max”: 1080}, > // Shorthand for ideal. > “framerate”: 30, > // "facingMode": "environment" would be optional. > “facingMode”: {"exact": “environment”}, > "advanced": [...] > }}, ...); > > And the following rules: > > 1. "min", "max", and "exact" are required, except when in the > "advanced" list. > 2. "ideal" and a bare value or list of values are optional. > 3. The browser indicates what it supports via > DeviceManager.getSupportedConstraints, which the JS can use to make > sure the browser supports a certain constraint before trying to use it. > > Here is an example of "I want 720p, I can go up to 1080p, and I can go > down to VGA": > > getUserMedia({“video”: { > “width”: {"min": 640, “ideal”: 1280, “max”: 1920}, > “height”: {"min": 480, “ideal”: 720, “max”: 1080}, > }}, ...); > > > Here is an example of "I want camera X, ideally with VGA": > > var cameraSourceId = ...; > getUserMedia({“video”: { > "sourceId": {"exact": cameraSourceId}, > "width": 640, > "height": 480 > }}, ...); > > Here is an example of "I want a front-facing camera and it must be VGA": > > var supports = DeviceManager.getSupportedConstraints("video"); > if(supports["facingMode"]) { > getUserMedia({“video”: { > "facingMode": {"exact": "user"}, > "width": {"exact": 640}, > "height": {"exact": 480} > }}, ...); > } > > Here is an advanced example of "I want 4k, then 1080, then 720p, and > nothing else". > > getUserMedia({“video”: { > "advanced": [ > {"width": 4096, "height": 2160}, > {"width": 1920, "height": 1080}, > {"width": 1280, "height": 720} > ] > }}, ...); > > > I have looked through the existing WebIDL, and I believe this is would > be the best way to structure the new WebIDL. Note the assumption that > there is a "DeviceManager" to be added before this: > > partial interface DeviceManager { > // Keys are constraint keys, and truthy values = supported and > // untruthy values = unsupported. > static Dictionary getSupportedConstraints(DOMString kind); > } > > dictionary MediaTrackConstraints : MediaTrackConstraintSet { > sequence<MediaTrackConstraintSet> advanced; > }; > > dictionary MediaTrackConstraintSet { > ConstrainLong width; > ConstrainLong height; > ConstrainDouble aspectRatio; > ConstrainDouble frameRate; > ConstrainVideoFacingMode facingMode; > ConstrainDouble volume; > ConstrainLong sampleRate; > ConstrainLong sampleSize; > boolean echoCancelation; > ConstrainDOMString sourceId; > }; > > typedef (Long or ConstrainLongRange) ConstrainLong; > typedef (Double or ConstrainDoubleRange) ConstrainDouble; > typedef (DOMString or sequence<DOMString> or ConstrainDOMStringParameters) > ConstrainDOMString; > typedef (VideoFacingModeEnum or sequence<VideoFacingModeEnum> or > ConstrainVideoFacingModeParameters) ConstrainVideoFacingMode; > > dictionary ConstrainLongRange { > long max; > long min; > long exact; // new > long ideal; // new > } > > dictionary ConstrainDoubleRange { > double min; > double max; > double exact; // new > double ideal; // new > }; > > // new > dictionary ConstrainDOMStringParameters { > (DOMString or sequence<DOMString>) exact; > (DOMString or sequence<DOMString>) ideal; > } > > // new > dictionary ConstrainVideoFacingModeParameters { > (VideoFacingModeEnum or sequence<VideoFacingModeEnum>) exact; > (VideoFacingModeEnum or sequence<VideoFacingModeEnum>) ideal; > } > > Note that it's possible, according to the type system, to have "exact" > and "ideal" in "advanced", which doesn't make sense according to the > algorithm. But making that not possible complicates the types a lot, > which probably isn't worth it. It would be much more simple to put a > check in the runtime rather than the type system to disallow that. > > > Now, two questions: > > 1. Does everyone like these details? > 2. What are the next steps to add text and get in the spec?
Received on Tuesday, 10 June 2014 10:43:11 UTC