做流媒体这块也有几年了，从早期的RTMP推流到后来的WebRTC低延迟，轮番折腾下来，生产环境里用得最稳、维护成本最低的，反而是HLS这套组合拳。尤其是当需求里同时出现直播、点播、版权保护和网络自适应这几个词的时候，HLS+M3U8基本就是标准答案。今天我想把这条链路上的关键环节完整拆一遍：视频切片怎么切才不会翻车，AES加密怎么加才靠谱，多码流自适应怎么组织才算专业。文章偏实操，适合正在做视频服务、或者被HLS播放问题折磨过的人。
1. HLS这套方案，到底解决了哪些实际问题
先聊清楚HLS为什么能活到现在。HLS全称HTTP Live Streaming，苹果在2009年提出，设计初衷是把连续的视频流切成一个个独立的小文件，然后通过一个文本索引让播放器按顺序拉取。这么多年过去了，它的核心思路几乎没有变过：用纯HTTP静态文件协议去承载流媒体传输。
这和RTMP有本质区别。RTMP需要长连接，服务器要维护会话状态，CDN边缘节点要处理大量并发连接，一个节点挂了用户就断流。而HLS的每个切片是一个独立文件，CDN可以把它们当成普通静态资源来缓存和分发。用户看视频的过程，本质上是"持续下载一个个小文件"，这个行为静态加速节点天生就擅长。所以HLS对CDN极其友好，这是它在分发规模上碾压RTMP的根本原因。
对于点播场景，HLS的好处更加直观。一个两小时的电影，转成HLS之后就是几千个TS切片加一个M3U8索引。用户拖进度条，播放器直接计算目标时间点对应哪个切片，然后发起HTTP Range请求。因为每个切片可以独立缓存、独立分发，冷门片段和热门片段在CDN上是完全独立的热度单位，不会因为某一秒的内容特别火而把整个文件搞得很被动。
再说直播。HLS直播虽然在延迟上比不过WebRTC，但胜在稳定和跨端。它不需要客户端维持长连接，播放器每隔几秒去拉最新切片就行。网络抖动的时候，播放器可以通过缓冲几个切片来平滑波动，不会像RTMP那样因为一点卡顿就触发重连。而且HLS原生支持我们后面要讲的多码流ABR，同一场直播同时输出高清、标清、流畅三路，播放器根据网速动态切换，这套逻辑在RTMP里实现起来非常痛苦。
还有一个容易被忽略的点：HLS是文本索引加二进制切片的结构，天然适合做加密防护。虽然它不是DRM级别的保护，但AES-128加密后，直接抓走TS文件是没法播放的，这给内容方多了一道防护。后面我会专门讲这一块。
一句话总结：HLS适合"要规模、要稳定、要跨端适配、内容还需要基础保护"的所有场景。它唯一的短板是延迟，标准HLS通常在10到30秒不等，不过低延迟HLS的出现已经把这条线拉到了2到5秒，后面在直播章节细说。
2. M3U8索引文件解剖：一条流是怎么被"索引"出来的
很多人把M3U8叫m3u8索引，这个名字其实很准确。它本质是一份UTF-8编码的播放列表，里面每一行都是一个标签或者一个资源地址。播放器拿到这个文件之后，先读标签了解流的属性，再按顺序去拉取资源。下面我用几段实际例子带大家读懂这个文件。
2.1 最简单的点播切片列表长什么样
这是一份典型VOD（点播）播放列表：
#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:6 #EXT-X-PLAYLIST-TYPE:VOD #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:6.00000, segment_0000.ts #EXTINF:6.00000, segment_0001.ts #EXTINF:6.00000, segment_0002.ts #EXT-X-ENDLIST逐行解释一下：
#EXTM3U：文件头，声明这是M3U格式，所有合法播放列表第一行都必须是它。#EXT-X-VERSION:3：协议版本号。版本3支持浮点数的EXTINF时长，版本7支持LL-HLS的EXT-X-PART等标签。兼容性考虑，通常用版本3就好。#EXT-X-TARGETDURATION:6：声明切片的最大时长。播放器用这个值来估算缓冲时间，所有EXTINF的时长都不能超过这个值，否则播放器可能报错。#EXT-X-PLAYLIST-TYPE:VOD：告诉播放器这是完整点播文件，不会再有切片追加进来，可以放心支持拖拽。#EXT-X-MEDIA-SEQUENCE:0：序列号起点。直播流中这个数字会不断增长，表示当前列表第一个切片的序号。#EXTINF:6.00000,：后面紧跟的TS文件的时长，单位秒。- 切片文件名：可以是相对路径也可以是绝对URL，播放器会基于M3U8所在的地址做拼接解析。
#EXT-X-ENDLIST：播放列表结束标记。点播流必须有，直播流不能有。
这份列表的阅读逻辑就是：从第0个切片开始，按顺序下载，每个切片时长6秒，直到ENDLIST为止。
2.2 加密流里多出来的EXT-X-KEY标签
如果切片做了AES-128加密，播放列表里会多出这样一行：
#EXT-X-KEY:METHOD=AES-128,URI="https://cdn.example.com/keys/key.bin",IV=0x00000000000000000000000000000000它的位置在第一个被加密的切片条目之前，表示从这一行之后的所有切片都用这个密钥解密。播放器加载到这个标签后，会先去URI下载16字节的密钥文件，然后结合IV对每个TS文件做AES-128-CBC解密。
注意，如果密钥URI是相对路径（比如keys/key.bin），播放器会以M3U8所在URL为基准拼接完整地址。这个看似不起眼的细节，是后面很多"解密失败""转换失败"问题的根源，后面排错章节会细讲。
2.3 直播播放列表：会滚动的索引
直播切片不会一次性全部生成，而是像流水线一样持续追加。播放器看直播时拉取到的队列表是动态的：
#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:6 #EXT-X-MEDIA-SEQUENCE:100 #EXTINF:6.00000, segment_100.ts #EXTINF:6.00000, segment_101.ts #EXTINF:6.00000, segment_102.ts注意，这里没有#EXT-X-PLAYLIST-TYPE:VOD，也没有#EXT-X-ENDLIST。#EXT-X-MEDIA-SEQUENCE:100告诉播放器当前列表第一个切片是第100号。播放器每次刷新列表时发现新序列号，就继续往下拉。旧的切片会被服务器逐步移出列表，这就是"滑动窗口"。
理解这一点对处理直播很重要：播放器不会去列表之外的切片文件。如果播放器因为某种原因落后太多了，服务器已经删掉了它所需要的旧切片，播放器要么追帧、要么重新加载列表，严重的直接卡死。这就是直播和点播在HLS语义下最大的区别。
2.4 多码流主播放列表：索引套索引
多码流自适应时，我们面对的不再是一条播放列表，而是一个主列表（Master Playlist）加上若干个码率子列表。播放器先加载主列表，根据网速选择子列表加载。
#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=4500000,RESOLUTION=1920x1080,CODECS="avc1.64001f,mp4a.40.2" stream_1080p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,CODECS="avc1.4d001f,mp4a.40.2" stream_720p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=854x480,CODECS="avc1.4d001e,mp4a.40.2" stream_480p/index.m3u8其中BANDWIDTH是包含音视频在内的峰值带宽估值（单位bps），RESOLUTION是分辨率，CODECS是编解码器标识字符串。播放器根据这些元数据做阶梯选择，比如网速快就切高码率档，网速差就自动降档。如果流里有单独的外挂字幕或备选音频，还会出现#EXT-X-MEDIA标签去做音轨绑定，这个在基础HLS里用得不多，先不展开。
3. 视频切片实操：FFmpeg怎么切才不容易翻车
播放列表懂了，接下来就是怎么生成一份靠谱的切片。命令本身不复杂，但坑特别多，尤其是"切片边界不落在关键帧上"这个问题，能坑掉一大半新手。
3.1 为什么切片边界必须对齐关键帧
HLS的TS切片要做到"每个切片都能独立解码播放"。TS文件开头通常是第一个关键帧（IDR帧）开始的GOP（Group of Pictures）。播放器拉到一个切片后，直接从这个片段的起始关键帧开始解码，不依赖上一个切片。
如果切片边界恰好切在非关键帧上，播放器拿到一个"半截GOP"，画面就无法解码，表现出来就是切入时间点黑屏、花屏或者跳动。FFmpeg在切片时会自动把切片边界对齐到关键帧，但前提是编码器产出的关键帧间隔不能太散。
这就涉及两个参数的最小配合：
-flags +cgop -g 48 -keyint_min 48-g 48表示每48帧一个关键帧，-keyint_min 48确保关键帧间隔不会小于48帧。如果视频是24fps，正好2秒一个GOP；30fps就是1.6秒一个GOP。设置-hls_time 4时，FFmpeg会以4秒为目标时长寻找最近的关键帧作为切片边界，实际切出来的片段可能是4.0秒、也可能是4.05秒，这都是正常的。
3.2 点播切片的标准命令
对于VOD点播，一份比较稳妥的命令是这样的：
ffmpeg -i input.mp4 \ -c:v libx264 -crf 20 -preset medium \ -c:a aac -b:a 128k -ac 2 \ -flags +cgop -g 48 -keyint_min 48 \ -hls_time 4 -hls_list_size 0 \ -hls_playlist_type vod \ -hls_segment_filename "segment_%04d.ts" \ index.m3u8逐个参数说明：
-crf 20：视频质量因子，数字越小质量越高、文件越大。VOD点播我一般建议18到22之间，20属于画质和体积比较平衡的选择。-hls_time 4：目标切片时长4秒。为什么不是2秒也不是10秒？2秒会导致切片数量膨胀、请求量翻倍，CDN压力大而且播放器频繁请求列表也费电；10秒会让直播延迟更高，点播拖拽精度也变差。4到6秒是绝大多数流媒体平台的选择。-hls_list_size 0：生成的播放列表包含所有切片。如果这里不设成0，默认只会保留最近的5个切片，点播流就没法完整播放了。-hls_playlist_type vod：让播放列表带上#EXT-X-PLAYLIST-TYPE:VOD和#EXT-X-ENDLIST标记。-hls_segment_filename "segment_%04d.ts"：切片文件名模板，%04d就是四位数字补零。
如果源文件本身已经是H.264+AAC编码，切片的转码环节其实可以省略，直接用-c copy纯复制流，速度极快：
ffmpeg -i input.mp4 -c copy \ -hls_time 4 -hls_list_size 0 \ -hls_playlist_type vod \ -hls_segment_filename "segment_%04d.ts" \ index.m3u8但要注意，-c copy必须确保源文件的GOP天然对齐，否则切出来的切片在拖拽时容易出问题。
3.3 生产环境里的文件命名和时间戳策略
小规模自用怎么命名都行，一旦上了CDN或者客户端会缓存切片的场景，我强烈建议切片文件名中不要只有序号，而是加上时间戳或者内容哈希前缀。比如segment_1690000000_0000.ts。原因有两个：
第一，CDN回源排查时，看文件名就知道这切片是什么时候生成的；第二，如果你需要把切片重新组装成视频或者做离线打包，带时间戳的文件排序不会乱。而且如果切片属于同一个流的多个版本，建议用不同的目录名来隔离，避免文件名冲突导致CDN缓存串流。
这里还要注意一点：如果使用-hls_segment_filename时，路径中带有子目录（比如stream_1080p/segment_%04d.ts），FFmpeg会自动创建子目录吗？实测不一定。建议先手动mkdir好目录再跑命令，否则部分版本会直接报错。
3.4 切片时长和实际时长的偏差
你可能会发现，-hls_time 4切出来的切片，EXTINF写的是4.00000，但实际上有的切片可能是4.05秒，有的可能是3.94秒。这正常。因为切片以GOP边界对齐为目标，目标时长只是参考值。
但如果出现某个切片明显异常（比如EXTINF是8秒，远超#EXT-X-TARGETDURATION），那就要检查编码器GOP设置是否失效了。常见原因是源视频自己带着极大的GOP，而-c copy模式没有重新编码，FFmpeg只能按照源GOP边界切片，源GOP是8秒就只能切出8秒的块，TARGETDURATION也会被拉大到8，播放器缓冲量按最大值算，延迟就上去了。
所以，如果是直播流或者对延迟敏感的场景，宁可多花CPU重新转码，也不要图省事直接copy。GOP对齐这事，转码是唯一稳妥的解法。
4. AES-128加密：给TS切片加一把正经锁
讲完切片，来说说加密。HLS的AES-128加密方案很直接：每个TS切片整个文件做AES-128-CBC加密，密钥是一个16字节的二进制文件，播放列表里通过EXT-X-KEY标签告诉播放器密钥的获取地址。
4.1 HLS加密为什么选AES-128-CBC而不是其他算法
AES-128-CBC是HLS协议最早支持的加密方式，也是所有播放器、所有服务端库兼容性最好的一套。CBC模式会把每个切片分成若干16字节块，前一个块的密文参与下一个块的加密，形成链式依赖。切片开头用IV（初始化向量）作为第一个块的"前一个密文"。
关于IV，协议允许两种做法：一是直接在EXT-X-KEY标签里显式写IV=0x...；二是省略IV，这时默认取#EXT-X-MEDIA-SEQUENCE的值作为IV。显式写IV更可控，推荐生产环境使用。IV是16字节，通常写作32位十六进制字符串。
有一点要明确：每个TS切片独立加密，密钥是同一个，但IV通常会随切片序号变化。这样即使两个切片内容相同，密文也不同，可以防止有人通过比对密文推测内容模式。如果所有切片都用同一个IV，安全性会明显下降。
4.2 FFmpeg做AES-128加密的完整流程
FFmpeg的HLS muxer原生支持加密，准备工作需要两个文件：密钥文件（16字节随机数）和密钥信息文件（key info file）。
先生成密钥：
openssl rand 16 > key.key密钥文件必须是恰好16字节的二进制文件。注意，有些初学者用文本编辑器写一个16个字符的字符串当key，这是不对的。AES-128密钥要求128位即16字节二进制，openssl rand 16生成的才是合法密钥。
然后创建密钥信息文件key_info.txt，格式固定三行：
key.key https://cdn.example.com/keys/key.key 0x00000000000000000000000000000000第一行是本地密钥文件的路径（FFmpeg进程读取用）；第二行是播放器访问密钥的URL（会写进M3U8的EXT-X-KEY标签）；第三行是IV的十六进制形式，可以省略。如果你的环境不能确定IV，建议还是写显式IV，避免某些非主流播放器在IV推导上出现问题。
然后执行切片+加密：
ffmpeg -i input.mp4 \ -c:v libx264 -crf 20 -preset medium \ -c:a aac -b:a 128k \ -flags +cgop -g 48 -keyint_min 48 \ -hls_time 4 -hls_list_size 0 \ -hls_playlist_type vod \ -hls_key_info_file key_info.txt \ -hls_segment_filename "segment_%04d.ts" \ index.m3u8跑完之后打开M3U8，会在第一个切片前看到类似这样的标签：
#EXT-X-KEY:METHOD=AES-128,URI="https://cdn.example.com/keys/key.key",IV=0x00000000000000000000000000000000播放器遇到这个标签之后，后续所有TS都会先下载密钥再解密播放。
4.3 加密部署时的实际坑点
加密这条路上有几个坑，我踩过也帮别人排查过，这里集中列一下。
坑一：密钥文件访问权限和CORS问题。
播放器是浏览器里的hls.js时，密钥文件的请求同样受CORS限制。如果你的M3U8、TS都在cdn.example.com，而密钥文件放在keys.example.com，没有给keys.example.com配置Access-Control-Allow-Origin，浏览器会直接拦截密钥请求，表现为"能加载M3U8但视频一直黑屏"。解决方式有两种：要么把密钥文件和TS放到同一个域名下，要么给密钥目录配置CORS头。CDN边缘节点通常不能直接设置，需要在源站配置。
坑二：密钥URI的路径是相对还是绝对。
EXT-X-KEY里的URI写相对路径时，播放器以M3U8所在URL为基础拼接。如果你的M3U8在/video/stream/index.m3u8，URI写../keys/key.key，就会拼成/video/keys/key.key，而不是你可能预期的/keys/key.key。一旦拼错，播放器就下载不到密钥。在FFmpeg的key_info第二行我推荐直接写完整的绝对URL，虽然部署时稍微麻烦点（换域名就得改），但能大幅降低排错难度。
坑三：-c copy模式下加密效率高，但小心不标准的源流。
-c copy切加密流在FFmpeg里是支持的，速度飞快。但如果源TS里带有多音轨、多字幕轨或者非常规PID，copy切出来的切片在部分播放器上可能无法解密。我遇到过HLS播放器解密后画面正常但没声音的case，最后发现是音轨PID和PAT/PMT表不匹配导致的。这种情况重新转码AAC一般能解决。
坑四：EXT-X-KEY放在了错误的位置。
EXT-X-KEY标签只对它之后的所有切片生效。如果你在M3U8中间某处又插入了一个新的EXT-X-KEY，那么它只对后面的切片生效。如果这个新标签的URI写错，后面所有切片都会播放失败。调试时看到一个流前面几秒能播、后面突然黑屏，优先检查列表中间是不是混入了第二个EXT-X-KEY。
5. 多码流自适应：从单路流到完整的ABR阶梯
多码流自适应（ABR）的目标很简单：同一个视频内容，准备多路不同码率/分辨率的切片，让播放器根据网络带宽动态选择最合适的一路。用户网络好就看1080p，网络差自动降到480p，整个过程不能在画面上出现明显中断。
5.1 为什么需要多码流而不是单码流转码
单码流转码相当于"一刀切"，为了照顾最差网络，只能压得很低，好的设备也看不到高清画面；照顾最好网络，低配用户就不断卡顿。多码流是行业标配的解法：本质上是用多路转码的计算成本换取每个用户都能在自己网络条件下获得尽量好的体验。
另外，从成本角度说，转码计算的边际成本并不是线性增长的。同一个源同时产三路流的CPU开销，小于分别转三次的开销，因为视频解码只需要做一次，三路主要是编码和滤镜的差异。这也是FFmpeg单命令多路输出能够节省资源的原因。
5.2 用FFmpeg生成多码率切片的标准姿势
最省事、最不容易出错的做法是分别跑多路FFmpeg，每一路生成一个子目录：
ffmpeg -i input.mp4 \ -vf scale=1920:1080 -b:v 4500k -maxrate 5400k -bufsize 8000k \ -c:v libx264 -g 48 -keyint_min 48 \ -c:a aac -b:a 128k \ -hls_time 4 -hls_list_size 0 -hls_playlist_type vod \ -hls_segment_filename "stream_1080p/segment_%04d.ts" \ stream_1080p/index.m3u8 ffmpeg -i input.mp4 \ -vf scale=1280:720 -b:v 2500k -maxrate 3000k -bufsize 4500k \ -c:v libx264 -g 48 -keyint_min 48 \ -c:a aac -b:a 128k \ -hls_time 4 -hls_list_size 0 -hls_playlist_type vod \ -hls_segment_filename "stream_720p/segment_%04d.ts" \ stream_720p/index.m3u8 ffmpeg -i input.mp4 \ -vf scale=854:480 -b:v 1000k -maxrate 1200k -bufsize 2000k \ -c:v libx264 -g 48 -keyint_min 48 \ -c:a aac -b:a 96k \ -hls_time 4 -hls_list_size 0 -hls_playlist_type vod \ -hls_segment_filename "stream_480p/segment_%04d.ts" \ stream_480p/index.m3u8跑完之后手动写一个主播放列表：
#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=5000000,AVERAGE-BANDWIDTH=4500000,RESOLUTION=1920x1080,FRAME-RATE=25,CODECS="avc1.640028,mp4a.40.2" stream_1080p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2800000,AVERAGE-BANDWIDTH=2500000,RESOLUTION=1280x720,FRAME-RATE=25,CODECS="avc1.4d001f,mp4a.40.2" stream_720p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1300000,AVERAGE-BANDWIDTH=1000000,RESOLUTION=854x480,FRAME-RATE=25,CODECS="avc1.4d001e,mp4a.40.2" stream_480p/index.m3u8把这份主播放列表命名为master.m3u8放在根目录，播放器加载它就行。BANDWIDTH建议比实际编码码率留20%的余量，因为网络请求还有TS封装开销和TCP开销，写得太紧播放器会频繁切换。
5.3 三路流的切片时间必须严格对齐
多码流ABR切换的基础是：所有码率档位的切片时长必须严格对齐。1080p的第5个切片和480p的第5个切片，在时间轴上必须覆盖相同的时间范围。这样播放器从1080p切到480p时，只需要从下一个切片开始切换，不需要重新对齐buffer。
怎样保证时间对齐？FFmpeg在-g和-keyint_min相同的情况下，多路转码的GOP边界天然对齐，因为源帧率相同、GOP相同、切片的GOP边界相同。只要都用了-flags +cgop -g 48 -keyint_min 48，切片时长基本一致。
这里有个很容易踩的坑：如果三路命令中有一路忘了加-g，那一路的GOP间隔和另外两路不一致，切出来的切片边界就对不上。播放器切换时会出现跳帧、快进、卡顿甚至重复播放一小段。所以在批量生成多码率时，GOP参数必须完全一致。
另外，如果源视频是可变帧率（VFR），切片时长会漂移，多路流的对齐也可能出现偏差。稳妥的做法是先统一转换成恒定帧率（CFR），比如加-r 25或者-fps_mode cfr。
5.4 播放器端的自适应选择逻辑
在浏览器端，hls.js是目前最成熟的HLS播放方案。Vue项目里集成很简单：
import Hls from 'hls.js'; export function playM3u8(videoElement, url) { if (videoElement.canPlayType('application/vnd.apple.mpegurl')) { // Safari 原生支持 HLS videoElement.src = url; } else if (Hls.isSupported()) { const hls = new Hls({ maxBufferLength: 30, maxMaxBufferLength: 60, startLevel: -1 // -1 表示自动选择初始码率 }); hls.loadSource(url); hls.attachMedia(videoElement); hls.on(Hls.Events.ERROR, (event, data) => { if (data.fatal) { switch (data.type) { case Hls.ErrorTypes.NETWORK_ERROR: hls.startLoad(); break; case Hls.ErrorTypes.MEDIA_ERROR: hls.recoverMediaError(); break; default: hls.destroy(); } } }); } }hls.js默认会通过带宽估算自动选择码率，startLevel: -1表示首次加载时自动。它内部会估算下行带宽，并在每个分段下载后重新评估是否切换。你可以监听LEVEL_SWITCHED事件来感知切换动作：
hls.on(Hls.Events.LEVEL_SWITCHED, (event, data) => { const level = hls.levels[data.level]; console.log('切换到码率档:', level.height, level.bitrate); });实测中hls.js的ABR表现比较激进，网络稍微抖动就降档，这在移动端尤为明显。如果产品上希望减少频繁切换，可以在Hls构造函数里把abrEwmaDefaultEstimate调高一些，并且把capLevelToPlayerSize设为true，让它在小屏设备上不拉高清流，节省流量。
6. 直播场景下的HLS：滑动窗口、延迟和播放器配合
HLS直播和点播的切片逻辑底层相同，但播放列表管理完全不同。直播场景下，切片是持续生成的，播放列表会不断追加新条目、移除旧条目，播放器必须理解这种"动态索引"才能流畅追播。
6.1 点播和直播在M3U8上的关键差异
直接对比一下：
| 项目 | 点播 VOD | 直播 LIVE |
|---|---|---|
| 切片总数 | 固定不变化 | 持续增加 |
| 是否带ENDLIST | 有 | 无 |
| PLAYLIST-TYPE | VOD | 可省略或EVENT |
| MEDIA-SEQUENCE | 固定为0 | 随窗口滑动持续增长 |
| 播放器拖拽范围 | 整个文件 | 仅当前窗口内 |
| 典型切片保留 | 永久 | 根据窗口大小 |
播放器判断一个M3U8是不是直播，主要看有没有#EXT-X-ENDLIST。有就是点播，没有就是直播。#EXT-X-PLAYLIST-TYPE:EVENT是一个中间状态，表示当前还是在直播，但列表可能会保留所有历史切片，直到直播结束补上ENDLIST，变成可完整回看的点播文件。
6.2 滑动窗口是什么，为什么要滑动
服务器如果无限保留切片，磁盘会爆。所以直播场景通常只保留最近N个切片（比如最近2分钟）。这意味着播放器的可回看范围只有这2分钟。播放器每次重新加载M3U8时，看到MEDIA-SEQUENCE增加、列表头部的旧切片被移除，就明白自己已经落后了，需要追上去。
这种机制下，有一个我踩过很多次的坑：如果播放器暂停时间过长（比如用户离开电脑10分钟），回来之后它继续去拉之前记录的旧切片序号，但服务器早就删掉那些切片了，返回404，播放器就可能一直卡住。稳妥的做法是在直播播放器里监听网络错误或者缓冲超时，一旦发现切片404，就主动重新加载M3U8并跳到最新位置。hls.js在NETWORK_ERROR时默认会startLoad，但恢复速度不一定理想，移动端弱网时最好自己加一层逻辑。
6.3 HLS直播延迟怎么降
标准HLS延迟高的原因很好理解：播放器至少要缓冲2到3个TS切片。假设切片4秒，播放器拉完第一个切片之后并不会立即播放，而是要等后续两个切片就绪，防止网络抖动导致中断。这样一算，10秒以上的延迟是跑不掉的。
延迟敏感场景有两个主流解法。
第一是走LL-HLS（Low-Latency HLS）：切片进一步拆分成更小的part，播放器可以只等part就开播，而不必等整个TS。配合HTTP/2分帧，延迟能压到2到5秒。FFmpeg 5.0以上和hls.js 1.2以上都支持LL-HLS标签，具体命令需要加-hls_playlist_type event -hls_flags independent_segments并用-hls_segment_type fmp4配合-hls_fmp4_init_filename。当然，这套方案对CDN和播放器支持要求都比较高。
第二是走WebRTC推流、边缘转HLS再分发。这其实是一种混合架构：主播端用WebRTC低延迟上行，服务端拉流后切片为HLS，观众端仍然用常规播放器。它解决的是"主播到服务器的上行延迟"，下行观众延迟还是要看HLS本身的窗口。这类架构适合互动直播场景。
6.4 直播转点播的落地方案
很多产品希望直播结束后能回看，这时候EVENT类型的播放列表就特别好用。直播中它持续追加切片，直播结束后我们在列表末尾补上#EXT-X-ENDLIST，并把PLAYLIST-TYPE改成VOD，它就变成了一份完整的点播列表。所有历史切片如果之前一直保留着，观众就能从头开始拖拽回看。
实际生产里，我通常把切片长期保存到对象存储，直播结束后由服务端生成一个永久M3U8。注意，原始M3U8里的MEDIA-SEQUENCE可能不从0开始，补ENDLIST时不需要改序号，播放器自己会从列表定位。如果你希望回看的"进度条基准"从0开始，可以用FFmpeg重新处理一遍列表：
ffmpeg -i live_index.m3u8 -c copy -hls_list_size 0 -hls_playlist_type vod vod_output.m3u8但这种方式只能重写播放列表，不能修改源切片序号。所以更干净的做法是直播切片时就让MEDIA-SEQUENCE从0开始，窗口足够大，结束后直接复用。
7. 排错笔记：从转MP4失败到Vue播放黑屏的排查链路
HLS链路涉及的环节多，问题表象却高度相似：要么是播放黑屏，要么是转换失败，要么是播着播着卡住。这里我整理一张排查表，然后挑几个高频case展开。
7.1 高频问题速查表
| 症状 | 可能原因 | 优先排查点 |
|---|---|---|
| M3U8能加载但一直黑屏 | 密钥下载失败 / CORS拦截 / 切片跨域 | 浏览器的Network面板看密钥请求是否200 |
| 播放几秒后花屏或跳帧 | 切片边界未对齐关键帧 | 检查-g和-keyint_min，重新转码 |
| 只有声音没有画面 | 视频编码为H.265或非标准H.264 | 换用H.264 Baseline/Main编码 |
| ffmpeg转MP4失败 | 密钥无法访问 / 路径错误 / ts损坏 | 用ffprobe检查切片 |
| 直播暂停后回来卡死 | 播放器还指向已删除的旧切片 | 重新加载列表，跳到最新MEDIA-SEQUENCE |
| Vue里播放正常但报跨域错 | 服务器未配置CORS头 | 给静态目录加Access-Control-Allow-Origin |
7.2 "m3u8视频转换失败"的完整排查链路
这个热搜词出现频率很高。很多人拿网上现成的命令：
ffmpeg -i https://example.com/stream/index.m3u8 -c copy output.mp4结果报错或者产出的mp4只有几KB。排查顺序我建议这样走：
第一步，先直接用浏览器或者curl访问M3U8，确认索引文件本身可读。如果返回404或者403，问题出在URL鉴权或防盗链上，需要带上Referer、Cookie或签名参数。
第二步，打开M3U8看是否有EXT-X-KEY标签。如果有，说明流是AES-128加密的，FFmpeg能自动解密，但前提是密钥地址可访问。用curl单独访问一次密钥URI，确认返回的是16字节二进制。如果密钥也是404或者被WAF拦截，ffmpeg必然转换失败。
第三步，确认切片路径拼写。M3U8里的相对路径如果解析错误，FFmpeg会尝试去错误地址拉TS。建议开发阶段把M3U8、密钥、TS统一放在同一目录，避免路径解析的各种姿态。
第四步，看错误日志末尾有没有类似Invalid data found when processing input的信息。如果TS本身损坏，或者源流是H.265编码（HEVC），而你的FFmpeg编译版本不带对应解码器，也会失败。这时候要么升级FFmpeg，要么换用-c copy以外的转码方式：
ffmpeg -i index.m3u8 -c:v libx264 -c:a aac output.mp47.3 加密流转MP4失败和密钥策略的关系
很多加密HLS转MP4失败的真正原因，是密钥文件的访问策略。有些平台为了安全，生成的密钥URI是带时间戳签名的，比如：
#EXT-X-KEY:METHOD=AES-128,URI="https://cdn.example.com/key?token=xxxx&expires=1699999999"这种URL只在有限时间内有效。如果你在切片生成几小时后才去转码，密钥URL早过期了，FFmpeg下载密钥失败，转换当然失败。这也是为什么"一个HLS下载只能在前次下载120分钟后进行"这类工具限制会在网上被反复吐槽——本质就是平台做了临时密钥和防盗链，工具方没法绕过授权限制，只能等窗口重启。
对我们做系统的人来说，这个现象提醒我们：密钥的过期策略要和切片生命周期匹配。如果切片已经永久存档了，密钥就必须永久有效，否则回看会失败。如果切片只存7天，那密钥有效期设7天即可，过期后同步删除切片，不会出现孤岛数据。
7.4 Vue播放M3U8常见的三个坑
第一个坑是MSE兼容性。hls.js依赖MSE（Media Source Extensions），虽然目前所有主流浏览器都支持，但偶尔有用户用老版本浏览器或者某些套壳浏览器内核太旧，Hls.isSupported()返回false。代码里要有降级处理：Safari走原生播放，其他不支持MSE的浏览器给出明确提示，别让用户面对一个无法点击的播放器。
第二个坑是自动播放策略。浏览器普遍限制带声音的视频自动播放，Vue里初始化播放器后立即调用video.play()可能被拒绝，表现为"卡在首帧不播"。解决方法是监听用户交互（点击、滚动）后再调用play，或者给video加上muted属性做静音自动播放，用户需要声音时再取消静音。
第三个坑是跨域资源。video标签播放M3U8时，TS请求发生在video元素内部，但如果页面本身运行在https://a.example.com，M3U8在https://b.example.com，TS在https://c.example.com，视频资源域必须返回允许a.example.com请求的CORS头，否则hls.js会报Unable to fetch ...或者bufferStalledError。生产环境建议把视频域名和页面域名保持同根域，或者统一挂到CDN下并配置好CORS。
7.5 还没完：播放器buffer设置和弱网表现
最后补一个容易被忽略的优化点。hls.js的默认buffer参数是偏激进的，它希望尽快把足够多的数据拉进buffer，所以网速好时没问题，网速差时可能因为缓冲数据太少而频繁触发bufferStalledError。我的经验是弱网场景下这样配置更平滑：
new Hls({ maxBufferLength: 30, maxMaxBufferLength: 60, maxBufferSize: 60 * 1000 * 1000, // 60MB abrEwmaFastVoD: 3, abrEwmaSlowVoD: 8, startLevel: -1, });maxBufferLength控制在30秒左右，既不会让首屏太慢，也不会因为缓冲太多浪费流量。abrEwmaFastVoD和abrEwmaSlowVoD是带宽估算的EMA参数，调小可以让切换更敏锐，调大更稳定。实测中移动端网络频繁波动时，适当调大这两个值能明显减少来回切档的问题。
8. 我最后想说的几句实在话
视频技术这条链路，坑都藏在细节里。切片时长、GOP对齐、密钥有效期、播放器的buffer策略，任何一个参数设得不够讲究，线上就会以各种奇怪的方式反馈给你。我的经验是：先定好播放器兼容基线，再倒推服务端参数。如果目标播放器是hls.js+Safari双端，切片格式和加密方式就有明确的边界，不需要为了兼容所有可能设备而过度设计。
密钥安全这件事我想再多说一句。AES-128加密只能防住"把TS文件拷走直接播"的初级盗用，防不了屏幕录制，也防不了专业逆向。如果内容版权价值很高，请在这个基础上叠加自定义协议头、动态密钥分发或者商业DRM。别把HLS加密当成万能的版权保险箱，它只是把门槛从"零成本拿走"抬高到了"需要一定技术门槛"，这个定位才是合理的。
另外，切片文件的清理策略一定要提前设计。直播切片是高速生产的，一天24小时直播，按4秒一个切片算就是21600个文件，一周下来磁盘占用非常可观。建议用带日期的目录存储，配合定时任务删除过期切片，同时保存对应的M3U8作为点播索引。很多线上事故不是流拉不回来，而是磁盘满了切片写不进去，这种问题最难排查。
最后分享一个小技巧：联调阶段别用真实CDN域名，先在本地起一个带CORS头的静态文件服务，把所有切片、M3U8、密钥放进去，用hls.js直接指向本地路径调试。这样能绕开CDN缓存和跨域干扰，纯测播放逻辑。等本地验证过了再切到CDN域名，到时候再踩的坑基本就只剩CDN配置了。做流媒体调试，能把变量控制得越少，解决问题的速度就越快。
