YouTube’s latency setting—not your encoder’s bitrate—selects the stream’s Normal, Low or Ultra-low mode. Encoder settings can affect delay indirectly if the bitrate exceeds what your upload connection can sustain and causes ingest trouble or buffering.
For a 24/7 channel, choose the latency mode for the kind of viewing you want, then configure the encoder to match your resolution, frame rate and available upload capacity. YouTube recommends a two-second keyframe interval; in FFmpeg with libx264, that means setting -g to twice the frame rate, not using -g 60 for every stream.
Choose a latency mode before tuning the encoder
The latency choice lives in YouTube Live Control Room under Stream Settings. Your encoder sends a video stream with its own resolution, frame rate, codec and bitrate; it does not override that platform setting. YouTube describes latency as the time from capture to the event appearing on the stream, and offers Normal, Low and Ultra-low modes. See YouTube’s latency guidance for the current options and trade-offs.
Normal latency is intended for non-interactive broadcasts. It supports all resolutions and live features, and YouTube identifies it as offering the least viewer buffering. Low is intended for limited interaction; YouTube says most viewers experience less than 10 seconds of latency in this mode. Ultra-low is aimed at real-time conversation and engagement, with YouTube saying most viewers experience less than five seconds. Those are platform guidance figures, not a promise for any one viewer or connection.
Lower latency can mean less time to absorb network variation before playback, so YouTube warns that it may increase buffering. In particular, viewers can be more affected by ingestion problems in Ultra-low mode. Neither the less-than-five-second nor less-than-10-second guidance tells you what a particular bitrate setting will achieve.
For a devotional channel, a lofi station or a news loop with little audience interaction, Normal may be a more suitable starting point than Ultra-low. For a live Q&A, test Low or Ultra-low if timely audience response matters. Low and Ultra-low do not support 4K; YouTube’s encoder guidance says 2160p uses Normal latency. If you need 4K, plan around that constraint rather than attempting to force a lower latency through encoder settings.
Choose output resolution and frame rate
Set the output format to suit both the material and the connection. A static image with a slow devotional song may not benefit from the same frame rate as fast movement or a local news presentation with regular camera cuts. Higher resolutions and frame rates send more data and can require a higher bitrate; they are not, by themselves, a way to reduce latency.
YouTube’s RTMP/RTMPS encoder guidance supports frame rates up to 60 fps and lists H.264, H.265/HEVC and AV1 as video codec options. Check the current YouTube encoder settings and bitrate table before choosing, since supported settings and recommendations can change. For a basic H.264 workflow, match bitrate and keyframe calculations to the actual output frame rate—not the frame rate of the source file if your encoder converts it.
A practical choice for a simple loop might be 720p30 if the source is not detailed and the upload is constrained; a detailed 1080p60 source may justify a higher output if the connection can sustain it. These are choices to test, not quality guarantees. If your stream is a playlist or archive, the advice in how to calculate bandwidth for prerecorded video streams is useful when checking the connection’s overall load. Remove the accidental space after the opening parenthesis when using that link: the correct URL is /blog/how-to-calculate-bandwidth-for-streaming-prerecorded-videos-to-youtube-nonstop.
For camera-based broadcasts, a wired connection can remove one variable from a Wi-Fi path, but it does not create more capacity at the internet connection or set YouTube latency. YouTube recommends leaving upload headroom beyond the total stream bitrate and notes that a shared connection can reduce available bandwidth. Check what other users or devices are uploading before you attribute every interruption to the encoder.
Use CBR for H.264 ingest
For RTMP/RTMPS ingest, YouTube recommends constant bitrate (CBR) encoding. CBR aims to keep the video stream’s bitrate steady, which gives the upload connection a more predictable demand than a mode that varies substantially with scene complexity. It does not mean the network is perfectly steady, nor does it select a latency mode.
In FFmpeg, a typical libx264 starting point uses -b:v for the target video rate, -minrate and -maxrate at the same value, and -bufsize for the rate-control buffer. For example, for a 1080p30 H.264 test at YouTube’s listed recommended video rate, a command fragment might include -c:v libx264 -b:v 14M -minrate 14M -maxrate 14M -bufsize 28M. Treat that as an illustrative rate-control fragment, not a complete FFmpeg command or a guarantee that the output will look a particular way. Audio bitrate is separate and must also be included when estimating total upload demand.
Do not lower a suitable bitrate solely because you expect it to shorten end-to-end delay. YouTube does not document a direct rule that reducing bitrate reduces latency. If your upload path is constrained or unstable and the encoder is sending more data than it can sustain, reducing an excessive rate may help address ingestion trouble; that is a troubleshooting inference, not a measured latency result. Check Stream Health and compare the selected rate with YouTube’s recommendations before changing several settings at once.
If you need a refresher on the process of sending a file-based stream, the FFmpeg guide to running a 24/7 Indian classical music stream covers a related continuous-stream workflow. Whatever tool you use, make one adjustment at a time and test with representative content, including the motion and audio that will actually run overnight.
Set a two-second maximum GOP
A GOP is a group of pictures beginning with a keyframe, also called an IDR frame in this context. Keyframes give a decoder a point from which it can begin reconstructing the video without relying on earlier frames. YouTube recommends a keyframe frequency of two seconds and says the interval should not exceed four seconds. This is an encoder recommendation for ingest, not a guarantee about viewer delay or picture quality.
With H.264, the encoder’s GOP interval is commonly configured as a number of frames. That is why the same two-second interval needs a different -g value at different frame rates. At 30 frames per second, two seconds correspond to 60 frames; at 25 fps, they correspond to 50 frames. A fixed -g 60 therefore represents two seconds at 30 fps, but 2.4 seconds at 25 fps and one second at 60 fps.
The distinction matters for a continuous stream: an interval that is too long can fail to follow YouTube’s guidance, while an unnecessarily short interval may add keyframes more often than your chosen target. YouTube’s maximum four-second guidance is an upper limit, not the preferred value when you are aiming for the documented two-second recommendation. Keep the target and the maximum separate in your reasoning.
Calculate -g from frame rate
For constant-frame-rate output, calculate the GOP length in frames as:
-g = output frame rate × keyframe interval in seconds
For YouTube’s recommended two-second interval, multiply the output frame rate by 2. If the output is 24 fps, use -g 48; at 25 fps, use -g 50; at 30 fps, use -g 60; and at 60 fps, use -g 120. These values are examples of the calculation, not interchangeable defaults. In particular, do not carry -g 60 over to every frame rate.
A libx264 command fragment for a 25 fps stream could include -r 25 -c:v libx264 -g 50 -keyint_min 50 -sc_threshold 0. Here, -r 25 indicates the intended output rate, while the GOP values specify a 50-frame target. Disabling scene-cut keyframes helps keep keyframe placement predictable for this example; verify the behaviour of your full command and encoder version rather than assuming every wrapper handles options identically. If your output frame rate is variable, a simple frame-count calculation may not map cleanly to elapsed seconds, so test the actual stream and check the encoder’s documentation.
Keep frame rate and GOP in sync if you change output settings. A command copied from a 30 fps guide will not automatically remain a two-second GOP when you switch to 25 fps. If you are using a GUI encoder, look for keyframe interval or keyframe frequency measured in seconds; if it asks for frames, apply the same multiplication. YouTube’s current encoder settings documentation is the place to verify the platform recommendation before publishing a long-running stream.
Match bitrate to the output format
YouTube’s bitrate table varies recommendations by resolution, frame rate and ingest codec. The sample figures below are YouTube recommendations for ingest, not latency targets, quality guarantees or requirements that will fit every connection. They are listed as published on YouTube Help in October 2026; check the current table before relying on them.
| Output format | AV1 or H.265 recommended | H.264 recommended |
|---|---|---|
| 720p30 | 6 Mbps | 8 Mbps |
| 720p60 | 6 Mbps | 8 Mbps |
| 1080p30 | 10 Mbps | 14 Mbps |
| 1080p60 | 12 Mbps | 17 Mbps |
For an H.264 1080p30 output, use the H.264 column rather than the lower AV1/H.265 figure. For 720p30 H.264, the table’s listed recommendation is 8 Mbps. The comparison shows why “my stream is 1080p” is not enough information: frame rate and codec also affect which row and column to consult. The table is about encoder ingest, not what each viewer receives after YouTube processing.
YouTube also recommends leaving 20% upload bandwidth headroom beyond the total stream bitrate. Account for audio and any additional output demand when considering the connection; leave room for other devices if the connection is shared. A speed test is only a snapshot, so test at the time and under the network conditions in which the channel will run. You can compare the broader connection arithmetic in this bandwidth guide for nonstop YouTube video.
If the stream health indicator reports trouble, first check whether your actual upload capacity can support the selected output rate with the recommended headroom. Then consider a lower resolution, frame rate or excessive bitrate, one change at a time. Lowering rate can improve stability when the configured demand is beyond a constrained path, but it does not switch the stream from Normal to Low or Ultra-low, and it does not promise a particular delay.
Check keyframe interval and stream health
Before a long broadcast, preview the stream in Live Control Room and confirm the detected resolution, frame rate, codec and ingest health. YouTube’s guidance is to test the encoder in advance, preview the stream and monitor audio and video. A short test should include a high-motion section as well as the calmer material; a static opening frame alone may not reveal encoder or upload problems that appear later.
If you see dropped frames or unstable ingest, distinguish local encoding limits from network capacity. Check whether the computer is overloaded, whether another device is using the connection, and whether the chosen bitrate leaves headroom. If you are using a stream key, verify that the key and stream destination are current as part of the same diagnosis. For a recurring 24/7 issue, the checklist for fixing disconnects caused by a stale RTMP stream key covers that separate failure mode.
A healthy encoder preview is not proof that every viewer has the same latency. Viewer location, playback conditions and buffering behaviour can differ. Compare like with like when testing modes: use the same output format and network, change the latency setting in Live Control Room, and observe whether the interaction benefit is worth the possible buffering trade-off. Do not claim a precise delay from an encoder setting alone.
For an unattended loop, plan what happens if the source encoder or connection stops, and check the broadcast again after a realistic run. StreamNeo is relevant when the particular pain is needing to keep your own computer on solely to repeat an uploaded video: it runs that file as a YouTube live stream without requiring your computer to remain on, rather than changing YouTube’s latency mode or guaranteeing a delay.
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 lowering my bitrate reduce YouTube Live delay?
Not as a direct, documented rule. Latency mode is selected separately in Live Control Room, and a lower suitable bitrate is not documented as a way to change that mode. If the current rate exceeds what a constrained connection can sustain, reducing it may help with ingest stability, but test and monitor rather than assuming a particular delay.
What -g value should I use for a two-second keyframe interval?
Multiply the output frame rate by two. That gives -g 48 at 24 fps, -g 50 at 25 fps, -g 60 at 30 fps and -g 120 at 60 fps. A value of 60 is not correct for every frame rate.
Should a 24/7 music stream use Ultra-low latency?
Usually, select latency according to interaction needs, not because a channel runs continuously. If listeners mainly play the stream in the background, Normal may be a sensible starting point; Ultra-low is designed for real-time conversation and can make viewers more sensitive to ingest issues. Test the mode with the audience experience you need.