- 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>
Hi 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