timestamp - 如何修复不正确的时间戳计算？ [OpenRtspClient]

Question

我的 RTSP Source 的 RTCP SR 对于一些 H.264 的计算时间戳不可靠> 流频繁导致大的负跳跃。

这是调试日志中的示例。查看它如何从 101006.6130 跳到 -4193861.6830 并继续这种方式。

101619 : 5cd3c38 Sample 63682 bytes time 100605.6130 to 100605.6131 latency 1264447034.4738
101715 : 5cd3c38 Sample 74194 bytes time 100706.6130 to 100706.6131 latency 1264447039.4738
101815 : 5cd3c38 Sample 72484 bytes time 100804.6130 to 100804.6131 latency 1264447038.4738
101923 : 5cd3c38 Sample 95679 bytes time 100906.6130 to 100906.6131 latency 1264447031.4738
102023 : 5cd3c38 Sample 93004 bytes time 101006.6130 to 101006.6131 latency 1264447031.4738
102134 : 5cd3c38 Sample 91388 bytes time -4193861.6830 to -4193861.6829 latency 1260152052.1778
102222 : 5cd3c38 Sample 90912 bytes time -4193738.1730 to -4193738.1729 latency 1260152088.6878
102328 : 5cd3c38 Sample 105902 bytes time -4193636.1730 to -4193636.1729 latency 1260152083.6878
102430 : 5cd3c38 Sample 106334 bytes time -4193537.1730 to -4193537.1729 latency 1260152081.6878
102520 : 5cd3c38 Sample 107120 bytes time -4193437.1730 to -4193437.1729 latency 1260152090.6878

所以，我的问题是:

How can I solve this problem using Live555 media lib? Should I ignore RTCP info or what is the recommended solution and how can I apply in Live555?

Answer 1

您是否只在客户端使用 live555？使用未修改源代码？您问题中的日志记录信息来自哪里？

通常，总是在时间戳中有一个非常接近流开头的跳跃:当客户端收到第一个 RTCP SR 时会发生这种情况，此时客户端重置 时间戳。这是必要的，以便客户端可以将多个流同步为音频和视频中的 RTP 时间戳，每个流都以随机偏移量开头。 RTCP SR 包含从 RTP 到 NTP 时间戳的映射，它允许客户端同步时间戳。由于 RTP 和 NTP 时间戳都是无符号的，因此时间戳跳负这一事实应该无关紧要。

Live555 负责这种同步，这就是为什么您可能会在非常接近开始的地方看到时间戳中的跳跃。您可以选择忽略在 RTCP 同步之前接收到的所有样本，或者您可以执行更复杂的偏移映射以将 RTCP 同步之前和之后的数据归零。您可以通过调用 live555 的 RtpSource::hasBeenSynchronizedUsingRTCP() 方法来检查是否发生了同步。

但是，如果您看到多次跳跃，那么您可能遇到了不同的问题。在这种情况下，请通过添加更多详细信息来编辑您的问题，例如使用的 RTSP 服务器、RTSP 客户端等。