波仔
🎬 第八章 FFmpeg命令行实现流媒体功能及直播应用
📄 一句话概括

RTSP 是「遥控器」，不是「水管」——它只下指令，画面走 RTP。 一条 OPTIONS 请求只有 93 字节，默认端口 554。

📝 本节和前面几节的关系

前七章都在本机处理文件，从这一章起画面要出门了。 8.1 讲最老的 RTSP，它是「拉模式」的代表： 客户端不来要，服务器一个字节都不发。

一、一句话说清 RTSP 是什么

RTSP 全称 Real Time Streaming Protocol，实时流协议。 名字里带 Streaming，但它自己一帧画面都不传。

它管的是「开始、暂停、快进、结束」这几件事。 真正的音视频数据走 RTP（8.2 讲），或者塞进 RTSP 自己的 TCP 连接里。

协议 管什么 打个比方

RTSP 控制指令 遥控器上的按键 RTP 音视频数据包 水管里的水 RTCP 收发统计与同步 水表 SDP 流的说明书 水管的规格单

四个协议各管一件事，缺一个就有一环说不清。 最容易混的是 RTSP 与 RTP——名字只差一个字母，干的活完全不同。

记住一句话就够：RTSP 那一头很轻，因为它只传几行文本。 所以它从不担心带宽，也从不做重传——重传是 RTP 那一层该头疼的事。

二、一条请求长什么样

一条 RTSP 请求是纯文本，四部分组成：请求行、头字段、空行、（可选）体。 实测一条 OPTIONS 请求总共 93 字节：

部分 内容 字节

请求行 方法 ＋ URI ＋ 版本 55 头字段 CSeq 与 User-Agent 两行 36 空行 两个 CRLF，结束头部 2 整条请求 发到网络上就这些字节 93

三部分加起来正好 93，一个字节不多。 所以 RTSP 的握手成本极低——四条请求一共才几百字节（8.1.4 有实测）。

请求行里三样东西：方法（OPTIONS）、URI、协议版本。 URI 是 rtsp:// 开头，后面没有扩展名——因为对面不是文件，是一条流。

streamid=0 是服务器自己起的名字，叫 live、叫 ch1 都行。 这一点跟 HTTP 很不一样：HTTP 的路径对应磁盘上的文件，RTSP 的路径对应一条流。

三、它跟 HTTP 差在哪

两者格式几乎一样，都是「起始行 + 头 + 空行 + 体」。 差别在这四处：

对比项 HTTP RTSP

请求行 GET /x.mp4 HTTP/1.1 OPTIONS rtsp://… RTSP/1.0 方法集 GET／HEAD／POST… OPTIONS／DESCRIBE／SETUP… 默认端口 80／443 554 干什么用 取一个文件 控制一条流

第四行是关键：HTTP 取回一个完整的东西，取完连接就完事。 RTSP 是「控制一条一直在动的流」，一个会话可能持续几个小时。

所以 RTSP 必须自己管会话：每条请求都带 Session 头，靠它认人。 HTTP 本来不需要这个（后来加了 Cookie，是同一类需求）。

还有一个差别：RTSP 允许服务器「反向」给客户端发消息。 比如服务器想通知「流要断了」，可以在客户端没请求的情况下发一条。 HTTP 永远是客户端先开口，这一点上 RTSP 更像电话、HTTP 更像寄信。

四、九个方法各自干什么

RTSP 一共定义了九个方法，常用的只有五个：

方法 谁发 干什么

OPTIONS 客户端 问服务器支持哪些方法 DESCRIBE 客户端 要一份 SDP 说明书 SETUP 客户端 商量传输方式与端口 PLAY 客户端 开始发媒体 TEARDOWN 客户端 结束会话 PAUSE 客户端 暂停，连接不断 ANNOUNCE 推流方 推流时告知有什么流 RECORD 推流方 推流时开始录 GET_PARAMETER 两边 保活、查参数

前五个是「看」的流程，中间两个是「推」的流程。 最后一个 GET_PARAMETER 常被拿来当心跳：会话超时前发一个，把计时器续上。

注意 PLAY 是「客户端」发的——这就是拉模式的证据。 服务器想开播也没用，它得等客户端说 PLAY 才敢发数据。

反过来说，RTSP 也能推流（ANNOUNCE ＋ RECORD），但业界很少这么用。 推流基本都交给 RTMP 或 SRT 了，因为 RTSP 推流要两边都支持这一套，太麻烦。

五、动手 Demo：一条请求的分段字节账

下面这段代码把一条 OPTIONS 请求拆成三段量字节，再跟 HTTP 逐项对比， 最后列一遍九个方法的用途。

