To stream an online radio station to YouTube from Linux, you need to read its audio feed, pair that audio with a visual, encode both for YouTube Live, and send the result to the ingest endpoint shown in YouTube Live Control Room. FFmpeg, Liquidsoap and OBS can each fit that workflow, but the right choice depends on the feed, whether you have a desktop session, and how much radio-specific processing you need.
A station’s web player is not necessarily the audio feed you can relay. Start with the direct stream URL and format published by the station, then test it locally before building a long-running broadcast around it. A relay that works in a browser is not automatically a reliable unattended channel.
Check the radio feed and your Linux setup
Find the station’s published stream URL, not just the page containing its player. It may be a direct network audio URL or a playlist that points to one or more streams. The station’s documentation or support team is the best place to confirm which address is intended for third-party players. There is no single extraction method that works for every station, so do not assume that a browser player’s page URL is the source.
Identify the stream format and transport. Common possibilities include MP3 or AAC audio delivered over HTTP, but the feed could use another format or a playlist wrapper. The distinction matters: your player or media tool must be able to open the actual resource and decode its audio. If a URL works only after a browser loads a page or sets a session cookie, that is a different problem from a straightforward network audio input.
Check the Linux environment you plan to use. A desktop machine with an active session makes a graphical workflow possible. A headless machine, such as a Linux VPS, usually favours command-line tools and a process that can run without an open desktop. Neither environment guarantees continuous delivery: power, network access, source availability and process recovery still matter.
Before choosing a tool, verify that you can play the feed on the intended machine and listen for a while. Notice whether it starts promptly, whether audio pauses or changes format, and whether the source redirects. A short successful playback confirms basic access, not that the station permits rebroadcast or that it will remain available. Check the station’s terms and seek rights-holder permission where needed; technical ability to relay audio does not establish permission to do so.
Choose a workflow: FFmpeg, Liquidsoap or OBS
Think of these as different ways to assemble and operate the same chain: network audio in, a visual source, encoding and output to YouTube. FFmpeg is a practical command-line path for a simple relay. Liquidsoap is worth considering when radio-oriented scheduling or processing belongs in the workflow. OBS is often easier to configure visually when you have an active desktop session and want to inspect the scene while it runs.
| Workflow | Often fits when | Main trade-off |
|---|---|---|
| FFmpeg | You need a direct command-line relay and can maintain its input and output configuration | Flexible, but command-line options and recovery behaviour need deliberate testing |
| Liquidsoap with an FFmpeg output | You need radio-oriented source handling, scheduling or processing as well as an encoded output | More components to understand and maintain than a simple relay |
| OBS | You have a desktop session and want to arrange audio and visual sources in a graphical scene | A graphical desktop is a less natural fit for a minimal headless setup |
These are not rankings. If all you need is to combine one accessible audio feed and a still image, FFmpeg may be a direct route. If you already use Liquidsoap to manage radio sources or schedules, it can keep that work together and use an FFmpeg-based output. If you need to see and adjust a scene, OBS gives you a visual control surface, provided the machine has a suitable desktop session.
Recovery is a separate decision from initial setup. A command that starts once does not tell you what will happen if the source stalls, the network drops or YouTube disconnects. Determine how the chosen process reports errors, whether it can reconnect, and how you will notice when it needs attention. For unattended operation, make monitoring and restart behaviour part of the deployment plan rather than treating a tool name as an uptime guarantee. A home computer also depends on local power and broadband; a Linux VPS is an optional alternative, not a prerequisite or a failure-proof host.
For examples of the broader always-on operating problem, see this guide to keeping a YouTube FFmpeg stream running during power cuts in India. Its subject is a different failure mode, but the practical point applies here too: plan how you will detect and respond to a dropped process.
Read and validate the network audio source
Once you have the published URL, test that the chosen tool can open it and decode it. FFmpeg’s protocol documentation describes its network protocols; the actual input handling also depends on the stream format and demuxer. Treat a stream URL as data to validate, not as proof that every downstream stage is working.
Separate source problems from encoding problems. First confirm you can hear the station on the Linux machine. Then verify that the audio reaches the broadcasting tool without long silence, clipping or unexpected gaps. If the station supplies a playlist, check how it points to the underlying media and whether the feed requires a particular URL. Do not use a guessed address copied from an unrelated station or assume that an Icecast, Shoutcast or other label determines the full setup by itself.
FFmpeg can be used as the relay’s command-line media component. Its protocol reference covers network input and output options, but it does not establish a universal command for every station URL. Inputs vary, as do installed FFmpeg builds and the desired audio/video combination. Build the configuration around the feed you have tested, and consult the documentation for the relevant input and output formats rather than pasting a command designed for a different source.
Liquidsoap can be useful when the radio source needs more than simple pass-through, such as source selection or scheduling. The Liquidsoap book documents an output pattern using FFmpeg and a YouTube RTMP destination. Use that example to understand the shape of a pipeline, not as a substitute for current YouTube transport and encoding requirements. If you have no scheduling or radio-processing need, adding another layer may increase the number of things you must diagnose.
With OBS, configure the audio source so that the station feed is audible in the scene and does not accidentally include unrelated desktop audio. Check the audio meter while listening to the actual output. A moving meter only confirms signal is present; it does not prove the feed is intelligible, correctly balanced or free from clipping. Keep a local playback check in the test plan.
Add a visual signal for YouTube Live
A radio feed supplies audio, but the YouTube Live encoder workflow described here sends a compatible audio-and-video stream. Add a visual signal: for example, a station image, a programme card or a looped visual that you have permission to use. YouTube’s encoder guidance sets out video and audio encoding recommendations for live streams.
A still image is simpler to prepare, but it can look static for the whole broadcast. A looped visual can show a schedule, current programme information or a subtle animation, but it brings another file and another possible point of failure. Check that the visual remains present throughout playback rather than showing only at the start. If you use programme details or a clock overlay, verify that they stay accurate; an outdated label can mislead viewers.
In an FFmpeg workflow, the visual is another input to combine with the radio audio before encoding. A still image and a looping video behave differently as inputs, so consult FFmpeg’s documentation for the chosen input and muxing approach. For Liquidsoap, the radio-oriented part of the pipeline may still need a separate visual input or an FFmpeg output arrangement capable of supplying video. Confirm that the resulting output includes both streams before sending it live.
In OBS, add the image or video as a scene source and arrange it with any text or branding. Inspect the actual canvas and output preview: a source can be present but cropped, hidden behind another source or scaled poorly. Keep the design legible at the output resolution and avoid small text that viewers cannot read on a phone. Check that looping media is set to repeat if the broadcast lasts longer than the clip.
The visual need not be elaborate. A clean station image with the programme name can be more useful than motion that distracts from listening. If you are adapting a pre-recorded video loop, this guide to looping a video on YouTube Live covers the separate choice of how to repeat video content; for a radio relay, the important point is that the audio feed remains the programme source and the visual is a deliberate accompaniment.
Configure encoding and YouTube ingest
In YouTube Live Control Room, create or select the live stream and use the ingest endpoint and stream key shown for it. Do not copy a key into public notes, a shared script repository or a screenshot. Prefer RTMPS when available: YouTube recommends it as the secure extension to RTMP for encoder ingestion. Use the current values displayed in Live Control Room rather than a URL copied from an old tutorial.
YouTube’s general encoder guidance recommends H.264 video, constant bitrate (CBR), and a two-second keyframe interval, with the interval not exceeding four seconds. It lists AAC or MP3 for audio and recommends 44.1 kHz and 128 kbps for stereo audio. These are YouTube recommendations, not a guarantee that every encoder, codec and protocol combination will work together. Check the current guidance and the selected protocol before choosing exact settings.
There is no single video bitrate to prescribe without knowing the output resolution, frame rate and available upstream bandwidth. Choose a video mode supported by your workflow, then consult YouTube’s current recommendations for that mode. Leave headroom for normal variation in your internet connection; if the upstream cannot sustain the chosen output, the stream may buffer or lose health. A lower, stable output can be more useful than a higher setting that your connection cannot reliably carry.
The transport choice affects compatibility and latency. RTMPS is the usual encoder route described in YouTube’s guidance. YouTube also documents HLS ingestion, but it has protocol-specific requirements, including an HTTPS stream URL, MPEG-TS segments between one and four seconds, a rolling playlist with no more than five outstanding segments, and HTTPS POST/PUT. HLS carries higher latency because it sends segments. Unless your workflow specifically needs HLS and meets its requirements, do not select it just because it appears as an available protocol.
The tool and the destination must agree about the output. With FFmpeg, that means the input, selected codecs, output container or muxer and YouTube endpoint must form a compatible pipeline. Liquidsoap can coordinate radio processing and use an FFmpeg output; the book’s example is a shape to adapt, not a current settings authority. OBS collects its sources in a scene and sends the configured output to YouTube. In all three cases, verify the actual outgoing audio and video rather than assuming that a successful connection means the programme is correct.
If you have already planned a continuous video channel, the article on YouTube Live settings for a 24/7 nature video playlist can help frame the separate video-mode decisions. For a radio station, do not copy another channel’s bitrate blindly: your chosen resolution, frame rate, encoder and available bandwidth determine what is sensible.
Test the whole path before launch
Run a controlled test before making the broadcast public. Use a private or otherwise controlled stream setting available in Live Control Room, and confirm what viewers will receive. Listen from the YouTube playback, not only from the Linux machine’s local player. That checks more of the actual route: source access, audio capture or decoding, encoding, ingest and playback.
Test both picture and sound. Confirm that the image or loop is visible, that video continues moving if it is meant to, and that audio stays audible without silence or clipping. Watch long enough to see the feed change naturally if it has programme transitions or brief pauses. Check YouTube Live Control Room for stream-health messages; the Live Streaming API documentation is useful background on YouTube’s live-stream resources, but the Control Room is where you should inspect the health of your actual encoder session.
A successful short test does not prove that a 24/7 broadcast will remain connected. Test the failure handling you can safely test: how you learn that the process stopped, who can restart it, and whether the input reconnects after a temporary network interruption. Avoid exposing the stream key while sharing logs or screenshots. Keep a record of the working configuration with credentials removed, so you can recover from a change without publishing secrets.
For an unattended channel, decide who checks the stream and how often, even if automated monitoring is also present. A local machine needs stable power and connectivity; a remote host still needs monitoring and an understood restart path. Check whether the station source itself is permitted for continuous rebroadcast and whether its terms could change. No encoder setting removes those operational or rights questions.
If the main burden is maintaining a Linux process and its recovery behaviour, consider whether you need to host the relay yourself at all. StreamNeo can remove the need to keep your own Linux computer running by turning an uploaded video into a YouTube broadcast; that suits a pre-prepared video loop, not a live relay of an external radio feed. It is YouTube-only, so choose it only if that distinction matches your channel.
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 stream an online radio station to YouTube from Linux?
Use the station’s published direct feed URL, add a visual source, encode audio and video to settings compatible with YouTube Live, then send the output to the endpoint and key from Live Control Room. FFmpeg is a direct command-line route, while Liquidsoap or OBS may fit other processing and operating needs. Test playback and stream health before making the broadcast public.
Can I send radio audio to YouTube Live without OBS?
Yes. FFmpeg can form a command-line workflow, and Liquidsoap can be used where radio-oriented processing or scheduling is part of the setup. In the audio-and-video encoder workflow covered here, include a visual source rather than sending only the radio audio.
Do I need a Linux VPS for a 24/7 radio stream?
No. A VPS is one possible way to run a headless process without relying on a home computer, but it is not required. Whichever machine you use, plan for power or host availability, connectivity, monitoring and recovery, and do not assume any host will prevent interruptions.
Does a working stream URL mean I can rebroadcast the station?
No. A URL that can be played technically does not establish permission to relay it on YouTube. Check the station’s terms and obtain permission from the relevant rights-holder where needed.