The opposite end of the preset spectrum from ultrafast: slow uses extensive motion search, B-frames, and rate-distortion optimization to find the smallest file for a given quality target. The trade-off is encode time: slow can take 5 to 10 times longer than the medium preset.

The command

ffmpeg -i input.mp4 -c:v libx264 -preset slow -crf 20 output.mp4

What it does

libx264's slow preset enables exhaustive motion search, larger motion vector search ranges, more B-frames, and rate-distortion optimization for mode and partition decisions. For a given CRF, the output is 10 to 20% smaller than the medium preset. The cost is encoding time: a 10-minute 1080p clip can take an hour or more on a mid-range CPU.

When to use it

For archival, master encodes, and any time you are encoding once and serving many. Streaming services and studios use slow or slower for their master encodes. For short-form content where encode time matters, stay at medium or slow.

Video and hardware requirements

CPU-bound. The slower presets do not benefit from hardware acceleration because they rely on the software encoder's deep analysis. Hardware encoders have their own preset scales (NVENC has p1 through p7, for example) that are not directly comparable to libx264's. Use -c:v h264_nvenc -preset p7 for the closest hardware equivalent.

Things to avoid

  • Using slow for live or real-time encodes. The CPU cost is too high; it is a master-encode preset, not a delivery preset.
  • Going beyond slow to slower or placebo. The quality gains are imperceptible (sub-1% size reduction) while the time cost doubles again.
  • Combining slow with a high CRF. The preset is designed to extract maximum quality at a target CRF; a high CRF gives it nothing to optimize.
  • Using slow on a CPU without enough cores. libx264's slow preset is heavily multi-threaded; a 4-core machine may not be much faster than a 2-core one. Use medium on low-end hardware.