零token视频去重，说白了就是不在大模型接口上花一个token，用本地抽帧、感知哈希和相似度计算，把素材库里重复的视频找出来。这个思路尤其适合短视频创作者、剪辑素材整理、团队素材合并这类场景：视频数量一多，很多文件内容相近，靠人工翻找非常浪费时间。最值得关注的是，它绕开了API登录、token失效、输出长度限制这一堆和视频内容无关的问题，处理规模和成本都更可控。
很多人一开始听到“视频去重”，第一反应是让多模态大模型看视频画面，然后让模型判断两个视频是否一样。这个思路不是不行，但长视频、批量素材、多成员协同时会非常痛苦。我这里想讲的是一种更“钝”但更稳的做法：不依赖模型对画面语义的理解，而是把视频压成指纹，再用距离计算找出相似片段。整个过程不消耗大模型的token，普通电脑就能跑。
下面按实际落地顺序拆一遍，你会看到为什么要抽帧、怎么生成指纹、阈值怎么调，以及批量处理时最容易踩的坑。
1. 为什么视频去重会扯上 token：先厘清成本和链路
1.1 常见的“高 token 去重”思路
用大模型做视频去重，通常会有两种形态。
第一种是把视频抽成帧，再把帧送入多模态模型，让模型总结画面内容、识别物体、描述场景，最后拿这些描述文本做相似度匹配。这种方案看起来很“智能”，能处理内容相似但画面完全不同的视频，比如同一场活动用不同机位拍摄的两段素材。但代价非常直接：每一帧都是一次图像输入，一次输入就会产生一次token消耗。短视频还好，如果是几十分钟的网课、会议录制、监控视频，抽出的帧数会迅速放大，token用量很容易失控。
第二种是把视频转成文字信息，比如抽字幕、转录音频成文本，然后对文本做相似度计算。这个方案适合有明确字幕或口播内容的视频，但问题也很明显：纯音乐、无人声、画外音不清晰的视频，转出来的文本质量很差，最后可能什么都匹配不到。
更麻烦的是认证链路。很多线上工具要求先登录，再获取一个短期有效的token。实际使用中经常遇到登录失败、token过期、刷新失败、地区限制、404错误这类问题。视频还没开始处理，人先被认证流程卡住。长视频处理时，大模型还有输出token上限，回答被截断后，前面的识别结果也跟着作废。
所以在“零token”方案里，我们不是讨论怎么省token，而是从链路层面把token这个变量直接去掉。
1.2 零token方案的本质：本地指纹匹配
零token视频去重的核心做法，是把视频当成“信号的集合”来处理。
具体来说，视频是一个按时间排列的帧序列。如果两个视频在时间顺序上存在大量相似的帧，那它们大概率内容重复。我们不需要模型理解画面的“含义”，只需要一个足够稳定的数学指纹。
这个指纹怎么来？
对视频抽若干帧，把每一帧缩放成很小的尺寸，转成灰度图，然后计算感知哈希。感知哈希会把一张图片变成一个固定长度的二进制串。判断两个视频是否相似，就变成比较两串二进制数的汉明距离。距离越小，说明两张画面越接近，多个画面都很接近，视频就越可能重复。
整个流程里没有外部API请求，没有按token计费，没有登录状态，也没有输出长度限制。本地CPU就能算，有GPU当然更快，但一般情况下不是瓶颈。
需要提前说清楚一点：零token不等于零成本。视频去重仍然需要磁盘空间、CPU/GPU计算时间和电力。如果你的素材文件放在对象存储里，调回本地处理也会产生流量费用。这里的“零token”指不调用按token计费的大模型接口。
2. 零token视频去重核心链路：抽帧、指纹、距离
2.1 完整流程
一个最小可用的视频去重系统，通常走五步：
- 扫描目录下的所有视频文件。
- 读取视频时长、分辨率、编码等信息。
- 从每个视频中抽取固定数量的帧。
- 对帧做缩放、灰度化、感知哈希，生成该视频的指纹。
- 两两比较指纹，计算相似度，把超过阈值的视频归为一组。
这里面最关键的是第3步和第4步。抽帧决定了你看到了视频内容的多少，哈希算法决定了你对转码、压缩、加字幕这类变化的容忍度。
2.2 抽帧策略：均匀抽帧还是场景抽帧
最常见的抽帧方式是固定间隔抽帧。比如每10秒抽1帧，或者按视频总时长均匀取8个点。
我建议先不要一上来就追求“把所有内容都覆盖到”。对于大多数素材去重场景，均匀抽8到16帧已经够用。原因有两点：
第一，真正重复的素材通常不是只有某一帧像，而是时间轴上大量位置都像。少数几个采样点的相似度已经能拉开差距。
第二，帧数越多，计算量越大。1万条视频，每条抽30帧，就是30万帧需要生成哈希和比较，普通笔记本跑起来会明显变慢。
如果你的素材是长视频，比如一小时的讲座，固定抽8帧可能会漏掉关键内容。这时可以改用场景检测抽帧，也就是只在画面发生明显切换的位置抽帧。常见工具是 PySceneDetect，它通过检测画面切割点来决定抽帧位置。
如果只是做第一次去重扫描，我会更推荐均匀抽帧。它的逻辑足够简单，结果容易解释，也方便排查问题。场景检测更适合你已经确认一批视频“时长很长且内容密集”，需要更精细的指纹时再用。
2.3 为什么用感知哈希而不是 MD5
有人会问：视频文件直接算MD5不就行了吗？完全相同的文件，MD5一定一样。
问题在于实际素材库里，真正重复的视频很少是字节级一样。同一个视频可能被剪掉片头、加上字幕、改编码、换封装格式、降低码率、加上B站或抖音的水印，甚至用手机重新录屏。这些操作之后，MD5完全变了，但人眼一看还是同一个内容。
感知哈希关注的是“画面结构”。它会把图像缩小到极低的分辨率，然后根据像素亮度的相对关系生成哈希。和MD5相比，它对微小的颜色变化、压缩噪声、分辨率变化更鲁棒。
当然，感知哈希不是万能的。如果两个视频画面风格完全不同，只是讲同一个话题，比如两个不同的人分别讲同一个PPT，感知哈希大概率认为它们不重复。这种情况下需要的是语义级去重，那就不是零token方案能覆盖的范围了。
2.4 相似度阈值：先保守，再放宽
感知哈希的相似度通常用汉明距离表示。两个哈希每一位相同，距离为0；位差越多，距离越大。
对应到单张图片，可以定义一个“是否相似”的距离阈值。对应到视频，因为一个视频有多个帧哈希，一般会计算所有对应帧的平均距离。
我建议第一轮跑的时候，阈值定得保守一点。宁可少召回，也不要误删。比如先认为“平均汉明距离小于等于5%才算高度相似”，跑完一轮看看结果，再根据实际素材决定是否放宽到10%或15%。
阈值不是一个固定的东西，它和视频格式、抽帧数量、分辨率缩放比例都有关系。别指望有某个阈值能适配所有场景。
3. 一个可以照跑的最小示例
3.1 环境准备
这个方案不需要很高的机器配置。我建议至少在Windows 10、macOS或Linux中用Python 3.8以上的版本。
需要安装的Python库有：
- opencv-python：读取视频帧。
- imagehash：计算感知哈希。
- Pillow：图像格式转换。
- tqdm：显示进度，适合批量跑。
如果你要处理的是还没有解码器的视频编码格式，可能还需要额外确认OpenCV能不能读。常见MP4、MOV、MKV在安装好ffmpeg的情况下通常都能处理。ffmpeg不是Python库，需要单独安装。Windows用户可以从ffmpeg官网下载可执行文件，macOS用户可以用包管理器安装。
安装Python库的命令大致是这样：
pip install opencv-python imagehash Pillow tqdm如果你不太确定系统是否已经有ffmpeg，可以先在终端里跑一下：
ffmpeg -version能显示版本信息就说明环境没问题。如果提示找不到命令，就先把ffmpeg装好再继续。
注意：这里不需要一上来就安装显卡版OpenCV。抽帧和感知哈希对GPU的依赖很低，CPU跑完全够用。
3.2 生成视频指纹的示例脚本
下面的代码是一段示例，用来给单个视频生成指纹。它做的事情是：用OpenCV打开视频，按总帧数均匀抽取8帧，对每帧计算感知哈希，最后返回一个哈希对象列表。
import cv2 from PIL import Image import imagehash def extract_frames(video_path, sample_count=8): cap = cv2.VideoCapture(video_path) if not cap.isOpened(): return [] total_frames = int(cap.get(cv2.CAP_PROP_FRAME_COUNT)) if total_frames <= 0: cap.release() return [] frame_indices = [ int(i * total_frames / sample_count) for i in range(sample_count) ] frames = [] for idx in frame_indices: cap.set(cv2.CAP_PROP_POS_FRAMES, idx) ok, frame = cap.read() if ok: rgb_frame = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) frames.append(rgb_frame) cap.release() return frames def video_fingerprint(video_path, sample_count=8, hash_size=16): frames = extract_frames(video_path, sample_count) if not frames: return [] hashes = [] for frame in frames: pil_img = Image.fromarray(frame) hashes.append(imagehash.phash(pil_img, hash_size=hash_size)) return hashes这段代码里有两个重要参数。
sample_count是每个视频抽多少帧。第一次跑建议用8，确认流程通了之后可以改成12或16。
hash_size是感知哈希的尺寸。16表示生成16x16的哈希，也就是单个图像指纹有256位。尺寸越大，区分度越高，但对细微变化的容忍度会降低。普通素材用16比较合适。
3.3 两两比较与分组
生成指纹之后，下一步是比较两个视频的相似度。
imagehash库的哈希对象之间可以直接做减法，结果就是汉明距离。对多个帧取平均，可以得到视频层面的平均距离。
def video_distance(fp_a, fp_b): if not fp_a or not fp_b: return 1.0 n = min(len(fp_a), len(fp_b)) if n == 0: return 1.0 total_distance = sum(fp_a[i] - fp_b[i] for i in range(n)) return total_distance / n然后扫描一个目录，把视频两两比较：
import os from itertools import combinations video_dir = "./videos" extensions = (".mp4", ".mov", ".mkv", ".avi", ".flv") videos = [ os.path.join(video_dir, f) for f in os.listdir(video_dir) if f.lower().endswith(extensions) ] fingerprints = {} for v in videos: fingerprints[v] = video_fingerprint(v) threshold = 0.05 for v1, v2 in combinations(videos, 2): dist = video_distance(fingerprints[v1], fingerprints[v2]) if dist <= threshold: print(f"{v1} <-> {v2} distance={dist:.4f}")这个两两比较逻辑在视频数量少的时候没问题。但如果超过几百个视频，两两比较的复杂度会变成O(n²)，速度会明显下降。后面我会讲批量场景怎么优化。
3.4 怎么判断是否重复
跑完脚本后，会得到一组“距离小于阈值”的视频对。
我建议不要直接自动删除。原因是距离小只能说明“画面结构相似”，不能证明“内容一定完全一样”。比如同一个视频的横版和竖版，画面大小不一致，但很多帧的画面主体相同；有时是同一个视频里包含同一段片头片尾，也会拉近视频间的距离。
更稳妥的做法是：
- 先看距离分布。距离普遍在0.01以下的，大概率是真重复。
- 距离在0.05到0.15之间的，进入人工复核名单。
- 人工复核时，只看关键帧略缩图或视频时长，不需要完整看整段视频。
零token方案的作用是帮你把几十个候选视频缩小到几个可疑组，而不是帮你做最终删除决定。
4. 批量场景要额外处理的四件事
单条视频跑通之后，很多人会直接开批量。但批量任务不是简单循环，有几个问题必须单独处理。
4.1 文件命名和去重结果输出
批量扫描时，视频文件名可能是乱的，也可能存在同名情况。建议先为每个视频生成唯一ID，再保存原始路径。结果不要只打印到终端，而是输出成CSV或JSON。
输出至少应该包含：
- 视频A的路径
- 视频B的路径
- 平均汉明距离
- 抽帧数量
- 视频时长
- 分辨率信息
这个结果本身就是一份可追溯的去重报告。后续如果发现误判，可以回看距离值，判断是阈值问题还是抽帧策略问题。
不要在生产环境里直接删文件。先用标记模式跑几天，确认结果稳定之后，再考虑自动移动或删除。
4.2 阈值怎么调
批量之后，你可能会看到几个典型现象。
如果你发现大量视频对都算“重复”，说明阈值太宽，也就是距离阈值设置得过高。如果你发现明明内容一样的视频没有被匹配出来，说明阈值太严，或者抽帧点没有对齐。
调整阈值时不要只看一个视频对。可以统计所有视频对距离的分位数，比如打印出最小距离、中位数、最大距离。如果中位数已经在0.1以上，说明你的素材整体差异较大，阈值可以适当放宽；如果大量视频对的距离都在0.02以下，可能说明素材里有大量重复，要继续往下查。
还有一个非常关键的细节：比较两个视频时，帧的顺序最好对齐。两个视频如果一个是另一个的加速版，抽帧点的内容就错开了，平均距离会变大。想要处理这类“倍速重复”，就要用动态时间规整或者对帧序列做相似度匹配，复杂度会高很多。刚开始不要急着处理这个场景。
4.3 重复不等于一模一样：转码、裁剪、加 logo
真正的重复视频往往不是原文件直接复制的，而是经历了各种再加工。
常见的变体有：
- 改变分辨率，比如从1080P压到720P。
- 改变编码，比如从H.264变成H.265。
- 裁剪黑边，或者把视频上下颠倒。
- 加上logo、字幕条、贴纸。
- 改变帧率，比如从30fps变成25fps。
- 改变时长，比如前面加5秒黑场、后面加片尾。
感知哈希能处理大部分编码、分辨率和压缩带来的变化，但因为每个视频抽帧数量和抽帧位置不同，偏移问题需要靠抽帧策略来缓解。
我建议抽帧时不要只抽开头的几帧。视频的前几秒经常是黑场、品牌Logo、软件开头动画，这些内容没有区分度。最好按总帧数均匀采样，让采样点覆盖视频的开头、中间和结尾。
如果素材有明显特征，还可以单独提取一个“区间指纹”，也就是把视频切成长度相等的若干段，每一段生成一个指纹向量。这样即使片头片尾不同，中段相同也能识别出来。
4.4 长视频、大目录、内存占用
视频文件本身不会全部读进内存，OpenCV是按帧读取的。但指纹列表会全部存在内存里。
1万条视频，每条8个哈希对象，在Python里占用并不夸张。但如果每条抽30帧，图片数组又一下子全存到列表里，内存就会明显上涨。在示例代码里，我是一次性把所有帧都暂存在frames里，这个写法适合小规模测试；大批量时最好改成“读一帧、算一帧、丢弃帧数组、只保留哈希”。
另一个问题是ffmpeg进程的并发。如果直接用OpenCV逐条读视频，速度取决于视频解码速度。想加快批量处理，可以尝试多进程并行。但不要一上来就开最大进程数。先开2到4个进程，观察CPU占用和内存占用，再逐步增加。
注意：处理超高清视频时，不要直接对原始分辨率抽帧。先用
cv2.resize把帧缩到200到400像素宽，再计算哈希。这能大幅减少计算量，而且不会显著降低去重准确性。
5. 实际运行中的典型问题与排查顺序
5.1 视频读不出来或抽帧结果为空
很多情况下不是代码问题，而是视频编码格式不被OpenCV支持，或者文件路径包含特殊字符。
排查顺序是：
- 先确认文件能否播放。
- 再确认文件路径里有没有中文、空格、特殊符号。
- 用
cap.isOpened()检查是否成功打开。 - 打印
total_frames，看是不是返回0。
如果OpenCV打不开，可以改用ffmpeg命令行抽帧。用ffmpeg -i input.mp4 -vf "select=not(mod(n,100))" -frames:v 8 frame_%03d.jpg这种方式抽帧，然后再用Pillow读入图片计算哈希。这个方法更依赖ffmpeg的环境，但兼容性更好。
5.2 所有相似度都偏低
如果两个内容完全一样的视频，距离却很大，优先检查抽帧点是否对齐。
比如一个视频是60秒，另一个也是60秒，但一个是从第2秒开始有画面，另一个是从第0秒开始有画面。均匀抽帧时，第一个视频的第1个采样点是第7.5秒，第二个视频的第1个采样点是第0秒附近，画面主体可能不同。
我建议把抽帧数提高一些，比如从8帧提高到16帧。更多的采样点会提高“碰对”的概率。
另外，检查帧是否被正确缩放。如果直接拿原始分辨率计算哈希，微小压缩噪声对哈希的影响会被放大。先缩放成小图，再计算哈希，稳定性会更好。
5.3 误判过多
误判通常有两种。
第一种是阈值太宽。距离0.15可能仍然有较高误判风险。我建议第一轮用0.05，然后看候选组的人眼复核结果。
第二种是素材本身包含大量公共元素。比如同一段片头、同一个Logo、同一个背景板。这种情况下，视频指纹会受公共元素影响，导致不相干视频被分到一组。解决办法是用“中间段抽帧”，去掉前10%和后10%的帧，只看主体内容。
5.4 处理速度比预期慢
先看瓶颈在哪里。如果CPU占用不高，但每个视频处理时间很长，通常是视频解码慢，而不是哈希计算慢。如果CPU占用接近100%，说明计算量大。
优化顺序是：
- 先降抽帧数。
- 再降抽帧分辨率。
- 然后考虑多进程并行。
- 最后才考虑换更强配置的机器。
不要一开始就在高配置设备上跑。先用一个小目录验证参数，再上全量素材。
5.5 排查顺序总结
每次遇到结果异常，我建议按这个顺序排查：
- 看原始输入：文件是否完整、编码是否正常、路径是否有特殊字符。
- 看采样点：抽帧是否覆盖到关键内容，帧顺序是否对齐。
- 看哈希参数：hash_size是否过大或过小，缩放分辨率是否合理。
- 看阈值：距离分布是否合理，阈值是太严还是太宽。
- 最后才怀疑算法本身。
很多问题看起来像是“这个工具不靠谱”，实际都是输入文件、路径、抽帧策略或阈值的问题。
6. 零token方案的边界和升级思路
6.1 适合和不适合的场景
零token视频去重适合以下场景：
- 素材库中大量视频是同一内容的不同格式、不同压缩版本。
- 需要快速筛查重复视频，不需要理解语义。
- 视频数量大，token成本不可控。
- 对数据隐私敏感，不希望把视频内容发送到外部接口。
- 团队多人素材合并，希望有一个可复现的本地工具。
它不适合以下场景：
- 两个视频画面完全不一样，但讲的是同一个主题。比如两个主持人分别录制的同一份新闻稿，这种情况下需要语音识别和语义理解。
- 重复内容被大幅剪辑，比如一个10分钟的视频被拆成5个2分钟的片段，每个片段之间没有完整的时间顺序。这时单纯靠全局指纹会漏掉大量重复。
- 视频被严重套壳，比如加滤镜、加复杂转场、加动态贴纸、改变播放速度。
在这些场景里，零token方案可以作为前置粗筛，但最终需要接入更高层的内容理解。这时才需要考虑大模型、向量化、或语音文本检索，token消耗也必然会回来。
6.2 想要更高准确率怎么办
如果零token方案遇到瓶颈，可以先不急着上大模型，而是做两个升级。
第一个升级是全局特征向量化。用CLIP这类视觉模型把抽出的帧转成向量，然后对向量做余弦相似度。整个过程仍可以在本地GPU上完成，没有token计费。这种方式能缓解“画面相似但哈希相似度不高”的问题，但需要额外的模型权重和显存。
第二个升级是视频级哈希融合。把每个视频的关键帧哈希局部敏感哈希化，建立索引而不是两两比较。这样在几万条视频的体量下也能快速检索出候选集，然后再对候选集做精排。
如果你最终一定要用大模型，也建议先走一遍零token粗筛，把候选组缩小到几百对，再调用大模型做细判断。这样既保留了模型对语义的理解能力，又不会让token用量失控。
6.3 我建议的落地顺序
如果你也想把“零token视频去重”落到自己的素材库里，我建议分四步走。
第一步，先找一个小目录，放几十个视频，其中包含几组确定重复的视频。跑通抽帧、指纹、距离输出。
第二步，打印距离分布，看正常视频对和重复视频对的差距。这一步能帮你找到一个适合自己素材的初始阈值。
第三步，扩展到几百个视频，输出CSV报告，人工复核可疑组。连续跑两三轮，确认没有明显误判。
第四步，再考虑自动化处理。比如每天定时扫描新增文件，生成去重报告；或者把重复视频移动到“待确认”目录，等人工确认后再清理。
整个过程不需要大模型接口，也不需要维护API token。你最需要投入的是整理素材规范、确认阈值、设计输出结果，这三件事做好之后，视频去重会变成一个非常便宜的固定流程。
踩过几次之后我发现，很多工具真正卡住人的不是算法不够聪明，而是把大量时间和注意力浪费在登录、配额、token失效这些和去重无关的事情上。零token方案最大的价值，就是把这些变量全部拿掉，让你能专心处理“视频到底重不重复”这一个问题。
