RTCP Sender Report、抖动与丢包——不看画面也能读懂流健康状况

当工程师搜索“RTSP 抖动”、“RTP 数据包丢失”或“RTCP 发送方报告”时，他们通常试图回答一个实际问题：流是否不健康，或者播放器是否只是在挣扎？视频播放是一个晚期症状。 RTP 和 RTCP 证据出现得更早，并且在支持案件中更容易辩护。

RTCP 是 RTP 的控制伴侣。它可以携带发送者报告、接收者报告、数据包计数、定时信息和质量反馈。并非每个摄像机都会公开丰富的 RTCP 行为，也不是每个部署都会正确转发它，但是当 RTCP 存在时，它会提供原始播放所无法提供的重要上下文。

为什么 RTCP 在相机诊断中很重要

RTP 承载媒体数据包。 RTCP 有助于描述媒体会话健康状况。对于 RTSP 摄像头流，RTCP 证据可以帮助回答：

• 在“PLAY”之后发送者还活着吗？
• 发送方报告了多少个 RTP 数据包？
• RTP 时间戳是否与挂钟计时一致？
• 数据包传输是稳定的还是突发的？
• 有明显的抖动吗？
• 视频解码失败时 RTP 是否继续？
• 媒体路径是否包含 RTCP？

如果 RTSP 控制成功并且 RTP 到达，但视频冻结，RTCP 可以帮助将网络计时与编解码器准备情况分开。

发件人报告是时间证据

RTCP 发送方报告可以将 RTP 时间戳与绝对 NTP 样式时间值相关联。这种关系有助于接收器同步流并推断时钟行为。在诊断中，精确的数学计算可能不如报告的存在性和一致性重要。

有用的观察：

• 媒体启动后出现发件人报告
• 数据包和八位位组数量增加
• RTP时间戳映射一致
• 报告间隔是合理的
• RTP 停止时报告也会停止
• 即使解码器出现故障，报告也会继续

如果 RTCP 与 RTP 一起停止，则发送方或媒体路径可能会中断。如果 RTCP 继续但视频解码失败，请检查有效负载和编解码器证据。

抖动与丢包不同

抖动意味着数据包以可变的时间到达。丢包意味着数据包丢失。两者都会导致明显的卡顿，但它们会导致不同的修复。

RTP 序列号显示丢失的数据包。 RTP 时间戳和到达时间显示时间变化。 RTCP 报告可以添加会话级反馈。正确的报告不应该只说“网络不好”。它应该说明问题是否是丢失、抖动、突发传送、阻塞 RTCP 或编解码器解码边界。

对于相机来说，抖动可能来自：

• Wi-Fi 上行链路变化
• 相机编码器过载
• NVR转发延迟
• 拥塞的交换路径
• VPN 或 WAN 路径
• 客户端缓冲行为

数据包丢失可能来自：

• UDP 丢弃
• 防火墙/NAT 行为
• 网络过载
• 相机发送缓冲压力
• 捕获点限制

修复方法不同。

RTCP缺失也是证据

即使 RTP 流动，某些部署也会阻止 RTCP。有些相机不发送有用的 RTCP。有些客户从来没有明确要求或收到。缺少 RTCP 并不自动意味着流已损坏，但应将其记录下来。

如果通过 UDP 协商 RTP，请检查媒体并控制伴随流量。如果使用 RTSP over TCP 交错，请检查交错通道元数据。报告“RTP 可见，RTCP 不存在”比空白字段更有用。

RTSP Inspector 适合什么地方

RTSP Inspector 专为协议证据而构建，而不是被动查看。 RTCP 与 RTSP 方法、SDP、RTP 序列连续性、有效负载类型、编解码器元数据和报告导出属于同一故事。

对于 RTCP 密集型搜索，RTSP Inspector 应该帮助回答：

• RTP 在“PLAY”之后到达吗？
• RTCP 发送方报告是否出现？
• 数据包数量增加了吗？
• 抖动或序列间隙是否与可见故障一致？
• 尽管有媒体传输，编解码器准备是否失败？
• 交通方式改变了健康状况吗？

这为相机供应商、网络工程师或 VMS 开发人员提供了一个具体的起点。 “流口吃”是一种症状。 “播放后 RTP 序列间隙和抖动增加，而 RTSP 控制保持活动”就是证据。