[FFmpeg-devel] [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert
michael at niedermayer.cc
Thu Nov 30 05:19:21 EET 2017
On Tue, Nov 28, 2017 at 05:14:37PM -0800, Neil Birkbeck wrote:
> On higher bit depth YUV inputs with range metadata signaled as PC/full levels,
> this change makes the results of scaling without explicitly
> setting the input range on vf_scale as if it were explicitly set.
> For example, the results with implicit color settings from the frame:
> -vf scale=-1:-1:out_range=mpeg,format=yuv420p
> Are the same as the correct result when set explicitly in the scaler:
> -vf scale=-1:-1:in_range=jpeg:out_range=mpeg,format=yuv420p
> The results are consistent with a similar yuv420p(pc) test input
> (e.g., implicit and explicit setting of in_range on vf_scale both work).
> Fate passes without the checks (or with a more specific check for >= 8).
> If this seems sane, I'll write some tests.
> I tried to reproduce the old results from before and after the commit
> that I think the previous comment was referring to
> but failed to repro (I may be testing the wrong thing). Using the samples
> from (https://trac.ffmpeg.org/ticket/2939), without the check:
> ffmpeg -i /tmp/progressive.jpg -vf format=rgb24 /tmp/progressive.png
> is still treated as full range input (treating it as studio causes clipping
> in the rgb).
If you are searching for a case where the patch makes a difference
./ffmpeg -i ~/tickets/4493/AVCI100.mov out.nut
file should be here:
if you want more cases that change, ill see if i can find more
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel