fdk-aac encoder

[Dukers]

People posted some time ago feature request for fdk-aac inclusion. At that time, it was rejected (couldn't find the thread ).

Now I see fdk-aac included in SVN. What's changed? Will we have finally a good AAC encoder on non-Mac plataforms?

Thanks!

[s55]

It was rejected due to licensing issues, but since those issues are less severe than those with faac it makes sense as a stop gap measure to something better. ffmpeg's aac encoder is taking a while so this gives folks doing unofficial builds an option instead of just dropping aac support.

It's a compile time option. Not enabled on the nightly builds currently.

AS for it being "good ". Most users are not likely to hear any difference.

[moneymatt4life]

i guess i'm going to have to wait until it's implemented in the GUI because whenever i use --enable-fdk-aac from the cmd it doesn't do anything... i keep getting an "unknown option" error... i don't know if i'm doing something wrong or what... but i'm interested to test this out though...

[Rodeo]

--enable-fdk-aac is a compile-time switch, not a CLI option.

[moneymatt4life]

lol figured i'd be doing something wrong (^o^)

[Dukers]

Well, that's good news.

If the licensing issues are less severe than FAAC, which is enabled by default today, may I presume next HB will have fdk-aac by default too?

By "good" I mean an AAC encoder capable of delivering aceptable quality at 128 kbps (or maybe at 96 kbps). FAAC/FFAAC can't do that.

[Rodeo]

We'll see. One thing that is certain is that we'll get rid of faac eventually (though perhaps not in the next release).

[moneymatt4life]

any sort-of ETA as to when us non-tech-savvy users can start using this??? cuz i'd like to see how it fares to some of my videos where faac sorta fails to output the specified bitrate (^^',)...

[moneymatt4life]

