If YouTube says the keyframe frequency is wrong, first compare the keyframe interval in the video actually being sent with YouTube’s live guidance. The usual target is one keyframe every two seconds, with no more than four seconds between keyframes.
With FFmpeg, that normally means setting the GOP size in frames rather than seconds, then checking the encoded output and Live Control Room. A missing interval control in your command does not, by itself, prove that YouTube will reject the stream.
What YouTube recommends for keyframes
YouTube’s live encoder guidance recommends a keyframe every two seconds and says not to exceed four seconds. You can read the current wording in YouTube’s live encoder settings.
A keyframe, also called an I-frame, is a complete picture from which later frames can be decoded. Between keyframes, video encoders generally send changes rather than complete pictures. This reduces the amount of data needed, but it also means that the decoder periodically needs a fresh reference point.
For a live platform, regular keyframes help the service begin processing a stream and create different playback versions. They can also help viewers recover more quickly after a connection interruption. The two-second recommendation is therefore about the behaviour of the encoded stream, not about whether a particular application happens to display a box labelled “keyframe interval”.
The interval must be translated using the output frame rate. YouTube’s live troubleshooting guidance gives the direct example: at 30 frames per second, a two-second interval is 60 frames. By the same calculation, a constant 60 fps output would use 120 frames for two seconds.
| Constant output frame rate | Two-second GOP target | Four-second upper interval expressed in frames |
|---|---|---|
| 24 fps | 48 frames | 96 frames |
| 25 fps | 50 frames | 100 frames |
| 30 fps | 60 frames | 120 frames |
| 50 fps | 100 frames | 200 frames |
| 60 fps | 120 frames | 240 frames |
These are frame-count conversions, not separate YouTube limits for each frame rate. They assume the output sent to YouTube is constant frame rate. If FFmpeg is sending 30 fps but you calculate the GOP from the source file’s nominal 25 fps, the resulting interval will not be what you intended.
Do not apply this live-stream guidance uncritically to an uploaded file. YouTube has separate recommended upload encoding settings, including advice about closed GOP and other file-encoding characteristics. An upload recommendation and a live-ingest warning belong to different workflows.
Does a missing control mean rejection?
No. A command that does not visibly contain a keyframe interval option is not enough evidence that the stream is invalid. The active encoder may have a default, may receive settings from another part of the command, or may produce an output that still has an acceptable keyframe pattern.
The reverse is also true. Seeing -g 60 in a command is not proof that the stream reaching YouTube contains a keyframe every two seconds. The selected encoder, output frame rate, rate-control behaviour, scene-change decisions, timestamp handling and other options can affect what is encoded.
FFmpeg’s generic -g option represents a GOP size in frames for encoders that support the generic codec option. It does not mean “two seconds” on its own. At 30 fps, -g 60 corresponds to two seconds; at 60 fps, the same value corresponds to one second.
You should also distinguish a recommendation from a mandatory visible control. YouTube may report an ingest problem when the actual stream has keyframes too often or not often enough, but that does not establish that every FFmpeg command needs a particular spelling or that every encoder exposes the same control. The useful question is what the output contains.
This is why changing one line and immediately restarting a long-running channel can be misleading. If the stream remains unstable, or the output frame rate is different from the one used in your calculation, the warning may remain for a reason unrelated to the presence of -g.
Check stream health in Live Control Room
Before changing FFmpeg, open the stream in YouTube Studio and look at the stream health information in Live Control Room. The health panel can show whether YouTube is currently receiving the stream and whether it has detected an encoder or ingest issue.
Start a short test broadcast rather than experimenting first on the channel’s overnight programme. Send the same resolution, frame rate, codec and transport settings that you intend to use for the real stream. Watch the health status while the encoder is running, and note the exact wording of any warning.
A keyframe warning is different from dropped frames, a disconnected input, insufficient bitrate, audio problems or a stream that has ended. If several warnings appear together, correct the transport or source problem first. A damaged or interrupted input can make the resulting output difficult to assess.
The YouTube live streaming error messages page is useful here because it describes the incorrect video keyframe frequency message and gives the 30 fps to 60-frame example. Use the current official page when the wording in Studio differs from an older screenshot or guide.
Keep a simple test record:
- the frame rate selected in the FFmpeg command
- the video encoder name
- the codec and pixel format
- the
-gvalue or timestamp-forcing option - when the stream started
- the exact health warning and when it appeared
This prevents you from changing several variables without knowing which change affected the result. It also makes it easier to compare a software encoder with a hardware encoder if your machine offers both.
For a 24/7 channel, health monitoring should be part of the operating routine rather than something you inspect only after viewers complain. The practical details of reading counters and separating connection problems from encoder problems are covered in this guide to dropped frames on a long stream.
Understand GOP length and open-GOP warnings
A GOP, or group of pictures, is the sequence beginning with one keyframe and continuing until the next keyframe. In simple terms, GOP length is the distance between those reference points. When you set -g 60 on a constant 30 fps output, you are asking for a maximum GOP distance of 60 frames, subject to the selected encoder’s behaviour.
“Maximum” matters. A GOP-size setting does not necessarily mean that every GOP will have exactly the same structure in every situation. Scene changes, forced keyframes, encoder rules and timestamps can cause keyframes to occur sooner. A setting that prevents the distance exceeding the target is usually more relevant than assuming every interval will be identical.
Closed GOP is a separate property. In a closed GOP, pictures in one GOP do not depend on pictures in another GOP. An open GOP may use references across the boundary. YouTube’s live troubleshooting information says its pipeline requires a closed GOP for optimal transcoding, so check whether your encoder exposes a closed-GOP or open-GOP control.
Do not confuse this with the upload page’s separate advice that describes a GOP of half the frame rate. That upload guidance should not be copied into a live command without considering the destination and workflow. For this article’s live-ingest case, begin with YouTube’s two-second recommendation and then verify the output.
B-frames add another possible source of confusion. They describe frame prediction and are not the same thing as the keyframe interval. A command can have a sensible GOP distance while still using codec features that need to be checked for compatibility with the live workflow.
If YouTube reports an open-GOP or keyframe-related issue, inspect the encoder-specific options rather than assuming that -g controls everything. Hardware encoders often use different option names from software encoders, and an option accepted by one build may not map identically to another.
Inspect the actual encoder output
The most useful troubleshooting step is to inspect what FFmpeg encoded, not only what you intended to encode. Confirm the video stream’s codec, frame rate, time base, frame count and keyframe positions. A command copied from a guide can be syntactically valid while producing a different stream because your installed build selected another encoder.
First identify the active video encoder. Look at the complete FFmpeg output when the stream starts, including the input and output mappings. If the command contains a codec alias or hardware acceleration option, confirm the encoder name that FFmpeg reports rather than inferring it from the filename or operating system.
Then ask that build what the encoder supports. A useful starting point is:
ffmpeg -h encoder=<encoder-name>
Replace <encoder-name> with the encoder shown in your output, such as the relevant software or hardware encoder. FFmpeg’s codec documentation explains the generic codec options and how encoder-specific options fit alongside them. The FFmpeg command-line documentation documents -force_key_frames and the other command-line mechanisms.
For a short test file, tools such as ffprobe can help you inspect frame types and timestamps. You are looking for I-frames at a regular interval and for an output frame rate that matches the calculation. The exact probing command depends on the FFmpeg version and the information you need, so do not treat a single compact command as a universal test.
If the output is 30 fps, a two-second target is 60 frames. If the output is 60 fps, it is 120 frames. Check the measured timestamps as well as the nominal frame rate because variable-frame-rate input, filters and timestamp transformations can change the relationship between frames and seconds.
-force_key_frames is another FFmpeg mechanism. It requests keyframes at particular timestamps, but the requested times are rounded to the encoder time base, and the encoder can still impose its own constraints. It can be useful when you need timestamp-based control, but it is not a replacement for understanding the selected codec, frame rate and GOP behaviour.
For a long-running channel, test a representative section that includes motion, still images, fades and any loop boundary. A devotional slideshow, a lofi animation and a local news loop may exercise the encoder differently. Do not assume that a test containing only a static image proves how the real programme behaves.
Choose a way to produce the recommended behaviour
There is no single FFmpeg line that fixes every keyframe warning. Choose the method according to the encoder you are actually using, then verify the result.
Software encoding with a constant frame rate
Suppose your output is constant 30 fps and your selected encoder supports the generic GOP option. A two-second target corresponds to 60 frames, so the relevant part of a command may look like this:
-g 60
At constant 60 fps, the equivalent value is:
-g 120
These fragments are examples of the calculation, not complete streaming commands. You still need to specify the input, output frame rate, codec, audio, bitrate, pixel format and destination correctly. If the output frame rate changes, recalculate the value.
You may also need to select a closed-GOP behaviour supported by the encoder. Check the encoder help before adding an option from a guide written for a different build. If an option is ignored, rejected or silently mapped differently, the final output is what matters.
Hardware encoding
Hardware encoders can be useful when a small computer must run a channel continuously, but they require closer attention to their own option names and defaults. A generic -g argument may be accepted, ignored or interpreted through the hardware encoder’s implementation. Read the startup log and the matching encoder help.
If the hardware encoder cannot provide the control or GOP behaviour you need, a software encoder may be the clearer diagnostic path for a short test. That does not mean software encoding is always better for production. It simply removes one layer of uncertainty while you establish what YouTube is receiving.
Timestamp forcing
Use -force_key_frames when timestamps are the control you need and your chosen encoder handles the request as expected. Remember that timestamp requests are interpreted through the encoder time base. Test the output rather than assuming that a list of requested times became an identical list of encoded keyframes.
For a channel that loops an MP4 continuously, you may find it simpler to make the source and output frame rates explicit and use a normal GOP-size calculation. This is also why checking the best video format for 24/7 live streaming can be useful before changing an FFmpeg command: source-file properties can complicate an otherwise straightforward live output.
When the computer is the problem
If the encoder cannot keep up, changing the keyframe setting will not solve every symptom. Check CPU or GPU load, thermal throttling, disk reads, network stability and the dropped-frame counters. A continuous podcast or music stream may be easier to run than a high-motion 60 fps channel, but the test must still use the settings you plan to send.
If maintaining FFmpeg overnight involves repeated reconnects, shell scripts and manual checks, an uploaded file can instead be sent through a managed workflow. StreamNeo removes the specific burden of keeping your own computer running and restarting the broadcast when it drops; you still need to prepare the source, use the YouTube stream key and check the channel’s live settings.
If the warning persists after changing FFmpeg
Work through the problem in this order.
First, confirm the destination. Make sure you are troubleshooting a live ingest warning, not an upload or export message. Use the live encoder guidance for the live broadcast and the upload guidance for a file upload.
Second, confirm the frame rate actually sent. Look at FFmpeg’s output mapping and the encoded stream, not only the input file’s properties. Calculate the two-second frame count from that output rate.
Third, confirm the active encoder. Check the startup log and run ffmpeg -h encoder=<encoder-name>. If you changed from software encoding to hardware encoding, treat the new encoder as a separate configuration and inspect its supported controls.
Fourth, check the GOP structure. Look for an excessive interval, unexpectedly frequent keyframes, open-GOP behaviour and timestamp irregularities. YouTube’s troubleshooting guidance also notes that ingestion errors can cause incorrect GOP sizes, so a network or transport problem may be part of the picture.
Fifth, run a controlled test. Keep the source, resolution, frame rate and bitrate fixed while changing one encoder setting. Let the test run long enough for Live Control Room to report a stable state, but do not take a short successful display as proof that every overnight condition is solved.
Finally, compare the warning with the observed output. If the measured stream matches the intended interval but YouTube continues to report a problem, check the current official guidance and the other health warnings rather than repeatedly increasing or decreasing -g. The evidence may point to a timestamp, closed-GOP, ingest or encoder-specific issue.
For people operating several channels, document each channel’s tested frame rate and encoder separately. A devotional stream at 25 fps and a 60 fps ambience channel should not share an unexplained -g value. A small settings note can prevent a repair on one channel from creating a new warning on another. You can also use this checklist for running two or three 24/7 channels to keep the tests and health checks separated.
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
What should -g be at 30 fps for YouTube Live?
For a two-second target at constant 30 fps, the frame-count calculation is 30 × 2, so the example value is -g 60. Confirm that the output really is 30 fps and that the selected encoder honours the generic option before relying on it.
Is YouTube rejecting my stream because FFmpeg has no keyframe interval box?
Not necessarily. The important evidence is the encoded stream and the health information in Live Control Room, not the appearance of a particular control in your command. A missing option alone does not prove rejection, while an apparently correct option does not prove that the output has the intended GOP.
What is the difference between GOP length and keyframe frequency?
GOP length is usually expressed as a number of frames between reference points, while keyframe frequency is often described as a time interval. You convert between them using the output frame rate, so -g 60 means two seconds at 30 fps but one second at 60 fps.
Should I use the upload GOP recommendation for a live stream?
No. YouTube provides separate guidance for live ingestion and uploaded files. For a live stream, start with the recommended two-second keyframe interval, do not exceed four seconds, and verify the actual output and Live Control Room health.