深入分析提升用户体验的关键技术：实时视频
作者：袁丽蓉
打马赛克就是因为内容不和谐吗？未必！实时视频中的马赛克和花屏可能是网络出现丢包啦，本文为您分析提升实时视频用户体验的关键技术。
随着WebRTC 标准的逐步推广,实时音视频通讯技术受到越来越多公司和技术人员的关注。对于交互式音视频应用而言,稳定、低延时、通话质量清晰可靠是其基本需求。在互联网环境下,音视频的通话质量与以下因素有关:一是编码码率、帧率和分辨率等编码因素; 二是网络的接入类型和接入设备性能;三是对丢包、抖动、乱序以及网络拥塞的自适应调整能力,即QoS(Quality of Service,服务质量)。容联云通讯作为国内最早且通讯能力最全的 PaaS服务商,在推出音视频通话这一关键能力时,更加注重保证QoS(Quality of Service, 服务质量), 升用户体验。本文主要介绍为保证QoS,在音视频传输和处理过程中采用的关键技术。
交互式实时视频应用通常采用RTP 协议进行音视频传输,RTP 头部供了诸如负载类型、时间戳、序列号和同步源等信息保证基本的音视频传输需求。但与TCP 不同,RTP 协议底层采用不可靠的 UDP 传输层协议,当网络过载或拥塞,无法实现对丢包、抖动、乱序以及网络拥塞的自适应调整。与音频相比,视频传输由于所占的带宽更大,更易受到网络环境变化的影响,因此以下将以视频为例分析Qos 升途径。
1、处理丢包
对与实时视频来说,网络出现丢包将直接导致接收端画面出现马赛克和花屏。有多种策略可以解决,包括:基于NACK 反馈的丢包重传,前向纠错
FEC 和参考帧选择RPS,这些策略通常与编解码端的容错技术(如:帧内刷新和错误隐藏)配合使用。
基于NACK 反馈的丢包重传方法:接收端循环检查接收缓冲,当发现丢包后使用RTCP NACK 反馈报文将丢包信息反馈给发送端;发送端接收NACK 反馈并解析后从发送缓存取出对应RTP 包,并再次发送给接收端。该方法的缺点是增大了端到端的延迟,尤其在丢包大量发生时更为明显。
前向纠错FEC:FEC 机制是在接收端根据视频帧的重要性(参考帧或非参考帧)发送冗余的视频RTP 包,在接收端如果检测到丢包则利用冗余包进行恢复,否则将冗余包丢弃。该方法的优点是视频无延迟,但发送冗余包占用了额外的带宽资源。
更为可行的方案是是混合NACK/FEC 模式,接收端根据帧大小和接收时延估计可用带宽,发送端根据可用带宽、丢包和RTT等反馈计算分配保护开销(protection overhead,包括 FEC bitrate、NACK bitrate)和视频编码码率各占的比率。具体来说,FEC 的保护级别(protection level)取决于往返时间RTT,当RTT较小时,丢包重传的延时不会导致明显的视频卡顿,因此可以相应减少FEC 包的数量;当RTT 较大时,时延对视频流畅度影响明显, 因此要相应增加FEC 包的数量。此外,可以使用多帧FEC 和结合时域分层信息的FEC,二者都可以在减小保护开销的同时, 供更低的渲染抖动、更低的端到端延迟和更高的视频质量。
2、拥塞控制与自适应带宽调整
拥塞控制技术的出由来已久,TCP 协议栈默认实现了对网络的拥塞控制以保证可靠传输。但在一些场合TCP 并不适用,如:无线传输信道,高速长距传输网络、实时通讯应用等。为此,IETF RMCAT(RTP Media Congestion Avoidance Techniques)工作组出了一系列针对实时通讯应用的拥塞控制算法需求,包括:能有效控制端到端时延、能有效控制丢包、与其他应用的流
共享链路带宽、能够与TCP 长连接流公平竞争可用链路带宽等。Google、Cisco 和 Ericsson 等公司相继出了各自的适用于实时交互应用的拥塞控制算法,开源工程WebRTC 的内部实现采用Google 出的算法:Google Congestion Control,简称 GCC。
GCC 算法是一种混合了基于丢包和基于时延的方法,原理如下:
发送端根据丢包调整目标带宽,具体来说:低丢包率(小于2%)时增加目标码率, 高丢包率(大于10%)时减小目标码率,丢包率介于二者之间时目标码率保持不
变;接收端根据时延估计最大带宽,由三个模块组成:排队时延估计、链路过载检测和
最大带宽估计模块,三个模块间的关系为:当排队时延小于阈值(根据网络状态自适应调整)时,链路检测结果为underuse;当排队时延大于阈值时,链路检测结果为 overuse;介于二者之间时,链路检测结果为normal;最大带宽估计模块的实现是一个表示当前链路状态(Increase、Hold、Decrease)的有限状态机,初始状态为Hold,根据链路检测结果进行状态迁移,并根据迁移后的链路状态和当前接收码率估计最大带宽remb。
上述两个过程的结合之处:接收端计算的remb 值通过RTCP REMB 反馈到发送端,发送端最终的目标码率应不超过remb 值。
3、关键帧请求
关键帧也叫做即时刷新帧,简称IDR 帧。对视频来说,IDR 帧的解码无需参考之前的帧, 因此在丢包 C 严重时可以通过发送关键帧请求进行画面的恢复。关键帧的请求方式分为三种: RTCP FIR 反馈(Full intra frame request)、RTCP PLI 反馈(Picture Loss Indictor)或SIP Info 消息,具体使用哪种可通过协商确定。
4、其他除上述几种方法外,还可以通过视频预处理模块对视频内容进行
分析,如:运动复杂程度、纹理复杂程度等,与拥塞控制模块一起进行自适应帧率和自适应分辨率的调整。
综上所述,在互联网上为实时交互式音视频应用供QoS 保证仍是一项挑战,需要音视频编码器、传输、预处理等多模块的协作配合,或利用现有网络协议和设备的支持,才能供给客户更多的选择和服务保证。
