| ▲ | Show HN: VidStudio, a browser based video editor that doesn't upload your files(vidstudio.app) |
| 196 points by kolx 7 hours ago | 75 comments |
| 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 |
|
| ▲ | elpocko 6 hours ago | parent | next [-] |
| > 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 |
| |
| ▲ | prhn 5 hours ago | parent | next [-] | | 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. | | |
| ▲ | mghackerlady 5 hours ago | parent | next [-] | | I knew about the soft copyleft (the source code requirements) but didn't know there was the requirement to have libs be replaceable. Now I want to know how useful that would be in reverse engineering closed systems (particularly nintendos, since I've always had an interest in the homebrew scene there) | | |
| ▲ | noduerme 4 hours ago | parent [-] | | iirc, the video player application VLC used to come without any mpeg support, and you had to go through a process to download ffmpeg separately ...not sure how easy it made it to replace individual libs, but I'm also not sure the license requires you to make it easy. | | |
| ▲ | maxloh 2 hours ago | parent [-] | | VLC is GPL licensed and open source. Maybe that's enough since you could compile it yourself anyway? |
|
| |
| ▲ | xixixao 5 hours ago | parent | prev | next [-] | | Dynamically and statically linked libs is hilarious in the context of webassembly running in the browser. | | |
| ▲ | circuit10 4 hours ago | parent [-] | | You can have multiple WASM modules communicating with each other (though you would probably need extra interop code?), or statically link them into a single module, the concepts work mostly the same | | |
| ▲ | giancarlostoro 43 minutes ago | parent [-] | | With a browser plugin I'm sure you could swap out a WASM module on the fly, if said plugin doesn't exist, maybe it should. Would make debugging in a prod URL simpler if you can just load a page with a testing WASM file. |
|
| |
| ▲ | giancarlostoro an hour ago | parent | prev [-] | | I think you're right, also an interesting aside: LGPL software is even trickier on the iOS app store, where its out of your control to "let the user link" the software. I guess in that case the only real way is to somehow give them access to the linkable files or allow them to pull in your copy of an LGPL library, but for them to run it on their device, good luck... I'm slowly leaning towards eventually just adopting MPL which is kind of weaker than LGPL but more friendly for iOS, course I mostly just default to MIT license these days. I prefer to let my users use my software however they want without fear that if they someday overhaul my code and build something that works for them, that they would lose it. |
| |
| ▲ | kolx 5 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | jmaw 4 hours ago | parent | next [-] | | You should look into how other companies and tools that use FFMPEG handle this situation. I wonder if you can keep your application itself closed source, but make an open-source adapter that handles the interaction with FFMPEG. I'm not super familiar with open source licensing, and IANAL, so make sure to do your own research :) As an example, I believe Audacity required me to install ffmpeg manually myself, and add it to my path. This is slightly different since Audacity itself is also open source. But could be helpful to reference. | | |
| ▲ | noduerme 4 hours ago | parent | next [-] | | Yes, Audacity definitely requires that. It can't open or save mp3s unless you separately install ffmpeg. | |
| ▲ | kolx 4 hours ago | parent | prev [-] | | Thank you, I guess I won't be fixing any bugs tonight but at least I will figure out how to comply.
I appreciate the help for real! |
| |
| ▲ | zenmac an hour ago | parent | prev | next [-] | | Wonder this guy is doing it? Or is it also not open sourced? https://news.ycombinator.com/item?id=42207002 | | |
| ▲ | pdyc 27 minutes ago | parent [-] | | that guy is not including ffmpeg and is not encoding in browser. What he is doing is generating a ffmpeg command that you can run on your cli/scripts etc. PS: i am that guy :-) |
| |
| ▲ | freedomben 5 hours ago | parent | prev [-] | | 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). | | |
| ▲ | netdevphoenix 5 hours ago | parent | next [-] | | > 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). | | |
| ▲ | sroussey 4 hours ago | parent | next [-] | | Or the other likely version: prevent commercialization. No source means that someone can’t make a fork, put on a new domain, run ads and charge money for his work. | |
| ▲ | mbesto 5 hours ago | parent | prev | next [-] | | 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? | | |
| ▲ | afavour 4 hours ago | parent [-] | | Most of the processing of the application is FFMPEG yes, but there's a whole lot of application outside of the processing. Video editors UIs that don't make you want to tear your hair out are a valuable commodity and I think OP has the right to commercialize that if they want to. They just need to use FFMPEG in the right way as they do it. | | |
| ▲ | mbesto 2 hours ago | parent | next [-] | | This application doesn't work without FFMPEG. I'm not arguing that the wrapper isn't valuable, I'm saying there is a significant chunk of it that is required for us to work is an open source library. | |
| ▲ | jpc0 an hour ago | parent | prev [-] | | From what I understand about this application ffmpeg of only used for export? That is very little of the processing of true, they mentioned the webcodec is used extensively and likely the only real requirement on ffmpeg is muxing into mp4 which to be entirely honest isn't much processing. |
|
| |
| ▲ | mghackerlady 5 hours ago | parent | prev | next [-] | | The problem is you can commercialise free software if you're creative about it. RMS made a decent amount of money working on emacs, redhat and SUSE exist, google has managed to commercialise chromium | | |
| ▲ | freedomben 4 hours ago | parent [-] | | > The problem is you can commercialise free software if you're creative about it. Did you mean to say that it is a problem? From the rest of your comment, and in the context of GP's comment, it sounds like commercializing is NOT a problem. | | |
| ▲ | mghackerlady 3 hours ago | parent [-] | | prev said that they might not be willing to release the source code so they can commercialise it |
|
| |
| ▲ | freedomben 5 hours ago | parent | prev [-] | | > 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) |
| |
| ▲ | kolx 5 hours ago | parent | prev [-] | | 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. | | |
| ▲ | Mashimo 5 hours ago | parent | next [-] | | Nah, besides sharing the code you don't have to do anything. Most people would want you to upload the code to github, then they can star and clone it with ease. But you don't have to have an issue tracker, and you certainly don't have to read any of the issues or pull request. You can ignore or disable that. I think even just having a up to date .zip with all the code would be technically enough. | |
| ▲ | qingcharles 3 hours ago | parent | prev [-] | | You don't have to collaborate with anyone. Just stick the code up on GitHub and if people file issues or PRs, then you can engage or not as you please. There are plenty of projects that are open source but don't accept any public modifications. You might just find you end up with some folks who genuinely want to help out, though. |
|
|
| |
| ▲ | CodesInChaos 5 hours ago | parent | prev | next [-] | | 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. | | | |
| ▲ | senko 6 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | elpocko 5 hours ago | parent [-] | | 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". | | |
| ▲ | senko 5 hours ago | parent | next [-] | | Not disagreeing with you, but cases like these really highlight how (L)GPL can nudge vendors into doing more closed solutions with greater lock-in. For example, we're complaining about a licensing issue for an app that can run locally (in your browser, no uploads needed). The licensing issues can easily be side-stepped by the the developer if they chose instead to do all the media manipulation in the backend. In the end, for the user this means they have to upload & trust a random service with their data, potentially can't get raw data out, and other negative side-effects of lock in. | |
| ▲ | trinix912 5 hours ago | parent | prev [-] | | > 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? | | |
| ▲ | elpocko 5 hours ago | parent | next [-] | | 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. | |
| ▲ | actionfromafar 5 hours ago | parent | prev [-] | | User must be able to replace the LGPL library with their own version of the library. |
|
|
| |
| ▲ | sreekanth850 5 hours ago | parent | prev [-] | | LGPL allow you to use the library in closed source. | | |
| ▲ | whateveracct 3 hours ago | parent [-] | | Yes but you must distribute in a way where it's trivial to link in another version of the library. So a single wasm blob is a violation. |
|
|
|
| ▲ | meerab 27 minutes ago | parent | prev | next [-] |
| 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! |
|
| ▲ | DoctorOW 5 hours ago | parent | prev | next [-] |
| 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). |
| |
| ▲ | kolx 5 hours ago | parent [-] | | 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. |
|
|
| ▲ | mankins an hour ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | amakolfc8 22 minutes ago | parent [-] | | I did not know about remotion but will be looking into that now thanks for pointing it out. I chose pixijs because they built on top of WebGl which seems to be well supported across all kinds of devices, platforms and browsers |
|
|
| ▲ | kevmo314 5 hours ago | parent | prev | next [-] |
| Wild that apps used to be completely local, no accounts, no uploads, and we're back to that as a value prop. |
| |
| ▲ | kolx 5 hours ago | parent | next [-] | | Agreed but I guess at the same time those who spend money to develop software need to find ways to monetise I just wish they were not so predatory.
Everything is a subscription now siphoning money out of users on a monthly basis. | |
| ▲ | pjmlp 4 hours ago | parent | prev [-] | | Except the part of them actually being native to the OS they are running on. | | |
| ▲ | RajT88 4 hours ago | parent [-] | | A recommendation I make where I can: OpenShot. FOSS, cross-platform, no accounts and very capable and easy to use. | | |
|
|
|
| ▲ | Unsponsoredio 4 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | utopiah 4 hours ago | parent [-] | | Yes and yet perfectly logical when the most successful business models are about selling private data. |
|
|
| ▲ | giancarlostoro 2 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | comicink 37 minutes ago | parent | prev | next [-] |
| This is so cool - will try it out. Pure browser based video editing is ambitious. Are you using Remotion ? |
| |
| ▲ | amakolfc8 25 minutes ago | parent [-] | | Hey thanks for the nice words. Indeed it is I wasn’t going to get into that until I realised this is a very nice data modelling exercise so I gave it a shot.
No I am not using Remotion but now that you mentioned will be reading up on it.
Thank you! |
|
|
| ▲ | xnx 6 hours ago | parent | prev | next [-] |
| How does it compare to https://omniclip.app/, https://tooscut.app, or https://clipjs.mohy.dev/ ? |
| |
| ▲ | b1temy 5 hours ago | parent | next [-] | | Also wondering how it compares to https://pikimov.com , another browser-based video editor I've seen making the rounds. | | |
| ▲ | bensyverson 5 hours ago | parent [-] | | Browser-based video editing is quickly becoming as commoditized as browser-based image editing | | |
| ▲ | vunderba 4 hours ago | parent | next [-] | | And 100% clientside browser-based PDF tools. I've seen at least 20-30 of them just on Show HN posts since vibe coding became popular. | |
| ▲ | abdusco 3 hours ago | parent | prev [-] | | We need a VdeoPea after PhotoPea and VectorPea |
|
| |
| ▲ | kolx 4 hours ago | parent | prev [-] | | Tbh I don't know, will check them out.
I did not know they existed, thank you for sharing them! |
|
|
| ▲ | woodydesign 2 hours ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | amakolfc8 19 minutes ago | parent [-] | | I am working on a transcription tool again same style all in the browser local no accounts or servers but that is quite challenging especially since I want to support multiple devices.
Will reach out again regarding the other points |
|
|
| ▲ | spuzvabob 5 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | kreco 4 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | senkora an hour ago | parent [-] | | 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. |
|
|
| ▲ | shardullavekar an hour ago | parent | prev | next [-] |
| looks great. any plans of abstracting these functions with an LLM integration? |
| |
|
| ▲ | jamiehugo30 4 hours ago | parent | prev | next [-] |
| 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? |
| |
| ▲ | kolx 4 hours ago | parent [-] | | So FFmpeg is part of the website in general but it is not used in the editor itself.
I did built on top of the Video Codec APIs and ofc a muxer library like mp4box.js |
|
|
| ▲ | Sergey777 5 hours ago | parent | prev | next [-] |
| 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. |
| |
|
| ▲ | prhn 5 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | kolx 5 hours ago | parent [-] | | 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. |
|
|
| ▲ | SilentM68 2 hours ago | parent | prev | next [-] |
| Price? |
|
| ▲ | lern_too_spel 3 hours ago | parent | prev [-] |
| 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. |
