# FFmpeg keyframe interval compared

Canonical: https://rendobar.com/blog/ffmpeg-keyframe-interval-cost/
Author: Abdelrahman Essawy
Published: 2026-08-20
Updated: 2026-08-20

---

## Key takeaways

- All-keyframes produced 2,661 KB against the default's 433 KB. That is 6.1x the bytes for the same visual quality setting.
- The 1-second GOP most HLS guides recommend cost 35% more bytes than x264's default 250-frame interval.
- Encode time barely moved across the range, 836 to 960 ms, so this is a size decision with almost no compute side.
- All-keyframes was the FASTEST encode at 446 ms, because there is no motion estimation left to do.
- Keyframe interval is the second-largest size lever measured on this site, after codec choice. Most streaming setups pick it once and never price it.

Every HLS tutorial tells you to use a 1 or 2 second keyframe interval so that
segments align. Almost none of them mention what that costs.

Short version. It costs **35% of your bytes** against x264's default, and it
costs essentially nothing in encode time. That makes it a pure bandwidth
decision, and one most people make once and never revisit.

## The size curve is steep

| Interval | Size | vs default |
|---|---:|---:|
| every frame (`-g 1`) | 2,661 KB | **+515%** |
| 0.4s (`-g 12`) | 779 KB | +80% |
| 1s (`-g 30`) | 585 KB | +35% |
| 2s (`-g 60`) | 505 KB | +17% |
| default (`-g 250`) | 433 KB | — |

A keyframe is a complete picture. Every other frame only stores what changed. So
the interval is really a question of how often you throw away all your
compression and start again, and the answer visibly compounds.

All-keyframes at **2,661 KB** is 6.1x the default. That is what an intra-only
encode costs, and it is why editing codecs like ProRes are enormous.

## Encode time barely moved

**836 ms** to **960 ms** across the whole practical range. That is a 15% spread
against a 6x spread in output size.

And the outlier is instructive: all-keyframes was the **fastest** encode in the
sweep at **446 ms**, roughly half the default's 945 ms. With no inter-frame
prediction there is no motion estimation to do, so the encoder does far less
work and produces far more bytes.

So the tradeoff is not compute against size. It is **size against seek
granularity**, and compute is not really in the conversation.

## What the shorter interval buys

Three things, and they are real:

**Segment alignment.** HLS and DASH segments must start on a keyframe. If your
GOP is 250 frames and your target segment is 2 seconds, the packager cannot cut
where you asked.

**Seek accuracy.** A player can only jump to a keyframe. A 250-frame GOP at 30fps
means seeks land up to 8 seconds from where the user clicked, which feels broken.

**Error recovery.** A corrupted keyframe damages everything until the next one.

For streaming, a 2-second GOP at **+17%** is usually the right trade. For a
download, or a file behind a player that decodes locally, the default is fine and
the 35% is free money.

## The number worth carrying

`-g 60` at +17% against `-g 30` at +35% is the same decision most people make
without seeing the price. Halving the interval roughly doubles the penalty each
time, and at 30fps the difference between a 1-second and a 2-second GOP is
**18% of your entire bandwidth bill** for a seek granularity difference almost
nobody notices.

## Where this stops

One 5-second 1280x720 clip, libx264 at CRF 23 preset medium, audio stripped. A
short clip exaggerates the keyframe penalty slightly, because the first keyframe
is a larger share of a small file. On longer content the percentages shrink but
the ordering and the rough shape hold.

Content matters more than length here. High-motion footage has less inter-frame
redundancy to lose, so shortening the GOP costs proportionally less. A static
screencast is the worst case and will punish a short interval hardest.

Keyframe interval is one of seven settings measured on this same source. The rest are in [FFmpeg encoding settings compared](/blog/ffmpeg-encoding-settings/).