What is a keyframe (I-frame) in video? GOP and seeking explained

A keyframe, known formally in digital video compression as an intra-coded frame or I-frame, is a complete, self-contained picture stored inside a video stream. Unlike the vast majority of frames in a compressed movie, which store only the pixels that changed from one moment to the next, a keyframe requires no other video frames to decode and display.

Whenever you scrub through a video timeline, skip forward ten seconds, or wait for an online stream to start playing, keyframes govern that experience. Understanding how keyframes interact with predictive frames and Group of Pictures (GOP) structures explains why video seeking behaves the way it does, why lossless trimming has rigid boundaries, and how modern players maintain playback responsiveness.

What is an I-frame, and how does it differ from P-frames and B-frames?

If a digital video camera recorded 24 or 60 complete, uncompressed pictures every second, a single two-hour movie would require multiple terabytes of storage. Modern video codecs—such as H.264, HEVC (H.265), VP9, and AV1—achieve manageable file sizes by exploiting the fact that consecutive video frames are almost identical.

To eliminate redundant visual information across time (temporal redundancy), video encoders divide frames into three distinct types: I-frames, P-frames, and B-frames.

Animation

A keyframe, then only what changed

1. I-Frames (Intra-Coded Keyframes)

An I-frame is a standalone reference image. The encoder applies spatial compression (similar to JPEG photograph compression) to the pixels of that single frame without referencing any past or future video data. Because an I-frame contains all of the image information, it has the lowest compression ratio and consumes the largest amount of data per frame, but it serves as an indispensable anchor for everything that follows.

2. P-Frames (Predicted Frames)

A P-frame encodes only the differences between the current picture and previously decoded frames. Instead of storing the entire background again, the encoder calculates motion vectors that describe where blocks of pixels moved, alongside residual error values for pixels that changed color. According to the ITU-T H.265 specification, P-frames achieve substantial compression gains by relying on forward temporal prediction from an earlier I-frame or P-frame.

3. B-Frames (Bi-Directional Predicted Frames)

A B-frame achieves the highest compression efficiency of all. It calculates motion vectors by evaluating reference frames from both the past and the future. By interpolating motion bi-directionally, B-frames require only a small fraction of bits to maintain perceptual clarity. However, because a B-frame depends on a future reference picture, the decoder must receive and decode that future frame out of chronological order before rendering the B-frame on your screen.

In summary, the compression hierarchy works as follows:

• I-frame (keyframe): Complete standalone picture, largest data size, zero dependencies.
• P-frame (predicted): Stores forward motion vectors and pixel changes, moderate data size, depends on past frames.
• B-frame (bi-directional): Interpolates motion from past and future references, smallest data size, depends on both directions.

What is a Group of Pictures (GOP) and keyframe interval?

A video file is structured as a continuous sequence of repeating cycles called a Group of Pictures (GOP). A GOP begins with an I-frame keyframe and includes all the intermediate P-frames and B-frames up until the next keyframe appears.

The distance between two consecutive keyframes is known as the keyframe interval or GOP length. Encoders define this interval either in frame counts (such as a GOP of 60 frames) or in elapsed time (such as a keyframe every 2.0 seconds). For example, in an 8-frame GOP structure, an opening I-frame is followed by alternating B-frames and P-frames before the cycle concludes at the next keyframe.

Choosing a keyframe interval involves a fundamental engineering trade-off between compression efficiency and playback flexibility:

Long GOP (5 to 10 seconds)

Long GOP encoding inserts keyframes infrequently—often once every 120 to 240 frames. Because I-frames consume significant bandwidth, reducing the number of I-frames frees up bits for higher overall visual quality at a lower average bitrate. Long GOP encoding is standard for commercial movie distribution, 4K Ultra HD Blu-ray discs, and local video archiving. However, long intervals make random timeline seeking computationally heavier.

Short GOP (1 to 2 seconds)

Short GOP encoding forces the encoder to insert an I-frame every 24 to 60 frames. This increases the overall file size or reduces visual efficiency, but it provides frequent entry points for decoders. Short GOP intervals are common for live television broadcasting, web video conferencing, and low-latency sports streaming.

Why does seeking or scrubbing jump to keyframes?

When you drag the playback slider across a movie timeline in a media player, you might notice that the playhead does not glide smoothly across every millisecond. Instead, it snaps to discrete intervals along the timeline.

