7 ms·

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

301 points by kolx 6mo 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 https://vidstudio.app/video-editor

l2s0 5mo ago
[dead]
elpocko 6mo 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 https://www.ffmpeg.org/legal.html
- senko 6mo 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.
  - elpocko 6mo 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".
    - trinix912 6mo 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?
      - elpocko 6mo 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.
      - actionfromafar 6mo ago
        User must be able to replace the LGPL library with their own version of the library.
    - senko 6mo ago
      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.
- deleted 6mo ago
  [deleted]
- prhn 6mo 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.
  - xixixao 6mo ago
    Dynamically and statically linked libs is hilarious in the context of webassembly running in the browser.
    - circuit10 5mo ago
      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 5mo ago
        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.
        jaakl 5mo ago
        Is there a browser plugin enabling to swap out any parts of a website/app with own ones? With prompt/vibe-based input, so any user can customize websites in any imaginable way. Maybe it should.
  - mghackerlady 6mo ago
    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)
- CodesInChaos 6mo 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.
  - kolx 6mo ago
    Thanks for sharing. Will look into it
- kolx 6mo 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.
  - freedomben 6mo 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).
    - netdevphoenix 6mo 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).
      - freedomben 6mo 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)
- sreekanth850 6mo ago
  LGPL allow you to use the library in closed source.
  - whateveracct 5mo ago
    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.
xnx 6mo ago
How does it compare to https://omniclip.app/ https://omniclip.app/, https://tooscut.app https://tooscut.app, or https://clipjs.mohy.dev/ https://clipjs.mohy.dev/ ?
- b1temy 6mo ago
  Also wondering how it compares to https://pikimov.com https://pikimov.com , another browser-based video editor I've seen making the rounds.
  - bensyverson 6mo ago
    Browser-based video editing is quickly becoming as commoditized as browser-based image editing
    - vunderba 5mo ago
      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 5mo ago
      We need a VdeoPea after PhotoPea and VectorPea
- kolx 5mo ago
  Tbh I don't know, will check them out. I did not know they existed, thank you for sharing them!
spuzvabob 6mo 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.
prhn 6mo 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.
- kolx 6mo 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.
Sergey777 6mo 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.
- bjord 6mo ago
  get this twitter-style LLM reply guy spam off of HN
  - Sergey777 5mo ago
    Remove yourself from this site.
DoctorOW 6mo 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).
- kolx 6mo 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.
kevmo314 6mo ago
Wild that apps used to be completely local, no accounts, no uploads, and we're back to that as a value prop.
- kolx 6mo ago
  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.
  - deleted 5mo ago
    [deleted]
- pjmlp 5mo ago
  Except the part of them actually being native to the OS they are running on.
  - RajT88 5mo ago
    A recommendation I make where I can: OpenShot. FOSS, cross-platform, no accounts and very capable and easy to use.
    - pjmlp 5mo ago
      Thanks, added to my list.
- hiccuphippo 5mo ago
  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.
jamiehugo30 6mo ago
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 6mo ago
  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
kreco 6mo ago
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 5mo ago
  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.
Unsponsoredio 5mo ago
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 5mo ago
  Yes and yet perfectly logical when the most successful business models are about selling private data.
- socalgal2 5mo ago
  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.
- errolabadzhiev 5mo ago
  [dead]
lern_too_spel 5mo ago
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.
woodydesign 5mo ago
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
- deleted 5mo ago
  [deleted]
- kolx 5mo ago
  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
SilentM68 5mo ago
Price?
- kolx 5mo ago
  Free!
  - SilentM68 5mo ago
    :)
giancarlostoro 5mo ago
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.
shardullavekar 5mo ago
looks great. any plans of abstracting these functions with an LLM integration?
- deleted 5mo ago
  [deleted]
- nimchimpsky 5mo ago
  [dead]
mankins 5mo ago
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 https://www.loremlabs.com/cliproom if you're interested in comparing
- deleted 5mo ago
  [deleted]
