Hector Martin

The reason for that is actually the codec. The video on the left is likely encoded in h.264 where, I shit you not, the relationship between frames is a directed acyclic graph - any frame can depend on any previous frame. In contrast, the video on the right is likely a .mov [1/2]

The codec commonly used in .mov, Quick Time Animation, encoded all frames independently which allows for instant scrubbing. But modern codecs such as HAP still allow to that on our modern computers... except they allow it in 4K+ resolutions. Also, thanks for ripcord :D

yeah, the video on the left is an MP4 re-encoding of the video on the right. the video on the right, in the .mov container, is Sorenson video. which is easier to scrub through. but the point of the comparison was software in 2020 vs 2002. which includes the codec. so that's 1/2

why I re-encoded it. but it's not an excuse for the modern software. there's so much computing power in this machine. it could easily make scrubbing responsive if it wanted to. (and some software can.) the people who made it just don't care enough.

It's not possible to make scrubbing universally responsive in h.264 except post facto by caching the hell out of everything. Keyframe intervals can be arbitrarily long and smooth scrubbing requires being able to decode one whole GOP per screen frame.

i've got 8gb of video memory and hundreds of milliseconds between clicking the mouse button down and moving the playhead. and even updating the player window every 100 milliseconds would be a huge improvement.

if you look at these old players they are actually doing all of these dirty tricks to make things responsive that you may be writing off in your head as not worth it.

Citation needed. Scrubbing is trivial when all your frames are I frames and requires no more memory or CPU than normally playing the video. It's literally zero extra code. That stops working when you introduce interframe compression.