[gstreamer-bugs] [Bug 620412] [video] Incomplete support for 15 and 16 bit RGB and BGR formats

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=620412
  GStreamer | gst-plugins-base | git

--- Comment #13 from martin.bisson at gmail.com 2010-06-08 05:54:29 UTC ---
After a little bit more research, here are my thoughts.

The simplest option would be to leave RGB15/16 as it is right now, which is
with host (or BYTE_ORDER) endianness.  If that option is chosen, it means that
the patch can be accepted, because it doesn't modify the caps or the
interpretation of the data.  It just adds new GstVideoFormat enums and adds the
missing support for the parsing of those already existing caps.

The endianness topic discussed here, althought relevant, is imho a little bit
out of the scope of the proposed fix.  Adding proper endianness support could
be another (different) feature request that would involve more work:

- New pixel formats might be defined, such as {RGB,BGR}_{15,16}_{LE,BE}
- New routines would be added to ffmpegcolorspace
- Existing plugins would have to be modified (for instance, videoscale assumes
host endianness for RGB565 format, because that's the way it is right now)
- Etc.

So if the __current__ behavior regarding RGB565 and RGB555 formats is
acceptable, I suggest incorporating the patch and leaving the more robust
endianness handling to another request (which, I agree with David, would be
very low priority).
Otherwise, it means that to get this patch in, I will implement complete and
correct support for those formats right away.

I tend to lean towards the first option.  Any thoughts?

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