Much of Tooscut's heavy data lives outside the V8 heap. We use WASM linear memory which is not counted against V8 heap. GPU buffers is in VRAM. Bitmaps are also native allocations.
Also, video files are never fully decoded. We use the browser's native WebCodecs on demand. Only a small buffered window gets decoded and sent to the compositor. So it can even handle long 4K videos.
I added CONTRIBUTING.md. I also took a look at OpenFX. My current view is that supporting OFX in the browser would be hard, since the standard and its existing tooling are not designed around wgpu or browser execution. Tooscut would likely need its own plugin model rather than adopting OFX as is.
That said, I would be very interested in hearing your thoughts if you are open to contributing or discussing what a practical plugin system should look like in this environment. Please file a GitHub issue if you can
The goal here is not to replace Premiere Pro across every professional workflow. But it is also not intended to be a toy editor.
Modern browser and GPU capabilities are already sufficient for a large category of practical video editing tasks. We are not targeting blockbuster scale 8K movies at least for now, but we are targeting real jobs people do every day across social, commercial, and non-commercial video production.
Good point. I agree that could be a very interesting direction.
I have used Remotion for years because the DX is great, but the performance and overhead is significant. Even something like attaching subtitles to a video can take around 10x more time and resources than bare FFmpeg because of the chromium layer.
A headless version of this wgpu renderer with a clean API and eventually a nicer DX layer such as a react renderer could be a strong replacement for that kind of workflow.
We actually already support text, transitions, and animation of basic properties as well as some filters. I would be interested to hear more about your use case and which capabilities you felt were missing from what you saw.
Seems interesting. I had not seen Omniclip specifically. But like most web-based NLEs I've seen, its UX feels unfamiliar. My goal was to build a desktop-grade professional editor that feels familiar to editors like Premiere Pro, DaVinci Resolve, and Final Cut Pro, rather than reinventing the editing experience.
Yes, that was part of the thinking behind the licensing choice. The goal was to keep the engine itself open source, while creating opportunities to monetize adjacent offerings like cloud file management, sharing, AI editing, and other higher-level capabilities.
Great question! I actually have built a poc that is not released yet. It's on the roadmap. It requires some tooling for the devs building these plugins like a CLI for building the WASM binaries, bundling, manifests, etc.
The current poc still has significant performance overhead, and that overhead grows as the plugin system becomes more powerful. If plugins are only allowed to apply a WGSL shader, the performance impact is almost negligible. But features that require broader access to timeline data, such as time shifts, speed ramps, or full timeline transformations, become much more expensive and make zero-copy architectures harder to reason about.
I see. I haven't decided on the commercial license yet. This might be temporary. I started this as part of another for-profit side project (for dubbing videos with AI). I may change the license later as the quote unquote "copyright owner". If I see the open-source community is active and finds it useful, I'd switch to a free-er license. Things are not super clear yet to me re what can be done with a web based video editor.
Yes, but the goal is to become the photopea of video editing. Something quick that you can launch via web that can support 80% of the day to day use cases.
Also, video files are never fully decoded. We use the browser's native WebCodecs on demand. Only a small buffered window gets decoded and sent to the compositor. So it can even handle long 4K videos.