Some delivery specs contain a line like “all-intra, no P-frames” or “every frame a key frame”. It reads like a formality next to codec and resolution, and it is the requirement most likely to be assumed rather than verified, because nothing on the surface of a file tells you whether it holds.
What a GOP is
Video compression saves space in two ways. Within a frame, by treating it like a still image. Between frames, by describing what changed since a previous one.
A codec that only does the first is intra-frame, or all-intra. Every frame is complete and independent. ProRes, DNxHR and Motion JPEG work this way.
A codec that does both is inter-frame, or long-GOP. H.264, HEVC and most delivery formats work this way. The frames come in groups — a Group of Pictures — and only the first frame of each group is complete:
- I-frame (intra) — a full picture, independent of everything else. Also called a key frame.
- P-frame (predicted) — describes changes from a previous frame.
- B-frame (bidirectional) — describes changes from frames both before and after it, which is why decode order and display order are not the same thing.
A typical broadcast H.264 stream might use a GOP length of 25 or 50: one complete frame, then a second or two of frames that only make sense in the context of their neighbours.
Why anyone asks for all-intra
The efficiency of long-GOP is real. So is the cost, and it shows up in specific places.
Editing. To display frame 37 of a long-GOP stream, the decoder has to find the last I-frame before it and decode forward. Scrubbing backwards is worse. On an all-intra file every frame is a seek target, which is why edit-friendly formats are all-intra even though they are five times the size.
Frame-accurate cuts. Cutting a long-GOP file at an arbitrary frame means re-encoding the group it lands in. Systems that splice content without a full re-encode need cuts on I-frame boundaries, and a spec that asks for all-intra is removing that constraint entirely.
Playback systems that decode in real time under load. LED processors, live playout servers and video walls often have a fixed per-frame decode budget. A long-GOP stream is cheap on average and expensive on I-frames, and a system sized for the average stutters on the peaks. All-intra is more data but flat, and flat is what a real-time system wants.
Repeated re-encoding. Every generation of inter-frame compression compounds errors along the prediction chain. Material that will be re-encoded several times degrades less if each generation starts from complete frames.
Why you cannot tell by looking
A long-GOP file and an all-intra file play identically. Nothing in the container header says “this is all-intra” — the closest thing is the codec name, and the codec name is not a guarantee. H.264 can be all-intra; there is an encoder setting for it, and specs that ask for “H.264 all-intra” are asking for exactly that. Conversely a file in an intra-only codec is all-intra by construction, so for ProRes the question does not arise.
The place the answer actually lives is the sample table: the index the container keeps of where every frame is and what kind it is. Frames that can be decoded independently are marked as sync samples. Counting them, and more importantly measuring the gaps between them, is the only way to answer the question.
The average is the wrong statistic
This is the part worth being careful about, because it is an easy mistake to make and it produces a confident wrong answer.
Suppose a tool walks the first 900 frames of a clip and finds 604 sync samples. The average distance between key frames is 900 ÷ 604, which is 1.49, and rounding that gives 1. One frame between key frames means every frame is a key frame, so the file is all-intra.
Except it is not. There are 296 frames in there that are not key frames. The average is dragged down by long runs of intra frames elsewhere in the file, and rounding finishes the job.
“Every frame a key frame” is a claim about every frame, so the statistic that tests it is the longest run between key frames, not the mean. If the maximum interval is 1, the file is all-intra. If it is 12, there is a group of twelve somewhere, whatever the average says.
A related caveat: any analysis that stops after a fixed number of frames is reporting on what it read. A clip that is all-intra for its first 900 frames and long-GOP afterwards will pass a bounded check. That is a defensible limit as long as it is stated, and it is worth knowing which you are getting.
Checking it in practice
Reading the sample table means opening the file properly and walking its index, which costs orders of magnitude more than reading a header. It is not something that can happen during an ordinary folder scan without making every scan slow.
So in FileLister it is an explicit step. Select the clips, run the key-frame analysis, and the interval appears as a column alongside codec and frame rate. The reported figure is the longest run rather than the mean, for the reason above, and an all-intra file reads as “every frame”.
Once the column is populated, a filter set can use it: a requirement that the key-frame interval equals 1 turns “all-intra” from an assumption into a pass or fail per file. Until the analysis has run, a file with such a requirement is reported as unjudged rather than failed — the honest answer, and the one that stops a folder of unanalysed clips from looking like a folder of rejects.
When it does not matter
Most deliveries do not need it. A file going to a streaming platform will be re-encoded to long-GOP anyway, and asking for all-intra on the master is only useful if the master is also being edited or replayed.
The requirement earns its place when the file is going into a system that seeks, splices or decodes it in real time. If the spec you were sent asks for it, that is usually why. If you are writing the spec and you are not sure whether you need it, you probably do not, and asking for it costs the supplier four or five times the file size.