4. 环境搭建总览
RTSP 推流实战并不是“装一个 FFmpeg 就能跑”的简单任务。它涉及采集端、编码端、推流端、RTSP 服务端、播放端以及网络链路等多个环节，任何一个环节的版本不匹配或网络不通，都会导致推流失败、花屏、延迟高或无法播放。因此，在动手写代码之前，必须先完成一次系统性的环境搭建总览：明确需求、选好软硬件、设计网络拓扑、整理工具清单并做好版本管理。本节将围绕这五个方面展开，帮助你搭建一个稳定、可复现、易排障的 RTSP 推流实战环境。
一、需求分析：先想清楚“推什么、推给谁、推多远”
环境搭建的第一步不是买设备，而是做需求分析。RTSP 推流实战的需求可以从四个维度拆解：
- 视频源类型：是摄像头实时采集、本地视频文件循环推流，还是屏幕录制？不同源决定了采集方式和编码参数。
- 编码格式与分辨率：H.264 还是 H.265？720P、1080P 还是 4K？分辨率越高，对 CPU/GPU 和带宽要求越高。
- 并发与延迟要求：单路推流还是多路并发？延迟要求是秒级还是毫秒级？这直接影响 RTSP 服务端选型和网络设计。
- 播放端形态：是 VLC 播放、Web 端播放，还是移动端拉流？不同播放端对传输协议和封装格式的兼容性不同。
二、软硬件选型：匹配需求，留出余量
软硬件选型的核心原则是“够用且留有余量”。推流端如果使用软件编码，CPU 占用会非常高；如果使用硬件编码，则需要确认显卡或编码器是否支持目标编码格式。RTSP 服务端可以选择开源方案如 MediaMTX、Live555，也可以使用商业方案如 Wowza、EasyDarwin。播放端通常使用 VLC 或 FFplay 进行验证。
| 环节 | 推荐选型 | 关键参数 | 备注 |
|---|---|---|---|
| 采集端 | USB 摄像头 / 网络摄像头 / 本地视频文件 | 分辨率、帧率、接口类型 | 网络摄像头需支持 RTSP 输出 |
| 推流端 | FFmpeg 6.x + x264 / NVENC | 编码格式、码率、GOP | 硬件编码可显著降低 CPU 占用 |
| RTSP 服务端 | MediaMTX 1.x | 端口、路径、鉴权 | 轻量、跨平台、配置简单 |
| 播放端 | VLC 3.x / FFplay | 协议支持、缓冲策略 | 用于快速验证推流是否成功 |
| 操作系统 | Ubuntu 22.04 LTS / Windows 11 | 内核版本、驱动 | Linux 更适合服务端部署 |
三、网络拓扑设计：让数据流清晰可控
RTSP 推流涉及“推流端 → RTSP 服务端 → 播放端”的数据流向。网络拓扑设计的目标是保证推流链路稳定、延迟可控、便于抓包排障。典型的实战环境拓扑如下：推流端和 RTSP 服务端部署在同一局域网内，播放端可以位于同一局域网或通过公网访问。如果涉及公网推流，需要在服务端配置端口映射或使用反向代理。
在上图中，推流端通过 RTSP 协议将编码后的音视频流推送到服务端的指定路径，播放端再从同一路径拉流。所有设备位于同一局域网内，便于使用 Wireshark 抓包分析 RTP/RTCP 交互。如果播放端位于公网，则需要在路由器上映射 8554 端口，并注意防火墙策略。
四、工具清单与版本管理：可复现才是硬道理
RTSP 推流实战涉及的工具较多，建议统一整理成清单，并锁定版本号。版本不一致是导致“别人能跑、我跑不通”的最常见原因。例如 FFmpeg 4.x 与 6.x 在 RTSP 推流参数上存在差异，MediaMTX 不同版本的配置字段也可能变化。
# 工具清单与版本锁定示例（Ubuntu 22.04）
ffmpeg -version # 建议 6.0 或以上
ffprobe -version # 与 ffmpeg 同版本
mediamtx --version # 建议 1.x 稳定版
vlc --version # 建议 3.0.x
docker --version # 可选，用于容器化部署
git --version # 用于管理配置文件和脚本
# 推荐使用 Docker 固定 MediaMTX 版本
docker run --rm -d \
-p 8554:8554 \
-v $(pwd)/mediamtx.yml:/mediamtx.yml \
bluenviron/mediamtx:1.9.3
五、案例与复盘：一次典型的推流环境搭建
假设我们需要搭建一个“USB 摄像头 → FFmpeg 推流 → MediaMTX 转发 → VLC 播放”的实战环境。首先确认摄像头支持 1080P@30fps，然后使用 FFmpeg 以 H.264 编码推流到 MediaMTX 的 /live/test 路径。推流命令如下：
ffmpeg -f v4l2 -i /dev/video0 \
-c:v libx264 -preset veryfast -tune zerolatency \
-b:v 2000k -g 50 \
-f rtsp rtsp://192.168.1.20:8554/live/test
推流成功后，使用 FFplay 验证拉流：
ffplay -rtsp_transport tcp rtsp://192.168.1.20:8554/live/test
常见误区包括：使用 UDP 推流导致丢包花屏、GOP 设置过大导致首帧等待时间长、未关闭摄像头自动曝光导致画面闪烁、防火墙未放行 8554 端口导致连接超时。复盘时建议记录每次调整的参数和现象，形成自己的《RTSP 推流参数对照表》。