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

wm4 nfxjfg at googlemail.com
Thu Nov 17 22:34:07 EET 2016

On Thu, 17 Nov 2016 21:10:34 +0100
Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 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?

If you don't understand it, then why do you frivolously change the code?

> 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)

All YUV formats with more than 16 bit are "shifted", i.e. the lower
bits are always 0. Why should this be different for GRAY?

Unless you argue that GRAY is a RGB format.

> 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".

These video players are broken then. Or consider GRAY RGB.

More information about the ffmpeg-devel mailing list