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 > 4959a4fcf76e7c595dbb23c4e3bf59abf2e60ea4 > 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 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