req = (u"OPTIONS rtsp://127.0.0.1:554/live/streamid=0 RTSP/1.0\r\n"
       u"CSeq: 1\r\n"
       u"User-Agent: Lavf62.12.102\r\n"
       u"\r\n")

line = u"OPTIONS rtsp://127.0.0.1:554/live/streamid=0 RTSP/1.0"
print(u"请求行  %d 字节" % (len(line) + 2))
print(u"头字段  %d 字节" % (len(req) - len(line) - 4))
print(u"空行    2 字节")
print(u"整条    %d 字节" % len(req))

for tag, l in ((u"HTTP", u"GET /s7.mp4 HTTP/1.1"),
               (u"RTSP", line)):
    print(u"%-6s %d 字符" % (tag, len(l)))

实跑输出：

--------------------------------------------------------------------
8.1.1 RTSP 简介
--------------------------------------------------------------------

**① 一条 RTSP 请求就是一封「格式固定的信」**

  `OPTIONS rtsp://127.0.0.1:554/live/streamid=0 RTSP/1.0`
  `CSeq: 1`
  `User-Agent: Lavf62.12.102`
  `（空行）`

  部分         内容                        字节
  -------------------------------------------------
  请求行       方法 ＋ URI ＋ 版本         55
  头字段       CSeq ＋ User-Agent 两行     36
  空行         两个 CRLF 结束头部          2
  整条请求     发到网络上就是这些字节      93

**② 它跟 HTTP 长得一模一样，只差三样**

  对比项       HTTP                    RTSP
  ------------------------------------------------------------------
  请求行       GET /x.mp4 HTTP/1.1     OPTIONS rtsp://… RTSP/1.0
  方法集       GET／HEAD／POST…        OPTIONS／DESCRIBE／SETUP…
  默认端口     80／443                 554
  干什么用     取一个文件              控制一条流

**RTSP 的 URI 里没有扩展名，因为对面不是文件，是一条流。**
**`streamid=0` 是服务器自己定的名字，叫什么都可以。**

**③ 方法一共九个，常用的五个**

  方法              谁发       干什么
  -------------------------------------------------------------
  OPTIONS           客户端     问服务器支持哪些方法
  DESCRIBE          客户端     要一份 SDP，说明流里有什么
  SETUP             客户端     为每一路流商量传输方式与端口
  PLAY              客户端     开始发（或开始收）媒体
  TEARDOWN          客户端     结束会话
  PAUSE             客户端     暂停，媒体流不断只停发
  ANNOUNCE          推流方     推流时告诉服务器我有什么
  RECORD            推流方     推流时开始录
  GET_PARAMETER     两边       保活、查参数

**④ 关键一句：RTSP 只传「控制指令」，不传媒体**

**音频视频走 RTP、走 TCP 的 interleaved 通道，甚至走别的机器。**
**RTSP 那一头只管「开始、暂停、结束」，所以它天生轻。**

**这也解释了一件事：为什么 RTSP 拉流必须「客户端先连」——**
**因为发不发是客户端用 PLAY 说了算，服务器不能自己开播。**

三段 55 ＋ 36 ＋ 2 正好 93 字节，跟节里那张表一一对上。

55 字节这一行里，光 URI 就占 36 个字符（rtsp:// 七字符、地址与端口十三字符、/live/streamid=0 十六字符）。 所以「流路径写得越短，握手越省」——虽然这点字节根本没人会在意。

最后两行是 HTTP 与 RTSP 的请求行对比：一个 22 字符、一个 53 字符。 差的不是格式，是 URI 里那串 rtsp://主机:端口/路径。

30 秒实验

  1. 改路径：把 streamid=0 换成 live，看请求行字节数变不变。
  2. 删掉 User-Agent：整条请求少 27 字节，服务器照样认。
  3. 加一条 Session 头：Session: 12345678 是 21 字节，体会一下「会话成本」。

常见误区

  1. 以为 RTSP 传画面。它只传指令，画面走 RTP。
  2. 把 RTSP 当成 HTTP 的兄弟。格式像，但一个有会话、一个没有。
  3. 以为 PLAY 是服务器发的。拉模式下永远是客户端发。
自测三问（点开对答案） 1. RTSP 传不传音视频数据？ —— 不传。它只传控制指令，媒体走 RTP 或 interleaved 通道。 2. 一条 OPTIONS 请求多大？ —— 93 字节：请求行 55、头字段 36、空行 2。 3. 为什么 URI 里没有扩展名？ —— 因为对面不是文件，是一条流，名字由服务器自己定。

相关笔记