【音视频】 HLS协议介绍

参考资料：https://www.cloudflare-cn.com/learning/video/what-is-http-live-streaming/

一、HLS概述

1.1 什么是HLS？

• HLS(HTTP Live Streaming)是苹果公司基于HTTP提出来的一种自适应码率的流媒体传输协议。尤其是在移动端，由于ios/h5不支持flash，使得HLS成了移动端实时音视频流传输的首选。HLS经常应用在直播领域，一些国内的直播云通常使用HLS拉流。但是HLS延迟严重，通常延迟都在10-30s之间。

• HTTP 实时流（HLS）是使用最广泛的视频流协议之一。尽管它称为 HTTP“实时”流，但它同时适用于点播流和实时流。HLS 将视频文件分解为较小的可下载 HTTP 文件，并使用 HTTP 协议来交付。客户端设备加载这些 HTTP 文件，然后将它们作为视频进行播放。

• HLS 的一个优点是，所有连入互联网的设备都支持 HTTP，因而它比需要使用专用服务器的流协议更易于实施。另一个优点是 HLS 流可以根据网络状况提高或降低视频质量，而不会中断播放。这就是在用户观看视频的过程中视频质量可能会变好或变差的原因。这个功能称为“自适应比特率视频传输”或“自适应比特率流式传输”，如果没有它，慢速网络条件可能导致视频播放完全停止。

1.2 什么是流传输？

• 流式传输是通过 Internet 向用户传递视频和音频媒体的一种方式。它通过连续地将媒体文件发送到用户设备来工作，一次传输一小部分，而不是一次性传输全部。

• 原始媒体文件可以存储在远程位置，或者在实时流式传输的情况下，可以使用远程摄像机或麦克风实时创建。这样，视频或音频可以开始播放，无需用户的设备预先下载整个文件。

1.3 什么是HTTP?

• HTTP 是应用程序层协议，用于在连接到网络的设备之间传输信息。普通用户可以访问的每个网站和应用程序都在 HTTP 上运行。通过 HTTP 传输数据通常基于请求和响应。几乎所有 HTTP 消息都是请求或对请求的响应。

• 对于通过 HTTP 的流式传输，标准的请求与响应模式并不适用。客户端和服务器之间的连接在流的持续时间内保持开启状态，并且服务器将视频数据推送到客户端，因此客户端不必逐一请求视频数据的每个片段。

1.4 什么是 HLS 自适应比特率流式传输？

• HLS 与一些其他流协议相比的优势之一是自适应比特率流式传输。这是指根据网络条件变化而在流的中间调整视频质量的能力。即使网络条件变差，此功能也可以使视频继续播放；相反，它也可以最大化视频质量，达到网络可以支持的最高质量。

• 如果网络速度变慢，用户的视频播放器会检测到，自适应比特率流式传输就会降低流的质量，从而使视频不会停止播放。如果有更多网络带宽可用，则自适应比特率流式传输将提高流的质量。

• 自适应比特率流式传输之所以成为可能，是因为 HLS 在分段过程中创建了多个不同质量级别的重复流片段。用户的视频播放器可以在视频播放期间从这些流之一切换到另一个流。

二、HLS原理

2.1 HLS原理概述

服务器： HLS 流源自于服务器，其中存储了媒体文件（在点播流式传输中）或创建了流（在实时流式传输中）。因为 HLS 基于HTTP，所以任何普通的 Web 服务器都可以发起流。

服务器上发生两个主要过程：

1. 编码： 重新格式化视频数据，以便任何设备都能识别和解析数据。HLS 必须使用 H.264 或 H.265 编码。
2. 分段： 视频分成长度为几秒钟的片段。片段长度可变，但默认长度为 6 秒（2016 年为止是 10 秒）。
   • 除了将视频分割为片段外，HLS 还创建视频片段的索引文件，以记录它们所属的次序。
   • HLS 还会创建几组不同质量等级的重复片段：480p、720p 和 1080p 等。

