RTP 丢包修复——解决 RTSP 摄像头画面冻结、花屏和解码器报错

IP 摄像头画面突然卡住、一帧一帧地跳、或者出现绿色花屏——这些症状通常晚于真正的原因出现。原因往往在 RTP 序列的更早位置：一个丢失的 RTP 包可能删掉了后续帧依赖的视频数据。等你看到解码器报错的时候，网络上的证据可能已经消失了。

这就是为什么在更改随机摄像机设置之前，RTP 故障排除应从序列号、时间戳、有效负载类型、标记行为和编解码器结构开始。

RTP 序列间隙告诉您什么

每个RTP数据包都携带一个序列号。对于稳定的流，序列应该按可预测的方式前进。间隙意味着一个或多个数据包未到达。向后跳转可能表示重新排序、重复传递、重新启动行为或捕获边界问题。

实际问题是：

• 丢失了多少个数据包？
• 损失发生过一次还是多次？
• 它发生在关键帧附近吗？
• RTCP 发送方报告是否继续？
• RTSP 控制会话是否保持活动状态？
• 解码器故障是否发生在间隙之后？

该证据可以将网络丢失与相机有效负载错误区分开来。如果序列间隙与视觉损坏一致，那么情况就更有说服力。如果序列连续性完美但有效负载格式错误，则诊断将转向编码器或分组化行为。

为什么 H.264 和 H.265 对丢失敏感

压缩视频不是独立图像的列表。帧间帧取决于参考帧。小数据包丢失可能会比直接数据包造成更大的损坏。 H.264和H.265流还可能依赖SPS和PPS等参数集，H.265增加了VPS。如果这些丢失、延迟或损坏，下游软件可能会拒绝流，即使宽容的查看器似乎已恢复。

常见症状包括：

• 宏块或块状伪影
• 冻结后突然追上
• “缺少参考”样式解码器错误
• 流已启动，但没有帧可供解码
• 大量动作场景后反复损坏

这些症状本身还不够。 RTP 和编解码器证据使它们具有可操作性。

不要将抖动与损耗混淆

抖动意味着数据包到达的时间不均匀。丢失意味着数据包没有到达。两者都会导致用户可见的卡顿，但它们需要不同的修复方法。

对于抖动，请检查时间戳进展和到达时间。对于丢失，请检查序列间隙。对于相机固件错误，请检查有效负载一致性和 NAL 结构。只说“流断断续续”的现场报告并没有告诉网络工程师、固件工程师或 VMS 供应商要更改什么。

更好的报告说：

• RTP序列间隙从N到N+M
• 在同一点观察到时间戳跳跃
• RTSP 会话保持建立状态
• 有效负载类型保持稳定
• H.264 切片不完整
• 下一个 IDR 帧恢复解码器就绪状态

那是一个更强大的支持神器。

UDP 和 TCP 讲述不同的故事

RTSP 通常通过 UDP 或交错 TCP 传输 RTP。 UDP直接暴露丢包。 TCP 可以使阻塞的 UDP 路径消失，但它可能会引入延迟，并且不能证明预期的部署路径是健康的。

对于诊断，比较两种模式：

• UDP 因序列间隙而失败：检查网络丢失、交换机、Wi-Fi、防火墙、NAT 或摄像头发送行为。
• UDP 未接收到 RTP：检查协商端口和防火墙策略。
• TCP 有效，但 UDP 失败：怀疑网络路径而不是编解码器。
• 两种模式都显示格式错误的负载：可疑的相机编码器、流配置文件或固件。

交通工具的选择是证据，而不仅仅是玩家的复选框。

RTSP Inspector 如何解决问题

RTSP Inspector 重点关注协议证据而不是播放。它捕获 RTSP、RTP、RTCP 和编解码器观察结果，以便可以重播和解释支持案例。当同一流在 VLC、FFmpeg、NVR、云摄取服务和分析管道中表现不同时，这一点很重要。

我们的目标并不是声称每个流都可以在本地修复。目标是确定故障的所有者：

• 网络路径
• 相机配置
• 固件打包
• 下游解码器支持
• 不支持的编解码器边界
• 预期的 UDP/TCP 部署不匹配

RTP 丢失不仅仅是视频症状。这是一个可测量的协议事件。一旦测量出来，故障排除对话就会变得更短。