Best possible uptime is essential for the RTSP client I'm implementing. I've therefore looked into how to best handle reconnection if the stream for any reason is disconnected. I noticed fairly quickly that liveMedia is taking care of that really good and there is no reason for me to try to implement any general disconnect handling, as I can't possible reconnect any faster than liveMedia already does.
There is one case where it doesn't work though, and I'm not sure how to handle it. This is if I do a seek while the stream is disconnected, then it never reconnects. In some cases I play a 10s loop where a timer do a seek every 10s and jumps back (using absolute seeking). Those streams never reconnect after a disconnection. I see a few alternatives: 1. I continuously try to reconnect myself, but I don't want to mess up liveMedia's reconnection handling, so not sure how to detect when I should handle a disconnect myself. 2. Make sure I don't issue a seek, or any PLAY-command (i.e. call sendPlayCommand()) when the stream is down. Is there a status flag I can check somewhere to determine this? 3. Look at the reconnect-handling in liveMedia. No idea what could be done to make sure the re-connect functionality isn't disrupted, but maybe buffer the PLAY-commands until they can be performed, or just discard them. Any comments would be appreciated. Can anyone confirm that my theories are correct, i.e. that a stream doesn't reconnect if a PLAY-command is issued while the stream is down? /Claes
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
