To turn an internet radio stream into a 24/7 YouTube video with a waveform, combine the station’s audio with a video scene that displays a waveform, then send the resulting feed to YouTube Live through an encoder. OBS offers a graphical way to compose the scene; FFmpeg is a command-line alternative.
Before building either version, check that your channel can livestream and that you have the rights to relay the audio. A continuous broadcast does not guarantee that YouTube will save one complete replay, so plan separately for any archive you need.
Why radio audio needs a video layer
An internet radio station sends audio, but YouTube Live expects an encoded audiovisual feed. You therefore need a video layer as well as the audio source. That layer could be a still image, a looping visual, or a scene with a waveform that moves in response to the sound.
The waveform is not something YouTube adds to the broadcast. Your chosen software has to create it, and its visualiser needs access to the audio being sent to the encoder. If it analyses a different signal, or receives no signal at all, the picture may be static or out of sync with what listeners hear.
Think of the setup as three connected parts: the radio audio input, the video composition, and the encoder output to YouTube. A failure in any one part can leave you with silence, a frozen visual, or no live feed. Keep the design simple at first: a station name, a restrained background, and a clearly visible waveform are easier to inspect than a scene full of moving elements.
A waveform can help viewers see that the broadcast is active, but it does not replace useful channel information. Give the video a readable station identity and make sure the title and description accurately describe the programme. If you are considering a broader ambient or music format, the practical considerations in this guide to running an ocean-sounds channel are relevant too.
Check channel eligibility and content rights
Check livestream access in YouTube Studio before you spend time configuring the encoder. YouTube’s live-streaming eligibility guidance explains the channel requirements, including verification and restrictions. The channel must be verified and must not have had a live-stream restriction in the previous 90 days. Check the current official page because account status and platform requirements can change.
Rights need equal attention. The fact that a radio station is already available online does not, by itself, give you permission to rebroadcast it on YouTube. Establish that you have the necessary rights for the music and other material in the stream, for every territory in which the content may be exploited. YouTube’s livestream terms set out the broadcaster’s responsibility for rights, including music licensing rights.
YouTube says that live streams are scanned for third-party content. If copyrighted material remains in a broadcast, YouTube may interrupt or terminate the stream. Its copyright guidance for live streams also notes that a licensed stream may still be interrupted if the rights holder has not allowlisted the channel through Content ID. If you believe a licence applies, ask the rights holder whether channel allowlisting is required; do not assume that a licence alone will prevent an interruption.
Keep evidence of permissions and the scope of any licence, including the channel and the territories or uses it covers. This is a practical record-keeping step, not a guarantee that a stream will be approved or remain uninterrupted. If you are relaying a third-party station, get permission from the appropriate rights holder rather than relying on the station’s public availability.
Choose OBS or FFmpeg
OBS and FFmpeg can both be used to combine audio with a video scene and send it to YouTube, but they suit different working habits. OBS is a graphical application: you arrange sources in a scene, inspect the result, and use its controls to start or stop the broadcast. FFmpeg is configured through command-line arguments and is often paired with process-management tools when it needs to run unattended.
| Consideration | OBS | FFmpeg |
|---|---|---|
| Scene setup | Arrange a background, text and visualiser in a graphical interface | Define the audio and video inputs and processing in a command |
| Waveform approach | A browser source can display a local HTML visualiser, if it works with the chosen audio path | Requires a suitable visualisation and video-processing pipeline |
| Where it runs | A computer with an available desktop session is a natural fit | Can run on a computer or, if you can manage it, an always-on server |
| Day-to-day operation | Easier to inspect visually and adjust interactively | Easier to automate after configuration, but harder to diagnose without command-line experience |
| Main trade-off | The computer and session must remain available | You must maintain the command, process and monitoring yourself |
These are operational differences, not comparative performance results. There is no basis here for claiming that one option is more reliable, uses less processing power, or costs less in every setup. OBS’s guide to streaming to YouTube is a useful starting point for its interface, while YouTube’s current encoder documentation should take precedence for output settings.
Choose OBS if you want to see the scene and troubleshoot sources through a desktop interface. It is also a reasonable choice if you already have a computer set up for a continuous broadcast. For other scene and operating details, see the guide to configuring OBS for recorded lessons on Windows.
Choose FFmpeg if you are comfortable working with commands and want to define the composition and delivery in a repeatable configuration. An always-on server can be part of that arrangement, but it is not a YouTube requirement. The trade-off is that you need to understand the inputs, output options, and how you will notice and recover from a stopped process. The FFmpeg loop-stream guide covers related considerations for a different kind of video source; it does not establish a ready-made waveform command for this radio use case.
Connect the radio audio source
First identify the actual audio URL or input method supplied by the station. A station page may play audio in a browser without exposing a direct stream address, and the web page itself is not necessarily a usable encoder input. Check the station’s own documentation and terms, and confirm that you are authorised to relay the feed. Do not guess a URL from a player or bypass access controls.
Next decide how the audio will reach both the encoder and the visualiser. The video encoder needs the audio to publish the broadcast; a waveform visualiser also needs a way to analyse that same audio. In an OBS workflow, the audio might be added as a source and the visualiser might be a browser source rendering a local page. That arrangement is only a design concept: compatibility depends on the visualiser and the way audio is exposed to it. Do not assume that any browser visualiser will automatically hear another OBS source.
A useful planning check is to draw the path on paper: station feed to audio input, audio signal to visualiser, then the combined scene to the encoder output. If the waveform is driven by a separate microphone or desktop sound capture, it may react to the wrong audio or capture system sounds. Make sure the signal you monitor is the signal you intend to broadcast.
Before going live, listen to the selected input locally and check for silence, clipping, unwanted notifications, or long gaps. A station may pause, change its stream address, or become unavailable. Decide what viewers should see and hear during a source interruption, and whether the encoder should stop, show a fallback image, or resume when the source returns. The right behaviour depends on the station and the tools; it is not guaranteed merely by selecting a stream URL.
Keep the YouTube stream key private. YouTube describes it as the credential that lets an encoder send a feed to the correct live event. Use the key provided in YouTube Studio, avoid placing it in public notes or screenshots, and replace it if you believe it has been exposed. The guide on resetting or replacing a stream key explains how to handle that change without rebuilding unrelated parts of a setup.
Render and review the waveform
For an OBS composition, make a scene with a background and the required station details, then add a visualiser source that can render a waveform. One suggested approach is a browser source pointed at a local HTML visualiser. Treat this as a possible implementation route rather than a verified plugin or production-ready recipe: the visualiser must work with the chosen browser source and receive the same audio that goes to the stream.
For an FFmpeg composition, the equivalent job is to combine the radio audio with a video source and an appropriate waveform-rendering step. The exact filters and command depend on the audio input and the visualisation you choose. Do not copy a command intended for a still image or another audio source and assume it will produce a correct, synchronised waveform. Check current FFmpeg documentation for the options you plan to use; the available material here does not verify a specific waveform command.
Review the picture at the size viewers will see. Check that the waveform is legible on a phone, does not obscure station identification, and responds at a pace that makes sense for the programme. If the line is too thin or the background too busy, simplify the design. A readable but modest waveform is more useful than a complicated animation that is difficult to follow.
Also review the scene after audio changes. If you switch stations or alter the input routing, verify that the visualiser still reacts to the intended signal. Watch for a frozen browser source, a silent audio meter, or a mismatch between the waveform and the sound. These checks establish that the local composition appears to be working; they do not prove that the YouTube feed will remain live continuously.
Send the combined feed to YouTube Live
Create or select the live broadcast in YouTube Studio, then use the stream key and server details shown there in your encoder. Follow YouTube’s current encoder settings guidance for protocol, resolution, frame rate and bitrate. YouTube recommends RTMPS and advises choosing settings that are reliable for your available connection. There is no universal bitrate to apply without considering the selected output and the connection carrying it.
For OBS, select YouTube as the service where appropriate, enter the stream key, and check the output and audio settings against YouTube’s current guidance. For FFmpeg, configure the destination and encoding options in the command or service that starts the process. In either case, a correct local preview is not enough: confirm in YouTube Studio that the incoming feed is recognised and that the live event has the expected picture and sound before treating the setup as ready.
Observe the connection you will actually use. If upload capacity varies, reduce output demands or choose a setting that the connection can sustain rather than chasing a higher resolution. A stream that repeatedly buffers is not improved by settings that look better on paper. Test during the conditions in which the channel will normally run, particularly if other people or devices share the connection.
Plan how you will detect trouble and what action you can take. OBS has visible controls, but the computer still needs to stay on and the session must remain available. FFmpeg can run without an interactive desktop, but a background process still needs monitoring and a way to restart after a failure. Neither choice removes the need to check the broadcast. For unattended operation, decide who receives an alert and who can respond if the source, connection, encoder, or YouTube event stops behaving as expected.
Plan for archive limits on long streams
“Live 24/7” describes the intended broadcast schedule; it does not mean YouTube will retain one complete archive. YouTube’s archive guidance says streams under 12 hours can be automatically archived and warns that streams exceeding 12 hours may not be captured at all. A long-running live event therefore should not be your only copy of material you want viewers to replay.
If replay matters, arrange a separate recording and a practical way to store and check it. A local recording can use disk space quickly, and it needs its own monitoring: an encoder may continue streaming even if recording has stopped, or recording may fill the available storage. Decide how long you need to retain files, who will check them, and how you will divide or publish the material if one uninterrupted recording is not useful.
You may prefer planned broadcast segments if an archive is important, but segmenting changes the viewing experience and requires a clear restart plan. Tell regular listeners when a stream is ending or resuming if that matters to them, and verify the next live event rather than assuming that an encoder reconnect will create the intended archive. Check YouTube’s current documentation before settling on a schedule, since archive behaviour is a platform matter rather than a waveform setting.
The same distinction applies to a hosted, unattended workflow. StreamNeo can take away the need to leave your own computer running by turning an uploaded video into a YouTube live stream, but it is for uploaded video rather than a live internet-radio input. For a radio feed that must remain live, choose and monitor an encoder path that can receive that source; do not treat either a hosted video loop or an encoder as a promise of a complete YouTube replay.
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 YouTube make the waveform for my radio stream?
No. You need to create the video layer with your chosen composition and encoder tools. The visualiser must be able to analyse the audio being sent to YouTube; YouTube receives the combined feed rather than generating that waveform for you.
Should I use OBS or FFmpeg for a 24/7 radio channel?
Use OBS if you prefer a graphical scene editor and can keep its computer and desktop session available. Use FFmpeg if you are comfortable managing command-line configuration and its monitoring. Neither route is proven more reliable in every setup, so choose based on the skills and operating arrangements you can maintain.
Can I relay any internet radio station if it is publicly available?
No. Public availability is not the same as permission to rebroadcast the music or other material on YouTube. Confirm your rights and any Content ID allowlisting requirements with the relevant rights holder, and check YouTube’s current official terms and copyright guidance.
Will YouTube save the whole 24/7 broadcast as one video?
Do not rely on that. YouTube warns that streams longer than 12 hours may not be captured as archives. If a replay matters, arrange and monitor a separate recording or plan suitable shorter segments, and verify current YouTube guidance before relying on any archive behaviour.