On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
> On Mon, Sep 4, 2017 at 4:47 AM, James Almer <jamr...@gmail.com> wrote:
>> Skip the invalid data in an attempt to find one instead, and continue
>> decoding from there.
>>
>> Fixes ticket #6634
>>
>> Signed-off-by: James Almer <jamr...@gmail.com>
>> ---
>> libavformat/aacdec.c | 41 +++++++++++++++++++++++++++++------------
>> 1 file changed, 29 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
>> index 364b33404f..7aacc88560 100644
>> --- a/libavformat/aacdec.c
>> +++ b/libavformat/aacdec.c
>> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
>> return 0;
>> }
>>
>> +static int resync(AVFormatContext *s)
>> +{
>> + uint16_t state;
>> +
>> + state = avio_r8(s->pb);
>> + while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
>> + state = (state << 8) | avio_r8(s->pb);
>> + if ((state >> 4) != 0xFFF)
>> + continue;
>> + avio_seek(s->pb, -2, SEEK_CUR);
>> + break;
>> + }
>> +
>
> The ADTS sync code isn't that much of a sync code, maybe it might be
> more resilient if you try to read the frame size and check if after
> that the next frame also starts with a valid code?
That will only let me know if at the end of the frame is another frame,
and not if the frame I'm reading is complete or not.
Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
complete and right after it there's garbage. Maybe it's incomplete
because another ADTS frame started suddenly in the middle of the one i
tried to read because the source is some weird stream (sample in the
ticket this fixes), and after reading the reported size of the intended
frame the demuxer will find itself in the middle of the new one but
unable to know that's the case.
Really, at the demuxer level i can't do much more than read an ADTS
header, make sure it's at least seven bytes long and that the reported
size of the entire frame is bigger than the header size, then make a
packet out of that. The decoder/parser will handle things from there,
knowing that at very least for the first few bytes what reaches them is
an ADTS frame.
>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
