FFmpeg is quite an amazing program. There’s a certain smugness that comes with being involved with it. That can lead to a bit of complacency followed by shock when realizing that you’re not as good as you thought you were.
That happened to me recently when I realized the official libtheora decoder is significantly more performant than FFmpeg’s Theora decoder. I suddenly wondered if this was true in any other departments, i.e., if FFmpeg is slower than other open source libraries that are dedicated to a single purpose. Why do I care? Because I started to wonder if FFmpeg would simply come to be known as the gcc of multimedia processing.
Is it good or bad to be compared to gcc in this way? Depends; gcc has its pros and cons. A colleague once succinctly summarized these trade-offs thusly: “You can generally count on gcc to generate adequate code for just about any platform.” Some free software fans grow indignant when repeated benchmarks unequivocally show, e.g., Intel’s proprietary compilers slaughtering gcc’s various versions. But what do you expect? gcc spreads the effort around to all kinds of chips while Intel largely focuses on generating code for chips that they invented and know better than anyone else. Frankly, I’ve always admired gcc for being able to do as well as it does.
But does it have to be that way with FFmpeg? “You can generally count on FFmpeg to be able to decode a particular format fairly quickly and encode to a wide variety of formats with reasonable quality.” That’s certainly the case currently regarding Theora (it can decode the format, just not as efficiently as libtheora). What about some other notable formats? I think some tests are in order.
Methodology: Take a long audio file (I had a 10m44s audio file within reach when I brainstormed this test) and encode it as MP3, AAC, Vorbis, and FLAC. Profile FFmpeg’s performance vs. other open source packages by measuring best wall-clock (real) time out of 3 consecutive runs. Run these tests on an EeePC 701 which has an Intel Celeron M running at 630 MHz. This is somewhere that performance matters. Ask all programs to decode to 16-bit PCM and dump the output directly to /dev/null while squelching as much console output as the program will allow (I don’t know how to make FFmpeg shut up entirely but ‘-v 0’ makes it not update its status along the way).
FFmpeg SVN revision 20667 was used for these tests.
Using FLAC 1.2.1. Command lines:
ffmpeg -v 0 -i file.flac -f s16le - > /dev/null flac --silent --stdout --decode file.flac > /dev/null
FFmpeg: 8.4s FLAC: 12.2s
Using whatever is currently installed in Ubuntu 9.10. I saw some security updates were downloaded recently so I suspect the Ogg and Vorbis libraries are quite up to date. Command lines:
ffmpeg -v 0 -i file.ogg -f s16le - > /dev/null oggdec --quiet --raw --output /dev/null file.ogg
FFmpeg: 7.2s libvorbis: 12.3s
Using FAAD v2.6. Command lines:
ffmpeg -v 0 -i file.m4a -f s16le - > /dev/null faad -q -f 2 file.m4a -o /dev/null
FFmpeg: 7.4s libfaad: 17.5s
Using mpg123 v1.9.2 and madplay v0.15.1 (beta). Command lines:
ffmpeg -v 0 -i file.mp3 -f s16le - > /dev/null madplay --very-quiet --output=raw:/dev/null file.mp3 mpg123 -q -s file.mp3 > /dev/null
FFmpeg: 22.3s libmad: 24.2s mpg123: 9.5s
So FFmpeg fared quite well except in the case of MP3 decoding. I’m a bit surprised that FFmpeg is relatively so slow to decode MP3. As Mans discovered, sometimes FFmpeg’s deficiencies are actually gcc’s fault. However, that blog post was primarily concerned with PowerPC. I wonder if x86_32 has the same problems.
I also wanted to test XviD vs. FFmpeg’s decoder but I didn’t know how to set up that test. And if you want to know how various H.264 decoders stack up, both performance-wise and feature-wise, corner Dark Shikari and he will be pleased to regale you with the benchmarks.
So I guess that leaves FFmpeg’s Theora decoder as the biggest embarrassment. The good news is that I have some substantial optimizations planned for the very near future.