分发：当客户端设备请求流时，已编码的视频段通过互联网推送到客户端设备。通常，内容交付网络 (CDN) 可以协助将流分发到地理上不同的区域。CDN 还可以缓存流，从而更快地将流提供给客户端。

客户端设备：客户端设备是接收流并播放视频的设备，例如用户的智能手机或笔记本电脑。客户端设备使用索引文件作为参考，以正确的顺序组装视频，并根据需要从更高质量影像切换到低质量影像（反之亦然）。

2.2 HLS服务器原理

• 服务器部分负责将输⼊的⾳视频媒体内容转换成为适合于内容分发组件进⾏递送的格式。对于视频直播，编码器⾸先将摄像机实时采集的⾳视频数据压缩编码为符合特定标准的⾳视频基本流(⽬前苹果的系统仅⽀持H.264视频和AAC⾳频)，然后再复⽤和封装成为符合MPEG-2系统层标准的传输流(TS)格式进⾏输出。

• 流分割器(Stream Segmenter)负责将编码器输出的MPEG-2 TS流分割为⼀系列连续的、⻓度均等的⼩TS⽂件(后缀名为.ts)，并依次发送⾄内容分发组件中的Web服务器进⾏存储。与此同时，为了跟踪播放过程中媒体⽂件的可⽤性和当前位置，流分割器还需创建个含有指向这些⼩TS⽂件指针的索引⽂件，同样放置于Web服务器之中。这个索引⽂件可以看作是⼀个连续媒体流中的播放列表滑动窗⼝，每当流分割器⽣成⼀个新的TS⽂件时，这个索引⽂件的内容也被更新，新的⽂件URI(统⼀资源定位符)加⼊到滑动窗⼝的末尾，⽼的⽂件URI则被移去，这样索引⽂件中将始终包含最新的固定数量的x个分段

• 流分割器还可以对其⽣成的每个⼩TS⽂件进⾏加密，并⽣成相应的密钥⽂件。

• 之所以采⽤MPEG-2 TS格式来对编码后的媒体流进⾏统⼀封装，是因为它能够将⾳视频媒体流严格按时序进⾏交织复⽤，任意截取和分段后，每⼀个分段都可能不依赖于之前的分段⽽独⽴进⾏解码和播放。

• 为此，TS⽂件中必须仅包含⼀个MPEG-2节⽬，在每个⽂件的开头应包含⼀个节⽬关联表(PAT)和⼀个节⽬映射表(PMT)，包含视频的⽂件中还必须含有⾄少⼀个关键帧和其他⾜够信息(如序列头)⽤以完成解码器的初始化。

• 索引⽂件采⽤扩展的M3U播放列表格式，后缀名为.m3u8。M3U播放列表是⼀个由若⼲⽂本⾏组成的⽂本⽂件，其中每⼀⾏要么是⼀个URI，⼀个空⾏，或者是⼀个以注释符“#”起始的⾏。每个URI⾏指向⼀个分段的媒体⽂件，或者⼀个衍⽣的索引(播放列表)⽂件。除了以“#EXT”起始的⾏是标签⾏外，其他以“#”起始的⾏是注释，应予忽略。下⾯是⼀个简单的.m3u8索引⽂件例⼦，其所表示的媒体流由3个未加密的⻓度为10秒的TS⽂件组成。

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:10
#EXTINF:10,
http://media.example.com/segment1.ts
#EXTINF:10,
http://media.example.com/segment2.ts
#EXTINF:10,
http://media.example.com/segment3.ts
#EXT-X-ENDLIST

• 对 于 视 频 点 播 ( V O D ) ， ⽂ 件 分 割 器 ( F i l e Segmenter)⾸先将预编码存储的媒体⽂件转码为MPEG-2 TS格式⽂件(已经封装为TS格式的⽂件则忽略这⼀步)，然后再将该TS⽂件分割成⼀系列⻓度均等的⼩TS⽂件。⽂件分割器同样也⽣成⼀个含有指向这些⼩⽂件指针的索引⽂件。

