W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2013

RE: An alternate approach to enumerating devices

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 21 Mar 2013 19:08:29 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B3853C4F063@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:15 UTC