If YouTube Live reports “keyframe frequency is too high”, check the GOP interval configured for the video encoder and set it to a regular interval of about two seconds. In FFmpeg, -g sets the maximum GOP size; choose its frame count from the output frame rate rather than copying a value from another stream.
For H.264 with libx264 at 30 fps, -g 60 is a useful starting example, not a universal fix. At 60 fps, the corresponding two-second value is 120. The encoder, its supported options, the actual output frame rate and YouTube’s stream-health message all matter.
What the warning is telling you
A GOP, or group of pictures, is a sequence of video frames that starts with a keyframe and continues until another keyframe begins a new group. The keyframe gives a decoder a reference point from which it can reconstruct the following frames. GOP size therefore affects how frequently those reference points appear in the stream.
YouTube’s error guidance describes this family of warnings as keyframes being sent “too often or not often enough”. The specific wording matters: a report that keyframes are too frequent points you towards an interval that may be shorter than intended, while a message about them being too infrequent points in the opposite direction. Do not treat all GOP-related messages as the same fault. YouTube’s live streaming error guidance gives the context for this diagnostic.
The warning is about the encoded video reaching YouTube, not necessarily the setting you meant to apply. A command may specify one encoder while the build, output mode or application selects another. A change in output frame rate can also make a previously sensible GOP count produce a different interval in seconds. Check what is actually being sent before changing unrelated settings.
Keep the scope narrow at first. The keyframe message by itself does not show that bitrate, resolution, audio, or network settings need adjustment. If YouTube reports separate dropped-frame or network problems, investigate those separately; the guide to improving live stream quality and preventing dropped frames covers those symptoms without confusing them with GOP cadence.
Aim for a regular interval of about two seconds
YouTube’s live encoder guidance recommends a two-second keyframe interval and says not to exceed four seconds. Those are interval lengths, not frame counts, so you must translate them for the frame rate of the outgoing stream. YouTube’s encoder settings page is the official reference to check before a live broadcast, since platform guidance can change.
For this repair, use a regular interval near two seconds as the starting point. If the diagnostic says keyframes are too frequent, inspect whether the configured GOP is substantially shorter than that target. If it says they are not frequent enough, the configured interval may be longer than intended. The warning does not justify making the interval arbitrarily short: a regular cadence is the objective, not the largest possible count of keyframes.
YouTube also notes that frame rate and keyframe frequency are linked. If you change the frame rate, recalculate the GOP count; do not assume a fixed -g value means the same number of seconds across frame rates. The maximum interval guidance is a separate boundary, not a reason to target that longer interval when the two-second recommendation is practical for your encoder.
Convert the interval into frames
The basic calculation is:
GOP size in frames = output frame rate × interval in seconds
Use the output frame rate that FFmpeg is producing, not merely the frame rate shown by the source file or selected in an editor. At 30 fps, two seconds is 60 frames. At 60 fps, it is 120 frames. YouTube’s error guidance explicitly gives the 30 fps, 60-frame example; the 60 fps figure follows from the same conversion.
| Output frame rate | Approximate two-second interval | Example maximum GOP size |
|---|---|---|
| 30 fps | 2 seconds | 60 frames |
| 60 fps | 2 seconds | 120 frames |
These examples assume the output frame rate remains as stated. If your stream is variable frame rate or being converted between rates, first establish the rate of the encoded output and how the selected encoder interprets GOP settings. A count is meaningful only in relation to the output cadence. If the command uses a different encoder, verify that its GOP option has the same meaning and syntax before applying the example.
The -g option sets the maximum GOP size in FFmpeg. “Maximum” matters: it describes a limit, and by itself it does not prove that every encoder will emit keyframes at precisely the interval you expect in every circumstance. Encoder-specific keyframe decisions, other options, version differences and the stream reaching YouTube can all affect what you observe. For reference, the FFmpeg codecs documentation describes GOP-related controls, including encoder-specific behaviour.
H.264 at 30 fps: a minimal example
For an H.264 output using the libx264 encoder at 30 fps, add -g 60 to the video-encoding portion of the command as a starting point. For example:
ffmpeg -i input.mp4 -c:v libx264 -g 60 -c:a aac output.mp4
This is an illustrative configuration, not a complete YouTube publishing command and not a command tested against your FFmpeg build. It shows the relevant GOP setting alongside a stated encoder and frame rate. If your command already has input, audio, output, or other encoding options, preserve the parts you need and change only what the diagnosis supports.
Do not read this as “set -g 60 for YouTube”. It is the two-second count for a 30 fps stream. At another frame rate, the same value represents a different duration. It is also specific here to an H.264/libx264 example; other codecs or encoders may use different option names or have additional constraints.
Before relying on the option, ask FFmpeg which encoder your command selects and inspect its supported options. The command-line help form ffmpeg -h encoder=libx264 can show options for that encoder when it is available in your build. If your command uses a different encoder, substitute its actual name in the help request. The [FFmpeg documentation] (https://ffmpeg.org/ffmpeg-codecs.html) is useful background, but your installed build’s encoder help is the practical check for local syntax.
At 60 fps, recalculate rather than reuse
At 60 fps, an interval of about two seconds corresponds to 120 frames. If the stream is H.264 and uses libx264, that makes -g 120 a reasonable starting example for this frame rate. It does not make -g 60 wrong in every situation, but -g 60 at 60 fps describes roughly a one-second maximum GOP, not a two-second one.
The same calculation applies whenever your output rate differs: multiply frames per second by the target interval in seconds. If you change from 30 to 60 fps while leaving the GOP count at 60, you have halved the interval in seconds. This is why a configuration copied from a different channel, encoder preset or tutorial can trigger a warning even when its author’s stream was working as intended.
Do not change frame rate solely to make a familiar GOP number fit. Choose the output frame rate for the content and delivery constraints, then set the interval from that rate. YouTube’s guidance supports up to 60 fps, but the stream’s actual encoding path and the rest of your setup determine what is appropriate. If you are sending a prerecorded loop, the guide to sending a video playlist to YouTube Live discusses the broader delivery path; it does not replace this frame-rate calculation.
Keep the GOP closed
YouTube says its live pipeline requires a closed GOP for optimal transcoding. In practical terms, a closed GOP avoids references crossing its boundary, so a following group can be treated as its own decoding unit. A suitable interval does not by itself establish that the GOP is closed; cadence and GOP structure are related but distinct properties.
FFmpeg documentation describes -cgop as the setting associated with closed GOP behaviour and explains that its negation disables closed GOP and enables open GOP. Do not use the disabling form for this YouTube use case. Exact controls and defaults depend on the encoder and version, so check the relevant encoder’s help and documentation rather than assuming that one option behaves identically everywhere.
For libx264, inspect its keyframe and GOP options, including the documented keyint and keyint_min controls, if a fixed maximum GOP setting does not produce the intended result. Avoid adding multiple keyframe controls pre-emptively. In particular, forcing keyframes is not the default response to this warning when a regular GOP setting addresses the diagnosis more directly. Make one change at a time and check the emitted stream.
If you are unsure whether a setting is applied by your chosen encoder, use a short test stream rather than learning during a long broadcast. A more general always-on checklist is available in how to stream a video file to YouTube Live without OBS, but for this specific warning the important checks remain encoder, output rate, GOP interval and closed-GOP behaviour.
Verify the output and recheck YouTube
A command line is an instruction, not evidence that the stream reached YouTube in the intended form. Check the encoder shown in the command, the output frame rate and the GOP option supported by that encoder. Where possible, inspect a short encoded output or test stream to confirm that keyframes appear at the expected cadence and that the encoder is not overriding the intended setting.
Then test through YouTube before the real broadcast. YouTube recommends testing the stream and monitoring stream health during the event. Start with the current official live encoder settings, then observe the exact message in YouTube’s live control room after the change. If the warning disappears, avoid changing bitrate or resolution without a separate reason.
If it persists, work through the possibilities systematically. Confirm that the output really is 30 or 60 fps as assumed; verify the selected encoder and its option syntax; look for other settings that may shorten or lengthen keyframe intervals; and check for a frame-rate conversion or ingestion issue. YouTube’s error guidance notes that ingestion errors can result in incorrect GOP sizes, so a correct encoder configuration is not conclusive proof that the received stream has the expected structure.
Record the command and the frame rate used for the test. For a channel that runs continuously, this avoids repeating the same diagnosis after a restart or a change of file. If the source changes its frame rate, repeat the calculation rather than carrying the prior GOP count forward. Keep separate notes for separate formats if the channel alternates between, for example, a 30 fps recorded programme and a 60 fps live source.
When the encoding is correct but keeping a machine running through overnight broadcasts is the separate problem, StreamNeo can remove the need to leave your own computer on to keep an uploaded video live. That solves a different operational burden; it does not alter the need to provide YouTube with a correctly encoded stream or resolve this warning by 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
Does -g 60 fix the warning for every FFmpeg stream?
No. It is an example for a two-second maximum GOP at 30 fps, shown with H.264/libx264. At 60 fps, a two-second interval is 120 frames, and another encoder may use different controls or behaviour. Confirm your output rate and selected encoder before choosing a value.
What should I use at 60 fps?
For a two-second target, calculate 60 frames per second × 2 seconds, which gives 120 frames. For an H.264/libx264 stream, -g 120 is a reasonable starting example, not a guarantee that YouTube will accept every stream. Test and check the current stream-health message.
Is the warning always caused by the FFmpeg -g value?
No. The warning can reflect a frame-rate change, encoder-specific behaviour or an ingestion issue as well as the configured GOP size. Check the exact diagnostic and the stream YouTube receives before changing unrelated encoding or network settings.
Do I need to force keyframes with -force_key_frames?
Not as the default fix. A regular GOP setting is the direct first control for this diagnosis, while forcing keyframes may be unnecessary and can complicate the output cadence. If a fixed GOP does not behave as expected, consult the documentation for the encoder and version you actually use.