4、视频分片：HLS/DASH分片策略、分片大小选择、GOP对齐

各位好，欢迎来到第四章。前面我们聊了编码参数和码率阶梯，但光有这些还不够。你想想看，一个两小时的4K电影，总码率就算压到20Mbps，那也是接近20GB的庞然大物。用户不可能一口气下载完再播放，对吧？

所以，我们需要把视频切成小块。这就是本章要讲的核心——视频分片。说白了，就是把一整块大蛋糕切成一口能吃下的小点心。HLS和DASH是目前最主流的两种分片协议，我会把它们的策略、分片大小怎么选、以及那个让无数人头疼的GOP对齐问题，一次性讲透。

4.1 HLS与DASH的分片策略

先说说HLS。苹果家的东西，历史最久。它的分片策略很直接：把视频切成一系列连续的.ts文件，每个分片时长固定。客户端通过下载一个.m3u8的索引文件，知道有哪些分片、每个分片在哪。

DASH呢？它更灵活。分片可以打包成单个文件（如mp4），也可以分片存储。它的MPD（Media Presentation Description）文件描述能力更强，支持多种编码、多种码率、多种语言轨道。我个人习惯把DASH看作“协议界的瑞士军刀”——功能全，但配置起来也复杂一些。

我在项目中遇到过这样一个场景：客户要求同时支持HLS和DASH，但他们的源文件是MP4。我们用了FFmpeg的dash封装器，一次性生成两种协议的索引文件和分片。嗯，这里要注意，虽然工具能同时生成，但分片策略必须统一，否则客户端切换协议时体验会不一致。

特性	HLS	DASH
容器格式	.ts（传统）或.fmp4（HLS fMP4）	.mp4（fMP4）为主
索引文件	.m3u8	.mpd
分片时长固定性	通常固定（如6秒）	可固定，也可可变
加密支持	原生支持（AES-128）	通过通用加密（CENC）
浏览器兼容性	iOS/Safari原生，其他需MSE	Chrome/Firefox/Edge原生

4.2 分片大小选择：不是越短越好

分片大小怎么定？这是每个流媒体工程师都会纠结的问题。我见过有人为了“极致低延迟”，把分片切成1秒。结果呢？服务器请求量暴增10倍，CDN费用直接起飞，客户端还因为频繁请求导致播放卡顿。

为什么会这样？因为分片太小，HTTP请求的开销占比就大了。每个分片都要建立连接、发送请求、接收响应，这些都有固定成本。分片太大呢？用户切换码率时，要等当前分片下载完才能切，切换延迟就高了。

我个人建议，常规场景下，分片时长选4到10秒。具体怎么选？看你的业务场景：

• 直播场景：追求低延迟，选2-4秒。配合Chunked Transfer Encoding，可以做到1-2秒延迟。
• 点播场景：追求稳定性和CDN效率，选6-10秒。6秒是业界最常用的值。
• 短视频场景：用户可能只看几秒，分片可以更短，比如2-3秒，但要做好预加载。

另外，分片大小还跟编码参数有关。假设你选了6秒分片，但GOP（关键帧间隔）设成了2秒。那一个分片里就有3个GOP。这没问题。但如果GOP设成了6秒，一个分片刚好一个GOP，那切换时就必须等这个GOP结束，灵活性反而降低了。

4.3 GOP对齐：自适应切换的命门

好，接下来是本章的重头戏——GOP对齐。这个问题，我当年刚入行时踩过一个大坑。

先解释一下什么是GOP。GOP（Group of Pictures）就是一组连续的画面，以I帧开头，后面跟着P帧和B帧。I帧是关键帧，可以独立解码；P帧和B帧依赖前面的帧。所以，解码器必须从I帧开始才能正确解码。

