video-use

render：短语感知字幕，字幕文件缺失时报错；skill：声音、字体、critic 环节（#183） 字幕：build_master_srt 使用固定的 2 词配对，会在停顿处拆分 （"DOES IS"）并闪现 0.18 秒的字幕（"WHAT A"）。chunk_words 现在会在 标点处和 >= 0.3 秒的停顿处断句，并将过短的字幕扩展到最多 3 个词。 字幕路径：EDL 的 "subtitles" 路径若无法相对于 EDL 目录解析，会打印警告 并在无字幕的情况下渲染。现在它还会尝试当前目录，然后以错误退出。 SKILL.md：音乐/音效规则、逐段响度检查以及自评估中的 critic 子代理、 字体加载断言，以及作为完整示例的 "show the edit" 钩子。 Co-authored-by: Claude Opus 5.5 (1M context)

transcribe：选择音轨，并拒绝上传静音音轨（#134） * feat(transcribe)：选择音轨并拒绝上传静音 extract_audio 运行时没有 -map，因此 ffmpeg 应用了其默认流选择 并只取了一条音轨——第一条。多音轨录制是屏幕录制的常见情况：OBS 将应用程序写入音轨 0， 将麦克风写入音轨 1。转写此类文件会上传应用程序音频 并悄无声息地丢弃旁白。 --audio-track 选择流，从零开始计数，默认为 0，因此现有的 单音轨运行保持不变。具有多条音轨的文件会在详细输出中说明， 因为默认值对其中一些是正确的，对另一些则是错误的。 提取出的 wav 在发送前还会检查电平。峰值低于 -60 dBFS 意味着该音轨是静音，这实际上意味着选错了音轨， 而 Scribe 对静音和语音收费相同。错误信息会列出 音轨数量并指向该标志。 * fix(transcribe)：按音轨设置缓存键，分块扫描峰值，命名音轨 对 #134 的审查发现了四个问题。 转写缓存仅以视频文件名为键，而 transcribe_one 在查看 audio_track 之前 就在缓存命中时返回。因此在选错音轨运行后使用 --audio-track 1 重新运行， 会返回该标志本应替换的那份转写。现在音轨会加入文件名， 而音轨 0 保留旧名称，因此现有转写仍然有效。 peak_dbfs 使用 readframes(getnframes()) 读取整个片段并将其复制到 数组中，因此一个两小时的 16 kHz 单声道文件会占用 230 MB 两次， 而批处理模式会同时运行多个。现在它改为以 64k 帧分块扫描； 在真实录制上测量，峰值与整文件版本相同。 "try --audio-track" 提示在 0 和 1 之间切换，因此在具有三条 音轨的文件上它可能指向另一条静音音轨。现在它会列出存在的音轨： "The file has 3 audio tracks; try --audio-track 0 or 2." 该标志的帮助文本说 ffmpeg 否则会取音轨 0。实际上它会应用其 默认流选择，即选择声道数最多的音轨。 * fix(transcribe)：在单文件和批处理模式之间共享一个转写路径 对 #134 的再次审查：前一次提交将音轨加入 transcribe.py 中的缓存键， 却让 transcribe_batch.py 仍检查 {stem}.json。因此批处理模式 使用 --audio-track 1 时会把具有音轨 0 转写的文件视为 已缓存并跳过，这使该标志失效，并且永远无法识别它刚刚写入的 {stem}.track1.json，因此每次运行都会重新上传并重新计费该文件。 两者现在都调用 transcript_path()，因此它们不会再出现偏差。 在一个包含一个视频和一份音轨 0 转写的目录上验证：默认 运行报告 "1 cached, 0 to transcribe"，使用 --audio-track 1 的同一运行 报告 "0 cached, 1 to transcribe" 并继续进入静音防护。

fix(render)：在竖屏检测中考虑旋转元数据（#137） * fix(render)：在竖屏检测中考虑旋转元数据 在读取编码尺寸的同时读取 display-matrix 旋转和旧式 rotate 标签。对四分之一圈旋转交换尺寸，以便 ffmpeg 自动旋转后的滤镜输入使用正确的缩放轴。 * fix(render)：仅信任 display rotation 侧数据 忽略不能保证 ffmpeg 自动旋转的普通 rotate 标签，并断言 ffprobe 查询继续请求 display-matrix 旋转。 --------- Co-authored-by: Anton Sidorov aka anticodeguy

fix(render)：默认保留源帧率；添加 --fps 覆盖（#55） * fix(render)：默认保留源帧率；添加 --fps 覆盖 extract_segment 硬编码了 `-r 24`，因此每次渲染都被强制为 24 fps， 无论源如何。这会静默地对 30/60 fps 素材进行降采样 （例如以 60 fps 录制的 OBS 屏幕/摄像头捕获），并与该 skill 声明的 "除非另有要求，否则匹配源" 原则相矛盾。此前没有 CLI 选项可以更改它。 使用 ffprobe 探测源的 r_frame_rate 并将其原样传递给 ffmpeg（因此像 30000/1001 这样的分数帧率可以保留而无需 舍入），仅在无法确定帧率时回退到 24。 添加 `--fps N` 标志以在需要时强制指定帧率。 行为变更：渲染现在默认保留源帧率， 而不是始终生成 24 fps。 Co-Authored-By: Claude Opus 4.8 (1M context) * fix(render)：每次渲染解析一个帧率，而不是每个片段 回应审查反馈（由 cubic 识别）：在 extract_segment 内部探测帧率 意味着混合帧率的多源 EDL（例如一个 30fps 和一个 60fps 源）会以不同帧率编码片段。无损 拼接（`-c copy`）要求每个片段共享同一帧率，因此这会破坏 多源编辑的拼接。 在 extract_all_segments 中一次性解析出单一输出帧率并传递给 每个片段：显式 --fps 优先，否则保留第一个源的 帧率（如果无法探测则回退到 24）。单源渲染仍保留 源帧率；多源渲染保持同质且拼接安全。 extract_segment 现在接受已解析的 `rate` 字符串（在没有 rate 独立调用时 仍会探测自己的源）。 Co-Authored-By: Claude Opus 4.8 (1M context) * fix(render)：强化源帧率处理 对可变帧率输入优先使用 avg_frame_rate，回退到 r_frame_rate，并接受十进制或分数形式的 --fps 覆盖。添加针对验证、探测和统一多源渲染帧率的专项测试。 * fix(render)：在分数解析前验证 fps 将 FPS 输入限制为有界的 ffmpeg 兼容数字和分数形式，规范化接受的值，并覆盖显式覆盖、回退行为和探测失败。 * fix(render)：保持规范 fps 解析幂等 拒绝超出 FFmpeg AVRational 分量边界的约简 FPS 分数，确保每个被接受的规范帧率都能再次安全解析。 --------- Co-authored-by: Anton Sidorov aka anticodeguy Co-authored-by: Claude Opus 4.8 (1M context)

