[Bug 693666] New: bayer: Caps for 16-bit Bayer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=693666
  GStreamer | gst-plugins-bad | unspecified

           Summary: bayer: Caps for 16-bit Bayer
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: oss at nvl.army.mil
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Currently in both 0.10 and 1.0 the caps for Bayer are limited to 8-bits,
however 16-bit is quite common, and I've seen 12-bit as well. I have seen three
different ways to extend this to at least 16-bit:

1) I have used video/x-raw-bayer,format=(string){gbrg16, bggr16, grbg16,
rggb16} so as to not conflict with the current expectation of 8-bit data from
bayer2rgb and rgb2bayer. Alternatively, something like video/x-raw-bayer16
could work as well, if not an elegant solution.

2) gst-plugins-elphel has a "bpp" property in their bayer2rgb2 element which
when true assumes the data to be 16-bit, otherwise 8-bit:
http://code.google.com/p/gst-plugins-elphel/source/browse/trunk/bayer2rgb2/src/gstbayer2rgb2.c#267

3) Aravis simply adds bpp and depth to the video/x-raw-bayer caps:
http://git.gnome.org/browse/aravis/tree/src/arvmisc.c#n635

#2 is clearly not a good solution since it moves the bpp out of the caps. #3 is
the most robust solution, though it would mean some applications would break,
though if supporting elements always prioritize bpp=8,depth=8, then breakage
would be minimal I believe. If changing the existing caps are unacceptable,
then we'd have to go with #1.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.