1. 项目概述与需求拆解
1.1 为什么突然想研究 ffmpeg + HLS
做流媒体这块的同行应该都有体会，无论你是做直播、点播，还是视频处理工具，几乎绕不开两个东西：一个是ffmpeg，另一个就是HLS。
ffmpeg 本身不用多介绍，音视频领域的老黄牛，能解、能编、能转、能切、能推流，你想到的常规操作它基本都覆盖了。而 HLS（HTTP Live Streaming）是苹果搞出来的基于 HTTP 的流媒体传输协议，把一段连续的视频流切成一个个小的分片文件（一般是 TS 或 fMP4 格式），再通过一个索引文件（m3u8）把这些分片串起来，播放器按顺序拉取播放。
这次我做的"ffmpeg-hls 使用测试研究"，目标很直接：把 ffmpeg 生成 HLS 流的完整流程跑通，摸清楚每个参数的实际影响，并且验证它在点播和直播两种场景下的表现。不是停留在"照抄命令能跑就行"的层面，而是真的去了解每个参数为什么要这么设、设了之后会有什么效果、遇到问题怎么排查。
这个研究过程适合谁参考？我觉得有三类人：
- 刚接触音视频处理，想搞懂 m3u8 和 ts 分片是怎么生成的后端开发；
- 做直播或点播系统，需要在服务器上自己切流、推流的运维或架构师；
- 手头有视频资源想转成 HLS 格式部署到 Web 或 App 上，但又不想被商业云服务绑架的独立开发者。
我踩过的坑、调过的参数、验证过的方案，下面都整理出来了。
1.2 测试前的环境准备
先说下我这次测试用的环境，方便你对照：
- 操作系统：Windows 11（另外在 Ubuntu 22.04 上也做了验证）
- ffmpeg 版本：6.1.1 完整版（Windows 下建议直接下载 release-full 版本）
- 推流测试的服务器：SRS 5.0 社区版，部署在同一台局域网机器上
- 播放器：VLC、浏览器原生 HLS 播放（Safari/Chrome 配合 hls.js）
- 测试源文件：一段 1080p、时长大约 10 分钟的 MP4 视频，码率 4000kbps
Windows 下装 ffmpeg 说简单也简单，说坑也坑。官网提供的是解压版，解压后把bin目录路径加进系统环境变量PATH里，命令行里就能直接敲ffmpeg了。这里有个我踩过的坑：加完环境变量后一定要重新打开终端窗口，否则不生效。另外，如果你之前装过旧版本，重装系统后再用，很大概率是 PATH 里残留了旧路径或者变量值失效，解决办法是先where ffmpeg看一下当前生效的是哪个路径，再用ffmpeg -version验证版本，指向不对就改环境变量。
Ubuntu 下装了 265 编码需求的，建议别图省事直接用 apt 装老版本。我之前为了测 libx265，老老实实用源码编译了一版，具体步骤是：
sudo apt update sudo apt install build-essential yasm cmake libx265-dev libx264-dev wget https://ffmpeg.org/releases/ffmpeg-6.1.1.tar.gz tar -xvf ffmpeg-6.1.1.tar.gz cd ffmpeg-6.1.1 ./configure --enable-gpl --enable-libx264 --enable-libx265 --enable-libmp3lame make -j$(nproc) sudo make install如果你的场景只需要软编 x264，官方 release 包就够了；但要做 265 编码就必须自己编。另外一个容易忽略的点是：源码编译前先确认磁盘空间至少 2GB 以上，编译时间视机器性能从几分钟到半小时不等，我编译的时候因为选了太多组件，中间还因为缺库失败过一次，后来按需裁剪 configure 选项才通过。建议一开始就按需选择组件，别一股脑全开。
2. HLS 核心设计与方案选型思路
2.1 HLS 到底解决了什么问题
在讲具体用法之前，我先花了点时间把 HLS 的原理捋清楚，因为这直接决定了后面参数怎么调。
HLS 的核心思路可以类比成"把一本书拆成单页发快递"。传统的视频文件是一个整体，播放器必须从文件头开始读，边下边播，但一旦遇到网络波动，很可能缓冲半天也没法播起来。HLS 的做法是把一部视频切成几秒钟一小段的分片（比如每 6 秒一个 TS 文件），再生成一个目录清单 m3u8。播放器拿到 m3u8 后，先看清单里有哪些分片，按顺序拉取第一个分片、开始播放，同时在后台预加载后面的分片，这样只要网速够快，用户几乎感知不到"文件正在加载"的过程。
从工程角度来说，HLS 最大的优势有两个：
- 纯 HTTP 传输，不依赖特殊协议，CDN、Nginx、对象存储都能直接扛流量，没有防火墙和端口封禁的烦恼。
- 自适应码率，可以在 m3u8 里声明多档码率的流，播放器会根据当前网速自动切换，实现无缝升降级。
这两点直接决定了为什么这么多年过去，RTMP 逐渐退潮，HLS 至今稳坐 Web 端直播和点播的头把交椅。而且苹果生态全系原生支持 HLS，不用装任何插件。
2.2 为什么切流这个活适合用 ffmpeg 干
HLS 协议本身并不是 ffmpeg 独有的，Nginx 的 nginx-rtmp 模块能切片，SRS 服务端也可以直接输出 HLS，为什么我仍然建议用 ffmpeg 来做切流？
因为 ffmpeg 有一个别人比不了的优势：它可以灵活地处理输入源。无论你的输入是本地文件、HTTP 拉流、RTSP 摄像头流、还是设备采集的裸流，ffmpeg 都能先统一做解码、滤镜处理、再编码，最后封装成 HLS。你可以在切流的同时顺手完成分辨率缩放、加水印、音视频增益、抽帧等操作，等于一条流水线解决所有预处理。
举个实际例子。这次测试时我需要对源视频做响度统一，就只加了一个滤镜参数：
ffmpeg -i input.mp4 -af loudnorm=I=-16:TP=-1.5:LRA=11 -c:v copy output.mp4这个命令把音频响度统一到 -16 LUFS，同时保持视频流原样拷贝（-c:v copy），实测下来效率很高。如果你用服务端切片功能，这些预处理要么不支持，要么得提前单独跑一遍，链路变长还容易出错。而 ffmpeg 全都能在切片那一步搞定，这是它作为"瑞士军刀"的核心价值。
另外一点是ffmpeg 的切片定位非常准确。它依据视频的关键帧位置来切分，不会出现"切片点落在非关键帧导致播放器花屏"的问题。切片命令里的-hls_time是一个目标时长，实际切割位置会自动对齐到最近的关键帧，这一点在直播场景里极其重要，后面细说。
2.3 点播 vs 直播：同一个 HLS 两种玩法
做测试研究时，我特意把 HLS 的两种主要场景分开跑了一遍，因为它们的需求完全不同：
点播场景（Video on Demand）：一个完整的视频文件，切成几十个分片，m3u8 是固定的，包含全部分片列表，末尾有#EXT-X-ENDLIST标记。这种场景下缓存友好、可以拖动播放、可以倍速，对分片的数量没有限制。适合做视频网站、在线课程等。
直播场景（Live）：持续产生分片，m3u8 里的分片列表是动态更新的，旧的会被移除，新的不断追加，m3u8 末尾不允许有#EXT-X-ENDLIST标记（结束标记会直接告诉播放器"这是点播流，播完即止"）。这种场景要求"边切边播"，对切片的及时性和生成速度有较高要求，而且分片列表窗口大小会直接影响直播延迟。
用 ffmpeg 实现这两种场景，参数差异非常明显。我把两种场景的核心命令分别整理在下面的实操章节里，方便你对照使用。
3. ffmpeg 生成 HLS 核心命令与参数深度解析
3.1 点播场景：一条命令切出完整 m3u8
最基础的点播切片命令如下：
ffmpeg -i input.mp4 -c copy -hls_time 10 -hls_list_size 0 -hls_segment_filename "output_%03d.ts" output.m3u8拆开看每个参数的意义：
-c copy：直接拷贝音视频流，不做转码。这里的坑在于：只有输入文件的编码格式符合 HLS 要求（比如 H.264 + AAC）时才能用 copy，如果源文件是 AV1 或者 PCM 音频，必须改成具体的编码器，否则生成的分片播放器根本播不了。-hls_time 10：目标切片时长 10 秒。但前面提到了，这不是硬性值，ffmpeg 会以关键帧为界对齐，实际每片可能在 9.5~11 秒之间浮动。-hls_list_size 0：播放列表包含所有分片。在点播场景必须写 0，否则默认只保留最后 5 个分片，用户播放 30 秒后的视频就没法从开头拉流了。-hls_segment_filename：分片文件名的模板，%03d表示三位数字序号，会生成 output_000.ts、output_001.ts 这样的文件。- 最后的
output.m3u8：指定 m3u8 文件的输出路径和名字，ffmpeg 会在文件里自动写好每个分片的相对路径。
跑完这条命令后，你会看到同目录下出现了一堆 ts 文件加一个 m3u8 文件。m3u8 的内容长这样：
#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.000000, output_000.ts #EXTINF:10.000000, output_001.ts ... #EXT-X-ENDLIST这个文件其实就是整个播放过程的"剧本"，播放器按顺序读取即可。
3.2 直播场景：边推边切的关键配置
直播场景下，我的典型命令是这样：
ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f hls -hls_time 6 -hls_list_size 5 -hls_flags delete_segments -hls_segment_filename "live_%03d.ts" live.m3u8这里面有几个关键差异：
-re：以原视频的真实帧率读取输入，否则 ffmpeg 会以最快速度把文件处理完，"直播"瞬间变成"点播"。这个参数理解成"按时间轴匀速放送"就对了。-hls_list_size 5：m3u8 里最多保留 5 个分片，形成滑动窗口，播放器会跟着窗口走。窗口越小，延迟越低，但也越容易出现播放器赶不上切片生成速度的情况。-hls_flags delete_segments：自动删除已经不在 m3u8 播放列表里的过期分片，防止磁盘被撑爆。这个参数在长时间直播场景下必须加，否则分片只会越来越多。
这里我还想说一个比较深刻的教训：直播切片时长直接决定观众的延迟感知。如果分片是 6 秒一片，播放器一般要累计 3 个分片才启动（约 18 秒），再加上网络传输时间，实际延迟可能到 20 秒左右，这还算正常。如果你想做低延迟直播，可以试试把-hls_time压到 1~2 秒，并在服务端开启 LL-HLS（Low-Latency HLS）支持，但这对编码器和服务器性能都有要求，不是简单改个参数就能完美跑起来的。
3.3 编码参数配合：GOP 大小与切片时长的关系
这是我在研究过程中觉得最容易忽略、但影响最大的一组配合。其实 HLS 切片的起点必须放在关键帧（IDR 帧）上。如果你的编码器把 GOP（两个关键帧之间的间隔）设成了 60 帧（2 秒），但你切片参数写的是-hls_time 10，那最终切出来的分片时长不会是 10 秒的整数倍，而是 GOP 时长的整数倍——最短也不可能比 2 秒还短。
所以实际生产环境里，切片时长应当和 GOP 尺寸对齐。比如你打算做 4 秒切片，编码参数就要设置对应的 GOP：
ffmpeg -re -i input.mp4 -c:v libx264 -x264-params "keyint=120:min-keyint=120:scenecut=0" -c:a aac -f hls -hls_time 4 live.m3u8这里keyint=120表示每 120 帧一个关键帧（25fps 下就是 4 秒），scenecut=0是禁用场景切换自动插入关键帧，保证关键帧间隔稳定。如果不管 scenecut，画面切换剧烈时编码器会提前插入关键帧，导致切片时长忽长忽短，直播流的更新节奏会被打乱。
我在实测中发现，GOP 设置得过大会导致延迟飙升，设置得过小会浪费码率。一般建议就是根据目标切片时长换算，保持两者基本一致或切片略大于 GOP 长度，这样每个分片都以关键帧开头，播放器拉流时立即能解码出画面。
4. 实操全流程：从点播切片到直播推流完整复现
4.1 本地生成 HLS 点播流并验证播放
我实际操作的流程如下。先用一个 10 分钟的 MP4 做测试源，放在D:\test\hls_test\目录下：
cd /d D:\test\hls_test ffmpeg -i input.mp4 -c copy -hls_time 10 -hls_list_size 0 -hls_segment_filename "output_%03d.ts" output.m3u8执行时间取决于磁盘速度和文件大小。对 10 分钟 1080p 的视频，-c copy模式大约 20 秒就完成了，几乎不用等待。然后我用 VLC 打开 output.m3u8，拖动进度条到任意位置，都能秒切画面并且无卡顿，说明切片完整。
但有一个问题值得注意：如果你用浏览器直接file://协议打开本地 m3u8，Chrome 大概率会报错。原因在于浏览器不允许通过 file 协议跨文件读取分片内容，而且 m3u8 和 ts 的路径解析也会出问题。你需要起一个本地 HTTP 服务来做验证，我常用一条命令解决：
python -m http.server 8080然后浏览器访问http://localhost:8080/output.m3u8，配合 hls.js 或直接拖进 Safari 就能正常播放。这一点对测试很有用，很多人第一次生成 m3u8 后打不开，往往不是切片有问题，而是访问方式不对。
4.2 把 HLS 流部署到 Nginx 上供公网访问
本地验证通过后，我把它部署到了 Nginx 上，模拟真实点播环境。Nginx 只需要配置静态文件服务，关键点是确保 m3u8 和 ts 文件都在同一个公开目录里，并且给 ts 文件配置正确的 MIME 类型：
server { listen 80; server_name media.example.com; location /hls/ { alias /opt/www/hls/; types { application/vnd.apple.mpegurl m3u8; video/mp2t ts; } add_header Cache-Control no-cache; } }配置里的Cache-Control no-cache对直播流尤其重要，不然 CDN 或浏览器可能把 m3u8 缓存住，导致直播列表不更新、观众一直停留在旧画面。如果是纯点播，则可以根据实际需求移除这行，让分片充分利用缓存加速。
部署完成后，我测试了 Safari 和 Chrome 下的播放体验。Safari 原生支持 HLS，不需要任何前端库；Chrome 则需要引入 hls.js 才能播放 m3u8。如果你在做 Web 播放器，建议直接用 video.js 配合 hls.js 扩展，成熟稳定，不用重复造轮子。
4.3 直播推流到 SRS：完整链路搭建
直播场景的完整链路我选了 SRS，因为它在 HLS 切片和 RTMP 推流之间做了很好的衔接。整个链路是这样的：
ffmpeg 推 RTMP 流 → SRS 接收 RTMP 流 → SRS 切片生成 HLS 流 → 播放器拉取 m3u8 播放先启动 SRS，配置文件里开启 HLS 输出。SRS 5.0 的配置片段如下：
listen 1935; max_connections 1000; vhost __defaultVhost__ { hls { enabled on; hls_path /usr/local/srs/objs/nginx/html; hls_fragment 6; hls_window 30; } }然后在 ffmpeg 这边，本地视频文件模拟推流：
ffmpeg -re -i input.mp4 -c:v libx264 -profile:v main -preset veryfast -tune zerolatency -c:a aac -f flv rtmp://192.168.1.100/live/test这条命令在编码参数里特别加了-tune zerolatency，这是低延迟场景的经典配置，减少编码缓冲。推流过程中，SRS 会自动生成 m3u8 和 ts 分片，我通过http://192.168.1.100/live/test.m3u8拉流验证，VLC 基本 15 秒左右起播。
这里有一个非常关键的体验要分享：整个链路的瓶颈通常不在 ffmpeg，而在 GOP 设置和切片时长。第一次测的时候我没有设置 GOP，用的是默认配置，结果切片时长忽长忽短，播放器缓冲频繁，延迟到了 30 秒以上。把编码参数固定为keyint=120之后，切片稳定了，延迟降到 18 秒左右。对于非低延迟场景这个数值可以接受，但要做真正的低延迟直播，还得上 LL-HLS 或者换 WebRTC 方案。
4.4 常用验证手段与复盘方法
做完整链路测试后，建议养成一个习惯：每次推流结束后，把产生的 m3u8 内容拉出来看一眼。m3u8 里的时间戳、序列号、分片个数都是重要的诊断信息。比如#EXT-X-MEDIA-SEQUENCE:5说明当前播放列表从第 5 片开始，如果这个数字一直涨，说明窗口在正常滑动；如果数字不变，说明列表更新有问题。
另外推荐一个小工具：ffprobe（ffmpeg 自带）。当播放器播不了流时，先用它检查一下源文件和推流后的流信息：
ffprobe -v error -show_format -show_streams http://192.168.1.100/live/test.m3u8它能列出流的编码格式、分辨率、码率、帧率等关键信息。有一次我推流后播放器黑屏，用 ffprobe 一查发现音频编码是 flac 格式，而 HLS 并不支持这种编码，改成 AAC 后问题消失。很多排查工作其实在 ffprobe 这一步就能解决大半。
5. 测试中的常见问题与排查实录
5.1 播放器一直转圈，起播失败
这个现象我测了两次都有，一次是切片格式不对，一次是 m3u8 路径问题。排查思路按顺序来：
- 先看 m3u8 内容：用文本编辑器打开，确认是否有
#EXT-X-ENDLIST（点播）或#EXT-X-MEDIA-SEQUENCE（直播），如果 m3u8 是空的或者只有开头几行，那说明切片还没生成完，或者生成失败。 - 用 VLC 打开 m3u8 文件：VLC 对错误格式的容错率高于浏览器，如果 VLC 能播而浏览器不能，大概率是分片跨域访问或 MIME 类型的问题。
- ffprobe 检查分片：对单个 ts 文件执行
ffprobe output_000.ts，确认里面确实有视频流和音频流。有时你用-c copy切片，但源文件的音频是 PCM 格式，ffmpeg 会报错，生成的 ts 里可能只有视频没有音频，用户看到的就是"画面是黑的"或者"无声"。
我实际踩过的场景是第一次用-c copy切一个 MKV 文件，源文件里带的是 PGS 字幕轨道和一个不兼容的音频流。切出来后在 VLC 里勉强能播，但移动端浏览器直接失败。后来加了-map 0:v:0 -map 0:a:0 -c:v copy -c:a aac，只保留首个视频轨和首个音频轨，并把音频统一转成 AAC，问题彻底解决。建议你在切片前先用ffprobe -show_streams input.mp4看清楚流轨道结构，再决定是否需要显式-map。
5.2 直播列表不更新，画面停在旧帧
直播场景下最常见的问题是：观众看到的画面一直停留在推流开始时的某一帧，或者播放器隔几分钟才刷新一次。
如果你用的也是 ffmpeg + Nginx/SRS 链路，优先排查这几个点：
- 检查 m3u8 的
#EXT-X-MEDIA-SEQUENCE是否持续增长。如果不涨，说明切片环节卡住了，大概率是 ffmpeg 进程挂了或者编码器报错。看 ffmpeg 终端的输出，如果有 error 关键字就要处理。 - 确认 HTTP 层没有缓存。Nginx 默认可能给静态文件加 Expires 头，导致播放器拉取 m3u8 时得到的还是旧内容。m3u8 的 location 块里务必加
add_header Cache-Control no-cache，这是我在生产环境里反复强调的点。 - 检查播放器配置。部分播放器对 HLS 直播有缓存参数，比如 hls.js 默认的
liveSyncDurationCount是 3，也就是至少保留 3 个分片的缓冲才起播，如果你想降低延迟，可以把这个值改小，但太小的代价是缓冲不足导致频繁卡顿。
5.3 延迟太高怎么办
延迟 20~30 秒是普通 HLS 的正常水平，很多人第一次做完直播后觉得"这也叫直播"，不好意思，HLS 就是这个调性。它本来就是以牺牲低延迟换取稳定性和 CDN 友好性。如果你的场景真的需要低延迟，实测下来有两条出路：
- 改进型 HLS（LL-HLS）：把切片切得更细（1~2 秒），并对 m3u8 增加分片预加载提示（
#EXT-X-PART），播放器可以更早开始播放。ffmpeg 6.0 以上版本可以这样开启：
ffmpeg -re -i input.mp4 -c:v libx264 -g 25 -f hls -hls_time 1 -hls_flags independent_segments+ll_hls live.m3u8不过要注意，LL-HLS 需要播放器端也支持，不能指望 VLC 或者所有 Web 播放器都能完美跑通。
- 换 WebRTC：直播延迟能压到 1 秒以内，但工程复杂度完全不同，对信令服务、SFU 服务器的要求都更高，适合实时互动场景。
我个人在实际项目里的取舍是：如果延迟容忍度在 10~30 秒，就继续用普通 HLS，简单可靠；如果要求低于 5 秒，直接上 WebRTC，别在 HLS 上硬撑。
5.4 分片越来越多导致磁盘被占满
长时间直播测试中，我还真把磁盘跑满过一次。原因就是漏了delete_segments参数。你在本地测试短时间推流可能感觉不到，但连续直播几小时后，分片文件数量和体积都会很恐怖。按 6 秒一片、每片约 4MB 算，一小时就是 600 片、2.4GB，一天下来 57GB。所以直播切流必须加：
-hls_flags delete_segments这个参数保证只有 m3u8 列表里保留的 5 个分片存在磁盘上，其余被自动清理。如果你需要更长的回看窗口，可以结合-hls_list_size调大到 30 或 60，但磁盘消耗也要相应承受。
5.5 移动端播放 HLS 常见兼容性问题
测试过程中我在 iOS Safari 和 Android Chrome 上各跑了一遍，发现一些平台差异：
- iOS Safari：对 HLS 原生支持，但要求 m3u8 响应内容的 Content-Type 必须是
application/vnd.apple.mpegurl或application/x-mpegURL，否则直接拒绝播放。Nginx 配置 MIME 时要特别注意。 - Android Chrome：原生不支持 HLS，必须用 hls.js 或类似的 JS 库。如果用了 hls.js 还是播不了，打开浏览器开发者工具看网络请求，确认 ts 请求是否存在 404 或跨域报错。
- 跨域问题：m3u8 和 ts 分片如果在不同域名下，播放器拉流会被 CORS 策略拦截。需要在服务端加 CORS 头：
add_header Access-Control-Allow-Origin *;这个头在直播测试时经常被忽略，但却是移动端播放失败的最常见原因之一。我在真机上踩过这个坑，当时放到线上才发现安卓播放全部黑屏，最后加上这个头后才解决。
6. HLS 测试中的一些心得与建议
6.1 深入研究时不要只看命令，要看数据
这次测试研究做下来，我最大的感受是：ffmpeg 的 HLS 相关参数并不复杂，真正复杂的在于理解你手头流媒体的特性。比如 GOP、码率、分辨率、音视频编码格式，这些指标之间互相牵制，任何一个不合理，最终都会反映到播放端的体验上。
建议你像我一样，测试完每一组参数后都记录一张表格，对比切片时长、延迟、文件大小、播放器起播时间。不要觉得麻烦，真实项目里排查问题时，这些历史记录就是你最可靠的参考资料。我这次整理了十几个不同参数组合的测试数据，在写这篇文章时帮了大忙。
6.2 生产环境里别迷信某个"最佳参数"
很多人喜欢在网上搜一套"万能命令"直接上生产，这在简单场景下问题不大，但在复杂场景下很容易翻车。比如直播流的hls_time，点播场景可能用 10 秒没问题，但直播场景同样的参数会导致起播时间成倍增加；再比如hls_list_size，点播必须为 0，直播却要根据窗口期合理设置。没有万能参数，只有适配具体场景的参数。
6.3 最后一个建议：从测试走向生产前做好监控
如果你打算把 ffmpeg + HLS 方案放到生产环境，除了验证功能流程，一定要补上监控。具体来说三个点：ffmpeg 进程是否存活、m3u8 文件是否持续更新、分片生成有没有积压。这三个指标基本能覆盖大多数故障场景。我自己在测试时会写一个简单的脚本定时拉取 m3u8 并检查最新的#EXT-X-MEDIA-SEQUENCE是否递增，一旦发现长时间不变就触发告警。这种小工具成本很低，但关键时刻能救命。
这次 ffmpeg-hls 的测试研究到这里算是告一段落。回头看看，好像也没有特别高深的技术在里面，但正是这些琐碎的参数验证和问题排查，把 HLS 从"文档里的一个协议"变成了我手里一个随时能用的工具。希望这篇记录能帮你少走一些弯路。
