W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > March 2020

Re: [mediacapture-main] "user-chooses": Does required constraints make any sense now? (#669)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Thu, 26 Mar 2020 22:12:44 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-604714456-1585260763-sysbot+gh@w3.org>
Maybe we are trying to fit too many things in a single getUserMedia method.

The main/sole use case for MediaDeviceInfo.label is a a web-based device picker.
Given labels are only available after page starts to capture, what we might actually want is a way to change the device being used for a given live capture track.
We could use a browser picker that could already be in use and invocable from browser UI, similarly to what Chrome is apparently implementing for getDisplayMedia. 

If we attach this API to a MediaStreamTrack, we could add a new API or try extending applyConstraints, given it can potentially already be used to switch between user and environment cameras. We probably want user activation whenever changing the device.

This would also be conceptually consistent with what we are trying to do for speakers, where speaker authorisation is a simple user click, and, in the case user wants to change the selected speaker, a new API would trigger a browser device picker.

As an extra bonus, no new track means no need to call replaceTrack, update MediaStreams, WebAudio nodes... This might simplify things for web developers.

One potential worry is the handling of cloned tracks. Maybe that would be the web app job to update any cloned track with the newly selected device (no user prompt needed here, could be done with applyConstraints).

GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/669#issuecomment-604714456 using your GitHub account
Received on Thursday, 26 March 2020 22:12:47 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:50 UTC