> ## Content Index
> Fetch the complete content index at: https://ffmpeguru.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Use the slow preset for maximum compression efficiency
- URL: https://ffmpeguru.com/use-the-slow-preset-for-maximum-compression-efficiency/
- Published: 2026-10-30T09:00:00.000Z
- Updated: 2026-10-30T09:00:00.000Z
- Author: FFmpeguru
- Tags: ffmpeg

![](https://picsum.photos/seed/ffblog15/1200/630)

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.