[FFmpeg-devel] [PATCH 2/5] fate: avoid framemd5, use framecrc its faster

[Michael Niedermayer]

On Thu, May 09, 2013 at 07:58:45AM +0200, Reimar Döffinger wrote:
> On 09.05.2013, at 02:12, Michael Niedermayer <michaelni at gmx.at> wrote:
> > Ive never seen crc or adler fail on real world data. It sure does
> > happen, for example you should find a colission in 100000 random files
> > but thats not the question.
> 
> If it was random files I would have no concerns...
> 
> > If i safe 10minutes a day, that sure is alot more than i will ever
> > spend on debuging crc & adler32 colission related bugs.
> > and i can spend these 10minutes on debuging other bugs thus ...
> 
> I don't really believe that FATE being 10 seconds faster would really safe you any time at all in the end, which might be part of why I have doubts about this making sense, sorry for being such a sceptic :-)

please pick 50 activities you do each day and on each wait 10
seconds each day doing nothing. ... that is if thats irrelevant and no
problem for you

also the current box iam using, ive bought pretty much for no other
reason than to reduce compile & fate times.
If i can make it 5 seconds faster thats a noticeable improvment

And we have developers who occasionally skip running fate before
pushes, i didnt ask but i suspect its because their hardware is
slow enough for running fate to be a burden

And look at fate.ffmpeg.org, speeding up fate will translate also
in these tests running more often.


> 
> >> It also suggests that they may fail to detect e.g. padding changing
> >> from 0x00 to 0xFF. This might be relevant to the valgrind memory
> > 
> > do you have a example of such colission with changed padding ?
> 
> Paper said it can't distinguish long runs of those since they are both 0 in one's complement, but I don't feel like doing my own research.

are you talking about fletcher or adler ?


> 
> >> An interesting question (though to be honest unless you want to
> >> I think I'd have you rather have you work on other stuff) would
> >> be if there is something more hashlike than adler32 with similar speed,
> >> RC4 maybe, I think it can be used for hashing?
> >> Anyway I leave it up to you, it's mostly a gut feeling from my side so
> >> far and not really worth wasting much of your time discussing it.
> > 
> > If you know of a better & fast method that has been subjected to
> > some serious use & testing then iam surely interrested.
> 
> Well, MurMur3 has had at least some use, and it has a fast x64_128 method that at least gives us 128 bit instead of just 32.
> Don't know if you feel it's worth spending time implementing it in FFmpeg though, I probably won't have time :-(
> http://smhasher.googlecode.com/svn/trunk/MurmurHash3.cpp

5th line of this says:
// Note - The x86 and x64 versions do _not_ produce the same results, as the

any other suggestions ?

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130509/81684dc0/attachment.asc>