WebRTC 中的 SVC 与 Simulcast：2026年全面技术对比

十二位参与者，十二种不同的网络连接，十二种不同的屏幕尺寸。您的视频平台如何同时为每位参与者提供最佳画质？在 WebRTC 中，针对这一问题有两种根本不同的解决方案：SVC(Scalable Video Coding) 和 Simulcast。两者都能解决自适应视频画质问题，但它们的实现方式完全不同，工程上的权衡取舍会影响到从 SFU 的复杂性到 CPU 使用率，再到平台如何优雅地处理参与者在通话过程中带宽下降等方方面面。

我们此前曾对SVC进行过深入探讨。本文将对 WebRTC 中的 SVC 与 Simulcast 进行全面对比：分析两种方案在架构层面的运作原理、各自的优势所在以及2026 年的编解码器发展态势（包括 VP9 SVC 和 AV1 SVC）。无论您正在构建新的 WebRTC 平台，还是对现有平台进行评估，本文将涵盖您所需的工程细节。

SVC 与 Simulcast 共同解决的问题

在一对一通话中，双方参与者都能以各自连接所能支持的最佳质量进行发送和接收。而在由选择性转发单元（SFU）支持的群组通话中，发送方发布的数据流必须同时到达多个接收方。每个接收方的可用带宽、设备性能各不相同，且分配给每位参与者视频画面的屏幕空间也各不相同。

向每位参与者发送相同的高质量流，会浪费带宽受限用户的带宽，并导致丢包和网络拥塞；而仅发送低质量流，则会损害那些具备足够带宽和屏幕空间以接收更高质量流的参与者的体验。因此，工程上的要求是实现自适应质量传输：即能够从单一发送方向多个接收方传输不同质量级别的流，且无需在服务器端进行重新编码或转码。

有两种架构方案可满足这一要求。Simulcast 会同时将视频编码为多种质量级别并全部发送；SVC 则仅对视频进行一次编码，但将多个质量层嵌入到单一比特流中。这两种方案都允许 SFU 根据可用带宽、画面块大小和发言者状态，针对每个接收者做出转发决策，但每种方案的运作机制、效率及权衡取舍在根本上存在差异。

Simulcast 工作原理

在 Simulcast 中，发送方的浏览器或 SDK 会同时将同一视频源以两种或三种不同的画质级别进行编码。典型的配置会生成 720p/1.5 Mbps、360p/500 kbps 和 180p/150 kbps 三种独立的流。每个编码都是一个完全独立的码流，在该分辨率下完整且可解码，彼此之间没有任何依赖关系。即使其中一个码流丢失或损坏，其他码流也不会受到影响。

这三个流都会传输到 SFU，SFU 接收它们后，会根据以下信号的组合，为每个下游接收端（订阅者）选择一个流进行转发：

• 接收端带宽：通过接收端浏览器发回的REMB 或 TWCC反馈数据包进行测量。
• 视频分块大小：缩略图大小的分块无法从 720p 流中获益。许多 SFU 会从客户端应用程序接收屏幕布局数据，以此作为决策依据，避免转发那些在显示前会被立即降采样的分辨率。
• 活跃发言者检测：当前正在发言的参与者通常会从其流中获得高分辨率视频；其他参与者的视频分辨率则会被降低，以保留带宽，确保为活跃发言者提供全质量传输。
• 手动锁定：某些平台允许用户锁定特定参与者，这会指示 SFU 优先为该特定接收者传输该参与者的高分辨率流，无论其视频块大小如何。

有一点很容易被忽略：在大型通话中，无论会话中有多少参与者，发送方始终发布固定数量的数据流（两到三个）。SFU 的分发工作量会随着接收方数量的增加而增加，但发送方的上传负载不会。

切换画质等级的速度很快。SFU 会停止转发当前流并开始转发另一个流，但需要向发布方发送关键帧请求，以便接收方的解码器能够干净地初始化新流，避免画面损坏。这种往返过程通常会增加短暂的延迟（通常只有几分之一秒），并在画质切换期间产生短暂的画面不连续性。这是 Simulcast 相对于 SVC 的主要缺点。

