When an FFmpeg YouTube livestream keeps disconnecting, first find out whether FFmpeg is losing its source input or YouTube is losing the publishing connection. The reconnect settings that work depend on which side failed: FFmpeg’s familiar HTTP reconnect flags are not a universal fix for RTMP or RTMPS output.
Record the exact error, the protocol used by the failing connection and the time it occurs before changing settings. A source that ends or stalls calls for a different investigation from an encoder that cannot reach YouTube’s ingest endpoint.
Identify which side is disconnecting
An FFmpeg command has at least two network-facing jobs: it reads media from an input and sends encoded media to an output. Either side can fail. A local file can also be an input, and the encoder itself can stall even when neither network endpoint has disconnected.
Start by noting what continues to work when the problem appears. Does FFmpeg report that it cannot read packets from the source, or does it report an error while writing to the YouTube destination? Does the local recording continue to grow? Does YouTube Live Control Room show that it stopped receiving data, or does its preview remain healthy while FFmpeg reports an input error?
These clues are more useful than the generic word “disconnect”. If a network camera or remote playlist stops supplying packets, the output may be fine but have nothing to publish. If FFmpeg continues reading and encoding while writes to YouTube fail, focus on the publishing path, destination and upload connection instead.
For a local file loop, check whether the loop actually continues and whether the process remains alive. A file reaching its end is not automatically a network disconnection. If you are building a prerecorded-video channel, the practical setup questions in software for playing prerecorded videos continuously can help you separate playback behaviour from publishing behaviour.
Make one change at a time and keep a short log: timestamp, FFmpeg message, input protocol, output protocol, and what Live Control Room displayed. Redact the stream key before saving or sharing a command. This gives you a before-and-after comparison and avoids mistaking a temporary recovery for a fix.
Read the error and identify the protocol
The error text matters, but it only makes sense alongside the URL scheme on the side that failed. http:// and https:// indicate HTTP input or output. rtmp:// and rtmps:// identify RTMP-family publishing destinations. A message about a read, write, timeout, EOF or TLS negotiation points to different parts of the path; none alone proves the root cause.
Run ffmpeg -version and keep the output with your notes. Builds differ, and an option present in one build may not be accepted in another. For the installed build’s HTTP options, inspect ffmpeg -h protocol=http; for a case-specific diagnosis, keep the complete command with credentials removed and the full error context around the failure.
Look at whether the error occurs during input reading or output writing. If the command has several inputs or outputs, identify which URL belongs to each one. A message mentioning an HTTP input does not explain why an RTMPS output later failed, and an RTMP write error is not evidence that an HTTP input flag will help.
FFmpeg’s protocol documentation describes options by protocol. Read the section for the protocol in the failing part of your command, rather than copying a flag from an example that happens to contain the word “reconnect”. The documentation supports a protocol-level diagnosis; it cannot tell you why a particular connection dropped without the actual build, command and logs.
What HTTP reconnect flags do—and do not do
The flags often suggested in forum answers—reconnect, reconnect_streamed, reconnect_at_eof and related options—are documented as HTTP protocol options. They can be relevant when FFmpeg reads an HTTP stream that disconnects. They do not become a general-purpose switch that reconnects an RTMP or RTMPS publishing output to YouTube.
In the HTTP context, reconnect concerns reconnecting after a disconnect before the end of the resource. reconnect_streamed extends applicable reconnect behaviour to streamed or non-seekable inputs. reconnect_at_eof can treat EOF as an error, which may suit a live or endless HTTP source that unexpectedly ends. Other documented HTTP options cover reconnecting on network errors, retry counts and delay limits. Their usefulness depends on the input and the FFmpeg version.
That scope has practical consequences. If your input is an HTTP radio stream that drops, HTTP reconnect options may be worth investigating against the installed build’s help and the FFmpeg documentation. If the failing connection is the RTMPS output to YouTube, adding HTTP flags to the command is not a protocol-appropriate answer. It can leave the real failure untouched and make later troubleshooting harder.
Do not assume that reconnect_at_eof is desirable for every source. EOF may mean the file or stream ended normally, and treating that as an error can change what the command does. First establish whether the input is meant to be continuous and what a clean end should mean for your workflow.
There is no responsible universal command to offer without the FFmpeg version, complete command with secrets removed, input scheme and exact error. If you are using FFmpeg to build a prerecorded loop, compare its playback design with looping property tours with FFmpeg on Linux, while still diagnosing the publishing connection separately.
Check the YouTube URL and stream key
For a publishing failure, open the relevant stream in YouTube Live Control Room and compare the destination and key with the values in your FFmpeg command. Copy the current values rather than relying on a saved command from an earlier broadcast. YouTube explains how to set up an RTMPS stream and how to manage live stream settings.
Use the RTMPS URL YouTube provides when your encoder supports it. Check that the scheme is rtmps:// if you intend to use RTMPS, and do not casually change the host, path or port. If YouTube has given you a specific endpoint, use that exact endpoint. A timeout may lead you to recheck reachability and the address; an SSL or TLS error makes the scheme and connection negotiation especially relevant. Neither error should be “fixed” by guessing a different destination.
Treat the stream key like a password. Do not paste it into a public forum, screenshot, article or support request. If someone else has seen it, replace it in YouTube Studio and update the encoder. When asking for help, replace the secret with [REDACTED] but retain the URL scheme and enough command structure to show which protocol is in use.
Check that the key is for the stream you intend to run and that the selected stream is ready to receive the encoder. A valid-looking key copied from another channel or event will not publish to the intended destination. For a step-by-step guide to finding the credential, see where to find your YouTube stream key in Studio in India.
Verify RTMPS and encoder settings
After confirming the destination, compare the encoder’s actual output with YouTube’s current recommendations. The YouTube encoder settings page covers accepted transport, video and audio codecs, bitrate guidance, frame rate, rate control and keyframes. Use its current table for the codec, resolution and frame rate you are sending; do not treat a bitrate example as a diagnosis of every disconnect.
YouTube recommends constant bitrate (CBR) and a keyframe interval of two seconds, with a maximum interval of four seconds. These settings help your encoder match the ingest guidance, but they cannot correct an unreliable source, an incorrect stream key or a poor network path. Verify what FFmpeg is actually producing rather than assuming the command’s intended values are what the output contains.
Compare the selected video codec, audio codec, resolution and frame rate with the current YouTube guidance. Then compare the target bitrate with both YouTube’s recommendation for that combination and the sustained upload capacity available to the encoder. A setting can be valid on paper and still be too demanding for a connection that fluctuates, especially when other devices share the upload.
| Check | What to compare | What a mismatch can tell you |
|---|---|---|
| Destination transport | YouTube-provided RTMPS URL and the scheme in FFmpeg | The encoder may be targeting a different endpoint or negotiating the wrong protocol. |
| Stream key | Current key in Live Control Room and the value in the command | A stale or mismatched key can prevent publishing to the intended stream. |
| Rate control and bitrate | CBR and the current YouTube guidance for codec, resolution and frame rate; also sustained upload capacity | The stream may exceed available upload capacity, or the encoder may not match the recommended configuration. |
| Keyframes | Two-second recommendation and four-second maximum | A different interval may not match YouTube’s encoder guidance. |
| Local output | CPU load, packet flow and recording progress, if enabled | A stalled encoder or input can look like an ingest problem from the viewer’s side. |
The figures in the table are checks, not guarantees. YouTube’s recommendations can change, and your actual connection can vary during the day. For more on distinguishing encoder pressure from other symptoms, use the OBS encoder lag troubleshooting guide as a separate diagnostic reference; its OBS-specific steps are not FFmpeg settings.
Test recovery and monitor stream health
Test with the same file, command, network connection and intended stream settings before relying on the channel overnight. Start a private or unlisted test stream if that suits your workflow, and watch both the FFmpeg console and YouTube Live Control Room. Check for recurring output errors, warnings, dropped data or a change in stream health. A process that remains open is not proof that viewers are receiving a healthy picture and sound.
If you have a local archive enabled, confirm that its size continues to increase during the test and inspect the saved video afterwards. That helps tell whether FFmpeg is still reading and encoding locally when the YouTube preview stops. Listen to audio and watch video for several minutes; a green status indicator alone cannot confirm that the content itself is usable.
Test a recovery path deliberately, not during a valuable broadcast. YouTube’s live streaming tips describe testing failover, including stopping a primary encoder or disconnecting Ethernet and checking whether playback moves to a backup. If you do not have a backup encoder configured, do not assume a restart will make a brief interruption invisible; verify what viewers see and how your stream is configured to resume.
Keep a simple incident record for each test: start time, failure time, FFmpeg version, redacted command, relevant errors, Live Control Room messages and whether the local archive continued. If the stream fails only on one network, compare another reliable connection if available. If it fails at the same source timestamp, inspect that input or media segment. Change one variable at a time so that a successful test tells you something.
For a channel that should continue while your own computer is off, repeated local restarts are a real operational burden. StreamNeo can remove that specific need to keep your computer running by taking an uploaded video and keeping the YouTube broadcast running, with monitoring and automatic restarts if it drops. It is YouTube-only, and it does not replace checking your source file, stream settings or current YouTube guidance.
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 FFmpeg reconnect flags fix a YouTube RTMPS disconnect?
Not as a universal fix. The commonly cited reconnect flags are documented for HTTP, so first establish whether the input or the RTMPS publishing output is failing. Use the error and protocol to choose the relevant diagnostic path.
Which reconnect setting should I use for an HTTP source?
Check the HTTP section of FFmpeg’s protocol documentation and the options supported by your installed build with ffmpeg -h protocol=http. Options such as reconnect_at_eof change how an ended stream is treated, so use them only when that matches the intended behaviour of the source.
Should I switch from RTMP to RTMPS?
Use the RTMPS destination provided in YouTube Live Control Room when your encoder supports it. Check the exact URL and scheme rather than guessing a host or port, and consult YouTube’s current setup instructions if the connection reports a timeout or TLS error.
What should I include when asking someone to diagnose my command?
Include the FFmpeg version, the full command with the stream key and other credentials removed, the input and output URL schemes, and the exact error text with nearby log lines. Also say what Live Control Room showed and whether any local recording continued; those details help distinguish input, encoder and publishing failures.