there are video streams showing a strange behaviour when recording them
with ffmpeg in that ffmpeg will record the stream for an apparently
random amount of time, ranging from one minute to ten minutes, and then
stop recording. Once it stops recording, ffmpeg continues to run
indefinitely, not receiving and not recording anything.
I have programmed my recording application that uses ffmpeg to overcome
this problem such that it monitors the size of the recorded file. If
the size doesn´t change for at least eight seconds, the ffmpeg process
supposed to record it is being killed and a new one is started to record
the same stream.
When the recording is finished, I have a number of files (chunks) that
were recorded, and I can use ffmpeg to concatenate these files. When
watching the concatenated version of the recording, the video that has
been recorded shows "backjumps": That means there are a few seconds that
were at the end of chunk N which also are at the beginning of chunk
N+1. How many seconds are overlapping varies.
This is, of course, annoying. It is also puzzling because I used to
think that the recording stops because there sometimes is insufficient
bandwidth to continue to record. This doesn´t seem to be the case,
The stream being recorded is an hls stream accessed via the http URL of
an m3u8 playlist.
There are such streams that can be played with ffplay without
interruption for hours. (I haven´t tried recording those yet. Since
the streams that can not be recorded continuously also cut off when
being played with ffplay, I can assume it would be possible to record
the streams that play uninterrupted as continuously as they play.)
Now I´m assuming that the problem isn´t insufficient bandwidth or an
issue with ffmepg, but more likely an incompatible or troubled server.
That hls provides the "stream" (I wouldn´t call that a stream because
"stream" implies a continuous flow) in small chunks can explain the
annoying overlaps I am observing:
When the recording is restarted, it starts with a chunk that already has
been received and continues with the next chunks provided, some of which
also have already been recorded.
It can take about 10 seconds for ffmpeg to be restarted. I have not
observed a single missing chunk, not even with a two hour movie
scattered over thirty single files. There have only been overlaps.
If there was a bandwidth problem, I would expect chunks to be missing.
Since no chunks are missing even after a rather lengthy break in
recording, all chunks seem to be available on the server for more then
So what if the time between the server telling ffmpeg 'use this next
chunk' and the availability of the chunk on the server is somewhat long?
Is there a time window within which ffmpeg tries to get the next chunk,
and is that window too short? Is there an option to make that window
longer, or a place in the source where I could make it longer?
What else might cause the interruptions?
Why is ffmpeg unaware that recording has ceased and doesn´t quit when
that happens? It is silly that the control program needs to poll the
size of the output file every eight seconds to figure out if something
is still being recorded or not. Doing that isn´t really feasible,
either, because it is not guaranteed that eight seconds is always the
right polling interval.
Why doesn´t ffmpeg quit after it has been recording for the amount of
time specified with the '-t' option? For example:
ffmpeg -n -loglevel 8 -i http://example.com/foo.m3u8 -codec copy -t 00:10:00 -f
Ffmpeg does not stop after the ten minutes have passed when the
recording has stopped before that. That doesn´t make any sense because
ffmpeg obviously either figures it is still recording --- in which case
it needs to stop after ten minutes --- or it figures it is not
recording, in which case it should quit before the ten minutes have
passed, or at least when they have passed. Having it run indefinitely
is not the right choice.
So what can I do to record without interruptions, or at least without
the annoying overlaps?
ffmpeg-user mailing list
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".