Re: [mediacapture-main] How should applyConstraints deal with constraints from other tracks sharing the same source? (#465)

> It is possible that the existing official description in the specification does not adequately reflect this behavior

I believe the [existing prose](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-applyconstraints-algorithm) adequately represents the original intent here, including the advanced constraints filter: *"The User Agent MAY choose new settings for the constrainable properties of the object at any time. When it does so it ***MUST attempt*** to satisfy ***all*** current Constraints, in the manner described in the ***algorithm above***."*

The _"algorithm above"_ is effectively the [SelectSettings](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-selectsettings) algorithm, which contains:
1. filtering by mandatory constraints (_"the set ... for which the fitness distance is finite"_)
2. pruning by advanced constraints (_"If the fitness distance is finite for one or more"_), and
3. prefer ideal (_"The UA SHOULD use the one with the smallest fitness distance"_)

...in that order.

_"MUST attempt"_ is key here, because while step 1 defines the envelope of settings dictionaries available to the user agent, step 2 by design cannot constrain to zero, but instead produces different results in the face of conflict depending on the order in which multiple concurrent constraint sets are addressed.

Both the original prose and the new prose preserve these steps, but neither say more about in exactly what order concurrent constraints are to be applied, leaving to user agents to attempt any order that produces a pleasing result.

I think leaving this to user agents is fine, and consistent with ideal constraints which similarly have an algorithm with the UA as tie breaker ("SHOULD").

Closing this as no change needed.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/465#issuecomment-577455531 using your GitHub account

Received on Thursday, 23 January 2020 00:50:49 UTC