FFmpeg fails to decode AAC with embedded tags

[shirt]

Summary of the bug: FFmpeg fails to decode AAC with embedded ID3v2 tags.
How to reproduce:
Use the attached aac file with ffmpeg. It works on ffmpeg 3.0.1 but fails on master. Also works after being processed with mkvmerge.

% ffmpeg -i test6000.aac -map 0:a -f null -
ffmpeg version git-2021-09-13-989febf-ffmpeg-windows-build-helpers Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 10.2.0 (GCC)
  configuration: --pkg-config=pkg-config --pkg-config-flags=--static --extra-version=ffmpeg-windows-build-helpers --enable-version3 --disable-debug --disable-w32threads --arch=x86_64 --target-os=mingw32 --cross-prefix=/home/runner/work/ffmpeg-autobuild/ffmpeg-autobuild/sandbox/cross_compilers/mingw-w64-x86_64/bin/x86_64-w64-mingw32- --enable-libcaca --enable-gray --enable-libtesseract --enable-fontconfig --enable-gmp --enable-gnutls --enable-libass --enable-libbluray --enable-libbs2b --enable-libflite --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libvorbis --enable-libwebp --enable-libzimg --enable-libzvbi --enable-libmysofa --enable-libopenjpeg --enable-libopenh264 --enable-liblensfun --enable-libvmaf --enable-libsrt --enable-libxml2 --enable-opengl --enable-libdav1d --enable-cuda-llvm --enable-libsvthevc --enable-libsvtav1 --enable-libaom --enable-libvpx --enable-nvenc --enable-nvdec --extra-libs=-lharfbuzz --extra-libs=-lm --extra-libs=-lpthread --extra-cflags=-DLIBTWOLAME_STATIC --extra-cflags=-DMODPLUG_STATIC --extra-cflags=-DCACA_STATIC --enable-amf --enable-libmfx --enable-gpl --enable-frei0r --enable-librubberband --enable-libvidstab --enable-libx264 --enable-libx265 --enable-avisynth --enable-libaribb24 --enable-libxvid --enable-libdavs2 --enable-libxavs2 --enable-libxavs --extra-cflags='-mtune=generic' --extra-cflags=-O3 --enable-static --disable-shared --prefix=/home/runner/work/ffmpeg-autobuild/ffmpeg-autobuild/ffmpeg-source --enable-nonfree --enable-libfdk-aac --enable-decklink
  libavutil      57.  5.100 / 57.  5.100
  libavcodec     59.  7.103 / 59.  7.103
  libavformat    59.  5.100 / 59.  5.100
  libavdevice    59.  0.101 / 59.  0.101
  libavfilter     8.  9.100 /  8.  9.100
  libswscale      6.  1.100 /  6.  1.100
  libswresample   4.  0.100 /  4.  0.100
  libpostproc    56.  0.100 / 56.  0.100
[aac @ 000001b5e6f283c0] Estimating duration from bitrate, this may be inaccurate
Input #0, aac, from 'test6000.aac':
  Metadata:
    id3v2_priv.com.apple.streaming.transportStreamTimestamp: \x00\x00\x00\x00\x00\x00\x00<
  Duration: 00:53:06.53, bitrate: 102 kb/s
  Stream #0:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 102 kb/s
  Stream #0:1: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 576x432 [SAR 72:72 DAR 4:3], 90k tbr, 90k tbn (attached pic)
    Metadata:
      comment         : Movie/video screen capture
Stream mapping:
  Stream #0:0 -> #0:0 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    id3v2_priv.com.apple.streaming.transportStreamTimestamp: \x00\x00\x00\x00\x00\x00\x00<
    encoder         : Lavf59.5.100
  Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
    Metadata:
      encoder         : Lavc59.7.103 pcm_s16le
test6000.aac: Invalid data found when processing input
size=N/A time=00:05:40.35 bitrate=N/A speed=1.1e+03x
video:0kB audio:63816kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

Test file: ​https://cdn.discordapp.com/attachments/807246463808700487/890004176166338560/test6000.aac

[Balling]

Yet ffplay does work...

[jeeb]

This seems to be a concatenated stream from a set of HLS segments.

A patch: ​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210927213133.28258-1-jeebjp@gmail.com/ .

It would be very lovely if someone could figure out what those occasional padding bytes are and if they should even exist when such a raw ADTS stream is concatenated during ripping/dumping. As currently enabling resync to work just means that:

1. The ADTS reader is able to proceed (in other words, parsing of the audio bits of the ADTS stream should work).
2. You are most likely losing all of the following ID3 metadata as the resync will skip until the next valid ADTS start code.

So if the padding is not supposed to be there when the stream is ripped and concatenated, then the ripping application should be fixed to not have this stuff. Otherwise if there is a specification for this stuff, that should be noted so that proper improvements can be made if necessary.

In this sample it looks like this:

[ADTS packet]
[0x0b .... or so padding]
[ID3 magic]

Previously it would fail at the second set of 0x0bs, at offset 5053141 as that is more than the default probesize of 5000000.

[jeeb]

Resync enabled past probesize (and thus this issue fixed) with c20577806f0a161c6867e72f884d020a253de10a .

As for what that padding was, looking at ​https://github.com/yt-dlp/yt-dlp/commit/7687c8ac6e223a725b3ef8f56f04779bebdc86c5 it probably was padding for PKCS#7 encryption. And thus it should not have been included in the resulting data :) .