On Mon, 24 Apr 2017 18:34:41 +0200 Luca Barbato <lu_z...@gentoo.org> wrote:
> On 4/24/17 5:37 PM, wm4 wrote: > > 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. > > We have a tiny amount of codecs with the issue (e.g. tiff), we would > have some command line incompatibility and probably we could just add a > be/le option for the specific codecs instead of having the RAW encoder > follow PCM in having all the possible combinations explicitly set. Not sure what the command line matters. If users explicitly force the pixfmts for encoders which can't select the target pixfmt implicitly? Maybe be/le formats could be made aliases at some point, although that doesn't really seem like a good solution. > An open question could be what's the proper way to send the information > from the demuxer (e.g. mkv with the new raw support) to our swapping raw > decoder. Like with sample formats: as a codec, or codec parameter. > I need to think a bit more if breaking compatibility would impact the > user in painful ways or it could be bearable. > > Looking at -sample_fmts and -pix_fmts output I must say I find it quite > interesting :) _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
