internal aac encoder fails with 5.1 input

[rogerdpack]

Summary of the bug: with 5.1 audio input, the internal aac encoder seems to produce "garbled" output

How to reproduce:

%ffmpeg-20120903-git-5d55830-win32-static\bin\ffmpeg -i yo.raw.wav  -acodec aac -strict experimental -ac 6 -ab 384k -y yo.aac
ffmpeg version N-44123-g5d55830 Copyright (c) 2000-2012 the FFmpeg developers
  built on Sep  2 2012 20:23:29 with gcc 4.7.1 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      51. 70.100 / 51. 70.100
  libavcodec     54. 55.100 / 54. 55.100
  libavformat    54. 25.104 / 54. 25.104
  libavdevice    54.  2.100 / 54.  2.100
  libavfilter     3. 15.102 /  3. 15.102
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 15.100 /  0. 15.100
  libpostproc    52.  0.100 / 52.  0.100
[wav @ 01f3c720] max_analyze_duration 5000000 reached at 5001333
Input #0, wav, from 'yo.raw.wav':
  Duration: 00:00:14.43, bitrate: 4608 kb/s
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 5.1, s16, 4608 kb/s
Output #0, adts, to 'yo.aac':
  Metadata:
    encoder         : Lavf54.25.104
    Stream #0:0: Audio: aac, 48000 Hz, 5.1, flt, 384 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le -> aac)
Press [q] to stop, [?] for help
size=     277kB time=00:00:14.44 bitrate= 157.4kbits/s
video:0kB audio:273kB subtitle:0 global headers:0kB muxing overhead 1.697209%

The resultant aac file has seemingly lost "most" channels. Encoding the same with libfdk_aac seems to work fine with all 6 channels.

[rogerdpack]

input file

[cehoyos]

(This used to be a regression in 2011, never reported on trac afaict.)

You can use -aac_coder 0 to encode this sample in a better way. I suspect that for real-world samples, the results would be different (but I also only tested artificial samples).

If you believe that coder 0 should be default (I don't know), consider sending a patch (line 808 in libavcodec/aacenc,c).

[rogerdpack]

so, just for reference, if you don't use -aac_coder 0 you get bad output too, is that right?

[cehoyos]

Replying to rogerdpack:

so, just for reference, if you don't use -aac_coder 0 you get bad output too, is that right?

As said, I found the same problem - that is a regression - approximately a year ago (also testing an artificial sample), as a result -aac_coder 0 was added, and since it is not default, I suspect that the problem is not reproducible with a real-world sample (but I never tested)-
If that is wrong (ie if you have a real-world sample that is encoded badly with the default coder regarding the surround channels), please share the sample (and test with -aac_coder 0 and / or provide a patch to make it default).

[rogerdpack]

use -aac_coder 0 by default

[rogerdpack]

Ok that makes sense. The initial attachment to this ticket is a "real-world" sample I was trying to convert that shows the poor behavior. And using -aac_coder 0 does seem to fix it (as a side-note, the effects channel seems to have slightly decreased volume after conversion, but at least now it has any data at all). The files from here:  http://www.jensign.com/bdp95/7dot1voiced/index.html also behave similarly. diff-patch attached, or would you prefer I send it to ffmpeg-devel?
Thanks for your help, and the work around.

[cehoyos]

Replying to rogerdpack:

or would you prefer I send it to ffmpeg-devel?

Only if you want that it gets committed;-)
Please either explain how the sample you attached was recorded (I have very strong doubts it is "real-world"), or - much better - test some 5.1 samples if -aac_coder 0 really improves encoding, and refer to the tested samples in your mail to ffmpeg-devel.

[rogerdpack]

I recorded it from a directshow "record what you hear" device, at 5.1. I also tested the samples from the link I previously posted, when I posted it. But that's not "real" real-world either, is it?

So here is using a more "real world" 5.1 test case:
 http://rogerdpack.t28.net/incoming/sintel.mpg

When used like this:

$ ffmpeg -i sintel.mpg -vn -acodec aac -strict experimental -ac 6 -ab 384k -t 30 sintel.mpg.aac_exp.aac

The result isn't "quite as bad" as with the small test samples (which lose something like 4 channels out of 5), however, it appears to still lose 3 channels out of 6.

running it like this:

$ ffmpeg -i sintel.mpg -vn -acodec aac -aac_coder 0 -strict experimental -ac 6 -ab 384k -t 30 sintel.mpg.aac_exp.acoder.aac

seems to get all 6 channels ( https://gist.github.com/3834919).

I'll report it on ffmpeg-devel, though I have no clue what aac_coder means or does, it helps at least these particular cases, so...
-roger-

[rogerdpack]

looks like -aac_coder 0 does provide output for all channels, but garbles the output (I didn't notice it before). Should this be reopened?

[cehoyos]

Do you think it worked better with an old version of FFmpeg, or does the old version produce the same bad quality as -aac_coder 0?

[klaussfreire]

Interesting. I just confirmed this still happens. I'm working on the AAC encoder, so I think I'll take a look at why this happens. While working on AAC's rate control, I noticed similar issues when too many bits are assigned to too loud signals, and it does look like this could be the case (the signal is really powerful). I already added lots of failsafes for this case (on a patch that I'll be sending soon), but it doesn't seem to cover this particular issue in the attached sample. So I'll keep looking.

PS: I believe the "too loud" somewhere induces NaNs?. They propagate very fast, hence the empty output.

[klaussfreire]

Patch that fixes this issue

[klaussfreire]

Attached is a patch that fixes this issue. It was caused by a silly miscalculation of the current channel, used when reading psy model data in the encoder.

[michael]

Patch applied (only the first 2 hunks as the 3rd seems to change something thats not in git master)

Thanks!

[klaussfreire]

Weird... just before making that patch, I did a "git reset HEAD".