A YouTube radio livestream needs both an audio programme and a video signal. You can use OBS to combine your radio feed with a background and an audio-reactive waveform, then send the finished scene to YouTube through an encoder stream.
The reliable way to build it is to test the complete chain: the actual audio source, the waveform motion, the YouTube preview and the stream-health indicators. A visualiser that looks correct in a browser is not necessarily receiving the same audio that your broadcast sends.
Create or schedule the YouTube broadcast
Open YouTube Studio and choose Create, then Go live. For a new encoder stream, use the Stream tab. If you want to prepare the title, description, visibility and start time in advance, use Manage to schedule a broadcast instead.
YouTube says that enabling live streaming for the first time may take up to 24 hours. Check this before planning a launch night. You can review the current process in YouTube's encoder streaming guide, because labels and the order of controls can change.
For an encoder stream, YouTube provides a server URL and a stream key. The encoder sends your audio and video to that destination. Treat the stream key as a password: do not place it in a public screenshot, description, shared document or browser demonstration.
A scheduled broadcast has one extra hand-off. Start the encoder early enough for YouTube to receive a preview, then check the preview in Live Control Room before choosing Go live. If you are making a private or unlisted test, confirm the visibility setting before broadcasting the real programme.
Before building the scene, check that the channel can livestream and that the intended broadcast is the one connected to your encoder. If you are unsure about the channel's status, use this check for YouTube live-streaming restrictions before troubleshooting OBS.
Choose the audio feed and visual background
A radio livestream can start with a simple arrangement:
| Part | Practical choice | What to check |
|---|---|---|
| Audio | Playlist, internet-radio feed, microphone mix or other permitted programme source | It continues playing when the desktop is unattended |
| Background | Station card, artwork or looping video | The file is readable and does not disappear when the scene loads |
| Waveform | Browser-based audio visualiser | It receives the same audio signal that viewers hear |
| Output | One OBS scene sent to YouTube | The preview shows both movement and audio |
A static station card is the least demanding visual option. It can show the station name, programme identity and any information that is genuinely useful to viewers. A looping background video adds movement, but it also creates another file to load and another source to troubleshoot.
If the radio feed already comes from a player on the same computer, OBS may be able to capture desktop or application audio, depending on your operating system and audio routing. If the feed arrives through a mixer, interface or virtual audio device, select that source directly where possible. Avoid building a chain of duplicate captures before you know which device is carrying the programme.
The audio source should be stable before you add decoration. Listen for silence, clipping, repeated tracks and sudden changes in level. A waveform cannot repair an interrupted source. It only displays the signal it receives, and a waveform may continue moving from background noise even when the intended programme has stopped.
For a playlist-based station, you can also review how to stream a playlist of videos on YouTube with OBS. The same planning principle applies here: decide which source owns the programme, then build the visual scene around it rather than adding several competing playback paths.
Add an audio-reactive waveform in OBS
The usual OBS approach is to add the visualiser as a Browser source. A Browser source loads a web page or local HTML visualiser inside the scene, where it can render lines, bars, circles or another waveform-style display.
In OBS, create or select the scene for the radio channel. Add the background first, then add the Browser source above it. Set the browser source's dimensions to match the canvas you intend to send to YouTube. A source that is too small may look soft after scaling; one that is much larger than necessary can use more rendering resources.
The important question is not whether the visualiser page loads. It is whether the page can access the audio signal used by your broadcast. Some visualisers listen to a browser tab, some expect an uploaded audio file, and some use a microphone or another input. That input must be connected to the programme you are actually sending to viewers.
When the visualiser uses a separate browser player, you can end up with two audio paths: the player that viewers hear and the player that drives the animation. They may begin together and drift apart, or one may stop while the other continues. Prefer a design in which the waveform is driven by the same source as the broadcast, then test it under normal playback and during a silent section.
The visualiser may need permission to use audio, and its page may not work when loaded in an embedded browser context. Check its instructions and test the exact Browser source rather than assuming that a demonstration page will behave identically in OBS. A third-party visualiser guide can suggest an implementation, but it does not guarantee compatibility with every OBS version, operating system or audio layout.
Keep the design readable at the size most viewers will see. A thin waveform placed over a busy background can vanish on a phone. Use a clear area behind it, and avoid putting important text underneath a moving element. You do not need a complex animation for a radio channel to feel active; a modest waveform over a recognisable station card is easier to inspect when something goes wrong.
Browser rendering can increase GPU use, particularly when the page combines animation, transparency and a large canvas. If OBS begins dropping frames, start by reducing unnecessary browser animation and checking the scene complexity. This guide to reducing OBS GPU usage on a nonstop YouTube stream covers the wider trade-off between appearance and stability.
Connect OBS with YouTube's URL and key
In OBS, open Settings and the Stream section. Choose the relevant YouTube service or custom server arrangement, then enter the server URL and stream key supplied by YouTube Studio. The wording varies between OBS versions, but the two values perform different jobs: the URL identifies the receiving service, while the key identifies the broadcast destination.
Do not paste a watch-page URL where the server URL belongs. Do not add spaces or extra quotation marks to the key. If you regenerate the key in YouTube Studio, the old value may stop working, so update the encoder before starting the next test.
YouTube supports RTMP and RTMPS encoder connections. The current YouTube live encoder settings guidance lists supported video and audio formats and gives recommendations by codec, resolution and frame rate. Use that table rather than copying a preset from an unrelated stream.
The same guidance recommends constant bitrate and a two-second keyframe interval, with the interval not exceeding four seconds. Its bitrate recommendations depend on the selected codec, resolution and frame rate. For example, the page lists 5 Mbps for 1080p at 30 frames per second in its H.264 table and 6 Mbps for 720p at 60 frames per second. Those are YouTube's published recommendations, not a measurement of your upload connection.
Choose a resolution and frame rate that your computer and connection can sustain. A waveform does not require a high frame rate to communicate movement, and a stationary background does not benefit from encoding more detail than viewers can see. If you choose a demanding output because the canvas looks attractive in the OBS preview, test it for a meaningful period before leaving it unattended.
Audio settings matter as much as the video settings for a radio channel. Confirm that OBS's selected audio device is the source you intend to send, and watch the audio meter while the programme plays. A moving meter alone does not prove that the correct content is being captured, so listen to the YouTube preview as part of the test.
Test the actual audio and waveform motion
Do not test only with a still image and a silent OBS scene. YouTube's own guidance says that tests should include audio and movement similar to what you will use in the live stream. For this project, that means testing the real radio feed, the actual Browser source and the background or loop that will remain on air.
Use a short private or unlisted broadcast first. Start the programme, confirm that the OBS audio meter moves, and look at the Browser source. Does the waveform respond to quiet speech, music and louder passages? Does it freeze during silence? Does it respond to the radio feed rather than to a separate tab or microphone?
Then open the YouTube preview and listen on another device if possible. This helps separate a local monitoring problem from a broadcast problem. Check for:
- audio arriving in both channels when the source is meant to be stereo
- an obvious delay between the audio and the visual movement
- clipping, distortion or very low programme volume
- the background remaining visible behind the waveform
- browser permission prompts or a visualiser page that stops after loading
- unexpected desktop notifications, cursor capture or other private material
Let the test run through more than one track or programme segment. A visualiser may react to one audio format and fail on another. A playlist may also change output devices, pause between items or load a track with a different level. Test a transition rather than judging the system from its first few seconds.
If the waveform does not move, work backwards. First confirm that the source itself plays. Then confirm that the source reaches OBS. Next confirm which input the Browser source is listening to. Finally check whether the visualiser needs a refresh, a permission grant or a different browser-source URL. Do not solve a blank animation by increasing bitrate; encoding settings cannot make a Browser source receive audio it does not have.
You can use the YouTube RTMP setup test before starting a 24/7 stream as a separate preflight checklist. Keep a written record of the working audio device, scene, output settings and YouTube destination so that a later restart is not a memory exercise.
Decide how the channel will stay on air
The first choice is where OBS or the playback process will run. A local computer gives you direct access to the audio devices and Browser source. It is useful when you can supervise the machine, but the broadcast depends on power, network access, operating-system updates and the computer remaining awake.
A VPS with an FFmpeg-based process can be suitable for someone comfortable with remote administration and restart handling. It may remove the need to keep a home computer running, but it introduces configuration, logging and maintenance work. You still need to design what happens when a file ends, an input disappears or the process exits.
A hosted continuous-playout service is another approach. It may provide remote playlist management and visual tools, while reducing the amount of local equipment you need to leave running. The trade-off is less direct control over the pipeline and dependence on that service's current features, terms and recovery behaviour. Check its own documentation rather than assuming that every hosted service supports Browser-source visualisers or the same audio formats.
These options should be compared by control, troubleshooting skill, recovery process, playlist requirements and verified total cost. There is no honest basis here for promising uninterrupted operation or declaring one arrangement universally most reliable.
If your main problem is leaving a computer running and restarting a dropped broadcast, StreamNeo removes that particular local-computer task: you upload the prepared video, provide the YouTube stream key and let the broadcast run remotely, with monitoring and automatic restart handling. It is still your responsibility to prepare the media, check the channel and confirm the music and visual rights.
For a long devotional, ambience or radio channel, also decide what viewers should see if the programme pauses. A static fallback scene is easier to recognise than a frozen frame. Write down who receives an alert, who can regenerate a stream key and who checks the first preview after a restart.
Monitor stream health after you start
The first successful preview is not the end of the test. In Live Control Room, watch the stream-health messages while the encoder is sending. OBS can show dropped frames, rendering problems and encoding load, while YouTube reports what it receives. These are different parts of the chain.
A stable OBS preview with poor YouTube health can point to an upload or network problem. Good network health with a stuttering OBS preview can point to rendering or encoding load. A clean health indicator with no programme audio can still mean that the wrong input was selected. Check the picture and sound, not only the status label.
Keep the YouTube preview open during the initial launch and inspect the stream after a playlist transition. If the health message changes, note the time and what the programme was doing. That record is more useful than repeatedly changing several settings at once.
For a 24/7 channel, define a small response plan:
- Confirm whether the problem is local OBS, the network, YouTube reception or the audio source.
- Check whether the scene is still moving and whether the audio meter is active.
- Avoid regenerating the stream key unless the connection itself is the suspected cause.
- Restart one component at a time and record what changed.
- Recheck the public watch page after recovery.
YouTube says that streams under 12 hours are automatically archived. Longer-running plans therefore need particular attention to the platform's current behaviour and to how you will start the next broadcast. Do not assume that a single encoder session is the right operational plan for every channel.
Clear music and visual rights before broadcasting
A waveform is a presentation layer, not permission to use the music underneath it. Before going live, confirm the rights for every recording, composition, voice clip, image, animation and loop in the programme.
For music, the relevant permissions can involve the sound recording and the underlying composition. A licence that permits personal listening, downloads or background use in a video may not automatically permit a public YouTube livestream. Check the exact terms for live streaming, commercial use if relevant, territories, duration, archived copies and Content ID handling.
Do not assume that a subscription to a music service clears every broadcast use. If a provider offers music for creators, read whether live streaming is included and whether the licence applies to your channel and country. Save invoices, licence pages and catalogue details with the project files, but remember that records do not expand the permission granted by the licence.
The same check applies to the visualiser and background. Confirm whether the visualiser's code or artwork may be used in a public broadcast, whether attribution is required and whether the licence permits modification or commercial use. If you use devotional artwork, photographs or looping footage, establish who owns each asset and what use was granted.
YouTube may identify protected content during a live broadcast. A claim, interruption or removal decision can depend on the work, territory and rights holder. No waveform design can prevent that. If you are unsure, contact the rights holder or obtain advice suited to your situation, and check YouTube's current copyright guidance before scheduling the public stream.
After the rights check, run one final private test with the exact playlist. Confirm that the source does not insert an unlicensed track, the waveform follows the intended audio and the YouTube preview has the expected title and visibility. Only then move the broadcast to its planned public setting.
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 add a waveform to a YouTube radio livestream with OBS?
Yes. Add an audio-reactive visualiser as an OBS Browser source, place it over a background, and send the complete scene to YouTube through an encoder. You must test whether that Browser source receives the same audio as the radio programme.
Does a YouTube radio livestream need video?
Yes. YouTube receives an audio and video broadcast, so a radio channel still needs a video feed. A station card, loop or waveform scene can provide the visual signal, but the chosen source must remain available while the audio plays.
Can OBS run a 24/7 YouTube radio stream by itself?
OBS can send a continuous broadcast while the computer, audio source and network remain available. It does not remove the need for power management, restart handling, monitoring or rights checks, so choose between local OBS, a managed remote process and hosted playout according to the support you can provide.
Why is my waveform visible but not moving?
The Browser source may be listening to a different tab, device or audio path from the one OBS sends to YouTube. Confirm the input, permissions and source playback, then test with real programme audio and compare the local scene with the YouTube preview.