合并拉取请求 #91，来自 ShawnPana/patch-1 更新 README.md

更新 README.md

合并拉取请求 #34，来自 browser-use/add-bux-video-use-note 添加 Browser Use Box 编辑说明

添加 Browser Use Box 编辑说明

fix(render)：为竖屏视频源保留方向（#29） 横屏视频按宽度缩放（scale=W:-2），这对 水平素材有效，但会挤压竖屏/垂直片段（高度 > 宽度）， 因为高度成为受约束的维度。 添加了 is_portrait_source()，它使用 ffprobe 检测 h > w 的情况，然后 将缩放滤镜切换为 scale=-2:H，以便竖屏源改为按 高度缩放，从而在整个流程中保持正确的 9:16 方向。 Co-authored-by: Claude Sonnet 4.6

fix(pack_transcripts)：以 UTF-8 写入输出以避免 cp1252 编码错误（#10） 在 Windows 上，Path.write_text() 默认使用系统区域设置编码 （cp1252），无法编码输出中使用的 Unicode 字符 （例如 >= U+2265、-> U+2192）。传入 encoding="utf-8" 可确保文件 在所有平台上正确写入。

添加 MIT 许可证（#32）

docs：添加 HyperFrames 动画选项（#13）

fix(subtitles)：将 MarginV 提高到 90 以避开垂直安全区（#5） 随附的粗体叠加字幕样式使用 MarginV=35，这会将 字幕基线放在靠近底边的位置。在 1080×1920 垂直输出 （TikTok / IG Reels / YouTube Shorts / Snap）上，这正好位于 平台 UI 安全区内——字幕、用户名、音乐滚动条和右侧栏 操作大约覆盖画面底部 ~25–30%。上传后字幕会被 UI 裁剪或遮挡。 提高到 MarginV=90，使基线落在距底部约 30% 的位置， 避开每个主要垂直平台上的 UI。添加注释记录 理由，以免未来的编辑悄悄改回去。 Co-authored-by: Claude Opus 4.7 (1M context)

fix(render)：将 HLG/PQ 源色调映射到 Rec.709 SDR（#6） iPhone（以及许多无反相机）默认输出 HDR——iPhone 为 HLG， 其他为 PQ。当前流程通过 pix_fmt=yuv420p 转换位深， 但在输出上保留了 HDR 传输元数据（arib-std-b67 / smpte2084）。 遵循该元数据的播放器——屏幕录制器、几乎所有 社交上传的重新编码路径（TikTok、IG、YouTube、X）——会将 8 位 值解释为 HDR，并显示压暗、过饱和的颜色。 macOS 上的 QuickTime 恰好在播放时进行色调映射，这在本地 掩盖了该 bug。屏幕录制和上传的渲染则不能。 修复： - 通过 ffprobe color_transfer ∈ {smpte2084, arib-std-b67} 检测 HDR 源。 - 当为 HDR 时，在 vf 图中前置 zscale → tonemap=hable → bt709 链， 以便提取产生干净的 Rec.709 SDR，并带有正确的元数据。 - 对 SDR 源（大多数现有素材）为空操作。 在模块级暴露 `is_hdr_source()` 和 `TONEMAP_CHAIN`，以便下游 脚本可以复用该检测。 在 iPhone HLG 1080×1920 HEVC 素材上端到端验证： 之前：输出 pix_fmt=yuv420p，color_transfer=arib-std-b67（损坏） 之后：输出 pix_fmt=yuv420p，color_transfer=bt709（干净的 SDR） Co-authored-by: Claude Opus 4.7 (1M context)

添加 install.md 和一键粘贴设置提示（#9） 镜像 harnesless 入门模型，以便 Claude Code、Codex、Hermes、 Openclaw 等可以通过单个粘贴的提示安装 video-use。 install.md 处理克隆、依赖、ffmpeg、按代理注册 skill， 并引导用户粘贴他们的 ElevenLabs API 密钥。 Co-authored-by: Claude Opus 4.7 (1M context)

向 readme 添加 what-it-does 部分 Co-Authored-By: Claude Opus 4.6 (1M context)

精简 readme——先讲 get started，收紧 how-it-works Co-Authored-By: Claude Opus 4.6 (1M context)

重命名为 video-use + readme 主视觉 将包从 video-editor 重命名为 video-use。向 README 添加横幅截图 和独立的时间线视图 SVG。 Co-Authored-By: Claude Opus 4.6 (1M context)

海报

自评估循环

自动评分 + 自动声音

v1