3

对于某些计算的流时间戳，我RTSP Source的 's 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

所以，我的问题是：

如何使用Live555媒体库解决此问题？我应该忽略RTCP信息还是推荐的解决方案是什么，我该如何申请Live555？

4

2 回答 2

2

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

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

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

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

于 2011-12-19T07:59:18.247 回答
1

我真的不知道RTCP SR的实现；因此我不知道100605.xxxx 代表的单位。但是，如果我假设通常如果我相信它们是从流的 90 kHz 时钟值的 PTS/DTS 值得出的。

如果这是真的，那么众所周知，这样的时钟定时器会以 2^33 位循环自身。这称为时钟的 WRAPROUND。如果将其打印为带符号的数字 - 这将变为正数。这样的环绕将恰好在某个时钟值之后发生。

验证最高和最低值确实总是在相同或相似的范围内。

另一种这样的可能性称为不连续性，当源时基突然移动（可能是由于某些故障）时会出现这种情况。

于 2011-12-26T12:39:00.123 回答