On Tue, Oct 25, 2022 at 10:31:48PM +0200, Peter B. wrote:
> Hi everyone :)
> 
> This is merely a question of interest. Not a request, complaint or trolling
> of any kind :)
> I'm happy about any answer. I'm curious.
> 
> Would it possibly have a significant impact on coding speed of FFV1's
> slicecrc option (Where a CRC is calculated for each frame slice), to use a
> faster algorithm instead (if one exists)?
> I'm wondering if, for example something like "xxHash" may warrant a try?
> (Haven't found CRC vs xxHash benchmarks yet, but I'm still looking)

CRC is not a random pick for error detection, CRC has specfic properties
like for example that whole classes of errors are guranteed to be detected
a random hash will not gurantee that.
for example a properly designed 8bit CRC will detect every single 1 byte change
always. a 8 bit hash like taking 8 bits from SHA256 will detect only 255 out of
256 1 byte changes

also CRC can be done in parallel if you have cores to spare, you can split a
chunk in as many chunks as you want do the CRC for each and combine them with a
bit of math

and CRC is in the specification so using somehing else would require
changing the spec 

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu