filter 'zscale=transfer=linear' fails with "code 2050: active window must be positive"

[rminnema]

Summary of the bug:

I have a .webm recorded from PS5 gameplay of Horizon Forbidden West. The file was recorded from HDR output although it doesn't have proper HDR metadata, but its color primaries are BT.2020 and transfer characteristics PQ. The video is thus washed out and oversaturated on SDR displays. Therefore I'm using ffmpeg to tone map the videos to something that looks acceptable in SDR.

When I try to do so using the options '-vf zscale=transfer=linear,tonemap=hable,zscale=transfer=bt709', ffmpeg exits with the error "[Parsed_zscale_0 @ 000002486a8a5680] code 2050: active window must be positive". The resulting output file is 0 bytes in size.

How to reproduce:

ffmpeg started on 2022-06-12 at 20:01:29
Report written to "ffmpeg-20220612-200129.log"
Log level: 48
Command line:
"d:\\programs\\bin\\ffmpeg.exe" -report -i ".\\sample.webm" -vf "zscale=transfer=linear,tonemap=hable,zscale=transfer=bt709" -map 0:v test.mkv
ffmpeg version N-107098-g4d45f5acbd-ffmpeg-windows-build-helpers Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 10.2.0 (GCC)
  configuration: --pkg-config=pkg-config --pkg-config-flags=--static --extra-version=ffmpeg-windows-build-helpers --enable-version3 --disable-debug --disable-w32threads --arch=x86_64 --target-os=mingw32 --cross-prefix=/home/robert/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/bin/x86_64-w64-mingw32- --enable-libcaca --enable-gray --enable-libtesseract --enable-fontconfig --enable-gmp --enable-gnutls --enable-libass --enable-libbluray --enable-libbs2b --enable-libflite --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libvorbis --enable-libwebp --enable-libzimg --enable-libzvbi --enable-libmysofa --enable-libopenjpeg --enable-libopenh264 --enable-libvmaf --enable-libsrt --enable-libxml2 --enable-opengl --enable-li  libavutil      57. 26.100 / 57. 26.100
  libavcodec     59. 33.100 / 59. 33.100
  libavformat    59. 24.100 / 59. 24.100
  libavdevice    59.  6.100 / 59.  6.100
  libavfilter     8. 40.100 /  8. 40.100
  libswscale      6.  6.100 /  6.  6.100
  libswresample   4.  6.100 /  4.  6.100
  libpostproc    56.  5.100 / 56.  5.100
Splitting the commandline.
Reading option '-report' ... matched as option 'report' (generate a report) with argument '1'.
Reading option '-i' ... matched as input url with argument '.\sample.webm'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with argument 'zscale=transfer=linear,tonemap=hable,zscale=transfer=bt709'.
Reading option '-map' ... matched as option 'map' (set input stream mapping) with argument '0:v'.
Reading option 'test.mkv' ... matched as output url.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option report (generate a report) with argument 1.
Successfully parsed a group of options.
Parsing a group of options: input url .\sample.webm.
Successfully parsed a group of options.
Opening an input file: .\sample.webm.
[NULL @ 0000022fb552a180] Opening '.\sample.webm' for reading
[file @ 0000022fb552a800] Setting default whitelist 'file,crypto,data'
[matroska,webm @ 0000022fb552a180] Format matroska,webm probed with size=2048 and score=100
st:0 removing common factor 1000000 from timebase
st:1 removing common factor 1000000 from timebase
[matroska,webm @ 0000022fb552a180] Before avformat_find_stream_info() pos: 631 bytes read:32768 seeks:0 nb_streams:2
[vp9 @ 0000022fb5541fc0] Format yuv420p10le chosen by get_format().
[opus @ 0000022fb5542780] skip 120/960 samples
[matroska,webm @ 0000022fb552a180] All info found
[matroska,webm @ 0000022fb552a180] After avformat_find_stream_info() pos: 342493 bytes read:375013 seeks:0 frames:2
Input #0, matroska,webm, from '.\sample.webm':
  Metadata:
    ENCODER         : Lavf59.24.100
  Duration: 00:00:03.00, start: -0.003000, bitrate: 18546 kb/s
  Stream #0:0, 1, 1/1000: Video: vp9 (Profile 2), yuv420p10le(pc, bt2020nc/bt2020/smpte2084), 1920x1088, SAR 967:960 DAR 967:544, 59.94 fps, 59.94 tbr, 1k tbn (default)
    Metadata:
      DURATION        : 00:00:03.002000000
  Stream #0:1, 1, 1/1000: Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      DURATION        : 00:00:03.000000000
