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