A college radio station can stream continuously on YouTube by sending its approved programme audio into an encoder such as OBS, then connecting that encoder to a stream created in YouTube Studio. BUTT and OBS have different jobs: BUTT sends live audio to supported audio streaming services, while OBS is the encoder route for an audio-plus-video feed to YouTube.
For a station, the harder work is often not pressing Go Live. You need an authorised signal path, music and archive permissions that cover the intended use, a tested YouTube preview, and a person or process that will notice a failure overnight.
What each tool is designed to do
BUTT is an audio broadcasting tool. It takes an audio input and sends it to supported audio streaming services, such as Icecast or Shoutcast. That makes it useful when a station wants to feed an audio server or webcast endpoint. Its listed support for those services, or for WebRTC, does not make it a direct YouTube encoder.
OBS is a production and encoding application. It can combine an audio source with a picture or other video, encode the resulting feed, and send it to YouTube Live using the server URL and stream key supplied by YouTube. For a radio station, the picture might be a station card, a now-playing graphic, a studio camera, or a programme-specific visual. You do not need a hardware encoder just because the content starts as radio audio: YouTube describes both software and standalone hardware encoder workflows.
A useful way to decide is to ask where the YouTube feed should originate. If your station already has a supported audio stream and a separate workflow to deliver its sound into OBS, you can keep the audio service and use OBS for the YouTube audiovisual feed. If the station’s sound is available directly from a desk output or computer input, connect that source to OBS and skip a separate BUTT-to-YouTube idea. The connection between the station’s audio and OBS is the key step.
This is a different tool choice from sending a prepared video file on repeat. For that distinction, see OBS and FFmpeg compared for looping video streams. A college station is usually relaying a changing live programme, so the input needs to follow the station’s actual output rather than a fixed playlist file.
Check how the station audio is available
Before opening OBS, map the signal path with the person who runs the studio. Is the programme output available from a mixer’s USB connection, a line output, a dedicated studio computer, or a web stream? Write down which output is approved for the YouTube feed, who controls its level, and whether it carries every show, including overnight automation. Avoid capturing a microphone or preview bus that can go silent when a presenter changes the desk settings.
If you use a physical output, check that it can be connected to the computer running OBS without introducing clipping, hum, or an unstable level. Test ordinary speech, quiet segments, and louder music. A signal that looks acceptable during a presenter’s microphone check may still peak when a full programme begins. If the output uses a separate audio interface, record its name and the input selected in OBS so another student operator can restore the same route.
If the station output is already available as a network audio stream, establish how the listening computer can receive it reliably. OBS can use audio sources available to the computer, but you should test the actual capture route rather than assume that a URL or a player window is automatically a clean input. Avoid routing audio through speakers and a room microphone when a direct connection is available; the room route can pick up voices, fan noise, or feedback.
Decide what viewers will see while the station plays. A station identity card is simple to maintain, while now-playing artwork or a studio camera needs a dependable source and someone responsible for keeping it appropriate. Keep the visual consistent with what the station is authorised to show. Include a contact or station identity in the operating notes, not the stream key.
For a continuous broadcast, continuity also means that the input remains present when nobody is in the studio. Check the overnight automation, scheduled programmes and any silence-detection behaviour. If the board computer reboots or the audio player changes devices, OBS may remain connected while sending silence. This is why you should test a full schedule hand-off and not only a short test with one operator at the desk.
Configure OBS to receive the audio
In OBS, create a scene for the station feed and add the audio input that corresponds to the approved programme output. Depending on the setup, that can be a capture device, an audio interface input, or a computer audio source. Add the station’s chosen visual to the same scene. Keep the scene deliberately simple at first: one known audio route and one known picture make faults easier to isolate than several nested scenes and filters.
Watch OBS’s audio meter while the station is playing. It should move with programme audio and fall during genuine pauses, without remaining pinned at the top. Listen to the output through headphones or a monitoring destination, and compare what you hear with the source at the desk. If the meter moves but the monitoring is silent, inspect the selected device and monitoring configuration. If the sound distorts, reduce the source or input level rather than assuming the encoder can repair clipping.
Do a hand-off test. Ask the studio operator to move from a microphone-led segment to music or automation, then confirm OBS continues to receive the right source. Test a programme change if the station uses different computers or output buses at different times. Record which OBS scene is intended to run and how to switch back if an experimental scene is selected accidentally.
Choose a video format and bitrate that your network can carry alongside the station’s other use. Even a largely static image is still part of an encoded audiovisual feed. YouTube’s encoder guidance recommends supported video and audio encoding formats, constant bitrate, and a two-second keyframe interval, with the interval not exceeding four seconds; check the current YouTube encoder settings guidance before settling on configuration because recommendations and available options can change.
As a documented example rather than a station-specific requirement, YouTube Help lists 720p at 30 frames per second with a recommended video bitrate of 2 Mbps and a maximum of 6 Mbps. These are platform recommendations, not measurements of your line or a promise that the stream will work at those settings. YouTube also advises leaving network headroom beyond the total bitrate; shared campus traffic can reduce what is actually available. Test from the same connection and location you intend to use overnight. For the relationship between image size and data rate, the resolution-versus-bitrate guide is a useful companion.
Create the YouTube encoder stream
First make sure the channel is ready to go live. YouTube says the channel must be verified and must not have live-streaming restrictions in the preceding 90 days. First-time enablement can take up to 24 hours, so do not leave activation until launch day. Check the channel’s current status in YouTube Studio and use the official YouTube live-streaming eligibility and enablement guidance for the current requirements.
Once live streaming is enabled, open YouTube Studio and choose Go Live. Create or schedule an encoder stream and set its title, description, visibility and other event details. Decide whether the initial test should be private or unlisted; the station should know who can access it and how to find the watch page. Treat this as a specific event in YouTube’s Live Control Room, even if the station intends to operate a regular feed. YouTube’s event setup instructions explain how to create the encoder stream and review its status.
Do not confuse creating the YouTube event with starting OBS. YouTube provides the destination information; OBS is the sender. Keep the event details and the scene setup in the station’s runbook, but store the stream key as a credential rather than placing it in a shared public document. YouTube describes the key as a password and address for the stream. Give it only to people who need to configure the encoder, and reset it if it is exposed.
A 24/7 station also needs a continuity plan beyond the event form. YouTube’s help material explains encoder setup and stream archives, but it does not promise that one event or one encoder session is designed to run indefinitely without intervention. Decide who will check the control room, what a dropped feed looks like, who is authorised to restart it, and how you will communicate a planned interruption to listeners. The practical guide to a YouTube radio stream with a time-based schedule can help when the station needs to coordinate programmes across operator shifts.
Enter the server URL and stream key
In OBS, open the streaming settings and choose YouTube as the service if that option is available in your setup. Use the connection method and server details shown in the YouTube control room. If the workflow asks for a server URL and stream key, copy each into its matching field: the URL identifies the ingest destination, while the key identifies the stream associated with the event. Do not paste one value into both fields or share a screenshot that exposes the key.
Confirm that the event in Studio is the one you intend to use. A station may have separate test and public events; connecting the wrong key can send a valid feed to the wrong control room. Keep a simple checklist with the event title, scene name, selected audio source and date of the last test. If a key is rotated, update the approved encoder and remove the old value from notes or screenshots.
The station should have a second authorised operator who can follow the same steps without guessing. If that person cannot identify the correct event, audio source and key-storage location, the workflow is not ready for an unattended shift. Limit access to the key, but make the recovery procedure available to the people responsible for operating the channel.
Start the encoder and check the preview
Start streaming from OBS while the YouTube event is still in a test state. Wait for YouTube Studio to report that it is receiving the encoder feed, then inspect the Live Control Room preview. Confirm the station image is correct, the audio is audible and in sync, and the programme playing in the preview is the programme you intended to send. A connected indicator alone is not proof that viewers receive intelligible audio.
Check the stream health information in the control room and listen through the public or test watch page on a separate device. Use a phone on a different network if possible, so the check does not rely on the same local audio monitoring route. Ask another person to confirm that speech is understandable and that the music does not clip. A short local recording can also help diagnose the source, but it is not a substitute for checking what YouTube receives.
Run the test long enough to include a quiet passage, a louder passage and any automation change that is likely to happen during a normal shift. If the feed breaks up, lower the total bitrate or find out whether campus network use is competing for upload capacity. If there is a delay or unexpected silence, trace it from the station source to OBS and then from OBS to YouTube, changing one part at a time.
Only after the preview and health checks are acceptable should you make the event public or begin the planned broadcast. Keep the test private or unlisted if its purpose is troubleshooting and it should not appear as a public station programme. Document what passed and what still needs attention; a hurried launch can turn a small routing problem into an overnight silent feed.
Go live and monitor the result
When ready, start the event in YouTube Studio if the event workflow requires it, and confirm the public watch page is live. Keep both OBS and Live Control Room visible to the operator at launch. Check the actual audience-facing page, not only the encoder status, and have the studio output playing as expected. Tell the next operator what to watch and where to find the current event.
For overnight operation, assign responsibility rather than relying on someone noticing a message by chance. The station can use a rota, a documented check-in process, or an alerting workflow it has tested. Write down the recovery order: verify the audio source, inspect OBS connection status, check YouTube stream health, then reconnect or restart only when the cause is understood. If a reboot or interruption occurs, confirm the preview again before declaring the feed restored. YouTube’s guidance on backup encoders is useful for event failover testing, but it does not define a complete unattended radio recovery design.
Audio and video continuity are separate. The encoder may keep sending a static image while the station’s audio source has gone silent; conversely, audio can continue while the visual source fails. Include both in each check. For other failure patterns, see the troubleshooting guide for a YouTube live stream that stops after a few hours. Its symptoms may differ from a radio station’s setup, but the distinction between source, encoder and platform is useful when tracing a stop.
Decide what happens to the archive. YouTube says streams under 12 hours are automatically archived, but that does not mean a single session should or will run continuously for a full day. Review the current YouTube archive and livestream help and decide whether a replay should remain available, be edited or be removed. An archive can create a separate rights question, and claims may arrive after the live programme ends.
Rights need to be checked before the first test that includes third-party music, not treated as an issue that platform detection will settle. YouTube’s live-stream terms put responsibility on the provider to have the necessary rights for live content. Its copyright guidance also explains that Content ID can detect third-party material during a live stream and interrupt or terminate the broadcast. A licence alone may not prevent an interruption if the relevant rights owner has not allowlisted the channel in Content ID.
Ask the institution or rights adviser whether existing agreements cover an audiovisual YouTube simulcast, the relevant territories, and any resulting replay. Composition rights and sound-recording rights are distinct considerations; also check student DJ selections, guest performances, syndicated programmes, callers, event recordings and the visuals shown alongside music. In the United States, some webcasting licences are limited to particular digital sound-recording transmissions and do not by themselves establish clearance for every composition or audiovisual YouTube use. Outside the United States, check the applicable local rules and agreements. Do not infer permission from the fact that a test stream was not interrupted.
At the point when a station wants to remove dependence on a studio computer remaining on overnight, StreamNeo can take an uploaded video and run it as a YouTube live stream with the computer switched off, which addresses that specific machine-continuity problem; it is YouTube-only and does not replace the station’s rights checks or live-programme signal planning. A changing, live radio output still needs a route from the station’s audio chain into the encoder workflow described above.
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 BUTT itself to send my station directly to YouTube?
No. BUTT sends live audio to supported audio streaming services, while the YouTube route described here uses an encoder such as OBS to send an audio-plus-video feed. Connect the station audio to OBS, then enter the YouTube event’s server URL and stream key there.
Does a college radio station need a hardware encoder?
Not necessarily. YouTube supports software encoders as well as standalone hardware encoders, so OBS can be a suitable route when a station computer can receive the programme audio and produce the chosen visual. A hardware unit may suit a station with dedicated production connections, but test the whole workflow before selecting equipment.
Does our existing radio licence cover YouTube?
You cannot assume that it does. Ask the institution or rights administrator whether the specific agreement covers audiovisual simulcasting to YouTube, the relevant territories and any archive, and whether rights owners need to allowlist the channel in Content ID. Rules and licences differ by territory and use.
Can one YouTube live session run continuously for 24 hours?
The cited YouTube setup guidance does not promise an uninterrupted 24-hour session or a complete always-on recovery design. Plan monitoring, shift hand-offs, restart steps and archive decisions, then test the station’s actual workflow. The automatic archive guidance for streams under 12 hours should not be read as a guarantee about continuous-session duration.