There is an ffmpeg instance running as a server on a VPS, that converts RTSP video to HLS and serves it to the web (using Apache). The RTSP video comes from a computer somewhere else (in another town in this case), to which I have an IP camera connected. The computer takes the RTSP data FROM the IP camera and retranslates it TO the VPS.
This is the ffmpeg command I'm using on that computer (the re-streamer, may I say):
ffmpeg \
-rtsp_transport tcp \
-i rtsp://[IP address of the camera]:554/live \
-c:v copy \
-f rtsp \
-rtsp_transport tcp \
rtsp://[IP address of the VPS]:4445/live.sdp
And this is the command I'm using on the VPS:
ffmpeg \
-rtsp_flags listen \
-listen_timeout 5 \
-timeout 5000000 \
-rtsp_transport tcp \
-i rtsp://[ip address of the VPS]:4445/live.sdp \
-map 0 \
-flags +global_header \
-fflags +igndts \
-c:v copy \
-g 0 \
-b:v 125k \
-maxrate 250k \
-bufsize 500k \
-hls_time 1 \
-hls_list_size 15 \
-hls_wrap 15 \
-y /dev/shm/hls/video.m3u8
Everything works fine so far: I can read the HLS stream in browser and it is pretty stable and fast. The problem comes when the connection between the re-streamer and the VPS drops: I have to ssh into the VPS and restart the ffmpeg instance manually. Is it possible to tell ffmpeg to "crash" (or simply stop it's process) when no input is coming on the -i address (on the VPS's side)? I am using a bash script that restarts the process automatically, so that's taken care of.
Just to avoid any confusion:
According to ffmpeg's official documentation the timeout flag takes MICROSECONDS as a value and listen_timeout takes SECONDS. I've seen a lot of posts where people were arguing about that :)
