Re: An alternate approach to enumerating devices

On 03/21/2013 08:08 PM, Travis Leithead wrote:
>> 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

Yep. I wanted to make sure we didn't lose it again, so thought I'd call 
it out.

>
>> - 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?

The critical text is this:

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.


That is, if the user granted you permission to grab a camera, you see 
its label; if the user hasn't granted you permission to grab it, you 
don't see it - you just know it's there.

I think a likely UI is that the question asked at first request time 
will be "Do you want to grant <origin> access to your cameras?" with an 
"options" pulldown to allow access to features like "my front camera but 
not my back camera"; in that case, the browser will record that it has 
full permissions to all the cameras, and populate the whole list.

("cameras and microphones" at appropriate places above, of course)

Received on Thursday, 21 March 2013 19:42:49 UTC