Multiple consumers for single video capture device

[alopatindev]

I want to allow any number of consumers for single video capture device, just like v4l2loopback does. This will allow easy intuitive interaction of any programs that access webcams: no need to check whether specific device is captured right now, no need to fight program that fails to release capture device for some reason, etc.

Is it currently possible with akvcam? If not, is it planned to support, or it's never gonna be implemented due to some limitation/design choice?

Thanks.

[hipersayanX]

Is it currently possible with akvcam?

No, isn't possible

If not, is it planned to support

No and never

or it's never gonna be implemented due to some limitation/design choice?

The device opening is handled by v4l2_fh_open as it's supposed to be implemented according to V4L2 developers, many parts of v4l2loopback code are implemented in a very hacky way.

If you want to stream the same frames to many clients, create as many capture device as the clients you want to send the frames, and connect one output to all of them.

[alopatindev]

Thanks for explanation, got it, that must be a fundamental V4L2 limitation:

1.1.3. Multiple Opens

V4L2 devices can be opened more than once.

...

Once an application has allocated the memory buffers needed for streaming data (by calling the ioctl VIDIOC_REQBUFS or ioctl VIDIOC_CREATE_BUFS ioctls, or implicitly by calling the read() or write() functions) that application (filehandle) becomes the owner of the device. It is no longer allowed to make changes that would affect the buffer sizes (e.g. by calling the VIDIOC_S_FMT ioctl) and other applications are no longer allowed to allocate buffers or start or stop streaming. The EBUSY error code will be returned instead.

At least for sound devices we have dsnoop/dmix, but nothing convenient for webcams. That's such a shame V4L2 was designed this way 🤦

I'm not sure how often it's been asked yet, but perhaps it's useful to add this question to FAQ.

[hipersayanX]

Thanks for explanation, got it, that must be a fundamental V4L2 limitation:

Exactly, did not remembered that part of the documentation, but that was the explanation. v4l2loop can do that, but it do it in a hacky way, while I prefer to play with the standards.

At least for sound devices we have dsnoop/dmix, but nothing convenient for webcams.

But there are, that was the reason why Pipewire was created.

https://blogs.gnome.org/uraeus/2018/01/26/an-update-on-pipewire-the-multimedia-revolution-an-update/

[alopatindev]

Looks like PipeWire emulate v4l2 layer using LD_PRELOAD and it must be working at least for some applications. Interesting, I was suspecting they do something like that with cameras. I'll check it out how it works, thanks.