12、媒体流控制：带宽估计、拥塞控制、流优先级、动态切换音视频流
媒体流控制，说白了就是让视频通话在有限的网络条件下，尽可能保持流畅和清晰。你想想看，网络环境千变万化，Wi-Fi 信号不稳定、4G 信号波动、甚至跨洋传输的延迟抖动，这些都会直接影响用户体验。如果不去控制，画面卡成 PPT、声音断断续续，用户早就挂电话了。
我在项目中遇到过不少这样的场景：用户一边走路一边视频，网络从 Wi-Fi 切到 4G，画面瞬间模糊，然后过几秒又恢复。这背后就是媒体流控制机制在起作用。今天我们就来拆解一下，WebRTC 到底是怎么做到这一点的。
12.1 带宽估计：摸清网络的底牌
带宽估计，就是 WebRTC 在实时探测当前网络能承载多少数据量。它不是一个静态值，而是动态变化的。WebRTC 内部有一套复杂的算法，我习惯把它分成两类：基于丢包的估计和基于延迟的估计。
| 估计方式 | 原理 | 适用场景 |
|---|---|---|
| 基于丢包 | 通过 RTCP 反馈的丢包率，判断网络是否过载 | 丢包明显的网络，如无线环境 |
| 基于延迟 | 通过 RTT 和单向延迟变化，判断网络拥塞程度 | 延迟敏感的场景，如实时互动 |
WebRTC 默认使用的是 GCC（Google Congestion Control） 算法。它结合了丢包和延迟两种信号，动态调整发送码率。我个人习惯在调试时，通过 getStats() 接口观察 availableOutgoingBitrate 这个字段，它能直观反映当前估计的带宽。
核心要点：带宽估计不是一次性的，而是持续进行的。WebRTC 每几百毫秒就会重新评估一次，然后调整编码器的目标码率。
12.2 拥塞控制：别让数据堵在路上
拥塞控制，是带宽估计的后续动作。当检测到网络开始拥堵时，WebRTC 会主动降低发送速率，避免数据包堆积和进一步丢包。这有点像高速公路上的限流措施——车太多就放慢速度，防止彻底堵死。
WebRTC 的拥塞控制有两个关键机制：
- 发送端控制：根据估计带宽，调整 RTP 包的发送间隔和大小。
- 接收端反馈：通过 REMB（Receiver Estimated Maximum Bitrate）或 Transport-CC（Transport-wide Congestion Control）反馈给发送端。
我曾经在一个跨国视频会议项目中，发现跨洋链路的 RTT 高达 300ms，默认的拥塞控制算法反应太慢，导致画面频繁卡顿。后来我们调整了拥塞控制的参数，把 minBitrate 和 maxBitrate 设置得更合理，情况才好转。
注意：不要随意关闭拥塞控制。有些开发者为了追求画质，把码率固定死，结果网络波动时直接导致通话中断。拥塞控制是保底机制，一定要保留。
12.3 流优先级：给重要数据让路
在一个视频通话中，通常有多个媒体流：视频流、音频流、屏幕共享流等。它们的优先级是不一样的。音频丢了，用户立刻能感知；视频稍微模糊一点，用户还能接受。所以，我们需要给不同的流设置优先级。
WebRTC 通过 RTP 扩展头 中的 a=extmap 来标记优先级。具体来说，可以在 SDP 中为每个媒体流指定 a=priority 属性。数值越大，优先级越高。
// 设置音频流优先级最高
const audioSender = pc.getSenders().find(s => s.track.kind === 'audio');
if (audioSender) {
const params = audioSender.getParameters();
params.priority = 'high'; // 可选: 'very-low', 'low', 'medium', 'high'
audioSender.setParameters(params);
}
// 设置视频流优先级中等
const videoSender = pc.getSenders().find(s => s.track.kind === 'video');
if (videoSender) {
const params = videoSender.getParameters();
params.priority = 'medium';
videoSender.setParameters(params);
}
嗯，这里要注意：优先级设置只在带宽受限时生效。如果网络足够好，所有流都能全速传输，优先级就没意义了。我在做在线教育项目时，把老师的视频流优先级设高，学生的设低，这样即使网络波动，老师的画面也能保持清晰。
小技巧：屏幕共享流的优先级通常设为 medium 或 high，因为用户更关注共享的内容，而不是摄像头画面。
12.4 动态切换音视频流：灵活应对网络变化
动态切换，指的是在通话过程中，根据网络状况或用户需求，实时切换音视频流的编码参数、分辨率、甚至开关某个流。这是媒体流控制的最终体现。
常见的动态切换场景包括：
- 分辨率降级：网络变差时，从 720p 降到 480p，甚至 360p。
- 帧率调整：从 30fps 降到 15fps，减少数据量。
- 流开关：暂时关闭视频流，只保留音频，节省带宽。
WebRTC 提供了 RTCRtpSender.replaceTrack() 方法，可以动态替换轨道。比如，当网络变差时，我们可以把高清视频轨道替换成低清轨道。
// 假设有两个视频轨道：高清和低清
const hdTrack = videoStream.getVideoTracks()[0]; // 高清
const ldTrack = lowQualityStream.getVideoTracks()[0]; // 低清
// 网络变差时，切换到低清
async function switchToLowQuality() {
const sender = pc.getSenders().find(s => s.track.kind === 'video');
if (sender) {
await sender.replaceTrack(ldTrack);
console.log('已切换到低清流');
}
}
// 网络恢复时，切换回高清
async function switchToHighQuality() {
const sender = pc.getSenders().find(s => s.track.kind === 'video');
if (sender) {
await sender.replaceTrack(hdTrack);
console.log('已切换回高清流');
}
}
我曾经在一个直播项目中，用 replaceTrack 实现了多路流切换。用户可以在摄像头、屏幕共享、甚至外部视频源之间自由切换，体验非常流畅。不过要注意，切换时会有短暂的画面停顿，因为需要重新协商编码器参数。
核心要点：动态切换的关键是 平滑。不要频繁切换，也不要切换得太慢。我建议在网络估计带宽变化超过 20% 时，才触发切换动作。
12.5 知识体系总览
下面这张图，把媒体流控制的几个核心模块串起来了。你可以看到，带宽估计是基础，拥塞控制是执行，流优先级是策略，动态切换是最终表现。它们环环相扣，缺一不可。
这张图里，带宽估计和拥塞控制是底层机制，流优先级是策略配置，动态切换是上层表现。实际项目中，这四个环节是协同工作的。比如，带宽估计发现网络变差，拥塞控制降低码率，同时根据优先级决定先降谁的码率，最后触发动态切换动作。
个人建议：在开发媒体流控制功能时，先从带宽估计入手。把网络探测做准了，后面的控制才有依据。我习惯在调试阶段，把 getStats() 的数据打印到控制台，实时观察带宽变化。
好了，关于媒体流控制的核心内容就这些。记住，控制不是目的，让用户无感知才是。好的媒体流控制，用户只会觉得画面流畅、声音清晰，而不会注意到背后发生了什么。