{"course":{"slug":"motion-and-audio","title":"Motion, Sound and Music","url":"https://addaly.com/learn/motion-and-audio","level":"intermediate","track":"create"},"lesson":{"slug":"intra-vs-inter-frames","title":"Frames that stand alone, and frames that do not","url":"https://addaly.com/learn/motion-and-audio/intra-vs-inter-frames","position":38,"of":72,"minutes":10,"answer":"A P- or B-frame is defined in terms of its neighbours, so a decoder cannot show frame 43 without decoding from the last keyframe forward, which is why long-GOP material scrubs badly.","keyIdea":"A P- or B-frame is defined in terms of its neighbours, so a decoder cannot show frame 43 without decoding from the last keyframe forward, which is why long-GOP material scrubs badly, why all-intra intermediates exist, and why a proxy beats a hardware upgrade."},"body":{"format":"markdown","text":"## Why scrubbing a phone video feels like wading\n\nDrag the playhead through footage straight off a camera and it lags, sometimes by half a second. Drag through the same footage converted to ProRes and it responds instantly, from a file five times larger. Nothing about your machine changed. The difference is whether each frame can be decoded on its own.\n\n## Three kinds of frame\n\n**I-frame** (intra-coded, also called a keyframe). Compressed on its own, like a JPEG. Everything needed to reconstruct it is in the frame.\n\n**P-frame** (predicted). Stored as a set of instructions relative to an earlier frame: take that block, move it 14 pixels left and 3 up, and add this small correction. For typical footage a P-frame is a small fraction of an I-frame's size.\n\n**B-frame** (bidirectional). Predicted from frames both before *and* after it in display order. Even smaller. Because they reference a future frame, the frames have to be transmitted out of display order, which is why a video has a decode order and a presentation order that differ.\n\nA **GOP** (group of pictures) is one I-frame and the dependent frames that follow it. A typical streaming encode uses a GOP of one to two seconds: at 25fps, an I-frame every 25 to 50 frames.\n\n## What follows for editing\n\nTo show frame 43 of a GOP starting at frame 1, the decoder must decode frames 1 through 43. There is no way around it; frame 43 is defined in terms of its predecessors. Scrub backwards and it is worse, because going back one frame means decoding forward from the keyframe again.\n\nThis is why editing \"long-GOP\" material is slow, and why the standard professional move is to transcode to an **all-intra** codec first. Every frame is independent, every seek is a single decode, and the price is file size.\n\nThe all-intra options, with the free ones named:\n\n- **ProRes** (Apple) and **DNxHR** (Avid): the two paid-ecosystem standards, both readable and writable by ffmpeg and by the free DaVinci Resolve. ProRes 422 runs around 150 Mbit/s at 1080p25: roughly 20 GB an hour.\n- **FFV1**: open source, mathematically lossless, and the format chosen by several national archives, including for preservation work at the Library of Congress. In a Matroska container with checksums per frame, it is the free archival answer.\n- **Ut Video** and **HuffYUV**: free lossless intermediates, fast, larger than FFV1.\n- **MJPEG**: every frame a JPEG. Old, inefficient, universally decodable, and still occasionally the pragmatic answer.\n\n## Keyframes and streaming\n\nThe GOP length is a trade-off with two visible consequences.\n\n**Seeking granularity.** A player can only start at a keyframe. With a 10-second GOP, clicking the middle of a progress bar means the player decodes up to 10 seconds of video before it can show you anything, or shows you a frame up to 10 seconds away from where you clicked.\n\n**Adaptive streaming.** HLS and DASH cut the video into segments and switch quality at segment boundaries, which must be keyframes. If your keyframe interval does not divide evenly into the segment length, the packager inserts extra keyframes or the segments drift.\n\nThe convention that avoids both problems: a keyframe every 2 seconds, with segments of 2, 4 or 6 seconds.\n\n```bash\n# 2-second keyframe interval at 25fps, no scene-cut keyframes\nffmpeg -i in.mov -c:v libx264 -g 50 -keyint_min 50 -sc_threshold 0 out.mp4\n```\n\n`-sc_threshold 0` turns off automatic keyframes at scene cuts. For general viewing you want them on, because a cut is exactly where a fresh I-frame is cheap and useful. For adaptive streaming you want them off, so every keyframe is where the packager expects it.\n\n## Cutting without re-encoding\n\nBecause a GOP is a unit, you can trim a file at keyframe boundaries without touching the compressed data:\n\n```bash\nffmpeg -ss 00:01:30 -i in.mp4 -t 00:00:45 -c copy out.mp4\n```\n\n`-c copy` means no decode and no encode: it is nearly instantaneous and there is no generational loss at all. The catch is that the cut lands on the nearest keyframe, so your out point can be up to a GOP away from where you asked. For a rough trim before uploading, this is the right tool and almost nobody uses it.\n\n## Where long-GOP wins\n\nNothing above says long-GOP is bad. For delivery it is dramatically more efficient: the whole reason streaming is possible. A 45-minute programme at 5 Mbit/s H.264 is about 1.7 GB; the same programme in ProRes 422 is about 50 GB.\n\nThe rule is the point in the chain. **Long-GOP for delivery, all-intra for work.** Acquisition sits in between and increasingly uses long-GOP for capacity, which is why the transcode step exists.\n\n## Proxies: the free middle path\n\nYou do not have to transcode to a huge intermediate to edit comfortably. A **proxy** is a small, low-resolution, all-intra copy that the editor uses for playback while the timeline still refers to the original for export.\n\n```bash\nffmpeg -i big.mp4 -vf scale=-2:540 -c:v dnxhd -profile:v dnxhr_lb \\\n  -c:a pcm_s16le proxy.mov\n```\n\nEvery serious editor supports this: DaVinci Resolve, Kdenlive and Shotcut all have proxy workflows in their free versions. It is the answer to \"my laptop cannot edit 4K\", and it is far more effective than any hardware upgrade at the same cost.\n\n## The free path\n\n**ffmpeg** encodes and decodes every format named here, including ProRes and DNxHR. **DaVinci Resolve**'s free edition has a full proxy and optimised-media workflow. **Kdenlive** and **Shotcut** both generate proxies with one setting. **FFV1** and **Matroska** are both open standards with no licensing questions, which is precisely why archives chose them.\n\n## The limitation\n\nAll-intra editing costs storage at a rate that surprises people. An hour of ProRes 422 HQ at 1080p is roughly 30 GB; at 4K it is over 100 GB. A week of shooting fills a drive, and the backup of that drive fills another.\n\nThere is also no single intermediate everyone agrees on. ProRes is effectively a standard and is Apple's; DNxHR is Avid's; FFV1 is open and slower to encode and not accepted by many facilities. Choosing one is a workflow decision with political and practical edges, and anybody who tells you there is an obvious answer works somewhere that already made it."},"check":{"question":"A team preparing video for adaptive streaming sets -sc_threshold 0 alongside a fixed two-second keyframe interval. Why turn off automatic keyframes at scene cuts, when a cut is exactly where a keyframe is cheapest?","options":[{"text":"Scene-cut keyframes are placed by a heuristic that misfires on fast-cut material, inserting so many I-frames that the average bitrate rises beyond the ladder's budget.","correct":false,"tempting":"Over-insertion is a real risk but a bitrate concern, not the reason the flag is standard for packaging."},{"text":"Adaptive streaming switches quality only at segment boundaries, which must be keyframes, so the keyframe positions have to be identical and predictable across every rendition.","correct":true},{"text":"Scene detection requires the encoder to look ahead, which is incompatible with the low-latency buffering that HLS and DASH players rely on.","correct":false,"tempting":"Look-ahead affects latency in live encoding but is unrelated to why packagers require fixed keyframe positions."},{"text":"A keyframe inserted at a scene cut is encoded without reference to the frames around it, so it cannot be used as the start of a B-frame pyramid, and the packager would have to re-encode the following frames to rebuild the reference structure at every segment boundary.","correct":false,"tempting":"Describes an internal reference-structure problem that packagers do not face; segments simply need to start at aligned keyframes."}]},"prev":{"slug":"what-a-codec-discards","title":"What a codec throws away","url":"https://addaly.com/learn/motion-and-audio/what-a-codec-discards"},"next":{"slug":"crf-and-bitrate","title":"Quality target or size target","url":"https://addaly.com/learn/motion-and-audio/crf-and-bitrate"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Frames that stand alone, and frames that do not', in Motion, Sound and Music. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/motion-and-audio/intra-vs-inter-frames (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Frames that stand alone, and frames that do not","courseTitle":"Motion, Sound and Music","module":{"index":5,"slug":"codecs-colour-and-delivery","title":"Codecs, colour and delivery"},"answer":null,"keyIdea":"A P- or B-frame is defined in terms of its neighbours, so a decoder cannot show frame 43 without decoding from the last keyframe forward, which is why long-GOP material scrubs badly, why all-intra intermediates exist, and why a proxy beats a hardware upgrade.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"why-scrubbing-a-phone-video-feels-like-wading","runs":[{"text":"Why scrubbing a phone video feels like wading"}]},{"t":"p","runs":[{"text":"Drag the playhead through footage straight off a camera and it lags, sometimes by half a second. Drag through the same footage converted to ProRes and it responds instantly, from a file five times larger. Nothing about your machine changed. The difference is whether each frame can be decoded on its own."}]},{"t":"h2","id":"three-kinds-of-frame","runs":[{"text":"Three kinds of frame"}]},{"t":"p","runs":[{"text":"I-frame","b":true},{"text":" (intra-coded, also called a keyframe). Compressed on its own, like a JPEG. Everything needed to reconstruct it is in the frame."}]},{"t":"p","runs":[{"text":"P-frame","b":true},{"text":" (predicted). Stored as a set of instructions relative to an earlier frame: take that block, move it 14 pixels left and 3 up, and add this small correction. For typical footage a P-frame is a small fraction of an I-frame’s size."}]},{"t":"p","runs":[{"text":"B-frame","b":true},{"text":" (bidirectional). Predicted from frames both before "},{"text":"and","i":true},{"text":" after it in display order. Even smaller. Because they reference a future frame, the frames have to be transmitted out of display order, which is why a video has a decode order and a presentation order that differ."}]},{"t":"p","runs":[{"text":"A "},{"text":"GOP","b":true},{"text":" (group of pictures) is one I-frame and the dependent frames that follow it. A typical streaming encode uses a GOP of one to two seconds: at 25fps, an I-frame every 25 to 50 frames."}]},{"t":"h2","id":"what-follows-for-editing","runs":[{"text":"What follows for editing"}]},{"t":"p","runs":[{"text":"To show frame 43 of a GOP starting at frame 1, the decoder must decode frames 1 through 43. There is no way around it; frame 43 is defined in terms of its predecessors. Scrub backwards and it is worse, because going back one frame means decoding forward from the keyframe again."}]},{"t":"p","runs":[{"text":"This is why editing “long-GOP” material is slow, and why the standard professional move is to transcode to an "},{"text":"all-intra","b":true},{"text":" codec first. Every frame is independent, every seek is a single decode, and the price is file size."}]},{"t":"p","runs":[{"text":"The all-intra options, with the free ones named:"}]},{"t":"ul","items":[[{"text":"ProRes","b":true},{"text":" (Apple) and "},{"text":"DNxHR","b":true},{"text":" (Avid): the two paid-ecosystem standards, both readable and writable by ffmpeg and by the free DaVinci Resolve. ProRes 422 runs around 150 Mbit/s at 1080p25: roughly 20 GB an hour."}],[{"text":"FFV1","b":true},{"text":": open source, mathematically lossless, and the format chosen by several national archives, including for preservation work at the Library of Congress. In a Matroska container with checksums per frame, it is the free archival answer."}],[{"text":"Ut Video","b":true},{"text":" and "},{"text":"HuffYUV","b":true},{"text":": free lossless intermediates, fast, larger than FFV1."}],[{"text":"MJPEG","b":true},{"text":": every frame a JPEG. Old, inefficient, universally decodable, and still occasionally the pragmatic answer."}]]},{"t":"h2","id":"keyframes-and-streaming","runs":[{"text":"Keyframes and streaming"}]},{"t":"p","runs":[{"text":"The GOP length is a trade-off with two visible consequences."}]},{"t":"p","runs":[{"text":"Seeking granularity.","b":true},{"text":" A player can only start at a keyframe. With a 10-second GOP, clicking the middle of a progress bar means the player decodes up to 10 seconds of video before it can show you anything, or shows you a frame up to 10 seconds away from where you clicked."}]},{"t":"p","runs":[{"text":"Adaptive streaming.","b":true},{"text":" HLS and DASH cut the video into segments and switch quality at segment boundaries, which must be keyframes. If your keyframe interval does not divide evenly into the segment length, the packager inserts extra keyframes or the segments drift."}]},{"t":"p","runs":[{"text":"The convention that avoids both problems: a keyframe every 2 seconds, with segments of 2, 4 or 6 seconds."}]},{"t":"code","lang":"bash","label":"Bash","text":"# 2-second keyframe interval at 25fps, no scene-cut keyframes\nffmpeg -i in.mov -c:v libx264 -g 50 -keyint_min 50 -sc_threshold 0 out.mp4"},{"t":"p","runs":[{"text":"-sc_threshold 0","code":true},{"text":" turns off automatic keyframes at scene cuts. For general viewing you want them on, because a cut is exactly where a fresh I-frame is cheap and useful. For adaptive streaming you want them off, so every keyframe is where the packager expects it."}]},{"t":"h2","id":"cutting-without-re-encoding","runs":[{"text":"Cutting without re-encoding"}]},{"t":"p","runs":[{"text":"Because a GOP is a unit, you can trim a file at keyframe boundaries without touching the compressed data:"}]},{"t":"code","lang":"bash","label":"Bash","text":"ffmpeg -ss 00:01:30 -i in.mp4 -t 00:00:45 -c copy out.mp4"},{"t":"p","runs":[{"text":"-c copy","code":true},{"text":" means no decode and no encode: it is nearly instantaneous and there is no generational loss at all. The catch is that the cut lands on the nearest keyframe, so your out point can be up to a GOP away from where you asked. For a rough trim before uploading, this is the right tool and almost nobody uses it."}]},{"t":"h2","id":"where-long-gop-wins","runs":[{"text":"Where long-GOP wins"}]},{"t":"p","runs":[{"text":"Nothing above says long-GOP is bad. For delivery it is dramatically more efficient: the whole reason streaming is possible. A 45-minute programme at 5 Mbit/s H.264 is about 1.7 GB; the same programme in ProRes 422 is about 50 GB."}]},{"t":"p","runs":[{"text":"The rule is the point in the chain. "},{"text":"Long-GOP for delivery, all-intra for work.","b":true},{"text":" Acquisition sits in between and increasingly uses long-GOP for capacity, which is why the transcode step exists."}]},{"t":"h2","id":"proxies-the-free-middle-path","runs":[{"text":"Proxies: the free middle path"}]},{"t":"p","runs":[{"text":"You do not have to transcode to a huge intermediate to edit comfortably. A "},{"text":"proxy","b":true},{"text":" is a small, low-resolution, all-intra copy that the editor uses for playback while the timeline still refers to the original for export."}]},{"t":"code","lang":"bash","label":"Bash","text":"ffmpeg -i big.mp4 -vf scale=-2:540 -c:v dnxhd -profile:v dnxhr_lb \\\n  -c:a pcm_s16le proxy.mov"},{"t":"p","runs":[{"text":"Every serious editor supports this: DaVinci Resolve, Kdenlive and Shotcut all have proxy workflows in their free versions. It is the answer to “my laptop cannot edit 4K”, and it is far more effective than any hardware upgrade at the same cost."}]},{"t":"h2","id":"the-free-path","runs":[{"text":"The free path"}],"role":"free"},{"t":"p","runs":[{"text":"ffmpeg","b":true},{"text":" encodes and decodes every format named here, including ProRes and DNxHR. "},{"text":"DaVinci Resolve","b":true},{"text":"’s free edition has a full proxy and optimised-media workflow. "},{"text":"Kdenlive","b":true},{"text":" and "},{"text":"Shotcut","b":true},{"text":" both generate proxies with one setting. "},{"text":"FFV1","b":true},{"text":" and "},{"text":"Matroska","b":true},{"text":" are both open standards with no licensing questions, which is precisely why archives chose them."}]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"All-intra editing costs storage at a rate that surprises people. An hour of ProRes 422 HQ at 1080p is roughly 30 GB; at 4K it is over 100 GB. A week of shooting fills a drive, and the backup of that drive fills another."}]},{"t":"p","runs":[{"text":"There is also no single intermediate everyone agrees on. ProRes is effectively a standard and is Apple’s; DNxHR is Avid’s; FFV1 is open and slower to encode and not accepted by many facilities. Choosing one is a workflow decision with political and practical edges, and anybody who tells you there is an obvious answer works somewhere that already made it."}]}],"check":{"question":[{"text":"A team preparing video for adaptive streaming sets -sc_threshold 0 alongside a fixed two-second keyframe interval. Why turn off automatic keyframes at scene cuts, when a cut is exactly where a keyframe is cheapest?"}],"options":[{"text":[{"text":"Scene-cut keyframes are placed by a heuristic that misfires on fast-cut material, inserting so many I-frames that the average bitrate rises beyond the ladder’s budget."}],"correct":false,"tempting":[{"text":"Over-insertion is a real risk but a bitrate concern, not the reason the flag is standard for packaging."}]},{"text":[{"text":"Adaptive streaming switches quality only at segment boundaries, which must be keyframes, so the keyframe positions have to be identical and predictable across every rendition."}],"correct":true,"tempting":null},{"text":[{"text":"Scene detection requires the encoder to look ahead, which is incompatible with the low-latency buffering that HLS and DASH players rely on."}],"correct":false,"tempting":[{"text":"Look-ahead affects latency in live encoding but is unrelated to why packagers require fixed keyframe positions."}]},{"text":[{"text":"A keyframe inserted at a scene cut is encoded without reference to the frames around it, so it cannot be used as the start of a B-frame pyramid, and the packager would have to re-encode the following frames to rebuild the reference structure at every segment boundary."}],"correct":false,"tempting":[{"text":"Describes an internal reference-structure problem that packagers do not face; segments simply need to start at aligned keyframes."}]}],"order":[0,1,2,3],"why":null},"prev":{"slug":"what-a-codec-discards","title":"What a codec throws away","minutes":11},"next":{"slug":"crf-and-bitrate","title":"Quality target or size target","minutes":10}}}