Hi! 2016-11-17 19:34 GMT+01:00 Ronald S. Bultje <rsbul...@gmail.com>: > > On Thu, Nov 17, 2016 at 1:06 PM, Kieran Kunhya <kier...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
