W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2015

How to handle known but unsupported constraints

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 16 Dec 2015 08:50:22 +0000
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B315889025E1D5AC@ESESSMB307.ericsson.se>

Let's start with the easy case - a constraint that will be added in the 
future. Present browsers don't now about it so it's not present in 
MediaTrackSupportedConstraints, MediaTrackCapabilities, 
MediaTrackConstraints nor MediaTrackSettings.

What about the case when a user agent can't support a technical feature 
that's described by one of the constraints from the initial set of the 
gUM() spec? For example, echo cancellation. Do we require that a 
compliant implementation must know about this constraint (have it in 
MediaTrackSupportedConstraints with default = true), but should return a 
single "false" as the capability (meaning that it can only be off), if 
echo cancellation isn't supported.

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?
Received on Wednesday, 16 December 2015 08:50:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 December 2015 08:50:55 UTC