为什么流媒体直播的延迟很高

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

通信技术的发展促进了视频点播和直播业务的兴起4G 和 5G 网络技术的进步也使得流媒体技术变得越来越重要但是网络技术并不能解决流媒体直播的高延迟问题本文不会介绍网络对直播业务的影响而是会分析直播中常见的现象 — 主播和观众之间能够感觉到的明显网络延迟。除了业务上要求的延迟直播之外有哪些因素会导致视频直播的延迟这么高呢

图 1 - 流媒体直播

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

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

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

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

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

数据编码

视频直播一定会使用音视频的编码技术目前主流的音频和视频编码方式是高级音频编码Advanced Audio CodingAAC1 和高级视频编码Advanced Video CodingAVC2AVC 常被称作 H.264。这一节不讨论音频数据的编解码算法我们来详细分析一下为什么需要 H.264 编码它又如何影响直播延迟。假设我们需要看一部时长为 2 小时的 1080p、60FPS 的电影如果每个像素需要 2 字节的存储那么整部电影需要占用如下所示的资源

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

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

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

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

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

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

图 3 - 视频编码 GOP

图像组Group of picturesGOP指定了视频帧的组织方式编码的视频流就由连续的 GOP 组成因为每个 GOP 都会以关键帧开头所以 GOP 的大小会影响播放端的延迟。视频占用的网络带宽也与 GOP 息息相关在通常情况下移动端直播的 GOP 都会被设置成 1 ~ 4 秒当然我们也可以使用更长的 GOP 降低占用的带宽4。

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

★文末名片可以免费领取音视频开发学习资料内容包括FFmpeg webRTC rtmp hls rtsp ffplay srs以及音视频学习路线图等等。

见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

数据传输

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

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

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

图 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 文件。

图 6 - m3u8 和 ts 文件

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

虽然所有应用层协议受限于物理设备的 MTU9 都只能分段传输音视频数据但是不同应用层协议对音视频数据的切分粒度决定了端到端的网络延迟。RTMP 以及 HTTP-FLV 等基于流分发的协议切片粒度很小延迟在 3s 以下可以看做实时的传输协议而 HLS 协议是基于文件分发的协议它的切片粒度很大在实际使用中可能会带来 20 ~ 30s 的延迟。

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