[FFmpeg-devel] [PATCH] probetest.c

[Kostya]

On Wed, Sep 16, 2009 at 01:27:01PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 16, 2009 at 07:51:03AM +0300, Kostya wrote:
> > On Tue, Sep 15, 2009 at 09:12:35PM +0200, Michael Niedermayer wrote:
> > > On Tue, Sep 15, 2009 at 09:04:22PM +0300, Kostya wrote:
> > > > On Tue, Sep 15, 2009 at 07:39:59PM +0200, Vitor Sessak wrote:
> > > > > Michael Niedermayer wrote:
> > > > >> On Mon, Sep 14, 2009 at 05:19:03PM +0200, Michael Niedermayer wrote:
> > > > >>> Some simple probe testing code should be attached
> > > > >>>
> > > > >>> its output, aka formats that detect random data with a score >25 are:
> > > > >>> Failure of h261 probing code with score=50 type=0 p=B53 size=2
> > > > >>> Failure of vc1test probing code with score=50 type=0 p=40E size=4
> > > > >>> Failure of h263 probing code with score=50 type=0 p=C1E size=4
> > > > >>> Failure of idcin probing code with score=50 type=0 p=E93 size=8
> > > > >>> Failure of mm probing code with score=50 type=0 p=FC0 size=128
> > > > >>> Failure of dv probing code with score=75 type=1 p=E85 size=256
> > > > >>> Failure of vmd probing code with score=50 type=0 p=AF4 size=512
> > > > >>> Failure of mpeg probing code with score=52 type=0 p=D9C size=4096
> > > > >>> Failure of dts probing code with score=51 type=1 p=B8F size=8192
> > > > >>>
> > > > >>> maintainers of the listed formats should look into fixing their probe
> > > > >>> code!
> > > > >>> ill try to look at h26*/mpeg if i find the time, that said if someone
> > > > >>> else is faster thats welcome of course ...
> > > > >>
> > > > >> and as everyone celebrates victory, probetest returns from the depths of
> > > > >> hell stronger and more evil to devour more demuxers
> > > > >> heres the output up to 32k
> > > > >
> > > > > [...]
> > > > >
> > > > >> Failure of mpc8 probing code with score=100 type=3 p=85A size=64
> > > > 
> > > > May I say that it would fail in many cases since any string of uppercase
> > > > letters starting with 'MPCK' can be parsed as valid Moosepack SV8 file
> > > > with strange but valid tags?
> > > 
> > > is that some kind of ukrainian humor?
> > > lets see
> > > 
> > >     if(tag != TAG_STREAMHDR){
> > >         av_log(s, AV_LOG_ERROR, "Stream header not found\n");
> > >         return -1;
> > >     }
> > >     pos = url_ftell(pb);
> > >     url_fskip(pb, 4); //CRC
> > >     c->ver = get_byte(pb);
> > >     if(c->ver != 8){
> > >         av_log(s, AV_LOG_ERROR, "Unknown stream version %d\n", c->ver);
> > >         return -1;
> > >     }
> > 
> > If you read SV8 spec or even my code, you'll see that file may contain
> > any number of tags before stream header, so file like:
> > MPCKMNF<67 bytes with  anything>FFM<76 other bytes with anything>SH\017...
> > is valid.
> 
> ill be more clear, what i meant is that
> 1. you should check for the main header (MPCK or so), you do that
> 2. you should follow the chain of chunks, you do not do that
> 3. if you find a stream header you should check that its valid (tag,ver,crc)
> if anything is invalid return 0, because read_header will fail anyway
> else if too little data has been provided by the application so the chain
>         goes beyond the buffer return a score below 25
> else all is valid and you can return the MAX score

ok, I'll work on that

> i dont know if checking unknown tags to be printable upper case letters is
> safe, also your new crc!=0 check looks a little odd, crcs in general can be
> 0.

SV8 spec says that all tags should be composed from uppercase letters
and that in that case CRC=0 is illegal.

> But if checking for printable upper case letters is safe, you surely should
> check the whole chain that is within the buffer!
> 
> the case that the stream header is outside the probe buffer should be very
> unlikely because, first an application is _required_ to increase the buffer
> size up to some limit when probing failed and second the header really should
> be close to the file start
> 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB