FFmpeg+MediaMTX本地模拟RTSP流：打通OpenCV与YOLO实时推理链路
1. 为什么本地跑视觉项目总卡在“没有摄像头”这一步
做过视觉项目的人大概率都遇到过这个尴尬：算法代码写完了，模型权重也准备好了，结果手边没有网络摄像头，或者摄像头在办公室、设备在机房，根本没法随时调。更麻烦的是，很多真实业务场景——比如园区监控、产线质检、交通流量统计——数据源根本不是本地 USB 摄像头，而是一路 RTSP 视频流。你不可能每次都跑到现场去接摄像头调试，所以“在本地模拟一路 RTSP 流”就成了从 YOLO 走向实时视觉系统必须迈过的一道坎。
这篇内容就是围绕这件事展开的：怎么用 FFmpeg 和 MediaMTX 在本地搭一个 RTSP 服务，把一段普通视频文件变成一路可被 OpenCV、YOLO 正常拉取的实时流。关键词里出现的 RTSP、FFmpeg、MediaMTX、OpenCV 正好构成了这条链路的核心工具组合。整套方案适合刚入门 YOLO 部署、想验证实时推理链路、又不想依赖真实摄像头的开发者，也适合需要反复复现拉流问题的调试场景。
我先说结论：本地模拟 RTSP 流这件事，难点从来不在“推流”本身，而在于协议细节、编码格式、延迟控制和拉流端的兼容性。很多人第一次尝试，推流命令敲下去看着没报错，OpenCV 那边 cv2.VideoCapture 却一直返回空帧，或者延迟高到没法用。下面我把整条链路拆开讲清楚，包括每一步为什么这么做、参数怎么定、以及我实际踩过的坑。
2. RTSP 流模拟的整体链路与工具分工
2.1 一条 RTSP 流从文件到 YOLO 到底经过了什么
先把整条链路讲明白，后面每一步操作你才知道自己在干什么。我们要实现的目标是：本地有一个视频文件（比如 test.mp4），希望它像一路真实的网络摄像头一样，被 OpenCV 通过一个 rtsp:// 地址拉取，然后送进 YOLO 做推理。
这条链路大致分四段：
- 源文件：本地磁盘上的 mp4、mkv 等视频文件，或者一段用测试视频合成的素材。
- 推流端：FFmpeg 负责读取源文件，按指定编码格式和帧率，把数据推送到 RTSP 服务器。
- RTSP 服务端：MediaMTX（原名 rtsp-simple-server）监听端口，接收推流并对外提供 RTSP 地址。
- 拉流端：OpenCV 的
cv2.VideoCapture通过 RTSP 地址拉流，逐帧解码后交给 YOLO。
这四段里，FFmpeg 是“搬运工”，MediaMTX 是“中转站”，OpenCV 是“取货方”。任何一段出问题，最终表现都是“拉不到流”或“画面卡顿”，所以排查时必须分段定位，不能一上来就怀疑 YOLO。
2.2 为什么选 MediaMTX 而不是自己写 RTSP 服务
RTSP 协议本身不算特别复杂，但自己实现一个稳定的 RTSP 服务端是件吃力不讨好的事。RTSP 涉及 OPTIONS、DESCRIBE、SETUP、PLAY 等一整套交互流程，还要处理 RTP 包的封装、时间戳、SSRC 等细节。用 Python 或 C++ 从零写一个能稳定工作的 RTSP 服务端，工作量远超“模拟一路流”这个需求本身。
MediaMTX 的价值就在于它把这些都封装好了：一个二进制文件，一个配置文件，启动即用，支持 RTSP、RTMP、HLS、WebRTC 多种协议，还能同时接收多路推流。它跨平台，Windows、Linux、macOS 都有对应版本，对本地调试极其友好。相比之下，自己写服务端或者用一些老旧的 RTSP 服务器软件，配置复杂度和踩坑概率都高得多。
提示：MediaMTX 早期叫 rtsp-simple-server，如果你在网上搜到的是旧名字，指的是同一个项目，配置文件格式基本一致，注意版本差异即可。
2.3 FFmpeg 在链路里扮演的角色和常见误解
很多人以为 FFmpeg 只是个“转码工具”，其实在这条链路里它承担的是读取源、重新编码、按 RTSP 协议推送三件事。这里有个常见误解：以为可以直接把 mp4 文件“复制”成 RTSP 流，不做任何编码。理论上 -c copy 可以避免重新编码，但前提是源文件的编码格式必须和 RTSP 传输要求完全匹配，实际中经常因为封装格式、时间戳问题导致拉流端解码失败。
所以更稳妥的做法是让 FFmpeg 重新编码成 H.264，这是目前 RTSP 生态里兼容性最好的视频编码。H.264 的硬件解码支持广泛，OpenCV 通过 FFmpeg 后端解码时也最稳定。代价是 CPU 会有一定占用，但对于本地模拟一两路流来说完全可以接受。
3. 环境准备：FFmpeg 与 MediaMTX 的安装细节
3.1 FFmpeg 安装：别用系统自带的老版本
FFmpeg 的安装是第一个容易踩坑的地方。Linux 上 apt install ffmpeg 装出来的版本往往偏旧，某些编码器参数不支持；Windows 上如果随便找个压缩包，可能缺少某些编解码库。我的建议是直接用官方或可信来源的完整构建版本。
Windows 下推荐从 FFmpeg 官方渠道下载完整版压缩包，解压后把 bin 目录加入系统 PATH。验证方式是打开命令行执行：
能正常输出版本号和编译配置就说明装好了。重点看输出里有没有 --enable-libx264，这是 H.264 软编码的关键。如果没有，推流时指定 libx264 会直接报错。
Linux 下如果系统源版本太旧，可以考虑用静态构建版本，或者通过包管理器安装带完整编码器的版本。macOS 用 Homebrew 安装通常没问题。
注意：FFmpeg 的版本差异会直接影响命令参数。比如较新版本对某些参数做了调整，网上抄来的命令在新版本上可能报“Unrecognized option”。遇到这种情况先
ffmpeg -h查一下当前版本支持的参数。
3.2 MediaMTX 的获取与最小配置
MediaMTX 的获取很简单，从项目发布页下载对应平台的压缩包，解压后得到一个可执行文件和一个默认配置文件 mediamtx.yml。默认配置其实已经能跑起来，它默认监听 8554 端口的 RTSP 服务，并且允许任意路径推流。
启动方式：
Windows 下就是 mediamtx.exe。启动后你会看到它打印出监听的各个协议端口，其中 RTSP 默认是 8554。这时候服务端就绪了，但它还不知道你要推什么流，路径是推流时动态创建的。
默认配置里有一个关键点值得注意：paths 段默认是 all_others 或者空，表示接受任意路径名的推流。这意味着你推 rtsp://localhost:8554/mystream，它就自动创建 mystream 这个路径。调试阶段这样最方便，不用每换一个流名就改配置。
3.3 验证服务端是否真正就绪
服务端启动后，别急着推流，先确认它真的在监听。可以用 netstat 或 ss 看端口：
看到监听状态说明服务起来了。如果端口被占用，MediaMTX 启动时会报错，这时候要么换端口，要么把占用进程处理掉。我遇到过好几次“推流没反应”，最后发现是上一次的 MediaMTX 进程没退干净，端口被占着，新进程其实没起来。
4. 用 FFmpeg 把视频文件推成 RTSP 流
4.1 推流命令的逐参数拆解
核心推流命令长这样：
这条命令里每个参数都有明确意图，我逐个解释：
-re：按源文件的真实帧率读取，而不是能多快读多快。这个参数是模拟实时流的关键。不加它，FFmpeg 会以 CPU 极限速度把整个文件瞬间推完，拉流端要么瞬间收到一堆帧，要么直接卡死。-stream_loop -1：循环播放源文件，让流一直存在，方便长时间调试。-i test.mp4：输入文件。-c:v libx264：视频编码用 H.264 软编码，兼容性最好。-preset ultrafast：编码速度优先，降低延迟。代价是压缩率低、码率高，但本地调试不在乎带宽。-tune zerolatency：针对低延迟场景优化，减少编码器内部缓冲。-pix_fmt yuv420p：像素格式设为 yuv420p，这是绝大多数解码器和播放器都支持的格式。如果源是其他格式不转换，拉流端可能花屏或直接失败。-g 25：关键帧间隔设为 25 帧。关键帧（I 帧）是拉流端能开始解码的起点，间隔太大，拉流端要等很久才能出画面。-f rtsp：输出格式指定为 RTSP。- 最后的地址就是推流目标。
4.2 延迟从哪来，怎么压下去
延迟是 RTSP 模拟里最让人头疼的问题。延迟来源主要有三块：编码器缓冲、传输缓冲、解码端缓冲。
编码端，-preset ultrafast 和 -tune zerolatency 已经把编码缓冲压到很低。传输端，RTSP 默认用 TCP 或 UDP 传输，UDP 延迟低但可能丢包，TCP 稳定但延迟略高。本地调试建议用 TCP，避免丢包导致的画面异常。
解码端的缓冲往往被忽略。OpenCV 的 cv2.VideoCapture 内部会缓冲若干帧，默认行为可能导致你看到的画面比实际推流慢好几秒。这个后面在拉流部分会专门讲怎么处理。
实测下来，用上面这套参数，本地端到端延迟可以控制在几百毫秒级别，对于调试 YOLO 实时推理完全够用。如果你追求更低延迟，可以进一步减小 -g 的值，但太小会增加码率。
4.3 推流成功的判断标准
推流命令执行后，FFmpeg 会持续输出编码进度信息，类似 frame= 120 fps=25 q=...。看到帧数在稳定增长，说明推流正常。同时 MediaMTX 那边会打印出“已创建路径”“推流者已连接”之类的日志。
如果 FFmpeg 报错退出，常见原因有：编码器不存在（版本问题）、地址连不上（服务端没起或端口不对）、参数不识别（版本差异）。这时候看 FFmpeg 的报错信息，基本能定位到具体环节。
5. OpenCV 拉流：为什么你的 VideoCapture 总是拿不到帧
5.1 拉流代码的最小可用版本
拉流端最基础的代码是这样：
这里显式指定 cv2.CAP_FFMPEG 作为后端很重要。OpenCV 支持多种视频后端，默认情况下可能选到 GStreamer 或其他后端，而 FFmpeg 后端对 RTSP 的支持最成熟。显式指定能避免很多“莫名其妙打不开”的问题。
5.2 打开失败和读取失败的排查顺序
cap.isOpened() 返回 False，和 cap.read() 返回 False，是两个不同阶段的问题，排查方向完全不同。
isOpened() 失败，说明连接或协议握手阶段就出问题了。排查顺序：
- 确认 MediaMTX 在运行，端口对得上。
- 确认 FFmpeg 推流进程还活着。
- 用
ffplay rtsp://localhost:8554/mystream测试这路流本身能不能播。ffplay 能播说明流没问题，问题在 OpenCV 这边。 - 检查 OpenCV 是否带 FFmpeg 支持。有些精简安装的 OpenCV 不带 FFmpeg 后端，
cv2.CAP_FFMPEG直接不可用。
read() 失败，通常是流中途断了，或者解码出错。这时候要回头看推流端是不是退出了，或者网络传输出了问题。
5.3 缓冲区导致的“假延迟”问题
这是最隐蔽的坑。流明明在推，OpenCV 也能读到帧，但画面延迟越来越大，或者你看到的画面和实际推流内容对不上。原因在于 OpenCV 的 VideoCapture 内部有一个帧缓冲队列，它会把收到的帧先存起来，read() 是从队列里取，而不是取最新帧。
解决办法是设置缓冲区大小：
把缓冲设为 1，让 read() 尽量取最新帧。不过要注意，CAP_PROP_BUFFERSIZE 的支持程度依赖后端和版本，不是所有环境都生效。如果设了没用，另一个思路是开一个独立线程专门读帧，主线程只处理最新一帧，用队列长度控制来丢弃旧帧。这个模式在实时 YOLO 推理里非常常见，后面会展开。
6. 把 RTSP 流接进 YOLO 推理链路
6.1 从单帧读取到稳定推理循环
把 RTSP 拉流和 YOLO 接起来，最直接的方式就是在读帧循环里调用模型：
这段代码能跑，但有个明显问题：YOLO 推理是同步阻塞的，推理期间不读帧，缓冲区就会堆积，延迟越来越大。短时间测试没问题，长时间跑必然出问题。
6.2 读帧与推理解耦的线程模型
要解决上面的问题，核心思路是读帧和推理分开。开一个线程专门负责从 RTSP 读帧，读到就放进一个只保留最新帧的容器；主线程从容器里取最新帧做推理。这样即使推理慢，也不会导致缓冲区堆积，因为读帧线程一直在消费流，旧帧被新帧覆盖。
这个模型的关键是“只保留最新帧”。用一个长度为 1 的队列，或者一个带锁的变量，新帧来了直接覆盖旧帧。这样推理永远处理的是当前最新画面，延迟不会累积。
提示：这个模式在真实监控场景里几乎是标配。真实摄像头不会因为你推理慢就暂停推流，所以拉流端必须有能力“丢弃旧帧、只追最新”。
6.3 多路流同时推理时的资源账
关键词里有个很实际的问题：一张 T4 显卡，1080p 25 帧，用 TensorRT 跑 YOLO 640 分辨率检测，能支持多少路？这个问题没有标准答案，但可以估算。
T4 的算力在 TensorRT 加速下，YOLO 640 分辨率单帧推理大概在几毫秒到十几毫秒量级，具体取决于模型大小（n/s/m/l）和优化程度。理论上单卡跑十几路甚至更多是可能的，但实际瓶颈往往不在 GPU，而在：
- 解码：多路 1080p 解码对 CPU 或 GPU 解码单元是压力。
- 内存带宽：多路数据搬运会吃带宽。
- 预处理：缩放到 640 的预处理如果放在 CPU 上，多路时 CPU 会先扛不住。
所以做多路方案时，解码和预处理尽量用 GPU 加速，别让 CPU 成为瓶颈。本地模拟阶段先用一两路把链路跑通，再逐步加压测试。
7. 那些让我调试到半夜的坑
7.1 推流地址写错导致的“静默失败”
有一次推流命令敲下去，FFmpeg 没报错，但 OpenCV 死活拉不到。查了半天发现是地址里路径名写错了，推的是 mystream，拉的是 mystream1。MediaMTX 对不存在的路径不会主动报错，拉流端就一直等。这种“静默失败”最耗时间，所以推流和拉流的地址一定要逐字符核对。
7.2 编码格式不匹配引发的花屏
还有一次，源视频是 H.265 编码，我图省事用了 -c copy 直接推，结果拉流端画面全是绿色块。原因是拉流端解码器对 H.265 over RTSP 的支持不完整。换成 libx264 重新编码后立刻正常。这件事让我养成了一个习惯：模拟流一律用 H.264，别偷懒。
7.3 端口占用与进程残留
MediaMTX 和 FFmpeg 都是常驻进程，调试时经常开了忘关。下次启动时端口被占，或者推流地址被旧进程占着，表现就是各种诡异问题。我的做法是每次调试前先检查端口和进程，确认环境干净再开始。这个习惯能省掉大量无谓的排查时间。
7.4 OpenCV 版本与后端支持
不同 OpenCV 版本对 RTSP 的支持差异很大。有些通过 pip 安装的版本不带 FFmpeg 后端，cv2.CAP_FFMPEG 不可用。判断方法是：
在输出里找 FFMPEG 那一项，显示 YES 才说明带 FFmpeg 支持。如果没有，要么换安装方式，要么用其他后端。这个问题在关键词里也有体现，很多人卡在 ModuleNotFoundError 或者后端不可用上。
8. 从模拟流到真实摄像头的平滑过渡
本地模拟跑通之后，切换到真实摄像头其实改动很小。真实网络摄像头的 RTSP 地址格式通常是 rtsp://用户名:密码@IP:端口/路径，主码流和子码流路径不同。主码流清晰但码率高，子码流分辨率低但省资源，做检测时常用子码流降低解码压力。
切换时唯一要注意的是：真实摄像头的帧率、分辨率、编码格式可能和模拟流不同，YOLO 的输入预处理要能适配。另外真实摄像头的网络抖动比本地流大，拉流端的重连逻辑必须做，否则网络一抖流就断了。模拟阶段可以故意把 MediaMTX 停掉再启动，测试拉流端的重连行为，提前把这个逻辑写好。
整套链路跑下来，你会发现“模拟 RTSP 流”这件事的价值不只是省一个摄像头，而是让你能在完全可控的环境里，反复验证从拉流、解码、推理到显示的每一个环节。等真实设备到位时，你手里已经有一套调好的、知道每个参数含义的代码，而不是从零开始试错。我个人在实际项目里的体会是，前期在模拟流上多花的两小时，能省掉现场调试的一整天。