Regression when decoding aac

[Carl Eugen Hoyos]

The sample from bug 1080 that is 20 seconds long only decodes for 2 seconds since 3d4026325381c1066d771bcb83e024c92ea7e189 related to ticket #6437.

$ ffmpeg -i sample_cut.dump -f null -
ffmpeg version N-87177-g69e6877 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (GCC)
  configuration: --enable-gpl
  libavutil      55. 74.100 / 55. 74.100
  libavcodec     57.104.101 / 57.104.101
  libavformat    57. 81.100 / 57. 81.100
  libavdevice    57.  8.100 / 57.  8.100
  libavfilter     6.101.100 /  6.101.100
  libswscale      4.  7.103 /  4.  7.103
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
[aac @ 0x3bab3c0] Estimating duration from bitrate, this may be inaccurate
Input #0, aac, from 'sample_cut.dump':
  Duration: 00:00:20.14, bitrate: 96 kb/s
    Stream #0:0: Audio: aac (HE-AAC), 48000 Hz, stereo, fltp, 96 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf57.81.100
    Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
    Metadata:
      encoder         : Lavc57.104.101 pcm_s16le
[aac @ 0x3bad040] Number of bands (56) exceeds limit (46).
Error while decoding stream #0:0: Invalid data found when processing input
sample_cut.dump: Invalid data found when processing input
size=N/A time=00:00:02.26 bitrate=N/A speed= 462x
video:0kB audio:424kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

[James]

This sample has several broken ADTS frames, and it's in the first of such frames where it's stopping right now. Half of said frame is present until some weird streaming header shows up and a new ADTS frame starts.
So this sample is just a raw dump of a glitchy stream stitched together.

Working around this would probably require reverting 3d4026325381c1066d771bcb83e024c92ea7e189, propagating data without bothering to check if it's a valid ADTS frame and once again leaving the work to the parser, reintroducing the behavior described in #6437

I don't know what's the best option here, of it there some alternative where we don't have to compromise.

[Carl Eugen Hoyos]

What exactly does the commit fix? I cannot reproduce the original issue.

[James]

Replying to cehoyos:

What exactly does the commit fix? I cannot reproduce the original issue.

Read the comments in that ticket. You can't reproduce the issue with the sample the user posted as it cut out the problematic data.

Revert the commit locally and run fate-adts-id3v1-demux to see the problem. The garbage at the beginning and the id3v1 tag at the end of the fate sample will be propagated to the decoder as if it was an audio frame.

[Carl Eugen Hoyos]

Replying to jamrial:

Replying to cehoyos:

What exactly does the commit fix? I cannot reproduce the original issue.

Read the comments in that ticket. You can't reproduce the issue with the sample the user posted as it cut out the problematic data.

(Unrelated to this ticket:)
Please upload the file that allows to reproduce.

[James]

Replying to cehoyos:

Replying to jamrial:

Replying to cehoyos:

What exactly does the commit fix? I cannot reproduce the original issue.

Read the comments in that ticket. You can't reproduce the issue with the sample the user posted as it cut out the problematic data.

(Unrelated to this ticket:)
Please upload the file that allows to reproduce.

aac/id3v1.aac from the FATE samples suite, used by fate-adts-id3v1-demux as i said before.

[Carl Eugen Hoyos]

Another sample is attached to ticket #6900.

[Carl Eugen Hoyos]

Three more real-world samples attached:
​http://ffmpeg.org/pipermail/ffmpeg-user/2018-December/042508.html

[ePirat]

Just want to point out that the regression caused breaks a frequently used technique for audio livestream fallbacks to other streams, which will produce desyncs as can be seen in the denbosch sample. (Found this only because apparently Chrome uses ffmpeg and some streams stopped playing fine there, same for mpv)

[James]

Should be fixed in 881e1f5a6227a6fbaf67083d4d4b6caf58ff9892

[max79]

Thanks for the gift :) Issue now fixed. Happy Holidays guys, you are the best!