A YouTube radio livestream built with FFmpeg and Docker needs a video track as well as audio, plus a source that you have tested from end to end. The important first distinction is whether your AAC is a local file or a live station feed: OBS uses different source types for those cases, and neither label alone proves that the audio will reach your broadcast.
This guide starts by checking the source in OBS, then covers an FFmpeg-and-Docker route for sending a tested programme to YouTube. Keep the OBS check and the FFmpeg deployment as separate workflows: OBS is useful for confirming a live feed plays and its audio meter moves, while Docker can run FFmpeg without OBS as the encoder.
First identify the AAC source
AAC describes an audio codec, not where the audio comes from. A file such as show.aac or an AAC track inside an MP4 is stored media; a URL that delivers audio continuously is a live feed. A playlist may point to either kind of material, so inspect what you actually have before choosing settings.
For a file, test that it opens, plays through, and contains the programme you expect. For a live feed, use the exact URL and credentials supplied by the station or feed provider. Check its documentation for the transport and access requirements. Do not assume an .m3u or .m3u8 playlist, an AAC label, or a URL ending in a familiar extension identifies a feed OBS can play.
There are two reasonable routes from here. If you want OBS to take a local file or feed as a source, follow the relevant OBS sections below and verify its meter. If you want Docker to run FFmpeg as the YouTube encoder, use the deployment sections; the OBS test remains a practical way to validate a feed before relying on it, but it is not a required part of that FFmpeg pipeline.
Add a local AAC file in OBS
For a stored audio file, add a Media Source in OBS. Open its properties, select the local file, and enable looping if you want the programme to repeat. OBS documents Media Source for media files, including the option to loop playback. A long programme can instead play once, provided you have planned what should happen at its end.
Do not treat a successful file selection as a complete test. Start playback and listen for the expected content. If the file has both audio and video, make sure its visual behaviour suits the scene; for an audio-only file, add a still image, visualiser, or other suitable visual source. A conventional YouTube live broadcast has a video picture as well as sound, so audio alone is not a complete programme output.
If you are rotating several files, decide how one item hands off to the next and test that transition. A single looping programme is simpler, but it can repeat at an awkward point or include silence at the join. A playlist arrangement gives you more control over sequence, at the cost of more moving parts. For shell-based rotation, this guide to automating a YouTube playlist with a Linux script is relevant; whichever method you choose, listen across a transition rather than checking only the first minute.
Configure a live feed with VLC Video Source
A network radio feed is not a local media file. In OBS, use VLC Video Source for a live feed rather than assuming Media Source will handle every network stream. OBS’s documentation distinguishes these input paths: Media Source is for media files, while VLC Video Source uses VLC playback support for sources such as playlists and network streams.
Add a VLC Video Source to the scene and enter the feed URL or playlist in its properties. If VLC is not available to OBS, install or configure the required VLC components for your operating system, then restart OBS if needed. The exact setup depends on the OBS build and platform, so use the current OBS VLC Video Source guide rather than copying settings intended for another machine.
A feed may require authentication, a particular playlist variant, or a transport that your installed VLC and OBS combination does not accept. Preserve any required URL parameters and credentials, but do not put a private feed URL into a public scene collection or screenshot. If you have several URLs from a provider, test the documented primary feed first; an alternate endpoint can behave differently even when the audio is nominally the same.
Check playback and transport before relying on it
Select the source and confirm that VLC actually begins playback. You should see the expected picture if the feed includes video, and you should hear audio if the source is audible in your monitoring setup. A blank visual or a source that remains stopped is a reason to investigate before connecting the scene to YouTube.
When playback fails, check the provider’s URL and transport instructions, network access, credentials, and the VLC/OBS versions you are running. A playlist may contain several entries, and successful playlist loading does not establish that every entry can be decoded. Test the specific entry that matters. OBS and VLC support a range of inputs, but no guide can promise that every AAC stream, transport, URL, or playlist will work in every installation.
For a local diagnostic, compare the feed in a VLC player with the same URL, then return to OBS and check the VLC Video Source there. Playback in a separate player is useful evidence, not proof that OBS will ingest the source identically. The decisive check for your intended setup is playback inside OBS itself, followed by a responsive audio meter. If your goal is a continuous station, let the test run long enough to observe whether it stops or changes programme unexpectedly.
Confirm the OBS audio meters respond
With the source playing, look at the OBS Audio Mixer. The meter for the source, or for the mixer channel receiving it, should move in time with the sound. Then listen through OBS monitoring or a test recording. A moving meter confirms that OBS is receiving audio at that point in the chain; it does not prove that the YouTube encoder is sending it or that viewers can hear it.
If you hear the feed but see no meter movement, check the source’s audio output settings and OBS mixer routing. If the meter moves but the stream is silent, check which audio track the output uses and whether the source is muted or assigned to a different track. Make a short recording or private test and play it back; this catches routing mistakes that a meter alone cannot.
Set levels so the programme remains audible without clipping. Avoid raising a quiet feed until its peaks distort, and listen for abrupt changes in loudness, missing channels, or long silences. For a devotional station, for example, test both a quiet spoken introduction and a louder song rather than judging the level from one passage. If your source has no audio at all, return to source playback and transport checks instead of changing YouTube settings blindly.
This is the point to spend time before leaving a station unattended. A feed that has loaded but never reached the mixer is not ready for a night-long broadcast. For a broader view of failures after a stream is already running, see how to fix FFmpeg reconnect errors when pushing to YouTube. That addresses a different layer from confirming that OBS can play the source in the first place.
Send an FFmpeg programme from Docker
If you prefer FFmpeg as the encoder, think of the job as a video input, an audio input, an output encoding, and a YouTube destination. For a radio programme, the video might be a still image or a looping visual; the audio could be a programme file or a prepared playlist. FFmpeg’s -stream_loop -1 option loops an input indefinitely, but the input, timestamps, stream mapping, and duration still need to suit the assets you have.
This illustrative command shape uses a video programme containing both picture and sound. Replace the file, encoding choices, and destination with tested values, and check the installed FFmpeg build for the required codecs. It is not a universal command or a guarantee that every image includes libx264 or supports the same protocols:
ffmpeg -re -stream_loop -1 -i /media/program.mp4 \\
-map 0:v:0 -map 0:a:0 \\
-c:v libx264 -preset veryfast -tune stillimage \\
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \\
-b:v 2500k -maxrate 2500k -bufsize 5000k \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "${YOUTUBE_RTMP_URL}/${YOUTUBE_STREAM_KEY}"
The example's video bitrate is illustrative, not a general YouTube recommendation. Choose the current YouTube bitrate guidance for the codec, resolution, and frame rate you select. YouTube lists H.264, H.265, and AV1 for RTMP/RTMPS ingestion, AAC or MP3 audio, constant bitrate encoding, and a recommended two-second keyframe interval that should not exceed four seconds. For stereo AAC, its encoder guidance lists 128 Kbps. See YouTube’s current encoder settings before deciding output values.
If the audio file is separate from the visual, add both inputs and map the intended streams explicitly. A still image needs to be made into a continuing video stream with suitable duration and frame rate; a music-only input does not magically create the video track expected for a conventional live event. Make a short unlisted test and check sync, visual presence, audio level, and the end or loop behaviour before changing the command into a persistent service.
Package the encoder carefully in Docker
Use a maintained or reproducibly built FFmpeg image that contains the codecs and protocol support you have tested. Mount media read-only where practical, run one foreground FFmpeg process, and choose a restart policy based on how you intend to operate the channel. A minimal Compose outline is below; its image name and command are placeholders, not a recommendation for an untested image.
services:
radio:
image: your-tested-ffmpeg-image
command: ["/bin/sh", "-c", "exec ffmpeg ..."]
volumes:
- ./media:/media:ro
restart: unless-stopped
secrets:
- youtube_stream_key
secrets:
youtube_stream_key:
file: ./secrets/youtube_stream_key
Adapt secret delivery to both your Compose deployment and the way your entrypoint reads it. A secret declaration alone does not make FFmpeg consume a key, and the endpoint/key construction must be handled without exposing the key in a committed file, screenshot, or routine logs. Docker recommends using secrets for sensitive data; for local development, keep any .env file containing credentials out of version control and restrict access to it. Read the Compose service reference and Docker’s guidance on environment variables for the mechanisms you actually use.
A restart policy can restart a container after it exits; it does not determine whether the programme is audible or whether YouTube is receiving a healthy stream. unless-stopped also honours an operator’s manual stop across a daemon restart. FFmpeg documents FIFO muxer recovery options for temporary RTMP failures, but those options need to match the installed version and be tested on your actual network. Neither a restart policy nor a reconnect setting is an end-to-end uptime guarantee.
Connect to YouTube and test before going live
Confirm first that the channel is eligible and live streaming is enabled. YouTube’s requirements can change, so check its current live streaming eligibility page. In Live Control Room, create or select the stream and copy the matching server URL and stream key from stream settings. Treat the key like a password: YouTube describes stream keys as the stream’s password and address. Use the corresponding encoder setup instructions, and reset the key if you expose it.
YouTube supports encrypted RTMPS and recommends it. Select the RTMPS endpoint when configuring your encoder if it is available and supported in your FFmpeg build. The key belongs after the appropriate server URL in the format expected by the selected encoder; keep it out of source control and avoid pasting it into a public support request.
Before a public broadcast, run a private or unlisted test. Check the preview in Live Control Room, listen to the audio there, verify the visual is present, and monitor stream health. YouTube recommends testing ahead of time and checking upload capacity; the connection should have margin above the combined stream bitrate, rather than merely matching it. Its guidance recommends 20% headroom. If the connection is shared or variable, test under realistic conditions instead of assuming the nominal plan speed is available to the encoder.
For Docker, observe the container while the test runs: confirm FFmpeg remains active, inspect useful error output without leaking secrets, and verify that the stream appears and plays in YouTube’s preview. Test a deliberate restart and, where practical, recovery from a brief network interruption before depending on unattended operation. If a machine or network choice is still unsettled, the trade-offs discussed in free cloud options for a recorded YouTube stream in India can help frame that decision. Cloud placement does not remove the need to validate source playback, outbound bandwidth, and recovery.
If you would rather not keep a Docker host and FFmpeg process running on your own computer, StreamNeo can take an uploaded video and keep the YouTube broadcast running without that computer remaining on. That addresses the specific burden of maintaining the encoder process; it does not decide whether your content, rights, or channel are suitable for a broadcast. For context on the separate question of prerecorded programming, read YouTube’s rules for 24/7 prerecorded live streams.
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 send only AAC audio to YouTube Live?
For a conventional audiovisual live broadcast, plan for a video track as well as audio. Pair an audio programme with a still image, visualiser, or suitable looping video, and verify the actual output in a private test. The right FFmpeg inputs and mapping depend on your assets.
Is an AAC radio URL guaranteed to work in OBS?
No. AAC identifies a codec, not a universally supported URL or transport. Use VLC Video Source for a live feed, check the provider’s instructions, and confirm playback and meter movement in your own OBS installation before relying on it.
Will Docker restart keep my radio stream online?
A Docker restart policy can bring back a container that exits, but it cannot by itself confirm that FFmpeg is sending a healthy stream or that the source is audible. Test container restart and network recovery on the host you intend to use, and monitor the YouTube preview and stream health.
Should I use OBS or FFmpeg in Docker?
OBS is useful when you want to assemble a scene and verify a live source through its mixer, especially when you need to establish that the specific feed plays and its meter moves. FFmpeg in Docker suits a process-based encoder that you can configure and operate yourself. Choose according to the workflow you can test and monitor, rather than assuming one tool will accept every source.