[FFmpeg-user] Can ffmpeg be set to wait if a stream stop happens?

[Bo Berglund]

On Thu, 22 Apr 2021 14:22:17 +0200, Moritz Barsnick <barsnick at gmx.net> wrote:

>Hej Bo,
>
>On Wed, Apr 21, 2021 at 16:59:10 +0200, Bo Berglund wrote:
>> But what I have noticed lately is that sometimes the stream it downloads from
>> stops feeding data for a few seconds (don't know for how long) and it seems like
>> ffmpeg at that times finishes up the output file and exits.
>
>ffmpeg shouldn't interrupt if the input stream just "stalls". It will
>interrupt if the stream server actually closes the connection. With
>HLS, where the URLs to open continuously change, ffmpeg will retry a
>certain number of times (IIRC) before giving up.
>
>> Is there a way to tell ffmpeg to stay online for that full amount even if the
>> stream pauses for some reason?
>
>I suspect it isn't "pausing". It would be practical to see a complete
>log output, of course. (You can generate them by using the "-report"
>option, but they may become large, unless you reduce the default report
>log level.)
>

I don't really know what happens but the hourly downloads are supposed to end at
about 4 min after the hour (using the -t argumant to ffmpeg) and the problem
videos end anywhere inside the hour.
It can happen after 5 min or 55 min into the recording...
The shortened videos are playable but suddenly end without warning.

I extended my download script so it will check after ffmpeg exits if the set
time has been reached or if it is more than 2 min short.
If it is short it modifies the output file name by adding extension .x.mp4
instead of .mp4, then it waits for 60 s and re-launches the ffmpeg command.
I log it too so I can see that it has triggered but no video file appears from
this call so I assume that the problem persists for longer than the minute I
wait...

In my log I see that the extra ffmpeg call has been executed 5 times since April
22, when I modified the script.
But no "rescue" video appeared so I guess at these times the outage was longer
than 60 seconds. When the next recording started the following hour it usually
worked.

Since I am unable to simulate the problem I think I have just to give up for the
moment...


-- 
Bo Berglund
Developer in Sweden