RE: An alternate approach to enumerating devices

> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> 
> ...
> 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.
> 
> ...
> 
> 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)

This requirement is not uniquely satisfied by this extension--it was already satisfied by what is in the current draft with getSourceIds

> - Trusted applications to create in-app UI that presents a sensible list of
> devices for the user to choose between

It definitely improves this scenario (the addition of 'facing' is the value-add)

> - A clear definition of going from "untrusted" to "trusted"

I don't follow this?

 
> 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 19:09:16 UTC