Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#1784 closed defect (fixed)

internal aac encoder fails with 5.1 input

Reported by: Roger Pack Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: aac
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no


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':
    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.

Attachments (3)

yo.raw.wav.gz (1.2 MB ) - added by Roger Pack 10 years ago.
input file
aac_codec0.diff (900 bytes ) - added by Roger Pack 10 years ago.
use -aac_coder 0 by default
0001-Fix-bug-1784-erasure-of-surround-channels.patch (2.1 KB ) - added by klaussfreire 9 years ago.
Patch that fixes this issue

Download all attachments as: .zip

Change History (16)

by Roger Pack, 10 years ago

Attachment: yo.raw.wav.gz added

input file

comment:1 by Carl Eugen Hoyos, 10 years ago

Component: undeterminedavcodec
Keywords: aac added
Resolution: worksforme
Status: newclosed
Version: unspecifiedgit-master

(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).

comment:2 by Roger Pack, 10 years ago

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

in reply to:  2 comment:3 by Carl Eugen Hoyos, 10 years ago

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).

by Roger Pack, 10 years ago

Attachment: aac_codec0.diff added

use -aac_coder 0 by default

comment:4 by Roger Pack, 10 years ago

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: also behave similarly. diff-patch attached, or would you prefer I send it to ffmpeg-devel?
Thanks for your help, and the work around.

in reply to:  4 comment:5 by Carl Eugen Hoyos, 10 years ago

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.

comment:6 by Roger Pack, 10 years ago

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:

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 (

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...

Last edited 10 years ago by Roger Pack (previous) (diff)

comment:7 by Roger Pack, 10 years ago

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?

comment:8 by Carl Eugen Hoyos, 10 years ago

Priority: normalwish
Resolution: worksforme
Status: closedreopened
Type: defectenhancement

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?

comment:9 by klaussfreire, 9 years ago

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.

Last edited 9 years ago by klaussfreire (previous) (diff)

by klaussfreire, 9 years ago

Patch that fixes this issue

comment:10 by klaussfreire, 9 years ago

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.

comment:11 by Michael Niedermayer, 9 years ago

Reproduced by developer: set
Resolution: fixed
Status: reopenedclosed

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


comment:12 by Carl Eugen Hoyos, 9 years ago

Priority: wishnormal
Type: enhancementdefect

comment:13 by klaussfreire, 9 years ago

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

Note: See TracTickets for help on using tickets.