2. 流媒体基础
在正式动手写 RTSP 推流代码之前，必须先弄清楚一件事：我们到底在“推”什么、数据在网络里是怎么流动的、为什么直播和点播看起来都是“播放视频”，底层却几乎是两套逻辑。这一节把流媒体的地基打牢，后面写 RTSP 客户端、搭 RTSP 服务器、做转发时，你才能知道每一步操作对应的是哪一层。
一、流媒体传输原理：边下边播，而不是下完再播
普通文件下载的逻辑是“先完整拿到文件，再交给播放器”。流媒体则相反：媒体数据被切成一个个小片段（帧或分片），持续地从服务端流向客户端，客户端收到一小段就开始解码播放，同时继续接收后续数据。这种“边接收、边解码、边播放”的模式，就是流媒体的核心。
要理解它，需要抓住三个关键角色和一条数据链路：
- 采集/编码端：摄像头或文件源产生原始音视频，经过 H.264/H.265 视频编码和 AAC 音频编码，压缩成码流。
- 封装/传输端：把编码后的裸码流按协议打包，例如 RTP 包、TS 分片、FLV Tag，再通过网络发送。
- 播放端：接收数据、缓冲、解封装、解码、渲染，并处理抖动、丢包和音视频同步。
其中“缓冲”是流媒体体验的命门。网络不可能绝对稳定，播放器必须先用一小段缓冲吸收抖动。缓冲太小会卡顿，缓冲太大则延迟升高。直播追求低延迟，点播追求流畅，本质就是在缓冲策略上做不同的取舍。
端到端延迟 ≈ 编码延迟 + 网络传输延迟 + 缓冲延迟 + 解码渲染延迟
RTSP 推流之所以常用于安防和互动场景，就是因为它能把缓冲压得很低，延迟通常可控制在几百毫秒级。
二、实时流与点播的区别
很多人把“直播”和“点播”混为一谈，其实它们在数据方向、时间轴和协议选择上完全不同。
| 对比维度 | 实时流（直播） | 点播（VOD） |
|---|---|---|
| 数据方向 | 推流端 → 服务端 → 播放端，持续单向推送 | 播放端主动向服务端请求指定片段 |
| 时间轴 | 只有“现在”，无法回退，内容随采集实时产生 | 完整时间轴，可任意拖动、暂停、倍速 |
| 延迟要求 | 极敏感，通常要求秒级甚至亚秒级 | 不敏感，缓冲可以很大 |
| 典型协议 | RTSP/RTP、RTMP、WebRTC、SRT | HLS、DASH、HTTP-FLV（准点播） |
| 服务端行为 | 转发为主，几乎不落盘或只做短时缓存 | 切片存储，按索引提供文件 |
| 典型场景 | 安防监控、视频会议、互动直播 | 影视网站、课程回放、短视频 |
从工程角度看，实时流最难的不是“传过去”，而是“稳定地低延迟传过去”。点播可以靠大缓冲和 CDN 缓存把问题掩盖掉，直播则必须直面丢包、抖动和时钟漂移。RTSP 正是为实时流设计的协议，它用 RTP 承载媒体、用 RTCP 做质量反馈，天生面向低延迟场景。
三、常见流媒体协议概览
协议没有绝对优劣，只有适不适合。下面这张信号链式的协议关系图，展示了从采集端到播放端，几种主流协议各自所处的位置和典型搭配。
结合上图，可以把协议选择归纳成几条实用原则：
- 要低延迟、要控制：选 RTSP/RTP，或 WebRTC。安防球机、云台控制、远程操控都依赖 RTSP 的 DESCRIBE/SETUP/PLAY 交互。
- 要推流到直播平台：选 RTMP，OBS 等工具默认就是它，生态最成熟。
- 要覆盖海量观众、兼容浏览器：选 HLS 或 DASH，用 CDN 分发，代价是延迟。
- 要抗弱网、跨公网：可考虑 SRT，它在 UDP 上做了重传和纠错，适合不稳定链路。
四、案例与实操：一次 RTSP 拉流都发生了什么
假设我们用 FFmpeg 从一台 IP 摄像机拉流并转推到本地 RTSP 服务器，命令如下：
# 从摄像机拉 RTSP 流，转封装后推给本地 RTSP 服务器
ffmpeg -rtsp_transport tcp \
-i rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101 \
-c copy -f rtsp rtsp://127.0.0.1:8554/live/cam01
# 用 ffplay 验证拉流是否成功
ffplay -rtsp_transport tcp rtsp://127.0.0.1:8554/live/cam01这条命令背后依次发生了：TCP 建连 → RTSP OPTIONS 探测 → DESCRIBE 获取 SDP → SETUP 建立 RTP 会话 → PLAY 开始传输 → RTP 包持续到达 → 播放器解封装解码。如果中间任何一步失败，日志里会明确停在某个方法上，这也是后面排障的重要线索。
-rtsp_transport tcp。UDP 模式虽然延迟更低，但在丢包或 NAT 环境下容易出现花屏、卡顿，先用 TCP 确认链路和鉴权没问题，再考虑切回 UDP 优化延迟。