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
