[gstreamer-bugs] [Bug 521392] New: Proposed patches for bayer2rgb encoding

[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=521392

  GStreamer | gst-plugins-bad | Ver: HEAD CVS
           Summary: Proposed patches for bayer2rgb encoding
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        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 wanted to use this plugin for decoding the data produced by a v4l2 camera (a
very cheap USB model) and found it didn't work. When I looked into the code, I
found that reason it wasn't working was because the routine assumed a format of
RGGB, but the (standard) output from v4l2 is BGGR.  Additionally, the
conversion being done did not include any interpolation, and there were several
areas which were not really a "finished product".

On the first point (format), I spent some time searching the internet to find
out what common formats were used for streaming (video) data.  The conclusion I
came to was that the v4l2 format V4L2_PIX_FMT_SBGGR8 is the only one with any
common usage.  The v4l2 project has assigned a fourcc code of BA81 for this.

In order to allow gstreamer to properly handle this format, I am attaching a
.tgz file containing two proposed patches.  The first is a trivial patch to
videotestsrc.c which changes its output for this format, as well as the fourcc
code which it produces.  The second is a very substantial patch to
gstbayer2rgb.c which replaces all of the previous conversion logic with
routines to transform with interpolation.  There are a large number of comments
within the patched code to describe what I (think I) am doing.  The code is not
particularly clever or efficient, but it seems to be working well, and has been
extensively tested with a combination of gdb and valgrind using test data from
my patched version of videotestsrc, as well as with my (cheap) camera.  In view
of the fact that this format is certainly not widely used, and it is unlikely
that the transformation efficiency will be a constraint, I didn't feel it would
be worthwhile to spend more time improving that.  I also cleaned up all of the
areas of the routine which I found questionable, and added the ability to
produce a wide variety of RGB formats.

If others feel that some improvement is needed, or other features really should
be added, I would be happy to do any further work that is required.  Otherwise,
I feel the enclosed patch is a substantial improvement to the existing code,
and would urge that it be adopted.


-- 
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=521392.