Re: How to handle known but unsupported constraints

On 12/16/2015 11:28 AM, Adam Bergkvist wrote:
> On 2015-12-16 09:56, Dominique Hazael-Massieux wrote:
>> On 16/12/2015 09:50, Adam Bergkvist wrote:
>>
>>> I'm leaning towards treating known but unsupported constraints/features
>>> the same as "future constraints". That would mean that if a constraint
>>> name is present in MediaTrackSupportedConstraints, it's not only that
>>> the browser won't ignore that constraint if used, but it can also do
>>> something useful with it and not only report that it's always turned off.
>>>
>>> What do you think?
>> It was designed that way, and I think it has to be that way; while in
>> the case of echo cancellation, it could be argued that always answering
>> false is OK, what would be the equivalent for frameRate or width?
> If only one frameRate and resolution (width) is supported, it's 
> interesting to know the exact numbers from the capabilities. The 
> question is if the same applies to a toggle on/off feature like echo 
> cancellation.
>
> /Adam
>
About echo cancellation specifically:

There are devices that have echo cancellation in hardware that can't be
turned off by the application.
It's not 100% clear that the application (browser or non-browser) will
always be able to know that, but reporting it should be allowed.

About the issue of what to do about known constraints that you can't do
anything with:

There's a difference between "unknown" and "known but supported" that I
found while coding support for the new-style constraint:

getUserMedia({video: {width: 477}}) will return something sensible (the
browser knows "width")

getUserMedia({video: {with: 477}}) will be quietly ignored (the browser
doesn't know "with")

getUserMedia({video: {width: "foo"}}) will return "TypeError" (the
browser knows it should be integer or dictionary)

getUserMedia({video: {with: "foo"}}) will be quietly ignored (the
browser can't know whether a future constraint of that type should be
integer or string, so ignoring it is the future-safe option)

So it's entirely correct, and makes a difference to the user, that the
browser should report "echoCancellation" in
mediaTrackSupportedConstraints - it informs the user that if he sends in
a syntactically incorrect constraint for "echoCancellation", it will be
rejected.

Not that it matters a *lot*, but it does constitute an observable
difference in behavior.

Received on Wednesday, 16 December 2015 13:03:16 UTC