- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 25 Mar 2013 09:44:38 -0700
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
We have agreement that constraints can be changed on a track without destroying the track if they overconstrain it. This isn't really made clear in the current draft. There's a lot of missing detail. Whatever happens, we need to decide what happens to constraints prior to successful application, and after a failed application. We need to be very clear on what information is exposed by constraints(), getConstraint(), etc... at these points. As a proposal, I'd like to see the old constraints exposed (the pending constraints are presumably available to the application during this time). Otherwise, pieces of the application that care about getting a clear view of the track state will get a misleading impression. Once applied successfully, the values exposed by constraints() can be updated. If application of constraints fails, the failed constraints should be passed through on the 'overconstrained' event. We have to decide if the optional constraints apply even if the mandatory ones can't be applied. I have a separate proposal on that.
Received on Monday, 25 March 2013 16:45:11 UTC