【发布时间】：2017-11-14 23:58:12
【问题描述】：
我想知道这条 SDP 线的含义是什么，因为我试图在 5% 到 10% 的数据包丢失情况下获得最平滑的帧速率。
我不知道的行是： a=rtcp-fb:100 goog-remb a=rtcp-fb:100 传输-cc
我不知道为什么 firefox（例如）正在删除“transport-cc”功能，即使我必须解码不完整的视频帧，我是否也想让流帧率平滑？
最好的问候，我希望有人可以帮助我:)
【问题讨论】：
【发布时间】：2017-11-14 23:58:12
【问题描述】：
Gustavo García 就此写了一篇名为 Bandwidth Estimation in WebRTC (and the new Sender Side BWE) 的博文。
总结一下：goog-remb 和 transport-cc 都是拥塞控制机制，goog-remb 是旧方法，transport-cc 是新方法。
我的最佳猜测是 firefox 正在剥离 transport-cc，因为 firefox 尚未采用 transport-cc 更改。根据我的经验，Chrome 在 webrtc 的变化上总是领先于 Firefox。
在有损网络中，这些拥塞控制算法可以告诉发送方降低发送比特率。降低发送比特率可以减少损失（以牺牲质量为代价）。但是，如果网络始终有 10% 的损耗，例如嘈杂的 WiFi 网络，您仍然可能会遇到视频帧解码问题。
处理视频解码失败是 vp8/h264 视频编码参数的功能，而不是拥塞控制。正如我所说，拥塞控制可能有助于减少丢失（如果您的网络被 WebRTC 数据包淹没），但如果您只有一个有损网络（例如，wifi 质量差），拥塞控制算法只会降低质量而不会改善解码失败.
【讨论】：
google-remb 和 transport-cc 只能处理拥塞，如果你想在 5% 到 10% 丢包率的情况下获得最平滑的帧率，你必须区分不同的情况：
- 由于网络拥塞导致的数据包丢失
使用联播或svc空间可扩展性，选择低分辨率
- 修复了由于 wifi 设备或其他原因导致的丢包问题
使用nack和fec，增加冗余
【讨论】：