Jumping to random points in a long H.264 MP4 is sluggish, but Task Manager never shows 100 percent CPU. Could long-GOP structure cause latency without maxing the whole processor?
Yes. Random access can require decoding from an earlier keyframe through dependent frames before the requested frame appears. That work can be serial/bursty rather than sustained 100-percent CPU.
Hardware decode can help, while intraframe proxies often improve random seeking even more because frames are easier to access independently.
Action Video Lab Editorial Team
Storage latency matters too when several streams are active. Test one clip on a local SSD before blaming decoding alone.
A local SSD helps a little, but an intraframe proxy makes seeking dramatically faster. Source structure is clearly a major part of the delay.
I moved the file from an external HDD to the internal SSD. Random seeking improved a little, but the delay did not disappear, so storage was only part of it.
How long is the GOP? If keyframes are several seconds apart, a backward jump can require a surprising amount of reconstruction even when average CPU usage looks modest.
Keyframes are roughly every two seconds. A proxy with much shorter GOP/intraframe-friendly settings feels almost instant.
That comparison is more informative than the CPU percentage. Random-access latency can be dominated by dependency structure and decoder scheduling rather than sustained all-core load.
Codecs & export
I see the same thing when making lots of tiny cuts. Normal playback is fine; thumbnail generation and jumping between cuts are what make the source feel heavy.
For long-GOP camera media, proxying is often the least destructive answer because it changes the editing representation, not the archive master.
Editing workflows
I am keeping the original H.264 and using proxies. That solved the actual editing problem without another full-resolution transcode set.