Re: Overconstrained tracks

On 02/06/2013 07:38 PM, Martin Thomson wrote:
> 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.)
That makes sense to me - if a track exists before getUserMedia 
(something I sometimes doubt), the track starts off in an 
overconstrained state, because it starts off with the constraint "you 
have to have media for this track", but we don't have any media. 
Selection is bringing it into a state where it's no longer overconstrained.
>
> 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 Tuesday, 12 February 2013 10:40:11 UTC