I was performing the timestamping using gettimeofday as the timestamps, but before temporarily queuing the samples. Once I moved the timestamping to the track's deliverFrame method the problem was resolved.
Thanks for your help. (First, when replying to a mailing list digest, please use a proper "Subject:" line. (In this case, I've corrected it for you.)) I suspect that the cause of your problem is that your H.264 video source object - on your server - is setting incorrect "fPresentationTime" values. It's important that these "fPresentationTime" values be ***aligned with wall-clock time*** - i.e., the time that you would get by calling "gettimeofday()". (The reason for this is that our RTCP implementation uses "gettimeofday()" times.) The server's clock doesn't have to be in sync with the rest of the world (i.e., via the Network Time Protocol (NTP)). But it's important that the "fPresentationTime" values be aligned with the server's clock. 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
