[FFmpeg-trac] #9433(undetermined:open): FFmpeg fails to decode AAC with embedded tags
FFmpeg
trac at avcodec.org
Tue Sep 28 01:35:31 EEST 2021
#9433: FFmpeg fails to decode AAC with embedded tags
-------------------------------------+-------------------------------------
Reporter: shirt | Owner: (none)
Type: defect | Status: open
Priority: normal | Component:
| undetermined
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by 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.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9433#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list