码率控制与闭环 · 估计怎么变成画质
带宽估计的终点，是把「网络能承受多少」变成「编码器该编多清晰」。这一章讲清 GoogCC 的输出 NetworkControlUpdate 怎么流向编码器与 pacer、目标码率如何在多条流间分配的引子，以及整个拥塞控制闭环怎么每隔几十毫秒转一圈。收尾第 5 部分。
码率控制与闭环 · 估计怎么变成画质
第 5 部分前面讲了怎么估带宽（延迟、丢包、探测）、怎么发（pacing、窗口）。这最后一章把它们收成一个闭环，并回答：估出的那个数字，最终怎么变成用户看到的画质？
输出：NetworkControlUpdate
GoogCcNetworkController 每处理一次反馈（OnTransportPacketsFeedback），产出一个 NetworkControlUpdate——它是拥塞控制的决策书，主要内容：
- 目标码率（target bitrate） —— “综合延迟 / 丢包估计取小、探测、窗口回压后，现在该用多少码率”。
- pacing 速率 —— 交给 pacer 的放行速率。
- 拥塞窗口 —— 交给窗口控制器的在途上限。
这个 update 顺着 RtpTransportControllerSend（第 9 部分）分发给各执行端：pacer 拿到新的放行速率，而目标码率流向最终的消费者——编码器。
目标码率 → 编码器 → 画质
目标码率的终点，是告诉编码器“你有多少带宽预算，请把画质 / 帧率编到这个预算之内”。 这是拥塞控制闭环的出口：网络能承受 2 Mbps，就让视频编码器按 2 Mbps 编——分辨率、帧率、量化参数据此调整。带宽宽裕 → 高清高帧率；带宽紧张 → 降分辨率 / 降帧率保流畅。“网络状况”就这样一路传导成了“用户看到的画质”——这是视频管线自适应（第 6 部分）的输入，也是整个 WebRTC 体验的关键传导链。
中间还有一步分配：一次通话可能有多条流（音频、视频、联播的多档），总目标码率要在它们之间分配——音频优先保住（语音比画面重要）、剩下的给视频。这活儿由 BitrateAllocator（第 9 部分）做，是连接“总带宽”和“每条流码率”的桥。这里先记住：拥塞控制给出总预算，分配器再把预算分到各条流的编码器。
完整闭环
把整个第 5 部分（和它与第 4、第 6 部分的连接）收成一张闭环图：
小结与第 5 部分回顾
码率控制是拥塞控制的出口：GoogCcNetworkController 产出 NetworkControlUpdate（目标码率 / pacing 速率 / 窗口），目标码率经 BitrateAllocator（第 9 部分）分配到各流的编码器，转化成画质 / 帧率。整个系统是一个每几十毫秒转一圈的闭环：发包→反馈→估带宽→定码率→调编码→再发包。
第 5 部分「拥塞控制」到此完整：总览（GoogCC 双控制器） → 延迟based（trendline/过载） → 丢包based → 探测 → pacing → 拥塞窗口 → 码率控制闭环。WebRTC 怎么“聪明地决定发多快”已经讲透。
目标码率交到了编码器手里——那编码器、以及整条视频管线（采集、编码、发送、接收、抖动缓冲、解码、渲染）是怎么运转的？第 6 部分进入 video/ 和 modules/video_coding/。👉 第 6 部分即将展开。
参考资料
- [1] libwebrtc 源码.
api/transport/network_control.h（NetworkControlUpdate）、goog_cc_network_control.cc（产出决策）。 - [2] libwebrtc 源码.
call/rtp_transport_controller_send.h（分发决策）、call/bitrate_allocator.h（码率分配，第 9 部分）。 - [3] IETF「GoogCC」draft —— 完整算法。