An internet radio server does not connect to YouTube Live by itself in one universal way. You first need to take the station’s programme audio from its existing playback or server output, feed it to an encoder, add video, and send the combined audio-video stream to YouTube.
The exact audio connection depends on your radio software, operating system and available output. YouTube’s part begins when the encoder sends a compatible stream using the ingestion URL and stream key shown in Live Control Room.
Map the station audio output
Start at the station rather than at YouTube. Identify where the final programme audio exists and how another application can receive it. The correct path may be a local audio output from the playout computer, an audio feed exposed by the radio software, a virtual audio device, or an output from a separate mixer or automation system.
There is no single capture instruction that applies to every internet radio server. Two stations may both publish the same type of online radio stream while producing that audio in entirely different ways. One may run its playlist and encoder on the same Windows computer. Another may have the radio server hosted elsewhere, with a separate machine receiving the station’s output. A third may already have a mixer carrying microphones, jingles and music.
Write down these details before changing anything:
- Which application generates the final programme audio.
- Which computer or hosted system runs that application.
- Whether the output is available locally or only through a network stream.
- Whether the output includes the complete programme mix, including voice, music and station identifiers.
- Which audio inputs your encoder can accept.
The important distinction is between the station’s public listening URL and an encoder-ready audio source. A public stream URL may be useful if your encoder can receive and decode it, but it may also introduce delay, reconnect behaviour or an additional conversion step. A local programme output may be more direct, but only if the encoder runs where that output is available.
Listen to the exact source you plan to send. If the station has several outputs, do not assume that the first one is the final mix. A monitor output might contain only music, while the public broadcast includes a presenter microphone and scheduled announcements. Check the source during a representative part of the schedule, not only while a quiet playlist is playing.
If your station is built around a playlist rather than a separate radio server, the workflow may resemble the one described in how to run a YouTube livestream continuously with a playlist file. The difference here is that the audio already comes from an internet-radio chain, so you need to locate that chain’s usable output first.
Decide where the encoder will run
The encoder must be able to receive the audio continuously. If the audio is produced on the same computer, a local input or virtual audio route may be suitable. If the audio comes from another system, the encoder may need a network-accessible source or a physical line-level connection into the encoder machine.
Avoid designing around a source you have not tested. A URL that plays successfully in a browser does not automatically mean that your encoder can open it, decode its codec, reconnect after a brief interruption or preserve the intended programme mix. Test the actual source inside the chosen encoder.
Choose an encoder and visual source
YouTube Live receives an audio-video contribution from an encoder. An internet radio station supplies audio, but audio alone is not a normal YouTube live broadcast input. You need to add a visual stream before sending the contribution to YouTube.
The visual can be simple. A static station image, a gently moving background, a programme card, a waveform or a scene containing the station logo can all provide the video portion. It does not have to come from a camera. The purpose is to give YouTube a video stream and to give viewers something meaningful to see while they listen.
Choose an encoder that can do all three jobs:
- Receive the station’s audio source.
- Produce a compatible video signal.
- Send the resulting audio-video stream to YouTube over a supported ingestion protocol.
The encoder may be software running on a computer, a hardware unit, or a cloud workflow. The right choice depends on where your audio exists and who needs to maintain the system. A local encoder gives you direct access to local audio devices, but the computer and connection must remain available. A cloud workflow can remove the need to keep a particular computer switched on, but only if the station audio can reach it in a reliable, supported form.
For an ordinary internet-radio simulcast, RTMPS is the practical starting point when the encoder supports it. YouTube describes RTMPS as RTMP carried through an SSL connection, and its general guidance recommends it for ordinary live content. The YouTube encoder settings guide covers current format, bitrate and keyframe recommendations.
YouTube also documents HLS and DASH ingestion for workflows that need them. They are not required merely because your source is internet radio. Segment-based protocols can introduce more latency, so use them only when your encoder or production requirements call for them.
Give the visual a job
A static image is acceptable for a station that primarily wants listeners to hear the programme, but it should still be deliberate. Include the station name, current programme information where practical, and a readable indication that the audio is live or continuous. Do not place small text around the edges where YouTube’s player controls or mobile cropping may obscure it.
If the visual changes, test the movement. YouTube’s own guidance says tests should include audio and movement similar to what you will use during the stream. A scene that looks fine for a few seconds may reveal a frozen layer, a missing image file or an incorrect source after the encoder has been running for longer.
Create or select a YouTube live stream
Open YouTube Studio and create or select the live event in Live Control Room. The exact screen labels can change, but you need the stream’s ingestion URL and stream key or stream name. These are the details that tell YouTube where the encoder should send its contribution.
Treat the stream key as a credential. Do not publish it in a screenshot, place it in a public document or send it through a group chat unnecessarily. If you think it has been exposed, replace or reset it in YouTube Studio before testing again.
Depending on the encoder, the connection details may be entered in separate fields:
- Server or stream URL.
- Stream key or stream name.
Some encoders instead require the complete destination in the form STREAM_URL/STREAM_NAME. Do not add a second slash, remove a required path, or paste the key into the server field unless that encoder’s instructions require it. YouTube’s LiveStreams API documentation describes the ingestion information and the separate stream resource used by the broadcast.
The stream resource carries the incoming feed. The broadcast is the viewer-facing event associated with that feed. This distinction matters if you automate recurring programmes or reuse a configured stream for later broadcasts. It does not remove the need to check the selected broadcast and its visibility before going live.
If you operate more than one YouTube channel, check that you are working in the intended channel before copying the key. A technically correct encoder pointed at the wrong channel still produces the wrong result.
Connect the station audio to the encoder
Now make the station-side connection. Select the encoder input that corresponds to the audio source you mapped earlier, then watch its audio meters while the programme is playing.
If the source is local, confirm that the encoder is receiving the final mix rather than a microphone, system notification or a monitor feed with the wrong balance. If the source is a network stream, enter it in the encoder’s supported network-input area and check whether the encoder reports a stable decoded signal. If the station audio must pass through a mixer or interface, use the appropriate line-level route and confirm that left and right channels are present.
The encoder needs a supported audio codec for the YouTube contribution. YouTube’s RTMP and RTMPS settings include AAC and MP3 audio. For stereo audio, its advanced guidance recommends a 44.1 kHz sample rate and 128 kbps audio bitrate. These are YouTube recommendations, not a promise that every radio source already uses those values.
If your source uses a different codec or sample rate, decide where conversion should occur. The encoder may convert it, or the station’s playback chain may expose a compatible output. Avoid adding conversions without checking the result, because each stage can alter level, channel layout or continuity.
Check level before transmission
Play several types of station material while watching the encoder meters. Include speech, music, a jingle and the transition between scheduled items. A source can appear active during music but become silent when a playout application changes items or when a voice channel is routed differently.
Keep the level below clipping and listen for excessive quietness. You are not trying to solve every mastering issue inside the live encoder. You are checking that the intended programme reaches it consistently, in both channels when stereo is expected, without distortion or unexpected silence.
Record the working audio path in plain language. For example: “Radio automation output on the station computer, selected as the encoder’s audio input, with the station artwork as the video scene.” This note helps you restore the setup after an operating-system update or a change to the programme chain.
Send audio and video with the stream details
Configure the encoder’s video and audio output before starting the test. The video codec may be H.264, H.265/HEVC or AV1, depending on the ingestion method and encoder. For a basic radio simulcast, use a configuration your encoder and YouTube both support rather than selecting a more advanced codec without a reason.
Use constant bitrate mode where the encoder provides it. Choose a resolution and video bitrate that your upload connection can sustain. YouTube publishes bitrate guidance by resolution, frame rate and codec, so use the row matching your actual encoder configuration rather than applying one number to every stream.
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. Set the encoder accordingly. A longer interval can affect stream health and playback behaviour even when the image appears normal on the encoder’s local preview.
For a radio station visual, a modest frame rate may be sufficient if the scene is mainly static. YouTube’s guidance supports frame rates up to 60 frames per second, but a higher frame rate does not improve a static artwork scene by itself. It can increase the amount of data the encoder must process and upload.
Prefer RTMPS when supported. The destination must use the correct endpoint and path. RTMPS uses TLS on port 443 and relies on the server hostname being presented correctly through SNI. A connection error can therefore come from an incorrect path or hostname even when the stream key is valid. Google’s guide to delivering live YouTube content via RTMPS explains the protocol requirements.
Before sending, run an upload test at the location where the encoder will operate. The relevant capacity is the available upload path during the station’s normal use, not only the result from a quiet moment. Leave room for other traffic if the same connection carries office work, monitoring, cloud backups or audience-facing services.
Start the encoder with representative audio and video. Do not test only a silent image and a short music file. Let the station’s real programme run through transitions, speech and any scheduled inserts that matter to listeners.
Check the signal and visual in Live Control Room
A local encoder preview only proves that the encoder can see its inputs. It does not prove that YouTube is receiving the contribution or that the selected broadcast is using it. Watch Live Control Room after starting the encoder and wait for the incoming signal and health information to update.
Check four things:
- The selected stream shows incoming data rather than an inactive state.
- Audio is present in YouTube’s preview or monitoring path.
- The visual is moving or changing as intended and is not a blank frame.
- Stream health messages do not identify a codec, bitrate, keyframe or connection problem.
Listen from a separate device if possible. The encoder’s local audio meter can move while the wrong source is selected, and a local preview can display a scene that is not reaching YouTube. A phone on mobile data or another connection is useful for checking the viewer-facing result without relying on the encoder computer’s local path.
Check the time relationship as well. Internet radio and YouTube will not necessarily be synchronised to the same moment, particularly if the source is a public listening stream or the YouTube broadcast has its own buffering. For most stations, the main requirement is that the programme is intelligible and continuous, not that a listener hears it at exactly the same moment as a local monitor.
If the test is successful, note the working encoder settings, source path and YouTube stream association. Save a copy of the visual scene and keep the stream key out of that record. If you later need to rebuild the encoder, these notes are more useful than a screenshot of a single successful run.
This is also the point to plan for unattended operation. A station that wants a continuous channel should consider what happens if the source disappears, the encoder stops, the connection drops or the computer restarts. A cloud workflow such as StreamNeo removes the need to leave your own computer running for the uploaded video stream and can restart a dropped broadcast automatically, but it is still YouTube-only and does not replace the need to establish a compatible station audio path.
For background on keeping a channel operating beyond one programme, see how to choose a cloud service for 24/7 YouTube Live streaming in India. The right arrangement depends on whether your live source is a file, a local audio chain or a continuously reachable radio output.
Troubleshoot missing audio or video
YouTube shows no data or an inactive stream
Confirm that the encoder is running and that it is sending to the currently selected YouTube ingestion URL. Check the stream key or name character by character, then verify that the encoder has not retained an older destination from another channel or broadcast.
If you changed the stream in Live Control Room, copy the current details again rather than assuming the old key points to the new event. The encoder can show a normal running state while sending to an endpoint that YouTube is not using for the selected broadcast.
The connection or TLS check fails
Confirm that you selected RTMPS rather than an incorrectly entered RTMP destination when RTMPS is intended. Check the complete URL path, port 443 and the server hostname used for the TLS connection. A firewall, proxy or network policy may also interfere with the connection, so test from the actual network where the encoder will run.
YouTube has no audio
First look at the encoder’s audio meters. If they are silent, the problem is between the radio programme and the encoder: wrong device, unavailable network source, muted mixer channel or a source that stops between programme items. If the meters move, check the selected output codec and channel configuration. AAC or MP3 are the relevant supported choices for RTMP and RTMPS in YouTube’s encoder guidance.
Listen to the YouTube preview rather than relying only on the meter. A meter can show activity from an unwanted input, while the encoded output may have a muted channel or an unsupported setting.
YouTube has no video
An audio-only contribution will not satisfy the expected live stream format. Check that the encoder has a video scene or source selected and that it is actually included in the outgoing profile. A missing image file, disabled scene layer or stopped capture source can leave the encoder without video even when its project still opens normally.
Use a simple known-good visual for the first test. Once YouTube receives it, replace it with the station artwork or animated scene and test again.
The stream buffers or health is poor
Check upload capacity, output bitrate, sample rate and keyframe interval. A bitrate that works in a short test may be difficult to sustain when other devices use the same connection. Also check whether the encoder is overloaded and dropping frames before the contribution leaves the computer.
Use YouTube’s health messages to narrow the problem rather than changing several settings at once. Change one relevant setting, test with the same audio and visual material, and record the result.
The radio audio drops during a reconnect
A public radio stream may reconnect differently from a local programme output. Observe what the encoder does when the source briefly disappears. Some workflows resume, while others require the input to be reopened or the encoder to be restarted. This behaviour belongs to the station-side source and encoder combination, not to the YouTube stream key alone.
If an unattended channel matters, test the failure deliberately during a maintenance window. Do not infer resilience from a single uninterrupted night. For a separate discussion of recovery after a short outage, read how to fix a cloud YouTube stream that does not resume after an outage.
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
Can I send my internet radio URL directly to YouTube?
Not normally as a complete YouTube live setup. You need an encoder or compatible workflow that receives the station audio, creates a video stream and sends the combined audio-video contribution using the YouTube ingestion details.
Do I need a camera for an internet radio YouTube stream?
No. You need video, but it can be a station image, programme card, waveform or another suitable visual source. Test it as part of the encoder output because YouTube expects the live contribution to contain video as well as audio.
Which part of the connection is station-specific?
The route from the radio server or playback chain to the encoder is station-specific. It depends on the radio software, operating system, location of the audio and available local or network outputs. The encoder-to-YouTube stage is the more consistent part: configure compatible audio-video settings and use the current stream URL and key.
Can this setup guarantee a continuous YouTube channel?
No. The source, encoder, network connection and YouTube broadcast can all require monitoring or recovery. Test the complete path, document the working settings and decide how the system should behave when the audio source or connection stops.