If FFmpeg is reading a direct HTTP media stream, start by matching reconnect options to the point where it failed: use -reconnect 1 for a disconnect during transfer, and add -reconnect_streamed 1 for a streamed or non-seekable input. Put these input options before the relevant -i; they do not repair every failure in a broadcast to YouTube.
A YouTube watch-page URL is not itself a direct media URL. If your command uses yt-dlp or another extractor, first find out whether extraction, downloader hand-off, or FFmpeg's resolved media input is where the freeze occurs.
Identify what FFmpeg is reading
Before changing flags, identify the input that FFmpeg actually opens. It might be a direct HTTP media URL, an HLS or DASH playlist, a local file, a pipe supplied by another process, or a URL first resolved by an extractor. Those cases do not all expose the same failure to FFmpeg's HTTP protocol handler.
A direct media URL points to media data or a media playlist that FFmpeg can read using its supported protocols. A YouTube watch page is a web page containing a player and references, not a direct media stream. A downloader such as yt-dlp may interpret that page, select or resolve media, and either pass a URL to FFmpeg or feed it media another way. That extra step changes where a stall can occur.
Look at the full command, not just the words “YouTube stream”. Find each -i and note what immediately precedes it. If the input is a URL, determine whether it is the original watch page or a URL resolved by another tool. If input comes from standard input, a named pipe, or a downloader process, reconnecting FFmpeg's own HTTP input may not affect the upstream reader.
This distinction is useful even when the visible symptom is identical. A devotional playlist that pauses because a source URL stopped sending bytes is a different problem from a yt-dlp process that has not produced bytes, or an FFmpeg process that has stopped writing to YouTube. The remedy follows the stage, not the appearance of the player.
For broader context on choosing a continuous-file workflow, see streaming an archive to YouTube Live with FFmpeg. That workflow question is separate from the HTTP input's reconnect behaviour, but it helps make clear which part of a long-running job is responsible for reading and which part is responsible for broadcasting.
Work out where the failure happens
“Freezes” describes what you see, not what FFmpeg encountered. The picture can stop while FFmpeg remains alive, while it waits on an input read, after a source reports EOF, or while the output side is unable to send packets. A reconnect flag is only useful if the failure matches the condition that option handles.
Start with the FFmpeg log around the first pause. Look for a read error, a connection attempt, a reported EOF, an HTTP status code, or continued packet output. Record timestamps and whether the process is still running. If an extractor is involved, capture its messages as well; the first failing component matters more than the last visible symptom.
A practical way to sort the evidence is to ask whether the connection had already opened. If the source was delivering data and then the read failed, that suggests a mid-transfer disconnect. If opening the connection failed before media arrived, that points to connection setup. If the server returned an HTTP response, inspect its status. If FFmpeg says it reached EOF, decide whether that is expected for a finite file or unexpected for a live input.
Also check whether bytes or packets continue moving. A player can appear frozen because of buffering or a downstream issue even while FFmpeg reads input and writes output. Conversely, a command can remain on screen without making progress. Neither observation alone proves a particular cause, so use the logs and, where practical, compare the input and output progress.
The distinction between process restart and protocol retry matters for unattended operation. A process manager can relaunch FFmpeg after it exits, but it does not necessarily reconnect a still-running process waiting on a stalled input. The article on using systemd to restart an FFmpeg stream after a server reboot covers the separate restart layer; first establish whether your current process exits or remains stuck.
Put HTTP reconnect options before -i
For a direct HTTP input, a starting pattern is:
ffmpeg -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 30 -reconnect_max_retries 10 -i 'HTTP_MEDIA_URL' -c copy output.mkv
The example is illustrative, not a universal setting or a guarantee. The values 30 and 10 are tuning choices for a maximum delay and retry count, respectively. Adjust them to the job, and confirm that your installed FFmpeg recognises the options. This example reads an HTTP media URL and writes to a local file; adapt the output for your actual broadcast command without assuming input flags fix output-side trouble.
FFmpeg options are interpreted in relation to inputs and outputs. The reconnect options shown here configure the HTTP input, so place them before the -i that introduces that input. Putting them after -i can mean they no longer configure the input you intended. If a command has more than one input, keep each input's options immediately before its own -i and check the resulting command carefully.
-reconnect 1 asks the HTTP protocol handler to reconnect automatically after a disconnect before EOF. -reconnect_streamed 1 permits reconnects for streamed or non-seekable input, where seeking back to a position may not be possible. For a direct HTTP live feed, those may be the relevant pair, but the source's protocol and behaviour still matter.
Do not add every available flag by habit. The FFmpeg protocol documentation describes the HTTP options and their roles. It is the right place to check exact behaviour against the FFmpeg build you use. The online documentation can describe a newer build than the one installed on an older machine or a managed environment.
If you want the process to survive a particular source interruption, test with that source and inspect the log before relying on the command overnight. A small controlled test lets you see whether FFmpeg retries, how long it waits, and whether the source resumes at a useful point. It cannot prove that every future interruption or failure will be handled.
Set retry limits to fit the job
Reconnect behaviour has a cost: retrying can keep a job alive through a temporary interruption, but it can also leave a broken job waiting for a source that will not recover. Choose limits based on what you want the process to do when the source stays unavailable.
| Option | What it limits or changes | When to consider it |
|---|---|---|
-reconnect_delay_max |
Maximum reconnect delay | Bound an individual wait while allowing repeated attempts |
-reconnect_max_retries |
Number of reconnect attempts | Stop after a defined number of tries |
-reconnect_delay_total_max |
Total reconnect delay budget | Bound the accumulated waiting time |
FFmpeg documents these as separate controls; one does not substitute for the others. A maximum delay can cap how long an individual back-off wait grows, while a retry count caps attempts. A total-delay ceiling instead limits the time spent waiting across retries. Check the documentation for details and option availability in your version.
Think about the job's purpose. A one-off conversion that should finish promptly may need a smaller wait budget and a clear failure signal. An unattended station may be intended to keep trying through temporary network problems, but an unlimited or overly generous wait can conceal a source that has been removed or changed. There is no single retry count that suits both cases.
Consider what happens after the limit is reached. Does a supervisor restart the command? Does someone receive an alert? Is it better to stop and let an operator investigate? A retry policy is only one part of recovery. If a restarted process begins from the start of a playlist or file, that may create a repeated segment; if it does not restart, the channel may remain silent. Plan the behaviour rather than copying values from an unrelated example.
If FFmpeg reports an unknown option, do not keep trying spelling variations in a live command. Note the version with ffmpeg -version, then consult documentation matching that build or its package. The FFmpeg HTTP implementation reference is another primary reference for the HTTP options, but it is specifically a reference for that version and does not establish what an older customised binary supports.
Treat EOF differently for live and finite inputs
End-of-file is not the same thing as a dropped connection. A finite video normally has a genuine end, and stopping there is expected. A live or endless source may occasionally report EOF when the reader needs to reconnect, but whether that is appropriate depends on how the source behaves.
For a genuinely live or endless HTTP input, you can test -reconnect_at_eof 1 before its -i. The option treats EOF as a condition for reconnecting. Do not add it casually to a finite video: FFmpeg may attempt to reconnect after normal completion, which changes the intended end of the job.
For example, a radio station's live HTTP feed may be designed to continue producing media, so an EOF caused by a transient interruption could be worth treating as recoverable. A finished music video, a recorded sermon, or a local file has an ordinary end. In those cases, EOF is not evidence that the network failed and reconnecting may result in confusing retries rather than a clean finish.
If your channel plays a finite set of files continuously, make the loop or playlist logic explicit. Reconnecting a media input after EOF is not automatically the same as starting the next file, returning to the beginning of a playlist, or maintaining a continuous broadcast. The guide to rotating videos with an FFmpeg playlist file is relevant when the intended behaviour is to move between files rather than reconnect one HTTP source.
Use the log to confirm what FFmpeg called the condition. If it reports EOF, ask whether that is expected for this source and whether its endpoint is documented to remain live. If the stream ends at a predictable time, a retry can mask normal completion; if it unexpectedly ends, consider whether the source provider or upstream process stopped. Treating EOF as a reconnect signal is a policy choice, not a general freeze fix.
Separate connection setup from HTTP responses
A failed connection can occur before FFmpeg has opened the media stream. TCP or TLS connection-establishment errors are a different stage from a transfer that breaks after bytes have begun arriving. For the setup case, FFmpeg documents -reconnect_on_network_error 1. Consider it when logs show connection establishment failures; it is not a catch-all for mid-stream freezes.
An HTTP error is different again: the server accepted a request and returned a status. -reconnect_on_http_error can be scoped to status codes or classes, such as 5xx, when retrying those responses makes sense for the source. A temporary server-side error might justify a retry, while an authentication, missing-resource, or request error may persist until the URL or access is corrected. Check the actual status before deciding.
Avoid broad retries for every status without knowing why the server responded. Retrying a permanent error can make logs noisy and delay an actionable fix. If a URL has expired, for example, reconnecting repeatedly does not refresh it. If access is denied, a retry does not supply credentials. Use the narrowest condition that matches evidence and is supported by your FFmpeg version.
The HTTP options belong to the input-reading side. A YouTube broadcast also has an output connection and stream key, and an error there needs output-side diagnosis. If FFmpeg continues reading packets but reports trouble sending output, changing the HTTP input's reconnect flags is unlikely to address that. For a broader decision about encoding and process choice, see OBS or FFmpeg for a continuous YouTube Live channel.
Keep watch-page extraction separate from media input
If your command contains a YouTube watch-page URL, do not assume FFmpeg's HTTP reconnect options apply to it as though it were a direct media URL. An extractor such as yt-dlp may accept the watch URL, inspect it, resolve media formats, and then either invoke FFmpeg or provide media to another stage. The failure can happen before FFmpeg receives an input it can read.
The yt-dlp project documentation and its FAQ describe YouTube URL handling and FFmpeg use. They do not tell you which exact process chain your command uses. Capture the complete command and logs from the beginning, including extractor output and any downloader invocation, then establish whether FFmpeg receives a direct media URL, an HLS or DASH playlist, a pipe, or something else.
When the extractor launches FFmpeg as an external downloader, its own retries and FFmpeg's input options may apply at different points. When media is streamed through standard input, FFmpeg is reading a pipe rather than opening the original watch page. In both cases, changing an HTTP protocol option on FFmpeg may have no effect on a failure that occurred earlier in extraction or downloading.
A useful diagnostic sequence is to test each stage separately where practical. Confirm that the extractor resolves the URL, confirm that the resolved media can be read, and then inspect the broadcast output. Keep the command line and timestamps together so you can tell whether the stall started before FFmpeg launched, during input reading, or while sending to YouTube. Avoid sharing private stream keys in logs or support requests.
This is also why a symptom such as “it worked yesterday” is not enough to select a flag. The watch page may still be available while a selected media URL has changed, an extraction step may fail, or the output connection may be the part that stalled. Diagnose the current failure stage rather than treating the original URL as the input FFmpeg necessarily sees.
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
Do reconnect flags fix every FFmpeg freeze on YouTube Live?
No. The HTTP reconnect options are for particular input-side HTTP failure modes, such as a disconnect during transfer or certain connection and response errors. They do not guarantee recovery from output-to-YouTube problems, encoder stalls, extractor failures, or a player-side pause.
Where should I put -reconnect 1?
Put it before the -i for the HTTP input it should configure. If your command has multiple inputs, place the relevant options before the matching input rather than assuming they affect every URL in the command.
Should I use -reconnect_at_eof 1 for a video file?
Usually not when EOF means the finite video has completed normally. That option is intended for cases where treating EOF as a reconnect condition fits a live or endless input, and it can make a finite source retry after its expected end.
What should I check if the input is a YouTube watch URL?
Find out whether an extractor such as yt-dlp resolves the watch page and how it passes media to FFmpeg. Inspect logs from the extractor and FFmpeg so you can distinguish extraction, input reading, and output failures.