音视频流媒体开发-目录
iOS知识点-目录
Android-目录
Flutter-目录
数据结构与算法-目录
uni-pp-目录
官⽹⽂档：
0 概览
HLS的配置
基本配置
实际使⽤
1. 服务器
服务器部分负责将输⼊的⾳视频媒体内容转换成为适合于内容分发组件进⾏递送的格式。对于视频直播，编码器⾸先将摄像机实时采集的⾳视频数据压缩编码为符合特定标准的⾳视频基本流(⽬前苹果的系统仅⽀持H.264视频和AAC⾳频)，然后再复⽤和封装成为符合MPEG-2系统层标准的传输流(TS)格式进⾏输出。流分割器(Stream Segmenter)负责将编码器输出的MPEG-2 TS流分割为⼀系列连续的、⻓度均等的⼩TS⽂件(后缀名为.ts)，并依次发送⾄内容分发组件中的Web服务器进⾏存储。与此同时，为了跟踪播放过程中媒体⽂件的可⽤性和当前位置，流分割器还需创建⼀个含有指向这些⼩TS⽂件指针的索引⽂件，同样放置于Web服务器之中。这个索引⽂件可以看作是⼀个连续媒体流中的播放列表滑动窗⼝，每当流分割器⽣成⼀个新的TS⽂件时，这个索引⽂件的内容也被更新，新的⽂件URI(统⼀资源定位符)加⼊到滑动窗⼝的末尾，⽼的⽂件URI则被移去，这样索引⽂件中将始终包含最新的固定数量的x个分段，如图所示。流分割器还可以对其⽣成的每个⼩TS⽂件进⾏加密，并⽣成相应的密钥⽂件。
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. 内容分发
内容分发系统⽤于通过HTTP协议将分割后的⼩媒体⽂件及其索引⽂件递送⾄客户端播放器，它既可以是⼀个普通的Web服务器，也可以是⼀个Web缓存系统。⼏乎不需要对Web服务器做任何特殊的配置，以及增加其他定制的模块。推荐的配置仅限于对.m3u8⽂件和.ts⽂件的MIME类型关联，如表所示。
HTTP Live Streaming中建议的MIME类型
由于索引⽂件需要频繁更新和下载，因此在Web cache的配置中有必要对.m3u8⽂件的TTL(time-tolive)值进⾏微调以保证客户端每次请求该⽂件时都能够下载到它的最新版本。
3. 客户端软件
通常情况下，客户端软件通过访问Web⽹⻚中的URL链接来获取和下载⼀个流媒体会话的索引⽂件。这个索引⽂件进⼀步指定了服务器上当前可⽤的TS格式媒体⽂件、解密密钥和其他替换流的位置。对于选定的媒体流，客户端依次下载索引⽂件中列出的每⼀个可⽤媒体⽂件。当这些媒体⽂件缓冲够⼀定数量后，客户端将它们按顺序重新拼装成⼀个连贯的TS流，然后发送⾄播放器进⾏解码和呈现。对于加密的媒体⽂件，客户端还负责根据索引⽂件的指引来获取解密密钥，提供⽤户认证接⼝，并按需进⾏解密。对于视频点播，上述过程不断持续下去，直到客户端碰到索引⽂件中的#EXT-X-ENDLIST标签。对于视频直播，索引⽂件中不存在#EXT-X-ENDLIST标签，客户端将周期性地向Web服务器重新请求获取该索引⽂件的更新版本，然后在这个更新版的索引⽂件中查找新的媒体⽂件和解密密钥，并将它们的URI添加⾄下载队列的末尾。需要注意HTTP Live Streaming并不是⼀个真正实时的流媒体系统，这是因为对应于媒体分段的⼤⼩和持续时间有⼀定潜在的时间延迟。在客户端中，⾄少在⼀个分段媒体⽂件被完全下载之后才能够开始播放，⽽通常要求下载完成两个分段媒体⽂件之后才开始播放以保证不同分段⾳视频之间的⽆缝连接。此外，在客户端开始下载之前，必须等待服务器端的编码器和流分割器⾄少⽣成⼀个TS⽂件，这也会带来潜在的时延。在推荐配置下，HTTP Live Streaming系统的典型时延约在30s左右。
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直播，需要研究并实现以下技术关键点
- 采集视频源和⾳频源的数据
- 对原始数据进⾏H264编码和AAC编码
- 视频和⾳频数据封装为MPEG-TS包
- HLS分段⽣成策略及m3u8索引⽂件
- HTTP传输协议
5 名词解析
统⼀资源标识符（Uniform Resource Identifier，URI)是⼀个⽤于标识某⼀互联⽹资源名称的字符串。
网友评论