- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 23 Aug 2012 16:03:30 +0200
- To: public-media-capture@w3.org
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:04:06 UTC