ffmpeg 5.1 cli changed how it interprets percent signs in output file urls

[mkhl]

Summary of the bug:
in ffmpeg 5.0 one had to "escape" percent signs in output file urls, so instead of 100%.png one had to pass 100%%.png.
in ffmpeg 5.1 this changed and percent signs are now interpreted literally, and i can't find any documentation regarding whether this change was intentional or which variant people should use.

See also:
​yt-dlp issue about how it's affected by this bug

How to reproduce:

% convert xc:#ffffff -size 1x1 white.png # so there's any image
% ffmpeg -y -loglevel repeat+info -f image2 -pattern_type none -i 'file:white.png' -movflags +faststart 'file:x%%.webp'
ffmpeg version n5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 12.2.0 (GCC)
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librav1e --enable-librsvg --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-version3 --enable-vulkan
  libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100
Input #0, image2, from 'file:white.png':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: png, monob(pc), 1x1, 25 fps, 25 tbr, 25 tbn
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> webp (libwebp_anim))
Press [q] to stop, [?] for help
Output #0, webp, to 'file:x%%.webp':
  Metadata:
    encoder         : Lavf59.27.100
  Stream #0:0: Video: webp, bgra(pc, gbr/unknown/unknown, progressive), 1x1, q=2-31, 200 kb/s, 25 fps, 1k tbn
    Metadata:
      encoder         : Lavc59.37.100 libwebp_anim
[libwebp_anim @ 0x562536100940] Using libwebp for RGB-to-YUV conversion. You may want to consider passing in YUV instead for lossy encoding.
frame=    1 fps=0.0 q=-0.0 Lsize=       0kB time=00:00:00.00 bitrate= 352.0kbits/s speed=0.177x    
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%

with 5.0 this would create a file x%.webp, with 5.1 it creates x%%.webp instead

[Carl Eugen Hoyos]

I am not exactly a fan of how the image2 muxer changed its behaviour but it appears that this was intended, see #9748.
For future tickets please remember that only current FFmpeg git head is supported on this bug tracker.

[pukkandan]

The change is reasonable; but I would like to know how a third party program (yt-dlp in this case) can decide which pattern to use without blindly assuming that the user will have the latest ffmpeg.

PS: Considering this change is breaking compatibility, shouldn't it have been reserved for a major release?

[Carl Eugen Hoyos]

I believe that this discussion should take place on the development mailing list / that it wouldn’t help you if it gets discussed here.