Big shout outs to x264, libavcodec, gpac, mediainfo, lftp, curl, mkvtoolnix, oggz, sox, lame, Ubuntu Linux, C, C++, Ruby, Rake, Postgresql, Redis, Dennis Ritchie, Steve Jobs, vim, emacs, and a hundred others. We couldn't have done it without all of you.
As far as I know, we are the only ones to give you full access to the command-line options in case you want to do funny stuff. The disadvantage is that we have been stuck with ffmpeg 0.6 on custom commands to not break backward-compatibility (which is what they used).
If they had used the presets, the encoding would have run with the latest ffmpeg which is also a lot faster.
Before current job I built a fairly large more general media management system which included tons of video related work (and encoding ;) ) using ffmpeg for some fairly prominent (something something geographic something / etc) so I definitely appreciate how powerfully awesome ffmpeg is once you get over the initial overwhelming hump of having to learn all the more general video concepts involved outside of ffmpeg.
Which is why seeing a "performance comparison" blog post was immediately extremely suspicious sounding for the very valid point that everyone has brought up that speed isn't all that matters. From my experience speed is one of the lowest concerns anyone doing anything professionally with video has. Quality / reliability / tweak-ability are all much more important.
If you're writing software you intend to sell for money for anything other than cat videos uploaded to youtube - do yourself a favor and make sure you're informed about all the core concepts before randomly picking someone. You'd be surprised at all the hiccups and encoding issues you run across once you have a large enough sample set of "problem videos" to test against.