即时通讯实时视频聊天技术提供QoS保证的方法

Posted 2023-03-23 weikeyuncn

随着WebRTC标准的逐步推广，实时音视频通讯技术受到越来越多公司和技术人员的关注。

 

对于交互式音视频应用而言，稳定、低延时、通话质量清晰可靠是其基本需求。在互联网环境下，音视频的通话质量与以下因素有关：一是编码码率、帧率和分辨率等编码因素；二是网络的接入类型和接入设备性能；三是对丢包、抖动、乱序以及网络拥塞的自适应调整能力，即QoS（Qualityof Service，服务质量）。

交互式实时视频应用通常采用RTP协议进行音视频传输，RTP头部提供了诸如负载类型、时间戳、序列号和同步源等信息保证基本的音视频传输需求。但与TCP不同，RTP协议底层采用不可靠的UDP传输层协议，当网络过载或拥塞，无法实现对丢包、抖动、乱序以及网络拥塞的自适应调整。与音频相比，视频传输由于所占的带宽更大，更易受到网络环境变化的影响，因此以下将以视频为例分析Qos提升途径。

对与实时视频来说，网络出现丢包将直接导致接收端画面出现马赛克和花屏。有多种策略可以解决，包括：基于NACK反馈的丢包重传，前向纠错FEC和参考帧选择RPS，这些策略通常与编解码端的容错技术（如：帧内刷新和错误隐藏）配合使用。

基于NACK反馈的丢包重传方法：接收端循环检查接收缓冲，当发现丢包后使用RTCPNACK反馈报文将丢包信息反馈给发送端；发送端接收NACK反馈并解析后从发送缓存取出对应RTP包，并再次发送给接收端。该方法的缺点是增大了端到端的延迟，尤其在丢包大量发生时更为明显。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

前向纠错FEC：FEC机制是在接收端根据视频帧的重要性（参考帧或非参考帧）发送冗余的视频RTP包，在接收端如果检测到丢包则利用冗余包进行恢复，否则将冗余包丢弃。该方法的优点是视频无延迟，但发送冗余包占用了额外的带宽资源。

更为可行的方案是是混合NACK／FEC模式，接收端根据帧大小和接收时延估计可用带宽，发送端根据可用带宽、丢包和RTT等反馈计算分配保护开销（protectionoverhead，包括FEC bitrate、NACK bitrate）和视频编码码率各占的比率。具体来说，FEC的保护级别（protectionlevel）取决于往返时间RTT，当RTT较小时，丢包重传的延时不会导致明显的视频卡顿，因此可以相应减少FEC包的数量；当RTT较大时，时延对视频流畅度影响明显，因此要相应增加FEC包的数量。此外，可以使用多帧FEC和结合时域分层信息的FEC，二者都可以在减小保护开销的同时，提供更低的渲染抖动、更低的端到端延迟和更高的视频质量。

拥塞控制技术的提出由来已久，TCP协议栈默认实现了对网络的拥塞控制以保证可靠传输。但在一些场合TCP并不适用，如：无线传输信道，高速长距传输网络、实时通讯应用等。为此，IETFRMCAT（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值通过RTC PREMB反馈到发送端，发送端最终的目标码率应不超过remb值。

关键帧也叫做即时刷新帧，简称IDR帧。对视频来说，IDR帧的解码无需参考之前的帧，因此在丢包C严重时可以通过发送关键帧请求进行画面的恢复。关键帧的请求方式分为三种：RTCPFIR反馈（Full intra frame request）、RTCPPLI反馈（Picture Loss Indictor）或SIPInfo消息，具体使用哪种可通过协商确定。

即时通讯开发之实时音视频技术的整体架构

WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音通话或视频聊天的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。

WebRTC提供了实时音视频的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。

虽然WebRTC的目标是实现跨平台的Web端实时音视频通讯，但因为核心层代码的Native、高品质和内聚性，开发者很容易进行除Web平台外的移殖和应用。很长一段时间内WebRTC是业界能免费得到的唯一高品质实时音视频通讯技术。

WebRTC（Web Real-Time Communication）项目的最终目的主要是让Web开发者能够基于浏览器（Chrome\\FireFox\\…）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序即可实现。

W3C等组织正在制定Javascript 标准API，目前是WebRTC 1.0版本、Draft状态。

另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台，形成开发者与浏览器厂商良好的生态环境。同时，Google也希望和致力于让WebRTC的技术成为HTML5标准之一，可见Google布局之深远。

WebRTC架构组件介绍

1Your Web App

Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。即时通讯聊天软件app开发可以加蔚可云

2Web API

面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用，最新的标准化进程可以查看这里。

3WebRTC Native C++ API

本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。

4Transport / Session

传输/会话层：会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议。

- a.  RTP Stack协议栈：Real Time Protocol；
- b.  STUN/ICE：可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接；
- c.  Session Management：一个抽象的会话层，提供会话建立和管理功能。该层协议留给应用开发者自定义实现。

5VoiceEngine

音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个解决方案。

VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先。

a. iSAC
Internet Speech Audio Codec：针对VoIP和音频流的宽带和超宽带音频编解码器，是WebRTC音频引擎的默认的编解码器。

    采样频率：16khz，24khz，32khz；（默认为16khz）
    自适应速率为10kbit/s ~ 52kbit/；
    自适应包大小：30~60ms；
    算法延时：frame + 3ms

b. iLBC
Internet Low Bitrate Codec：VoIP音频流的窄带语音编解码器。标准由IETF RFC3951和RFC3952定义。

    采样频率：8khz；
    20ms帧比特率为15.2kbps
    30ms帧比特率为13.33kbps

c. NetEQ for Voice
针对音频软件实现的语音信号处理元件。NetEQ算法：自适应抖动控制算法以及语音包丢失隐藏算法。使其能够快速且高解析度地适应不断变化的网络环境，确保音质优美且缓冲延迟最小。是GIPS公司独步天下的技术，能够有效的处理由于网络抖动和语音包丢失时候对语音质量产生的影响。

NetEQ 也是WebRTC中一个极具价值的技术，对于提高VoIP质量有明显效果，加以AEC\\NR\\AGC等模块集成使用，效果更好。

d. Acoustic Echo Canceler (AEC)
回声消除器是一个基于软件的信号处理元件，能实时的去除mic采集到的回声。

e. Noise Reduction (NR)
噪声抑制也是一个基于软件的信号处理元件，用于消除与相关VoIP的某些类型的背景噪声（嘶嘶声，风扇噪音等等… …）

6VideoEngine

WebRTC视频处理引擎：VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

a. VP8
视频图像编解码器，是WebRTC视频引擎的默认的编解码器。VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。

VPx编解码器是Google收购ON2公司后开源的，VPx现在是WebM项目的一部分，而WebM项目是Google致力于推动的HTML5标准之一。

b. Video Jitter Buffer
视频抖动缓冲器，可以降低由于视频抖动和视频信息包丢失带来的不良影响。

c. Image enhancements
图像质量增强模块：对网络摄像头采集到的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。