Re: problem with constraints algorithm

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 Wednesday, 18 July 2012 15:22:52 UTC