RTSP 诊断中的 SDP、H.264 和 H.265:决定视频是否可以启动的元数据

许多 RTSP 故障被描述为“摄像机流无法播放”。该短语隐藏了最重要的诊断边界：相机在 SDP 中声明了什么，媒体负载是否与该声明匹配？

SDP 通常是 RTSP 会话中第一个可用的结构化证据。它声明媒体轨道、有效负载类型、编解码器名称、时钟速率、控制 URL 和编解码器特定的参数。如果 SDP 错误、不完整或不受消费者支持，则流可能会在第一帧解码之前失败。

SDP应该证明什么

在“DESCRIBE”之后，客户端应该知道流是否包含视频、哪种有效负载类型映射到哪个编解码器以及应如何设置媒体轨道。对于相机诊断，请检查：

• m=video 媒体部分
• a=control 跟踪 URL
• a=rtpmap 负载类型和编解码器名称
• a=fmtp 编解码器参数
• H.264 sprop-parameter-sets 存在时
• H.265 VPS/SPS/PPS 信令（如果可用）
• 广告时钟频率是否符合预期

如果 SDP 通告 H.264，但摄像机发送其他内容，则接收方并非不合理。如果 SDP 忽略了必要的参数证据，并且流从不带内发送它，则解码器可能没有足够的信息来开始。

H.264 参数集不是可选证据

H.264 解码器需要序列和图像参数信息。在 RTSP 摄像机部署中，此证据可能出现在 SDP、带内 RTP 有效负载或两者中。当相机假设接收器已经知道它不知道的东西时，就会出现问题。

一份干净的诊断记录可以回答：

• SPS 可见吗？
• PPS 可见吗？
• 有效负载是否包含 IDR 帧？
• 直播是在共和党中期开始的吗？
• 配置文件级别 ID 看起来合理吗？
• 打包模式是否与观察到的有效负载结构匹配？

当一名球员工作而另一名球员不工作时，这一点尤其重要。宽容的观看者可能会在有问题的元数据中幸存下来。记录、分析或合规管道可能会拒绝它。

H.265 增加了更多兼容性边界

H.265 在现代相机上很常见，尤其是在带宽很重要的情况下，但在旧工具和嵌入式消费者中，它的支持不如 H.264 普遍。 H.265除了SPS和PPS之外还带来了VPS证据。仅表示“RTSP 有效”的部署仍可能会失败，因为实际的编解码器配置文件或参数传递超出了消费者支持的范围。

对于现场团队来说，有用的文章、票证或报告不应只说“切换到 H.264”。应该解释一下原因：

• 当前消费者缺乏H.265支持
• H.265 参数集丢失或延迟
• 有效负载类型与预期的编解码器映射不匹配
• 流有效但在产品边界之外
• 应为此工作流程更改相机配置文件

这种清晰度可以防止重复的试错更改。

SDP必须与RTP进行比较

SDP 是一种主张。 RTP 就是接下来的证据。两者必须进行比较。

示例：

• SDP 声称有效负载类型 96 是 H.264，但 RTP 到达时具有不同的有效负载类型。
• SDP 包含视频轨道，但“PLAY”后面没有 RTP。
• SDP说H.265，但下游产品只支持H.264。
• SDP 省略参数集，RTP 从不在切片之前发送它们。
• RTP 到达，但 NAL 单元结构与通告的编解码器不一致。

这些情况需要不同的后续行动。如果不比较 SDP 和 RTP，它们看起来都像是同样模糊的“无视频”故障。

为什么 RTSP Inspector 会显示此证据

RTSP Inspector 专为需要可重复证据的流工程师、摄像机供应商和 CCTV 集成商而设计。它故意不是一个通用的媒体播放器。它的工作是检查 RTSP 控制路径、SDP 元数据、RTP/RTCP 流和 H.264/H.265 就绪情况。

这使得输出在支持对话中很有用：

• 相机供应商：修复 SDP 或打包
• 网络团队：修复RTP传输路径
• VMS团队：调整支持的编解码器配置文件
• 现场积分器：更改流配置文件或传输模式
• 客户：了解为什么回放不能证明协议健康

在 RTSP 诊断中，SDP 不是样板文本。这是该流提供的第一份合同。如果该合同被打破，管道的其余部分就会猜测。