On Sat, 9 Feb 2013, Michael Niedermayer wrote:
Module: libav
Branch: master
Commit: d6d5ef5534d582f9dbaf18ac2605cf5bb72cd821
Author: Michael Niedermayer <[email protected]>
Committer: Derek Buitenhuis <[email protected]>
Date: Fri Jan 25 23:05:48 2013 +0100
sws: GBRP9, GBRP10, and GBRP16 output support
Signed-off-by: Michael Niedermayer <[email protected]>
Signed-off-by: Derek Buitenhuis <[email protected]>
---
libswscale/output.c | 28 +++++++++++++++++++++++++---
libswscale/utils.c | 16 ++++++++--------
tests/ref/lavfi/pixdesc | 6 ++++++
tests/ref/lavfi/pixfmts_copy | 6 ++++++
tests/ref/lavfi/pixfmts_null | 6 ++++++
tests/ref/lavfi/pixfmts_scale | 6 ++++++
tests/ref/lavfi/pixfmts_vflip | 6 ++++++
7 files changed, 63 insertions(+), 11 deletions(-)
The GBRP16 output is broken. In sws_init_swScale_c, other horizontal
scalers (hScale8To19_c or hScale16To19_c) are picked if the destination
format has over 10 bits per component, and these ones write data into
intermediate buffers as 32 bits per value, while yuv2gbrp_full_X_c only
reads it assuming that the intermediate buffer is 16 bit.
If you try e.g. "avconv -i foo -frames 1 -an -vcodec rawvideo -pix_fmt
gbrp16le -f rawvideo test.raw" and then playing it back with "avplay -f
rawvideo -pixel_format gbrp16le -video_size WxH test.raw", you'll see that
it's garbled. This also reflects the fate test failures on big-endian
machines in these tests.
If I read the existing code correctly, to support this case you'd need to
do a separate version of yuv2gbrp_full_X_c that reads the input
intermediate buffers as 32 bits instead of 16 (and does the appropriate
shifts) - possibly other tweaks and quirks as well. Short of doing that,
I'd suggest to just disallow the conversion to 16 bpp.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
