15、Simulcast与SVC场景下的拥塞控制：分层编码的带宽分配、优先级策略、动态码率调整
聊到WebRTC的拥塞控制，大部分资料都在讲单流场景——也就是一路视频流，一个码率，一个RTP流。但实际生产环境中，尤其是多人会议、直播推流这类场景，单流根本不够用。你想想看，一个用户可能同时用手机和电脑接入，网络状况天差地别，你让他只发一路码率？那体验肯定崩。
所以就有了Simulcast和SVC。这两个东西，说白了就是「分层编码」的两种不同实现思路。我最早接触Simulcast是在2017年做视频会议SDK的时候，当时被客户吐槽「你们这画质怎么一卡一卡的」，后来才发现是单流在弱网下根本扛不住。嗯，从那以后我就开始认真研究分层编码下的拥塞控制该怎么搞。
15.1 Simulcast vs SVC：两种分层思路
先简单区分一下这两个概念，因为很多新人容易搞混。
| 特性 | Simulcast | SVC |
|---|---|---|
| 编码方式 | 同时编码多路独立流（如360p、720p、1080p） | 单流内部分层（时间层、空间层、质量层） |
| 带宽开销 | 较高，多路流同时发送 | 较低，层间有依赖关系 |
| 解码复杂度 | 低，每路独立解码 | 高，需要层间参考 |
| 拥塞控制灵活性 | 高，可以独立丢弃某路流 | 中等，丢弃高层需保证底层完整 |
| 浏览器支持 | 广泛（Chrome、Firefox原生支持） | 有限（Safari部分支持，Chrome实验性支持） |
我个人习惯把Simulcast叫做「多路并行流」，SVC叫做「单流叠罗汉」。前者是空间换带宽灵活性，后者是计算换带宽效率。没有绝对的好坏，看场景选。
15.2 分层编码下的带宽分配：核心矛盾
拥塞控制在单流场景下，核心问题是「我该降多少码率」。但在分层编码场景下，问题变成了「我该降哪一层」。这完全是两个维度的问题。
举个例子。假设你开了Simulcast，发了三路流：
- 低分辨率流：320x180，150kbps
- 中分辨率流：640x360，500kbps
- 高分辨率流：1280x720，1.5Mbps
总带宽预算2.15Mbps。突然网络抖动，可用带宽降到800kbps。这时候你怎么分配？
我见过不少团队的做法是「按比例降」，每路都砍一刀。结果呢？低流勉强能看，中流糊成一片，高流直接卡死。这其实是最差的策略。
核心原则：分层编码的带宽分配，优先级永远高于码率平滑。宁可保一路清晰，也不要三路都模糊。
15.3 优先级策略：谁该被保，谁该被丢
我在项目中遇到过最头疼的问题，就是优先级策略怎么定。不同场景，优先级完全不同。
15.3.1 基于分辨率的优先级
最直观的策略：高分辨率流优先级最高，低分辨率流优先级最低。带宽不足时，先丢低流，再丢中流，最后才动高流。
但这里有个坑——你想想看，如果所有接收端都只想要高流，那Simulcast的意义何在？实际上，Simulcast的价值在于「不同接收端拿不同流」。比如手机端拿低流，PC端拿高流。所以优先级不能只看分辨率，还要看接收端的需求。
15.3.2 基于接收端的优先级
我建议的做法是：每个接收端上报自己期望的流层级。发送端根据所有接收端的反馈，动态调整各层的码率分配。
举个例子：
- 接收端A（手机，弱网）：期望低流
- 接收端B（PC，强网）：期望高流
- 接收端C（PC，中等网络）：期望中流
这时候，高流优先级最高，因为有两个接收端依赖它（B和C都间接依赖高流？不，C只依赖中流）。嗯，这里要仔细算一下依赖关系。
避坑指南：我曾经在实现时犯过一个错误——只统计了「当前正在接收某层流的接收端数量」，忽略了「可能切换到该层的接收端」。结果导致高流被误丢，用户体验反而更差。正确的做法是：统计所有接收端的「最大可接收层级」，然后保底满足最高层级的需求。
15.4 动态码率调整：分层编码的拥塞控制算法
有了优先级策略，接下来就是具体的码率调整算法。这里我结合GCC（Google Congestion Control）和PCC（Performance-oriented Congestion Control）的思路，讲一下分层场景下的调整逻辑。
15.4.1 基于GCC的分层调整
GCC的核心是带宽估计 + 码率分配。在分层场景下，带宽估计的逻辑不变，但码率分配需要改。
标准GCC的码率分配公式：
// 单流场景
target_bitrate = estimated_bandwidth * 0.95 // 留5%余量
// 分层场景（Simulcast）
total_target = estimated_bandwidth * 0.9 // 留10%余量，因为分层切换有开销
// 按优先级分配
high_priority_bitrate = min(high_max, total_target * 0.6)
mid_priority_bitrate = min(mid_max, (total_target - high_priority_bitrate) * 0.7)
low_priority_bitrate = total_target - high_priority_bitrate - mid_priority_bitrate
这个分配比例不是固定的。我习惯用动态权重：根据接收端反馈，实时调整各层的权重系数。比如弱网接收端增多，就提高低流的权重。
15.4.2 基于PCC的分层调整
PCC的思路更激进——它通过「试错」来找到最优码率。在分层场景下，我尝试过一种方法：
- 每次调整时，随机选择一个层级进行码率增减
- 观察所有接收端的QoE（Quality of Experience）变化
- 如果QoE提升，保留调整；否则回退
这个方法的好处是自适应性强，坏处是收敛慢。我在实验中发现，PCC在分层场景下需要约3-5秒才能稳定，而GCC只需要1-2秒。所以生产环境中，我建议以GCC为主，PCC作为辅助优化手段。
15.5 知识体系总览
下面这张图是我自己总结的分层编码拥塞控制的核心逻辑，画出来方便你理解整体流程。
15.6 实际项目中的避坑经验
最后分享几个我在实际项目中踩过的坑，希望能帮你少走弯路。
坑1：Simulcast流切换的延迟
我曾经在实现Simulcast流切换时，发现从高流切到低流需要1-2秒的延迟。原因是编码器需要重新配置分辨率。后来我用了「预编码」策略——让编码器同时维护多路流的编码状态，切换时直接发送已编码的帧，延迟降到200ms以内。
坑2：SVC层间依赖导致的「雪崩效应」
SVC的时间层依赖关系很脆弱。如果底层（如T0层）丢包，所有高层（T1、T2）都无法解码。我遇到过因为底层丢包率超过5%，导致整个视频流卡死的情况。解决方案是：在拥塞控制中，给底层流预留额外的带宽余量（约10-15%），确保底层传输的可靠性。
坑3：带宽估计的「假阳性」
分层编码场景下，带宽估计容易受到「流切换」的干扰。比如你从高流切到低流，瞬间码率下降，带宽估计器会误判为「网络变好」，然后开始增加码率。结果刚切回高流，网络又扛不住了。我建议在流切换后的1秒内，冻结带宽估计器的调整，等稳定后再恢复。
嗯，关于Simulcast和SVC场景下的拥塞控制，核心就是这三件事：带宽怎么分、优先级怎么定、码率怎么调。没有银弹，只有根据场景不断调优。希望这些经验对你有帮助。
公众号:蓝海资料掘金营，微信deep3321