How we measured.

The setup

• Metric. VMAF — the 0–100 perceptual metric developed at Netflix and used across the streaming industry to score how close a compressed video looks to the untouched original. Mid-90s and up is visually identical to the master; below 90 the damage is visible; below 60 the file is unusable.
• Adobe’s files. Rendered by After Effects’ own H.264 encoder via aerender, at the three bitrates its Render Queue offers (5 / 15 / 40 Mbps). Measured exactly as AE produced them — no re-encode, no simulation.
• BetterQueue’s files. Produced from the identical lossless master with the exact FFmpeg arguments BetterQueue emits.
• References. Lossless masters (TIFF/PNG sequences or FFV1), verified bit-exact by framemd5 before use.
• The clips. A real client social ad (1080×1350, 63 s — gradients, type, held frames); two clips from the Xiph raw-video corpus, the industry-standard codec-test set (old_town_cross, a slow aerial drift over a city, and crowd_run, runners filling every frame — the standard torture test); plus two synthetic control clips used to validate the harness.

The headline result: one preset, three fates

After Effects’ 5 Mbps H.264 preset and BetterQueue’s CRF 18 — both untouched — on three very different clips.

A fixed bitrate spends the same bits on a held title card as on a whip pan, so the same preset swings from beautiful to broken depending on the footage. A quality target spends whatever each frame needs — the file size moves so the quality doesn’t. This is the one result that held on every clip we tested, and it is the claim the page leads with.

The mirror image on easy content: AE’s 40 Mbps “quality” preset spent 225.1 MB on the social ad to buy 0.19 VMAF over its own 5 Mbps preset (25.6 MB @ 97.73 vs 97.92). BetterQueue’s CRF 12 veryslow encode of the same ad: 7.3 MB @ 97.51 — 31× under the preset a quality-conscious user would pick, at a gap of 0.41 VMAF. Published estimates put one just-noticeable difference at 2–6 VMAF points; 0.41 is far below the bottom of that range.

What we cannot claim

• No universal size win. At matched quality on the Xiph clips: 49% smaller than AE’s 5 Mbps on the aerial pan, 16% smaller than 15 Mbps on the crowd — but 15% bigger than AE’s 40 Mbps on the crowd and 140% bigger on the pan at that highest target. BetterQueue wins on easy content and low-to-mid targets; Adobe wins on hard content at high targets. The saving tracks how much the picture holds still.
• x264 does not beat Adobe’s encoder at equal file size. On the social ad at ~25 MB the two were a wash (97.56 vs 97.73, Adobe marginally ahead). The win is rate control — being allowed to pick a quality at all — not a superior codec.
• We cannot beat Adobe’s VMAF at any size on that ad. The x264 curve plateaus around 97.6; only true lossless reaches Adobe’s 97.9. “Indistinguishable and far smaller” is supportable; “higher quality” is not.
• GPU is the speed path, not the quality path. NVENC CQ 18 measured ~2× x264’s encode speed but spent 62% more bytes on the grain-heavy control clip. That is why software stays BetterQueue’s default and the GPU is a labelled per-export choice.
• x264’s psychovisual tuning costs VMAF (-tune ssim scores higher in smaller files) — but psy exists to make video look better while scoring worse, so we did not switch it off to win the benchmark.

The colour receipts

After Effects’ H.264 ships with no colour metadata — the classic “my export came back washed out” bug. Probed directly:

Decoding AE’s output under each possible assumption and comparing against the RGB master shows it actually contains bt709 limited-range (bt709/tv wins by ~9 dB) — it just never says so, leaving every player to guess. BetterQueue writes the Rec.709 tags on every export.

Method — and the four bugs that nearly shipped a lie

The comparison is symmetric: both files are decoded back to RGB (declaring bt709/limited, since AE tags nothing) and take an identical trip to YUV 4:4:4 before VMAF. Getting any of this wrong produced spectacular, completely false results first — all four are guarded against in the harness now:

1. Frame-rate drift. FFmpeg defaults an image sequence to 25 fps, so a 30 fps master silently became a 25 fps reference. VMAF pairs frames by timestamp, so it measured drift and scored Adobe 67 at every bitrate — a constant score across bitrates looks exactly like a thrilling result. The harness now refuses to measure until reference and candidate agree on fps and frame count.
2. Asymmetric colour. Scored in the YUV domain, our encodes match the reference bit-for-bit (FFmpeg made both) while Adobe’s carries Adobe’s own RGB→YUV conversion — charging it for a colour conversion that isn’t compression loss. Hence the symmetric RGB decode.
3. A broken log path. libvmaf’s log path can’t hold a Windows drive-letter colon; every score silently read back 0 and the interpolation confidently printed “−97% at VMAF 0.0.” A zero score is now a hard failure.
4. RGB hiding in a YUV container. ProRes 4444 reports color_space=gbr — the planes hold RGB. Encodes made from such a master carry a constant levels error that compression damps, so quality appeared to rise as CRF rose, and a bit-exact lossless copy scored below a 1 MB file. The harness now hard-fails on an inverted quality curve, because compressing harder cannot improve quality.

Reproduce it

You need an FFmpeg build with libvmaf, After Effects, and a lossless master. The core loop:

Sweep CRF 8–28 to build the quality/size curve, and check every sanity guard above — especially that lossless scores highest and that quality falls as CRF rises. Run on Windows 11 / RTX 5090 / After Effects 2026 (26.3). The client comp is a real deliverable and stays private; the Xiph clips (crowd_run_1080p50, old_town_cross_1080p50) are freely available from media.xiph.org.