For a stereo sleep-sounds stream, set FFmpeg to AAC audio at 128 Kbps and a 44.1 kHz sample rate: -c:a aac -b:a 128k -ar 44100. These are YouTube’s general stereo live-encoder recommendations, not a guarantee that every source will sound better at that setting.
The audio bitrate is controlled by -b:a, not -b:v. The latter applies to video. You still need to adapt the input, video codec, video bitrate, frame rate, resolution and YouTube ingest address to your own file and channel.
Recommended stereo audio settings
For the usual sleep ambience stream with left and right channels, the relevant FFmpeg output options are:
-c:a aac -b:a 128k -ar 44100
Here is what each setting represents:
| Setting | Value for stereo live audio | Purpose |
|---|---|---|
| Audio codec | AAC | Encodes the audio sent to YouTube |
| Audio bitrate | 128 Kbps | Sets the target rate for the AAC audio stream |
| Sample rate | 44.1 kHz | Follows YouTube’s stereo live-encoder guidance |
| Channel layout | Stereo | Preserves left and right channels when the source supports them |
YouTube’s official live encoder settings list AAC or MP3 as supported live audio codecs. The same guidance lists 128 Kbps and 44.1 kHz for stereo audio. It lists different values for 5.1 surround sound, but a sleep-sounds channel does not automatically need a surround mix.
There is no sleep-specific bitrate study in the evidence used for this guide. The 128 Kbps value comes from YouTube’s general stereo recommendation, rather than from a comparison of rain, brown noise, fan recordings or other sleep audio. It is therefore a sensible starting point for the platform, not an audible-quality promise.
A higher bitrate cannot restore detail that was removed when the original recording was compressed. If your source is already a low-quality MP3, encoding it again at 128 Kbps will not recreate the missing information. It can still produce a suitable live output, but the source, mixing and loudness remain important.
Do not reduce the audio bitrate simply because the picture is a still image or a dark night-time scene. Viewers are still receiving the ambience, and the audio stream has its own encoding requirements. Conversely, if the source is silent, changing the bitrate will not create sound. Confirm that the file contains the intended audio before building the streaming command.
What the FFmpeg audio flags do
FFmpeg uses stream specifiers to apply an option to a particular type of stream. In -b:a 128k, the :a means audio. This makes the command clear when video and audio are configured together.
-b:a 128k
The k suffix expresses the value in kilobits per second. FFmpeg also supports a generic bitrate option, but the audio-specific form avoids confusion in a command that contains both audio and video settings. FFmpeg documents the audio bitrate option and its native AAC encoder in its official codec documentation.
The codec option selects AAC:
-c:a aac
The sample-rate option sets the audio sampling rate:
-ar 44100
The number is expressed in samples per second. It is separate from bitrate. A 44.1 kHz sample rate does not mean 44.1 Kbps, and changing one does not automatically change the other.
The native FFmpeg AAC encoder uses constant bitrate mode when you specify a bitrate. That gives the output a defined target of 128 Kbps for the audio stream. It does not mean the complete live stream will use 128 Kbps, because the video stream, container overhead and transport also consume bandwidth.
You can inspect the input before encoding with ffprobe, which is distributed with FFmpeg:
ffprobe -v error -select_streams a:0 \
-show_entries stream=codec_name,sample_rate,channels,channel_layout \
-of default=noprint_wrappers=1 input.mp4
This helps you see whether the file has an audio stream, how many channels it contains and what sample rate it uses. It does not prove that the final output will be accepted by YouTube, so treat it as an input check rather than a live test.
If you also use -map, be deliberate. A command that maps only video can create an output with no audio, even though the original file contains sound. For example, -map 0:v:0 selects the first video stream only. To select the first video and first audio stream, use -map 0:v:0 -map 0:a:0, provided both streams exist.
An example output command
Assuming input.mp4 already contains the intended video and audio, this is an illustrative command:
ffmpeg -i input.mp4 \
-c:v libx264 -b:v 4500k \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY"
The audio settings in this example are -c:a aac -b:a 128k -ar 44100. The video settings are the options beginning with -c:v and -b:v. The 4500k video bitrate is included only to show where video options sit in the command. It is not a universal YouTube recommendation and should not be copied without checking whether it suits your selected codec, resolution and frame rate.
The command also assumes that the input already provides a video stream. It is not a complete command for turning a standalone audio file into a video stream. YouTube Live needs a video stream as well as audio, so an audio-only source requires a deliberate video input, such as a still image or generated visual, and appropriate mapping.
For a simple file containing one video and one audio stream, FFmpeg often maps suitable streams automatically. When the file has multiple audio tracks, subtitles, attached images or unusual metadata, automatic selection may not match your intention. Inspect the file first, then add explicit mapping if necessary.
You can add -loglevel info while testing to make the console output easier to inspect. FFmpeg should report the selected audio codec, sample rate and channel layout when it starts. If the output line shows video but no audio, stop and correct the command rather than relying on YouTube to repair it.
The output format is FLV because that is commonly used for RTMP and RTMPS live delivery. The destination URL is quoted so that shell characters in a real address do not get interpreted unexpectedly. Keep the actual key out of screenshots, shell history shared with others and public support posts.
Set the input and video options
The audio flags are only one part of the output. Before choosing them, establish what your source actually contains. A sleep-sounds video may be a long rendered file, a short loop, a still image paired with an audio recording or a playlist of separate files. Each arrangement changes the input portion of the command.
For a rendered MP4, begin with:
ffmpeg -i sleep-sounds.mp4 \
-c:v libx264 -c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY"
This is still only a skeleton. You must choose video settings that match the actual file and the current YouTube guidance. The command does not establish a suitable resolution, frame rate, pixel format or video bitrate for every channel.
If your source contains a still image and a separate audio file, you need two inputs and must create a video stream from the image. A simplified pattern looks like this:
ffmpeg -loop 1 -i cover.jpg -i ambience.wav \
-map 0:v:0 -map 1:a:0 \
-c:v libx264 -c:a aac -b:a 128k -ar 44100 \
-shortest \
-f flv "rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY"
Do not treat this as a ready-to-run 24/7 loop. -shortest can end the output when the shorter input finishes, and a single still-image input may need duration or looping behaviour suited to your file. The point is to show that the image and audio need to be mapped separately, while the audio bitrate remains -b:a 128k.
For a long-running channel, confirm how the input ends. A finite MP4 will eventually stop unless you loop it or use a playlist workflow. If you are rotating several files, the guide to running a YouTube livestream continuously with a playlist file covers a different part of the problem: keeping content moving after one file finishes.
You should also think about transitions. If one recording is substantially louder than the next, viewers may experience an abrupt change even though both files use the same AAC bitrate. Normalise or mix the source before streaming where appropriate, and listen to the joins in a private test rather than assuming that identical encoder flags make the programme consistent.
A computer-based setup needs more than a correct command. It needs a stable power arrangement, a reliable network path and a way to restart the process after an interruption. If you are considering a spare machine, compare the operational details in how to set up an always-on YouTube channel with a spare PC, including what happens when the machine sleeps, reboots or loses its connection.
Use YouTube’s ingest URL and private key
YouTube provides the live destination through the channel’s live-control workflow. The ingest address and stream key are separate pieces of information that together identify where FFmpeg should send the broadcast. Copy them from the current YouTube interface rather than relying on an old command saved months ago.
In the example, they appear as placeholders:
rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY
Replace the entire placeholder destination with the address and key YouTube gives you. Do not paste a real key into a public article, a public code repository, a shared screenshot or a support message. Anyone who obtains it may be able to send content to the associated live setup until you revoke or reset it.
You can read about the objects involved in YouTube’s live workflow in the YouTube Live Streaming API documentation. The API documentation is not a substitute for the current Live Control Room instructions, but it is a primary reference for the live-stream resource and its ingest settings.
Use RTMPS when YouTube supplies an RTMPS endpoint and your FFmpeg build supports it. Check the address carefully for missing characters, extra spaces or a key copied with surrounding punctuation. A valid media command can still fail to connect if the destination string is wrong.
Treat the stream key as a credential. If you believe it has been exposed, rotate or reset it through YouTube rather than continuing to use it. The same caution applies if you automate the command in a script: restrict access to the script and avoid printing the full destination in logs that other users can read.
The live destination does not determine your audio quality by itself. FFmpeg must still produce an output containing AAC audio at the intended bitrate and sample rate, and YouTube must receive that output without transport or codec errors.
Test the output before going live
YouTube’s instruction is simple: test before starting the live stream. The test should use audio and movement similar to the real programme, and you should watch the stream-health messages rather than checking only whether FFmpeg connects.
Start by checking the local FFmpeg output. Look for an audio stream in the startup information and confirm the reported codec, sample rate and channel count. If you used explicit mapping, verify that the selected audio stream is the one you intended. A file can contain several tracks, including a silent track, and FFmpeg may not know which one you prefer.
Then check the receiving side in YouTube’s live controls. Confirm that audio is detected, that the preview is moving as expected and that the health panel is not reporting a codec, bitrate or sample-rate problem. YouTube may transcode the live stream into multiple viewer formats, so the local output and the viewer-facing result are related but not identical.
Listen to the private or unlisted output with headphones and speakers. Check for:
- silence caused by incorrect mapping
- clipping during louder rain, music or environmental sounds
- an unexpectedly narrow or unbalanced stereo image
- clicks at the beginning or end of a loop
- a sample-rate or channel-layout conversion that changes the character of the recording
- a video that stops while the audio continues, or the reverse
Use a representative section rather than a quiet opening alone. If your normal stream contains thunder, music, traffic, birds or other peaks, include those in the test. A calm first minute can hide clipping that appears later.
Do not interpret a clean connection as proof that the stream will run unattended indefinitely. Check the process after it has been running long enough to expose input, network and output problems, then decide how you will be alerted if it stops. For a local FFmpeg setup, a service manager can restart a process, but it does not make an unsuitable input or exposed stream key safe. The systemd guide for an always-on FFmpeg YouTube stream is relevant if you are managing the process on Linux.
If you do not want your own computer encoding and reconnecting throughout the day, StreamNeo removes that particular operational burden by letting you upload the prepared video, provide the YouTube stream key privately and let the broadcast run while your computer is switched off. You still need to prepare suitable media, check YouTube’s current rules and test the resulting channel output.
Power and network planning matter as well. A machine that sleeps, changes networks or reboots after an update can interrupt an otherwise correct command. If you are comparing local hardware with a hosted arrangement, the guide to 24/7 streaming costs explains the practical trade-offs without changing the audio setting itself.
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 enough for sleep sounds on YouTube?
For stereo live audio, 128 Kbps is YouTube’s stated general recommendation and is the appropriate starting value for this setup. It does not guarantee a particular listening experience, especially when the source has already been compressed or poorly recorded.
Should I use -b:a or -b:v for audio?
Use -b:a for audio, as in -b:a 128k. -b:v configures video, so changing it will not set the AAC audio bitrate.
Does a still image mean I can lower the audio bitrate?
No. A still image changes the video workload, but it does not change the audio stream’s requirements. Keep the intended ambience in the audio input and configure the audio separately from the video.
Can I share my YouTube stream key when asking for help?
No. Treat it as private account access and redact it before sharing a command or screenshot. If it has been exposed, reset or rotate it in YouTube before using the stream again.