作者：李晨光、匡建鑫、陈鉴平

卷首语：

据我国互联网络信息中心发布的《我国互联网络开展状况计算陈述》显示，截止到 2022 年 6 月我国网络直播用户规模达到了 7.16 亿，占网民全体的 68.1% 。最主要原因是 2020 年度疫情期间导致居家办公和休闲文娱的人数呈现激增，新媒体互动直播成为了广阔网民最重要的休闲文娱方式之一。

跟着直播工业链的不断扩展齐备晋级，相关工业链各个环节分工逐步明确且各环节参与人数逐步增多；为了满意不同的就业需求，引发相关就业人数进步，经过直播方式赋能传统工业晋级转型，并与高新技能融合创新，优化传统职业商业形式，如直播带货、新媒体广告传媒转型等。

丰厚的传统文化、新闻、竞技体育、法律、常识同享等内容，经过移动端互动直播的方式得以愈加高效的展示传达，既让优质的直播内容能够完结迸发式传达扩散，又能够让用户有更多的时机感触，学习甚至主动参与直播互动，完结内容供给侧和需求传达的多方共赢。

能够说，超低延时直播技能正在走上一条全新的开展之路。InfoQ将联合火山引擎视频直播团队推出《超低延时直播技能演进之路》系列，带您探索超低延时直播技能的演进进程，揭示背后的挑战和突破，以及对未来直播职业的影响。

今日这篇文章咱们来讲一下超低延时直播技能的前世今生~

网络基础设施晋级、音视频传输技能迭代、WebRTC 开源等要素，驱动音视频服务时延逐步下降， 使超低延时直播技能成为炙手可热的研讨方向。实时音视频事务在消费互联网范畴蓬勃开展， 并逐步向工业互联网范畴加速浸透。经历了职业第一轮的红利迸发期，我国实时音视频职业的场景效能逐步深化，步入到理性增长阶段。

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

超低延时直播技术的前世今生

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

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

超低延时直播技术的前世今生

（一）传统规范直播技能的局限性

1. RTMP 协议的推迟问题

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

超低延时直播技术的前世今生

2. 传统直播技能在实时互动场景中的缺乏

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

超低延时直播技术的前世今生

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

3. 超低延时直播与规范直播的差异

  • 超低延时直播是近年来新鼓起的一类使用。如电商直播、赛事直播等场景，兼具高并发与低延时的特性，传统直播 3-20s 的时延难以满意其需求，但对实时互动的要求又不及视频会议等典型的实时音视频使用，无需将时延下降至 400ms 以下。 为此，超低延时直播融合了传统直播与实时音视频的技能架构，经过取长补短的方式完结了介于二者之间的端到端时延。 尽管针对超低延时直播厂商尚无一套规范的技能路径，但大体能够概括为拉流协议、网络架构和推流协议三个方面的改造， 在实践使用过程中，厂商会平衡本钱及性能指标等要素，在不同的协议和网络架构之间进行挑选。

  • 传输层协议的****差异 （根据 UDP 协议的牢靠性优化，为弱网对立战略供给根据）

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

  • UDP 协议的优化：

    • UDP 协议往往和 RTP/RTCP 协议一起在实践使用中出现。RTP 担任数据传输，其协议头中的序列号、 端口类型、时刻戳等字段，可为数据包的分组、拼装、排序供给逻辑根据；RTCP 作为 RTP 的操控协议，担任对 RTP 的传输质量进行计算反馈，并为弱网对立战略供给操控参数。
    • 超低延时直播技术的前世今生

（二）超低延时直播技能的演进进程

  • 根据事务场景开展的直播技能演进过程（推迟主线）

  • 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 “www.webrtc.org/experiments…”

      • 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 收包时刻自行解析处理完结解码动作，作用是削减信令交互时刻，进步拉流成功率。

1. WebRTC 协议在直播播映器的移植

  • RTM 低延时直播根据 WebRTC 技能衍生，根据 WebRTC 规范构建点到点传输一般有如下几个过程：

    • 通讯两边要进行媒体协商，会话详细规范即 SDP(Session Description Protocol) 交互；
    • 随后进行交互式网络地址协商（查询对端真实 IP 地址）预备构建媒体传输通道；
    • 当上述条件预备结束即进入终究的 Peer to Peer 点对点媒体数据传输。

超低延时直播技术的前世今生

  • 信令部分客户端-服务器独自开发，利用了 SDP 规范报文形式；媒体传输部分选用开源的 WebRTC 结构和自截自研的实时音视频媒体引擎进行媒体传输。

2. RTC ****信令 协议的改造晋级（ MiniSDP 紧缩 协议）

github.com/zhzane/mini…

超低延时直播技术的前世今生

  • 规范 SDP 比较冗长（ 5-10KB 左右），不利于快速高效传输。在直播场景下，会特别影响首帧时刻。MiniSDP 对规范 SDP 文本协议进行高效能紧缩，将原生 SDP 转换成更小的二进制格式，使其能够经过一个 UDP 包来传输。
  • 下降信令交互时刻，进步网络传输效能，下降直播拉流首帧烘托时刻，进步拉流秒开率/成功率等 QoS 计算指标。
播映协议 RTM-HTTP信令 RTM-MiniSDP信令 FLV
首帧时刻（预览） 600ms 510ms 350ms
拉流成功率（预览） 97.50% 98.00% 98.70%

3. CDN 对 RTM ****信令 的 异步 回源优化

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

超低延时直播技术的前世今生

4. 视频烘托卡顿的优化（百秒卡顿平均下降4秒）

  • 改进人均看播时长，改动 RTC 引擎的组帧/解码战略；禁止 RTC 在低延时形式下的丢帧，改进直播的视频烘托卡顿。
实验组 视频烘托百秒卡顿（直播间场景）
RTM默许JitterBuffer战略 8.3s
RTM改进的JitterBuffer非丢帧战略 3.6s

  • 传统的 RTC 场景优先保时延，全链路会触发各种丢帧（包含但不限于解码模块，网络模块），FLV 直播场景会优先保证观播体会（不丢帧，杰出的音画同步作用）。RTM 要想削减卡顿，获得 qoe 的收益，播控战略需进行定制化, 定制逻辑修改点：

    • 保证不会由于软解的解码耗时或许硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ，内核层有一层强制的音画同步逻辑，能够保证音视频的播映体会；

    • 一起上层在监控网络模块和解码模块的缓存长度，有相应的兜底逻辑：

      1. 判断硬解的确解不过来，dec_cache_frames 过多，上报过错，会降级到软解；
      2. jitterbuffer 反常，缓存的 frame_list 过多，触发播映器反常逻辑，上报过错，从头拉流。

超低延时直播技术的前世今生

5. RTM 播控逻辑的优化

  • 改进移动端看播浸透，RTC 统一内核计划天然生成存在缺点（ MediaCodec 硬件解码器初始化耗时久）；将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播映内核，复用了 FLV 的视频解码模块（ MediaCodec 防止从头初始化）；明显的下降了安卓平台的首帧烘托时刻，进步了拉流的成功率。
  • RTC 内核通用逻辑

超低延时直播技术的前世今生

  • 改进的 RTM 内核播控逻辑

超低延时直播技术的前世今生

以上为超低延时直播技能演进之路《进化篇》的一切内容，第二篇《实战篇》咱们将聚焦于超低延时直播技能怎么大规模落地实践，请我们持续重视~