不能在SFU侧直接复用GoogCcNetworkController，因其本质是发送端行为，需控制发包、pacing、probe等，而SFU仅转发RTP包，无发送队列、不生成时间戳、不参与拥塞反馈闭环。
直接结论：不能在 SFU 侧直接复用 WebRTC 发送端的 GoogCcNetworkController 做拥塞控制，但可以通过接收端反馈（REMB 或 Transport-CC）驱动 SFU 的码率决策逻辑，再结合 Simulcast 或 AV1 SVC 层级切换实现动态码率自适应。
为什么 SFU 不能自己做拥塞控制？
WebRTC 的拥塞控制（如 GCC）本质是发送端行为——它需要精确控制发包时机、重传、 pacing、probe 等，而 SFU 只转发 RTP 包，不生成也不修改时间戳、不参与 pacing，也没有自己的发送队列。强行在 SFU 中注入 RtpTransportControllerSend 会导致：
- 时序错乱：
abs-send-time和transport-wide-cc扩展头被透传后，发送端无法识别真实路径延迟 - 反馈污染：多个下游客户端的
REMB或TCC报文混在一起，SFU 无法区分哪路反馈对应哪条上行链路 - 状态分裂：每个
MediaStreamTrack在 SFU 内部没有独立的NetworkStateEstimate实例，无法维持 per-recipient 拥塞视图
怎么用 RTCP 反馈驱动 SFU 码率决策？
真正可行的做法是：让每个下游客户端（receiver）持续上报其网络质量，SFU 解析并聚合这些反馈，再决定向该 client 转发哪一层视频流。关键依赖以下机制：
-
REMB报文需携带ssrc和estimated_max_bitrate_bps，SFU 按接收者维度缓存最近 3–5 秒的值，剔除突变异常点后取滑动平均 -
Transport-CC更优：它带每包到达时间戳（arrival_time_ms），SFU 可本地计算单向延迟梯度（inter-arrival jitter），比 REMB 更敏感 - 必须绑定
ssrc到具体RemoteVideoTrack实例，否则无法映射到对应转码/转发策略 - 避免直接使用原始
acked_bitrate：它反映的是上行链路能力，而 SFU 下发的是下行流，需反向折算（例如：若 client 上报 1.2 Mbps REMB，且你有 720p@2.5Mbps 和 480p@1.0Mbps 两层，则选后者）
如何在 C++ SFU 中接入并触发码率切换？
以 Licode 或 mediasoup 的 C++ 后端为例（非 JS 层），核心是监听 RTCP 并更新 track 的 target layer：
- 在
OnRtcpPacket回调中识别RTCP_RTPFB子类型为RTCP_RTPFB_REMB或RTCP_PSFB_TCC，提取bitrate_bps和ssrc - 查表获取对应
Consumer实例，调用其SetMaxBitrate()或RequestKeyFrame()接口（注意：不是改 encoder，而是通知转发器切层） - 若使用
Simulcast，需预先在 offer 中协商多组ssrc，SFU 根据目标码率选择转发其中一路；若用AV1 SVC，则通过scalability_mode字段和 temporal/spatial layer index 控制 - 切层必须带防抖：两次请求间隔不得小于 1s，且新层分辨率变化超过 30% 时应插入 FIR 请求关键帧，避免花屏
容易忽略的底层细节
实际落地时，最常出问题的地方不在算法逻辑，而在数据对齐和生命周期管理：
-
REMB中的ssrc是 receiver 的 video ssrc，但 SFU 内部可能把多个 sender 映射到同一组接收 ssrc（尤其在混合流场景），必须确保ssrc绑定到具体 consumer 而非 transport - Transport-CC 的
base_sequence_number和packet_status_count需按接收者单独解码，跨 consumer 复用解析器会丢包计数错乱 - Linux 上高并发时，RTCP 包可能被内核 UDP buffer 截断（默认 212992 字节），需调大
net.core.rmem_max，否则TCC大包丢失导致拥塞误判 - 不做 NTP 时间戳校准的话，不同 client 的
arrival_time_ms无法横向比较——SFU 必须用本地 monotonic clock 对齐所有接收时间
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
