Re: problem with constraints algorithm

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 Friday, 13 July 2012 18:34:29 UTC