# 联播与 SVC · 一次编码，多档服务

> 会议里有人网好有人网差，发一档视频没法同时讨好所有人。联播（发多条独立流）和 SVC（一条流内含多层）让 SFU 能按各接收者的网况转发合适的画质。这一章讲清两者的原理、区别，以及它们为群组通话解决的核心问题。

- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-07-14
- 原文：https://daiw.org/manual/webrtc/simulcast-svc
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 联播与 SVC · 一次编码，多档服务

[自适应](https://daiw.org/manual/webrtc/video-adaptation)让一路视频适配**一个**接收者。但群组通话（经 [SFU](https://daiw.org/manual/webrtc/sframe)）里，不同接收者网况天差地别——有人千兆光纤，有人挤在地铁 4G。发**一档**视频：发高清，网差的人卡；发低清，网好的人亏。怎么**同时讨好所有人**？答案是**联播**和 **SVC**。

## 联播：同时发好几档

**联播（Simulcast）** 最直接：**同一个画面，同时编码成好几条独立的流**，分辨率 / 码率各异（比如同时发 1080p、540p、270p 三条）。

<Callout type="info">
  **联播 = 发送端把同一画面编成多条独立流，[SFU](https://daiw.org/manual/webrtc/sframe) 按每个接收者的[网况](https://daiw.org/manual/webrtc/rate-control)，转发合适的那一档给他。** 网好的接收者收 1080p，网差的收 270p——各取所需，SFU 只是**挑一条转发**，自己不必转码（转码极耗服务器 CPU）。这就解决了“一档讨好不了所有人”的难题。

  代价是发送端要**同时编码多条流**——CPU 和上行带宽都翻几倍。所以联播的档数有限（通常 2-3 档），且[码率要在各档间分配](https://daiw.org/manual/webrtc/video-bitrate-allocation)。每条联播流有自己的 [SSRC](https://daiw.org/manual/webrtc/rtp-packet)，在 [SDP](https://daiw.org/manual/webrtc/sdp-and-jsep) 里协商（`a=simulcast`）。发送端上行足够时，联播是群组通话的主流方案。
</Callout>

## SVC：一条流，内含多层

**SVC（Scalable Video Coding，可伸缩编码）** 更精巧：**一条流内部就分好几层**，层层叠加、逐步增强。

<Callout type="info">
  **SVC 把视频编码成“基础层 + 增强层”：只解基础层能得到低质画面，叠加增强层逐步提升到高质。[SFU](https://daiw.org/manual/webrtc/sframe) 想给谁降质，只要**丢弃它的高层**、只转发低层即可——不必要求发送端多编。** 增强分两个维度：**空间（分辨率）** 和 **时间（帧率）**。比如时间 SVC：基础层是 15fps，加一层变 30fps——SFU 给网差的人**只转发基础层的帧**（那些帧本身就构成完整的 15fps），就把帧率砍半了。

  SVC 相比[联播](https://daiw.org/manual/webrtc/simulcast-svc)的优势：**发送端只编一条流**（层之间共享信息，比编几条独立流省），上行也更省。代价是**编码更复杂**、对编解码器有要求（VP9、AV1 原生支持好 SVC，VP8 有限）。用 `ScalabilityMode`（如 `L3T3` = 3 空间层 3 时间层）描述层结构。SVC 是现代群组通话的先进方案，尤其在发送端上行受限时更优。
</Callout>

## 联播 vs SVC：一张对比

| | 联播 Simulcast | SVC |
| --- | --- | --- |
| 怎么多档 | 编**多条独立流** | **一条流内分层** |
| 发送端开销 | 高（编几遍） | 较低（编一遍） |
| [SFU](https://daiw.org/manual/webrtc/sframe) 怎么降质 | 挑一条流转发 | 丢弃高层 |
| 编解码器要求 | 通用（VP8 也行） | VP9/AV1 支持好 |
| 上行带宽 | 高（多条全发） | 较省（层共享） |

<Callout type="info">
  **两者本质是同一个思路的不同实现：“提前准备好多档质量，让 [SFU](https://daiw.org/manual/webrtc/sframe) 按需下发，而不必转码。”** 核心洞察是**把“降质”的决定权，从“发送端为某一个人”移到“SFU 为每一个人”**——发送端只管把“多档可能性”准备好（[联播的多条流 / SVC 的多层](https://daiw.org/manual/webrtc/simulcast-svc)），SFU 再针对每个接收者的[实时网况](https://daiw.org/manual/webrtc/rate-control)挑合适的下发。这让**一次上行，服务千人千面**，是 WebRTC 支撑大型会议的关键。选联播还是 SVC，是“发送端 CPU / 上行”和“编解码器能力”之间的权衡，现代趋势是 SVC（尤其 AV1/VP9）。
</Callout>

## 小结与下一章

群组通话里接收者网况各异，**发一档讨好不了所有人**。**联播**编**多条独立流**（各档分辨率 / 码率），[SFU](https://daiw.org/manual/webrtc/sframe) 挑一条转发——通用但发送端开销大。**SVC** 一条流**内分基础层 + 增强层**（空间 / 时间），SFU 丢高层降质——省上行但要 [VP9/AV1](https://daiw.org/manual/webrtc/video-encoder-abstraction) 支持，用 `ScalabilityMode` 描述。两者同一思路：**提前备好多档，让 SFU 按各人网况下发，不必转码**。

发多档 / 多层，总[码率](https://daiw.org/manual/webrtc/rate-control)就得在它们之间**分配**——给哪档多少？下一章讲视频码率分配。👉 [视频码率分配](https://daiw.org/manual/webrtc/video-bitrate-allocation)。

## 参考资料

- [1] libwebrtc 源码.`modules/video_coding/codecs/vp9/`、`av1/`（SVC 实现）、`video/`（simulcast）。
- [2] libwebrtc 源码.`api/video_codecs/scalability_mode.h`（`ScalabilityMode`）、`modules/video_coding/svc/`。
- [3] IETF / W3C simulcast（RFC 8853）、SVC scalability。