正文
这段代码在我的macbook pro上跑了大约一个小时。 我们来看看结果：
很好，结果看起来很直观，从下图中可以看出，帧5928与帧2048454相同，帧5936与帧2048462相同，以此类推。让我们目视确认。
完美。所以，这个视频肯定是伪造的。 然而，帧匹配的数量看起来实在太低了，值得怀疑啊。 真的只有25个相同的帧吗?在整整24小时的视频中这25帧的长度几乎不到1秒钟。我们来进一步看一下!
情况变复杂了
该程序的作用是确定相同的帧，这样我就能知道视频是在循环播放。让我们来看看上面两幅图像的后2秒的帧(帧5936 + 60和帧2048462 + 60)是什么样的。
等等…… 这两个图像看起来是一样的啊!但是他们为什么没有标记为匹配呢?我们可以把其中一个帧减去另外一个帧来找出不同之处。这个减法是对每个像素的红、绿、蓝的值分别做减法。
太好了，我们创造出了一个很酷的故障艺术!但是，实际上两个帧的差值仅仅是视频被压缩后的两个帧的差异。由于经过了压缩，原来相同的两个帧可能会受到噪音的影响而导致失真，从而在数值上不再一样(尽管它们在视觉上看起来是一样的)。
对上面的说明总结一下，当我将数据存储在字典中时，我取了每个图像的哈希。哈希函数将图像(数组)转换为整数。如果两个图像完全相同，则哈希函数将得到相同的整数。如果两个图像不同，我们将得到两个不同的整数。但是我们实际想要的是，如果两个图像只是稍微不同，我们然仍然能得到相同的整数。
简化我们的压缩问题
有几种不同的哈希算法，每种都有专门的使用场景。我们在这里将要看到的是感知哈希。与其他类型的哈希不同的是，对于靠近在一起的输入，它们的感知哈希值是相同的。反向图像搜索网站显然使用的是类似的技术，这些网站只是抓取他们遇到的网络和哈希图像。由于同一张图片在互联网上可能存在多种不同的分辨率和剪裁，所以检查其他具有相同哈希值的东西则更为方便。
然而，对于我们来说，又有新的麻烦了，因为我们处理的并不完全是图像，而是一系列的图像，每一张图片都是相差1/30秒。这意味着我们的哈希函数需要：
