Encoder presets — what x264 / x265 / SVT-AV1 presets actually mean

Encoder presets are the most consequential single configuration decision in video encoding pipelines. The preset determines speed-quality tradeoffs across hundreds of internal encoder parameters in one knob. The choice of "medium" vs "fast" vs "slow" can be the difference between a real-time live stream and an unencodable one, or between a quality-competitive VOD encode and a noticeably worse one. This page is the engineering reference for what presets actually mean across encoders, how to pick them, and how to calibrate.

#What encoder presets are

Modern video encoders (x264, x265, SVT-AV1, libvpx) expose hundreds of internal parameters that control encoding behavior — motion search range, transform sizes used, B-frame count, look-ahead depth, reference frame count, etc. Tuning these individually requires deep codec expertise; presets provide named bundles that have been calibrated by the encoder's authors.

A preset typically corresponds to a point on the speed-quality curve. Faster presets do less work per frame; slower presets do more work and produce better quality at the same bitrate.

Standard preset names across encoders:

• x264 / x265 — ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo.
• SVT-AV1 — numbered 0-13, where 0 is slowest/highest-quality and 13 is fastest/lowest-quality.
• libvpx-vp9 — --cpu-used 0 to 8, where 0 is slowest/highest-quality.
• NVENC — p1 (fastest) to p7 (slowest).

The mapping between encoder preset names and actual speed-quality positions varies. "x264 medium" and "x265 medium" are not necessarily comparable encoding-time-wise; the names map to internal tuning, not to an absolute scale.

#x264 presets

x264's presets are the most-tested in production. The standard mapping:

Quality differences (at the same bitrate, in VMAF):

• ultrafast vs medium: ~5-8 VMAF lower
• veryfast vs medium: ~3-5 VMAF lower
• fast vs medium: ~1-2 VMAF lower
• slow vs medium: ~1-2 VMAF higher
• veryslow vs medium: ~2-3 VMAF higher
• placebo vs veryslow: <0.5 VMAF higher (not worth the wall-time)

The "diminishing returns past slower" pattern is consistent across content. veryslow and placebo deliver tiny quality improvements at huge wall-time cost. They exist for research purposes and for content where every quality point matters and time doesn't.

For 2026 production:

• Live: fast or veryfast, depending on quality budget.
• VOD: medium for baseline; slow for premium.
• Throughput-bound: faster.
• Research: slow or slower (placebo for paper-only purposes).

#x265 presets

x265 inherits x264's preset naming but the underlying tuning is different. x265 medium is roughly comparable to x264 medium in encoding time but produces meaningfully better compression (HEVC's compression advantage).

x265's encoding time grows more dramatically than x264's at slow presets. x265 veryslow can be 10x slower than x265 medium; x264 veryslow is closer to 6x slower than x264 medium. The compression gain is also larger — x265 has more to optimize.

For 2026 production:

• Live: x265 fast or veryfast.
• VOD: x265 medium for baseline; slow for premium.
• Throughput-bound: x265 faster.

#SVT-AV1 presets

SVT-AV1 uses numeric presets 0-13. The Intel/Netflix engineers who built SVT-AV1 made the presets correspond to a smooth speed-quality curve.

Quality-vs-encoding-time relationship:

• preset 0 vs preset 6: ~3-4 VMAF higher, 5-10x slower
• preset 4 vs preset 6: ~1-2 VMAF higher, 2x slower
• preset 8 vs preset 6: ~1-2 VMAF lower, 2-3x faster
• preset 12 vs preset 6: ~3-5 VMAF lower, 5-8x faster

For 2026 production:

• Live: SVT-AV1 preset 10-12.
• VOD: SVT-AV1 preset 6 for baseline; preset 4 for premium.
• Throughput-bound: SVT-AV1 preset 7-8.
• Research / top-end: SVT-AV1 preset 2-3.

SVT-AV1 preset semantics shift slightly across versions. The latest stable releases have well-tuned presets; older releases have rougher behavior. Keep encoder versions current.

#libvpx-vp9 presets

libvpx-vp9 uses --cpu-used 0-8:

VP9 production has moved toward AV1, so the preset tuning isn't as actively-developed as x264/x265/SVT-AV1. Use libvpx-vp9 if you have an existing VP9 pipeline; for new pipelines, AV1 is the answer.

#Hardware encoder presets

Hardware encoders expose simpler preset interfaces. The mapping is generally:

