Re: A proposal for getUserMedia constraints based on the consensus reached in the DC interim

On 10/06/2014 10:18 AM, Harald Alvestrand wrote:
> 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)

Maybe it will help if we think of this in terms of HTML. Imagine that 
"min" and "environment" are equivalent to HTML tags and they are 
associated with attributes. I am saying we have:

<min value="1024" required>
<environment value="true" required>

If you look at it that way, "min" has an implicit attribute "required" 
and environment has an implicit attribute value="true".

Under the current modal, you have:

<min value="1024" required>
<required value="environment">

which seems backward to me. The model I am suggesting also scales 
better. Parameters like "environment" might take a value in the future 
(not "environment" itself, but other parameters that might show up in 
that space in the future).

Gili

>
>>
>>> - 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 15:42:52 UTC