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

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.

> - the WebIDL already permits multiple DOMString values in "exact" and 
> "ideal"

Multiple values is one thing, ordered is another.

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 13:13:40 UTC