- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Sat, 05 Sep 2020 08:04:02 +0000
- To: public-webrtc-logs@w3.org
> The issue here is that if a wrong camera is opened, or a wrong setting is used, re-open/update it is very costly.
Opening a wrong camera is slow and painful.
Ideally, applyConstraints would fix all issues with wrong settings but there are indeed system limitations that may trigger LED blinking for instance.
> * opening a camera is a slow operation and might pop-up a dialog every time
> * blinking wrong camera LED is bad UX
exact deviceId contraints should prevent that (both prompt and LED).
If deviceId is not matching, the exact constraint will make the getUserMedia call fail quickly (assuming user agent enumerated camera devices already) without a camera LED blink.
Do you know of configurations where this is not the case?
> * The app would need to try `getUserMedia({video: A + X})` and `getUserMedia({video: B + Y})`, which is far from ideal imo.
Let's say page sets A and B as exact deviceId constraints:
- If A is there, the first getUserMedia call resolves and page can start using it.
- If A is not there, the first getUserMedia call will reject quickly (no prompt, no LED, no device opened).
- If B is there, the second getUserMedia call resolves and page can start using it.
- If B is not there, the second getUserMedia call will reject quickly
- Page calls getUserMedia({ video : true }) to try getting a video stream
Would that work for your use case?
Do you know of configurations where this approach would be slower?
--
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/709#issuecomment-687569461 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 5 September 2020 08:05:21 UTC