Learn FFmpeg - Performance & Optimization

#Introduction

In episode 18 you were introduced to modern codecs — AV1, efficient but heavy. The question that immediately follows: how long does the process take, and how do we speed it up without throwing away quality? This episode answers that.

We'll cover four pillars of encode performance: measuring speed correctly, managing threading and presets, running many encodes in parallel, and reducing memory footprint for large batches. The guiding principle is simple: don't guess — measure first, then optimize. Someone who optimizes without measuring is only moving the problem around.

#Honest Benchmarking

Before chasing speed, you need to know your baseline numbers. The cleanest way to measure pure encode speed is to discard the result — we only care about time and fps. On Linux, encode output is thrown away with -f null -.

ffmpeg -hide_banner -i input.mp4 -c:v libsvtav1 -crf 30 -preset 8 -f null - -benchmark

The -benchmark flag prints speed statistics at the end of the process: total time, CPU time, and other key parameters. For a per-frame picture, add -benchmark_all, or simply watch the frame= statistics line in the stderr output, which gives real-time fps.

Three benchmark rules that are often violated:

1. One variable at a time. Change a single parameter (e.g., preset), keep the others constant. You can't compare preset 6 vs 8 if bitrate and threads also changed.
2. Representative sample. Don't benchmark with a 5-second video if your production runs 2 hours. Complex scenes change the encode ratio drastically.
3. Same machine, same conditions. A CPU that's already hot performs worse. Run the benchmark twice and take the stable number.

-hide_banner and -nostats are also useful in scripts: they reduce stderr noise so the log only contains errors that really matter.

#Threading with -threads

FFmpeg supports multi-threading at the codec level. By default (-threads 0), it uses all detected cores — but that's not always the best choice.

ffmpeg -i input.mp4 -c:v libx264 -threads 4 -preset medium output.mp4
ffmpeg -i input.mp4 -c:v libsvtav1 -threads 8 -preset 8 output.mkv

The points you must understand:

• Oversubscription. If you run 8 encodes at once and each uses all 16 cores, the total thread count becomes 128 — the kernel will be busy switching between processes (context switching), and total throughput actually drops. This is like a kitchen with 128 cooks crammed in: busy, but no food comes out.
• Hyperthreading isn't physical cores. Each physical core provides 2 threads. For heavy encoding loads, using all logical threads rarely gives 2x — generally only 1.1–1.3x of the physical cores.
• Rough rule: for a single encode, use the physical core count (or fewer). For many parallel encodes, divide the cores evenly.

A quick formula for batches: if the machine has N physical cores and you run P parallel processes, give each process about -threads N / P. Check the core count with nproc.

#Preset: The Speed Gears

Every encoder provides a speed scale via presets. The key point: a faster preset = more bitrate for the same quality — not directly worse quality. You buy encoding time by paying in storage space.

ffmpeg -i input.mp4 -c:v libx264 -preset ultrafast output-fast.mp4
ffmpeg -i input.mp4 -c:v libx264 -preset veryslow output-slow.mp4

Test it directly: encode the same file with ultrafast and veryslow, then compare file sizes at the same perceived quality. You'll see a 30–50% size difference — that's the "price" of speed. For daily work, medium (libx264) or preset 8 (SVT-AV1) is the common balanced point.

#Deadline for AV1 Encoders

Specifically for libaom-av1, FFmpeg exposes -deadline to set the encoder's execution priority:

ffmpeg -i input.mp4 -c:v libaom-av1 -cpu-used 4 -deadline good output.mkv
ffmpeg -i input.mp4 -c:v libaom-av1 -cpu-used 8 -deadline realtime output.webm

• good — quality is prioritized, suitable for final files and archives.
• realtime — speed is prioritized, the encoder tries to finish each frame within its playback time. For live streaming or fast previews.
• best — maximum quality, very slow; use only occasionally.

The same rule applies: deadline isn't an "automatically good quality" button — it shifts the priority between speed and bitrate efficiency.

#Parallel Encode Pipeline

