-stream_loop -1 repeats a readable input when it reaches its end; it does not restart FFmpeg after a local-file error. If FFmpeg exits because it cannot read the file, recovery needs a separate process supervisor, a check of the file, and usually a known-good fallback.
Start by finding which part failed: reading the media, decoding it, or sending the output to YouTube. Those failures call for different remedies. A reconnect option aimed at an HTTP input will not repair a broken local file, and no single command guarantees that a live broadcast will recover.
Identify where the failure occurs
When a 24/7 stream stops or freezes, “the stream disconnected” is not a diagnosis. FFmpeg reads an input, demuxes its container, decodes and encodes media as configured, then writes an output. A fault at any stage can look similar from the viewer’s side, but the log and process status usually narrow it down.
Check the last FFmpeg messages, whether the process is still running, and its exit status if it has stopped. Note the timestamp and whether YouTube Studio still shows an incoming stream. An error opening the input points towards a path, permissions, or file problem. Demux or decode messages point towards the media contents or format. Write or connection errors can indicate an output problem instead.
A process that remains alive while reporting some corrupt packets is different from one that exits. Likewise, a normal end-of-file message is not automatically a failure: a finite input has simply run out of content unless you have configured it to repeat. Save stderr and the exit status before relaunching, so that a recurring cause does not disappear in a sea of restarts.
If you are troubleshooting a YouTube publishing error rather than an input problem, the FFmpeg invalid-stream-key guide covers a separate failure category. It is useful to keep that diagnosis distinct from a file read error: changing a stream key cannot make damaged media readable.
What -stream_loop -1 does
FFmpeg documents -stream_loop as an input option. A value of -1 means to loop the input indefinitely. For one local file, the option belongs before the corresponding -i, because FFmpeg options generally apply to the next input or output. For example, the command shape can begin ffmpeg -stream_loop -1 -re -i input.mp4 ....
That setting addresses a specific event: the input reaches its normal end and FFmpeg should read it again. It does not monitor the process and launch a new one if FFmpeg exits. If the file cannot be opened, the option has no healthy input to repeat. If decoding encounters an unrecoverable problem and FFmpeg terminates, -stream_loop -1 is not a restart policy.
The rest of a real command depends on the media, encoder, and destination. Treat a short command example as a guide to option placement, not as a copy-and-run publishing recipe. In particular, keep the YouTube stream key private, and use the current YouTube encoder settings for its supported ingestion protocol and encoding requirements.
A frequent source of confusion is that several separate settings can appear in one FFmpeg command. Looping governs what happens at input EOF; real-time reading affects the pace at which input is processed; encoding options shape the output. None of these, simply by being present, supervises a process after it exits. If you need automatic relaunch, that responsibility belongs outside the FFmpeg invocation.
Normal end of file versus a file error
A normal end of file (EOF) means FFmpeg has reached the end of the readable input. When an input is valid and the loop option is correctly placed, FFmpeg can begin another pass. Depending on the content, you may still see a visible or audible transition at the join; looping does not promise a seamless edit.
A file error is different. FFmpeg may be unable to open the path, may fail to parse or demux the container, or may hit a decode failure it cannot continue through. Some damaged packets can be skipped in supported inputs, but other problems prevent useful processing or make the process exit. The relevant question is not merely whether the file has errors; it is whether FFmpeg continues producing usable output.
The input flag -fflags +discardcorrupt tells FFmpeg to discard corrupted packets where applicable. It may help when a limited part of a file is damaged and the rest is usable. It does not repair a container, guarantee that the next packet can be decoded, or make an unreadable file recoverable. Likewise, -xerror and -max_error_rate affect error handling or exit behaviour; neither starts a replacement process.
If the file fails repeatedly at the same point, an endless loop can bring the same failure back on every pass. Replaying a damaged segment is not the same as recovery. Keep an intact alternate file available if continuity matters, and verify it before making it the fallback. For a useful example of how a playback loop is configured in another workflow, see OBS source settings for a long rain video; the mechanics differ, but the distinction between repeating media and recovering from a failure remains important.
Local-file failure versus HTTP input interruption
A local file is read from the machine or environment where FFmpeg runs. If the path is wrong, access is denied, the storage disappears, or the media cannot be parsed, HTTP reconnect flags are not the remedy. They apply to HTTP protocol events, not to local-file errors. First check that the path is correct and accessible, then test that the file can be read and decoded. If the file itself is bad, replace it or select a validated fallback.
An HTTP input is different: it depends on a network connection to a remote source. FFmpeg’s protocol documentation describes options for reconnecting on disconnect, at EOF, or on network errors, as well as retrying selected HTTP status codes and limiting retries. These controls are specific to HTTP behaviour and need to be chosen for the source and failure conditions. A retry limit can help prevent endless waiting, but the right policy depends on how long the source may be unavailable and what should happen meanwhile.
Do not add HTTP flags to a local-file command and expect them to catch decode failures. Nor should a successful retry of an HTTP source be read as evidence that output publishing has recovered: reading the source and writing to YouTube are separate legs of the pipeline. The FFmpeg command-line documentation describes input option scope, while the protocol documentation describes HTTP-specific reconnect options.
If you are comparing a self-managed host with a workflow that avoids leaving a computer running, the practical constraints are different. A VPS-based looping meditation stream still needs input checks, process supervision, and an output health check. Hosting somewhere else can change who operates the machine, but it does not make a failed source file healthy.
Publishing failure versus input failure
YouTube publishing happens after FFmpeg has read and processed the input. If local-file reads and decoding continue normally but the output reports a write, connection, or publishing error, investigate the destination path instead. Check the current stream key and selected ingestion settings in YouTube Studio, then compare the encoder configuration with YouTube’s current guidance. Do not expose the stream key in shared logs or screenshots: YouTube describes it as the value that lets an encoder send a feed to the channel.
For live ingestion, YouTube lists RTMP and RTMPS among its protocols and provides encoder guidance for settings such as CBR and keyframe interval. Its published recommendation is a two-second keyframe interval, not exceeding four seconds. That guidance is about the incoming stream, not a fix for a file that FFmpeg cannot read. YouTube also recommends monitoring stream health and testing the setup before relying on it.
A publisher-side interruption may require a decision about whether the same FFmpeg process can continue, whether it must be restarted, or whether YouTube Studio needs attention. The logs and Studio’s stream-health display help distinguish these cases, but neither means that FFmpeg’s HTTP input reconnect flags apply to the publishing connection. FFmpeg documents RTMP separately from HTTP; use the protocol and output behaviour actually in your command when diagnosing it.
For an unattended channel, test the path from source to destination separately: first confirm that the file reads and loops locally, then confirm that the encoder can publish to the intended YouTube event, and finally observe a planned interruption or restart. YouTube’s streaming tips recommend testing and monitoring, and advise maintaining upload capacity headroom. A healthy YouTube ingest cannot compensate for a missing input file, and a healthy local loop cannot prove the upload path will remain available.
Choose recovery by failure type
A robust recovery plan starts with classification, not with adding more flags. Use the table to choose the mechanism that matches the observed event, then decide what the channel should do if the first recovery attempt fails.
| Observed situation | Suitable response | What it does not establish |
|---|---|---|
| Valid file reaches normal EOF | Put -stream_loop -1 before its -i input |
Recovery from an unreadable file or an exited process |
| Some corrupted packets, but processing continues | Consider -fflags +discardcorrupt and inspect the resulting output |
Repair of the file or guaranteed continued decoding |
| FFmpeg exits on a local-file failure | Use an external supervisor with a delay, logs, validation, and a fallback | That FFmpeg itself will relaunch or that the same file is now usable |
| HTTP source disconnects | Configure appropriate HTTP reconnect and retry options | Local-file recovery or recovery of YouTube publishing |
| YouTube output becomes unhealthy | Inspect output errors, Studio health, key, and encoder settings | That a working input file will be restored |
If FFmpeg exits, an operating-system service manager or wrapper can record the exit, wait a bounded period, check the file, and launch a new process. The exact syntax depends on the operating system and supervisor; there is no universal restart command that has been verified here. A useful policy is to avoid rapid repeated launches: after a failure, preserve the stderr and exit status, run a preflight check, and only restart with the original file if it is readable. If it remains broken, select a known-good fallback or stop and alert someone rather than replaying the same failure indefinitely.
For an always-on devotional, ambience, or study channel, a fallback need not resemble the main programme, but it should be suitable to publish and already checked. Make the choice explicit: pause and notify, switch to a safe holding loop, or retry after a human repairs the source. A recorded-video 24/7 streaming tools overview may help frame the broader operating choice, but a tool choice does not remove the need to define what happens when an input fails.
When a machine is expected to run unattended, -nostdin can prevent FFmpeg from waiting for terminal input in a background invocation. The FFmpeg FAQ also describes redirecting standard input. This closes one operational gap only; it does not implement restart logic, validate a media file, or alert you when output stops. Add a separate monitoring and escalation path if a missed broadcast would matter.
If the maintenance burden of checking a machine overnight is the specific problem, StreamNeo removes the need to keep your own computer running for an uploaded-video broadcast. It does not change the need to supply a usable file or check that the YouTube channel and content are ready.
Test the loop and review logs
Test the same file, command shape, and input option placement you intend to use for the live run. Confirm that the file opens, reaches EOF, and starts another pass. Watch both sound and picture across the join; a loop that technically restarts can still produce an awkward black frame, a pause, or an audio discontinuity. If the input should be continuous, edit or replace it rather than assuming the loop flag will hide the join.
Then test failure handling separately. Use a disposable copy or a controlled test environment rather than damaging the only production file. Confirm that a missing or unreadable input produces a log and exit status your supervisor can capture, that the supervisor waits before retrying, and that a fallback is selected or an alert is raised according to policy. Do not test by repeatedly restarting against the same known-bad file and calling the result recovery.
Keep a record of the command configuration, the input filename, timestamps, stderr, process exit status, and whether YouTube Studio showed an incoming stream. Avoid recording the stream key in a shared diagnostic file. This makes it possible to see whether the failure repeats at a particular timestamp or packet, whether the process exited, and whether the publisher rather than the input stopped.
Finally, verify the YouTube side with a private or otherwise appropriate test event before depending on the workflow for a scheduled channel. Check the preview and stream-health notices, and confirm the archive or replay behaviour you expect. YouTube’s advice to test and monitor is not a guarantee against interruption, but it can expose a configuration issue before viewers rely on the stream.
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
Does -stream_loop -1 restart FFmpeg after a file error?
No. It repeats an input at normal EOF; it does not launch another FFmpeg process after an error or exit. Use a supervisor to handle process exit, and check or replace the file before trying again.
Can HTTP reconnect flags fix a local video file?
No. Those flags address HTTP protocol connections and retry cases. A local file that is missing, inaccessible, or not decodable needs a file-level check, repair, replacement, or fallback.
Should I use -fflags +discardcorrupt?
It may help FFmpeg skip corrupted packets in supported inputs, but it cannot repair every kind of damage. Test whether usable video and audio continue, and do not treat the flag as a substitute for a known-good file.
How can I tell whether YouTube publishing failed instead?
Look for FFmpeg output or connection errors and check whether YouTube Studio still shows an incoming stream and reports stream health. If the input continues to read and decode, investigate the output configuration and destination separately rather than changing local-file recovery settings.