ffmpeg png to gif losing first half of frame list with fifo filter

Question

Can anybody suggest a solution to (or at least a cause for) the following snag I'm experiencing in Windows 10, please? While I originally thought this was, maybe, a problem with the source images, I'm now focusing on a difficulty with the fifo function – but I'm prepared to stand corrected.

Problem
I'm losing all but the last seventeen frames out of thirty-eight 1920x1080px frame slideshow while using the following command to create an animated gif:

    ffmpeg -framerate 1 -i PREFIX_%4d.png -filter_complex "scale=w=iw/2:h=ih/2,split=2[palette_in][gif];[palette_in]palettegen[palette_out];[gif]fifo[gif_fifo]; [gif_fifo][palette_out]paletteuse"  -r 1 -y PREFIX.gif

The intention is to split the input, create a palette and then use this to create the output gif. Why? Because StackExchange taught me to do it this way.

the PREFIX_????.png fileset is a sequentially numbered copy of an original jpg photo sequence. Frame loss is consistent over many runs with this image set, including using the 'original' first-pass copy pngs (with non-sequentially numbered file names) specified in a concat file with a 1.0 second duration parameter.

Basic Output

ffmpeg version N-94174-gfeade2b403 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9.1.1 (GCC) 20190621
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
  libavutil      56. 30.100 / 56. 30.100
  libavcodec     58. 53.101 / 58. 53.101
  libavformat    58. 28.101 / 58. 28.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter     7. 56.100 /  7. 56.100
  libswscale      5.  4.101 /  5.  4.101
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Input #0, image2, from 'PREFIX_%4d.png':
  Duration: 00:00:38.00, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, rgb24(pc), 1920x1080 [SAR 2834:2834 DAR 16:9], 1 tbr, 1 tbn, 1 tbc
Stream mapping:
  Stream #0:0 (png) -> scale
  paletteuse -> Stream #0:0 (gif)
Press [q] to stop, [?] for help
Output #0, gif, to 'PREFIX.gif':
  Metadata:
    encoder         : Lavf58.28.101
    Stream #0:0: Video: gif, pal8, 960x540 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 1 fps, 100 tbn, 1 tbc
    Metadata:
      encoder         : Lavc58.53.101 gif
[Parsed_palettegen_2 @ 0000023393365180] 255(+1) colors generated out of 492243 colors; ratio=0.000518
frame=   17 fps=2.9 q=-0.0 Lsize=    6098kB time=00:00:37.01 bitrate=1349.8kbits/s speed=6.21x
video:6098kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000320%

The problem has not manifested on other test image sets and does not manifest if the split/fifo/palette section is removed.

ffmpeg -framerate 1 -i PREFIX_%4d.png  -r 1 -y PREFIX.gif

The scaling filter was included as a test only, although it does help keep the test gif size down!

Answer 1

Most filters in ffmpeg require the input to have consistent attributes across all frames of the input. Only a few filters are coded to be aware of and adjust to changing attributes (scale being one of them).

The logs shows that the filtergraph is reinitialized twice at the 15th and 22nd frames implying some attribute inconsistency. Need more logging to identify what those are. When reinitialized, the fifo filter loses all frames buffered before reinitialization, hence the frame losses.

Try

ffmpeg -reinit_filter 0 -framerate 1 -i PREFIX_%4d.png -filter_complex "scale=w=iw/2:h=ih/2,format=bgra,split=2[palette_in][gif];[palette_in]palettegen[palette_out];[gif]fifo[gif_fifo]; [gif_fifo][palette_out]paletteuse"  -r 1 -y PREFIX.gif

The -reinit_filter 0 tells ffmpeg to skip reinitialization. The scale and format at the front of the filtergraph ensure* that all further filters receive uniform input.

*sort of. The scale args should be set to fixed sizes to be sure of that. In this case, I believe the pixel format has changed and the format filter takes care of that.