HLS协议

1.HLS概述
      HLS 全称是 HTTP Live Streaming, 是一个由 Apple 公司实现的基于 HTTP 的媒体流传输协议. 他跟 DASH 协议的原理非常类似. 通过将整条流切割成一个小的可以通过 HTTP 下载的媒体文件, 然后提供一个配套的媒体列表文件, 提供给客户端, 让客户端顺序地拉取这些媒体文件播放, 来实现看上去是在播放一条流的效果.m3u8文件就是基于m3u8协议，存放视频流元数据的文件。
       每一个 .m3u8 文件，分别对应若干个 ts 文件，这些 ts 文件才是真正存放视频的数据，m3u8 文件只是存放了一些 ts 文件的配置信息和相关路径，当视频播放时，.m3u8 是动态改变的，video 标签会解析这个文件，并找到对应的 ts 文件来播放，所以一般为了加快速度，.m3u8 放在 web 服务器上，ts 文件放在 cdn 上。.m3u8 文件，其实就是以 UTF-8 编码的 m3u 文件，这个文件本身不能播放，只是存放了播放信息的文本文件：

 #EXTM3U                 m3u文件头
 #EXT-X-MEDIA-SEQUENCE   第一个TS分片的序列号
 #EXT-X-TARGETDURATION   每个分片TS的最大的时长
 #EXT-X-ALLOW-CACHE      是否允许cache
 #EXT-X-ENDLIST          m3u8文件结束符
 #EXTINF                 指定每个媒体段(ts)的持续时间（秒），仅对其后面的URI有效
 mystream-12.ts

Master Playlist Tags（一级索引）包含多种比特率（Variant Stream 集合）的m3u8
      Master Playlist tags 定义 Variant Streams, Renditions 和 其他显示的全局参数. Master Playlist tags 只能出现在 Master Playlist 中.
      #EXTM3U
      #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000
       http://example.com/low.m3u8
      #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000
       http://example.com/mid.m3u8
      #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
       http://example.com/hi.m3u8
      #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5"
       http://example.com/audio-only.m3u8

• EXT-X-MEDIA: 用于关联同一个内容的多个 Media Playlist 的多种 renditions.
• EXT-X-STREAM-INF: 用于指定一个 Variant Stream.
• EXT-X-I-FRAME-STREAM-INF: 用于指定一个 Media Playlist 包含媒体的 I-frames.
• EXT-X-SESSION-DATA: 存放一些 session 数据.
• EXT-X-SESSION-KEY: 用于解密.

        由于传输层协议只需要标准的 HTTP 协议, HLS 可以方便的透过防火墙或者代理服务器, 而且可以很方便的利用 CDN 进行分发加速, 并且客户端实现起来也很方便.HLS 目前广泛地应用于点播和直播领域.

2.HLS优势
       客户端支持简单, 只需要支持 HTTP 请求即可, HTTP 协议无状态, 只需要按顺序下载媒体片段即可.
       使用 HTTP 协议网络兼容性好, HTTP 数据包也可以方便地通过防火墙或者代理服务器, CDN 支持良好.
       Apple 的全系列产品支持, 由于 HLS 是苹果提出的, 所以在 Apple 的全系列产品包括 iphone, ipad, safari 都不需要安装任何插件就可以原生支持播放 HLS, 现在, Android 也加入了对 HLS 的支持.
      自带多码率自适应, Apple 在提出 HLS 时, 就已经考虑了码流自适应的问题.

3.HLS劣势
       相比 RTMP 这类长连接协议, 延时较高, 难以用到互动直播场景.
       对于点播服务来说, 由于 TS 切片通常较小, 海量碎片在文件分发, 一致性缓存, 存储等方面都有较大挑战.

4.HLS延时分析
       HLS 理论延时 = 1 个切片的时长 + 0-1个 td (td 是 EXT-X-TARGETDURATION, 可简单理解为播放器取片的间隔时间) + 0-n 个启动切片(苹果官方建议是请求到 3 个片之后才开始播放) + 播放器最开始请求的片的网络延时(网络连接耗时)

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

简单流程

6.服务器端与客户端的逻辑
   服务器端逻辑
     1.将媒体源切片成 Media Segment, 应该优先从可以高效解码的时间点来进行切片(如: I-frame).
      2.为每一个 Media Segment 生成 URI.
      3.Server 需要支持 “gzip” 方式压缩文本内容.
      4.创建一个 Media Playlist 索引文件, EXT-X-VERSION 不要高于他需要的版本, 来提供更好的兼容性.
      5.Server 不能随便修改 Media Playlist, 除了 Append 文本到文件末尾, 按顺序移除 Media Segment URIs, 增长 EXT-X-MEDIA-SEQUENCE 和 EXT-X-DISCONTINUITY-SEQUENCE, 添加 EXT-X-ENDLIST 到文件尾.
     6.在最后添加 EXT-X-ENDLIST tag, 来减少 Client reload Playlist 的次数.
     7.注意点播与直播服务器不同的地方是, 直播的 m3u8 文件会不断更新, 而点播的 m3u8 文件是不会变的, 只需要客户端在开始时请求一次即可.

客户端逻辑
      1.客户端通过 URI 获取 Playlist. 如果是 Master Playlist, 客户端可以选择一个 Variant Stream 来播放.
      2.客户端检查 EXT-X-VERSION 版本是否满足.
      3.客户端应该忽略不可识别的 tags, 忽略不可识别的属性键值对.
      4.加载 Media Playlist file.
      5.播放 Media Playlist file.
     6.重加载 Media Playlist file.
     7.决定下一次要加载的 Media Segment.