RTSP 连接但不显示视频:在指责播放器之前应检查哪些内容

最常见的摄像头支持票之一听起来很简单：RTSP URL 连接，身份验证成功，但查看器不显示视频。自然的本能是尝试另一个玩家。这可能很有用，但它并不能回答工程问题：流是否在 RTSP 控制、SDP 协商、RTP 交付或编解码器准备就绪时失败？

对于闭路电视集成商、VMS 工程师和摄像机供应商来说，这种区别很重要。播放器可以隐藏数据包丢失、重用旧的解码器状态或静默重试传输模式。诊断报告应解释流的哪一部分被证明是健康的，哪一部分是不健康的。

将控制成功与媒体成功分开

RTSP 是一种控制协议。成功的“描述”、“设置”和“播放”序列证明摄像机接受了会话。它并不能证明 RTP 数据包已到达。它也不能证明有效负载实际上是 SDP 通告的形式的 H.264 或 H.265。

有用的第一遍记录：

• OPTIONS、DESCRIBE、SETUP 和 PLAY 的 RTSP 状态代码
• SDP主体是否包含视频媒体部分
• 为视频轨道协商的有效负载类型
• RTP数据包是否在“PLAY”之后到达
• RTP时间戳和序列号是否向前移动
• 第一视频负载是否包含编解码器参数证据

如果控制成功但没有 RTP 到达，则问题通常是传输、防火墙、NAT、摄像头模式或服务器端流可用性。如果 RTP 到达但没有可解码的视频，则问题将转向有效负载、打包或编解码器元数据。

为什么 SDP 是第一个证据边界

SDP 告诉客户端相机声称将发送的内容。对于 H.264，工程师会查找“rtpmap”和“fmtp”值，例如打包模式、配置文件级别 ID 和“sprop-parameter-sets”。对于H.265，SDP可能会以不同方式承载VPS、SPS和PPS信息，并且许多消费者有更严格的支持限制。

当 SDP 表示 H.264 但媒体字节不包含预期的 NAL 单元结构时，该故障不是一般的“播放器问题”。这是广告元数据与实际负载之间的不匹配。当 SDP 省略参数集并且 RTP 流从不在带内发送它们时，解码器可能会永远等待。

这就是为什么 RTSP 检查工作流程应将 SDP 保留在媒体证据旁边，而不是隐藏在播放器日志中。

RTP 到达还不够

即使 RTP 数据包到达，视频仍然可能失败。 H.264 和 H.265 帧通常依赖于较早的数据包。丢失的数据包可能会使下一个切片无法解码。无序交付可能看起来像是腐败。在 GOP 中间开始的有效负载可能无法解码，直到下一个关键帧和参数集出现。

要收集的最低证据是：

• RTP序列连续性
• 时间戳进展
• 标记位行为
• 负载类型一致性
• H.264 或 H.265 NAL 单元类别
• SPS、PPS 和 H.265 VPS 可见性
• 第一个关键帧准备就绪

这解释了为什么“VLC 播放它”和“我们的分析管道拒绝它”都可能是真的。一些观众积极恢复。工程系统通常需要标准干净的证据。

TCP 与 UDP 是一种诊断选择

将 RTSP 传输从 UDP 切换到 TCP 是常见的故障排除步骤，但不应将其视为万能药。 TCP交错可以避免UDP端口被阻塞，减少网络策略造成的丢包。它还可以隐藏部署的预期 UDP 路径是否有效。

一份好的现场报告会记录这两种尝试：

• RTSP over TCP 交错：媒体是否到达？
• RTP over UDP 单播：数据包是否到达协商端口？
• RTCP：发送方反馈是否显示时间和数据包计数？

如果 TCP 有效而 UDP 失败，则原因可能是不支持编解码器。它可能是网络路径、防火墙、NAT 或端口分配。如果两种传输都提供 RTP 但解码仍然失败，请检查编解码器结构。

RTSP Inspector 适合什么地方

RTSP Inspector 就是为此精确边界而构建的。它并不想成为视频播放器或 NVR。它捕获有关 RTSP 会话、SDP、RTP/RTCP 流和 H.264/H.265 准备情况的证据，以便工程师可以解释为什么“连接”没有变成“可用视频”。

有用的输出不是黑色播放器窗口的屏幕截图。这是一个可重复的答案：

• RTSP控制成功
• SDP 通告此编解码器和有效负载类型
• RTP 已到达或未到达
• 数据包序列连续或中断
• 编解码器参数证据存在或缺失
• 下一个操作属于网络、相机配置、固件或流消费者

这就是观看直播和诊断直播之间的区别。