联播与 SVC · 一次编码，多档服务
会议里有人网好有人网差，发一档视频没法同时讨好所有人。联播（发多条独立流）和 SVC（一条流内含多层）让 SFU 能按各接收者的网况转发合适的画质。这一章讲清两者的原理、区别，以及它们为群组通话解决的核心问题。
联播与 SVC · 一次编码，多档服务
自适应让一路视频适配一个接收者。但群组通话（经 SFU）里，不同接收者网况天差地别——有人千兆光纤，有人挤在地铁 4G。发一档视频：发高清，网差的人卡；发低清，网好的人亏。怎么同时讨好所有人？答案是联播和 SVC。
联播：同时发好几档
联播（Simulcast） 最直接：同一个画面，同时编码成好几条独立的流，分辨率 / 码率各异（比如同时发 1080p、540p、270p 三条）。
SVC：一条流，内含多层
SVC（Scalable Video Coding，可伸缩编码） 更精巧：一条流内部就分好几层，层层叠加、逐步增强。
SVC 把视频编码成“基础层 + 增强层”：只解基础层能得到低质画面，叠加增强层逐步提升到高质。SFU 想给谁降质，只要丢弃它的高层**、只转发低层即可——不必要求发送端多编。** 增强分两个维度：空间（分辨率） 和 时间（帧率）。比如时间 SVC：基础层是 15fps，加一层变 30fps——SFU 给网差的人只转发基础层的帧（那些帧本身就构成完整的 15fps），就把帧率砍半了。
SVC 相比联播的优势：发送端只编一条流（层之间共享信息，比编几条独立流省），上行也更省。代价是编码更复杂、对编解码器有要求（VP9、AV1 原生支持好 SVC，VP8 有限）。用 ScalabilityMode（如 L3T3 = 3 空间层 3 时间层）描述层结构。SVC 是现代群组通话的先进方案，尤其在发送端上行受限时更优。
联播 vs SVC：一张对比
| 联播 Simulcast | SVC | |
|---|---|---|
| 怎么多档 | 编多条独立流 | 一条流内分层 |
| 发送端开销 | 高（编几遍） | 较低（编一遍） |
| SFU 怎么降质 | 挑一条流转发 | 丢弃高层 |
| 编解码器要求 | 通用（VP8 也行） | VP9/AV1 支持好 |
| 上行带宽 | 高（多条全发） | 较省（层共享） |
两者本质是同一个思路的不同实现：“提前准备好多档质量，让 SFU 按需下发，而不必转码。” 核心洞察是把“降质”的决定权，从“发送端为某一个人”移到“SFU 为每一个人”——发送端只管把“多档可能性”准备好（联播的多条流 / SVC 的多层），SFU 再针对每个接收者的实时网况挑合适的下发。这让一次上行，服务千人千面，是 WebRTC 支撑大型会议的关键。选联播还是 SVC，是“发送端 CPU / 上行”和“编解码器能力”之间的权衡，现代趋势是 SVC（尤其 AV1/VP9）。
小结与下一章
群组通话里接收者网况各异，发一档讨好不了所有人。联播编多条独立流（各档分辨率 / 码率），SFU 挑一条转发——通用但发送端开销大。SVC 一条流内分基础层 + 增强层（空间 / 时间），SFU 丢高层降质——省上行但要 VP9/AV1 支持，用 ScalabilityMode 描述。两者同一思路：提前备好多档，让 SFU 按各人网况下发，不必转码。
发多档 / 多层，总码率就得在它们之间分配——给哪档多少？下一章讲视频码率分配。👉 视频码率分配。
参考资料
- [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。