新冠肺炎疫情的突发，让全球远程办公、在线教育、在线协作、远程面试等领域需求急剧增加，这也让支撑远程通信的实时音视频技术成为焦点。由腾讯实时音视频（Tencent Real-Time Communication，TRTC）为基础支撑的腾讯内外众多产品业务如腾讯会议、企业微信群直播、腾讯课堂、VIPKID等均出现爆发式增长。 随着各地有序复工复产，TRTC 也为包括金融行业远程面审、保险远程业务、法院视频庭审、人社局远程面试、长三角教师云招聘、上海市重大产业项目云签约等重要项目发挥了重要作用。数据显示，目前TRTC 平台的客户端上行时长超过 30 亿分钟/天，每天并发在线达到千万级。 本文主要针对 TRTC 技术解读系列中低延时实现技术的解析。
腾讯实时音视频（Tencent Real-Time Communication，TRTC）将腾讯 21 年来在网络及音视频技术上的深度积累，以多人音视频通话、低延时互动直播两大场景化 PaaS 方案，通过全平台覆盖的 SDK 及云 REST API 的方式，在腾讯云上向开发者提供开放服务，致力于帮助开发者快速搭建低成本、低延时、高品质的音视频互动解决方案。
实时即端到端 1 秒以内延时，TRTC 实现了全球的平均端到端延时300ms，其核心的技术也是围绕着降低延时这一点来进行。在音视频系统之中，延时主要来自于以下几个部分：
- 网络层，是指设备端到服务端的网络传输延时。设备端到服务端的网络层的传输链路，也就是常说的“最后一公里”。传输延时中有一些是客观存在的时间消耗，也有一部分可以从技术上做好优化。
- 设备端，主要指设备端内部处理延时。从推流侧的采集、前处理、编码、打包发送，到播放侧的收包解包、解码、渲染播放，每一个环节的耗时都需要控制，播放侧是关键。
- 服务端，即服务端内部处理延时。针对跨运营商、跨国、跨地域的调度处理以及并发高峰的负载调度，在服务上都需要做好耗时优化。
一
网络层
先从网络层开始，现实情况下的网络总是会存在或多或少的丢包、不稳定的延时以及有限的带宽。为了适应实际的网络，在一般的互联网音视频应用例如在线点播、在线直播场景里，通常使用的都是基于TCP 的传输协议，例如 HTTP 和RTMP。但在延时要求高的实时音视频场景，我们会选择使用 UDP 而不是 TCP 来作为传输层的协议，原因主要在于 TCP 的拥塞控制策略。
TCP的拥塞控制策略
TCP 的拥塞控制是将丢包视为网络出现拥塞的信号，下图即为TCP的拥塞控制示意。一旦出现丢包（超时或收到 3 个相同的 ACK 时），TCP 就认为网络出现拥塞，进而降低一半发包阈值，之后如果没有再出现抖动，TCP 的发包会线性增加恢复，这种策略也就是我们常说的“加法增大，乘法减小”。
当出现网络抖动时，TCP 的发包速率会受到很大影响，为了吸收网络中的流量抖动，在 TCP 协议栈中，会设置一定的缓冲区。在 TCP 基于丢包设计的拥塞控制策略下，倾向于填满缓冲区以抵抗网络抖动；当遇到链路瓶颈的缓冲区很大时，需要很长的时间才能将缓冲区的数据包发送出去，造成很大的网络延时，这种情况称之为 TCP 的“缓冲区膨胀”。
播放器的抗抖动策略
网络的抖动在所难免，比如前一次 RTT 还是 50ms，下一次 RTT 可能就是 500ms 了。客户端的播放器为了做好对抗网络抖动的处理，避免这类不均匀的抖动空口时引起播放的卡顿，播放器中会设置一个Jitter Buffer 区用于做本地缓冲，减缓网络抖动对于解码的影响。Jitter Buffer 减少了网络抖动带来的卡顿，但 Jitter Buffer 越大时，播放端的延时也随之增大了。
Jitter Buffer 就像是一个蓄水池，将来自网络的不均匀的数据包先进行一次缓冲，再均匀地交给解码器进行解码。水池的水位越高，要灌满的时间越久，同样的排空的时间也越久。
为了减少延时，在TRTC 中，我们在传输层的使用了 UDP 协议，不过 UDP不像 TCP 协议原本就有 ACK 机制来做好可靠性，需要从协议上做一些处理。
ARQ 与 FEC
ARQ 即自动重传请求，TCP 的 ACK 机制是 ARQ 的一种方式。除了 ACK 以外，有一种机制为 NACK。不同于 ACK 是用来做接收确认，NACK 是没有收到数据包的确认。例如在同样存在丢包的场景下，发送方发出 5 个数据包，接收方接收到的数据丢失了第 3 个数据包：
- 在 ACK 机制下，接收方会回复给发送方已确认收到第 1 个和第 2 个数据包，发送方需要将第 3、4、5 个数据包重传；
- 在 NACK 的机制下，接收方会回复给发送方第 3 个数据包没有收到，发送方需要将第 3 个数据包重传。
通过控制NACK 的响应耗时，可以将重传等待的时间缩减到 300ms 以内，保障了数据可靠性的同时，也降低了重传带来的延时。
通过 NACK 的重传保障后，已经可以抵抗一定的网络丢包，但丢包后的重传仍然不可避免，重传即意味着延时，为了减少重传次数，我们通常还会将配合 FEC 策略。 FEC 即前向错误纠正，是通过增加网络层的校验数据包，增加数据冗余，抵抗传输过程中丢包带来的影响，遇到少量丢包时，接收方无须再通知发送方重传数据，可以直接在本地通过数据校验恢复原始数据，从而减少了延时。不过 FEC 添加冗余数据包也会带来更多的网络带宽占用，因此 FEC 的这种工作方式是“以带宽换延时”。
QoS
利用好 ARQ 和 FEC 机制的基础，是需要有准确的带宽预测，也就是 QoS 中最关键的一环。TRTC 依靠腾讯线上业务多年以来的技术积累，在 QoS 上有着众多专利技术，可以实现更为快速准确的带宽预测，通过及时地调整数据码率匹配网络带宽，可以减少客户端上的网络堆积，降低数据传输的耗时。同时，通过准确的带宽预测，ARQ 和 FEC 策略能够更加有效地发挥作用，带来更好的传输效能。
二
设备端
除了网络层以外，TRTC 在设备端的编解码层面也做了很多处理，其中最重要的是针对视频和音频编解码器的优化。用户对于音视频的播放效果是特别敏感的，尤其是遇到音视频卡顿的情况，用户体验会很差。卡顿的直接原因是播放器解码渲染时没有数据，通常是因为数据传输的过程中存在丢包，接收方没有收到数据。
RPS
我们在视频编解码器上做了一些改进，引入 RPS 帧参考关系来降低网络丢包对视频的损伤。H.264 中，标准的帧参考关系从一个 I 帧开始到下一个 I 帧之间的一组帧组成一个 GOP ，通常是 IPPPP…… 这样的序列形式，每一个 P 帧都参考前一帧，依赖于前一帧进行解码。假设在网络传输过程中发生了丢包导致了某一个帧丢失，如果丢失的是 I 帧，那整个 GOP 都无法解码，而如果丢的是某个 P 帧，那这个 P 帧后面的画面都没法解码出现画面了。
RPS 是在 H.265 中提出的一种参考帧关系，不同于标准 GOP，RPS 在的帧参考关系上并不要求严格地依赖前一帧，而是可以参考在这一帧之前的某一帧。通过控制好帧参考关系，在遇到网络丢包时引起某一帧丢失，那么只会在丢失的这一帧无法解码，而这一帧前后的数据都不受影响，表现在用户层面就是画面觉察不到卡顿，因为一帧的时间只有几十毫秒，人眼一般觉察不到。
PLC
音频质量是通话体验中最关键的影响因素，因为人耳对于声音的敏感程度很高，轻微的声音变化都能被人轻易地觉察，而音频数据丢包的话，很容易产生跳音、杂音、噪音的问题，影响用户感受。 PLC 全称是 Packets Loss Cancellation，即丢包隐藏技术，是通话处理中必不可少的一项技术。通过修改音频编解码器，在编解码器中对于音频帧状态进行记录，记录当前帧及其前后帧的状态，当遇到丢包导致的丢帧时，通过 PLC 将丢失的数据包重建出来，减少重传。 恢复出来的数据不一定效果很好，还需要对音频数据做好平滑处理，腾讯多媒体实验室研发的 TRAE 音频处理库，是领先行业的音频处理引擎，通过 TRAE 对音频数据进行处理，可以高度还原出原始数据。
音画同步
通过网络及编解码器中优化之后，还需要做好在音视频播放上的音画同步处理，确保部分丢包不影响到整体的效果，音画同步的关键在于抖动评估，通过对网络层面的抖动进行准确评估，合理调整音视频的变速，降低网络抖动影响，同时提升用户体验。
三
服务端
在服务端层面，跨运营商、跨国、跨地域的链路情况十分复杂，而遇到业务并发高峰，网络的抢占，资源的消耗都带来不少的挑战。 腾讯云目前在全球已开放 25 个地理区域，运营 53 个可用区，带宽储备超 100Tbps。TRTC 使用腾讯云 CVM、CAP 、GAAP等基础 IaaS 设施，在全球机房部署了音视频服务节点，搭建 TRTC SDN，为全球 196 个国家和地区提供一致的音视频接入体验。通过全球虚拟网络、跨国专线、智能选路、客户端优化等方法，TRTC 全球端到端平均延时小于 300ms。
TRTC是一整套覆盖从客户端到服务端，从硬件设备到高并发系统的音视频全链路技术，本文主要介绍 TRTC 在降低延时上所做的一些技术处理。通过这些技术的优化，不仅让腾讯内部的腾讯会议、企业微信群直播等业务的用户体验领先同行一步，也让腾讯云上众多的金融、政务、教育等行业场景下的实时音视频需求得到良好的解决。
后续，腾讯云音视频团队将继续不断打磨技术，为数百万开发者提供完善的开发体验。
了解更多关于TRTC的信息>>
了解畅享体验包：9.9元2万分钟通用套餐包>>
了解全民特惠包：实时音视频套餐包六折起>>
