<div dir="ltr"><div><div><div><div><div><div><div><div><span style="font-family:monospace,monospace">Hi All,<br><br></span></div><span style="font-family:monospace,monospace">I have a very simple Gstreamer (using version 1.6.0 at present) pipeline running on an Embedded ARM system:<br><br></span></div><span style="font-family:monospace,monospace">rtspsrc -> rtph264depay -> appsink<br></span></div><span style="font-family:monospace,monospace">        -> rtppcmudepay -> appsink<br><br></span></div><span style="font-family:monospace,monospace">In the appsink I pass the buffers to my application for processing. However, over time the PTS value of the buffers gradually drift into the future.<br><br></span></div><span style="font-family:monospace,monospace">My RTSP source is an IP Camera, providing H.264 video (</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">1080P, 15fps)</span> and PCM mulaw audio (single channel, 8000Hz).<br><br></span></div><span style="font-family:monospace,monospace">Ideally I need to have the buffer PTS values in real time so I can match video frames (and audio) up to externally timed events, such that I'm given a Linux epoch where I need to find the appropriate video frames for within a buffer in my application.<br></span></div><div><span style="font-family:monospace,monospace"><br>I was under the impression that the jitter buffer should be compensating for any drift or mismatch in clocks?<br><br></span></div><div><span style="font-family:monospace,monospace">I've tried a few things but nothing seems to resolve this problem! Before setting sync=false on my sinks, lag would build up in the live output from the appsink...and over the course of a few days I'd be 10, or so, minutes behind real time and the application's memory usage would increase accordingly (I believe it was stacking up the rtspsrc somewhere). I've tried adding queues between the depayloaders and sinks, and again no difference. (I used the camera's overlay feature to place the date and time in the video frame, comparing that time value to the timestamp shows the same problem - at the start they are in line, but after some running time, the disparity builds).<br><br></span></div><span style="font-family:monospace,monospace"></span><span style="font-family:monospace,monospace"></span></div><div><div><span style="font-family:monospace,monospace"></span></div><div><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">I've had the pipeline use the GST_CLOCK_TYPE_REALTIME (since I want buffer PTS with real time values) and </span>I've also just tried using the defaults to no avail... In the appsink I decided to print out the pipeline clock time, the base time and the PTS of the buffer:<br><br>Example after running for a couple of minutes: <br>    Pipeline Clock:[16905692471587] Pipeline Base Time:[16662001463649] Buffer PTS:[243730006699]. A little calculation: <br>        clock - base = running time <br>        (</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">16905692471587</span> - </span><span style="font-family:monospace,monospace">16662001463649) = 243691007938, which is less than PTS: </span><span style="font-family:monospace,monospace">243730006699 (bad).<br><br></span></div><div><span style="font-family:monospace,monospace">And just for reference - the first buffer to arrive at the appsink:<br>    Pipeline Clock:[16663381713212] </span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">Pipeline </span>Base Time:[16662001463649] Buffer PTS[480006699]. </span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">A little calculation: <br>        clock - base = running time </span><br></span></div><div><span style="font-family:monospace,monospace">        (</span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">16663381713212 - </span></span><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">16662001463649</span></span>) = 1380249563, which is greater than the PTS: </span><span style="font-family:monospace,monospace">480006699 (good).<br><br></span><span style="font-family:monospace,monospace">I've found some improvement by setting the 
buffer-mode to 0 and by setting ntp-time-source to 3. But 
essentially am just staving off the inevitable.<br><br></span></div><div><span style="font-family:monospace,monospace">Any ideas?<br><br><br></span></div><div><span style="font-family:monospace,monospace">Best Regards,<br><br></span></div><div><span style="font-family:monospace,monospace">Martin<br></span></div></div></div>