A running FFmpeg process does not prove YouTube is receiving media. Start with the Live Control Room and FFmpeg’s output, then verify the stream key and ingest URL before investigating the outbound connection; the message alone cannot identify the cause.
Work through the checks in that order and compare what each system reports at the same time. A process can remain open after its connection has failed, while a dashboard can take a moment to reflect a change. Avoid changing several settings at once: you want to find evidence of where delivery stops.
Check what Live Control Room reports
Open YouTube Studio’s Live Control Room and inspect the status for the affected stream. Look for whether YouTube is receiving the encoder feed, any warnings about the incoming stream, and whether the event is still live or has changed state. YouTube’s live-stream troubleshooting guidance recommends checking the dashboard and the encoder when a stream has a startup or connection problem.
The important distinction is between a local process and a received stream. FFmpeg may still be running, reading a video file, or waiting for input even though YouTube is no longer receiving data. Conversely, the dashboard may show a brief transition while a connection is being established. Treat neither the process list nor a single dashboard label as a complete diagnosis; compare the current status with FFmpeg’s most recent output.
If the stream has a scheduled start, make sure you are looking at the intended event and not an older or separate broadcast. An event page can remain open while your encoder is pointed elsewhere. If you are setting up a loop rather than recovering an existing feed, the steps in streaming a looping video with a scheduled start may help you distinguish the scheduled event from the encoder connection itself.
Note the exact status and the time you checked it. Record whether YouTube says it is receiving data, reports an encoder error, or shows no incoming feed. Do not share screenshots or copied settings that expose your stream key. A status observation is useful evidence, but it does not establish whether the key, URL, FFmpeg output, or network caused the interruption.
Inspect FFmpeg output and process state
Next, inspect FFmpeg’s recent console output or log, particularly the lines around when YouTube changed status. A process can continue to exist while its output is stalled or while repeated writes fail. Look for messages indicating a failed write, a closed connection, a rejected key, a protocol or TLS error, or repeated reconnection attempts. These clues point to different checks; they are not interchangeable diagnoses.
Check that FFmpeg is still making progress. Depending on how it was launched, useful signs may include continuing progress lines, advancing output time, and ongoing packet or frame activity. If the process is alive but those indicators stop advancing, it may be stuck rather than delivering a usable stream. If progress continues, that still does not prove YouTube receives the output: the local encoder can produce data while the remote connection is broken.
YouTube recommends checking the local stream’s picture and sound, encoder errors, CPU load, and whether the encoder software is current. If you have a local recording or preview, inspect it for frozen video, missing audio, or an unexpected source. A faulty or overloaded local output needs attention before a network diagnosis. An FFmpeg command can exit with errors in its log, but the particular message and command matter; do not apply a copied flag just because it appears in a forum post.
The FFmpeg protocol documentation is the primary reference for protocol behaviour and options. Use it to understand a specific protocol setting shown in your command, not as a reason to replace the command wholesale. If you do not manage the command yourself, capture the relevant error lines and ask the person who configured it to interpret them.
A useful distinction is whether the failure happens before or after FFmpeg begins sending. An immediate connection or authentication error makes the destination settings especially relevant. A connection that starts and then drops may call for checking both the output and network path. Neither pattern alone proves a single cause, so keep the dashboard, log, and configuration evidence together.
Verify the stream key and ingest URL
Compare the destination configured in FFmpeg with the current server URL and stream key shown for the intended broadcast in Live Control Room. YouTube’s guidance for a third-party encoder startup error is to obtain the stream key from Live Control Room and update the encoder. A key can be changed or replaced, and an old saved command can continue running with a value that is no longer the one YouTube expects.
Check the URL and key as separate fields. Confirm that the ingest address uses the expected RTMP or RTMPS form, that there are no unintended spaces or truncated characters, and that the key belongs to this event or stream configuration. Do not paste a key into a public support forum, an article comment, or an unredacted screenshot. If you share a command for diagnosis, replace the key with a placeholder first.
If FFmpeg reports an authentication or key rejection, compare the configured value with the current value in Studio rather than repeatedly restarting the same command. If the values match, preserve the error and check whether you are viewing the right channel and event. A mismatch is one possible explanation, not a conclusion to draw without checking the evidence.
For RTMPS, the URL and port matter as well as the key. RTMPS is RTMP carried through SSL. YouTube’s RTMPS guidance notes that when the address appears correct but an SSL error occurs, the port may be wrong. Match the actual FFmpeg error to the exact URL and port in use; do not change to an unverified port simply because the dashboard says disconnected.
A stream key change can also affect a long-running channel that was configured long ago. If this is a persistent channel, the article on what happens when a church’s livestream key changes explains why saved encoder settings need to be checked after a key change. Keep the distinction clear: verifying the key is a configuration check, not proof that the connection will remain stable once accepted.
Check the outbound connection and local encoder health
If the destination appears correct and local output is sound, examine the outbound internet connection between the encoder and YouTube’s ingest service. The relevant path is not simply whether a browser can open a web page. A stream sends data continuously, so intermittent loss or a connection that cannot sustain the configured output may interrupt delivery even while other internet use seems normal.
The OBS Project’s stream connection troubleshooting guide describes dropped frames and intermittent disconnections as signs of issues between the computer and remote ingest server. It also explains that drops can relate to an unstable connection or a bitrate the connection cannot sustain. This is useful context even if your encoder is FFmpeg: the local process and the network path are different parts of the chain.
Check for evidence over time rather than relying on one speed test. Note whether FFmpeg logs show repeated connection interruptions, whether YouTube’s status changes at the same time, and whether other devices or a wired test show similar problems. If practical, test with an Ethernet cable instead of Wi-Fi to isolate the local wireless link. A wired test cannot rule out an ISP issue or a problem at the ingest service, and buying a cable is not a universal fix.
Also consider local encoder load. YouTube recommends checking CPU load and the quality of the local picture and sound. If the machine is overloaded, the output may become irregular or the system may struggle to keep up. If local output remains clean and the encoder shows no obvious overload, that makes the network path worth closer attention, but it does not establish that the ISP is at fault.
If a connection test points to a problem beyond your local setup, YouTube advises contacting your ISP; if its troubleshooting steps do not resolve the problem, report it to YouTube. Preserve timestamps and the relevant errors so the report describes an observed issue rather than a guess. For a longer-running FFmpeg setup, running an FFmpeg YouTube stream from a VPS is a different operating arrangement, but it still depends on verifying the destination and monitoring actual delivery.
Compare timestamps across logs and status
A timeline often narrows the investigation more reliably than a single error message. Write down when the dashboard first showed disconnected, when FFmpeg last reported successful output or first logged an error, and whether there was a local change such as a restart, network interruption, or key update. Use the timestamps displayed by the systems as they are; account for any obvious clock difference before treating seconds as exact.
| What you observe | What to check next | What it does not prove |
|---|---|---|
| YouTube reports no incoming stream and FFmpeg logs a connection or write error at the same time | Inspect the exact error, then verify URL, key, protocol and port | It does not by itself identify which setting or network component failed |
| YouTube reports disconnected, but FFmpeg progress appears to continue | Check whether progress is advancing, inspect recent write errors, and verify that the configured destination is the intended event | A live process or advancing local work does not prove remote receipt |
| FFmpeg reports an authentication or key error | Compare the key and destination with the current values in Live Control Room | It does not prove the key is the only issue until the values and target event are checked |
| Local picture or sound is faulty, or CPU load is high | Investigate the source, encoding load and local output before focusing on the network | A poor local output does not establish a YouTube ingest fault |
| Local output is sound but connection interruptions appear in logs | Test the outbound path and look for intermittent drops or a connection that cannot sustain the stream | It does not prove the ISP is responsible |
Keep a short record rather than collecting every system detail. Include the stream state, time, the last relevant FFmpeg lines with secrets removed, and whether local video and sound were normal. This makes it easier to see if the sequence was: output problem first, connection error first, or dashboard status change first. If the evidence is incomplete, say so rather than filling the gap with a presumed cause.
For a 24/7 channel, compare the incident with previous interruptions. A recurring drop at the same point in the output may warrant examining the loop or process behaviour; an interruption that coincides with a key change points to a different check. The article on YouTube 24/7 streams disconnecting when RTMP output reaches a time limit covers one specific pattern. Do not assume that pattern applies unless your timeline and logs support it.
Retest by changing one thing at a time
Once you have recorded the initial state, make a controlled retest. If the key or URL does not match Studio, correct that value and test again. If the logs show a specific RTMPS SSL or port error, verify the documented address and port. If the local output is faulty, address the local source or load. If output is healthy but the connection is unstable, isolate the network path where practical. Changing only the relevant item makes the result easier to interpret.
Before restarting, save the last useful log lines and note the dashboard state. After restarting, check whether FFmpeg establishes a connection, whether its output advances, and whether Live Control Room reports receipt. A successful restart is evidence that the stream is working at that moment; it does not show why the earlier connection failed or guarantee that the issue will not recur.
If YouTube recommends trying a different encoder, use it as a comparison test rather than an assumption that FFmpeg is defective. Compare the same criteria: does YouTube receive a stable feed, is local picture and sound intact, is encoder load reasonable, are there dropped frames or disconnections, and is the exact destination accepted? Keep other conditions as similar as possible so you are not comparing a changed key, network, and encoder all at once.
If the problem persists, escalate with a concise evidence pack: the affected event, timestamps, the dashboard status, redacted FFmpeg errors, the protocol and destination type, and what you already tested. Do not include the stream key. Contact the ISP when tests point to the connection, and use YouTube’s troubleshooting route when the encoder, destination, and local connection checks have not resolved the problem.
For a channel whose main concern is whether a home computer must remain on all day, a hosted broadcast workflow can remove that particular operational burden. StreamNeo takes an uploaded video and runs it as a YouTube live stream, so you do not have to keep your own computer on for that job; it will not diagnose this FFmpeg incident or remove the need to check YouTube’s receipt status and channel configuration.
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
Why does FFmpeg keep running if YouTube says the encoder is disconnected?
The process can remain open even if its connection is no longer delivering media to YouTube. Check the recent FFmpeg output and the Live Control Room status together; the process being present is not proof of receipt.
Should I change the stream key first?
First compare the configured key and ingest URL with the current values in the correct Live Control Room event. If FFmpeg reports a key or authentication error, this check is particularly relevant, but the title alone does not show that the key is wrong.
Could the internet connection be the cause?
Yes, an unstable outbound path or a connection that cannot sustain the stream can be relevant, especially if local output is healthy and logs show drops or interruptions. Test the connection and compare timestamps before assigning responsibility to Wi-Fi, the ISP, or the ingest service.
What should I send to support?
Share the event status, incident times, and the relevant redacted FFmpeg errors, along with the protocol and checks already performed. Remove the stream key and other credentials from logs or screenshots before sending them.