[FFmpeg-devel] [RFC]lavc/ffv1dec: Scale msb-packed output to full 16bit

Carl Eugen Hoyos ceffmpeg at gmail.com
Thu Nov 17 22:10:34 EET 2016


Hi!

2016-11-17 19:34 GMT+01:00 Ronald S. Bultje <rsbultje at gmail.com>:
>
> On Thu, Nov 17, 2016 at 1:06 PM, Kieran Kunhya <kierank at obe.tv> wrote:

>> Furthermore I will be reverting this patch in two hours.
>
> There's no need to wait two hours, the patch is fundamentally wrong.

This is not a helpful comment.

> Carl, the reason the patch is wrong is that luma range does not scale up
> from 16<<n to (236<<n)-1, but from 16<<n to (236-1)<<n, where n is bpc-8.
> This is documented in numerous places, see e.g.
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx
> :
>
> "For example, if the white point of an 8-bit format is 235, the
> corresponding 10-bit format has a white point at 940 (235 × 4)."

This is indeed very difficult to understand: How is this related?

AV_PIX_FMT_GRAY was changed years ago after several users
protested that it did conform to above specification, since it doesn't
do now, the paragraph looks unrelated.
(AV_PIX_FMT_GRAY is full-scale as is AV_PIX_FMT_GRAY16)

More important:
My patch is not related to 10-bit output format, so above calculations
are also not related afaict.

> Your patch is therefore theoretically wrong. The correct behaviour in
> limited-range upscaling is indeed to leave the lower bits empty. For
> full-range, the lower bits might be filled if the intention is for the
> pixel value to be a representation of what the 16bit result would look
> like, but whether this belongs in a decoder or not is up for discussion.

Decoders tend to be used by video players and if white looks gray on a
screen, it doesn't make much sense to say "the player should have
worked-around this".

Carl Eugen


More information about the ffmpeg-devel mailing list