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

> > > I think evidence of poor web compat points to browsers not following the algorithm.
> > 
> > 
> > The spec should first define a precise and unambiguous algorithm. This is not yet the case.
> 
> @youennf The [SelectSettings](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-selectsettings) _algorithm_ **is** precise if you follow it. I'm all for tightening the _SHOULD_ to a _MUST_, if you think we gave user agents too much rope to not follow it.
> 
> In any case, it would seem adhering to the algorithm is the answer to web compat, not the problem.
> 

I think it's part of the answer. Another problem is that for requests that are not very constrained (e.g., unconstrained or wide min/max ranges) and without ideal values, implementations are allowed to select any setting that satisfies the constraints. Since lots of different values are allowed, browsers break this tie using different criteria. This is not bad, since different browsers can have very good reasons to choose different defaults, but it leads to different results.
Maybe the spec can suggest some implicit ideal values for some properties? 

> > 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.
> 
> @guidou While implementations are free to make such assumptions, I see no need to cement them in the spec¹ or contort the API over them. It seems cleaner in the abstract for apps to ask for what they want based on their needs, and not make cross-feature assumptions.

I agree. But I was referring more to the point that having a separate single boolean constraint (e.g., ptzAbility or similar) wouldn't allow zoom-only, or pan-only, or tilt-only selection, to which the reply is that there should be separate constraints for that, and that this is orthogonal to the permission.
Anyway, I think all three approaches are valid (separate bool constraints, syntactic sugar, and combined bool-double constraints). Of the three, I think the separate constraints is probably the most confusing for users, the combined bool/double is the most expressive (as long as we specify true to mean having the capability and false as not having the capability), and the syntactic sugar is easier to implement, but with more potential for confusion (is true required or best effort?, what if I want the other?).
Based on the priority of constituencies you cited, I'm inclined to go for the combined bool/double constraint, provided the bool values are defined as I indicated.
The permissions considerations can be discussed separately in the spec and it shouldn't be particularly different from the normal camera permission. Simply, if SelectSettings selected a camera with any of the PTZ capabilities, and that capability was requested (by having any of pan, tilt, zoom present in a non-ignored constraint set in the request), the PTZ permission should be requested.

> @eehakkin I find the separate `panTiltZoom` boolean constraint above semantically redundant and confusing (is it needed? What happens if I omit it?) On ergonomics alone, option 3 seems a superior way to express the above²:
> 
> ```js
> navigator.mediaDevices.getUserMedia({video: {pan: {exact: 0}, tilt: {exact: 0}}});
> ```
> 
> ...or if I don't want to set values (for the same impact on fitness distance):
> 
> ```js
> navigator.mediaDevices.getUserMedia({video: {pan: {exact: true}, tilt: {exact: true}}});
> ```
> 
> 1) We combine them only in the permissions-space, where I think it makes sense since the trio shares similar privacy concerns.
Agree

> 2) Note this assumes we specify that `0` values are not satisfied by non-panable, non-tiltable cameras.
Agree that the spec should say this.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/256#issuecomment-689834947 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 21:36:17 UTC