A reconnect flag is not a universal fix for FFmpeg errors: the right response depends on the input protocol and whether the failure happened while connecting, midstream, at EOF, or after an HTTP status response. First capture the full error and your FFmpeg version; only then decide whether HTTP-specific retry options apply.
This guide is about diagnosing a continuously available education source that you are recording. It does not assume a particular source URL, format, FFmpeg build, or error, and the example command is illustrative rather than tested against your setup. A successful input reconnect also cannot keep recording if the FFmpeg process exits or the destination runs out of space.
Start with the input protocol and failure point
Look at the scheme at the start of the input URL, without sharing any password, token, or private query string. An http:// or https:// URL identifies an HTTP input; rtsp:// and srt:// identify different protocols, and a local filename is not a network input at all. The options in this article concern FFmpeg’s HTTP protocol. They should not be carried over to RTSP, SRT, or another protocol unless its own documentation and your installed build support the relevant settings.
Next, establish where the failure occurs. Does FFmpeg fail to open the URL before it receives media? Does it begin recording and then lose the connection? Does the log report end-of-file while you expected an endless feed? Or does the source return an HTTP status such as an access error? Those cases can look alike in a short console excerpt, but they are not the same event and do not call for the same retry behaviour.
A source that plays a finite lecture and reaches its natural end may be working correctly. A live classroom feed or endless playlist that returns EOF unexpectedly may need different handling. Likewise, an authentication rejection is unlikely to be cured by repeatedly requesting the same resource. Keep the source type in mind: finite or endless, seekable or streamed, and whether a reconnect can resume useful material.
If you are also deciding where the long-running process should live, the practical trade-offs between a Windows VPS and Linux VPS for 24/7 YouTube streaming in India are separate from the input retry question. A different machine does not make an HTTP flag applicable to another protocol, but a stable operating environment may simplify monitoring and storage.
Capture the full error and FFmpeg version
Before editing a command, save the complete error context. Keep the invocation with any secrets redacted, the lines immediately before and after the failure, the input URL scheme, and the point at which recording stopped. A single phrase such as “connection reset” may omit whether it occurred during connection setup or after media had been read.
Run ffmpeg -version in the same environment that runs the recorder and retain its output. Packaged builds can differ in version and enabled options, so the command available on a workstation may not match the one on a VPS or container. If you use a wrapper or scheduled task, check the executable it actually launches rather than assuming the shell’s default binary is the same.
Do not post a complete URL if it contains a signed token, credentials, or a private course identifier. Preserve the scheme and useful host/path shape while replacing sensitive values. For example, https://user:[email protected]/live?token=abc should be redacted before sharing; the important diagnostic fact is that the input is HTTPS, not the credential.
Record whether the process remains alive after the error. If FFmpeg logs a retry and continues, you are looking at input recovery. If the process returns to the shell, restarts are a separate concern: an operating-system service manager or supervisor may be needed, but FFmpeg’s HTTP retry options alone do not provide that process-level recovery. The distinction matters for an overnight recording, where a process that exits quietly can leave a gap even if the next manual run works.
Select HTTP reconnect options by symptom
For an HTTP source, FFmpeg documents several options for different failure conditions. The project’s HTTP protocol documentation describes reconnect for reconnecting when disconnected before EOF. That is the likely option to investigate for a midstream disconnect, not a blanket setting for any error printed by FFmpeg.
reconnect_at_eof is different: it treats EOF as an error and causes a reconnect, and the documentation identifies live or endless streams as a use case. Consider it only when EOF is genuinely unexpected for the source. If a finite recorded lesson is supposed to end, forcing a reconnect can instead produce repeated requests that accomplish nothing.
For a streamed or non-seekable HTTP input, reconnect_streamed extends reconnect behaviour to that kind of input. When the failure is specifically a TCP or TLS error during connection establishment, reconnect_on_network_error is the more targeted HTTP control to check. These options address distinct situations; adding all of them without matching the log evidence makes it harder to understand what changed.
An HTTP response failure is another case. reconnect_on_http_error accepts particular status codes or groups such as 4xx and 5xx. Broadly retrying 4xx deserves care: a client error can indicate a malformed request, an expired token, or missing access, and retrying does not repair those conditions. Check the source’s response and request requirements before expanding a status list.
FFmpeg also documents respect_retry_after, which honours a server’s Retry-After response header instead of its exponential backoff; the HTTP documentation says it is enabled by default and notes its relevance to responses such as 429 and 503. If the source is asking the client to wait, that response is part of the diagnosis, not noise to bypass by retrying more aggressively.
Retry delay and count controls set a budget rather than promising uninterrupted recording. The HTTP options include reconnect_delay_max, reconnect_max_retries, and reconnect_delay_total_max. The FFmpeg 8.1 source lists defaults of 120 seconds for maximum delay, no set maximum retry count, and 256 seconds for the total delay maximum, with Retry-After enabled. Those are defaults for that source version, not a guarantee for your binary or a reliability statistic. Confirm the options and defaults in the version you run.
Separate connection, midstream, EOF and status failures
Use the log sequence to place the error in a category before selecting an option. The table maps common evidence to the next question. It is a diagnostic aid for HTTP inputs, not a command prescription; on another protocol, consult that protocol’s documentation instead.
| Failure point | What to establish | HTTP control to investigate | What not to assume |
|---|---|---|---|
| Connection attempt | Did TCP or TLS fail before media arrived? | reconnect_on_network_error |
That every DNS, access, or URL problem is transient |
| Midstream disconnect | Had FFmpeg already read media before the connection dropped? | reconnect |
That the recording will resume without a gap |
| EOF | Is the source meant to be endless, or did a finite file finish? | reconnect_at_eof for an endless source; reconnect_streamed may be relevant to streamed input |
That EOF always means a fault |
| HTTP response | Which status code did the server return, and is the request valid? | reconnect_on_http_error for deliberately selected codes or groups |
That repeatedly retrying a 4xx fixes access or request errors |
A disconnect can leave a gap in the recording even when FFmpeg reconnects. Whether the missing interval can be recovered depends on the source and whether it serves earlier media again; do not infer that a retry means continuous, complete capture. If the output is intended to be a single uninterrupted file, inspect its timestamps and playback after recovery rather than relying only on a “reconnected” log line.
If the failure is an HTTP status, check the URL, access, and source behaviour before changing retry policy. If it is EOF, verify the source is actually supposed to continue. If it is connection setup or midstream loss, inspect the surrounding network and source status as well as the relevant HTTP option. The error category narrows the next experiment; it does not identify the root cause by itself.
Check the installed build and option placement
Even a correctly chosen option will not help if the executable does not recognise it or if it is attached to the wrong input. FFmpeg’s command-line documentation explains that options generally apply to the next input or output and reset between files. Place HTTP protocol options before the corresponding -i URL. Output selection and recording options follow the input they affect.
Inspect the help available from the exact binary and its version-specific protocol documentation. If an option is reported as unknown, do not silently remove it and assume the rest of the command now handles the failure. Confirm whether your package supports it, update only through a source you trust if appropriate, and retest the precise command with the same input type. Build capability can vary, so a reference to a newer option is not proof it exists in your packaged version.
An illustrative shape for an HTTP input is:
ffmpeg \\
-reconnect 1 \\
-reconnect_streamed 1 \\
-reconnect_delay_max 30 \\
-i 'https://stream.example.invalid/live.m3u8' \\
-c copy recording.ts
This is not a universal fix or a tested recipe for your input. The delay value is illustrative, and the example does not include reconnect_at_eof, because that belongs only in an EOF case where an endless source should continue. Add network-error or HTTP-status handling only when the observed failure supports it. If there are multiple inputs, verify which options precede each -i; placement after an input may not configure that input.
For a prerecorded lesson being sent onward to YouTube, input capture and the YouTube output are two different legs. Fixing an HTTP source retry does not configure the encoder or destination. The guide to streaming prerecorded videos to YouTube Live with OBS on Windows 11 covers a different path and can help keep source recording questions separate from broadcast configuration.
Test a cautious recovery workflow
Start by preserving the original command and output location. Make one change at a time in a controlled test window, using an input you are permitted to access. First confirm that the source works without added retry options and note how the failure appears. Then test the one option that corresponds to the evidence: for example, HTTP reconnect for a midstream disconnect, not reconnect_at_eof by habit.
Decide the retry budget deliberately. A higher retry count or longer delay may keep a process waiting through a temporary outage, but it can also leave a broken or unauthorized request spinning for longer. Check the installed version’s delay and total-delay behaviour, including the server’s Retry-After response where applicable. There is no universal number of retries that makes a 24/7 recording reliable.
Monitor both the process and the resulting file. Check whether FFmpeg remains active, whether the output grows, whether timestamps and audio/video continue, and whether storage is available. If the process exits, a separate supervisor can restart it, but make that a deliberate operational layer: ensure it does not launch overlapping writers or overwrite a file that is still being recovered. FFmpeg’s input reconnect controls are not a full process supervision, retention, or storage design.
Keep recordings on a destination with enough capacity for your bitrate and retention plan. An external drive can help with local retention, but it cannot fix an input disconnect; estimate space from the actual output rate and how long you keep files rather than choosing a capacity by guesswork. Back up or rotate old recordings if losing earlier lessons would matter. If you are sending the same recorded material to a live destination rather than merely capturing it, distinguish that workflow from source-side recording; continuous recorded church sermons on YouTube discusses a broadcast use case, not a repair for HTTP input errors.
Keep a short incident note with the timestamp, failure category, FFmpeg version, option changed, and result. That record makes it possible to roll back an ineffective change and compare later incidents without treating one successful reconnection as proof that the setup is fixed. If the source is not HTTP, note its actual protocol and investigate its own reconnect behaviour instead of reusing this HTTP example.
When the same input error continues after the targeted option is confirmed, return to the source and the complete log. The server may be ending sessions, rejecting a request, or providing media in a way the client cannot resume. More retries can lengthen the wait without solving any of those causes. An education stream needs a recovery plan for gaps and process exits as well as an input flag.
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 -reconnect 1 fix every FFmpeg reconnect error?
No. It is an HTTP protocol option for reconnecting after a disconnect before EOF, and it does not establish that an RTSP, SRT, or other protocol failure will be handled. Identify the protocol and failure stage first, then check the installed build’s documentation.
Should I add -reconnect_at_eof to every live recording?
Only consider it when EOF is unexpected because the HTTP source is intended to be live or endless. For a finite lecture, EOF may be the correct completion signal, and forcing reconnection can repeatedly request a source that has already ended.
Why does FFmpeg still stop after a reconnect attempt?
An input retry and a process restart are different mechanisms. The process may exhaust its applicable retry behaviour, encounter another error, or exit; if it exits, a separate supervisor may be needed, alongside checks for output space and file integrity.
What should I share when asking for help?
Share the redacted command, the complete relevant error lines, ffmpeg -version, the input URL scheme, and whether failure occurred before media, midstream, at EOF, or after an HTTP status. Remove passwords, tokens, and private identifiers while retaining enough context to establish the protocol and failure point.