Opened 10 years ago
Last modified 5 years ago
#4392 new enhancement
Reconnect on lost connection for TCP based protocols
Reported by: | liquider | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | unspecified | Keywords: | |
Cc: | jsantiago@fastmail.us | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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?
Change History (4)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Read-only but still ACK
ing 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?
comment:3 by , 8 years ago
Cc: | added |
---|
comment:4 by , 5 years ago
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.
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.