RE: getDeviceInfos and capabilities()

Wouldn't it be clearer to have a static method that returned information for all sources, and let the instance method return information only for the attached source (it should return nothing if no source is attached)?  

With the current semantics, if a source is attached, and the developer calls capabilities() and applies a constraints, will the UA switch sources if the constraints are satisfied by a source other than the attached one?  If it doesn't, the behavior is not consistent.  

- Jim

-----Original Message-----
From: Dan Burnett [mailto:dburnett@voxeo.com] 
Sent: Thursday, May 16, 2013 2:58 PM
To: Jim Barnett
Cc: Stefan Håkansson LK; Harald Alvestrand; public-media-capture@w3.org
Subject: Re: getDeviceInfos and capabilities()

Remember that a track can now be created explicitly, without being attached yet to a source.  capabilities() returns all possible capabilities for the type of track (audio or video).  It is, as Harald described, intended to match constraints.  It lists all possible capabilities of all devices together, out of which the app developer specifies the relevant constraints for his app, which causes the appropriate selection to occur.  I'm not necessarily arguing for this, just explaining the original intent and also that it is not a simple as you think to make it source-specific.

-- dan

On May 16, 2013, at 9:46 AM, Jim Barnett wrote:

> The phrasing in the current draft is a bit vague.  It says that capabilities():
> 
>    Returns a dictionary with all of the capabilities for the track 
> type
> 
> You could take this to mean that it returns all the capabilities of all sources that have the same type as the Track's source.  But if Stefan is right it means that it returns all the capabilities of the Track's source, where the type of the returned dictionary depends on the Track's type.  This is the more sensible interpretation, but it would be good to make the wording explicit.
> 
> - Jim
> 
> -----Original Message-----
> From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: Thursday, May 16, 2013 9:39 AM
> To: Harald Alvestrand
> Cc: public-media-capture@w3.org
> Subject: Re: getDeviceInfos and capabilities()
> 
> 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 19:05:07 UTC