Simulcast 的发送方带宽成本是其最常被提及的权衡之处。实际上，由于低分辨率视频流的编码成本要低得多，因此总开销通常比单个高质量视频流的成本高出 30% 到 50%，但实际数值很大程度上取决于比特率配置；一些采用更激进的子层压缩的测量结果显示，开销低至 17%。举个具体的例子，以 1.5 Mbps 的比特率发送 720p 视频流，以 500 kbps 的比特率发送 360p 视频流，以及以 150 kbps 的比特率发送 180p 视频流，总成本约为 2.15 Mbps，而不是 4.5 Mbps。

SVC 工作原理

SVC 采取了截然不同的方法。SVC 并非对多个独立流进行编码，而是对视频进行一次编码，并将多个质量层嵌入到单一比特流中。SFU 会选择性地转发该分层流：向网络连接良好的接收端发送所有层，而对带宽受限的接收端则舍弃较高层。在信号链的任何环节都不会进行重新编码。

SVC 支持三种可扩展性类型，具体部署可采用其中一种或任意组合：

• 时间可扩展性：在保持分辨率不变的情况下改变帧速率。例如，基础层可能以 7.5 fps 的帧速率传输画面。第一个时间增强层增加帧速率，使其达到 15 fps；第二个时间增强层则将其提升至 30 fps。通过减少时间层，可以平滑地降低带宽，但会降低帧速率，而不会改变分辨率。
• 空间可扩展性：改变分辨率。基础层承载 180p 图像。空间增强层添加像素细节，重建 360p 图像，然后再重建 720p 图像。丢弃空间层相当于 SVC 中的同步广播质量切换，但不会导致关键帧不连续。
• 质量（信噪比）可扩展性：在固定分辨率下改变图像保真度。基础层生成低保真度图像；增强层逐步提升图像质量。这有助于在不改变分辨率或帧速率的情况下优雅地应对网络拥塞。

SFU 读取每个数据包的层元数据（嵌入在 RTP 扩展头中的时间 ID 和空间 ID），以决定将哪些数据包转发给哪个接收器。连接受限的接收器接收基础层或部分增强层。连接良好的接收器接收完整的协议栈。

由于每个增强层都依赖于基础层进行解码，基础层数据包的丢失会导致更高层无法解码。这种依赖关系是易丢包网络上SVC可靠性的主要问题。然而，从SFU的角度来看，丢层操作的计算成本很低：SFU读取层ID标签，丢弃高于目标阈值的数据包，并将剩余部分直接转发，无需转码。

SVC 与 Simulcast 对比

下表是 SVC 与 Simulcast 的对比分析，从七个关键维度反映了工程实践中的实际情况。结果反映了 2026 年的生产环境，包括对实际部署影响最大的浏览器支持限制。

浏览器支持情况是2026年最重要的因素。完整的VP9 SVC（空间和时间层相结合）是 Chrome 浏览器特有的功能。Firefox支持VP9，但仅发送时间可扩展性，不发送空间层。Safari 的 WebRTC 不支持 VP9 编码。这种 VP9 编码限制对任何 VP9 策略都至关重要，无论是 SVC 还是 Simulcast：无论 SFU 采用哪种方法，Safari 参与者都无法发送 VP9。如果您的平台服务于 Safari 或 iOS 用户，则仅支持 VP9 的策略（SVC或Simulcast）需要为每个参与者提供编解码器回退。VP8 Simulcast（或H.264 Simulcast）是跨浏览器的生产标准，因为通用兼容性在于VP8，而非 Simulcast 本身。

什么时候选择 SVC？

SVC 并非一种较差的方法。它是一种更专业化的方法，在权衡取舍与部署场景相契合的情况下，其表现显然更优。

