add ability to specify constraints to enumerateDevices
Per discussion here https://github.com/ericblade/quagga2/issues/227
allow specifying constraints to enumerateDevices, so that if you are providing users a choice of devices, you can eliminate devices that don't fit constraints. Would probably be quite useful for eliminating wide-angle-only cameras.
Definitely. I'm struggling with this issue pretty hard right now with a variety of Android devices. In particular, the Galaxy 10 Series of devices have no obvious capability differences between camera sources.
I'm not sure when exactly I'm going to be able to get to this, but in the meantime, you could call getUserMedia directly with constraints to get a list of devices that support the given constraints, I think.
Unfortunately, while it's possible to query the browser for what it supports, it doesn't seem that there's any way to query the devices for what they support. So, I think the best one can do is give a range of possibilities that are acceptable, and then let the user make a decision if there's more than one device returned that support the given request.
And unfortunately, on all the Android devices I've tried, the cameras have empty name fields, or useless names like "camera1" unlike on PC, where they use the USB device name.
Another page that has a lot of good info https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API/Constraints
Perhaps implementing something like this could help us?
https://unpkg.com/browse/[email protected]/src/lib/cameraAccess.ts
That.. is a pretty comprehensive library. I'll presume that it's quite a bit newer than QuaggaJS :-)
I know you were just referring to their camera code, which is pretty thorough.. that could easily be extracted to an application that uses Quagga, and then you can use it to determine what camera you want to use with it, then pass the deviceId to quagga.
I suspect, though, that that library as a whole might be quite a bit better than Quagga. If so, it might be worth looking into it to see if it does location detection, and if not, then perhaps coupling Quagga to that with some reader glue.