[FFmpeg-devel] Indeo5 beta sample: a bug in the AVI demuxer?

[Maxim]

Aurelien Jacobs schrieb:
> On Thu, Oct 01, 2009 at 12:17:12AM +0200, Michael Niedermayer wrote:
>   
>> ssOn Wed, Sep 30, 2009 at 10:58:11PM +0200, Aurelien Jacobs wrote:
>>     
>>> On Sat, Sep 26, 2009 at 10:37:37PM +0200, Maxim wrote:
>>>       
>>>> Hi,
>>>>
>>>> I got a sample from Kostya (AV36_1.AVI at shishkov.homeunix.net) encoded
>>>> with indeo5 beta that cannot be decoded properly with my submitted decoder.
>>>>
>>>> I checked that and found out that the problem resides on the demuxer side!
>>>> Many important frames (key frames except the 1st one) simply don't reach
>>>> the decoder (those will be misteriously dropped by the demuxer) so the
>>>> whole video just cannot be decoded properly!
>>>>
>>>> Kostya, can you resubmit the above mentioned video?
>>>>
>>>> For example, the important frame at the offset 0x33808 is dropped (don't
>>>> being send to the decoder).
>>>>
>>>> Could anyone check it and fix it?
>>>>         
>>> I confirm this bug. The mplayer native AVI demuxer works fine with
>>> the sample while the lavf demuxer is skipping some frames.
>>>
>>> Here is the check which is responsible for this:
>>>
>>>             } else if(   ((ast->prefix_count<5 || sync+9 > i) && d[2]<128 && d[3]<128) ||
>>>                          d[2]*256+d[3] == ast->prefix /*||
>>>                          (d[2] == 'd' && d[3] == 'c') ||
>>>                          (d[2] == 'w' && d[3] == 'b')*/) {
>>>
>>> Some frames are skipped because they don't match this test.
>>> Here are the values of different variables for those skipped frames:
>>>
>>>   pos     prefix_count   sync     i     d[2]  d[3]  d[2]*256+d[3]   prefix
>>> 0x033807       13       210941  210951  100    98      25698        25699
>>> 0x05F807       27       391165  391175  100    98      25698        25699
>>> 0x08D807       41       579581  579591  100    98      25698        25699
>>> 0x0B5007       55       741373  741383  100    98      25698        25699
>>>
>>> I don't know the avi demuxer well and I didn't verified exactly the
>>> meaning of this test, but I've checked that the sample file is demuxed
>>> correctly when applying one of the 2 attached patch (both works).
>>> I don't have time to work more on this, so it would be great if someone
>>> who knows AVI well could check this and apply a proper fix.
>>>       
>> i can provide a proper fix (below)
>>     
>
> Great.
>
>   
>> but its not tested (lazy and too much other stuff to do)
>>     
>
> That's good enough for me.
>
>   
>> add this to where the similar JUNK check is
>>         //parse stray LIST
>>         if(d[0] == 'L' && d[1] == 'I' && d[2] == 'S' && d[3] == 'T'){
>>             url_fskip(pb, 4);
>>             goto resync;
>>         }
>>     
>
> OK. Tested successfully with the aforementionned sample, so committed.
>
>   
>> PS: this is one of the more weird AVIs ive seen, it should be kept on mphq!
>>     
>
> http://samples.mplayerhq.hu/avi/AV36_1.AVI
>   

Thank you very much! I've just tested it with my indeo5 decoder while
checksum test enabled. No reported errors - it means the decoding is
bitexact! Good work!

Regards
Maxim