On 4/24/17 7:19 PM, wm4 wrote: > 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?
The only use-case I'm considering plausible is generating a series of tiff images on a specific format that is required by some other program. > Maybe be/le formats could be made aliases at some point, although that > doesn't really seem like a good solution. Usability wise if we go to he 1-codec-per-raw-format it is the same as we do for pcm so it is sort of least surprising, if we go the option route we'd have an option for the raw encoder and tiff (and those I'm forgetting). A little more surprising, but we wouldn't clutter the codecs list with seldom used raw formats. >> 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'd rather use a codec parameter. lu _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