Successfully opened the file.
Parsing a group of options: output url test.mkv.
Applying option vf (set video filters) with argument zscale=transfer=linear,tonemap=hable,zscale=transfer=bt709.
Applying option map (set input stream mapping) with argument 0:v.
Successfully parsed a group of options.
Opening an output file: test.mkv.
[file @ 0000022fb55e7580] Setting default whitelist 'file,crypto,data'
Successfully opened the file.
detected 32 logical cores
Stream mapping:
  Stream #0:0 -> #0:0 (vp9 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
[vp9 @ 0000022fb5544f40] Format yuv420p10le chosen by get_format().
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
[Parsed_zscale_0 @ 0000022fb567b140] Setting 'transfer' to value 'linear'
[Parsed_tonemap_1 @ 0000022fb5611ec0] Setting 'tonemap' to value 'hable'
[Parsed_zscale_2 @ 0000022fb55f4c00] Setting 'transfer' to value 'bt709'
[graph 0 input from stream 0:0 @ 0000022fb5592980] Setting 'video_size' to value '1920x1088'
[graph 0 input from stream 0:0 @ 0000022fb5592980] Setting 'pix_fmt' to value '62'
[graph 0 input from stream 0:0 @ 0000022fb5592980] Setting 'time_base' to value '1/1000'
[graph 0 input from stream 0:0 @ 0000022fb5592980] Setting 'pixel_aspect' to value '967/960'
[graph 0 input from stream 0:0 @ 0000022fb5592980] Setting 'frame_rate' to value '19001/317'
[graph 0 input from stream 0:0 @ 0000022fb5592980] w:1920 h:1088 pixfmt:yuv420p10le tb:1/1000 fr:19001/317 sar:967/960
[format @ 0000022fb5590d40] Setting 'pix_fmts' to value 'yuv420p|yuvj420p|yuv422p|yuvj422p|yuv444p|yuvj444p|nv12|nv16|nv21|yuv420p10le|yuv422p10le|yuv444p10le|nv20le|gray|gray10le'
[AVFilterGraph @ 0000022fb8a26100] query_formats: 6 queried, 5 merged, 0 already done, 0 delayed
[Parsed_zscale_0 @ 0000022fb567b140] picking gbrpf32le out of 2 ref:yuv420p10le alpha:0
[Parsed_zscale_2 @ 0000022fb55f4c00] picking yuv444p10le out of 9 ref:gbrpf32le alpha:0
[Parsed_zscale_0 @ 0000022fb567b140] code 2050: active window must be positive
[Parsed_zscale_0 @ 0000022fb567b140] code 2050: active window must be positive
Error while filtering: Generic error in an external library
Failed to inject frame into filter network: Generic error in an external library
Error while processing the decoded data for stream #0:0
[AVIOContext @ 0000022fb5544200] Statistics: 0 bytes written, 0 seeks, 0 writeouts
[AVIOContext @ 0000022fb5547940] Statistics: 723207 bytes read, 0 seeks
Conversion failed!

[Balling]

Just -c copy and tag the video as PQ transfer, bt.2020 primaries and bt.2020nc matrix.

Also you are wrong, it is vp9 in webm and tagged as yuv420p10le(pc, bt2020nc/bt2020/smpte2084).

[rminnema]

Replying to Balling:

Just -c copy and tag the video as PQ transfer, bt.2020 primaries and bt.2020nc matrix.

Also you are wrong, it is vp9 in webm and tagged as yuv420p10le(pc, bt2020nc/bt2020/smpte2084).

The video still looks washed out when I do that. Only tone mapping fixes its appearance.

I just found that if I use the n5.0 latest release instead of the master branch, this same command works. It's on the master branch that it doesn't.

Also I'm unclear on what you're saying I'm wrong about.

[BoKK]

*Deleted*

[Balling]

The video still looks washed out when I do that. Only tone mapping fixes its appearance.

No, it does not. Are you sure you understasnd how to play HDR?

Also I'm unclear on what you're saying I'm wrong about.

doesn't have proper HDR metadata
The video is thus washed out and oversaturated on SDR displays

This implication is wrong. HDR metadata is what makes a video HDR10, not HDR. PQ function makes video HDR.

It only happens in my modified Windows. In a vanilla one no error is thrown.

Use windows 11.

[rminnema]

Replying to Balling:

The video still looks washed out when I do that. Only tone mapping fixes its appearance.

No, it does not. Are you sure you understasnd how to play HDR?

I already said I am trying to play these videos on an SDR display. Are you sure you "understasnd" how to read?

