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

Reply via email to