For ordinary stereo audio in a YouTube Live RTMP or RTMPS stream, use AAC at 44.1 kHz and 128 Kbps. To repeat a file indefinitely with FFmpeg, put -stream_loop -1 before the -i that opens that file.
Those settings make a useful starting point, not a guarantee of uninterrupted streaming. You still need to use the stream details from YouTube Studio, check the encoded output and test the complete stream before relying on it overnight.
YouTube’s recommended stereo AAC settings
YouTube’s live encoder guidance recommends AAC or MP3 audio for RTMP and RTMPS ingestion. For stereo audio, its recommended configuration is a 44.1 kHz sample rate and 128 Kbps bitrate. These are recommendations for a common stereo stream, not a claim that any other setting is technically impossible.
For this guide, AAC is the straightforward choice because FFmpeg includes a native AAC encoder. The three audio options in the example below make the intended output explicit: -c:a aac selects AAC, -ar 44100 requests 44.1 kHz, and -ac 2 requests two channels. The bitrate option sets the target to 128 Kbps.
| Audio configuration | Sample rate | Audio bitrate | When it applies |
|---|---|---|---|
| Stereo | 44.1 kHz | 128 Kbps | The ordinary stereo recommendation discussed here |
| 5.1 surround | 48 kHz | 384 Kbps | A different channel layout; RTMP/RTMPS 5.1 requires AAC |
These figures come from YouTube’s live encoder settings guidance, which also covers video codec, resolution, frame rate and bitrate. Do not treat the audio row as a complete encoder configuration: video contributes to total upload demand, and its settings depend on what you are streaming.
If your programme is music, prayer or spoken material, the source itself matters too. A file with quiet passages, clipped peaks or large loudness differences between tracks will not be repaired merely by choosing AAC. For a playlist made from separate files, see how to normalise audio levels across videos in an FFmpeg YouTube playlist. Normalisation and encoder settings address different problems.
Set AAC, 44.1 kHz, 128 Kbps and stereo
A practical starting command for a file with both video and audio is:
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-c:v libx264 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv 'rtmps://a.rtmp.youtube.com/live2/STREAM_KEY'
Replace input.mp4 with your media file and replace the destination placeholder with the RTMPS address and stream key shown for your broadcast in YouTube Studio. Do not publish a real key in a script shared with others, a screenshot or a public repository. Treat it like a password: anyone who can use it may be able to send a feed to your broadcast destination.
The audio arguments have separate jobs. -c:a aac chooses the audio codec; -b:a 128k sets the encoder bitrate; -ar 44100 asks for a 44,100 Hz output sample rate; and -ac 2 asks for two audio channels. FFmpeg documents its native AAC encoder as the default AAC encoder, and its bitrate option uses bits per second. For this encoder, specifying the bitrate activates constant-bitrate mode. Writing the value explicitly is useful even where a default might otherwise match it, because it makes the intended configuration visible when you revisit the command.
These are output settings, so they do not prove that every source file contains useful stereo audio. A mono source can be encoded into a two-channel output, but that does not create a second independent performance. If the input is silent, has an unexpected audio stream, or decodes badly, the output can still be unsuitable. Check your actual FFmpeg build and the input material rather than assuming a command line guarantees the audio you intend.
The video arguments shown are illustrative, not a complete recommendation for every machine or event. -c:v libx264 chooses a video encoder; the example does not set a video bitrate, resolution, frame rate or keyframe interval. YouTube recommends constant bitrate for live encoding and a two-second keyframe interval, with a maximum interval of four seconds. Choose video settings for the source and intended presentation, then verify them in Live Control Room. Audio compatibility alone does not establish that the video feed meets your needs.
For audio-only material, do not simply assume this video-and-audio example establishes a universal audio-only workflow. The right setup depends on the YouTube workflow and what visual stream it requires. If you are building a prerecorded channel rather than operating FFmpeg yourself, FFmpeg and cloud streaming compared for a prerecorded YouTube channel can help you think through the operating trade-off without changing the audio requirements.
Send the RTMP workflow over RTMPS
RTMP and RTMPS are related ingestion protocols, but YouTube recommends RTMPS, describing it as a secure extension to RTMP. The example uses an RTMPS destination and the FLV output muxer for this RTMP-family workflow. Use the actual endpoint and key supplied for your stream in YouTube Studio rather than copying a placeholder literally.
The destination string in the example is a pattern, not a universal key or a command published by YouTube. Your Studio settings are authoritative for the stream you are configuring. If you rotate or replace a stream key, update the command or saved encoder configuration accordingly. Avoid pasting the key into a public post when asking for technical help; redact it first.
Do not mix up RTMP/RTMPS and HLS instructions. HLS is a separate YouTube ingestion route with its own segment and playlist requirements. Although YouTube’s HLS documentation also lists AAC and the same stereo audio recommendations, an RTMP/FLV command is not an HLS setup. If you choose HLS, follow the separate HLS setup instructions rather than adapting the destination alone.
Protocol choice does not remove the need to check the rest of the path. You need a readable input, a working encoder, the correct destination, a valid key, and enough network capacity for audio and video together. YouTube’s streaming tips recommend upload bandwidth headroom of 20 percent. Consider that against the total stream bitrate, not just the audio bitrate: a 128 Kbps audio track is only one part of the feed.
Make FFmpeg repeat the input indefinitely
FFmpeg’s -stream_loop option controls how an input is read. A value of -1 means infinite looping: when FFmpeg reaches the end of that input, it starts reading it again. That is the behaviour needed when one prerecorded file is intended to supply the programme repeatedly.
A file loop concerns the input, not the YouTube connection. It does not send a new stream key, diagnose a failed upload, correct a damaged file or guarantee that viewers see a continuous broadcast. If the process stops, the network drops, timestamps cause trouble or YouTube reports a stream issue, an infinite input loop does not by itself resolve that condition.
The -re option in the example asks FFmpeg to read the file at its native rate rather than consume it as fast as possible. It is commonly useful when sending prerecorded content as a live feed. It is distinct from looping: -re affects reading pace, while -stream_loop -1 controls what happens at the end of the input.
For a 24/7 devotional or instrumental channel, a single file can be a simple source, while a playlist may be a better fit if you need variation or planned transitions. The guide to building a 24/7 Hindustani instrumental radio stream from prerecorded tracks addresses that broader programming decision. Whatever the source arrangement, confirm how the chosen tool handles the end of each item and test the transition, not only the opening minutes.
Put the loop option before its input
The position of -stream_loop -1 matters because it is an input option. Put it before the -i for the file it should repeat:
ffmpeg -stream_loop -1 -i input.mp4 ...
In the full command, -re also appears before the input, followed by the input option and then -i input.mp4. This makes it clear that the loop applies to input.mp4. If a command has multiple inputs, place the loop option before the particular -i you mean it to affect.
Do not put the loop option after the input it is meant to repeat. In this command structure, options after an input may apply to a different part of the command rather than retroactively changing how FFmpeg opened the earlier input. If your file is not repeating, inspect the ordering first. The correct placement is before the relevant -i, not somewhere after the filename or just before the destination.
When editing a long command, keep each input’s options next to that input. For example, if you later add a separate audio file, decide whether that file should loop too and place the loop option before its own -i. A video input looping indefinitely does not automatically mean a separately opened audio input has the same behaviour.
Know what zero loops means
The numeric values are easy to misread: -stream_loop -1 requests infinite looping, while -stream_loop 0 means no looping. Zero does not mean “repeat forever” or “loop once”. If you want FFmpeg to repeat the file continuously, use -1; if you do not want looping, omit the option or use zero as appropriate for your command.
This distinction is particularly useful when copying or generating commands. A value that looks like a conventional setting of zero can silently leave you with a single pass through the source. After the file reaches the end, the process may stop producing the intended programme even though the AAC arguments were correct. Check the option value and its placement together: -1 before the matching input is the infinite-loop pattern.
If a single pass is actually what you want, such as a scheduled event with a definite ending, do not add an infinite loop merely because it appears in a reusable template. The source duration and the intended broadcast duration should agree. Decide first whether the programme is meant to end, repeat, or transition to another item, then build and test the input arrangement for that behaviour.
Validate the stream before you rely on it
YouTube recommends testing before starting a live stream. For a continuous channel, make the test resemble the actual programme: use the same media, audio level, video movement, command, network connection and stream destination where practical. A short test of a still image and silence will not tell you whether a music file has clipping, whether a loop boundary clicks, or whether a busy visual scene causes encoder load.
Check the encoded output as well as the command. Confirm that audio is present, that the channel layout and sample rate are what you expect, and that the bitrate is configured as intended. Listen across a file boundary, because a repeated source may reveal a pop, abrupt silence or a timing discontinuity at the join. Watch the YouTube Live Control Room for stream health and messages; a process continuing to run locally is not proof that YouTube is receiving a healthy feed.
The loop does not guarantee uninterrupted playback. Network outages, decode errors, timestamp problems, mismatched source streams, encoder load, a wrong key and platform-side conditions can all interrupt a real broadcast. Plan a way to notice a failure and respond to it. For persistent channels, consider whether you can check the feed at times when nobody is physically near the computer, and establish who will act if the test or overnight monitoring shows a problem.
Network headroom matters when you choose video settings. YouTube’s streaming tips recommend 20 percent additional upload bandwidth beyond the stream bitrate. Measure or otherwise establish the available upload capacity under realistic conditions, and account for other devices using the same connection. Avoid treating the audio figure as the total required upload rate, because video generally contributes substantially to the feed.
If you are weighing a local FFmpeg process against a workflow that does not depend on your own computer staying on, consider the operational burden as well as the command. For example, a devotional channel using a fixed prerecorded programme may prefer not to leave a home computer running overnight; StreamNeo removes that particular requirement by taking an uploaded video and running it as a YouTube live stream with the creator’s computer off. It does not change the need to prepare appropriate media or check that the channel and stream are ready.
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
What AAC bitrate should I use for YouTube Live?
For a standard stereo RTMP or RTMPS stream, YouTube recommends AAC audio at 128 Kbps. Set it explicitly with -b:a 128k in FFmpeg, while remembering that video bitrate and network capacity are separate considerations.
What sample rate does YouTube Live recommend for stereo?
YouTube’s live encoder guidance recommends 44.1 kHz for stereo audio. In FFmpeg, -ar 44100 requests that output sample rate; check the actual output and source material rather than assuming the request repairs every input issue.
Does -stream_loop -1 work with RTMPS?
The loop option controls how FFmpeg reads its input file, while RTMPS is the protocol used to send the encoded stream to YouTube. You can use the looped input in an RTMPS workflow, but the option must be before the relevant -i and does not guarantee a continuous connection.
What happens if I set -stream_loop 0?
Zero means no looping, so FFmpeg reads the input once rather than repeating it indefinitely. Use -stream_loop -1 before the file’s -i when you want an infinite input loop, then test the broadcast and monitor stream health.