Gstreamer与Android WebRTC互通时丢包计算指标异常问题咨询

问题属性判定 #

该问题属于不同RTP协议栈实现互通时的常见统计逻辑差异类问题，不影响实际媒体流传输能力，仅因两端丢包统计规则不一致导致指标异常。

异常值具体解读 #

Gstreamer侧负丢包值 #

Gstreamer RTPSource组件的丢包统计采用后验修正逻辑：

• 先按RTP序号断层差值初步累加丢包数
• 此前判定为丢失的包后续乱序到达、或收到重复包时，会直接扣减对应丢包计数
• 当乱序/重复包总数量超过历史累计丢包数时，就会出现负数值

你给出的持续递减负数序列如下：

[ -154, -697, -1234, -1764, -2288, -2823, -3350, -3869, -4409, -4988, -5533,
  -6065, -6592, -7123, -7672, -8237, -8831, -9383, -9949, -10527, -11036,
  -11581, -12136, -12721 ]

该类负数值的绝对值对应当前收到的重复包+乱序到达包超出历史累计丢包数的差值，实际使用时直接取0作为丢包参考值即可，持续递减的负数说明当前流中存在持续的重复包发送或者大量乱序重传场景。

Android WebRTC侧16777215异常值 #

16777215是24位无符号整数的最大值（2^24 -1），该值出现的原因是：

• RTCP SR/RR报文中的丢包字段标准定义为24位有符号整数
• Gstreamer上报负丢包值时，Android WebRTC侧会按照无符号24位整数解析该字段，最终得到16777215的结果

该异常值本质是Gstreamer非标准的负丢包上报逻辑，和WebRTC标准字段解析逻辑不兼容导致。

通用修复方案 #

• 处理Gstreamer侧统计值时增加截断逻辑：若丢包值小于0，直接取0作为实际丢包数
• 处理Android WebRTC侧统计值时增加异常过滤逻辑：若packetsLost等于16777215，直接判定为统计异常，取上一次有效值或0作为当前丢包数
• 两端协商开启统一的RTCP扩展统计字段，可从根本上统一统计口径，解决指标偏差问题

内容的提问来源于stack exchange，提问作者Kris