📚 课程目录第3章推流与拉流概念

3. 推流与拉流概念

在 RTSP 推流实战中，很多人第一次接触“推流”“拉流”“转发”“转码”这四个词时，容易把它们混为一谈。实际上，它们描述的是流媒体链路中完全不同的动作：谁主动、谁被动、数据往哪个方向走、是否改变编码格式，决定了系统架构和排障思路。理解这四个概念，是搭建稳定 RTSP 环境的前提。

一、核心原理：四个动作的本质区别

流媒体传输的本质是“一端产生数据，另一端消费数据”。围绕这个本质，四个概念可以这样区分：

推流（Push）：采集端主动把音视频数据“送出去”。例如摄像头、OBS、FFmpeg 把流推到 RTSP 服务器或 RTMP 服务器。推流端是主动方，需要知道目标地址。
拉流（Pull）：播放端主动向服务器“要数据”。例如 VLC、播放器、NVR 向 RTSP 地址发起 DESCRIBE、SETUP、PLAY 请求。拉流端是主动方，服务器被动响应。
转发（Forward/Relay）：服务器或中间节点把收到的流原样复制给多个下游，不改变编码、分辨率、帧率。它解决的是“一路输入、多路输出”的分发问题。
转码（Transcode）：把输入流解码后再重新编码，改变编码格式、分辨率、码率或封装。它解决的是“下游设备不支持原格式”或“需要降低带宽”的兼容性问题。

关键判断：转发是“复制”，转码是“重造”。转发几乎不消耗 CPU 的编解码算力，转码则非常吃 CPU/GPU。RTSP 链路中，能转发就不要转码。

二、RTSP 在流媒体链路中的位置

RTSP（Real Time Streaming Protocol）是一个“控制协议”，它本身不传输音视频数据，而是负责建立、控制和拆除会话。真正的音视频数据由 RTP 承载，RTCP 负责传输质量反馈。因此，RTSP 在链路中处于“信令控制层”，而不是“数据承载层”。

一个典型的 RTSP 链路可以表示为：

摄像头/编码器 --RTSP推流--> RTSP服务器 --RTSP拉流--> 播放器/NVR
                              |
                              +--转发--> 多个播放端
                              |
                              +--转码--> HLS/WebRTC/低码率RTSP

在这个链路中，RTSP 服务器既是推流端的“接收者”，也是拉流端的“提供者”。它负责管理会话、维护流列表、处理并发拉流。如果服务器只做转发，那么它更像一个“流路由器”；如果服务器做转码，它就是一个“媒体处理节点”。

三、方法流程：一次完整 RTSP 会话发生了什么

以“摄像头推流到 RTSP 服务器，播放器拉流观看”为例，流程如下：

摄像头通过 RTSP ANNOUNCE 告知服务器要推送的流地址和媒体描述（SDP）。
服务器返回 200 OK，摄像头执行 RECORD，开始通过 RTP 发送音视频包。
播放器向服务器发起 DESCRIBE，获取 SDP，了解编码格式、分辨率、端口。
播放器执行 SETUP，建立 RTP/RTCP 传输通道；再执行 PLAY，开始接收数据。
如果服务器配置了转发，多个播放器可以同时拉同一路流；如果配置了转码，服务器会先解码再编码后输出。
播放结束，播放器发送 TEARDOWN，服务器释放会话资源。

排障提示：如果播放器能连上但黑屏，优先检查 SETUP 阶段的传输方式（TCP/UDP）是否匹配；如果画面卡顿，优先看 RTCP 丢包统计和服务器出口带宽。

四、对比清单：推流、拉流、转发、转码

概念	主动方	数据方向	是否改变编码	资源开销	典型工具/协议
推流	采集端	端 → 服务器	否	低（仅采集编码）	FFmpeg、OBS、RTSP ANNOUNCE
拉流	播放端	服务器 → 端	否	低（仅解码播放）	VLC、NVR、RTSP PLAY
转发	服务器	服务器 → 多端	否	低（内存复制）	MediaMTX、Nginx-RTMP relay
转码	服务器	服务器 → 多端	是	高（CPU/GPU）	FFmpeg、GPU 转码卡

五、案例与场景：什么时候用转发，什么时候用转码

场景一：安防监控多屏查看。 一路 1080P 摄像头推流到 RTSP 服务器，保安室 4 台客户端同时拉流。此时应使用转发，服务器只复制 RTP 包，CPU 占用极低。如果误用转码，4 路同时转码会让服务器 CPU 飙升，反而导致卡顿。

场景二：浏览器无插件播放。 浏览器原生不支持 RTSP，需要把 RTSP 转成 HLS 或 WebRTC。这时必须转码或至少转封装。如果只是转封装（如 RTSP 转 HLS），不改变编码，开销中等；如果还要降低码率适配弱网，就必须真正转码。

场景三：远程巡检低带宽回传。 现场摄像头是 4Mbps 的 H.265 流，回传链路只有 1Mbps。此时需要在边缘服务器转码为 800Kbps 的 H.264，再推送到中心 RTSP 服务器。这里转码是刚需，转发无法解决带宽问题。

常见误区：把“转发”当成“转码”来配置，导致服务器 CPU 跑满；或者把“转码”当成“转发”来用，导致下游设备无法解码。判断标准很简单——下游能不能直接解原流？能，就转发；不能，才转码。

六、复盘：RTSP 链路设计的三个原则

就近转发，按需转码。 能在边缘转发的，不要拉到中心转码；能转封装的，不要重新编码。
先确认协议层，再查数据层。 RTSP 负责控制，RTP 负责数据。连不上先查 RTSP 信令，画面异常再查 RTP/RTCP。
用真实参数验证。 推流端码率、分辨率、编码格式，拉流端支持的协议和封装，必须逐项核对，不能凭感觉。

掌握推流、拉流、转发、转码的区别，并清楚 RTSP 在链路中处于控制层的位置，后续搭建 RTSP 服务器、配置推流地址、排查拉流失败时，就能快速定位问题属于“信令不通”“数据不到”还是“格式不兼容”，而不是盲目重启服务。