Not to this extreme, as far as I can tell, though I wasn't in the industry during the period that got standardized. You can actually go and try out some of the proposals; one, for example, was called Nokia MVC (not to be confused with the much later H.264 MVC); see http://wiki.multimedia.cx/index.php?title=Nokia_MVC for more information. While it certainly was a kitchen-sink of "interesting" features (affine motion compensation, KLT, etc), it was not so slow as to be impossible to use.
But I can't say for sure that there weren't some totally insane encoders put forward by those involved.
What I suspect is going on is a case of exponents. That is, you have an algorithm that tries every possible A, an algorithm that tries every possible B, and an algorithm that tries every possible C. You optimize them independently, and then in the final encoder you submit, you run them all at the same time, optimizing every possible A, for every possible B, for every possible C, sending runtime sky-high.
I'd read the code, but it's nearly-undocumented C++, written by the kind of people who reimplemented their own option parser using C strings (in C++) in Visual Studio.
But I can't say for sure that there weren't some totally insane encoders put forward by those involved.
What I suspect is going on is a case of exponents. That is, you have an algorithm that tries every possible A, an algorithm that tries every possible B, and an algorithm that tries every possible C. You optimize them independently, and then in the final encoder you submit, you run them all at the same time, optimizing every possible A, for every possible B, for every possible C, sending runtime sky-high.
I'd read the code, but it's nearly-undocumented C++, written by the kind of people who reimplemented their own option parser using C strings (in C++) in Visual Studio.