1. 从“video-use”这个标题说起它到底想解决什么问题第一次看到video-use这个标题我脑子里蹦出来的第一个念头是这大概率不是一个单纯的播放器也不是一个简单的视频剪辑脚本而更像是一套“让程序化视频生成这件事变得可复用、可组合”的工具集或者方法论。结合后面跟着的一串热词——Claude Code、ffmpeg、Remotion、Manim——这个判断基本就坐实了。video-use这个名字本身很朴素直译就是“视频使用”。但恰恰是这种朴素暴露了它的野心它不想只做某一个环节而是想把“视频”当成一种可以被代码调用的资源像调用一个函数一样去使用它。你可以把它理解成一个“视频能力中间层”——上游对接各种生成引擎Remotion 做网页式动画、Manim 做数学可视化、ffmpeg 做底层编解码下游对接各种自动化流程Claude Code 这类 AI 编程助手来写脚本、调参数、串流程最终让“做视频”这件事从手工活变成工程活。为什么我这么判断因为热词里同时出现了ffmpeg命令、ffmpeg m3u8转换mp4格式、ffmpeg推流到srs存在延迟这类偏底层的问题也出现了claude code skill、claude code怎么手动装github上的skills、claude code接入deepseek这类偏 AI 工作流的问题还有manim官网、Remotion这类偏内容生成的问题。这三类问题放在一起指向的只有一个场景用 AI 辅助写代码用代码驱动视频生成用 ffmpeg 做最后的封装和分发。所以这篇博文我不打算把它写成某个工具的说明书而是想把这套“video-use”思路拆开讲清楚它背后的技术选型逻辑、实操中真正会卡住你的地方以及我踩过的那些坑。适合谁看如果你是会一点命令行、想用代码批量做视频的开发者或者你是做数据可视化、教学视频、自动化报告的技术人再或者你只是好奇“AI 到底能不能帮我剪视频”这篇都能给你一条能走通的路。2. 整体设计思路为什么是 ffmpeg Remotion Manim 这个组合2.1 三层架构底层编解码、中层动画、上层智能调度我先把video-use这类项目的典型架构画在脑子里它基本是三层。最底层是ffmpeg。这一层负责所有“脏活累活”格式转换、裁剪拼接、码率控制、音频混流、字幕烧录、推流分发。ffmpeg 是这个领域事实上的标准没有之一。你可能会问为什么不用某个 Python 库直接封装因为一旦涉及到m3u8转换mp4、推流到srs、invalid argument这种问题你最终还是要回到 ffmpeg 的命令行参数上去调。与其隔一层不如直接掌握它。中间层是Remotion 和 Manim。这两个是“内容生成器”但定位完全不同。Remotion 是拿 React 写视频本质是把网页渲染成帧序列适合做那种带 UI 元素、图表、文字动效的“信息型视频”。Manim 是数学动画引擎适合做公式推导、几何变换、函数图像这类“教学型视频”。它们俩的共同点是用代码描述画面而不是用时间轴拖拽。这正是video-use的核心价值——视频内容变成可版本控制、可参数化、可批量生成的代码。最上层是Claude Code这类 AI 编程助手。它的作用不是直接生成视频而是帮你写 Remotion 组件、帮你拼 ffmpeg 命令、帮你排查报错。热词里claude code skill、claude code怎么手动装github上的skills说明很多人已经在尝试把常用视频处理逻辑封装成 skill让 AI 直接调用。这是很聪明的做法因为 ffmpeg 参数组合太多人记不住但 AI 可以。2.2 为什么不用“一站式”视频编辑软件有人会问既然要批量做视频为什么不用剪映、Premiere 的脚本功能我的实测结论是一旦视频数量超过 20 条或者内容需要根据数据动态变化传统软件的脚本能力就不够用了。它们的 API 要么封闭要么性能瓶颈明显要么无法在服务器上无头运行。而video-use这套组合的最大优势是全链路可无头运行。你可以在 Ubuntu 服务器上装好 ffmpeg、Node.js、Python然后让 Claude Code 写一个脚本自动拉数据、生成 Remotion 组件、渲染、再用 ffmpeg 压制和推流。整个过程不需要打开任何图形界面。这对于做自动化日报、数据播报、课程批量生成来说是质变。2.3 选型背后的取舍Remotion 还是 Manim这两个不是二选一而是按内容类型分工。我一般这样判断内容类型推荐引擎理由数据图表、UI 动效、文字排版RemotionReact 生态CSS 布局能力强适合信息密度高的画面数学公式、几何动画、函数图像Manim专为数学可视化设计坐标系和变换开箱即用纯剪辑、拼接、转码、推流ffmpeg底层能力最全性能最好需要 AI 动态生成脚本Claude Code 上述三者AI 负责写代码和调参引擎负责渲染这个表格看起来简单但实际项目里最容易犯的错就是拿 Remotion 去硬做数学动画或者拿 Manim 去做复杂 UI。前者会让你在坐标系上浪费大量时间后者会让你在文字排版上崩溃。选对引擎项目就成功了一半。3. 核心细节解析ffmpeg 那些绕不开的参数与坑3.1 ffmpeg 安装Windows 和 Ubuntu 的差异热词里ffmpeg安装、ffmpeg下载官网、ffmpeg master latest win64 essentials.zip、ubuntu安装claude code同时出现说明很多人卡在环境准备这一步。我分别说。Windows 下官方推荐的是ffmpeg-master-latest-win64-gpl.zip或者essentials版本。下载后解压把bin目录加到系统 PATH 里。这里有个细节essentials 版本不含某些非自由编解码器如果你要处理 H.265 或者某些特殊封装建议用 full 版本。加完 PATH 后一定要新开一个终端验证因为旧终端不会刷新环境变量。Ubuntu 下就简单很多sudo apt install ffmpeg基本够用。但如果你需要最新特性比如某些滤镜或者硬件加速建议用官方静态编译包或者自己编译。热词里【跨平台交叉编译】android 编译 x264 ffmpeg 万字完结篇和ffmpeg for android已编译说明移动端也有需求但那属于另一个话题本文聚焦桌面和服务端。提示安装完成后用ffmpeg -version和ffmpeg -codecs确认版本和编解码器支持情况。很多人装完不验证结果跑到一半才发现不支持某个格式。3.2 常用命令拆解从 m3u8 转 mp4 说起ffmpeg m3u8转换mp4格式是高频需求。最基础的命令是ffmpeg -i input.m3u8 -c copy output.mp4-c copy表示不重新编码直接复制流。这速度快但前提是 m3u8 里的分片格式和 mp4 容器兼容。如果遇到invalid argument大概率是分片编码和容器不匹配这时候要去掉-c copy让它重新编码ffmpeg -i input.m3u8 -c:v libx264 -c:a aac -strict experimental output.mp4这里-strict experimental是老版本 aac 编码器的兼容参数新版本一般不需要。我实测下来重新编码虽然慢但兼容性最好尤其是处理来源不明的 m3u8 时。3.3 推流延迟为什么 ffmpeg 推流到 srs 会有延迟ffmpeg推流到srs存在延迟这个问题我踩过不止一次。延迟来源通常有三个编码缓冲、网络传输、播放器缓冲。编码端ffmpeg 默认会做一定量的缓冲来保证画质。你可以通过-tune zerolatency和-preset ultrafast来降低编码延迟ffmpeg -re -i input.mp4 -c:v libx264 -preset ultrafast -tune zerolatency -c:a aac -f flv rtmp://server/live/stream-re表示按原始帧率读取模拟直播节奏。如果不加-reffmpeg 会以最快速度推流导致服务端缓冲暴涨。网络端如果是内网延迟主要来自 TCP 缓冲。可以尝试调整-buffer_size和-max_delay。播放端很多播放器默认缓冲 3 到 5 秒这个要在播放器侧调不是 ffmpeg 的问题。注意降低延迟和保证画质是一对矛盾。ultrafast会明显增大码率如果带宽不够反而会卡顿。我的经验是先保证网络稳定再逐步调低延迟参数。3.4 硬件加速rk3588 上的 ffmpeg 推流热词里rk3588 ffmpeg推流说明有人在嵌入式板子上做推流。rk3588 有硬件编码器用h264_rkmpp或者hevc_rkmpp可以大幅降低 CPU 占用ffmpeg -i input.mp4 -c:v h264_rkmpp -b:v 4M -c:a copy -f flv rtmp://server/live/stream但硬件编码器的参数和软件编码器不完全一样比如-preset可能不支持。建议先用ffmpeg -encoders | grep rkmpp确认支持情况再逐步调参。我见过有人直接套用 x264 的参数结果报错半天找不到原因。4. 实操过程用 Claude Code 驱动 Remotion 和 Manim 生成视频4.1 环境准备Claude Code 的安装与配置热词里claude code安装、claude code使用教程、vscode配置claude code、windows安装claude code、ubuntu安装claude code全都有说明这是当前最热的入口。我按我的实际配置流程说。Claude Code 本质上是一个命令行工具通过 npm 安装npm install -g anthropic-ai/claude-code安装完成后在项目目录下运行claude即可启动。VSCode 里可以装对应插件实现编辑器内调用。Ubuntu 和 Windows 的安装方式基本一致前提是 Node.js 版本不要太老建议 18 以上。提示热词里有一条note: claude code might not be available in your country. check supported co这说明可用性受地区限制。如果你遇到无法使用的情况建议先确认官方支持范围不要盲目折腾。配置好后我一般会先让它做一件小事读一个 ffmpeg 报错日志然后给出修复命令。这一步能快速验证它是否理解你的上下文。4.2 用 Claude Code 写 Remotion 组件Remotion 的项目初始化npx create-videolatest然后让 Claude Code 帮你写一个带动态数据的组件。比如你要做一个“每日数据播报”视频可以这样描述需求写一个 Remotion 组件接收一个 JSON 数组每个元素包含日期和数值用柱状图展示带入场动画时长 10 秒30fps。Claude Code 会生成对应的 React 组件和Composition配置。你只需要把数据传进去运行npx remotion render就能出片。这里的关键是把需求描述得足够具体。我试过只写“做一个图表视频”结果生成的组件很泛改起来比自己写还慢。后来我总结了一个模板输入数据结构 视觉形式 动画要求 时长帧率四要素齐全生成质量明显提升。4.3 用 Manim 做数学动画的实操要点Manim 的安装pip install manim然后写场景类from manim import * class FunctionPlot(Scene): def construct(self): axes Axes(x_range[-3, 3], y_range[-1, 9]) graph axes.plot(lambda x: x**2, colorBLUE) self.play(Create(axes), Create(graph)) self.wait()渲染命令manim -pql scene.py FunctionPlot-pql表示预览、低质量。正式输出用-pqh高质量。我踩过的坑是Manim 的坐标系和 Remotion 的像素坐标系完全不同不要试图把两者的参数混用。另外Manim 渲染比较吃 CPU批量生成时建议排队执行不要并发太多。4.4 用 ffmpeg 做最终封装与分发Remotion 和 Manim 输出的都是视频文件最后一步通常是用 ffmpeg 做统一封装。比如把多个片段拼接ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4list.txt里每行写file xxx.mp4。如果要加背景音乐ffmpeg -i video.mp4 -i audio.mp3 -c:v copy -c:a aac -shortest output.mp4-shortest表示以较短的流为准避免音频比视频长导致黑屏。如果要烧录字幕ffmpeg -i video.mp4 -vf subtitlessub.srt output.mp4这些命令看起来简单但组合起来就能覆盖 80% 的后期需求。我的建议是把常用命令封装成 shell 脚本或者 Claude Code 的 skill用的时候直接调用不要每次手敲。5. 常见问题与排查技巧实录5.1 ffmpeg 报错速查表报错信息常见原因解决方法Invalid argument参数不匹配或流格式不支持去掉-c copy改用重新编码Unknown encoder编解码器未安装检查ffmpeg -codecs安装对应库No such filter滤镜未编译进当前版本换 full 版本或重新编译Connection refused推流地址不可达检查服务端和网络Conversion failed输入文件损坏或格式异常用ffprobe检查输入流5.2 Claude Code 使用中的典型问题热词里claude code怎么手动装github上的skills、claude code skill、claude code接入deepseek、claude code接deepseek说明大家在扩展能力上花了不少心思。我的经验是skill 的本质是预置的提示词和工具调用逻辑手动安装就是把对应文件放到指定目录然后在配置里注册。接入其他模型要谨慎不同模型对工具调用的支持程度不一样ffmpeg 这种需要精确参数的任务模型能力不足时反而添乱。不要指望 AI 一次写对复杂 ffmpeg 命令我的做法是让它先给方案我再人工核对参数确认无误再执行。5.3 渲染性能优化的几个实操心得批量生成视频时性能是绕不开的。我总结了几条Remotion 渲染用--concurrency控制并发不是越高越好超过 CPU 核心数反而变慢。Manim 用-ql先出低质量预览确认动画逻辑无误后再出高质量避免浪费时间。ffmpeg 编码用硬件加速如果机器支持 NVENC 或者 rkmpp优先用硬件编码。中间文件用无损格式比如prores或者ffv1最后一步再压成h264避免多次有损压缩导致画质下降。注意中间文件很占磁盘批量任务前先确认剩余空间。我见过因为磁盘满导致渲染中断的情况排查了半天才发现是空间问题。5.4 跨平台编译的坑热词里【跨平台交叉编译】android 编译 x264 ffmpeg 万字完结篇和ffmpeg 编译dll库说明有人在做交叉编译。这块我的建议是除非必要不要自己编译。交叉编译 ffmpeg 涉及工具链、依赖库、配置参数一大堆很容易卡在某个库的版本兼容上。优先用官方预编译包或者社区维护的构建能省下大量时间。如果确实要编译记住顺序先编译 x264 等基础库再编译 ffmpeg并且--enable-shared和--enable-static要按需求选。Android 平台还要注意 NDK 版本和 API level 的匹配。6. 我对 video-use 这套思路的个人体会把视频当成代码来写这件事我一开始是怀疑的。毕竟传统剪辑软件那么直观为什么要绕这么大一圈但当我真正用 Remotion 批量生成了几十条数据播报视频用 Manim 自动出数学课件再用 ffmpeg 一条命令完成封装和推流之后我回不去了。这套video-use思路最大的价值不是省了某一次剪辑的时间而是让视频生产变成了可积累的资产。你写的组件、封装的命令、调好的参数下次直接复用。数据变了视频自动变。这种“一次投入长期收益”的模式是手工剪辑永远做不到的。当然它也有门槛。你得会一点命令行得理解 ffmpeg 的基本参数得能看懂 React 或者 Python 代码。但好消息是Claude Code 这类工具正在快速降低这个门槛。你不需要成为 ffmpeg 专家只需要能描述清楚需求剩下的可以交给 AI 去写、去调、去排查。最后分享一个小技巧把你最常用的 ffmpeg 命令和 Remotion 组件模板整理成一个自己的 skill 库放在项目目录里。每次新任务先让 Claude Code 读这个库再让它生成新代码。这样它的输出会越来越贴合你的习惯返工率会明显下降。这个习惯我坚持了几个月现在做一条新视频的平均时间从最初的半天压缩到了二十分钟以内。