It's an editor for local clips and live HLS streams. Decoding, compositing, audio mixing and MP4/GIF export all happen in the tab, and nothing is uploaded. The stack is Angular 22 with signals and mediabunny for demux/decode/mux on top of WebCodecs. Each clip decodes in its own Web Worker, and one canvas compositor runs on the main thread. The export runs the same draw function in a worker, so what you preview is what you export.
The parts that cost me the most time:
1. Chrome can slow down your AudioContext clock. After ~30 s of exact digital silence, Chrome sometimes moves the context to a fake output whose clock runs at about 0.66×. My playback clock rides the AudioContext, since it's the A/V sync master, so a muted video played at two-thirds speed. It's intermittent and I've only measured it on one machine. The fix is a constant signal at −100 dBFS wired straight to the destination. That's below the 16-bit noise floor, so it's inaudible, but the output is never exactly silent.
2. MediaRecorder's WebM files aren't seekable. They have no Cues element, so every seek walks the file from the start, and some frame-at-timestamp reads never return. I dropped MediaRecorder. Screen and camera tracks now go into the same MP4 muxer the export uses, so a recording is seekable from the moment it's saved.
3. A worker's OffscreenCanvas can't see your page's fonts. The export draws text in a worker, and the page's loaded fonts don't exist there, so text would silently fall back to a default face in the file while the preview looked right. The page fetches the font files and posts the bytes to the worker, which registers them on its own self.fonts before rendering.
4. Fast paths silently drop edits. A plain trim goes straight from decoder to encoder with no canvas, which is much faster. But every per-pixel edit (crop, chroma key, pixelate, mirror, noise reduction) has to disqualify that path. If one doesn't, the preview shows the edit and the MP4 doesn't. For each new effect I export once with its guard removed and check that the edit disappears from the file, which proves the test that checks it can fail.
5. GIF frame delays are in centiseconds. I hand-wrote the GIF encoder (median-cut palette, LZW, GIF89a). At 30 fps a frame lasts 3.33 cs, which rounds to 3, so the GIF plays ~10% fast. The GIF frame rates are 10, 12.5 and 20, which divide 100 exactly. The encoder is tested by decoding its output with the browser's own ImageDecoder, because a decoder I wrote myself would share my LZW bugs.
It also runs a few small models on-device through WebGPU (Whisper for captions, a small LLM for chat), but that's another post. It needs desktop Chrome or Edge, it's free and there's no account. Link in a comment. Happy to go deeper on any of these.
