Why architecture matters here
Architecture matters because GOP structure is the hinge between two systems that rarely talk to each other: the codec and the delivery layer. An encoder team optimizing purely for bitrate will use long GOPs and heavy B-frame usage and produce beautifully small files that are useless for adaptive streaming — the player cannot switch quality except at rare I-frames, seeking jumps in coarse chunks, and channel changes are slow. A streaming team that demands two-second segments with an I-frame at every boundary forces short GOPs that inflate bitrate by 20–40%. Neither team is wrong; the GOP structure is where their requirements are reconciled, and getting it wrong shows up as either bloated bandwidth bills or a janky, slow-to-seek player.
It also matters for error resilience. Because P- and B-frames depend on their references, a corrupted or lost frame poisons everything that references it until the next I-frame resets the chain. A stream with a two-second GOP recovers from a glitch in at most two seconds; a stream with a ten-second GOP can smear a single lost packet into ten seconds of blocky garbage. The GOP length is therefore also a reliability knob, directly setting the worst-case duration of visible corruption after packet loss — which is why broadcast and low-latency live streams keep GOPs short even at a bitrate cost.
Finally, latency. B-frames require the decoder to receive future frames before it can display the current one, so any B-frame usage adds structural latency equal to the reorder depth. Real-time applications (video calls, cloud gaming) forbid B-frames entirely and often use very short GOPs or even I-frame-light 'infinite GOP' with periodic refresh. Understanding the architecture is what lets you place each stream correctly on the compression-vs-latency-vs-seekability triangle instead of copying a default that was tuned for a different use case.
The architecture: every piece explained
An I-frame (intra-coded) is compressed using only information within itself — like a JPEG — so it can be decoded with no other frame. The special IDR (Instantaneous Decoder Refresh) I-frame additionally guarantees that no later frame will reference anything before it, making it a clean cut point. A P-frame (predicted) stores motion vectors and residuals relative to one or more earlier reference frames: 'this block moved here, with these small differences.' A B-frame (bi-directional) may reference both earlier and later frames, letting it interpolate and achieve the highest compression of the three — at the cost of requiring future frames to be decoded first.
The GOP length N is the spacing between I-frames (the keyframe interval), often expressed in frames or seconds. A typical pattern might be IBBPBBPBBP… repeating. A closed GOP is self-contained: no frame in it references any frame outside it, so a decoder can start cleanly at its I-frame — essential for seeking and ABR switching. An open GOP allows B-frames near the boundary to reference the previous GOP, squeezing out slightly better compression but breaking clean entry, so it is unsuitable for switch points. Because B-frames reference the future, the decode order (the order frames are stored and decoded) differs from the display order (the order they are shown): a B-frame is decoded after the future frame it depends on but displayed before it, so the decoder maintains a reorder buffer and the container carries separate decode and presentation timestamps (DTS/PTS).
Two more pieces complete the architecture. Rate control spends a bit budget across the GOP — an I-frame is large, P-frames medium, B-frames small — so the encoder allocates bits per frame type to hit a target average bitrate while keeping quality even. And scene-cut detection inserts an extra I-frame at hard cuts, because predicting across a cut is futile (nothing carries over), so a fresh intra frame is both smaller and cleaner than a P-frame trying to reference an unrelated image. In adaptive streaming, keyframe alignment ties it together: every bitrate ladder rung must place IDR frames at identical timestamps so segments are interchangeable and the player can switch at any segment boundary.
The reference relationships also explain the size hierarchy that rate control must budget around. An I-frame, coding a full image with no prediction, is by far the largest — often five to ten times a P-frame; a P-frame, storing only motion vectors and residuals from a past reference, is medium; a B-frame, interpolating from both directions, is the smallest because bidirectional prediction leaves the least residual. A GOP's total size is therefore dominated by its single I-frame plus the count and complexity of its P-frames, which is why lengthening the GOP (fewer I-frames per second) so effectively lowers bitrate, and why a scene with lots of motion — where P- and B-frame prediction works poorly and residuals balloon — costs far more bits than a static shot even at the same GOP length.
End-to-end flow
Trace an encode with GOP length 48 (about two seconds at 24fps), closed, with two B-frames between anchors. The encoder starts each GOP with an IDR I-frame — a full intra-coded picture, the largest frame in the group. It then predicts a P-frame from that I-frame, and inserts two B-frames between them that reference both the I-frame behind and the P-frame ahead. Because those B-frames need the future P-frame, the encoder emits them in decode order (I, P, B, B) while tagging each with a presentation timestamp so the player shows them as I, B, B, P. This continues — P anchors every third position, B-frames filling the gaps — until 48 frames have passed, when a new IDR resets the group.
On the delivery side, the packager cuts the stream into segments aligned to GOP boundaries, each starting with an IDR frame. Because the GOP is closed and every bitrate variant used the same 48-frame interval with keyframes at the same timestamps, segment 3 of the 1080p rendition and segment 3 of the 480p rendition cover the identical time span and both begin at a clean IDR. The player can therefore download 1080p segments while the network is good and, the instant it degrades, request the next 480p segment and splice it in seamlessly — the switch lands on an I-frame, so the decoder needs no earlier context.
On playback, the decoder fills a reorder buffer: it decodes I, then P (buffering it), then the two B-frames that needed P, then displays them in presentation order I, B, B, P. When the user seeks, the player jumps to the nearest IDR — never into the middle of a GOP, because a P- or B-frame there would reference frames the decoder never decoded — then decodes forward to the exact target. If a packet is lost mid-GOP, corruption propagates through the dependent P/B frames until the next IDR, at most two seconds away, at which point the picture snaps clean. Every one of these behaviors — clean switching, seek granularity, bounded corruption — is a direct consequence of the GOP structure chosen at encode time.
To see why seeking must land on an IDR, imagine the player tried to start decoding at a B-frame in the middle of the GOP. That B-frame's data is meaningless on its own — it says 'interpolate between the frame before and the frame after,' neither of which the decoder has decoded. Even a P-frame there references an earlier frame the decoder skipped. Only the IDR is self-contained, so the player always snaps a seek to the nearest preceding IDR and then decodes forward, discarding frames until it reaches the requested timestamp. This is why GOP length directly sets seek granularity: with a two-second GOP the worst-case decode-forward distance is two seconds, usually imperceptible, but with a ten-second GOP a seek can require decoding up to ten seconds of frames before the target appears — a visibly sluggish scrub.