1. 课程导入
RTSP（Real Time Streaming Protocol，实时流传输协议）是音视频领域中用于控制流媒体会话的经典协议，它本身并不负责音视频数据的封装与传输，而是像“遥控器”一样负责 PLAY、PAUSE、TEARDOWN、SETUP 等会话控制。真正承载音视频码流的通常是 RTP/RTCP，而媒体描述则依赖 SDP。很多初学者会把“RTSP 推流”理解成“把文件丢给服务器”，实际上推流链路涉及采集、编码、封装、协议交互、传输、服务端分发与客户端拉流等多个环节。本课程的目标，就是带你从零搭建一套可运行、可观察、可排障的 RTSP 推流实战环境，让你不仅“跑得起来”，还能“看得懂、改得动、查得出”。
一、学习目标：从“能跑”到“能排障”
本课程不是单纯罗列命令，而是围绕一条完整的推流链路建立工程能力。具体目标可以拆成四个层次：
- 概念层：理解 RTSP、RTP、RTCP、SDP、RTMP、HLS 之间的分工与边界，知道 RTSP 负责“控制”，RTP 负责“搬运”，SDP 负责“描述”。
- 环境层：能够在 Linux 或 Windows 上部署流媒体服务器（如 MediaMTX、ZLMediaKit、Live555），并配置端口、鉴权、路径与日志。
- 推流层：能够使用 FFmpeg、GStreamer 或 OBS 将本地文件、摄像头、屏幕画面推送到 RTSP 服务端，并控制码率、分辨率、帧率、编码格式。
- 验证与排障层：能够用 VLC、ffplay、Wireshark、ffprobe 等工具拉流、抓包、查看 SDP 与统计信息，定位“推不上、拉不到、花屏、卡顿、延迟高”等典型问题。
二、核心概念：一张图看清推流链路
下面这张图展示了 RTSP 推流实战环境的核心拓扑。左侧是媒体源，中间是推流客户端与 RTSP 服务器，右侧是拉流播放端。图中同时标出了 RTSP 控制信令、RTP 媒体流、RTCP 反馈以及 SDP 描述的作用位置，便于你建立“信令与媒体分离”的直觉。
三、整体框架：五层环境模型
为了便于学习和排障，我们把 RTSP 推流环境抽象为五层。每一层都有明确的输入、输出和验证手段，后续章节会逐层展开。
| 层级 | 核心对象 | 典型工具/组件 | 验证方式 |
|---|---|---|---|
| 媒体源层 | 摄像头、文件、屏幕、测试源 | v4l2、file、testsrc、screen-capture | ffprobe 查看源信息 |
| 编码封装层 | H.264/H.265、AAC、RTP 打包 | libx264、libx265、aac、rtpenc | ffprobe 查看编码参数 |
| 协议控制层 | RTSP 会话、SDP、RTP/RTCP | FFmpeg、Live555、MediaMTX | Wireshark 抓包、日志 |
| 服务分发层 | 路径、鉴权、转发、录制 | MediaMTX、ZLMediaKit、Nginx-RTMP | 服务端日志、API 状态 |
| 播放验证层 | 拉流、解码、渲染、统计 | VLC、ffplay、WebRTC、HLS | 画面、延迟、丢包统计 |
四、方法流程：一条最小可运行链路
下面给出一条最小可运行的推流命令示例。它使用 FFmpeg 生成测试画面，编码为 H.264，并推送到本地 MediaMTX 的 RTSP 路径。你可以先不深究每个参数，重点是建立“源—编码—推流—服务端—拉流”的完整闭环。
# 1. 启动 RTSP 服务器（以 MediaMTX 为例）
./mediamtx
# 2. 使用 FFmpeg 推送测试流到 RTSP 服务端
ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=25 \
-c:v libx264 -preset veryfast -tune zerolatency \
-b:v 1500k -pix_fmt yuv420p \
-f rtsp rtsp://127.0.0.1:8554/live
# 3. 使用 ffplay 拉流验证
ffplay -rtsp_transport tcp rtsp://127.0.0.1:8554/live
# 4. 查看流信息
ffprobe -v error -show_streams rtsp://127.0.0.1:8554/live-rtsp_transport tcp。UDP 虽然延迟更低，但在丢包、NAT、防火墙环境下更容易出现花屏和卡顿，不利于初学者定位问题。
五、案例与场景：从实验室到生产
在实验室中，我们通常用本机回环地址和测试图快速验证链路；在真实场景中，环境会复杂得多。例如：安防摄像头通过 RTSP 推流到中心服务器，再由服务器转封装为 HLS 或 WebRTC 供浏览器播放；在线教育场景中，讲师端用 OBS 推 RTMP，再由服务端转 RTSP 供低延迟终端拉取；工业质检场景中，多路摄像头同时推流，对带宽、延迟和稳定性要求极高。不同场景对传输协议、编码参数、缓冲策略的选择完全不同，这也是本课程后续要逐一拆解的内容。
六、常见误区与复盘
- 误区一：把 RTSP 当成传输协议。RTSP 只负责控制，媒体数据由 RTP 承载，二者常配合使用但职责不同。
- 误区二：只关注推流命令，不关注服务端日志。推流失败时，服务端日志往往比客户端报错更直接，例如路径冲突、鉴权失败、端口占用。
- 误区三：忽略时间戳与时钟同步。RTP 时间戳、RTCP SR 与系统时钟不一致，会导致播放端音画不同步或延迟累积。
- 误区四：用 UDP 测试后直接上生产。实验室 UDP 正常不代表公网可用，生产环境应结合 TCP、重传、拥塞控制与缓冲策略综合评估。
七、学习路径：30 章如何展开
整门课程将沿着“概念—环境—推流—拉流—排障—优化”的主线推进。前几章聚焦协议概念与环境准备，中间章节进入 FFmpeg/GStreamer 推流实战、服务端配置与多协议转换，后段则覆盖抓包分析、延迟优化、并发压测与生产部署。你在学习每一章时，都可以回到本节这张拓扑图，问自己三个问题：当前操作位于哪一层？输入输出是什么？用什么工具验证？只要这三个问题能回答清楚，RTSP 推流环境就不再是黑盒。