阅读 2158

WebRTC SFU中发送数据包丢失反馈

WebRTC SFU的职责之一是接收和发送RTCP数据包。RTCP数据包包括关于音频和视频流的不同类型的反馈,并且最重要的RTCP数据包是接收器报告(RR).

RR数据包从媒体流接收器发送到该媒体流的发送者。在SFU的情况下,RR由SFU产生,并发送到媒体流发送器,并且还从每个流接收器发送到SFU。(如图1)。

RR数据包内发送的反馈包括用于计算网络引入的往返时间延迟,抖动和信息丢失。

这些RR数据包中报告的数据包丢失很重要,因为发送的音频和视频将根据该参数进行调整:

在音频流的情况下,网络中的数据丢失修改了OPUS编解码器的强度级别。在存在很多数据丢失的情况下,发送器增加包括在音频分组中的前向纠错(FEC)的冗余级别。 在视频流的情况下,数据丢失修改编码和发送的视频比特率。在存在大量数据丢失的情况下,发送方降低发送比特率以减少网络中可能的拥塞。 基于该行为,问题是……SFU如何计算从SFU发送到发送方的RR报文中报告的丢包,以获得最佳用户体验?

在接下来的部分,您可以找到有关如何在三种不同类型流中处理此问题的建议:音频,带有联播的视频,和没有联播的视频。

音频

Opus FEC是带内发送的,因为FEC是端到端的(不能在SFU中添加/更新),并且会议室中的每个人将获得相同等级的FEC。

如果我们希望音频FEC能够很好地为具有最弱链接的参与者工作,那么我们必须确保向发送方报告最糟糕的数据包丢失。

因此,从SFU向发送方报告的丢包应该是接收方的较差分组(max(PL1, PL2)).

例如,如果其中一个接收参与者在下行链路中遇到20%的数据丢失,则报告给发送方的数据丢失将会是20%,即使发送方和其余接收方处于完美的网络状态。

带有联播的视频

使用联播时,SFU能够向每个参与者发送不同的视频质量,因此不需要使发送流适应任何特定参与者。

因此,从SFU向发送方报告的丢包应该是该链路(发送方-SFU)的丢包,无论收到的丢包是什么,对于接收方1和2都是如此。

例如,如果发送方上行链路良好,即使接收方在下行链路中遇到大量丢包,报告给发送方的丢包也将为0.通过选择要转发给那些参与者的较低分辨率/层,可以通过在SFU中完成的重新传输和比特率自适应来纠正这一点。

无联播的视频

无联播时,SFU必须向每个参与者发送相同的视频质量。因此,发送者使用最弱的链接调整发送比特率并发送给参与者(和/或禁用某些参与者的视频)。

该比特率自适应主要由REMB RTCP数据控制,其中SFU包括在较差接收器中可用的带宽。但是丢包也会对REMB数据包中报告的比特率产生影响,因此我们需要确定要在RR数据包中包含哪些数据包丢失。

在这种情况下,我认为前面几节中描述的两种方法都可以很好的工作。或者a)SFU报告最差的接收器的丢包率,或者b)使用每个接收器的丢包估其带宽,并仅报告RR数据包中的发送方一侧丢包。

注意:如果您在房间中有2个参与者时使用P2P连接,并且当房间中有3个或更多参与者时,切换到具有联播的SFU,那么你应该从不在此视频中使用No-Simulcast和多个参与者案例。

本文首发于由声网 Agora 赞助运营的 WebRTC 中文网

关注下面的标签,发现更多相似文章
评论