为什么 4G/5G 的直播延时依然很高-技术圈

通信技术的发展促进了视频点播和直播业务的兴起，4G 和 5G 网络技术的进步也使得流媒体技术变得越来越重要，但是网络技术并不能解决流媒体直播的高延迟问题。

本文不会介绍网络对直播业务的影响，而是会分析直播中常见的现象 — 主播和观众之间能够感觉到的明显网络延迟。除了业务上要求的延迟直播之外，有哪些因素会导致视频直播的延迟这么高呢？

live-streaming 图 1 - 流媒体直播

当观众通过弹幕与主播进行互动时，从我们看到弹幕到得到主播的响应可能要经过 5s 甚至更长的时间，虽然主播看到弹幕的时间与观众看到弹幕的时间不会有太大的差别，但是直播系统将主播的音视频数据传输到客户端或者浏览器需要较长的时间，这个从主播端到观众端传输数据的时间一般被称作端到端的音视频延迟。

流媒体直播从音视频的采集和编码到音视频的解码和播放涉及了非常长的链路，需要途径主播端、流媒体服务器以及观众端，这三方分别提供了不同的功能：

主播端：音视频采集、音视频编码、推流；
流媒体服务器：直播流收集、音视频转码、直播流分发；
观众端：拉流、音视频解码、音视频播放；

在这个冗长的采集和分发流程中，不同过程中都会通过一些技术保证直播的质量，这些为了保证可靠性、降低系统带宽而使用的手段共同造成了直播高延迟的问题。本文会从以下三个方面分析为什么流媒体直播的端到端延迟很高：

音视频使用的编码格式决定了客户端只能从特定帧开始解码；
音视频传输使用的网络协议切片大小决定了客户端接收数据的间隔；
服务器和客户端为了保证用户体验和直播质量预留缓存；

数据编码

视频直播一定会使用音视频的编码技术，目前主流的音频和视频编码方式是高级音频编码（Advanced Audio Coding，AAC）[^1] 和高级视频编码（Advanced Video Coding，AVC）[^2]，AVC 常被称作 H.264。

这一节不讨论音频数据的编解码算法，我们来详细分析一下为什么需要 H.264 编码，它又如何影响直播延迟。假设我们需要看一部时长为 2 小时的 1080p、60FPS 的电影，如果每个像素需要 2 字节的存储，那么整部电影需要占用如下所示的资源：

然而在实际情况下，每一部电影占用的磁盘空间只有几百 MB 或者几 GB，这与我们计算出来的结果相差好几个数量级，音视频编码就是起到用于压缩音视频数据，减少占用磁盘和网络带宽的关键技术。

H.264 是用于视频压缩的业界标准，因为视频是由一帧一帧的图片组成的，而不同的图片之间有较强的连续性，H.264 使用关键帧（Intra-coded picture，I 帧）作为视频的全量数据，不断使用向前参考帧（Predicted picture，P 帧）和双向参考帧（Bidirectional predicted picture，B 帧）对全量的数据进行增量式的修改以达到压缩的目的。

h264-frames 图 2 - H.264 压缩视频数据

H.264 会使用 I 帧、P 帧和 B 帧将视频数据压缩成如上图所示的图片序列，这三种不同的视频帧分别起到不同的作用[^3]：

视频帧	作用
I 帧	类似 JPG 或者 BMP 格式的完整的图片
P 帧	可以使用前一个视频帧的数据压缩数据
B 帧	可以使用前一个和后一个视频帧压缩数据

压缩后的视频数据是一系列连续的视频帧，客户端在解码视频数据时会先找到视频数据的第一个关键帧，然后增量对关键帧进行修改。如果客户端接收到的第一个视频帧就是关键帧，那么客户端就可以直接播放视频，但是如果客户端错过了关键帧，那么就需要等待下一个关键帧才可以播放视频。

group-of-pictures 图 3 - 视频编码 GOP

图像组（Group of pictures，GOP）指定了视频帧的组织方式，编码的视频流就由连续的 GOP 组成，因为每个 GOP 都会以关键帧开头，所以 GOP 的大小会影响播放端的延迟。

视频占用的网络带宽也与 GOP 息息相关，在通常情况下，移动端直播的 GOP 都会被设置成 1 ~ 4 秒，当然我们也可以使用更长的 GOP 降低占用的带宽[^4]。

视频编码中的 GOP 决定了关键帧的间隔，也决定了客户端在找到第一个可以播放的关键帧的时间，进而影响流媒体直播的延迟，这种秒级别的延迟对于视频直播业务来说影响还是比较明显的，GOP 的设置是对视频质量、带宽和延迟权衡的结果。

数据传输

音视频数据传输可以选择使用不同的应用层协议，最常见的两种网络协议是实时消息传输协议（Real Time Messaging Protocol，RTMP）和 HTTP 实时流式传输协议（HTTP Live Streaming，HLS），这两种网络协议分别使用不同的方式传输音视频流，我们可以认为 RTMP 协议基于音视频流分发数据，而 HLS 协议基于文件分发音视频数据。

