GNOME Bugzilla – Bug 768195
v4l2: Add support for device capability
Last modified: 2016-07-11 01:38:14 UTC
At some point in time (v4l2 in gst is very old) the capability structure in V4L2 was extended in a way it broke the ABI. A driver now uses the v4l2_capability::capabilities as the intersection of all capabilities by adding V4L2_CAP_DEVICE_CAPS flags there. In GStreamer, when this flag is present, we always want to look at the v4l2_capability::device_caps. A suggestion while porting would be to check if this flags is present, if not, copy the capabilities into device_caps. And then, everywhere in the code, replace capabilities with device_caps.
This issue can be seen when using gst v4l2{src,sink} elements and vivid. vivid is the Virtual Video Test Driver. $ gst-launch-1.0 v4l2src device=/dev/video1 ! v4l2sink device=/dev/video2 Fails to negotiate the caps, it should work when passing input_types=0x9 as module parameter to vivid. Looking at the logs with GST_DEBUG=*CAPS*:5 the only difference is in the colorimetry. colorimetry=(string)2:4:7:1 for v4l2src and colorimetry=(string)bt601 for v4l2sink.
Not sure it's a single bug here, the colorimetry issue would mean both src and sink aren't colorimetry compatible and you need a color converter. What type 0x9 ?
AFAIU input_types=0x9 asks vivid to create a TV tuner and an S-Video input for the first driver instance, 4 inputs are created by default according to the docs. To reproduce Luis's example I'm actually using: n_devs=2 node_types=0x1,0x100 num_inputs=1 input_types=0x2 num_outputs=1 output_types=0x0 for two instances, one S-Video input and one S-Video output. More info here: https://www.kernel.org/doc/Documentation/video4linux/vivid.txt
Created attachment 330767 [details] [review] v4l2: use opened device caps instead of physical device ones As expected this doesn't solve our colorimetry issue as the caps are at best case trimmed by the fact we are using the opened device instead of the physical device ones but should go a long way towars doing the right thing. Pretty rough patch only mildly tested. Please review.
Created attachment 330768 [details] [review] use caps intersect API instead of re-implementing GST_CAPS_INTERSECT_FIRST Bonus patch. Spotted this one while working around the caps handling code.
Attachment 330767 [details] pushed as 4b16b16 - v4l2: use opened device caps instead of physical device ones
And git bz failed on the second: commit dfdc15c548a0df957bfd9cb6944f4f099bd52b03 Author: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com> Date: Fri Jul 1 22:53:33 2016 -0700 v4l2src: use gst_caps_intersect_full in negotiate() And 1.8 commit d6c8cb63859368e7100b0002354ad742e4286eba Author: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com> Date: Sat Jul 2 01:56:07 2016 -0700 v4l2: use opened device caps instead of physical device ones The other one does not fix a bug, it's more like a cleanup, that's why I don't backport here.
Thanks.
Created attachment 331105 [details] [review] Fix capture of multiplanar devices This can be tested by doing: $ sudo modprobe vivid node_types=0x101 output_types=0x1 input_types=0x3 num_inputs=1 num_outputs=1 multiplanar=2 $ gst-launch-1.0 v4l2src device=/dev/video2 io-mode=dmabuf ! fakesink Before the patch: ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to enumerate possible video formats device '/dev/video2' can work with After the patch: Playback \o/ This happened because in sys/v4l2/gstv4l2object.c:gst_v4l2_object_fill_format_list(): if (v4l2_ioctl (v4l2object->video_fd, VIDIOC_ENUM_FMT, format) < 0) { Would send the wrong format, and the vivid driver would return ENOTTY since you can't do VIDIO_ENUM_FMT with single-planer on a multiplanar device, or viceversa.
Review of attachment 331105 [details] [review]: Haha, funny, we relied on this bug. Look good.
Review of attachment 331105 [details] [review]: commit eaa01071e0f5eea915edfd3510f6f3b71930576c Author: Luis de Bethencourt <luisbg@osg.samsung.com> Date: Fri Jul 8 17:28:19 2016 +0000 v4l2: fix multiplanar capture After switching to using V4L2_CAP_DEVICE_CAPS we lost support for multiplanar device types. After some research, it looks like vcap.capabilities treated the multiplanar flag of output and capture devices equally, but not the new device_caps. https://bugzilla.gnome.org/show_bug.cgi?id=768195
Apparently you also forgot to copy the new member device_caps in the function gst_v4l2_dup() used to create shared v4l2object. In M2M, we don't probe a second time the device, it would be a waste, we simply copy the information and adapt what need to be adapted. The broke every M2M elements.
Created attachment 331174 [details] [review] v4l2: Also copy device_caps in gst_v4l2_dup This fixes regression where M2M error out saying they have no output format (the V4L2 CAPTURE side).
Attachment 331174 [details] pushed as 5a9c0aa - v4l2: Also copy device_caps in gst_v4l2_dup