4、分辨率与帧率动态调整：自适应分辨率算法、帧率降级策略、Simulcast与SVC的实战应用
各位同学，欢迎来到第四章。这一章我们聊点实在的——分辨率与帧率的动态调整。
说实话，我在做WebRTC早期项目时，最头疼的就是这个问题。用户网络一波动，画面要么卡成PPT，要么糊成马赛克。后来我慢慢摸索出一套组合拳，今天全部分享给你们。
4.1 自适应分辨率算法：让画面自己“找平衡”
自适应分辨率，说白了就是根据网络状况动态调整视频尺寸。网络好时用1080p，差时降到480p甚至360p。
核心思路：通过实时监测带宽、丢包率、RTT，决定下一帧该用多大分辨率。
我常用的算法框架是这样的：
// 伪代码：自适应分辨率决策器
function decideResolution(bandwidth, packetLoss, rtt) {
let score = 100;
// 丢包惩罚
if (packetLoss > 5%) score -= 30;
if (packetLoss > 10%) score -= 40;
// RTT惩罚
if (rtt > 200ms) score -= 20;
if (rtt > 400ms) score -= 30;
// 带宽惩罚
if (bandwidth < 1Mbps) score -= 40;
if (score > 80) return { width: 1920, height: 1080 };
if (score > 60) return { width: 1280, height: 720 };
if (score > 40) return { width: 854, height: 480 };
return { width: 640, height: 360 };
}
关键点：不要频繁切换分辨率。我习惯加一个“冷却期”，至少保持2秒以上再切换，否则画面会一直闪烁。
我在项目中遇到过一个问题：用户网络在1Mbps和2Mbps之间反复横跳，导致分辨率每3秒切换一次。后来我加了滞后阈值——上升需要多30%带宽，下降需要少20%带宽，才稳定下来。
4.2 帧率降级策略：流畅度与清晰度的博弈
帧率降级，很多人以为就是简单地把30fps降到15fps。其实没那么简单。
降级策略矩阵：
| 网络状况 | 分辨率策略 | 帧率策略 | 我的建议 |
|---|---|---|---|
| 良好 | 保持最高 | 30fps | 不动 |
| 轻度拥塞 | 降一档分辨率 | 保持30fps | 先降分辨率，保帧率 |
| 中度拥塞 | 降两档分辨率 | 降到20fps | 分辨率优先 |
| 严重拥塞 | 最低分辨率 | 降到10-15fps | 保音频，视频可丢帧 |
为什么会这样？因为人眼对帧率的敏感度其实没那么高。15fps和30fps在静态场景下差别不大，但分辨率从720p降到360p，文字立马就看不清了。所以我的原则是：先降帧率，再降分辨率——不对，等等，上面表格里写的是先降分辨率？
嗯，这里要注意：不同场景策略不同。如果是屏幕共享（有文字），分辨率优先级更高。如果是视频通话（人脸），帧率优先级可以适当提高。我个人习惯在代码里加一个场景判断：
if (isScreenSharing) {
// 保分辨率，降帧率
resolutionPriority = 1.0;
frameratePriority = 0.6;
} else {
// 视频通话，平衡处理
resolutionPriority = 0.7;
frameratePriority = 0.8;
}
避坑指南：我曾经把帧率降到8fps以下，结果用户反馈“画面像在翻书”。后来我设了一个底线——最低10fps，低于这个值直接切到音频-only模式。
4.3 Simulcast与SVC：多流与分层编码的实战
Simulcast和SVC，这两个概念经常被搞混。我简单解释一下：
- Simulcast：同时发送多个分辨率的独立流（比如720p、480p、360p各一路）。接收端根据自身网络选择一路。
- SVC：只发一个流，但内部有分层（时间层、空间层、质量层）。接收端可以只解码部分层。
你想想看，Simulcast的优点是简单粗暴，缺点是带宽浪费（同时发三路）。SVC的优点是节省带宽，缺点是编码复杂度高，而且浏览器支持不统一。
我的实战选择：
- 如果是大型会议（几十人以上），用Simulcast。因为SVC的解码负担在接收端，人多时接收端扛不住。
- 如果是小规模通话（2-4人），用SVC。灵活性更好，带宽利用率高。
下面这张图展示了Simulcast和SVC的核心区别：
4.4 实战配置：在WebRTC中启用Simulcast
直接上代码。这是我在一个视频会议项目中实际用过的配置：
const pc = new RTCPeerConnection();
// 获取摄像头流
const stream = await navigator.mediaDevices.getUserMedia({
video: {
width: { ideal: 1920 },
height: { ideal: 1080 },
frameRate: { ideal: 30 }
}
});
// 添加视频轨道，启用Simulcast
const videoTrack = stream.getVideoTracks()[0];
const sender = pc.addTrack(videoTrack, stream);
// 关键：设置RTP编码参数
const parameters = sender.getParameters();
parameters.encodings = [
{ rid: 'high', maxBitrate: 2500000, maxFramerate: 30, scaleResolutionDownBy: 1.0 },
{ rid: 'mid', maxBitrate: 1000000, maxFramerate: 24, scaleResolutionDownBy: 2.0 },
{ rid: 'low', maxBitrate: 400000, maxFramerate: 15, scaleResolutionDownBy: 4.0 }
];
await sender.setParameters(parameters);
注意：Simulcast需要浏览器支持。Chrome从M71开始支持，Safari从14.5开始支持。Firefox目前只支持SVC。我在项目中吃过这个亏——用户用Firefox，Simulcast死活不生效，后来加了特性检测才解决。
4.5 SVC实战：VP9的SVC模式
SVC在WebRTC中主要通过VP9编码器实现。配置方式略有不同：
// 启用VP9 SVC
const parameters = sender.getParameters();
parameters.encodings = [{
scalabilityMode: 'L3T3', // 3层空间层 × 3层时间层
maxBitrate: 2500000,
maxFramerate: 30
}];
await sender.setParameters(parameters);
scalabilityMode参数说明：
| 模式 | 空间层数 | 时间层数 | 适用场景 |
|---|---|---|---|
| L1T1 | 1 | 1 | 最低复杂度 |
| L2T2 | 2 | 2 | 一般通话 |
| L3T3 | 3 | 3 | 高质量会议 |
我个人习惯用L2T2。L3T3虽然灵活，但编码延迟会增加20-30ms，对实时性要求高的场景不太友好。
4.6 动态切换策略：什么时候用Simulcast，什么时候用SVC？
这里我分享一个实战中的决策树：
- 先检测浏览器能力：支持SVC的用SVC，不支持的回退到Simulcast。
- 再判断参会人数：超过10人，强制Simulcast。因为SVC的接收端解码负担会随着人数线性增长。
- 最后看网络类型：如果是移动网络（4G/5G），优先SVC。因为移动网络波动大，SVC的细粒度调整更合适。
避坑指南：我曾经在Simulcast中设置了三个流，但没注意带宽总和。结果三个流加起来超过了上行带宽，导致所有流都卡顿。后来我加了一个总带宽限制：三个流的maxBitrate之和不超过上行带宽的80%。
4.7 性能监控与自适应触发
说了这么多策略，怎么触发调整？答案是：靠监控数据。
我常用的监控指标：
- 丢包率：超过5%触发降级
- RTT：超过300ms触发降级
- 抖动：超过50ms触发降级
- 编码耗时：超过30ms/帧，说明CPU扛不住了，降分辨率
// 监控回调示例
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState === 'failed') {
// 立即降级到最低配置
triggerDegradation('emergency');
}
};
// 定期检查统计信息
setInterval(async () => {
const stats = await pc.getStats();
let packetLoss = 0;
stats.forEach(report => {
if (report.type === 'inbound-rtp' && report.kind === 'video') {
packetLoss = report.packetsLost / report.packetsReceived;
}
});
if (packetLoss > 0.05) {
triggerDegradation('packet-loss');
}
}, 2000);
嗯，这里要注意：不要每秒钟都触发调整。我习惯用“积分制”——连续3次检测都超标，才执行降级。这样可以避免网络瞬态波动导致的误触发。
好了，这一章的内容就到这里。分辨率与帧率的动态调整，说白了就是在带宽、CPU、用户体验之间找平衡。没有银弹，只有根据场景不断调优。
希望这些实战经验对你有帮助。下一章我们会聊音频相关的优化，到时候见。