RE: Constraints at request time (Re: Revised Constraints modification API proposal)

The current range-based constraints could also be re-interpreted to be Boolean.  For instance, there could be a binary setting like enableHighResCapture.  The UA could interpret such a setting to provide a high res low fps stream when the flag is set, and the developer doesn't have to deal with mandatory constraint settings (and multiple invocations of gUM) to get what is required.  Or maybe this has been considered and rejected by the group before?

That would provide a simple solution to the use case I clumsily tried to describe on the call today - enabling a higher-quality stream when a preview is required specifically for still image capture.

-Giri Mandyam

-----Original Message-----
From: Travis Leithead [mailto:travis.leithead@microsoft.com] 
Sent: Thursday, August 23, 2012 11:54 AM
To: Randell Jesup; public-media-capture@w3.org
Subject: RE: Constraints at request time (Re: Revised Constraints modification API proposal)

> From: Randell Jesup [mailto:randell-ietf@jesup.org]
> 
> On 8/23/2012 10:03 AM, Harald Alvestrand wrote:
> > (Note - I think we need to separate cleanly the constraints, which 
> > apply to capabilities of the device, from *commands* to the device, 
> > like "turn the flash on" or "pan to the left" - the latter needs to 
> > be an interface like what Rich is suggesting. It can't be expressed 
> > sensibly using constraints.)
> 
> Agreed; see my last message.  I'd be interested in how well Rich's 
> proposal handles the usecases I mention there.  (I'm behind in my reading here).

Yeah, some settings work better as properties, e.g., Booleans. (use flash, use backlight, etc., all the toggles)

The settings that I map to constraints (in my head) are the ones that take ranges (mostly stuff like resolution and framerate)

Having a list of these to talk in specifics will be very helpful.

Received on Thursday, 23 August 2012 19:06:28 UTC