- From: Daniel Burnett via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Sep 2016 08:14:32 +0000
- To: public-media-capture-logs@w3.org
I can see your concern with "other requests" in Harald's statement. It is definitely the case that applyConstraints should never itself be able to cause OverconstrainedEvent on any track. However, SelectSettings should take into account other active constraints for the source. Say that in a world with only one constrainable property we have track A with constraints that allow for a setting of either 1 or 2 to satisfy the constraints and the UA chooses a setting of 1. Now we add track B with constraints that allow only for a setting of 2. In this case the UA should change the source to setting 2, affecting both track A and track B. If we then add track C with constraints that allow only for a setting of 1 or 3, it should be rejected (even though track A could have accepted this). Then let's say setting 2 becomes impossible due to environmental changes or other changes to the source availability or configurability due to changes outside the control of the UA. At that point track B should receive an OverconstrainedEvent and the source should be changed to setting 1, affecting track A. I believe that this sequence works equivalently when multiple constrainable properties are involved. If we are agreed on this behavior, then we just need to figure out how to adjust the spec wording to match. -- GitHub Notification of comment by burnburn Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/394#issuecomment-248542399 using your GitHub account
Received on Wednesday, 21 September 2016 08:14:49 UTC