How to fix incorrect timestamp calculations? [OpenRtspClient]

Question

My RTSP Source's RTCP SR are not reliable for some of the calculated timestamps of H.264 streams frequently resulting in large negative jumps.

Here is an example from the debug log. See how it jumps from 101006.6130 to -4193861.6830 and continues that way.

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

So, my question is:

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

Are you using live555 exclusively on client? With unmodified source code? Where does the logging info in your question come from?

Generally, there will always be one jump in timestamp fairly close to the beginning of the stream: this occurs when the first RTCP SR is received by the client at which point the client resets the timestamp. This is necessary so that a client can synchronize multiple streams as RTP timestamps in both audio and video each begin with a randomized offset. The RTCP SR contains the mapping from RTP to NTP timestamp, which allows the client to synchronize the timestamps. The fact that the timestamp jumps negative shouldn't matter since both RTP and NTP timestamps are unsigned.

Live555 takes care of this synchronization and this is why you might see a jump in timestamp fairly close to the beginning. You have the option of either ignoring all samples received prior to RTCP synchronisation or you can perform a more complex offset mapping to zero both prior RTCP synchronisation and after. You can check whether synchronization has occurred by calling the live555 RtpSource::hasBeenSynchronizedUsingRTCP() method.

If however you are seeing multiple jumps, then you may have a different problem. In that case, please edit your question by adding more detail, such as RTSP server used, RTSP client, etc.

Answer 2

I really don't know the implementation of RTCP SR; consequently i don't know the units which 100605.xxxx represents. However, if i assume that generally if i believe that they are derived from PTS/DTS values of the stream's 90 kHz clock value.

If this is true, it is well known that such a clock timers recycles themselves at 2^33 bits. This is called as WRAPAROUND of the clock. If this is printed as a signed number - this will become positive. Such a wraparound will happen exactly after a certain value of Clock.

To validate that indeed the highest and lowest values will always be in same or similar range.

The other such possibility is called discontinuity which arise when the source timebase suddenly shifts (possibly due to some fault).