Google chrome 如何在WebRTC视频录制中使用PLI数据包

我们正在使用MCU将视频从Google Chrome传输到服务器并录制。这里棘手的部分是，只涉及一个Chrome浏览器，因此服务器端必须处理向客户端发送反馈的问题

我们添加了服务器端，每5秒向客户端发送REMB（带宽）数据包。这会导致客户端提高比特率，从而使视频质量良好

我们对PLI数据包做了一些尝试，以提高视频质量。录制的视频有块状瑕疵，看起来不太好。当前代码每0.8秒发送一个PLI，这会导致客户端发送一个关键帧（视频的完整帧）。这修复了视频质量差的问题，因为它强制执行关键帧，但当出现数据包丢失（wifi网络）时，它会很快再次变差

我的问题是这些PLI数据包应该如何使用

我认为物价指数的意思是：

PLI    - Picture Loss Indication

---

您的应用程序应至少发送三种RTCP反馈：

• 每秒左右一次准确的接收器报告（RFC3550），向发送方指示数据包丢失和抖动率；这将导致发送方根据链路特性调整其吞吐量
• 一个通用NACK（RFC 4585），每当它错过一个数据包时；这将通过使发送方重新发送丢失的任何数据包来避免损坏
• 当PLI（RFC 4585）在给定的时间间隔（例如两秒）内没有看到关键帧时

---

只有当吞吐量增长过快时，才需要发送REMB来限制吞吐量，例如，如果接收器报告中提供的反馈不准确。

您可能需要尝试传统的FIR rtcp请求。PLI是特定于负载的，尽管它应该可以工作，但我发现它在某些情况下不起作用。我只是想知道这是不是正确的使用方法。您能解释一下“特定于负载”的含义吗？PLI不是标准RTCP数据包类型，它与媒体负载具体相关。但是，PLI应该为您提供一个带有vp8的新关键帧。此外，每0.8秒就有大量关键帧。为什么需要发送REMB来增加带宽？如果网络支持，chrome中的Webrtc在一段时间内自然会上升到2MB/s。（和的源）PLI数据包确实正在创建关键帧。我们这样做是为了解决我们看到的视频质量差的问题。那NACK包呢？从我所读到的内容来看，这是接收器应该如何处理数据包丢失，但我无法让客户端注册从服务器发送的NACK。我们注意到，对于带有一个Chrome浏览器的licode MCU，除非服务器发送REMB数据包，否则不会增加服务器带宽。