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

[Michael Niedermayer]

On Mon, Sep 14, 2009 at 09:59:31AM +0200, Reimar D?ffinger wrote:
> On Mon, Sep 14, 2009 at 01:34:32AM +0200, Michael Niedermayer wrote:
> > On Sun, Sep 13, 2009 at 11:35:35PM +0200, Reimar D?ffinger wrote:
> > > Hello,
> > > this is a suggestion for fixing issue1382.
> > > It returns the rather high probe value of 3/4 of max only when multiple
> > > DV-typical bit patterns were found (ca. 128 bit worth), otherwise only
> > > 1/3 of max.
> > > Though I think with the improved mp3 probe it might make sense to
> > > increase its values a bit, too...
> > 
> > feeding the probe code with random data or systematic nonsense should
> > as the amount of data is increased cause the returned score to fall
> > toward 0
> > your code can only increase its score as more data is added, this feels
> > quite incorrect
> 
> Well, since that is the case for many formats I'd expected it is good
> enough to even it out.

any formats i maintain?
if so, tell me and i see what i can do, but IMO foremost the
ones that actually fail in practice (like dv here) should be fixed.


> I don't like making such extensive changes since we have few DV samples,
> but what about this change?

i think the code should check for invalid things that cannot occur in valid
dv and then compare the valid vs. invalid counts to decide on the score

after all the issue at hand is that the code claims its dv while its
not.
You argue that we dont have enough dv files, sorry to flame but
your code cant even distinguish them from /dev/random nor this file here
at hand
also i cant see how the issue of too few samples could ever be solved
except by changing the probe code to check more and seeing if that
works in the wild or if we really have files with 99% of the startcodes
missing all profile and framerate values changing mid frame and all the
packs being at wrong positions (something our decoder would btw fail at)

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

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

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/20090914/6130048f/attachment.pgp>