我想知道这条 SDP 线的含义是什么，因为我试图在 5% 到 10% 的数据包丢失情况下获得最平滑的帧速率。
我不知道的行是： a=rtcp-fb:100 goog-remb a=rtcp-fb:100 transport-cc
我不知道为什么firefox（例如）正在删除“transport-cc”功能，即使我必须解码不完整的视频帧，我是否也想让流帧率平滑？
最好的问候，我希望有人可以帮助我:)
问问题
5611 次
2 回答
9
Gustavo García 写了一篇关于此的博客文章，称为WebRTC 中的带宽估计（以及新的 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 质量差），拥塞控制算法只会降低质量而不会改善解码失败.
于 2017-11-07T17:51:36.540 回答
1
google-remb 和 transport-cc 只能处理拥塞，如果你想获得 5% 到 10% 丢包率的最平滑帧率，你必须区分不同的情况：
- 网络拥塞导致的丢包
使用联播或 svc 空间可扩展性，选择低分辨率
- 由于wifi设备或其他原因导致的固定数据包丢失
使用 nack 和 fec，增加冗余
于 2018-05-22T01:57:02.083 回答