Re: An alternate approach to enumerating devices

That was too weird - trying again, without formatting....

The WebRTC GetUserMedia spec released on March 20 has this device 
enumeration API on the VideoStreamTrack and AudioStreamTrack:

-------------------------------------

interface VideoStreamTrack : MediaStreamTrack {
static sequence<DOMString> getSourceIds ();
....
};

Explanation:

getSourceIds, static
Returns an array of application-unique source identifiers. This list 
will be populated only with local sources whose sourceType is "camera" 
or "photo-camera" [and if allowed by the user-agent, "readonly" variants 
of the former two types]. The video source ids returned in the list 
constitute those sources that the user agent can identify at the time 
the API is called (the list can grow/shrink over time as sources may be 
added or removed). As a static method, getSourceIds can be queried 
without instantiating any VideoStreamTrack objects or without calling 
getUserMedia().

ISSUE 1
Issue: This information deliberately adds to the fingerprinting surface 
of the UA. However, this information will not be identifiable outside 
the scope of this application and could also be obtained via other 
round-about techniques using getUserMedia().
(end quote)

--------------------------


I suggest this is a bit limited, and we should instead offer:

<proposal begins>

interface MediaStreamTrack {
static sequence<SourceInfo> getSourceInfos()
}

dictionary SourceInfo {
DOMString id; // same as “sourceid” in previous proposal
DOMString kind; // “video” or “audio”
DOMString label; // only present if authorized
VideoFacingModeEnum facing; // only for video sources
}

with the additional text:

If the application is authorized to get info from one or more sources, 
the “label” attribute will be filled in for those sources, with exactly 
the same value as one would have had if the application had done 
getUserMedia with a constraint specifying that camera ID.

<proposal ends>

The interface is on MediaStreamTrack, which allows video and audio 
sources to be retrieved in a single call, and also allows additional 
types of source with no API change, if that ever becomes needed. It’s 
also easily extensible to allow other kinds of information to be 
returned, if desired.

For reference, here’s the description of “label” from the 
MediaStreamTrack section:

label of type DOMString, readonly
User agents may label audio and video sources (e.g., "Internal 
microphone" or "External USB Webcam"). The MediaStreamTrack.label 
attribute must return the label of the object’s corresponding track, if 
any. If the corresponding track has or had no label, the attribute must 
instead return the empty string.

)

(Note - section 3 of this spec version has some discussion on when the 
source is released to the application. This proposal only says that this 
also releases the label to view.)

This extension will allow:
- Untrusted applications to quickly determine whether a camera is 
present or not (satisfies the “does it make sense to offer video 
calling” requirement)
- Trusted applications to create in-app UI that presents a sensible list 
of devices for the user to choose between
- A clear definition of going from “untrusted” to “trusted”

Note: It may make sense to have the in-chrome user permission prompt 
give alternatives:
- “give access to all my cameras”
- “give access to one specific camera”
- “deny access”
It’s an UI design decision whether or not all these need to be offered; 
this shouldn’t be in the spec.

Received on Thursday, 21 March 2013 18:46:33 UTC