An internet radio station can be sent to YouTube by giving FFmpeg two inputs: the station’s audio URL and a still image that supplies the video track. FFmpeg then encodes those inputs and sends the result to YouTube Live over an ingest connection.
The command below is an illustrative pattern, not a tested or universal recipe. Radio formats, FFmpeg builds, network conditions and YouTube credentials vary, so treat each placeholder and setting as something to verify before using it for a live channel.
Check the feed format and your rebroadcast rights
Start with the radio URL, not with the FFmpeg command. The address must be directly accessible from the computer running FFmpeg. A web page for a station is not necessarily an audio stream, and a player URL may depend on browser requests, cookies or JavaScript that FFmpeg cannot reproduce.
Find out what the endpoint actually returns. It may provide AAC, MP3 or another format, and it may use a playlist or redirect before reaching the audio stream. Some stations require authentication. A URL that plays in a browser can still fail when requested by a command-line programme, so inspect the station’s technical documentation or test the endpoint with tools available on your system.
The exact codec also affects your output choices. FFmpeg can sometimes pass a compatible audio stream through without re-encoding, but transcoding to AAC provides a more predictable starting point for a YouTube Live output. That does not make every AAC source compatible, and it does not solve an endpoint that is inaccessible or unstable.
Rights are a separate question from format. Confirm that you have permission to relay the station, the underlying recordings and any announcements or adverts to YouTube viewers in the territories you intend to reach. A station’s permission to broadcast on one platform may not cover a public YouTube relay. The technical documentation cannot answer that question for your station or jurisdiction, so check the relevant licence terms and obtain advice where necessary.
If you are turning your own spoken or recorded material into a station, the workflow is similar to the one described in how to set up a podcast livestream on YouTube with audio-only episodes. A third-party radio feed introduces an additional source and rights check.
Create a YouTube Live stream
Open YouTube Studio, choose Create, then Go Live. Create or select the stream that will receive the encoder connection. Live Control Room provides the stream URL and stream key that identify the destination for your broadcast. YouTube’s guide to creating a live stream with an encoder describes the account and preview steps.
Do not confuse the stream key with a public identifier. It works as a credential for sending video to your channel. Anyone who obtains it may be able to send content to that destination, depending on the account’s current settings. Keep it private in the same way you would protect a password.
You can create a separate stream for testing rather than experimenting with the channel’s main broadcast. That gives you a place to check the image, audio, latency and failure behaviour without unexpectedly replacing an established programme. YouTube may also require account features or verification before live streaming is available; check the current requirements shown in your own Studio account.
Before starting FFmpeg, decide whether the broadcast should be public, unlisted or private during the test. An unlisted test can make it easier to share the preview with a colleague without placing it in the public channel view. Test settings still need to reflect the intended show, including representative music or speech and the amount of movement in the image or graphics.
For a radio station, the video may be a single cover graphic for most of the session. That is technically simple, but it still needs a valid video track. YouTube does not receive a complete live broadcast merely because the audio URL is live.
Find the RTMPS ingest URL
YouTube recommends RTMPS for encrypted ingest. In Live Control Room, use the lock icon or the relevant connection option to retrieve the RTMPS server URL shown for your stream. Do not assume that a familiar RTMP address is the correct destination. YouTube’s RTMPS guidance explains how to obtain the secure endpoint and what to check when the connection fails.
Copy the endpoint exactly as displayed. The path, trailing slash and placement of the stream key can vary with the endpoint YouTube gives you. In the example later in this article, rtmps://INGEST_URL/STREAM_KEY is a placeholder, not a value to copy literally.
RTMPS protects the connection between your encoder and YouTube while the stream is being sent. It does not grant permission to rebroadcast the radio station, and it does not make the stream public or private by itself. Those are separate account, content and rights decisions.
YouTube also documents HLS for cases outside ordinary RTMP capabilities, including some codec or HDR situations. HLS is segmented and can introduce higher latency, so RTMPS is the simpler starting point for a still-image radio broadcast when the required encoders and settings are available.
Prepare the still image
Choose an image you are entitled to use. It might contain the station logo, programme name, schedule or a notice explaining that the channel is carrying audio. Avoid using artwork supplied with a recording unless your permission covers its display on YouTube as well as the audio relay.
Save the file locally in a format your FFmpeg build can read, such as JPEG or PNG. Use a clear, appropriately sized image rather than a tiny file enlarged until it becomes visibly soft. The image is not just decoration: FFmpeg will use it to construct the video stream required by YouTube.
Check the image before going live. Look for spelling, outdated programme details, telephone numbers that should not be public and logos belonging to another organisation. If the station changes programmes, a single still may be acceptable, but it will not show those changes unless you create a separate visual workflow.
The command uses -loop 1 so the image acts as a continuing video input in commonly used FFmpeg builds. Still-image timing and loop behaviour can differ with versions and builds, so confirm the behaviour of the FFmpeg installation you are using. Do not assume that a command copied from another computer has identical codec support or defaults.
Adapt the FFmpeg command pattern
Here is a starting pattern. It was not run or tested for a particular radio URL, operating system, FFmpeg build or YouTube account. Replace every placeholder, keep the destination private, and adjust the inputs if your station’s endpoint behaves differently.
ffmpeg -re -loop 1 -i cover.jpg -i 'RADIO_STREAM_URL' \
-map 0:v:0 -map 1:a:0 \
-c:v libx264 -preset veryfast -tune stillimage \
-r 30 -g 60 -b:v 2500k -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv 'rtmps://INGEST_URL/STREAM_KEY'
The first input is the image. The second is the radio source. -map 0:v:0 explicitly selects the first input’s video stream, while -map 1:a:0 selects the second input’s first audio stream. This is useful because FFmpeg may otherwise choose streams differently when an input contains extra metadata, a playlist or more than one track.
-re asks FFmpeg to read the inputs at their normal rate rather than sending available data as quickly as possible. -loop 1 repeats the still image. The output format is FLV because it is commonly used with RTMP and RTMPS ingest. The destination must be the exact endpoint supplied in Live Control Room, with the private key included in the required position.
The video settings are an example aligned with current YouTube guidance, not a universal requirement. The example uses H.264, 30 frames per second, a 60-frame group-of-pictures interval and a pixel format widely accepted by video platforms. YouTube’s encoder guidance lists H.264, H.265 and AV1 video, and recommends a two-second keyframe interval that should not exceed four seconds.
For 720p at 30 frames per second, YouTube currently lists 3 Mbps as a recommended video bitrate, with a 2 Mbps minimum and 6 Mbps maximum on its settings page. The template uses a 2.5 Mbps target with a 3 Mbps maximum, which is only an example of how a constrained radio image might be configured. You should select a bitrate your upload connection can sustain and confirm that the chosen resolution and encoder are suitable.
For audio, YouTube lists AAC and MP3 among the supported choices and gives 128 Kbps stereo at 44.1 kHz as a recommendation. The command requests those values. If the station provides a different channel layout or if the installed AAC encoder is unavailable, you may need to change the audio options or install a build with the required encoder.
The libx264 name is not guaranteed to exist in every FFmpeg build. Run the version and encoder checks appropriate to your installation before relying on it. If H.264 or AAC support is absent, choose supported encoders and verify that their output matches YouTube’s current requirements. Do not swap settings blindly because a different codec can change compatibility, bitrate needs and CPU use.
FFmpeg’s official documentation is the right reference for input options, stream selection, filtering and output behaviour. YouTube’s encoder settings guidance should be checked alongside it because platform requirements can change.
Protect the stream key
Never place the real stream key in a screenshot, tutorial, public repository, shared shell history or public support post. The illustrative command deliberately uses STREAM_KEY. Treat the complete destination, including the key, as secret even if the rest of the command is harmless to share.
A command entered directly into a shell may remain in command history, depending on the operating system and shell configuration. A public script is worse because it can be copied, backed up or indexed. Keep the destination in a protected local configuration method where practical, and restrict access to the account or machine that needs to run the encoder.
Also review logs. FFmpeg can print input and output details, and a wrapper script may record the complete command line. Check that error logs, monitoring dashboards and support bundles do not capture the RTMPS destination with its key attached. Mask the value before sending diagnostics to anyone else.
If you think the key has been exposed, return to Live Control Room and reset or regenerate it if that option is available. Then update the private command or configuration. Changing the YouTube video title or thumbnail does not replace a compromised stream credential.
The key should not be confused with the radio station’s own authentication. If the source URL also contains a username, token or password, protect that value separately. A private YouTube key does not protect credentials embedded in the radio URL.
Test the output and diagnose failures
Run a private or unlisted test before scheduling the real broadcast. Use audio and movement similar to the intended programme, as YouTube Help advises: a test of speech and a still image may not reveal the same problems as music, changing artwork or a long unattended session. Watch the Live Control Room preview and stream health rather than assuming that a process still running in a terminal means viewers are receiving valid media.
Start with the simplest test that can answer one question at a time. Confirm that the image opens locally. Confirm that FFmpeg can read the radio endpoint. Confirm that the selected encoders exist. Then test the complete output with the actual RTMPS destination. This separation makes an error easier to attribute.
| Symptom | Likely area to check | Practical next step |
|---|---|---|
| FFmpeg cannot open the radio URL | URL, redirect, authentication or source availability | Inspect the source details and test the direct endpoint from the encoder machine |
| The preview has video but no sound | Audio mapping or source codec | Check -map 1:a:0, inspect the input streams and verify that the source contains audio |
| The preview has sound but no picture | Image path, image decoder or video mapping | Confirm the local file opens and that -map 0:v:0 selects it |
| YouTube rejects the connection | Ingest URL, key or unsupported encoder output | Copy the current RTMPS endpoint again and check encoder availability and output settings |
| The stream buffers or disconnects | Upload capacity, source interruptions or local load | Reduce unnecessary output load, test the connection and watch health messages |
| Audio stops while FFmpeg remains open | Radio source stalled or changed format | Check the source independently and review FFmpeg’s input and reconnect behaviour |
A stable upload connection needs headroom above the encoded bitrate. YouTube recommends running a speed test and testing before the event, but a speed-test result is not a guarantee of overnight stability. Other users, Wi-Fi changes, ISP routing and local congestion can affect the result. For a 24/7 channel, read the VPS bandwidth guide for a 24/7 YouTube livestream before choosing where FFmpeg will run.
The source itself is another possible failure point. If the station server pauses, changes its response or disconnects, the video image may continue while the audio becomes silent. If the internet connection drops, FFmpeg may exit or remain unable to send. An unattended setup needs a separately designed process for detection, restart and notification; this command pattern does not guarantee uninterrupted operation.
For a private rehearsal, follow the steps in how to test a YouTube radio livestream privately before going public. Include a long enough observation period to expose source and upload behaviour, but do not treat one successful test as proof that every future session will work.
When the test is over, stop FFmpeg and end the stream in Live Control Room. YouTube’s encoder help says streams under 12 hours are automatically archived. That does not mean one session should be treated as an indefinitely running recording, nor does it remove the need to plan how you will stop, restart and label broadcasts.
If keeping a computer running all night is the problem, StreamNeo removes that specific operational burden by letting you upload a prepared video, connect your YouTube stream key and have the broadcast run while your own computer is switched off, with automatic monitoring and restart when a drop is detected. It is YouTube-only, so it does not replace an FFmpeg workflow when you need to relay a live external radio URL or customise the encoder process yourself.
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 FFmpeg send radio audio to YouTube without a video file?
YouTube Live expects a video stream as well as audio for this workflow. A still image supplies the video track, while the radio URL supplies audio, so FFmpeg can encode both into one output.
Is this command compatible with every radio stream?
No. The source may use a different format, authentication method, playlist structure or codec, and FFmpeg builds differ in available encoders. Inspect the actual input and adjust the mapping, decoding or audio settings rather than assuming the template will work unchanged.
Should I use RTMP or RTMPS?
Use the RTMPS endpoint shown by YouTube when it is available and suitable for your encoder. Retrieve it from the lock icon or connection details in Live Control Room instead of guessing the URL, and keep the accompanying stream key private.
Will this run forever if the terminal stays open?
No. The radio source, computer, FFmpeg process and upload connection can all fail, and YouTube sessions have their own lifecycle and archive behaviour. Test the complete arrangement, monitor it, and design separate restart and alerting procedures if the channel must operate unattended.