2007675 - v4l2loopback Camera Not Found with WebRTC

Status: RESOLVED DUPLICATE of bug 1946916

(Core :: WebRTC: Audio/Video, defect)

Description

[doc987]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:146.0) Gecko/20100101 Firefox/146.0

Steps to reproduce:

Go to Mozilla getUserMedia test page (https://mozilla.github.io/webrtc-landing/gum_test.html) and press the Camera button.

Actual results:

Received the following message:
NotFoundError: The object can not be found here.

Expected results:

Should have received a request to use the camera.

Comment 1

[doc987]

Additional Notes

1. Firefox does not find a v4l2loopback camera. NotFoundError ("The object can not be found here.") is returned by navigator.mediaDevices.getUserMedia({video:true}).
2. Setting privacy.resistfingerprinting to true in about:config changes the error above to NotAllowedError ("The request is not allowed by the user agent or the platform in the current context.").
3. There is no issue with navigator.mediaDevices.getUserMedia({audio:true}). Running that results in a request for access to a microphone.
4. The results above also occur on the Mozilla getUserMedia test page (https://mozilla.github.io/webrtc-landing/gum_test.html).
5. Using Firefox in a brand new profile does not fix the issue.
6. Chromium finds the v4l2loopback camera.
7. VLC finds the v4l2loopback camera.
8. Firefox does find a non-v4l2loopback camera (USB webcam).
9. Firefox does find a v4l2loopback camera if media.webrtc.camera.allow-pipewire to set to false in about:config.

Comment 2

[Dan Baker[:dbaker]]

Thank you for letting us know about this issue you are seeing.
Could you provide some additional information to assist with trouble shooting.

• In a tab navigate to about:support and copy your information to add to this bug.
• If you are able to reproduce this still could you please navigate to about:logging
  • Under Logging Preset select WebRTC
  • Click the Start Logging at the top
  • Reproduce the issue in another tab
  • Navigate back to the logging tab and select Stop Logging
  • This should open up a profiler that you upload and attach the link to this bug.
• If you haven't could you try to verify if you see this issue running in our Nightly app?

Comment 3

[doc987]

Attachment: about_support.txt

Comment 4

[doc987]

Attachment: Firefox 2026-01-06 16.19 profile.json.gz

Comment 5

[doc987]

Comment on attachment 9535999 [details]
Firefox 2026-01-06 16.19 profile.json.gz

Log Context

• Page: https://mozilla.github.io/webrtc-landing/gum_test.html
• Pressed the "Camera" button.

Comment 6

[doc987]

Attachment: Firefox 2026-01-06 16.29 profile.json.gz

Log Context

• Page: https://mozilla.github.io/webrtc-landing/gum_test.html
• Pressed the "Camera" button.

Comment 7

[doc987]

I attached the two files requested. Nightly is not included my distribution's repository. I'm running the most recent version available (146.0).

Comment 8

[Dan Baker[:dbaker]]

Thank you for getting back so quickly with this information. Could you try to get a profile again the one you posted seemed to be missing information.

When grabbing the logging make sure to have selected the WebRTC logging modules under about:logging. Then navigate and reproduce the issue. It's important when uploading or saving to ensure the Include hidden threads is checked.

Comment 9

[doc987]

Attachment: Firefox 2026-01-07 16.14 profile.json.gz

Log Context

• Page: https://mozilla.github.io/webrtc-landing/gum_test.html
• Pressed the "Camera" button.

Comment 10

[doc987]

I produced the file again, and checked the "Include hidden threads" box.

Comment 11

[Dan Baker[:dbaker]]

From what I can see we are not getting devices returned so we are not able to start any capture device. When you mention that the v4l2loopback is found when you disable pipewire could indicate there is an issue with permissions/pipewire on the system. Looking at the code it seems like we take a seperate path straight to checking the system for video devices when that pref for pipewire is disabled.

Does querying the system using pipewire show the v4l2loopback?
You mentioned it worked elsewhere do you know if that app is also using pipewire?

Comment 12

[Dan Baker[:dbaker]]

Stransky would you happen to have any ideas or suggestions on what to check regarding this issue?

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Jan Grulich should know more as it works on WebRTC/Pipewire.

Comment 14

[Jan Grulich]

Possible duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1946916?

Comment 15

[doc987]

Dan - You posed two question (reproduced below). I don't know how to check these. Do you?

1. Does querying the system using pipewire show the v4l2loopback?
2. You mentioned it worked elsewhere do you know if that app is also using pipewire?

Note

• SELinux: The camera is still not found if I change SELinux to permissive.
• wpctl: wpctl status shows /dev/video0 as v4l2 under video devices.

Comment 16

[Dan Baker[:dbaker]]

Did you check the bug referenced by Jan specifically that the v4l2 device was created and trying systemctl --user restart wireplumber to see if it gets picked up?

How are you creating the loopback device?

I believe you can use the pipewire cli like pw-cli ls Node maybe add a | grep -i v4l or camera to see what it sees.

Comment 17

[doc987]

Device Creation

I created the loopback devices (/dev/videoX) with modprobe v4l2loopback devices=N where N is the number of devices desired.

Bug 1946916 mentioned that wpctl status will not show a virtual camera in "Sources". I found that it depends on the exclusive_caps value used by modprobe.

• exclusive_caps=0 results in wpctl status showing /dev/videoX under both video devices and video sources.
• exclusive_caps=1 results in wpctl status showing /dev/videoX under both video devices and not under video sources, but will show under video sources after subsequently running systemctl --user restart wireplumber.

Device Input

I've tried two different approaches of providing input to a device:

• scrcpy: e.g. scrcpy --v4l2-sink=/dev/video1 --video-source=camera --camera-facing=back --no-audio --no-playback
• OBS Studio: "Start Virtual Camera"

In both approaches above, the result is the same. That is:

• Firefox: Does not find the camera.
• VLC: Can play (Media -> Open Capture Device...) the video from /dev/videoX.
• Chromium: Can play (using the Mozilla test page https://mozilla.github.io/webrtc-landing/gum_test.html) the video from /dev/videoX. Note that modprobe must create the device with exclusive_caps=1 in order for Chromium to find it (e.g. modprobe v4l2loopback devices=1 exclusive_caps=1).

pw-cli

The output depends on whether or not exclusive_caps is 0 or 1.

Example 1: modprobe v4l2loopback devices=1 exclusive_caps=0
pw-cli ls Node|grep -i v4l yields:

      object.path = "v4l2:/dev/video0"
      node.description = "OBS Virtual Camera (V4L2)"
      node.name = "v4l2_input._sys_devices_virtual_video4linux_video0"

Example 2: modprobe v4l2loopback devices=1 exclusive_caps=1
pw-cli ls Node|grep -i v4l yields no output.

wireplumber

Carrying out the steps listed below in the order in which they are listed does result in a successful camera request in Firefox.

• Use modprobe to create /dev/videoX. It does not matter if exclusive_caps is 0 or 1.
• Add video input (doesn't matter if it's from scrcpy or OBS) to /dev/videoX.
• Restart wireplumber: systemctl --user restart wireplumber. This is needed regardless of the value of exclusive_caps, and thus regardless of whether or not /dev/videoX appears under video sources from wpctl status.
• Press the "Camera" button on the Mozilla test page (https://mozilla.github.io/webrtc-landing/gum_test.html) in Firefox.

Comment 18

[Dan Baker[:dbaker]]

Jan could you confirm if this seem like https://bugzilla.mozilla.org/show_bug.cgi?id=1946916 or a known issue? It sounds like it but I would prefer a second opinion before closing this bug as a duplicate of a known issue.

Comment 19

[Jan Grulich]

Hi, yes, it's a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1946916 and there is an upstream issue for this as well here https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3659.