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

Marton Balint cus at passwd.hu
Tue Sep 5 23:07:55 EEST 2017



On Tue, 5 Sep 2017, James Almer wrote:

> 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.

I kind of confused this with the aac decoder, sorry. Thanks for 
explaining, I guess it is OK then.

Regards,
Marton


More information about the ffmpeg-devel mailing list