超低延时直播技术演进之路-进化篇

一、概述

网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素，驱动音视频服务时延逐渐降低，使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展，并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期，我国实时音视频行业的场景效能逐渐深化，步入到理性增长阶段。

延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度，场景丰富多样。

在这些极端场景下，延时在用户侧希望越小越好，接近于实时通信的低延迟模式可以最大化地激发用户的参与感，无缝地与内容生产方产生互动效应，调动用户所见即所得的积极性。比如在主播秀场的 PK 、送礼、工会冲榜、打赏的活动关键环节，竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应，为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。

下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用；从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。

二、传统标准直播技术的局限性

2.1 RTMP 协议的延迟问题

RTMP 协议是最传统的直播协议，主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发，端到端延迟一般控制在 3 到 7 秒。问题是 RTMP 的可扩展性存在缺陷，同时对于延迟的进一步下探存在一定的技术困难。RTMP 协议情况下：为了满足延时降低必然压缩播放器的下载缓冲区，这样会引发显著的卡顿问题，使得播放的观感产生不舒适的感受（延时下探至 2 秒以下）。

2.2 传统直播技术在实时互动场景中的不足

比较典型的有以下一些不足：

1. 视频延时和弹幕交互的延时存在显著差异，问题聊天内容互动与视频传输图像节奏不匹配。

1. 观众与主播互动形式单一，是单向内容传导无法做到双向（在 RTC 技术引入之前无法显著解决）。
2. 单向传导的局限第一个方面表现在：观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知，在网络情况实时变化的场景（比如弱网，移动基站切换等）固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验；另一方面在网络条件更好时，固定码率传输无法动态提升视频传输码率（更高的画质带来更加舒适的体验）。
3. 在直播和连麦场景共存的互动直播场景下，主播采用传统 RTMP 推流在遇到连麦 PK 场景时，会产生推流/本地连麦合流/服务器连麦合流的切换问题，这种场景变换的切换会使得观众端产生瞬间的卡顿问题；如果采用基于 webRTC 直播技术的超低延时直播方案，这种推流–连麦逻辑的合流切换问题可以得到比较友好的解决（只需要改变服务器转发-订阅流通道的分发逻辑，不涉及推流媒体数据流的旁路调度切换）。

2.3 超低延时直播与标准直播的区别

1. 超低延时直播是近年来新兴起的一类应用。如电商直播、赛事直播等场景，兼具高并发与低延时的特性，传统直播 3-20s 的时延难以满足其需求，但对实时互动的要求又不及视频会议等典型的实时音视频应用，无需将时延降低至 400ms 以下。 为此，超低延时直播融合了传统直播与实时音视频的技术架构，通过取长补短的方式实现了介于二者之间的端到端时延。 尽管针对超低延时直播厂商尚无一套标准的技术路径，但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造， 在实际应用过程中，厂商会平衡成本及性能指标等因素，在不同的协议和网络架构之间进行选择。
2. 传输层协议的差异 （基于 UDP 协议的可靠性优化，为弱网对抗策略提供依据）。

传统直播 FLV/RTMP 等采用的是 TCP 协议（或者 QUIC 协议）TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。弱网环境下，其在数据传输前的“三次 握手”连接会带来较大延时。而 UDP 作为不可靠的传输协议，其最大的优点为高实时性，但不保证数据的到达和排序。 实时音视频产品（如 RTM 超低延时直播）往往采用 UDP 协议，并在此之上进行协议层与算法层的优化，来提高传输的可靠性与逻辑性。

1. UDP 协议的优化

UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。RTP 负责数据传输，其协议头中的序列号、 端口类型、时间戳等字段，可为数据包的分组、组装、排序提供逻辑依据；RTCP 作为 RTP 的控制协议，负责对 RTP 的传输质量进行统计反馈，并为弱网对抗策略提供控制参数。

三、超低延时直播技术的演进历程

（1）基于业务场景发展的直播技术演进过程（延迟主线）

（2）RTM 协议本身的演进历程

• miniSDP 信令标准实现部分（抖音)
• CDN 信令异步回源
• RTP 携带扩展头组成部分

 a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"
a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"
a=extmap:21 "uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range"
a=extmap:22 "uri:webrtc:rtc:rtp-hdrext:video:frame-type"
a=extmap:23 "uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp"
a=extmap:27 "uri:webrtc:rtc:rtp-hdrext:audio:aac-config"

• a=extmap:18 “http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp”
• a=extmap:19 “uri:webrtc:rtc:rtp-hdrext:video:CompositionTime”

RTP 使用 RTP 私有扩展头携带 DTS/CTS 值，每一帧 RTP 数据包通过 RFC5285-Header-Extension 扩展头携带该帧的 DTS 值，每一帧首个 RTP 包和 VPS/SPS/PPS 包通过 RFC5285-Header-Extension 扩展头携带该帧的 CTS 值，通过 PTS = DTS + CTS 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。

• a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range

