Hi Ross,
OK, so we've established (again!) that your problem is that your
server's presentation times are not properly aligned with 'wall clock'
time
(the time that you'd get by calling "gettimeofday()"). This is
necessary because the periodic RTCP "SR" ("Sender Report") packets -
sent by the server - are used, by receivers, to properly synchronize
the stream, and the timestamps in these RTCP "SR" packets are set by
calling
"gettimeofday()".
(Note, BTW, that these RTCP "SR" packets are sent frequently, and do
*not* necessarily coincide with the connection of new RTSP clients.)
So, this RTCP SR logic is calling gettimeofday() and changing
fPresentationTime outside of my control?
If - using your current scheme - you cannot keep your presentation
times aligned with wall clock time, then I suggest computing your
presentation
times by calling "gettimeofday()" each time - not just at the start of
the stream. Or, if you feel that that's too expensive,
then compute it using "gettimeofday()" something like every 100 frames.
I've come full circle now, I started with calling gettimeofday() every
single frame, but the users complained that vlc was way too jumpy and
they
insisted that other encoders showed exactly 40ms between the
presentation times of every frame.
However, it sounds promising to re-align with wall-clock time every 100
frames, which is every 4 seconds in my application.
- D
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
