Jitsi-meet: Improper camera enumeration

[ClausAndersen]

As my camera is working I decided no to add this to Meta - camera issues #5425. It is however in the same ballpark. Feel free to merge if applicable.

jit.si does a bad job of enumerating cameras. Google Meet and Skype Web works perfectly. Google Duo has almost the same problem as jit.si.

Tested with the current latest versions:
UVC driver by Microsoft version 10.0.18362.693
Chrome Version 81.0.4044.113 (Officiel version) (64-bit)

The "camera" is a Cam Link 4K HDMI->USB device getting 1920x1080 at 50 frames.

The device is using the latest firmware MCU: 20.01.20 / FPGA: 67

By itself it works flawless. There are huge audio/video sync issues which I do not see on any other platforms but this is besides the point for this issue. It works as a UVC webcam with the OS supplied driver (Windows 10).

I saw an occasional freeze so I decided to update to the latest firmware. To do that you install their 4K Capture Utility.

In my case this is 4K Capture Utility version 1.7.0.4587 and can be found at:

• Download page
• Direct download link

This tool also installs a virtual device Elgato Screen Link.

These are my personal assumptions:

• The virtual device presents itself as a UVC device
• The virtual device reports no resolution when not running
• Is enumerated before the Cam Link 4K

Uninstalling this device makes jits.si and Google Duo work. With the virtual device installed they do not. Google Meet and Skype Web both work in both cases. Even though the software is Elgato specific it seems like you would be able to install and reproduce without any physical Elgato device.

Permissions are set in Windows to allow camera access for Chrome and Firefox.

The following webrtc sites have access to microphone and cameras:
https://duo.google.com:443
https://meet.google.com:443
https://web.skype.com:443
https://test.webrtc.org:443
https://meet.jit.si:443

When using jit.si you get the error:

Failed to access your camera
Cannot use camera for an unknown reason

When checking jit.si settings it says "Preview unavailable" and "Camera" as "Permission not granted". You cannot select anything else as "Camera".

My personal assumptions are then:

• jit.si only grabs the first UVC device
• jit.si does not enumerate the device properly so another device can be selected
• jit.si fails when the camera returns no image but does not try the next.

In Google Duo it is slightly different. Here I am able to preview the camera in settings but fails when setting up the call.

Testing in Chrome is not revealing and gives the expected results:

Check resolution 320x240 - FAIL
Check resolution 640x480 - FAIL
Check resolution 1280x720 - FAIL
Check supported resolutions - OK

As we are at 1920x1080p50 this seems reasonable.

When testing with Firefox 75 everything is the same except that it is a little more revealing.

When going to jit.si it only asks for Elgato Screen Link

When going to Webrtc test it asks for both Cam Link 4K and Elgato Screen Link

If I only give temporary permissions this is what happens during testing:

• First 3 resolution tests it asks for permission to Elgato Screen Link and then fail.
• For supported resolutions it asks for permission for Cam Link 4K and then succeed.

While the workaround to uninstall 4K Capture Utility work fine for me it does indicate that the camera detection routine is sub optimal. You could claim it to be an Elgato problem but at least Google Meet and Skype Web handles this gracefully.

I have screenshots if needed. And I will happily do further testing. But expect no pull request from me on this issue :-) Feel free to close this issue at your leisure.

[rhuijben]

Seeing the same thing. If the first camera can't be used for some reasons (e.g. in use by another app), Jitsi doesn't allow selecting another camera while other browser based solutions do allow this. Once the right camera is cached (in a cookie/local storage?) then the next time enumerating the cameras works fine.

[rhuijben]

I think Jitsi accidentally asks some info from the first/default camera and gets a denied there... and then via some bad error handling assumes that all cameras are not accessible. Have seen this issue on several jitsi deployments over the last few weeks.

[saghul]

Check resolution 320x240 - FAIL
Check resolution 640x480 - FAIL
Check resolution 1280x720 - FAIL
Check supported resolutions - OK

Jitsi uses 720p by default and never goes beyond that, so the failure is expect in so far as the required resolution is not supported.

