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

I think that there are 3 different things involved here.  
1) Device properties.  These represent immutable aspects of the device.
Likely examples are whether it produces audio or video, and possibly the
direction it faces (for built-in devices).
2) Device capabilities.  These represent things that the device can do,
but doesn't necessarily have to do.  Some cameras may be able to rotate,
so for them direction is a capability, not a property.  (But the
capability may apply only within a range, for example, when a camera can
rotate up to 90 degrees but no further.)
3) Device settings.  These are the specific values selected for the
capabilities, via the commands  that Harald mentions.  

In principal, there are three different, but related, APIs needed here:
One to request devices with specific properties and capabilities,  one
to describe the capabilities of the devices that are returned, and one
to apply settings to devices. If we have a constraint language that can
describe the device's capabilities (i.e. range of possible values) _and_
the device's current setting, it can support all 3 APIs.  (A property as
a special case of capability: it's one that has a range of 0 or 1,
depending on your point of view).  

One question is  whether we would want the command/settings API to
select a range, rather than a specific value (e.g., I want the camera to
point within 5 degrees of direction x)

- Jim
-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Thursday, August 23, 2012 10:03 AM
To: public-media-capture@w3.org
Subject: Re: Constraints at request time (Re: Revised Constraints
modification API proposal)

On 08/23/2012 03:50 PM, Adam Bergkvist wrote:
>
> I've also though about this initial filtering that applying 
> constraints before presenting device options to the user provides.
> However, I think we win more with the new approach than we loose.
>
> Even with constraints applied after device selection we need some 
> small set of options/constraints to filter the device list presented 
> to the user. We have the obvious "audio" and "video", but we may also 
> need something to hint about camera direction where it's possible 
> ("front"/"user" "back"/"environment"). If this proves to be a huge 
> problem, we could also look into some quality hints here like "hd", 
> "vga" and so on. It won't solve everything but I think it will cover a

> lot of cases.
>
> /Adam
>
Now I've really lost you - are you advocating applying constraints as
part of getUserMedia, or are you advocating not applying constraints as
part of getUserMedia?

I'm not even going to consider the implications of having two different
data structures for constraints, one that you use on getUserMedia and
one that you use after getting the device; that's just too gross to
consider.

(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.)

                       Harald

Received on Thursday, 23 August 2012 14:52:08 UTC