Opened 6 years ago

Last modified 16 months 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 Nicolas George, 6 years ago

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.

comment:2 by liquider, 6 years ago

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?

comment:3 by Jose Santiago, 5 years ago

Cc: jsantiago@fastmail.us added

comment:4 by gregorycu, 16 months 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.

Note: See TracTickets for help on using tickets.