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