Re: [mediacapture-image] Determine how PTZ permission prompts are supposed to work (#243)

> > maybe instead of saying "any algorithm", we could link to a specific section about gUM.
> 
> Yes, I would think it helps.

I'll work on this.

> > there's an [example in the spec](https://w3c.github.io/mediacapture-image/#example1)
> 
> I am not clear on whether it is possible for a browser to allow a user to say: yes for camera but no for PTZ in case of `getUserMedia({ video : { pan : true }})`?

Nope. With `getUserMedia({ video : { pan : true }})`, the website requests a camera PTZ. If there's none, it will fail.
However with `getUserMedia({ video: { advanced: [{ pan: true }] } })`, the website asks to prefer a PTZ camera during camera selection process. 

> If it is possible, is it mandatory for a user agent to support that or is it UX territory?
> If it is possible, how is the web page notified of the user decision (getCapabilities, navigator.permissions.query).

It could use the permissions API indeed. See below
```js
const panTiltZoomPermissionStatus = await navigator.permissions.query({
  name: "camera",
  panTiltZoom: true,
});
panTiltZoomPermissionStatus.onchange = () => {
  // User has changed PTZ permission status.
}
```

Using `"pan" in videoTrack.getCapabilities()` is also a reliable way to know if selected camera supports pan for instance.

> If it is possible, browser A supports it but browser B does not, web pages might be coded so that getUserMedia promise fulfilment means PTZ is granted for instance while this might not be true on all browsers, hence compat issues.

You would still use `getCapabilities()` and `getSettings()` to retrieve pan, tilt, and zoom values and display them in the UI.
This is why you should use `if ("pan" in navigator.mediaDevices.getSupportedConstraints())` to know if PTZ is supported by the browser first.

> If it is possible, we enter in UX that might ask variable questions like : camera-only, microphone-only, camera+microphone, cameraPTZ-only, cameraPTZ+microphone... This adds a lot of variability to the question asked to the user.

You can give a try to the Chromium implementation by running Chrome 86 with `--use-fake-device-for-media-stream`  and play with https://ptz.glitch.me.

> Another related question (maybe this is already clear in the spec). If PTZ is supported by the camera and page has a MediaStreamTrack, what would return capabilities.pan and applyConstraints({pan: xxx}) in the following cases:
> 
> * page did not ask for { pan : true } in getUserMedia
> * page asked for { pan : true } but user decided to only grant camera, not PTZ.

In both cases, `capabilities.pan` is undefined and `applyConstraints({pan: xxx})` rejects.
 
> The primer also says: "It will also be possible for users to revoke the PTZ permission by itself, while keeping the camera permission". Is there anything the spec should say about this case? For instance, in terms of what happens to live cameraPTZ track(s)? media capture main indicates (not very strongly though) that the live tracks get ended if permission is revoked.

We don't end live tracks for now, but that's something we could do indeed.
Where is it in the media capture main spec?


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


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

Received on Friday, 14 August 2020 09:36:20 UTC