Add libfaac as a possible audio transcoding choice in profiles.xml

Tricky one this, because you cannot redistribute an FFmpeg binary with libfaac compiled in (it's non-GPL). However, it would be a very useful option for those power users who don't mind compiling or obtaining their own.

I'm assuming that at some point an AppleHTTP muxer will be included in FFmpeg, and at that point AAC transcoding will be needed to stream to iPhones and iPads. I'm trying to smooth the way as much as possible for when that happens.

From what I understand, the FFmpeg native AAC encoder is so bad as to be useless. I have tested that libfaac seems to have similar encode times to the Nero encoder (apparently the best one) so it's not particularly slow. The problem seems to be that any attempt to control the bitrate results in the encoder using a less efficient ABR mode (according to faac.exe's help). The other problem is that on the default settings FFmpeg erroneously reports that it is encoding at 64Kbps, when in fact it is encoding in VBR mode with a quantization setting of 100 (giving roughly 150Kbps). This is probably a little high so I found during listening tests of my own that q=85 was a better trade-off (around 128Kbps).

The transcoding syntax to convert say a DivX AVI for non-streamed playback on iPad would be:

//ffmpeg -i input.avi -acodec libfaac -aq 85 -ac 2 -vcodec copy output.mp4//

This works well - only a couple of minutes on my PC to convert a 30min TV programme. For live-streaming to iDevices we'll neet to use the mpegts container and then run it through the muxer to break it into chunks with a .m3u8 playlist which is parsed every few seconds for more chunk metadata.

For something I was doing at work recently I also noticed that libmp3lame doesn't use VBR unless you use the //-aq// setting in FFmpeg (it passes it to LAME as a -V value). Would you be able to expose -aq as a variable in profiles.xml since both of these encoders kind of need it?

Comments (5)