Re: problem with constraints algorithm

Harald, you are correct.  "Optional constraint" means that
a) it is not mandatory, so it is possible for a track to be returned that does not satisfy the constraint
b) if the constraint can be satisfied, it must be

The question then arises what to do when there are two or more mutually-incompatible constraints, where not all can be satisfied simultaneously.  This is what the ordering is for.
Priority ordering introduces the requirement that
c) if two constraints could both be satisfied but not simultaneously, then the one that comes first in priority order must be satisfied

Notice that condition c only applies if both can be satisfied.  Thus, in the original algorithm, if we encounter a constraint that cannot be satisfied by any remaining possible tracks we skip over it.

I believe the algorithm below describes the above 3 conditions accurately.  Because step 5 contains an implicit loop, the "candidateSet" is continually whittled down by constraints that can be satisfied.  As we encounter constraints that cannot be satisfied, we skip them because they have no effect on any of the three conditions I described above.

If there is a flaw in my logic here please let me know!

-- dan

On Jul 18, 2012, at 11:22 AM, Harald Alvestrand wrote:

> My problem with Cullen's note is that I've read it a couple of times now, and can't figure out what the change is - he describes the desired algorithm exactly the way I parsed the text that he says is wrong.
> 
> In particular, this paragraph:
> 
> 	3  If the secondPassSet is now empty, let the secondPassSet be
> the current contents of the candidateSet. Otherwise, let the
> candidateSet be the current contents of the secondPassSet.
> 
> 
> which I parse as
> 
>   if (secondPassSet.empty()) {
>      secondPassSet = candidateSet; // Restore secondPassSet to what it was before 5.2
>   } else {
>      candidateSet = secondPassSet; // Remember what we successfully reduced to
>   }
> 
> matches my parse of Cullen's language exactly.
> 
> Somewhere I must be parsing it wrong.
> 
>        Harald
> 
> 
> 
> 
> On 07/13/2012 08:34 PM, Cullen Jennings wrote:
>> makes sense … I don't see any reason not to apply all the constraints that can be satisfied even after a higher priority constraint fails.
>> 
>> On Jul 10, 2012, at 13:47 , Jim Barnett wrote:
>> 
>>> That seems right.  One question:  in that case (where an optional
>>> constraint has removed all the tracks), should  we proceed to subsequent
>>> constraints?  They are all lower priority than the one that just
>>> resulted in an empty track list.  I don't know how intuitive it is to
>>> skip a constraint and then apply a bunch of lower-priority ones.  It
>>> might be clearest to say that we go as far down the list of optional
>>> constraints as we can go (and still keep a non-null track list), and
>>> then stop.
>>> 
>>> In either case, the algorithm will need to keep track of the last
>>> non-null value of the secondPassSet.
>>> 
>>> - Jim
>>> 
>>> -----Original Message-----
>>> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
>>> Sent: Tuesday, July 10, 2012 4:16 PM
>>> To: public-webrtc@w3.org
>>> Subject: problem with constraints algorithm
>>> 
>>> 
>>> It currently says
>>> 
>>> 4 Let the secondPassSet be the current contents of the candidateSet.
>>> 
>>> 5  For each constraint key-value pair in the "optional" sequence of the
>>> constraints that are for the current media type, in order,
>>> 
>>> 	1  If the constraint is not supported by the browser, skip it
>>> and continue with the next constraint.
>>> 
>>> 	2  Remove from the secondPassSet any tracks that cannot satisfy
>>> the value given for the constraint.
>>> 
>>> 	3  If the secondPassSet is now empty, let the secondPassSet be
>>> the current contents of the candidateSet. Otherwise, let the
>>> candidateSet be the current contents of the secondPassSet.
>>> 
>>> 
>>> 
>>> 
>>> But in 5.3, I think it should go back to what it was before 5.2 not what
>>> it was in step 5. Think of the case where an earlier constraint removed
>>> some but not all of the tracks. Then a later constraint removed all the
>>> tracks - it's the effect of the last constrains that we want to roll
>>> back.
>>> 
>>> If this does not make sense, I provide a more detailed example.
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
>

Received on Saturday, 21 July 2012 14:10:19 UTC