尧图网站建设 
170帧还是26帧claude-real-video benchmark实测LLM到底需要看多少帧才够【免费下载链接】claude-real-videoLet Claude (or any LLM) actually watch a video — scene-aware, deduplicated frames transcript, from a URL or local file. Runs locally, MIT.项目地址: https://gitcode.com/gh_mirrors/cl/claude-real-videoclaude-real-video 是一个开源工具让 Claude 等 LLM 真正看视频场景感知抽帧 去重 字幕转录全程本地运行。这个项目附带的官方 benchmark 做了一个有意思的实验——同一个视频固定 1fps 抽帧要 170 帧而它只保留真正有变化的 26 帧。LLM 到底需要多少帧才够这篇文章直接搬出实测数据回答你。为什么每秒抽 1 帧是个陷阱大多数让 LLM 看视频的脚本包括 Gemini 自己的管线都用固定间隔抽帧每 N 秒取一帧。问题在于静态内容被过度采样一张 10 分钟的 PPT 静帧1fps 会抽出 600 张几乎一模一样的图token 全烧了信息量为零快速剪辑被欠采样一闪而过的文字卡片帧与帧之间的变化直接被跳过而视频里有意义的帧其实取决于画面什么时候变了而不是时间过去了多久。这就是 claude-real-video 的核心思路用场景变化检测选帧再用滑动窗口去重把重复镜头只送一次。实验设置7 个视频 × 4 种方法完整实验记录在 benchmark/benchmark.md一键复现脚本是 benchmark/run_benchmark.sh。测试环境是 Mac mini M4对比四种方法方法说明A固定 1fpsffmpeg 直接抽帧B固定 0.5fps每 2 秒一帧Ccrv 默认场景检测 去重Dcrv --adaptive额外启用慢变场景检测测试材料覆盖了 7 种完全不同的视频类型演讲幻灯片、快剪文字卡、屏幕录制、1962 年颗粒感老胶片、火箭发射、慢速轨道平移、逐笔手写动画——每一种都在考验抽帧策略的不同短板。结果总表帧数与 token 估算token 估算按帧数 × 765Claude 单张约 1.15MP 图片的视觉成本。加粗为人工检查后确认内容完整的行视频1fps0.5fpscrv 默认crv --adaptive演讲幻灯片 (150s)150 帧 / 115k75 / 57k87 / 67k101 / 77k快剪文字卡 (30s)30 / 23k15 / 11k3 / 2.3k ⚠️3 / 2.3k ⚠️屏幕录制 (58s)58 / 44k29 / 22k6 / 4.6k ⚠️6 / 4.6k ⚠️1962 老胶片 (180s)180 / 138k90 / 69k53 / 41k116 / 89k ❌火箭发射 (527s)527 / 403k264 / 202k20 / 15k20 / 15k轨道慢移 (201s)201 / 154k100 / 77k101 / 77k101 / 77k手写动画 (52s)52 / 40k26 / 20k3 / 2.3k ⚠️3 / 2.3k ⚠️ 赢麻的案例火箭发射 527 帧 → 20 帧8 分 47 秒的发射视频1fps 要 527 帧约 40 万 tokencrv 只保留 20 帧约 1.5 万 token减少 96%。更关键的是质量这 20 帧拼出来是一个完整故事——发射台、点火、升空、烟柱漂移、空台、渐暗一帧不落。老胶片同理1962 年 JFK 演讲180 帧压到 53 帧约 57% 降幅token 从 138k 降到 41k画面内容没有丢失。⚠️ 输掉的案例当意义的变化比像素快benchmark 最诚实的部分是它如实记录了三个翻车现场——共同点是画面布局几乎不动变的是文字。快剪文字卡30 秒视频只保留了 3 帧至少两张核心文字卡被整体漏掉黑底小字切换像素变化远低于 8% 的去重阈值屏幕录制6 帧漏掉了图表页以及整段演示中信息密度最高的五条结论全部渲染完成的结尾画面手写动画52 秒的逐笔书写过程被压缩到 3 帧白闪、空白页、写完的页LLM 根本看不出这是一支笔在写字根因都在去重器它工作在 16×16 的降采样签名上见 src/claude_real_video/core.py 的dedup_frames细笔画、小字、局部 UI 更新在降采样后差异为 0.0%任何阈值都救不回来。另一个重要教训--adaptive在颗粒感老胶片上反而翻车——116 帧token 翻倍却没有找到任何新内容噪点和压缩抖动把检测器骗了。 0.7.4 修复三个翻车案例全部翻盘v0.7.4 在原有全局比较器旁边加了一条局部稳态检测通道在 192px 签名上寻找与所有已保留帧差异明显、且接下来不再变化的局部区域专门捕捉文字卡切换和 UI 局部更新。同机同文件重测视频修复前修复后手写动画3 帧9 帧空白→四段中间态→完成页快剪文字卡3 帧8 帧5 张文字卡全部找回屏幕录制6 帧15 帧图表页五条结论结尾都在代价是噪点素材帧数上升老胶片 53→77仍比 1fps 少 57%以及--adaptive在老胶片上变得更不推荐。 结论LLM 到底需要多少帧没有一个数字的答案benchmark 给出的是按内容类型的经验值有冗余长镜头发射、演讲crv 默认模式可砍 70%~96% 帧内容无损文字卡/屏幕录制用 0.7.4 的默认模式或带字幕轨道时加--text-anchors颗粒感老胶片千万别开--adaptive固定 1fps永远能用但 token 上限是你的视频有多长一个直观的量级参考3 分钟视频1fps 约 52k tokencrv 默认约 15k~25k。少喂 60%~90% 的帧理解力还在线——这才是够的真正含义不是帧数够多而是每一帧都该在。想自己动手验证仓库里的 benchmark/run_benchmark.sh 改一下视频列表就能跑你自己的素材抽出的帧也可以加--grid打包成缩略图墙像这样一张图检查全部【免费下载链接】claude-real-videoLet Claude (or any LLM) actually watch a video — scene-aware, deduplicated frames transcript, from a URL or local file. Runs locally, MIT.项目地址: https://gitcode.com/gh_mirrors/cl/claude-real-video创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 170帧还是26帧？claude-real-video benchmark实测：LLM到底需要看多少帧才够
170帧还是26帧claude-real-video benchmark实测LLM到底需要看多少帧才够【免费下载链接】claude-real-videoLet Claude (or any LLM) actually watch a video — scene-aware, deduplicated frames transcript, from a URL or local file. Runs locally, MIT.项目地址: https://gitcode.com/gh_mirrors/cl/claude-real-videoclaude-real-video 是一个开源工具让 Claude 等 LLM 真正看视频场景感知抽帧 去重 字幕转录全程本地运行。这个项目附带的官方 benchmark 做了一个有意思的实验——同一个视频固定 1fps 抽帧要 170 帧而它只保留真正有变化的 26 帧。LLM 到底需要多少帧才够这篇文章直接搬出实测数据回答你。为什么每秒抽 1 帧是个陷阱大多数让 LLM 看视频的脚本包括 Gemini 自己的管线都用固定间隔抽帧每 N 秒取一帧。问题在于静态内容被过度采样一张 10 分钟的 PPT 静帧1fps 会抽出 600 张几乎一模一样的图token 全烧了信息量为零快速剪辑被欠采样一闪而过的文字卡片帧与帧之间的变化直接被跳过而视频里有意义的帧其实取决于画面什么时候变了而不是时间过去了多久。这就是 claude-real-video 的核心思路用场景变化检测选帧再用滑动窗口去重把重复镜头只送一次。实验设置7 个视频 × 4 种方法完整实验记录在 benchmark/benchmark.md一键复现脚本是 benchmark/run_benchmark.sh。测试环境是 Mac mini M4对比四种方法方法说明A固定 1fpsffmpeg 直接抽帧B固定 0.5fps每 2 秒一帧Ccrv 默认场景检测 去重Dcrv --adaptive额外启用慢变场景检测测试材料覆盖了 7 种完全不同的视频类型演讲幻灯片、快剪文字卡、屏幕录制、1962 年颗粒感老胶片、火箭发射、慢速轨道平移、逐笔手写动画——每一种都在考验抽帧策略的不同短板。结果总表帧数与 token 估算token 估算按帧数 × 765Claude 单张约 1.15MP 图片的视觉成本。加粗为人工检查后确认内容完整的行视频1fps0.5fpscrv 默认crv --adaptive演讲幻灯片 (150s)150 帧 / 115k75 / 57k87 / 67k101 / 77k快剪文字卡 (30s)30 / 23k15 / 11k3 / 2.3k ⚠️3 / 2.3k ⚠️屏幕录制 (58s)58 / 44k29 / 22k6 / 4.6k ⚠️6 / 4.6k ⚠️1962 老胶片 (180s)180 / 138k90 / 69k53 / 41k116 / 89k ❌火箭发射 (527s)527 / 403k264 / 202k20 / 15k20 / 15k轨道慢移 (201s)201 / 154k100 / 77k101 / 77k101 / 77k手写动画 (52s)52 / 40k26 / 20k3 / 2.3k ⚠️3 / 2.3k ⚠️ 赢麻的案例火箭发射 527 帧 → 20 帧8 分 47 秒的发射视频1fps 要 527 帧约 40 万 tokencrv 只保留 20 帧约 1.5 万 token减少 96%。更关键的是质量这 20 帧拼出来是一个完整故事——发射台、点火、升空、烟柱漂移、空台、渐暗一帧不落。老胶片同理1962 年 JFK 演讲180 帧压到 53 帧约 57% 降幅token 从 138k 降到 41k画面内容没有丢失。⚠️ 输掉的案例当意义的变化比像素快benchmark 最诚实的部分是它如实记录了三个翻车现场——共同点是画面布局几乎不动变的是文字。快剪文字卡30 秒视频只保留了 3 帧至少两张核心文字卡被整体漏掉黑底小字切换像素变化远低于 8% 的去重阈值屏幕录制6 帧漏掉了图表页以及整段演示中信息密度最高的五条结论全部渲染完成的结尾画面手写动画52 秒的逐笔书写过程被压缩到 3 帧白闪、空白页、写完的页LLM 根本看不出这是一支笔在写字根因都在去重器它工作在 16×16 的降采样签名上见 src/claude_real_video/core.py 的dedup_frames细笔画、小字、局部 UI 更新在降采样后差异为 0.0%任何阈值都救不回来。另一个重要教训--adaptive在颗粒感老胶片上反而翻车——116 帧token 翻倍却没有找到任何新内容噪点和压缩抖动把检测器骗了。 0.7.4 修复三个翻车案例全部翻盘v0.7.4 在原有全局比较器旁边加了一条局部稳态检测通道在 192px 签名上寻找与所有已保留帧差异明显、且接下来不再变化的局部区域专门捕捉文字卡切换和 UI 局部更新。同机同文件重测视频修复前修复后手写动画3 帧9 帧空白→四段中间态→完成页快剪文字卡3 帧8 帧5 张文字卡全部找回屏幕录制6 帧15 帧图表页五条结论结尾都在代价是噪点素材帧数上升老胶片 53→77仍比 1fps 少 57%以及--adaptive在老胶片上变得更不推荐。 结论LLM 到底需要多少帧没有一个数字的答案benchmark 给出的是按内容类型的经验值有冗余长镜头发射、演讲crv 默认模式可砍 70%~96% 帧内容无损文字卡/屏幕录制用 0.7.4 的默认模式或带字幕轨道时加--text-anchors颗粒感老胶片千万别开--adaptive固定 1fps永远能用但 token 上限是你的视频有多长一个直观的量级参考3 分钟视频1fps 约 52k tokencrv 默认约 15k~25k。少喂 60%~90% 的帧理解力还在线——这才是够的真正含义不是帧数够多而是每一帧都该在。想自己动手验证仓库里的 benchmark/run_benchmark.sh 改一下视频列表就能跑你自己的素材抽出的帧也可以加--grid打包成缩略图墙像这样一张图检查全部【免费下载链接】claude-real-videoLet Claude (or any LLM) actually watch a video — scene-aware, deduplicated frames transcript, from a URL or local file. Runs locally, MIT.项目地址: https://gitcode.com/gh_mirrors/cl/claude-real-video创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考