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