零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_count8): 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_count8, hash_size16): 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_sizehash_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 selectnot(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方案最大的价值就是把这些变量全部拿掉让你能专心处理“视频到底重不重复”这一个问题。