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

[Michael Niedermayer]

On Thu, May 09, 2013 at 02:59:06PM +0200, Reimar Döffinger wrote:
> 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.

my argumnet was aiming toward that if instead of input "mixing"
the state itself was mixed more it would be better because there would be
more mixing of older data with the same amount of computations.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- 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/77b19761/attachment.asc>