live-streaming-protoco 图 4 - 流媒体数据传输协议

RTMP 协议是基于 TCP 的应用层协议，它将音视频流切分成片段进行传输，在默认情况下音频数据段的大小为 64 字节，视频数据段的大小是 128 字节[^5]。使用 RTMP 协议时，所有的数据都会块（Chunk）的形式传输：

rtmp-payload 图 5 - RTMP 协议数据块

每个 RTMP 的数据块都包含 1 ~ 18 字节的协议头，协议头由基本协议头（Basic Header）、消息头（Message Header）和扩展时间戳（Extended Timestamp）三个部分组成，除了包含块 ID 和类型的基本协议头之外，其他的两个部分都是可以省略的，进入传输阶段的 RTMP 协议只需要 1 字节的协议头，这也意味着极低的额外开销[^6]。

HLS 协议是苹果在 2009 年发布的基于 HTTP 协议的码率自适应的流媒体网络传输协议[^7]。当播放器获得使用 HLS 协议的拉流地址时，播放器会从拉流地址中获得如下所示的 m3u8 文件：

#EXTM3U
#EXT-X-TARGETDURATION:10

#EXTINF:9.009,
http://media.example.com/first.ts
#EXTINF:9.009,
http://media.example.com/second.ts
#EXTINF:3.003,
http://media.example.com/third.ts

m3u8 是一种播放多媒体列表的文件格式[^8]，该文件中包含了一系列的视频流切片，播放器可以根据文件中的描述依次播放各个视频流。

HLS 协议将直播流拆分成一个个小的文件并使用 m3u8 组织这些直播片段，当播放器播放直播流时会根据 m3u8 的描述依次播放拆分后的 ts 文件。

m3u8-ts 图 6 - m3u8 和 ts 文件

HLS 协议切分的 ts 文件大小会影响端到端的直播延迟，苹果官方文档推荐使用 6 秒的 ts 切片，这也就意味着从主播到观众的延迟至少会增加 6 秒，使用更短的切分方式并不是不可行，只是会带来巨大的额外开销和存储压力。

虽然所有应用层协议受限于物理设备的 MTU[^9] 都只能分段传输音视频数据，但是不同应用层协议对音视频数据的切分粒度决定了端到端的网络延迟。

RTMP 以及 HTTP-FLV 等基于流分发的协议切片粒度很小，延迟在 3s 以下，可以看做实时的传输协议；而 HLS 协议是基于文件分发的协议，它的切片粒度很大，在实际使用中可能会带来 20 ~ 30s 的延迟。

需要注意的是基于文件分发不等价于高延迟，分片的大小才是决定延迟的关键因素，在保证分片小的同时降低额外开销是实时流媒体传输协议需要考虑的问题。

多端缓存

视频直播架构的链路往往都很长，我们不能保证整条链路的稳定性，想要提供流畅的数据传输和用户体验，服务端和和客户端都会增加缓存以应对直播的音视频卡顿。

服务器一般会先缓存一部分直播数据，然后将数据传输至客户端，在网络突然抖动时，服务端可以使用缓存中的数据保证直播流的流畅。

当网络状况恢复时，又会重新缓存数据；客户端也会使用预读缓冲区来提高直播的质量。我们可以调小缓冲区增加实时性，但是在网络状况抖动较多时会严重影响客户端的用户体验[^10]。

总结

流媒体直播的高延迟是一个系统性的工程问题，与微信视频等 1 对 1 的实时通信相比，视频流的生产方和消费方之间的链路极长，很多因素都会影响主播和观众的感受，因为带宽的成本、历史的惯性以及网络的不确定，我们只能通过不同的技术解决遇到的问题，而不得不牺牲的就是用户的体验：

全量的音视频数据过多 — 使用音视频编码会使用关键帧以及增量修改的方式压缩数据，关键帧的间隔 GOP 决定了客户端在播放第一个画面时需要等待的最长时间；
浏览器对实时流的协议支持不够 — 使用 HLS 协议基于 HTTP 对直播的切片进行分发，这会为主播和观众带来 20 ~ 30s 的直播延迟；
链路过长带来的不确定性 — 服务器和客户端使用缓存减少网络抖动对直播质量造成的显著影响；

上述的这些因素都会影响直播系统的端到端延迟，在一个正常的直播系统中使用 RTMP 和 HTTP-FLV 可以达到 3s 以下的延迟，不过 GOP 以及多端缓存都会影响这一指标，延迟在 10s 以内都是很正常的。到最后，我们还是来看一些比较开放的相关问题，有兴趣的读者可以仔细思考一下下面的问题：

基于文件的流媒体传输协议最大会带来多少的额外开销？
不同的视频编码格式的压缩率是怎么样的？

有道无术，术可成；有术无道，止于术

欢迎大家关注Java之道公众号

好文章，我在看❤️