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

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 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.

> 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:13:37 UTC