RTSP 协议详解
Real Time Streaming Protocol------摄像头 / 监控行业的"控制面协议"。最重要的一句话：RTSP 负责控制会话，SDP 负责描述媒体，RTP/RTCP 负责真正传音视频。
本文速览
| 章节 |
读完要掌握什么 |
| 0. RTSP 是啥 |
RTSP 是媒体控制协议，不是直接承载音视频的媒体协议。 |
| 1. 和 RTMP / HTTP / HLS 的差异 |
分清控制面、媒体面、分发协议的边界。 |
| 2. 典型应用 |
IPC、NVR、DVR、监控平台为什么大量使用 RTSP。 |
| 3. URL 格式 |
看懂用户名、密码、host、port、厂家路径和主/子码流。 |
| 4. 完整会话流程 |
从 OPTIONS 到 TEARDOWN，知道每一步在协商什么。 |
| 5. 控制方法 |
掌握 OPTIONS/DESCRIBE/SETUP/PLAY/PAUSE/TEARDOWN 的作用。 |
| 6. 媒体传输模式 |
RTP over UDP、RTP over TCP interleaved、HTTP tunneling 的取舍。 |
| 7. SDP 详解 |
详细理解 SDP 如何描述 track、codec、payload type、SPS/PPS、AAC 参数。 |
| 8. RTP 包格式 |
知道 RTP header 字段、H.264 FU-A、AAC MPEG4-GENERIC 的基本关系。 |
| 9. 鉴权 |
Basic、Digest、RTSPS 的流程和安全边界。 |
| 10. 实战 |
FFmpeg 如何拉 RTSP、转封装、调试。 |
| 11. 用 GStreamer |
用 rtspsrc 快速验证 RTSP 拉流链路。 |
| 12. 服务端 |
GStreamer RTSP Server、Live555、ZLMediaKit 等实现选择。 |
| 13. 常见坑 |
连接失败、UDP 丢包、401、RTCP timeout、SDP 不完整怎么排查。 |
| 14. RTSP vs ONVIF |
RTSP 管媒体，ONVIF 管设备；监控行业通常两者配合。 |
| 15. 总结 |
用一张表记住 RTSP/SDP/RTP/ONVIF 的关系。 |
0. RTSP 是啥
RTSP 的定位可以先按下面这张表记：
| 维度 |
说明 |
| 全称 |
Real Time Streaming Protocol。 |
| 标准 |
RTSP 1.0 对应 RFC 2326，RTSP 2.0 对应 RFC 7826。监控行业大量设备仍以 RTSP 1.0 行为为主。 |
| 默认端口 |
554/TCP；很多测试服务也会用 8554。 |
| 核心定位 |
控制播放会话：探测能力、获取媒体描述、建立 RTP 通道、开始/暂停/结束播放。 |
| 媒体承载 |
真正音视频通常由 RTP/RTCP 承载，不是 RTSP 文本消息直接承载。 |
| 文本风格 |
请求/响应格式很像 HTTP：起始行 + Header + 可选 Body。 |
| 典型设备 |
海康、大华、Axis、Bosch、NVR、DVR、监控平台、部分会议系统。 |
RTSP、SDP、RTP 三者分工：
| 协议 / 格式 |
一句话作用 |
类比 |
| RTSP |
控制播放：OPTIONS/DESCRIBE/SETUP/PLAY。 |
遥控器 / 控制台。 |
| SDP |
描述媒体：有几路 track、codec 是什么、payload type 怎么映射。 |
菜单 / 说明书。 |
| RTP |
承载媒体：H.264/AAC 被打进 RTP 包持续发送。 |
真正的数据传送带。 |
| RTCP |
反馈统计：丢包、抖动、同步信息等。 |
质量反馈通道。 |
核心金句：RTSP 不直接"传视频"，它负责让客户端和摄像头商量好"这路视频怎么传、传到哪个端口、从什么时候开始传"。
1. 跟 RTMP / HTTP / HLS 的本质差异
| 协议 |
控制方式 |
媒体承载 |
典型端口 |
典型场景 |
和 RTSP 的区别 |
| RTSP |
RTSP 文本请求/响应。 |
RTP/RTCP over UDP 或 TCP interleaved。 |
554 |
IPC/NVR/监控。 |
控制面和媒体面通常分离。 |
| RTMP |
AMF 命令。 |
RTMP Message/Chunk 同连接承载音视频。 |
1935 |
直播推流到 CDN。 |
控制和媒体通常走同一条 TCP 长连接。 |
| HTTP |
HTTP 请求/响应。 |
文件、分片、接口响应。 |
80/443 |
Web、下载、HLS/DASH。 |
不是专门的实时媒体控制协议。 |
| HLS/DASH |
拉清单 + 拉分片。 |
TS/fMP4 分片。 |
80/443 |
互联网大规模播放。 |
更适合 CDN 分发，不适合低延迟摄像头控制。 |
| WebRTC |
SDP/ICE/DTLS/SRTP 等。 |
SRTP。 |
动态 |
互动实时音视频。 |
延迟更低，但部署和 NAT 穿透更复杂。 |
2. 典型应用
| 类型 |
场景 |
为什么用 RTSP |
| 适合 |
IP 摄像头拉流 |
设备普遍支持，能直接拿主码流/子码流。 |
| 适合 |
NVR / DVR |
监控录像系统需要稳定拉取多路摄像头。 |
| 适合 |
监控平台接入 |
RTSP + ONVIF 是监控行业常见组合。 |
| 适合 |
局域网专业视频 |
低延迟、可控、设备侧支持广。 |
| 一般 |
互联网跨公网播放 |
NAT、防火墙、UDP 丢包、浏览器不支持都会增加成本。 |
| 不适合 |
大规模 CDN 分发 |
HLS/DASH/HTTP-FLV 更适合缓存和海量播放。 |
| 不适合 |
强互动连麦 |
WebRTC 更适合亚秒级互动。 |
3. URL 格式
RTSP URL 基本形态：
| 部分 |
示例 |
说明 |
| scheme |
rtsp / rtsps |
明文 RTSP 或 RTSP over TLS。 |
| user:pass |
admin:12345@ |
可选；很多摄像头还会走 Digest challenge，不建议在 URL 明文放密码。 |
| host |
192.168.1.100 |
IPC/NVR/流媒体服务器地址。 |
| port |
554 |
RTSP 默认端口，省略时通常按 554。 |
| path |
/Streaming/Channels/101 |
厂商定义的流路径。 |
| query |
?channel=1&subtype=0 |
厂商私有参数，例如通道、码流类型。 |
常见示例：
| 厂商 / 场景 |
URL 示例 |
说明 |
| 海康主码流 |
rtsp://admin:12345@192.168.1.100:554/Streaming/Channels/101 |
101 常表示 1 通道主码流，102 常表示子码流。 |
| 大华主码流 |
rtsp://admin:12345@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0 |
subtype=0 主码流，1 子码流常见。 |
| Axis |
rtsp://192.168.1.100/axis-media/media.amp |
Axis 常见路径。 |
| GStreamer 测试服务 |
rtsp://127.0.0.1:8554/test |
本地测试 RTSP Server 常用。 |
4. 完整会话流程
4.1 标准会话：7 个动作，10 条左右 RTSP 消息
标准 RTSP 拉流流程按"控制消息 + 媒体通道 + RTP 数据"整理成表格更清楚：
| 步骤 |
方向 |
RTSP 方法 / 数据 |
关键 Header / Body |
目的 |
| 1 |
C → S |
OPTIONS |
CSeq、User-Agent |
查询服务端支持哪些 RTSP 方法。 |
| 2 |
S → C |
200 OK |
Public: OPTIONS, DESCRIBE, SETUP, PLAY... |
返回可用方法列表。 |
| 3 |
C → S |
DESCRIBE |
Accept: application/sdp |
请求媒体描述 SDP。 |
| 4 |
S → C |
200 OK + SDP |
Content-Type: application/sdp |
告诉客户端有几路媒体、codec、payload type、track URL。 |
| 5 |
C → S |
SETUP video track |
Transport: RTP/AVP;unicast;client_port=8000-8001 |
为视频 track 协商 RTP/RTCP 端口或 TCP interleaved 通道。 |
| 6 |
S → C |
200 OK |
Session、server_port=6000-6001 |
返回 Session ID 和服务端媒体端口。 |
| 7 |
C → S |
SETUP audio track |
client_port=8002-8003 |
如果有音频 track，再建一路媒体通道。 |
| 8 |
S → C |
200 OK |
通常复用同一个 Session |
音频通道协商成功。 |
| 9 |
C → S |
PLAY |
Session、Range: npt=0.000- |
要求服务端开始发送媒体。 |
| 10 |
S → C |
200 OK |
RTP-Info: url=...;seq=...;rtptime=... |
告诉客户端 RTP 起始序号和 RTP 时间戳映射。 |
| 11 |
S → C |
RTP/RTCP 媒体包 |
UDP 端口或 TCP $ interleaved frame |
服务端开始发送音视频。 |
| 12 |
C → S |
TEARDOWN |
Session |
结束播放并释放服务端会话资源。 |
| 13 |
S → C |
200 OK |
CSeq |
确认会话结束。 |
多 track 的关键点：
| 情况 |
正确理解 |
| 只有视频 |
通常只需要对 trackID=0 执行一次 SETUP。 |
| 音视频都有 |
video 和 audio 通常各自 SETUP 一次，但共享同一个 RTSP Session。 |
| 多码流摄像头 |
主码流和子码流通常是不同 URL，不是同一个 SDP 里随便切。 |
| TCP interleaved |
不协商 UDP client_port，而是协商 interleaved=0-1 这类通道号。 |
4.2 OPTIONS：查询支持的方法
请求示例：
OPTIONS rtsp://192.168.1.100/stream RTSP/1.0
CSeq: 1
User-Agent: VLC/3.0.20
响应示例：
RTSP/1.0 200 OK
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER
字段解释：
| 字段 |
位置 |
作用 |
OPTIONS |
请求行方法 |
探测服务端支持的 RTSP 方法。 |
| URL |
请求行 URI |
可以是具体流 URL，也可以是服务根路径，取决于服务端实现。 |
CSeq |
请求/响应 Header |
RTSP 请求序号；响应必须带回相同 CSeq，便于客户端匹配请求。 |
User-Agent |
请求 Header |
客户端标识，例如 VLC、Lavf、LIVE555。 |
Public |
响应 Header |
服务端声明支持的方法集合。 |
4.3 DESCRIBE：拿 SDP 媒体描述
请求示例：
DESCRIBE rtsp://192.168.1.100/stream RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: Lavf/60.0.0
响应示例：
RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp
Content-Base: rtsp://192.168.1.100/stream/
Content-Length: 520
v=0
o=- 1234567890 1234567890 IN IP4 192.168.1.100
s=IPCamera Stream
c=IN IP4 0.0.0.0
t=0 0
a=control:*
m=video 0 RTP/AVP 96
a=control:trackID=0
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42801F;sprop-parameter-sets=Z0LAH9oBQBboQAAA,aM48gA==
m=audio 0 RTP/AVP 97
a=control:trackID=1
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;config=1190;SizeLength=13;IndexLength=3;IndexDeltaLength=3
DESCRIBE 的价值：
| SDP 告诉客户端什么 |
客户端拿它做什么 |
| 有几路媒体 |
创建 video/audio track。 |
| 每路媒体的 track URL |
对 trackID=0/1 分别发送 SETUP。 |
| Payload Type 到 codec 的映射 |
收到 RTP 包后用 PT 判断是 H.264 还是 AAC。 |
| H.264 时钟频率 |
RTP timestamp 用 90000 时基换算播放时间。 |
| AAC 采样率和声道数 |
初始化音频解码器。 |
| SPS/PPS 或 AAC config |
提前初始化解码器，不必等码流内参数集。 |
4.4 SETUP：建立媒体通道
UDP 模式下，客户端在 SETUP 里告诉服务端"我准备好在哪两个 UDP 端口收 RTP/RTCP"。
视频 track 请求示例：
SETUP rtsp://192.168.1.100/stream/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8000-8001
视频 track 响应示例：
RTSP/1.0 200 OK
CSeq: 3
Session: 12345678;timeout=60
Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=6000-6001;ssrc=0A12B3C4
SETUP 协商结果：
| 字段 |
示例 |
含义 |
Transport |
RTP/AVP;unicast |
RTP Audio/Video Profile，单播模式。 |
client_port |
8000-8001 |
客户端收 RTP/RTCP 的 UDP 端口，通常偶数 RTP、奇数 RTCP。 |
server_port |
6000-6001 |
服务端发送 RTP/RTCP 使用的 UDP 端口。 |
Session |
12345678;timeout=60 |
RTSP 会话 ID，后续 PLAY/PAUSE/TEARDOWN 必须带。 |
ssrc |
0A12B3C4 |
RTP 同步源标识，部分服务端会返回。 |
如果 SDP 有音频 track，还要对音频再 SETUP：
| track |
SETUP URL |
端口示例 |
说明 |
| 视频 |
/stream/trackID=0 |
client_port=8000-8001 |
收视频 RTP/RTCP。 |
| 音频 |
/stream/trackID=1 |
client_port=8002-8003 |
收音频 RTP/RTCP。 |
TCP interleaved 模式的 SETUP 不使用 UDP 端口：
SETUP rtsp://192.168.1.100/stream/trackID=0 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
| 模式 |
Transport 示例 |
媒体怎么走 |
| UDP |
RTP/AVP;unicast;client_port=8000-8001 |
RTP/RTCP 走独立 UDP 端口。 |
| TCP interleaved |
RTP/AVP/TCP;unicast;interleaved=0-1 |
RTP/RTCP 用 $ 帧复用在 RTSP TCP 连接里。 |
4.5 PLAY：开始发送 RTP
请求示例：
PLAY rtsp://192.168.1.100/stream RTSP/1.0
CSeq: 5
Session: 12345678
Range: npt=0.000-
响应示例：
RTSP/1.0 200 OK
CSeq: 5
Session: 12345678
Range: npt=0.000-
RTP-Info: url=rtsp://192.168.1.100/stream/trackID=0;seq=12345;rtptime=98765,url=rtsp://192.168.1.100/stream/trackID=1;seq=32100;rtptime=45678
PLAY 之后发生什么：
| 内容 |
说明 |
| 服务端开始发 RTP |
UDP 模式发到 client_port；TCP 模式发 $ interleaved frame。 |
Range |
npt=0.000- 表示从头或 live 起点开始；点播 seek 也靠它。 |
RTP-Info.seq |
该 track 第一个 RTP 包的 sequence number。 |
RTP-Info.rtptime |
该 track 第一个 RTP 包的 RTP timestamp。 |
| 播放器初始化同步 |
用 RTP-Info、RTP timestamp、RTCP SR 等信息做音视频同步。 |
4.6 PAUSE / TEARDOWN：暂停和结束
| 方法 |
典型请求 |
服务端行为 |
使用场景 |
PAUSE |
带 Session |
暂停发送 RTP，但保留会话资源。 |
点播暂停、部分摄像头不支持。 |
PLAY after PAUSE |
带 Session 和可选 Range |
恢复发送 RTP。 |
点播恢复播放。 |
TEARDOWN |
带 Session |
释放会话、端口、缓存。 |
停止播放、退出页面。 |
GET_PARAMETER |
带 Session |
可作为保活。 |
摄像头/NVR 长连接保活。 |
5. 控制方法
| 方法 |
方向 |
是否常见 |
作用 |
常见 Header |
OPTIONS |
C → S |
高 |
查询服务端支持的方法。 |
CSeq。 |
DESCRIBE |
C → S |
高 |
获取 SDP。 |
Accept: application/sdp。 |
SETUP |
C → S |
高 |
建立 RTP/RTCP 传输通道。 |
Transport、Session。 |
PLAY |
C → S |
高 |
开始或恢复播放。 |
Session、Range。 |
PAUSE |
C → S |
中 |
暂停播放。 |
Session。 |
TEARDOWN |
C → S |
高 |
结束并释放资源。 |
Session。 |
GET_PARAMETER |
C ↔ S |
中 |
查询参数或保活。 |
Session。 |
SET_PARAMETER |
C → S |
低到中 |
设置参数，厂商私有较多。 |
Content-Type、body。 |
ANNOUNCE |
C → S |
低 |
客户端向服务端提交 SDP，多见推送/录制场景。 |
SDP body。 |
RECORD |
C → S |
低 |
录制或推流相关。 |
Session。 |
REDIRECT |
S → C |
低 |
服务端要求客户端切到其他 URL。 |
Location。 |
6. 媒体传输三种模式
6.1 RTP over UDP：默认低延迟模式
| 通道 |
典型协议 / 端口 |
作用 |
优点 |
风险 |
| RTSP 控制 |
TCP 554 |
发送 OPTIONS/DESCRIBE/SETUP/PLAY。 |
可靠、有序。 |
只管控制，不传大媒体。 |
| RTP 视频 |
UDP 偶数端口，例如 8000 |
承载视频 RTP 包。 |
延迟低。 |
NAT/防火墙/丢包。 |
| RTCP 视频 |
UDP 奇数端口，例如 8001 |
承载统计和同步反馈。 |
可做质量反馈。 |
有些设备实现不完整。 |
| RTP 音频 |
UDP 偶数端口，例如 8002 |
承载音频 RTP 包。 |
和视频分离。 |
需要音视频同步。 |
| RTCP 音频 |
UDP 奇数端口，例如 8003 |
音频反馈。 |
同步和统计。 |
可能被防火墙拦截。 |
6.2 RTP over TCP interleaved：跨防火墙友好
TCP interleaved 把 RTP/RTCP 包塞回 RTSP 的 TCP 连接，用 $ 前缀区分二进制媒体包和普通 RTSP 文本响应。
| 项 |
说明 |
| SETUP 写法 |
Transport: RTP/AVP/TCP;unicast;interleaved=0-1。 |
| 通道号 |
0 常表示 RTP，1 常表示 RTCP；音频可能用 2-3。 |
| 包格式 |
$ + channel(1 byte) + length(2 bytes) + RTP/RTCP payload。 |
| 优势 |
只需要一条 TCP 连接，穿 NAT/防火墙更稳。 |
| 劣势 |
TCP 丢包重传会队头阻塞，弱网下延迟可能变大。 |
| FFmpeg 参数 |
-rtsp_transport tcp。 |
6.3 RTP over HTTP / HTTPS tunneling
| 特性 |
说明 |
| 目标 |
穿过更严格的 HTTP 代理或防火墙。 |
| 实现 |
用 HTTP/HTTPS 隧道包装 RTSP/RTP。 |
| 现实情况 |
标准和设备支持差异大，工程上远不如 UDP/TCP interleaved 常见。 |
| 替代方案 |
公网播放通常转 HLS/HTTP-FLV/WebRTC。 |
三种模式选型：
| 场景 |
推荐模式 |
原因 |
| 局域网监控 |
RTP over UDP |
延迟低，网络环境可控。 |
| 跨网段 / 防火墙复杂 |
RTP over TCP interleaved |
端口少，成功率高。 |
| 公网互联网播放 |
转 HLS/HTTP-FLV/WebRTC |
浏览器和 CDN 生态更适合。 |
| 弱网但要求低延迟 |
视情况 UDP 或 WebRTC/SRT |
TCP 重传可能导致延迟积累。 |
7. SDP 详解
SDP 是 DESCRIBE 响应体里的媒体说明书。RTSP 客户端拿到 SDP 后，才知道要对哪些 track 发 SETUP，以及 RTP 包里的 payload type 应该怎么解释。
7.1 一份典型 IPC SDP
v=0
o=- 1234567890 1234567890 IN IP4 192.168.1.100
s=IPCamera Stream
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=range:npt=0-
m=video 0 RTP/AVP 96
a=control:trackID=0
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42801F;sprop-parameter-sets=Z0LAH9oBQBboQAAA,aM48gA==
m=audio 0 RTP/AVP 97
a=control:trackID=1
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;config=1190;SizeLength=13;IndexLength=3;IndexDeltaLength=3
7.2 会话级字段
| 行 |
字段名 |
示例 |
含义 |
客户端怎么用 |
v= |
Version |
v=0 |
SDP 协议版本，通常固定 0。 |
基础解析校验。 |
o= |
Origin |
o=- 1234567890 1234567890 IN IP4 192.168.1.100 |
会话创建者、session id、版本、网络类型、地址。 |
一般用于标识会话，不直接决定播放。 |
s= |
Session Name |
s=IPCamera Stream |
会话名称。 |
展示或日志。 |
c= |
Connection Info |
c=IN IP4 0.0.0.0 |
连接地址。RTSP 场景经常不靠它决定端口。 |
真实端口通常由 SETUP 协商。 |
t= |
Timing |
t=0 0 |
会话有效时间，0 0 常表示永久。 |
直播/监控常见永久。 |
a=control:* |
Session Control |
a=control:* |
会话级控制 URL。 |
PLAY/TEARDOWN 可对聚合 URL 操作。 |
a=range |
Range |
a=range:npt=0- |
可播放时间范围。 |
点播 seek 或 live 范围判断。 |
7.3 媒体级字段：m= 和 a=control
| 行 |
示例 |
含义 |
关键点 |
m=video 0 RTP/AVP 96 |
video track |
媒体类型是视频；端口写 0；RTP profile 是 RTP/AVP；payload type 是 96。 |
RTSP 里端口常写 0，因为端口靠 SETUP 协商。 |
m=audio 0 RTP/AVP 97 |
audio track |
媒体类型是音频；payload type 是 97。 |
动态 payload type 要靠 rtpmap 解释。 |
a=control:trackID=0 |
video 控制 URL |
这路 video track 的相对控制地址。 |
客户端用它拼出 SETUP rtsp://.../trackID=0。 |
a=control:trackID=1 |
audio 控制 URL |
这路 audio track 的相对控制地址。 |
每路媒体通常都要 SETUP。 |
a=control URL 拼接规则：
| SDP 写法 |
示例 |
SETUP URL 怎么理解 |
| 相对路径 |
a=control:trackID=0 |
基于 Content-Base 或 DESCRIBE URL 拼接。 |
| 绝对 RTSP URL |
a=control:rtsp://host/stream/trackID=0 |
直接使用该 URL。 |
| 星号 |
a=control:* |
会话级控制，不代表某一路媒体 track。 |
| 厂商私有 |
a=control:streamid=0 |
按服务端返回原样 SETUP，不要猜。 |
7.4 Payload Type：静态和动态
| Payload Type 范围 |
含义 |
例子 |
说明 |
| 0-95 |
静态或历史保留较多。 |
0=PCMU、8=PCMA、14=MPA。 |
客户端可按标准表解释。 |
| 96-127 |
动态 payload type。 |
96=H264、97=AAC 常见。 |
必须看 SDP 的 a=rtpmap 和 a=fmtp。 |
动态 PT 的映射示例：
| RTP 包里的 PT |
SDP 行 |
解释 |
| 96 |
a=rtpmap:96 H264/90000 |
PT=96 的 RTP payload 是 H.264，RTP 时钟 90kHz。 |
| 97 |
a=rtpmap:97 MPEG4-GENERIC/48000/2 |
PT=97 的 RTP payload 是 AAC，采样率 48kHz，2 声道。 |
7.5 H.264 的 SDP 参数
H.264 通常由 a=rtpmap 和 a=fmtp 两类行描述：
| 字段 |
示例 |
说明 |
a=rtpmap |
a=rtpmap:96 H264/90000 |
H.264 RTP timestamp 使用 90kHz 时钟。 |
packetization-mode |
1 |
0 表示单 NAL 模式；1 支持非交错模式，常见 FU-A 分片。 |
profile-level-id |
42801F |
H.264 profile/constraint/level，播放器可用于兼容性判断。 |
sprop-parameter-sets |
Z0LA...,aM48... |
Base64 编码的 SPS/PPS，通常用逗号分隔。 |
sprop-parameter-sets 的作用：
| 作用 |
说明 |
| 提前初始化解码器 |
客户端不必等 RTP 里出现 SPS/PPS，就能配置 H.264 decoder。 |
| 确定分辨率等参数 |
SPS 里包含 profile、level、宽高、VUI 等信息。 |
| 降低首帧等待 |
摄像头如果不是每个 IDR 都带 SPS/PPS，SDP 里的参数集很关键。 |
| 调试黑屏重点 |
SDP 没有 SPS/PPS、SPS/PPS 错或 base64 解析失败，都可能导致黑屏。 |
H.264 over RTP 常见 payload 形态：
| 形态 |
说明 |
什么时候出现 |
| Single NAL Unit |
一个 RTP 包放一个完整 NAL。 |
小 NAL，例如 SPS/PPS/小 P 帧。 |
| STAP-A |
一个 RTP 包聚合多个小 NAL。 |
把 SPS/PPS 等小包合并发送。 |
| FU-A |
一个大 NAL 被拆成多个 RTP 包。 |
大 I 帧 / 大 P 帧超过 MTU 时。 |
7.6 AAC 的 SDP 参数
AAC over RTP 在 RTSP 监控里常见 MPEG4-GENERIC：
| 字段 |
示例 |
说明 |
a=rtpmap |
a=rtpmap:97 MPEG4-GENERIC/48000/2 |
PT=97 是 MPEG4-GENERIC，采样率 48kHz，2 声道。 |
mode |
AAC-hbr |
AAC high bit-rate 模式。 |
config |
1190 |
AudioSpecificConfig 十六进制表示，描述 AAC profile、采样率、声道。 |
SizeLength |
13 |
AU header 中 size 字段位数。 |
IndexLength |
3 |
AU header 中 index 字段位数。 |
IndexDeltaLength |
3 |
AU header 中 index delta 字段位数。 |
AAC 易错点：
| 坑点 |
正确理解 |
| 以为 RTP payload 一定是 ADTS |
标准 MPEG4-GENERIC 常是 AU Header + AAC raw access unit，不是简单 ADTS 文件帧。 |
忽略 config |
config 是初始化 AAC 解码器的重要信息，类似 MP4 里的 AudioSpecificConfig。 |
| 只看 payload type |
PT=97 只是动态编号，真正 codec 必须看 rtpmap/fmtp。 |
7.7 客户端拿到 SDP 后做什么
| 顺序 |
客户端动作 |
依赖 SDP 内容 |
| 1 |
解析 session 级字段。 |
v/o/s/c/t/a=control。 |
| 2 |
枚举 m= 媒体段。 |
判断有 video、audio、subtitle 几路 track。 |
| 3 |
建立 PT → codec 映射。 |
a=rtpmap、a=fmtp。 |
| 4 |
拼出每路 SETUP URL。 |
a=control + Content-Base。 |
| 5 |
初始化解码器参数。 |
H.264 SPS/PPS、AAC config。 |
| 6 |
为每路媒体 SETUP 端口。 |
video/audio track 各自 setup。 |
| 7 |
PLAY 后解析 RTP。 |
RTP header 的 PT、timestamp、seq。 |
8. RTP 包格式（媒体数据）
RTP 包一般由固定 12 字节 header + 可选扩展 + payload 组成。
| 字段 |
位数 |
示例 / 范围 |
作用 |
| V |
2 |
2 |
RTP 版本，通常为 2。 |
| P |
1 |
0/1 |
Padding 标记。 |
| X |
1 |
0/1 |
Header extension 标记。 |
| CC |
4 |
0-15 |
CSRC 个数。 |
| M |
1 |
H.264 常用于帧结束 |
Marker bit；视频常标记一帧最后一个 RTP 包。 |
| PT |
7 |
96、97 |
Payload Type；动态 PT 必须结合 SDP 解释。 |
| Sequence Number |
16 |
递增 |
检测丢包、乱序、重排。 |
| Timestamp |
32 |
H.264 90kHz 时基 |
表示媒体采样时间，不是系统绝对时间。 |
| SSRC |
32 |
随机源标识 |
同步源 ID，区分不同 RTP source。 |
| CSRC |
0-15 个，每个 32 位 |
混音/混流场景 |
监控拉流中通常没有。 |
RTP header 和 SDP 的关系：
| RTP 字段 |
需要 SDP 帮忙解释吗 |
例子 |
| PT |
需要，尤其是 96-127 动态 PT。 |
SDP 告诉 96=H264、97=AAC。 |
| Timestamp |
需要知道 codec clock rate。 |
H.264 90000，AAC 48000。 |
| Payload |
需要 codec 和 packetization 参数。 |
H.264 FU-A、AAC MPEG4-GENERIC。 |
8.2 H.264 over RTP
| Payload 形态 |
RTP payload 第一个字节特征 |
作用 |
客户端处理 |
| Single NAL |
NAL type 为普通类型，例如 1/5/7/8。 |
一个 RTP 包就是一个完整 NAL。 |
直接恢复 NAL，必要时加 Annex-B start code。 |
| STAP-A |
NAL type 24。 |
一个 RTP 包聚合多个小 NAL。 |
逐个拆出内部 NAL。 |
| FU-A |
NAL type 28。 |
大 NAL 分片。 |
按 Start/End 标记重组完整 NAL。 |
FU-A 关键字段：
| 字段 |
说明 |
| FU Indicator |
包含原始 NAL 的 F/NRI 和 type=28。 |
| FU Header S |
Start bit，表示这是分片开始。 |
| FU Header E |
End bit，表示这是分片结束。 |
| FU Header Type |
原始 NAL type，例如 5 表示 IDR。 |
| Marker bit |
通常一帧最后一个 RTP 包置 1，帮助帧边界判断。 |
8.3 AAC over RTP
| 项 |
说明 |
| 常见 SDP |
MPEG4-GENERIC/48000/2 + mode=AAC-hbr。 |
| payload 结构 |
通常是 AU Headers Length + AU Headers + AAC raw data。 |
| 不是简单 ADTS |
很多 RTSP AAC RTP 不带 ADTS header，不能直接当 .aac 文件拼。 |
| 解码初始化 |
依赖 SDP config 生成 AudioSpecificConfig。 |
| 时间戳步进 |
AAC-LC 每帧常见 1024 samples；48kHz 下 timestamp 每帧常加 1024。 |
8.4 RTP、RTCP、音视频同步
| 机制 |
作用 |
| RTP Sequence |
检测丢包、乱序、重复包。 |
| RTP Timestamp |
单 track 内恢复播放时间。 |
| RTCP Sender Report |
把 RTP timestamp 和 NTP 时间关联，用于跨 track 音视频同步。 |
| RTP-Info |
PLAY 响应里给初始 seq/rtptime，帮助起播时建立映射。 |
| Jitter Buffer |
客户端缓存少量 RTP 包，抵抗乱序和抖动。 |
详见下一篇 RTP 专题时，可以再深入 H.264 FU-A、STAP-A、RTCP SR/RR、jitter buffer。
9. 鉴权
RTSP 鉴权通常在客户端第一次请求时触发：服务端返回 401 Unauthorized 和 WWW-Authenticate，客户端再带 Authorization 重试。
9.1 Basic Auth
Basic challenge：
RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Basic realm="IPCamera"
客户端重试：
OPTIONS rtsp://192.168.1.100/stream RTSP/1.0
CSeq: 2
Authorization: Basic YWRtaW46MTIzNDU=
Basic Auth 解释：
| 项 |
说明 |
| 编码内容 |
base64(username:password)，例如 admin:12345。 |
| 安全性 |
Base64 只是编码，不是加密；抓包后很容易还原。 |
| 适用性 |
局域网老设备可能支持，但不建议公网使用。 |
| 改进方式 |
至少使用 RTSPS/VPN/专网，避免明文暴露。 |
9.2 Digest Auth（摄像头主流）
Digest challenge：
RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Digest realm="IPCamera", nonce="abc123", algorithm=MD5, qop="auth"
客户端重试：
DESCRIBE rtsp://192.168.1.100/stream RTSP/1.0
CSeq: 2
Accept: application/sdp
Authorization: Digest username="admin", realm="IPCamera", nonce="abc123", uri="rtsp://192.168.1.100/stream", response="b8e9d1234...", algorithm=MD5
Digest 关键字段：
| 字段 |
来源 |
作用 |
realm |
服务端 |
认证域，参与 hash。 |
nonce |
服务端 |
一次性随机值，防止简单重放。 |
username |
客户端 |
用户名。 |
uri |
客户端 |
本次请求 URI，参与 hash。 |
response |
客户端计算 |
证明客户端知道密码，但不直接发送密码。 |
qop / cnonce / nc |
可选增强 |
增强防重放能力，设备支持情况不一。 |
Digest 简化计算：
| 步骤 |
计算 |
| HA1 |
MD5(username:realm:password)。 |
| HA2 |
MD5(method:uri)。 |
| response |
无 qop 时常见为 MD5(HA1:nonce:HA2)；有 qop 时还会加入 nc/cnonce/qop。 |
Digest 的安全边界：
| 结论 |
说明 |
| 比 Basic 好 |
密码不会直接以 base64 形式发送。 |
| 不是加密传输 |
RTSP 请求、SDP、RTP 仍可能被嗅探。 |
| MD5 已老旧 |
很多摄像头仍只支持 MD5 Digest。 |
| 公网仍需额外保护 |
推荐 VPN、专网、TLS、零信任网关或协议转换。 |
9.3 RTSPS
| 特性 |
说明 |
| 协议 |
RTSP over TLS。 |
| 作用 |
加密 RTSP 控制连接，避免 Header、鉴权信息被明文嗅探。 |
| 端口 |
设备实现不统一，可能是 322、443、554 上升级或私有端口。 |
| 限制 |
摄像头支持率不如 HTTPS/HLS 普遍，部署证书也更复杂。 |
| 注意 |
如果 RTP 仍走独立 UDP，媒体是否加密还要看具体实现；仅控制面 TLS 不一定等于媒体加密。 |
10. 实战（FFmpeg）
10.1 拉流播放
ffplay rtsp://admin:12345@192.168.1.100/stream
常用参数：
| 参数 |
作用 |
什么时候用 |
-rtsp_transport tcp |
强制 RTP over TCP interleaved。 |
UDP 被防火墙拦截、花屏、丢包时。 |
-stimeout / -timeout |
设置连接或读超时。 |
摄像头不响应、网络不稳定时。 |
-fflags nobuffer |
减少 demux 缓冲。 |
低延迟预览。 |
-flags low_delay |
解码低延迟倾向。 |
低延迟预览。 |
10.2 拉流转封装
| 场景 |
命令 / 写法 |
说明 |
| RTSP → MP4 文件 |
ffmpeg -rtsp_transport tcp -i rtsp://admin:12345@192.168.1.100/stream -c copy output.mp4 |
不转码，直接把 RTP 中的 H.264/AAC 重新封装进 MP4。 |
| RTSP → RTMP 推流 |
ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100/stream -c copy -f flv rtmp://server/app/key |
摄像头拉流后推到直播 CDN。 |
| RTSP → HLS |
ffmpeg -rtsp_transport tcp -i rtsp://192.168.1.100/stream -c copy -f hls -hls_time 2 output.m3u8 |
把摄像头流转成浏览器/移动端更好播放的 HLS。 |
10.3 用 OPTIONS 探活
ffprobe -v debug -rtsp_transport tcp rtsp://192.168.1.100/stream
| 看什么 |
说明 |
| OPTIONS 响应 |
服务端是否在线，支持哪些方法。 |
| DESCRIBE 响应 |
SDP 是否返回，codec 是否符合预期。 |
| SETUP Transport |
实际走 UDP 还是 TCP，端口是否协商成功。 |
| RTP 日志 |
是否持续收到 packet，是否丢包。 |
11. 用 GStreamer
gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.100/stream \
protocols=tcp ! decodebin ! autovideosink
| 组件 |
作用 |
rtspsrc |
实现 RTSP 客户端，会自动 OPTIONS/DESCRIBE/SETUP/PLAY。 |
protocols=tcp |
要求 RTP over TCP interleaved。 |
decodebin |
自动选择 depay、parse、decoder。 |
autovideosink |
自动选择视频显示 sink。 |
12. 服务端
12.1 GStreamer RTSP Server
#include <gst/rtsp-server/rtsp-server.h>
GstRTSPServer *server = gst_rtsp_server_new();
GstRTSPMountPoints *mounts = gst_rtsp_server_get_mount_points(server);
GstRTSPMediaFactory *factory = gst_rtsp_media_factory_new();
gst_rtsp_media_factory_set_launch(factory,
"videotestsrc ! x264enc ! rtph264pay name=pay0 pt=96");
gst_rtsp_mount_points_add_factory(mounts, "/test", factory);
gst_rtsp_server_attach(server, NULL);
// rtsp://localhost:8554/test
12.2 商业 / 开源选项
| 项目 |
语言 / 类型 |
特点 |
| GStreamer RTSP Server |
C |
和 GStreamer pipeline 集成方便。 |
| Live555 |
C++ |
经典 RTSP/RTP 库，很多项目参考。 |
| ZLMediaKit |
C++ |
国内常用，多协议转换能力强。 |
| EasyDarwin |
Go/C++ 生态项目 |
国内 RTSP/流媒体方向历史项目。 |
| Wowza / Flussonic |
商业 |
商业流媒体服务端。 |
| SRS |
C++ |
主要强项在 RTMP/WebRTC/SRT/HLS 等，RTSP 支持需看具体版本能力。 |
13. 常见坑
13.1 拉不到流
| 现象 |
可能原因 |
排查动作 |
| Connection refused |
端口没开、服务没启动、IP 错。 |
telnet host 554、确认摄像头 RTSP 开关。 |
| 404 Not Found |
RTSP path 错。 |
对照厂商文档，区分主码流/子码流 URL。 |
| 401 Unauthorized |
用户名密码错，或 Digest 没处理。 |
看 WWW-Authenticate，确认客户端支持 Digest。 |
| DESCRIBE 无响应 |
防火墙、设备固件兼容问题。 |
用 VLC/FFmpeg 对比，打开 debug 日志。 |
| SETUP 失败 |
UDP 端口被拦，NAT 不通。 |
试 -rtsp_transport tcp。 |
13.2 卡顿 / 花屏
| 现象 |
可能原因 |
处理方式 |
| 花屏 |
UDP 丢包导致 H.264 NAL 缺片。 |
切 TCP interleaved；改善网络；降低码率。 |
| 卡顿 |
带宽不够或 jitter 大。 |
拉子码流；增大 jitter buffer；就近部署网关。 |
| 黑屏但有连接 |
SDP 缺 SPS/PPS、payload type 映射错、解码器不支持。 |
检查 SDP fmtp，抓 RTP 看 IDR/SPS/PPS。 |
| 有视频无音频 |
audio track 没 SETUP，AAC config 解析失败。 |
检查 SDP audio rtpmap/fmtp 和第二次 SETUP。 |
| 延迟越来越大 |
TCP 重传、播放器 buffer 增长、服务端堆积。 |
降低码率、低延迟参数、监控网络丢包。 |
13.3 鉴权失败 401
| 原因 |
说明 |
处理 |
| 账号密码错误 |
摄像头 Web 登录和 RTSP 用户可能不同。 |
确认 RTSP 用户权限。 |
| Digest 算法不兼容 |
设备可能要求 Digest，但客户端只发 Basic。 |
换支持 Digest 的客户端或升级库。 |
| URI 参与 hash 不一致 |
Digest response 对 URI 敏感。 |
确认 Authorization 里的 uri 和请求 URI 一致。 |
| nonce 过期 |
服务端 nonce 过期或重放。 |
重新请求拿新 nonce。 |
13.4 RTCP timeout
| 原因 |
说明 |
处理 |
| 服务端不发 RTCP |
一些 IPC 实现不完整。 |
客户端放宽 RTCP 超时策略。 |
| RTCP 端口被拦 |
UDP 奇数端口不通。 |
切 TCP interleaved。 |
| NAT 映射失效 |
长时间无包导致端口映射失效。 |
保活、TCP、网关代理。 |
14. RTSP vs ONVIF
RTSP 和 ONVIF 经常一起出现，但它们不是一类东西。
| 维度 |
RTSP |
ONVIF |
| 定位 |
流媒体控制协议。 |
设备管理和互联标准。 |
| 主要解决 |
怎么拉一条音视频流。 |
怎么发现设备、管理配置、控制 PTZ、订阅事件、拿流地址。 |
| 承载协议 |
RTSP 文本 + RTP/RTCP。 |
SOAP/HTTP、WS-Discovery、WS-Security 等。 |
| 媒体数据 |
通过 RTP 传 H.264/H.265/AAC 等。 |
自己不直接传媒体，通常返回 RTSP URL。 |
| 典型接口 |
DESCRIBE/SETUP/PLAY。 |
GetProfiles、GetStreamUri、ContinuousMove、GetEvents。 |
| 使用方 |
播放器、NVR、流媒体网关。 |
设备管理平台、NVR、配置工具。 |
ONVIF 常见能力：
| 能力 |
说明 |
和 RTSP 的关系 |
| 设备发现 |
在局域网发现摄像头。 |
找到设备后再拿 RTSP 地址。 |
| 获取媒体配置 |
查询 profile、编码参数、分辨率、码率。 |
用 GetStreamUri 获取 RTSP URL。 |
| PTZ 控制 |
云台平移、倾斜、变焦。 |
控制摄像头姿态，媒体仍可通过 RTSP 看结果。 |
| 事件订阅 |
移动侦测、遮挡、告警。 |
事件走 ONVIF，视频流走 RTSP/RTP。 |
| 用户/网络配置 |
时间、网络、用户、安全配置。 |
属于设备管理，不属于 RTSP。 |
典型监控平台接入流程：
| 步骤 |
协议 |
动作 |
| 1 |
ONVIF WS-Discovery |
发现局域网摄像头。 |
| 2 |
ONVIF Device/Media |
登录并查询 profiles。 |
| 3 |
ONVIF Media |
调 GetStreamUri 获取 RTSP URL。 |
| 4 |
RTSP |
OPTIONS/DESCRIBE/SETUP/PLAY 拉流。 |
| 5 |
RTP/RTCP |
持续接收音视频。 |
| 6 |
ONVIF PTZ/Event |
需要时控制云台或接收告警。 |
结论 ：RTSP 是"看视频"的链路，ONVIF 是"管设备"的链路；监控行业通常是 ONVIF 找设备和拿地址，RTSP/RTP 真正拉媒体。
15. 总结
RTSP 可以按分层记忆：
| 层级 |
关键内容 |
一句话 |
| 控制层 |
RTSP over TCP 554 |
用文本请求/响应控制播放会话。 |
| 描述层 |
SDP |
描述 track、codec、payload type、SPS/PPS、AAC config。 |
| 传输协商层 |
SETUP + Transport |
协商 UDP 端口或 TCP interleaved 通道。 |
| 媒体层 |
RTP |
真正承载 H.264/H.265/AAC 等媒体数据。 |
| 反馈层 |
RTCP |
丢包、抖动、同步、统计。 |
| 设备管理层 |
ONVIF |
发现设备、拿 RTSP URL、PTZ、事件、配置。 |
完整拉流主线：
| 顺序 |
动作 |
记忆点 |
| 1 |
OPTIONS |
先问服务端支持哪些方法。 |
| 2 |
DESCRIBE |
拿 SDP，知道有哪些 track 和 codec。 |
| 3 |
SETUP video |
给视频协商 RTP/RTCP 端口或 interleaved 通道。 |
| 4 |
SETUP audio |
有音频时再给音频协商通道。 |
| 5 |
PLAY |
服务端开始发送 RTP 包。 |
| 6 |
RTP/RTCP |
客户端重组 H.264/AAC，做同步和解码。 |
| 7 |
GET_PARAMETER / OPTIONS |
可选保活。 |
| 8 |
TEARDOWN |
结束会话，释放资源。 |
和其他协议的取舍：
| 目标 |
更常用方案 |
原因 |
| 拉 IPC/NVR 监控流 |
RTSP |
摄像头原生支持，生态最成熟。 |
| 主播推流到 CDN |
RTMP / SRT / WebRTC |
推流生态和公网传输更成熟。 |
| 互联网大规模播放 |
HLS / DASH / HTTP-FLV |
HTTP/CDN 友好，浏览器和 App 支持好。 |
| 互动低延迟 |
WebRTC |
端到端低延迟、拥塞控制和 NAT 穿透更完整。 |
| 设备发现和云台控制 |
ONVIF |
管设备，不直接替代 RTSP 拉流。 |
金句：RTSP 是监控行业的"播放控制面"，SDP 是"媒体说明书"，RTP 是"真正的视频包"，ONVIF 是"设备管理面"。把这四个角色分清，RTSP 拉流链路就不会乱。