A local FFmpeg message saying that the process has started does not prove that YouTube has accepted the feed or published the stream. Check the intended stream in YouTube Live Control Room first, then verify the stream key, server URL, protocol, encoding settings and scheduled-stream status.
The exact cause cannot be diagnosed from the word “offline” alone. You need the FFmpeg command and logs, together with the preview, health indicator and timestamped messages shown in Live Control Room. Treat the dashboard as the evidence of what YouTube is receiving, rather than treating a running terminal process as proof that viewers can watch.
What an FFmpeg start message actually proves
When FFmpeg prints a starting message, it normally tells you that the local process has launched and is attempting to read your input and send an output. It does not, by itself, tell you that the destination is correct, that the stream key is valid, that the outbound connection is stable, or that YouTube has accepted the video and audio.
There are several stages between starting FFmpeg and publishing a YouTube stream:
| Stage | What to inspect | What the evidence can establish |
|---|---|---|
| Local encoder | FFmpeg output, input and output logs | Whether FFmpeg is producing the intended audio and video |
| Connection and authentication | Server URL, protocol, key and connection errors | Whether FFmpeg is reaching the intended ingest destination with the intended credential |
| YouTube ingest | Live Control Room preview, health and errors | Whether YouTube is receiving and accepting the feed |
| Event publication | Scheduled-stream state and Go live action | Whether a previewed event has actually been published |
| Viewer access | Watch page, channel page and connection stability | Whether viewers can open and receive the stream |
This distinction matters for an always-on channel. You might see a clean FFmpeg process on a computer in another room while YouTube is showing no preview. You might also see a preview while a scheduled event remains unpublished because a separate Go live action is still required.
Do not change five settings at once. If you replace the key, change the protocol, alter the bitrate and restart the machine together, you lose the evidence that would have identified the original failure. Work from YouTube's dashboard towards the encoder, recording what you see at each stage.
Start with Live Control Room
Open YouTube Studio and select the exact live stream or event that FFmpeg is meant to feed. Look for the preview and the stream-health area before editing the command. YouTube's live-stream troubleshooting guidance recommends using the encoder status and the available dashboard information to separate an encoder problem from a connection problem.
If the preview is visible, YouTube is seeing enough of the feed to display it. That does not automatically mean the event is public or that the stream is available to viewers, but it moves the investigation beyond the first connection question. Read the health messages beside the preview and note their timestamps. A message appearing at the same time as the FFmpeg restart is more useful than a general assumption that the command is correct.
If the preview is absent, check whether the dashboard reports an error, a waiting state or no incoming data. A blank preview may indicate that YouTube is not receiving the feed, but you should still use the precise message to decide whether to inspect the key, endpoint, protocol, encoding or network next. YouTube distinguishes critical red errors from moderate yellow messages, and unresolved messages can continue to appear.
Use the dashboard for the intended event, not a different test stream opened in another browser tab. A common source of confusion is copying a key from one scheduled event and then looking at the status of another. The title, scheduled time and stream settings should all identify the same destination.
It can help to take a screenshot or write down the status before restarting FFmpeg. This gives you a simple before-and-after comparison. If the dashboard reports a wrong format, changing the key will not address it. If it reports no data and the command is sending to an old event, adjusting codecs will not address that either.
For a private or unlisted check, the process described in how to test a live stream without going public can help you keep the diagnostic separate from a public broadcast. The important point is to test the same workflow you intend to use, including its stream key and publication step.
Verify the stream URL and key
The server URL tells FFmpeg where to send the feed. The stream key identifies the YouTube stream that should receive it. Both must belong to the intended stream, and the key must be copied exactly. A process can continue running while sending data to the wrong destination or while failing authentication.
Open the stream settings in Live Control Room and compare the displayed server URL and key with the values in the FFmpeg command. Check for an omitted character, an extra space, quotation-mark damage, a copied URL from another workflow or a key belonging to an older event. If your command is stored in a script or service, inspect the value actually being used rather than only the version you think you edited.
YouTube describes the stream key as the credential that allows it to accept the feed and the server URL as the destination. Its guidance for encoder problems includes copying a new stream key and updating the encoder. That is a useful controlled test when the key may have been exposed, changed or associated with the wrong stream. It is not a reason to rotate keys repeatedly without checking the dashboard.
After replacing a key, stop the old FFmpeg process fully before starting the new one. Two processes sending to the same destination can make the result harder to read and may produce competing connection behaviour. Confirm that the new process is using the new value, especially if the key is supplied through an environment variable, batch file or service configuration.
Do not assume that a familiar URL is valid for every stream. Copy the current value from the relevant Live Control Room workflow. If the stream was created as a scheduled event, use the settings attached to that event rather than a key saved from a previous recurring broadcast.
If the URL and key match but the dashboard still shows no preview, move to the protocol and connection checks. Do not conclude from the matching text alone that YouTube has accepted the feed. The preview and health messages remain the stronger evidence.
Check protocol and outbound connection
The protocol in the URL and the protocol supported by your FFmpeg build must agree. YouTube supports RTMP and RTMPS workflows, but an RTMPS endpoint is not simply an ordinary RTMP endpoint with a different spelling. YouTube explains that RTMPS is RTMP over a TLS/SSL connection and provides encryption in its RTMPS guidance.
If you selected RTMPS in Live Control Room, copy the RTMPS server address instead of assuming that an old RTMP address can be reused. YouTube's documented checks for RTMPS problems include confirming that both the protocol and server are rtmps. For the SSL error case, it suggests trying port 443. For a timeout, it advises checking the URL and confirming that the encoder supports RTMPS.
The error in the FFmpeg log matters here. An authentication or handshake error points towards the endpoint, key, TLS support or connection path. A timeout points towards reachability, a wrong address, a blocked route or an encoder that cannot complete the chosen connection. These are different tests, even though both can leave the YouTube stream offline.
Check whether the computer can maintain the outbound connection for more than a brief moment. A feed that connects and drops repeatedly may produce an intermittent preview or a stream that changes state. Wi-Fi congestion, a busy upload connection, router rules and an unstable broadband link can all matter, but the dashboard and FFmpeg timestamps should guide which possibility you investigate first.
The total stream bitrate must fit within the available upload capacity. YouTube recommends leaving headroom rather than using all of the connection's apparent capacity. A speed test taken at another time is not proof that a continuous upload will remain stable, particularly if other people or devices share the connection.
If the local encoder output looks healthy but YouTube reports connection trouble, investigate the outbound path rather than repeatedly rebuilding the video command. You can pause other large uploads, test from a more stable wired connection where practical, and observe whether the dashboard health changes. That test does not prove the original network was the cause unless the result is repeatable, but it narrows the failure stage.
For an always-on channel, this is also where operating choices matter. Keeping a personal computer running requires you to maintain the network, power, operating system and FFmpeg process. A cloud-based workflow can remove the need to leave your own computer switched on, but it does not make an incorrect YouTube key, an unpublished scheduled event or an unsupported output format valid. StreamNeo is useful when the specific pain is keeping a pre-recorded file running continuously without installing and supervising FFmpeg on your own machine.
Check codecs, bitrate and keyframes
Once the destination and connection are plausible, inspect what FFmpeg is actually sending. YouTube publishes encoder guidance covering supported video and audio codecs, bitrate behaviour and keyframe frequency in its encoder settings documentation. Use the current guidance for the exact protocol, resolution and stream type you have selected.
Do not rely on the input file's properties. FFmpeg may be reading a file successfully while its output settings produce a format YouTube does not accept for that workflow. Read the output portion of the log and identify the video codec, audio codec, pixel format, frame rate, dimensions, bitrate mode and keyframe settings. The input and output can differ.
YouTube recommends constant bitrate for the encoder workflow described in its guidance. A variable or unexpectedly high output can create problems even if the local video looks normal. Compare the configured bitrate with the available upload capacity and with YouTube's current settings for the chosen resolution. If the source is a high-quality master, do not assume it should be sent unchanged as a live feed.
Keyframes affect how the platform can process and begin displaying the stream. YouTube's cited guidance recommends a keyframe frequency of two seconds and says the interval should not exceed four seconds. These are encoder settings, not a promise that every source or workflow behaves identically. If you want the background to these values, see keyframe interval for 24/7 streams, then confirm the current official encoder page before applying a setting.
The practical test is to make one deliberate output change, restart FFmpeg, and check Live Control Room again. If the health message names a codec or format problem, use that message to choose the change. If the dashboard says the feed is not arriving at all, codec adjustments may be premature because YouTube may not yet be receiving a usable connection.
Audio should not be ignored. A video preview without usable audio, or an audio format outside the supported workflow, can create a different problem from a completely missing feed. Look at both streams in the FFmpeg output and in YouTube's health messages. A devotional channel, lofi station or local-news loop still needs the audio path checked even when the picture appears in the preview.
Avoid piling filters, scaling operations and re-encoding options into a troubleshooting command unless they solve an identified issue. A simple, explicit output is easier to read and reproduce. Save the working command once you have evidence that the dashboard accepts it, and keep a separate copy of the original command for comparison.
Scheduled streams need a separate Go live step
A scheduled stream can have an encoder transmitting while the public event is still not live. YouTube's encoder workflow says to start the encoder, wait for the preview to appear in Live Control Room, and then click Go live. This is why an FFmpeg terminal can look active while the scheduled stream or watch page still shows offline.
Treat these as two separate questions:
- Is YouTube receiving the feed and showing a preview?
- Has the scheduled event been published with Go live?
If the preview is present but the event remains offline, check the scheduled event's controls and status. Do not restart FFmpeg simply because the watch page has not opened yet. Restarting the encoder may remove the preview you needed before publishing the event.
If the preview is absent, the Go live control is not the first fix. Return to the stream-health messages and the encoder logs. You need YouTube to receive a usable feed before a publication step can succeed. Conversely, if the preview is present and health is acceptable, an unpublished scheduled event may explain the viewer-facing offline state.
This distinction is important for planned 24/7 channels. A test performed privately, a scheduled event created for later and a currently public broadcast are different states. Write down which one you created before troubleshooting. If the channel is built around a repeating file, make sure the event you are opening is the event that the command is feeding.
After clicking Go live, check the channel and watch pages as well as Live Control Room. YouTube recommends testing the stream and confirming that the event is accessible from the relevant viewing pages. A dashboard preview alone is not the final check for viewer access.
Use logs and dashboard errors to narrow the cause
Save the FFmpeg command, the complete startup output and the lines produced when the connection changes. The useful details include the input file, output URL with the stream key removed, protocol, codec selections, bitrate settings, keyframe configuration and any errors with timestamps. Never publish the stream key when asking for help or sharing a log.
Then place those details beside the Live Control Room status at the same time. A useful record might say that FFmpeg began at a particular time, the dashboard showed no preview, a connection timeout appeared, and a later restart produced a preview. That is more actionable than saying that FFmpeg “seemed fine”.
Use the first explicit error as the starting point. YouTube's live-stream error guidance lists issues including incorrect stream format and codec problems. If the message identifies a format, inspect the output settings. If it identifies a connection or timeout problem, inspect the endpoint, protocol and network. If it reports that the stream is waiting or scheduled, inspect the event state instead of changing codecs.
A compact decision order is:
- No preview and no useful local output: inspect the input file and FFmpeg process.
- Local output exists but the dashboard has no feed: inspect URL, key, protocol and outbound access.
- Dashboard sees a feed and reports format or codec errors: inspect the encoded output.
- Preview exists but viewers see offline: inspect the scheduled event and Go live state.
- Feed appears and disappears: compare connection errors, upload capacity and health timestamps.
This order prevents a common mistake: treating every offline symptom as an encoding problem. It also prevents the opposite mistake of changing network settings when YouTube is clearly reporting an unsupported output format.
Once the stream works, test it deliberately rather than assuming the first successful preview proves the whole night will be stable. Watch the health indicator for a period, confirm that the watch page opens, and keep the working command and key-management notes in a secure place. For channels built around a loop, the advice in playlists, chapters and the watch page is a separate publishing consideration, not a substitute for confirming the live feed.
If the problem continues, provide the exact FFmpeg command with the key redacted, the relevant log lines, the protocol, the stream type and the Live Control Room message. Without those details, nobody can honestly identify whether the fault is local encoding, authentication, ingest, scheduled publication or viewer access.
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 say it started when YouTube is still offline?
FFmpeg starting only shows that the local process has launched and is attempting to send an output. It does not prove that YouTube accepted the key, received the feed, or published the event. Check the Live Control Room preview and health messages for those stages.
Should I change the bitrate first?
Not usually. First check the dashboard status, exact URL, stream key and protocol, then read the first explicit error in the FFmpeg log. Change encoding settings when YouTube reports a format, codec, bitrate or keyframe issue, rather than using them as a general fix.
Why is there a preview but the scheduled stream is offline?
A scheduled event can receive a preview before it is published. Start the encoder, wait for the preview in Live Control Room, and click Go live for the scheduled event when the dashboard is ready. Confirm the result on the watch page as well.
What information is needed to diagnose a particular setup?
You need the redacted FFmpeg command and relevant logs, the chosen protocol, the exact Live Control Room status and any timestamped dashboard error. Also state whether the stream is scheduled, unlisted or already public. Without that evidence, the cause should remain a set of possibilities rather than a confident diagnosis.