RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/test/ref/repack_zimg.log

19 lines
334 B
Plaintext
Raw Normal View History

test: add tests for zimg RGB repacking This tests the RGB repacker code in zimg, which deserves to be tested because it's tricky and there will be more formats. scale_test.c contains some code that can be used to test any scaler. Or at least that would be great; currently it can only test repacking of some byte-aligned-component RGB formats. It should be called repack_test.c, but I'm too lazy to change the filename now. The idea is that libswscale is used to cross-check the conversions performed by the zimg wrapper. This is why it's "OK" that scale_test.c does libswscale calls. scale_sws.c is the equivalent to scale_zimg.c, and is of course worthless (because it tests libswscale by comparing the results with libswscale), but still might help with finding bugs in scale_test.c. This borrows a sorted list of image formats from test/img_format.c, for the same reason that file sorts them. There's a slight possibility that this can be used to test vo_gpu.c too some times in the future.
2019-11-09 00:50:46 +00:00
0bgr using gbrp
0rgb using gbrp
zimg: add alpha support libzimg recently added direct alpha support and new API for it. (The API change is rather minimal, and it turns out we can easily support old and new zimg versions.) This does not support _all_ alpha formats. For example, gray + alpha is not supported yet, because my stupid design in the zimg wrapper would require a planar gray + alpha format, while ffmpeg provides only a packed one.
2020-02-09 18:16:54 +00:00
abgr using gbrap
argb using gbrap
test: add tests for zimg RGB repacking This tests the RGB repacker code in zimg, which deserves to be tested because it's tricky and there will be more formats. scale_test.c contains some code that can be used to test any scaler. Or at least that would be great; currently it can only test repacking of some byte-aligned-component RGB formats. It should be called repack_test.c, but I'm too lazy to change the filename now. The idea is that libswscale is used to cross-check the conversions performed by the zimg wrapper. This is why it's "OK" that scale_test.c does libswscale calls. scale_sws.c is the equivalent to scale_zimg.c, and is of course worthless (because it tests libswscale by comparing the results with libswscale), but still might help with finding bugs in scale_test.c. This borrows a sorted list of image formats from test/img_format.c, for the same reason that file sorts them. There's a slight possibility that this can be used to test vo_gpu.c too some times in the future.
2019-11-09 00:50:46 +00:00
bgr0 using gbrp
bgr24 using gbrp
bgr48 using gbrp16
zimg: add support for big endian input and output 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*).
2020-04-12 20:14:55 +00:00
bgr48be using gbrp16
zimg: add alpha support libzimg recently added direct alpha support and new API for it. (The API change is rather minimal, and it turns out we can easily support old and new zimg versions.) This does not support _all_ alpha formats. For example, gray + alpha is not supported yet, because my stupid design in the zimg wrapper would require a planar gray + alpha format, while ffmpeg provides only a packed one.
2020-02-09 18:16:54 +00:00
bgra using gbrap
bgra64 using gbrap16
zimg: add support for big endian input and output 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*).
2020-04-12 20:14:55 +00:00
bgra64be using gbrap16
test: add tests for zimg RGB repacking This tests the RGB repacker code in zimg, which deserves to be tested because it's tricky and there will be more formats. scale_test.c contains some code that can be used to test any scaler. Or at least that would be great; currently it can only test repacking of some byte-aligned-component RGB formats. It should be called repack_test.c, but I'm too lazy to change the filename now. The idea is that libswscale is used to cross-check the conversions performed by the zimg wrapper. This is why it's "OK" that scale_test.c does libswscale calls. scale_sws.c is the equivalent to scale_zimg.c, and is of course worthless (because it tests libswscale by comparing the results with libswscale), but still might help with finding bugs in scale_test.c. This borrows a sorted list of image formats from test/img_format.c, for the same reason that file sorts them. There's a slight possibility that this can be used to test vo_gpu.c too some times in the future.
2019-11-09 00:50:46 +00:00
rgb0 using gbrp
rgb24 using gbrp
rgb48 using gbrp16
zimg: add support for big endian input and output 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*).
2020-04-12 20:14:55 +00:00
rgb48be using gbrp16
zimg: add alpha support libzimg recently added direct alpha support and new API for it. (The API change is rather minimal, and it turns out we can easily support old and new zimg versions.) This does not support _all_ alpha formats. For example, gray + alpha is not supported yet, because my stupid design in the zimg wrapper would require a planar gray + alpha format, while ffmpeg provides only a packed one.
2020-02-09 18:16:54 +00:00
rgba using gbrap
rgba64 using gbrap16
zimg: add support for big endian input and output 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*).
2020-04-12 20:14:55 +00:00
rgba64be using gbrap16