For a YouTube Live stream encoded with FFmpeg, use H.264 video and AAC audio, set a constant bitrate suited to your resolution and frame rate, and target a keyframe every two seconds. YouTube recommends RTMPS; confirm that your FFmpeg build and Live Control Room setup can use it before relying on a command.
There is no single command that fits every source file, capture device, FFmpeg build, or ingest destination. The example and checks below make their assumptions explicit so you can adapt them, test the result, and avoid treating a copied line as a guarantee.
YouTube Live’s codec requirements at a glance
YouTube’s live encoder settings guidance lists H.264 as a supported video codec and AAC or MP3 as supported audio codecs for RTMP/RTMPS ingest. This guide uses H.264 and AAC because they are the requested combination. YouTube lists frame rates up to 60 fps and constant bitrate encoding; those are platform recommendations, not proof that a particular computer or connection can sustain the chosen output.
The practical decisions fit together. Choose a resolution and frame rate your source can provide and your upload can sustain, set the corresponding bitrate, and calculate the keyframe cadence from the frame rate. For stereo audio, YouTube lists 44.1 kHz sampling and 128 Kbps. If you need 5.1 audio, consult its current guidance: YouTube lists AAC for 5.1, with different audio settings from stereo.
| Output choice | YouTube guidance | What to check in your setup |
|---|---|---|
| Video codec | H.264 is supported | An H.264 encoder is available in your FFmpeg build |
| Audio codec | AAC is supported | An AAC encoder is available and the intended audio stream is mapped |
| Rate control | Constant bitrate (CBR) | The selected encoder accepts the rate-control options you use |
| Frame rate | Up to 60 fps | The source and upload can sustain the selected rate |
| Keyframes | Every two seconds recommended; do not exceed four seconds | GOP length is expressed in frames for the chosen rate |
| Stereo audio | 44.1 kHz, 128 Kbps listed | The source is stereo or is deliberately mixed to stereo |
These are platform settings, not quality guarantees. A still devotional image, a lofi visualiser, and a news loop with frequent cuts may behave differently at the same nominal bitrate. Check the current YouTube page before a scheduled broadcast because its live-maintained recommendations can change.
Check your input and FFmpeg build
Start by identifying what FFmpeg will read. For a file, note its container, video and audio streams, resolution, frame rate, and whether it has multiple audio tracks. For a camera or capture device, identify the device-specific input syntax and any input options it needs. Those options differ by operating system and capture path, so a file example should not be pasted unchanged into a camera command.
FFmpeg’s command-line documentation explains that options normally apply to the next input or output. Input-specific options belong before the relevant -i; output encoding options belong after the input and before the output destination. This placement is easy to get wrong, especially when adapting a command with several inputs.
Check what your local executable can do rather than inferring it from an online example. ffmpeg -version identifies the build; ffmpeg -encoders lists compiled encoders, and ffmpeg -protocols lists protocols. Look for an H.264 encoder such as libx264 and an AAC encoder, but do not assume either name is present. Builds vary, and an encoder may be supplied under another name or omitted altogether. Likewise, protocol availability varies: confirm RTMPS support rather than assuming that every build can send to an RTMPS URL.
If a file has more than one video or audio stream, choose deliberately. FFmpeg’s -map option selects streams explicitly; without an intentional mapping, automatic selection may not pick the language, commentary, or camera feed you meant. Review the input first, and map the intended video and audio indices for that file. The indices in a command are specific to its input, not reusable labels.
Select H.264 video encoding
Encoding means decoding the source and producing a new video stream. It costs processing capacity and, in ordinary lossy encoding, can change image detail. Streamcopy, written as -c copy, passes packets through without re-encoding. It is useful when the existing codec and stream are already suitable, but it does not convert an incompatible video into H.264 or audio into AAC. The FFmpeg manual describes the distinction; choose the path based on the actual input rather than adding -c copy to a conversion command.
For a file-based example, suppose your input is input.mp4, it contains the video and audio you want, and your build has libx264 and an AAC encoder. This is a command outline, not a tested universal recipe:
ffmpeg -re -i input.mp4 \
-map 0:v:0 -map 0:a:0 \
-c:v libx264 -pix_fmt yuv420p \
-c:a aac -ar 44100 -b:a 128k \
-f flv "rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY"
The example maps the first video and first audio stream, asks for H.264 using libx264, and sets AAC audio. It deliberately leaves out resolution, frame rate, video bitrate, GOP and rate-control flags: set those only after choosing output characteristics and confirming that the selected encoder accepts the relevant options. It also uses a placeholder destination. Obtain the ingest URL and stream key from your YouTube Live setup, and never publish a real key in a script, screenshot, or support post.
-re reads a file at its native rate rather than sending it as fast as the machine can process it. This can be useful when using a file as a live source, but it is not a general-purpose performance fix; a live capture source already arrives in real time. If your source needs scaling, deinterlacing, frame-rate conversion, or a different pixel format, add and test the appropriate filter rather than assuming the example performs that work for you.
If libx264 is absent, do not conclude that FFmpeg cannot encode H.264. Check the available encoder list and documentation for your build, then substitute an available H.264 encoder and its own supported options. Encoder names and controls are not interchangeable. If your build has no suitable encoder, use a build or encoding path whose capabilities you have verified before a broadcast.
Configure AAC audio
Map the intended audio track, then encode it with AAC if the source audio is not already appropriate and you are transcoding. For stereo, the YouTube guidance lists 44.1 kHz and 128 Kbps. In the example, -ar 44100 requests that sample rate and -b:a 128k requests the audio bitrate. Verify the output channel layout as well: a stereo target is not achieved merely by setting the sample rate and bitrate if the selected source or filters produce something else.
FFmpeg options are scoped by position, so put audio output options after the input they affect and before the destination. If there is no audio stream, mapping 0:a:0 will fail; remove or change that mapping only after deciding whether the stream should have audio. If the file has multiple tracks, map the intended track rather than relying on the first one. For a practical always-on playlist, the issue of a stream moving between items is separate from codec selection; see this guide to keeping FFmpeg playlist order consistent.
Avoid re-encoding audio that you meant to pass through with -c:a copy if your goal is specifically AAC output. Conversely, avoid unnecessary transcoding when the source already meets your delivery needs and streamcopy is viable. Test for clipping, silence, channel imbalance, and synchronisation using the kind of material the channel will actually play. A quiet prayer recording and a music track with percussion can reveal different problems.
Set bitrate, frame rate, and keyframes
Select the output resolution and frame rate first, then consult YouTube’s bitrate table for that exact combination. Its current guidance lists 14 Mbps for H.264 at 1080p30, 17 Mbps at 1080p60, 8 Mbps at 720p30, and 8 Mbps at 720p60. These are YouTube recommendations, not a guarantee of picture quality or a promise that your upload connection is reliable. Other resolution and frame-rate combinations have their own entries on the official page.
A higher frame rate or resolution needs a suitable bitrate and more source and encoding capacity. If your source is 25 or 30 fps, up-converting it to 60 fps does not create new motion detail; it can add processing and bandwidth demands. For a static ambience scene, a lower frame rate may be adequate, while a local news loop with movement and cuts may make compression more visible. Choose based on source material, viewer needs, and measured upload stability rather than selecting the largest number in the table.
YouTube recommends a keyframe interval of two seconds and says not to exceed four seconds. FFmpeg’s GOP setting is generally expressed as a count of frames, so calculate the count from the output frame rate: at 30 fps, two seconds corresponds to 60 frames; at 60 fps it corresponds to 120. Do not copy one GOP count across different frame rates. Confirm the selected encoder’s option syntax, and verify the resulting stream rather than assuming the requested value took effect.
CBR means targeting a steady bitrate rather than allowing large swings in output rate. The exact flags for CBR can vary by encoder. For libx264, options commonly used for rate control include a target bitrate and buffer-related values, but their correct combination depends on the encoder and muxing context. Check the encoder’s own help (ffmpeg -h encoder=libx264, when available) and test how it behaves. If using another H.264 encoder, use its documented controls instead of carrying over libx264 flags.
The bitrate sent by the encoder is not the only demand on your connection: the stream must leave enough headroom for ordinary variation in the network and other household or business traffic. Measure the upload where the encoder will run, at the time the channel is likely to be live, and test the selected output. A connection that appears adequate in a quiet daytime check may behave differently when others are using it. If it cannot hold the chosen rate, lower the resolution or frame rate and retest rather than hoping the connection will recover mid-broadcast.
Use RTMPS and the correct ingest details
YouTube recommends RTMPS, which it describes as a secure extension of RTMP with data encrypted on the way into and through Google’s servers. Use the RTMPS ingest details displayed for your live setup, and confirm that the URL format and stream key are paired as YouTube specifies. Do not copy a destination from an unrelated tutorial: ingest details can be specific to your setup.
The protocol in the output URL must be supported by your installed FFmpeg build. Check ffmpeg -protocols, and if RTMPS is absent, resolve that capability before planning to use an RTMPS destination. Do not quietly replace it with RTMP without considering YouTube’s recommendation and the security trade-off. The destination also belongs at the end of the command, after output options. FFmpeg interprets options according to their position, so putting -c:v after the URL will not configure that output as intended.
Treat the stream key as a credential. Store it somewhere private, avoid sharing full command lines that include it, and rotate it in YouTube’s controls if it is exposed. For recurring broadcasts, keep a known-good command template with a placeholder rather than embedding a real key in a document others may copy. For the larger question of how a channel can keep a loop running, the spare-PC sermon loop guide covers a different operating choice from configuring FFmpeg’s output.
Test the stream before going live
Test with the same kind of movement, cuts, and audio that the real programme contains. YouTube advises testing before a live stream and monitoring stream health and messages during the event. A few minutes of a static title card will not reveal whether a fast-moving segment causes encoding pressure, whether audio remains in sync, or whether a particular song is too loud. Use a representative section, and check the preview and health indicators in YouTube Live Control Room.
Read both sides of a failure. FFmpeg’s console output can show a rejected option, missing encoder, unsupported protocol, or input problem. YouTube’s live diagnostics can show whether frames are arriving and flag stream issues. A successful FFmpeg process alone does not establish that viewers receive the intended image and sound. Likewise, a warning about dropped frames may have a different cause from an authentication or ingest error; narrow it down before changing several settings at once.
Change one variable at a time. First check that the input and mapping are correct, then confirm codec and protocol support, then tune bitrate, frame rate, and GOP. Save the command and note the output settings once a representative test works, but keep the stream key separate. If the channel is a 24/7 video loop, a cloud-based file-to-live workflow such as StreamNeo removes the specific need to keep your own computer encoding and sending that uploaded file continuously; it does not change YouTube’s codec requirements, and you should still verify the channel and stream settings.
A test is a rehearsal, not a guarantee. Recheck the current encoder guidance before an important broadcast, watch the stream after it starts, and have a fallback ready if your machine, source, connection, or ingest path behaves differently under real conditions. If your problem is that the stream stops unexpectedly rather than how to encode it, this guide to distinguishing encoder and internet failures can help you separate the likely causes.
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
Does every FFmpeg build support H.264 and AAC encoding?
No. Builds can differ in their compiled encoders and protocols. Check your local encoder and protocol lists, and use options documented for the encoder you actually have.
Can I use -c copy to make the stream H.264 and AAC?
No. Streamcopy passes already-encoded packets through; it does not convert their codecs. To convert incompatible source streams, select suitable encoders and transcode them.
What keyframe value should I use?
YouTube recommends a two-second interval and says not to exceed four seconds. If your encoder setting uses frames, derive the GOP count from the output frame rate, then test the result.
Which bitrate should I choose for 1080p?
Use the recommendation for your frame rate: YouTube’s current table lists 14 Mbps for H.264 at 1080p30 and 17 Mbps at 1080p60. Check its live guidance for the current values, and test that your source, encoder, and upload can sustain the choice.