Re: [mediacapture-image] Clarify meaning of PTZ constraints presence (#256)

> But that is just a note. If that meaning is to be retained, it should be spelled out in the main descriptions and not only in a note.

Then it should be moved to be normative. Without that note, pan:true being equivalent to pan: {} is totally worthless and has no meaning since {} otherwise means unconstrained, which is largely the same as not saying anything, which is what pan:false is supposed to mean. if true and false mean the same thing, then there is no point in having a boolean.
This fact is what motivated the discussion in issue #225 and I thought the consensus was that pan, tilt and zoom were going to be treated in a special way so as to ensure that the presence of any of them, even if unconstrained (as in {}) meant that the constraint set  restricted candidates to those that could provide PTZ capability.

> Like that text does not say anything about that in this case an empty ConstrainDouble implies required hardware support for the property also in the basic set unlike in the case of all non-PTZ properties.
> 

> In addition, in Chrome, `{pan: {}}` does not imply required hardware support for pan but only a permission request and a hardware support for _some_ PTZ property (pan, tilt or zoom).
> 
Yes, it does. At least, that's what it did the last time I reviewed the code.

> > > Option 3 would add that with e.g. `{pan: {exact: true}}`, modulo whatever we come up with in #246.
> > > > Not sure if the extra complexity of allowing pan to be used this way or in the usual DoubleConstraint way is worth it over using a separate constraint for the PTZ capability.
> 
> Option 3 would allow a request to prefer a pan and tilt capable camera over a zoom-only capable camera using
> 
> ```
> navigator.mediaDevices.getUserMedia({video: {pan: true, tilt: true}});
> ```

That is correct. However, in the discussions I have seen (and in the Chromium implementation) pan/tilt/zoom has been treated as a single hardware capability. If that is not the case, then this should be clarified in the spec and, if possible in practice, also in the Chromium implementation.

> although the idea behind the true semantics is to able to avoid guessed defaults like `{ideal: 0.0}`.
>
There are no 
 
> With a separate constraint for the PTZ capability the former would remain impossible and the latter would remain the same or become
> 
> ```
> navigator.mediaDevices.getUserMedia({video: {
>     pan: {min: -180.0 * 3600, ideal: 0.0, max: 180.0 * 3600},
>     panTiltZoom: {exact: true},
>     tilt: {min: -180.0 * 3600, ideal: 0.0, max: 180.0 * 3600}
>     }});
> ```
>

That is an issue only if pan,tilt and zoom are independent hardware capabilities and you use a single constraint. If they are indeed separate, you need three separate boolean constraints. This is orthogonal to the permission (there are lots of other constraints for the regular camera permission, just like there can be three constraints for a single PTZ permission).
Also, in practice, if a developer uses a numeric constraint in a request, the boolean one becomes unnecessary since the numeric one already implies a request for the capability.
The only purpose of the booleans (as I understood it from previous discussions), no matter how we implement it (separate constraints, syntactic sugar, or combined bool/double), is to allow selecting a PTZ-capable camera without forcing any movement to a particular setting. Is this not the case?

-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/256#issuecomment-689756657 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 9 September 2020 19:04:12 UTC