Two-pass encoding — when it matters and when single-pass is fine

Two-pass encoding is a technique where the encoder analyzes the entire video in a first pass to understand content complexity, then uses that analysis in a second pass to produce the final output with smarter bit allocation. It's most useful when you need to hit a specific average bitrate target — at fixed bitrate, two-pass meaningfully improves quality over single-pass. For modern CRF-based workflows, two-pass is usually unnecessary. This page is the engineering reference for when two-pass earns its wall-time cost.

#What two-pass encoding is

Two-pass encoding splits the encoding job into two distinct passes:

First pass — encode the video at low quality (fast settings), measure per-frame complexity, write statistics to a sidecar file. The output of the first pass is typically discarded; only the stats file matters.

Second pass — read the stats file, plan bit allocation across the entire video based on the per-frame complexity profile, encode at full quality with informed bit allocation.

The benefit: the second pass knows that frame 1500 is a complex action shot that needs more bits, so it can save bits in the static talking-head frames before it to make budget. Single-pass encoding doesn't have this lookahead — it makes decisions frame-by-frame without knowledge of what's coming later.

Wall-time cost: two-pass roughly doubles the wall-time of single-pass encoding (first pass is usually ~50% the time of second pass since it's at lower fidelity).

#When two-pass matters most

Two-pass produces meaningful quality improvements in specific scenarios:

Target-bitrate VBR with strict budget — when you have a hard average bitrate target (e.g., "this 90-minute movie must encode to exactly 4 GB"), two-pass's bit budget allocation is significantly better than single-pass. Quality differences of 1-3 VMAF points at the same bitrate are typical.

Low bitrates — at constrained bitrates, every bit counts. The smarter allocation in two-pass shows up more clearly. At 600 kbps for 720p H.264, two-pass might give 2-3 VMAF improvement over single-pass; at 5 Mbps for the same content, the gap shrinks to <1 VMAF.

Long-form content — two-pass benefits compound on longer content. The bit allocation has more opportunity to balance budget across diverse complexity. Short clips don't benefit as much because there's less budget arbitrage to perform.

Low-complexity content with occasional high-complexity peaks — content that's mostly easy with hard moments (talking-head shows with cut-aways, news with action B-roll). Two-pass identifies the hard moments and saves budget for them.

#When two-pass doesn't matter

Two-pass is unnecessary or inapplicable in several cases:

CRF mode — CRF doesn't have a bitrate target to plan against. Each frame gets bits based on its own complexity at the configured quality level. Two-pass adds nothing because there's nothing to plan.

Capped CRF — same logic. The cap is per-frame, not aggregate; second-pass planning isn't needed.

Live streaming — you don't have future frames to analyze. Two-pass is fundamentally incompatible with live encoding.

Very high bitrates — at high enough bitrates that quality is already near ceiling, the two-pass improvement is invisible. At 50 Mbps for HEVC 4K, single-pass and two-pass produce visually-identical output.

Fast iteration — when you need quick encodes for review or testing, two-pass's wall-time cost isn't worth the modest quality improvement.

Hardware encoders — most hardware encoders don't support two-pass. They're designed for streaming pipelines where wall-time is the constraint.

#CLI patterns

x264 two-pass:

# First pass
ffmpeg -y -i input.mp4 -c:v libx264 -b:v 4M -pass 1 -an -f null /dev/null

# Second pass
ffmpeg -y -i input.mp4 -c:v libx264 -b:v 4M -pass 2 -c:a aac output.mp4

The -pass 1 and -pass 2 flags trigger the two-pass behavior. The first pass writes to ffmpeg2pass-0.log (and related files); the second pass reads from them. The -y flag overwrites existing output; -an in the first pass disables audio (audio doesn't matter for video bit-allocation analysis).

x265 two-pass:

ffmpeg -y -i input.mp4 -c:v libx265 -b:v 4M -x265-params pass=1 -an -f null /dev/null
ffmpeg -y -i input.mp4 -c:v libx265 -b:v 4M -x265-params pass=2 -c:a aac output.mp4

x265 uses the codec-specific parameter syntax. The behavior is the same.

SVT-AV1 two-pass:

ffmpeg -y -i input.mp4 -c:v libsvtav1 -b:v 4M -svtav1-params passes=2:pass=1 -an -f null /dev/null
ffmpeg -y -i input.mp4 -c:v libsvtav1 -b:v 4M -svtav1-params passes=2:pass=2 -c:a aac output.mp4

SVT-AV1's two-pass support has been improving across versions; quality gains vs single-pass VBR are real but smaller than x264/x265's improvements.

#Three-pass and N-pass

Some encoders support more than two passes. The marginal benefit drops rapidly:

• Single-pass to two-pass: meaningful improvement (1-3 VMAF at constrained bitrates).
• Two-pass to three-pass: small improvement (~0.5 VMAF), 50% more wall-time.
• Three-pass to N-pass: diminishing returns.

In practice, three-pass and beyond aren't used in production. Two-pass is the only multi-pass mode that's broadly justified.

#Two-pass and per-title encoding

Per-title encoding (see per-title encoding) involves multiple analysis encodes per content asset. There's a question of whether to use two-pass for those analysis encodes.

The pragmatic answer: usually not. Per-title analysis already involves multiple encodes; adding two-pass to each multiplies the wall-time. The bitrate selection from per-title is robust to single-pass analysis quality variance.

For the final production encodes after per-title selection, two-pass at the chosen bitrate may be worth it. The selected bitrate is intentionally constrained; two-pass smarter allocation matters at constrained bitrates.

#Two-pass and live encoding

Live encoding is single-pass by necessity. You can't analyze frames you haven't encoded yet. There's no "live two-pass."

Some live workflows use a delayed-output technique that approximates two-pass benefit:

1. Encode at low fidelity in real-time.
2. Buffer the output.
3. Re-encode at higher fidelity using the first encode's stats (effectively a delayed second pass).

This is rare in production because it adds latency (typically 30-60s) and operational complexity. Most live workflows accept single-pass encoding and tune the encoder presets to compensate.

#Two-pass and rate control mode

Two-pass interacts with rate control mode:

The pattern: two-pass matters when there's a bitrate target to plan against. CRF-based modes don't have one; bitrate-targeted modes do.

#Two-pass operational considerations

Things that matter in production two-pass workflows:

Stats file storage — first-pass stats files are typically small (~1-10 MB for a feature-length video). Need persistent storage between passes; can be transient.

Wall-time scheduling — two-pass jobs take ~2x as long. Scheduler needs to account for this when making promise-based delivery commitments.

Failure handling — if the first pass succeeds but the second pass fails, do you re-run both passes or just the second? Re-running just the second is faster but requires confidence the stats file is intact.

Stats file portability — first-pass stats are encoder-version-specific. If you upgrade the encoder between passes, the stats may be invalid. Either re-run both or carefully manage versioning.

Inter-pass latency — if you're queueing two-pass jobs and the second pass waits behind other work, total wall-time grows. Two-pass is best when the second pass runs immediately after the first.

#A historical note on two-pass

Two-pass encoding was much more important in the early-to-mid 2000s than it is today. Early codec rate control was crude — H.263 and early H.264 single-pass VBR could produce wildly varying quality across content, with the encoder making poor frame-level decisions because it lacked global context. Two-pass was a meaningful quality improvement that justified its wall-time cost on every serious VOD workflow.

Modern encoders (x264 since ~2010, x265 since launch, SVT-AV1, current libvpx) have much better single-pass rate control. The lookahead in current x264 is sophisticated enough that single-pass VBR at modest bitrates approaches two-pass quality. The improvement margin two-pass offers has shrunk; the wall-time cost hasn't.

The 2026 reality: two-pass is a tool you reach for when bitrate constraint is tight and quality matters more than wall-time. Most modern workflows don't fit that profile and use single-pass capped CRF instead. Two-pass isn't dead; it's just less universal than it was.

#What MpegFlow does with two-pass

Two-pass is supported per workflow as a pair of FfmpegExecutor stages with explicit dependency tracking. The partitioner persists both stages to job_stages; the first-pass output (the stats file) flows into the second-pass input via cross-stage data flow; per-stage retry handles transient failures. Default encoding mode for streaming workflows is capped CRF (single-pass); customers opt into two-pass via workflow YAML for use cases where it matters — primarily strict-bandwidth-target VOD (mezzanine production, archive at constrained bitrate, contribution feeds with bitrate budget).

If the second pass fails after the first pass succeeded, per-stage retry can re-execute just the second pass against the persisted stats file; sibling cancellation prevents dependents of a fatal failure from running. Encoder-build changes (the worker image rolling forward) invalidate stats and require both stages.

For customers asking whether two-pass is worth it for their content, the typical answer: probably not for streaming ABR ladders (capped CRF gets you there); definitely yes for strict-bitrate VOD targets where the budget is tight; sometimes yes for archive at constrained bitrates. The right answer depends on the bitrate budget vs content complexity tradeoff for the specific use case.

The strict-broker security model handles two-pass like any pipeline payload — workers carry no ambient credentials; content access for each pass flows through short-lived presigned URLs scoped per stage; the stats file flows between stages as workflow data; access is disposed on completion. Two-pass doesn't change the security posture; it changes the encoding wall-time.