- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Thu, 23 Aug 2012 19:23:47 +0000
- To: Jim Barnett <Jim.Barnett@genesyslab.com>, Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com] > > 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) Here's what I'd like to see: getUserMedia: * supports required device properties * supports optional device capabilities (this helps browsers build a smarter UX for initial camera selection but does not exclude devices based on capability) getSettings(): * returns optional device capabilities (those with range values other than binary) applySettings(x): * supports required device capabilities with a failure notification mechanism Settings that are binary should just be made into read/write properties for convenience I think that at this point we need to get concrete about which capabilities we want to expose in V1 of our specification (Rich suggested a few already) and how our proposed mechanisms work with them. I'll plan to revise my proposal again based on the existing feedback.
Received on Thursday, 23 August 2012 19:24:32 UTC