[Live-devel] Presentation time, multicast and multiple client connections

[DJM-Avalesta]

Hi Ross,

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?

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.

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

if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0)
         gettimeofday(&fPresentationTime, NULL);
else
{
     // Increment by the sample time
    _ unsigned uSeconds = fPresentationTime.tv_usec + 1000000/25; 
//25fps, _the frame rate (40ms)
     fPresentationTime.tv_sec += uSeconds/1000000;
     fPresentationTime.tv_usec = uSeconds%1000000;
}

Does the Live555 library carry out its own check on fPresentationTIme 
and modify it if it drifts away from wall clock time?

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,
it should just fall further behind wall clock time.

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)
is not accurate enough to use as a system clock.

Any ideas how I can debug this further?

Thanks again.
D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20220708/69b76610/attachment.htm>