W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2013

Re: Applying constraints

From: Dan Burnett <dburnett@voxeo.com>
Date: Mon, 25 Mar 2013 13:11:46 -0400
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-Id: <8EB499D6-5133-4A56-A16A-9FB480320CB9@voxeo.com>
To: Martin Thomson <martin.thomson@gmail.com>

On Mar 25, 2013, at 12:44 PM, Martin Thomson wrote:

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

Agreed if mandatory constraints fail they need to be reported back.

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

This is an interesting question.  I have always assumed (based on constraints historically being used for track selection) that failure to apply one or more mandatory constraints resulted in no application of constraints.

Received on Monday, 25 March 2013 17:12:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:15 UTC