• 带宽受限的发送方： SVC 对发送方带宽的较低要求在移动连接或上传成本较高的市场中尤为重要。发送单层流而非两到三个独立流可显著降低上传压力，尤其是在高分辨率下。厂商提供的数据通常表明，在同等质量条件下，SVC 的带宽占用比 VP8 同步广播低 40% 到 60% 左右，这对于移动优先部署而言意义重大。
• 平滑的画质过渡： SVC 的逐层切换技术可实现几乎察觉不到的画质变化。它无需关键帧请求、解码器重置，也不会造成画面卡顿。对于对画面连续性要求极高的应用场景，例如医学影像阅片、远程工业检测或广播制作监看，这种平滑的画质过渡相比 Simulcast 基于关键帧的切换方式，无疑是一项真正的优势。
• 大规模选择性转发：当一个同步转发单元 (SFU) 同时为来自单个发送器的数百个接收器提供不同质量级别的服务时，SVC 的丢层技术比每个发送器缓冲和管理多个独立的编码流在计算上更经济。每个额外的同步广播流都会增加 SFU 的内存和转发开销；而 SVC 则不会。在会话规模非常大的情况下，每个发送器开销的这种差异会累积起来。
• 服务器端录制：单个 SVC 流可以存档并进行后处理，生成多种输出质量，而无需重新编码原始捕获的内容。每个会话存储两到三个 Simulcast 流会成倍增加存储成本。对于会话量大且需要长期保存的平台而言，这一点值得考虑。

当满足上述条件且所有参与者都使用 Chrome 浏览器时，VP9 SVC 目前是一个可行的生产环境选择。Google Meet 内部使用 VP9 SVC 正是出于这些原因：在以 Chrome 为主的环境中，可以降低发送方带宽并实现更流畅的大规模质量自适应。

什么时候选择 Simulcast？

对于大多数服务于真实用户群的生产级 WebRTC 平台而言，Simulcast 是正确的架构选择。以下四个原因始终支持这一观点。

• 跨浏览器支持是不可或缺的：任何面向大众用户的平台都必须支持 Safari 和 iOS。如上所述，Safari 完全无法在 WebRTC 中编码 VP9，因此 VP9 SVC 和 VP9 Simulcast 都无法使用。真正实现跨浏览器兼容性的编解码器是 VP8，而使用 VP8 时，Simulcast 是唯一能够实现分辨率级别自适应的选项。VP8 Simulcast 可在 Chrome、Firefox、Safari 和 Edge 上运行，无需复杂的编解码器协商或针对每个设备进行功能检查。
• 实现成熟度：在成熟的媒体服务器（Janus、mediasoup 和 Jitsi Videobridge）中，SFU Simulcast 的实现已经过多年的生产环境测试，涵盖了各种网络条件、设备类型和会话规模。相比之下，SVC SFU 的实现成熟度较低，记录在案的故障模式较少，可供参考的部署案例也较少。
• 可预测性： Simulcast 的流选择逻辑透明且易于理解。一旦出现故障，调试也十分便捷：您可以轻松识别出 N 个流中的哪一个发生故障以及故障原因。SVC 的层依赖关系链增加了诊断的复杂性，从而延长了生产环境中故障的解决时间。对于缺乏深厚 SVC SFU 专业知识的团队而言，这确实是一个实际的运维风险。
• 编解码器依赖性： VP8 不支持空间 SVC。如果您的平台使用 VP8，则 Simulcast 是实现分辨率级自适应的唯一选择。WebRTC 中的 VP8 支持时间可伸缩性（L1T2 和 L1T3 模式），这使得 SFU 可以丢弃时间层来降低帧率，而无需关键帧请求。这并非完整的空间 SVC，但可以部分弥补帧率过渡时的平滑度不足。

对于以带宽效率为优先考虑的 Chrome 浏览器间会话，VP9 Simulcast 可以作为一种补充选项。但需要明确的是：VP9 Simulcast 与 VP9 SVC 一样，都面临着 Safari 浏览器的回退要求。跨浏览器的优势来自于 VP8，而非 Simulcast 本身。

给开发者的实用建议

