Re: getDeviceInfos and capabilities()

On 5/16/13 9:04 PM, Jim Barnett wrote:
> 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)?

To me, that seems like a good approach. Stefan

>
> 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 Friday, 17 May 2013 07:34:43 UTC