Open Demmenie opened 1 year ago
any updates on this? it's still so slow it's not even funny.
and i don't think that the problem is "unoptimized" code, but i think it's the logic behind it, on how it was conceived in first place...
i mean look at the definition of how it calculates the hashes:
"Every one second, a frame from the input video is extracted, the frames are shrunk to a 144x144 pixel square, a collage is constructed that contains all of the resized frames(square-shaped), the collage's wavelet hash's bit-list is the first bit-list that we use. The frames extracted are now stitched horizontally to each other, and finally divided into 64 equal sized images, the domiant color of these 64 images are detected and compared with a pre-defined pattern of dominant colors, if they match the bit is set else unset. So now we have two bitlist, finally we bitwise XOR these two bitlists. The XOR'ed output is used to generate the final 64 bit hash-value for the video. The bits are joined to form the 64 bit hash-value of the input value."
This process is bound to take a long time, and if this is the way that it calculates hashes then i don't think there's too much we can do to speed it up....
but maybe someone that's smarter than me can answer this better?
I played around with logging when the function calls happen, and the vast majority of the time is taken up in detecting the cropping/black bars.
Edit: I was able to speed it up ~10x for short videos by passing the output for video_duration() to framesextractor() and stopping it from looking for cropping in timestamps past the end of the video.
Edit: I was able to speed it up ~10x for short videos by passing the output for video_duration() to framesextractor() and stopping it from looking for cropping in timestamps past the end of the video.
I think you could do PR for it.. even if the author will never merge it.
I think you could do PR for it.. even if the author will never merge it.
Please do, if only to let other people do the same. I think the author does update it but only infrequently.
Edit: I was able to speed it up ~10x for short videos by passing the output for video_duration() to framesextractor() and stopping it from looking for cropping in timestamps past the end of the video.
I implemented this in my fork and it was about twice as fast on average, counting both long and short videos: https://github.com/Demmenie/videohash2 https://pypi.org/project/videohash2/
Describe the bug It takes quite a while to hash a video.
To Reproduce
Expected behavior It should realistically be doable in under a second
Please complete the following information:
Additional context Currently takes about 3/4 seconds