Re: An alternate approach to enumerating devices

On 3/22/13 1:43 PM, Cullen Jennings wrote:
>
> 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

We have discussed this in the past, and to me it still seems sufficient 
if you can poll (check e.g. every 30 seconds).

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

For a first version, front and back seems sufficient to me. We can 
always add if we see the need.

>
>
>
> 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 Monday, 25 March 2013 13:17:59 UTC