- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 10 Jun 2014 16:18:08 +0200
- To: public-media-capture@w3.org
On 06/10/2014 03:12 PM, cowwoc wrote:
> On 10/06/2014 6:42 AM, Harald Alvestrand wrote:
>> 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
>
> I think you're missing the parameter name with its attributes, which
> brings me to another point I didn't mention: consider flipping "exact"
> and "environment" so "environment" can be assigned one or more
> attributes, where "required" is one of them. This would actually be
> more consistent with "min" and "max" in that the latter will have an
> implicit "required" associated with them.
Like Peter, I don't want to make changes just for the sake of making
changes.
What is the use case for which this will make a difference?
(I can't parse the comment - "environment" is a value of the facingMode
constraint, while "exact" is a token of the proposed syntax; flipping
them doesn't make sense to me)
>
>> - the WebIDL already permits multiple DOMString values in "exact" and
>> "ideal"
>
> Multiple values is one thing, ordered is another.
For ordered, I think we want to direct people to use "advanced".
>
> Gili
>
>>
>>
>> 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 14:18:44 UTC