v4l2loopback stops working after first close

[luigirizzo]

After a recent upgrade from 0.12.5 to 0.12.7 my previously working setup started misbehaving as follows:

• i load v4l2loopback at boot (or manually) with the following: sudo modprobe v4l2loopback devices=1 card_label="test" exclusive_caps=1 This results in one /dev/video0 entry to be used as output device e.g. from obs.

1. the first time I run obs --startvirtualcam after module loading, the output stream is correctly generated on /dev/video0and is picked up by clients e.g. ffplay and Meet
2. after I close the output the first time (e.g. closing obs, or pushing 'stop virtual camera'), subsequent open attempts do not work anymore. obs does not complain, but ffplay exits immediately, and Meet fails to detect /dev/video0 as a possible source.
3. if I unload and reload the module, behavior restarts as in step 1
4. if I load the module with devices=2 card_label="test,foo", the second and subsequent opens of the device from obs generate output on /dev/video1 which ffplay can capture. Meet, however, does not see neither of the two entries anymore.

This is happening on a 5.18 kernel. Not sure if this is a bug in v4l2loopback or obs. Could this commit have anything to do with the issue?

[BenBE]

This has been addressed in #477 and #485 as resolution to #470 and #484. I hope this resolves your problem.

[luigirizzo]

The release which shows the bug for me is 0.12.7, doesn't it already include the two patches you mention, #477 and #485 ?

[BenBE]

Unfortunately neither of those two patches has been backported into a stable release yet AFAIK.

[shoffmeister]

I can confirm that the current release version of v4l2loopback continues to provide a challenge to OBS on Linux.

On Fedora Linux 36, I am currently using a locally built portable version of OBS with a patch applied (https://github.com/obsproject/obs-studio/pull/7078) to address this. This allows me to run OBS 28 just fine.

[polarathene]

Unfortunately neither of those two patches has been backported into a stable release yet AFAIK.

Is there something blocking that?

I'm only aware of this older issue that was blocking releases in the past for a stale WIP PR (which now appears to be deferring to PipeWire / libcamera).

There was a newer release request issue raised from what looks like Ubuntu packagers requesting to include some commits, the project maintainer responded to that but still expressed that blocking concern from the older (still open) release request issue (#398).

The maintainer didn't continue to engage in the discussion after their comment though, I guess they're very busy? (totally understand that!)

Perhaps v4l2loopback could be moved into an Github organization, sharing access with some trusted contributors? PRs can be configured to require more than one approval to merge if that helps further establish trust_)

---

I was a bit confused seeing the commits in the main branch from June, with the 0.12.7 release having commits from August present, but excluding other commits in main branch, notably fixes you've worked on and had merged.

Is this a decision up to @umlaeute to make? Is it just a matter of cherry-picking the commits?

---

For OBS users, it seems that'll be resolved with the upcoming 28.1 release.

Otherwise usage elsewhere may require building this kernel module from the git main branch until a new release is available, or manually working around the issue with sudo rmmod v4l2loopback (before I had time to investigate why a system update broke the camera functionality, I'd been relying on restarting the entire system as a workaround :cry: ).

[mrsteve0924]

Otherwise usage elsewhere may require building this kernel module from the git main branch

building from main branch solved the OBS issue for me

[bestouff]

rmmod + modprobe works.

[umlaeute]

seems to work with obs-29.0.2 and current main

[shoffmeister]

FWIW, things should have been working with OBS for some time, as of (my) commit https://github.com/obsproject/obs-studio/pull/7078/commits/f8f64016f6d3c5899aca0a9db3bcc1bb4b8ae0fc which worked around the (then) behaviour of the v4l2loopback module.