RE: problem with constraints algorithm

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 Tuesday, 10 July 2012 20:48:03 UTC