- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 16 May 2013 13:39:09 +0000
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 5/15/13 3:02 PM, Harald Alvestrand wrote:
> Hello,
>
> I just want to verify something....
> in the "device info" proposal we agreed to earlier, the following static
> method is added:
>
> 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
> }
>
> One thing this allows is to get the list of all valid sourceId values.
> But it gives more information than that, on a per-device basis.
>
> This has not yet been added to the draft.
>
> The capabilities() call in the latest editors' draft also gives the list
> of all valid sourceId values, but in a slightly different context:
>
> interface MediaStreamTrack : EventTarget {
> ....
> (AllVideoCapabilites or AllAudioCapabilities) capabilities ();
> ....
> }
>
> dictionary AllVideoCapabilities {
> CapabilityList? sourceType;
> CapabilityList? sourceId;
> CapabilityRange? width;
> CapabilityRange? height;
> CapabilityRange? frameRate;
> CapabilityList? facingMode;
> };
>
> This gives all possible values of sourceId as well as facingMode, but
> doesn't match them up - you can't tell from the fact that "front" and
> "back" are present in the capabilities which sourceId belongs to which
> camera.
The way I read the document, it gives the values for the source of the
MediaStreamTrack, not all sources. So I think they are a bit different
really.
>
> Two possible directions to go in:
>
> - No change. Just add the getSourceInfos call as described, and keep the
> capabilities() as is - separate.
> - Modify the capabilities() call to return a structure more like
> SourceInfo, where the capabilities of each individual device are
> enumerated separately - effectively, merging the two functionalities.
>
> This moves the target of capabilties() somewhat - from describing what
> the legal ranges of constraints are to describing what acceptable ranges
> of constraints on specific devices are.
>
> By nature, I'm conservative, so I'd prefer the first alternative. But
> I'm only one participant.
>
> What do people think?
>
> Harald
>
>
>
Received on Thursday, 16 May 2013 13:39:40 UTC