YouTube Live can show “offline” while FFmpeg is running because transmitting packets, YouTube receiving a valid feed, a preview appearing, and the scheduled event going live are separate stages. Start by checking whether the intended stream has an incoming preview in Live Control Room: if it does, the event may still need the Go live action; if it does not, investigate the ingest path.
An FFmpeg process that is active, or a log that appears to show output, does not prove YouTube has accepted the feed. Use YouTube’s own preview, health indicator and error messages to decide which stage to check next, rather than repeatedly restarting the encoder or clicking Go live without evidence.
Packets, preview and live event are different states
Think of the broadcast as a sequence. FFmpeg reads or produces audio and video, encodes or packages it, and sends it to a destination. YouTube must receive a usable feed for the selected stream before Live Control Room can show an incoming preview. For a scheduled stream, you then review that preview and start the event with Go live. An event can therefore remain not live even when a feed is reaching YouTube.
These stages help narrow the problem:
| What you can see | What it suggests | What to check next |
|---|---|---|
| FFmpeg process is running, but no preview appears | The destination may be wrong, the key may not match, or ingest may be failing | Confirm the current URL and key, then read YouTube’s health messages |
| Preview appears in Live Control Room, but the event is not live | YouTube is showing incoming video, but the scheduled event may not have been started | Check the event state and use Go live if that is the intended action |
| Preview appears with an error or poor health indicator | YouTube has detected a problem with the incoming stream | Read the specific message and its timestamp before changing settings |
| Event has started but viewers still report a problem | The issue may be on the viewer side, in the event selection, or in the stream’s subsequent stability | Confirm the public event and continue checking health and connectivity |
The distinction matters because a fix for one stage will not necessarily affect another. Changing a key cannot start an event that is waiting for your action. Clicking Go live cannot repair a feed that YouTube is not receiving. And a running process alone cannot tell you whether the packets reached the correct stream in an acceptable format.
If you are setting up the FFmpeg destination for the first time, the guide to setting a YouTube stream key in FFmpeg is useful for understanding how the URL and credential are put together. Keep the diagnosis here centred on what Live Control Room actually reports.
Verify the URL and key for this stream
Open the intended broadcast in Live Control Room and compare the displayed Stream URL and stream key with the destination configured in FFmpeg. YouTube’s encoder setup instructions direct you to use the server URL and key shown for the stream. A destination copied from a different event, an old configuration or a previous test may send data somewhere other than the event you are watching.
Check both parts, not just the key. The URL identifies the ingest destination; the key identifies the stream credential. Make sure they were copied from the same intended stream. If the key was reset since the FFmpeg command or configuration was last updated, replace the stored value with the current one. YouTube explains how to reset a key in its live stream settings guidance.
Treat a stream key like a password. Do not paste it into a public post, screenshot, support request or shared command transcript. If you need to show your FFmpeg command to someone, redact the key first. A leaked key can let another sender use the credential, and it also makes a troubleshooting trail harder to share safely.
When checking the configured destination, avoid copying a generic example from a forum and assuming it matches your event. Use the endpoint YouTube currently shows for that stream. If you have changed the encoder configuration, check the actual command or saved configuration that is running, rather than the version you meant to launch. A shell script, service, scheduled task or container may still have an older value.
The stream key is not the event’s Go live control. Correct credentials can help YouTube identify an incoming feed, but they do not by themselves start a scheduled event. Once URL and key match, return to Live Control Room and check for a preview before moving on.
Use the incoming preview as the decision point
The preview is the most useful dividing line in this diagnosis. YouTube’s documented sequence for an encoder stream is to start the encoder, wait for the preview in Live Control Room, and then select Go live. If a preview is visible, YouTube is showing an incoming video feed for that stream. The event can still be scheduled rather than live until you complete the start action.
If you see a preview but the event remains not live, confirm that you have opened the correct scheduled event. Then use Go live if you intend to start it. Check the event state afterwards; do not assume that pressing the button resolved every possible issue. Read any health messages that remain, and verify that viewers are being directed to the same event you started.
If there is no preview, do not treat Go live as the next universal fix. The encoder feed may not be reaching the selected event, or YouTube may not be able to use it. Stay at the ingest stage: compare the URL and key, inspect the health indicator and errors, and verify the output format and connection.
A preview is evidence about the incoming feed, not a promise that the entire broadcast is healthy or that it will remain uninterrupted. Continue to watch the health indicator after the event starts. If the preview freezes, disappears or shows an error, use the message and its timing to guide the next check.
This is also why “FFmpeg says it is sending” is not a sufficient diagnosis. The log belongs to the sending side. The preview and health status belong to YouTube’s receiving side. Use the signal from the side that is reporting offline to choose the next step.
Start the scheduled event after preview appears
A scheduled stream has an event state as well as an ingest state. FFmpeg can send a feed while the event page remains scheduled, because sending the encoder feed and starting the public event are separate actions. When Live Control Room shows the intended preview and you are ready to begin, select Go live there.
If you have several scheduled broadcasts, check the event title and timing before starting one. A working encoder pointed at a different stream can leave the event you are watching without a preview, while another event receives the feed. This is a coordination mistake rather than proof that FFmpeg has stopped transmitting.
After using Go live, verify the state shown in Live Control Room and confirm the event link you intend to share. If the state does not change or a warning appears, read the message instead of cycling through the action. An event workflow problem and an ingest problem can look similar in a high-level status label, but the preview and the detailed status help separate them.
For a channel built around a repeating file or playlist, keep the event workflow distinct from media scheduling. The practical steps for rotating promo videos in a YouTube Live playlist cover a different part of the setup; they do not replace checking the encoder preview and starting the scheduled event.
Read ingest errors before changing FFmpeg
When the preview is missing or unhealthy, inspect the health indicator and the errors in Live Control Room or the Live Dashboard. YouTube says these areas report detected errors; messages may be marked critical or moderate and include timestamps. A warning from an earlier test may not describe the current FFmpeg run, so compare the time shown with when you started the current sender.
Use the message as a lead, not a reason to change several settings at once. For example, YouTube’s guidance for an incorrect RTMP stream format specifies H.264 video and AAC audio. Check the actual output stream and codecs FFmpeg is producing; a filename extension or the codec of the source file does not establish what is being sent after processing.
Also check whether the configured endpoint uses RTMP or RTMPS. Use the protocol and URL YouTube provides for the selected stream, and make sure the encoder supports that choice. YouTube notes that an RTMPS URL uses the rtmps protocol and its SSL troubleshooting guidance mentions port 443. That is a protocol-specific check, not a universal remedy for an offline indicator; do not switch endpoints or ports without a reason in the configuration or error message.
If the format and endpoint appear right but the feed is still absent or unstable, consider the outgoing network path. YouTube advises that total stream bitrate must fit within available upload bandwidth and recommends 20% headroom. For a primary and backup stream, include both bitrates in that calculation before allowing the headroom. Check upload capacity and connection stability, not merely download speed or a single speed-test peak. A network disruption can interrupt the stream even when the initial connection looked sound.
For a broader method of testing the upload side, see how to increase upload speed for live streaming. The point is to diagnose the connection before buying equipment or changing unrelated encoder settings: a network check will not correct a stale key, an unsupported format or an event that has not been started.
Check FFmpeg pacing and output deliberately
The -re option is often mentioned in examples for sending a file to an RTMP destination. FFmpeg documents it as reading the input at its native frame rate, equivalent to -readrate 1. It controls how quickly a file is read; it does not validate a YouTube URL or key, prove that YouTube accepted the feed, create a preview or start a scheduled event.
A generic illustration from FFmpeg’s documentation is:
ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream
That is not a complete YouTube configuration. Use the URL and key YouTube provides for the intended stream, and use output settings compatible with the selected ingest protocol. Avoid putting a real key in an example you share. Check the FFmpeg output details and the destination in the command or configuration that is actually running.
Pacing depends on the input. For a stored video file, reading at its native rate can prevent FFmpeg from sending the content as quickly as it can read it. For a live capture device or another live input, applying a low read rate can cause packet loss; FFmpeg cautions against doing so. Do not add -re reflexively just because YouTube shows offline. First establish whether the input is a file or a live source and inspect YouTube’s status.
If the setup is complex, test one change at a time. Verify the source and output codecs, confirm the destination, then observe whether the preview appears. Changing the protocol, bitrate, codec and key together may produce a different result, but it will not tell you which condition mattered. For a second view of encoder choices, the OBS and FFmpeg comparison for a nonstop podcast stream discusses the trade-off between a graphical workflow and command-line control.
Test one stage at a time
Use the following order and record what Live Control Room shows after each check. This makes it easier to identify whether the issue is the event, the destination, the incoming format or the network.
- Select the intended event. Confirm the title and scheduled stream you want to broadcast. Keep the event page open while checking the encoder.
- Compare the current destination and key. Copy them from that event’s Live Control Room settings. Update the running configuration if the key was reset or the endpoint changed.
- Start or inspect FFmpeg. Confirm that it is reading the expected input and that its output is aimed at the intended destination. Keep credentials out of logs you share.
- Look for YouTube’s preview and health status. Note whether a preview appears and whether any current error has a timestamp matching this run.
- If there is a preview, start the event when ready. Use Go live, then verify the event state. If no preview is present, stay with ingest diagnosis instead.
- If ingest remains missing or unhealthy, follow the error evidence. Check output format, protocol, upload bandwidth and connection stability in that order where relevant.
Change only one setting per test and note the result. If you replace a key, do not simultaneously change codecs and the RTMP endpoint unless an error specifically calls for it. Otherwise, even a successful test leaves you uncertain about which change addressed the symptom, and a failed one leaves more possibilities to undo.
When the incident is over, keep a short private record of the event used, whether preview appeared, the relevant error wording and the configuration change that mattered. Exclude the stream key. That record can save time if an overnight stream fails again, without turning a one-off workaround into an unexamined permanent setting.
If you are tired of keeping a separate computer running just to send a prepared file overnight, StreamNeo removes that particular operational task: you upload the video, provide the YouTube stream key, and the broadcast can continue with your computer switched off. It is YouTube-only, so you still need to prepare the right event and verify its status in YouTube.
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
If FFmpeg is running, does that mean YouTube received the stream?
No. A running process or apparent packet output only describes what FFmpeg is doing on the sending side. Check the intended event’s preview and health messages in Live Control Room to see what YouTube reports receiving.
The preview is visible, so why does the event still say scheduled?
For a scheduled encoder stream, YouTube’s workflow is to wait for the preview and then select Go live in Live Control Room. Confirm that you are on the correct event and use that action when you are ready to start it, then check the event state again.
Should I restart FFmpeg or click Go live when the status is offline?
Neither action is a universal fix. If a preview exists but the event has not started, Go live is the relevant event action; if there is no preview, first check the URL, key, health errors, output and connection. Restarting FFmpeg without identifying the failing stage may only repeat the same condition.
Does adding -re make YouTube go live?
No. FFmpeg’s -re option controls the read rate of an input, commonly a file, and does not verify the destination or start the event. Use it only when it suits the input; FFmpeg warns that a low read rate on a real capture or live input can cause packet loss.