What is a keyframe?
A keyframe — an I-frame — is a video frame stored as a complete picture, with no reference to any other frame. Everything between keyframes is interframe compression: frames that record only what changed. One keyframe plus the dependent frames that follow it is a GOP, or group of pictures. That structure is why seeking and scrubbing feel sticky, why a stream-copy cut can only start at a keyframe, and why ProRes, where every frame is a keyframe, scrubs instantly.
Open a video file and you might assume it contains a sequence of pictures. It mostly doesn't. A small fraction of the frames are complete images, and the rest are descriptions of how the previous frame changed.
The complete ones are keyframes, also called I-frames. Everything else depends on them.
Why encoders work this way
Consecutive frames are overwhelmingly similar. In a two second shot of someone talking, the wall behind them is identical in every frame. Storing that wall sixty times is enormously wasteful, so the encoder stores it once and then records only what moved.
The saving is not marginal. A typical delivery file might place a keyframe every two to ten seconds, and the frames in between can be a small fraction of the size. That is most of why a ten minute video is not gigabytes. It is also why bitrate and resolution are not the same lever: the bits a keyframe consumes are bits the frames after it do not get.
I-frames, P-frames and the GOP
Three frame types do the work. An I-frame is intra-coded — the complete picture, decodable on its own. A P-frame is predicted from frames before it. A B-frame is predicted bi-directionally, from frames both before and after it, which is why it compresses best and why the order frames are stored in a file is not the order they are displayed in.
A keyframe plus everything that depends on it is a group of pictures, or GOP. The GOP is the real unit of independence: it is the smallest span of the file a decoder can reconstruct without reading anything earlier. Where GOP boundaries land is an encoder decision, made two ways at once — at a fixed interval, which is what an encoder's keyframe-interval setting controls, and at scene changes, where predicting from the previous shot would be worthless anyway. This is why keyframe spacing on a real file is uneven rather than metronomic, and why a cut that snapped to a keyframe can miss by a few frames on one file and by two seconds on another.
One further distinction explains cuts that look right and play wrong. An open GOP lets its leading frames reference the GOP before it, so it is not genuinely self-contained; a closed GOP does not. In H.264 the keyframe that truly resets the decoder is an IDR frame, and a plain I-frame need not be one. A tool that starts a stream copy at an I-frame that is not an IDR can hand you a first second of garbled picture that cleans itself up — the file is not corrupt, it is being decoded without the references it was written to expect.
The three consequences you actually feel
Scrubbing feels sticky on some files. To display an arbitrary frame, the decoder has to find the previous keyframe and rebuild every frame from there to the one you asked for. Drop the playhead just before a keyframe and the work is small. Drop it just after and there may be hundreds of frames to reconstruct first.
Cuts can land where you didn't put them. A trim that re-encodes can cut anywhere. A trim that copies the stream without re-encoding can only start at a keyframe, because there is nothing else to start from. That is why some tools quietly move your in-point by up to a few seconds and why the result is sometimes shorter or longer than you asked for.
Some operations are instant and some are not. Anything that can be done by copying compressed data straight across is fast and lossless. Anything that has to decode and re-encode costs time and a generation of quality — and, on a long or high-resolution file, most of the wall-clock time of the export.
Editing codecs make a different trade
ProRes and similar intermediate codecs store every frame independently, which is to say every frame is a keyframe. That is why scrubbing a ProRes file is instant and why cuts land exactly where you place them. You pay in file size, often by a factor of ten or more.
That trade is the whole reason both kinds of codec exist. Delivery codecs optimise for the viewer who watches start to finish. Editing codecs optimise for the editor who jumps around.
Crisp's export menu carries the editing side of that trade explicitly: ProRes 422 LT, ProRes 422 and ProRes 422 HQ are all offered, each labelled "editing" in the list. Because the ProRes family can only live in a QuickTime container, choosing one also fixes the wrapper — Crisp rewrites the output extension to .mov rather than writing a file the muxer would reject. If the next thing that happens to a file is an edit rather than an upload, that is the choice this whole page is about.
What this means in practice
If scrubbing is painful on a long file, the codec is usually the reason rather than your machine. Transcoding to an intermediate before a heavy edit is a real fix, not a superstition.
If a trim landed in the wrong place, the tool almost certainly took the fast stream-copy path. And if you are re-exporting the same file repeatedly, remember that each re-encode is a generation of loss. Keep the master.
Which Crisp operations copy, and which re-encode
Crisp picks a side per operation rather than globally, and the choice is always the same question: can this be done by moving compressed data, or does it need decoding?
Converting the container takes the copy path. Crisp stream-copies the video into the new wrapper when the source codec is one that muxes cleanly into both MP4 and MOV — H.264, HEVC, MPEG-4, AV1 or MJPEG — and re-encodes only when the codec cannot live in the target container, such as VP9 or Theora into MP4. The job reports which of the two it did, as a strategy of copied or re-encoded, so "lossless" is a claim you can check rather than take on trust.
Trimming does the opposite, on purpose. Crisp's trim seeks and re-encodes rather than stream-copying, for the reason the module itself records: a stream copy would snap to the nearest keyframe and drift. You pay one encode to get the in-point you actually asked for instead of the nearest keyframe to it. The timeline works the same way — clips are trimmed inside the filter graph, which means decoding, which means the cut lands on the frame you chose.
Grabbing a still frame splits the difference, and the split is instructive. Crisp does a fast keyframe-anchored seek to a few seconds before the frame you asked for, then an accurate seek for the remainder — cheap positioning first, exact positioning only over the short distance that actually needs decoding.
That hybrid exists because the naive alternative gets more expensive the further into a file you reach. Measured on a 300-second source while building Crisp's montage assembler, cutting the same 0.467-second segment with a decode-everything filter cost 273.9 ms at five seconds in and 502.3 ms at 295 seconds in. Switching the single-segment case to a keyframe-anchored input seek made it a flat 274 ms wherever the cut sat. The cost of reaching a frame is the cost of the frames before it, back to the last keyframe — or, if you ask for it the wrong way, back to the start of the file.
Keyframes, in detail
Why does my video scrub smoothly in one app and badly in another?
Usually because one app has transcoded or cached an intermediate version. The underlying file still needs a keyframe plus every frame since, so an app that quietly builds a proxy will feel far faster on the same source.
Can I add more keyframes to make editing easier?
Only by re-encoding, which means a quality generation. If you are doing serious work the better move is transcoding to an intermediate codec where every frame is independent, rather than nudging the keyframe interval of a delivery codec.
Why is trimming sometimes instant and sometimes slow?
Instant means the tool copied the compressed stream without decoding, which can only start at a keyframe. Slow means it decoded and re-encoded, which lands the cut exactly where you asked and costs a generation.
Does a shorter keyframe interval improve quality?
Not directly, and it can hurt. Keyframes are large, so more of them at a fixed bitrate leaves fewer bits for everything else. Shorter intervals help seeking and streaming startup, which is why streaming platforms use them.
Related
Download Crisp for Mac Free to try, one-time $129 to remove the watermark. Runs entirely on your Mac.