[FFmpeg-devel] [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert

Neil Birkbeck neil.birkbeck at gmail.com
Thu Nov 30 06:08:40 EET 2017

On Wed, Nov 29, 2017 at 7:40 PM, Neil Birkbeck <neil.birkbeck at gmail.com>

>> If you are searching for a case where the patch makes a difference
>> one is:
>> ./ffmpeg -i ~/tickets/4493/AVCI100.mov out.nut
>> file should be here:
>> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/
>> if you want more cases that change, ill see if i can find more
> Perfect, thanks Michael. Let me check those samples out.
For that sample, I feel like it may be incorrectly tagged as pc/full.
Looking at the histogram of the original there is no data in low range and
a peak due to clipping near where you'd expect higher up for studio/mpeg
ffplay /tmp/AVCI100.mov -vf histogram

And scaling, treating the input as studio/mpeg and outputting full range,
stretches y to cover the entire range:
ffplay /tmp/AVCI100.mov -vf

This is a real concern though. I don't have a good feel for how many higher
bit depth files are incorrectly labelled as pc/full.

Here is a comparison of what I was described in the commit log.
> The naming of the files images are ${pixfmt}_${scaled}_${in_range}_${out_range}
> for with/without the patch:
> https://rawgit.com/nbirkbeck/ffmpeg-test-samples/master/
> color-range/results/report.html
> My concern was the yuv444p10_${scaled}_jpeg_mpeg (explicit settings), give
> different results than the implicit yuv444p10_unscaled_unspec_mpeg ones for
> high bit depth. And the high bit depth is results are in general different
> than the low bit depth ones.
> Report generated with:
> https://raw.githubusercontent.com/nbirkbeck/ffmpeg-test-
> samples/master/color-range/run.sh
> Using these test files:
> https://github.com/nbirkbeck/ffmpeg-test-samples/tree/
> master/color-range/data

More information about the ffmpeg-devel mailing list