Also I'm unclear on what you're saying I'm wrong about.

doesn't have proper HDR metadata
The video is thus washed out and oversaturated on SDR displays

This implication is wrong. HDR metadata is what makes a video HDR10, not HDR. PQ function makes video HDR.

Fine. I'm glad you got that out of your system. Are you here to help identity and fix bugs, or are you here to argue with people about how they use the software?

[Balling]

I already said I am trying to play these videos on an SDR display. Are you sure you "understasnd" how to read?

So you do not understand there is no difference, most SDR displays are HDR because they are more than 100 nits.

Anyway, it works for me, no

code 2050: active window must be positive

in both cases from two people.

Please provide small sample.webm.

[BoKK]

error_2050_when_using_zscale_to_resize_video

[BoKK]

I'm editing to *Deleted* my posts.

I've found new cases where I'm having ffmpg crash or fail, related to zscale, but too convoluted to explain here. I don't want to distract the attention from the original issue stated by the OP, so I'll be posting my own report once I've done some tests.

Please ignore the file I uploaded, too, and delete all my posts here if possible.

[rminnema]

webm file that fails to encode in ffmpeg with given options

[Balling]

I'm editing to *Deleted* my posts.

I am not such a person that thinks someone hijecked or derailed [or 100 other things] the thread, it is obvious that if a) i cannot reproduce b) you can reproduce on some modified windows
then this is a OS/compiler/binary issue.

Again, if your command causes the same warning, it is safe to at least assume it is the same bug, even if it is not, that is not a problem! So thank you for googling and finding it instead of opening another bug!

Only tone mapping fixes its appearance.

I suppose I will clarify what I meant here. HDR to SDR convertion is NOT CALLED tonemapping. Anyone who uses that does not understand what HDR is. Tonemapping is what is used BY HDR10 display to convert properties of source data to display data and only does not apply to ideal full primaries 10000 nits display. Yes in practice those two things look mathemtically close, but still.

[Balling]

I cannot reproduce! Please retest on
​https://github.com/BtbN/FFmpeg-Builds

To prove I am not lying here is the file I get after -vf zscale=transfer=linear,tonemap=hable,zscale=transfer=bt709

Same about the second file, will not attach it though.

[BoKK]

Replying to Balling:

b) you can reproduce on some modified windows then this is a OS/compiler/binary issue.

First of all, thanks for your patience and kindness.

About your sentence quoted above, I would like to find what change made to my OS could be reacting to recent changes in ffmpeg code. I'm happy if this is not a bug in ffmpeg but I'd love to find how to solve it on my end then.

This said, and if nobody find it a problem, I'll post what I've found here instead of opening a new bug.

---

I asked sekrit-twc [zimg] about this to check if something on that library could be causing what I'm going to post now and, as I don't know programming, I asked him to please take a quick look at commit ​https://github.com/FFmpeg/FFmpeg/commit/52a14b8505923116ed6acc5e691c0c7c44e6f708

He answered me with a question that I find interesting given my findings.
The issue I opened there was this one ​https://github.com/sekrit-twc/zimg/issues/177

• I've started from zero to check all of this again. I generated a test video with ffmpeg

  ffmpeg -f lavfi -i testsrc=duration=3:size=3840x2160:rate=24000/1001 test_in.mkv
  

• Then I applied a simple rescale filter, with varying values for width and height. Command was this, changing 1920 and 1080 values to test the outcome

  ffmpeg -report -i test_in.mkv -vf zscale=size=1920x1080 -c:0 libx265 test_out.mkv
  

• I found something really weird to me
  1. Changing only horizontal dimension caused no problem at all
  2. Changing only vertical dimension started throwing a 2050 error on very specific numbers, and error plus ffmpeg.exe crash on a range of numbers.
  3. The best way I'm able to explain it is with this two screenshots, which I hope are easy to understand
     

Error only appeared when vertical dimensions were 'small-ish', but not every small number triggered it as it can be seen in the imgs above.
And, as sekrit-twc 'predicted', I am using a 12-cores, 24-threads AMD processor.

---

GyanD ffmpeg-2022-05-12-git-30e2bb0f64-essentials_build is the last version problem-free.
BtbN ffmpeg-N-106757-geef652ca9c-win64-gpl is the last version problem-free.

So, as I suspected, commits made at May 13, 2022 apparently are what triggered the error for me

Also, same test on a virtual machine with a fresh and non-modified Windows 10 x64 install didn't throw any error. Therefore I suppose this is going to be hardly reproducible by anyone excepting those that by chance have customized/modified their OS in the same way.

