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

[Michael Niedermayer]

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) but its not tested (lazy and too much
other stuff to do)

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;
        }

PS: this is one of the more weird AVIs ive seen, it should be kept on mphq!

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091001/9fa9df58/attachment.pgp>