[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