• 计划在 2026 年搭建新平台？不妨使用 VP8 或 H.264 Simulcast。这两种协议都兼容所有主流浏览器，并在所有主流 SFU 实现中经过实战检验，同时覆盖 Safari 和 iOS，无需复杂的回退机制。对于 Chrome 浏览器之间的会话，如果需要在带宽受限的连接环境下获得更高的带宽效率，可以考虑添加 VP9 Simulcast 作为补充选项。
• 已经在使用 VP9 SVC 了吗？如果您的部署仅限于 Chrome 浏览器（例如，设备管理严格的受控企业环境），那么 VP9 SVC 是一个合理的生产环境选择。在推广到普通用户之前，请先定义并测试您的 Safari 回退策略。
• 计划支持 AV1 吗？目前，支持 WebRTC 的 AV1 SVC 尚未广泛普及，无法在各种浏览器上实现通用的双向视频通话。Chrome 自 2021 年的 Chrome 90 版本起就支持 AV1 WebRTC 编码，但实时 AV1 编码仍然非常消耗 CPU 资源，硬件加速也仅限于某些最新的芯片组，这限制了其通用性。Safari 的 WebRTC 协议栈完全不支持 AV1 编码，即使是在现在已具备 AV1 硬件编码功能的 Apple Silicon 芯片上也是如此。AV1 SVC 实现广泛的跨浏览器支持，预计要到 2028 年或更晚。建议您现在就设计一个简洁的编解码器抽象层，以便在浏览器支持 AV1 SVC 时，无需从头开始重新构建，即可将其作为转发选项添加。对于屏幕共享而言，AV1 尤其值得在支持的浏览器上进行评估，因为即使在今天，它在低帧率下的压缩效率对于屏幕内容来说仍然非常出色。
• 对于录制工作流程而言：无论您采用何种实时编码方式，将会话录制内容转码为 AV1 格式以便存储和 CDN 分发都值得评估。实时编码的限制不适用于会话后处理，而且在同等质量水平下，AV1 相对于 VP8 和 H.264 的压缩优势非常显著。
• 对于同时有超过十个活动视频流的 WebRTC 群组通话：密切监控 SFU CPU，并考虑对仅限 Chrome 的参与者子集使用 VP9 SVC，或者对每个发送方流管理开销成为瓶颈的大型会话使用 SFU 级联架构。

常见问题

Q1. WebRTC 中的 SVC 和 Simulcast 的核心区别是什么？

在 Simulcast 中，发送方同时对同一视频进行多级编码，并将所有编码后的码流作为独立的码流发送。信号流处理单元（SFU）根据可用带宽、视频块大小和扬声器状态，选择将哪个码流转发给每个接收方。在单层视频编码（SVC）中，发送方只需编码一次，即可生成一个单层比特流。SFU 会针对带宽有限的接收方选择性地丢弃较高层码流。SVC 在发送方端的带宽效率更高；而 Simulcast 则提供更广泛的浏览器兼容性和更简单的故障分析。

Q2. Safari 在 2026 年是否支持 SVC 编码？

不。Safari 无法在 WebRTC 中对 VP9 进行编码，这使得任何 Safari 参与者都无法使用 VP9 SVC 作为发送策略。同样的限制也使得 Safari 无法使用 VP9 Simulcast。Safari 从 Safari 14 / iOS 14 开始可以解码 VP9，但由于无法编码，无论 SFU 使用的是 SVC 还是 Simulcast，Safari 参与者都必须回退到 VP8 或 H.264。

Q3. SVC 和 Simulcast 哪种方式占用更少的发送端带宽？

SVC 使用的发送端带宽显著降低。与单一质量级别的编码相比，单层 SVC 流的开销极小。Simulcast 会同时编码两到三个独立的流；在典型的三层配置中，总上传成本比单个高质量流高出 30% 到 50%，但实际开销取决于子层的压缩程度。对于带宽受限的移动网络连接的发送方而言，这种差异至关重要。Chrome 浏览器要到 2026 年才能完全支持空间 SVC 编码；Firefox 提供时间可扩展性；Safari 则无法编码 VP9。

准备好在生产环境中体验自适应视频质量了吗？了解ZEGO SDK的视频大小流和分层编码