It’s difficult to see how the actions of a disconnecting client (i.e., whether
or not it sends a RTSP “TEARDOWN” command) could make much difference to the
behavior of a server that’s streaming a multicast stream, because a server for
a multicast stream (i.e., using a “PassiveServerMediaSubsession”) specifically
does not do anything to the stream when it receives a “TEARDOWN” (because, for
a multicast stream, it’s possible that other receiving clients might still want
to continue receiving the stream). So I think this is a ‘red herring’.
Without a way to reproduce your problem (e.g, by streaming from a specific,
known Transport Stream file), it’s going to be hard to figure out what’s going
on.
But I wonder if your problem might instead be related to the earlier problem -
which was caused by our code’s handling of unexpected jumps in the input
stream’s PCR timestamps.
When you test receiving the stream using “openRTSP” - as you did here
http://lists.live555.com/pipermail/live-devel/2024-April/022529.html
do you still see any issues?
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
