[Live-devel] Sysclock sanity check causes slow-motion MPEG-2 TS playback from live555MediaServer

[Warren Young]

We have discovered a problem with the following patch, introduced in 
live.2010.12.05:

- Added a sanity check to "MultiFramedRTPSink" and "BasicUDPSink" to
   allow for the possibility of the system clock jumping ahead in time,
   and thereby messing up the calculation of how long to wait before
   sending the next packet. (Thanks to Anders Chen for noting this
   issue.)

This causes MPEG-2 TS videos to play in slow motion on CentOS 3.x boxes, 
but not on our CentOS 5.x boxes.  I'm guessing that it is due to some 
difference in the implementation of gettimeofday() in kernel 2.6.

The client doesn't seem to matter.  We've seen it with VLC on a variety 
of PCs, but also with hardware RTSP MPEG-2 TS stream decoders.

We've ruled out differences in compilers and system libraries.  We 
initially tested with binaries built on the test systems, but later 
tried copying the binary built on our CentOS 3.x test box to our CentOS 
5.x test box, and the problem persisted.

That test also rules out CPU type differences, since our CentOS 3.x box 
is a 32-bit Intel and the CentOS 5.x is a x86_64 box.  Running the 
32-bit binary built on the older box to the new 64-bit box -- where it 
runs asymptomatically -- rules out things like int64_t being typedef'd 
incorrectly.

Here are the uname strings for our test boxes:

CentOS 3.x, slo-mo: 2.4.21-63.EL i686 GNU/Linux
CentOS 5.x, normal: 2.6.18-164.15.1.el5 SMP x86_64 GNU/Linux

Maybe this patch also caused this guy's symptom:

http://lists.live555.com/pipermail/live-devel/2010-December/012969.html

Was this patch just "looks like a good idea" sort of patch, or does it 
fix something else, and reverting it breaks that?