- From: hills via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Sep 2020 17:35:29 +0000
- To: public-webrtc-logs@w3.org
> Not really, in step 4, you can check capture is using the device with the given id through the provided MediaStreamTrack.
I don't think its a good sign that a problem is introduced and now the solution is to use more API :)
> 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.
So you should be able to always stop at step 4.
"Should" and "always" are not compatible here :)
With the above clarification, developers will only act defensively, and are reduced to:
1. Device ID from a previous session
1. A dummy call to getUserMedia(audio: true)
1. Prompt the user, get it out of the way
1. close the device
1. now continue with the rest of the program as normal
And this _still_ provides a poor user experience requiring restarts if the primary device is unavailable. And it will be especially poor if any browser is prompting per-call to getUserMedia.
--
GitHub Notification of comment by hills
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/709#issuecomment-685889897 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 September 2020 17:35:31 UTC