Re: Overconstrained tracks

I think that you could model selection and modification to be the same...

That is, you could consider the action that occurs at getUserMedia to
be the application of settings, where failure causes the current
constraints to be unchanged.  Since the state of the tracks prior to
gUM is disconnected, they would remain disconnected.  (Yes, this isn't
perfect for a few reasons, but that might help you reconcile your
mental model.)

The synchronous getUserMedia is still interesting to me.  There were
concerns raised yesterday about the reasons for the existence of the
mechanism, but that doesn't diminish my enthusiasm for it.

On 6 February 2013 12:06, Travis Leithead <travis.leithead@microsoft.com> wrote:
> 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>
> 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
>
>

Received on Wednesday, 6 February 2013 18:38:30 UTC