#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)
Change History (16)
by , 12 years ago
Attachment: | yo.raw.wav.gz added |
---|
comment:1 by , 12 years ago
Component: | undetermined → avcodec |
---|---|
Keywords: | aac added |
Resolution: | → worksforme |
Status: | new → closed |
Version: | unspecified → git-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).
follow-up: 3 comment:2 by , 12 years ago
so, just for reference, if you don't use -aac_coder 0 you get bad output too, is that right?
comment:3 by , 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).
follow-up: 5 comment:4 by , 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.
comment:5 by , 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 , 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.
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-
comment:7 by , 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 , 12 years ago
Priority: | normal → wish |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
Type: | defect → enhancement |
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 , 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.
PS: I believe the "too loud" somewhere induces NaNs. They propagate very fast, hence the empty output.
by , 12 years ago
Attachment: | 0001-Fix-bug-1784-erasure-of-surround-channels.patch added |
---|
Patch that fixes this issue
comment:10 by , 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 , 12 years ago
Reproduced by developer: | set |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
Patch applied (only the first 2 hunks as the 3rd seems to change something thats not in git master)
Thanks!
comment:12 by , 12 years ago
Priority: | wish → normal |
---|---|
Type: | enhancement → defect |
input file