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

[Reimar Döffinger]

On Thu, May 09, 2013 at 02:40:09PM +0200, Michael Niedermayer wrote:
> First, before the finalization step it has 128bits of state
> the finalization then (excluding the first line) does nothing to
> improve collisions, any colission that existed before, exists
> afterwards. Aka the code is useless and just might make the hash
> look more random to human eyes.

I don't think I follow you completely.
However the point by my understanding is to spread the bits out.
This makes it for example work better with hash tables.
It also makes it more robust against further operations,
e.g. if you xor two hashes you still get a fairly useful hash
that doesn't cancel out in predictable ways.
It generally eliminates the predictable "if I change bits a, b, c, d
together the hash won't see the difference".
The general principle is described here:
http://en.wikipedia.org/wiki/Avalanche_effect
Though I admit its usefulness for a non-cryptographic hash isn't
so clear except my examples above.

> But at the same time it makes
> interrupting and continuing the checksum calculation annoying

I don't think that is a big issue, I didn't implement that
specifically but if you look at my patch I think it's fairly
trivial to do really.

> so while i dont dispute murmur3 works well, its design looks a bit
> fishy to me

For our purpose the author _might_ have concentrated more on the
avalanche behaviour than what makes sense.
And while I understand your argument about the uselessness
of the finalize step, I haven't been able to quite follow it
for the input mixing step, I believe this one avoids properties
like collisions being far more likely if the input has certain
patterns as opposed to being random, which means this part specifically
addresses one of my bigger concerns with adler and CRC.