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

Michael Niedermayer michaelni
Tue Sep 15 22:02:58 CEST 2009


On Tue, Sep 15, 2009 at 12:22:14PM -0700, Roman V Shaposhnik wrote:
> On Tue, 2009-09-15 at 09:27 +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...
> 
> In DV the header is duplicated in as many places in the frame as you
> have segments. This is done because of tendency that tape has called
> bit rot. 

ohh umm, thats bad, bit rot is contagious and can spread, you better
disinfect all your tapes right away, i suggest hydrogen peroxid its a good
desinfactant. But if you do, you must add something so it does not just
disinfect the surface, i suggest aceton and some acid
;)


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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/53e92c0c/attachment.pgp>



More information about the ffmpeg-devel mailing list