- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Sep 2020 03:23:27 +0000
- To: public-webrtc-logs@w3.org
Subsequent calls to `getUserMedia()` is part of the problem, along with
> Although the spec does not require it, I think getUserMedia({ video : { deviceId: 'xyzxyzxyzxyz' } }) browser current implementations will always pick the device with the corresponding id, if the device is there and functional.
where the corresponding `deviceId` does not necessarily mean the device intended to be selected, e.g., Chromium label `"audiooutput"` where audio output capture is not supported at Linux.
As suggested, the user needs to be able to select devices before `getUserMedia()`, and have clear and unequivocal notification of the device being capable of being captured by `getUserMedia()` or `getDisplayMedia()`.
For that reason the order needs to be `enumerateDevices()` first, then `getUserMedia()`, where if the device the user intends to capture is not available per implementation, then the user need not even proceed with any code related to `getUserMedia()` at all, where the result will be for naught in any event if the device intended to be captured is not accessible. Thus, resulting in the same issue regarding having to call `getUserMedia()` - and potentiall call `MediaStream` and `MediaStreamTrack` processing code as well, only to find that is not the device intended to be captured. `enumerateDevices()` => `getUserMedia()`, is a substantive change that will provide clarity as to which devices are available and whether to continue or not with further code that coud ultimately be futile.
--
GitHub Notification of comment by guest271314
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/709#issuecomment-686227096 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 September 2020 03:23:29 UTC