To send an Icecast radio stream to YouTube with FFmpeg, use the station’s listener URL as the input, add a visual component such as a still image, then send the combined feed to the YouTube Live server URL with your stream key. The chain is simple to describe, but the actual URL, codecs, upload capacity and YouTube stream settings all need checking before you rely on it.
This guide gives you an illustrative command and a way to test each part. It does not promise uninterrupted delivery: FFmpeg, the source station, your network and YouTube’s ingest each have their own failure modes.
Identify the Icecast listener URL
Start with the address that a listener uses to hear the station. It is often a URL for a mount point, such as https://radio.example.org/live.mp3, but the real path and protocol depend on the station. Ask the station operator or check its published player details if you do not know the listener address.
Do not substitute the source-client publishing address. That is used by the station to send audio into Icecast; for this workflow FFmpeg reads the station’s outgoing listener feed. The distinction matters because FFmpeg also documents an icecast:// protocol for sending media to Icecast servers. That protocol is not the normal way to read a listener mount for a relay to YouTube. See FFmpeg’s protocol documentation for the distinction and supported protocols.
Test the listener URL before building the full command. Open it in a browser or audio player that supports the feed. Confirm that it plays the expected station and that access does not require credentials or special headers. A link to the station’s web page is not necessarily the feed URL: find the actual audio address rather than passing the page’s HTML to FFmpeg.
The source may provide MP3, AAC, Opus or another audio format. Do not assume that the file extension tells the whole story, or that the stream uses the same codec all day. If playback works but FFmpeg reports that there is no audio stream, inspect the URL and input details with ffprobe or FFmpeg’s input logging before adjusting the output settings.
A useful way to keep the chain straight is to write down the three addresses separately: the Icecast listener URL, the YouTube ingest server URL, and the YouTube stream key. The first is an input; the latter two form the destination. Mixing up the Icecast source-client address and listener address is a common cause of silence or connection errors.
Prepare a visual component for the radio feed
The example here pairs the live radio audio with a still image, producing a video-and-audio feed for the YouTube broadcast. Prepare an image you have permission to use, with station branding or programme information if that suits the channel. A single image is easier to maintain than an animated visual and avoids introducing movement or extra visual encoding work.
Check the image before starting: make sure it opens locally, has a sensible aspect ratio for your intended live video, and does not contain outdated schedule details. If you want to understand how framing affects the result, see the guide to YouTube Live aspect ratios. Keep a separate copy of the source artwork so you can restore it if you experiment with sizing or format conversion.
The still image is one practical way to provide the visual component in this workflow; it is not a claim that every possible YouTube setup must use the same visual treatment. The example command loops the image while taking audio from Icecast. If you later use a changing visual, test that independently: it can affect bitrate, CPU use and the amount of configuration you need to maintain.
For a small radio station, a static card can be useful when there is no camera or video programme to send. It gives viewers context about what they are hearing, but it does not replace accurate titles, descriptions or rights checks. Make sure any logos, album art or other material in the visual are appropriate for your intended broadcast.
Get the YouTube Live server URL and stream key
In YouTube Studio, create or open a live stream in Live Control Room. YouTube displays the server URL and stream key for the selected stream. Copy the values from there rather than reusing a value from an old note; a key can be changed, and different stream configurations may show different destinations.
Treat the stream key like a password. Do not put a real key in a blog post, screenshot, public repository, shared command transcript or support message. Avoid leaving it in shell history where other users of the machine can read it. If it is exposed, reset it in Live Control Room and update the encoder with the replacement. YouTube describes the key as the credential that lets an encoder send to the stream; read YouTube’s live encoder setup guidance before configuring a broadcast.
For the example below, the destination is represented by a placeholder, not a working credential. Use the exact server and key shown for your stream. YouTube recommends RTMPS for encrypted delivery to its ingest, so prefer the RTMPS server URL shown in Studio when available. Do not assume that a remembered endpoint or an example URL is valid for your current stream.
You also need permission to live stream on the channel and a stream that is ready in Studio. If the Live Control Room does not let you create or configure the broadcast, resolve the channel-side issue before spending time on FFmpeg. This checklist for missing YouTube Live permission covers channel access checks separately.
Build the FFmpeg input and output workflow
The command below is a template, not a tested recipe. Replace the image path, Icecast URL and destination locally; never publish your real stream key. It assumes the Icecast listener supplies audio that FFmpeg can read, and that the installed FFmpeg build includes the required input and output support.
export ICECAST_URL='https://radio.example.org/live.mp3'
export YT_INGEST='rtmps://a.rtmps.youtube.com:443/live2/YOUR_STREAM_KEY'
ffmpeg -re \
-stream_loop -1 -framerate 1 -i station-artwork.jpg \
-i "$ICECAST_URL" \
-map 0:v:0 -map 1:a:0 \
-c:v libx264 -preset veryfast -tune stillimage \
-r 30 -g 60 -b:v 2500k -maxrate 2500k -bufsize 5000k \
-c:a aac -b:a 128k -ar 44100 \
-f flv "$YT_INGEST"
Here the first input is the image and the second is the radio feed. -stream_loop -1 asks FFmpeg to keep reusing the image; -map selects its video and the Icecast input’s audio. The output is H.264 video with AAC audio in an FLV container, sent to the YouTube ingest address. -re reads the inputs at a paced rate rather than trying to process them as quickly as possible.
The video bitrate values in this template are an editorial starting point for testing a static-image feed, not YouTube’s recommendation. A lower bitrate may be reasonable when the visual is simple, but it still needs to fit the stability of your upstream connection. The command also re-encodes audio to AAC instead of relying on an unknown source codec to pass through. If you know the source format and compatibility, copying audio may be possible, but re-encoding is the safer general starting point.
You may need to adjust the input for your station. Some Icecast mounts require authentication, request headers or a particular user agent; some do not provide a format FFmpeg can decode in your installed build. If the feed requires credentials, avoid placing them in a shared script or log. First verify that your FFmpeg build can open the listener URL and identify an audio stream, then adapt the input options with care.
For unattended operation, remember that running this command in a terminal is not the same as supervising it through network or source interruptions. If FFmpeg exits, the broadcast stops until something starts it again. A process supervisor or hosted operating environment may help with restart management, but it adds configuration and cost, and it still needs monitoring. The related guide to creating a 24/7 YouTube stream from MP4 files with FFmpeg covers a different input chain and may help if your source is a file rather than a live Icecast feed.
Apply YouTube ingest settings
YouTube’s published encoder guidance recommends RTMPS, constant bitrate (CBR), and a keyframe every two seconds, with four seconds as the stated ceiling. It lists H.264, HEVC and AV1 video, and AAC or MP3 audio for RTMP/RTMPS ingest. For stereo audio, its guidance gives 44.1 kHz and 128 kbps. These are settings to configure and verify, not a guarantee that a particular network can sustain the stream.
| Setting | YouTube guidance or example | What to check |
|---|---|---|
| Transport | RTMPS recommended | Use the server URL shown in Live Control Room |
| Rate control | CBR | Set a stable target and watch stream health |
| Keyframes | Two-second interval recommended; do not exceed four seconds | At 30 fps, -g 60 requests a 60-frame GOP |
| Video codec | H.264, HEVC or AV1 listed | The template uses H.264 for broad compatibility |
| Audio codec | AAC or MP3 listed for RTMP/RTMPS | The template uses AAC stereo |
| Stereo audio | 44.1 kHz and 128 kbps recommended | The template sets -ar 44100 and -b:a 128k |
| 720p30 H.264 bitrate | 8 Mbps recommended | The template’s lower example is not YouTube’s recommendation |
The bitrate guidance is not a target to copy blindly. YouTube’s current table recommends 8 Mbps for 720p30 H.264, while this illustration uses a lower video rate for a static image. If you choose a resolution and bitrate, base them on the available stable upload capacity, leave headroom for variation and check the actual health indicator in Studio. Raising the bitrate beyond what your uplink can sustain can make delivery less stable, not more professional.
The -g 60 setting corresponds to a two-second interval at the command’s 30 frames per second. The bitrate flags ask for a target and a maximum, but you should verify how your FFmpeg build and chosen encoder behave rather than assuming a flag guarantees YouTube’s preferred output. For current recommendations and resolution-specific values, consult YouTube’s encoder settings and bitrate guidance.
Start and verify the live broadcast
Use a scheduled or otherwise prepared live event in Live Control Room. Start FFmpeg and look for the incoming preview there before you make the stream public. YouTube’s guidance says to test before starting a live stream; that check is valuable because it exposes key, input and output mistakes while you can still correct them.
A practical test has several parts. Confirm that the preview shows the intended visual, that audio is present and in sync, and that the channel information is correct. Watch the stream health messages in Live Control Room while FFmpeg runs. If you see warnings, note when they begin and whether they coincide with a source or network change. A clean local FFmpeg log does not prove the viewer-facing broadcast is healthy.
When the preview and settings are right, use the Live Control Room workflow to select Go live. Keep the control room available during the broadcast and continue checking stream health. If you are testing from the same machine that runs FFmpeg, make sure its sleep settings, network access and power arrangement are suitable for the test period. The point is to find likely failure conditions, not to treat a successful short test as proof of uninterrupted delivery.
At the end, stop FFmpeg’s output and end the broadcast in Live Control Room. YouTube says streams under 12 hours are automatically archived; do not assume the same archive outcome for a longer stream without checking the current platform guidance. For a 24/7 station, plan how you will handle intentional restarts and verify the channel’s actual archive and live status after each change. A guide to nonstop YouTube radio streams for different music moods may be useful when you are planning more than one station feed.
Troubleshoot input and connection issues
No incoming preview: Recheck the YouTube server URL and key in Live Control Room, confirm that the destination uses the expected protocol, and verify that FFmpeg is producing output. Check outbound network or firewall rules if the connection cannot reach the ingest address. If the key may have been exposed, reset it rather than continuing to troubleshoot with a compromised credential.
Preview appears, but audio is missing: Confirm the Icecast address is the listener mount and plays in an audio player. Check that FFmpeg identifies audio on the second input and that -map 1:a:0 matches it. If the mount is not the format or stream you expected, use ffprobe or FFmpeg input logs to inspect it; do not try to solve an input problem by changing YouTube’s video bitrate.
FFmpeg cannot open the source: The station may require authentication or headers, the mount may be private, or the installed FFmpeg build may lack a needed protocol feature. Confirm the requirements with the station operator and test the same listener URL independently. If the source codec is unsupported by the installed build, you may need a suitable build or a different input method.
The stream buffers or drops: Reduce the video resolution or bitrate and retest against the stable upstream capacity, rather than the best speed seen in a single network test. Check whether other traffic shares the connection and monitor YouTube’s health messages. A station feed that is itself intermittent can also interrupt the relay, so compare the source player with the outgoing YouTube preview when diagnosing a drop.
The process exits unexpectedly: FFmpeg does not promise to recover from every source or network interruption by itself. Review its output and decide whether a supervisor or an operator restart is appropriate. If the broadcast is intended to run overnight, test the restart procedure deliberately and check the resulting YouTube state; do not assume a restarted process will automatically put the event live again.
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 use the Icecast source-client address as FFmpeg input?
No. For this direction, use the listener or playback URL for the mount point. The source-client address is used to publish audio into Icecast, while this workflow reads from the station’s listener feed and sends onward to YouTube.
Why does the example include an image?
The example combines radio audio with a still image so its output has video as well as audio. That is the chosen visual approach for this workflow, not a statement that all encoder setups have identical requirements. Use artwork you are entitled to show and confirm that the preview displays it correctly.
Can I leave FFmpeg running without checking it?
A running process is not proof that the source, network and YouTube ingest remain healthy. Monitor FFmpeg and Live Control Room, and plan how you will respond if the process or source stops. For longer broadcasts, verify YouTube’s current guidance about stream duration and archives rather than assuming a continuous recording.
What should I do before using this for a regular station?
Test with the actual listener URL and stream configuration, verify audio and video in the preview, and check health messages before selecting Go live. Keep the key private, make a restart plan, and test that plan. When the file and channel are ready, start free — 24-hour trial, no card.