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

Re: [mediacapture-main] No way to reliably choose correct camera & microphone upfront (#656)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Thu, 16 Jan 2020 13:30:01 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-575151527-1579181400-sysbot+gh@w3.org>
> If it's wrong, you'll need to correct it after the fact.

Note that this might not be as big a deal as one might think.

First, the spec states that default devices should be preferred if possible and users would probably expect those devices to be used. I guess in most cases, these default devices are actually selected.

Second, this only happens for the first visit of a user to that website.
Afterwards, either the website or the browser could actually remember whose devices are captured.

> **Proposal C:** Same as B, but with new method:

It seems to me a picker based API is different from a permission request API as is somehow getUserMedia.
A new API might be a better fit and would not need to be consistent with the permission request API.
The role of the constraints mechanism becomes very important for the selection of the device.
Do we want exact/ideal distinctions?
Do we want to allow a web page to say something like "I really want audio and if possible, camera as well, from the same grouped device if possible"?
How do we handle exposing newly plugged-in devices and whether site should call again the API or not?

Also, a new API for roughly the same functionality of an existing API needs a good transition plan to deprecate the existing API.
I guess we could weaken progressively the power of getUserMedia to induce transition to the new API, something like only capturing with default devices.

GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/656#issuecomment-575151527 using your GitHub account
Received on Thursday, 16 January 2020 13:30:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:36 UTC