- kolx 5mo ago
  Cool project will check it out. I have not checked Remotion but will certainly take a look.
Serhii-Set 5mo ago
[dead]
comicink 5mo ago
This is so cool - will try it out. Pure browser based video editing is ambitious. Are you using Remotion ?
- deleted 5mo ago
  [deleted]
- kolx 5mo ago
  I have not checked out Remotion but will do thanks for pointing it out!
meerab 5mo ago
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!
- kolx 5mo ago
  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.
j1elo 5mo ago
What is the performance difference between native FFmpeg and WebAssembly-translated FFmpeg running in a web browser?
- kolx 5mo ago
  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.
dsalaj 5mo ago
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.
- kolx 5mo ago
  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!
- kolx 5mo ago
  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.
billconan 5mo ago
LGPL issues aside, will a project like this need to pay the h264 patent fee?
Vachyas 5mo ago
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.
ArielTM 5mo ago
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.
- kolx 5mo ago
  Good idea. Once I am through the licensing ordeal I have a giant stack of errors to tackle which should increase usability.
  - ArielTM 5mo ago
    Thanks!
0x142857 5mo ago
nice
alfg 5mo ago
Looks good. Good work on shipping! I love seeing video applications utilizing Web Assembly. However, it usually falls short in when it comes to longer video in the browser's sandboxed environment. How is the performance? Curious if you've tried using the FFmpeg libraries directly (libav), rather than compiling all of FFMpeg to WASM? I always end up using running FFmpeg directly since it's faster and more reliable, but I still have some hope for a full functioning browser-based implementation someday. I also made https://ffmpeg-commander.com https://ffmpeg-commander.com a while back to generate commands for FFmpeg.
- kolx 5mo ago
  Yeah you are right about the wasm issues with video apps. The editor itself relies fully on web codecs and the rest of the tools are halfway migrated from ffmpeg wasm anyways. I did not look into any other alternatives for ffmpeg thinking that wasm will give me the next best thing to the cli tool and ofc since the browser is the main delivery mechanism the I was limited in my options. I have seen your project and it is really cool!
nopointttt 5mo ago
Glad you're holding the "nothing leaves your machine" line. A lot of tools in adjacent categories added cloud sync early, the local audience didn't come back. If you can keep v1 and v2 fully client side you'll find the people who care. ffmpeg-on-wasm will hit a memory ceiling on longer videos, but most people opening a browser video editor are doing short clips anyway.
- kolx 5mo ago
  Thanks for encouragement. You are right ffmpeg-wasm doesn't really cut it for long videos but I have pivoted to web/audio codecs now, and there I can work based on streams at least for video. So once I harden the tools a bit more memory limits should be large enough to do some good editing.
roxana_haidiner 5mo ago
I tried multiple times to upload a 1920x1080 video and export it as 1080 x 1920 for tik tok...but I couldn't do this, the last one was blocked at 75%, and it was an 30 seconds of 5 mb video..... I really need this website if everything works well!
- kolx 5mo ago
  Will take a look asap. Can you also try this maybe https://vidstudio.app/resize https://vidstudio.app/resize
  - roxana_haidiner 5mo ago
    Yes, I'm gonna try this tmr...be right back with feedback!
mehmetkeremmtl 5mo ago
Running FFmpeg via WebAssembly and rendering with Pixi.js sounds heavy for mobile browsers, which are notoriously aggressive with memory limits. How are you handling OOM crashes or storage quota limits in IndexedDB when users import large 4K video files on mobile?
pacovook 5mo ago
This is great, thank you!
zane__chen 5mo ago
Finally see a local first web based video editor. Cool thing!
paolatauru 5mo ago
webcodecs for timeline scrubbing is the right call. curious how you handle frame caching though - webcodecs decoder buffers are memory mapped and the browser can evict them when under pressure. did you implement your own lru cache on top or are you just letting the decoder handle it. also interested in how mobile holds up on memory constrained devices - iphones especially tend to kill pages that use too much webcodecs memory in the background

