WebCodecs 是一个浏览器 JavaScript API，它允许开发者通过原始的 VideoEncoder、VideoDecoder、AudioEncoder 和 AudioDecoder 对象直接访问浏览器内置的视频和音频编解码器，而无需经过完整的 WebRTC 堆栈或 video 元素。该 API 的出现，是因为越来越多的开发者需要对帧级进行控制，而 WebRTC 却有意将这些功能进行了抽象处理：自定义传输、逐帧处理、对原始像素进行机器学习等，这些功能都无法完美地融入一个旨在简化点对点通话的 API 中。本文将探讨 WebCodecs API 的含义、它能为您提供什么、它与 WebRTC 的关系，以及在何种情况下实际值得使用它。
WebCodecs 解决的问题
WebRTC 和 video 元素在设计上是一体化的。WebRTC 将采集、编码、传输、抖动缓冲和渲染整合到一条管道中，并刻意将编解码器层隔离在外：你可以配置首选项，但永远无法直接接触原始编码帧。对于标准的视频通话而言，这恰到好处：因为开发会议产品的开发者不愿意手动实现拥塞控制。但一旦需要 WebRTC 设计时未预留的接口，例如在发送前将帧数据输入机器学习模型、将编码后的输出复用为自定义文件格式，或者通过 WebRTC 未支持的传输协议发送媒体——这种设计就会成为限制。
WebCodecs 通过将编码和解码步骤独立出来，使其脱离采集和传输环节，从而解决了这一问题。您将获得对原始编解码器的访问权限，并负责构建围绕它的处理管道，这正是寻求使用该 API 的开发者所期望做出的权衡。
WebCodecs 核心构建模块
这个 API 的表面比听起来要小。两个对象家族完成了全部工作：
原始媒体单元。 VideoFrame 和 AudioData 用于存储未压缩的媒体数据。一个 VideoFrame 包含像素数据以及时间戳和时长等元数据，并与浏览器当时使用的底层内存相关联。
编码器与解码器。 VideoEncoder 和 VideoDecoder 完成实际的编解码工作。VideoEncoder 接收 VideoFrame 对象，将其转换为 EncodedVideoChunk 实例（压缩后的字节加上少量元数据，尤其是该块是关键帧还是增量帧）。VideoDecoder 则执行相反操作，将 EncodedVideoChunk 对象还原为 VideoFrame 对象。AudioEncoder 和 AudioDecoder 在音频领域与之对应，处理 AudioData 和 EncodedAudioChunk。
一个最简化的处理流程如下：
- 采集或生成一个 VideoFrame。
- 将其交给一个配置好的 VideoEncoder。
- 在回调中收到一个 EncodedVideoChunk。
- 将该数据块发送到任何你需要的地方，例如通过 WebTransport、WebSocket 或数据通道，或者将其路由到封装库中生成文件。
- 在接收端，将每个数据块输入 VideoDecoder，它会返回 VideoFrame 对象。
接下来如何处理这些帧，完全取决于你：可以将它们绘制到 canvas
上，作为纹理上传到 WebGPU 或 WebGL 以实现 GPU 端特效，读取其原始像素供机器学习模型使用，或者将它们输入到 MediaStreamTrackGenerator 中，将其转换回普通的视频流。所有操作均以异步方式运行，最好在 Web Worker 中脱离主线程执行，因为编码和解码回调每秒可能触发多次，否则会导致页面运行缓慢。
不过，这一切并非毫无约束。编码器和解码器在接受任何数据之前，都需要配置一个特定的编解码器字符串，且该字符串不仅需指定编解码器家族，还需指定配置文件和级别（对于VP8以外的编解码器），因为浏览器的硬件解码器通常只支持有限范围的配置。配置错误不会导致页面崩溃；编码器或解码器只会报告无法支持所请求的配置，这就是为什么大多数实际实现会在确定使用特定编解码器之前先检查支持情况，而不是在处理过程中才发现错误。
WebCodecs 与 WebRTC：二者如何关联
最常见的误解是将其视为 WebRTC 的直接替代品。事实并非如此。WebRTC 仍然负责实时点对点连接、通过 ICE 实现的 NAT 穿透、拥塞控制以及完整的 SDP 提议/应答协商，而 WebCodecs 并未试图复制其中的任何功能。WebCodecs 仅仅是编解码器层，现在可以直接访问，而不再被锁定在 WebRTC 的管道中。如果你需要具有合理默认设置的点对点通话，WebRTC 仍然是首选工具；而当你想要构建 WebRTC 的“黑盒子”无法提供的功能，并且愿意自行提供传输和错误恢复逻辑时，WebCodecs 就是你的选择。
这正是新兴的“WebCodecs 加 WebTransport”模式所填补的空白。WebTransport 为浏览器提供了一种基于 QUIC 的 HTTP/3 传输原语，完全没有 WebRTC 的协商开销；尽管它是一种客户端-服务器传输（浏览器到服务器而非点对点），因此它是对 WebRTC 的补充，而非直接替代。将其与 WebCodecs 结合，可在某些低延迟流媒体场景中提供一种比 WebRTC 更解耦的替代方案：它作为浏览器端的协议栈，是Media over QUIC等新型协议构建的基础。
WebCodecs 实际应用场景
在实际应用中，WebCodecs 通常出现在以下几类特定的项目中：
使用自定义传输的低延迟直播。 这是最典型的用例：将 WebCodecs 与 WebTransport 配对，可以构建一条按自身延迟和质量取舍定制的传输管道，而不是直接采用 WebRTC 的默认配置。
帧级处理， 例如背景移除或需要在编码前检查、修改原始像素的计算机视觉分析。如果这类处理发生在实时 WebRTC 通话内部，WebRTC 自带的 Insertable Streams API 通常可以做到，不需要 WebCodecs。WebCodecs 的价值体现在完全独立于实时通话之外的帧级处理场景，在这些场景中，WebRTC 的抽象层从一开始就未曾介入。
云游戏和远程渲染。 这些负载对编码延迟极为敏感，不希望一个通用的会议技术栈挡在中间，因此硬件加速编码很有吸引力。但实际上，编解码器配置中的 hardwareAcceleration 只是浏览器可以随意忽略的提示，实际硬件支持情况因设备和操作系统而异。生产级管道仍然需要检查 isConfigSupported() 并备好软件编码回退方案，而不是想当然地认为硬件加速一定可用。
浏览器内录制或转码。 在客户端本地将视频流转码为另一种编解码器或封装格式，这在 WebCodecs 出现之前是不现实的。当时的替代方案是把媒体发送到服务器，或打包一个 WebAssembly 编码器。
浏览器支持及实际使用中的注意事项
Chromium 生态系统中的支持非常完善且成熟：Chrome、Edge 和 Opera 早在几年前的 Chrome 94 版本起就已提供完整的编解码器访问功能。Firefox 最近才在桌面端迎头赶上，从 Firefox 130 版本开始提供完整支持，不过 Android 版的 Firefox 目前仍未实现该功能。Safari 的支持进程耗时最久：多年来，Safari 仅提供部分支持（仅限视频），直到 Safari 26 才实现了包括音频在内的完全兼容。实际结果是，对于当今以 Chromium 优先或桌面端优先的产品而言，WebCodecs 是一个安全可靠的选择，但在正式采用前，请务必查阅您具体目标浏览器及版本的当前兼容性表格，特别是当您的用户群体中包含移动版 Firefox 或旧版 Safari 时。
WebTransport 实现普及花了更长时间。它直到 2026 年 3 月才达到 Baseline 状态（即 Chrome、Edge、Firefox 和 Safari 全部支持），当时 Safari 26.4 终于提供了支持。Chromium 自 2022 年起就支持它，Firefox 自 2023 年起支持。因此，这一组合技术栈真正能够广泛部署的时间仅有数月之久，而非数年，在将生产系统押注于此之前，这一点值得纳入考量。
更大的注意事项并非浏览器兼容性问题，而是当你跳出 WebRTC 的抽象层后，需要自行承担的责任。WebRTC 免费为你提供了丢包恢复、同步、抖动缓冲和拥塞控制等功能，这些功能经过十多年的实际生产环境使用已得到充分优化。若转而使用 WebCodecs 和 WebTransport，这些功能将不再内置：你必须自行处理码率自适应、丢包处理以及音视频同步问题，因为浏览器已刻意不再为你做出这些决策。WebTransport 本身目前尚不具备与 WebRTC 带宽估算和自适应码率算法相当的功能，因此，一个严肃的自定义管道通常意味着需要实现或借用这些逻辑，而不是假设传输层会自动处理。这就是真实的权衡：以更低层次的控制权为代价，换取对那些原本由捆绑式协议栈默默处理的困难部分的掌控。
您需要 WebCodecs，还是需要一个能为您处理这些事务的平台？
这值得作为“自行构建”与“第三方解决方案”之间的真正抉择来考量，而不是一味认为直接访问原始数据总是更好的选择。对于需要构建真正定制化的媒体管道、专有流媒体协议、必须在原始帧上进行的处理步骤，或是 WebRTC 根本无法满足的产品形态的团队而言，WebCodecs 的复杂性是物有所值的。
不过，在考虑使用 WebCodecs 之前，还有一条值得了解的中间方案。如果您只是需要在普通视频通话中进行帧级访问（例如背景虚化或计算机视觉特效），WebRTC 本身已经提供了一种无需放弃其传输机制的实现方式。插入式流（MediaStreamTrackProcessor 和 MediaStreamTrackGenerator）以及 WebRTC 编码转换（WebRTC Encoded Transform）允许您在通话过程中读取和修改帧，同时 WebRTC 继续处理拥塞控制、NAT 穿越和同步。当您需要更多功能时，例如完全独立于实时 WebRTC 通话之外的管道、自定义传输协议，或是 WebRTC 原本不支持生成的容器格式，WebCodecs 才是正确的选择。
对于仅需标准视频通话功能的大多数产品而言，这些功能均非必需，因为 WebRTC 或基于即构(ZEGO)实时音视频SDK构建的方案已经处理了编码、传输和丢包恢复，无需重复编写相关代码。
结论
WebCodecs 在浏览器中实现了原始的帧级编码和解码：对于构建自定义低延迟流媒体或逐帧处理管道的团队而言，这确实是一项强大的功能；但对于仅进行标准视频通话的用户来说，则会带来不必要的负担。其 API 接口简洁且定义明确，除少数移动设备和旧版浏览器存在兼容性缺口外，当前浏览器支持已相当完善，但突破 WebRTC 抽象层所带来的责任也是切实存在的。
常见问题
什么是 WebCodecs API？
它是一个浏览器 JavaScript API，直接暴露浏览器内置的视频和音频编码器/解码器，让开发者获得帧级控制能力，而无需经过 WebRTC 或 video 元素。
WebCodecs 与 WebRTC 有何不同？
WebRTC 是一个完整、打包好的实时通信技术栈，采集、编码、传输和渲染一体处理。WebCodecs 只是编解码层——编码和解码独立出来，传输及其他一切交给开发者自行处理。
VideoEncoder 和 VideoDecoder 是做什么用的？
VideoEncoder 将原始 VideoFrame 对象转换为压缩的 EncodedVideoChunk 对象；VideoDecoder 执行相反操作，将编码块还原为可显示的帧。
哪些浏览器支持 WebCodecs API？
Chrome、Edge 和 Opera 自 Chrome 94 起全面支持。Firefox 自 Firefox 130 起在桌面端提供完整支持，但 Android 端尚未支持。Safari 的支持多年间仅限视频，直到 Safari 26 才达到包括音频在内的完全对等。
什么时候使用 WebCodecs 而不是第三方实时音视频 SDK？
当你构建真正自定义的媒体管道、专有传输、帧级处理，或标准视频通话不适配的产品形态时，可以考虑选择 WebCodecs。大多数需要普通视频通话的产品，用已经处理了编码和传输的实时音视频 SDK 会更合适。
WebCodecs 可以与 WebTransport 一起用于直播吗？
可以。将 WebCodecs 与 WebTransport 配对，正是 Media over QUIC 等新型低延迟流媒体方案背后的新兴模式，它为开发者提供了基于 QUIC 的传输和直接编解码器访问，而非 WebRTC 的捆绑式管道。
