The difference is random access.

An I-frame can be decoded without reconstructing another picture first. P and B pictures can use information from reference pictures. That dependency is one of the reasons long-GOP compression is efficient: instead of describing every frame independently, the codec spends bits mostly on what changed.

A media player usually moves forward in a predictable order, so those dependencies are efficient to decode. An editor behaves differently. You drag the playhead backwards, jump to a cut point, display thumbnails, reverse a clip, or ask for several tracks at once. To show a requested frame, the decoder may need to start from an earlier reference point and reconstruct a chain of dependent pictures.

Shorter GOPs or intra-heavy formats can improve seeking because frames are more independent, but the cost is usually more data. So “more I-frames” is not free quality or free speed; it trades compression efficiency for easier random access.

This is why acquisition/delivery codecs and editing intermediates solve different problems.

A camera wants to fit a lot of high-quality video on a memory card. Streaming wants to reduce bandwidth. Long-GOP compression is excellent for those goals. An editing intermediate is designed more around fast access and repeated decoding, so it may use less temporal dependency and much higher bitrates.

You do not necessarily need to convert everything to an intermediate, though. Modern hardware decoders can make long-GOP camera files perfectly usable. If native editing is smooth, keep it simple. If not, proxies give you many of the responsiveness benefits without turning the whole source library into huge intermediate files.

That is also why file size alone is a poor predictor of editing speed.

GOP structure can also affect what happens after an edit point during export.

If you use a true smart-render/copy workflow that avoids re-encoding, cuts may be restricted by keyframe positions or require special handling around the cut. In a normal NLE render, the editor decodes the source and encodes a new output, so you can cut on any frame — but the source still has to be decoded correctly to reach that frame.

For ordinary creative editing, I would not choose camera settings based only on GOP length unless the manufacturer exposes a meaningful option. Resolution, frame rate, bit depth, stabilization and image profile usually matter more at capture time.

Treat GOP information mainly as an explanation for why some compressed media seeks better than others.

The simplest mental model is: playback asks “what comes next?”, editing often asks “show me this exact frame right now.”

That is why the H.264 deep dive describes I/P/B frames in the context of timeline responsiveness: How H.264 actually works. HEVC uses a more advanced picture/reference structure, but the practical idea remains that inter-frame compression trades some random-access simplicity for storage efficiency.

In VSDC or any other NLE, if a long-GOP source scrubs badly, first test hardware decoding. If the project is still uncomfortable, proxies are usually a more targeted solution than changing the source codec after the fact.