[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