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

Original Article ↗ Hacker News Discussion ↗

A new browser-based video editor, VidStudio, promises fully local processing with no uploads, aiming to combine privacy, convenience and decent performance using WebCodecs, Pixi.js and FFmpeg compiled to WebAssembly. Commenters probe its legal and technical underpinnings, especially compliance with FFmpeg’s LGPL license in a WASM context, codec support gaps across browsers, memory limits for long or high‑bit‑depth videos, and how it compares to existing web editors. Many welcome the local‑first, no‑account model as a counterweight to cloud‑centric, subscription tools, while noting that cloud workflows still appeal for collaboration and easy sharing.

Licensing & FFmpeg Use

  • A major thread centers on FFmpeg’s LGPL/GPL licensing in a closed-source, browser-delivered app.
  • Concerns: current deployment likely misses FFmpeg’s “License Compliance Checklist” (no clear source links, unclear way to replace the FFmpeg build, single opaque WASM blob).
  • Clarifications:
    • LGPL allows closed source but requires clear separation and the ability for users to relink or replace the library.
    • This is conceptually hard with WebAssembly; suggestions include multiple WASM modules, separate “adapter” layer, or letting users supply their own FFmpeg binaries.
  • Some note that using server-side FFmpeg could sidestep these constraints, but at the cost of privacy and more lock‑in.
  • There’s discussion of how tricky LGPL is on platforms like iOS App Store.

Architecture & Performance

  • The editor reportedly uses WebCodecs + Pixi.js for editing and FFmpeg-wasm only for final export or other tools; ffmpeg-wasm is described as much slower and memory‑limited, especially for long videos.
  • One user reports processing 3+ hours of media successfully; others warn that long videos and mobile memory limits remain problematic.
  • Seeking implementation is criticized for reinitializing VideoDecoder per seek, causing poor performance; this may stem from limitations in the demuxing library (e.g., mp4box.js).

Browser Codec & Compatibility Issues

  • Several users cannot import common formats: HEVC/hvc1 from phones, 10‑bit video, and certain WebM files.
  • Root cause is often WebCodecs/browser gaps (especially on Firefox), not FFmpeg itself.
  • Suggestions include better error messaging (e.g., nudging users toward Chrome when Firefox cannot decode).
  • Question raised, but not answered, about whether h264 patent fees apply to such a project.

UX, Features & Use Cases

  • Praise: very fast, transparent persistence, impressive for pure in‑browser editing; liked auxiliary local tools (compress/convert, Discord presets).
  • Criticism:
    • Track manipulation is limited (no reordering tracks, hard to move clips between tracks).
    • Transform tools exist but are hard to discover.
    • Some exports (e.g., 1080→1920 TikTok) stall partway.
  • Feature requests: automatic subtitles/transcripts, better handling of mixed aspect ratios, media-library workflows over network shares.
  • Pricing is currently “free”.

Privacy vs Cloud Convenience

  • Strong appreciation for “no uploads, no account, fully local” as a differentiator versus SaaS editors.
  • Others argue many users actively want cloud workflows (sharing links, collaborative review, device sync).
  • Some lament that privacy has become a “feature” rather than the default.

Open Source, Commercialization & Ecosystem

  • Some encourage open‑sourcing (possibly AGPL) both for compliance clarity and community contribution; others defend keeping the UI logic closed for commercialization or to avoid clones.
  • It’s emphasized that FFmpeg’s licenses explicitly allow commercialization if terms are followed.
  • The broader ecosystem of browser‑based video editors is noted as becoming crowded/commoditized, akin to image and PDF tools.