[vlc-devel] live555 connection timeout (patch included)
rdenis at simphalempin.com
Wed Oct 8 09:59:28 CEST 2008
On Tue, 7 Oct 2008 23:42:34 +0200, Derk-Jan Hartman <hartman at videolan.org>
>> 1. change i_lefttries from 3 to 1. As Sebastien remarqued, I don't
>> know why we want to retry 3 times and take 3 times as much time to
>> return. The user can retry manually if he wants to. I am sure he would
>> rather retry himself than wait longer.
For the RTSP control connection or for data?
I personally think that retrying TCP connection (without the user asking)
is evil. TCP handshake has built-in SYN and SYN/ACK retransmissions to deal
with packet loss anyway.
This leaves the case that the server sends a RST packet. Which means the
server is off. Which means you should not try to reconnect unless the
On the other hand, many people keep asking for http-reconnect to be
"fixed", so I can imagine the same requests coming for RTSP.
> This is for an initial authentication failure basically, and for
> rollover to TCP i think.
So it reconnects the control connection to rollover to TCP? That would seem
>> 2. In the Connect member, if p_sys->rtsp->sendOptionsCmd fails
>> p_sys->rtsp->describeURL is called anyway. both of these call
>> openConnectionFromURL. It would seem that if
>> p_sys->rtsp->sendOptionsCmd fails, p_sys->rtsp->describeURL could be
>> skipped. This saves waiting for another openConnectionFromURL to fail.
> Possibly, but i'm a tad weary on this.
In theory, it should work, but if it makes the messy/buggy
liblive555_plugin state machine even more complicated, then err...
> The live555 code should be fixed, or better, we should dump live555
> and implement RTSP in VLC. (so we also get ipv6 support).
> We can discuss this to the moon, but ultimately, those are the best
> two options. There is one question to ask, and that is who's is gonna
> do the coding work.
More information about the vlc-devel