GNOME Bugzilla – Bug 630888
v4l2sink does not cope with v4l2loopback kernel module
Last modified: 2010-10-10 09:24:46 UTC
there is a kernel module "v4l2loopback" (http://github.com/umlaeute/v4l2loopback/) that allows to pipe video-data into other applications by means of a loopback device. the receiving application only needs to be able to read v4l2 devices. unfortunately, it is currently not possible to write into the device using the GStreamer's "v4l2sink" element. i strongly suspect, that the problem is, that the loopback module accepts any format, and thus the VIDIOC_G_FMT ioctl in v4l2sink doesn't return anything meaningful (the loopback module's format should be set by the sending application rather than tell the sender what it should send), and therefore caps-negotiation fails. it would be nice if there was some way to force v4l2sink to use a certain format (i tried with capsfilter, but without success)
for what it is worth, there is also a "v4l2loopback" GStreamer element, which works (soleley) with the loopback device (a fork can be found at http://github.com/umlaeute/gst-v4l2loopback) of course it would be nicer, if the standard v4l2sink could handle v4l2loopback devices
If VIDIOC_G_FMT fails this means, that the loopback device did not support the selected format. That's a real problem then... v4l2sink gets the list of supported formats by using the VIDIOC_ENUM_FMT ioctl. For the sink it should maybe assume that all possible V4L2 formats are supported if nothing is returned here (or even better if it's possible to detect that this is a loopback device). A capsfilter before the v4l2sink should work in any case though, just make sure that you have appropiate converters before the capsfilter.
thanks for the hints. i have fixed the kernel-module so it now properly returns a list of supported formats with VIDIOC_ENUM_FMT. after some more hacking, the loopback device is now working with the "v4l2sink" element. anyhow, while doing so, i discovered some minor issues with the v4l2sink element, for which i attach 2 patches.
Created attachment 172004 [details] [review] protect against NULL pointer access in v4l2sink.c there is a possible NULL-pointer access in gst_v4l2sink_change_state() (which i triggered several times...)
Created attachment 172005 [details] [review] don't call ioctlS for VIDEO_OVERLAY if not explicitely requested the current v4l2sink assumes that the device supports overlays (for which i see no reason); it always calls VIDIOC_*_FMT for a VIDEO_OVERLAY buffer, which eventually fails (if the driver does not support overlay). the attached patch only uses G/S_FMT on VIDEO_OVERLAY if the user explicitely requested overlay-features by setting one of the "overlay-*" properties.
commit b37845dac0ebb71ddfa17a2d1e55ef9cb12c67fd Author: IOhannes m zmölnig <zmoelnig@iem.at> Date: Sat Oct 9 14:14:27 2010 +0200 v4l2sink: Only get/set overlay params if needed it's perfectly ok for a video output device to not have overlay capabilities this patch removes the need to get/set the overlay parameters if the user does not explicitely request one of the overlay properties commit 4ba93e9f1a460452a9baaff4038d6d99cf387627 Author: IOhannes m zmölnig <zmoelnig@iem.at> Date: Thu Sep 30 15:28:23 2010 +0200 v4l2sink: Protect against NULL-pointer access gst_v4l2sink_change_state() would free the pool without checking whether the was a valid pool...