- 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