so yay fdk-aac is finally in the nightly (cli at least (^^',)) and i was wondering if that fdk-aac issue would passover to handbrake... which it did...
fdk-aac is weird where the maximum automatic lowpass filter from 192kbps-320kbps stays at 17kHz whereas the 128 and 160 have appropriate auto lowpass filters (i'm guessing?) and the only way to fix it was to manually input the lowpass frequency... will there be any way to correct this issue? cuz the lowpass for 256kbps should be at least 20kHz (as i have a few ts files recorded where the aac audio is 256kbps and their lowpass is just slightly above 20kHz, even though i'm uncertain of which aac encoder was used for them)

here's my log for 192kbps... as using 256 or 320 looks no different... even though i'm fairly sure this isn't a handbrake issue, figured i'd post the log anyways... *took me a while to figure out how to copy from the cli (^^',)

Code: Select all

C:\Users\Mathew>handbrakecli.exe -i "D:\Kira Kira.vob" -o "D:\Videos\Handbrake\K
ira Kira-20fdkaac192.m4v" --strict-anamorphic -e x264 -q 20 --vfr -a 1 -E fdk_aa
c -6 stereo -R 48 -B 192 -x b-adapt=2:direct=auto --verbose=2
[15:27:24] hb_init: starting libhb thread
[15:27:24] thread 31d060 started ("libhb")
HandBrake svn5590 (2013061601) - MinGW x86_64 - http://handbrake.fr
4 CPUs detected
Opening D:\Kira Kira.vob...
[15:27:24] hb_scan: path=D:\Kira Kira.vob, title_index=1
[15:27:24] thread 31d200 started ("scan")
libbluray/bdnav/index_parse.c:162: indx_parse(): error opening D:\Kira Kira.vob/
BDMV/index.bdmv
libbluray/bdnav/index_parse.c:162: indx_parse(): error opening D:\Kira Kira.vob/
BDMV/BACKUP/index.bdmv
libbluray/bluray.c:1725: nav_get_title_list(D:\Kira Kira.vob) failed (0000000000
31DD80)
[15:27:24] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 4.1.3
libdvdread: Using libdvdcss version 1.2.11 for DVD access
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[15:27:24] dvd: not a dvd - trying as a stream/file instead
[15:27:24] file is MPEG Program Stream
[15:27:24] Probing 1 unknown stream
[15:27:24]     Probe: Found stream mpeg2video. stream id 0xe0-0x0
[15:27:24] Found the following streams
[15:27:24]     Video Streams :
[15:27:24]       0xe0-0x0 type MPEG2 (0x2)
[15:27:24]     Audio Streams :
[15:27:24]       0xbd-0xa0 type LPCM (0x83)
[15:27:24]     Subtitle Streams :
[15:27:24]     Other Streams :
[15:27:24] stream id 0xbd (type 0x83 substream 0xa0) audio 0xa000bd
[15:27:24] scan: decoding previews for title 1
[15:27:24] scan: preview 1
[15:27:24] fifo_close: trashing 0 buffer(s)
[15:27:24] scan: audio 0xa000bd: LPCM, rate=48000Hz, bitrate=1536000 Unknown (LP
CM) (2.0 ch)
[15:27:24] scan: preview 2
[15:27:24] scan: preview 3
[15:27:24] scan: preview 4
[15:27:24] scan: preview 5
[15:27:24] scan: preview 6
[15:27:24] scan: preview 7
[15:27:24] scan: preview 8
[15:27:24] scan: preview 9
[15:27:24] scan: preview 10
Scanning title 1 of 1, preview 10, 100.00 %[15:27:24] scan: 10 previews, 720x480
, 29.970 fps, autocrop = 2/0/0/0, aspect 16:9, PAR 32:27
[15:27:24] stream: 59 good frames, 0 errors (0%)
[15:27:24] thread 31d200 exited ("scan")
[15:27:24] thread 31d200 joined ("scan")
[15:27:24] libhb: scan thread found 1 valid title(s)
+ title 1:
  + stream: D:\Kira Kira.vob
  + duration: 00:04:22
  + size: 720x480, pixel aspect: 32/27, display aspect: 1.78, 29.970 fps
  + autocrop: 2/0/0/0
  + chapters:
    + 1: cells 0->0, 0 blocks, duration 00:04:22
  + audio tracks:
    + 1, Unknown (LPCM) (2.0 ch) (iso639-2: und)
  + subtitle tracks:
[15:27:24] thread 31d200 started ("work")
[15:27:24] 1 job(s) to process
[15:27:24] starting job
[15:27:24] sync: expecting 7860 video frames
[15:27:24] job configuration:
[15:27:24]  * source
[15:27:24]    + D:\Kira Kira.vob
[15:27:24]    + title 1, chapter(s) 1 to 1
[15:27:24]  * destination
[15:27:24]    + D:\Videos\Handbrake\Kira Kira-20fdkaac192.m4v
[15:27:24]    + container: MPEG-4 (mp4v2)
[15:27:24]  * video track
[15:27:24]    + decoder: mpeg2
[15:27:24]      + bitrate 9800 kbps
[15:27:24]    + filters
[15:27:24]      + Framerate Shaper (0:27000000:900900)
[15:27:24]        + frame rate: same as source (around 29.970 fps)
[15:27:24]      + Crop and Scale (720:478:2:0:0:0)
[15:27:24]        + source: 720 * 480, crop (2/0/0/0): 720 * 478, scale: 720 * 4
78
[15:27:24]    + strict anamorphic
[15:27:24]      + storage dimensions: 720 * 478, mod 0
[15:27:24]      + pixel aspect ratio: 32 / 27
[15:27:24]      + display dimensions: 853 * 478
[15:27:24]    + encoder: H.264 (x264)
[15:27:24]      + options: b-adapt=2:direct=auto
[15:27:24]      + quality: 20.00 (RF)
[15:27:24]  * audio track 1
[15:27:24]    + decoder: Unknown (LPCM) (2.0 ch) (track 1, id 0xa000bd)
[15:27:24]      + bitrate: 1536 kbps, samplerate: 48000 Hz
[15:27:24]    + mixdown: Stereo
[15:27:24]    + dither: triangular
[15:27:24]    + encoder: AAC (FDK)
[15:27:24]      + bitrate: 192 kbps, samplerate: 48000 Hz
[15:27:24] file is MPEG Program Stream
[15:27:24] Probing 1 unknown stream
[15:27:24]     Probe: Found stream mpeg2video. stream id 0xe0-0x0
[15:27:24] thread 326cd0 started ("Reader")
[15:27:24] reader: first SCR 146 id 0xe0 DTS 22254
[15:27:24] thread 326e70 started ("Framerate Shaper")
[15:27:24] thread 327430 started ("Crop and Scale")
[15:27:24] thread 3279f0 started ("AudioSynchronization")
[15:27:24] thread 31f520 started ("MPEG-2 decoder (libmpeg2)")
[15:27:24] encx264: min-keyint: 30, keyint: 300
[15:27:24] encx264: encoding with stored aspect 32/27
[15:27:24] encx264: Encoding at constant RF 20.000000
[15:27:24] encx264: opening libx264 (pass 0)
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
[15:27:24] mpeg2: "Chapter 1" (1) at frame 0 time 3003
x264 [info]: using SAR=32/27
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 3.0
[15:27:24] thread 5a831b0 started ("H.264/AVC encoder (libx264)")
[15:27:24] thread 7f1ce10 started ("LPCM decoder")
[15:27:24] thread 7ffe7b0 started ("AVCodec Audio encoder (libavcodec)")
[15:27:24] thread 7ffe980 started ("Video Synchronization")
[15:27:24] sync: first pts is 3003
[15:27:24] muxmp4: track 0, chunk duration 12012
[15:27:24] muxmp4: track 1, chunk duration 6407
[15:27:24] thread 7ffee60 started ("Muxer")
Encoding: task 1 of 1, 100.00 %[15:31:25] reader: done. 1 scr changes01s)
[15:31:25] thread 326cd0 exited ("Reader")
Encoding: task 1 of 1, 100.00 %[15:31:26] work: average encoding speed for job i
s 33.086098 fps
Encoding: task 1 of 1, 100.00 %[15:31:26] thread 5a831b0 exited ("H.264/AVC enco
der (libx264)")
Encoding: task 1 of 1, 100.00 %[15:31:26] thread 31f520 exited ("MPEG-2 decoder
(libmpeg2)")
[15:31:26] thread 7f1ce10 exited ("LPCM decoder")
[15:31:26] thread 7ffe980 exited ("Video Synchronization")
[15:31:26] thread 7ffe980 joined ("Video Synchronization")
[15:31:26] sync: got 7978 frames, 7860 expected
Encoding: task 1 of 1, 100.00 %[15:31:26] thread 3279f0 exited ("AudioSynchroniz
ation")
[15:31:26] thread 7ffee60 exited ("Muxer")
[15:31:26] thread 7ffe7b0 exited ("AVCodec Audio encoder (libavcodec)")
Encoding: task 1 of 1, 100.00 %[15:31:27] thread 326e70 exited ("Framerate Shape
r")
[15:31:27] thread 326e70 joined ("Framerate Shaper")
[15:31:27] render: lost time: 0 (0 frames)
[15:31:27] render: gained time: 0 (0 frames) (0 not accounted for)
[15:31:27] fifo_close: trashing 0 buffer(s)
Encoding: task 1 of 1, 100.00 %[15:31:27] thread 327430 exited ("Crop and Scale"
)
[15:31:27] thread 327430 joined ("Crop and Scale")
[15:31:27] thread 3279f0 joined ("AudioSynchronization")
[15:31:27] thread 31f520 joined ("MPEG-2 decoder (libmpeg2)")
[15:31:27] mpeg2 done: 7978 frames
[15:31:27] thread 5a831b0 joined ("H.264/AVC encoder (libx264)")
x264 [info]: frame I:154   Avg QP:19.06  size: 32138  PSNR Mean Y:44.95 U:47.37
V:46.71 Avg:45.53 Global:44.98
x264 [info]: frame P:2614  Avg QP:22.23  size: 16121  PSNR Mean Y:42.63 U:45.46
V:44.66 Avg:43.27 Global:42.11
x264 [info]: frame B:5210  Avg QP:24.68  size:  7306  PSNR Mean Y:41.65 U:45.05
V:44.04 Avg:42.38 Global:41.01
x264 [info]: consecutive B-frames:  5.1% 13.6% 29.2% 52.0%
x264 [info]: mb I  I16..4: 17.3% 53.3% 29.4%
x264 [info]: mb P  I16..4:  6.3% 19.6%  6.8%  P16..4: 27.1% 13.4%  7.7%  0.0%  0
.0%    skip:19.1%
x264 [info]: mb B  I16..4:  0.8%  2.6%  1.3%  B16..8: 28.2%  8.1%  3.1%  direct:
 9.2%  skip:46.8%  L0:38.9% L1:44.6% BI:16.4%
x264 [info]: 8x8 transform intra:58.3% inter:69.8%
x264 [info]: direct mvs  spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 66.3% 82.1% 56.8% inter: 24.5% 26.9% 8.0%
x264 [info]: i16 v,h,dc,p: 44% 27%  5% 24%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 15% 16%  6%  7% 10%  6%  9%  7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 19% 13%  5%  6%  8%  5%  6%  5%
x264 [info]: i8c dc,h,v,p: 40% 21% 29% 11%
x264 [info]: Weighted P-Frames: Y:5.0% UV:4.5%
x264 [info]: ref P L0: 58.5% 15.4% 16.9%  9.0%  0.2%
x264 [info]: ref B L0: 86.5%  9.8%  3.7%
x264 [info]: ref B L1: 96.5%  3.5%
x264 [info]: SSIM Mean Y:0.9810040 (17.213db)
x264 [info]: PSNR Mean Y:42.036 U:45.228 V:44.295 Avg:42.730 Global:41.395 kb/s:
2559.07
[15:31:27] thread 7f1ce10 joined ("LPCM decoder")
[15:31:27] thread 7ffe7b0 joined ("AVCodec Audio encoder (libavcodec)")
[15:31:27] encavcodeca: closing libavcodec
[15:31:27] thread 7ffee60 joined ("Muxer")
[15:31:27] Writing Metadata to output file...
Muxing: this may take awhile...[15:31:27] mux: file size, 91701396 bytes
[15:31:27] mux: track 0, 7978 frames, 85147923 bytes, 2558.92 kbps, fifo 2048
[15:31:27] mux: track 1, 12468 frames, 6383617 bytes, 191.84 kbps, fifo 4096
[15:31:27] mux: overhead, 8.31 bytes per frame
[15:31:27] thread 326cd0 joined ("Reader")
[15:31:27] stream: 132283 good frames, 0 errors (0%)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] fifo_close: trashing 0 buffer(s)
[15:31:27] Freed 32 buffers of size 1024
[15:31:27] Freed 32 buffers of size 2048
[15:31:27] Freed 32 buffers of size 4096
[15:31:27] Freed 32 buffers of size 8192
[15:31:27] Freed 32 buffers of size 16384
[15:31:27] Freed 32 buffers of size 32768
[15:31:27] Freed 32 buffers of size 65536
[15:31:27] Freed 5 buffers of size 131072
[15:31:27] Freed 32 buffers of size 1048576
[15:31:27] Allocated 38502400 bytes of buffers on this pass and Freed 38371328 b
ytes, 131072 bytes leaked
[15:31:27] thread 31d200 exited ("work")
[15:31:27] thread 31d200 joined ("work")
[15:31:27] libhb: work result = 0

Encode done!
[15:31:27] thread 31d060 exited ("libhb")
[15:31:27] thread 31d060 joined ("libhb")

HandBrake has exited.

also... i was wondering, is there any specific reason as to why fdk-aac always applies dither? i thought one was to apply dither when going down to a lower bitdepth like 24->16/etc...
and i hope the vbr modes get supported sometime as well (^__^) cuz afaik fdk-aac is primarily cbr (^^',) and it would be nice to test it out with handbrake, as it's been awhile since i tested it with fdk-aac.exe...
also wondering if afterburner is enabled? i think i read on hyrdogenaudio that it's an improved quality mode or something like that... not entirely sure what it does tbh...

*wasn't entirely sure of where to post this so i just posted here...

[JohnAStebbins]

How are you determining what the low pass of your output is?

[Rodeo]

also... i was wondering, is there any specific reason as to why fdk-aac always applies dither? i thought one was to apply dither when going down to a lower bitdepth like 24->16/etc...

HandBrake decodes everything to the internal sample format (32-bit float), and there's currently no way to know what the original sample format actually is, so dither is always applied (FDK only accepts 16-bit signed integer input samples).

Eventually I'd like to improve things so that sample format conversion is only done when necessary (downmixing, volume change), but there are several changes required before this works.

[moneymatt4life]

How are you determining what the low pass of your output is?

i use Spek as it's the only "nice" one i found that works for many audio formats and supports analyzing audio from video files (i've only used it with vob/mp4, so not sure if it works with mkvs but it should?)

HandBrake decodes everything to the internal sample format (32-bit float), and there's currently no way to know what the original sample format actually is, so dither is always applied (FDK only accepts 16-bit signed integer input samples).

ohhh ok i gotcha now...

[JohnAStebbins]

i use Spek as it's the only "nice" one i found that works for many audio formats and supports analyzing audio from video files (i've only used it with vob/mp4, so not sure if it works with mkvs but it should?)

Cool. I just tested it. It does work with mkvs.

[JohnAStebbins]

So, I found the code responsible for this. Now I just need to figure out why they did this (because it is quite deliberate).

Code: Select all

typedef struct{
  INT chanBitRate;
  INT bandWidthMono;
  INT bandWidth2AndMoreChan;

} BANDWIDTH_TAB;

static const BANDWIDTH_TAB bandWidthTable[] = {
  {0,      3700,  5000},
  {12000,  5000,  6400},
  {20000,  6900,  9640},
  {28000,  9600, 13050},
  {40000, 12060, 14260},
  {56000, 13950, 15500},
  {72000, 14200, 16120},
  {96000, 17000, 17000},
  {576001,17000, 17000}
};

[moneymatt4life]

yeah it didn't make much sense to me when i first saw the spectros months ago... i'm too used to the coreaudio lowpass (even though i know that fraunhofer and coreaudio are pretty different(?right?)) so when i saw it i was like "why is it so low when the bitrate is fairly high? even the lowpass filter for fraunhofer mp3 (using iTunes, not sure if they modify it somewhat(?)) at 256 and 320 is ~22kHz so AAC should be MORE than able to have those lowpass as well"... which is fixable in the cli at least where you just put -w 22050 for example... but i have no idea how the fix would be in this case...

is there like, anyway to modify the code to fix it??? or can you not legally do that??? (^^',)

[musicvid]

fdk-aac, by all accounts, is a work in progress.
So if you want to get in on the ground floor with your suggestions, maybe be a hero, their developer and support site is here:
http://opencore-amr.sourceforge.net/

It seems slightly odd to be asking the Handbrake developers to "fix" something in the third party encoder.

[JohnAStebbins]

fdk-aac, by all accounts, is a work in progress.
So if you want to get in on the ground floor with your suggestions, maybe be a hero, their developer and support site is here:
http://opencore-amr.sourceforge.net/

It seems slightly odd to be asking the Handbrake developers to "fix" something in the third party encoder.

There is an API in fdk-aac to manually change the bandwidth. But libav does not expose this API.

So the options available to us are:
1. get openamr to fix it then update the version of fdk-aac we use.
2. patch fdk-aac to use higher bandwidth for higher bitrates. I already created and tested such a patch. Seems to work for the minimal amount of testing I did.
3. patch a new option into libav to allow us access to the fdk-aac API that modifies the bandwidth. Then add code to HandBrake to manually set this option when the bitrate is > X.

Option 2 is the simplest, but option 3 is the best in my opinion because it solves the problem *and* adds capability to libav.

[JohnAStebbins]

FYI, a few interesting facts.

I created a simple sweep audio sample that goes from 10hz to 20khz and encoded it with each of faac, libav aac, fdk aac, and fdk haac. Of all the encoders, libav aac reproduced this simple waveform the most accurately. faac was the worst by a very large margin. fdk aac had a weird spike of higher frequencies at around 8khz, but otherwise was as good as libav up to it's cutoff frequency at around 17khz. libav aac appears to either have no low pass filter or it's cutoff is above 20khz.

[moneymatt4life]

... what John said (^o^)
manually setting the lowpass is pretty much the only "fix" i know of, as i've only worked from the fdk_aac.exe (but i THOUGHT that with one of the vbr modes there wasn't a lowpass or something??? i dunno that was a LONG time ago... and i might redownload the auto build script from the qaac page to test that out again but i'm not so sure)
fraunhofer must have had SOME reason to make 17kHz the highest lowpass filter for bitrates above 192... cuz even setting the bitrate to 512 (i think that's the max it goes to) has the 17kHz (^o^) which... really makes no sense, to me at least...

regarding libav aac... from what i see, at 256 there is no lowpass filter used, but... i've already tested with 2 videos and the resulting audio is kinda distorted (at 256 at least)... which i didn't have with faac and fdk-aac (at 192) doesn't have that either... *but this isn't really the place to discuss that*

[JohnAStebbins]

regarding libav aac... from what i see, at 256 there is no lowpass filter used, but... i've already tested with 2 videos and the resulting audio is kinda distorted (at 256 at least)... which i didn't have with faac and fdk-aac (at 192) doesn't have that either... *but this isn't really the place to discuss that*

Were these libav aac tests recent? Along with the fdk-aac changes I also committed some bug fixes for libav aac. I'm just wondering if your tests were before or after these fixes went in.

[moneymatt4life]

Were these libav aac tests recent? Along with the fdk-aac changes I also committed some bug fixes for libav aac. I'm just wondering if your tests were before or after these fixes went in.

... used the latest nightly (svn5590) provided from the nighlies page (^^',) so probably before the new changes were implemented...

[JohnAStebbins]

5590 has all the aac improvements. so the libav aac problems you saw must still exist.

[moneymatt4life]

5590 has all the aac improvements. so the libav aac problems you saw must still exist.

... lol should i take it somewhere else then? like, bugs or windows forum? (^^',) or... is it something to take over to the libav people (**.)

but i guess once the fdk-aac lowpass issue is circumvented i won't have to worry about libav aac (^o^)

[Rodeo]

3. patch a new option into libav to allow us access to the fdk-aac API that modifies the bandwidth. Then add code to HandBrake to manually set this option when the bitrate is > X.

Can't we just set avctx->cutoff?

[musicvid]

I got around to encoding a Green Day piano cover with the FDK-AAC 320 Kbps option (SVN 5656), and I must say these experienced but aging ears are quite impressed. It's every bit as good as Nero AAC that I had been muxing with my Handbrake music vids, maybe even a bit cleaner in the high-mid range.

This one's a keeper, and will be my go-to for music vids. More tests to see how bad Youtube mangles it, but off to a good start!
Be patient, it may still be uploading:
https://dl.dropboxusercontent.com/u/205 ... eenday.mp4