GOP Structure Visualizer

Visualize and analyze Group of Pictures (GOP) patterns in video encoding. Adjust GOP size, B-frames, and frame rate to understand compression efficiency and seek latency tradeoffs.

Worked example — GOP Structure Visualizer

GOP size	12 frames

These are the values the calculator shows when the page opens. Change any input above to recompute them.

Loading interactive simulation...

A GOP length means nothing until you divide it by the frame rate 🖖

The seek readout is the number that matters, because it is how long a player waits before it can show anything after a jump or a channel change. streaming uses 24 frames at 30 fps, so 800 ms. bluray uses 48 at 24 fps — twice the frames, but 2000 ms, two and a half times the wait, because a slower frame rate stretches the same GOP further in time. allIntra sets the GOP to 1, making every frame a keyframe: seeking then costs a single frame, 33 ms, and you pay for it in bitrate on every frame you ever send.

Why scrubbing a video sometimes snaps 🖖

A video rarely stores every frame in full. Only I-frames (keyframes) hold a complete picture; P- and B-frames just describe what changed compared to nearby frames. A GOP is one run from one keyframe to the next. When you drag the scrubber, the player can only restart decoding at the previous keyframe and rebuild forward to your target — so a long GOP saves space but makes seeking slower and less precise.

Datamoshing: art from broken keyframes 🖖

Because P-frames carry only motion, not real content, video artists deliberately delete I-frames so the decoder keeps smearing old pixels along new motion vectors. The result is the melting, bleeding "datamosh" look seen in music videos like Kanye West's Welcome to Heartbreak (2009) and Chairlift's Evident Utensil. The very corruption that ruins a stream with a lost keyframe becomes a deliberate aesthetic.

ONE STAGE OF A CHAIN — WHAT ARRIVES, WHAT LEAVES, WHAT BREAKS DOWNSTREAM

Where This Sits In The Encoding Pipeline

A video encoder is not one algorithm but eight stages in a fixed order, and the order is not arbitrary: each stage exists because the one before it made its job possible. This tool models one of them. The chain below links to the other seven.

GOP Structure Visualizer — decides which frames are coded standalone and which are coded as differences

What arrives: A run of sampled frames, none of them coded yet.
What leaves: An assignment: I-frames coded alone, P and B frames coded against reference frames.
What the next stage assumes: Motion estimation runs only on P and B frames. An I-frame skips it completely.
What goes wrong here: This stage decides whether the next one runs at all for a given frame, so it gates stage 04 rather than merely preceding it. Long gaps between I-frames compress much better and make seeking worse, because a player has to decode forward from the last I-frame to reach any point you ask for.

Previous stage: Chroma subsampling Next stage: Motion estimation

Problem solved in full

Frame mix and average frame size for 48 frames at 24 fps 6 steps
A Blu-ray-style group of pictures: 48 frames, 3 consecutive B-frames between references, played at 24 fps. Take an I-frame to cost 100 relative units, a P-frame 12 and a B-frame 6. Find the frame mix and the average frame size, then work out how much compression a longer GOP could still buy.
1. One I-frame opens the group, which leaves 47 slots. Those slots repeat a 4-frame unit — 3 B-frames and the P-frame that anchors them — and 47 is not a multiple of 4. 47 = 11 × 4 + 3, so 11 complete units and a tail of 3 B-frames left hanging.
  
  $N_{GOP} - 1 = 47, 47 = 11 \times 4 + 3$
2. That gives 11 P-frames and 33 + 3 = 36 B-frames. Check it: 1 + 11 + 36 = 48.
  
  $N_{P} = 11, N_{B} = 11 \times 3 + 3 = 36, 1 + 11 + 36 = 48$
3. Weight each type by its cost. 100 + 132 + 216 = 448 units for the whole group, and 448 / 48 = 9.3 per frame. An all-intra stream pays 100 for every frame, so this structure is 10.7 times smaller for the same 48 pictures.
  
  $\overset{ˉ}{S} = \frac{1 \times 100 + 11 \times 12 + 36 \times 6}{48} = \frac{448}{48} = 9.3$
4. The bill for that arrives as latency. You cannot start decoding in the middle of a group — every P- and B-frame is defined relative to something else — so seeking lands you on the I-frame and you decode forward from there. The worst case is the full 48 frames, which at 24 fps is 2 s.
  
  $T_{seek} \leq \frac{N _{GOP}}{f} = \frac{48}{24} = 2 s = 2000 ms$
5. Now find the floor. Each repeating unit costs 3 × 6 + 12 = 30 units for 4 frames, or 7.5 per frame, and lengthening the GOP does nothing but add more of these units. Subtract that rate from the group and 448 - 7.5 × 48 = 88 units are left over.
  
  $\frac{3 \times 6 + 12}{4} = 7.5, 448 - 7.5 \times 48 = 88 = 100 - 12$
6. Those 88 are one number: 100 - 12, the I-frame's premium over the P-frame it stands in place of. The premium does not grow with the group, so it is 88 whatever the length is, and the average is S̄ = 7.5 + 88/N. Test it at double the length: N = 96 gives 7.5 + 88/96 = 8.4 units per frame.
  
  $\overset{ˉ}{S} = 7.5 + \frac{88}{N} ⟹ N = 96 : 7.5 + \frac{88}{96} = 8.4, T_{seek} = 4 s$
Answer

9.3 units per frame, against a floor of 7.5 that no GOP length can go below. The two halves of the trade scale in opposite directions and neither is linear in the way it looks: what you still have to gain falls as 88/N while the seek latency rises as N/24. At 48 frames you are 1.8 units above the floor. Doubling to 96 recovers 0.9 of that — under 10% of the frame size — and costs another 2 s of worst-case seek. Doubling again recovers 0.46 and costs 4 s more. So the GOP length worth choosing is fixed by the latency you are willing to accept, not by the compression you are still chasing: past a few dozen frames, one I-frame amortised a little further is all that is left on the table.

$\overset{ˉ}{S} - 7.5 = \frac{88}{N} \propto N^{- 1}, T_{seek} = \frac{N}{f} \propto N$

References (1)

Where I, P and B pictures and the GOP structure are specified: ITU-T Recommendation H.264, Advanced video coding for generic audiovisual services.

By the 42Math team · Updated 2026-05-24

Reviewed against published sources. Corrections welcome. Editorial policy · Corrections

All Computing lessons →

Example problems

Low latency (IP) - GOP=4, no B-frames: maximum seek speed, minimal compression — common in real-time streaming
Web streaming (IBBP) - GOP=24, 2 B-frames: ~800 ms seek latency, good compression — typical VOD streaming
Blu-ray (IBBBP) - GOP=48, 3 B-frames: ~2 s seek latency, best compression — standard Blu-ray
All-intra (I-only) - All-intra: every frame is an I-frame — highest quality, 5–10× larger than B-frame stream