Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#6634 closed defect (fixed)

Regression when decoding aac

Reported by: Carl Eugen Hoyos Owned by:
Priority: important Component: avformat
Version: git-master Keywords: aac regression
Cc: epirat07@gmail.com Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: yes

Description

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

Attachments (5)

sample_cut.dump (236.4 KB ) - added by Carl Eugen Hoyos 5 years ago.
Absolute Jest - V Vi Vivacissimo Drestissimo_cut.aac (500.0 KB ) - added by Carl Eugen Hoyos 4 years ago.
Alto Consilio (Conductus) - Schola Cantorum Basiliensis_cut.aac (500.0 KB ) - added by Carl Eugen Hoyos 4 years ago.
Toccata E Fuga (Bwv 565)_cut.aac (500.0 KB ) - added by Carl Eugen Hoyos 4 years ago.
aac-denbosch.aac (1.8 MB ) - added by Carl Eugen Hoyos 3 years ago.

Change History (15)

by Carl Eugen Hoyos, 5 years ago

Attachment: sample_cut.dump added

comment:1 by James, 5 years ago

Analyzed by developer: set
Component: avcodecavformat
Reproduced by developer: set
Status: newopen

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.

comment:2 by Carl Eugen Hoyos, 5 years ago

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

in reply to:  2 ; comment:3 by James, 5 years ago

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.

in reply to:  3 ; comment:4 by Carl Eugen Hoyos, 5 years ago

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.

in reply to:  4 comment:5 by James, 5 years ago

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.

comment:6 by Carl Eugen Hoyos, 5 years ago

Another sample is attached to ticket #6900.

by Carl Eugen Hoyos, 4 years ago

comment:7 by Carl Eugen Hoyos, 4 years ago

by Carl Eugen Hoyos, 3 years ago

Attachment: aac-denbosch.aac added

comment:8 by ePirat, 3 years ago

Cc: epirat07@gmail.com added

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)

comment:9 by James, 3 years ago

Resolution: fixed
Status: openclosed

comment:10 by max79, 3 years ago

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

Last edited 3 years ago by max79 (previous) (diff)
Note: See TracTickets for help on using tickets.