Why H.264 and AV1 Are Hard to Edit: Long-GOP Explained
In short
H.264 and AV1 are hard to edit because they are long-GOP codecs that store complete frames only at intervals, so an editor decodes many frames to show one. Intraframe codecs like ProRes and DNxHR store every frame whole, so scrubbing and cutting stay light, at the cost of far larger files.
On this page
What is a long-GOP codec?
A long-GOP codec is a video codec that stores complete frames only at intervals and predicts the frames between them. H.264, HEVC, VP9 and AV1 all work this way, and they are the codecs YouTube streams. The long-GOP glossary entry keeps the one-line definition.
GOP means group of pictures. Each group opens with an I-frame, a full picture that decodes on its own. The frames after it are P-frames, which store only what changed since an earlier frame, and B-frames, which borrow from frames both before and after them.
Long-GOP compression is excellent for delivery. A talking head against a still wall changes very little from frame to frame, so most frames cost a handful of bits. The price is dependency: a P-frame or B-frame means nothing until the frames it points to have been decoded first.
For a streaming platform that trade is ideal, because viewers play forward from the start. An editor does the opposite, jumping, scrubbing backward and cutting in the middle of groups, which is why the YouTube codecs H.264, VP9 and AV1 behave so differently on a timeline than in a browser.
What is an intraframe codec?
An intraframe codec is a video codec that compresses every frame on its own, with no reference to any other frame. Apple ProRes and Avid DNxHR are intraframe codecs, built for editing rather than delivery.
The Apple ProRes white paper describes every ProRes codec as frame-independent: each frame is encoded and decoded without touching its neighbors, a design Apple credits with the best editing performance. Avid’s DNxHR follows the same principle for Avid Media Composer and DaVinci Resolve.
The comparison table sets long-GOP delivery codecs against intraframe editing codecs, aspect by aspect.
| Aspect | Long-GOP (H.264, VP9, AV1) | Intraframe (ProRes, DNxHR) |
|---|---|---|
| How frames are stored | One complete frame per group, the rest as predicted changes | Every frame complete |
| Work to show one frame | Decode back from the last I-frame, often dozens of frames | Decode that frame only |
| Scrubbing and reverse play | Often stutters, worst in reverse | Usually smooth |
| Cutting mid-group | The editor rebuilds the group around each cut | No group to rebuild |
| File size | Small, built for streaming | Large, often 10 times the source or more |
| Hardware decode | Depends on your GPU generation and the codec | Rarely needed |
| Designed for | Delivery and streaming | Editing, grading, finishing |
The link between those rows is simple: long-GOP spends your processor’s time to save disk space, and intraframe spends disk space to save your processor’s time.
Why does long-GOP footage stutter when scrubbing?
Long-GOP footage stutters when scrubbing because every frame you land on may depend on a chain of earlier frames. To show frame 40 of a group, the decoder first rebuilds the I-frame and every reference frame between it and frame 40, then throws that work away when you move again.
Forward playback hides much of that cost, since each decoded frame feeds the next one. Scrubbing, reverse playback and jumping between cuts break the chain over and over, so the decoder restarts from an I-frame each time.
The cost multiplies on a real timeline. Two long-GOP clips stacked for a transition, a speed ramp or a multicam angle each need their own decode chain, and effects on top compete for the same processor. Every extra layer adds another group to rebuild for each frame the playhead lands on.
Resolution and codec raise the stakes further. A 4K frame has four times the pixels of a 1080p frame (3840 x 2160 against 1920 x 1080), and AV1 and VP9 use more complex prediction than H.264. On Ema Zamboni’s own DaVinci Resolve Studio timelines on Windows 11, 4K60 AV1 footage downloaded from YouTube was heavy to play back, and AV1 or VP9 downloads crashed Resolve at times.
Hardware decoding decides how much of that you feel. When your graphics card has no hardware decoder for a codec, all of that work lands on the CPU, which is the pattern behind YouTube video choppy in DaVinci Resolve with AV1 and VP9.
What does transcoding change for timeline playback?
Transcoding decodes each long-GOP frame once and writes it back as a complete intraframe frame, so your editor never has to rebuild a group again. The picture stays the same; the decode cost per frame drops.
A transcode cannot add detail. YouTube’s encoder already removed what it removed, and a ProRes or DNxHR copy preserves that picture rather than improving it. For the quality side of the choice, the best format to download YouTube videos for editing weighs each option.
B-ROLL applies this transcode at download time. When you pick ProRes or DNx as the format, B-ROLL downloads the best streams into an MKV master, then converts it with ffmpeg to a .mov of the same name, keeping the source resolution and frame rate. The conversion runs one file at a time on every CPU core, and the MKV master is deleted once the conversion succeeds.
B-ROLL also picks the tier: the lightest ProRes or DNxHR tier whose data rate, scaled to the clip’s frame size and frame rate, is at least 10 times the source bitrate, with DNxHR HQX for 10-bit sources. For a 1080p 30 fps source at 8 Mbps that means ProRes 422 LT, which Apple targets at 102 Mbps at 1920 x 1080 and 29.97 fps: 0.77 GB per minute (102 Mbps x 60 s / 8 bits per byte / 1000).
Download YouTube videos in ProRes or DNxHR covers every tier, and ProRes vs DNxHR for editing helps you choose between the two families.
Proxies are the other route: they keep the original file and add a light copy for editing. For heavily compressed YouTube sources, proxies vs transcoding for YouTube footage explains why a single transcode is usually the simpler workflow.
When is long-GOP footage fine to edit?
Long-GOP footage is fine to edit when the codec is light, the resolution is modest and your hardware decodes it. A 1080p H.264 clip cut with a few straight edits often plays well on a machine with H.264 hardware decoding.
Short timelines with little stacking also forgive long-GOP media. A handful of b-roll shots laid end to end, no reverse play and no heavy grading ask the decoder for little more than forward playback, which is what long-GOP was designed for.
Long-GOP turns into a problem as soon as one of those conditions breaks: 4K or 60 fps sources, VP9 or AV1 without hardware support, multicam, speed changes, or a grade that forces constant re-rendering. At that point an intraframe copy costs disk space and saves hours of waiting. The rest of the codec and container choices are mapped out in codecs and formats for editing YouTube footage.
Frequently asked questions
What does GOP stand for?
GOP stands for group of pictures: a run of frames that starts with a complete I-frame and continues with P-frames and B-frames predicted from their neighbors. A long-GOP codec uses long groups to save bits, while an intraframe codec makes every frame its own group of one, so any frame decodes without the others.
Why are intraframe files so large?
Intraframe files are large because every frame is compressed on its own, with no savings from repeating what the previous frame already showed. Apple's target rate for ProRes 422 LT is approximately 102 Mbps at 1920 x 1080 and 29.97 fps, many times a typical web stream. That extra data buys a frame your editor can decode instantly.
Is all-intra H.264 easier to edit than long-GOP H.264?
Yes. All-intra H.264 encodes every frame as an I-frame, so the editor never decodes neighboring frames to reach the one under the playhead. Each frame still goes through H.264's heavier decoding math, so ProRes and DNxHR usually stay lighter. Camera formats such as AVC-Intra use this all-intra approach for exactly that reason.
Sources
- Apple ProRes white paper (April 2022) apple.com
- Apple Support: About Apple ProRes support.apple.com
- Avid Knowledge Base: DNxHR Codec Bandwidth Specifications kb.avid.com
- ITU-T Recommendation H.264 itu.int
