FFmpeg+Nginx+Rtmp+HLS+Videojs搭建直播网站（理论与实战）

这套资料的主题很明确：用 FFmpeg 做推流与转码，Nginx 配合 RTMP 模块接收流，再由 HLS 切片对外分发，前端用 Video.js 播放。整条链路是自建直播站点的经典组合，不依赖第三方云服务，适合想搞清楚"一路流从采集到播放到底经过了什么"的开发者。它不是单纯讲某个中间件的配置手册，而是把四个组件串成一条可运行的流水线，重点在协议衔接和参数对齐。

技术栈的分工与边界

先理清每个组件在链路里的位置，后面调参才不会乱。FFmpeg 负责输入侧的协议适配和编码转换，可以吃摄像头、本地文件、RTSP 流，输出推到 RTMP 地址；Nginx 通过 nginx-rtmp-module 承担两个角色，一是 RTMP 服务端接收推流，二是调用 HLS 模块把流切成 m3u8 与 ts 分片；HLS 本身不是软件而是 Apple 定义的流媒体协议，靠 HTTP 分发，天然穿透 CDN 和大多防火墙；Video.js 是播放器层，用 videojs-contrib-hls 或浏览器原生支持消费 m3u8。理解这个分层，遇到"推流成功但播放 404"或"延迟忽高忽低"时，就能按 RTMP 接收、切片生成、HTTP 访问三段分别排查，而不是整体瞎试。

项目结构与可复用模块

工程部分的价值在于目录约定和配置模板。典型结构会区分 Nginx 配置目录、HLS 切片输出目录、FFmpeg 推流脚本、前端静态页面几块，切片目录需要正确的写权限，否则 nginx 报错但日志不直观。可复用的东西包括：一份带 rtmp 与 hls 两个 block 的 nginx.conf 片段，其中 hls_path、hls_fragment、hls_playlist_length 三个参数决定了延迟与卡顿的平衡；一套 FFmpeg 命令行模板，覆盖 -re 限速推流、-c:v libx264 关键帧间隔对齐切片、-g 与 -hls_time 的匹配关系；以及一个最简 Video.js 页面，处理自动播放策略和直播源地址。这些模块抽出来，换业务场景时只需改推流地址和切片时长，不用重写。

实战中真正会卡住的点

• 关键帧间隔与 hls_time 不匹配，导致切片时长漂移、播放器频繁等待，这是最常见的一类问题。
• GOP 过大时首屏加载慢，过小则码率利用率下降，需要根据场景在 1～4 秒间取舍。
• RTMP 默认走 1935 端口，HLS 走 80/443，两者在容器或云主机上的安全组、防火墙规则要分别放行。
• HLS 天生有几秒到十几秒延迟，追求低延迟得换 LL-HLS 或走 WebRTC，不要指望调 hls_fragment 就能压到秒级以内。
• Video.js 的直播源需要正确的 mime 类型和 crossOrigin 配置，跨域和自动播放限制经常让页面白屏。

这些问题在文档里往往一句话带过，但实际部署时会反复出现，资料里如果给出对照现象和排查顺序，比单纯贴配置更有用。

怎么用这份资料自学

建议按"跑通再优化"的顺序推进：先在单机上把 RTMP 推到 Nginx、确认切片文件生成、再用 Video.js 播出来，这一步走通整条链路就活了；然后回头调 hls_fragment、hls_playlist_length 和编码参数，观察延迟与画质的变化；最后再考虑多码率、鉴权、CDN 分发这些扩展。每完成一段，自己写一份配置说明，记录参数改动前后的现象差异，这比抄一遍配置文件印象深得多。前端部分不要停在能用就行，试着改播放器皮肤、加清晰度切换，会顺带理解 HLS 主播放列表和子播放列表的关系。配套笔记适合课后复盘，但真正内化靠的是自己重搭一次环境并踩一遍坑。

适合谁

如果你在做音视频相关后端、运维或全栈，需要一套自托管直播方案作为起点，或者想搞清楚 FFmpeg、RTMP、HLS 之间的数据流关系，这门课的主题正好对口。它的定位是工程对照材料——边看边动手搭，把参数和现象对应起来，比只看视频进度条有效得多。需要提醒的是，自建直播在生产环境的复杂度主要在并发、转码算力和分发上，这套组合适合作为理解原理和搭建原型的底座，而不是直接扛高并发的最终形态。