通过即时通讯和实时视频聊天技术提供服务质量保证的方法

时间:2020-10-20

videobridge

 通过即时消息和实时视频聊天技术提供服务质量保证的方法

 随着WebRTC标准的逐步推广,越来越多的公司和技术人员开始关注实时音视频通信技术。

 对于交互式音频和视频应用,稳定性、低延迟和清晰可靠的通话质量是基本要求。在互联网环境中,音频和视频通话质量与以下因素有关:第一,编码因素,如编码率、帧速率和分辨率;二是网络的接入类型和接入设备的性能;第三是自适应调整分组丢失、抖动、混乱和网络拥塞的能力,即服务质量。

 本文主要介绍音视频传输和处理中保证服务质量的关键技术。

 基本介绍

 交互式实时视频应用通常使用实时传输协议进行音频和视频传输。RTP报头提供诸如负载类型、时间戳、序列号和同步源等信息,以确保基本的音频和视频传输要求。然而,与TCP不同的是,RTP协议的底层采用不可靠的UDP传输层协议,当网络过载或拥塞时,协议无法自适应地调整丢包、抖动、无序和网络拥塞。与音频相比,视频传输占用更多的带宽,并且更容易受到网络环境变化的影响。因此,下面将以视频为例来分析提高Qos的方法。

 如何处理丢包?

 对于实时视频,网络上的丢包会直接导致接收端的马赛克和花屏。有许多策略可以解决,包括基于NACK反馈的丢包重传、前向纠错FEC和参考帧选择RPS。这些策略通常与编解码器的容错技术(如帧内刷新和错误隐藏)结合使用。

 一种基于NACK反馈的丢包重传方法,包括以下步骤:接收端循环检查接收缓冲区,当发现丢包时,使用RTCPNACK反馈消息向发送端反馈丢包信息;发送端接收并分析NACK反馈,然后从发送缓冲区中取出相应的实时传输包,并再次发送给接收端。这种方法的缺点是增加了端到端的延迟,特别是当大量的数据包丢失时。

 前向纠错:前向纠错机制是指在接收端根据视频帧(参考帧或非参考帧)的重要性发送冗余的视频传输包。如果在接收端检测到分组丢失,冗余分组将被恢复,否则冗余分组将被丢弃。这种方法的优点是视频没有延迟,但是发送冗余数据包会占用额外的带宽资源。

 更可行的方案是混合NACK/前向纠错模式,其中接收器根据帧大小和接收延迟来估计可用带宽,发送器根据可用带宽、分组丢失和RTT的反馈来计算分配的保护开销(包括前向纠错比特率和NACK比特率)和视频编码率的比率。具体来说,对外直接投资的保护水平取决于RTT的往返时间。当RTT较小时,丢包重传的延迟不会造成明显的视频干扰,因此可以相应减少前向纠错包的数量。当RTT较大时,延迟对视频流畅性有明显的影响,因此FEC包的数量应相应增加。此外,可以使用多帧FEC和结合时域分层信息的FEC,这两者都可以提供更低的渲染抖动、更低的端到端延迟和更高的视频质量,同时减少保护开销。

 拥塞控制和自适应带宽调整

 拥塞控制技术提出已久,而TCP协议栈默认实现网络拥塞控制以保证可靠传输。然而,在某些场合,如无线传输信道、高速长距离传输网络、实时通信应用等,TCP是不适用的。为此,即时通信媒体拥塞避免技术工作组提出了一系列实时通信应用的拥塞控制算法要求,包括:有效控制端到端时延,有效控制丢包,与其他应用流共享链路带宽,与TCP长连接流公平竞争可用链路带宽。谷歌、思科、爱立信和其他公司已经为实时交互应用提出了自己的拥塞控制算法。开源项目WebRTC的内部实现采用了谷歌提出的算法:谷歌拥塞控制(简称GCC)。

 GCC算法是一种基于丢包和时延的混合方法,其原理如下:

 发送方根据丢包率调整目标带宽,具体为:当丢包率较低(小于2%)时,目标码率增加;当丢包率高于10%时,目标码率保持不变;

 接收机根据时延估计最大带宽,它由三个模块组成:排队时延估计、链路过载检测和最大带宽估计。这三个模块之间的关系是:当排队时延小于阈值时(根据网络状态自适应调整),链路检测结果未被充分利用;;当排队延迟大于阈值时,链路检测结果被过度使用;;当介于两者之间时,链路检测结果正常;;最大带宽估计模块的实现是表示当前链路状态(增加、保持和减少)的有限状态机。初始状态为保持,根据链路检测结果迁移状态,根据迁移的链路状态和当前接收码率估计最大带宽remb。

 以上两个过程的结合:接收方计算的remb值通过RTC Premb反馈给发送方,发送方的最终目标码率不应超过remb值。

 关键帧请求

 关键帧也称为即时刷新帧,简称IDR帧。对于视频,IDR帧的解码不需要参考前一帧,所以当丢包严重时,可以通过发送关键帧请求来恢复图像。请求关键帧有三种方式:RTCPFIR请求、RTCPPLI反馈或SIPInfo消息,这可以通过协商来确定。

 补充

 除了上述方法之外,视频预处理模块还可以分析视频内容,例如运动复杂度和纹理复杂度,并且可以与拥塞控制模块一起调整自适应帧速率和自适应分辨率。

 综上所述,为互联网上的实时互动音视频应用提供服务质量保障仍然是一个挑战,这需要音视频编码器、传输、预处理等多模块的配合,或者需要现有网络协议和设备的支持,为客户提供更多的选择和服务保障。