目录

在互联网环境下，音视频的通话质量与以下因素有关：

一是编码码率、帧率和分辨率等编码因素；

二是网络的接入类型和接入设备性能；

三是对丢包、抖动、乱序以及网络拥塞的自适应调整能力，即QoS（Qualityof Service，服务质量）。

为保证QoS，在音视频传输和处理过程中采取了下面的技术：

交互式实时音视频采用RTP协议进行音视频传输，RTP头部提供了负载类型、时间戳、序列号和同步源等信息保证了基本的音视频传输需求。

RTP底层采用的UDP传输层协议，当网络过载/拥塞，无法实现对丢包、抖动、乱序以及网络拥塞的自适应调整。视频传输由于占据带宽更大，更容易受到网络环境变化的影响，因此下面以视频为例分析Qos提升途径。

处理方法：

  • 基于NACK反馈的丢包重传
  • 前向纠错FEC
  • 参考帧选择RPS

基于NACK反馈的丢包重传

接收端循环检查接收缓冲，当发现丢包后使用RTCPNACK反馈报文将丢包信息反馈给发送端；发送端接收NACK反馈并解析后从发送缓存取出对应的RTP包，再次发送给接受端。

缺点：增大了端到端的延迟，在丢包量大时这种延迟更加明显

FEC机制在接受端根据视频帧的重要性（参考帧或非参考帧）发送冗余的视频RTP包。

优点：视频无延迟

混合NACK/FEC模式

接受端根据帧大小和接收时延来估计可用带宽，发送端根据可用带宽、丢包、RTT等反馈计算分配保护开销（包括 FEC bitrate、NACK bitrate）和视频的编码码率各占的比例。

FEC的保护级别取决于RTT：

当RTT较小时，丢包重传的时延不会导致明显的视频卡顿，所以可以减少FEC包数量。

当RTT较大时，时延对视频流畅度影响严重，要相应增加FEC包数量。

也可以使用多帧FEC和结合时域分层信息的FEC（有点SVC编码的味道了），二者均可在减小保护开销的同时，提供较好视频质量

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

TCP协议栈默认实现了对网络的拥塞控制以保证可靠传输，但实时通讯应用中并不会用到。所以为了能有效控制端到端延迟、有效控制丢包率、与其他应用流共享链路带宽、能与TCP长连接流公平竞争可用链路带宽的话，就需要重新规划出相应算法。GCC就是该类型算法之一。

GCC全称 Google Congestion Control，是一种混合了基于丢包、基于时延 的方法，大概原理如下：

发送端根据丢包率调整目标带宽：

低丢包率（小于2%）时增加目标码率，高丢包率（大于10%）时减少目标码率，丢包率介于二者之间时目标码率保持不变。

接受端根据时延估计最大带宽，这一部分由三个模块组成：

排队时延估计、链路过载检测、 最大带宽估计

当排队时延 < 阈值（根据网络状态自适应调整）时，链路检测结果为underuse；

当排队时延 > 阈值，链路检测结果为overuse；

介于二者之间时，链路检测结果为normal；

最大带宽估计模块是一个表示当前链路状态（Increase、Hold、Decrease）的有限状态机，初始状态为Hold，根据链路检测结果进行状态转移，根据转移后的链路状态和当前接收码率估计最大带宽remb。

接受端计算的remb值回通过RTC PREME反馈到发送端，发送端最终目标码率不应该超过remb值。

关键帧请求

关键帧也叫即时刷新帧，简称IDR帧。对于视频来说，IDR帧的解码无需参考之前的帧，因此在丢包严重时可以通过IDR请求画面恢复。IDR请求的方式分为三种：RTCPFIR反馈（Full intra frame request）、RTCPPLI反馈（Picture Loss Indictor）或者SIPinfo消息。