obs-studio
obs-studio copied to clipboard
obsproject
v4l2 Virtual camera - Loopback device conflicts (Including droidcam)
Platform
Operating system and version: Arch Linux - Rolling OBS Studio version: 26.1.0.r9
Expected Behavior
Clicking on "Start Virtual Camera" button should start the virtual cam flawlessly
Current Behavior
Pressing the button does not create any effect.
Steps to Reproduce
- Install droidcam from @dev47apps**
- Install obs-studio-git from AUR
- Remove the old CatxFish/obs-v4l2sink plugin
- Install v4l2loopback-dkms
- Start OBS and click "Start Virtual Camera" button.
Additional information
The log says "warning: Failed to start virtual camera" when clicking on the button. I've installed droidcam alongside OBS, and it currently uses the /dev/video0 device. I thought maybe obs is trying to use that device and it conflicts with droidcam, but disabling (not removing) droidcam doesn't solve the issue.
Edit: I've tried removing droidcam, it turns out that they were indeed in conflict. Removing droidcam solves the issue, reinstalling it works fine, but as long as I reboot droidcam takes over /dev/video0 and I could not find any other ways than removin and reinstalling droidcam... every reboot. It's solved in a way but that's not very practical.
I am experiencing the same issue.
Platform Operating system and version: Kubuntu 20.10 OBS Studio version: 26.1
Expected Behavior Clicking on "Start Virtual Camera" button should start the virtual cam flawlessly
Current Behavior Pressing the button does not create any effect. (button text remains "Start Virtual Camera")
Steps to Reproduce Install obs-studio 26.1 from ppa:obsproject/obs-studio Install v4l2loopback-dkms (previously installed) Start OBS and click "Start Virtual Camera" button.
Additional information
- The log says "warning: Failed to start virtual camera" when clicking on the button.
- I do not have droidcam or any other camera manipulation software installed (as far as I know)
- I had a previous version of OBS Studio installed (from Ubuntu 20.10 repository - uninstalled before installing 26.1 from PPA).
Log File Contents
03:19:54 PM.696: CPU Name: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
03:19:54 PM.696: CPU Speed: 1830.528MHz
03:19:54 PM.696: Physical Cores: 2, Logical Cores: 4
03:19:54 PM.696: Physical Memory: 11850MB Total, 2914MB Free
03:19:54 PM.696: Kernel Version: Linux 5.8.0-33-generic
03:19:54 PM.696: Distribution: "Ubuntu" "20.10"
03:19:54 PM.696: Session Type: x11
03:19:54 PM.697: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.20.9
03:19:54 PM.697: Portable mode: false
03:19:54 PM.754: OBS 26.1.0 (linux)
03:19:54 PM.754: ---------------------------------
03:19:54 PM.841: ---------------------------------
03:19:54 PM.841: audio settings reset:
03:19:54 PM.841: samples per sec: 48000
03:19:54 PM.841: speakers: 2
03:19:54 PM.850: ---------------------------------
03:19:54 PM.850: Initializing OpenGL...
03:19:54 PM.903: Loading up OpenGL on adapter Intel Mesa Intel(R) HD Graphics 620 (KBL GT2)
03:19:54 PM.903: OpenGL loaded successfully, version 4.6 (Core Profile) Mesa 20.2.1, shading language 4.60
03:19:54 PM.919: ---------------------------------
03:19:54 PM.919: video settings reset:
03:19:54 PM.919: base resolution: 1600x900
03:19:54 PM.919: output resolution: 1280x720
03:19:54 PM.919: downscale filter: Bicubic
03:19:54 PM.919: fps: 30/1
03:19:54 PM.919: format: NV12
03:19:54 PM.919: YUV mode: 709/Partial
03:19:54 PM.919: NV12 texture support not available
03:19:54 PM.921: Audio monitoring device:
03:19:54 PM.921: name: Default
03:19:54 PM.921: id: default
03:19:54 PM.921: ---------------------------------
03:19:54 PM.923: Failed to load 'en-US' text for module: 'decklink-captions.so'
03:19:54 PM.925: Failed to load 'en-US' text for module: 'decklink-ouput-ui.so'
03:19:55 PM.030: A DeckLink iterator could not be created. The DeckLink drivers may not be installed
03:19:55 PM.030: No blackmagic support
03:19:55 PM.039: [obs-browser]: Version 2.9.1
03:19:55 PM.039: [obs-browser]: CEF Version 76.1.13+gf19c584+chromium-76.0.3809.132
03:19:55 PM.070: os_dlopen(libnvidia-encode.so.1->libnvidia-encode.so.1): libnvidia-encode.so.1: cannot open shared object file: No such file or directory
03:19:55 PM.070:
03:19:55 PM.070: FFMPEG VAAPI supported
03:19:55 PM.093: VLC found, VLC video source enabled
03:19:55 PM.094: ---------------------------------
03:19:55 PM.094: Loaded Modules:
03:19:55 PM.094: vlc-video.so
03:19:55 PM.094: text-freetype2.so
03:19:55 PM.094: rtmp-services.so
03:19:55 PM.094: obs-x264.so
03:19:55 PM.094: obs-vst.so
03:19:55 PM.094: obs-transitions.so
03:19:55 PM.094: obs-outputs.so
03:19:55 PM.094: obs-libfdk.so
03:19:55 PM.094: obs-filters.so
03:19:55 PM.094: obs-ffmpeg.so
03:19:55 PM.094: obs-browser.so
03:19:55 PM.094: linux-v4l2.so
03:19:55 PM.094: linux-pulseaudio.so
03:19:55 PM.094: linux-jack.so
03:19:55 PM.094: linux-decklink.so
03:19:55 PM.094: linux-capture.so
03:19:55 PM.094: linux-alsa.so
03:19:55 PM.094: image-source.so
03:19:55 PM.094: frontend-tools.so
03:19:55 PM.094: decklink-ouput-ui.so
03:19:55 PM.094: decklink-captions.so
03:19:55 PM.094: ---------------------------------
03:19:55 PM.094: os_dlopen(../obs-plugins/obs-browser->../obs-plugins/obs-browser.so): ../obs-plugins/obs-browser.so: cannot open shared object file: No such file or directory
03:19:55 PM.094:
03:19:55 PM.094: ==== Startup complete ===============================================
03:19:55 PM.097: All scene data cleared
03:19:55 PM.097: ------------------------------------------------
03:19:55 PM.106: pulse-input: Server name: 'pulseaudio 13.99.2'
03:19:55 PM.107: pulse-input: Audio format: s16le, 48000 Hz, 2 channels
03:19:55 PM.107: pulse-input: Started recording from 'alsa_output.pci-0000_00_1f.3.analog-stereo.monitor'
03:19:55 PM.107: [Loaded global audio device]: 'Desktop Audio'
03:19:55 PM.110: pulse-input: Server name: 'pulseaudio 13.99.2'
03:19:55 PM.111: pulse-input: Audio format: s16le, 48000 Hz, 2 channels
03:19:55 PM.111: pulse-input: Started recording from 'alsa_input.pci-0000_00_1f.3.analog-stereo'
03:19:55 PM.111: [Loaded global audio device]: 'Mic/Aux'
03:19:55 PM.111: v4l2-input: Start capture from /dev/video0
03:19:55 PM.226: v4l2-input: Input: 0
03:19:55 PM.234: v4l2-input: Resolution: 640x480
03:19:55 PM.234: v4l2-input: Pixelformat: YUYV
03:19:55 PM.234: v4l2-input: Linesize: 1280 Bytes
03:19:55 PM.234: v4l2-input: Framerate: 30.00 fps
03:19:55 PM.235: Switched to scene 'Scene'
03:19:55 PM.235: ------------------------------------------------
03:19:55 PM.235: Loaded scenes:
03:19:55 PM.235: - scene 'Scene':
03:19:55 PM.235: - source: 'Video Capture Device (V4L2)' (v4l2_input)
03:19:55 PM.235: ------------------------------------------------
03:19:55 PM.665: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds (source: Mic/Aux)
03:19:55 PM.665:
03:20:01 PM.687: Failed to start virtual camera
03:20:07 PM.038: ==== Shutting down ==================================================
03:20:07 PM.056: v4l2-input: Stopped capture after 354 frames
03:20:07 PM.098: pulse-input: Stopped recording from 'alsa_output.pci-0000_00_1f.3.analog-stereo.monitor'
03:20:07 PM.098: pulse-input: Got 2073 packets with 487220 frames
03:20:07 PM.098: pulse-input: Stopped recording from 'alsa_input.pci-0000_00_1f.3.analog-stereo'
03:20:07 PM.098: pulse-input: Got 1220 packets with 574616 frames
03:20:07 PM.100: All scene data cleared
03:20:07 PM.100: ------------------------------------------------
03:20:07 PM.232: [Scripting] Total detached callbacks: 0
03:20:07 PM.243: Freeing OBS context data
03:20:07 PM.259: == Profiler Results =============================
03:20:07 PM.259: run_program_init: 699.53 ms
03:20:07 PM.259: ┣OBSApp::AppInit: 2.373 ms
03:20:07 PM.259: ┃ ┗OBSApp::InitLocale: 1.074 ms
03:20:07 PM.259: ┗OBSApp::OBSInit: 622.338 ms
03:20:07 PM.259: ┣obs_startup: 1.475 ms
03:20:07 PM.260: ┗OBSBasic::OBSInit: 477.28 ms
03:20:07 PM.260: ┣OBSBasic::InitBasicConfig: 0.088 ms
03:20:07 PM.260: ┣OBSBasic::ResetAudio: 0.127 ms
03:20:07 PM.260: ┣OBSBasic::ResetVideo: 79.832 ms
03:20:07 PM.260: ┣OBSBasic::InitOBSCallbacks: 0.004 ms
03:20:07 PM.260: ┣OBSBasic::InitHotkeys: 0.043 ms
03:20:07 PM.260: ┣obs_load_all_modules: 172.504 ms
03:20:07 PM.260: ┃ ┣obs_init_module(decklink-captions.so): 0.032 ms
03:20:07 PM.260: ┃ ┣obs_init_module(decklink-ouput-ui.so): 1.016 ms
03:20:07 PM.260: ┃ ┣obs_init_module(frontend-tools.so): 74.543 ms
03:20:07 PM.260: ┃ ┣obs_init_module(image-source.so): 0.006 ms
03:20:07 PM.260: ┃ ┣obs_init_module(linux-alsa.so): 0.003 ms
03:20:07 PM.260: ┃ ┣obs_init_module(linux-capture.so): 0.303 ms
03:20:07 PM.260: ┃ ┣obs_init_module(linux-decklink.so): 0.188 ms
03:20:07 PM.260: ┃ ┣obs_init_module(linux-jack.so): 0.001 ms
03:20:07 PM.260: ┃ ┣obs_init_module(linux-pulseaudio.so): 0.001 ms
03:20:07 PM.260: ┃ ┣obs_init_module(linux-v4l2.so): 2.458 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-browser.so): 0.062 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-ffmpeg.so): 0.299 ms
03:20:07 PM.260: ┃ ┃ ┗nvenc_check: 0.256 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-filters.so): 0.018 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-libfdk.so): 0.002 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-outputs.so): 0.004 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-transitions.so): 0.009 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-vst.so): 0.006 ms
03:20:07 PM.260: ┃ ┣obs_init_module(obs-x264.so): 0.004 ms
03:20:07 PM.260: ┃ ┣obs_init_module(rtmp-services.so): 0.635 ms
03:20:07 PM.260: ┃ ┣obs_init_module(text-freetype2.so): 0.021 ms
03:20:07 PM.260: ┃ ┗obs_init_module(vlc-video.so): 2.482 ms
03:20:07 PM.260: ┣OBSBasic::ResetOutputs: 0.144 ms
03:20:07 PM.260: ┣OBSBasic::CreateHotkeys: 0.03 ms
03:20:07 PM.261: ┣OBSBasic::InitService: 1.079 ms
03:20:07 PM.261: ┣OBSBasic::InitPrimitives: 0.197 ms
03:20:07 PM.261: ┗OBSBasic::Load: 140.113 ms
03:20:07 PM.261: obs_hotkey_thread(25 ms): min=0.086 ms, median=0.31 ms, max=70.343 ms, 99th percentile=6.86 ms, 99.5885% below 25 ms
03:20:07 PM.261: audio_thread(Audio): min=0 ms, median=0.079 ms, max=2.966 ms, 99th percentile=0.525 ms
03:20:07 PM.261: obs_graphics_thread(33.3333 ms): min=0.017 ms, median=1.388 ms, max=113.687 ms, 99th percentile=16.17 ms, 99.7275% below 33.333 ms
03:20:07 PM.261: ┣tick_sources: min=0 ms, median=0.012 ms, max=113.6 ms, 99th percentile=0.04 ms
03:20:07 PM.261: ┣output_frame: min=0.008 ms, median=0.558 ms, max=1.6 ms, 99th percentile=1.525 ms
03:20:07 PM.261: ┃ ┗gs_context(video->graphics): min=0.007 ms, median=0.558 ms, max=1.598 ms, 99th percentile=1.525 ms
03:20:07 PM.261: ┃ ┣render_video: min=0.004 ms, median=0.439 ms, max=1.348 ms, 99th percentile=1.312 ms
03:20:07 PM.261: ┃ ┃ ┗render_main_texture: min=0.004 ms, median=0.433 ms, max=1.345 ms, 99th percentile=1.275 ms
03:20:07 PM.261: ┃ ┗gs_flush: min=0 ms, median=0.08 ms, max=0.408 ms, 99th percentile=0.366 ms
03:20:07 PM.261: ┗render_displays: min=0.002 ms, median=0.672 ms, max=18.786 ms, 99th percentile=15.498 ms
03:20:07 PM.261: =================================================
03:20:07 PM.261: == Profiler Time Between Calls ==================
03:20:07 PM.261: obs_hotkey_thread(25 ms): min=25.157 ms, median=25.414 ms, max=95.456 ms, 64.1237% within ±2% of 25 ms (0% lower, 35.8763% higher)
03:20:07 PM.261: obs_graphics_thread(33.3333 ms): min=19.609 ms, median=33.332 ms, max=113.69 ms, 98.9071% within ±2% of 33.333 ms (0.546448% lower, 0.546448% higher)
03:20:07 PM.261: =================================================
03:20:07 PM.275: Number of memory leaks: 0
It seems the issue was that "modprobe v4l2loopback" assigned /dev/video99 to the virtual camera. Removing v4l2loopback and then manually assigning the next available number (in my case /dev/video2) resulting in the virtual camera working.
I wonder if there is a way to force OBS to use /dev/video99.
It seems the issue was that "modprobe v4l2loopback" assigned /dev/video99 to the virtual camera. Removing v4l2loopback and then manually assigning the next available number (in my case /dev/video2) resulting in the virtual camera working.
I wonder if there is a way to force OBS to use /dev/video99.
You wrote about a "modprobe v4l2loopback" and a /dev/video99, but you actually never mentioned them before, what did you mean?
I forgot that I had to run "modprobe v4l2loopback" in order for the "Start Virtual Camera" button to appear. Or at least, the button did not appear until after I ran that command. I found I had to run that command when experimenting with uninstalling and reinstalling v4l2loopback-dkms as well as OBS.
I forgot that I had to run "modprobe v4l2loopback" in order for the "Start Virtual Camera" button to appear. Or at least, the button did not appear until after I ran that command. I found I had to run that command when experimenting with uninstalling and reinstalling v4l2loopback-dkms as well as OBS.
I see. I've noticed something else: maybe it can be a issue with the propting for elevated rigths, 'cause without root access obs has no way to configure a new v4l2loopback device. So my guess is that obs can't prompt you for elevation, then it fails to register a new virtual camera and consequently fails to start it.
I have "almost" the same issue...
Although for me OBS reports that the virtual camera is actually started:
[...]
18:04:23.524: Virtual camera started
18:04:23.531: ==== Virtual Camera Start ==========================================
18:05:43.722: Output 'virtualcam_output': stopping
18:05:43.722: Output 'virtualcam_output': Total frames output: 2404
18:05:43.722: Output 'virtualcam_output': Total drawn frames: 2406
18:05:43.722: ==== Virtual Camera Stop ===========================================
18:05:43.724: Virtual camera stopped
18:05:45.202: ==== Shutting down ====q==============================================
[...]
I can't see the output in any of the virtual cameras of my system.
The point is I have multiple "virtual" cameras already:
$ v4l2-ctl --list-devices
Virtual akvcam (out) (platform:akvcam-0):
/dev/video0
Virtual akvcam (platform:akvcam-1):
/dev/video1
Virtual Camera (platform:v4l2loopback-000):
/dev/video3
Droidcam (platform:v4l2loopback_dc-000):
/dev/video2
UVC Camera (046d:0809) (usb-0000:00:14.0-2):
/dev/video4
- The two firsts are created by the akvcam module that is used by webcamoid.
- The third one is the one that OBS should use (it is not named "OBS Virtual Camera" because I created it in the modprobe conf file... Anyways I checked the OBS code and it seems that the name "OBS Virtual Camera" is never used elsewhere but in the function creating the v4l2loopback conf.).
- The fourth one is easy to guess.
- The last one is my physical camera.
And of course that order changes across reboots, as reported multiple times.
The problem seems that the code is checking the fact the v4l2loopback module is loaded, but I have no idea how it determines which device to actually use... I 'm guessing the first one.
I tried to use any of the virtual cameras to check if it was not outputing to the wrong virtual camera, but no... It just reports the virtual cam is started and issues no error, while it evidently doesn't work.
I am runnning Ubuntu 18.04 on this machine
OBS 26.1.0 (64)
FYI, with the previous OBS release I was using the obs-v4l2sink plugin and it was fully working (I removed everything regarding this plugin when I upgraded to this version of OBS).
I hope this helps as it's clearly a blocking issue, I am considering falling back, but would definitely prefer to have OBS virtual camera working with no plugin.
I think OBS should have a config flag to specify which virtual camera to use (it was the case with the plugin). Be it by path, by id, or by whatever is secondary. Even if with the plugin, it was painful to each time check if the /dev/videox used was the correct one after a reboot, it was not blocking at all, which it is now...
Using Arch - Rolling, OBS 26.1.0.r20. Can confirm, removing Droidcam and rebooting fixed my issue and Virtual Camera is working beautifully now.
I confirm that removing all virtual cameras is a workaround (clearly not a fix).
In my case I had to remove both akvcam and v4l2loopback_dc (the module used by Droidcam) modules and the the OBS virtual camera started working. But I insist this is no fix!
The real fix would be to provide a way to specify which v4l2 camera to use as virtual camera, like it was the case with the plugin it supercedes.
@topongo I suggest you modify the issue title once again to:
"Virtual camera fails to start due to the presence of any v4l2loopback device other than the one expected by OBS"
As it is confirmed, akvcam (which is another flavour of v4l2loopback) has to be removed as well...
A much better workaround until this is fixed is to actually continue using the obs-v4l2sink plugin which still allows selecting the relevant virtual camera to use.
Just tested with all modules I use actually loaded and it works (like with previous versions of OBS)...
Out of curiosity, how do akvcam and droidcam handle the mapping? Is there something we could be doing better automatically?
I am afraid that, for that, you will have to have a look at their respective repos... I am just a user in this case.
The point is both akvcam and droidcam use their own modules (akvcam for Webcamoid and v4l2loopback_dc for Droidcam) which are somehow derived from v4l2loopback but with at least the name differing... I guess this is what they use to target the correct devices.
In the case of OBS, as it relies on the generic v4l2loopback, I doubt something fully automated could be really achieved unless maybe only one device exists using that module. The best way is clearly to allow to specify which one to use in the OBS config, and to improve regarding the mechanism currently existing within the plugin, use something else than the /dev/videox to ensure consistency across reboots...
Maybe a possibility for something fully automated would be that OBS provides its own forked flavour of the v4l2loopback module to be able to rely on the module name, but honestly I think that this pathway should be avoided.
I'm currently using OBS compiled from source (OBS Studio - 26.1.0-15-g60fed63d6) on elementary (Ubuntu 18.04 base) with the droidcam plugin but not the v4l2loopback_dc. Compiled v4l2loopback myself and in /etc/modprobe.d I have a file v4l2loopback.conf with the following content:
options v4l2loopback devices=1 video_nr=10 card_label="OBS Virtualcam" exclusive_caps=1
Works perfectly for me.
I'm having the same issue. For me at least, it's that I can't select WHICH device to output to. My DSLR is a loopback device, and OBS 26 is overwriting it.
Previously, I could select which v4l2loopback device to output to. After updating to OBS 26, with the new "Start Virtual Camera", I can only output to the first v4l2loopback device. Is there a setting somewhere? How can I select the output path of the virtual camera?
Details: I'm using a Canon DSLR to USB3 via g2photo & v4l2loopback. This is itself a v4l2loopback device. When I run "v4l2-ctl --list-devices", it lists two devices. I then use g2photo to send a stream from the camera to /dev/video0 . For OBS to detect the camera, it has to be running into a loopback device BEFORE OBS starts. The issue is that since I can't select where to send OBS virtual camera output path, it is overwriting the camera with the output. This is how I output OBS into something like Zoom. It was working fine with OBS 25.
Has the feature: "ability to select which v4l2loopback device" been overlooked?
Definitely, the ability to carry over the setting from the plugin to OBS 26 either isn't there or isn't working.
I have the same issue in 26.1. I'm using Droidcam-OBS, the remote camera works in OBS and I can stream/record with it. Clicking Start Virtual Camera only produces "Failed to start virtual camera" in output log.
Same issue here, again with ArchLinux and DroidCam installed producing "Failed to start virtual camera" in the output.
For me, moving droidcam away from /dev/video0 to another device (eg. /dev/video3) somehow worked (Virtual Cam image is somehow disturbed :thinking:):
/etc/modprobe.d/droidcam.conf
options v4l2loopback_dc width=640 height=480 video_nr=3
But obs-v4l2sink-git still works better.
Archlinux, OBS 26.1.0-2
Definitely agree with @lbriais here. An option to specify the loopback device is the best solution. The workaround of moving other applications away from the first loopback device doesn't work in all cases. For example, you can't run multiple OBS instances each with their own loopback output.
Providing some findings from my side (Debian, build from source with automation dated to master branch 81a89e6) if it is useful. A device selector is suffice.
My v4l2 device is /dev/video100.
- If I use CatFish plugin, I got to select that device - everything is working fine.
- If I start virtual camera, apparently it locked itself to
/dev/video0which is my laptop camera (log generated from terminal):
...
info: v4l2-input: Start capture from /dev/video0
info: v4l2-input: Input: 0
info: v4l2-input: Resolution: 640x480
info: v4l2-input: Pixelformat: YUYV
info: v4l2-input: Linesize: 1280 Bytes
info: v4l2-input: Framerate: 30.00 fps
info: v4l2-input: /dev/video0: select timeout set to 166666us (5x frame periods)
...
error: v4l2-input: /dev/video0: select timed out
error: v4l2-input: /dev/video0: failed to log status
error: v4l2-input: /dev/video0: select timed out
error: v4l2-input: /dev/video0: failed to log status
error: v4l2-input: /dev/video0: select timed out
error: v4l2-input: /dev/video0: failed to log status
warning: Failed to start virtual camera
```
Below are some observations I've made. For reference, here's my setup:
- Debian Unstable
- OBS
26.1.2without any plugins v4l2loopback-dkms 0.12.5-1- laptop with 1 webcam (which for some reason is both on
/dev/video0and/dev/video1) - DSLR camera (streamed via
gphoto2)
Observations
- if the
v4l2loopbackkernel module isn't loaded, OBS will load it by runningmodprobe v4l2loopback exclusive_caps=1 card_label='OBS Virtual Camera'. On the other hand, if the module is loaded, it won't do anything, such as trying to reload it. This is because dynamic module management isn't fully implemented yet inv4l2loopback, and reloading the whole module would probably break running devices. - there has to exist at least one free loopback device, otherwise the virtual camera will falsely report that it has started, but won't be available in other software
- on that note, if I create 2 devices,
/dev/video2and/dev/video3, set my DSLR to stream to/dev/video2, and try to start the virtual camera, it will produce some bizarre flicker on the output of the DSLR and I won't be able to use the output from the virtual camera in other software. On the other hand, if I stream to/dev/video3and start the virtual cam, the virtual camera works fine in other programs (checked withffplay /dev/video2and Signal desktop). TL;DR when streaming from devices, it seems that the order matters, and OBS isn't happy if the (numerically) first loopback device isn't available, so make sure that the very first loopback device remains free. - for any
v4l2loopbackdevice number > 63, OBS will fail to start the virtual camera; this is hardcoded, so unless your setup requires it, use device numbers <= 63. Alternatively, you can change the hardcoded constant and recompile OBS from source. - if all of the above works correctly, and the virtual camera is started, for some reason, I am unable to stream from the webcam anymore (
ffplay /dev/video0reportsDevice or resource busy), but can stream from both OBS and the DSLR - if I run OBS from the terminal, occasionally I'll get the message
libv4l2: error dequeuing buf: Invalid argument; I'm still not sure why that happens, or what triggers it
Enabling the OBS virtual camera
So, to recap, the following will probably work:
- when loading the
v4l2loopbackmodule:- always create one extra device for OBS
- use the option
exclusive_caps=1(for multiple devices, useexclusive_caps=1,1,1..., i.e. put as many ones as there are devices being created) - don't use device numbers > 63
- always leave the numerically first loopback device free, because OBS will use that one (it goes through them in order)
I will admit that this method is very clumsy, and running multiple OBS instances won't work, but I don't think there's much that can be done, at least until dynamic device management becomes available in v4l2loopback, which would enable OBS to spawn a loopback device on-the-fly and use that one.
I would propose simply adding a new configuration option which allows the user to specify the v4l2loopback device they wish to use. This should allow for all of the more advanced use cases. The user can load the v4l2loopback module with whatever options they want prior to launching OBS (OBS should not attempt to load the module itself if it's already loaded). They can also specify which device they want OBS to use, which eliminates conflicts with other devices/applications and also allows for multiple instances of OBS (by setting different loopback devices for each instance).
If there is a desire to improve automatic behaviour, that can be done in separate patches without affecting users who choose to use the manual setting. Power users will likely always need a manual option for more complex scenarios, regardless of what changes are made to the automatic behaviour.
In my opinion, automatic loading of kernel modules should not be done at all by user applications. It would be better to just give a warning/error message if the module is not loaded, and leave it up to the distribution or user to load the module with the appropriate options. However, I recognize that some may disagree. If we had manual settings, then the user at least has the ability to override the automatic behaviours when they are not correct for their environment.
Back 3 months ago. Is there any issue with implementing this or are our assumptions wrong somewhere ? I fully agree on the split of the two problems, one being the automatic default behavior and the other being the manual configuration.
And if needs to be phased, the manual config solves all the issues whereas the automatic default behavior is just nice to have.
Hello together, a manual selection would be perfect. Had the same problem with droidcam and OBS. Both want to use /dev/video0 and either in OBS nor in droidcam, a manual configuration is possible. I needed a while to figure this out, this thread here helps. Thanks guys! :rocket:
To solve my problem, I use the solution @quantenProjects describes in his comment and edited /etc/modprobe.d/droidcam.conf from video_nr=0 to video_nr=1.
# /etc/modprobe.d/droidcam.conf
options v4l2loopback_dc width=640 height=480 video_nr=1
After a reboot, everything is fine. OBS on /dev/video0 and droidcam on /dev/video1.
Sorry, I have the same problem of OBS having a "Start Virtual Camera" button that doesn't do anything except produce an error message (if OBS is run from command line) of "warning: Failed to start virtual camera".
I am not quite a Linux noob but still need some hand-holding to try to follow the potential solutions described in this thread. In particular, when pardomi commented on Dec 21, 2020:
"Removing v4l2loopback and then manually assigning the next available number (in my case /dev/video2) resulting in the virtual camera working."
How exactly does one manually assign the next available number? Is it through the use of the "video_nr=sudo modprobe v4l2loopback devices=1 video_nr=2 card_label="OBS Virtual Camera" exclusive_caps=1
If that is the case, then this solution does not work for me. I have a built-in webcam in my laptop that results in the following output from the command "v4l2-ctl --list-devices":
Integrated_Webcam_HD: Integrate (usb-0000:00:14.0-11): /dev/video0 /dev/video1
These devices are present upon boot-up, so I cannot start OBS before them to reserve /dev/video0 for OBS's virtual camera. When I type
sudo modprobe v4l2loopback devices=1 video_nr=2 card_label="OBS Virtual Camera" exclusive_caps=1
that results in the following output from the command "v4l2-ctl --list-devices":
OBS Virtual Camera (platform:v4l2loopback-000): /dev/video2
Integrated_Webcam_HD: Integrate (usb-0000:00:14.0-11): /dev/video0 /dev/video1
Unfortunately, the error continues to persist, with OBS having a "Start Virtual Camera" button that doesn't do anything when clicked.
I also tried following the suggestion when lbriais commented on Dec 25, 2020: " I confirm that removing all virtual cameras is a workaround (clearly not a fix)"
I am not sure whether the built-in webcam which takes up /dev/video0 and /dev/video1 count as virtual cameras. If they do, then I have no hope: they are already present long before my system can boot up to the point where I can type a "sudo modprobe" command. If they don't count as virtual cameras, then, for me, removing all virtual cameras is NOT a workaround. That is, even if I do "sudo modprobe -r v4l2loopback" (which successfully results in "v4l2-ctl --list-devices" NOT listing anything other than the /dev/video[01] above) does NOT solve the problem: when I click on "Start Virtual Camera", OBS asks for sudo permission (I guess to run "sudo modproble v4l2loopback") but still fails to produce a working virtual camera.
I also read where JCGoran commented on Mar 23: "the following will probably work: ... when loading the v4l2loopback module: ... always create one extra device for OBS ... use the option exclusive_caps=1 ..." etc. Unfortunately, I still get the same error.
(The frustrating thing is, up till two weeks ago it had been working for several months, and then one day it simply didn't work. In between, the only thing that happened was that I installed more RAM on my laptop, but I'm pretty sure that wouldn't cause this error.)
Any insight would be appreciated, but my formal specific question is: How exactly does one manually assign the next available number for the webcam? And does the presence of the integrated webcam keep me from using OBS's virtual camera?
If this is not the appropriate forum to ask these questions, please forgive me, and let me know where my question would be better posted.
Thanks.
I think OBS should have a config flag to specify which virtual camera to use (it was the case with the plugin). Be it by path, by id, or by whatever is secondary. Even if with the plugin, it was painful to each time check if the
/dev/videoxused was the correct one after a reboot, it was not blocking at all, which it is now...
+1 to this idea. Config option is the way. A dropdown in the GUI would be superb.
I have experienced this using Iriun Webcam. /dev/video0 was created by Iriun on its installation, after that, OBS use this device for its VirtualCam and does not create another one. First, OBS should always create a new device when the user starts it for the first time, even if already exists 50 devices, create a new one is always necessary to avoid conflicts, after that, an option to change is simply unnecessary since OBS already created a new device for it, using an existing device without creating a new one is not a good behaviour.
@DanielRios549 The loopback devices are created when the v4l2loopback kernel module is loaded. There is no provision for applications to create new ones after the module has already been loaded. However, the kernel module parameters devices= and video_nr= can be used to create whatever number and naming of loopback devices is desired when the module is loaded.
The obvious thing OBS should be doing is just allowing users to select the desired loopback device, rather than naively assuming that they will only ever use the first one. Even if dynamically adding loopbacks was possible (which it currently is not), it would still be necessary in many cases to specify a specific device for consistent naming purposes.
@DanielRios549 The loopback devices are created when the v4l2loopback kernel module is loaded. There is no provision for applications to create new ones after the module has already been loaded.
Would it be possible/practical to scan all existing loopback devices, unload the module, then reload the module with all previous devices plus a new one? Obviously that might not be desired behavior for everyone, but a button with a warning+confirmation could be nice, for users who aren't great at the CLI themselves.
Then would of course be a separate feature, somewhere near the new feature where we select a device.
Would it be possible/practical to scan all existing loopback devices, unload the module, then reload the module with all previous devices plus a new one? Obviously that might not be desired behavior for everyone, but a button with a warning+confirmation could be nice, for users who aren't great at the CLI themselves.
If I was going to start putting that much effort into this, I would choose to improve the v4l loopback module code so that one can dynamically request a new V4L loopback device. That feels less clunky, less likely to break things (i.e. for those that have multiple devices, allows one to keep working when you load a second), and would be easier to test + maintain.
@mikeperalta1
Would it be possible/practical to scan all existing loopback devices, unload the module, then reload the module with all previous devices plus a new one?
If any other applications have a v4l2loopback device open, the module unload would just fail. Also, this would not solve the problem of consistent device naming, so you would have to be sure to start things in the same order or end up reconfiguring your applications each time. If people truly want dynamic add/remove of loopback modules, that capability would have to be added to v4l2loopback (along with some type of persistent device naming).
I would propose a much simpler solution. Add a configuration option to allow users to set which loopback device they want to use. If it's not specified, keep the current behavior of using the first device. For users with the simple scenario (one OBS instance and no other loopback devices), everything is automatic just like it is now. For users with more complex scenarios, they can just specify the device they want to use.
There appears to be some support for dynamic device management, although it's not available in my distro yet. That could solve this issue(s).[1] Additionally, choosing the virtual devices based on attributes other than their sequence number would probably be a good idea.[2] e.g. prefer the first loopback device with a label containing the string "OBS" and avoid loopback devices that /do/ report sink capabilities (they are likely already in use by another source) [1]https://github.com/umlaeute/v4l2loopback#dynamic-device-management [2]https://wiki.archlinux.org/title/Udev#udev_rule_example
