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.
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.
I sincerely had a lots of problems doing transcoding to MP4[H.264+AAC] myself, with FFmpeg or MEncoder. MEncoder produces the right video stream, FFmpeg (almost) the right container, but neither can seem to produce a fully good file. With “right” I mean, for the video stream, being of a quality near enough the original, with a similar filesize, and for the container, to play on at least three of my systems (xine, QuickTime/iTunes, AppleTV).
I ended up paying for a frontend to get my files encoded in a decent way. I have no clue what they are doing behind the scenes to make it work, but they certainly saved me from having to spend time figuring out the right components at the right version.
I’m afraid this might well be a problem with FFmpeg and x264 release schedules (hint: there are none).
Mike: I don’t know if you noted but you need recent yasm (0.7.x) to compile x264.
Also, I can offer advice regarding x264 encoding options in FFmpeg through the guides on my website. I didn’t write them for nothing…
Combine the FFmpeg x264 encoding guide (which tells you how to match the defaults with the x264 CLI) with the option mapping from the x264 to FFmpeg CLI on there and the non-bold x264 CLI settings lists from here: http://forum.doom9.org/showthread.php?p=1072386#post1072386 . Those should achieve you some good speed/quality tradeoffs.
Else you could try the presets I wrote: http://rob.opendot.cl/index.php/2008/07/23/lc-aac-and-sbr-amr-nb-floating-point-presets/
Thanks for the tips. This is surely only the beginning of the journey.
BTW, Rob, your preset files are 404.