5

EDIT: At the time of this writing there is no functionality within FFMPEG that can detect/handle when an RTP/RTSP stream is still active but is no longer delivering valid frames. The only solution I could find was to periodically reset the stream by stopping recording, then reconnecting and starting a new recording which -f segment does NOT do.

I'm recording an RTSP stream from a network camera with FFMPEG, and after some time (usually about an hour and a half to two hours). I'm sure it's specifically a problem with the cameras I'm using and not FFMPEG or my system resources.

What specifically happens is the video freezes but network traffic with the camera continues - it just doesn't seem to send new frames. Because of this behaviour FFMPEG doesn't disconnect/keeps recording because the network connection is still alive. After a few minutes there will always be a single warning in the FFMPEG output: More than 1000 frames duplicated But it keeps recording - it's just the same frame over and over.

The command I'm using is:

ffmpeg -stimeout 1000000 -rtsp_transport udp -fflags discardcorrupt -i rtsp://192.168.1.163/live/0/MAIN -vc libx265 -f segment -segment_time 300 -segment_atclocktime 1 -reset_timestamps 1 -strftime 1  "163-%Y-%m-%d_%H-%M-%S-h265.mp4"

Some notes:

  • stimeout doesn't seem to do anything as the network connection is maintained the camera just seems to stop sending (valid) frames.
  • Changing the codec to copy doesn't improve the issue
  • Changing the RTSP transport doesn't improve the issue
  • I'm aware there is a filter to detect frozen frames, but my FFMPEG does not seem to have it - I'm going to try and build FFMPEG myself now; but would much prefer a solution that works with bundled FFMPEG ~> 4.1.3

Having FFMPEG fail and exit after > 1000 frames are duplicated would actually be ideal, as then I can just spawn FFMPEG from a script, monitor the process, and restart it when the process ends. Any solution would be great though.

Kagetsuki
  • 309
  • 2
  • 18

2 Answers2

3

While have been struggling with similar issue for a while, I haven't found any reliable solutions. The best option so far was to run watchdog script that monitors all running ffmpeg processes reading RTSP streams, and tracks CPU usage for every process. When usage drops to zero between a few consecutive checks, 99.9% that means that ffmpeg is stuck reading the stream. Watchdog just kills corresponding ffmpeg process, and it starts again from another shell wrapper script.

I also use stimeout, and it actually helps in cases when there are various network issues, but as stated by the topic starter it doesn't have any effect when network is fine and it's just RTSP source (camera) that stops working correctly.

This is indeed ugly but tends to work. Appreciate if anyone would share better approaches.

Andrei Belov
  • 1,131
  • 9
  • 8
1

This guy will help you:

11.134 mpdecimate

Drop frames that do not differ greatly from the previous frame in order to reduce frame rate.

The main use of this filter is for very-low-bitrate encoding (e.g. streaming over dialup modem), but it could in theory be used for fixing movies that were inverse-telecined incorrectly.

use like that: "-vf", "mpdecimate,setpts=N/FRAME_RATE/TB",

luno
  • 51
  • 2
  • 2
    I should have updated my question but I actually tried that. Because there is no real data in the frames mpdecimate can't actually perform a comparison and the filter is never run - the data still filled up. The problem wasn't with ffmpeg per-se, the only solution I could find was to periodically reset the connection (stop and re-start recording). There is no functionality in ffmpeg that I am aware of at this time/could find that can detect when a stream is not dropped but is no longer delivering frames. – Kagetsuki Apr 21 '20 at 07:46