Thanks for your quick and useful response, I have checked it and admit that the "SR" always comes to the client before the first RTP packet.
But I still wonder about two things: 1) Since the RTPTimestamp bound to the first "SR" is different from the one bound to the first RTP packet, how can PTS be synchronized to the server's NTP correctly at the client side? 2) Does PTS at client always monotonically increase even in case RTPTimestamp (32-bit) is wrapped around?. Regards. Steve. On Fri, Jan 22, 2021 at 4:01 PM Ross Finlayson <finlay...@live555.com> wrote: > > > > On Jan 22, 2021, at 4:05 PM, Steve Ha <stev...@u2sr.com> wrote: > > > > My question is how can I force the first RTCP "SR" packet to be > delivered at the same time as the first RTP packet so that the RTSP client > could get all frames with correct PTS? > > Basically, you can’t. (But even if you could, there’d be no guarantee > that it would be received, as it (like all RTCP (and RTP packets) are > datagrams.) > > However, our RTSP server implementation *does* send an initial RTCP “SR”, > before the first RTP packet, precisely for this reason. (See > “OnDemandServerMediaSubsession.cpp”, line 550.) > > > 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 >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
