WebAV：用浏览器原生 WebCodecs 做视频编辑 SDK，号称比 ffmpeg.wasm 快 10–20 倍
阅读时间: 大约 9 分钟
WebAV：用浏览器原生 WebCodecs 做视频编辑 SDK，号称比 ffmpeg.wasm 快 10–20 倍
WebAV 是一个“在 Web 平台上创建/编辑视频文件”的 SDK，核心卖点一句话：所有解码、合成、编码都在用户浏览器里完成，不上传服务器。它站在浏览器原生的 WebCodecs API 之上，官方称性能是 ffmpeg.wasm 的 10–20 倍、体积约 50KB。本文基于 webav-tech.github.io 官网与 GitHub 仓库，分析它的架构、适用边界，以及那个“20 倍”到底该怎么理解。
一、背景：浏览器长期“碰不到”视频帧
过去十几年，网页里处理视频基本只有两条路：用 <video> 标签播放，或者把整个文件上传到服务器用 ffmpeg 转码。问题在于：
<video>是一个黑盒——你能播、能截图，但拿不到每一帧的原始像素，也拿不到编码后的码流，想逐帧加滤镜、合字幕、混流，浏览器不给你入口；- 上传到服务器转码意味着带宽成本、排队延迟和隐私问题——用户的视频要先传到你的机器上。
WebCodecs 是浏览器在 2022 年前后推出的原生 API，直接暴露 VideoDecoder / VideoEncoder / AudioDecoder 等接口，让 JS 能逐帧拿到解码后的位图、再把位图重新编码成视频。WebAV 就是把这套底层能力封装成“素材 + 时间轴 + 画布”的编辑 SDK。
二、是什么：三个包拼出一个编辑器
WebAV 不是单一库，而是 monorepo 下三个分工明确的包：
| 包 | 职责 | 类比 |
|---|---|---|
| av-cliper | 基础音视频处理：IClip（素材抽象，解析视频/图片/字幕）、Sprite（给素材加空间位置与时间偏移）、Combinator（按图层与时间合成输出 MP4） | 时间轴引擎 |
| av-canvas | 在 av-cliper 之上提供可交互画布，支持拖拽、缩放、旋转 Sprite，快速搭出剪辑台/直播工作台 | 可视化编辑界面 |
| av-recorder | 录制 MediaStream（摄像头/麦克风/屏幕），输出 MP4 码流 | 本地录屏录制 |
用官方 README 的话：IClip 负责“这是什么素材”，Sprite 负责“它在哪、什么时候出现”，Combinator 负责“把它们按时间叠在一起导出成文件”。
三、关键数据：体积、性能与兼容性
这些数字都能在官网首页和 README 核对：
| 指标 | 官方口径 |
|---|---|
| 性能 | 官方称是 ffmpeg.wasm 的 10–20 倍（README 写 20×，官网首页写 10～20 倍） |
| 体积 | 约 50KB（minified + gzipped，且未做 tree-shaking） |
| 浏览器要求 | Chrome 102+ / Edge，并可在 Electron 中运行 |
| 计算位置 | 完全客户端，零服务器成本，不上传用户数据 |
| 商业模式 | 开源核心 + WebAV Pro 商业授权与定制外包 |
典型用法包括：批量给视频加水印、配音、嵌字幕；做在线剪辑、直播录制、视频动画；以及和 Canvas、WebAudio 配合做自定义特效。
四、评测方法批判：“20 倍”是和谁比
这个性能数字必须拆开看，否则容易误判：
- 对比基准是 ffmpeg.wasm，不是原生 ffmpeg。ffmpeg.wasm 是把整个 FFmpeg 编译成 WebAssembly 在浏览器里跑，编解码慢、内存占用高——它本身就是“在浏览器里硬跑重型转码”的最慢路线之一。WebAV 直接调用浏览器原生 WebCodecs（背后是系统/硬件解码器），快是理所当然的。和一个已知慢的 WASM 实现比出 20 倍，并不等于“和桌面剪辑软件一样快”。
- “接近 Native”是官方措辞，不是实测。官网卡片写“接近 Native 方案性能”，但没有给出与原生 FFmpeg / 桌面应用的同场对比数据；README 也只是链接到一个 WebCodecs 性能基准页，而不是自己业务流程的端到端耗时。
- 50KB 是 SDK 体积，不是完整产物。它指 av-cliper 等库本身 minified+gzip 后约 50KB、未 tree-shaking；真正编码能力来自浏览器，不代表你的整个剪辑应用只有 50KB。
- 浏览器兼容性是硬门槛。WebCodecs 需要 Chrome/Edge 102+，Firefox 与 Safari 的支持历史上滞后，官方 demo 页自己也提示“先确认你的浏览器支持 WebCodecs”。在企业内网或需兼容旧浏览器的场景，这个前提直接否决。
五、优势与局限
优势：
- 真正的客户端处理：视频不出用户设备，省了服务器转码成本和隐私风险，对“敏感素材编辑”类产品很有价值；
- 性能路线正确：用原生 WebCodecs 而非 WASM 软编软解，从原理上避开了 ffmpeg.wasm 的性能泥潭；
- 对 Web 开发者友好：基于 Canvas/WebAudio/标准 DOM，前端团队不需要懂 C++ 就能二次开发；
- 三层分工清晰：从基础 cliper 到可交互 canvas 再到 recorder，可按需取用。
局限：
- 性能数字对照系偏弱：10–20× 的胜利建立在“比 ffmpeg.wasm 快”上，与原生方案的差距官方未给出；
- 浏览器锁定：Chrome 102+ 是硬约束，跨浏览器（尤其旧 Safari/Firefox）不可用；
- 高级功能走向商业化：README 明确引导到付费的 WebAV Pro，开源版能力边界需要自己核实，避免选型后发现关键功能在 Pro 里；
- 生态与文档年轻：demo 资源托管在 GitHub Pages，国内访问可能慢；复杂特效（多层合成、实时预览性能）仍需自己踩坑。
六、谁该关注
- 做在线视频工具、批量加水印/字幕/拼接，且不想搭转码服务器的团队：WebAV 把“上传→排队→转码→下载”整条链路省成浏览器内一次操作，成本结构完全不同；
- 重视隐私的音视频场景：医疗、证件、内部培训等不希望素材出域的产品，客户端处理是刚需；
- Electron 桌面剪辑/直播工具：同一套 WebCodecs 代码在 Electron 里跑，省掉为桌面端单独写 C++ 的成本。
反之，如果你的用户群大量使用旧浏览器或 Safari、需要 4K 多层特效实时预览、或追求与桌面软件对齐的编码质量，WebAV 的开源版可能不够——先用它的 demo 页在你的目标设备上实测一遍导出耗时与兼容性，再决定是否把它作为产品底座。