Show HN: VidStudio, a browser based video editor that doesn't upload your files

Posted by kolx 1 hour ago

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

Comments

Comment by elpocko 1 hour ago

> 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

Comment by prhn 48 minutes ago

Closed source is fine, but there are a few other things that are required of LGPL, some of which are

- Provide links to the source of the version of ffmpeg you used in your code

- User should be able to replace the ffmpeg libs with his own compatible builds if you're using dynamically linked libs. For statically linked libs, you need to provide the tools to re-link against a compatible build.

I went through an LGPL review recently so some of this is fresh in my memory, but please correct me if I'm wrong.

Comment by xixixao 12 minutes ago

Dynamically and statically linked libs is hilarious in the context of webassembly running in the browser.

Comment by kolx 37 minutes ago

Thank you for pointing this out, to be completely honest, I did not consider licensing because the website started as a collection of tools I built to run locally and get into video/audio codecs then I realised it is already a decent collection of tools that other people might want to use too. But I will be making the needed changes to comply fully tonight. At least I comply with this: `Do not misspell FFmpeg (two capitals F and lowercase "mpeg")` I realised I have some more reading to do regarding GPL vs LGPL because of the wasm project.

Comment by freedomben 34 minutes ago

Any reason not to just open source it? Personally I'd love to hack on it :-) IANAL, but IMHO AGPL would be a good fit here as it complies with LGPL and also ensures nobody besides you (the copyright holder) can stand it up for profit without contributing back).

Comment by netdevphoenix 28 minutes ago

> Any reason not to just open source it?

Mmmm...potential commercialisation? Always find it curious that people expect to get source code for free in ways that they don't do for other work (ask George Martin to release his drafts and notes).

Comment by mbesto 19 minutes ago

The parent commenter is making that comment because this is precisely the nature of why the GPL license exists. Most of the processing of this application is FFMPEG, so why should someone who has done zero development on that library commercialize it?

Comment by freedomben 21 minutes ago

> Mmmm...potential commercialisation?

Hence why I asked the question... And not everybody does everything for commercial reasons, so it would be dumb to assume that and therefore not ask the question.

> Always find it curious that people expect to get source code for free in ways that they don't do for other work (ask George Martin to release his drafts and notes).

Where in my question did you get that I expect to get source code for free in ways that I don't for other work?

But regardless, you do know that open source is a common thing right? People open source things all the time, especially on HN.

Also OP already says they don't do any uploading of your videos to the cloud, so this thing already runs local-only. It's not like there is a shortage of video editors around (including ... open source video editors)

Comment by kolx 11 minutes ago

I never maintained an open source project and not sure how to even do it properly. I am also not sure how much effort would I have to put to an open source project. I imagine I would need to collaborate with a pretty much anyone who has an interest in the area. Again not that I mind just not sure how much time I have to spare. Right now this is a really slow process and tbh I have to rely on manual testing at least for the editor.

Comment by CodesInChaos 47 minutes ago

It should be possible to comply with LGPL without publishing the source code of the whole application. Either by running the application and ffmpeg in different isolates (wasm processes), or by offering a way to merge (link) the wasm code of the closed-source application with a user compiled FFmpeg wasm build.

Different isolates might even be enough to satisfy GPL, similar to how you can invoke FFmpeg as a command line tool from a closed application. Though that feels like legally shaky ground.

Comment by sreekanth850 2 minutes ago

LGPL allow you to use the library in closed source.

Comment by senko 1 hour ago

LGPL permits that.

However, some popular codecs use GPL, which, if enabled, would require to distribute the rest of the code under it as well.

Comment by elpocko 48 minutes ago

LGPL permits you to distribute binaries, but you can't distribute the software as an opaque binary blob with no reasonable way to modify it. What even is the equivalent of a shared library that a user can replace when software runs in the browser?

Anyway, OP doesn't do most of the things FFmpeg lists under their "License Compliance Checklist".

Comment by trinix912 25 minutes ago

> Anyway, OP doesn't do most of the things FFmpeg lists under their "License Compliance Checklist".

Legitimately asking, which points and how are they expected to handle it for this type of app (assuming they want to keep it closed source)? As far as I understand it they just need to credit the libraries?

Comment by elpocko 15 minutes ago

The important thing is there has to be a clear separation between the proprietary parts and the LGPL parts of the app, and they have to provide a way to replace the LGPL parts. I have no idea how this is usually handled in the case of browser-based apps.

Comment by actionfromafar 10 minutes ago

User must be able to replace the LGPL library with their own version of the library.

Comment by 1 hour ago

Comment by spuzvabob 49 minutes ago

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.

Comment by xnx 55 minutes ago

How does it compare to https://omniclip.app/ or https://tooscut.app ?

Comment by b1temy 27 minutes ago

Also wondering how it compares to https://pikimov.com , another browser-based video editor I've seen making the rounds.

Comment by bensyverson 4 minutes ago

Browser-based video editing is quickly becoming as commoditized as browser-based image editing

Comment by DoctorOW 29 minutes ago

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).

Comment by kolx 2 minutes ago

Thank you for the encouragement. Regarding the track manipulation I have not fully cracked it yet so you can't move clips between tracks yet and track reordering didn't cross my mind but will look into it. Regarding transforms once you manage to get a clip in the track you should be able to click on it and then get on the right hand side of the program monitor you should see a transforms panel with a limited selection of options, at least what I could sort of understand how to program together with LLMs ofc ahahaha.

Comment by Sergey777 42 minutes ago

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.

Comment by bjord 28 minutes ago

get this twitter-style LLM reply guy spam off of HN

Comment by prhn 45 minutes ago

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.

Comment by kolx 32 minutes ago

Thank you for flagging this, indeed you are right. I do have a long list of problems to go through. The editor mostly relies on the browser Audio/Video codecs which I learned after trying FFmpeg out. They have wide support but also a bunch of limitations. Actively working on it, thank you for the feedback. It is the first time I take such a deep dive to all of these.

Comment by kevmo314 18 minutes ago

Wild that apps used to be completely local, no accounts, no uploads, and we're back to that as a value prop.