Re: An alternate approach to enumerating devices

This is good. In addition, I would like to add 

1) a callback when a new camera or source gets added so I don't have to find out by polling this 

2) facing is too limited. I want just a camera adescription enum that includes front and back but also has left, right, center



On Mar 21, 2013, at 12:46 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

> 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 Friday, 22 March 2013 12:43:35 UTC