Show HN：VidStudio - 不上传文件的浏览器视频编辑器
文章摘要
作者 kolx 发布了 VidStudio——一个隐私优先的浏览器视频编辑器。它最大的卖点是：没有账号、没有上传，所有数据都持久化在用户本地机器上。
功能特性丰富而完整：多轨道时间线、帧精确定位（frame accurate seek）、MP4 导出、音频/视频/图片/文本轨道、WebGL 加速的 canvas 渲染（在支持的浏览器上）、移动端兼容。
技术栈也很值得圈点：底层使用 WebCodecs 处理时间线播放和拖动时的帧解码，这正是让快进定位响应迅速的关键——浏览器支持时解码会跑在硬件解码器上。FFmpeg 编译为 WebAssembly 处理最终编码、格式转换以及 WebCodecs 覆盖不到的部分。渲染走 Pixi.js + WebGL canvas，WebGL 不可用时有软件回退方案。项目数据存在 IndexedDB，重活都跑在 Web Workers 里以保证 UI 在导出时仍流畅。
作者在帖子里表示乐意回答关于”全客户端管线”的技术权衡问题。这个 Show HN 在 HN 上获得 300 分、108 条评论，技术圈反响热烈，是 Web 平台能力跨越式进步的又一例证——曾经只能在 Premiere/Final Cut 这类原生应用中完成的视频编辑，现在已经可以完整跑在浏览器里。
HN 评论精华
关于 LGPL/FFmpeg 许可证合规的辩论（评论焦点）：elpocko 第一时间指出，VidStudio 使用了 FFmpeg（LGPL），但似乎没有完整执行 FFmpeg 网站列出的”License Compliance Checklist”。LGPL 的核心要求包括：（1）提供你使用的 FFmpeg 版本的源码链接；（2）让用户能用自己编译的兼容版本替换 FFmpeg 库（动态链接）或提供重链接的工具（静态链接）。这在浏览器/WASM 场景里非常棘手——”在浏览器里跑的软件，相当于’共享库’让用户能替换的形态是什么？” 这一辩论引发了关于 LGPL 在 WebAssembly 时代是否还可行的深入讨论。
senko：补充了一个反直觉的视角——”这种案例恰恰凸显了 (L)GPL 怎么把厂商推向更封闭的解决方案。我们现在抱怨的是一个能本地跑（在浏览器里、不需要上传）的应用的许可证问题。如果开发者改成把所有媒体处理放到后端做，他完全可以绕过这些许可问题。结果用户必须信任一个随机服务、可能拿不回原始数据，反而被锁得更死。” 这是对 copyleft 在现代部署场景下副作用的深刻反思。
giancarlostoro：从 iOS App Store 视角进一步指出——LGPL 在 iOS 上更棘手，因为开发者无法控制”让用户链接软件”。”我现在慢慢倾向直接用 MPL（比 LGPL 弱一点但更友好），或者干脆用 MIT。我希望我的用户用我的软件想怎么用就怎么用。”
xixixao：对 WASM 场景下”可替换库”的实现做了技术探讨——可以让多个 WASM 模块互相通信（需要互操作代码），或者静态链接成单个模块。giancarlostoro 补充：”用浏览器插件应该可以热替换 WASM 模块。”
关于 VLC 的有趣类比：noduerme 提到 VLC 早期就不带任何 mpeg 支持，要单独下载 ffmpeg——这是一种早期解决 LGPL 在视频播放器上合规性的方案。maxloh 反驳：”VLC 是 GPL 开源的，你能自己编译，所以这个就够了？”
对产品本身的正面评价：很多评论者对在浏览器里跑出帧精确视频编辑表示惊艳，认为这代表了 Web 平台 + WebCodecs + WASM + WebGL 组合的成熟。
对隐私优先理念的认同：评论者普遍认可”不上传”模式相比 CapCut/Veed 等云端编辑器在数据安全上的优势，尤其适合处理敏感视频素材。
整体反响是技术上充分认可、产品方向受欢迎，但 FFmpeg LGPL 合规性是必须解决的核心法律问题。