Many of you VapourSynth and Avisynth users are probably familiar with FFMS2, the reasonably useful source plugin that can open almost everything and fairly often seeks properly. Or at least it used to seek fairly well back when it was released 17 years ago. Since then the number of seeking workarounds and complexity has reached insane levels due to many newer video codecs having more and more complex reordering with invisible frames and other tricks. This broke every single original assumption made about seeking. And then the new assumptions were broken. And the new new assumptions failed. And the shiniest and freshest assumptions produced the wrong frames before finally ending at the current state of not being completely broken again.

Due to the insane tedium of trying to find new workarounds I lost interest in trying to fix FFMS2. Instead I started on BestSource. The first official release 2 years ago did pure linear decoding only with some caching and tricks behind the scenes to allow for relatively fast jumping around (by linear decoding standards). It was correct but for high resolution files over 5 minutes it was not enjoyable to use. It definitely had its niche use cases but FFMS2 still had hardcore followers for a reason.

That was however just where the project stopped due to a lack of time. The plan was always to implement seeking by hashing the output frames and using that to figure out where seeking actually takes us. And now it’s happened. Perfect and fast seeking in almost all formats and containers. Complete with proper RFF handling and in most cases the index only takes up 9 bytes per frame where 8 of them is the hash itself. FFMS2 is now officially obsolete.

But why didn’t anyone do it earlier? The idea is obvious. Many FFMS2 contributors with sufficient coding skills have thought about doing it. And after you’ve accepted an indexing pass it’s a no-brainer! Except that back in 2007 it would’ve been unacceptably slow. Even parsing a whole movie to index it generated complaints because hard drives were true snails. Doing a full decode of every frame would’ve ensured nobody wanted to use it. Besides, handling the delay introduced by b-frames wasn’t hard and only mpeg4 asp and h.264 existed that had to be tested for this complexity. For a short time it was possible to both be fast and correct. Apart from the poor and unreliable seeking in FFmpeg’s mpeg/mpegts demuxers which would surely be fixed soon and then all popular containers would work well! (It has to this day not been improved at all)