Yearly Archives: 2008

AAC Decoder Is In!

It certainly has been a long journey for native Advanced Audio Coding (AAC) in FFmpeg. It started with a Google Summer of Code project back in FFmpeg’s inaugural FFmpeg SoC season (2006). It went unfinished. Since then, many people have endeavored to fix it up to the point where it can be included into the mainline. But it was Robert Swain who persevered toward the end goal. And now look:

$ ffmpeg -formats
[...]
Codecs:
 D V    4xm             4X Movie
 D V D  8bps            QuickTime 8BPS video
 D A    8svx_exp        8SVX exponential
 D A    8svx_fib        8SVX fibonacci
 D A    aac             Advanced Audio Coding
[...]

Robert profiled the new AAC decoder to be significantly faster than the libfaad, the prevailing AAC decoding solution in the open source community. Further optimization work is ongoing, as is support for more advanced coding modes. Currently, the decoder only deals with low complexity (AAC-LC), the most common variant you are likely to encounter.

And of course, thanks also to Robert for creating more FATE work for me. I can’t avoid the problem of testing perceptual audio decoders for much longer.

Baldur’s Task

I have a lot of experience consuming multimedia on Linux using open source software. But I have little experience generating or transcoding multimedia within the same parameters. So, much like I experienced with the MOOBEX exercise, I decided to move out of my comfort zone and work on transcoding for once.

Fortunately, I have a concrete task– a colleague who is interested in game preservation wanted to know about transcoding the Interplay MVE files from games such as Baldur’s Gate into a format a little more modern. So let’s see what we can do about using FFmpeg to transcode to MP4/H.264/AAC.


Baldur's Gate logo

I suspect the steps will look like this:

  • Download and install libfaac, as Kostya’s AAC encoder is not in the mainline tree yet
  • Download and install a recent snapshot of x264
  • Update to the latest SVN snapshot of FFmpeg and compile it with libfaac and x264 support
  • Transcode away, preferably with some manner of batch transcode process

Let’s see if it’s that easy.

This is the first time I have ever worked with x264. I decided to install from source. It has trouble finding and using the yasm assembler installed on the system. No matter, I’ll be patient for the test encodings. I finally got everything compiled together and figured out what options FFmpeg wanted (‘-acodec libfaac -vcodec libx264’) and I let it rip…

…and the whole thing blows up. Segfault down in the x264 library.

Between this and the MOOBEX exercise and the library problems on my little work project, I can’t help but take a dim view of multimedia support on Linux this week. Which is especially depressing since I sort of consider multimedia on Linux to be my beat.

Dog food sucks. But on the plus side, Robert finished committing AAC-LC decoding support to FFmpeg.

YASM Active

Thanks to Loren Merritt for restructuring FFmpeg’s build system to use YASM and for submitting and relicensing a number of ASM optimizations compilable with YASM. The idea is that if you have YASM installed (x86_32 or x86_64), FFmpeg’s configure script will notice it and automatically compile in the new optimizations. I just installed the assembler on both the x86_32 and x86_64 FATE build machines.

Hope it works, and that it’s faster than before. I look forward to assessing how it improves performance on certain H.264 conformance vectors, particularly monsters like MV1_BRCM_D. From the associated README file:

“Check that the decoder handles the worse case of prediction bandwidth. Prediction bandwidth is at maximum due to largest number of motion vectors (in 1/4 pel position) per macroblock pair (32 as defined in standard). Non-integer position motion vectors require using 6-tap filter always.”

I’m not sure what all of that means. I just know that it takes a long time to decode on the FATE machines.

Introducing MOOBEX

I was sitting at The Linux Foundation’s Collaboration Summit last April in Austin, Texas, USA pondering the state of multimedia usability on Linux. I realized that I live a somewhat sheltered computing existence vis-à-vis consuming multimedia because I happen to know a little bit more about it than most users. Then I got to wondering what the typical uninitiated user experiences when trying to play multimedia in Linux these days.

That’s the moment when I conceived MOOBEX: Multimedia Out-Of-Box EXperience. (Initially, I called it MOOB. But I wisely googled to see if that already had some meaning attached to it. I’m glad I did, and I’ll leave it to the reader to learn about the colloquial connotations of that word if they feel so inclined.)

For MOOBEX, I raided my vast personal multimedia archive and assembled a small suite of what I consider to be representative multimedia types. Then I developed a strict process for testing the multimedia capabilities of various stock Linux distributions from the perspective of a new Linux user. I tested the latest versions of 5 Linux distributions for the first pass at this. These include (x86_32 in all cases):

Fairness (and general curiosity) dictates that I give equal treatment to non-Linux operating systems. Thus, this initial pass also covers:

Executive Summary: Mandriva is absolutely remarkable with its out-of-the-box multimedia capability. Ubuntu is almost as good– while it isn’t too capable out of the box, it does a fine job of holding the user’s hand while installing required multimedia software on demand. The custom Xandros install on the Eee PC is also very good, albeit with a few holes. OpenSUSE isn’t too capable. Fedora Core’s multimedia support is deplorable and stultifyingly patronizing to boot (but, to be fair, somewhat improved from 2 years ago).

Apple’s and Microsoft’s operating systems perform as expected, able to play their respective company’s technologies perfectly out of the box but not being able to deviate from that, save for Adobe Flash.

I will have more analyses and opinions about my findings soon. In the meantime, the raw data is available in the MultimediaWiki. Also, be advised: No one can play an AIFF file anymore (except Apple). Maybe I’m the only person who finds this surprising; AIFF files weren’t that uncommon, were they?

Just as I was finishing this first round of reports, I realized that I named one sample girls-just-wanna-cook.rm. Wow, that could get me in trouble. I took the FUN_RM_32.rm sample from the samples archive — a 15-second sample of Cyndi Lauper’s timeless “Girls Just Wanna Have Fun” and renamed it to denote that it uses the RealAudio Cooker ‘COOK’ codec. Oops. Well, I’m not changing all those reports now.