有奖小调查

3 分钟回答 几 个小问题,让内容更符合你的 WebRTC 学习与开发期望。
每个月最后一天会随机抽出 5 名获奖者,并通过邮件联系送上奖品。
填写问卷

TCP中服务器WebRTC的通道质量指标(一)

发布和播放

在流视频领域,WebRTC服务器端有两个主要功能:发布和播放。需要发布时,WebRTC从网络摄像机捕获视频流,并将其从浏览器移动到服务器。需要播放时,视频流从服务器移动到浏览器,在设备浏览器的HTML5的“video”进行解码,然后播放。

UDP和TCP

视频可以通过两种传输协议(即TCP或UDP)移动。用UDP协议的话,NACK RTCP反馈会主动工作,并携带丢失数据包的相关信息,这使得检测UDP信道恶化非常简单,即对NACK(Negative ACK)进行计数以确定质量。NACK和PLI(Picture Loss Indicator)反馈越多,实际损耗就越多,信道质量也越低。

没有NACK的TCP

本文重点讨论TCP协议。在TCP上使用WebRTC时不会发送NACK RTCP反馈。即使发送了NACK RTCP反馈,也无法反映损耗的真实情况,所以我们无法通过反馈来确定信道质量。但众所周知,TCP是可以保证传递的传输协议。因此,我们会通过TCP发送网络中的其余数据包以防信道质量下降。这些数据包迟早会被交付,但这些损失不会导致NACK的产生,因为实际上并没有损失。所以,这些数据包会延迟到达目的地,且他们根本不会聚集到视频帧中,只会被拆包器丢弃。所以用户会看到些许失真的图片,如下图所示。

但同时,反馈显示一切正常。下图中包含Wireshark流量的截图,显示了在压缩的TCP和UDP通道上发布的视频流的走向。Google Chrome数据截图在下图中也有所展示。通过这些截图您可以看到:即使信道状态非常糟糕,TCP中的NACK指标也不会像在UDP中那样剧增。

TCP

UDP

如果UDP更好,为什么还要通过TCP进行流传输?

这个问题很好。答案是:我们需要TCP来推动更高的分辨率。比如在进行VR(虚拟现实)流传输时,分辨率可能为4k,不可能把这种分辨率和约10 Mbps比特率的流无损地推送到常规信道中。这时服务器会拒绝接收UDP数据包,然后把这些数据包成包丢弃在网络中,再把剩下的数据包发送。长此以往,大量废弃的视频数据包会破坏视频,最终导致视频质量很差。这就是为什么我们要使用TCP上的WebRTC,通过WebRTC在通用网络中以高分辨率(如Full HD和4k)传送视频以减少网络中数据包丢失的情况。这样做我们只会有一点通信延迟,事半功倍。

RTT用于确定信道质量

因此,没有指标能百分百显示信道的不良状态。一些开发人员试图依靠RTT指标,但是它不能在所有浏览器中使用,且无法给出准确的结果。

下图展示了基于callstat项目的信道质量对RTT的依赖性。

原文地址:https://flashphoner.com/channel-quality-indicator-for-server-webrtc-over-tcp/

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营