[Bug 719902] New: 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

           Summary: video: Multi-byte-per-component video formats,
                    endianness and component order
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: slomo at coaxion.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Currently ARGB64 and AYUV64 are defined in native-endianness, while
I420_10BE/LE have different variants for the different endianness. Should we
make this more consistent, deprecate the ARGB64 format and add two new ones for
it?

I'm also going to add a ARGB64_F16 video format soonish, for which the same
question would apply. Currently I only need it in native endianness, but it's a
question of consistency.


Also should we add variants for the different component orders? E.g. a RGBA64,
BGRA64, ABGR64? Variants with x instead of A? Or do we expect elements to do
the conversion themselves to the correct order? What I currently would need
would be a RGBA64_F16 to allow zerocopy, but that would of course be
inconsistent with ARGB64 :)

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