现在想象一下：你正在看720p的视频，突然网络变好了，客户端决定切换到1080p。如果两个码率的分片，它们的I帧位置不一样——比如720p的I帧在分片开头，1080p的I帧在分片中间——那客户端切换时，就会从一个非I帧开始解码。结果呢？花屏、绿屏、马赛克，直到下一个I帧出现才能恢复。

这就是GOP不对齐的后果。我曾经在一个项目中，因为编码器配置没统一，导致两个码率的GOP长度差了0.5秒。上线后用户投诉“切换时画面闪一下”，排查了两天才找到原因。

怎么实现GOP对齐？有两种主流方法：

1. 编码时强制对齐：在编码器参数中，设置-g（GOP大小）为固定值，并开启-sc_threshold 0（禁用场景切换检测，防止编码器自动插入I帧）。这样所有码率的I帧位置就一致了。
2. 后处理对齐：如果源文件已经编码好了，可以用FFmpeg的setpts和select滤镜，重新调整帧位置。但这种方法会损失画质，不推荐。

下面是一个FFmpeg的示例，生成GOP对齐的多码率HLS流：

ffmpeg -i input.mp4 \
  -filter_complex "[0:v]split=3[v1][v2][v3]; \
    [v1]scale=1920:1080[v1out]; \
    [v2]scale=1280:720[v2out]; \
    [v3]scale=854:480[v3out]" \
  -map [v1out] -c:v libx264 -b:v 5000k -g 48 -sc_threshold 0 \
  -map [v2out] -c:v libx264 -b:v 2500k -g 48 -sc_threshold 0 \
  -map [v3out] -c:v libx264 -b:v 1000k -g 48 -sc_threshold 0 \
  -map a:0 -c:a aac -b:a 128k \
  -f hls -hls_time 6 -hls_list_size 0 \
  -master_pl_name master.m3u8 \
  out_%v.m3u8

注意看，-g 48表示每48帧一个I帧（假设帧率24fps，就是2秒一个GOP），-sc_threshold 0禁止场景切换检测。这样三个码率的I帧位置就完全对齐了。

4.4 分片与GOP的协同设计

分片时长和GOP长度不是孤立的。它们必须协同设计。我见过一个常见的错误：分片时长设6秒，GOP长度设2秒，但分片边界和GOP边界没对齐。结果呢？一个分片可能从GOP中间开始，导致客户端下载后无法立即解码。

正确的做法是：分片边界必须落在GOP边界上。也就是说，每个分片的开头必须是一个I帧。这样客户端下载任意分片后，都能立即开始解码，不需要等待前一个分片。

怎么保证？很简单：

• GOP长度设为分片时长的整数分之一。比如分片6秒，GOP可以设2秒或3秒。
• 编码时强制I帧位置对齐到分片边界。
• 打包时（如用FFmpeg的hls或dash封装器），确保分片切割点与I帧位置一致。

下面这张图展示了分片、GOP、I帧之间的关系：

从图上可以看得很清楚：分片边界（蓝色块的边缘）和I帧位置（红色圆点）完全重合。每个分片包含3个GOP（绿色块），每个GOP时长2秒。这样客户端在任何分片边界切换码率，都能从I帧开始解码，不会出现花屏。

4.5 实战中的分片策略选择

最后，我总结一下不同场景下的分片策略选择。这些是我在实际项目中验证过的，你可以直接参考：

场景	分片时长	GOP时长	分片内GOP数	备注
低延迟直播	2秒	1秒	2	配合Chunked Transfer，端到端延迟可控制在3秒内
常规点播	6秒	2秒	3	最通用配置，兼容性好
高码率4K点播	10秒	2秒	5	减少分片数量，降低CDN压力
短视频/竖屏	2-3秒	1秒	2-3	用户停留时间短，需要快速启动
教育/会议录播	4秒	2秒	2	兼顾低延迟和稳定性

好了，关于视频分片的核心内容就这些。记住三个关键词：分片时长、GOP对齐、协同设计。把这三点做好了，你的自适应流系统就成功了一大半。