That's from over 2 years ago. A version 10x faster (and with half the code stripped out) was available last year and I assume someone has made a sane version since.

Anyways he explains what happened: instead of choosing sane options, that encoder would iterate through every possible encoding and test each of them for PSNR, for a competition. It's not the kind of encoder you would ever use in practice.

For reference, there are 129,600 frames in a 1.5 hour long 24 fps movie.

At 0.75 hours per frame, that's 97,200 machine hours, or just under three years even if you have a cluster of 100 machines.

This might be GPU encoding's chance to shine. Right now it's generally considered to not be worth the hassle over a fast i7 machine.

And of course the algorithms will be optimized, maybe by orders of magnitude. But that's still a lot of computation power required, no matter how you slice it.

It's worse than that, as the algorithms are not simply parallelisable (frames relate to each other). Of course you could chop the film into 100 pieces, and compress each individually, but you would lose some compression rate which would (partly) defeat the whole purpose.

Not really - the encoder tends to reset quite often, e.g. it is recommended to insert an "I" frame every 5 seconds or less (stands for "intra coded", but could be thought of as "independent") - so that you have to decode at most 5 unused seconds when doing a random seek.

You wrote a whole lot here based on years-old numbers for a prototype encoder whose implementation wasn't even relevant when the numbers were posted, as acknowledged in the posting. Why did you do that?