Opened 3 years ago

Last modified 18 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 (3)

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by 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?

comment:3 Changed 18 months ago by jlsantiago0

  • Cc jsantiago@fastmail.us added
Note: See TracTickets for help on using tickets.