我有一个摄取视频文件的系统,然后启动多个CPU密集型任务。由于这些任务的计算成本很高,我想跳过处理文件(如果已经处理过的话)。
视频来自各种来源,因此文件名等不是可行的选择。
如果我使用图片,我会比较MD5哈希,但在5GB - 40GB视频上,这可能需要很长时间才能计算出来。
要比较我测试此方法的2个视频:
有谁知道更有效的方法吗?或者更好的方法来解决问题?
答案 0 :(得分:1)
我将从文件长度(快速和污垢)开始,继续MD5并完成检查框架。快速而简单。
当然,如果你得到一个编辑过的文件,它会给你假阴性,但是它可能会给你MD5的假阴性,甚至可能检查偶数帧;防止由于版本导致的漏报,计算成本太高,以至于忽略它们可能会更好。
答案 1 :(得分:1)
哈希文件,并跟踪哈希值。这是一个例子:Getting a File's MD5 Checksum in Java
请记住,尽管极不可能,但在数学上可以让两个不同的文件提供相同的哈希值。如果你正在处理大量不合适的文件(大约2 ^ 128个文件),那么你需要一个更好的哈希算法......比如SHA2-256。但这可能不是这种情况。
答案 2 :(得分:1)
首先,您需要正确定义两个视频文件在哪些条件下被视为相同。你的意思是完全相同的逐字节吗?或者你的意思是内容相同,那么你需要为内容定义一个合适的比较方法。
我假设第一个(完全相同的文件)。这与文件实际包含的内容无关。当您收到文件时,始终构建文件的哈希值,并将哈希值与文件一起存储。
检查重复项是一个多步骤的过程:
1。)比较散列,如果找不到匹配的散列,则文件是新的。在新文件的大多数情况下,您可以期望此步骤是唯一的步骤,良好的哈希(SHA1或更大的东西)对于任何实际数量的文件都会有很少的冲突。
2.。)如果您发现其他文件具有相同的哈希值,请检查文件长度。如果它们不匹配,则该文件是新的。
3.如果散列和文件长度都匹配,则必须比较整个文件内容,当找到第一个差异时停止。如果整个文件比较结果与文件完全相同。
在最坏的情况下(文件相同),读取两个文件的原始IO速度不应超过原始IO速度。在最好的情况下(散列不同),测试只需要哈希查找(在DB或HashMap或您使用的任何内容中)所花费的时间。
编辑:您关注构建哈希的IO。如果您首先比较文件 length 并且跳过文件长度的所有内容都是唯一的,那么可能会部分避免这种情况。另一方面,您还需要跟踪已经构建哈希的文件。这将允许您推迟构建哈希,直到您真正需要它。如果缺少哈希,您可以直接跳过比较这两个文件,同时在同一个传递中构建哈希 。它需要跟踪更多的状态,但根据您的情况,它可能是值得的(您需要一个可靠的数据基础来重复文件的出现频率和平均大小分布以做出决定)。
答案 3 :(得分:0)