JPEG conversion failure with zscale

[Niklas Haas]

$ ffmpeg -i in.jpg -vf showinfo,zscale='width=0.5*iw:height=ih/2',showinfo out.jpg
ffmpeg version N-116932-ge6983ed525 Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 14 (SUSE Linux)
  configuration: --prefix= --disable-optimizations --assert-level=2 --enable-libfreetype --enable-libharfbuzz --enable-libx264 --enable-libzimg --enable-lcms2 --enable-gpl --enable-libdrm --enable-libdav1d --enable-libaom --enable-libsvtav1 --enable-libx265 --enable-libx264 --enable-libvpx --samples=/home/nand/cms/fate-suite
  libavutil      59. 36.100 / 59. 36.100
  libavcodec     61. 13.100 / 61. 13.100
  libavformat    61.  5.101 / 61.  5.101
  libavdevice    61.  2.100 / 61.  2.100
  libavfilter    10.  2.102 / 10.  2.102
  libswscale      8.  2.100 /  8.  2.100
  libswresample   5.  2.100 /  5.  2.100
  libpostproc    58.  2.100 / 58.  2.100
Input #0, image2, from '/home/nand/in.jpg':
  Duration: 00:00:00.04, start: 0.000000, bitrate: 67442 kb/s
  Stream #0:0: Video: mjpeg (Baseline), yuvj444p(pc, bt470bg/unknown/unknown), 792x1728, 25 fps, 25 tbr, 25 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg (native) -> mjpeg (native))
Press [q] to stop, [?] for help
[Parsed_showinfo_0 @ 0x7f1140003300] config in time_base: 1/25, frame_rate: 25/1
[Parsed_showinfo_0 @ 0x7f1140003300] config out time_base: 0/0, frame_rate: 0/0
[Parsed_showinfo_2 @ 0x7f1140004900] config in time_base: 1/25, frame_rate: 25/1
[Parsed_showinfo_2 @ 0x7f1140004900] config out time_base: 0/0, frame_rate: 0/0
[Parsed_showinfo_0 @ 0x7f1140003300] n:   0 pts:      0 pts_time:0       duration:      1 duration_time:0.04    fmt:yuvj444p cl:center sar:0/1 s:792x1728 i:P iskey:1 type:I checksum:A427001E plane_checksum:[D49BB543 789750A5 FE2DFA18] mean:[65 115 148] stdev:[65.3 11.9 13.4]
[Parsed_showinfo_0 @ 0x7f1140003300]   side data - ICC profile: (3144 bytes)
[Parsed_showinfo_0 @ 0x7f1140003300] color_range:pc color_space:bt470bg color_primaries:unknown color_trc:unknown
[Parsed_zscale_1 @ 0x7f1140003540] code 3074: no path between colorspaces
    Last message repeated 25 times
[vf#0:0 @ 0x32a28dc0] Error while filtering: Generic error in an external library
[vf#0:0 @ 0x32a28dc0] Task finished with error code: -542398533 (Generic error in an external library)
[vf#0:0 @ 0x32a28dc0] Terminating thread with return code -542398533 (Generic error in an external library)
[vost#0:0/mjpeg @ 0x32a2a880] Could not open encoder before EOF
[vost#0:0/mjpeg @ 0x32a2a880] Task finished with error code: -22 (Invalid argument)
[vost#0:0/mjpeg @ 0x32a2a880] Terminating thread with return code -22 (Invalid argument)
[out#0/image2 @ 0x32a2a140] Nothing was written into output file, because at least one of its streams received no packets.
frame=    0 fps=0.0 q=0.0 Lsize=       0KiB time=N/A bitrate=N/A speed=N/A    
Conversion failed!

[Niklas Haas]

Fixed by https://ffmpeg.org//pipermail/ffmpeg-devel/2024-September/333130.html

[Balling]

Clearly, not fixed: JPEG uses center chroma, yet that was never mandated by the code, see: #9693.

Not to mention prores supports range, full or limited, using metadata, that is not yet supported by ffmpeg.

"MPEG range only:

prores, prores_aw, prores_ks"

That is false. #8074 703288cec6522655e8533c89efa3cd6df9613b99

[Niklas Haas]

Clearly, not fixed: JPEG uses center chroma, yet that was never mandated by the code, see: #9693.

Adding support for chroma location negotiation is somewhere on my TODO list. I believe I have a branch for it somewhere, even. But it's not in scope for 7.1.

That is false. #8074 703288cec6522655e8533c89efa3cd6df9613b99

Patches welcome. If you add proper tag handling to ProRes, we can relax this restriction easily.

[Michael Niedermayer]

I dont think zscale should be release blocking. In fact we should remove support for external scalers.

[Balling]

Replying to Michael Niedermayer:

I dont think zscale should be release blocking. In fact we should remove support for external scalers.

In fact you can't... Mpv uses it and so do everyone in the industry.

[Michael Niedermayer]

Replying to Balling:

Replying to Michael Niedermayer:

I dont think zscale should be release blocking. In fact we should remove support for external scalers.

In fact you can't... Mpv uses it and so do everyone in the industry.

And everyone in the industry used libfaad/libfaac, used MS binary decoders, used ...

scaling, like decoding is a integral part of what FFmpeg does, and we have always removed external libraries whenever our code could do the job well enough. Time and effort should be concentrated on our scaler. Thats how FFmpeg has always handled external libs and its the right thing to do. We need to have good scaling support internally

[Balling]

And everyone in the industry used libfaad/libfaac, used MS binary decoders, used ...

Yes, everyone (Android) uses libfdkaac, Apple uses qaac, best quality encoder, ffmpeg twoloop is garbage. MS binary decoders for eac3 are used by chrome and free hevc hw decoder from microsoft store is used not ffmpeg in Chrome MFF decoder, EAC3 Atmos decoder is Dolby Access. TrueHD decoder for Atmos is only Dolby reference player.

We need to have good scaling support internally

You do. it is called zscale that uses WTFPL license anyway. ​https://github.com/sekrit-twc/zimg

Time and effort should be concentrated on our scaler

It is unsalvageable, there is a undefined behaviour without accurate_rnd #10852

[Michael Niedermayer]

Replying to Balling:

We need to have good scaling support internally

You do. it is called zscale that uses WTFPL license anyway. ​https://github.com/sekrit-twc/zimg

This has nothing to do with the license. Its simply that we need a internal scaler. Delegating scaling to a external library is not an option. It causes problems with self tests, complicates dependencies and others.

Time and effort should be concentrated on our scaler

It is unsalvageable, there is a undefined behaviour without accurate_rnd #10852

If you consider bugs related to the internal scaler unsalvageable and bugs related to zscale "release blocking", thats your choice.

Also haasns swscale work is funded by STF currently. So i think swscale will improve significantly within the next months.

Last but not least, the CC wanted to ban you (Balling) indefinitly in march as you probably know. And it was me who stopped that.
If you want to convince me that I made a mistake, you are doing a good job of that

[Niklas Haas]

Replying to Michael Niedermayer:

I dont think zscale should be release blocking. In fact we should remove support for external scalers.

This bug is not about zscale, zscale is just the easiest reproducer I have. It is a core bug about the filter negotiation when using the (deprecated) YUVJ formats, that absolutely should be fixed before the release. (Or we could just remove YUVJ for the release)

Anyway, a patch exists, I will merge it later today if there are no objections as it is a rather straightforward fix that will be deleted when YUVJ stops existing.