3. 推流与拉流核心概念

在 RTSP 推流稳定化体系中，最先需要厘清的不是某个参数，而是“谁在做什么”。很多推流不稳定、播放卡顿、首帧慢的问题，根源并不在编码器，而在于角色边界模糊、传输方式选错、单播与组播混用。本节把 RTSP 链路拆成三个明确角色，再对比 TCP 与 UDP 的差异，最后落到单播与组播的适用场景，为后续排障建立判断坐标。

一、三个角色：推流端、服务端、播放端

RTSP 本身是“控制协议”，它负责建立会话、协商媒体参数、控制播放与暂停，真正的音视频数据由 RTP 承载。因此一条完整链路至少包含三个角色：

• 推流端（Publisher / Source）：负责采集、编码、封装，并通过 RTSP ANNOUNCE + SETUP + RECORD 把媒体流推给服务端。常见形态是 IPC、NVR、OBS、FFmpeg 进程或自研 SDK。它关心的是编码参数、关键帧间隔、发送节奏和网络出口带宽。
• 服务端（RTSP Server / Media Server）：负责接收推流、维护会话状态、转发或录制。它同时承担鉴权、路径映射、并发连接管理、缓存与丢包重传策略。服务端是整条链路的“交通枢纽”，也是稳定性问题最集中的位置。
• 播放端（Player / Client）：通过 DESCRIBE 获取 SDP，SETUP 建立传输通道，PLAY 开始拉流，接收 RTP 并解码渲染。播放端关心首帧时间、缓冲策略、解码能力和网络抖动容忍度。

三者的关系可以用下面的结构图表示。注意：RTSP 控制信令与 RTP 媒体数据是两条并行的通道，理解这一点是后续选择 TCP 或 UDP 的前提。

二、RTSP over TCP 与 UDP 的差异

RTSP 的 SETUP 阶段会协商 RTP 的承载方式，常见两种：RTP over UDP 与 RTP over TCP（Interleaved）。它们不是“谁更先进”的问题，而是对网络环境的适配选择。

在 FFmpeg 中，可以通过参数强制指定传输方式，这是排障时最直接的验证手段：

# 使用 TCP 承载 RTP（推荐公网/跨 NAT）
ffplay -rtsp_transport tcp rtsp://192.168.1.10:554/live

# 使用 UDP 承载 RTP（推荐局域网低延迟）
ffplay -rtsp_transport udp rtsp://192.168.1.10:554/live

# 推流端指定 TCP 输出
ffmpeg -re -i input.mp4 -c copy -f rtsp -rtsp_transport tcp rtsp://server:554/live/stream

三、单播与组播场景

单播（Unicast）是一对一传输：每个播放端都与服务端建立独立会话，服务端为每个客户端复制一份 RTP 流。组播（Multicast）是一对多传输：服务端只发送一份流到组播组地址，网络设备负责复制分发，播放端加入组播组即可接收。

• 单播适用：点对点监控、客户端数量少、需要独立控制（不同播放端可暂停/回放）、跨网段或公网访问。缺点是客户端越多，服务端出口带宽和 CPU 压力越大。
• 组播适用：局域网内大量客户端观看同一路流，如园区监控大屏、教室直播、IPTV。优点是服务端只发一份，带宽不随客户端数量线性增长。缺点是需要交换机支持 IGMP Snooping，跨网段需配置组播路由，公网基本不可用。

四、案例与复盘：一次“花屏 + 首帧慢”的排查

某园区项目反馈：局域网内播放正常，但通过 VPN 远程播放时频繁花屏，首帧超过 8 秒。排查过程如下：

1. 确认推流端编码正常，关键帧间隔 2 秒，码率 4 Mbps，无异常。
2. 抓包发现远程播放端使用 UDP 承载 RTP，VPN 链路上存在明显丢包与乱序。
3. 将播放端改为 -rtsp_transport tcp，花屏消失，但首帧仍慢。
4. 进一步检查服务端缓存策略，发现 GOP 缓存过大，调整为按关键帧对齐下发后，首帧降至 1.5 秒内。

复盘结论：传输方式选择要与网络质量匹配，UDP 在可控局域网表现优秀，但在丢包链路上会直接体现为花屏；TCP 解决了丢包，却把问题转化为延迟，需要服务端配合优化缓存与关键帧策略。同时，该场景客户端数量少且分散，应使用单播而非组播。