这是一个很大的问题，所以我选择写一个相当长的回复来尝试将问题分解成可能更容易解决的部分。
使用可用的计算和时间资源进行比较很重要：我怀疑需要数月才能运行的解决方案在动态视频数据库中是否非常有用。并且数据库的大小可能使云计算资源的使用变得不可行。因此，我们非常关心几个不同领域中每次比较的本地成本：1）数据存储，2）计算资源，3）时间。
要考虑的一个关键成本是从每个视频中提取所需的数据以用于要使用的任何比较指标。一旦提取的数据可用，则必须考虑执行比较的成本。最后，必须执行将所有视频相互匹配所需的比较。
前两个步骤的成本是视频数量的 O(1)。最后一步的成本必须比 O(1) 更糟，可能更糟。所以我们的主要目标应该是最小化最后一步的成本，即使这意味着增加许多早期的简单步骤。
此过程的最佳算法将在很大程度上取决于数据库的特征，单个和多个匹配存在的级别。如果 100% 的视频与其他视频匹配，那么我们将希望将成功匹配的成本降至最低。但是，更可能的情况是匹配很少，因此我们希望最小化不成功匹配的成本。也就是说，如果有一种快速而肮脏的方式说“这两个视频不能匹配”，那么我们应该先使用它，甚至在我们开始确认匹配之前。
为了表征数据库，首先进行一些抽样和手工匹配，以估计数据库内的匹配程度。这个实验应该显示冗余视频是如何“聚集”的：如果给定的视频有匹配，它有多可能有多个匹配？所有匹配中有多少百分比也是多重匹配的一部分？此过程将产生数据库的“模型”（统计分布），用于帮助算法选择和调整系统。
展望未来，我将假设比赛相对罕见。毕竟，如果有很多匹配，视频会“聚集”，有效地使数据库更小，从而使问题变得更简单。让我们假设问题尽可能难。
我提倡多级分类方法，我们将构建一系列算法，重复执行“这两个视频不匹配”/“这两个视频可能匹配”的二元决策。只有链中的最后一个算法需要输出“这两个视频匹配”的答案。
分类/匹配算法可能会以两种方式中的一种或两种方式失败：假阳性（不匹配的视频被错误标记为匹配）和假阴性（匹配的视频被错误标记为不匹配）。这些错误决策中的每一个都有一系列与之相关的概率，我们希望将两者都最小化。
由于我们正在构建算法管道，因此我们希望算法能够非常擅长无错误地识别不匹配，这意味着它们必须具有极低的 False Reject 率，并且我们不太关心 False Accept 率。例如，Wierd Al 的视频克隆可能看起来和听起来都与原始视频非常相似，我们可能要到算法管道的后期才能证明它与原始视频不匹配。
应该首先运行最简单、最快、最可靠的算法，因为绝大多数测试都会产生“不匹配”的结果。最简单的检查是在数据库中搜索相同的文件，这是由许多快速简单的文件系统和数据库维护实用程序完成的。运行此扫描后，我们可以假设我们实际上需要打开并读取视频文件以检测差异。
由于视频比较比较困难，让我们从音频开始。将数据库首先视为可能包含重复项的 MP3 集合。毕竟，如果我们得到一个好的音频匹配，我们很可能会有一个视频匹配，反之亦然。我们可以肯定地说，音频是视频的“公平”代表。幸运的是，快速的网络搜索将产生许多可靠、快速和成熟的音频指纹识别和比较包。需要为数据库中的每个视频生成音频指纹。缺少音轨的视频将自动落入“可能匹配”组。
但是这里有一个“陷阱”：画外音呢？如果给定的视频被编码两次，有和没有画外音，它们是否匹配？法语音频与西班牙语或英语怎么样？如果这些都应该被认为是匹配的，那么可能需要跳过音频测试。
此时，我们知道文件系统条目都“足够不同”，并且我们知道音轨都“足够不同”（如果经过测试），这意味着我们不能再推迟查看视频数据了。幸运的是，这应该只需要对视频数据库的一小部分进行，所以我们可以容忍一些成本。和以前一样，我们仍然希望首先尝试快速消除更多的不匹配，然后再尝试积极地标记匹配。
由于我们需要考虑分辨率的变化（例如，从 1080p 到 iPod），我们需要一种方法来表征视频信息，该方法不仅与分辨率无关，而且能够容忍添加的噪声和/或数据丢失的一部分。改变分辨率。我们必须容忍帧速率的变化（例如，从电影的 24 fps 到视频的 30 fps）。还需要考虑纵横比变化，例如从 4:3 NTSC 到 16:9 HD。我们想要处理色彩空间的变化，例如从彩色到单色。
然后是同时影响所有这些的转换，例如 HD 和 PAL 之间的转码，它可以同时影响色彩空间、帧速率、纵横比和分辨率。特征还应该容忍某种程度的裁剪和/或填充，例如在 4:3 和 16:9 纵横比之间来回切换（信箱，但不是平移和扫描）。我们还应该处理被截断的视频，例如从故事片的结尾删除演职员表。而且，显然，我们还必须处理由输入相同视频流的不同编码器产生的差异。
这是一个相当多的清单！让我们考虑一些我们可能选择不考虑的事情：我怀疑在存在图像变形时找不到匹配项是可以的，尽管变形变形并不罕见，尤其是在 35mm 宽屏电影中没有变形重建的扫描（高瘦的人）。当帧中间出现大水印时，我们也可能选择失败，尽管我们希望容忍角落中的较小水印。最后，无法匹配在时间上扭曲或在空间上翻转的视频是可以的，例如当一个是另一个的慢动作，或者从左到右翻转时。
这只是覆盖视频空间吗？希望清楚为什么从文件系统和音频开始很重要！也就是说，首先将您的数据库更像是 MP3 集合，然后再将其视为视频集合。
忽略音频，视频只是静止图像的有序序列。所以我们实际上是在寻找一种或多种图像比较算法与一种或多种时间序列比较算法相结合。这可以是一对单独的算法（表征每个帧，然后表征帧序列），或者它可以合并为一个算法（查看帧之间的差异）。
图像本身可以进一步分解为单色“结构”图像和彩色“叠加”。如果计算方便的话，我相信我们可以放心地忽略颜色信息。
从上面看，听起来我假设我们必须对视频进行完全解码才能对其进行任何比较。情况不一定如此，尽管编码数据的比较存在许多限制其有用性的困难。一个重要的例外是对象级视频编码，例如 MP4，其中执行了非常高级的多帧比较。不幸的是，MP4 流之间的对象比较没有太多研究，而且我知道没有包能够执行此功能。但是，如果您找到了，请使用它！
大多数其他数字视频流使用编码方案，例如 MPEG2、Quicktime 或类似的东西。这些方案都使用了关键帧和差异帧的概念，尽管它们的实现方式不同。当比较不同的视频（大小不同的视频）时，关键帧和差异帧不太可能匹配到任何有用的程度。然而，这并不意味着它是不可能的，并且存在试图从这些流中提取有用信息而不执行完全解码的包。如果您发现一个速度很快，它可能属于“为什么不试试”的测试类别。
我将使用的一个技巧是不完全解码帧，而是将它们仅解码为单独的组件通道（HSV、HSL、YUV 等），而不是一直解码到 RGB 帧缓冲区（当然，除非这是编码的内容）。从这里开始，接下来我将创建单独的亮度和色度（颜色）帧，以便可以在相关域中进行比较。一直解码到 RGB 帧缓冲区可能会引入错误，从而使查找匹配变得更加困难。
接下来，我将丢弃颜色信息。由于单色视频应该与其颜色原始匹配，我们根本不关心颜色！
如何将生成的单色帧序列与另一个可能看起来非常不同但仍可能匹配的序列进行最佳比较？在这一领域已经进行了数十年的研究，其中大部分归类为“尺度不变匹配检测”。不幸的是，很少有这项研究直接用于确定视频何时匹配或不匹配。
为了我们的目的，我们可以从几个方向来处理这个问题。首先，我们必须自己知道在单色域中什么是匹配项，什么不是匹配项。例如，我们不关心像素级差异，因为即使两个匹配但不同的视频具有相同的分辨率，我们也必须容忍由于编码器差异等原因而产生的某种程度的噪声。
一个简单（但缓慢）的前进方式是将每个图像转换为独立于分辨率和纵横比的形式。一种这样的变换是到空间频域，而 2D FFT 是理想的。在丢弃虚部之后，可以在高频处截断实部以去除噪声，在低频处截断以去除纵横比效应，然后归一化到标准比例以消除分辨率差异。生成的数据看起来像一个奇怪的微小图像，可以直接在视频流之间进行比较。
还有许多其他可能的帧转换策略，许多比 FFT 更有效，文献搜索应该突出它们。不幸的是，我知道很少有软件库中实现了与 FFT 一样易于使用的软件库。
一旦我们将单色帧转换为更小更有用的域，我们仍然必须与来自另一个视频的另一个这样的流进行比较。而且该视频几乎可以肯定不是帧到帧匹配，因此简单的比较肯定会失败。我们需要一个考虑到时域差异的比较，包括添加/删除的帧和帧速率的差异。
如果您查看 FFT 帧的序列，您会注意到一些非常不同的行为。场景淡入淡出很突然，非常容易发现，剪辑也可以区分，剪辑之间的 FFT 通常只有缓慢的变化。从 FFT 序列中，我们可以将每一帧标记为剪切/淡入淡出之后的第一帧，或者作为剪切/淡入淡出之间的帧。重要的是每次剪切/淡入淡出之间的时间，与它们之间的帧数无关，这会创建很大程度上与帧速率无关的签名或指纹。
获取整个视频的指纹会产生比视频本身小得多的数据。它也是一个线性数字序列，一个简单的时间序列向量，很像音频，可以使用许多相同的工具进行分析。
第一个工具是执行相关性，以确定一个视频中的剪辑模式是否与另一个视频中的剪辑模式密切匹配。如果存在显着差异，则视频是不同的。如果它们是紧密匹配，则需要比较每个相关切割后仅有的几个 FFT 以确定帧是否足够相似以成为匹配。
我不会在这里对 2D FFT 进行比较，因为有大量的参考资料比我做得更好。
注意：还有许多其他操作（除了 2D FFT）可以应用于单色帧以获得额外的指纹。实际图像内容的表示可以通过提取图像的内部边缘（字面上像 FBI 指纹）或通过选择性地对图像进行阈值处理并执行“blobbing”操作（创建相关区域描述符的链接列表）来创建。跟踪帧之间的边缘和/或斑点的演变不仅可用于生成剪切列表，还可用于提取使用 2D FFT 会丢失的其他高级图像特征。
我们已经构建了一系列比较算法，这些算法在发现不匹配时应该非常快，并且不需要太多时间来最终确定匹配。唉，拥有算法并不能解决问题！我们必须考虑与如何最好地实现这些算法有关的几个问题。
首先，我们不想打开和读取每个视频文件超过必要的次数，否则 CPU 可能会停止等待来自磁盘的数据。我们也不想在需要的情况下进一步读取文件，尽管我们不想过早停止读取并可能错过以后的匹配。是否应该保存表征每个视频的信息，或者是否应该在需要时重新计算？解决这些问题将允许开发、测试和部署高效且有效的视频比较系统。
我们已经证明可以比较视频，希望在高度可变的条件下找到匹配项，并具有计算效率。
其余的留给读者作为练习。;^)