RE: problem with constraints algorithm

I hope I can understand the problem with the following example, where track T1 fails the optional constraint O1 and T2 passes O1 but fails O2:

	O1	O2
T1	0	1
T2	1	0

In this case, the algorithm rolls back O2 and returns {T2}.

However, the selected track may skip high priority constraint. For example, the algorithm returns {T1} even though T1 does not satisfy O2:

	O2	O1
T1	0	1
T2	0	0

If this is the algorithm we want, it can be described in an abstract way that's independent of implementations:

Given a set of candidate tracks Ti, and an ordered list of optional constraints Oj, let m(Ti,Oj)=1 if Ti matches Oj and 0 otherwise.
Let m(Ti)=the binary number formed by m(Ti,Oj) for all Oj.
Select all Ti whose m(Ti) are the greatest (ties permitted).

Thanks.
Li

-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Wednesday, July 18, 2012 11:22 AM
To: public-webrtc@w3.org
Subject: 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 Thursday, 19 July 2012 16:34:56 UTC