I can't pinpoint what change in my OS causes this so I don't know how widespread this error might be, but maybe my modified OS is by pure chance revealing a potential problem that may be worth investigating at least until is traced back to an specific OS problem on my side -- or in vf_zscale.c code that could be done differently to be less susceptible of interact with OS issues.

---

---

Important new data, I think.

I've repeated tests on a vitual machine with my customized OS version installed but with only 2 cores assigned... and every ffmpeg version worked just fine.

So, I tested this on my main machine limiting number of threads with -threads 2 ... and now every ffmpeg version works OK no matter what size I set for zscale. I keep increasing thread count without a problem until I reach -threads 17, then I get error again.

These results are in line with the commit I supposed started the problem for me.

[Balling]

This commit should be used too. 710dce131fdb6c1ebec1f26a7a4173d82d828330

Not only 52a14b8505923116ed6acc5e691c0c7c44e6f708. This Intel slice threading patch is just wow. Third bug.

using a 12-cores, 24-threads AMD processor

Well, that is just great. CPU problem. See the original guy, detected 32 logical cores.

same test on a virtual machine with a fresh and non-modified Windows 10 x64 install didn't throw any error

That is a very bad test. I hope you at least used Vmware.

[BoKK]

Replying to Balling:

This commit should be used too. 710dce131fdb6c1ebec1f26a7a4173d82d828330

Not only 52a14b8505923116ed6acc5e691c0c7c44e6f708. This Intel slice threading patch is just wow. Third bug.

using a 12-cores, 24-threads AMD processor

Well, that is just great. CPU problem. See the original guy, detected 32 logical cores.

same test on a virtual machine with a fresh and non-modified Windows 10 x64 install didn't throw any error

That is a very bad test. I hope you at least used Vmware.

Yes, latest VMware Workstation used.
Also, please read my last edit to my previous post: in my main machine, if I limit thread use by ffmpeg starting with -threads 2, the problem vanishes... until I reach -threads 17

[Balling]

Fixed in 42289d5eaf3e938f0969aaf58c81550c0aed8f5e, but please test, build will be here soon ​https://github.com/BtbN/FFmpeg-Builds/

[BoKK]

Latest BtbN build, version N-107118-g5242ede48d-20220616

Made some quick test and seems fixed for me.

It could be a fixed-for-the-time-being situation, though, if what sekrit-twc is pointing out here ​https://github.com/sekrit-twc/zimg/issues/177#issuecomment-1157734233 is right.

[rminnema]

Replying to Balling:

Fixed in 42289d5eaf3e938f0969aaf58c81550c0aed8f5e, but please test, build will be here soon ​https://github.com/BtbN/FFmpeg-Builds/

It seems to be working fine for me now as well. The same sample webm I posted here earlier now does tone mapping with no issues.

Thanks for your help.

[BoKK]

Similar issue caused by this file

[BoKK]

It seems something is happening again, or at least something that seems related to zscale and threads used, somehow.
I'm reopening this because I am guessing it's related so I see no point in opening a separate report for now.

ffmpeg -i test.mkv -vf zscale=size=1920x1080 -c:0 libx265 test_out.mkv  >> ffmpeg.exe crash
ffmpeg -i test.mkv                           -c:0 libx265 test_out.mkv  >> OK
ffmpeg -i test.mkv -vf scale=1920:1080       -c:0 libx265 test_out.mkv  >> OK

Crash error is 'Exception Processing Message 0xc0000005 – Unexpected parameters'

What makes it weirder this time is... it doesn't always happen.
This would point to a software or hardware error but then it should also happen when zscale is not used and that's not happening.

• Using zscale=scale > Error most of the times.
• NOT using zscale > No error, ever.

To make it weirder, what mitigated the problem before, setting -threads 2, achieves just the opposite -- error now appear always.

• Using zscale=scale > Error ~90% of the times.
• Using zscale=scale + -threads 2 > Error 100% of the times.

If I had to guess, I'd say this behaviour looks like some floating point rounding error... but I'm no programmer so that's just what it is, a guess.

I'm uploading a test file, 'test_file_BOKK_20220701.mkv'.
I suppose few people will be able to reproduce the issue... but it is happening nonetheless.

[Marton Balint]

Can you try the latest git master? The calculation of slices has changed slightly. Although I can't reproduce the crash you are experiencing...

[Marton Balint]

The original issue supposed to be fixed in a6f0e641bcde6d8475c5d5473ac9b4de89618fc5, please open a new ticket if you can reproduce a crash with the latest git master.