[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 #8 from Wim Taymans <wim.taymans at gmail.com> 2013-12-30 10:12:42 UTC ---
(In reply to comment #7)
> If nobody complains, I'll:
> 
> 1) Make the endianness flag for RGB16/15 depending on the native endianness

Yes, at least

> 2) Add ARGB64_F16 (native endianness)

How about we add (and only add) ARGB64_F16LE on little endian and ARGB64_F16BE
on big endian at least we can then later add the other endianness without
causing trouble?

We could do GST_VIDEO_FORMAT_ARGB_F64 = _GST_VIDEO_FORMAT_NE(ARGB_F64) like we
do with audio.

> 3) Maybe: Deprecate endianness-aware variants of I420_10* and GBR_10* and
> replace them by a native endianness variant? Note that libav has LE/BE variants
> of these. And also variants for 9, 11 and 12 bits.

also note that ffmpeg only does native audio formats while we list all LE/BE
variants

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