I often note that I find things in binary packages that irritate me. Sometimes it’s too much nonsense compiled in so that installation of a small utility requires massive dependencies to install. This means not just a lot of extra stuff taking up hard drive space, it means more packages that get updated and other inconveniences.
Sometimes I also notice little things that make me go hmmm. Today I was playing around with mocp, a curses-based server-client music program. There’s not yet a package for *el6 so I compiled it myself. I thought I’d hit up all the right things so that it would stream and play all common music codecs. Everything seemed fine with mp3, ogg-vorbis, and even an ASX stream. Then I tried an AAC stream and found I had more work to do.
No big deal. I searched to find out what I was missing. I found a suggestion that I should build it –without-aac (overriding the internal AAC decoder) so that AAC would be handled by the ffmpeg plugin. I tried that and it didn’t work.
So I decided to double check my ffmpeg version, which was installed from rpmforge. While it had faad and faac support enabled, I found something else that seemed a bit weird.
I know, I know. It’ll still work on other CPUs but it’s optimized for Intel Atom. Why? I’m not using this on my dual thread netbook, it’s on a dual core laptop. It could’ve (should’ve?) been compiled with -mtune=generic.
It’s stuff like this that drives me nuts and makes me start recompiling things or install something that I can optimize for my own use if the packaging (indiscriminately!) includes optimizations that suit particular hardware rather than generic. I thought that was the idea of pre-packaging binaries: so they could be used by a wide variety of common users.
For what it’s worth, the spec says:
Description: FFmpeg is a very fast video and audio converter. It can also grab : from a live audio/video source. : The command line interface is designed to be intuitive, in the : sense that ffmpeg tries to figure out all the parameters, when : possible. You have usually to give only the target bitrate you : want. FFmpeg can also convert from any sample rate to any other, : and resize video on the fly with a high quality polyphase filter. : : Available rpmbuild rebuild options : : --without : lame vorbis theora faad faac gsm xvid x264 a52dec : altivec
So it has faad/faac enabled. Should’ve worked, no?
I checked version information against what I have on my older laptop running Sabayon (with dwm). No extra c flags noted in the ffmpeg -version output but I’ll double-check that tomorrow:
ffmpeg version 0.7.1, Copyright (c) 2000-2011 the FFmpeg developers built on Jun 30 2011 12:51:22 with gcc 4.5.2 configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib \ --mandir=/usr/share/man --enable-shared --cc=i686-pc-linux-gnu-gcc
I still didn’t get AAC working on m *el6 laptop with the ffmpeg-devel package from rpmforge, or even when disabling it and building against the -devel packages for faad/faac. I’ll mess with it again tomorrow.
By the way, with all the -devel packages installed and all the compiling I end up doing, I wonder why I don’t just install something that has the relevant headers (Slackware) or that I can optimize and set up the right way — my way — from the start (Gentoo). Days like this, I wonder if the multi-year support of the EL clones is really all it’s cracked up to be. In fairness, though, we’re talking about a third-party repository and not stuff in the base which seems to be put together with more care and diligence. Maybe my lesson is to build my own packages for things not provided in the CentOS/SL repositories; that would solve not only this kind of issue but conflicts when a third-party repository has a more recent version number of something provided in the base.