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. http://www.live555.com/ _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
