[Bug 719902] video: Multi-byte-per-component video formats, endianness and component order

[GStreamer (bugzilla.gnome.org)]

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

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #5 from Wim Taymans <wim.taymans at gmail.com> 2013-12-23 16:43:13 UTC ---
You don't have to add variants for ARGB, ABGR, RGBA, BGRA, these formats have
bit depths of 8 and so ARGB is uniquely defined in all endiannesses.

For the ones with component sizes > 8 (I420_10, ..) you need to know how to
read the component and there is a flag in the info that describes this. For
RGB16, we always have LE endianness (but we don't read it like this currently,
we read it in native endianness..)

The endianness is of course essential for exchanging raw formats between
architectures of different endianness. If there is no I420_10LE and BE variant,
it would be impossible to exchange this format between LE and BE machines.

If there is a format in the wild that specifies the endianness explicitly, I
would add a variant for it or else you would not be able to handle this on some
architectures.

To exchange raw formats, I would again only make those formats that you find in
real files and not care about exchanging raw formats. For the weird ones you
either need to convert them to something portable or (when possible) exchange
for the equivalent formats (ARGB -> BGRA), IMHO.

I also think I420_10LE and BE is a bit overkill, we should probably have kept
the native ones only.

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