在开发视频播放器、RTSP 客户端或流媒体相关功能时，最常见的一个问题就是：
👉 手上没有稳定的 RTSP 推流源，没法反复测试播放器行为。
其实在macOS（苹果电脑）上，用现成工具就可以快速启动一个 RTSP 推流服务，用于本地或局域网测试。
本文将从准备工作 → 启动 RTSP 服务 → 推流 → 播放验证，一步一步带你完整跑通。
一、准备工作
1️⃣ 操作系统
macOS（Intel / Apple Silicon 均可）
已安装Homebrew（macOS 包管理工具）
如果还没装 Homebrew，可参考官方方式：
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"2️⃣ 安装 FFmpeg（用于推流）
brew install ffmpeg安装完成后确认：
ffmpeg -version我的是 7.1.1的版本
3️⃣ 安装 MediaMTX（RTSP 服务端）
MediaMTX 是一个轻量级、多协议的流媒体服务器，原名 rtsp-simple-server，非常适合本地测试。
brew install mediamtx确认安装成功：
mediamtx --version我的版本是 v1.15.6
二、准备一个测试视频文件
准备一个本地视频文件，例如：
test.mp4要求不高，常见的 H.264 + AAC 即可。
示例路径：
/Users/yourname/Videos/test.mp4三、配置并启动 RTSP 服务
1️⃣ 创建配置文件
在任意目录创建一个mediamtx.yml：
paths: live: {}说明：
paths：RTSP 的“挂载点”配置live：RTSP 路径名，对应rtsp://host:8554/live{}：使用默认配置，允许推流和播放
2️⃣ 启动 MediaMTX
在配置文件所在目录执行：
mediamtx mediamtx.yml看到类似日志说明启动成功：
INF [RTSP] listener opened on :8554 (TCP)⚠️ 如果提示端口被占用（如 8888），请先关闭对应进程或修改配置。
四、使用 FFmpeg 推送 RTSP 流
在另一个终端窗口执行推流命令：
ffmpeg -re -stream_loop -1 -i test.mp4 \ -c:v copy -c:a aac \ -f rtsp -rtsp_transport tcp \ rtsp://127.0.0.1:8554/live参数说明：
| 参数 | 说明 |
|---|---|
-re | 按真实时间推流 |
-stream_loop -1 | 无限循环播放 |
-c:v copy | 视频不转码 |
-c:a aac | 音频使用 AAC |
-rtsp_transport tcp | 使用 TCP 推流（更稳定） |
/live | 对应 MediaMTX 配置的路径 |
如果看到 FFmpeg 持续输出帧信息，说明推流成功。
五、使用播放器进行验证
1️⃣ 使用 VLC 播放
打开 VLC → 打开网络串流 → 输入：
rtsp://127.0.0.1:8554/live如果能正常播放，说明RTSP 推流 + 服务端一切正常。
2️⃣ 用于 Flutter / App / 设备测试
此时你已经拥有了一个：
✅ 稳定
✅ 可循环
✅ 可随时启停
的 RTSP 流，可直接用于：
Flutter 播放器调试
RTSP 连接生命周期测试
服务端行为验证
网络异常测试
至此， 就可以打开VLC播放器来读这个流了。
六、常见问题总结
❓ 推流时报Connection refused
MediaMTX 未启动
端口不一致（默认 RTSP 是 8554）
路径未配置（如
/live不存在）
❓ 提示path 'live' is not configured
检查
mediamtx.yml是否包含：
paths: live: {}❓ 关闭播放器，服务端没有收到 TEARDOWN？
这是正常现象：
RTSP 协议中
TEARDOWN是可选很多播放器（包括 ffmpeg / fvp / 移动端）不会发送
服务端应依赖连接断开或超时
七、总结
通过FFmpeg + MediaMTX，我们可以在 macOS 上：
快速搭建 RTSP 推流环境
不依赖真实摄像头或设备
高效调试播放器和流媒体逻辑
这是一个强烈推荐给所有音视频 / IoT / 客户端开发者的基础测试方案。
如果你愿意，我还可以帮你补一篇进阶的，比如：
《RTSP 推流常见问题与排错清单》
《用 FFmpeg 模拟不稳定 RTSP 网络环境》
《RTSP 在移动端播放器中的真实行为分析》
你想往测试还是协议原理再深入一步？
