[FFmpeg-devel] [libav-devel] [RFC] M-bit to N-bit YUV conversions

madshi madshi at gmail.com
Thu Aug 25 08:47:23 CEST 2011

2011/8/25 Michael Niedermayer <michaelni at gmx.at>
> for 8->10 full range its a compromise between loosing
> the 3 brightst levels vs. some slight loss of smoothness.

There's a solution which has neither of these two

10bit = dither(8bit * 1023.0 / 255.0)

Of course that's strictly only for full range content, it
shouldn't be used for limited range content.

>> b) Should we distinguish between limited and full range YUV?
> for 8->10 it likely doesnt make a vissible difference

I'm not sure about that. At least the current way to use
unsigned byte duplication for chroma upscaling is probably
visible, because gray isn't gray after upscaling, anymore
(128 becomes 514).

If we don't want to distinguish between limited and full
range YUV, then we should definitely use simple << 2,
because that's what BT.709 recommends for limited range
content, and limited range YUV is the norm. Full range
YUV is the exception. So let's make the norm fulfill the
standards perfectly.

Best regards, Mathias.

More information about the ffmpeg-devel mailing list