• 与直播型会话不同的是，这⾥的索引⽂件是⼀个不随时间⽽更新的静态⽂件，其中包含⼀个节⽬从头到尾所有分段⽂件的URI列表，并以#EXT-X-ENDLIST标签结尾。可以通过下述⽅法将⼀个直播事件转换成VOD节⽬源供以后点播：在服务器上不删除已经过期的分段媒体⽂件，同时在索引⽂件中也不删除这些⽂件所对应的URI索引项，在直播结束的时候将#EXT-X-ENDLIST标签添加⾄索引⽂件的末尾。

2.3 内容分发

• 内容分发系统⽤于通过HTTP协议将分割后的⼩媒体⽂件及其索引⽂件递送⾄客户端播放器，它既可以是⼀个普通的Web服务器，也可以是⼀个Web缓存系统。⼏乎不需要对Web服务器做任何特殊的配置，以及增加其他定制的模块。
• 推荐的配置仅限于对.m3u8⽂件和.ts⽂件的MIME类型关联，如表所示。

HTTP Live Streaming中建议的MIME类型

由于索引⽂件需要频繁更新和下载，因此在Web cache的配置中有必要对.m3u8⽂件的TTL(time-to-live)值进⾏微调以保证客户端每次请求该⽂件时都能够下载到它的最新版本。

2.4 客户端软件

• 通常情况下，客户端软件通过访问Web⽹⻚中的URL链接来获取和下载⼀个流媒体会话的索引⽂件。这个索引⽂件进⼀步指定了服务器上当前可⽤的TS格式媒体⽂件、解密密钥和其他替换流的位置。对于选定的媒体流，客户端依次下载索引⽂件中列出的每⼀个可⽤媒体⽂件。当这些媒体⽂件缓冲够⼀定数量后，客户端将它们按顺序重新拼装成⼀个连贯的TS流，然后发送⾄播放器进⾏解码和呈现。对于加密的媒体⽂件，客户端还负责根据索引⽂件的指引来获取解密密钥，提供⽤户认证接⼝，并按需进⾏解密。

• 对于视频点播，上述过程不断持续下去，直到客户端碰到索引⽂件中的#EXT-X-ENDLIST标签。、

• 对于视频直播，索引⽂件中不存在#EXT-X-ENDLIST标签，客户端将周期性地向Web服务器重新请求获取该索引⽂件的更新版本，然后在这个更新版的索引⽂件中查找新的媒体⽂件和解密密钥，并将它们的URI添加⾄下载队列的末尾。

• 需要注意HTTP Live Streaming并不是⼀个真正实时的流媒体系统，这是因为对应于媒体分段的⼤⼩和持续时间有⼀定潜在的时间延迟。在客户端中，⾄少在⼀个分段媒体⽂件被完全下载之后才能够开始播放，⽽通常要求下载完成两个分段媒体⽂件之后才开始播放以保证不同分段⾳视频之间的⽆缝连接。此外，在客户端开始下载之前，必须等待服务器端的编码器和流分割器⾄少⽣成⼀个TS⽂件，这也会带来潜在的时延。在推荐配置下，HTTP Live Streaming系统的典型时延约在30s左右。

2.4 ⽹络⾃适应的流间切换和故障保护

在基于HTTP Live Streaming的流媒体系统中，服务器可以为同⼀节⽬源准备多份以不同码率和质量编码
的替换流，并为每个替换流都⽣成⼀个衍⽣的索引⽂件。在主索引⽂件中通过包含⼀系列指向其他衍⽣索
引⽂件的URI指针来找到相应的替换流，如图所示。

• 在移动互联⽹环境下，由于⽹络覆盖⾯的不同和信号强弱的变化，移动终端可能随时在不同的⽆线接⼊⽹络(例如3G，EDGE，GPRS和WiFi等)之间进⾏切换。此时客户端软件可根据⽹络和带宽的变化情况随时切换到不同衍⽣索引⽂件所指向的替换流进⾏下载，从⽽⾃适应地为⽤户提供相应⽹络条件下接近最优的⾳视频QoS体验。

