FFmpeg + MediaMTX 模拟 RTSP 流：YOLO 实时推理部署实战

1. 为什么我们需要模拟 RTSP 流做视觉项目的人都有一个共识模型训练只是万里长征第一步真正折磨人的是部署和联调。你本地跑通了 YOLO 推理拿几张图片测了测mAP 看着还行但一旦要接入真实摄像头做实时检测问题就全冒出来了。摄像头不在手边、网络环境复杂、多个进程抢设备、调试时反复插拔网线——这些都是我踩过的坑。RTSP 流模拟就是解决这个问题的。它的核心思路很简单用一段本地视频文件或者摄像头采集的画面通过软件模拟成一个标准的 RTSP 流服务让下游的 OpenCV、YOLO 推理程序、播放器都以为自己在跟一台真实的网络摄像头打交道。这样做的好处非常直接开发阶段不依赖硬件、可以反复回放同一段视频做对比测试、能模拟多路并发场景、方便做压力测试。这篇文章面向的是正在做 YOLO 实时视觉部署的开发者尤其是那些已经跑通了单张图片推理、准备接入视频流但手头没有网络摄像头或者摄像头不方便频繁调试的人。我会从工具选型开始一步步讲清楚怎么用 FFmpeg 和 MediaMTX 搭建一套完整的 RTSP 模拟环境包括推流、拉流、OpenCV 接入、YOLO 推理对接以及我在实际项目中遇到的各种坑和排查方法。整个方案的核心工具链是FFmpeg MediaMTX OpenCV。FFmpeg 负责编码和推流MediaMTX 负责接收流并对外提供 RTSP 服务OpenCV 负责拉流和解码。这三者各司其职组合起来就是一套完整的模拟链路。下面我会逐个拆解每个环节的设计思路和实操细节。2. 工具选型与整体架构设计2.1 为什么选 MediaMTX 而不是其他 RTSP 服务器市面上能用的 RTSP 服务器方案不少比如 Live555、GStreamer 的 rtsp-server、SRS 等。我最早用的是 Live555编译麻烦不说配置文件写起来也费劲文档还停留在十几年前的水平。后来试了 GStreamer 的 rtsp-server功能确实强大但依赖链太长在一个干净的 Linux 环境上装完 GStreamer 全家桶磁盘直接多了好几个 G。MediaMTX 是我目前最推荐的方案。它是一个用 Go 写的单二进制文件下载下来直接就能跑不需要安装任何依赖。配置文件是 YAML 格式可读性很好。它支持 RTSP、RTMP、HLS、WebRTC 多种协议既能接收推流也能对外提供拉流服务。最关键的是它的延迟控制得相当不错在局域网环境下 RTSP 拉流延迟可以稳定在 200ms 以内这对于实时视觉应用来说完全够用。还有一个实际考量MediaMTX 支持路径级别的配置你可以为不同的视频源配置不同的路径名比如/camera1、/camera2下游程序只需要改一下 URL 就能切换视频源。这在做多路视频测试的时候特别方便。2.2 FFmpeg 在链路中的角色定位FFmpeg 在这个方案里承担的是“内容生产”的角色。它负责读取本地视频文件或者摄像头设备按照指定的编码参数进行转码然后推送到 MediaMTX。为什么不让 MediaMTX 直接读文件因为 MediaMTX 的设计定位是流媒体服务器不是转码工具。它接收什么格式就转发什么格式不做编码转换。所以我们需要 FFmpeg 先把视频文件转成适合网络传输的编码格式。这里有一个关键选择用H.264 还是 H.265。H.265 压缩率更高同样的画质下码率能省一半但问题是 OpenCV 对 H.265 的软解支持不如 H.264 成熟尤其是在一些老版本的 OpenCV 上拉 H.265 流经常出现解码失败或者花屏。我的建议是如果你的下游是 OpenCV YOLO 这套组合优先用 H.264。除非你的带宽确实非常紧张否则没必要为了省那点码率去冒兼容性的风险。另一个参数是推流协议的选择。FFmpeg 推流到 MediaMTX 可以用 RTSP 推也可以用 RTMP 推。RTSP 推流的延迟更低但 RTMP 推流在某些网络环境下更稳定。我实测下来局域网内 RTSP 推流完全没问题延迟比 RTMP 低大概 100ms 左右。所以默认用 RTSP 推流就行。2.3 整体数据流向整个链路的数据流向是这样的FFmpeg 读取本地视频文件解码后重新编码为 H.264通过 RTSP 协议推送到 MediaMTX 的某个路径上。MediaMTX 接收流后在内部维护这个流的状态并对外提供一个 RTSP URL。OpenCV 通过这个 URL 拉流解码后得到帧数据送给 YOLO 做推理。这个架构的好处是每一层都可以独立替换。比如你不想用 FFmpeg 推流可以用 OBS 推流不想用 MediaMTX可以换成 SRS不想用 OpenCV 拉流可以用 GStreamer。每一层的接口都是标准的替换成本很低。3. 环境搭建与核心配置实操3.1 MediaMTX 的下载与最小化配置MediaMTX 的获取方式很简单直接去它的 GitHub Releases 页面下载对应平台的压缩包。Linux 下解压后只有一个可执行文件和一个默认配置文件。Windows 下也是一个 exe 文件加一个 yml 文件。最小化配置只需要关注几个参数。默认配置文件里有一大堆选项但实际用到的没几个。我一般会新建一个精简的配置文件只保留必要部分rtspAddress: :8554 paths: camera1: source: publisher camera2: source: publisher这里rtspAddress指定了 RTSP 服务的监听地址和端口默认是 8554。paths下面定义了路径camera1和camera2是两个路径名source: publisher表示这个路径等待外部推流。也就是说FFmpeg 推流到这个路径MediaMTX 就会把流转发给所有拉流的客户端。启动命令就是./mediamtx它会自动读取同目录下的mediamtx.yml。如果你想指定配置文件可以用./mediamtx /path/to/config.yml。注意MediaMTX 默认会占用 8554RTSP、1935RTMP、8888HLS、8889WebRTC这几个端口。如果你的机器上已经有服务占用了这些端口需要在配置文件里改掉否则启动会报错。3.2 FFmpeg 推流命令的完整拆解FFmpeg 推流命令看起来很长但拆开来看每个参数都有明确的目的。下面是我常用的一条命令ffmpeg -re -stream_loop -1 -i test_video.mp4 \ -c:v libx264 -preset ultrafast -tune zerolatency \ -b:v 2000k -maxrate 2000k -bufsize 4000k \ -pix_fmt yuv420p -g 30 \ -an \ -f rtsp rtsp://127.0.0.1:8554/camera1逐段解释一下。-re表示按照视频的实际帧率读取而不是尽可能快地读完。这个参数非常关键如果不加-reFFmpeg 会以最快速度把整个视频文件推完MediaMTX 收到的流会瞬间结束下游根本来不及处理。-stream_loop -1表示循环播放这样一段短视频可以一直推方便长时间测试。-c:v libx264指定视频编码器为 H.264 的软件编码器。如果你有 NVIDIA 显卡可以换成-c:v h264_nvenc编码速度会快很多CPU 占用也低。-preset ultrafast和-tune zerolatency是 x264 编码器的参数前者让编码速度最快后者优化了低延迟场景。这两个参数会牺牲一些压缩率但在局域网环境下带宽不是瓶颈优先保证实时性。-b:v 2000k设置目标码率为 2000kbps-maxrate和-bufsize配合使用控制码率波动。-pix_fmt yuv420p是像素格式这个格式兼容性最好OpenCV 和大多数播放器都能正常解码。-g 30设置 GOP 大小为 30 帧也就是每 30 帧一个关键帧。GOP 越小拉流端能越快拿到关键帧开始解码但码率会略微上升。-an表示不处理音频。做视觉推理不需要音频去掉音频可以减小流的大小也避免一些音频编码器带来的兼容性问题。最后的-f rtsp指定输出格式为 RTSP后面跟的是 MediaMTX 的推流地址。3.3 验证推流是否成功推流命令跑起来之后怎么确认流已经成功推上去了最直接的方法是看 FFmpeg 的输出。如果推流成功你会看到类似这样的输出frame 300 fps 25 q28.0 sizeN/A time00:00:12.00 bitrateN/A speed1.00xfps25表示实际推流帧率是 25 帧speed1.00x表示推流速度跟视频实际播放速度一致。如果speed远大于 1说明-re参数没生效如果fps是 0 或者波动很大说明编码或者网络有问题。另一个验证方法是用 FFplay 或者 VLC 直接拉流播放。FFplay 的命令很简单ffplay -rtsp_transport tcp rtsp://127.0.0.1:8554/camera1-rtsp_transport tcp强制使用 TCP 传输 RTSP 流。RTSP 默认是 UDP 传输但在某些网络环境下 UDP 丢包会导致花屏用 TCP 更稳定。如果 FFplay 能正常播放说明整条链路是通的。实操心得我习惯在推流命令后面加-loglevel warning这样 FFmpeg 只输出警告和错误信息不会刷屏。调试阶段可以不加方便看帧率和速度。3.4 OpenCV 拉流的关键参数OpenCV 拉 RTSP 流看起来很简单cv2.VideoCapture(url)一行代码就搞定了。但实际用起来默认参数经常出问题。最常见的问题是缓冲区堆积导致延迟越来越大。OpenCV 默认会缓冲一定数量的帧如果你的推理速度跟不上推流速度缓冲区会越积越多你看到的画面可能是十几秒之前的。解决方法是设置CAP_PROP_BUFFERSIZE为 1import cv2 url rtsp://127.0.0.1:8554/camera1 cap cv2.VideoCapture(url, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) while True: ret, frame cap.read() if not ret: print(拉流失败尝试重连) cap.release() cap cv2.VideoCapture(url, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) continue # 在这里做 YOLO 推理cv2.CAP_FFMPEG指定使用 FFmpeg 作为后端这比 OpenCV 默认的后端兼容性更好。CAP_PROP_BUFFERSIZE设置为 1 表示只缓冲一帧这样每次read()拿到的都是最新的帧。代价是如果网络抖动可能会丢帧但对于实时检测来说丢帧比延迟累积要好得多。还有一个细节OpenCV 拉流失败时read()返回False但VideoCapture对象不会自动重连。你需要手动释放再重新创建。我一般会加一个重试计数器连续失败超过一定次数就退出程序避免死循环。4. YOLO 推理与 RTSP 流的对接实战4.1 推理循环的设计要点把 YOLO 推理嵌入到 RTSP 拉流循环里看起来就是把cap.read()拿到的帧送给模型但实际写起来有几个关键决策点。第一个是推理频率和拉流频率的解耦。RTSP 流可能是 25 帧每秒但你的 YOLO 模型在 CPU 上可能只能跑 5 帧每秒。如果你每拉一帧就推理一次程序会越来越慢延迟越来越大。正确的做法是拉流循环持续运行但推理可以跳帧执行。比如每 5 帧推理一次中间帧直接丢弃或者复用上一次的推理结果。第二个是推理结果的异步处理。如果你需要在画面上画检测框并显示绘制操作本身也会消耗时间。我通常会把推理和绘制放在同一个循环里但用跳帧来控制节奏。如果要做更复杂的后处理比如跟踪、计数可以考虑用队列把帧送给单独的推理线程。下面是一个典型的推理循环结构import cv2 import time url rtsp://127.0.0.1:8554/camera1 cap cv2.VideoCapture(url, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) frame_count 0 infer_interval 5 # 每5帧推理一次 last_boxes [] while True: ret, frame cap.read() if not ret: break frame_count 1 if frame_count % infer_interval 0: # 执行 YOLO 推理 results model(frame) last_boxes results[0].boxes # 绘制检测框 for box in last_boxes: x1, y1, x2, y2 box.xyxy[0].cpu().numpy() cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 2) cv2.imshow(YOLO RTSP, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这个结构里infer_interval控制推理频率。你可以根据模型的实际推理速度来调整这个值。如果模型很快设为 1 就是每帧都推理如果模型较慢设为 5 或者 10 可以保证画面流畅。4.2 多路 RTSP 流的并发处理实际项目中经常需要同时处理多路摄像头。用 MediaMTX 模拟多路流很简单启动多个 FFmpeg 推流进程分别推到/camera1、camera2、camera3就行。但下游用 OpenCV 同时拉多路流就需要一些技巧了。最直接的方法是开多个线程每个线程负责一路流的拉取和推理。Python 的 GIL 会限制多线程的并行计算能力但 OpenCV 的read()和 YOLO 的推理都会释放 GIL所以多线程方案在实际使用中是可行的。import threading def process_stream(url, name): cap cv2.VideoCapture(url, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) while True: ret, frame cap.read() if not ret: break results model(frame) # 处理结果... cv2.imshow(name, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() threads [] for i in range(1, 4): url frtsp://127.0.0.1:8554/camera{i} t threading.Thread(targetprocess_stream, args(url, fcam{i})) t.start() threads.append(t) for t in threads: t.join()注意多路并发时CPU 和内存的消耗会成倍增加。如果每路都跑 YOLO 推理建议用 GPU 推理并且控制并发路数。我实测在一台 8 核 CPU 的机器上同时拉 4 路 1080p 流并做推理CPU 直接跑满帧率掉到个位数。后来换成 GPU 推理同时拉 8 路都没问题。4.3 延迟测量与优化做实时视觉延迟是一个绕不开的指标。从摄像头采集到画面显示整个链路的延迟包括采集延迟、编码延迟、网络传输延迟、解码延迟、推理延迟、显示延迟。在模拟环境中采集和编码由 FFmpeg 完成网络传输是本地回环解码和推理在 OpenCV 和 YOLO 这边。测量端到端延迟的一个实用方法是在视频画面里放一个计时器然后对比实际时间和画面里的时间。我通常会在测试视频的每一帧上叠加当前时间戳然后在拉流端读取这个时间戳跟系统时间做差。这个差值就是端到端延迟。优化延迟的几个关键点FFmpeg 推流时用-tune zerolatency和较小的 GOPMediaMTX 配置里可以调整缓冲区大小OpenCV 拉流时设置CAP_PROP_BUFFERSIZE为 1推理时跳帧处理。我实测下来在局域网环境下从 FFmpeg 推流到 OpenCV 显示延迟可以控制在 300ms 以内。5. 常见问题排查与避坑指南5.1 推流成功但拉流失败这是最常见的问题之一。FFmpeg 显示推流正常但 OpenCV 或者 FFplay 拉流时报错或者一直卡住。可能的原因有几个第一种可能是路径名不匹配。FFmpeg 推流到rtsp://127.0.0.1:8554/camera1但 MediaMTX 配置里没有定义camera1这个路径。MediaMTX 默认会拒绝未定义的路径。解决方法是在配置文件里加上对应的路径或者把paths配置成通配符形式。第二种可能是传输协议问题。RTSP 默认用 UDP 传输在某些网络环境下 UDP 包会被防火墙拦截。解决方法是在拉流端强制使用 TCP。OpenCV 可以通过设置环境变量OPENCV_FFMPEG_CAPTURE_OPTIONS来指定传输协议import os os.environ[OPENCV_FFMPEG_CAPTURE_OPTIONS] rtsp_transport;tcp第三种可能是编码格式不兼容。如果 FFmpeg 推的是 H.265而 OpenCV 的 FFmpeg 后端不支持 H.265 解码就会拉流失败。解决方法就是前面说的推流时统一用 H.264。5.2 画面花屏或者卡顿花屏通常是丢包导致的。UDP 传输下丢包是常态尤其是无线网络环境。解决方法还是强制 TCP 传输。卡顿的原因可能更多CPU 编码跟不上、网络带宽不足、下游解码太慢。如果是 CPU 编码跟不上FFmpeg 的输出里会看到speed小于 1说明编码速度跟不上视频播放速度。这时候可以降低分辨率、降低码率、或者换用硬件编码器。如果是下游解码太慢可以尝试降低拉流分辨率或者在 OpenCV 里设置CAP_PROP_FRAME_WIDTH和CAP_PROP_FRAME_HEIGHT来强制缩放。5.3 MediaMTX 启动报错端口占用MediaMTX 默认会监听多个端口如果其中任何一个被占用启动就会失败。报错信息通常会指明是哪个端口被占用了。解决方法有两种一是找到占用端口的进程并关掉二是修改 MediaMTX 的配置文件把冲突的端口改成其他值。在 Linux 下可以用lsof -i :8554或者netstat -tlnp | grep 8554来查看端口占用情况。Windows 下可以用netstat -ano | findstr 8554。5.4 OpenCV 拉流延迟越来越大这个问题前面提到过根本原因是缓冲区堆积。OpenCV 默认的缓冲区大小可能比较大如果你的推理速度跟不上推流速度缓冲区里的帧会越来越多延迟就越来越大。解决方法就是设置CAP_PROP_BUFFERSIZE为 1。但要注意这个参数不是所有后端都支持必须用cv2.CAP_FFMPEG后端才生效。还有一个隐藏问题如果你在循环里做了耗时的操作比如保存图片、写日志也会导致拉流循环变慢进而引起缓冲区堆积。解决方法是把耗时操作放到单独的线程或者异步处理。5.5 常见问题速查表问题现象可能原因排查方法解决方案推流正常但拉流失败路径未定义检查 MediaMTX 配置添加对应路径配置拉流失败UDP 被拦截换 TCP 传输测试强制 RTSP over TCP画面花屏丢包查看网络质量改用 TCP 传输画面卡顿编码或解码慢看 FFmpeg 的 speed 值降低分辨率或码率延迟越来越大缓冲区堆积观察延迟变化趋势设置 BUFFERSIZE 为 1MediaMTX 启动失败端口占用查看报错信息改端口或关占用进程OpenCV 报解码错误编码格式不兼容确认推流编码统一用 H.264实操心得我习惯在开发阶段把 FFmpeg 的日志级别调到info这样能看到每一帧的推流状态。正式跑的时候调到warning减少日志输出。另外推流命令最好写成一个 shell 脚本或者 bat 文件把参数固定下来避免每次手敲出错。6. 进阶技巧与扩展思路6.1 用本地摄像头模拟 RTSP 流手头没有网络摄像头但电脑上有 USB 摄像头也可以用 FFmpeg 把 USB 摄像头的画面推成 RTSP 流。Linux 下 USB 摄像头通常是/dev/video0Windows 下需要用dshow或者v4l2来指定设备。Linux 下的命令ffmpeg -f v4l2 -framerate 25 -video_size 1280x720 -i /dev/video0 \ -c:v libx264 -preset ultrafast -tune zerolatency \ -b:v 2000k -pix_fmt yuv420p -g 30 -an \ -f rtsp rtsp://127.0.0.1:8554/camera1Windows 下的命令ffmpeg -f dshow -framerate 25 -video_size 1280x720 -i videoUSB Camera \ -c:v libx264 -preset ultrafast -tune zerolatency \ -b:v 2000k -pix_fmt yuv420p -g 30 -an \ -f rtsp rtsp://127.0.0.1:8554/camera1Windows 下设备名需要用ffmpeg -list_devices true -f dshow -i dummy来查看。6.2 模拟多路不同分辨率的流实际项目中不同摄像头的分辨率可能不一样。用 MediaMTX 可以很方便地模拟这种情况。启动多个 FFmpeg 进程每个进程用不同的分辨率和码率推流到不同的路径。比如一路 1080p、一路 720p、一路 480p这样可以测试你的推理程序在不同分辨率下的表现。6.3 录制 RTSP 流到本地文件调试的时候经常需要把 RTSP 流录下来方便回放分析。FFmpeg 可以直接从 MediaMTX 拉流并保存为文件ffmpeg -rtsp_transport tcp -i rtsp://127.0.0.1:8554/camera1 \ -c copy -f mp4 output.mp4-c copy表示不重新编码直接复制流。这样录制速度很快CPU 占用也很低。但要注意如果流是 H.264保存为 mp4 通常没问题如果是其他编码格式可能需要转码。6.4 用 Python 脚本一键启动整套环境每次调试都要手动开三个终端MediaMTX、FFmpeg、OpenCV时间长了很烦。我写了一个 Python 脚本用subprocess模块一键启动所有进程import subprocess import time import signal import sys processes [] def start_process(cmd): p subprocess.Popen(cmd, shellTrue) processes.append(p) return p def cleanup(sig, frame): for p in processes: p.terminate() sys.exit(0) signal.signal(signal.SIGINT, cleanup) # 启动 MediaMTX start_process(./mediamtx) time.sleep(1) # 启动 FFmpeg 推流 start_process(ffmpeg -re -stream_loop -1 -i test_video.mp4 -c:v libx264 -preset ultrafast -tune zerolatency -b:v 2000k -pix_fmt yuv420p -g 30 -an -f rtsp rtsp://127.0.0.1:8554/camera1) print(环境已启动按 CtrlC 退出) signal.pause()这个脚本的好处是按一次 CtrlC 就能把所有子进程都关掉不用挨个终端去 kill。6.5 性能监控与日志记录长时间跑测试的时候监控 CPU、内存、网络带宽的变化很有必要。Linux 下可以用top、htop、iftop这些工具。更精细的做法是在 Python 脚本里用psutil库定期采集资源使用情况写到日志文件里。这样跑完测试可以回头分析资源瓶颈在哪里。我在实际项目中还会记录每路流的帧率、延迟、丢帧数。这些数据对于判断系统是否稳定运行非常重要。如果发现某路流的帧率持续下降或者延迟持续上升就说明这一路有问题需要单独排查。7. 我在实际项目中的几点体会这套 RTSP 模拟方案我在多个项目中用过从简单的单路测试到八路并发推理都跑过。最大的体会是模拟环境越接近真实环境后期切换的成本越低。如果你在模拟阶段用的是 1080p、25fps、H.264 的流那切换到真实摄像头时只要摄像头的编码参数差不多代码基本不用改。另一个体会是不要过度优化。我见过一些开发者在模拟阶段就纠结于把延迟从 300ms 降到 200ms花了很多时间调参数。但实际上真实摄像头的采集延迟可能就有 100ms 以上网络传输还有几十毫秒你在这边省下来的几十毫秒在整体链路里根本感知不到。先把功能跑通再根据实际需求做针对性优化。最后分享一个小技巧如果你需要测试程序在断流情况下的表现可以在 FFmpeg 推流命令里加-t 60让推流在 60 秒后自动停止。这样可以模拟摄像头断线或者网络中断的场景测试你的程序是否能正确处理重连。这个技巧在调试自动重连逻辑的时候特别有用。