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

[BONNEAU Guy]

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 
library.

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
initialized 
at the time the sink is started. And in the latest case an application
like 
VLC try to compensate the few seconds of gap once the RTCP
synchronization 
packed is received and cannot because the gap between the audio and
video 
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
rather 
when the computePresentationTime() is called the first time. Though I 
experienced that problem with the Mpeg framer you might have a look at
the 
live555 code if your video stream uses another framer.

I suggested a minor change to the live555 library to solve that problem
that 
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
application 
that demonstrate the problem. If I remember I was using an I frame only
mpeg2 
stream as a source for the video. You might try the patch I suggested to
check 
if it solve your problem.

http://lists.live555.com/pipermail/live-devel/2008-February/008121.html
http://lists.live555.com/pipermail/live-devel/attachments/20080212/8ba7d
ba1/attachment.ksh 
http://lists.live555.com/pipermail/live-devel/attachments/20080212/8ba7d
ba1/attachment-0001.ksh

Hope this help.
GB

>-----Original Message-----
>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
>openrtsp
>
>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
>live-devel at lists.live555.com
>http://lists.live555.com/mailman/listinfo/live-devel