- From: andypaicu via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 May 2020 16:00:51 +0000
- To: public-webrtc-logs@w3.org
Also developers would have to keep track that they have requested PTZ and it was denied/unavailable since I suspect that they don't want to repeatedly run through that pattern whenever they might want to do something with `pan`,`tilt` and `zoom`. The fact that `pan`, `tilt`, `zoom` being undefined could either mean `you're denied/feature unavailable` or `you have not requested the permissions yet, give a try perhaps` makes writing the code somewhat cumbersome IMO. I suspect developers would end up doing something like this: ``` let pan = track.getSettings().pan; // undefined if (pan === undefined) { await track.applyConstraints({pan: true}); // permission elevation prompt pan = track.getSettings().pan; // actual value revealed (if supported) } let ptz_available = (pan !== undefined); // And from now on, rely on ptz_available instead of doing `pan !== undefined` ``` Of course, in contrast the other proposal also has downsides in terms of cumbersomeness since it will require re-calling `getUserMedia` and replacing your stream. But OTOH it means that `pan === undefined` will always mean `you're denied/feature unavailable` (in a stream that was obtained with a PTZ-enabling `getUserMedia` call). Mentally that makes more sense to me. Practically I don't know if any approach has a clear edge so at this point I'm happy either way. -- GitHub Notification of comment by andypaicu Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/223#issuecomment-630916839 using your GitHub account
Received on Tuesday, 19 May 2020 16:00:53 UTC