1. 从“video-use”这个标题说起它到底想解决什么问题第一次看到video-use这个标题我脑子里蹦出来的不是某个具体库而是一类非常典型的工程需求用代码把视频“用起来”。不是剪辑软件里拖时间线那种用法而是把视频当成一种可编程的数据流交给脚本、交给命令行、交给自动化流程去处理。这个标题背后站着的其实是三条技术线的交汇——以ffmpeg为代表的底层音视频处理以Remotion为代表的“用前端技术写视频”以及以Manim为代表的“用代码生成数学动画”。而把这些串起来的那根线最近越来越多地落在Claude Code这类终端里的 AI 编程助手上。我先把话说在前面video-use不是一个我能在官方仓库里翻到的知名项目名它更像是一个自建工具集或者内部脚本集合的命名。所以这篇东西我不会假装它有个现成的 README 让我抄而是按一个真实从业者拿到这个标题后会怎么拆、怎么搭、怎么踩坑来讲。你如果正在做类似的事——比如想给自己攒一套“输入一段素材或一段描述输出一段成片”的流水线——那这篇基本可以当施工图看。它解决的问题很具体视频处理这件事重复劳动太多而可复用的自动化太少。剪一个 30 秒的演示片手动做要半小时但如果你的素材是结构化的、模板是固定的用 ffmpeg 加一层脚本可能 10 秒就跑完了。video-use的核心价值就在这个“把一次性劳动变成可重复执行的命令”上。适合谁看三类人一是会写点代码但没系统搞过音视频的开发者二是做内容但被重复剪辑折磨的运营或创作者三是想拿 Claude Code 这类工具把零散命令串成工作流的人。基础要求不高能看懂命令行、知道cd和管道符是干嘛的就够开始了。2. 整体设计思路为什么是 ffmpeg Remotion Manim 这个组合2.1 三条技术线各自的定位别混着用很多人一上来就想找一个“全能工具”结果发现哪个都不顺手。我的经验是这三样东西的边界其实非常清晰分清楚了架构自然就出来了。ffmpeg是地基。它管的是已经存在的音视频数据——转码、裁剪、拼接、抽帧、加音轨、压码率、改封装格式。它的强项是“处理”弱项是“从零创造画面”。你让它把一段 4K 压成 1080p它一秒能处理几十帧但你让它画一个带缓动动画的标题那就纯属为难它了。Remotion是“用 React 写视频”。它的思路很讨巧视频本质上就是“时间轴上的帧序列”那我用 React 组件描述每一帧长什么样给定帧号frame组件渲染出对应画面逐帧截图再合成就是视频。它的强项是模板化、数据驱动——比如你要给 100 个商品各生成一条 15 秒短视频模板写一次数据喂进去批量出片。弱项是渲染慢因为它本质是逐帧截图复杂动画跑起来 CPU 直接拉满。Manim是“用 Python 写数学动画”。它专治那些“用普通剪辑软件做起来要命”的东西——公式推导、坐标系变换、几何证明的动态演示。它的强项是精确的数学表达和优雅的动画曲线弱项是通用性差你拿它剪 vlog 就是杀鸡用牛刀。所以video-use的合理架构应该是ffmpeg 做前后处理和素材规整Remotion 做模板化批量出片Manim 做需要精确数学表达的特殊片段最后再回到 ffmpeg 合成。三者不是竞争关系是流水线上的不同工位。2.2 为什么把 Claude Code 放进这条链路这里得说清楚Claude Code 在这套体系里不是“视频处理工具”它是编排层和胶水层。视频处理最烦人的地方在于命令参数多、报错信息晦涩、不同素材要微调参数。以前你得翻文档、试参数、看日志一轮下来半小时没了。Claude Code 这类终端 AI 助手的价值在于你可以用自然语言描述意图它帮你生成 ffmpeg 命令、帮你写 Remotion 组件骨架、帮你排查Invalid argument这种经典报错。我实测下来它在“把模糊需求翻译成具体命令”这件事上确实省时间尤其是 ffmpeg 那种参数组合爆炸的场景。但要注意它生成的东西必须你自己验证尤其是涉及滤镜链和编码参数的地方它偶尔会给你一个语法正确但语义不对的命令。2.3 方案选型的核心权衡可控性 vs 效率我见过两种极端做法。一种是全手动每个视频都开剪辑软件拖可控性拉满但效率为零另一种是全自动写个脚本一把梭效率高但一出问题就抓瞎。video-use的合理定位在中间把高频、结构化的部分自动化把低频、创意性的部分留给人。具体来说转码、加水印、统一分辨率、批量切片这些闭着眼睛自动化片头片尾的创意、节奏的把控、情绪的铺垫这些还是得人来。判断标准很简单这个操作你是不是每次都在重复做同样的动作是就自动化不是就别硬上。我踩过的坑就是一开始想把所有东西都脚本化结果维护脚本的时间比手动做还长得不偿失。3. 核心细节解析ffmpeg 命令里那些没人告诉你的门道3.1 转码参数怎么选别只会 -c copy新手最容易犯的错就是看到-c copy就到处用。-c copy是流复制不重新编码速度快、无损但它有个硬性前提目标封装格式必须支持源流的编码格式。你把 H.265 的视频往某些老容器里塞它直接报错。而且-c copy做不了任何画面处理裁剪、缩放、加滤镜统统不行。真正要处理画面时你得重新编码。这时候参数选择就有讲究了参数作用常用取值我的建议-c:v视频编码器libx264 / libx265 / libvpx-vp9通用选 libx264兼容性最好-crf恒定质量因子0-51越小越清晰18-23 是甜点区23 是默认-preset编码速度档ultrafast 到 veryslow用 medium快慢平衡-c:a音频编码器aac / libopusaac 兼容性无敌-b:a音频码率128k / 192k128k 够用192k 更稳-crf这个参数值得单独说。它不是“质量百分比”而是“质量因子”数值越小质量越高、文件越大。很多人以为设成 0 就是无损其实不是0 只是“数学上最接近无损”文件会大到离谱。我一般用 20 做存档23 做发布28 做预览。-preset影响的是编码时搜索最优压缩方式的努力程度veryslow比medium能省大概 10% 体积但耗时可能翻三倍日常用medium就行。3.2 滤镜链的写法顺序决定结果ffmpeg 的-vf滤镜链是很多人绕不过去的坎。核心规则就一条滤镜按从左到右的顺序执行前一个的输出是后一个的输入。顺序错了结果完全不一样。举个例子你要把视频缩放再裁剪# 正确先缩放再裁剪 ffmpeg -i input.mp4 -vf scale1280:720,crop640:480:0:0 output.mp4 # 错误先裁剪再缩放裁剪坐标基于原始尺寸容易裁歪 ffmpeg -i input.mp4 -vf crop640:480:0:0,scale1280:720 output.mp4再比如加文字水印drawtext滤镜的参数多到让人头大ffmpeg -i input.mp4 -vf drawtexttextMyBrand:fontfile/path/to/font.ttf:fontsize36:fontcolorwhite:xw-tw-20:y20 output.mp4这里xw-tw-20的意思是“视频宽度减去文字宽度再减 20 像素”也就是右上角留 20 像素边距。w和tw是 ffmpeg 内置变量分别代表视频宽度和文字宽度。这种表达式写法是 ffmpeg 的精髓学会了能省很多事。注意drawtext依赖 libfreetype 库有些精简版 ffmpeg 编译时没带这个库会直接报 “No such filter”。装之前先ffmpeg -filters | grep drawtext确认一下。3.3 抽帧和合成把视频拆成图片再拼回去video-use里很常见的一个操作是“抽帧处理再合成”。比如你要给每一帧加个滤镜或者做逐帧分析。抽帧命令# 每秒抽 1 帧 ffmpeg -i input.mp4 -vf fps1 frames/frame_%04d.png # 抽所有帧 ffmpeg -i input.mp4 frames/frame_%04d.png%04d是序号占位符会生成frame_0001.png、frame_0002.png这样的文件名。合成回去ffmpeg -framerate 30 -i frames/frame_%04d.png -c:v libx264 -crf 20 output.mp4这里-framerate必须和抽帧时的帧率对应否则速度会不对。我踩过的坑是抽帧时用了fps1合成时忘了改-framerate结果 30 秒的视频变成了 1 秒的幻灯片。3.4 音频处理别让音画不同步毁了一切音画不同步是视频处理里最烦人的问题之一。常见原因有三个一是抽帧合成时帧率没对齐二是音频编码有延迟三是用了-ss和-t做裁剪时时间点没算准。我的做法是音频和视频分开处理最后再合并。这样每一步都可控# 提取音频 ffmpeg -i input.mp4 -vn -c:a copy audio.aac # 处理视频不带音频 ffmpeg -i input.mp4 -an -vf scale1280:720 video.mp4 # 合并 ffmpeg -i video.mp4 -i audio.aac -c:v copy -c:a copy output.mp4-vn是“不要视频”-an是“不要音频”。分开处理的好处是如果音频有问题你不用重新跑一遍视频处理省时间。4. 实操过程从零搭一条可复用的视频处理流水线4.1 环境准备ffmpeg 装对版本比装最新版重要先说 ffmpeg 的安装。Windows 上很多人去官网下ffmpeg-master-latest-win64-essentials.zip解压后把bin目录加到 PATH 里。这个流程没问题但有个细节essentials 版本是精简版很多滤镜和编码器没带。如果你要用drawtext、libx264之外的东西建议下 full 版本或者用包管理器装。Ubuntu 上就简单了sudo apt update sudo apt install ffmpeg但 apt 源里的版本通常偏旧。要新版本的话可以用静态编译包解压后软链到/usr/local/bin。验证安装ffmpeg -version ffmpeg -encoders | grep 264 ffmpeg -filters | grep drawtext这三条命令分别确认版本、编码器支持、滤镜支持。我见过太多人装完发现某个滤镜用不了回头查半天其实就是版本问题。Claude Code 的安装这里不展开具体步骤核心思路是它是一个终端工具装完之后你在项目目录里直接调用它会读取当前目录的上下文。所以用之前先cd到你的视频项目目录让它能看到你的素材和脚本。4.2 目录结构设计别把素材和输出混在一起一个能长期用的视频流水线目录结构必须清晰。我的习惯是这样video-use/ ├── input/ # 原始素材只读不改 ├── work/ # 中间产物可随时删 ├── output/ # 最终成品 ├── scripts/ # 处理脚本 ├── assets/ # 字体、水印、音效等静态资源 └── config/ # 参数配置input目录设成只读是为了防止手滑覆盖原始素材。work目录放中间文件比如抽出来的帧、分离的音轨这些都可以重新生成所以可以放心清理。scripts里放你的处理脚本每个脚本做一件事用文件名说明用途比如transcode_1080p.sh、add_watermark.sh。4.3 写第一个可复用脚本批量转码假设你有一堆手机拍的视频分辨率乱七八糟想统一成 1080p。手动一个个转太蠢了写个脚本#!/bin/bash # scripts/batch_transcode.sh INPUT_DIR./input OUTPUT_DIR./output CRF23 PRESETmedium mkdir -p $OUTPUT_DIR for file in $INPUT_DIR/*.mp4 $INPUT_DIR/*.mov; do [ -e $file ] || continue filename$(basename $file) name${filename%.*} echo Processing: $filename ffmpeg -i $file \ -vf scale1920:1080:force_original_aspect_ratiodecrease,pad1920:1080:(ow-iw)/2:(oh-ih)/2 \ -c:v libx264 -crf $CRF -preset $PRESET \ -c:a aac -b:a 128k \ -y $OUTPUT_DIR/${name}_1080p.mp4 done这个脚本里有个关键点scale后面跟了force_original_aspect_ratiodecrease和pad。这是干嘛的因为手机视频比例五花八门直接scale1920:1080会把画面拉变形。正确做法是先等比缩放到能放进 1080p 框里再用黑边补齐。pad的参数(ow-iw)/2:(oh-ih)/2是让画面居中ow/oh是输出宽高iw/ih是输入宽高。提示-y是覆盖已存在文件时不询问。批量脚本里必须加否则跑到一半卡在确认提示上。4.4 用 Remotion 做模板化出片Remotion 的安装和初始化npx create-videolatest它会问你选模板选 blank 就行。核心概念是Composition你定义一个组件告诉它视频多长、多少帧、什么尺寸// src/Root.jsx import { Composition } from remotion; import { MyVideo } from ./MyVideo; export const RemotionRoot () { return ( Composition idMyVideo component{MyVideo} durationInFrames{150} fps{30} width{1920} height{1080} defaultProps{{ title: 默认标题 }} / ); };durationInFrames{150}配合fps{30}就是 5 秒视频。组件里用useCurrentFrame()拿到当前帧号用interpolate()做插值动画import { useCurrentFrame, interpolate } from remotion; export const MyVideo ({ title }) { const frame useCurrentFrame(); const opacity interpolate(frame, [0, 30], [0, 1], { extrapolateRight: clamp, }); return ( div style{{ flex: 1, backgroundColor: #111, justifyContent: center, alignItems: center }} h1 style{{ color: white, opacity }}{title}/h1 /div ); };interpolate的意思是在第 0 帧到第 30 帧之间把值从 0 线性映射到 1extrapolateRight: clamp保证超过 30 帧后不再继续增大。这就是最基础的淡入效果。渲染命令npx remotion render MyVideo output/video.mp4Remotion 的坑在于渲染速度。它默认用无头浏览器逐帧截图复杂页面一帧可能要几百毫秒。优化手段有减少 DOM 复杂度、避免用重型 CSS 效果、开--concurrency并行渲染。我实测下来一个简单模板 5 秒视频大概 20 秒渲染完能接受但如果你要批量出 100 条就得考虑上服务器或者用它的 Lambda 方案了。4.5 Manim 做数学动画片段Manim 的安装稍微麻烦点因为它依赖一堆科学计算库pip install manim装完验证manim --version一个最简单的场景from manim import * class FormulaScene(Scene): def construct(self): formula MathTex(rE mc^2) self.play(Write(formula)) self.wait(1) self.play(formula.animate.to_edge(UP)) self.wait(1)渲染manim -pql scene.py FormulaScene-pql是“预览、低质量”的意思快速看效果用。正式出片用-pqh高质量。Manim 的输出是无声视频你后面得用 ffmpeg 把音轨合进去。Manim 和 Remotion 的定位区别在于Manim 擅长“数学上精确”的动画Remotion 擅长“设计上灵活”的动画。你要画一个抛物线运动Manim 几行代码就搞定而且曲线绝对准确你要做一个带品牌色的动态标题Remotion 更顺手。4.6 用 ffmpeg 做最终合成假设你有三段素材片头Remotion 出的、主体实拍、片尾Manim 出的。合成命令# 先统一格式 ffmpeg -i intro.mp4 -vf scale1920:1080,fps30 -c:v libx264 -crf 20 -an intro_norm.mp4 ffmpeg -i main.mp4 -vf scale1920:1080,fps30 -c:v libx264 -crf 20 -an main_norm.mp4 ffmpeg -i outro.mp4 -vf scale1920:1080,fps30 -c:v libx264 -crf 20 -an outro_norm.mp4 # 拼接 ffmpeg -f concat -safe 0 -i filelist.txt -c copy merged.mp4 # 加音轨 ffmpeg -i merged.mp4 -i bgm.aac -c:v copy -c:a aac -shortest final.mp4filelist.txt内容file intro_norm.mp4 file main_norm.mp4 file outro_norm.mp4-shortest的意思是“以最短的流为准”防止音频比视频长导致结尾黑屏。5. 常见问题与排查技巧实录5.1 ffmpeg 报错速查表报错信息常见原因解决方法Invalid argument参数拼写错误或值超范围逐段检查命令用-v verbose看详细日志No such filter滤镜未编译进当前版本换 full 版本或重新编译Unknown encoder编码器不支持ffmpeg -encoders查可用编码器moov atom not found文件损坏或未完整下载用-err_detect ignore_err尝试修复Conversion failed通常是滤镜链问题拆开滤镜逐个测试Invalid argument这个报错我遇到最多。它特别笼统什么原因都可能。我的排查套路是先把命令简化到最小可运行版本再逐步加参数。比如一个复杂的滤镜链报错先只留第一个滤镜跑通了再加第二个这样能快速定位是哪个环节的问题。5.2 推流延迟问题热词里提到“ffmpeg 推流到 srs 存在延迟”这是个经典问题。延迟来源通常有三个编码缓冲、网络传输、播放器缓冲。ffmpeg 这边能做的优化ffmpeg -re -i input.mp4 \ -c:v libx264 -preset ultrafast -tune zerolatency \ -c:a aac -b:a 128k \ -f flv rtmp://server/live/stream-re是“按实际帧率读取”防止推太快。-tune zerolatency是让编码器不做前瞻缓冲牺牲一点压缩率换低延迟。-preset ultrafast同理。但要注意这些参数会让码率变高、画质略降是典型的“延迟换质量”权衡。5.3 Remotion 渲染失败的排查Remotion 渲染失败最常见的原因是浏览器环境问题。它依赖 Chromium如果系统缺依赖库会启动失败。排查步骤先跑npx remotion preview看能不能打开预览预览能开说明浏览器没问题。预览能开但渲染失败多半是资源路径问题检查staticFile()的用法。渲染到一半卡住看是不是某个组件里有死循环或者异步没处理好。我踩过的一个坑是组件里用了setTimeout做动画结果渲染时因为是无头环境定时器行为不一致导致帧对不上。Remotion 里所有动画都必须基于useCurrentFrame()不能用时间相关的 API这是铁律。5.4 我的独家避坑清单永远保留原始素材。处理前先备份或者把 input 目录设成只读。我有次手滑把原始素材覆盖了哭都来不及。命令先小范围测试。批量处理 100 个文件前先拿 1 个跑通确认参数没问题再全量跑。中间产物用无损格式。抽帧用 PNG 不用 JPG中间视频用高码率或无损最后一步再压缩。这样多次处理不会累积画质损失。日志要留。脚本里加21 | tee log.txt出问题能回溯。Claude Code 生成的命令必须验证。它有时候会给你一个看起来对但实际有问题的命令尤其是涉及滤镜链和路径的地方。我的习惯是让它生成后自己再逐参数过一遍。6. 工具选型与扩展这套东西还能怎么长6.1 什么时候该上 Remotion什么时候该用纯 ffmpeg判断标准很简单画面内容是不是“数据驱动”的。如果你要给 50 个不同的产品各生成一条视频模板一样只是文字和图片不同那 Remotion 是正解。如果你只是把一段视频转个码、加个水印那 ffmpeg 一行命令搞定上 Remotion 纯属折腾。我见过有人用 Remotion 做简单的视频拼接结果渲染慢得要死其实 ffmpeg 的concat几秒就完事了。工具要匹配场景不是越高级越好。6.2 Manim 的适用边界Manim 最适合的场景是教育类、科普类内容尤其是涉及公式、图表、几何的内容。它的动画曲线是经过数学设计的看起来就是比手动 K 帧舒服。但如果你要做的是实拍剪辑、vlog、产品宣传片Manim 基本用不上。另外 Manim 的学习曲线不低它有一套自己的坐标系和动画系统得花时间熟悉。我的建议是先看官方示例库找到和你需求最接近的那个改着用别从零开始啃文档。6.3 把 Claude Code 用成“视频处理副驾驶”Claude Code 在这套流程里最实用的三个场景第一生成 ffmpeg 命令。你描述需求它出命令你验证。比翻文档快。第二写脚本骨架。比如“写一个 bash 脚本遍历 input 目录下所有 mp4转成 720p输出到 output”它能给你一个基本可用的框架你再改细节。第三排查报错。把报错信息贴给它它通常能给出几个可能原因和排查方向。但记住它的答案要交叉验证尤其是涉及具体参数值的地方。注意Claude Code 生成的内容质量和你给的上下文强相关。用之前先cd到项目目录让它能看到你的文件结构这样生成的命令路径才不会错。6.4 后续扩展方向这套流水线搭起来之后能扩展的方向不少。比如加一个素材自动分类环节用 ffprobe 读取每个视频的分辨率、时长、编码格式自动决定用哪套参数处理。再比如加一个质量检测环节处理完后自动抽几帧对比原始素材确认没有明显画质损失。还有一个我觉得很有价值的方向是模板参数化。把 Remotion 的模板做成配置文件驱动改 JSON 就能换文案、换配色、换时长非技术人员也能出片。这个在批量内容生产场景下特别实用。说到底video-use这类东西的核心不是某个具体工具而是把视频处理从“手工活”变成“工程活”的思路。工具会变ffmpeg 的参数会更新Remotion 的 API 会调整但“结构化、可复用、可验证”这三个原则不会变。我自己的体会是前期花时间把流水线搭好后面每做一个视频省下的时间都是纯赚的。