#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: critical | Component: avcodec Version: 4.2 | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by LeadAssimilator): * Attachment "ffmpeg-20200131-060735.log" added. verify report -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: critical | Component: avcodec Version: 4.2 | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): Sample just completed upload. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: critical | Component: avcodec Version: 4.2 | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): This issue appears to affect only mingw cross-compiled ffmpeg builds such as those from https://ffmpeg.zeranoe.com/builds/ or made with https://github.com/rdp/ffmpeg-windows-build-helpers on Ubuntu. Native builds on nix with gcc or msvc on win do not appear to have this problem. I suspect a compiler issue with mingw and/or some related math problem. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: normal | Component: avcodec Version: unspecified | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): Replying to [comment:5 cehoyos]:

Is the issue you see reproducible with current FFmpeg git head, the only version supported here?

I did some quick tests with the zeranoe builds and the last working version was 3.4.2. All 4.x versions, including master/head are broken. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: normal | Component: avcodec Version: unspecified | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): What in my answer is difficult to parse exactly? 3.4.2 success 4.0.0 fail 4.0.1 fail 4.0.2 fail 4.1.0 fail 4.1.1 fail 4.1.3 fail 4.2.0 fail 4.2.1 fail 4.2.2 fail master/head fail The commandlines are already in both the description and the report files. And the output is there as well, albeit intermixed with the stuff that -report adds. I'm not sure why you encourage including them if you are just going to ignore them... The output w/o -report is this for the one sample I uploaded (I don't yet have an input sample to upload for the "invalid band type" error yet): {{{ ffmpeg.exe -i trac_8505_0_input.wav -b:a 192K output.aac ffmpeg version 4.2.2 Copyright (c) 2000-2019 the FFmpeg developers built with gcc 9.2.1 (GCC) 20200122 configuration: --disable-static --enable-shared --enable-gpl --enable- version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable- libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable- libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable- libopenmpt libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat 58. 29.100 / 58. 29.100 libavdevice 58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 libpostproc 55. 5.100 / 55. 5.100 Guessed Channel Layout for Input Stream #0.0 : stereo Input #0, wav, from 'trac_8505_0_input.wav': Duration: 00:00:42.43, bitrate: 2822 kb/s Stream #0:0: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 44100 Hz, stereo, flt, 2822 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_f32le (native) -> aac (native)) Press [q] to stop, [?] for help Output #0, adts, to 'output.aac': Metadata: encoder : Lavf58.29.100 Stream #0:0: Audio: aac (LC), 44100 Hz, stereo, fltp, 192 kb/s Metadata: encoder : Lavc58.54.100 aac size= 512kB time=00:00:35.92 bitrate= 116.8kbits/s speed=71.8x size= 870kB time=00:00:42.44 bitrate= 167.9kbits/s speed=67.9x video:0kB audio:858kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.457950% [aac @ 01664d80] Qavg: 10880.012 }}} {{{ ffmpeg.exe -i output.aac -f null -v error - [aac @ 02f51bc0] Number of bands (56) exceeds limit (44). Error while decoding stream #0:0: Invalid data found when processing input }}} And this would be a hell of a lot easier and less confusing if we could have the edit description grant for our own trac tickets...especially since I have to upload samples separately causing the names to mismatch what I originally specified. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:8> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: important | Component: avcodec Version: unspecified | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by LeadAssimilator): * keywords: aac => regression aac -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:10> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: important | Component: avcodec Version: unspecified | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): I'm not sure why that would be necessary - not only is that not indicated in the manual, that isn't even true for many of the tickets already reported and marked as a regression, which is the pattern I'm following. In practice, stating 3.4.2 is working and 4.0.0 and later are not, is more than sufficient for regression demarcation. If the exact commit was known, then I would have fixed the issue already not wasted my time gathering information, filing a bug and getting frustrated by this whole experience. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: important | Component: avcodec Version: unspecified | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): I don't remember, but they can be easily found if you look. If there is some policy regarding priorities and regression tags, then I suggest pointing me to it and enforcing it better. No, that makes me sad, but I'm trying to remain patient in light of the apparent language barrier through critical commentary and helpful suggestions. Any assistance in helping me keep my patience while I narrow down the faulty commit(s) would be much appreciated :) -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:14> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: fast aac encoder produces invalid output -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: important | Component: avcodec Version: unspecified | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): The regression in 4.x/master is related to this change fcb681ac3edd708f26c3b5014c06e32fd2723887 where the default coder was switched from twoloop to fast. So it appears the fast coder is broken for these crosscompiled windows builds. Now to find out why... -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:16> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: fast aac encoder produces invalid output for x86 32-bit builds -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: new Priority: important | Component: avcodec Version: unspecified | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by LeadAssimilator): There appears to be an issue in [http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/aacenc_quantizatio... quantize_and_encode_band_cost_template] where it attempts to encode an ESC sequence with too few bits. A minimum coefficient value of 16 is required for an ESC sequence, but the computed coefficient is only 15. Since the value 15 is too low, the required number of bits for the combined ESC sequence prefix bits and separator bit is also calculated too low at 0 (minimum is 1), along with an invalid value of -1. These erroneous values are then used in the call to put_bits which writes 0 bits to the output instead of the minimum required 1 bit. Similarly the number of bits for the sequence word is also under calculated at 3 bits, versus the minimum 4 bits. They again are used in the call to put_sbits with the too small coefficient 15, that writes 3 bits to the output instead of the minimum required 4 bits. As a result, the entire ESC sequence is only coded as 3 bits as opposed to the the shortest viable sequence of 5 bits and this corrupts the output bitstream. It seems that [http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/aacencdsp.asm;... ff_aac_quantize_bands_sse2] may be partially to blame. When used, it quantizes slightly differently than the non-sse2 version [http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/aacenc_utils.h;h=b... quantize_bands], producing larger values. This might not normally be an issue, but later calculations are done with the same inputs using a different function, [http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/aacenc_utils.h;h=b... quant], which yields different results during the writing of the ESC sequence. In this particular failure case, the input -56421.839844 (-0x1.b8cbaep+15) quantized to 16 via sse2, 15 via the non-sse2 variant quantize_bands (during a working run) and 15 via quant. This discrepancy explains why this issue affects only 32-bit x86 builds, however it can happen any time ff_aac_quantize_bands_sse2|quantize_bands produces values larger than quant for the same input and the resulting quant output is < 16. I see the following possible solutions: 1) Use the same exact quantization routines for all involved calculations (possible performance impacts) 2) Clamp the lower bound of the escape sequence coefficient to 16 It would be great if someone more familiar with the aac encoder or these kinds of issues weighs in and/or takes over. If no one is interested, I can take a stab at producing a patch. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:18> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: fast aac encoder produces invalid output for x86 32-bit builds -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: open Priority: important | Component: avcodec Version: git-master | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Lynne): I'm not exactly sure how to fix that. Clamping the escape sequence length is more of a hack, and getting rid of the SSE function would slow down the encoder by a non-negligible amount. What I don't get is how the results of the 2 quant functions diverge. Nothing should use x87 code now, even on 32 bit machines since its just unacceptably slow, so compilers just use SSE but don't use more than 1 element of a vector. I don't mind making the C quant version match the SSE version, though I don't really know how. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:20> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: fast aac encoder produces invalid output for x86 32-bit builds -------------------------------------+------------------------------------- Reporter: | Owner: LeadAssimilator | Type: defect | Status: open Priority: important | Component: avcodec Version: git-master | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Lynne): Would an SSE quant function fix the problem? It would have to be done in inline asm since the function overhead doesn't seem great. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:22> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: fast aac encoder produces invalid output for x86 32-bit builds -------------------------------------+------------------------------------- Reporter: | Owner: (none) LeadAssimilator | Type: defect | Status: open Priority: important | Component: avcodec Version: git-master | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): The default coder was switched from fast to twoloop. So bug is gone. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:24> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

#8505: fast aac encoder produces invalid output for x86 32-bit builds -------------------------------------+------------------------------------- Reporter: | Owner: (none) LeadAssimilator | Type: defect | Status: open Priority: important | Component: avcodec Version: git-master | Resolution: Keywords: regression | Blocked By: aac | Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Simon): I'm investigating a reproduction with: ffmpeg version N-66244-g468615f204-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2023 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --enable-gpl --enable-version3 --enable-static --disable- debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libfribidi --enable-libass --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo- amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable- libx265 --enable-libxml2 --enable-libxvid --enable-libzimg libavutil 58. 13.101 / 58. 13.101 libavcodec 60. 21.100 / 60. 21.100 libavformat 60. 9.100 / 60. 9.100 libavdevice 60. 2.100 / 60. 2.100 libavfilter 9. 8.102 / 9. 8.102 libswscale 7. 3.100 / 7. 3.100 libswresample 4. 11.100 / 4. 11.100 libpostproc 57. 2.100 / 57. 2.100 Hyper fast Audio and Video encoder (is N-66244-g468615f204-static this before or after the mentioned commit?) On a specific audio input, subsequent decode reliably produces : [aac @ 0xcba1d80] Number of bands (43) exceeds limit (41).ed=98.4x [aist#0:1/aac @ 0xcbcb800] Error submitting packet to decoder: Invalid data found when processing input Encode command: ./ffmpeg -i ./media/aacorg.mp4 -y -dn -vn ./media/aaconly.mp4 Decode command: ./ffmpeg -i ./media/aaconly.mp4 -f wav -vn -y /dev/null This version seems to not reproduce the issue: ffmpeg version 6.1-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2023 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --enable-gpl --enable-version3 --enable-static --disable- debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat 60. 16.100 / 60. 16.100 libavdevice 60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc 57. 3.100 / 57. 3.100 Hyper fast Audio and Video encoder I am also unable to reproduce with 7.0.2: ffmpeg version 7.0.2-static https://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2024 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --enable-gpl --enable-version3 --enable-static --disable- debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg libavutil 59. 8.100 / 59. 8.100 libavcodec 61. 3.100 / 61. 3.100 libavformat 61. 1.100 / 61. 1.100 libavdevice 61. 1.100 / 61. 1.100 libavfilter 10. 1.100 / 10. 1.100 libswscale 8. 1.100 / 8. 1.100 libswresample 5. 1.100 / 5. 1.100 libpostproc 58. 1.100 / 58. 1.100 Universal media converter However, if I use -ss to start the encoding from 1 hour into the audio (the issue occurs at ~01:47:14), the issues does not occur. If I transcode to mp3, and then encode, the issue does not occur. I can only reproduce from the original aac input (with or without video in the source mp4). So the issue is very hard to reproduce, so it's possible the mods MAY have just changed the parameters enough to hide it for now. unfortunately I don't have permission to share the complete source audio, and trying to trim it prevents the issue from occurring. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8505#comment:26> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker