3. 推流与拉流核心概念

在 RTSP 推流全链路中，任何一次可用的视频播放，都可以拆解为三个角色的协同：推流端负责采集与编码，服务端负责接收、缓存与分发，播放端负责请求、解码与渲染。理解这三者的职责边界，是后续调优的前提——因为绝大多数“卡顿、花屏、延迟高”的问题，最终都能定位到某一个角色的某一环。

一、三个角色的职责与数据形态

推流端通常是摄像头、编码器、OBS 或 FFmpeg 进程。它把原始音视频经过采集、编码（H.264/H.265、AAC）、封装（RTP 打包）后，通过 RTSP 的 ANNOUNCE / SETUP / RECORD 流程推给服务端。此时数据形态是RTP 包 + RTCP 反馈。

服务端（如 MediaMTX、ZLMediaKit、Live555、SRS 的 RTSP 模块）是链路的枢纽。它完成三件事：鉴权与路径注册、RTP 包的接收与时间戳重整、以及面向多个播放端的转发。服务端并不解码视频，它只做“搬运 + 少量整形”，因此它的性能瓶颈往往在网络 IO 和缓冲区管理，而不是 CPU 编解码。

播放端通过 DESCRIBE 获取 SDP，再 SETUP 建立传输通道，最后 PLAY 触发数据流。它负责 jitter buffer 抖动缓冲、丢包重排、解码与渲染。播放端的缓冲策略直接决定“低延迟”与“抗抖动”之间的平衡点。

二、RTSP over TCP 与 UDP 的差异

RTSP 本身是控制协议，真正的媒体数据走 RTP。RTP 可以选择 UDP 或 TCP 承载，这是调优中最常见的分叉点。

UDP 模式下，RTP/RTCP 走独立端口（通常为偶数 RTP、奇数 RTCP）。优点是延迟低、无队头阻塞，适合局域网和网络质量稳定的场景。缺点是丢包后没有重传，弱网下容易出现花屏、马赛克，且需要额外开放端口，穿越 NAT 和防火墙较麻烦。

TCP 模式下，RTP 数据通过 RTSP 的同一连接以 interleaved 方式传输（$ 通道帧）。优点是只需一个端口、天然穿透 NAT、丢包由 TCP 重传保证完整性。缺点是丢包时会发生队头阻塞，延迟抖动更明显，高码率下 TCP 窗口和缓冲会推高延迟。

# FFmpeg 强制 TCP 推流
ffmpeg -re -i input.mp4 -c copy -f rtsp -rtsp_transport tcp rtsp://host/live/stream

# FFmpeg 使用 UDP 推流
ffmpeg -re -i input.mp4 -c copy -f rtsp -rtsp_transport udp rtsp://host/live/stream

# 播放端强制 TCP 拉流
ffplay -rtsp_transport tcp rtsp://host/live/stream

实践建议：公网、跨 NAT、弱网优先 TCP；局域网、超低延迟、可控网络优先 UDP。若使用 UDP 且需要抗丢包，可开启 FEC 或调整 jitter buffer。

三、单播、组播与广播的适用场景

寻址模型决定了服务端如何“复制”数据流，直接影响带宽与并发能力。

组播的关键前提是整条路径支持 IGMP 与组播路由。若中间有路由器未开启组播，或客户端在 NAT 之后，组播会直接失效。广播则几乎不用于 RTSP 媒体传输，因为会打扰同网段所有主机，且无法跨网段。

四、一次完整拉流的时序与判断路径

下面这张图把三个角色、两种传输方式与三种寻址模型放在同一条链路上，便于快速判断“当前请求走的是哪条路径”。

五、常见误区与复盘要点

• 误区一：认为 TCP 一定比 UDP 好。TCP 保证完整性，但队头阻塞会放大延迟。低延迟场景下，UDP + FEC 往往优于 TCP。
• 误区二：组播配置了地址就能用。组播依赖 IGMP snooping 和组播路由，交换机、路由器、防火墙任一处未放行都会失败。
• 误区三：把服务端当解码器。服务端只转发不解码，若出现花屏，优先查推流端编码参数与网络丢包，而不是服务端 CPU。
• 误区四：忽略 RTCP。RTCP 提供丢包率、抖动、RTT 反馈，是判断链路质量的关键数据源，调优时应优先采集。