[ClausAndersen]

That is a quick dismissal which does not correspond with the facts.

The error given by Jit.si is:

Failed to access your camera
Cannot use camera for an unknown reason

So even if Jit.si by default expects 720p - this can in no reasonable way be interpreted as "expected".

The real problem is the enumeration of multiple cameras. If the first camera does not respond as expected it fails.

Even if it actually was because 720p was not available - I would still expect it to try the next camera.

From a project management perspective I can understand how you might choose to mark this as "won't fix". And that would be fair!

But a statement of "expected" makes me think that the cause is not properly understood.

So on a system with 2 cameras. Camera 1 only suplies 8K+ and Camera 2 is within spec with 720p jit.si will not work. The end user does not have any control over which one will be the first!

My "expected" behaviour would be:

Enumerate all cameras. Pick the first with a supported resolution.

Current behaviour:

Try the first camera. If it fails you are dead in the water. The user cannot control which one is picked first. You get a unhelpful "unknown error"

I am sorry to nag you with this. If you do not care about systems with multiple cameras that is completely fair and they are for sure in the minority. I can live with that and will go away. No hard feelings.

But my expectation would be at least a better error message. "Unknown reason" for a lack of 720p is not very helpful.

The main culprit to me does however seem to be a "unreasonable" expectation that the first found camera should be usable. The user is not in control of that so in my mind it would be logical for the app to enumerate them and see if there is another which can satisfy the needs.

Again: I am mindful that I am pressing this issue - and I do not really want that. But it seems that the root cause is misunderstood so I hope we can get back on track. A

[saghul]

That is a quick dismissal which does not correspond with the facts.

Sorry, I didn't intend to sound dismissive. I reply to many issues throughout the day and sometimes my responses end up being too terse and/or I may miss something when reading quickly.

I was trying to provide some quick feedback on why you were seeing that error.

The real problem is the enumeration of multiple cameras. If the first camera does not respond as expected it fails.

Even if it actually was because 720p was not available - I would still expect it to try the next camera.

Yeah, this is indeed a very reasonable expectation. (@jallamsetty1 does this bug ring any bell?)

I myself run 3-4 cameras at all times, but they all support a resolution of 720p or less, so I have never seen this problem before. Now we know!

Again: I am mindful that I am pressing this issue - and I do not really want that. But it seems that the root cause is misunderstood so I hope we can get back on track.

Understood now, thanks for elaborating!

[ClausAndersen]

No worries - happy that we are on the same page.

Feel free to close this if you do not consider it a bug and are tracking it on a feature list.

And I am available for further testing etc. - alas do not expect any pull requests :-)

[jallamsetty1]

That is a quick dismissal which does not correspond with the facts.

Sorry, I didn't intend to sound dismissive. I reply to many issues throughout the day and sometimes my responses end up being too terse and/or I may miss something when reading quickly.

I was trying to provide some quick feedback on why you were seeing that error.

The real problem is the enumeration of multiple cameras. If the first camera does not respond as expected it fails.
Even if it actually was because 720p was not available - I would still expect it to try the next camera.

Yeah, this is indeed a very reasonable expectation. (@jallamsetty1 does this bug ring any bell?)

I myself run 3-4 cameras at all times, but they all support a resolution of 720p or less, so I have never seen this problem before. Now we know!

Again: I am mindful that I am pressing this issue - and I do not really want that. But it seems that the root cause is misunderstood so I hope we can get back on track.

Understood now, thanks for elaborating!

@saghul, yes this bug was reported in the camera meta issues as well, I couldn't repro it then as I didn't have a non-working camera. I will give it a try by installing a virtual cam or something similar.

[hackerb9]

Just a note that this is still an issue as I've run into what I believe is the same bug.

I am helping a gentleman who has an old 640x480 QuickCam Pro 4000 attached to his computer. He added a new Generic "Full HD" camera and now sees the "Preview Unavailable" error when trying to select it from the camera list.

It may be helpful to know that the new camera does work when using meet.jit.si in Firefox, just not in Chrome or Chromium.