#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/[email protected]/
.
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_______________________________________________
FFmpeg-trac mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
