Clarify pan/tilt/zoom capabilities and settings (#245) #248
Conversation
| <dd>This reflects the current <a>pan</a> setting of the camera.</dd> | ||
| <dd>This reflects the current <a>pan</a> setting of the camera. | ||
|
|
||
| If the track has been created without <a>requesting permission to use</a> (as defined in [[!permissions]]) a PermissionDescriptor with its name member set to {{PermissionName/camera}} and its {{CameraDevicePermissionDescriptor/panTiltZoom}} member set to true or if that permission request is denied, the track does not support <a>pan</a>. |
There was a problem hiding this comment.
It seems checking the permission value at the time getSettings is called is sufficient.
Why adding a check for the permission at the time the track was created?
There was a problem hiding this comment.
This PR does not add a check for the permission at the time the track was created. That check already exists in the spec. So reusing the result of that check (or the fact that the check was skipped because PTZ was not requested) seems sufficient.
Checking the permission value at the time getCapabilities or getSettings is called breaks the developer assumptions that availability of capabilities and settings do not change during track life time (like it is common to create UI components and their event listeners based on capabilities when the track starts).
I also think that PTZ capabilities and settings should not suddenly appear to non-PTZ tracks just because the origin gains PTZ permission through another getUserMedia call during the life time of the non-PTZ track.
What happens if the PTZ permission is revoked is more interesting. One option is that the track could be ended (in which case getCapabilities and getSettings do not have to check permissions). The second option is that the settings would not be updated after the revocation (in which case getCapabilities and getSettings again do not have to check permissions). The third option is that PTZ capabilities and settings would be removed (but would that require some kind of event so that the web page could listen for that event?).
There was a problem hiding this comment.
Let's continue this discussion at #249
| <dd>This reflects the <a>pan</a> value range supported by the UA and by the track. | ||
|
|
||
| If the track has been created without <a>requesting permission to use</a> (as defined in [[!permissions]]) a PermissionDescriptor with its name member set to {{PermissionName/camera}} and its {{CameraDevicePermissionDescriptor/panTiltZoom}} member set to true or if that permission request is denied, the track does not support <a>pan</a>. | ||
| In that case the UA MUST NOT expose the <a>pan</a> value range.</dd> |
There was a problem hiding this comment.
I would split this PR in two, one for getSettings and one for getCapabilities.
This change would disallow some step-by-step permission flow (first request camera permission, then request PTZ permission if PTZ support)
There was a problem hiding this comment.
I will two separate PRs.
The idea (and way it is currently implemented in Chrome) is that capabilities are guarded by the PTZ permission so that PTZ ranges cannot be used for fingerprinting without explicit permission grant.
There was a problem hiding this comment.
Let's continue at #250
This CL mandates PTZ capabilities and settings must be sanitized based on permission.
I hope that this clarifies the issue.