[FFmpeg-devel] [PATCH] improve DV probe score

[Michael Niedermayer]

On Tue, Sep 15, 2009 at 09:27:09AM +0200, Reimar D?ffinger wrote:
> On Tue, Sep 15, 2009 at 03:54:23AM +0200, Michael Niedermayer wrote:
> > On Mon, Sep 14, 2009 at 03:38:53PM +0200, Reimar D?ffinger wrote:
> > > On Mon, Sep 14, 2009 at 03:06:06PM +0200, Michael Niedermayer wrote:
> > > > On Mon, Sep 14, 2009 at 09:59:31AM +0200, Reimar D?ffinger wrote:
> > [...]
> > > > that said, while i disagree with how you solve this, i
> > > > do not object to the patch, it is an improvment to what we have now
> > > > i just think it can be done quite a bit more solidly, even a check
> > > > of the number of startcodes per byte && the matches being > 3 would
> > > > be better than what its now, also as you return a score >0 for a single
> > > > match, am i missing something or shouldnt a single valid frame have at
> > > > least 10 matches? it seems requireing 3 before a non 0 score is returned
> > > > seems quite reasonable to me
> > > 
> > > How did you come up with the number 10? These checks are exactly like
> > > that used to find the start of the frame, so there should be at most 2
> > > matches per frame, and we have a sample with only one match per frame
> > 
> > static void dv_format_frame(DVVideoContext* c, uint8_t* buf)
> > {
> >     int chan, i, j, k;
> > 
> >     for (chan = 0; chan < c->sys->n_difchan; chan++) {
> >         for (i = 0; i < c->sys->difseg_size; i++) {
> > [...]
> >             buf += dv_write_dif_id(dv_sect_header, chan, i, 0, buf);
> >             buf += dv_write_pack((c->sys->dsf ? dv_header625 : dv_header525), c, buf);
> > 
> > difseg_size being at least 10 in dvdata.h
> 
> Not sure I remember right, but the checks look only for block_number ==
> 0 - I guess mostly because that's what we need for read_header, it
> _might_ make sense to change it for probe - though it means there is a
> higher probability of a match in random data, so not sure if it is
> really an improvement...

maybe you could do something like i did in h261_probe() ?
besides, if iam not mistaken these byte sequences must be at fixed
distances so it would just be checking the existence of 9*4 bytes
for each startcode at fixed locations, that really would make the
probe pretty hard to trigger on random data

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- 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/20090915/6fcf3416/attachment.pgp>