I propose that we remove non-native endian pixfmt variations. Pixel
data would always be in native endianness (for example little endian on
a little endian system). All LE/BE formats would be dropped, and only
those without suffix would be left (mostly this implies moving the
current native-endian aliases to the proper pixfmt enum).

Some formats (mostly simply raw formats) actually store data in a
specific endianness - decoders and encoders would need to byte-swap
them.

Reasons pro:
- this would dramatically lower the number of pixfmts
- actually facilitates endian-agnostic code, instead of bothering every
  downstream application to deal with endianness explicitly
- most real decoders always output native endianness (for example, the
  h264 decoder will never output AV_PIX_FMT_YUV420P10BE on a little
  endian system)
- most processing requires the data in native endianness anyway, so
  there will be a conversion
- raw formats could byte-swap the data while it's still in the cache, so
  it wouldn't affect speed negatively (or even speed it up)
- pixfmt endianness isn't even well defined - for example,
  AV_PIX_FMT_RGBA64BE requires endian-swapping _after_ extracting
  components, while AV_PIX_FMT_BGR565BE requires endian-swapping
  _before_ extracting them (or some horrible mixture). Pixdesc doesn't
  describe the difference very well either, and an API user has to
  guess either endian-dependent access is needed, since only the big
  endian variants have a flag set (!)
- as such it would simplify pixdesc
- can remove non-native endian paths from libswscale
- audio formats are always native endian too

Reasons contra:
- have to change all the raw decoders
- codec copy with raw-only formats could become slower

Thoughts?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to