mirror of
https://github.com/mpv-player/mpv
synced 2024-12-23 07:12:39 +00:00
a8b84c9a1a
One of the extremely annoying dumb things in ffmpeg is that most pixel formats are available as little endian and big endian variants. (The sane way would be having native endian formats only.) Usually, most of the real codecs use native formats only, while non-native formats are used by fringe raw codecs only. But the PNG encoders and decoders unfortunately use big endian formats, and since PNG it such a popular format, this causes problems for us. In particular, the current zimg wrapper will refuse to work (and mpv will fall back to sws) when writing non-8 bit PNGs. So add non-native endian support to zimg. This is done in a fairly "generic" way (which means lots of potential for bugs). If input is a "regular" format (and just byte-swapped), the rest happens automatically, which happens to cover all interesting formats. Some things could be more efficient; for example, unpacking is done on the data before it's passed to the unpacker. You could make endian swapping part of the actual unpacking process, which might be slightly faster. You could avoid copying twice in some cases (such as when there's no actual repacker, or if alignment needs to be corrected). But I don't really care. It's reasonably fast for the normal case. Not entirely sure whether this is correct. Some (but not many) formats are covered by the tests, some I tested manually. Some I can't even test, because libswscale doesn't support them (like nv20*).
19 lines
334 B
Plaintext
19 lines
334 B
Plaintext
0bgr using gbrp
|
|
0rgb using gbrp
|
|
abgr using gbrap
|
|
argb using gbrap
|
|
bgr0 using gbrp
|
|
bgr24 using gbrp
|
|
bgr48 using gbrp16
|
|
bgr48be using gbrp16
|
|
bgra using gbrap
|
|
bgra64 using gbrap16
|
|
bgra64be using gbrap16
|
|
rgb0 using gbrp
|
|
rgb24 using gbrp
|
|
rgb48 using gbrp16
|
|
rgb48be using gbrp16
|
|
rgba using gbrap
|
|
rgba64 using gbrap16
|
|
rgba64be using gbrap16
|