<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi Ross,</p>
<p>Apologies, I couldn't find that thread from last year for some reason. I know it's not netiquette to resubmit the same question so could we please consider this a continuation of that previous thread?</p>
<p>I had thought I'd reduced this issue to a negligible point but not so. I had patched it up be adding a resynchronise with wall clock time every time a new client connected, however this did not fix the issue.</p>
<p>The following is the only place now in my code where fPresentationTime is set and the only place gettimeofday() is called is at the very start of the stream (unless fPresentationTime gets zeroed).</p>
<pre><em>if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0)
</em> <em>gettimeofday(&fPresentationTime, NULL);
</em><em>else
</em><em>{
</em><em> // Increment by the sample time
</em> <em> unsigned uSeconds = fPresentationTime.tv_usec + 1000000/25; //25fps, </em><em>the frame rate (40ms)
</em> <em>fPresentationTime.tv_sec += uSeconds/1000000;
</em> <em>fPresentationTime.tv_usec = uSeconds%1000000;
</em><em>}<br /></em><br />Does the Live555 library carry out its own check on fPresentationTIme and modify it if it drifts away from wall clock time? <br /><br />Why might this only occur when there is an RTSP handshake? Even if this handshake is hogging the CPU, the presentation time should not jump more than 40ms, <br />it should just fall further behind wall clock time.<br /><br />I can't stop this drift of fPresentationTime away from wall clock time, I assume that the 25fps from the TV chip (this is an encoder for analog video) <br />is not accurate enough to use as a system clock.<br /><br />Any ideas how I can debug this further?<br /><br />Thanks again.<br />D.</pre>
<div id="v1v1_rc_sig"></div>
</body></html>