Reconnect on lost connection for TCP based protocols

[liquider]

ffmpeg doesn't reconnect when streaming to a remote server (e.g. rtmp://, tcp://) if the connection is lost.

When running e.g.

$ ffmpeg -i ... -f flv rtmp://...

if the connection drops for some reason (e.g. ifdown eth0, network cable unplugged), ffmpeg doesn't reestablish the session when the connection becomes available again. In fact nothing happens, the process just hangs.

-loglevel debug doesn't report anything, the RTMP_SendPacket just stops.

This seems to have been discussed before:
​http://ffmpeg.org/pipermail/ffmpeg-user/2012-October/010137.html

A pair of options like -reconnect and -disconnect_exit would make sense for TCP-based protocols?

[Cigaes]

This is more complicated than you think.
If the protocol is read-only for the bulk of the transfer, there is nothing to detect a disconnected remote host. Unlike what you believe, ifdown or unplugging the cable does not have that effect.

TCP has the SO_KEEPALIVE option to send dummy packets to detect fallen links like that. It does not do what people believe, it has a very long timeout (two hours) that is not supposed to be changed.

Clients for that kind of protocol usually need to implement some sort of user-settable timeout to achieve anything.

[liquider]

Read-only but still ACKing every packet (or so). What about SO_SNDTIMEO socket option? Couldn't it be made to account for relatively slow connections and still trigger something when the connection is effectively broken?

[gregorycu]

There are categories of situations where you can indeed detect a link going down. Not being able to handle every single situation isn't a really good justification for downplaying a specific use case.