For YouTube Live, aim to send a keyframe every two seconds. YouTube Help says not to exceed four seconds, but the FFmpeg command alone does not prove that the outgoing stream is actually meeting either interval.
Convert two seconds into frames using the stream's real output frame rate: 60 frames at 30 fps, or 120 frames at 60 fps. In FFmpeg, -g sets the maximum distance between keyframes, so it is a useful starting point, followed by a check of the encoded output and stream health.
YouTube's two-second live target
A keyframe, also called an intra frame or I-frame, contains a complete image rather than relying on earlier frames. The frames between keyframes usually describe changes from an earlier reference. This saves bitrate, but it also means that a receiver may need to wait for the next keyframe before it can begin decoding cleanly or recover after a disruption.
For live streaming, YouTube's encoder guidance recommends a keyframe frequency of two seconds and says not to exceed four seconds. You can read the current wording in YouTube's live encoder settings, which lists the keyframe recommendation alongside other live-ingest settings.
That is an interval in time, not a universal frame count. A stream at 30 frames per second needs a different GOP size from a stream at 60 frames per second if both are to place keyframes about two seconds apart. This distinction matters when you copy an FFmpeg command from another channel or change frame rate later.
The two-second value is live-ingestion guidance. It should not be confused with YouTube's separate upload recommendations, where GOP guidance is expressed differently. A file prepared for upload and a continuous live stream have different delivery problems, so do not copy the upload setting into a live command without checking its context. YouTube's upload encoding recommendations are the relevant separate reference.
YouTube's four-second figure is a ceiling, not the target to aim for. Waiting four seconds between keyframes may still create an ingest warning or make recovery less responsive if the encoder does not behave consistently. For a dependable overnight stream, two seconds gives you a clear operating target and leaves less room for timing drift.
Turn two seconds into frames
The basic calculation is:
GOP size = frame rate × desired interval in seconds
For a two-second target, the common starting points are:
| Output frame rate | Two-second calculation | Starting -g value |
|---|---|---|
| 24 fps | 24 × 2 | 48 |
| 25 fps | 25 × 2 | 50 |
| 30 fps | 30 × 2 | 60 |
| 50 fps | 50 × 2 | 100 |
| 60 fps | 60 × 2 | 120 |
The 30 fps example is also given in YouTube's live troubleshooting guidance: two seconds is 60 frames. At 60 fps, the same arithmetic produces 120 frames. The other rows apply the same calculation to the stated output rate; they are not a claim that every YouTube stream uses all of these frame rates.
Use the encoded output frame rate, not the frame rate you intended when creating the source file. If a 60 fps video is being converted to 30 fps before it reaches the encoder, the relevant calculation is 30 × 2, which is 60 frames. If a filter, capture device, or encoder changes the rate, recalculate the GOP size for the new output.
Variable frame rate needs more care. A value such as 60 fps may describe a nominal or maximum rate rather than a steady sequence of 60 frames every second. In that situation, a frame count does not translate neatly into a fixed time interval. Prefer a known, stable output frame rate for a live channel, then inspect the actual encoded stream rather than assuming the source's label tells you what YouTube receives.
This is why the same -g 60 command can be appropriate for one stream and wrong for another. It is close to two seconds at 30 fps, but it is only one second at 60 fps and two and a half seconds at 24 fps. The number has no useful meaning without the frame rate beside it.
For a channel using a pre-rendered devotional video, a lofi loop, or a local news graphic, check whether the playback and encoding stages preserve the intended rate. A quiet picture does not remove the need for regular keyframes. The decoder still receives a timed sequence, and the ingest service still evaluates the encoded stream.
Set the maximum GOP with -g
In FFmpeg, -g sets the GOP size. FFmpeg describes this as the maximum distance between keyframes. For a fixed 30 fps output targeting two seconds, a starting command might include:
-g 60
At 60 fps, the corresponding starting value is:
-g 120
These are starting points, not certificates of compliance. The option tells FFmpeg or the selected encoder what maximum interval to use, but the resulting stream can also be affected by the encoder, rate-control settings, scene changes, timestamps, filters, and the input's frame-rate behaviour. A command line that contains -g 60 is evidence of intent, not evidence of what was emitted.
The selected video encoder matters. FFmpeg's official documentation documents GOP-related options, including encoder-specific keyframe controls. Read the section for the encoder in your actual FFmpeg build rather than assuming that an option accepted by one encoder has identical behaviour in another.
For example, a command using libx264 may include a two-second GOP calculation such as -g 60 at 30 fps. That does not mean every encoder option around it should be copied unchanged. Codec choice, rate control, bitrate, pixel format, and output frame rate all need to match the live service's current guidance and the capacity of your upload connection.
If you change from 30 fps to 60 fps without changing -g, you have changed the interval. If you add a filter that alters the frame rate without changing -g, you may also have changed the interval. Treat the pair as one setting: first establish the actual frame rate, then calculate the GOP size.
Do not use a small -g value simply because smaller sounds safer. More frequent keyframes can make recovery quicker, but they also use more bits for complete frames and can alter the distribution of bitrate through the stream. The useful setting is the one that meets the live requirement while leaving the encoder enough room to maintain the chosen picture quality and bitrate.
For a wider view of bitrate alongside resolution and frame rate, use a YouTube Live bitrate calculator by resolution and frame rate before changing several encoder settings at once. It is easier to diagnose a stream when you know which variable you changed.
Prefer a closed GOP when the encoder supports it
A closed GOP does not depend on frames from the preceding GOP for decoding. The next GOP can begin at a self-contained keyframe, which makes the boundaries clearer for a live pipeline that may need to join, recover, segment, or transcode the stream.
YouTube's live troubleshooting guidance says its pipeline requires a closed GOP for optimal transcoding. Use a closed GOP setting when the encoder selected in your FFmpeg build supports it, and confirm the encoder's documentation for the exact option and behaviour.
Do not assume that adding a generic phrase such as “closed GOP” to a command has done anything. Some options are encoder-specific, some may be ignored or rejected, and some may influence reference-frame behaviour without giving you the exact cadence you expected. The setting should be followed by inspection of the output.
A practical comparison looks like this:
| Item to compare | What you are checking | Why it matters |
|---|---|---|
| Time interval | About two seconds between keyframes | This is YouTube's recommended live target |
| GOP size | Frame count calculated from actual fps | The same number means different times at different rates |
| GOP type | Closed rather than open, where supported | YouTube identifies closed GOP as required for optimal transcoding |
| Emitted stream | Keyframes actually appear on schedule | The command expresses intent but does not prove output behaviour |
If your encoder cannot provide the closed-GOP behaviour you need, do not hide that limitation behind a different -g value. Choose an encoder and workflow you can inspect, or test the stream thoroughly before using it for a channel that needs to run unattended.
Check the real frame rate and encoder behaviour
Start by inspecting the source, but do not stop there. A media probe can tell you what the input claims to contain. The important question is what FFmpeg produces after decoding, filtering, frame-rate conversion, and encoding.
Check these items:
- The actual output frame rate, including whether it is constant or variable.
- The encoder selected by the command.
- The codec and pixel format sent to the output.
- The keyframe or I-frame positions in the encoded file or transport stream.
- Whether the GOP is closed when the encoder supports that distinction.
- Whether timestamps remain continuous during long playback.
For a file-based test, write a short representative sample using the same filters, frame rate, encoder, GOP settings, and bitrate as the live command. Include movement, fades, scrolling text, and scene changes if those occur in the real channel. A static test image may hide timing or bitrate behaviour that appears during a busy news loop or a devotional video with animated backgrounds.
Then inspect the encoded sample with a media-analysis tool and look at the frame types and timestamps. You are looking for keyframes at roughly the intended two-second cadence, not merely for the presence of a -g option in a script. The exact display of frame types varies by tool, so interpret the result using the tool's documentation and the encoder's documentation.
A scene change may cause an earlier keyframe. That does not automatically mean the stream is wrong. The important question is whether the maximum distance remains within the required interval and whether the encoder's behaviour is stable. If keyframes appear at irregular or unexpectedly long gaps, investigate before sending the stream overnight.
You should also test the real live path. A local file can behave correctly while the live output has timestamp, muxing, network, or reconnect problems. Send a private or otherwise controlled test broadcast, watch the status indicators, and review the ingest warnings. YouTube's live streaming troubleshooting guidance specifically addresses keyframe warnings and asks for keyframes every two seconds, with four seconds or less as the stated maximum.
If you run FFmpeg on a home computer, remember that the encoder can behave differently under sustained load than it does during a short command test. A machine that handles a five-minute sample may still drop frames, alter timing, or fail after several hours. This is one reason a long test is more useful than a screenshot of the command.
For a 24/7 channel, the operating environment is part of the test. A spare PC versus a VPS for an always-on YouTube stream involves different failure points, but neither choice removes the need to verify the encoded stream. If you are trying to keep a channel running without leaving a computer on, StreamNeo removes the local FFmpeg process from this particular workflow: you upload the video, provide the YouTube stream key, and the channel can continue from the cloud while your computer is off, with automatic monitoring and restart if the broadcast drops.
Validate the outgoing stream before going live
Validation should happen at three levels: the command, the encoded output, and YouTube's ingest view.
First, check the command against the actual frame rate. Write down the intended output rate and the multiplication used to choose -g. This simple note prevents a common error when a 30 fps command is later reused for 60 fps footage.
Second, inspect a representative encoded sample. Confirm that keyframes are present at the expected cadence, that the frame rate is what you intended, and that the selected encoder has applied the closed-GOP behaviour where supported. If the output is variable frame rate when you expected a steady rate, stop and resolve that before relying on a frame-count calculation.
Third, test the outgoing live stream in YouTube Studio. Look for ingest warnings, dropped frames, unstable bitrate, or other status messages while the test is running. YouTube also recommends constant bitrate for live encoders, and its current encoder guidance should be checked again when you change resolution, frame rate, codec, or delivery method.
Do not use the absence of an immediate warning as proof that every future broadcast will behave identically. A stream may pass a short test and fail when a different source file introduces unusual timestamps or when the encoder is under sustained load. Keep the test media representative of the material you intend to broadcast.
A useful troubleshooting order is:
- Confirm the output frame rate.
- Recalculate the two-second GOP size.
- Confirm the encoder-specific keyframe and closed-GOP settings.
- Inspect the emitted frames and timestamps.
- Test the real outgoing stream in YouTube Studio.
- Only then leave the channel running unattended.
If YouTube reports that keyframes are too far apart, do not immediately reduce -g at random. First establish whether the output is actually 30, 60, or another frame rate, and whether the encoder is honouring the requested setting. If the warning persists, compare the emitted stream with the command and inspect the encoder logs.
A keyframe problem can appear alongside other problems, but changing everything at once makes the cause harder to find. Keep the resolution, bitrate, frame rate, codec, and GOP settings stable while testing one change. For a black picture or missing video, use a separate diagnostic path such as this guide to fix a black screen on a YouTube stream running from a VPS, rather than treating every visible fault as a keyframe issue.
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
Is -g 60 always correct for YouTube Live?
No. It is a two-second starting point at 30 fps. At 60 fps, two seconds is 120 frames, and a different output rate requires a different calculation.
Does -g guarantee keyframes every two seconds?
No. FFmpeg describes GOP size as the maximum distance between keyframes, while the selected encoder and other output settings affect actual behaviour. Inspect the encoded frames and timestamps, then test the outgoing stream.
Should the GOP be open or closed?
Use a closed GOP when the selected encoder supports it. YouTube's live troubleshooting guidance says its pipeline requires a closed GOP for optimal transcoding, but you should confirm that the encoder-specific setting has taken effect.
What should I do if YouTube reports a keyframe warning?
Check the real output frame rate first, recalculate the two-second frame count, and inspect the emitted stream. Then review the encoder-specific settings and test the complete live path again rather than changing only the command's -g value.