> I come back on the subject of sending presentationTime from a live555 RTSP > server to a live555 RTSP client. > Till now I have missed that RTCP sendReport were always based on server clock > and basically the presentationTime set by an RTPSink is more or less ignored.
No, the presentation time that is fed to (not 'set by') a server's "RTPSink" is NOT 'ignored' It's never ignored. HOWEVER, as I have REPEATEDLY said on this mailing list, if the server is built using our code, then these presentation times (the ones that are fed to "RTPSink"s) must be aligned with 'wall clock' time - i.e., the times that are sent using "gettimeofday()". In other words, the data source objects that feed to "RTPSink"s must have their presentation times properly aligned with 'wall clock' time. I don't know what your 'patch' allegedly does (because I don't know why/where your proposed new "RTPSink::setPresentationTImes()" function would ever be called, but I don't care, because presentation times are not 'set' for "RTPSink"s; they are fed to "RTPSink"s). In any case, I won't be applying your patch, because nothing is broken. > Do you think it could be a way to send frame time from RTSP server to RTSP > client ? I simply fail to understand why you keep talking about 'sending times from the server to the client', because that's ALREADY WHAT WE DO (and have done for years)! However (again, as I have explained REPEATEDLY), all clients must be prepared for the possibility that the first few client-generated presentation times (before RTCP synchronization has occurred) will not be accurate. HOWEVER, as of version 2013.03.23, our server implementation (but, of course, not necessarily other people's server implementations) sends a RTCP "SR" packet before the first RTP packet. This makes it very likely (though never certain, due to possible packet loss) that the clients presentation times will all be RTCP-synchronized. I did this specifically to make you happy - or so I thought... (Unfortunately, I'm going to have to moderate all future posts from you, because I'm tired of the mailing list being filled with your confused messages, and I'm tired of explaining the same thing over and over again.) 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
