[FFmpeg-user] Can I set a "wait-timeout" for ffmpeg to not abort a stream download?

[Adam Nielsen]

> On a new invocation I will have to adjust the -t argument to handle
> the time until the original stop was supposed to be done of course.

If you're using "at" as you have suggested in your other message,
possibly you could just write the FFmpeg PID to a file and have "at"
send a TERM signal at the specified time.  That way you'd only need one
calculation, or possibly none if you can specify the duration as a
start and end time.

Just be careful of the edge case where it's in the process of
restarting right when the end time arrives, so there's nothing to
terminate and then the stream resumes.

> Is there a readymade function that can add/subtract time in hh:mm:ss
> format and return the same format?
> I think ffmpeg can actually handle -t hh:mm:ss in addition to -t sss

"date" can do a limited bit of maths but not sure if it will cover your
use case:

  date -d "now + 30 mins"

> Can I somehow specify to ffmpeg that it should *append* the new data
> to the already downloaded first part? Or do I have to get this new
> bit separately and then paste them together?

ffmpeg doesn't append, it takes in whole files and writes whole files.
You'd have to merge them after the fact.  You could possibly work
around the issue but I'm not sure it's worth it.

One workaround would be to have your ffmpeg instance stream the
transcoded data to a localhost UDP socket instead of a file ("-f
rtp_mpegts udp://localhost:1234").  Then you could run a second ffmpeg
instance that reads data from the UDP socket and writes it to your
file.  Since this second instance is listening on UDP, it won't
terminate when the first ffmpeg gets cut off, so when the first one
restarts and resumes sending the UDP data, the second one will keep
going, effectively "appending" the data.

But now you have to deal with two ffmpeg instances per recording, one
of which may randomly restart, and you might have to mess around with
which of the two instances does the actual encoding depending on what
codecs rtp_mpegts is able to send over the UDP socket.

> I have seen while watching live on the source webpage that it
> sometimes towards the top of the hour seems to black out the player
> for a while and then resume. It could take anywhere from 10 seconds
> to a couple of minutes when it happens.
> 
> The aborted recording does not have any of that it just suddenly ends.

You'll probably find the web player just blanks out the video while
it's trying to reconnect.  You might be able to get ffmpeg to do the
same with one of the -vsync options, but then having minute long black
sections in the output video might not be great for playback.

> I don't really understand why I would need to collect the "complete
> output" since I am not asking about *how or why* ffmpeg failed, what
> I asked is if there is an argument to ffmpeg, which will force the -t
> video time to be observed intstead of ffmpeg aborting when the stream
> pauses its streaming.

To understand why this was asked, have a read of "Pounding A Nail: Old
Shoe or Glass Bottle":

  https://weblogs.asp.net/alex_papadimoulis/408925

I know sometimes you just want an answer to your immediate problem, but
so often the issues people have would be better solved by tackling it a
different way.  Not having all the information about the problem means
often time gets wasted trying to solve the wrong issue.

In your case we could've spent ages trying to investigate ways to keep
ffmpeg alive, when it turned out that the lost TCP connection meant
keeping ffmpeg alive would not have helped solve the problem, and any
attempts to try to do so would have been wasted effort.  This is why
everyone is eager to fully understand what you are trying to achieve,
so they can offer the best solution.  Yes, the information might seem
irrelevant to you, but many a time someone will spot something you
weren't even aware of so it's always worth giving the whole story when
asking for help.

And yes, speaking from experience sometimes this results in solutions
you don't want, but that's better than an answer that does exactly what
you asked for but still doesn't fix the problem!

> I cannot dig out such information anyway since it is hidden below
> several levels of at command handling and scripts calling other
> scripts. It all happens in an at job container...

Sounds like you need to improve your logging :-P

Cheers,
Adam.