This behavior occurs because media players choose between two distinct seeking modes:

Keyframe Seeking (Fast / Snapping)

In keyframe seeking mode, the player instructs the demuxer to jump directly to the nearest I-frame packet. Because an I-frame requires zero reference data, the decoder reconstructs the image in less than a millisecond, providing fast visual feedback as you scrub. The trade-off is precision: if keyframes are spaced four seconds apart, the playhead jumps in four-second increments.

Frame-Accurate Seeking (Exact / Slow)

In frame-accurate seeking mode, you request a specific timestamp—for example, hour 1, minute 12, second 43.15. If that exact frame happens to be a B-frame located 80 frames after the nearest keyframe, the player cannot simply decode that single frame. It must:

1. Seek backward along the file to the preceding I-frame at second 40.00.
2. Decode the I-frame into memory.
3. Rapidly decode all 79 intermediate P-frames and B-frames in sequential order without displaying them.
4. Render frame 80 on screen.

On high-bitrate 4K or 8K video files, decoding dozens of high-resolution reference frames in a fraction of a second places heavy demand on the processor. If the hardware decoder cannot keep up, the user experiences timeline lag and dropped frames.

Why can lossless video trimming only cut on keyframes?

A common frustration for video editors and archivists is attempting to trim a video clip without re-encoding using tools like FFmpeg or MKVToolNix, only to discover that the output file starts a few seconds earlier or later than the chosen timestamp.

When you cut a video using stream copying (such as ffmpeg -i input.mp4 -c copy output.mp4), you copy compressed packets directly from the source container to the destination container without decompressing a single pixel. This operation finishes in seconds and causes zero loss in image quality.

However, as outlined in the official FFmpeg Seeking documentation, lossless stream copying can only begin on a keyframe:

• If you cut cleanly on an I-frame, the video decoder receives a complete, independent picture on frame one and continues playing smoothly.
• If you attempt to force a stream copy starting on a P-frame or B-frame, the decoder receives instructions like “move pixel block 14 four pixels to the right,” but the baseline picture containing pixel block 14 was discarded.

When a cut starts on a non-keyframe without re-encoding, the resulting video typically freezes, displays severe gray macroblocking artifacts, or plays audio over a black screen until the next keyframe arrives. If you require frame-accurate cutting down to the individual 24th of a second, you must re-encode the footage at the cut point using a smart-render pipeline or accept a full transcode.

How do streaming platforms use keyframes for instant playback?

Whenever you click play on a streaming platform like YouTube, Netflix, or Apple TV+, or when you switch channels during a live broadcast, your playback buffer must synchronize quickly.

Modern web streaming relies on HTTP Live Streaming (HLS) or MPEG-DASH. In these architectures, a video is broken into short discrete chunks (segments), typically lasting between 2.0 and 6.0 seconds. According to the Apple HLS Authoring Specification, every individual HLS video segment must begin strictly with an independent I-frame keyframe (#EXT-X-TARGETDURATION).

This rule enables three essential streaming capabilities:

1. Fast Start: When your player requests a stream, it downloads the current segment and starts decoding immediately from the opening I-frame, avoiding any delay waiting for reference data.
2. Adaptive Bitrate Switching: When your Wi-Fi signal weakens, the streaming player drops from 4K down to 1080p or 720p. The player waits for the current segment boundary to finish and switches to the lower-bitrate stream at the next keyframe, ensuring the transition happens without a visible screen glitch.
3. Bandwidth Scrubbing: Video scrubber thumbnails displayed on streaming progress bars are generated by extracting and caching the small I-frames embedded at the start of each segment.

How does MacLC handle seeking and HDR format switching?

Seeking in any player follows the same rule: the decoder jumps to the keyframe before the point you chose and decodes forward from there. Files with long groups of pictures take a moment longer to land exactly where you clicked.

For fine timing, MacLC’s Track Synchronization window (in the Window menu) and the keys F and G (audio delay) and H and J (subtitle delay) adjust offsets while the film plays.

To learn more about how video codecs compress image streams and manage pixel data, explore our companion guides on what a codec is and what CRF rate control does. If you frequently work with command-line video tools, consult our FFmpeg commands cheat sheet.

If you want a media player that scrubs through large 4K movies with fast response and smooth playback on Apple Silicon, download MacLC from the download page. It decodes in hardware through VideoToolbox and is free.