23、Adaptive Streaming：动态分辨率调整、帧率自适应、码率阶梯设计
自适应流，说白了就是让视频通话自己“看人下菜碟”。网络好的时候给你1080p，网络一抖，立马降到360p。我刚开始做WebRTC的时候，觉得这功能就是个锦上添花的东西。直到有一次在客户现场演示，会议室WiFi突然被隔壁部门抢带宽，画面直接卡成PPT……嗯，从那以后，我把自适应流当成了系统的生命线。
为什么需要自适应？
你想想看，用户的网络环境千奇百怪。有人用5G，有人在地铁里用4G，还有人连的是咖啡厅的公共WiFi。如果视频编码器始终用同一个参数，结果就是：要么高码率导致卡顿，要么低码率导致模糊。
自适应流的核心目标就三个：
- 不卡顿——丢包率控制在5%以内
- 不模糊——在带宽允许时尽量给高清
- 平滑切换——分辨率变化时不要“闪一下”
核心原则：自适应不是“一刀切”，而是“动态平衡”。带宽多就多吃，带宽少就少吃，但绝不能饿死（卡死）。
动态分辨率调整
分辨率调整，我习惯把它分成两步：检测和决策。
检测靠的是WebRTC内置的带宽估计器（GCC，Google Congestion Control）。它会根据RTT（往返时间）和丢包率，估算出当前可用带宽。决策层拿到这个数字后，决定要不要降分辨率。
举个例子，我之前的项目里遇到过一个问题：用户突然从WiFi切到4G，带宽从10Mbps掉到1Mbps。如果直接降到320x240，用户会感觉“画面突然糊了”。我的做法是：
// 伪代码：分辨率阶梯切换
const resolutionSteps = [
{ width: 1280, height: 720, minBitrate: 1500 }, // 720p
{ width: 640, height: 480, minBitrate: 800 }, // 480p
{ width: 320, height: 240, minBitrate: 300 }, // 240p
];
function adjustResolution(estimatedBandwidth) {
for (let step of resolutionSteps) {
if (estimatedBandwidth >= step.minBitrate) {
return step;
}
}
return resolutionSteps[resolutionSteps.length - 1];
}这里要注意，不要频繁切换。我见过有人每秒钟检测一次，结果分辨率在720p和480p之间来回跳，用户看着画面一抽一抽的。我个人建议：切换间隔至少3秒，并且加上“滞回区间”。比如从720p降到480p需要带宽低于800kbps，但从480p升回720p需要带宽高于1200kbps。这样能避免“乒乓效应”。
避坑指南：我曾经在iOS设备上遇到过分辨率切换后编码器重新初始化的耗时问题。解决方案是：预创建多个分辨率的编码器实例，切换时直接换实例，而不是销毁重建。
帧率自适应
帧率自适应，很多人容易忽略。其实帧率对用户体验的影响非常大。举个例子，你在看一个演讲者的PPT翻页，30fps和15fps差别不大。但如果是体育直播，30fps和15fps就是“流畅”和“幻灯片”的区别。
帧率自适应的逻辑其实很简单：
- 带宽充足时：保持30fps，保证运动流畅
- 带宽紧张时：先降分辨率，再降帧率
- 带宽极度紧张时：降到15fps甚至10fps，但保持画面清晰
我个人的经验是：帧率不要低于10fps。低于这个值，人眼会明显感觉到卡顿，而且唇音同步会出问题。我在一个远程医疗项目里试过降到8fps，医生反馈说“看不清病人的细微动作”，后来我们就把下限锁在了12fps。
// 帧率自适应逻辑
function adjustFramerate(estimatedBandwidth, currentResolution) {
const resolutionBitrate = getResolutionBitrate(currentResolution);
const headroom = estimatedBandwidth - resolutionBitrate;
if (headroom > 200) {
return 30; // 带宽充裕，满帧
} else if (headroom > 50) {
return 20; // 中等带宽，降帧
} else {
return 12; // 带宽紧张，保清晰度
}
}码率阶梯设计
码率阶梯，说白了就是给不同分辨率配一个“推荐码率”和“最低码率”。这个设计直接决定了自适应流的效果。
我见过很多团队直接照搬HLS的码率阶梯，结果在实时通信场景下效果很差。为什么？因为HLS是点播，可以预缓冲；而WebRTC是实时流，延迟要求高，码率波动必须平滑。
下面是我在项目中总结的一套码率阶梯：
| 分辨率 | 推荐码率 (kbps) | 最低码率 (kbps) | 最高码率 (kbps) | 适用场景 |
|---|---|---|---|---|
| 1280x720 (720p) | 1500 | 800 | 2500 | 桌面共享、高清会议 |
| 960x540 (540p) | 1000 | 500 | 1800 | 一般视频通话 |
| 640x480 (480p) | 600 | 300 | 1200 | 移动端、弱网 |
| 320x240 (240p) | 300 | 150 | 600 | 极端弱网 |
注意：码率阶梯不是死的。我建议你在实际部署时，根据用户群体的网络状况做微调。比如东南亚地区的用户，4G网络普遍比欧美差，可以把最低码率再压低一些。
自适应流的整体架构
说了这么多，我们来画一张图，把整个自适应流的流程串起来。
实际项目中的坑
最后分享几个我踩过的坑：
- 不要只看丢包率：有一次网络抖动，丢包率只有2%，但RTT飙升到500ms。如果只看丢包率，决策引擎不会降级，结果用户端画面延迟了3秒。后来我把RTT也纳入了决策因子。
- 注意编码器预热：切换分辨率后，编码器需要几帧来稳定码率。我建议在切换后的前5帧，码率控制放宽一些，避免画面出现“马赛克”。
- 用户偏好也很重要：有些用户宁愿卡一点也要看高清，有些用户宁愿模糊一点也要流畅。我在项目中加了一个“偏好设置”，让用户自己选“流畅优先”还是“清晰优先”。
我的习惯：每次上线新版本，我都会在后台打点记录“分辨率切换次数”和“用户满意度评分”。如果切换次数过多，说明码率阶梯设计得太激进；如果满意度下降，说明降级策略太保守。数据会告诉你真相。
自适应流不是一锤子买卖。网络在变，用户在变，你的策略也得跟着变。嗯，保持迭代，保持敬畏。