If an FFmpeg YouTube broadcast keeps stopping, first identify which connection failed. FFmpeg's reconnect options are mainly HTTP input controls, while YouTube receives your encoder output over RTMP or RTMPS.
That distinction matters. A flag such as reconnect_at_eof may help FFmpeg reopen an HTTP source, but it does not guarantee that an RTMP(S) output will reconnect after a network drop. A dependable 24/7 setup uses separate controls for the source, FFmpeg process, output connection, host, and wider network.
How the YouTube encoder connection works
FFmpeg reads your media, encodes or copies the streams, and sends the result to a YouTube-provided ingest URL with your stream key. YouTube recommends RTMPS, which is the encrypted form of RTMP. The output side is therefore a live publishing connection, not an HTTP file download.
A typical command has an input and an output with different jobs:
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -b:v 5M -maxrate 5M -bufsize 10M \
-g 60 -c:a aac -b:a 128k \
-f flv "rtmps://your-youtube-ingest-url/your-stream-key"
The exact encoder settings must match the resolution, frame rate, media and available upload capacity. YouTube's official encoder settings recommend constant bitrate, a keyframe frequency of two seconds and a maximum interval of four seconds. For H.264, the published examples include 3 Mbps minimum and 8 Mbps recommended for 720p at 30 fps, and 5 Mbps minimum and 14 Mbps recommended for 1080p at 30 fps.
Those figures describe the stream YouTube expects to receive. They do not make a disconnected output reconnect, and they do not prove that your connection can sustain the selected bitrate. YouTube's streaming tips recommend leaving 20% upload headroom. If your video and audio total 5.1 Mbps, a connection that only manages that figure in perfect conditions leaves little room for ordinary variation.
You should also distinguish a YouTube ingest problem from a YouTube player or dashboard problem. Check the Live Control Room's stream health messages, then compare their timing with FFmpeg's log. If YouTube reports no incoming data while FFmpeg still appears to be running, the output path may be broken even though the process has not exited.
For a channel built from prerecorded files, the always-on YouTube channel guide covers the wider workflow. This article concentrates on what happens when the running FFmpeg job loses something.
What FFmpeg HTTP reconnect flags actually do
FFmpeg documents reconnect and related settings under its HTTP protocol options. They are useful when the input URL is HTTP or HTTPS and the failure occurs while FFmpeg is reading that source.
The main options have distinct purposes:
| Option | What it is intended to handle | What it does not establish |
|---|---|---|
reconnect 1 |
Retry an HTTP connection after a disconnect before FFmpeg reaches EOF | A repair for an RTMP(S) YouTube output |
reconnect_at_eof 1 |
Treat HTTP EOF as a condition for reconnecting | That every normal file ending should be restarted |
reconnect_streamed 1 |
Permit retries for streamed or non-seekable HTTP inputs | Recovery of a stopped FFmpeg process |
reconnect_on_network_error 1 |
Retry selected TCP or TLS errors during HTTP connection establishment | Recovery from a dead host or power loss |
reconnect_on_http_error 4xx,5xx |
Retry selected HTTP response codes or categories | A response to an RTMP(S) ingest rejection |
reconnect_delay_max |
Cap the delay between HTTP retry attempts | A limit on YouTube's output session behaviour |
reconnect_max_retries |
Cap the number of HTTP retries | A guarantee that the overall broadcast continues |
reconnect_delay_total_max |
Cap cumulative HTTP retry delay | A process supervisor or failover system |
respect_retry_after 1 |
Honour an HTTP Retry-After response where available |
Information supplied by an RTMP(S) endpoint |
The complete descriptions are in the FFmpeg Protocols documentation. These are input-side protocol settings, so place them before the HTTP input they belong to. For example:
ffmpeg -reconnect 1 \
-reconnect_at_eof 1 \
-reconnect_streamed 1 \
-reconnect_on_network_error 1 \
-reconnect_delay_max 30 \
-i "https://example.com/live-source.m3u8" \
-f flv "rtmps://your-youtube-ingest-url/your-stream-key"
That example shows the location and purpose of the options. It does not mean every HTTP source accepts every option in the same way, and it does not make the final RTMPS output self-healing.
Retry defaults are version and build dependent. FFmpeg's current master HTTP implementation lists a 120-second maximum reconnect delay, unlimited retry count represented by -1, and a 256-second cumulative retry-delay limit, with Retry-After handling enabled. Treat those as implementation details to verify against your installed binary, not as assumptions about an older package. Run ffmpeg -protocols, inspect ffmpeg -h, and read the documentation for the version you actually operate.
An unlimited retry count also does not mean the command will run indefinitely. A cumulative delay limit, an input protocol that does not support the option, a fatal error, an external supervisor, or a host failure can still stop the job.
Separate the HTTP input from the RTMP(S) output
There are usually two connections in a YouTube loop: FFmpeg's connection to the media source and FFmpeg's connection to YouTube. They may fail independently.
An HTTP input failure might look like repeated messages about connection resets, HTTP status codes, timeouts or end-of-file while reading the source. If the source is an endless HTTP stream, reconnect, reconnect_streamed or reconnect_at_eof may be relevant. If a server returns a temporary HTTP status, reconnect_on_http_error may be relevant, subject to what that source actually returns.
An RTMP(S) output failure produces a different problem. The YouTube connection may stop accepting data, the socket may break, TLS may fail, or the remote ingest session may disappear. An HTTP input retry flag does not change the protocol used by the output and should not be advertised as an RTMP reconnect solution.
This is the common mistake behind many answers to “FFmpeg YouTube stream reconnect options”. Someone sees a working HTTP option bundle and copies it beside an rtmps:// output. The command may still parse, but parsing is not evidence that the flag controls the final connection.
If your source is a local MP4, there may be no HTTP input at all. In that case, adding HTTP reconnect options cannot help the source. The relevant recovery questions become whether the file should loop, whether FFmpeg exits when it reaches the end, and what restarts the process after an output failure.
For a practical comparison of the media side, see the guide to bitrate ladders for long-run streams. Choosing 720p or 1080p affects the upload load, but it is separate from deciding how to restart a failed publishing process.
Check whether FFmpeg exited or the source ended
A 24/7 stream can stop for at least four different reasons that look similar from the outside:
- The HTTP source disconnected and FFmpeg is trying, or failing, to reopen it.
- The RTMP(S) output disconnected while FFmpeg remained alive or then terminated.
- The input media reached its natural end and FFmpeg exited normally.
- The process crashed, was killed, or lost its host.
Start with the last lines of the FFmpeg log. A clean message indicating end-of-file or successful completion points towards media ending. A socket, connection or protocol error points towards the output or input path. A sudden absence of logs points towards the process, machine, power or network rather than a media-loop setting.
For a local file that should repeat, configure the loop deliberately. FFmpeg's input looping behaviour and filter-based looping have different implications depending on whether you are copying streams, re-encoding, or combining several inputs. Test the exact command until it continues beyond the end of one copy of the file. Do not infer that a command is 24/7 merely because the player shows a long video.
If the process exits when the YouTube output drops, a process supervisor may start it again. That is a different layer from FFmpeg's protocol options. The supervisor needs a clear restart policy, a way to prevent several copies running at once, and logs that show why each restart happened.
A restart may create a new publishing session rather than resume the same session in a way viewers experience as seamless. Confirm the behaviour in the YouTube Live Control Room and on the public player. A command that restarts successfully is not automatically a command that preserves one uninterrupted event.
Diagnose network and power interruptions
A home broadband connection can drop while the computer remains powered. A VPS can remain reachable while a particular route to YouTube fails. A laptop can sleep, reboot, run out of storage, or lose power. These are not interchangeable faults.
Record the time of each incident and compare three sources of evidence: FFmpeg's log, the host's system log, and YouTube's stream health message. If the host clock jumps or the log stops completely, investigate the machine before changing reconnect flags. If the host stays healthy but the output socket reports a failure, investigate the route, firewall, TLS and upload connection.
Check the upload path under load rather than relying on an advertised line speed. YouTube recommends 20% headroom, and that margin should remain available after other activity on the connection. A household upload can be consumed by backups, cameras or another live stream without FFmpeg changing any setting.
Power protection and restart behaviour matter for a local machine. Disable sleep, make sure the machine can start the streaming application after an intentional reboot, and keep enough free disk space for logs and any local recording. Test this during a planned maintenance window. A restart procedure that has never been tested is only a hypothesis.
For a hosted deployment, compare the operational responsibility rather than only the monthly figure. A VPS versus cloud streaming service comparison explains why direct control can suit someone comfortable with process supervision, while a managed workflow can remove some of the routine machine work. Neither approach removes the need to test YouTube ingest and the actual recovery path.
Choose recovery controls for the actual failure
Use this sequence when a broadcast stops:
If the HTTP source drops
Confirm that the input really begins with http:// or https://. Then select the HTTP options that match the observed failure: retry a disconnect, treat EOF as a reconnect condition, allow retries for a streamed input, or retry the HTTP status codes the source returns. Keep a ceiling on delay or attempts where an endless retry would hide a permanently broken source.
If the source is a playlist or remote file that ends normally, decide whether the desired behaviour is to loop the media or fetch a new source. Reconnecting an HTTP URL is not the same as replaying a local MP4 and should not be used as a substitute for a tested media loop.
If the RTMP(S) output drops
Do not add HTTP flags and call the problem solved. Confirm what your installed FFmpeg build does when the output socket fails, whether it returns a non-zero exit status, and whether your launch method restarts the command. Validate the complete process with the YouTube stream key and an intentional network interruption.
A restart wrapper, service manager or external monitor may be appropriate, but its exact configuration depends on the operating system and deployment. It should detect a stopped or unhealthy process, apply a controlled delay, and avoid launching duplicate encoders. The output reconnect path must be tested with the same RTMPS URL, stream settings and host used in production.
If the process exits
Capture the exit code and the final log lines. Check for invalid input, encoder errors, unavailable devices, permission problems, full disks and resource exhaustion. Restarting every failure without recording the cause can turn a simple configuration error into a repeating outage.
If the media ends
Use a tested loop or a playlist design. Confirm that audio and video continue across the boundary and that timestamps remain acceptable to YouTube. If you are looping Hindi music or devotional material, the guide to looping Hindi songs in a 24/7 YouTube stream covers the content-side decisions that sit beneath the FFmpeg command.
If the host or network fails
A single process cannot restart while its computer has no power or route. Use a second tested encoder only if you can operate it without publishing competing streams accidentally. YouTube recommends testing failover by stopping the primary encoder or disconnecting its network and checking that the backup actually takes over.
Recovery also needs observability. Keep the FFmpeg log, note the YouTube health status, and alert on a process that is running without useful output. A green process list is not proof that viewers are receiving a healthy broadcast.
Build a 24/7 test plan before going live
Test the media loop beyond one complete cycle. Test the normal end of the source, a deliberately unavailable HTTP source if you use one, a YouTube output interruption, a full FFmpeg stop, a host reboot and a temporary upload outage. Perform each test separately so you know which layer responded.
For the output test, watch both the public player and YouTube's Live Control Room. Note whether viewers see a brief interruption, whether the event remains active, whether a new session appears, and how long the recovery takes. The result is specific to your command, FFmpeg build, host and network, so do not generalise it into a guarantee for another setup.
Keep a local recording if the programme matters. YouTube Help's archive guidance, checked in September 2026, says streams under 12 hours can be automatically archived, while a stream exceeding 12 hours may not be captured at all. A 24/7 broadcast therefore should not rely on YouTube as its only copy. Decide whether to split events and where the local files will be stored, and verify that storage can sustain the recording.
Before launch, write down the source URL, output URL format, stream settings, restart method, log location, alert destination and manual recovery steps. Store the stream key securely and avoid printing it in shared logs. If someone else operates the channel, give them a short runbook that starts with evidence gathering rather than repeatedly changing flags.
The central rule is simple: first name the failed layer, then choose the control that belongs to it. HTTP reconnect options are useful, but only for the HTTP input behaviours they document. They are not a universal answer to a YouTube RTMP(S) output disconnect.
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_at_eof and reconnect_streamed reconnect YouTube?
They are documented as HTTP protocol options for input handling. They may help FFmpeg retry an HTTP source, but they do not guarantee reconnection of an RTMP(S) output to YouTube after a network drop.
Should HTTP reconnect flags go before the YouTube output URL?
No. They belong to the relevant HTTP input and should be placed before that input in the command. If the input is a local file and the output is RTMPS, those flags do not address either the local file's natural end or the output connection's failure.
How can I tell whether the source ended or YouTube disconnected?
Read the final FFmpeg log lines and compare them with YouTube's stream health messages. End-of-file or normal completion suggests the media ended, while socket or ingest errors suggest a connection problem. A completely silent host may indicate a process, power or network failure instead.
Is a process supervisor enough for a 24/7 stream?
It can restart a command after an exit, but it cannot repair every source, output, host or network problem. Test whether it avoids duplicate encoders, records the cause, waits before restarting and produces the YouTube behaviour you expect after an RTMPS interruption.