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

Re: Syntax options for constraints structure

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sat, 12 May 2012 15:38:55 +0200
Message-ID: <4FAE67EF.7060305@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).

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:

   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?
Received on Saturday, 12 May 2012 13:39:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC