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

I recently gave a presentation on the history of constraints and how they ended up the way they are now.[1]  The original text we had was close to the current text that says 

> The behavior is as follows: all 'min', 'max', and 'exact' constraints in the basic Constraint structure are together treated as the 'required' set, and if it is not possible to satisfy simultaneously all of those individual constraints for the indicated property names, the User Agent MUST reject the returned promise. Otherwise, it must apply the required constraints. Next, it will consider any ConstraintSets given in the 'advanced' list, in the order in which they are specified, and will try to satisfy/apply each complete ConstraintSet (i.e., all constraints in the ConstraintSet together), but will skip a ConstraintSet if and only if it cannot satisfy/apply it in its entirety. Next, the User Agent MUST attempt to apply, individually, any 'ideal' constraints or a constraint given as a bare value for the property. Of these properties, it MUST satisfy the largest number that it can, in any order.

The current selectSettings text was written in an attempt to unify the selection of getUserMedia() with the application of applyConstraints(), but the spirit of the original text may have gotten lost in the process.

When combined with the "you are not allowed to make another track unconstrained" rule that @jan-ivar mentioned and the (original and supposedly-still-present) rule that advanced constraints MUST be satisfied if they can be, making them technically optional but not disregardable, @jan-ivar is correct that in your example T2.applyConstraints() will fail if B2 would make B1 impossible to satisfy.  Beyond that, it is browser choice as to which of the original advanced constraints from T1 and which of the advanced constraints in T2.applyConstraints() to apply, except that, when done, if one of the advanced constraints remains unsatisfied that could be satisfied without invalidating any of the other applied basic or advanced constraints from either track the browser has failed to meet the intent of the algorithm.

It is possible that the existing official description in the specification does not adequately reflect this behavior, but if so we would need specific text suggestions on how to adjust it.  It is definitely unfortunate that the current official text is so different from the original "spirit of" description.

[1] [Slides](https://www.slideshare.net/AmirZ/webrtc-standards-implementation-qa-webrtc-constrains) and [Video](https://www.crowdcast.io/e/webrtcstandards19)



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

Received on Tuesday, 10 October 2017 12:20:25 UTC