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

【问题标题】：How to fix incorrect timestamp calculations? [OpenRtspClient]如何修复不正确的时间戳计算？ [OpenRtspClient]
【发布时间】：2012-01-21 21:12:27
【问题描述】：

我的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

所以，我的问题是：

如何使用Live555 媒体库解决这个问题？我是不是该忽略RTCP 信息或推荐的解决方案是什么，我该怎么做申请Live555?

【问题讨论】：

标签： timestamp h.264 rtsp live555 rtcp

【解决方案1】：

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

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

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

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

【讨论】：

我修改了 Live555 Open Rtsp 代码...使其更加面向对象并且可在多线程环境中使用...问题是我的一些 [不是全部] rtsp 服务器 [它们是 IP 摄像机] 甚至不发送任何 RTCP 信息...所以 RtpSource::hasBeenSynchronizedUsingRTCP() 永远不会是真的...
顺便说一句，当我将我的 rtsp 源连接到解码器并渲染它时，一切都可以，因为我没有给媒体样本提供任何时间戳值......但是当我尝试录制时，我必须给时间戳然后记录文件包含所有帧但时间戳错误...
更多解释我的问题：stackoverflow.com/questions/8558448/…
我不认为这是因为 RtpSource::hasBeenSynchronizedUsingRTCP() 标志...我以 10 分钟等时间间隔记录帧..假设前 5 个十分钟记录是正确的但稍后错误的...应该在 50 分钟后同步...
好的，那么您的意思是，由于您的某些 IP 摄像机甚至不发送 RTCP 报告，因此 RTCP 同步上不会发生跳转？我建议一次处理一种 RTSP 服务器类型以确定最佳工作解决方案。然而，这不是 live555 的问题：根据我的经验，live555 正确地实现了 RTP 标准。如果相机发送的 RTP 时间戳无特殊原因跳转并且您可以验证这一点（IMO 最好使用未修改的 openRTSP 客户端以确保您没有引入任何错误）我会与制造商讨论这个问题相机。

【解决方案2】：

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

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

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

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

【讨论】：