RTSP 主码流不工作但子码流工作:差异证明了什么

一个非常常见的 IP 摄像机搜索查询是“RTSP 主码流不工作，但子码流工作”。该症状足够具体，很有用。如果子流工作，则可以访问摄像机，凭据可能正确，RTSP 服务已启用，并且至少可以访问一个视频配置文件。问题不再是“RTSP 损坏”。问题在于流配置文件之间的差异。

主码流和子码流通常在分辨率、比特率、编解码器、GOP 间隔、有效负载大小，有时甚至 URL 路径方面有所不同。子流可能是低分辨率的 H.264，而主流是 H.265、4K、高比特率或限制为较少的并发会话。 NVR 可以暴露来自摄像机本身的不同路径。 ONVIF 可能会返回低质量的实时 URL，而录制 URL 或主配置文件需要单独的路径。

有用的诊断问题是：工作子流证明了什么，没有证明什么？

工作子流证明了什么

如果子流可以通过 RTSP 打开，您通常可以说：

• 摄像机IP地址可达
• RTSP端口已打开
• 身份验证至少适用于一个流
• 客户端可以解析基本的 RTSP 响应
• 至少一个配置文件的“DESCRIBE”、“SETUP”和“PLAY”可以成功
• 至少一个媒体轨道可以进行 RTP 传送

这是有价值的证据。它缩小了搜索范围。此后，除非主流使用不同的主机、端口、传输模式或 NVR 路径，否则不应继续调试基本网络可达性。

工作子流不能证明什么

工作子流并不能证明：

• 主码流URL路径正确
• 主码流已启用
• 支持主流编解码器
• 主码流码率可跨网络
• 主流可供多个客户端使用
• 主码流发送解码就绪的 SPS/PPS 或 VPS/SPS/PPS 证据
• NVR通过同一路径曝光摄像机主码流

这就是为什么“VLC 可以打开子流”对于需要主流的 VMS、分析系统或重新流媒体管道来说是不够的。

在编解码器之前检查 URL 路径

许多相机系列对主码流和子码流使用不同的路径模式。有些使用“profile1”和“profile2”。有些使用“/Streaming/Channels/101”和“/Streaming/Channels/102”。有些使用“main”、“sub”、“video1”、“video2”或特定于供应商的访问名称。某些 NVR 公开的通道与直接摄像机 URL 不同。

如果主流返回“404 Not Found”，请检查：

• 在“DESCRIBE”中发送的确切请求 URI
• URL路径是否与供应商型号匹配
• 频道号
• 流数
• ONVIF 发现的配置文件令牌
• 是否在相机 Web UI 中启用流
• URL是否针对摄像机IP或NVR IP

不要将 404 视为丢包。 RTP 尚未开始。

路径有效后检查编解码器和码率

如果主流返回 SDP 并启动 RTP 但仍然不显示视频，请转到编解码器和媒体证据。

主流失败通常来自：

• 选择 H.265，而消费者期望 H.264
• 缺少 H.264 SPS/PPS 或 H.265 VPS/SPS/PPS 证据
• 关键帧间隔很长
• Wi-Fi 或弱上行链路造成高比特率损失
• 运动中的数据包碎片和丢失
• 下游系统不支持解码器配置文件或级别

在此阶段，报告应包括SDP、有效负载类型、RTP序列连续性、编解码器NAL单元证据以及是否达到第一个解码边界。

并发限制和 NVR 行为

一些预算 DVR、NVR 或摄像机固件版本会限制主流访问。当主流已被本地显示、录制、供应商应用程序或其他客户端消耗时，子流可能保持可用。即使路径正确，这也可能看起来像 URL 问题。

有用的检查：

• 断开其他观看者的连接
• 测试直接摄像机 IP 与 NVR IP
• 比较相机 Web UI 的主流
• 较低的主流比特率或分辨率
• 将主流编解码器从 H.265 切换到 H.264
• 分别测试 TCP 交错和 UDP 上的 RTSP

如果降低比特率可以解决问题，则最初的故障可能是传输容量而不是 URL 语法。

RTSP Inspector 应如何构建此案例

RTSP Inspector 在解释边界时最为强大：

• 子码流控制路径成功
• 主流控制路径失败并显示状态码
• 主码流返回SDP但没有RTP
• 主流RTP到达丢包
• 主流编解码器元数据丢失或不受支持
• 主流是H.265，消费者需要H.264

这就是“主流被打破”和有用的支持报告之间的区别。正确的下一步操作可能是供应商 URL 查找、流配置文件配置、编解码器更改、比特率降低、固件更新或网络路径修复。

如果您的确切搜索是“RTSP 子流有效但主流无效”，请首先比较 RTSP 方法、SDP、编解码器、传输和并发性。工作子流并不是诊断的结束。这是对照样品。