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