Ghosts S01e11 Libvpx May 2026

The blocks don’t look like corruption. They look like... memories. Shadows of a previous frame refusing to leave. You’ve just encoded a 10-bit source with Libvpx (VP9), and somehow, the ghost of frame 1,042 is haunting frame 1,043.

Welcome to Ghosts S01E11: Libvpx . Let’s exorcise it. It started with a routine archival job. We were transcoding a film scan (ProRes 4444 → WebM) for a client’s interactive museum installation. The command was standard: ghosts s01e11 libvpx

The ghosting bug in Libvpx v1.11.0–v1.12.0 is largely fixed in v1.13.0+. The patch (Change-Id: I8a3f7b2e9c4d1a5f6e7b8c9d0e1f2a3b4c5d6e7f) corrects the reference frame buffer reset logic after scene detection. The blocks don’t look like corruption

ffmpeg -i input.mov -c:v libvpx-vp9 \ -tile-columns 2 -row-mt 1 \ -lag-in-frames 16 \ # Reduce from default 25 -auto-alt-ref 1 \ # Keep on, but be careful -arnr-maxframes 3 \ # Reduce temporal filtering -cpu-used 2 \ output.webm Two-pass encoding often masks the bug because the first pass forces the encoder to re-evaluate scene boundaries more strictly. Shadows of a previous frame refusing to leave

# Disable alt-ref and limit reference frames ffmpeg -i input.mov -c:v libvpx-vp9 -auto-alt-ref 0 -arnr-maxframes 0 -lag-in-frames 0 output.webm If the ghost disappears, you’ve confirmed it’s an ALTREF or Golden Frame issue. You have three solutions, ranked from "quick fix" to "proper patch."

0
Would love your thoughts, please comment.x