- From: Eero Häkkinen via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Sep 2020 07:42:32 +0000
- To: public-webrtc-logs@w3.org
> > 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.
True and false do not mean the same thing. Both `{pan: true}` and `{pan: {}}` causes PTZ permission to be requested and pan to be exposed in `track.getCapabilities()` and in `track.getSettings()` while `{pan: false}` does not.
From the spec: Any algorithm which uses a MediaTrackConstraintSet object and its pan dictionary member which exists after a possible normalization MUST request permission to use a PermissionDescriptor with its name member set to camera and its panTiltZoom member set to true, and, optionally, consider its deviceId member set to any appropriate device’s deviceId.
> > 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.
Does it? Below you say that in the Chromium implementation pan/tilt/zoom has been treated as a single hardware capability so in essence Chrome request and a hardware support for _some_ PTZ property (pan, tilt or zoom).
> > > > 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.
True.
> > 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.
At least there are cameras which are capable to zoom but not capable to pan or tilt so might be useful to treat them as separate capabilities.
I have no data to compare popularity of PTZ cameras, zoom cameras and normal cameras, though.
> 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?
In the first place, the purpose of the boolean is to allow to request PTZ permission without forcing any movement to a particular setting.
Selection of a PTZ-capable camera is also very useful. I am just not sure if it makes sense to implement that in a way there only PTZ constraint precense in the basic set become required capability constraints while all other constraints in the basic without explicit 'exact', 'min' or 'max' are non-required constraints.
--
GitHub Notification of comment by eehakkin
Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/256#issuecomment-690054588 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 September 2020 07:42:34 UTC