Opened 2 years ago

Closed 2 years ago

#9702 closed defect (fixed)

Regression of vf_zscale in d0aefc37069e1602aa8cc5568e87f4a5e52fb4f3

Reported by: Ulrik Mikaelsson Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by Ulrik Mikaelsson)

For the invocation of
ffmpeg -y -f lavfi -i yuvtestsrc=duration=5:size=1280x720:rate=15 -vf 'zscale=range=full:primaries=240m:matrix=470bg:transfer=601:rangein=full:primariesin=709:matrixin=709:transferin=709' -preset veryfast out1.mp4

i expect the colors to be changed slightly compared to

ffmpeg -y -f lavfi -i yuvtestsrc=duration=5:size=1280x720:rate=15 -preset veryfast out2.mp4

This seems to have broken on d0aefc37069e1602aa8cc5568e87f4a5e52fb4f3. For the commit just prior, I do see a slight difference in output, as expected. Starting with the commit in question, I notice that the `if`-statement switching between filtering and simple frame-forwarding, never seem to end up in the filtering branch.

I'm not familiar with the code, but I'm slightly surprised to see the call to format_init (which I understand to setup of s->src_format from options) being done inside the filtering branch, when it's effect is part of the branching decision itself.

Change History (5)

comment:1 by Ulrik Mikaelsson, 2 years ago

Description: modified (diff)

comment:2 by Balling, 2 years ago

You did not tag the output, also transfers 601 and 709 are the same. Sigh. primaries=240m are the same as 170m. There is no point in using 240m.

Slight change in color?? What? You are changing the matrix from bt709 to bt601 that is not slight at all. The change from 709 primaries to 170m (SMPTE C) should be slight indeed.

Why did you not isolate what precisly is the problem?

Last edited 2 years ago by Balling (previous) (diff)

comment:3 by Balling, 2 years ago

Status: newopen

You did not tag the output as full range. Like what??? That is done with -color_range pc and makes a difference in color, rather big one. Now... Any normal player (not ffmpeg) will think that untagged hd file is bt709. So you forgot to tag it: -colorspace bt470bg, you also forgot -color_primaries smpte170m -color_trc bt709. So the end command is:

ffmpeg.exe -y -f lavfi -i yuvtestsrc=duration=5:size=1280x720:rate=15 -vf 'zscale=range=full:primaries=240m:matrix=470bg:transfer=601:rangein=full:primariesin=709:transferin=709' -color_range pc -colorspace bt470bg -color_primaries smpte170m -color_trc bt709 -color_range pc -preset veryfast out11212121111.mp4

Okay, that is nice. Next now that we fixed all "undefined behaviour"...

Now lets try older build: with the command above it just prints (because I remobed matrixin=)

code 3074: no path between colorspaces

So it cannot be tested.

Now, the bug appears to be that in latest ffmeg matrixin=x does not matter, it is not being accounted for. It is always the same.

Last edited 2 years ago by Balling (previous) (diff)

comment:4 by Balling, 2 years ago

BTW, I just before you reported the issue where the situation is the opposite, only zscale works (when you go from 709 full to jpeg, so matrix should change, yet range does not). Yet the behaviour without output matrix in zscale is quite strange https://trac.ffmpeg.org/ticket/9693#comment:5

comment:5 by Balling, 2 years ago

Resolution: fixed
Status: openclosed

code 3074: no path between colorspaces

Is returned after e5189b13827746e57bc1eccc78a5381f646963b9 and thus the bug is fixed.
https://trac.ffmpeg.org/ticket/9693#comment:5 is still broken.

Note: See TracTickets for help on using tickets.