301 points by kolx 6mo ago

l2s0 5mo ago

[dead]

elpocko 6mo 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 https://www.ffmpeg.org/legal.html

senko 6mo 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.
- elpocko 6mo 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".
  - trinix912 6mo 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?
    - elpocko 6mo 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.
    - actionfromafar 6mo ago
      User must be able to replace the LGPL library with their own version of the library.
  - senko 6mo ago
    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.
deleted 6mo ago
[deleted]
prhn 6mo 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.
- xixixao 6mo ago
  Dynamically and statically linked libs is hilarious in the context of webassembly running in the browser.
  - circuit10 5mo ago
    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 5mo ago
      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.
      - jaakl 5mo ago
        Is there a browser plugin enabling to swap out any parts of a website/app with own ones? With prompt/vibe-based input, so any user can customize websites in any imaginable way. Maybe it should.
- mghackerlady 6mo ago
  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)
CodesInChaos 6mo 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.
- kolx 6mo ago
  Thanks for sharing. Will look into it
kolx 6mo 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.
- freedomben 6mo 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).
  - netdevphoenix 6mo 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).
    - freedomben 6mo 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)
sreekanth850 6mo ago
LGPL allow you to use the library in closed source.
- whateveracct 5mo ago
  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.

xnx 6mo ago

How does it compare to https://omniclip.app/ https://omniclip.app/, https://tooscut.app https://tooscut.app, or https://clipjs.mohy.dev/ https://clipjs.mohy.dev/ ?

b1temy 6mo ago
Also wondering how it compares to https://pikimov.com https://pikimov.com , another browser-based video editor I've seen making the rounds.
- bensyverson 6mo ago
  Browser-based video editing is quickly becoming as commoditized as browser-based image editing
  - vunderba 5mo ago
    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 5mo ago
    We need a VdeoPea after PhotoPea and VectorPea
kolx 5mo ago
Tbh I don't know, will check them out. I did not know they existed, thank you for sharing them!

spuzvabob 6mo 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.

prhn 6mo 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.

kolx 6mo 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.

Sergey777 6mo 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.

bjord 6mo ago
get this twitter-style LLM reply guy spam off of HN
- Sergey777 5mo ago
  Remove yourself from this site.

DoctorOW 6mo 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).

kolx 6mo 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.

kevmo314 6mo ago

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

kolx 6mo ago
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.
- deleted 5mo ago
  [deleted]
pjmlp 5mo ago
Except the part of them actually being native to the OS they are running on.
- RajT88 5mo ago
  A recommendation I make where I can: OpenShot. FOSS, cross-platform, no accounts and very capable and easy to use.
  - pjmlp 5mo ago
    Thanks, added to my list.
hiccuphippo 5mo ago
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.

jamiehugo30 6mo ago

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 6mo ago
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

kreco 6mo ago

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 5mo ago
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.

Unsponsoredio 5mo ago

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 5mo ago
Yes and yet perfectly logical when the most successful business models are about selling private data.
socalgal2 5mo ago
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.
errolabadzhiev 5mo ago
[dead]

lern_too_spel 5mo ago

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.

woodydesign 5mo ago

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

deleted 5mo ago
[deleted]
kolx 5mo ago
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

SilentM68 5mo ago

Price?

kolx 5mo ago
Free!
- SilentM68 5mo ago
  :)

giancarlostoro 5mo ago

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.

shardullavekar 5mo ago

looks great. any plans of abstracting these functions with an LLM integration?

deleted 5mo ago
[deleted]
nimchimpsky 5mo ago
[dead]

mankins 5mo ago

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 https://www.loremlabs.com/cliproom if you're interested in comparing

deleted 5mo ago
[deleted]
kolx 5mo ago
Cool project will check it out. I have not checked Remotion but will certainly take a look.

