Author Archives: Multimedia Mike

Knowing Too Much

I heard an old, familiar song on the radio this morning. But something about it was off, and I knew what. I found myself yelling at the radio, “Use a higher bitrate!” For you see, the chorus of the song exhibited something that sounded like the notorious “underwater” artifact in MP3 when encoding with too low a bitrate.

I remember first hearing perhaps 10 years ago that radio stations were starting to move all of their music to MP3 (prior to that, I remember hearing that some would have a stack of about 10 CD players with music queued up; who really knows? And I’m sure varying radio stations use different equipment and setups). I just assumed that a radio station would use the highest bitrate possible. Perhaps this particular encoding was a leftover from when the radio station first moved to MP3 (the song itself was from 1995), when they assigned an intern to use some shareware encoder that was only capable of 96 kbps MP3.

I know I can’t be the only multimedia geek who gets frustrated at seeing sub-optimality deployed in the world at large. I remember staying at a hotel during Christmas of 2000 (the same year I was just starting to study multimedia) where the in-hotel movie preview system through the TV displayed horrible blocking artifacts. At the time, I only vaguely understood what could have been going on.

FATE On DOS

FATE cycles coming from DOS? Sure, why not? As long as someone is willing to do the work to maintain such a machine and contribute continuous build/test data for FFmpeg, let’s let them. That’s why I designed FATE with its distributed model.

Meet Michael K. He has set up a DOSEMU/FreeDOS session on a modern machine that has all the amenities of a typical Unix system, including gcc provided by DJGPP. Python 2.5+ must also be available and that’s all that’s really needed to run FATE (that and TCP/IP networking, somehow).

And now I really need to get some kind of front page revision rolled out. I happen to know some people are getting annoyed at having to sift through the, ahem, less relevant platforms at the top to get down to the real meat.

Escape From HappyFaceLand

I delved deep into my personal programming archives and was reminded of the brief stint I served at my dream job as a video game developer. The game I worked on was entitled Escape From HappyFaceLand. The stories you have no doubt heard about the game industry are true– Ridiculous hours, breakneck development cycles, struggles with arcane gaming technology, haphazard coding just to get something that barely works in time to meet an artificial deadline, only to be promptly forgotten about, even though the game is an unqualified success at release time.

Continue reading →

Intel Beats Up GCC

Executive Summary: Showcased by FFmpeg, Intel’s C Compiler beats gcc’s C compiler. Handily. Decisively. I stop just short of brutal dismemberment metaphors because that just seems so tasteless, and because I know there must be options to explore in order to improve gcc’s numbers.

Pursuant to my last post where I found results all over the map when comparing FFmpeg‘s performance when built with different compilers, with Intel’s C compiler (icc) barely edging out gcc 4.1.2, David Conrad recommended that I try building FFmpeg with all ASM and manual SIMD optimizations disabled. In doing so, the compilers would have a chance to really shine in optimizing plain C code for a computationally intensive — not to mention commonplace — task. And so I repeated the same test, only I configured the builds with these options:

./configure --disable-yasm --disable-mmx \ 
--disable-mmx2 --disable-sse --disable-ssse3

I also built static binaries with no swscale, if that makes any difference. After each build, I manually audited the resulting binary using the command:

objdump -d ffmpeg_g | grep movq

This method is predicated on the observation that x86 SIMD code blocks nearly always involve at least a movq (move quadword) instruction.

Then I did 2 runs back to back with each build. The results are thus:


icc savagely destroys gcc

It’s interesting to note that icc’s build tested positive for movq instructions– they appear to be generated by the compiler, not present due to FFmpeg code. If the compiler was smart enough to build a binary that uses SIMD where appropriate, I count that as fair game for this exercise. Note that I didn’t specify any specific CPU type to icc. Meanwhile, the optimization level for the gcc builds is cranked up to -O3 (same with icc).

I’m eager to hear how gcc’s numbers might be improved in this case (especially for the latest gcc versions). For reference, every one of these gcc compiler versions was built from source by me. Did I neglect to configure with some –turbo option? Also, fairness dictates that I field suggestions about how to coax icc into building an FFmpeg binary that further embarrasses gcc — and, by extension, free software — in this matter.

Hey, wanna hear something really creepy? Just as I was finishing this post, an apparently automated email arrived from Intel, asking for my feedback on icc.

See Also: