The 48‑Hour Struggle to Build a Browser‑Based Video Editor (And How I Finally Won)
- The Dream That Seemed So Simple
- ⚡ FAST COMPILER LITE
- 📂 CLICK OR DROP FILES
- The First Wall: “Why Won’t You Load?”
- The Breakthrough: Go Back in Time
- Security – Because People Upload Weird Stuff
- The Timeline: From Zero to Drag‑and‑Drop
- The Nightmare of the Filter Graph
- The Moment of Truth
- What I Learned (The Hard Way)
- The Final Tool – Now on My Blog
The Dream That Seemed So Simple
A few days ago I had what I thought was a straightforward idea: create a video editor that lives entirely in the browser. Drag and drop clips, add background music, trim, overlay a second video, and hit “compile” – all without uploading anything to a server. No privacy worries, no monthly fees, just a single HTML file that could even live on a Blogger page.
I knew about FFmpeg.wasm, the legendary video toolkit compiled to WebAssembly. How hard could it be to glue together a few filters and make it work? Famous last words.
⚡ FAST COMPILER LITE
OFFLINE📂 CLICK OR DROP FILES
Video (MP4/WebM) & Audio (MP3/WAV)
The First Wall: “Why Won’t You Load?”
I grabbed some sample code, whipped up a minimal UI, and clicked “Load Engine”. The console immediately spat out:
Uncaught (in promise) RuntimeError: abort(Unable to grow wasm stack).
After some frantic googling I learned that newer versions of FFmpeg.wasm (≥0.11.0) use multi‑threading, which requires a JavaScript feature called SharedArrayBuffer. And SharedArrayBuffer only works if the page is served with special HTTP headers – Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy. On a simple local file, or on a platform like Blogger, you can’t set those headers. So the engine just refused to load.
I spent hours trying to configure a local server with the right headers, but I knew that approach would never work on Blogger. I was ready to give up.
The Breakthrough: Go Back in Time
Late on the second night, buried in a GitHub issue, I found a comment that saved me: “Use version 0.10.1 – it doesn’t need SharedArrayBuffer.” I swapped the script tag, pointed to the older core, and held my breath. The engine loaded. On the first try. I literally punched the air.
That one change turned everything around. The moral? Sometimes the latest and greatest isn’t the most compatible.
Security – Because People Upload Weird Stuff
When you let users drop files, you have to be paranoid. I added:
- File type validation – only video and audio MIME types.
- Size limits – 500MB max per file (browsers can’t handle much more).
- Filename sanitisation – stripping out any dodgy characters before writing to FFmpeg’s virtual file system.
- Text escaping – always using
textContentinstead ofinnerHTMLwhen displaying file names.
It’s not bulletproof, but it closes the obvious holes. For a client‑side tool, that’s enough.
The Timeline: From Zero to Drag‑and‑Drop
I kept the UI brutally simple: two tracks – one for video, one for audio. Each clip shows a small preview thumbnail (just a frame at 1 second), plus Start and End inputs so you can trim. I used the browser’s loadedmetadata event to automatically grab the clip’s duration – a nice touch that saves the user from guessing.
Drag‑and‑drop was easy: a drop zone with the standard events. No external libraries needed. When you drop files, they land in the right track based on their MIME type. I also added a small play button on each clip that opens a modal preview – handy for checking what you just dropped.
The Nightmare of the Filter Graph
Now came the real monster: building the FFmpeg filter string dynamically. Every clip needs to be trimmed, scaled (turbo mode = 480p, normal = 720p), and then concatenated. All audio streams – both from the video clips and the standalone audio files – have to be mixed together. And of course, everything has to happen in the right order.
I must have rewritten the filter generation a dozen times. Every attempt threw a new error:
- “Filter ‘concat’ has an unconnected output”
- “Stream specifier ‘:a’ in filtergraph description”
- “Cannot find a matching stream for unlabeled input pad”
Finally, after way too many console.logs, I settled on a structure that works:
- Write every uploaded file to FFmpeg’s virtual filesystem with a sanitised name.
- For each video clip, create a trimmed video stream and a trimmed audio stream.
- For each audio‑only clip, create a trimmed audio stream.
- Concatenate all video streams into one.
- Mix all audio streams (video‑attached + standalone) into one.
- Map the final video and audio to an output MP4.
The turbo mode checkbox simply changes the scale filter from 1280:-2 to -2:480, cutting rendering time by a huge margin during testing.
The Moment of Truth
After the hundredth “Compilation error”, I finally saw:
✅ SUCCESS! Click download.
A download link appeared. I clicked it, held my breath, and played the video. There were my clips, stitched together perfectly, with the background music I’d added. It worked. It actually worked.
I may have shouted a little.
What I Learned (The Hard Way)
- FFmpeg.wasm version matters. Stick to ≤0.10.1 if you want to avoid the SharedArrayBuffer headache.
- Browser‑based video editing is possible, but you need to respect browser memory limits and understand filter graphs.
- Security can be handled with simple validation and escaping.
- Never give up – every error message is a clue, and the web is full of people who’ve already solved the same problems.
The Final Tool – Now on My Blog
The editor is now live (as a static HTML snippet) on my Blogger site. No server, no uploads – just pure client‑side magic. You can drop in your files, tweak the trim, and download the result. It’s not Adobe Premiere, but for quick mash‑ups it’s perfect.
If you want to peek at the code, it’s all in the conversation above. And if you decide to build your own, remember: when the engine won’t load, try an older version. That one change might save you 48 hours.
P.S. – A huge thank you to everyone on GitHub and Stack Overflow who documented their own struggles. You’re the real heroes.