前几天前端同事跑过来告诉我页面上视频播放不了浏览器控制台里躺着一行刺眼的报错hls error, type: mediaerror, details: fragparsingerror。我第一反应不是去看播放器代码而是先打开Network面板确认m3u8和ts分片到底有没有正常返回。这种报错十有八九不是播放器的问题而是链路某个环节偷偷长歪了。后来一路查到源站才发现是切片时长和GOP没对齐导致分片里出现了残缺帧。这件事让我觉得很多人把HLS当作一个“拿过来就能用”的协议但真正动手做过视频切片、AES加密、多码流自适应之后才会明白每个细节都可能变成生产事故的源头。这篇文章我会把HLS和M3U8从原理到实战拆开来讲重点放在视频切片、AES加密、多码流自适应这三个核心话题上再结合我实际踩过的坑帮大家少走弯路。1. HLS的工作模型先搞懂它到底传了什么HLSHTTP Live Streaming听起来像是一个“流媒体协议”但本质上它更像一个“文件分发系统”。视频不是通过一条长连接推给播放器的而是被切成很多小文件播放器通过索引文件找到这些小文件然后用普通HTTP请求一个个拉下来播放。这个设计让HLS天然能复用CDN、穿透防火墙也是它能横跨直播和点播两个场景的根本原因。1.1 M3U8索引文件看似简单却藏着协议的“魂”M3U8是M3U的UTF-8版本表面上看就是一个文本播放列表。但HLS的很多关键行为比如直播滑动窗口、多码流自适应、加密信息声明全部是靠M3U8里的标签来完成的。一个最简单的点播M3U8长这样#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.0, segment-000.ts #EXTINF:10.0, segment-001.ts #EXT-X-ENDLIST#EXT-X-TARGETDURATION告诉播放器分片的最大时长是多少播放器会根据它来预估缓冲也用它来检查索引中的分片是否异常。#EXTINF后面的数值是分片实际时长再下一行是分片文件名。#EXT-X-ENDLIST表示这个列表已经结束了后面不会再有新分片这是点播流的特点直播流的M3U8通常没有这一行列表会不停地更新和伸缩。M3U8的标签是大小写敏感的播放器对标签的解析都很严格。我见过不少人手写M3U8时把#EXT-X-KEY写错位置结果整个流都播不了。所以理解每个标签的含义而不是只复制粘贴模板是玩转HLS的第一步。1.2 直播与点播的差异一个文件列表的生命周期点播场景下M3U8一旦生成就是静态的里面包含所有分片的地址播放器可以从任意分片开始播放也可以拖动进度条。直播场景下M3U8是一个动态文件。编码器不断产生新分片列表也不断往里追加同时把已经过期、磁盘上被删掉的老分片移出列表。这个“滑动窗口”机制最关键的标签是#EXT-X-MEDIA-SEQUENCE它表示列表中第一个分片的序号也是播放器计算密钥IV的基础。很多人说HLS直播延迟高其实是分片时长加播放器缓冲策略共同造成的。默认切6秒一个分片播放器为了平滑播放还要额外缓冲两三个分片延迟自然低不了。如果业务对延迟敏感要么用低延迟HLSLL-HLS要么直接换WebRTC而不是拿标准HLS硬扛。这里没有银弹选协议之前先想清楚业务到底需要多低的延迟。2. 视频切片GOP对齐是切片质量的生死线视频切片听起来就是把一个视频按时间切成几段实际操作起来却没那么简单。切片的关键不是“时间点”而是“关键帧”。一个TS分片要想被播放器独立解码它的开头必须是一个IDR关键帧并且至少包含一个完整的GOPGroup of Pictures从一个关键帧到下一个关键帧之间的全部帧。如果切片位置没有落在关键帧上播放器从这个分片开始解码就会缺少参考帧表现出来就是花屏、黑屏甚至直接报fragparsingerror。2.1 切片命令及参数背后的编码逻辑我用得最多的切片工具是ffmpeg一条标准点播切片命令如下ffmpeg -i input.mp4 \ -c:v libx264 -preset veryfast -g 60 -sc_threshold 0 \ -c:a aac -b:a 128k \ -f hls -hls_time 6 -hls_playlist_type vod \ -hls_segment_filename output/segment_%03d.ts output/index.m3u8这里有三个参数必须理解清楚-g 60设置关键帧间隔单位是帧。假设视频fps是25那么-g 60约等于每2.4秒一个IDR帧。如果我想切6秒一个分片就需要保证每6秒左右有关键帧但26和24之间的对齐问题很常见所以实际切出来分片时长会在6秒上下小幅漂移。-sc_threshold 0关闭ffmpeg的场景检测自动插入关键帧功能。如果不关ffmpeg在画面切换时可能额外插入关键帧导致GOP长度不可控切片位置变得飘忽不定。-hls_time 6目标切片时长。注意它只是一个目标值ffmpeg的切片器会找最近的IDR帧做切割点所以最终#EXTINF可能写的是5.92或6.18而不是精确的6.00。如果不想重新编码可以用-c copy直接切片但前提是原始视频的关键帧间隔必须和目标切片时长对齐否则切出来的分片很可能不是从IDR帧开始。这个坑我踩过不止一次拿到一个别人给的视频没看GOP就急急忙忙-c copy切片结果前几个分片播放正常越到后面越容易出现花屏播放器报错也时有时无特别难排查。2.2 切片时长怎么选延迟、兼容性、服务器压力三者的权衡切片时长取决于业务场景没有通吃所有场景的万能值。下面是我在实践中的对比经验切片时长优势劣势适用场景2秒起播快直播实时性高分片数量多索引文件大服务器请求压力大低延迟直播、互动性强场景4~6秒平衡了请求量和起播速度直播延迟仍然偏高常规点播、标准HLS直播10秒分片数量少CDN命中率高起播慢拖动进度条不够精细缓存友好型点播、活动录像我建议常规点播默认使用6秒直播如果不追求极致延迟也可以用6秒LL-HLS场景再考虑切到1秒或2秒。曾经有个项目为了追求低延迟把切片切到500毫秒结果分片数量暴增源站Nginx直接扛不住大量小文件请求延迟没降多少稳定性倒先崩了。切片时长不是越小越好小文件带来的请求放大效应往往被低估。3. AES-128加密给TS分片加锁的正确姿势很多视频业务有版权保护需求HLS原生支持对分片做AES-128加密。加密后分片仍然是TS格式但里面的内容是密文播放器必须先拿到密钥才能解密这比简单地对M3U8地址做鉴权要靠谱得多。3.1 EXT-X-KEY标签与密钥分发加密信息通过M3U8中的#EXT-X-KEY标签声明。一个带AES-128加密的M3U8长这样#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-KEY:METHODAES-128,URIhttps://key.example.com/hls/key?id123,IV0x00000000000000000000000000000001 #EXTINF:6.0, segment-000.tsMETHODAES-128是固定的URI指向一个16字节的二进制密钥文件。IV是初始化向量可以省略。如果不写IV播放器会默认用分片的MEDIA-SEQUENCE序列号作为IV即序列号转成16字节大端序不足部分高位置零。密钥分发是最容易被忽视的安全短板。很多人把key.bin直接和TS分片放在同一个目录或者放在一个任何人猜得到URL的静态路径下。这样一旦有人抓到M3U8就等于拿到了钥匙。稳妥做法是密钥通过一个鉴权下发接口返回请求方必须携带有效的凭证才能拿到16字节的密钥文件并且整个链路要走HTTPS。密钥接口的延迟也要控制好如果响应太慢播放器会一直卡在起播前的阶段用户看到的就是转圈。3.2 加密流的常见翻车点密钥长度、IV、和播放器兼容性我做过不少HLS加密流最常踩的坑集中在下面几个地方。密钥长度必须是16字节。AES-128规定的密钥长度就是16字节多一个少一个都不行。推荐用openssl生成openssl rand 16 key.bin有人图省事直接echo 1234567890123456 key.bin看起来是16个字符但多了一个换行符实际是17字节播放器解密时就会报错。这种错误特别隐蔽因为只从M3U8看什么都正常只有播放器卡住不动。IV必须一致。如果指定了IV加密时用的IV和M3U8里声明的IV必须一致否则解密出来是乱码。TS封装头部有固定的同步字节乱码会导致播放器无法识别TS结构报错往往就是fragparsingerror。如果用默认IV那要保证所有分片来自同一个加密流程MEDIA-SEQUENCE没有跟实际分片序号错位。播放器兼容性悬殊。hls.js、VLC、Safari原生播放器对AES-128支持都比较完善但一些智能电视、机顶盒、WebView内置播放器对加密流的支持很弱。有次客户反馈只有部分设备能播一查才发现是某品牌电视浏览器遇到了密钥请求的CORS问题又因为密钥URL带了自定义Header触发了先OPTIONS后GET的预检流程预检失败播放器就直接放弃了。这种问题只能靠实际设备矩阵去测没有一次性搞定的银弹。4. 多码流自适应Master Playlist是“导演”播放器是“观众”多码流自适应的核心不是某个播放器功能而是M3U8的分层结构。一个Master Playlist主索引不直接指向TS分片而是指向多个不同码率、不同分辨率的子播放列表。播放器会根据实时带宽和设备屏幕尺寸在子播放列表之间切换用户主观感受是“同一个视频画质在自动变化”。4.1 Master Playlist的结构解析一个通用的Master Playlist长这样#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH800000,RESOLUTION640x360,CODECSavc1.42c01e,mp4a.40.2 video-360p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH1400000,RESOLUTION1280x720,CODECSavc1.4d401f,mp4a.40.2 video-720p.m3u8BANDWIDTH的单位是bps不是kbps以前有人把800000理解成800kbps写成800结果播放器一上来就选最差的流画质糊得没法看。RESOLUTION是可选的但它能帮助播放器在做首屏选择时直接排掉分辨率过高的流减少不必要的缓存浪费。CODECS字段主要用于原生播放器提前判断自己能不能解码。主播放列表里还可以用EXT-X-MEDIA声明多音轨、多字幕、多角度但大多数业务用不到我这里就不展开了。4.2 自适应切换如何做到无感知GOP对齐与带宽估算多码流自适应看起来美好做不好就会频繁卡顿、画质来回跳。最核心的一点所有码流的切片时间边界必须对齐并且每个分片都要从IDR关键帧开始。如果360p的第三个分片时长是6.0秒720p的第三个分片也必须是6.0秒这样播放器切换码流时可以直接拉取新的分片解码不需要丢弃前一个流的缓冲内容。如何做到编码阶段就要让所有码流使用相同的关键帧间隔比如统一-g 60、-sc_threshold 0这样切片器才能在同样的时间点切出对齐的分片。很多转码服务说“支持多码率输出”但如果没做GOP对齐播放器照样可能在切换时花屏。播放器端的带宽估算策略也很关键。hls.js默认根据分片下载速度和缓冲长度来综合判断如果当前分片下载速度远高于当前码率说明带宽有余量它才会尝试切到更高码率如果缓冲量快要低于阈值它会先降级保流畅。这个策略可以通过abrEwmaFastDescend等参数调整激进程度但普通项目用默认配置就够了。实际生产环境中多码流通常不是由一个ffmpeg命令直接完成的而是对原始素材分别转成多路不同码率的视频每一路单独切片最后再生成一个总的Master Playlist。手工维护这套结构很繁琐所以我更推荐先用ffmpeg验证流程随后切换到云厂商的转码服务或自建转码集群来批量生产。5. 从fragparsingerror出发的完整排障链路做HLS对接时播放器报错是最常见的“打招呼”方式。hls.js这类库会把错误统一包装成mediaError具体原因在details字段里比如fragParsingError。这个报错字面上是“分片解析失败”但背后的真实原因五花八门必须一步步排查。5.1 hls.js的报错机制与常见根因fragparsingerror的高频根因我整理了一张表根因表现排查方向分片URL错误返回HTMLNetwork里分片请求是200但Content-Type是text/html不是video/mp2t看M3U8里的分片URL是否被路由或鉴权劫持分片文件本身损坏或截断部分分片可以播部分分片失败且失败位置不固定用ffprobe检查失败分片加密密钥拿不到或错误所有分片都失败播放器报错前有明显的key请求失败看EXT-X-KEY的URI能否访问key是否16字节TS封装不规范某些播放器能播、另一些不能播用ffprobe检查TS流SPS/PPS对比播放器差异CORS问题浏览器里报跨域非浏览器环境正常检查m3u8、ts、key三个请求的响应头有一次我排查vue播放m3u8的报错Network面板里每个分片请求都是200但播放器就是卡在fragparsingerror。把其中一个分片下载下来用ffprobe一看发现分片时长只有0.2秒原因是原视频关键帧间隔不稳定ffmpeg切片时生成了大量超短分片。播放器在处理边界超短分片时就崩了。5.2 逐步排查从HTTP状态到TS分片完整性我一般情况下按以下顺序排查先看M3U8内容。把URL在浏览器直接打开确认#EXTINF、分片URL、#EXT-X-KEY这些标签是否存在且顺序正确。直接访问分片URL确认返回的Content-Type是video/mp2t或application/octet-stream如果返回text/html基本被路由或鉴权劫持了。下载一个失败分片用ffprobe检查ffprobe -v error -show_format segment_000.ts如果输出Invalid data found when processing input分片肯定有问题。如果流是AES加密的这里要注意加密分片本身是密文不能用ffprobe直接解析要先拿到密钥解密后再检查。如果是浏览器环境打开Network面板检查三个关键请求m3u8、ts分片、key看是否有跨域报错。最后再用能播的播放器比如VLC跟hls.js做对照缩小问题范围。VLC能播而hls.js不能播大概率是播放器兼容性或CORS问题两边都不能播问题基本在源站。5.3 海康平台HLS对接的额外坑安防项目里经常要对接海康综合安防管理平台的HLS流。海康的WEB API能拿到类似http://ip:port/ISAPI/Streaming/channels/xxx/hls.m3u8的地址但直接用这个地址有坑设备流可能带鉴权参数比如session或token过期后需要重新拉URL。很多海康设备默认不返回CORS跨域头浏览器前端直接播放会报跨域错误。旧款设备输出的TS分片时间戳和EXTINF可能对不上hls.js在解析时会频繁告警甚至触发fragparsingerror。我的处理办法是不在前端直接连设备而是用后端服务拉取设备的HLS流做一层标准协议转换后再以统一的HLS输出给前端。这样既解决了CORS又能把不规范的设备流变成稳定、标准的分片序列前端的播放器兼容性问题也能一起收敛。6. 日常开发中用得上的命令与脚本片段最后分享一些高频命令和避坑经验都是我实际项目里反复用到的。6.1 ffmpeg切片的完整命令模板标准化点播切片我推荐用下面这条ffmpeg -i input.mp4 \ -c:v libx264 -preset veryfast -g 48 -sc_threshold 0 \ -profile:v main -pix_fmt yuv420p \ -c:a aac -b:a 128k -ac 2 \ -f hls -hls_time 4 -hls_playlist_type vod \ -hls_segment_filename out/seg_%03d.ts out/index.m3u8-pix_fmt yuv420p是为了兼容Safari和绝大多数播放器否则换成yuv444或10bit色深很多播放器就解码不了。-profile:v main的兼容性也比high更稳。直播滑动窗口切片可以采用这种形式ffmpeg -i rtmp://source/live/stream \ -c:v copy -c:a copy \ -f hls -hls_time 4 -hls_list_size 6 -hls_flags delete_segments \ /var/www/hls/live.m3u8-hls_list_size 6表示索引里只保留最近6个分片delete_segments表示删除已过期的分片文件。如果直播流需要加密需要额外加上-hls_key_info_file key_info.txt。key_info文件格式一共三行key.uri key.bin 0x00000000000000000000000000000001第一行是M3U8里暴露给播放器的密钥URL第二行是本地密钥文件的路径第三行是IV如果省略ffmpeg默认用分片序列号作为IV。注意key.bin必须是16字节生成方式前面说过了。6.2 m3u8转MP4以及转换失败的原因分析把m3u8转成mp4最常见的需求是下载回放。基础命令是ffmpeg -i index.m3u8 -c copy output.mp4不过HLS分片里的音频流是ADTS格式直接封装成MP4通常会遇到声道信息丢失问题更稳妥的命令是加上音频比特流过滤器ffmpeg -i index.m3u8 -c copy -bsf:a aac_adtstoasc output.mp4转换失败的原因我遇到的几乎就这三类M3U8是直播流没有#EXT-X-ENDLISTffmpeg会把当前这个“没有终点”的列表当成无限列表一直拉不到结束条件转出来要么失败要么文件不完整。分片或密钥下载失败。某一帧出错或某个分片404ffmpeg默认会因为读取错误中断。加密流没有提供密钥ffmpeg不能凭空解密。需要在命令里通过-hls_key_info_file指定密钥文件或者干脆先把解密后的分片合并再转封装。在动手转MP4之前先确认你对这个视频有合法处理权限。技术上能做到的事不等于就应该去做尤其是网上流传的各种m3u8地址很多都涉及版权问题这里不展开但希望每个人都守住底线。回到开头的那个fragparsingerror排查。后来我把播放器从H5切到VLC验证发现VLC能播就基本锁定了是播放器兼容性问题。再对比不同分片的ffprobe结果确认是原视频GOP不均匀导致超短分片。修复方式很简单重新转码再切片让GOP对齐到4秒。从那以后我在任何切片任务里都会先检查源视频的关键帧分布也会在切片脚本里自动保留一份ffprobe -show_frames日志备查。流媒体开发就是这样一次事故换一个教训踩过的坑多了链路自然就熟了。
HLS与M3U8实战：视频切片、AES加密与多码流自适应全解析
前几天前端同事跑过来告诉我页面上视频播放不了浏览器控制台里躺着一行刺眼的报错hls error, type: mediaerror, details: fragparsingerror。我第一反应不是去看播放器代码而是先打开Network面板确认m3u8和ts分片到底有没有正常返回。这种报错十有八九不是播放器的问题而是链路某个环节偷偷长歪了。后来一路查到源站才发现是切片时长和GOP没对齐导致分片里出现了残缺帧。这件事让我觉得很多人把HLS当作一个“拿过来就能用”的协议但真正动手做过视频切片、AES加密、多码流自适应之后才会明白每个细节都可能变成生产事故的源头。这篇文章我会把HLS和M3U8从原理到实战拆开来讲重点放在视频切片、AES加密、多码流自适应这三个核心话题上再结合我实际踩过的坑帮大家少走弯路。1. HLS的工作模型先搞懂它到底传了什么HLSHTTP Live Streaming听起来像是一个“流媒体协议”但本质上它更像一个“文件分发系统”。视频不是通过一条长连接推给播放器的而是被切成很多小文件播放器通过索引文件找到这些小文件然后用普通HTTP请求一个个拉下来播放。这个设计让HLS天然能复用CDN、穿透防火墙也是它能横跨直播和点播两个场景的根本原因。1.1 M3U8索引文件看似简单却藏着协议的“魂”M3U8是M3U的UTF-8版本表面上看就是一个文本播放列表。但HLS的很多关键行为比如直播滑动窗口、多码流自适应、加密信息声明全部是靠M3U8里的标签来完成的。一个最简单的点播M3U8长这样#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.0, segment-000.ts #EXTINF:10.0, segment-001.ts #EXT-X-ENDLIST#EXT-X-TARGETDURATION告诉播放器分片的最大时长是多少播放器会根据它来预估缓冲也用它来检查索引中的分片是否异常。#EXTINF后面的数值是分片实际时长再下一行是分片文件名。#EXT-X-ENDLIST表示这个列表已经结束了后面不会再有新分片这是点播流的特点直播流的M3U8通常没有这一行列表会不停地更新和伸缩。M3U8的标签是大小写敏感的播放器对标签的解析都很严格。我见过不少人手写M3U8时把#EXT-X-KEY写错位置结果整个流都播不了。所以理解每个标签的含义而不是只复制粘贴模板是玩转HLS的第一步。1.2 直播与点播的差异一个文件列表的生命周期点播场景下M3U8一旦生成就是静态的里面包含所有分片的地址播放器可以从任意分片开始播放也可以拖动进度条。直播场景下M3U8是一个动态文件。编码器不断产生新分片列表也不断往里追加同时把已经过期、磁盘上被删掉的老分片移出列表。这个“滑动窗口”机制最关键的标签是#EXT-X-MEDIA-SEQUENCE它表示列表中第一个分片的序号也是播放器计算密钥IV的基础。很多人说HLS直播延迟高其实是分片时长加播放器缓冲策略共同造成的。默认切6秒一个分片播放器为了平滑播放还要额外缓冲两三个分片延迟自然低不了。如果业务对延迟敏感要么用低延迟HLSLL-HLS要么直接换WebRTC而不是拿标准HLS硬扛。这里没有银弹选协议之前先想清楚业务到底需要多低的延迟。2. 视频切片GOP对齐是切片质量的生死线视频切片听起来就是把一个视频按时间切成几段实际操作起来却没那么简单。切片的关键不是“时间点”而是“关键帧”。一个TS分片要想被播放器独立解码它的开头必须是一个IDR关键帧并且至少包含一个完整的GOPGroup of Pictures从一个关键帧到下一个关键帧之间的全部帧。如果切片位置没有落在关键帧上播放器从这个分片开始解码就会缺少参考帧表现出来就是花屏、黑屏甚至直接报fragparsingerror。2.1 切片命令及参数背后的编码逻辑我用得最多的切片工具是ffmpeg一条标准点播切片命令如下ffmpeg -i input.mp4 \ -c:v libx264 -preset veryfast -g 60 -sc_threshold 0 \ -c:a aac -b:a 128k \ -f hls -hls_time 6 -hls_playlist_type vod \ -hls_segment_filename output/segment_%03d.ts output/index.m3u8这里有三个参数必须理解清楚-g 60设置关键帧间隔单位是帧。假设视频fps是25那么-g 60约等于每2.4秒一个IDR帧。如果我想切6秒一个分片就需要保证每6秒左右有关键帧但26和24之间的对齐问题很常见所以实际切出来分片时长会在6秒上下小幅漂移。-sc_threshold 0关闭ffmpeg的场景检测自动插入关键帧功能。如果不关ffmpeg在画面切换时可能额外插入关键帧导致GOP长度不可控切片位置变得飘忽不定。-hls_time 6目标切片时长。注意它只是一个目标值ffmpeg的切片器会找最近的IDR帧做切割点所以最终#EXTINF可能写的是5.92或6.18而不是精确的6.00。如果不想重新编码可以用-c copy直接切片但前提是原始视频的关键帧间隔必须和目标切片时长对齐否则切出来的分片很可能不是从IDR帧开始。这个坑我踩过不止一次拿到一个别人给的视频没看GOP就急急忙忙-c copy切片结果前几个分片播放正常越到后面越容易出现花屏播放器报错也时有时无特别难排查。2.2 切片时长怎么选延迟、兼容性、服务器压力三者的权衡切片时长取决于业务场景没有通吃所有场景的万能值。下面是我在实践中的对比经验切片时长优势劣势适用场景2秒起播快直播实时性高分片数量多索引文件大服务器请求压力大低延迟直播、互动性强场景4~6秒平衡了请求量和起播速度直播延迟仍然偏高常规点播、标准HLS直播10秒分片数量少CDN命中率高起播慢拖动进度条不够精细缓存友好型点播、活动录像我建议常规点播默认使用6秒直播如果不追求极致延迟也可以用6秒LL-HLS场景再考虑切到1秒或2秒。曾经有个项目为了追求低延迟把切片切到500毫秒结果分片数量暴增源站Nginx直接扛不住大量小文件请求延迟没降多少稳定性倒先崩了。切片时长不是越小越好小文件带来的请求放大效应往往被低估。3. AES-128加密给TS分片加锁的正确姿势很多视频业务有版权保护需求HLS原生支持对分片做AES-128加密。加密后分片仍然是TS格式但里面的内容是密文播放器必须先拿到密钥才能解密这比简单地对M3U8地址做鉴权要靠谱得多。3.1 EXT-X-KEY标签与密钥分发加密信息通过M3U8中的#EXT-X-KEY标签声明。一个带AES-128加密的M3U8长这样#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-KEY:METHODAES-128,URIhttps://key.example.com/hls/key?id123,IV0x00000000000000000000000000000001 #EXTINF:6.0, segment-000.tsMETHODAES-128是固定的URI指向一个16字节的二进制密钥文件。IV是初始化向量可以省略。如果不写IV播放器会默认用分片的MEDIA-SEQUENCE序列号作为IV即序列号转成16字节大端序不足部分高位置零。密钥分发是最容易被忽视的安全短板。很多人把key.bin直接和TS分片放在同一个目录或者放在一个任何人猜得到URL的静态路径下。这样一旦有人抓到M3U8就等于拿到了钥匙。稳妥做法是密钥通过一个鉴权下发接口返回请求方必须携带有效的凭证才能拿到16字节的密钥文件并且整个链路要走HTTPS。密钥接口的延迟也要控制好如果响应太慢播放器会一直卡在起播前的阶段用户看到的就是转圈。3.2 加密流的常见翻车点密钥长度、IV、和播放器兼容性我做过不少HLS加密流最常踩的坑集中在下面几个地方。密钥长度必须是16字节。AES-128规定的密钥长度就是16字节多一个少一个都不行。推荐用openssl生成openssl rand 16 key.bin有人图省事直接echo 1234567890123456 key.bin看起来是16个字符但多了一个换行符实际是17字节播放器解密时就会报错。这种错误特别隐蔽因为只从M3U8看什么都正常只有播放器卡住不动。IV必须一致。如果指定了IV加密时用的IV和M3U8里声明的IV必须一致否则解密出来是乱码。TS封装头部有固定的同步字节乱码会导致播放器无法识别TS结构报错往往就是fragparsingerror。如果用默认IV那要保证所有分片来自同一个加密流程MEDIA-SEQUENCE没有跟实际分片序号错位。播放器兼容性悬殊。hls.js、VLC、Safari原生播放器对AES-128支持都比较完善但一些智能电视、机顶盒、WebView内置播放器对加密流的支持很弱。有次客户反馈只有部分设备能播一查才发现是某品牌电视浏览器遇到了密钥请求的CORS问题又因为密钥URL带了自定义Header触发了先OPTIONS后GET的预检流程预检失败播放器就直接放弃了。这种问题只能靠实际设备矩阵去测没有一次性搞定的银弹。4. 多码流自适应Master Playlist是“导演”播放器是“观众”多码流自适应的核心不是某个播放器功能而是M3U8的分层结构。一个Master Playlist主索引不直接指向TS分片而是指向多个不同码率、不同分辨率的子播放列表。播放器会根据实时带宽和设备屏幕尺寸在子播放列表之间切换用户主观感受是“同一个视频画质在自动变化”。4.1 Master Playlist的结构解析一个通用的Master Playlist长这样#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH800000,RESOLUTION640x360,CODECSavc1.42c01e,mp4a.40.2 video-360p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH1400000,RESOLUTION1280x720,CODECSavc1.4d401f,mp4a.40.2 video-720p.m3u8BANDWIDTH的单位是bps不是kbps以前有人把800000理解成800kbps写成800结果播放器一上来就选最差的流画质糊得没法看。RESOLUTION是可选的但它能帮助播放器在做首屏选择时直接排掉分辨率过高的流减少不必要的缓存浪费。CODECS字段主要用于原生播放器提前判断自己能不能解码。主播放列表里还可以用EXT-X-MEDIA声明多音轨、多字幕、多角度但大多数业务用不到我这里就不展开了。4.2 自适应切换如何做到无感知GOP对齐与带宽估算多码流自适应看起来美好做不好就会频繁卡顿、画质来回跳。最核心的一点所有码流的切片时间边界必须对齐并且每个分片都要从IDR关键帧开始。如果360p的第三个分片时长是6.0秒720p的第三个分片也必须是6.0秒这样播放器切换码流时可以直接拉取新的分片解码不需要丢弃前一个流的缓冲内容。如何做到编码阶段就要让所有码流使用相同的关键帧间隔比如统一-g 60、-sc_threshold 0这样切片器才能在同样的时间点切出对齐的分片。很多转码服务说“支持多码率输出”但如果没做GOP对齐播放器照样可能在切换时花屏。播放器端的带宽估算策略也很关键。hls.js默认根据分片下载速度和缓冲长度来综合判断如果当前分片下载速度远高于当前码率说明带宽有余量它才会尝试切到更高码率如果缓冲量快要低于阈值它会先降级保流畅。这个策略可以通过abrEwmaFastDescend等参数调整激进程度但普通项目用默认配置就够了。实际生产环境中多码流通常不是由一个ffmpeg命令直接完成的而是对原始素材分别转成多路不同码率的视频每一路单独切片最后再生成一个总的Master Playlist。手工维护这套结构很繁琐所以我更推荐先用ffmpeg验证流程随后切换到云厂商的转码服务或自建转码集群来批量生产。5. 从fragparsingerror出发的完整排障链路做HLS对接时播放器报错是最常见的“打招呼”方式。hls.js这类库会把错误统一包装成mediaError具体原因在details字段里比如fragParsingError。这个报错字面上是“分片解析失败”但背后的真实原因五花八门必须一步步排查。5.1 hls.js的报错机制与常见根因fragparsingerror的高频根因我整理了一张表根因表现排查方向分片URL错误返回HTMLNetwork里分片请求是200但Content-Type是text/html不是video/mp2t看M3U8里的分片URL是否被路由或鉴权劫持分片文件本身损坏或截断部分分片可以播部分分片失败且失败位置不固定用ffprobe检查失败分片加密密钥拿不到或错误所有分片都失败播放器报错前有明显的key请求失败看EXT-X-KEY的URI能否访问key是否16字节TS封装不规范某些播放器能播、另一些不能播用ffprobe检查TS流SPS/PPS对比播放器差异CORS问题浏览器里报跨域非浏览器环境正常检查m3u8、ts、key三个请求的响应头有一次我排查vue播放m3u8的报错Network面板里每个分片请求都是200但播放器就是卡在fragparsingerror。把其中一个分片下载下来用ffprobe一看发现分片时长只有0.2秒原因是原视频关键帧间隔不稳定ffmpeg切片时生成了大量超短分片。播放器在处理边界超短分片时就崩了。5.2 逐步排查从HTTP状态到TS分片完整性我一般情况下按以下顺序排查先看M3U8内容。把URL在浏览器直接打开确认#EXTINF、分片URL、#EXT-X-KEY这些标签是否存在且顺序正确。直接访问分片URL确认返回的Content-Type是video/mp2t或application/octet-stream如果返回text/html基本被路由或鉴权劫持了。下载一个失败分片用ffprobe检查ffprobe -v error -show_format segment_000.ts如果输出Invalid data found when processing input分片肯定有问题。如果流是AES加密的这里要注意加密分片本身是密文不能用ffprobe直接解析要先拿到密钥解密后再检查。如果是浏览器环境打开Network面板检查三个关键请求m3u8、ts分片、key看是否有跨域报错。最后再用能播的播放器比如VLC跟hls.js做对照缩小问题范围。VLC能播而hls.js不能播大概率是播放器兼容性或CORS问题两边都不能播问题基本在源站。5.3 海康平台HLS对接的额外坑安防项目里经常要对接海康综合安防管理平台的HLS流。海康的WEB API能拿到类似http://ip:port/ISAPI/Streaming/channels/xxx/hls.m3u8的地址但直接用这个地址有坑设备流可能带鉴权参数比如session或token过期后需要重新拉URL。很多海康设备默认不返回CORS跨域头浏览器前端直接播放会报跨域错误。旧款设备输出的TS分片时间戳和EXTINF可能对不上hls.js在解析时会频繁告警甚至触发fragparsingerror。我的处理办法是不在前端直接连设备而是用后端服务拉取设备的HLS流做一层标准协议转换后再以统一的HLS输出给前端。这样既解决了CORS又能把不规范的设备流变成稳定、标准的分片序列前端的播放器兼容性问题也能一起收敛。6. 日常开发中用得上的命令与脚本片段最后分享一些高频命令和避坑经验都是我实际项目里反复用到的。6.1 ffmpeg切片的完整命令模板标准化点播切片我推荐用下面这条ffmpeg -i input.mp4 \ -c:v libx264 -preset veryfast -g 48 -sc_threshold 0 \ -profile:v main -pix_fmt yuv420p \ -c:a aac -b:a 128k -ac 2 \ -f hls -hls_time 4 -hls_playlist_type vod \ -hls_segment_filename out/seg_%03d.ts out/index.m3u8-pix_fmt yuv420p是为了兼容Safari和绝大多数播放器否则换成yuv444或10bit色深很多播放器就解码不了。-profile:v main的兼容性也比high更稳。直播滑动窗口切片可以采用这种形式ffmpeg -i rtmp://source/live/stream \ -c:v copy -c:a copy \ -f hls -hls_time 4 -hls_list_size 6 -hls_flags delete_segments \ /var/www/hls/live.m3u8-hls_list_size 6表示索引里只保留最近6个分片delete_segments表示删除已过期的分片文件。如果直播流需要加密需要额外加上-hls_key_info_file key_info.txt。key_info文件格式一共三行key.uri key.bin 0x00000000000000000000000000000001第一行是M3U8里暴露给播放器的密钥URL第二行是本地密钥文件的路径第三行是IV如果省略ffmpeg默认用分片序列号作为IV。注意key.bin必须是16字节生成方式前面说过了。6.2 m3u8转MP4以及转换失败的原因分析把m3u8转成mp4最常见的需求是下载回放。基础命令是ffmpeg -i index.m3u8 -c copy output.mp4不过HLS分片里的音频流是ADTS格式直接封装成MP4通常会遇到声道信息丢失问题更稳妥的命令是加上音频比特流过滤器ffmpeg -i index.m3u8 -c copy -bsf:a aac_adtstoasc output.mp4转换失败的原因我遇到的几乎就这三类M3U8是直播流没有#EXT-X-ENDLISTffmpeg会把当前这个“没有终点”的列表当成无限列表一直拉不到结束条件转出来要么失败要么文件不完整。分片或密钥下载失败。某一帧出错或某个分片404ffmpeg默认会因为读取错误中断。加密流没有提供密钥ffmpeg不能凭空解密。需要在命令里通过-hls_key_info_file指定密钥文件或者干脆先把解密后的分片合并再转封装。在动手转MP4之前先确认你对这个视频有合法处理权限。技术上能做到的事不等于就应该去做尤其是网上流传的各种m3u8地址很多都涉及版权问题这里不展开但希望每个人都守住底线。回到开头的那个fragparsingerror排查。后来我把播放器从H5切到VLC验证发现VLC能播就基本锁定了是播放器兼容性问题。再对比不同分片的ffprobe结果确认是原视频GOP不均匀导致超短分片。修复方式很简单重新转码再切片让GOP对齐到4秒。从那以后我在任何切片任务里都会先检查源视频的关键帧分布也会在切片脚本里自动保留一份ffprobe -show_frames日志备查。流媒体开发就是这样一次事故换一个教训踩过的坑多了链路自然就熟了。
