[gstreamer-bugs] [Bug 520092] New: v4l2src proposed patches

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=520092

  GStreamer | gst-plugins-good | Ver: HEAD CVS
           Summary: v4l2src proposed patches
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: wbrack at mmm.com.hk
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=520092.