On Wed, Nov 29, 2017 at 7:40 PM, Neil Birkbeck <neil.birkb...@gmail.com> wrote:
> >> >> 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 range 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 scale=-1:-1:in_range=mpeg:out_range=jpeg,format=yuv422p10le,histogram 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 > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
