If your encoder says it is sending but YouTube remains on “Starting Soon” or “Waiting for data”, the problem is usually the connection between the encoder and the YouTube broadcast. Work through the handshake in order rather than changing bitrate, video files and software settings at the same time.
The useful question is not whether the encoder is running. It is whether YouTube is receiving a valid stream on the correct ingest address, with the correct key, and whether that incoming stream is attached to the broadcast you are viewing.
What YouTube is waiting for, precisely
A YouTube live stream has several separate pieces that are easy to treat as one thing:
- The video and audio being produced by your encoder
- The ingest URL that receives the outgoing connection
- The stream key that identifies your stream
- The broadcast or watch page that YouTube displays to viewers
- The connection between the incoming stream and that broadcast
Your encoder can report “live”, “connected” or “sending” while one of the other pieces is wrong. That message normally describes the encoder’s own state. It does not prove that YouTube has accepted the incoming data or attached it to the intended watch page.
When YouTube says it is waiting for data, it has not received a usable stream on the expected connection. The cause may be an incorrect address, a key copied with an extra character, a blocked outgoing connection, an inactive backup path, or a broadcast that has not been bound to the incoming stream.
“Starting Soon” can be slightly different. The watch page may exist and be visible, but the broadcast has not transitioned to the live state. YouTube may still be waiting for an accepted signal, or the scheduled broadcast may be waiting for you to start it in the Live Control Room. Do not delete the watch page at this stage. First identify which layer has failed.
A useful test is to open YouTube Studio in one browser tab and the encoder in another. In Studio, open the exact live control room for the broadcast. Confirm the channel, broadcast title and scheduled time. In the encoder, record the ingest URL, stream key and connection status before changing anything.
If the channel is built around recorded material, the file itself is usually not the first suspect. A devotional replay, a lofi loop or a local news sequence can be a perfectly valid source while the handoff to YouTube is failing. The same principle applies when you are turning a podcast into a 24/7 live radio channel: separate the media file from the live connection when diagnosing the fault.
Check the ingest URL and key separately
The ingest URL tells the encoder where to send the stream. The stream key tells YouTube which incoming stream belongs to your channel or selected stream configuration. They work together, but they are not interchangeable.
Start by copying both values again from YouTube Studio rather than relying on an old note, screenshot or saved profile. In Live Control Room, find the streaming settings for the broadcast or stream. Copy the server URL into the encoder’s server or ingest field, and copy the stream key into the key field.
Do not paste the full server URL into a field that expects only the key. Likewise, do not put the key at the end of the server address unless the encoder’s instructions explicitly require that format. Most encoders present these as two separate fields.
Look for small copying errors:
- A leading or trailing space in the key
- A key from a different YouTube channel
- A key from an older stream setup
- A primary URL entered where a backup URL was intended
- An RTMPS address entered into a field configured for another protocol
- A masked or partially copied key
If you have several channels, do not assume that the selected YouTube account in your browser is the account represented by the key. A key copied while signed into a devotional channel will not normally direct the encoder to a local-news channel simply because both channels are managed from the same computer.
Use a fresh test key only when you have a reason to suspect the existing key. If you rotate the key, update every device, automation profile and cloud stream configuration that uses it. A key change can fix a stale or exposed credential, but it can also make a working encoder appear broken if one copy remains old.
The address and key should be tested without changing the source file. If the same file works with a different valid YouTube connection, the file is not the primary issue. If the connection still fails, continue to the transport and broadcast checks instead of re-encoding the whole library.
For recorded loops, the codec can still matter after the handshake succeeds. YouTube publishes its current encoder guidance, including supported protocols and recommended stream settings, in its official live encoder help. If you need to review the media side separately, compare the practical consequences of H.264 and HEVC for 24/7 YouTube loops, but do not use codec changes as a substitute for verifying the connection.
Do not test the backup path by accident
YouTube can support a primary and a backup stream arrangement, but the backup is not a second copy that appears automatically whenever the first encoder connects. It has to be configured correctly, and the second encoder or transmission must actually send data to the backup ingest path.
This creates a common diagnosis trap. One encoder is connected to the primary URL and reports that it is sending. You are looking at a broadcast configuration that expects a backup, or you copied the backup address into the only encoder. YouTube continues waiting because the path you are watching is not receiving the stream you think it is.
Treat primary and backup as two distinct routes:
| Configuration | What must be true | Typical mistake |
|---|---|---|
| Primary only | The encoder sends to the primary ingest address with the correct key | A backup address is pasted into the main profile |
| Primary with backup | The primary and backup paths are configured according to YouTube’s instructions, with the appropriate stream being sent to each path | The second path is configured but no second encoder is transmitting |
| Testing a backup | You know which incoming path YouTube is receiving and which broadcast it is meant to serve | You change both paths at once and cannot tell which change helped |
If you are not deliberately operating a backup, simplify the setup. Use one encoder, one ingest address and one stream key. Remove an unneeded secondary profile from the test so that the result answers one question.
If you are deliberately using a backup, inspect the two configurations side by side. Confirm that the primary and backup addresses are not reversed, that the key belongs to the correct stream, and that the second encoder has its own active network connection. A second configuration file sitting on disk does not produce a backup signal.
Do not repeatedly start and stop both encoders while YouTube is still showing the old state. Record which path is active, stop one test, allow Studio to update, then test the other. The exact time YouTube takes to reflect a change can vary, so avoid inventing a timeout and moving on too early.
For a small 24/7 channel, a single clean path is often easier to maintain than a backup arrangement you cannot observe. If continuity is important, document the primary URL, backup URL, key ownership and the broadcast each path is supposed to feed. That note is more useful at two in the morning than a collection of unnamed encoder presets.
Check the firewall, port and protocol
Once the URL and key are confirmed, check whether the encoder can establish the required outbound connection. A firewall, office network, mobile hotspot policy, VPN or security product can allow ordinary web browsing while blocking the streaming connection.
RTMP and RTMPS are not the same transport. RTMP commonly uses port 1935, while RTMPS is an encrypted connection and may use a different port, commonly 443. The correct port depends on the exact ingest URL and protocol in use. Port 1935 is not guaranteed to be open on every network, and changing to it blindly can make the connection worse.
Read the encoder’s complete server address. If it begins with an RTMPS scheme, keep the encoder configured for RTMPS if that is what the software supports. If the encoder has separate protocol and port controls, make sure they agree with the address. An address that points to one protocol while a manual port field forces another can produce a failed or misleading connection.
Then test the network in the order below:
- Temporarily disconnect a VPN or proxy, if your organisation allows it, and test the same configuration.
- Try a different network, such as a phone hotspot, without changing the encoder profile.
- Check whether the computer’s security software has logged or blocked the encoder.
- Ask the network administrator whether outbound streaming traffic to the required YouTube ingest endpoint and port is allowed.
- Restore the normal network and create an explicit firewall rule only if you understand the local security policy.
A different network is a useful comparison, not a permanent answer. If the stream works on a hotspot but not on the office connection, the evidence points to the network rather than the YouTube key. If it fails on both, return to the URL, key, protocol and broadcast binding.
Avoid opening random inbound ports on a home router. The encoder normally needs to make an outbound connection to the ingest service; accepting unsolicited traffic from the internet is a different requirement and may increase risk without solving the handshake.
The encoder’s log can help here. Look for the first connection error, not only the final summary. Messages about name resolution suggest a network or address problem. Authentication or rejected-connection messages point more strongly to the key or ingest configuration. Repeated connection attempts followed by disconnects may indicate transport, firewall or encoder instability, but the log wording differs between products.
Scheduled and instant broadcasts need a binding step
A scheduled broadcast and an instant stream do not always follow the same operating sequence. With an instant stream, the incoming encoder signal can often be associated with the live session as you start it. With a scheduled broadcast, you may create the watch page first and then need to select or bind the incoming stream to that specific event.
This is the step many operators miss: they have a valid key and a connected encoder, but they are looking at a scheduled broadcast that is not the broadcast receiving that signal. The encoder is not necessarily broken. The data may be arriving under another stream configuration, or YouTube may be waiting for the scheduled event to be started.
Open the scheduled event in YouTube Studio, not merely the public watch-page URL. Check its stream settings and confirm that the selected stream key or stream configuration is the one currently used by the encoder. Then check whether Studio shows an incoming preview or signal for that event.
If the scheduled broadcast has a separate “start” control, use it only after the preview and signal are correct. Starting the event before the encoder is ready can leave you troubleshooting two states at once: the event is active, but the incoming feed is absent or attached elsewhere.
For a clean test, create a small temporary broadcast if your channel workflow permits it. Use a known key, one encoder and one source. This separates a binding problem in the scheduled event from a general failure to reach YouTube. Do not delete your established watch page merely because the temporary test works.
YouTube’s current instructions for scheduling and managing live streams should take priority over screenshots or older tutorials. Review the official YouTube guide to live streaming when labels in Studio do not match an older setup guide. Interface names and available controls can change, while the underlying need to associate the encoder signal with the intended broadcast remains.
A scheduled stream is also worth checking for channel-level restrictions, verification requirements or live-streaming eligibility notices. These are not fixed by changing an ingest port. Read any notice shown inside YouTube Studio and use the current official guidance before assuming the encoder is at fault.
Read Stream Health before the stream is live
The Stream Health panel is more useful before the public stream begins than many operators realise. It can show whether YouTube is receiving a signal and can identify problems in the incoming video or audio even while the watch page still says “Starting Soon”.
Look for an incoming preview, health state, warning or error associated with the exact broadcast. If there is no preview at all, prioritise URL, key, protocol, network and broadcast binding. If a preview appears but health warnings are present, the handshake is working and you can move on to encoder settings.
Separate these observations:
- No incoming signal: YouTube is not receiving the expected connection.
- Incoming signal with an error: YouTube receives something but cannot use it as configured.
- Video preview without audio: the connection works, but the audio track may be missing, silent or incompatible.
- Preview with unstable health: the encoder is reaching YouTube, but the data may be interrupted or produced inconsistently.
- Healthy preview while the page is not live: the broadcast may still need a start or schedule action.
Do not change five settings after seeing a health warning. Write down the warning, current resolution, frame rate, video codec, audio codec and bitrate, then change one relevant item. A bitrate ladder for long-run streams can help you choose a sensible profile once YouTube is receiving the signal, especially if the channel will run overnight on an ordinary connection.
For a file-based channel, confirm that the encoder is producing continuous timestamps and a real audio track. A video can play normally in a media player while an encoder struggles with variable timing, an unusual audio format or a file that ends without being looped. Those are source or encoding issues, not ingest authentication issues.
If the preview is healthy but the picture freezes later, keep this article’s first diagnosis separate from the later stability problem. A stream that reaches YouTube has completed the initial handshake. You then need to inspect upload consistency, encoder load, source looping and reconnection behaviour.
Restart cleanly without throwing away the watch page
A restart should reset the connection, not erase the work you have already done. Before stopping anything, note the broadcast title, scheduled status, stream key name, ingest URL, current health message and whether a preview is visible.
Then use this order:
- Stop the encoder’s current transmission.
- Wait until its status and log show that the connection has closed.
- Refresh the Live Control Room for the same broadcast.
- Confirm that the broadcast is still the intended one and that its stream settings have not changed.
- Start one encoder with the verified primary URL and key.
- Watch for the incoming preview and health message in Studio.
- Start or publish the broadcast only when the control room shows the signal you expect.
The purpose is to remove stale connections and prevent two encoder sessions from competing for the same stream. Starting a second copy while the first is still reconnecting can make the result harder to read and may produce a key-in-use or unstable-session message.
Do not delete and recreate the public watch page as a first response. A new broadcast can change the URL, reset the schedule and make it difficult for people who already have the original link to find the stream. A restart of the encoder is not the same thing as recreating the broadcast, although YouTube’s behaviour can differ by broadcast state and configuration.
At the same time, do not promise yourself that every restart will preserve the page. If the event has ended, the schedule has passed, the stream was cancelled or YouTube reports a state that cannot be restarted, the existing page may no longer accept the intended connection. Read the status in Studio before taking destructive action, and record the public URL before making changes.
For operators who do not want a personal computer to remain on all night, StreamNeo removes the specific problem of keeping the encoder process running locally: upload the prepared video, provide the YouTube stream key, and the channel can continue from the cloud with monitoring and automatic restart when the connection drops. It remains your responsibility to check the YouTube channel, content rights, broadcast state and current platform requirements.
A good permanent runbook is short. Keep one page containing the current broadcast workflow, the verified ingest configuration, the source-file location, the network test method and the official YouTube links you rely on. Add the date whenever a key, encoder or channel setting changes.
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 my encoder say it is live while YouTube says it is waiting?
The encoder’s status usually confirms only that it is attempting or maintaining its own connection. YouTube still needs to receive a valid signal at the correct ingest address, authenticate it with the correct key and associate it with the broadcast you are viewing. Check the Live Control Room preview and health state rather than relying on the encoder label.
Should I change the bitrate when YouTube is stuck on Starting Soon?
Not first. A bitrate change will not fix a wrong key, wrong ingest URL, blocked protocol or unbound scheduled broadcast. Change encoder settings only after YouTube shows that it is receiving the signal and reports a video, audio or stability problem.
Is port 1935 the fix for a failed RTMPS stream?
No. Port 1935 is commonly associated with RTMP, while RTMPS may use another port, commonly 443, depending on the ingest address and service instructions. Follow the protocol and port specified by the current configuration, and test whether the network permits the required outbound connection.
Will restarting the encoder keep my YouTube watch page?
A clean encoder restart normally targets the incoming connection rather than deleting the broadcast, but preservation is not guaranteed for every broadcast state. Check the event in YouTube Studio, record its public URL and avoid deleting it until you know whether it can accept a new signal.