I use an Elgato Cam Link 4K capture stick as video input source and it works fine in this WebRTC demo (the permissions door hanger properly shows it as video and audio input device):

https://webrtc.github.io/samples/src/content/devices/input-output/

However, on https://meet.jit.si/test I only get it as an audio input, not as a video input (it is simply missing from the video input list, showing only internal camera). The same site works in Chrome with the same video input.

Hi Christian, I suspect this is bug 1286945.

Could you try selecting your camera in https://jsfiddle.net/jib1/3kvb7j9o/ and moving the height slider slowly up and down (pausing at times) to discover what resolutions Firefox is able to get from it?

From a MOZ_LOG=MediaManager:5 mach run it appears jitsi is using max constraints to limit resolution, which due to bug 1286945 will exclude cameras from the list that aren't able to meet the resolution requirement natively (without downscaling).

[Child 96806: MediaSupervisor #1]: D/MediaManager Constraints: {
[Child 96806: MediaSupervisor #1]: D/MediaManager   width: { min: 320, max: 1280, ideal: 1280 }
[Child 96806: MediaSupervisor #1]: D/MediaManager   height: { min: 180, max: 720, ideal: 720 }

Tried this and the selected default resolution was 1920 x 1080. I tried other heights such as 720 or 2160 but none of them worked. It would just show some green jitter, then reset back to 1920 x 1080. Any resolutions in particular that I should test other than the ones named?

On the investigation of this issue, the major difference between the behavior seen in Firefox (latest release/nightly) versus the one seen on Chrome: it appears that Chrome offers permission to all connected webcams AT ONCE, while Firefox needs to allow permission for ONE AT A TIME.
Firefox CAN allow both cams in one call (or profile used) but the behavior can appear a little confusing in combination with Jitsi's UX.

Jitsi allows the user to open a dropdown with both live video input streams, so he can select one or the other. In a normal situation, a firefox user has only allowed one of them when he joined the call, so when he opens the drop-down, another permission door hanger is triggered, for the other webcam that is already connected to the system. If the user allows this second video input permission door-hanger, then closes and reopens Jitsi's stream selection drop-down, both streams are properly working and can be correctly switched.

While reading jib's comment 1, he suspects that this issue could be caused by different resolutions of the input streams, so if I understand correctly, to test your original issue properly, I might need 2 video input sources that have different resolutions (OR different aspect ratios?!). Is that right? (Ultimately we would need a quality camera and the Elgato cam link 4K to investigate it)

Using my setup, the integrated 1080 camera of a Dell G5 laptop and the external Logitech C920 1080 webcam displayed ad selectable in Jitsi webrtc calls, as expected. Tested with Ubuntu 22 and Mac OS 11.

@jib: Please advise how we should address this further, if still necessary.

P.S. I could not reproduce any suspecting behaviors using the test pages, either:
https://webrtc.github.io/samples/src/content/devices/input-output/
https://jsfiddle.net/jib1/3kvb7j9o/

(In reply to Christian Holler (:decoder) from comment #2)

Tried this and the selected default resolution was 1920 x 1080. I tried other heights such as 720 or 2160 but none of them worked. It would just show some green jitter, then reset back to 1920 x 1080. Any resolutions in particular that I should test other than the ones named?

This confirms my suspicion. The camera's only resolution 1920x1080 falls outside of Jitsi's constraints, so Firefox doesn't list it.

(In reply to Bodea Daniel [:danibodea] from comment #3)

... Firefox needs to allow permission for ONE AT A TIME. Firefox CAN allow both cams in one call (or profile used) but the behavior can appear a little confusing in combination with Jitsi's UX.

This seems a separate issue which I've filed bug 1781918 on.

I should add that Jitsi could solve this by removing their max constraint, and using scaleResolutionDownBy, either as a workaround for Firefox or as a general improvement (higher resolution self-view in lobby)

Hi Nils, just wanted to make you aware of this issue. What do you think about comment 5?

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #6)

Hi Nils, just wanted to make you aware of this issue. What do you think about comment 5?

Thanks for the NI. I'll say that droping the max from our gUM code and an alternative on the PeerConnection is a pretty big change (that probably doesn't qualify as a fix for Firefox anymore). So I'll have to check what/if we can do about it.