[FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found

James Almer jamrial at gmail.com
Tue Sep 5 22:53:28 EEST 2017


On 9/5/2017 3:52 PM, Marton Balint wrote:
> 
> On Sun, 3 Sep 2017, James Almer wrote:
> 
>> Skip the invalid data in an attempt to find one instead, and continue
>> decoding from there.
>>
>> Fixes ticket #6634
> 
> If you skipped some broken ADTS frames, which were previously reported
> errnous, then can you signal that somehow? (E.g. by setting
> AVFrame->decode_error_flags on the next frame, or adding
> AV_FRAME_FLAG_CORRUPT flag to the next returned frame?)

The entire point of the custom packet reading function instead of using
the raw one was to avoid propagating any kind of data that's not an ADTS
frame. This could for example be an id3v1 or APE tag at the end.
fate-adts-id3v1-demux tests this (The demuxer skips both garbage at the
beginning of the file and the id3v1 tag at the end).

If a file has an incomplete ADTS frame but with an intact header we
afaics have no way to know it from the demuxer side. We read the amount
of bytes the ADTS header reports and propagate it inside a packet.
By the time the demuxer tries to read the next frame, if it finds out
there's no ADTS header right after the reported end of the previous
frame then the only thing it can do is bail out, or skip data until EOF
or an ADTS header shows up.
Before this patch, the former behavior is what happens. After this patch
the demuxer will skip data until either EOF, an arbitrary amount of
bytes were read, or an ADTS header shows up.


More information about the ffmpeg-devel mailing list