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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
