Show HN: VidStudio, a browser based video editor that doesn't upload your files (vidstudio.app)

301 points by kolx ↗ HN
Hi HN, I built VidStudio, a privacy focused video editor that runs in the browser. I tried to keep it as frictionless as possible, so there are no accounts and no uploads. Everything is persisted on your machine.

Some of the features: multi-track timeline, frame accurate seek, MP4 export, audio, video, image, and text tracks, and a WebGL backed canvas where available. It also works on mobile.

Under the hood, WebCodecs handles frame decode for timeline playback and scrubbing, which is what makes seeking responsive since decode runs on the hardware decoder when the browser supports it. FFmpeg compiled to WebAssembly handles final encode, format conversion, and anything WebCodecs does not cover. Rendering goes through Pixi.js on a WebGL canvas, with a software fallback when WebGL is not available. Projects live in IndexedDB and the heavy work runs in Web Workers so the UI stays responsive during exports.

Happy to answer technical questions about the tradeoffs involved in keeping the whole pipeline client-side. Any feedback welcome.

Link: https://vidstudio.app/video-editor

49 comments

[ 3.3 ms ] story [ 64.0 ms ] thread
> FFmpeg compiled to WebAssembly handles final encode

FFmpeg's license is the LGPL 2.1. VidStudio looks like closed source software, I couldn't see any indication that it's free software. You're distributing this software to run in the client's browser. I'm not a lawyer but I think you're in breach of the terms of the LGPL.

https://www.ffmpeg.org/legal.html

I've built a similar video editor and have been considering pure client side implementation vs transcoding into a known format beforehand, went with transcoding for wider format support and easier video playback implementation.

I'm interested in how you handle demuxing different container formats any which ones are supported?

I get "Audio decode failed: your browser cannot decode the audio in "41b1aee9-ac65-43f6-b020-e8fed77c3c72_webm.bin". Try re-encoding the file with AAC audio." for a WEBM with no audio.

h264/aac MP4 works, is that demuxed with mp4box.js? I noticed seeking (clicking or scrubbing on timeline) initializes a new VideoDecoder and destroys the previous one for every new frame, leading to abysmal performance as you lose decoder state and a lot of decoding work has to be repeated. Plus the decoder reinitialization time. Is that because the demuxing logic doesn't give precise access to encoded frames? iirc mp4box.js didn't support that last time I checked.

You probably already know this, but I could not import 10-bit video on Windows which I think would be fairly common among the target audience.

ffmpeg supports decoding 10-bit video.

Interesting approach—privacy-friendly editing without uploads is compelling. Curious how you handle performance and large files purely in-browser, and what trade-offs there are vs server-based editors.
Let me just say the performance is absolutely incredible, and the persistence is so transparent. I actually was given access to an in-browser video editor that chokes pretty quickly so I'm impressed. The tracks didn't seem to work well for me. I'm on Firefox on Windows and couldn't drag and drop tracks to change the order, there doesn't seem to be any layer transformation tools (position, rotation, scale) that I could find to counteract it not handling footage of different aspect ratios (I.E. portrait and landscape).
Wild that apps used to be completely local, no accounts, no uploads, and we're back to that as a value prop.
But this time sandboxed and you have some mod capabilities if you know how to use greasemonkey scripts.

And all the text in the app is selectable and copypastable.

Curious how you're handling the MP4 export entirely client-side — are you using FFmpeg compiled to WebAssembly, or something custom built around the WebCodecs API?
Sorry for the significantly unrelated comment:

Does anyone know if there is any limitation to create a "https-local://" or something like that, which guarantee that things are only downloaded, and never uploaded?

I don’t know, but I’ve thought for a while that a browser version of “pledge” to permanently restrict uploads from a webpage after it is called would be a great idea.
Wild that privacy became a feature and not the default. Building in this space too and the no uploads needed angle is surprisingly hard to communicate to users who've been trained to expect everything to live in the cloud.
I think the majority of users want their data in the cloud. Edit on desktop, send link to work to client, client looks at it on their phone. No need to export. Change something, client sees it immediately.

Even if it's not business. Sister shares video she edited of party. Mom points something out, sister makes edit.

I'm not saying there's no use to local only solutions. I'm only saying that I suspect for most users, the benefits of in the cloud are something they want.

I've seen dozens of these posted to HN. Surprisingly, there is a lack of browser based video editors for media libraries, which means I have to load the video over the network using WebDAV or Samba, edit it locally, and then upload it back. It's a niche use case, but the people who manage their own photos and video storage are generally tech savvy, so it's surprising that no such tools exist.
I love no accounts and no cloud a lot!

