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

[Reimar Döffinger]

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 :-)

>> 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.

>> 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