glitchforge is a video-glitch studio that runs entirely in your browser. You load a
clip, build a chain of effects, and it re-renders the video — and nothing is ever uploaded.
The whole engine, including a real video codec, runs client-side in WebAssembly. The clip never leaves
your device.
Codec-domain glitching
glitchforge works inside the compressed video bitstream. It decodes MPEG-4 Part 2 and H.264 (CAVLC) down
to their internal syntax elements — motion vectors, DC/AC coefficients, quantizers —
edits those directly, and re-encodes. Because the change happens in the compression itself, it reaches
results pixel filters cannot: motion vectors that pull pixels from the wrong parts of earlier frames,
scrambled coefficients, warped quantizers, altered block modes. Alongside these are frame, pixel, and
analog effects — VHS, bloom, channel desync, pixel sort, feedback, melt, and more.
In the lineage of FFglitch
FFglitch (Ramiro Polla) established
that a codec's internals — motion vectors, quantized coefficients — can be surfaced as editable data and
scripted on top of a modified FFmpeg. It is the reference point for codec-domain glitch art, and
glitchforge grows out of that lineage. It carries the idea in its own direction: a byte-exact
reimplementation of the codecs, a curated palette of named effects spanning multiple codecs, per-parameter
controls, and a rack that reverse-explains what each effect does to the bitstream.
How it's built
The engine is Python paired with a byte-exact Rust codec that performs the native
bitstream editing — parsing, mutating, and re-serializing MPEG-4 and H.264 at the level of individual
syntax elements. On top of the codec sit the effects and the recipe/pipeline model that chains them
together into a render.
How it runs in your browser
That entire engine is compiled to WebAssembly so it runs client-side, with no server.
Pyodide runs the Python (CPython, in wasm), the Rust codec ships as a wasm module,
ffmpeg.wasm handles general decode and encode, and WebCodecs drives a
hardware-accelerated streaming pixel pipeline so longer clips stay within memory. Everything runs off the
main thread in a Web Worker, so the page stays responsive while a render is in progress.
This is also why clip lengths are capped. Every frame is decoded, changed, and re-encoded on your own
device; there is no server to do the work. A browser tab can use only so much memory — about one to two
gigabytes. A clip past a certain length needs more than that, and when it runs out, the tab crashes or the
render fails. The cap keeps you under the limit.
Your browser is missing a capability glitchforge needs. Here is the
exact chain glitchforge runs on every render, and the step where yours breaks.
1 · Decode — get the frames out
To change a video you first have to turn its compressed H.264 / HEVC bitstream back into raw pixels.
glitchforge does this with the device's own hardware video decoder, reached through WebCodecs
— the VideoDecoder API. Without VideoDecoder there is no way to pull individual
frames out of the file at any usable speed.
2 · Transform — the engine itself
Each frame is handed to a real image engine running inside your browser: CPython, compiled to
WebAssembly (Pyodide), plus a byte-exact codec written in Rust, also
compiled to WebAssembly. Nearly every browser can do this part — WebAssembly is universal — and it runs in
a Web Worker so the page never freezes. This is not where you break.
3 · Re-encode — write the video back out
The changed frames have to be compressed back into a playable file, again through the device's hardware
encoder via WebCodecs — the VideoEncoder API. This is the piece Firefox, and
Firefox on Android in particular, either does not ship or ships incompletely. No VideoEncoder,
no way to write the result back out.
Why not just use ffmpeg?
glitchforge does ship ffmpeg compiled to WebAssembly, and the codec-bitstream effects
(the H.264 and MPEG-4 ones) lean on it — those may still limp along here. But decoding and re-encoding
every frame of HD video in software, inside a browser tab, is far too slow and far too
memory-hungry: a tab can hold roughly 1–2 GB before it crashes. The hardware WebCodecs path is the only
one fast and light enough to work in a browser at all, so its absence is fatal for the pixel and analog
effects.
What does work
A recent Chrome, Edge, or Safari — on desktop or on
iOS. They all expose WebCodecs. Open the same link there and it works.
effects
Tap an effect to run it. This in-browser version runs one effect at a time — tapping
another replaces it. (The full app, run locally, chains as many as you like.)
source
Renders clips up to about 15 seconds. It runs in your browser, so a render takes
several times the clip's length.
Drag a video here, or click to choose
pipeline
The effect you tapped, ready to render. Tap it to tweak its settings.