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

[Keith Page]

The problem I experience with VLC is that it takes the first set of 
presentation stamps as it's seed. When the new PTS stamps start coming 
in it detects that the numbers are way off from before, outside it's 
tolerance and throws an error saying PTS GAP, resetting clock, it then 
rebuffers. While that buffering takes place it throws out the frames 
coming in, leaving a blank section of the final muxed video. Once the 
buffer has refilled it is then fine on  per stream basis. During this 
process the video streams are able to stay in sync within a few ms but 
the audio is now all defunct and off by 4 - 8 seconds. The result is the 
first 30 second of video is pretty much junk and has to be cut off, and 
the audio through out the entire video is delayed as stated before.

I have tried playing with the code myself in vlc but have not had 
success getting a proper result out of it, it's beyond my ability to 
resolve. Though i thought if we could get a stream of stable PTS from 
openRTSP this problem would go away from VLC's point of view. VLC's code 
currently looks for the RTCP and then reset all it's counters once it's 
seen and throws out it's current buffer and rebuilds a new one.

So we aren't trying to re-invent any wheel, we are running into a 
problem with the current wheel not working in this situation,  that I 
thought could be fixed here by uniforming the PTS through the RTCP sync.

Could openRTSP not simply calculate an offset after the RCTP packet and 
adjust each subsequent packet by that offset to keep the whole PTS 
stream consistent? What would be the downside to doing this?

Thanks
Keith

On 10-01-18 5:03 PM, Ross Finlayson wrote:
>> 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'.