4、RTSP协议基础：RTSP/RTP/RTCP协议原理、SDP描述、常用传输方式（UDP/TCP）
在RK工业网关的视频链路中，RTSP（Real Time Streaming Protocol，实时流协议）是连接IP摄像机与网关推理引擎的“第一公里”。无论是海康、大华等主流安防设备，还是ONVIF协议兼容的工业相机，绝大多数都通过RTSP对外提供视频流。理解RTSP及其配套的RTP/RTCP协议、SDP描述和传输方式，是后续硬解码、RGA预处理和NPU推理的基础。本章将从协议栈结构、会话建立流程、SDP关键字段和传输选型四个维度展开，并结合RK平台的实际调试经验，帮助你在网关侧快速定位拉流失败、花屏和延迟问题。
上图展示了RTSP协议栈的整体协作关系：左侧是RTSP控制平面，负责会话的建立、播放和拆除；右侧是RTP/RTCP数据平面，承载实际的视频帧和网络质量反馈；底部SDP则作为“媒体参数清单”，在DESCRIBE阶段由服务器返回给客户端。理解这三者的分工，是掌握RTSP协议的关键。
4.1 RTSP协议核心原理：控制与媒体分离
RTSP是一个应用层协议，其设计哲学是“控制与媒体分离”。它本身不传输视频数据，而是像“遥控器”一样管理媒体会话。RTSP使用文本格式的命令（类似HTTP），默认端口为554，通常运行在TCP之上以保证控制命令的可靠性。一个完整的RTSP会话流程包括以下步骤：
- OPTIONS请求：客户端向服务器询问支持的RTSP方法（如DESCRIBE、SETUP、PLAY等），用于确认服务器能力。
- DESCRIBE请求：客户端请求媒体描述信息，服务器返回SDP文本，包含视频编码格式、分辨率、帧率、传输地址等关键参数。
- SETUP请求：客户端根据SDP中的媒体信息，指定传输方式（UDP/TCP）和客户端接收端口，服务器确认并分配服务端端口。
- PLAY请求：客户端发送播放命令，服务器开始通过RTP协议推送视频流。
- TEARDOWN请求：会话结束，释放资源。
在RK工业网关中，通常使用GStreamer或FFmpeg库来封装RTSP客户端逻辑。例如，使用FFmpeg的avformat_open_input()函数时，内部会自动完成上述RTSP握手流程。但理解底层交互过程，有助于在拉流失败时快速判断是网络问题、协议版本不匹配还是SDP解析异常。
rtsp://[username:password@]ip:port/path。在RK平台调试时，建议先在PC上用VLC或FFplay验证URL的正确性，再移植到嵌入式环境，避免因URL拼写错误浪费调试时间。
4.2 RTP/RTCP协议原理：媒体传输与质量反馈
RTP（Real-time Transport Protocol）负责承载实际的音视频数据。每个RTP包包含一个12字节的固定头部，其中最重要的字段包括：
- 序列号（Sequence Number）：16位，用于检测丢包和恢复包顺序。每发送一个RTP包，序列号加1。
- 时间戳（Timestamp）：32位，反映媒体采样时刻，用于播放同步和抖动消除。对于H.264视频，时间戳通常基于90kHz时钟。
- SSRC（同步源标识）：32位，唯一标识一个媒体流，用于区分同一会话中的多个流（如视频流和音频流）。
- Payload Type（PT）：7位，标识负载格式。动态负载类型96-127通常用于H.264/H.265，具体映射在SDP中声明。
RTCP（RTP Control Protocol）是RTP的伴生协议，周期性地在会话参与者之间交换控制包。其主要功能包括：
- SR（Sender Report）：发送者报告，包含发送包数、字节数以及NTP时间戳和RTP时间戳的对应关系，用于音视频同步。
- RR（Receiver Report）：接收者报告，包含丢包率、累计丢包数、抖动和往返时延（RTT）等统计信息。
- SDES（源描述）：携带CNAME（规范名称）等元数据，用于标识参与者。
在RK网关的硬解码场景中，RTP时间戳的准确性直接影响视频帧的播放节奏。如果时间戳异常（如跳变或重复），可能导致解码器输出帧率不稳或花屏。因此，在调试时可以通过抓包工具（如Wireshark）检查RTP时间戳的增量是否均匀。
| 协议 | 传输层 | 主要功能 | 典型端口 | 可靠性 |
|---|---|---|---|---|
| RTSP | TCP | 会话控制（建立、播放、暂停、拆除） | 554 | 可靠 |
| RTP | UDP/TCP | 媒体数据传输（视频帧、音频帧） | 动态（SETUP协商） | 不可靠（UDP） |
| RTCP | UDP/TCP | 质量反馈（丢包率、抖动、RTT） | RTP端口+1 | 不可靠 |
| SDP | 文本（嵌入RTSP响应） | 媒体参数描述（编码、分辨率、地址） | — | — |
4.3 SDP描述：媒体参数的“合同书”
SDP（Session Description Protocol）是一种文本格式的会话描述协议，它本身不传输数据，而是作为RTSP DESCRIBE响应的主体内容。SDP由多行字段组成，每行以单个小写字母开头，后跟等号和具体值。在RK工业网关的拉流场景中，最需要关注的SDP字段包括：
- m= 媒体描述行：格式为
m=video 0 RTP/AVP 96，表示媒体类型为视频，端口为0（实际端口由SETUP协商），传输协议为RTP/AVP，负载类型为96。 - a=rtpmap：格式为
a=rtpmap:96 H264/90000，说明负载类型96对应H.264编码，时钟频率为90kHz。 - a=fmtp：格式为
a=fmtp:96 profile-level-id=42C01F; packetization-mode=1，包含H.264的profile和level信息，以及打包模式。RK平台的硬解码器（如RKMPP）需要根据profile-level-id来初始化解码参数。 - a=control：格式为
a=control:trackID=1，指定该媒体流的控制URL，用于SETUP请求。
在RK平台开发中，一个常见的坑是：某些摄像头在SDP中声明的编码参数与实际码流不一致（例如声明H.264 High Profile但实际发送Baseline）。这会导致硬解码器初始化失败或输出花屏。因此，建议在拉流后先解析SDP，再根据实际码流的前几个I帧进行解码器参数校验。
rtspsrc插件时，可以通过设置latency属性（默认2000ms）来调整缓冲大小。对于工业现场的低延迟需求，可尝试降低到200-500ms，但需注意网络抖动可能导致的卡顿。
4.4 常用传输方式：UDP与TCP的选型与权衡
RTSP支持多种传输方式，最常用的是RTP over UDP和RTP over TCP。两种方式在RK工业网关场景中各有优劣，需要根据实际网络环境选择。
4.4.1 RTP over UDP
这是最常用的传输方式，RTP数据包直接封装在UDP数据报中。其优点是延迟低、带宽利用率高，适合局域网内稳定网络环境。但UDP不保证数据可靠性，丢包会导致画面花屏或马赛克。在RTSP SETUP请求中，客户端需要指定两个UDP端口：一个用于RTP接收，另一个（端口+1）用于RTCP接收。
4.4.2 RTP over TCP
当网络环境较差（如跨公网、Wi-Fi信号不稳定）时，可以选择RTP over TCP。RTP数据被封装在TCP流中，通过RTSP的交互通道传输。这种方式利用TCP的重传机制保证数据完整性，但会增加延迟和带宽开销。在RTSP SETUP请求中，需要指定interleaved参数，例如Transport: RTP/AVP/TCP;unicast;interleaved=0-1，其中0和1分别表示RTP和RTCP在TCP连接中的通道号。
| 对比维度 | RTP over UDP | RTP over TCP |
|---|---|---|
| 延迟 | 低（毫秒级） | 较高（受TCP拥塞控制影响） |
| 可靠性 | 无重传，丢包即丢失 | 可靠传输，TCP重传保证 |
| 带宽开销 | 较低（UDP头8字节） | 较高（TCP头20字节+ACK开销） |
| 适用场景 | 局域网、有线连接、低延迟要求 | 跨公网、Wi-Fi、弱网环境 |
| NAT穿透 | 困难（需要端口映射） | 容易（只需TCP连接） |
| RK平台推荐 | 优先选择（配合RTCP反馈） | 备选方案（网络不稳定时） |
在RK工业网关的实际部署中，建议采用“自适应策略”：默认使用UDP传输，同时开启RTCP监控。当检测到丢包率超过5%或RTT抖动超过50ms时，自动切换为TCP传输。这种策略可以在保证低延迟的同时，兼顾弱网环境下的可用性。
-rtsp_transport tcp），需注意TCP的粘包问题。FFmpeg内部已处理RTP over TCP的分帧逻辑，但若使用自研的RTSP客户端，必须正确解析RTSP交互通道的4字节长度前缀（$ + 通道号 + 2字节长度），否则会导致数据错位。
4.5 实战案例：RK3588网关拉流花屏问题排查
在某工业质检项目中，使用RK3588网关通过RTSP拉取海康威视DS-2CD3T56摄像头的视频流，进行硬解码和NPU推理。现场现象是：视频画面每隔几秒出现一次花屏，持续约200ms后恢复，且花屏期间NPU推理结果异常。
初步排查过程：
- 使用VLC在PC上拉流，画面正常，排除摄像头故障。
- 在RK3588上使用
ffprobe检查码流信息，发现SDP中声明的分辨率为2688×1520，但实际码流的分辨率在I帧切换时变为1920×1080。进一步分析发现，摄像头开启了“智能编码”功能，导致关键帧（I帧）的分辨率动态变化。 - 检查RTP时间戳，发现花屏时刻的时间戳增量异常，从正常的3003（90kHz/30fps）跳变为9009，说明存在帧丢失。
- 通过Wireshark抓包，发现花屏期间存在UDP丢包，丢包率约3%。由于使用的是UDP传输，丢包导致H.264码流中的参考帧数据缺失，引发花屏。
解决方案：
- 在摄像头端关闭“智能编码”功能，固定分辨率为2688×1520，消除分辨率动态切换问题。
- 在RK3588的GStreamer管道中增加
rtpjitterbuffer插件，设置latency=500，吸收网络抖动。 - 将传输方式从UDP切换为TCP（
rtspsrc protocols=tcp），利用TCP重传机制消除丢包。
结果对比：切换后花屏现象完全消失，NPU推理准确率从92%提升至98.5%。但延迟从原来的120ms增加到180ms，仍在可接受范围内。
复盘经验：在工业场景中，摄像头端的编码策略（如动态分辨率、智能编码）对后端解码的影响往往被忽视。建议在项目初期就与摄像头厂商确认编码参数，并在网关侧做好SDP解析和码流参数校验，避免因参数不匹配导致的隐性故障。