RE: Overconstrained tracks

As originally intended, track constraints could be layered on top of a "new" (uninitialized) track, prior to getUserMedia activation. Given that model, there was no distinction between "selection" and "modification" behavior of the constraints on a track. It's unclear to me if this initialization model for tracks is still desired (are we still interested in sync getUserMedia).

If we consider your suggestion (which I am not opposed to), then the behavior model for "selection" and "modification" start to diverge. I understand the merged model-I don't yet understand the split model, and that makes me concerned with adopting your proposal.
From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, February 6, 2013 8:43 AM
To: Martin Thomson
Cc: public-media-capture@w3.org
Subject: Re: Overconstrained tracks

+1

On Wed, Feb 6, 2013 at 8:40 AM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
Currently, the settings proposal includes a mechanisms where settings
changes and external events that cause a track to become
"overconstrained" also cause the track to be muted.

As we discussed at the meeting, I think that the track should continue
to flow in these cases.  In the case that new settings were not
successfully applied, there should be no change to the constraints on
the track and the event will indicate which of the settings caused the
problem.  In other cases, where external factors trigger the event,
the characteristics of the track might change, (not discussed) and the
event might indicate which of the existing constraints are no longer
being met.

If the application cares about having constraints being absolutely
mandatory, then it can listen for the overconstrained event and stop
using the stream.

--Martin