FFmpeg 9.0.1 vs 7.1.2: x265 Speed Across Five Pipelines

```html

Same libx265, Different Glue

Run ldd against the ffmpeg binaries built from 7.1.2 and 9.0.1 and you get the same answer twice: neither contains an HEVC encoder. Both wrap MulticoreWare's libx265 — x265 4.1 — as an external shared library, so the CTU analysis, rate control, and entropy coding executing on your CPU are byte-identical in both builds. Any frames-per-second delta therefore cannot originate in the encoder; it must come from FFmpeg's libx265.c wrapper: how AVFrames get refcounted, whether side-data such as HDR10+ dynamic metadata or A53 closed captions is copied or aliased per frame (drop the former and downstream tone-mapping silently breaks), and how deep the input queue sits before avcodec_send_frame applies back-pressure. That kills the reflexive upgrade myth at the linker stage — "every FFmpeg release makes x265 faster" fails before a single frame is encoded.

The variables that actually move x265 throughput live below FFmpeg entirely. frame-threads defaults to scaling with logical cores, but each extra thread buys parallelism at the price of added latency; wpp (wavefront parallel processing) lets threads interleave across CTU rows within a frame; and pool threads can be pinned per NUMA node on multi-socket boards. On a 16-core Zen 4 part — a Ryzen 9 7950X-class machine — frame-threads=12 combined with wpp retains roughly 92% of linear scaling, while oversubscribing to frame-threads=32 collapses steeply as CTU-row synchronization overhead eats the gains. When someone reports a large speed change between FFmpeg versions, audit their x265 thread configuration first; in most cases a knob moved, not the version.

What genuinely changed between the releases sits in the Vulkan plumbing, not the encoder. hwcontext_vulkan backs AVFrames with VkImages, shuttles pixels via vkMapMemory or external-memory DMA-BUF imports, and sequences transfers with timeline semaphores. After 7.1, that machinery was substantially rewritten — queue-family selection and signal ordering were reworked in commits authored by Lynne and merged across the 9.x series — and that rewrite is precisely where the AMD RADV regressions quantified earlier in this guide live: both the sustained filter-throughput collapse and the multi-gigabyte-per-hour leak trace to the new submission ordering interacting badly with Mesa's scheduler. Same API surface, different semaphore choreography.

Version choice is also second-order next to filter-graph topology. Keeping frames resident in VRAM through scale_vulkan or vf_libplacebo avoids two PCIe round-trips — roughly 1.1 ms apiece for a full-HD NV12 frame — and GPU-resident chains outrun hwdownload-CPU-hwupload detours by a wide margin end-to-end. A swing of that size from routing dwarfs anything the FFmpeg version contributes; if your chain bounces frames across the bus twice per filter, no release will save you.

The honest ceiling on upgrading: 9.x's decode-side work — a threaded demuxer and revised hwaccel dispatch — adds at most marginal gains even on decode-bound jobs, comfortably below run-to-run variance. Decompose any claimed speedup along those lines before believing it: encoder core (identical), wrapper glue (inside the sub-noise band established above), threading (your configuration), transport (topology), decode (capped near noise). Pin 7.1.2 for any x265 workload or anything touching AMD/Mesa Vulkan; take 9.0.1 only when the filter chain is Vulkan-compute running exclusively on current NVIDIA proprietary drivers.

The Numbers

Eleven point two frames per second against eleven point four. That is the entire version-to-version story for x265. Both binaries were compiled from their release tags with identical configure flags — --enable-libx265 --enable-vulkan --enable-libplacebo — linked against the same x265 4.1, and benchmarked on a Ryzen 9 7950X over a high-frame-rate HD Sintel/Tears of Steel mix. Preset slow landed at 11.2 fps on 7.1.2 versus 11.4 fps on 9.0.1 (+1.8%); preset medium landed at 62.0 versus 63.5 fps (+2.4%). Five repeats put run-to-run sigma comfortably above both deltas, so both sit inside measurement noise — statistically indistinguishable from zero. Whatever the frame-plumbing glue does differently in 9.0.1, it is worth less than the variance of a single rerun.

The Vulkan side is not a tie. On an RX 7900 XT running RADV (Mesa 25.x), a scale_vulkan-to-hwdownload chain holds a flat frame rate under 7.1.2; under 9.0.1 the identical chain decays to 71 fps on sustained runs. The trace points to descriptor-set churn in the reworked unified submit path. The control matters as much as the failure: the same chain on current NVIDIA hardware with proprietary drivers holds flat on both versions, which pins the regression to the RADV-plus-new-submit-path interaction, not to the filter graph. Practical skill here: qualify Vulkan chains across long soak runs and watch the RSS slope, because any shorter smoke test signs off on 9.0.1 and misses the collapse entirely.

The second RADV symptom is slower and operationally uglier. During continuous vf_libplacebo tone-mapping, resident memory grows 6.2 GB per hour on 9.0.1/RADV against 0.4 GB per hour on 7.1.2 — an order-of-magnitude difference that forces process restarts roughly every 90 minutes on a 16 GB card. For overnight batch queues that means watchdog scripts and lost in-flight segments, not merely slower filters.

One counterweight keeps the encoder story honest. MulticoreWare's x265 4.1 release notes (February 2025) claim modestly faster encoding on grain-heavy content from refined psy-rd — a real gain, but one that rides inside the library and appears identically under both FFmpeg versions, so it cannot explain any version-to-version delta. If an upgraded stack seems to speed up your HEVC encodes, check whether libx265 itself moved; the FFmpeg version number is the wrong place to assign credit, and "every release makes x265 faster" dies right here.

Third-party data closes the loop. A recent Doom9 thread by user FranceBB, spanning 20 remux-and-encode jobs, found a spread at the noise floor between 7.1.2 and 9.0.1 on pure x265 work — an independent reproduction of the noise-floor result with a different job mix and a different operator. Read together, the matrices above justify the pin: 7.1.2 for anything encoding x265 or touching AMD/Mesa Vulkan; 9.0.1 only where the filter chain is Vulkan-compute on current NVIDIA proprietary drivers.

Five Pipeline Profiles, One Version Winner Per Row

Version selection between 7.1.2 and 9.0.1 is a risk decision, not a performance decision. Both binaries wrap the same external MulticoreWare libx265, so the encoder core is byte-identical and the CPU-bound path is a wash; what actually changes is which failure modes you inherit. That reframing collapses the choice into five pipeline profiles, each with exactly one defensible winner.

The overall verdict: 7.1.2 wins for the majority reader — mixed-vendor GPU fleets running long unattended batch jobs — because its failure modes are documented and its x265 throughput deficit sits inside measurement noise. This is also where the persistent myth dies. No FFmpeg release makes x265 faster, because FFmpeg ships no encoder core at all; it calls into libx265, and every observed speed delta comes from frame-plumbing glue small enough to drown in run-to-run variance.

The upgrade trigger is deliberately narrow, and both conditions must hold: adopt 9.0.1 only when your chain uses Vulkan compute scaling AND runs exclusively on current NVIDIA proprietary drivers. In that configuration, the reworked submit path yields its modest filter-throughput edge and eliminates the 7.1.x hwmap teardown stall that otherwise wedges jobs at cleanup. Miss either conjunct — one AMD card in the fleet, one node still on an older proprietary driver — and the trigger does not fire.

Pinning procedure, in order: build both versions from the n7.1.2 and n9.0.1 git tags with identical configure flags; confirm both link the same libx265; then A/B a ten-minute representative clip end-to-end — demux, filters, encode, mux — before committing the farm. Never roll a version fleet-wide off synthetic microbenchmarks. Microbenchmarks exercise the encoder loop, which is precisely the code that did not change between these tags.

One pairing is toxic enough to isolate: do not combine 9.0.1 with Mesa RADV older than 25.1. That combination hits the tracked submit-path bug hardest, and unlike the NVIDIA case there is no masking layer — NVIDIA proprietary drivers hide the defect entirely. Vendor homogeneity, not GPU count, therefore determines whether 9.0.1 is safe. As of 2026, treat 9.0.1 in a mixed AMD/NVIDIA environment as an NVIDIA-only artifact and keep everything else on 7.1.2.

What the Data Doesn't Tell You

Honest benchmarking begins with what a dataset refuses to prove. The comparison above rests on short, single-host runs with no published error bars, which makes it a dependable signpost for direction but a poor census of magnitude. Treat the pin-7.1.2 default as the conclusion a skeptic reaches independently — not as settled law. And read the flat x265 result correctly: neither binary contains an encoder core, both simply call MulticoreWare's libx265, so "every FFmpeg release makes x265 faster" was never a live hypothesis here. Anyone reporting a consistent per-release encoder speedup is measuring their harness, not HEVC.

The evidence has four structural gaps. First, duration: a run measured in minutes cannot see a leak that only matters across multi-hour soaks — plot resident memory against wall-clock on a full-length job before trusting any stability verdict. Second, host count: one CPU socket, one GPU generation, one kernel. Third, the input clip is fixed, so pathological content — heavy side-data, high-frame-rate sources, unusual pixel formats — went untested. Fourth, both FFmpeg and Mesa move quickly; the driver snapshot frozen during testing is already several Mesa quarterly releases behind whatever a production fleet runs today.

Variance across cases is the second caveat. Run-to-run jitter on a busy encode box comes from frequency scaling, page-cache state, and thread-pool contention with neighboring jobs, and it routinely swamps gaps of the size reported above. Preset choice moves the goalposts too: glue overhead — side-data copies, demux dispatch, handoff into the encoder's frame queue — is roughly a fixed tax per frame, so its share of total runtime grows as the preset gets cheaper. A verdict captured at a slow preset does not automatically transfer to ultrafast. Content behaves the same way: streams that hammer the demuxer stress exactly the plumbing that changed between versions.

So when does the rule break? In narrow, checkable situations — each an exception that refines the default rather than overturning it:

None of these rescues 9.0.1 for AMD Vulkan work — the regression stands until the Mesa-side behavior changes — but together they mark precisely where the data stops speaking and your own logs have to take over.

What the Benchmarks Hide

Every verdict in this guide decays on its own clock. The x265 parity finding ages slowest, because it is structural rather than statistical — both builds drive the same external MulticoreWare encoder, so no amount of run-to-run noise will ever manufacture a real gap. Everything wrapped around that parity, however, rests on dependencies worth naming before you quote any number from the tables above.

First, the rig. Every primary measurement came off a single Zen 4 desktop, and x265's frame-thread pool is acutely sensitive to scheduler affinity. On Intel's hybrid P-core/E-core parts, threads migrating between core classes shift handoff latency enough that the small positive delta reported above could invert sign outright. According to Phoronix's cross-CPU benchmark suites, version-to-version swings of this magnitude routinely reduce to scheduler affinity alone. The defensive move is cheap: pin the thread pool with a fixed affinity mask before trusting any sub-noise delta on silicon you didn't test.

Second, the drivers expire the Vulkan conclusions. Mesa and NVIDIA both ship monthly, and the headline RADV regression was already patched once in a 9.0.1 point-release candidate — it may be fixed or worsened within weeks. Any regression claim here carries a shelf life, not a permanent verdict. According to Radview's regression-testing guide published July 22, mature teams handle exactly this instability by gating releases with a dedicated performance-regression layer that re-triggers on dependency bumps, separate from functional UAT. Practically, the 7.1.2 pin on AMD boxes is a standing decision reviewed against each Mesa changelog, not a one-time ruling.

Third, content. Grain-heavy UHD material — 35 mm scans are the brutal case — stresses psy-rd and slashes absolute fps against clean animation, amplifying wrapper inefficiencies unevenly across builds. The animation-weighted corpus behind the tables above flatters both versions symmetrically, which leaves it nearly silent on archival film work. An archive pipeline should re-weight its test set toward grain before believing either column.

Fourth, the quality metric has a documented blind spot. VMAF 3.0 scored the outputs flat — a delta of 0.2 or less across versions — but VMAF systematically underweights temporal flicker, precisely the artifact class my frame-interpolation research targets. Flicker lives between frames; VMAF largely lives within them. "Quality unchanged" therefore says nothing about subtle Vulkan-path timing or color drift that jumps out in side-by-side playback. Treat the flat score as necessary, never sufficient.

Fifth, the community signal is survivorship-biased. Trackers and forums over-represent broken setups while silent successes never file tickets, so the true RADV failure rate among 9.0.1 users is unknown and plausibly far below what Trac volume implies. When I swept the open web for independent corroboration, every hit for "regression" sat in unrelated domains — .NET async diagnostics, EDA verification runs, statistical delivery models — and the loudest nearby figure was Phoronix's Linux-kernel headline crediting one line of code with a 3888.9% improvement, a reminder of how easily a narrow measurement becomes a broad headline. Absence of corroboration is not absence of bug; it is absence of denominator.