扩展头携带帧的起始/结束序号：如果首帧的前几个包丢失，那么可根据起始序号快速发起重传加快首帧；如果当前帧的后几个包丢失，那么可根据该帧的结束序号快速发起重传，降低延时，减少卡顿。

• a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type

扩展头携带帧的类型：如果携带并解析了正确的帧类型，客户端可以不用解析 metadata ；同时在弱网情形，客户端可以跳过 B 帧直接解码 P 帧，加速出帧并减少潜在卡顿。

• a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp

扩展头携带 P 帧的参考帧信息：如果发生弱网情形，那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳，跳过 B 帧解码，减少卡顿发生。

• a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config

为了加速信令交互的速度，CDN 可以在某些条件下不去查询媒体信息，直接向客户端返回支持的音视频能力；此时 SDP 的媒体描述中将不包含有具体的音视频配置详细信息。在音频层面，此时 AnswerSDP 中不包含 aac 解码所需的头信息；此时我们需要采取 RTP 扩展头模式携带 AAC-Config 供客户端在 RTP 收包时刻自行解析处理完成解码动作，作用是减少信令交互时间，提升拉流成功率。

3.1 WebRTC 协议在直播播放器的移植

RTM 低延时直播基于 WebRTC 技术衍生，基于 WebRTC 标准构建点到点传输一般有如下几个步骤：

（1）通信双方要进行媒体协商，会话详细规范即 SDP(Session Description Protocol) 交互；

（2）随后进行交互式网络地址协商（查询对端真实 IP 地址）准备构建媒体传输通道；

（3）当上述条件准备完毕即进入最终的 Peer to Peer 点对点媒体数据传输。

信令部分客户端-服务器单独开发，利用了 SDP 标准报文模式；媒体传输部分采用开源的 WebRTC 框架和自截自研的实时音视频媒体引擎进行媒体传输。

3.2 RTC 信令协议的改造升级（ MiniSDP 压缩协议）

参考链接：https://github.com/zhzane/mini_sdp

经过升级后的miniSDP协议具有如下优势：

• 标准 SDP 比较冗长（ 5-10KB 左右），不利于快速高效传输。在直播场景下，会尤其影响首帧时间。MiniSDP 对标准 SDP 文本协议进行高效能压缩，将原生 SDP 转换成更小的二进制格式，使其能够通过一个 UDP 包来传输。
• 降低信令交互时间，提高网络传输效能，降低直播拉流首帧渲染时间，提高拉流秒开率/成功率等 QoS 统计指标。

数据参考下表：

播放协议	RTM-HTTP信令	RTM-MiniSDP信令	FLV
首帧时间（预览）	600ms	510ms	350ms
拉流成功率（预览）	97.50%	98.00%	98.70%

3.3 CDN 对 RTM 信令的异步回源优化

• 降低 RTM 信令交互时间，降低 RTM 拉流首帧渲染时间。
• 原来的流程在服务端缓存不命中时需要等待回源拿到数据，才能返回带有 AacConfig 信息的 AnswerSDP。客户端收到 AnswerSDP 后发送 STUN，而服务端只能在收到 STUN 才能开始下发数据。（如下图左）；当异步回源情况下：服务端不再等待回源结果直接返回 AnswerSDP，之后回源和 WebRTC 建连流程同步进行。等到 WebRTC 建连成功且回源拿到数据立即下发 RTP 数据。（如下图右）

3.4 视频渲染卡顿的优化（百秒卡顿平均降低 4 秒）

改善人均看播时长，改变 RTC 引擎的组帧/解码策略；禁止 RTC 在低延时模式下的丢帧，改善直播的视频渲染卡顿。

实验组	视频渲染百秒卡顿（直播间场景）
RTM默认JitterBuffer策略	8.3s
RTM改进的JitterBuffer非丢帧策略	3.6s

传统的 RTC 场景优先保时延，全链路会触发各种丢帧（包括但不限于解码模块，网络模块），FLV 直播场景会优先保证观播体验（不丢帧，良好的音画同步效果）。RTM 要想减少卡顿，取得 qoe 的收益，播控策略需进行定制化 , 定制逻辑修改点：

• 确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ，内核层有一层强制的音画同步逻辑，可以确保音视频的播放体验；
• 同时上层在监控网络模块和解码模块的缓存长度，有相应的兜底逻辑：a，判断硬解确实解不过来，dec_cache_frames 过多，上报错误，会降级到软解；b，jitterbuffer 异常，缓存的 frame_list 过多，触发播放器异常逻辑，上报错误，重新拉流。

3.5 RTM 播控逻辑的优化

• 改善移动端看播渗透，RTC 统一内核方案天生存在缺陷（ MediaCodec 硬件解码器初始化耗时久）；将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核，复用了 FLV 的视频解码模块（ MediaCodec 避免重新初始化）；显著的降低了安卓平台的首帧渲染时间，提升了拉流的成功率。
• RTC 内核通用逻辑

• 改进的 RTM 内核播控逻辑