> On Dec 22, 2021, at 3:15 AM, DJM-Avalesta <david.my...@avalesta.com> wrote: > > > So, I suggest adding, to your server code, code that compares the value of > > ‘fPresentationTime” computed your new way, > > > with the value that would be computed by calling “gettimeofday()”, and > > print out the difference > > Thanks, Ross. I assume you mean, if the new presentation time becomes > different from wall clock time by a large amount, eg more than 1 second, I > should reallign fPresentationTime with wall clock time
No, I meant that if the new presentation time becomes different from wall clock time by a large amount, eg more than 1 second, you should figure out why this has happened, and fix the bug in your code that has caused this to happen. As I noted before, having a new RTSP client ask to join the multicast group (using the “DESCRIBE”, “SELECT”, “PLAY” commands) should not affect the outgoing RTP stream at all, including the computation of “fPresentationTime”. Calling “gettimeofday()” only once - at the beginning - and thereafter computing “fPresentationTime” from the frame count and frame rate, is a perfectly reasonable thing to do. (For example, this is what our “testH264VideoStreamer” demo application does, using “H264VideoStreamFramer”.) But the fact that this is failing badly for you whenever a new client requests the stream suggests that there is a bug in your code that you should fix - not just paper over, as you’re doing now. 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
