[Live-devel] Request to Fix inconsistent timestamps in openrtsp

Ross Finlayson finlayson at live555.com
Mon Jan 18 17:03:56 PST 2010

>The beginning of the muxing in vlc suffers from starts and stops 
>while RTCP occurs. The time stamps being fed into vlc from openRTSP 
>starts as actual unix time stamps, once a RTCP is received from the 
>media source openRTSP changes to an arbitrarily number

This is normal, and expected; there's no bug here.  It's because the 
first few presentation times - before RTCP synchronization occurs - 
are just 'guesses' made by the receiving code (based on the 
receiver's 'wall clock' and the RTP timestamp).  However, once RTCP 
synchronization occurs, all subsequent presentation times will be 
accurate.  (Depending upon the server, these presentation times - 
after RTCP synchronization has occurred - might not necessarily look 
like current Unix timestamps, but they *will be* accurate, and in 
sync with other substreams, unless of course your server is broken.)

This means is that a receiver should be prepared for the fact that 
the first few presentation times (until RTCP synchronization starts) 
will not be accurate.  The code, however, can check this by calling 
"RTPSource:: hasBeenSynchronizedUsingRTCP()".  If this returns False, 
then the presentation times are not accurate, and should be treated 
with 'a grain of salt'.  However, once the call to returns True, then 
the presentation times (from then on) will be accurate.

Note, however, that this is *already* implemented in VLC (in its 
"live555" demux module), so I don't know why you're trying to 
reinvent the wheel here.  You should be able to just use VLC 'as is'.

Ross Finlayson
Live Networks, Inc.

More information about the live-devel mailing list