Fwd: Re: Syntax options for constraints structure

oops, sent this to the wrong list.

-------- Original Message --------
Subject: 	Re: Syntax options for constraints structure
Resent-Date: 	Sat, 12 May 2012 13:39:16 +0000
Resent-From: 	public-webrtc@w3.org
Date: 	Sat, 12 May 2012 15:38:55 +0200
From: 	Harald Alvestrand <harald@alvestrand.no>
To: 	Anant Narayanan <anant@mozilla.com>, public-webrtc@w3.org



On 05/11/2012 09:46 PM, Anant Narayanan wrote:
>  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).
Anant,

I don't think you are interpreting the example in the way the algorithm
suggested in Dan's proposal works.

In Dan's proposal, the implementation will satisfy all constraints in
the list until it meets a constraint it can't satisfy.
>
>  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
>        }
>      ]
>    }
>  });
So in this example, the second constraint would always be satisified if
the first was, and would thus have no effect.

Instead, you'd have to write:

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

     ]
   }
});

saying "I want at least 15 fps of 320x240 or better; if you can make it,
I'll want 640x480@30 fps".

Note my reaction to grouping is the same as Dan's: It's not clear what
the semantics are.

>  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.
If you intend to comment on Dan's algorithm proposal, I think your
example is wrong; if you're proposing an alternative evaluation
algorithm for optional constraints, I don't understand what it is.

Can you clarify?