[FFmpeg-devel] [PATCH] swscale-test: add md5 output

Ramiro Polla ramiro.polla
Sun Jul 25 18:47:23 CEST 2010


On Sun, Jul 25, 2010 at 12:47 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sat, Jul 24, 2010 at 07:52:03PM +0200, Reimar D?ffinger wrote:
>> On Sat, Jul 24, 2010 at 06:43:20PM +0100, M?ns Rullg?rd wrote:
>> > Ramiro Polla <ramiro.polla at gmail.com> writes:
>> > > On Fri, Jul 23, 2010 at 9:59 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > >> On Fri, Jul 23, 2010 at 06:54:15PM -0300, Ramiro Polla wrote:
>> > >>> $subj, to be used for regression tests. sse is still default.
>> > >>> (indentation will be done afterwards)
>> > >>
>> > >> knowing how similar the output is to the input is usefull as well as its
>> > >> usefull to know if they differ on 2 computers
>> > >
>> > > -sse is still left as an option to be run separately, or do you want
>> > > both strings to be printed out?
>> > >
>> > >> btw, crc should be slightly faster than md5...
>> > >
>> > > New patch attached used av_adler32_update().
>> >
>> > Wasn't it just recently someone advocated sha1 over md5 (in the
>> > context of the md5 muxer iirc), the latter allegedly not strong
>> > enough?
>
> feeding the troll ...
> md5 is intended to be a strong hash, "recent" advances in cryptanalysis
> made it somewhat weak, thus replacing md5 by something better in the
> contect where md5 was needed makes sense.
>
> crc is intended to detect changes in data though damage or simply to
> detect that data differs, not intentional tampering, iam not aware of
> advances in random noise in this universe that weakens crc
>
> besides adler32 is actually significantly weaker than crc32 for small
> packets of data, i dont know if this applies to us here
>
>
>>
>> IMO that was more a theoretical discussion.
>> I did argue that a CRC is not really enough for e.g. a muxer
>> which calculates a single number for a full file.
>> I can't imagine it really matters much for rather limited
>> regression tests on not that much data and where you always
>> run more than just one single test so going for speed seems
>> reasonable (though I guess only of there's actually a relevant
>> speed difference).
>
> how often did we or anyone had crc32 colissions that hid bugs?
> statistically that should happen less ofthen than once every
> 4 billion bugs

and about the patch... ?



More information about the ffmpeg-devel mailing list