The speed of a single encode is only half the story. For large batches (e.g., transcoding an entire archive), you can run many encodes at once. This is the most effective model: many independent files processed in parallel, each with evenly divided -threads.

CPU_CORES=$(nproc)
JOBS=$((CPU_CORES / 2))
find ./source -name '*.mp4' -print0 | \
  xargs -0 -P "$JOBS" -I{} \
    ffmpeg -hide_banner -loglevel error -i "{}" \
      -c:v libsvtav1 -crf 30 -preset 8 -threads 2 \
      "out/{}.mkv"

Read the script above line by line:

• JOBS is calculated from the physical core count divided by 2 — deliberately not using all cores so the operating system and other work can still breathe. This is like running a warehouse: don't fill every aisle, leave an evacuation path.
• xargs -0 -P reads the file list from find and runs up to $JOBS commands at once.
• Each process runs with -loglevel error so only errors are printed, plus -threads 2 — total active threads around JOBS * 2, matching the physical core capacity.
• Results are written to a separate out/ folder so sources aren't overwritten.

A modern alternative is parallel (GNU parallel) with similar syntax but richer features — automatic rescheduling, per-job logs, and retry handling. Both xargs -P and parallel share the identical principle: divide the cores, don't exceed capacity, and keep logs clean.

#Efficient Formats & Memory Footprint

For large batches, memory is often the limiting factor before CPU. A few habits save RAM significantly:

#Choose an Efficient Intermediate Format

If the workflow uses intermediate files (e.g., heavy filtering first, then final encode), don't store the intermediate as BMP, TIFF, or per-frame PNG — giant files that slow I/O. Use a lossless codec or high-CRF one that's light to decode:

ffmpeg -i input.mp4 -vf "filter_berat" -c:v libx264 -crf 18 -preset fast intermediate.mkv

An intermediate at libx264 -crf 18 is nearly lossless to the eye, fast to decode, and far smaller than a stack of PNGs. The principle: intermediate files should be easy to read back, not museum quality.

#Limit the Streams Processed

By default FFmpeg reads all streams if not directed otherwise. For a video with dozens of audio tracks and subtitles, process only what's needed:

ffmpeg -i input.mkv -map 0:v:0 -map 0:a:0 -c:v libx265 -preset medium -c:a aac output.mp4

-map 0:v:0 -map 0:a:0 instructs only the first video and first audio. The effect: smaller decoder buffers, lower memory, and the CPU doesn't waste cycles unpacking streams that are never used.

#Prevent Queue Overflow

Files with many streams or giant packets sometimes raise the error Too many packets buffered. The initial solution: raise the muxing queue threshold.

ffmpeg -i input.mp4 -c copy -max_muxing_queue_size 2048 output.mp4

-max_muxing_queue_size tells FFmpeg how many packets may pile up waiting for the muxer. The default value is sometimes too small for heavy streams. But note: this uses memory — raising it too high only postpones the problem. Get used to selective -map as the root solution, and queue size only as a safety net.

#Monitor Memory

Before running a batch of 500 files, monitor a single encode process first with top or htop. If one process uses 2 GB and you run 8 in parallel, that's 16 GB. Set JOBS based on available memory, not just cores — memory is the resource that can crash the entire batch at once.

#Conclusion

Episode 19 gave you the tools to make encoding fast without guesswork:

• Measure first with -benchmark and -f null - before changing anything.
• Control -threads — oversubscription more often hurts than helps.
• Understand presets as a speed-vs-file-size trade-off, from ultrafast to veryslow, plus -deadline for AV1.
• Run parallel batches with xargs -P or parallel, dividing cores and memory sensibly.
• Reduce memory footprint via efficient intermediate formats, selective -map, and -max_muxing_queue_size settings.

All this optimization has so far been done through the command line. But what if you want to build an application that uses FFmpeg inside it — or automate these thousands of commands from a program? In episode 20, we move to the API & programmatic use: calling the libav* libraries directly from C, Go, and Python, up to automation via wrappers like ffmpeg-python and fluent-ffmpeg. See you there.