GNOME Bugzilla – Bug 520092
v4l2src proposed patches
Last modified: 2008-05-26 15:39:29 UTC
I ran into several problems while trying to get three quite different v4l2 cameras to work under gstreamer. For me, solving these required some changes to the existing code, and I attach some proposed patches with the following explanations: 1) Patch to gstv4l2src.c for supporting V4L2_PIC_FMT_SBGGR8, V4L2_PIX_FMT_GREY, V4L2_PIX_FMT_NV12, V4L2_PIX_FMT_NV21, V4L2_PIX_FMT_YYUV and V4L2_PIX_FMT_HI240 I am only able to test with V4L2_PIC_FMT_SBGGR8, but the others are quite similar. There was an error whereby if some of these codes were not defined, case statements were still present (fixed). Also some minor enhancement of debugging information in the case of unknown codes encountered. 2) Patch to v4l2src_calls.c This patch is a bit more complicated. a) In gst_v4l2src_probe_caps_for_format_and_size, removed unused variable. Corrected a problem when a device allowed VIDIOC_ENUM_FRAMESIZES but did not implement VIDIOC_ENUM_FRAMEINTERVALS. In this instance, the routine now returns a range [ 0/1, 100/1 ]. Also changed the debug message from "Failed" to "Unable". b) In gst_v4l2src_probe_caps_for_format, there is a comment explaining how capabilities are sorted to present capabilities in the sequence "highest resolution" to "lowest resolution". This was being done for V4L2_FRMSIZE_TYPE_DISCRETE, but not being done for V4L2_FRMSIZE_STEPWISE and V4L2_FRMSIZE_CONTINUOUS. I fixed that. Also in this routine, there was a separate problem which adversely affected any driver which doesn't implement VIDIOC_ENUM_FRAMESIZE. The data usually returned from this function is the only direct way to determine the framerate for the current input of the device, so when this failed, the framerate capability could not be correctly "fixated". To solve this, I added code to attempt to find the correct framerate from the current "norm". This works very successfully for me, but this should be reviewed by others to assure it is philosophically acceptable. c) In gst_v4l2src_set_capture, there was another problem concerning frame intervals / framerates. Under the V4L spec, the stream params returned by VIDIOC_G_PARM may or may not contain the frame interval, and may or may not be able to change it. I made a small enhancement to the code to avoid the problem whenever possible, but in case the program wants to change it, and the device refuses, I removed the error condition and left only a warning.
Created attachment 106466 [details] [review] proposed patch for gstv4l2src.c
Created attachment 106467 [details] [review] proposed patch for gstv4l2_calls.c
Added the support for NV12 and NV21 and more bayer support. The other formats we don't have caps for yet in gstreamer so there is no point in trying to make random caps. Patch by: William M. Brack <wbrack at mmm dot com dot hk> * sys/v4l2/gstv4l2src.c: (gst_v4l2src_v4l2fourcc_to_structure), (gst_v4l2_get_caps_info): Add NV12, NV21 and bayer support. See #520092.
I chery-picked some of the second patch, some of the other code was already fixed in the latest CVS. This part deals with the frameinterval ioctl failures. Patch by: William M. Brack <wbrack at mmm dot com dot hk> * sys/v4l2/v4l2src_calls.c: (gst_v4l2src_probe_caps_for_format_and_size): If we fail to get the frame intervals, simply don't touch the framerates on the template caps instead of discarding the format. See #520092.
Patch by: William M. Brack <wbrack at mmm dot com dot hk> * sys/v4l2/v4l2src_calls.c: (gst_v4l2src_probe_caps_for_format): Fix potential caps leak. If we can't get the framerate with an ioctl, try to get it with the current norm. Fixes #520092.