W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2012

RE: Proposal for device "enumeration"

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Fri, 7 Dec 2012 17:43:46 +0000
To: Adam Bergkvist <adam.bergkvist@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3853AD19AF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> On 2012-12-06 18:57, Martin Thomson wrote:
> > As discussed on the call, and as no doubt Travis is already typing up,
> > here is what I think we need for device enumeration:
> >
> > VideoStreamSource and AudioStreamSource each have a static method
> > (invoked on the constructor, not an instance) that produces a sequence
> > of device identifiers.
> >
> >    typedef DOMString DeviceId;
> >    partial interface VideoStreamSource {
> >      static sequence<DeviceId> getDeviceIds();
> >    }
> >    partial interface AudioStreamSource {
> >      static sequence<DeviceId> getDeviceIds();
> >    }
> Is the gain of enumerating the deviceIds that high that it's worth the
> finger printing surface?
> Couldn't you solve the use case of requesting a specific specific camera
> (you have used before and know works) by only exposing the deviceId on
> that source and having a constraint to request that particular device
> again with getUserMedia()? The app could create and persist something
> similar to getDeviceIds() (above) itself, but only with ids of devices
> it has been granted access to. The latter could be a rule for the native
>   getDeviceIds() functions as well, but it complicates things a bit.

Let me throw out my idea for how I'd like to write this up in the next settings proposal draft.

Instead of a deviceId, I want to use a deviceIndex (I'll call it sourceIndex). This meets most use cases except those in which an application wants to be able to detect a specific camera AND the user has multiple cameras that are not (or rarely) connected to the UA (the plug-in style of cameras/mics). Otherwise, as long as the UA places sources into an ordered list consistently (for the known device sources), and sources in this list are guaranteed not to have their index changed as long as the app is running (even if other devices are unplugged), and that new devices added during the lifetime of the app are added to the end of the list, then an app can generally rely on a source index just as well as a device identifier. When you get an actual source, you'll also be able to read what its sourceIndex is, as this will be just another setting. I'll keep the getNumDevices() API so that an app can know how many sources there are before requesting.

I think this is far easier to spec, less prone to fingerprinting, and maintains almost all of the important use-cases. As previously noted, if devices don't come and go frequently (which I assume to be the case for most devices with embedded microphones/cameras), then apps can reliable cache the last known index of a device they want to request next time, and simply request it.

For requesting a previously identified source, you apply the constraint:

New VideoStreamTrack({ optional: [ { deviceIndex: 0 } ] }); // or mandatory, if you must have it, but this isn't advised as the identity of the device at index 0 _can_ change between invocations of the app.

Through the new settings API you will be able to use this new constraint to change sources for a track.
Received on Friday, 7 December 2012 17:44:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:13 UTC