exclusive_caps limits loopback device to a single producer open (e.g. with OBS)

[pmichaud]

Step 2: Environment:

• v4l2loopback version: 0.12.5 (via v4l2loopback-dkms package)
• kernel version: 5.11.0-31-generic
• Distribution (+version): Ubuntu 21.04

Step 3: Describe the problem:

When using exclusive_caps=1, the loopback device can only be opened once by a producer. If the producer closes the device, it's no longer available to be opened by a subsequent producer.

This is being observed by multiple people in e.g. obsproject/obs-studio#4808 ... once a Virtual Camera is started and stopped, it's not possible to re-start a virtual camera without removing and reloading the v4l2loopback device.

Steps to reproduce:

1. Load v4l2loopback with exclusive_caps=1
2. Run OBS studio. Select "Start Virtual Camera" (works)
3. Select "Stop Virtual Camera" (works)
4. Select "Start Virtual Camera" (fails with error message "Failed to start virtual camera")

Exiting OBS and removing/reloading the v4l2loopback module (via rmmod and modprobe) re-enables the virtual camera setting for another single instance.

Observed Results:

• When exclusive_caps=1 is not used, OBS can start/stop/restart the virtual camera without limitation.
• When exclusive_caps=1 is used, OBS can do one invocation of "Start Virtual Camera". Subsequent invocations fail until the v4l2loopback module is reloaded.

In more detail, here's the output of v4l2-ctl for a loopback device created without "exclusive_caps=1":

pmichaud@kiwi:~$ sudo v4l2-ctl -d /dev/video0 --all
Driver Info:
	Driver name      : v4l2 loopback
	Card type        : Dummy video device (0x0000)
	Bus info         : platform:v4l2loopback-000
	Driver version   : 5.11.22
	Capabilities     : 0x85200003
		Video Capture
		Video Output
		Read/Write
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x05200003
		Video Capture
		Video Output
		Read/Write
		Streaming
		Extended Pix Format
Priority: 2

This remains the same before, during, and after Virtual Camera output in OBS. As a result, OBS is able to start/stop/re-start the virtual camera an unlimited number of times. However, Chrome will not find the device as a valid video input (thus the reason for wanting exclusive_caps=1).

With exclusive_caps=1, the device starts out with:

pmichaud@kiwi:~$ sudo v4l2-ctl -d /dev/video0 --all
Driver Info:
	Driver name      : v4l2 loopback
	Card type        : Dummy video device (0x0000)
	Bus info         : platform:v4l2loopback-000
	Driver version   : 5.11.22
	Capabilities     : 0x85200002
		Video Output
		Read/Write
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x05200002
		Video Output
		Read/Write
		Streaming
		Extended Pix Format
Priority: 2

Once "Start Virtual Camera" is used in OBS, the device switches to:

pmichaud@kiwi:~$ sudo v4l2-ctl -d /dev/video0 --all
Driver Info:
	Driver name      : v4l2 loopback
	Card type        : Dummy video device (0x0000)
	Bus info         : platform:v4l2loopback-000
	Driver version   : 5.11.22
	Capabilities     : 0x85200001
		Video Capture
		Read/Write
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x05200001
		Video Capture
		Read/Write
		Streaming
		Extended Pix Format
Priority: 2

At this point consumers such as Chrome can see the device and receive the video stream.

When "Stop Virtual Camera" is selected in OBS, the device switches to:

pmichaud@kiwi:~$ sudo v4l2-ctl -d /dev/video0 --all
Driver Info:
	Driver name      : v4l2 loopback
	Card type        : Dummy video device (0x0000)
	Bus info         : platform:v4l2loopback-000
	Driver version   : 5.11.22
	Capabilities     : 0x85200000
		Read/Write
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x05200000
		Read/Write
		Streaming
		Extended Pix Format
Priority: 2

At this point the device is no longer available to be used by OBS or other producers for output (advertises neither OUTPUT nor CAPTURE capabilities). Subsequent attempts to "Start Virtual Camera" in OBS fail. The only mechanism found so far is to reboot or "rmmod v4l2loopback / modprobe v4l2loopback" to restart another loopback device.

Expected Results:

• When exclusive_caps=1 is present, a producer should be able to open and use the virtual loopback device even if it has been previously used/closed by a previous producer.
• Alternatively, there should be some way to reset the virtual loopback device to an OUTPUT state if there are no other producers currently writing to the device.

[vicamo]

This is a duplicate of #404.

[mowglixx]

after reading both #404 and this issue, they are different issues, one is getting no output, this guy just cant restart virtual cam after closing OBS without a reboot, an issue that I also have on Pop OS 22.04

System config

• Pop OS 22.04
• Kernel 5.17.5-76051705-generic
• OBS 27.2.4
• v4l2loopback-dkms 0.12.5-1ubuntu5
• v4l2loopback-source 0.12.5-1ubuntu5
• v4l2loopback-utils 0.12.5-1ubuntu5

The sudo modprobe -r v4l2loopback command works by removing the device so OBS can restart it (correctly), Ideally I've been thinking that a close hook could be used with this command to remove the virtual device when closing OBS.

possible solution but not ideal and would be a pain to implement across DE's either way I don't think this is an issue for the v4l2Loopback devs as this should be something that OBS could add to the .desktop file as part of installation...

opinion?

[BenBE]

The solution is to ioctl(loopfd, VIDEOIO_STREAMON); before doing any write(loopfd, …) call on the video device. Cf. floe/backscrub#133 (comment) for some information on the issue. I reported this issue as #470 about two months ago and didn't even get some reaction …

FWIW: I'm currently reviewing this kernel driver together with a few others and we already found further issues (currently preparing PRs downstream).

[umlaeute]

sorry i didn't answer on #470 yet, my time is limited (and developing v4l2loopback is not my day job).
i'm looking forward to any PRs.