Wondering if it support subtitle and transcript? It would be helpful for non-native speaker use case.

Also, can you talk more about the use case difference between VidStudio vs. Finalcut/Imovie/Premiere? I am quite interested. Thanks

(comment deleted)
It is on my to do list to add automatic subtitles. The 3 editors you mentioned are backed by cloud juggernauts that either asked already or will ask for a perpetual licence to any content you process with them because they can and they also offer cloud options. I do have to say that they are probably more mature and feature rich than VidStudio at this point in time ahhaha
I worked on something similar for a relative who wanted to know if I could build something like this for them using Claude, and sure enough you can, I wound up having to ditch ffmpeg wasm edition because of a lot of slowness, and when with ffmepg on the backend. Curious how this performs vs ffmpeg on the backend. I'm genuinely surprised there's not 100% browser native solution to this.
looks great. any plans of abstracting these functions with an LLM integration?
I recently did something similar but as a Mac app.

It sounds like a similar stack, but distributed as an app. FFmpeg (LGPL compilation).

I haven't tried Pixi.js, looks interesting. I guess it was good for this.

Have you looked at remotion? I found them good for somethings, but ended up using Safari for rendering (instead of remotion's chrome-based rendering) because app packaging was easier that way.

https://www.loremlabs.com/cliproom if you're interested in comparing

Cool project will check it out. I have not checked Remotion but will certainly take a look.
This is so cool - will try it out. Pure browser based video editing is ambitious. Are you using Remotion ?
I have not checked out Remotion but will do thanks for pointing it out!
Congrats on shipping this!

I went down the same path for videotobe.com, fully client-side with ffmpeg.wasm, and it fell over on longer videos. The memory ceiling and encode times pushed me to a cloud processing pipeline.

You've managed to solve both, the WebCodecs plus Pixi plus ffmpeg.wasm split looks like the right decomposition in hindsight.I processed 3+ hrs of media using VidStudio and it held up. Nicely done!

Wow this is really cool thanks a lot for sharing I was a bit demotivated from all the errors I have on sentry ahahha. I did give ffmpeg wasm my best shot, even trying worker fs to deal with the memory problems but yeah a lot of effort for marginal gains imo. Video codecs are really impressive but they are raw in the sense that I underestimated how much ffmpeg carries by giving you a decode, transform encode pipeline.
What is the performance difference between native FFmpeg and WebAssembly-translated FFmpeg running in a web browser?
Wasm ffmpeg is much slower for sure and multithreading for wasm ffmpeg is buggy you need to control threads per pipeline step to get it working.
I am really attracted to the idea of local running in-browser tools, since the website is then used only as a distribution medium which is super easy to use. And I really need such a tool, I was eager to test it. However on both my first and second try it failed. I tried to import a video clip recorded on a Pixel phone. In Firefox it failed with a following message:

"Your browser does not support the codec "hvc1.2.4.L156". Try a different video."

Ok, fair, probably need to use Chrome for this type of tool. Tried it in Chrome:

"Audio decode failed: your browser cannot decode the audio in "..._webm.bin". Try re-encoding the file with AAC audio."

Sad. Hope you manage to work this out. Let me know if you have a newsletter or something where I can get notified if this gets fixed.

Hey this is on my todo list and will make it a point to get back to you here once it is fixed. The main issue is that codec support is patchy most muxer software that I found has gaps in codec support and I had no clue but the codec names for audio and video seem to be named differently based on platform and browser even for some cases. Will be looking again at this topic asap and will get back to you here!
Hey, I had to rework a few things to try and address this issue and that exposed another bigger problem so thank you very much for flagging this. I released a fix primarily for chrome but firefox seems to be a lot harder to solve but I will start working on a fix for that as well.
LGPL issues aside, will a project like this need to pay the h264 patent fee?
I really like all the compress-to-X links at the bottom and the convert from X to Y tools. Especially the Discord one with presets for different target file sizes based on Discord's subscription tiers.

I've been using server-based (online, upload required) tools for this sort of stuff, but am now going to be using this.

Pretty cool find considering I have no need for a full-fledged video editor right now, and was just checking this out for fun.

The hvc1 and 10-bit failures a few comments up aren't a FFmpeg-wasm fallback thing, they're a WebCodecs browser-gap. Firefox's HEVC path is partial and 10-bit paths are worse. Chrome mostly works and Firefox fails on the exact files iPhones and modern Androids record by default.

A "your browser can't decode this codec, try Chrome" nudge would probably spare people the bounce, especially on test imports from their phone.

Good idea. Once I am through the licensing ordeal I have a giant stack of errors to tackle which should increase usability.