Dynamic creation of video devices

[sesse]

Hi,

This is a feature request.

I'm looking for a way to programmatically create new video devices; ie., an ioctl or similar that I can use to create a new video device on the fly, with a given title, max_width etc.. The reason is fairly simple; it would make it much simpler for the user to just start an output session from my program (a video mixer) and have it show up in the web browser, which just enumerates /dev/video* paths anyway. Would it be possible?

[azertyalex]

I'm also in need of this feature. Are there plans or maybe some implementation already?

[umlaeute]

no there's no implementation.
why can't you just create the number of devices you need beforehand?

modprobe v4l2loopback devices=8

[sesse]

How would I know which devices are free, which ones are real capture devices and which ones are v4l2loopbacks but in use from other instances/programs? How can I set the title of it, so that the user knows which one to pick? How can I set exclusive_caps=1 on it, so that I don't have to tell the user to do that?

[azertyalex]

In my case I could actually need hundreds (or more) devices, one for each container I spawn. For me having the option to create devices on the fly, without having to delete the previous, would be a clean solution in my project.

[umlaeute]

@sesse how would you do that when creating devices on the fly?

[sesse]

I don't know what the appropriate kernel interface is, but just assume for the same of the argument that there's a /dev/v4l2loopback that I can open and connect to, the API would perhaps look something like this:

struct v4l2loopback_opt opt;
memset(&opt, 0, sizeof(opt));
opt.max_width = 1280;
opt.max_height = 720;
opt.exclusive_caps = 1;
opt.title = "Name of my application";

int fd = open("/dev/v4l2loopback", O_RDWR);
ioctl(fd, V4L2_CREATE_LOOPBACK_DEVICE, &opt);

// Now, /dev/videoN is created, and fd works as if you just opened it for output

Does that make sense?

[normanr]

That's very much how /dev/ptmx is the pseudoterminal master and /dev/try/* are the slaves. It means you don't have to be root in order to configure the device's settings.

[ShayBox]

Some way to create and delete devices is required, as it is you can only create and delete by loading and unloading the kernel module, which isn't something a userspace program should have to do to create a device to use, and what if multiple programs installed need to create a device, one program loads the module, another has to unload and load it again which deletes the first programs device, this has lead to programs straight up forking and modifying the v4l2loopback driver just to spawn their own device like, Ex. Droidcam. This isn't just a driver users use now, it's being used by programs which need to create and delete devices.

[umlaeute]

this has lead to programs straight up forking and modifying the v4l2loopback driver just to spawn their own device like, Ex. Droidcam

afaict, the only things these forks do are just renaming the module, so you can load the driver multiple times.
but that doesn't solve any problem.

This isn't just a driver users use now, it's being used by programs which need to create and delete devices.

well, you can of course still just pre-create all the devices you ever need. (unless you have an edge requirement like @azertyalex )
the default MAX_DEVICES is 8, which is probably too low for such a dynamic scenario. but if you set it to say 64, I don't think you will ever hit this limit in practice.

in any case, i'd like to hear more actual suggestions on how to implement such a feature (rather than more pleas to implement t "somehow")

[normanr]

in any case, i'd like to hear more actual suggestions on how to implement such a feature (rather than more pleas to implement "somehow")

sesse suggested to do it manually by sending an ioctl to a control device (the way that /dev/loop-control works, see loop(4)).

I suggested to do it automatically (like the pseudoterminal master /dev/ptmx does it, see ptmx(4)). Instead of exclusive_caps where the devices Capabilities change from "Video Output" to "Video Input", create a new device on-the-fly for the "Video Input" device. That way there's only ever one "Video Output" device, and exactly the same number of "Video Input" devices as there are available virtual streams. This only works if v4l2 allow multiple clients to write to a single "Video Output" device at a time, also you still need something like ptsname (probably a new ioctl) to find out what the "Video Input" device associated with the current output is.

[umlaeute]

i'd prefer @sesse 's suggestion, as it seems to be more flexible (although it requires explicit support by the application that wants to use it).

creating devices automatically seems to be impractical if you have to restart the producer.