Zscale transform to ST 2084 EOTF results in black video output

[Alex Zambelli]

Summary of the bug:

Sometime between releases 4.2.2 and 4.2.3 a bug was introduced into Zscale filter which causes the video output of the filter to be reduced to black when transforming video using SMPTE ST 2084 (PQ) EOTF.

How to reproduce:

Source video: ​https://hulu.box.com/shared/static/5o419x2dag93wx5f0msc69gbljfydri1.mp4

ffmpeg version git-2020-06-28-4cfcfb3
built with gcc 9.3.1 (GCC) 20200621

ffmpeg.exe -y -i zscale_test_source.mp4 -vf zscale=t=linear:w=640:h=360,format=gbrpf32le,zscale=t=smpte2084:p=bt709:m=bt709,format=yuv420p10le -vcodec ffv1 zscale_test_smpte2084.avi

Sample output: ​https://hulu.box.com/shared/static/6a8yjs5mel2scv63vvpmrn0438fqbiil.avi

If t=smpte2084 is replaced with another EOTF, such as bt709, the filter produces the correct output:

ffmpeg.exe -y -i zscale_test_source.mp4 -vf zscale=t=linear:w=640:h=360,format=gbrpf32le,zscale=t=bt709:p=bt709:m=bt709,format=yuv420p10le -vcodec ffv1 zscale_test_bt709.avi

Sample output: ​https://hulu.box.com/shared/static/uuy3gfhg6mwflrqmhvb2bvkl7009nlf4.avi

The bug does not repro in FFmpeg release 4.2.2. To the best of my memory while working with nightly builds, this Zscale transform worked correctly until at least early May 2020.

[Alex Zambelli]

Broken zscale t=smpte2084 output

[Alex Zambelli]

Correct zscale output (using t=bt709 for example)

[Carl Eugen Hoyos]

Please point us to the commit introducing the regression.

[Alex Zambelli]

Replying to cehoyos:

Please point us to the commit introducing the regression.

I'm not familiar with that part of the project code so it'd be difficult for me to look for specific commits.

The best I could do is find the date/build when the issue is introduced, by trying out the same command line on different builds.

[Elon Musk]

Make sure this is not zimg issue, as zscale is just a wrapper around it.

[mawazi]

This appears to be a problem in zimg, fixed with the following zimg commit: ​https://github.com/sekrit-twc/zimg/commit/fc7473db7e730b46fd8f05b3d9d15631c6aa79a1

The npl parameter of zscale, which deals with peak luminance when converting between HDR and SDR, was not being dealt with properly when not explicitly set. This can also be worked around in current ffmpeg builds by setting npl=100 (which should be the default when not set) when using zscale to convert between HDR and SDR transfer functions (and vice-versa).

[Balling]

Fixed upstream and already in ​https://github.com/BtbN/FFmpeg-Builds/blob/56c81f32753fb5dc8c8668239d23cee4583c55c3/scripts.d/50-zimg.sh#L4