HTTP Live Streaming (HLS) 协议科普扫盲

HTTP Live Streaming:

HLS是一个由苹果公司提出的基于HTTP的流媒体网络传输协议，可以实现流媒体的直播（live）和点播(vod)。

HLS协议规定：

HLS协议由HTTP+M3U8+TS三部分组成，其中，HTTP是传输协议，M3U8是索引文件，TS是视音频的媒体信息。
视频的编码格式为H264,音频编码格式为MP3、AAC或者AC-3。

工作原理：

把整个ts流分成一个个ts小文件供播放器按顺序下载播放。
在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8) playlist文件，用于寻找可用的媒体流。

1 http 请求 m3u8 的 url。
2 服务端返回一个 m3u8 的播放列表，这个播放列表是实时更新的，一般一次给出5段数据的 url。
3 客户端解析 m3u8 的播放列表，再按序请求每一段的 url，获取 ts 数据流。

Media encoder将视频源中的视频数据转码到目标编码格式（H264）的视频数据，之后，在stream segmenter模块将视频切片。切片的结果就是index file（m3u8）和ts文件。

HLS的index文件（m3u8文件）

播放模式

点播VOD的特点就是当前时间点可以获取到所有index文件和ts文件，二级index文件中记录了所有ts文件的地址。这种模式允许客户端访问全部内容。
Live 模式就是实时生成M3u8和ts文件。它的索引文件一直处于动态变化的，播放的时候需要不断下载二级index文件，以获得最新生成的ts文件播放视频。如果一个二级index文件的末尾没有#EXT-X-ENDLIST标志，说明它是一个Live视频流。
m3u8的Tag，太多了，这里就不一一说明。
播放器拿到该m3u8列表之后，会请求一片ts后，间隔一段时间请求下一片ts。这个间隔的时间的长短，一般是根据m3u8中的 #EXT-X-TARGETDURATION

优势：

1.码率自适应（Adaptive Streaming）

当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。

2.基于HTTP(穿墙/性能高)

HLS采取HTTP协议传输文件，所以可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。相比之下，因为RTMP协议不使用标准的HTTP接口传输数据，所以在一些特殊的网络环境下可能被防火墙屏蔽掉。

3.跨平台性：

支持PC/Android/IOS平台，并在移动端趋势明显。（PC主要的直播方案是RTMP）

4.充分利用CDN（负载均衡）：

CDN即Content Delivery Network （内容分发网络）。CDN包含两大核心技术：负载均衡和分发网络
于负载，RTMP是一种有状态协议，很难对视频服务器进行平滑扩展，因为需要为每一个播放视频流的客户端维护状态。而HLS基于无状态协议（HTTP），客户端只是按照顺序使用下载存储在服务器的普通TS文件，做负责均衡如同普通的HTTP文件服务器的负载均衡一样简单。

劣势：

1.实时性差：

基本上HLS的延迟在10秒以上,而RTMP协议的延迟最低可以到3、4秒左右。

2.文件碎片：

若分发HLS，码流低，切片较小时，小文件分发不是很友好。特别是一些对存储比较敏感的情况，譬如源站的存储，嵌入式的SD卡。

HLS延时分析

HLS理论上延时=1个切片的时长+ 0-1个td + 0-n个启动切片 +网络连接耗时。

td是EXT-X-TARGETDURATION，可简单理解为播放器取片的间隔时间
n:苹果官方建议是请求到3个片之后才开始播放

假设列表里面的包含5个 ts 文件，每个 TS 文件包含5秒的视频内容，那么整体的延迟就是25秒。苹果官方推荐的ts时长时10s，所以这样就会大改有30s（n x 10）的延迟。

为了追求低延时效果，我们可以将切片切的更小，取片间隔做的更小，播放器未取到3个片就启动播放。极致来说可以缩减列表长度为1，并且 ts 的时长为1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲，增加HLS不稳定和出现错误的风险。

参考：
HLS协议介绍
HTTP Live Streaming (HLS) - 概念
流媒体｜从入门到出家：流媒体协议—HLS
HTML 5 视频直播一站式扫盲