[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

--- Comment #6 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2013-12-23 18:12:02 UTC ---
(In reply to comment #5)
> 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.

Agreed, I never suggested that but was talking about ARGB64 here :)

> 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 flag is per VideoFormatInfo though, not something you can change via the
caps or GstVideoInfo. So it's a fixed endianness per GstVideoFormat.

Should we change the flag for RGB16/15 to be set depending on the host
endianness btw?


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

Makes sense but what does this mean in the end for my case? You would add a
ARGB64_F16 (for consistency with ARGB64) and the only user of it so far would
reorder the bytes? I'm fine with that btw, I just think we should define this
somewhere instead of deciding on something different next time someone comes up
with such a thing ;)

If I had a time machine I would make the I420_10LE/BE things a I420_16 (without
LE/BE) btw as there's not much advantage in having 10 bits... other than that
we have to add variants for 9, 11, 12, ... 16 bits too now :)

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