For H.264 YouTube Live, set your 1080p video bitrate according to frame rate: YouTube lists 14 Mbps recommended and 5 Mbps minimum at 30 fps, or 17 Mbps recommended and 6 Mbps minimum at 60 fps. Add audio separately, use constant bitrate (CBR) and a two-second keyframe interval, then check that your actual connection can sustain the combined output with room for variation.
Those figures are ingest guidance, not a promise of uninterrupted streaming or a guarantee of viewer quality. For a loop, the file-reading and repeat settings matter too, but they do not change the bitrate your connection has to carry.
Choose the frame rate before the bitrate
A 1080p label describes the frame dimensions, not how many frames are sent each second. A 30 fps video sends fewer frames than a 60 fps video; YouTube therefore publishes different H.264 ingest recommendations for each. Decide which rate suits the material before choosing a bitrate.
For a devotional image with slow movement, a study background, or a mostly static local noticeboard, 30 fps may be an appropriate choice. A loop with faster movement may benefit from 60 fps, provided the source is actually that smooth and your encoder and connection can sustain the greater demand. Increasing the output frame rate does not create detail absent from the source; it can instead repeat frames or force the encoder to spend bits on less useful changes.
Check the source file and your intended output together. If a 30 fps file is simply encoded at 60 fps, the result may use more network capacity without adding meaningful motion information. Conversely, a 60 fps source reduced to 30 fps will send fewer frames, which may be acceptable for slower content but can make movement less smooth.
The examples below assume a constant output rate. In FFmpeg, -r 30 or -r 60 can set the output frame rate, but decide deliberately rather than copying a command blindly. If you are still sorting out the source dimensions and output format, the guide to increasing video resolution for live streaming helps separate resolution from the other encoding choices.
YouTube's H.264 figures: minimum and recommended
YouTube’s H.264 video-ingest table distinguishes its minimum bitrate from its recommended bitrate. Treat the minimum as the lower listed threshold, not a target that guarantees a usable picture under every kind of motion. The recommended figure gives you a different starting point, but it still needs to fit your equipment and sustained upload capacity.
| 1080p output | H.264 minimum video bitrate | H.264 recommended video bitrate |
|---|---|---|
| 30 fps | 5 Mbps | 14 Mbps |
| 60 fps | 6 Mbps | 17 Mbps |
These figures come from YouTube Help’s live encoder settings, checked on 3 October 2026. They apply to the video stream, not a combined video-and-audio total. YouTube may change its guidance, so consult the current page when you configure a new stream.
If you choose the recommended H.264 video rate for 1080p30, a straightforward starting set of FFmpeg options is -b:v 14M -maxrate 14M -bufsize 28M. At 1080p60, the corresponding example is -b:v 17M -maxrate 17M -bufsize 34M. These options describe a rate target and a video buffer configuration; by themselves, they do not prove that the encoder is operating in strict CBR mode. Check the documentation for the encoder you are actually using and select its CBR mode where available.
You can choose a lower rate if your connection cannot sustain the recommended figure, but be clear about the trade-off: the picture may show more compression, especially during movement. The published minimum is not a shortcut to stable delivery. If you need to lower the output further, recheck YouTube’s current requirements and test the result with the content you plan to loop.
Keep audio bitrate separate
Audio consumes upload capacity too, but YouTube’s video figures above do not include it. Add the audio bitrate when estimating the total stream output. For stereo AAC, YouTube lists 128 kbps as its recommendation and 44.1 kHz as a recommended sample rate in the same live settings guidance.
For example, a 14 Mbps video stream plus 128 kbps audio has a nominal encoded total of about 14.128 Mbps before protocol overhead and network variation. This arithmetic is a planning aid, not a promise that the connection will carry the stream reliably. Audio can also vary if you select a different codec or bitrate, so recalculate using your actual output settings.
A file may already contain audio, or it may be silent. Inspect it rather than assuming that a soundtrack exists or that the input audio is suitable. The optional audio mapping in the example below, -map 0:a:0?, allows FFmpeg to continue if that input has no audio stream. If your loop is meant to include bhajans or meditation music, listen to the start and the loop boundary; encoding settings will not correct a source track that is clipped, out of sync, or cut awkwardly. For troubleshooting a specific encoder issue, see how to fix FFmpeg AAC errors in a looping meditation stream.
Set CBR and a two-second keyframe interval
YouTube recommends CBR for RTMP or RTMPS live ingest and recommends a keyframe every two seconds, with intervals not exceeding four seconds. CBR means the encoder aims to keep its output rate constant; this can make the stream easier to budget than a variable rate that rises sharply during complex scenes. It does not make the network itself constant or prevent a drop.
At a constant 30 fps, two seconds correspond to 60 frames, so the example GOP setting is -g 60. At 60 fps, use -g 120. Here, -g specifies the maximum distance between keyframes in frames; the conversion depends on the chosen output frame rate. If you change frame rate, revisit the GOP value rather than leaving an old number in place.
A practical H.264 starting pattern for an existing 30 fps file is shown below. It is illustrative, not a tested command, and you should adapt and validate it against your installed FFmpeg version and selected encoder. Replace the ingest address with the one currently provided in YouTube Live Control Room, and keep your stream key private.
ffmpeg -stream_loop -1 -re -i input.mp4 \\
-map 0:v:0 -map 0:a:0? \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-r 30 -b:v 14M -maxrate 14M -bufsize 28M -g 60 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://YOUR_INGEST_ENDPOINT/YOUR_STREAM_KEY'
-stream_loop -1 asks FFmpeg to repeat the input indefinitely; -re reads a file at real-time speed rather than sending it as fast as it can be processed. They do different jobs. Do not add -re indiscriminately to a live capture device or an already-live input. For a 60 fps version, change the output rate to 60, set the video rate to the selected 60 fps value and use -g 120.
FFmpeg notes that command-line options apply to the next specified file, so order matters. In this pattern, the input options precede -i, and the encoding and output options follow it. See the FFmpeg command-line documentation and check the options supported by your local build. The generic bitrate and buffer flags alone do not establish that libx264 or a hardware encoder is producing strict CBR; use the encoder’s own documented controls if you need to select that mode explicitly.
Budget upload capacity with headroom
A speed test is a snapshot, not proof that an upload connection will maintain a chosen rate overnight. Test the connection you will actually use, from the same location and over the same wired or wireless path as the streaming computer. Check sustained upload performance at different times if the connection is shared or known to vary. A short peak should not be your budget.
Add video and audio rates to estimate the encoded output, then leave capacity for protocol overhead and normal network variation. There is no single headroom percentage that fits every home, office, router, or ISP connection, so do not treat an invented universal margin as a rule. If the measured upload repeatedly approaches your stream’s total, choose a lower output rate or improve the connection before relying on the setup.
A wired Ethernet connection can remove some wireless variability between a computer and router, but it cannot increase the service’s available upload capacity. Likewise, changing a cable does not fix congestion upstream. For India-specific planning and the distinction between advertised and usable upload, see what upload speed you need for a 24/7 YouTube stream in India.
If the upload cannot sustain the recommended H.264 rate, consider whether 30 fps suits the material better than 60 fps, whether a lower tested video rate is acceptable, or whether another supported codec is practical. Lowering resolution may be another option, but this article’s figures are for 1080p. Do not keep the output unchanged and assume FFmpeg’s reconnect behaviour will compensate for insufficient capacity.
Compare the other listed codec recommendations
YouTube lists separate bitrate recommendations for AV1 and H.265, also called HEVC. Its current table gives the following values for 1080p ingest. These are codec-specific video figures, so audio must still be budgeted separately.
| Codec | 1080p30 minimum / recommended | 1080p60 minimum / recommended |
|---|---|---|
| H.264 | 5 / 14 Mbps | 6 / 17 Mbps |
| AV1 | 4 / 10 Mbps | 4 / 12 Mbps |
| H.265 (HEVC) | 4 / 10 Mbps | 4 / 12 Mbps |
The lower listed rates do not mean that switching codecs is automatically the right answer. Your chosen encoder must support the codec and its required settings, and the YouTube ingest path you use must accept it. H.264 is a broadly familiar starting point; an AV1 or H.265 setup may be sensible when you have a compatible encoder and have tested the full path. Confirm current compatibility and ingest guidance in YouTube Help before changing a working system.
These recommendations describe what is sent to YouTube, not the quality YouTube will deliver to each viewer after processing. A viewer’s playback rendition and connection are separate from your upload bitrate. If you are making the larger decision about which parts of a loop workflow to automate, compare the practical trade-offs in OBS playlist plugins versus FFmpeg scripts for a 24/7 stream.
Test the live result and monitor it
Before committing to an overnight loop, test the exact output settings with representative audio and movement. A static title card is not a useful test for a stream whose normal content has moving visuals or music. Check the preview and stream-health notices in YouTube Live Control Room, and make sure the sound, image and loop transition are all acceptable.
YouTube’s guidance is to test before going live with audio and video movement similar to the planned stream, then monitor stream health and review messages during the event. Keep the live dashboard visible during an initial run. Look for warnings, dropped frames, encoder overload, audio problems, or repeated disconnects; each points to a different possible cause and should not be collapsed into “wrong bitrate”.
Change one thing at a time when diagnosing a problem. If the encoder reports overload, reduce its work or select an appropriate preset; if upload capacity is inconsistent, test the network path or reduce the rate; if the picture is poor but delivery is steady, compare the source and output quality. After a change, run another representative test rather than assuming the issue is resolved.
FFmpeg documents an optional FIFO muxer pattern for attempting recovery from some transient RTMP output interruptions. Recovery can help with a temporary output problem, but cannot fix inadequate sustained upload, an overloaded encoder, power loss or a YouTube-side outage. Validate that your installed FFmpeg build includes the needed components and use its documentation before adding recovery options. Restart logic is not a substitute for monitoring the actual stream.
If managing a computer, the loop process and its recovery through the night is itself the burden you are trying to remove, StreamNeo turns an uploaded video into a YouTube live stream without requiring your computer to stay on.
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
Should I use YouTube’s minimum or recommended 1080p bitrate?
Use the recommended figure if your encoder and sustained upload can support it; YouTube lists 14 Mbps for H.264 1080p30 and 17 Mbps for H.264 1080p60. The minimums are 5 Mbps and 6 Mbps respectively, but selecting a minimum does not guarantee a stable stream or a particular viewing result. Test the actual content and connection.
Does -b:v 14M make FFmpeg use CBR?
Not by itself. It sets a video bitrate target, while -maxrate and -bufsize configure rate control behaviour; verify the selected encoder’s documentation and explicitly choose CBR mode if supported and required. Encoder options can differ across FFmpeg builds.
What keyframe value should I use for 1080p?
For the two-second interval YouTube recommends, use a GOP of 60 frames at 30 fps or 120 frames at 60 fps. These values assume a constant output frame rate. If you change the frame rate, recalculate the GOP in frames.
Can a reconnect option make my loop stable overnight?
No reconnect or recovery setting can guarantee that outcome. It may attempt to recover from some transient output interruptions, but it cannot supply missing upload capacity, fix an overloaded encoder, restore power or resolve a platform outage. Test and monitor the full setup, and check YouTube’s current live encoder settings before relying on it.