14、Simulcast深度实践：多流编码的配置、接收端流切换逻辑、带宽分配策略
Simulcast，说白了就是同一路视频源，编码器同时产出多个不同分辨率和码率的流。嗯，这玩意儿在大型会议、直播场景里几乎是标配。我最早接触Simulcast是在一个跨国视频会议项目里，当时用户反馈说「为什么我网络卡了，画面直接变成马赛克？」——后来发现，没有Simulcast，接收端只能硬扛单流，网络一波动就崩。
今天咱们把Simulcast拆开揉碎了讲。我会从编码配置讲起，再到接收端怎么切流，最后聊带宽分配策略。你想想看，这三块其实是环环相扣的。
核心要点：Simulcast不是简单的「多发几路流」，而是编码器、网络、接收端三方的协同博弈。配置不对，带宽浪费；切换不灵，用户体验差；分配策略不好，整体吞吐量上不去。
14.1 多流编码的配置
先说说编码配置。Simulcast不是简单地把分辨率改小就完事。我见过不少团队，直接把单流配置复制三份，改个分辨率就上线——结果带宽爆炸，画质还差。
正确的做法是：每层流独立配置编码参数。包括分辨率、帧率、码率、关键帧间隔。举个例子：
// 发送端 Simulcast 编码配置示例
const simulcastConfig = {
high: {
width: 1280,
height: 720,
frameRate: 30,
bitrate: 2500000, // 2.5 Mbps
keyFrameInterval: 2000
},
medium: {
width: 640,
height: 360,
frameRate: 24,
bitrate: 800000, // 800 Kbps
keyFrameInterval: 3000
},
low: {
width: 320,
height: 180,
frameRate: 15,
bitrate: 200000, // 200 Kbps
keyFrameInterval: 5000
}
};这里有个坑：关键帧间隔不能一样。我曾经在项目中把三层流都设成2秒一个关键帧，结果网络波动时，三层流同时请求关键帧，瞬间带宽打满，直接卡死。后来我把低清流的关键帧间隔拉长到5秒，高清流保持2秒，问题就解决了。
我的习惯：高清流用短关键帧间隔（1-2秒），低清流用长间隔（4-6秒）。因为低清流本身码率低，丢一帧恢复成本小，没必要频繁发关键帧。
另外，编码器的复杂度预设也要分层。高清流可以用medium或slow预设，追求画质；低清流用fast或veryfast，降低CPU开销。你想想看，低清流本来就看不清细节，没必要花大量CPU去优化。
14.2 接收端流切换逻辑
接收端怎么切流？说白了就是根据网络带宽，动态选择接收哪一层。WebRTC默认用的是基于REMB（Receiver Estimated Maximum Bitrate）的切换策略。
流程是这样的：
- 接收端持续测量接收带宽（通过Transport-CC反馈）
- 当带宽下降，低于当前流码率的1.2倍时，触发降级
- 接收端发送RTCP PLI（Picture Loss Indication）请求关键帧
- 发送端切换到低一层流，并发送关键帧
- 当带宽回升，稳定超过高一层流码率的1.5倍持续3秒，触发升级
嗯，这里要注意：切换有延迟。从检测到带宽变化，到实际切流完成，通常需要500ms到2秒。我在项目中遇到过一个问题：用户网络频繁抖动，导致流在高低层之间来回切换，画面一会儿清晰一会儿模糊，体验极差。
避坑指南：我曾经在切换逻辑里加了「滞回区间」——降级阈值和升级阈值之间留出20%的缓冲区。比如高清流码率2.5Mbps，降级阈值设为2.0Mbps，升级阈值设为3.0Mbps。这样能有效避免「乒乓切换」。
代码层面，接收端可以通过RTCRtpReceiver的getStats()获取各层流的接收情况：
// 接收端获取各层流统计
const stats = await receiver.getStats();
stats.forEach(stat => {
if (stat.type === 'inbound-rtp' && stat.kind === 'video') {
console.log(`层: ${stat.rid}, 接收码率: ${stat.bytesReceived / stat.timestamp} bps`);
// 根据码率决定是否切换
if (stat.bytesReceived / stat.timestamp < threshold) {
// 触发降级
requestDowngrade();
}
}
});14.3 带宽分配策略
带宽分配是Simulcast最核心也最容易被忽视的部分。发送端总带宽是固定的（比如5Mbps），三层流怎么分？
我常用的策略是比例分配法：
| 流层级 | 默认比例 | 带宽充足时 | 带宽紧张时 |
|---|---|---|---|
| 高清流 (720p) | 50% | 60% | 30% |
| 标清流 (360p) | 30% | 25% | 40% |
| 低清流 (180p) | 20% | 15% | 30% |
为什么带宽紧张时要给低清流更多比例？因为低清流是保底流，所有接收端都能收。如果低清流码率太低，画面直接崩了，那Simulcast就失去意义了。
实际项目中，我还会结合接收端数量动态调整。比如有100个接收端，其中80个只能收低清流，那低清流的带宽占比就要提高。我曾经写过一个自适应分配算法：
// 自适应带宽分配
function allocateBandwidth(totalBandwidth, receiverCapabilities) {
const highCount = receiverCapabilities.filter(r => r.canReceiveHigh).length;
const mediumCount = receiverCapabilities.filter(r => r.canReceiveMedium).length;
const lowCount = receiverCapabilities.length;
// 权重计算：高清流权重3，标清流权重2，低清流权重1
const totalWeight = highCount * 3 + mediumCount * 2 + lowCount * 1;
return {
high: (totalBandwidth * highCount * 3) / totalWeight,
medium: (totalBandwidth * mediumCount * 2) / totalWeight,
low: (totalBandwidth * lowCount * 1) / totalWeight
};
}这个算法不完美，但胜在简单实用。你想想看，如果大部分接收端都能收高清流，那高清流就应该分更多带宽；反之，如果大部分接收端只能收低清流，那低清流才是重点。
重要提醒：带宽分配不是一次性的。发送端需要每1-2秒重新计算一次，因为接收端的网络状况和数量都在动态变化。我习惯把带宽分配逻辑放在编码器的onStats回调里，每次收到统计就重新算一遍。
最后说一个容易被忽略的点：Simulcast和SVC的区别。Simulcast是独立编码的多层流，SVC是依赖编码的层级流。Simulcast的优点是切换快、容错好，缺点是带宽开销大（三层流总码率是单流的1.5-2倍）。SVC带宽利用率高，但解码复杂度高，而且浏览器支持有限。我个人更倾向Simulcast，因为它在实际网络环境中的表现更稳定。
好了，Simulcast的深度实践就聊到这儿。记住三个关键词：独立配置、滞回切换、动态分配。把这三点吃透，你的Simulcast方案基本不会出大问题。