NVENC — presets p1 (fastest, lowest quality) through p7 (slowest, highest quality):

NVENC quality at p7 is roughly equivalent to x264 fast or x265 fast. Hardware encoder quality plateaus; you don't get x265 medium quality from NVENC HEVC.

Quick Sync — velocity, slower, slow, medium, fast, faster (note: ordering inverse of x264):

#Picking presets — the decision framework

The preset decision factors:

Wall-time budget:

• Live: must encode in real-time. Fast presets only.
• Same-day VOD publishing: hours per asset. Medium-class presets fit.
• Premium VOD with patient publishing: days per asset OK. Slow / very slow presets fine.
• Archive: minimum bitrate, no time constraint. Slowest presets justified.

Quality target:

• Reach the quality threshold; don't pay for quality beyond what your VMAF target requires.
• For VMAF 90+ targets at challenging bitrates, slow presets matter.
• For VMAF 80-90 targets at comfortable bitrates, medium presets suffice.

Compute budget:

• High volume, modest budget: faster presets, accept some quality cost.
• High volume, high budget: medium presets, efficient encoding.
• Low volume, high budget: slow presets for premium quality.

Audience tolerance:

• Premium streaming customers expect high quality. Slow presets matter.
• Internal use cases tolerate "good enough." Medium or fast presets fine.
• Free/ad-supported tier: medium presets typical.

A pragmatic 2026 default: x264 medium / x265 medium / SVT-AV1 preset 6 for VOD; x264 fast / x265 fast / SVT-AV1 preset 10 for live. Adjust from there based on specific quality targets and operational constraints.

#Cross-encoder preset comparison

Comparing presets across encoders is inherently rough because the encoders implement different codec features. As a starting point for "what's the equivalent x264-like preset across encoders":

The "rough equivalent" caveat matters — actual quality at equivalent bitrates differs across codecs even at preset-matched configurations because the codec tools differ.

#Calibration

The preset decision should be validated against actual content. The procedure:

1. Pick representative content samples (genre/format mix that reflects your production).
2. Encode each sample at multiple presets (e.g., medium, slow, slower).
3. Compute VMAF for each preset against source.
4. Compute encoding wall-time for each preset.
5. Plot quality vs encoding-time.
6. Identify the preset that hits your quality target with acceptable wall-time.

This calibration takes a day or two of analysis but pays back across years of pipeline operation. The "right preset" for your content might be different from the default; calibration tells you which.

#What MpegFlow does with encoder presets

MpegFlow's DAG runtime exposes per-rendition preset selection through the workflow YAML; each value flows into the corresponding FfmpegExecutor stage's parameters. The partitioner persists each rendition stage to job_stages with explicit dependency tracking and per-stage retry; sibling cancellation propagates fatal failures across rendition stages so a fast-preset failure on one rung doesn't waste compute on the dependents of a slower-preset rung.

Default presets per content category — sensible starting points, not magic numbers:

• Premium VOD: x265 slow / SVT-AV1 preset 4 for top tiers; x265 medium / SVT-AV1 preset 6 for mid; x264 medium for floor.
• Standard VOD: x265 medium / SVT-AV1 preset 6 across the ladder.
• Live: x265 fast / SVT-AV1 preset 10 / hardware encoder (NVENC where the GPU pool is available; VAAPI on compatible hardware).
• Archive / mezzanine: x265 slower / SVT-AV1 preset 3 for highest quality.

Customers tune presets per workflow to fit their quality and wall-time constraints. The KEDA-driven autoscaler sizes the worker pool to the queued workload, so slower presets that take longer per stage scale horizontally rather than queuing behind faster work.

For customers calibrating presets for their pipeline, we run a side-by-side preset comparison on representative content — encode at medium / slow / slower presets, compute VMAF, plot quality vs encoding time, identify the preset that hits target quality. The calibration is content-specific; "right" presets vary across pipelines.

The strict-broker security model handles preset configuration like any pipeline payload — workers carry no ambient credentials; content access flows through short-lived presigned URLs scoped per stage; access is disposed on completion.

The encoder preset decision is one of the most consequential in pipeline design — it affects encoding cost, quality, and operational throughput. Getting it right requires content-specific calibration, not just defaults. The defaults that ship with MpegFlow are sensible starting points; production-tuning your presets for your content is the ongoing engineering work that distinguishes a tuned pipeline from a default one.