[ArtWomb]

My new years resolution might just be to gain mastery of ffmpeg. It's incredibly versitile. Combine with python bindings, image magick and opencv and you have a powerful weapon in your arsenal.

But I keep running out of memory. I like that the process just dies. And can usually be solved by sequential batching. But how can I automate via predictive instrumentation?

[pselbert]

Learning ffmpeg can be daunting but it is a highly useful tool to know. The option intricacies and peculiarities make it extremely hard to “master” though. It requires so much experimentation and experience (trial and error) that achieving mastery in a year seems nigh impossible!

[the8472]

ffmpeg can operate in on streams of frames, you don't have to keep everything in memory or operate on discrete batches.

[BubRoss]

I don't know what you mean by predictive instrumentation or why you are running out of memory, but don't forget the original interprocess communication, the file system.

[ArtWomb]

Thanks for the replies the8472 and BubRoss!

I just mean I'd like to "cap" ffmpeg's memory usage to ensure it never crashes.

I'll provide a simple example. Creating an image slideshow from a directory of huge images. I can downscale and compress to jpeg before processing. But even then, besides batching, it always fails. And this is just raw, without any filters or image processing. Have tried all the i/o techniques from the wiki:

https://trac.ffmpeg.org/wiki/Slideshow

All this local laptop based (4GB). I just want to get a better handle before devoting cloud resources (ffmpeg is standard on gcloud serverless) ;)

[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!

[AstralStorm]

Sounds like there's a lack of feature in the CLI tool. You will have to write your own, pick a language and it probably has enough of low level ffmpeg bindings to do this. The library supports streaming reads and writes very well, though you may have to provide a custom reader callback or use the old loop APIs.

[BubRoss]

ffmpeg from the command line is very powerful and people use it for what is being described here all the time. Why do you think it is necessary to have to resort to the library and API?

[BubRoss]

I'm not sure why you would need to use a server when you have your laptop, ffmpeg should be able to chew through this stuff faster than you could upload it.

Something is likely very off with how you are using ffmpeg. If you force more keyframes, use good quality settings etc. it should make short work of it.

[kohanz]

You should be able to, for example, divide the slideshow into smaller segments, create those and then use the concatenate ability to join them back together. Maybe that's what you were already referring to by 'batching'? It's a completely valid approach.