Do we need an infrared constraint?

[jan-ivar]

Infrared cameras are common on phones, and are typically included in enumerateDevices() w3c/mediacapture-main#553.

They're rarely desirable except for special purposes, and browser vendors occasionally get bugreports where an infrared camera is chosen by default on some phones. The fix for dealing with them is usually to put them after the first non-infrared front camera and first non-infrared back camera in the list, and label them as " (infrared)".

But since they're special-purpose, should we let apps constrain them out, using e.g. {infrared: {exact: false}} (or in)?

[rahulsingh-msft]

We've had bug reports in Microsoft Edge(Chromium based) where the root cause was the websites picking the IR camera due to its facingMode: user. Given that IR cameras are only utilized for a few specific purposes, we would support an opt-in constraint to gate their inclusion in getUserMedia().

[jan-ivar]

websites picking the IR camera due to its facingMode: user

Were there no other front-facing cameras available?

An "opt-in constraint" would be a new concept that would challenge the model somewhat. Constraints constrain, they don't expand choices. E.g. would the device be listed in enumerateDevices?

[rahulsingh-msft]

I see your point! So, an opt-out constraint that allows websites to specify that they DON'T want IR cameras included in EnumerateDevices() would also work. Such a constraint would be useful in cases where the device label for IR cameras doesn't contain the substring 'IR'. Eg. the IR camera on a Surface Laptop 3 is labeled "AvStream Media Device". In such cases, websites can incorrectly pick the IR camera instead of the front facing RGB camera.