"网页里剪视频、转格式"过去有两条路：上传到服务器处理，或者用 ffmpeg.wasm 在浏览器里软解——前者要等上传、后者慢且烫 CPU。WebCodecs 提供了第三条路：让网页直接调用设备的硬件编解码器。理解它的分层和边界，就能判断这类方案适合什么任务、不适合什么。
WebCodecs 解决的是什么问题？
WebCodecs 是浏览器暴露的底层编解码 API，让 JavaScript 能直接访问操作系统/硬件的视频、音频编解码器。在它之前，前端处理视频只能二选一：把文件传到服务器用 ffmpeg 转，或者把 ffmpeg 编译成 WebAssembly 在浏览器里跑。
两条老路各有硬伤：服务器方案要承担上传时延和后端算力成本，数据也离开了设备；ffmpeg.wasm 方案是纯软件解码，跑在 CPU 上，处理 1080p 视频常常是"实时的几分之一"速度，还会让风扇狂转。WebCodecs 的价值在于绕开软件解码，直接用本机已有的硬件编解码单元——现代 CPU/GPU 大多内置 H.264/H.265 的专用编解码硬件。
它在分层里处于哪一层？
要理解 WebCodecs 的能力边界，关键是看清视频处理的分层。一个 .mp4 文件从读到处理到导出，要经过几层，而 WebCodecs 只负责其中的编解码层：
| 层 | 职责 | 谁来做 |
|---|---|---|
| 容器封装 (mux/demux) | 解析/封装 MP4、MOV 等容器，分离音视频轨 | 不属于 WebCodecs，需 mp4box.js 等 |
| 编解码 (codec) | 压缩帧 ↔ 原始帧（H.264/VP9/AV1…） | WebCodecs (VideoEncoder/VideoDecoder) |
| 原始帧处理 | 裁剪、缩放、变速、滤镜、合成 | Canvas / WebGL / 自行实现 |
| 音视频同步 | 时间戳管理、对齐 | 应用层自己处理 |
这张表是理解一切的关键：WebCodecs 给你的是 VideoDecoder（压缩帧→VideoFrame）和 VideoEncoder（VideoFrame→压缩帧），两头之外的封装、像素处理、同步全得自己接。所以它不是"开箱即用的转码器"，而是高性能的编解码积木。
一次浏览器转码的完整流水线
把上面分层串起来，一次典型的"改分辨率并重新编码"大致是这样：
- 解封装：用封装库从 MP4 里取出编码后的视频包（packet）和时间戳。
- 解码：把视频包喂给
VideoDecoder，得到一帧帧VideoFrame（原始像素）。 - 处理：把
VideoFrame画到 Canvas/WebGL 上做缩放、裁剪、变速等。 - 编码：把处理后的帧交给
VideoEncoder，按目标码率/分辨率压成新的视频包。 - 重新封装：用封装库把新视频包和音频轨写回一个 MP4。
整条流水线都在浏览器进程内完成，硬件编解码让 2、4 两步快到接近甚至超过实时，因此处理短视频常常是秒级；而且数据全程不离开设备。
为什么比 ffmpeg.wasm 快这么多？
核心差异是硬件 vs 软件。ffmpeg.wasm 把整套编解码逻辑编译成 WASM，逐像素在 CPU 上算，受限于单线程/SIMD，处理高分辨率视频很吃力。WebCodecs 则把活儿交给专用硬件编解码单元，这些单元是为视频编解码定制的，吞吐量远超通用 CPU 软算。
不过这把"快"是有前提的：只支持平台硬件/系统具备的编解码格式。常见的 H.264 几乎处处可用，但某些格式（如部分 H.265、AV1 编码）在特定浏览器或老设备上可能没有硬件支持，此时要么降级、要么不可用。这与 ffmpeg.wasm "啥都能解但都慢"形成互补取舍。
能力边界与已知限制
WebCodecs 强在编解码这一层，把它用在它不擅长的地方只会事倍功半。常见边界：
- 不做封装：读写 MP4/MOV 容器要另配 mp4box.js 之类，时间戳和轨道对齐得自己管。
- 格式覆盖不如 ffmpeg：支持哪些编解码取决于浏览器+操作系统+硬件，不像 ffmpeg 那样几乎通吃所有冷门格式。
- 音视频同步要手写：API 只给帧和时间戳，对齐逻辑、丢帧补偿都在应用层。
- 滤镜要自己实现：裁剪、缩放、变速得借 Canvas/WebGL 自己做，没有 ffmpeg 那种现成滤镜图。
- 浏览器兼容性：较新的 API，老浏览器不支持，需做能力检测和降级。
一句话概括取舍：WebCodecs 用「格式覆盖窄 + 要自己搭周边」换来了硬件级速度和数据不出设备；ffmpeg.wasm 用「慢且吃 CPU」换来了几乎万能的格式兼容。
这类方案适合什么 workload？
判断一个视频任务适不适合走 WebCodecs，看三点：格式是否主流、是否在意速度与数据本地化、处理逻辑是否在编解码层。
- 适合：主流格式（H.264 MP4/MOV）的转码、压缩、裁剪、变速；对速度敏感、希望数据留在本地处理的场景。
- 勉强：需要冷门格式或大量复杂滤镜——可行但要补很多周边，性价比下降。
- 不适合：依赖 ffmpeg 海量滤镜链、或要处理设备硬件不支持的编解码格式——此时服务器端 ffmpeg 或 ffmpeg.wasm 更合适。
小结
WebCodecs 是浏览器暴露的底层编解码 API，让网页直接调用硬件编解码器，从而绕开"上传服务器"和"ffmpeg.wasm 软解慢"两条老路。它只负责编解码这一层，封装、像素处理、音视频同步都要应用层自己接；换来的是硬件级速度和数据不出设备，代价是格式覆盖受限于平台、周边要自己搭。主流格式、看重速度与隐私的转码/压缩/剪辑，是它的主场；冷门格式和重滤镜链，仍属于 ffmpeg 的领域。