- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Mar 2025 15:48:43 +0000
- To: public-webrtc-logs@w3.org
@guidou, going back to the scenario you mentioned, it seems web apps can already implement this scenario while respecting the spec as @fippo mentioned above: 1. web app checks permissions and validates that permissions are granted 2. web app checks that devices are available via enumerateDevices. 3. web app populates UI to allow enabling camera/microphone Then, when user wants to enable camera or microphone, web app has to call getUserMedia. It can happen either: 4a. At startup time, web app then quickly closes the tracks but has the list of devices 4b. When showing the in app picker, for instance with a self preview Looking at Zoom, there is no issue for microphone: enabling audio playback will trigger microphone usage. For camera, I can see at least two options: - Zoom implements either 4a or 4b. - We relax the spec to allow enumerateDevices to return a whole list of devices in case there is a successful getUserMedia call and permission is granted for the other device type. I have not tried Dialpad which seems to be doing 4a. I am unsure whether above relaxing rule would fix their issue. I can also see that native Webex allows to start with microphone and camera muted, but will still trigger the microphone capture indicators on macOS. This leads to two thoughts: 1. Above relaxing rule might, in practice, be good enough to fix the issue for cameras while preserving users's privacy. 2. Stating that camera/microphone quick usage to get the list of devices is against user preference is untrue, for Webex users at least. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1019#issuecomment-2761742862 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 28 March 2025 15:48:44 UTC