RTP包时间戳混乱但序列号正常的原因及解决方法咨询

问题复现 #

观察到的RTP包序列：

E.g.#1 : seqnum: 17233, ts: 225300783 -> seqnum: 17234, ts: 225297783 -> seqnum: 17235, ts: 225303783 -> seqnum: 17236, ts: 225318783 -> seqnum: 17249, ts: 225312783

序列号保持单调递增，但时间戳出现局部下降，直接干扰音视频同步逻辑。

核心原因分析 #

• 媒体帧发送顺序与生成顺序不一致：发送端可能存在帧调度逻辑（如优先发送关键帧、缓存旧帧延迟发送），导致后生成的帧先被发送，序列号按发送顺序递增，但时间戳保留帧的原始生成时间，从而出现时间戳逆序。比如示例中seqnum 17234对应的帧，实际生成时间早于seqnum 17233的帧，但被延迟到后面发送。
• 发送端时间戳生成逻辑错误：编码器或RTP打包模块未严格按照媒体帧的采样/采集时间计算时间戳，可能复用了未重置的变量、错误复用前帧时间戳，或是时间戳增量计算失误，导致时间戳不随帧的生成顺序递增。
• 丢包后的补帧/重传异常：当出现丢包时，发送端可能从缓存中取出旧帧补充发送，这些旧帧的时间戳早于当前正常发送的帧，但序列号仍按发送顺序递增，引发时间戳逆序。

解决方法 #

1. 按时间戳重新排序RTP包：
   维护一个接收缓存队列，将收到的RTP包先按时间戳排序，再送入解码器处理。需要根据网络状况设置合理的缓存窗口大小（如几十到几百毫秒），平衡延迟与排序效果，避免因过度缓存导致播放延迟过高。

2. 校验并修复发送端时间戳生成逻辑：

   • 音频：确保每帧时间戳增量严格等于采样率 × 每帧采样数 / 总采样率（比如48kHz采样率，每帧10ms则增量为480）。
   • 视频：时间戳应基于帧的实际采集时间或编码器输出的PTS/DTS生成，避免随意赋值或复用旧值。

3. 过滤无效的旧帧：
   维护当前播放的时间戳基准，对于时间戳远低于当前基准的RTP包（已过播放窗口），直接丢弃，无需送入解码器，避免干扰同步逻辑。

4. 利用RTCP校准时间基准：
   通过RTCP发送者报告（SR）中的NTP时间与对应RTP时间戳的映射关系，校准本地RTP时间戳的基准，确保时间戳的全局递增性。若发送端时间戳本身存在偏移，可通过SR计算出偏移量进行修正。

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