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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Dec 30 02:54:53 PST 2013


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

--- Comment #12 from Wim Taymans <wim.taymans at gmail.com> 2013-12-30 10:54:51 UTC ---
(In reply to comment #11)
> That's true, yes. Do you think that's a problem? We can still add the
> endianness-aware versions later if needed without too much effort.

I think it's fine to only add the endianness that we currently need but we
should do it in such a way that we can easily and naturally add the other
endianness later and while we're at it, make it possible to exchange formats
between machines with different endiannesses (so endianness needs to be in the
format name somewhere).

If it would be possible to only define one of ARGB_F16LE or ARGB_F16BE
(depending on the endianness with an enum value mapping ARGB_F16 to the native
endian version) that would be ideal. I think that's what we do for audio 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.


More information about the gstreamer-bugs mailing list