> On Dec 21, 2021, at 6:10 AM, DJM-Avalesta <david.my...@avalesta.com> wrote: > > >Connecting a RTSP client to receive a multicast RTP stream should not change > >the RTP stream at all - so (unless you have a firewall > >or other middlebox somewhere that is altering the RTP stream) there must be > >a mistake in the way that your RTSP server application > >is delivering this stream. > > I believe, there still needs to be a RTSP handshake for VLC to join the > multicast stream.
Of course. But this “RTSP handshake” should not change the multicast RTP stream (i.e., the contents of the outgoing RTP packets) at all. The stream of outgoing multicast RTP packets should be oblivious to whatever/whenever remote RTSP clients join or leave the stream. The fact that this is not happening for your server points to where the bug must be - probably, in the way that you are computing “fPresentationTime” (see below). > This is code which has run for many years. The change I made recently was to > calculate the presentation time for each frame based on > the frame-rate, eg 40ms for 25fps, rather than calling gettimeofday() for > every frame. This would have been nice to know before. The key point is that the values of “fPresentationTime” - computed by your server for each outgoing H.264 NAL unit - must (for our RTSP server implementation) be ‘aligned’ with wall clock time - i.e. the time that you would get by calling “gettimeofday()”. That doesn’t mean that each “fPresentationTime” has to be computed by calling "gettimeofday()” (as you were doing before), but, instead, that the computed values of “fPresentationTime” should be the same (or very close to the same) as if you had called “gettimeofday()” (ideally, as soon as possible after the NAL unit was encoded). 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 (e.g., in microseconds), for each NAL unit. At first, this difference will be very small, but you’ll likely find that sometime - whenever a new RTSP client joins the stream - this difference becomes large. This should tell you where the bug is in your code. As I noted earlier, for a multicast stream, having a client join or leave the group should not affect the outgoing stream at all (including, the values of “fPresentationTime”). 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
