v4l2loopback and kernel-3.7
hi all,
i'm currently maintainer of the "v4l2loopback" device [1], a virtual video device that allows applications to share video-streams via the v4l2 API (each device being V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_VIDEO_OUTPUT).
now (unfortunately for someone maintaining a driver) i have not been following development of the linux-kernel very closely (mainly using debian unstable kernels myself), but some of my users do. it seems that with newer kernel-versions the functionality for video-output modules have been somehow removed from the kernel (3.7.1 has been confirmed to make troubles, whereas 3.6.10 still works).
i'd like to inquire, what happened in/to the mainstream kernel, and what's the supposed way to proceed for a virtual video device like mine. (i naively ask the question here, as i'm a bit afraid of kernel-dev mailing list :-))
what's more, if the v4l2-taskforce would be interested to take over a kernel-module that - to my knowledge - is currently the only feasible way on linux to exchange live video streams between applications, we might talk about that :-)
fgasdmr
IOhannes
Quoted 1 line · On 2013-01-24 16:59, forum::für::umläute wrote:
hi all,
just in case: please CC me, as i'm not subscribed to this list (yet).
gfadmsr
IOhannes
Quoted 29 lines
i'm currently maintainer of the "v4l2loopback" device [1], a virtual video device that allows applications to share video-streams via the v4l2 API (each device being
V4L2_CAP_VIDEO_CAPTURE|V4L2_CAP_VIDEO_OUTPUT).now (unfortunately for someone maintaining a driver) i have not been following development of the linux-kernel very closely (mainly using debian unstable kernels myself), but some of my users do. it seems that with newer kernel-versions the functionality for video-output modules have been somehow removed from the kernel (3.7.1 has been confirmed to make troubles, whereas 3.6.10 still works).
i'd like to inquire, what happened in/to the mainstream kernel, and what's the supposed way to proceed for a virtual video device like mine. (i naively ask the question here, as i'm a bit afraid of kernel-dev mailing list :-))
what's more, if the v4l2-taskforce would be interested to take over a kernel-module that - to my knowledge - is currently the only feasible way on linux to exchange live video streams between applications, we might talk about that :-)
fgasdmr
IOhannes
Quoted 13 lines · On Thu January 24 2013 16:59:36 forum::für::umläute wrote:
hi all,
i'm currently maintainer of the "v4l2loopback" device [1], a virtual video device that allows applications to share video-streams via the v4l2 API (each device being
V4L2_CAP_VIDEO_CAPTURE|V4L2_CAP_VIDEO_OUTPUT).now (unfortunately for someone maintaining a driver) i have not been following development of the linux-kernel very closely (mainly using debian unstable kernels myself), but some of my users do. it seems that with newer kernel-versions the functionality for video-output modules have been somehow removed from the kernel (3.7.1 has been confirmed to make troubles, whereas 3.6.10 still works).
Quoted 4 lines
i'd like to inquire, what happened in/to the mainstream kernel, and what's the supposed way to proceed for a virtual video device like mine. (i naively ask the question here, as i'm a bit afraid of kernel-dev mailing list :-))
In 3.7 the vfl_dir field was added to struct video_device. For output devices this has to be set to VFL_DIR_TX. For devices that do both capture and output it has to be set to VFL_DIR_M2M (memory-to-memory). Otherwise the v4l2 core will assume that it is a capture device and disable any output support.
Quoted 5 lines
what's more, if the v4l2-taskforce would be interested to take over a kernel-module that - to my knowledge - is currently the only feasible way on linux to exchange live video streams between applications, we might talk about that :-)
Personally I am all for that, but I know Mauro has (had?) reservations about it. Looking at the code it would also be a fair amount of work to get it ready for inclusion in the kernel.
Frankly, I wonder if much of the functionality isn't already part of the mem2mem_testdev driver.
Regards,
Hans