[Live-devel] Request to Fix inconsistent timestamps in openrtsp
gbonneau at miranda.com
Tue Jan 19 07:25:02 PST 2010
I do not know enough about the OpenRSTP application neither understand
how you interface the live camera stream with it. But your problem look
very similar to one I had 2 years ago with VLC. In fact you might have
ran into the same synchronization issue I have had while I was working
for another company. To understand that problem I had to recompile VLC
with modified code I added to the live555 demux wrapper code that VLC
used. You will find some links below. VLC was doing exactly what you
described with an application I developed that was using the live555
The video was an Mpeg2 elementary stream and the audio was a PCM stream.
This is what I found. The seed time for the timestamp of the Mpeg2 video
stream is initialized when the the MPEGVideoStreamFramer is created when
the method MPEGVideoStreamFramer::reset() is called by the constructor.
For the audio the seed time for timestamp of the PCM was initialized by
the object ByteStreamFileSource when method
ByteStreamFileSource::doReadFromFile() is called the first time.
As long as the starting of the video sink by method startPlaying is very
close (a few ms) to the creation of the Mpeg framer you are fine. You
have no synchronization problem with VLC. But if you start the sink a
few seconds after the creation of the Mpeg framer the video sink will
nonetheless use the timestamp seed that was initialized at the creation
of the object while the audio will use a timestamp seed that is
at the time the sink is started. And in the latest case an application
VLC try to compensate the few seconds of gap once the RTCP
packed is received and cannot because the gap between the audio and
is too big.
My point of view is that the MpegFramer of the live555 library shouldn't
use a time seed that is initialized when the object is created but
when the computePresentationTime() is called the first time. Though I
experienced that problem with the Mpeg framer you might have a look at
live555 code if your video stream uses another framer.
I suggested a minor change to the live555 library to solve that problem
is explained in the thread below. I am not sure but I think it was never
implemented. You might look at this thread yourself. It includes 2
that demonstrate the problem. If I remember I was using an I frame only
stream as a source for the video. You might try the patch I suggested to
if it solve your problem.
Hope this help.
>From: live-devel-bounces at ns.live555.com [mailto:live-devel-
>bounces at ns.live555.com] On Behalf Of Keith Page
>Sent: Monday, January 18, 2010 20:46
>To: LIVE555 Streaming Media - development & use
>Subject: Re: [Live-devel] Request to Fix inconsistent timestamps in
>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
>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
>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
>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?
>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
>> '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
>> with other substreams, unless of course your server is broken.)
>> This means is that a receiver should be prepared for the fact that
>> 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
>> the wheel here. You should be able to just use VLC 'as is'.
>live-devel mailing list
>live-devel at lists.live555.com
More information about the live-devel