HLS直播取流协议及实现原理详解_hls直播流

1、背景

视频会议进行中可以开启直播，支持HLS协议取流，需要根据HLS协议实现客户端取流并实现播放的功能。
本文主要记录对于HLS协议实现的理解，以及通过postman实践取流的操作加深对于HLS协议实现客户端操作的理解

2、直播取流协议

2.1、协议原理简介

HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U （m3u8）playlist文件，用于寻找可用的媒体流。

2.2、图解HLS协议工作原理

注 以下图中的m3u8不是正确完整的格式，只是便于说明的简略写法！！！

2.2.1、服务端工作原理如下图

1. 若存在多码率适配流，则存在如图中index.m3u8文件，记录次级m3u8文件（例如图中的/live/sec/1280_720.m3u8）以及文件对应的码率适配参数，文件格式稍后解析
2. 根据网络以及当前需求以及一级文件信息中参数可以选择最为合适的次级m3u8文件，从而获取对应分辨率的ts文件的url，例如网络较好的情况下可以根据“/live/sec/1280_720.m3u8”拉取视频分辨率1280720的码流，网络差的情况下可以根据“/live/sec/640_360.m3u8”拉取视频分辨率640360的码流
3. 次级m3u8（例如图中的/live/sec/1280_720.m3u8）展示ts流文件列表的url，一般都是相对路径，HLS的live模式下，该节目列表会随着ts文件的生成而更新，例如最开始列表中包含3.ts、4.ts、5.ts，随着新的ts文件生成，列表更新记录的直播流为 4.ts、5.ts、6.ts（有时候没有视频流格式适配，就没有一级m3u8列表文件，直接提供的就是次级m3u8文件）
4. 图中 /live/1280_720/ 指的是存放ts文件的相对路径

2.2.2客户端协议取流实现流程图

1、客户端使用HTTP/HTTPS协议下载一级m3u8文本信息，信息中获取次级m3u8文件列表，根据当前环境以及需求需要选择适当分辨率的次级m3u8文件（不存在分辨率适配就直接下载的是次级m3u8文件信息）
2、循环周期性的请求下载次级m3u8文件，监测更新的ts文件流，并下载解码渲染

2.3、M3U8文件解析

2.3.1、使用场景一

作为单码率节目列表（相当于上述的次级M3U8）向客户端提供当前已经可以下载的ts流文件，随着直播的进行会产生新的ts流文件，M3U8文件中的ts流列表会同步更新。

字段简述（描述常用字段，更多字段可以参考相关的协议文档了解）：
1、#EXTM3U: 表明该文件是一个 m3u8 文件，HLS存在两种模式：
(1)点播VOD的特点就是当前时间点可以获取到所有index文件和ts文件；
(2)Live模式就是实时动态的生成M3U8和ts文件，本文的介绍是Live模式的实现；
文件没有#EXT-X-ENDLIST标志则表示是Live模式。
2、#EXT-X-VERSION：表示 HLS 的协议版本号，该标签与流媒体的兼容性相关。该标签为全局作用域，使能整个 m3u8 文件；每个 m3u8 文件内最多只能出现一个该标签定义。如果 m3u8 文件不包含该标签，则默认为协议的第一个版本。
3、#EXT-X-MEDIA-SEQUENCE：文件播放列表文件中每个媒体文件的URI都有一个唯一的序列号。URI的序列号等于它之前那个RUI的序列号加一。EXT-X-MEDIA-SEQUENCE指明了出现在播放列表文件中的第一个URI的序列号
4、#EXT-X-TARGETDURATION：指定最大的媒体段时间长（秒），也就是ts文件的存储的音视频流的播放时长的最大值。
5、#EXTINF：下一行链接中ts流的时长，紧接着的就是ts文件的url，一般是相对路径，这里也就是需要解析url 并下载url对应的视频流，一般下载的是最后一个，也就是每一次更新m3u8文件列表后下载最新的，这样才能使延时降到最低，但是实际开发中可能ts分段不均分，如果直接播放最新的可能造成已经播放完成上一个片段，新的片段还没有生成的情况。

2.3.2、使用场景二

M3u8提供多码率适配流（上述提及的一级M3U8），内部描述字段包含多个码率的次级M3U8文件以及对应的相关参数，使用过程中只需要获取一次，从中选择适合的码率对应的M3U8文件链接，后续只需要刷新次级M3U8即可。

1、#EXT-X-STREAM-INF用于次级M3U8视频流属性的描述：
BANDWIDTH 指定码率
PROGRAM-ID 唯一ID
CODECS 指定流的编码类型

3、获取直播链接以及直播链接观察以上描述的操作方案

3.1、获取直播链接

1、百度搜索CCTV1在线直播

2、进入标记链接，点击F12

3、刷新页面，关注 m3u8结尾的链接，有一个index.m3u8就是一级M3U8，后续刷新的可以观察是一级中包含的多个二级M3U8链接，并选择了其中某一个码率的二级M3U8链接（截图的是相对路径，完整请求可以点击链接查看Headers查看），后续可以留意该链接会周期刷新。

4、为了便于观察二级m3u8的ts文件列表更新，可以使用postman 请求次级链接，并观察ts的索引变化，也可以用m3u8中的ts链接下载ts文件。

3.2、观察列表的变化

3.2.1、用上述获取的一级M3U8的链接，通过postman查看一级M3U8的变化

等待一段时间再次刷新会发现一级M3U8文件中信息列表没有变更，因此直播取流过程中在获取了次级链接之后可以不需要循环刷新一级M3U8文件。

3.2.2、从一级M3U8文件中选择一个次级M3U8链接，获取ts流列表

几秒钟后…如下图，标记的位置与之前的一次获取会发现ts文件有更新，实际开发中也就是循环刷新M3U8文件，获取最新的节目列表。

4、经验总结

1、网上博客大多说HLS协议延时10秒，这个不是正确的描述，延时的多少和ts文件切片的时长有关，还与播放时选择的是否是列表中最新的文件有关，CCTV的切片时长基本都是10秒左右，但是实际开发中我遇到的是切片时长不均等，例如 5s、6s、7s的都有，所以延时没有确切值。
2、如第1条总结的时间切片会有不均等的情况，此时需要注意是否可以下载列表中最新的ts文件，因为时长的不均等，可能出现上一个ts流播放结束，新的ts流还未下载成功的情况，这样会造成直播卡顿的问题。
3、HTTP请求超时设置不能太小，否则引起文件下载未结束而导致超时出错。
4、M3U8文件列表的更新时间间隔不能太长，否则会出现3.2.2节中两次请求的情况，观察可以发现后一张图第一个ts文件和前一张图的ts文件编号不是连续的，这样就会导致直播视频出现跳跃的情况，也不建议过于频繁，占用资源。