W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2012

Re: Syntax options for constraints structure

From: Anant Narayanan <anant@mozilla.com>
Date: Fri, 11 May 2012 12:46:14 -0700
Message-ID: <4FAD6C86.8030800@mozilla.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 5/11/12 10:51 AM, Dan Burnett wrote:
> On May 10, 2012, at 3:17 PM, Anant Narayanan wrote:
>> We could certainly make the optimization of grouping each "set" of constraints in one object instead of making a new object for each constraint, and I think Dan did have something like this in his original proposal in the form of a "Constraint Set", IIRC.
>
> Anant, this was for the mandatory structure, where ordering was not significant, and for the getCapabilities return value, where ordering is also not significant.

I'm having trouble understanding the ordering requirement then. Why do 
we need to support the case where there are two conflicting constraints 
to begin with? Do we have a concrete example for this (as you mentioned, 
minFrameRate and minTimeBetweenRefFrames don't really make sense).

I can see why the app might want to prioritize a /set/ of constraints 
over another. For instance, video of any type is mandatory; I'd prefer 
getting 640x480 @ 30fps if possible, but if not I'll settle for 320x240 
@ 15fps:

navigator.getUserMedia({
   video: {
     mandatory: {},
     optional: [
       {
         minWidth: 640,
         minHeight: 480,
         minFramerate: 30
       },
       {
         minWidth: 320,
         minHeight: 240,
         minFramerate: 15
       }
     ]
   }
});

In other words, I don't see what the use case is for specifying 
conflicting constraints within the same set. Note that sets can contain 
only a single property, so in the event there are, they would just be 
two sets with one constraint each; but I'm guessing the more common case 
would be to have a few sets each containing a few properties each, like 
the above.

-Anant
Received on Friday, 11 May 2012 19:46:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:14:59 GMT