Re: [Bug 23820] New: Add special values for PropertyValueRange to enable preference specification in optional constraints

On 20/11/13 19:13, Martin Thomson wrote:
> On 20 November 2013 09:59, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> I agree, but should it lie also when I check the settings of the
>> Constrainable it implements?
>
> I think that the settings should reflect the settings that were set.
> That is, if you asked for 1024, then you are "getting" 1024, whatever
> optimizations might be going on.  Keep in mind that these are just
> optimizations, what you have asked for and what you are getting should
> still be there.  (If the browser can't bump to 1024 instantly when you
> resize the video element, then it probably shouldn't be optimizing so
> aggressively.)
>
>> And in general: if I use constraints with gUM, would those also be
>> applied to the tracks, or just used to select devices? I.e., if I read
>> out the Constraints, would I get an empty set, or the one used with gUM?
>
> My expectation was that selection constraints for gUM turn into
> constraints/settings on the tracks that gUM provides.  If that isn't
> the case, then there isn't really anything holding the tracks back
> after consent is granted.  If you request 720p min, get it, then
> discover that the browser has forgotten about the constraint and
> starts to feed you QCIF, then we lose all sorts of guarantees.

I'm really fine either way, but it should be spelled out in the document 
(I can find no language about it currently).

>
>> I sort of prefer to get the unconstrained track (but knowing what it can
>> do) back - but can't really motivate well why.
>
> If you want unconstrained, then feel free to change the settings once
> you obtain a track.  Now that the source can't change, that should be
> good.

Yes (but that is one update that is missing in the draft yet - it still 
has the language about the UA being able to switch source).

>
>> I'm not sure the set of constraints that can be used at gUM time is
>> exactly the same as later. E.g., facingMode could be crucial when
>> selecting device, but not later (because you can't change it).
>
> Facing mode, device identifier, and maybe others do become fixed when
> a device is selected.  That's always true.  But I'd rather treat these
> the same as every other setting and fire overconstrained errors rather
> than bifurcate the logic further.
>

Received on Wednesday, 20 November 2013 18:32:40 UTC