A church’s YouTube Live page can show “waiting for encoder” when the broadcast is prepared but YouTube has not received a usable audio and video feed. Scheduling the event and sending that feed are separate steps: the encoder or sending service must be configured and started as well.
Treat the message as a prompt to trace the signal from its source to YouTube, not as proof that one particular setting is wrong. Check, in order, that the sender is running, has a valid input, is aimed at the intended stream and is reaching YouTube.
What “waiting for encoder” means
A YouTube live broadcast has a page and an incoming signal. The page holds details such as its title, thumbnail and scheduled time; the signal is the audio and video sent by an encoder or another sending service. YouTube explains this sequence in its guide to creating a live stream with an encoder: prepare the broadcast, configure the encoder, start sending, then check the received preview.
That distinction is easy to miss in a busy church. Someone may have prepared the event in the livestream settings page, while the person operating the camera or computer has not started the output. The public page can be ready for viewers without receiving any pictures or sound. Preparing or scheduling the page does not itself send video data.
The wording can also appear in an encoder’s own interface, and its precise meaning depends on the product. For example, the Cobalt Digital 9992-ENC manual defines its “Waiting for Encoder” state as the encoder not attempting to connect to the RTMP server. That is a device-specific definition, not a universal description of every YouTube status. Read the surrounding status details and use the manual for your own equipment rather than assuming the same label means the same thing everywhere.
Your first job is therefore to locate the break in the chain: source, encoding, output, connection, or YouTube’s received preview. Do not begin by changing the title, rescheduling the event or replacing the stream key unless the evidence points there. A useful overview of the difference between the broadcast page and incoming feed is also in this explanation of what YouTube Live Control Room can and cannot automate.
Check that the encoder is running
Find the software or hardware that actually sends the service to YouTube. It might be OBS on a computer, a dedicated encoder connected to a video mixer, or a sending process that plays prepared recordings. Confirm that its streaming output has been started; opening the project or seeing the local preview is not necessarily the same as transmitting.
Look for the encoder’s own status and any error text. A button labelled “Start Streaming” or equivalent should change to a running state, but use the status display rather than relying on the button label alone. If the output is stopped, start it and give YouTube a short moment to report whether a feed has arrived. If it reports a connection failure, note the exact message before changing anything.
Next, verify that the encoder has something to send. Check that the camera is powered, the intended camera input is selected on the mixer or capture device, and the media source is loaded if the service uses a prerecorded video. A black local preview, frozen frame or absent audio meter suggests an input problem; it does not by itself establish a YouTube problem.
For a church using a computer, confirm that the correct scene is active and that the camera or media source is visible in that scene. For a hardware encoder, check its input indicators and consult its manual if the status is unclear. The Cobalt manual, for instance, describes product-specific causes including a stopped encoding core or invalid input. Treat those as clues for that model, not rules for all encoders.
Avoid restarting several parts of the setup at once. If the encoder was stopped, start it and observe the result. If it was already running but had no source, restore the source and observe again. Changing one thing at a time helps distinguish a missing input from a transmission failure and gives the next operator a useful account of what happened.
Confirm the selected stream and destination
A running encoder can still be sending to the wrong destination. Compare the broadcast selected in YouTube Studio with the stream configuration selected in the encoder. This matters when a church has separate events for a morning service, Bible study, rehearsal or a recurring broadcast: a correct encoder can send to a different event than the one the congregation has opened.
Check that the intended output is enabled. Some systems let you configure a destination without actively connecting to it; a saved profile is not proof that it is transmitting. Confirm that the selected stream is the one planned for this service, and check the encoder’s output status after starting it.
If the encoder says it is running but not connected, follow the connection branch rather than treating it as a stopped encoder. Check that the destination details match the selected YouTube stream and that the network can reach the service. The Cobalt manual lists unreachable servers, incorrect RTMP parameters and failure to resolve a server name among possible reasons for that product’s “Not Connected” state. Other products may use different labels, so inspect their own diagnostics.
On a church network, a connection issue may involve a changed Wi-Fi connection, a cable that has been unplugged, a router restart or a network policy that blocks the sender. If the encoder relies on a computer, check that it still has internet access. Avoid assuming that ordinary web browsing from a separate phone proves the encoder’s route works; it only confirms that phone’s connection.
If your church is choosing a sending setup rather than troubleshooting a single service, compare the source and operating responsibility as well as the equipment. Software on an existing computer may suit a live camera and mixer when someone can monitor it. A dedicated hardware encoder may fit a fixed installation, while prerecorded continuous playback has different needs. The guide to running church Bible study recordings as a 24/7 YouTube stream is relevant when the source is a prepared recording rather than a live service. No device is the universal fix for a sender that is simply stopped or pointed elsewhere.
Verify the URL and stream key
Once you know the sender is running and trying to connect to the intended broadcast, verify the destination information. YouTube’s encoder workflow provides stream information for the encoder to use. Compare the selected server or ingest URL and stream key carefully with the details for the event you mean to send. If the software uses a saved profile, check which profile is active rather than assuming the displayed name identifies the current key.
A key can be associated with a different stream setup, copied incompletely or replaced after the encoder profile was last saved. But “waiting for encoder” alone does not prove the key is wrong. Establish first whether the output is active, whether there is a valid source, and whether the encoder is attempting a connection. If it never attempts output, replacing the key will not start it.
Handle stream keys as credentials: do not read them aloud in a public service, include them in screenshots shared widely, or paste them into an untrusted support forum. If you need to replace a key, update the encoder configuration deliberately and confirm which event the new details belong to. Follow the current controls in YouTube Studio because labels and workflow can change.
A useful check is to have one operator read the event name and another verify the encoder’s selected destination against it. This catches a common human error without exposing the key itself. Keep the check short: event identity, destination selected, output enabled, and connection status. If those align but the encoder cannot connect, gather its error details and investigate network or DNS access rather than repeatedly rotating credentials.
Check encoder preview and YouTube ingest status
There are two previews worth checking. The encoder’s local preview tells you whether it has a source to encode. YouTube’s preview or stream-health area tells you whether YouTube is receiving the outgoing feed. A picture in one place does not prove that it has reached the other.
After starting the encoder, return to the intended broadcast in YouTube Studio and check for incoming video and audio. Allow for the normal delay in status updates, but do not treat an unchanged waiting message as evidence that the feed is healthy. Look for the current health information and any explanation YouTube provides. The official encoder settings and recommendations are the right reference if the feed arrives but YouTube flags its format or quality.
Use the order of evidence to decide what to do next. If the encoder preview is empty, return to the camera, mixer or media source. If the local preview is sound but the sender reports disconnected, inspect destination details and the network path. If the encoder reports a connection and YouTube shows a feed with a warning, compare the actual output settings with YouTube’s current guidance. Do not apply a setting found in an old forum post as a guaranteed cure; recommendations and interface options can change.
If the feed is visible in YouTube but still shows a health warning, distinguish that from having no feed at all. Record the warning text, check whether both audio and video are present, and make one measured adjustment at a time. For example, if the picture reaches YouTube but no sound does, inspect the audio source and routing before changing the video format. A church that streams a prepared playlist can use this FFmpeg playlist-at-boot guide as a separate reference for its sender workflow, but it does not replace checking the current YouTube ingest status.
Test audio and video before going live
A successful connection is not yet a successful service stream. Check the picture and sound as a viewer would receive them. In YouTube’s preview, confirm that the expected camera or video is visible, the image is not frozen, and the audio is present at a sensible level. A local meter moving does not prove that the audience can hear it; the received preview is the more relevant check.
For a live service, test the complete route: microphone or mixer, encoder input, encoder output, then YouTube preview. If there are multiple microphones, cameras or scenes, verify the one intended for the opening. If the church uses a prerecorded opening or holding slide, check that the source changes as expected and that it does not leave the audience with silence when the service begins.
For continuous prerecorded content, check that the correct file or playlist is loaded and that it advances as intended. The OBS versus FFmpeg comparison for looping video on YouTube Live can help frame that choice when you are planning a recorded loop. A loop is not a substitute for a tested input: it still needs a sender that is running, configured for the correct destination and monitored for a received preview.
Keep a simple service-day checklist near the control desk: confirm event identity, source picture, audio, encoder output, YouTube preview, and who is watching the stream after it begins. Record the specific error and the change that resolved it if something goes wrong. That note is more useful at the next service than a vague instruction to “check the settings”.
When to use a rehearsed backup
A backup is most useful when the main signal cannot be restored in the time available without disrupting the service. Decide in advance who can make the call, what viewers will see or hear, and how the congregation will be told about a change. The backup might be another tested source, a prepared holding image with audio, or an agreed way to direct viewers to an alternate service update. Do not improvise a new stream key or unfamiliar encoder workflow while the service is underway unless there is no safer choice.
Rehearse the backup with the people who will operate it. A note in a folder is not a tested plan if nobody knows which input or event it refers to. Verify that the alternate source reaches the intended YouTube broadcast, and check its audio as well as its picture. If the fallback is a recording, confirm that the church has the appropriate rights and permissions for that material; technical readiness does not settle rights questions.
For a church that wants prerecorded material to continue without a local computer being left on, a cloud-based sender can remove the need to keep that computer operating. StreamNeo is relevant to that separate unattended-playback problem: it takes an uploaded video and sends it to a YouTube channel, so there is no church computer to restart if it switches off. It does not repair a live camera encoder that has no input, a wrong destination, or a connection fault; diagnose those problems at their source.
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
Does scheduling the church’s broadcast send video to YouTube?
No. Scheduling prepares the broadcast page and its details, but an encoder or sending service still needs to transmit the audio and video. Confirm that the sender is running and that YouTube’s preview shows the incoming feed.
Does “waiting for encoder” mean the stream key is wrong?
Not by itself. The encoder may be stopped, missing a usable input, pointed at another stream, or unable to connect. Check its running state and source before changing the key; then verify the selected destination if it is attempting to send.
What should we check if the encoder says it is connected?
Check YouTube’s received preview and current stream-health message. If video or audio is missing, trace that part of the signal from its source; if a warning appears, compare the actual output with YouTube’s current encoder guidance.
Should we buy a new encoder to clear the message?
Not as the first step. A stopped sender, missing camera input or incorrect destination can affect equipment that is otherwise working. Identify where the signal stops, and consider new hardware only if the existing setup cannot meet the church’s actual operating needs.