RTSP 推流与拉流

1 RTSP

RTSP 的全称是 Real Time Streaming Protocol，中文标准翻译是“实时流传输协议”。

我们可以把这四个单词拆开来看：

1.1 Real Time（实时）

它强调的是低延迟。与你看 Netflix 或 Bilibili 那种为了保证画质可以缓冲好几秒的视频不同，RTSP 诞生之初就是为了监控摄像头、视频会议这种对“即时性”要求极高的场景设计的。它追求的是“那边发生什么，这边立刻看到”。

1.2 Streaming（流传输）

“流”就像自来水一样。你不需要把一个几 GB 的视频文件全部下载（Download）到本地硬盘才能打开看。视频数据像流水一样，源源不断地送过来，你的播放器接住一滴就播一滴，播完就扔掉，不占本地存储空间。

1.3 Protocol（协议）

协议就是两台机器之间沟通的“交规”或“语言”。你要和服务器对话，就必须遵守一套既定的语法。

---

1.4 核心认知澄清：RTSP 其实是一个“遥控器”

这里有一个行业里非常常见的误区：RTSP 协议本身，其实是不负责搬运视频画面的。

你可以把 RTSP 想象成你手里的电视机遥控器。 当用终端去拉流时，RTSP 在网络上发送的，其实都是纯文本的“控制指令”。

如果查看拉流日志，里面其实就藏着 Progress: (request) SETUP stream 0 和 Progress: (request) Sent PLAY request 这样的字眼。

那么真正搬运画面的“苦力”是谁呢？ 是它的底层兄弟协议，通常叫做 RTP (Real-time Transport Protocol)。 RTSP 负责在“上层”发号施令建立连接，而底层的 RTP 就像一辆辆小卡车，把 H.264 编码的视频一车一车地运过来。所以在 GStreamer 的管道里，会用到 rtph264depay（把 RTP 卡车里的 H.264 货物卸下来）这个插件。

简而言之，RTSP 就是流媒体世界里，用来控制视频流播放、暂停和断开的“网络高级遥控器”。

2 推流 (Push Stream) —— “我是主播，我把画面送上云端”

• 概念：推流是指将现场的视频/音频数据（比如摄像头的画面，或者本地的视频文件）主动发送（上传）给中心化的流媒体服务器的过程。
• 角色：你是内容的生产者。
• 在你刚才的实操中： 当你运行下面这条命令时，你就是在推流：

ffmpeg -re -stream_loop -1 -i test.mp4 -c copy -f rtsp rtsp://127.0.0.1:8554/mystream

解析：这里的 ffmpeg 就是推流客户端。它把本地的 test.mp4 文件拆解成数据包，源源不断地“推”给了地址为 127.0.0.1:8554、房间号为 mystream 的流媒体服务器。

• 现实生活中的例子：网红用手机开直播，手机把她的画面实时上传到抖音服务器，这就是推流。或者你们公司的 IPC（网络摄像头）通电后，把录制的画面传给安防监控中心，也是推流。

---

3 拉流 (Pull Stream) —— “我是观众，我要看这个频道的画面”

• 概念：拉流是指客户端主动向流媒体服务器发送请求，要求获取（下载）某个特定频道的视频/音频数据，并在本地进行解码和播放的过程。
• 角色：你是内容的消费者。
• 在你刚才的实操中： 当你运行下面这条带着 rtspsrc 和 mppvideodec 的命令时，你就是在拉流：

gst-launch-1.0 rtspsrc location="rtsp://127.0.0.1:8554/mystream" ... ! glimagesink

解析：这里的 GStreamer 就是拉流客户端。rtspsrc (RTSP Source) 插件敲开了服务器的大门，说：“嘿，把 mystream 这个房间的画面给我一份”，然后拿到数据，交给瑞芯微的硬件解码器解码，最后画在屏幕上。

• 现实生活中的例子：你打开手机上的抖音 APP，点进某个主播的直播间观看画面；或者客户在他们的控制大屏上，调出某个摄像头的监控画面，这都是拉流。

---

4 中间人：流媒体服务器 (RTSP Server)

• 概念：它是一个数据分发中心。它不负责生产画面，也不负责看画面，它只负责接收推流，并响应拉流请求。
• 在你刚才的实操中： 那个默默运行在后台的 mediamtx 就是服务器。
• 它先接收了 FFmpeg 推过来的数据。
• 然后你的 GStreamer 跑过来拉流，它就把数据复制一份发给 GStreamer。