Video encoding, harvested from two apps at once
09-07-2026
DOM/ffmpeg and DOM/recorder landed together: encode a canvas timeline to MP4 in the browser, and capture screen, camera or canvas to a Blob.
They are the clearest case of the harvest rule so far, because the same thing had been built twice without either author noticing. Phlo Presentation needed to render a slideshow to video on the client. flysight.video needed to burn GPS overlays onto jump footage. Two apps, two hand-rolled pipelines around ffmpeg-wasm and WebCodecs, no shared line between them. Both were replaced by the resource on the day it was extracted.
The boundary matters more than the code. The app keeps what is genuinely its own: a drawFrame(ctx, t) callback and a description of its audio. The engine takes the part nobody wants to write twice: encode() for the canvas timeline to MP4, frameSource() for decoding source frames through WebCodecs with a seek fallback, and transcode() for everything else.
Some hard-won details came along. Encoding prefers a hardware VideoEncoder and retries in software before falling back to the slow ffmpeg-wasm pass. Source demuxing streams over HTTP range requests, which removed a size ceiling on input files. And MediaRecorder records only one audio track, so a screen capture with both tab audio and a microphone silently lost one until the recorder started mixing them through an AudioContext first.