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

[Aurelien Jacobs]

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

Aurel