📚 课程目录第3章 RTSP协议详解

3. RTSP协议详解

在旭日视频流部署链路中，RTSP 是摄像头与边缘计算设备之间的第一道“会话入口”。它并不直接承载视频帧，而是负责建立、控制和拆除媒体会话，真正的音视频数据通常由 RTP/RTCP 传输。理解 RTSP 的协议原理、交互流程和报文结构，是后续解码、抽帧和 BPU 推理稳定运行的前提。

一、协议原理：RTSP 是“带外控制”的文本协议

RTSP（Real Time Streaming Protocol）由 IETF 在 RFC 2326 中定义，设计目标类似于 HTTP，但面向实时流媒体。它采用客户端/服务器模型，默认端口 554，报文以 ASCII 文本形式组织，因此可读性强、便于抓包分析。RTSP 的核心思想是“控制与传输分离”：RTSP 负责会话控制，RTP 负责媒体数据传输，RTCP 负责传输质量反馈。

RTSP 支持两种主要的传输模式：

TCP 交错模式（RTP over RTSP）：RTP 包通过 RTSP 的 TCP 连接传输，用 $ 符号区分通道，穿透 NAT 和防火墙能力强，但延迟抖动可能受 TCP 重传影响。
UDP 模式：RTP/RTCP 使用独立 UDP 端口传输，实时性更好，但丢包和 NAT 穿透问题更明显。

在旭日设备部署中，若摄像头与设备在同一局域网，UDP 模式通常延迟更低；若跨网段或经过防火墙，建议优先使用 TCP 交错模式，减少“能连上但收不到流”的问题。

二、交互流程：从 DESCRIBE 到 TEARDOWN

一次完整的 RTSP 会话通常包含以下方法：OPTIONS、DESCRIBE、SETUP、PLAY、PAUSE、TEARDOWN。其典型交互顺序如下：

OPTIONS：客户端询问服务器支持哪些方法，服务器返回 Public 头。
DESCRIBE：客户端请求媒体描述信息，服务器返回 SDP（Session Description Protocol），其中包含编码格式、分辨率、时钟频率和媒体轨道信息。
SETUP：为每个媒体轨道建立传输参数，包括 RTP/RTCP 端口、传输模式（TCP/UDP）和会话 ID。
PLAY：客户端请求开始播放，服务器返回 RTP-Info，随后开始发送 RTP 包。
PAUSE：暂停播放，RTP 包停止发送，但会话保持。
TEARDOWN：结束会话，释放服务器资源。

下面这张图展示了 RTSP 客户端与摄像头之间的典型时序关系，以及 RTP/RTCP 的并行数据通道：

三、报文结构：请求行、状态行与头部字段

RTSP 报文分为请求报文和响应报文。请求报文由请求行、首部行和实体主体组成；响应报文由状态行、首部行和实体主体组成。请求行格式为 Method SP Request-URI SP RTSP-Version CRLF，状态行格式为 RTSP-Version SP Status-Code SP Reason-Phrase CRLF。

下面是一个真实的 DESCRIBE 请求与响应示例，注意 SDP 中 sprop-parameter-sets 携带了 H.264 的 SPS/PPS，这是解码器初始化的关键参数：

DESCRIBE rtsp://192.168.1.64:554/Streaming/Channels/101 RTSP/1.0
CSeq: 2
User-Agent: Lavf58.76.100
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Length: 512

v=0
o=- 0 0 IN IP4 192.168.1.64
s=Media Presentation
t=0 0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;
  sprop-parameter-sets=Z2QAH6zZQFAFuhAAAAMAEAAAAwPI8YMZYA==,aO48gA==
a=control:trackID=1

常见头部字段及其作用如下表所示：

头部字段	方向	作用	典型值
`CSeq`	请求/响应	命令序列号，请求与响应必须匹配	1、2、3…
`Session`	响应/请求	标识一次会话，SETUP 后由服务器分配	12345678
`Transport`	请求/响应	指定传输模式、端口和交错通道	RTP/AVP/TCP;interleaved=0-1
`Content-Type`	响应	实体主体类型，DESCRIBE 返回 SDP	application/sdp
`RTP-Info`	响应	PLAY 后返回 RTP 序列号和时间戳基准	seq=1000;rtptime=8000
`Public`	响应	服务器支持的方法列表	OPTIONS, DESCRIBE, SETUP, PLAY

四、案例与场景：旭日设备接入 RTSP 摄像头

在旭日 X3 或 X5 设备上，常用 FFmpeg 或 OpenCV 拉取 RTSP 流。以下命令将 RTSP 流以 TCP 模式拉取并保存为 1 帧图像，用于验证链路是否通畅：

ffmpeg -rtsp_transport tcp \
  -i rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101 \
  -frames:v 1 -q:v 2 snapshot.jpg

若使用 Python OpenCV，可这样设置：

import cv2
cap = cv2.VideoCapture(
    "rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101",
    cv2.CAP_FFMPEG
)
cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)
ret, frame = cap.read()

提示：在旭日设备上，建议将 CAP_PROP_BUFFERSIZE 设为 1，避免解码器内部缓存过多旧帧，导致抽帧和 BPU 推理延迟增大。

五、误区与复盘：常见 RTSP 问题定位

误区一：RTSP 连接成功就等于视频流正常。实际上 RTSP 只负责控制，若 SETUP 后没有 RTP 包，可能是传输模式、端口或防火墙问题。
误区二：忽略 SDP 中的 SPS/PPS。若解码器未获取到 sprop-parameter-sets，会出现花屏或无法解码。
误区三：UDP 模式丢包导致画面卡顿。可切换为 TCP 交错模式，或检查网络交换机是否限速。
误区四：Session 超时未保活。RTSP 会话默认 60 秒无请求可能被服务器断开，需定期发送 OPTIONS 或 GET_PARAMETER 保活。

排障建议：使用 ffplay -rtsp_transport tcp -v debug rtsp://... 查看完整 RTSP 交互日志；若出现 451 Unsupported Transport，说明摄像头不支持当前传输模式，需改用 UDP 或调整 interleaved 通道。

掌握 RTSP 的协议原理、交互流程和报文结构后，就能在旭日视频流部署中快速判断问题出在“会话建立”“媒体描述”还是“RTP 传输”阶段，为后续解码、抽帧和 BPU 推理打下稳定基础。