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