Opened 12 years ago

Closed 12 years ago

Last modified 12 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

Description

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.

Attachments (3)

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

Download all attachments as: .zip

Change History (16)

by Roger Pack, 12 years ago

Attachment: yo.raw.wav.gz added

input file

comment:1 by Carl Eugen Hoyos, 12 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, 12 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, 12 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, 12 years ago

Attachment: aac_codec0.diff added

use -aac_coder 0 by default

comment:4 by Roger Pack, 12 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: 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.

in reply to:  4 comment:5 by Carl Eugen Hoyos, 12 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, 12 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:
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-

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

comment:7 by Roger Pack, 12 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, 12 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, 12 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.

Version 0, edited 12 years ago by klaussfreire (next)

by klaussfreire, 12 years ago

Patch that fixes this issue

comment:10 by klaussfreire, 12 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, 12 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)

Thanks!

comment:12 by Carl Eugen Hoyos, 12 years ago

Priority: wishnormal
Type: enhancementdefect

comment:13 by klaussfreire, 12 years ago

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

Note: See TracTickets for help on using tickets.