Serhii-Set 5mo ago

[dead]

comicink 5mo ago

This is so cool - will try it out. Pure browser based video editing is ambitious. Are you using Remotion ?

deleted 5mo ago
[deleted]
kolx 5mo ago
I have not checked out Remotion but will do thanks for pointing it out!

meerab 5mo ago

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!

kolx 5mo ago
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.

j1elo 5mo ago

What is the performance difference between native FFmpeg and WebAssembly-translated FFmpeg running in a web browser?

kolx 5mo ago
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.

dsalaj 5mo ago

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.

kolx 5mo ago
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!
kolx 5mo ago
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.

billconan 5mo ago

LGPL issues aside, will a project like this need to pay the h264 patent fee?

Vachyas 5mo ago

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.

ArielTM 5mo ago

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.

kolx 5mo ago
Good idea. Once I am through the licensing ordeal I have a giant stack of errors to tackle which should increase usability.
- ArielTM 5mo ago
  Thanks!

0x142857 5mo ago

nice

alfg 5mo ago

Looks good. Good work on shipping! I love seeing video applications utilizing Web Assembly. However, it usually falls short in when it comes to longer video in the browser's sandboxed environment. How is the performance? Curious if you've tried using the FFmpeg libraries directly (libav), rather than compiling all of FFMpeg to WASM? I always end up using running FFmpeg directly since it's faster and more reliable, but I still have some hope for a full functioning browser-based implementation someday. I also made https://ffmpeg-commander.com https://ffmpeg-commander.com a while back to generate commands for FFmpeg.

kolx 5mo ago
Yeah you are right about the wasm issues with video apps. The editor itself relies fully on web codecs and the rest of the tools are halfway migrated from ffmpeg wasm anyways. I did not look into any other alternatives for ffmpeg thinking that wasm will give me the next best thing to the cli tool and ofc since the browser is the main delivery mechanism the I was limited in my options. I have seen your project and it is really cool!

nopointttt 5mo ago

Glad you're holding the "nothing leaves your machine" line. A lot of tools in adjacent categories added cloud sync early, the local audience didn't come back. If you can keep v1 and v2 fully client side you'll find the people who care. ffmpeg-on-wasm will hit a memory ceiling on longer videos, but most people opening a browser video editor are doing short clips anyway.

kolx 5mo ago
Thanks for encouragement. You are right ffmpeg-wasm doesn't really cut it for long videos but I have pivoted to web/audio codecs now, and there I can work based on streams at least for video. So once I harden the tools a bit more memory limits should be large enough to do some good editing.

roxana_haidiner 5mo ago

I tried multiple times to upload a 1920x1080 video and export it as 1080 x 1920 for tik tok...but I couldn't do this, the last one was blocked at 75%, and it was an 30 seconds of 5 mb video..... I really need this website if everything works well!

kolx 5mo ago
Will take a look asap. Can you also try this maybe https://vidstudio.app/resize https://vidstudio.app/resize
- roxana_haidiner 5mo ago
  Yes, I'm gonna try this tmr...be right back with feedback!

mehmetkeremmtl 5mo ago

Running FFmpeg via WebAssembly and rendering with Pixi.js sounds heavy for mobile browsers, which are notoriously aggressive with memory limits. How are you handling OOM crashes or storage quota limits in IndexedDB when users import large 4K video files on mobile?

pacovook 5mo ago

This is great, thank you!

zane__chen 5mo ago

Finally see a local first web based video editor. Cool thing!

paolatauru 5mo ago

webcodecs for timeline scrubbing is the right call. curious how you handle frame caching though - webcodecs decoder buffers are memory mapped and the browser can evict them when under pressure. did you implement your own lru cache on top or are you just letting the decoder handle it. also interested in how mobile holds up on memory constrained devices - iphones especially tend to kill pages that use too much webcodecs memory in the background