FFmpeg does not remember which playlist item should run next after its process crashes. If you want a stream to continue from a deliberate point, a wrapper or supervisor must store that progress and decide whether an interrupted video should be replayed or skipped.
For a clear completion boundary, run one FFmpeg process per video and let the wrapper update a durable item index. The concat demuxer can handle a compatible ordered list in one process, but it does not provide durable playlist-position recovery by itself.
Why FFmpeg does not remember the next playlist item
FFmpeg processes the inputs you give it and exits when it reaches the end or encounters a condition that ends the process. Its concat demuxer can read a text list of files and process them one after another, but that describes how to consume a list during a run; it is not a saved checkpoint that records what a separate process should open after a crash.
That difference matters in a 24/7 channel. Suppose a playlist contains a morning prayer video, a bhajan session and a recorded local bulletin. If the FFmpeg process stops halfway through the bhajan session, FFmpeg has no independent record that says “retry this item” or “start the bulletin”. When you launch a new process, it starts from the inputs you provide to that new process.
The playlist order and the restart decision therefore belong to the application around FFmpeg. That application might be a small script, a service manager configured to run a script, or another supervisor. It chooses an item, launches FFmpeg, observes the exit, updates progress and applies the recovery policy you chose. This is a design built around FFmpeg’s documented input and process behaviour, not a built-in resume feature.
A process restart and a YouTube live event are separate concerns, too. YouTube tells encoder users to configure the live server URL and stream key in their encoder. Its help page also says that stopping content from the encoder ends the stream. A reconnect may send content again, but you should not assume it preserves the same uninterrupted viewer session or the identical live event. Check YouTube’s current live encoder guidance before relying on a particular workflow.
Choose a recovery policy before writing the wrapper
“Resume from the next video” sounds precise, but it leaves one important question unanswered: what should happen if FFmpeg fails during the current video, before it has completed? You cannot infer completion just from the fact that the process exited. A failure could happen near the beginning or close to the end, and the checkpoint alone cannot distinguish those cases unless the design records more progress.
There are two simple policies. Under a replay-current-item policy, the wrapper advances only after FFmpeg reports that the selected video finished successfully. A crash during playback leaves the checkpoint pointing at that video, so it is tried again. This avoids silently omitting an item, but viewers may see part of it a second time.
Under a skip-current-item policy, the wrapper records the following item before launching the current one. If FFmpeg then crashes, a restart begins with the following item. This reduces the chance of replaying a long video, but it can omit the current video if FFmpeg stopped before sending much or any of it. Neither policy is universally correct: a devotional station may prefer a repeat to an omission, while a tightly timed news loop may prefer to keep its schedule moving.
| Recovery policy | When the checkpoint moves | Likely result after a mid-video crash | Main trade-off |
|---|---|---|---|
| Replay current item | After a successful item exit | The interrupted item starts again | Possible repeated content; fewer accidental omissions |
| Skip current item | Before launching the item | The following item starts | Possible omission if the item did not finish |
| Track playback progress | As progress is recorded by the wrapper | Can resume nearer a recorded point, if the design supports it | More state and testing; still not a guarantee of exact-once delivery |
The third row is more involved than keeping an item index. FFmpeg output can have buffering and timing boundaries, and sending a timestamp or byte position is not the same as proving what viewers received. For many small channels, a clear replay-or-skip rule is easier to operate than a more elaborate checkpoint scheme whose edge cases are poorly understood.
Write the policy down in ordinary language before implementing it. For example: “If an item exits successfully, play the next one. If it exits with an error, wait and retry the same item.” That is much easier to inspect at three in the morning than an undocumented assumption buried in a restart script.
Store the current item durably
Keep the playlist and progress record outside the FFmpeg process. A simple design uses a stable ordered playlist and an index into it. A more maintainable design gives each item a stable identifier, so adding or reordering files does not accidentally make an old index point at a different video.
For example, a playlist record might identify morning-prayer, bhajan-session and community-bulletin in order. The checkpoint can say which identifier is selected, and the wrapper can map that identifier to a file path. The names are illustrative; choose names that remain unambiguous if a file is replaced. A filename alone can be a weak identifier if operators routinely overwrite files while retaining the same name.
Write checkpoint changes atomically. In practical terms, prepare the new value as a separate file, flush it as appropriate for your environment, and replace the old checkpoint in one operation. The aim is to avoid leaving a half-written value if the machine loses power while the wrapper is updating it. The exact durability guarantees depend on the operating system and storage, so test the method on the machine that will run the channel rather than assuming every filesystem behaves identically.
Keep the playlist itself stable while a run is in progress, or define what edits mean. If an operator inserts a video at the beginning while the checkpoint is an integer, the same number may now refer to a different item. Stable IDs help, but the wrapper still needs a rule for a removed current item: stop and ask for attention, advance to the next valid item, or mark the playlist change in a log.
Separate “selected item” from “completed item” if that makes the recovery rule clearer. A small state record could include the item ID, the last known outcome and the time of the last update. Do not treat the timestamp as evidence that the video reached YouTube; it only records what the wrapper observed. A log can explain why the state changed, while the checkpoint remains the compact value needed for the next launch.
If you are also planning programme changes rather than a fixed playlist, the wrapper has more than one state to manage: which scheduled block is active and which file within it is next. A fixed ordered list is simpler. For a schedule-driven channel, the decisions in switching between scheduled programmes are relevant, but the schedule still needs an explicit restart rule of its own.
Run one item at a time or use concat
The concat demuxer is useful when you want a single FFmpeg process to read a compatible ordered list. The FFmpeg Formats documentation says that the demuxer reads a list of files and other directives from a text file and demuxes them one after another as if their packets had been muxed together. See the FFmpeg concat demuxer documentation for the supported script format and requirements.
Compatibility is the important qualification. The files should have the same streams, codecs and time base. Differences in stream layout or unreliable duration information can cause trouble; a truncated source file, for example, may have duration information that leads to timestamp artefacts. Test the actual files and their transitions rather than assuming that videos which look alike in a media player are suitable for one concat input.
A separate FFmpeg invocation for every item gives the wrapper a natural boundary. It launches one file, waits for that process to exit, decides whether the exit counts as successful completion, records the next item according to policy, and launches again. This is often easier to reason about when durable per-video checkpointing matters. The trade-off is more process launches and a possible gap while one process stops and the next connects.
| Method | Good fit | What recovery still needs | Operational trade-off |
|---|---|---|---|
| Concat demuxer | Compatible files should flow through one FFmpeg process | A separate checkpoint and a way to generate a list starting at the chosen item | Convenient continuous input; file parameters and duration metadata matter |
| One process per item | The wrapper needs a clear success or failure boundary per video | A durable item record and a policy for failed items | Easier item-level decisions; stop and reconnect gaps may occur |
| Segment muxer and segment list | Splitting one source into output segments is the task | Playlist-level state if recovery must select a source video | Segment boundaries and bookkeeping are not a generic playlist checkpoint |
The FFmpeg FAQ describes the concat demuxer as an option when you want to avoid a re-encode and the format does not support file-level concatenation. That is a different question from where to restart a playlist after a crash. See the FFmpeg FAQ for the concat context, and keep the recovery choice in your wrapper design.
Do not confuse the segment muxer with playlist recovery. It can produce segment lists, including lists usable by the concat demuxer, but segment starts are tied to reference-stream keyframes. It is a way to split an output, not a saved marker saying which source-video item the channel should play next after a process failure.
If you are deciding whether to build and maintain a local FFmpeg setup or use a managed workflow, consider the work beyond encoding: the playlist file, checkpoint, logs, retries and overnight checks all need an owner. StreamNeo removes the need to keep your own computer running for a file-based YouTube broadcast, which may be useful if maintaining that local process is the pain you are trying to avoid; it does not change the fact that your playlist policy must be clear.
Handle exits and restart after a delay
The wrapper should distinguish a normal end of an item from an error and from an intentional stop. A successful exit can be the signal to advance under a replay-current-item policy. A non-success exit can leave the checkpoint unchanged and trigger a retry after a delay. An operator stop should stop the loop, not be mistaken for a crash that deserves another launch.
FFmpeg has an -xerror option whose documented description is “Stop and exit on error”. It can help make certain error conditions visible to a supervising process, but it does not decide what the wrapper should do next. Consult the FFmpeg command-line documentation for your installed version and place options carefully: FFmpeg options generally apply to the next input or output, so their position in the command matters.
After an unexpected exit, wait before trying again. A short fixed delay is easier to understand than an immediate restart loop. If repeated failures continue, increasing the pause between attempts can prevent a broken input or network condition from causing constant relaunches. Set a practical limit or alert condition so a channel that cannot recover does not silently cycle without anyone noticing.
Log the item ID, launch time, exit status, decision taken and next retry time. Avoid writing the stream key to logs, shared scripts or screenshots. If a key is exposed, follow YouTube’s current instructions for replacing or updating it. Keep logs useful enough to answer “which file was attempted?” and “why did the wrapper retry?” without including credentials.
For an always-on setup, the host itself can also fail, so test how the wrapper starts after a machine reboot. On a Raspberry Pi in a place with intermittent power, for instance, a process supervisor cannot make electricity continuous; the saved checkpoint is what lets the application make a deliberate choice after power returns. The practical planning in running an FFmpeg stream through Indian power cuts is relevant to that wider failure mode.
Prevent duplicate or skipped items
A checkpoint design is a choice about what to do with uncertainty, not a way to eliminate it. Consider a crash just after the video has played nearly to its end but before the wrapper records success. If the wrapper retries the item, viewers may hear or see material again. If it has already moved the checkpoint, it may omit material that never reached the stream. Neither sequence can be called exact-once playback after every crash.
Be precise about what “completed” means. A zero exit status tells the wrapper that FFmpeg ended without reporting a failing exit under the conditions it observed. It does not prove every viewer received every frame, nor that YouTube preserved the same event. If your policy advances only on a successful exit, describe it as “advance after FFmpeg exits successfully”, not “guaranteed delivered”.
Avoid two supervisors managing the same playlist. If a service manager restarts the wrapper while a separate cron job starts another copy, two FFmpeg processes might compete for the same stream key and playlist state. Arrange for one owner of the playlist loop, and make the wrapper refuse to start a second copy while an earlier instance is active. The exact locking mechanism depends on the operating system; the operational requirement is that only one process should control the checkpoint and broadcast at a time.
Also decide what happens when the playlist changes during recovery. If an item was removed, silently interpreting an old numeric index against the new order can skip or repeat unrelated content. Stable IDs and a validation step can turn that ambiguity into a visible error. It is usually better for the wrapper to stop and record “current item missing” than to guess which video was intended.
A loop that repeats the entire playlist after reaching its end is different from a crash retry. Keep these states distinct: completed playlist, item failure, operator stop and host restart. A product demo loop may want to repeat from the beginning after the final item, while a one-time news rundown may be finished and should wait for a new schedule. The advice in why a product demo loop keeps stopping can help distinguish stream stoppages from decisions about playlist order.
Test crash and restart cases
Do not first test the recovery policy during a public overnight broadcast. Make a short test playlist with distinguishable files and run it through the same wrapper, checkpoint format and launch command you intend to use. A spoken slate or visible label in each test file makes it easy to tell whether the wrapper replayed, skipped or advanced as intended.
Test a clean item completion first. Confirm the wrapper sees the expected exit, updates the checkpoint once, and selects the following item. Then stop FFmpeg deliberately partway through a file. Under a replay-current-item policy, the wrapper should select that same item; under a skip-current-item policy, it should select the following one. Record the observed result rather than relying on the script’s intended logic.
Test failure before playback as well as failure late in a file. A missing file, a malformed path or a file with incompatible streams should not cause an uncontrolled loop. Verify the retry delay, the log message and any alert or stop threshold. For concat, test the real list with the actual file formats and inspect the transition timestamps and audio at boundaries.
Finally, test the machine-level case: stop the host or simulate the closest safe equivalent, bring it back, and verify the wrapper reads the checkpoint rather than resetting to the first item. Also test an intentional operator stop to ensure it does not restart on its own. Keep a note of the policy, the command version and the results so the next person maintaining the channel can reproduce the test.
If even a small test produces unexpected repeated items or a black gap, fix that before making the stream routine. A local FFmpeg setup gives you control over commands and files, but you own the restart process and its monitoring. For a comparison of the work involved in local and managed operations, see what 24/7 streaming really costs; the right arrangement depends on whether you want to maintain the recovery wrapper yourself.
When the playlist, checkpoint policy and test are settled, choose the operating arrangement that fits the work you want to own.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I make FFmpeg restart automatically?
Use a wrapper or supervisor that launches FFmpeg, observes its exit, waits before retrying and logs the decision. Configure it to distinguish an intentional stop from an unexpected failure, and decide whether a failed item should be retried or skipped. Restarting the process alone does not restore playlist position unless the wrapper also stores that state.
Should I use the concat demuxer or one FFmpeg process per video?
Use concat when the files are compatible and you want one process to consume an ordered list. Use one process per video when a wrapper needs a simple per-item completion boundary to update a checkpoint. In either case, durable restart position is separate state that you design and test.
Will a YouTube reconnect continue the same live event?
Do not assume that it will. YouTube’s encoder guidance explains how to send a live stream, but a process restart does not guarantee the same uninterrupted viewer session or event. Check YouTube’s current help information for your channel and workflow.
Can I guarantee that no video is repeated or skipped?
Not for every crash with a simple item checkpoint. Advancing only after a successful exit can replay an item after a late failure; advancing before launch can skip one if the process fails before sending it. Choose the failure mode that suits your channel and describe the behaviour honestly.