在 WebRTC 中，速率控制（Rate Control）和码率控制（Bitrate Control）是两个密切相关但不同的概念，主要区别在于控制对象、实现层次和目标：

一、核心定义与区别

二、工作原理详解

1. 速率控制（Rate Control）

• 核心机制：基于 ** 拥塞控制（Congestion Control）** 算法，实时监测网络状态（延迟、丢包率），动态调整发送速率。
• 关键组件：带宽估计（BWE）：通过 RTCP 反馈（如 REMB、TWCC）计算可用带宽。发送端速率控制器：根据 BWE 结果，决定实际发送速率（包括媒体包 + 重传包 + RTCP 包）。
• 典型算法：Google Congestion Control（GCC），结合延迟 - based 和丢包 - based 策略。
• 示例流程：
• plaintext
• 1. 接收端通过RTCP包反馈网络状态（如"丢包率3%，RTT=80ms"） 2. 发送端BWE算法估算可用带宽为500kbps 3. 速率控制器将总发送速率限制为500kbps
• 
  

2. 码率控制（Bitrate Control）

• 核心机制：根据速率控制提供的可用带宽上限，调整编码器参数（如量化参数 QP、帧率、分辨率）。
• 关键组件：编码器参数控制器：决定编码器的具体配置（如 VP8/VP9/H.264 的编码参数）。质量优化器：在带宽限制内，平衡分辨率、帧率和画质（如优先保持帧率还是清晰度）。
• 典型策略：CQ（Constant Quality）：固定画质，动态调整码率。VBR（Variable Bitrate）：固定码率，动态调整画质。
• 示例流程：
• plaintext
• 1. 接收到速率控制的可用带宽上限500kbps 2. 码率控制器决定： - 分辨率：720p → 360p - 帧率：30fps → 15fps - 编码器QP值：28 → 35（画质降低）
• 
  

三、协同工作流程

plaintext

网络状态变化（如丢包率上升） → 速率控制（降低总发送速率） → 码率控制（调整编码器参数） → 输出媒体流

• 强依赖关系：码率控制必须服从速率控制的带宽限制，否则会导致网络拥塞加剧。
• 动态平衡：速率控制侧重网络稳定性，码率控制侧重视觉体验，两者需协同优化。

四、常见误解澄清

1. 速率控制 ≠ 码率控制

• 速率控制关注的是网络出口总速率（包括媒体、重传、控制包），而码率控制仅针对编码器输出的媒体流。
• 示例：当网络拥塞时，速率控制可能将总速率限制为 500kbps，其中媒体流占 400kbps，重传包占 100kbps。

2. 带宽估计是基础

• 速率控制和码率控制都依赖准确的带宽估计。若 BWE 算法高估带宽，会导致拥塞；低估则浪费网络资源。

3. 弱网场景下的优先级

• 速率控制优先保证连接存活（避免丢包率过高导致连接中断）。
• 码率控制在有限带宽内，优先保证视频流畅度（如降低分辨率而非帧率）。

五、优化方向

1. 速率控制优化

• 改进 BWE 算法（如基于机器学习预测带宽变化）。
• 多路径传输（如同时使用 Wi-Fi 和 4G，提升稳定性）。

2. 码率控制优化

• 智能分层编码（如 SVC/AV1，优先传输基础层）。
• 动态帧率调整（弱网时降低帧率而非分辨率，保持流畅感）。

六、总结

理解两者的区别与协作机制，是解决 WebRTC 实时通信中 “卡顿”“模糊”“花屏” 等问题的关键。