To send a Shoutcast stream to YouTube Live with FFmpeg, you relay audio from your station’s actual network stream URL to the ingest endpoint for a YouTube Live event. The exact URL and command depend on the station, its audio format, your FFmpeg build and the event’s settings, so treat examples as a starting point rather than a universal recipe.
The job has two endpoints: FFmpeg must be able to read the station, and YouTube must be ready to receive the broadcast. Check each endpoint separately before leaving the relay running. Neither a successful connection nor reconnect options guarantee an uninterrupted broadcast.
Check YouTube Live access and create an event
Before changing your station or writing a command, confirm that you can create a live event on the channel you intend to use. In YouTube Studio, open Live Control Room and follow YouTube’s current steps to schedule or create a broadcast. Access and event settings belong to the channel and event; an FFmpeg command cannot establish that the channel is eligible or that the event is configured as intended.
Once the event exists, find the ingest details shown for that event: the server or ingest URL and the stream key. Use the details YouTube presents for this broadcast, not an address copied from an old tutorial or another event. YouTube’s official streaming setup instructions explain where to configure a stream and obtain its connection details. Check the current instructions in Studio, because the interface and available choices may change.
For an encrypted RTMP connection, YouTube directs users to use the RTMPS address when it is provided for the setup. RTMPS carries RTMP over TLS. Do not assume that the address and key are interchangeable with other protocol choices: both ends of the relay need to agree on the selected ingest method. YouTube also documents HLS ingestion, which follows a different setup path using an HLS protocol selection and an HTTPS ingest address. It may suit a workflow that specifically needs HLS, but it is not automatically a better fit for a straightforward FFmpeg relay.
Make a note of the event’s intended start and privacy settings as well as its ingest details. A command that reaches the ingest endpoint does not by itself start or publish an event in the way you expect. Use Live Control Room preview to check the incoming feed, then follow the event’s controls to start the broadcast. For guidance on how a continuous broadcast fits a channel’s content, see whether looping videos on YouTube Live is considered reused content; that is a separate question from whether FFmpeg can connect.
Find the station’s actual stream URL
A Shoutcast station’s public listening page is not necessarily the URL FFmpeg should read. The page may contain a player, a playlist file, an embedded player address or a link that redirects. You need the actual audio stream endpoint that the station operator exposes to listeners or relay clients. It may include a path, mount point, port, query string or authentication information. There is no single Shoutcast URL format that applies to every station.
Start with the station’s own control panel, provider documentation or instructions from whoever operates the server. Look for a field described as a direct stream URL, mount, relay URL or listener URL. If you manage the station yourself, check the server configuration and the public address you have already verified with a player. If someone else manages it, ask them for the exact client URL, whether authentication is required, and whether it is intended for direct playback or for a playlist download.
Keep the complete address intact when testing it. Removing a path or query parameter because it looks optional can point to a different resource. Conversely, a browser-facing address that redirects to a playlist may not work as a continuous audio input. Where credentials appear in the URL, do not paste that address into a public forum, screenshot or shared log. Ask the operator for a safe way to provide access if the credentials need to be rotated or kept separate.
A useful first test is to open the supplied address in a player that can handle network audio, or use a local FFmpeg probe in a terminal. Confirm that the station is audible and that playback continues, rather than merely confirming that a web page loads. If you need the relay to run without leaving your own computer on, you are weighing a separate operating choice: VPS bandwidth cost for a 24/7 YouTube stream covers the costs and trade-offs of hosting an always-on process.
Test access and identify the audio format
Before publishing, find out what the station actually sends. FFmpeg’s ffprobe utility, where included in your installation, can inspect a network input; FFmpeg itself can also report stream information when opening it. The commands and available options depend on the local build. If a probe cannot open the URL, first check the address, authentication, network access and whether the server permits direct client connections. A failed probe does not by itself show that the station is offline.
Record the audio codec and any reported sample rate, channel layout and metadata. These details help you decide whether the incoming audio can be passed through or needs conversion. The server may provide useful station or track metadata, incomplete metadata, or none. FFmpeg’s protocol documentation describes SHOUTcast and ICY metadata handling, but protocol support does not mean every station publishes meaningful titles or that those titles will appear at YouTube as desired. Check the actual input and the YouTube preview rather than relying on the station directory listing.
If the station requires authentication, verify the permitted form with its operator before putting credentials in a command. A URL can appear in shell history, process listings, configuration files and logs. Treat any credential as sensitive, including a token embedded in a query string. Do not test with a live YouTube key in a command pasted into a chat or support request.
You can also confirm what your local FFmpeg installation supports by checking its version and help output. Builds can differ in compiled-in protocols, options and encoders. The FFmpeg protocol documentation describes protocol-level behaviour, including SHOUTcast/ICY handling; it is not a guarantee that a particular server URL will work with every build. If the station uses an unusual codec or protected endpoint, get the operator’s requirements before selecting an output mode.
Understand FFmpeg input and YouTube output
The relay has an input side and an output side. FFmpeg opens the Shoutcast URL, reads its audio stream and then sends a selected stream to YouTube’s ingest URL using the event’s key. In practical terms, input options and authentication relate to the station; output protocol, URL and key relate to YouTube. Keeping those roles distinct makes errors easier to diagnose.
There are two broad ways to handle the audio. Stream copy passes compressed audio packets through without decoding and encoding them again. The FFmpeg documentation describes stream copy as copying packets without decoding, filtering or encoding. It can avoid extra processing and another lossy encode, but only works when the source stream is acceptable to the destination and the container or protocol can carry it as configured. It cannot apply audio filters or convert a codec.
Transcoding decodes the source and encodes it again in a chosen output format. That can solve a compatibility problem or allow processing, but it uses more compute and creates a new encode. Do not select a codec, bitrate, sample rate or channel layout by habit: check YouTube’s current ingest guidance and the actual event configuration, then choose settings the source and local build support. YouTube’s current live encoder settings guidance is the primary reference for its requirements; review it before committing to an output recipe.
A common source of confusion is assuming that a radio stream is automatically a complete YouTube broadcast. A station may supply audio only, while the event and ingest arrangement may require or expect a video-bearing feed. The appropriate handling depends on current YouTube settings and the selected ingest protocol. The evidence here does not establish one rule for every audio-only event configuration. Verify the preview in Live Control Room and consult YouTube’s current documentation if you need to add a visual component.
Adapt the command to local details
Do not copy a command from a tutorial until you have filled in its assumptions. In the outline below, every capitalised value is a placeholder, not a working address or credential. It illustrates the two endpoints and the choice between passing audio through and converting it; it has not been tested against your station or event.
ffmpeg -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max DELAY \
-i 'SHOUTCAST_INPUT_URL' \
-vn -c:a AUDIO_HANDLING \
-f flv 'YOUTUBE_INGEST_URL/STREAM_KEY'
This outline is not a universal command. Confirm the reconnect options are available in your build, and replace the input with the exact station URL supplied by its operator. Use the ingest URL and key from the YouTube event, applying the protocol and URL format shown there. Do not add or remove path components based on a generic example. The output format and audio handling must match what the selected YouTube ingest setup accepts.
For AUDIO_HANDLING, copy is only appropriate when the station’s audio stream is compatible with the selected output. If the probe shows that it is not, select an encoder and parameters supported by both the build and YouTube’s current requirements. The command outline omits those parameters deliberately; there is no one encoding recipe established for every Shoutcast source and event. A conversion choice should follow the evidence from the probe and the official ingest guidance, not a guess based on the station’s name or genre.
The -vn option indicates that no video stream is being selected from the input. It does not create a visual track. If your YouTube event setup requires video, this outline is insufficient until you choose a compatible video-bearing source or another supported arrangement. Verify the selected configuration in YouTube’s preview before treating the relay as ready.
Read the FFmpeg command documentation for option placement and behaviour. Input options generally need to be associated with the input they affect, while output options belong with the output. The official FFmpeg command documentation explains stream selection, stream copy and option handling. If you change one element at a time and keep a record of the working input, output mode and event, you can distinguish a URL issue from a codec or event-setting issue. For a video-based loop instead of a radio input, the guide to looping multiple MP4 files on a 24/7 YouTube livestream covers a different source workflow.
| Choice | What it changes | When it may fit | What to check |
|---|---|---|---|
| Stream copy | Passes compatible audio packets through without re-encoding | The source codec can be carried by the selected output and needs no filtering | Probe the source and confirm YouTube accepts the resulting feed |
| Transcoding | Decodes and re-encodes the audio | Conversion or audio processing is needed | Confirm supported encoder, output settings and available compute |
| RTMPS | Sends the event feed using RTMP over TLS | YouTube provides an RTMPS address for the event | Use the event’s own URL and key |
| HLS | Uses YouTube’s HLS ingest workflow | The workflow needs HLS-supported capabilities | Select HLS in the event setup and use its HTTPS ingest URL |
Protect the stream key
A stream key is a credential for the YouTube ingest endpoint. Anyone who obtains a usable key may be able to send a feed to that event, so treat it with the same care as a password. Do not include a real key in an article, public command example, screen recording, ticket or screenshot. The same caution applies to station credentials embedded in the input URL.
If you run FFmpeg interactively, remember that commands may remain in shell history. A running process may also expose its arguments to other users on the same machine, depending on the operating system and permissions. On a shared computer or rented host, consider how you store and restrict access to configuration and logs. Do not assume that hiding the terminal window protects a key.
Use YouTube’s key-management controls if you believe the key has been exposed, and check the current instructions in Live Control Room before replacing it. After changing a key, update the relay’s stored output details and test the new event connection. Keep a private record of which configuration belongs to which event, but avoid recording secrets in plain notes that are shared or synchronised without access controls.
Test audio and reconnect behaviour
Run a short, attended test before relying on the relay. Start FFmpeg with the intended station input and event output, then inspect Live Control Room’s preview. Confirm that the event receives audio, that the level is usable and that any station information you expect is actually present. A stream opening successfully at the command line is not enough: YouTube must receive a compatible feed, and the preview is where you can check the result at the platform end.
Listen for silence, clipping, unexpected channel behaviour and gaps. Compare the preview with the station’s own player. If audio is missing, first check whether FFmpeg selected the correct input stream and whether the source codec is compatible with the output. If the preview is present but the station’s title or track details are not, treat that as a metadata behaviour question rather than proof that the audio relay is broken. Metadata handling varies; do not promise that it will transfer or display as intended.
FFmpeg documents reconnect options for network errors and streamed inputs. Options such as those shown in the outline can help a process retry in some conditions, and FFmpeg also documents how to treat EOF as an error for endless sources. Exact option support and behaviour depend on the build and failure type. Reconnection cannot prevent the station from going offline, repair every network failure, guarantee recovery, or ensure that YouTube keeps the event live. Test the actual station and build, including what happens after a controlled input interruption, before you depend on it.
For a channel that needs an always-on result, decide who will notice a failed relay and what they will do. A local FFmpeg process depends on the host computer, its network connection, power and operating system continuing to behave. If you choose to host it elsewhere, that is an operational decision rather than a requirement of FFmpeg; compare the expected running cost and the effort of maintaining the process. For content that relies on a prerecorded loop rather than a live radio input, see the OBS guide to streaming Indian folk music 24/7 on YouTube for a different workflow.
If your station URL, command and event are already prepared but keeping a local computer on is the specific problem, StreamNeo can remove that computer-running burden for a file-based YouTube broadcast: you upload a video, provide the event stream key, and the broadcast runs with your computer switched off. It does not relay a live Shoutcast input, so it is not a substitute for this FFmpeg workflow when the source must remain a live radio station.
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
How do I relay my Shoutcast radio stream to a YouTube live stream?
Find the direct stream URL from the station operator, test it and identify the audio format. Then create a YouTube Live event, use its ingest details in FFmpeg, and verify the incoming feed in Live Control Room before starting the broadcast.
Can I use one Shoutcast URL format for every station?
No. A station may use a particular host, port, path, mount, query string or authentication method. Use the exact address supplied for your station and test it; a directory or player page is not necessarily the audio endpoint.
Should I use copy or transcode the audio?
Use stream copy only if the source audio is compatible with the selected YouTube ingest configuration and you do not need filtering or conversion. Otherwise, transcode using settings supported by your FFmpeg build and the current YouTube guidance, then verify the preview.
Will FFmpeg keep the broadcast from being interrupted?
Reconnect options may help FFmpeg recover from some input errors, but they do not guarantee continuous service or fix every failure. The station, network, host computer, FFmpeg process and YouTube event can each fail, so test recovery and plan how you will monitor the relay.