HLS协议

目录1、核心概念1.1、整体架构1.2、两大核心文件1.3、工作机制1.4、HLS的优缺点1.4.1、优点1.4.2、缺点1.5、与其它流媒体协议的对比1.5.1、与RTMP的对比1.5.2、与WebRTC的对比2、原理2.1、整体数据流架构2.2、切片生成2.3、M3U8索引文件2.3.1、M3U8文件结构示例2.3.2、主播放列表Master Playlist与自适应码率2.4、自适应码率ABR2.4.1、工作原理2.4.2、码率切换策略2.4.3、切片的时间对齐要求2.5、不同场景的特殊处理2.5.1、点播M3U8特征2.5.2、直播M3U8特征2.5.3、直播的滑动窗口机制1、核心概念1.1、整体架构HLS采用简单清晰的服务端-分发-客户端三层架构服务端将视频流切片并生成索引文件分发组件通过HTTP服务器通常搭配CDN分发内容客户端下载索引和切片解码播放1.2、两大核心文件文件类型作用格式M3U8索引文件记录视频切片的元数据时长、顺序、地址等文本文件类似播放列表。可以多级索引TS媒体切片存储实际的音视频数据2-10秒的小文件1.3、工作机制服务端将视频流切分为连续的TS小文件同时生成M3U8索引客户端先下载主M3U8索引文件根据自身网络选择合适的码率版本客户端下载二级M3U8索引文件获取TS切片地址列表客户端按顺序下载TS切片并播放播放过程中客户端持续监测网络状况动态切换码率1.4、HLS的优缺点1.4.1、优点优势一全平台兼容性——最大的竞争壁垒HLS是目前兼容性最广泛的流媒体协议。iOS/macOS原生支持Android通过ExoPlayer完美支持Web端可通过hls.jsM3U8格式的标杆解决方案实现播放。相比之下其主要竞争对手DASH在苹果生态中需要额外适配。这一优势使得HLS成为社交软件URL分享的首选协议。当用户在微信、Twitter等平台分享视频链接时底层通常就是HLS流。优势二自适应码率保障极致体验HLS通过ABR机制在网络波动时实现无感知质量切换网络良好时自动升级到1080p/4K网络拥塞时平滑降级到720p/480p切换过程不中断播放用户几乎无感知这种设计使得HLS特别适合移动端场景——用户在地铁、电梯等网络变化剧烈的环境中仍能获得流畅体验。优势三部署成本低标准Web服务器即可支撑HLS分发无需专用流媒体服务器。结合CDN后可按需扩展带宽成本可控。1.4.2、缺点劣势一高延迟——最突出的短板传统HLS延迟为10-30秒这是其切片索引架构的固有问题切片生成需要积累足够数据通常2-10秒客户端需要先下载M3U8才能知道切片地址播放缓冲区进一步增加延迟这意味着传统HLS不适合实时互动场景如电商直播、在线课堂、体育赛事竞猜等。不过低延迟HLSLL-HLS已将延迟降至2-5秒正在缩小这一差距。劣势二服务器资源开销大HLS的切片机制带来多重资源消耗存储开销每个码率版本都需保存完整切片文件点播场景下存储成本显著处理负载服务端需持续进行切片封装客户端需逐个解码缓存复杂度多码率、多切片的缓存策略比单一文件复杂1.5、与其它流媒体协议的对比1.5.1、与RTMP的对比对比维度HLSRTMP主导场景播放端下行分发推流端上行 ingest连接方式HTTP短连接TCP长连接并发能力高CDN分发低单服务器受限防火墙穿透易80/443端口难非标准端口当前地位播放端标准推流端事实标准实际工作流编码器 →RTMP推流→ 流媒体服务器 →HLS切片→ CDN分发 → 播放器RTMP在推流端的统治地位短期内难以撼动但播放端已全面转向HLS。1.5.2、与WebRTC的对比对比维度HLSWebRTC延迟10-30秒1秒架构CDN分发一对多P2P/SFU小范围互动网络要求宽容自适应强要求高弱网表现下降适用场景大规模广播小规模双向互动选择逻辑需要数千至上百万观众同时观看 →HLS借助CDN需要双向实时互动如视频会议→WebRTC部分混合方案WebRTC用于互动环节HLS用于大规模分发2、原理HLSHTTP Live Streaming的核心设计哲学是将连续的媒体流转换为一系列离散的小文件通过HTTP协议传输让客户端能够动态适应网络变化。2.1、整体数据流架构HLS的完整数据流转可以概括为原始音视频 → 编码/封装 → 切片/索引生成 → HTTP分发 → 客户端解析播放2.2、切片生成编码器输出的连续TS流被切割成等时长的小文件默认10秒可配置为2-6秒降低延迟原始流: [---10秒---][---10秒---][---10秒---]... 切片后: segment0.ts, segment1.ts, segment2.ts...每个TS切片是独立的媒体文件包含关键帧IDR帧后续若干非关键帧音频帧为了保证切片独立解码切片边界必须对齐关键帧。如果某个切片不以关键帧开头播放器将无法从该切片开始播放。2.3、M3U8索引文件M3U8是HLS的核心控制结构本质上是一个UTF-8编码的播放列表Playlist是由多个独立行组成的文本文件包含所有切片的元数据。每行由用 \n 或者 \r\n来标识换行。每一行可以是一个URI、空白行或是一个 以# 号开头的字符串。URI 表示一个TS分片地址或是Playlist地址。URI 可以用绝对地址或者相对地址如果使用相对地址那么是相对于当前Playlist的地址。2.3.1、M3U8文件结构示例二级M3U8#EXTM3U # 文件头标识必需必须是第一行 #EXT-X-VERSION:3 # HLS协议版本 #EXT-X-TARGETDURATION:10 # 所有切片的最大时长秒 #EXT-X-MEDIA-SEQUENCE:0 # 第一个切片的序列号 ​ # 第一个切片 #EXTINF:10.0, # 单个切片时长10秒 segment0.ts ​ # 第二个切片 #EXTINF:9.8, # 切片时长9.8秒 segment1.ts ​ # 第三个切片 #EXTINF:10.0, segment2.ts ​ #EXT-X-ENDLIST # 点播流结束标记直播没有注上述内容中的注释的语法是不对的仅用于理解代码当一个 # 后面紧跟一个大写字母开头的特定字符串时它就是一个HLS标签是M3U8文件的核心指令。播放器会解析并执行这些指令它们不是注释。例如#EXTINF、#EXTM3U当一个#不符合上述任何标签的语法时它会表示一行纯粹的注释播放器会完全忽略这一行。特别注意行尾注释 (inline comments) 是不允许的。2.3.2、主播放列表Master Playlist与自适应码率当存在多个码率版本时使用主M3U8一级M3U8进行统一管理#EXTM3U #EXT-X-VERSION:3 ​ # 低码率版本360pBANDWIDTH该版本所需的平均比特率(bps)客户端据此判断网络是否满足 #EXT-X-STREAM-INF:BANDWIDTH800000,RESOLUTION640x360 low/playlist.m3u8 ​ # 中码率版本720pRESOLUTION视频分辨率 #EXT-X-STREAM-INF:BANDWIDTH2500000,RESOLUTION1280x720 mid/playlist.m3u8 ​ # 高码率版本1080p #EXT-X-STREAM-INF:BANDWIDTH5000000,RESOLUTION1920x1080 high/playlist.m3u82.4、自适应码率ABRABR是HLS最核心的智能特性让播放器能够动态、无感知地切换质量。2.4.1、工作原理1. 客户端下载主M3U8获取所有码率版本信息 ├─ 800kbps (360p) ├─ 2500kbps (720p) └─ 5000kbps (1080p) ​ 2. 客户端测量当前下载速度 - 下载1个TS切片耗时2秒切片大小1MB → 速度500KB/s≈4000kbps ​ 3. 选择合适码率 - 当前速度4000kbps 2500kbps → 选择2500kbps版本 - 保留安全余量通常选择比测量值低20-30%的码率 ​ 4. 持续监测 - 每隔几个切片重新测量速度 - 网络下降时自动切换到低码率 - 网络恢复时自动升级到高码率2.4.2、码率切换策略策略类型实现方式优缺点基于带宽实时计算下载速度选择匹配码率简单有效但可能滞后基于缓冲区缓冲区阈值时降级阈值时升级更平滑避免卡顿混合策略带宽缓冲区综合决策业界主流方案2.4.3、切片的时间对齐要求为了实现无缝切换不同码率的切片必须时间对齐时间轴: 0s 5s 10s 15s 低码率: [seg0] [seg1] [seg2] [seg3] 中码率: [seg0] [seg1] [seg2] [seg3] 高码率: [seg0] [seg1] [seg2] [seg3] ​ # 播放到5秒时低切高完成seg1后下一个请求高码率的seg2如果时间不对齐切换时会出现内容重复或跳帧。2.5、不同场景的特殊处理点播和直播在M3U8生成逻辑上有本质区别。2.5.1、点播M3U8特征包含所有切片的完整列表有#EXT-X-ENDLIST标记切片数量固定不随时间变化#EXT-X-MEDIA-SEQUENCE固定通常为0 —— 第一个切片的序列号2.5.2、直播M3U8特征只保留最近一段时间的切片如最近5个切片没有#EXT-X-ENDLIST标记#EXT-X-MEDIA-SEQUENCE动态递增客户端需要周期性重新下载M3U8来获取新切片2.5.3、直播的滑动窗口机制时间线: ─────────────────────────────────────→ 切片序列: 100 101 102 103 104 105 106 107 108 ​ 时刻T1的M3U8: [100, 101, 102, 103, 104] (MEDIA-SEQUENCE100) 时刻T2的M3U8: [101, 102, 103, 104, 105] (MEDIA-SEQUENCE101) 时刻T3的M3U8: [102, 103, 104, 105, 106] (MEDIA-SEQUENCE102) ​ # 客户端每隔几秒重新请求M3U8对比MEDIA-SEQUENCE发现新切片 # 新切片序列号 旧MEDIA-SEQUENCE 旧列表长度