[shakna]

I think there's something vital missing from this story.

I regularly use a laptop with 4GB RAM to generate videos using the sequential method listed there, with 4-8k sized frames, producing video files of hundreds of GB, without a crash. There can be hundreds of thousands of them as well.

No batching required.

The final command in my pipeline is a simple:

    ffmpeg \
    -threads "$threads" \
    -y \
    -start_number 0 \
    -i 'build_frames'"$unique"'/%09d.png' \
    -c:v libvpx-vp9 \
    -lossless 1 \
    -qscale:v 2 \
    -r "$fps" \
    build_tmp"$unique"/media.webm

But, if you really need to limit ffmpeg's memory consumption, you probably need to look at -max_alloc and -bits_per_raw_sample. It'll be highly specific to your own hardware.

[izacus]

There's also a word of warning here - the fps filter (which gets auto-inserted with -r) has a tendency to buffer the duplicated frames between two input frames.

This can cause large memory spikes if your input has low fps (or is generated from JPEGs with large time difference), since frames between two input frames will be generated and then sent to the output in a single operation, spiking memory usage.

[_Gyan_]

the fps filter (which gets auto-inserted with -r)

Which ffmpeg version are you using? This hasn't been the case since 2012. Both input and output -r are effected through fftools and not libs.

[ArtWomb]

Thnks for the replies all ;)

Switching to vp9 (from x264) worked for me!