#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)
Change History (15)
by , 7 years ago
Attachment: | sample_cut.dump added |
---|
comment:1 by , 7 years ago
Analyzed by developer: | set |
---|---|
Component: | avcodec → avformat |
Reproduced by developer: | set |
Status: | new → open |
follow-up: 3 comment:2 by , 7 years ago
What exactly does the commit fix? I cannot reproduce the original issue.
follow-up: 4 comment:3 by , 7 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.
follow-up: 5 comment:4 by , 7 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.
comment:5 by , 7 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.
by , 5 years ago
Attachment: | Absolute Jest - V Vi Vivacissimo Drestissimo_cut.aac added |
---|
by , 5 years ago
Attachment: | Alto Consilio (Conductus) - Schola Cantorum Basiliensis_cut.aac added |
---|
by , 5 years ago
Attachment: | Toccata E Fuga (Bwv 565)_cut.aac added |
---|
comment:7 by , 5 years ago
Three more real-world samples attached:
http://ffmpeg.org/pipermail/ffmpeg-user/2018-December/042508.html
by , 5 years ago
Attachment: | aac-denbosch.aac added |
---|
comment:8 by , 5 years ago
Cc: | 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 , 5 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
Should be fixed in 881e1f5a6227a6fbaf67083d4d4b6caf58ff9892
comment:10 by , 4 years ago
Thanks for the gift :) Issue now fixed. Happy Holidays guys, you are the best!
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.