- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Mar 2020 09:07:54 +0000
- To: public-webrtc-logs@w3.org
Right, this is precisely why I want some experimentations and experimentation results before defining a new API/new API model. This will allow us to make sure we are all comfortable implementing the new model. And to decide whether this is a whole new model or not from getUserMedia as well. In general, I see constraints as a way to help the user agent pick the default selected devices presented to the user. That is all, maybe also rank the devices but I think this will be counter-intuitive to user. It does not seem to make sense to allow camera and microphone selection but only a subset would actually be selectable by the user. If a user wants to select microphone and not camera, user should have the choice. In that sense, this is not Audio&Video, but Audio|Video that constraints would end up defining. Or maybe we should have an API for microphone and a separate API for camera? I also do not really like the model of a prompt that would happen or not based on what the web page would provide as input. If a webpage says it wants the default camera and default microphone, why shouldn't the user be allowed to override this selection with different devices, or say no to camera but yes to microphone? I guess there might be some latitude here for heuristics based on page capture history, but the whole story is not clear to me. And I am unclear as to whether the spec will provide guidelines/requirements in that area as well/ -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/669#issuecomment-601598068 using your GitHub account
Received on Friday, 20 March 2020 09:07:56 UTC