YouTube's recommended target for stereo radio audio is AAC or MP3 at 44.1 kHz and 128 kbps. For the live connection, use RTMPS where it is available, then confirm the stream in YouTube Live Control Room before you leave it running.
There is no single FFmpeg command that is safe to call universal for every internet-radio station. The correct input options depend on the station URL, protocol, source format, installed FFmpeg build and whether you are sending audio alone or adding a visual stream.
Start with the station input and stream type
Before choosing output flags, identify what the station is actually providing. An internet-radio URL may point to an MP3 stream, an AAC stream, a playlist file, or a service using a protocol that your FFmpeg build handles differently. The visible URL is not always the same thing as the underlying audio format.
You also need to decide whether YouTube will receive audio only or audio with video. A radio relay can include a still image, a waveform, a station logo, or another moving visual. Once video is included, FFmpeg must encode and package both streams, and YouTube's video settings become relevant. They do not replace the audio settings.
For an audio-only plan, your main decisions are:
- the station input URL and its protocol
- whether FFmpeg should copy or re-encode the incoming audio
- the output codec, sample rate and bitrate
- the YouTube ingest URL and stream key
- how the process should behave when the source disconnects
The last item matters for an overnight relay. A station can stop responding even when your own computer and broadband connection are working. Reconnect behaviour depends on the input and on the FFmpeg build, so check the current FFmpeg documentation for the exact options rather than copying a flag from an unrelated command.
If the relay will run on a small computer, separate the audio problem from the machine problem. A long-running visual stream can use more CPU than a straightforward audio encode. The practical considerations in how to reduce CPU use for a 24/7 Indian music YouTube stream are relevant when your radio channel also carries a visual layer.
YouTube's recommended stereo audio settings
For stereo audio, YouTube's live encoder guidance lists AAC and MP3 as supported audio codecs, and recommends a 44.1 kHz sample rate with a 128 kbps stereo audio bitrate. These are YouTube ingest targets for the audio portion of the broadcast, not a claim that every station source already has those properties.
| Audio choice | Practical target for stereo radio | What it means in FFmpeg |
|---|---|---|
| Codec | AAC or MP3 | Select an encoder supported by your installed build and output format |
| Sample rate | 44.1 kHz | Resample when the source does not already use this rate |
| Bitrate | 128 kbps | Set the audio encoder target rather than applying a video bitrate |
| Channels | Stereo | Preserve two channels where the source genuinely provides stereo |
If the station arrives at a different sample rate, FFmpeg may resample it for the YouTube output. That changes the output; it does not improve a source that was already heavily compressed. If the station source is mono, forcing two channels creates a stereo-shaped output but does not create additional detail. Keep the output choice aligned with the material you own or are authorised to relay.
AAC and MP3 are both listed by YouTube as supported choices. The better choice for your particular setup can depend on which encoder is present in your FFmpeg build, how the destination container is being produced, and whether your source or workflow already expects one format. Do not assume that a codec name accepted by one build will have identical options in another.
The 128 kbps figure belongs to stereo audio. YouTube also publishes bitrate guidance for video at different resolutions, codecs and frame rates. Those figures are not alternate audio settings. Applying a video bitrate table to a radio-only stream can make you spend time solving the wrong problem.
YouTube's live encoder settings guidance is the place to check the current recommendations before you configure a new channel. The page can change, and your Live Control Room may expose options that depend on the type of broadcast you create.
Use RTMPS for live ingest
YouTube supports RTMP and RTMPS for live ingest and recommends RTMPS. RTMPS is RTMP carried over TLS or SSL, so it protects the connection between the encoder and YouTube while the stream is being sent. It does not change the station's original audio quality and it does not repair a poor source.
Copy the current RTMPS server URL from your own YouTube Live Control Room. Do not substitute the station URL for the destination URL. The station URL is the input that FFmpeg reads; the YouTube RTMPS URL is the output destination. Your stream key joins the output destination to the correct YouTube broadcast.
Treat the stream key as a password. Do not put a real key in a public script, screenshot, support request or article. If you think it has been exposed, replace it in Live Control Room before starting another relay. YouTube explains the encoder connection workflow in its live streaming setup instructions.
A command normally has three distinct parts even when it is written on one line: input options and the station URL, audio and possibly video output settings, and the YouTube destination containing the ingest URL and key. Keeping those parts separate makes troubleshooting easier. If the station plays locally but YouTube receives nothing, inspect the destination and output packaging rather than immediately changing the station input.
RTMPS is a transport recommendation, not an instruction to use a particular FFmpeg flag without checking your build. Confirm the syntax supported by the FFmpeg version installed on the machine that will run the stream. Also confirm that the URL scheme and TLS support are available in that build.
CBR and keyframe guidance applies to video
YouTube's general encoder guidance specifies constant bitrate, or CBR, and recommends a two-second keyframe frequency, with four seconds as the maximum. These settings describe the encoded video stream. A radio relay with no video does not acquire a video bitrate or keyframe requirement merely because it is being sent to YouTube Live.
If you add a still image or visualisation, the situation changes. You now need to choose a video codec, resolution, frame rate, video bitrate, rate-control mode and keyframe interval. The two-second keyframe recommendation belongs in that video configuration. It should not be inserted into an audio-only command as if it controlled the radio bitrate.
The same separation applies to bandwidth. Your outgoing requirement is the combined size of the audio, video and protocol overhead. A 128 kbps audio target is not the total bandwidth required by a stream carrying video. Conversely, an audio-only stream does not need the resolution-specific video bitrate shown in YouTube's encoder tables.
YouTube's encoder bitrate and resolution page includes guidance for different video arrangements. Read the row that matches the visual stream you actually send. If you use a static image, you still have a video stream, but you should not pretend that a video table is an audio recommendation.
For readers using a visual layer, this distinction also helps with capacity planning. Measure the available upload speed, compare it with the complete outgoing stream and leave the headroom recommended by YouTube. If the connection is shared with other household or office traffic, test it under the conditions in which the channel will run, not only when the network is quiet.
Why the FFmpeg command varies
A command that works for one radio station can fail for another without either operator making a mistake. The source might be delivered as a continuous MP3 stream, an AAC stream, a playlist reference or another input that requires different probing and demuxing. Some sources also expose metadata or redirects that affect how the input is opened.
The output decision is separate. You may be able to copy a compatible source in some workflows, but you may need to re-encode to meet YouTube's recommended sample rate, bitrate or codec. Copying avoids another lossy encode, but it does not give you control over the output characteristics. Re-encoding gives you those controls, while adding CPU work and another generation of compression.
The installed FFmpeg build matters as well. Encoders can be enabled or absent, option names can differ between versions, and a command copied from a guide may assume an input or muxer that your machine does not have. Operating system packaging can also provide an older or differently compiled build.
The delivery shape matters too. Audio alone is not configured in exactly the same way as a stream carrying a still image. A visual layer requires a video source, even if that source is only one image held on screen. Its duration, frame rate and looping behaviour must be defined so that FFmpeg continues producing a valid live output.
For that reason, use examples as patterns, not promises. Replace the station input and YouTube destination with your own values, then check every option against the current FFmpeg documentation and the actual input. No command should be called tested unless it has been run with that station, that destination format and that installed build.
If the station is already producing a reliable visual loop, you may find the broader packaging discussion in how to stream an FFmpeg playlist to YouTube with a static image between videos useful. It concerns a different source pattern, but it illustrates why adding video creates decisions beyond the radio audio itself.
Check the installed FFmpeg build and input format
Start on the machine that will run the relay. Check the FFmpeg version and list the available encoders and formats. The purpose is not to collect commands from a version screen; it is to confirm that the codec and output path you intend to use are present in the build you will actually operate overnight.
Next, inspect the station input without publishing it. Establish whether the URL opens, which stream is detected, what codec and sample rate are reported, and whether the connection remains readable for more than a brief moment. A source that plays in a browser is not automatically an input that your FFmpeg build can read.
Keep a small record of the source details:
| Check | Why it matters | Action if it fails |
|---|---|---|
| URL opens in FFmpeg | Confirms the input is readable by this build | Check redirects, protocol support and the station's current URL |
| Codec is identified | Determines whether copying or re-encoding is sensible | Choose a supported output codec and verify the required encoder |
| Sample rate is known | Shows whether resampling is needed | Set the output rate to the YouTube target when appropriate |
| Channels are known | Prevents accidental assumptions about stereo | Match the output to the actual source content |
| Stream remains active | Tests continuity rather than only startup | Investigate station interruptions and reconnect handling |
Do not publish the stream key while testing. Use the Live Control Room's preview and replace the key if it has appeared in a log, screen recording or shared configuration file. YouTube's stream health guidance explains the checks available while the broadcast is being received.
If the station owner provides a playlist URL rather than a direct stream, ask which address is intended for software players and whether relaying it is permitted. A playlist may change the actual audio URL over time. That is both a technical issue and a rights issue, so do not infer permission from the fact that a player can access it.
Test the output before going live
A dependable overnight test has separate stages. First, confirm the station input. Second, start an output to YouTube using the current RTMPS destination and a private or otherwise appropriate broadcast setting. Third, wait for the preview to appear in Live Control Room and listen for the audio there.
Check more than whether the status says that data is arriving. Listen for silence, clipping, one-sided audio, repeated reconnects, unexpected volume changes and gaps when the station changes programme. Watch whether the preview continues and whether YouTube reports an issue with the incoming stream.
YouTube recommends checking upload capacity and leaving 20% headroom. Think of that margin as protection against ordinary variation, not as a promise that a weak connection will become reliable. If your available upload is only just above the calculated stream requirement, another device uploading photographs or a video call can interrupt the relay.
For a visual stream, check that the image remains present and that the frame rate and resolution are what you intended. A still image can appear correct during a short test while the process later stops producing video frames. Monitor the output for long enough to expose the behaviour you are trying to prevent, especially when the source is known to change format or reconnect.
After the test, review the process logs. Look for input timeouts, encoder errors, muxing warnings and repeated connection attempts. Do not silence warnings simply to make the log look clean. A warning that occurs once may be harmless; the same warning every few seconds can explain a stream that fails during the night.
If you want to avoid keeping a personal computer awake for the whole broadcast, StreamNeo removes the particular burden of leaving your own machine running and watching for a dropped relay: upload the finished video, provide the YouTube stream key, and the channel can be run from the cloud with automatic monitoring and restarts. It is intended for uploaded video streams rather than a live internet-radio input, so it is not a replacement for configuring FFmpeg to relay a station.
For a source that must remain on a home computer, plan for power interruptions, operating-system updates and network changes. The checklist in how to keep a YouTube 24/7 stream online during Windows updates covers a different failure mode, but the principle is the same: test recovery instead of assuming that the first successful start proves overnight reliability.
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
Is 128 kbps the correct bitrate for YouTube radio audio?
YouTube's current guidance recommends 128 kbps for stereo audio, alongside a 44.1 kHz sample rate and AAC or MP3. Treat that as the audio target only. It is not a video bitrate and it is not the total bandwidth for a stream that also carries video.
Should I use RTMP or RTMPS with FFmpeg?
YouTube supports both, but recommends RTMPS for live ingest. Copy the current RTMPS URL from your own Live Control Room and confirm that your installed FFmpeg build supports the required connection.
Do keyframes matter for an audio-only radio stream?
Keyframes apply to video. If you send only audio, YouTube's two-second keyframe recommendation does not create a setting you need to add to the audio encoder. If you add a still image or other visual, configure the video stream separately and use YouTube's current keyframe guidance.
Can I copy an FFmpeg command from another radio station?
You can use it as a starting pattern, but you should not assume it is universal or tested for your setup. Check the source protocol and format, installed FFmpeg build, output type and current YouTube destination, then test the preview and stream health before leaving it unattended.