• 上述替换流和衍⽣索引⽂件机制除了可以⽤于基于带宽波动的动态流间切换外，还可以⽤于服务器的故障保护。为此⽬的，⾸先在⼀台服务器上按照正常流程⽣成⼀个媒体流或者多个替换流，以及对应的索引⽂件，然后再在另⼀台服务器上⽣成⼀套并⾏的备份媒体流和索引⽂件。接下来将指向备份流的索引加⼊到主索引⽂件之中，使得其中针对每个带宽值都对应有⼀个主媒体流和⼀个备份媒体流。例如，假定主服务器和备份服务器分别为ALPHA和BETA，则主索引⽂件中的内容可能如下所示：

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000
http://ALPHA.example.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000
http://BETA.example.com/lo/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000
http://ALPHA.example.com/md/prog_index.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000
http://BETA.example.com/md/prog_index.m3u8

• 在上述例⼦中，当客户端连接主服务器ALPHA失败时，它将试图连接备份服务器BETA，从中获取最⾼带宽值替换流所对应的衍⽣索引⽂件，并进⼀步根据该索引⽂件下载相应的替换媒体流⽂件。

• 相对于常⻅的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最⼤的不同在于，直播客户端获取到的，并不是⼀个完整的数据流。

• HLS协议在服务器端将直播数据流存储为连续的、很短时⻓的媒体⽂件（MPEG-TS格式），⽽客户端则不断的下载并播放这些⼩⽂件，因为服务器端总是会将最新的直播数据⽣成新的⼩⽂件，这样客户端只要不停的按顺序播放从服务器获取到的⽂件，就实现了直播。由此可⻅，基本上可以认为，HLS是以点播的技术⽅式来实现直播。

• 由于数据通过HTTP协议传输，所以完全不⽤考虑防⽕墙或者代理的问题，⽽且分段⽂件的时⻓很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟⼀般总是会⾼于普通的流媒体直播协议。

根据以上的了解要实现HTTP Live Streaming直播，需要研究并实现以下技术关键点

1. 采集视频源和⾳频源的数据
2. 对原始数据进⾏H264编码和AAC编码
3. 视频和⾳频数据封装为MPEG-TS包
4. HLS分段⽣成策略及m3u8索引⽂件
5. HTTP传输协议

三、HLS的使用场景和优缺点

3.1 使用场景

HLS 协议因兼容性和自适应能力，广泛应用于以下场景：

1. 直播：体育赛事、新闻直播、演唱会等（虽有延迟，但适合大规模分发）；
2. 点播：视频平台（如 YouTube、Netflix 部分内容）、教育课程（支持多设备播放和清晰度切换）；
3. 移动流媒体：短视频 APP、手机电视（利用自适应码率应对移动网络波动）；
4. IPTV：通过 HLS 实现电视、手机、平板等多终端同步播放；
5. 企业培训：内部视频系统，支持跨设备访问和网络自适应。

3.2 优点

1. 自适应码率：HLS可以根据网络带宽和设备性能等因素，自动调整视频的码率和分辨率，以保证最佳的观看体验。
2. 安全性高：HLS协议支持加密传输，可以保证视频内容的安全性。
3. 它支持插入式内容边界：可以不改变原始流的方式媒体流中插入广告、节目信息等内容，需要在m3u8中加入"EXT-X-DISCONTINUITY"标签和插入流的URI即可。如果是flv、mp4格式的文件，需要把插入的广告融合进原始流，需要做一些视频拼接的工作。
4. 适合录像：录像之后产生的ts文件可以直接上传到云端，然后删除本地文件，不占用本地磁盘空间，这是录制flv、mp4无法相比的。
5. 支持实时回放：HLS支持实时回放，也就是直播还没结束的时候可以回看直播过的内容。

3.3 缺点

1. 延迟较高：因需等待 TS 片段生成（通常 5-10 秒）和缓冲，延迟普遍在 10-30 秒，不适合实时互动场景（如视频通话、在线课堂）。
2. 服务器开销大：需生成多码率片段和索引文件，且需实时更新 M3U8，对服务器性能有要求。
3. 带宽占用：多码率机制会增加存储和传输成本（同一内容需存储多个码率版本）。

更多资料：https://github.com/0voice