如果你经常处理一批短视频素材，而不是单条精剪，那你一定体会过这种痛苦：同样的切割、转码、加片头、压分辨率，要在一堆文件上重复执行几百遍，但常规剪辑软件一次只能开一个项目，想批量自动化又离不开命令行写脚本。最近在 Hacker News 上冒出头的 Apollodorus Video，恰好踩在这个痛点上。它的定位非常清晰：做一个在浏览器里运行的批量视频编辑器，并且所有处理都在本地完成。
这个定位值得展开聊两层。第一层是“浏览器里做视频编辑”，这早就不是什么新鲜事，云剪辑产品遍地都是。第二层才是关键：数据不出本机、不传服务器、不依赖云端转码。这意味着它把过去“上传素材、云端排队、再下载结果”的流程，压缩成了“本地读取、本地计算、本地输出”。对开发者来说，这件事的价值不只是省一顿午饭时间，而是把视频批处理能力真正放到了用户手里。
这篇文章不会只贴一个“这个工具很好用”的结论。我会从需求匹配、运行原理、架构选型、代码实现到排错清单，完整拆解一条“浏览器本地批量视频处理”的技术路线。不管你是想用现成工具提效，还是想在自己的项目里复刻类似能力，都能从里面找到可落地的思路。
1. 批量视频编辑，为什么需要浏览器方案
先谈场景。很多人觉得视频处理就是打开剪辑软件一帧一帧抠，但现实中大量需求是“同质化操作 + 海量文件”。例如：
- 内容团队每天产出几十条短视频，需要统一加水印、片头和字幕。
- 测评团队录制了大量屏幕录像，需要批量裁剪黑边、压缩成统一分辨率。
- 自动化和数据标注系统生成上千段小片段，需要统一转码成模型可用的格式。
- 个人用户备份手机视频，需要把全家桶转成兼容性最好的 H.264 MP4。
这些需求用专业剪辑软件做，会把人逼疯。用 FFmpeg 命令行写循环脚本，确实能跑，但你要处理参数管理、失败重试、进度反馈、批量预览等问题，而且很多非技术同事根本不想开终端。
传统方案有两条路：一是本地桌面软件，二是云端视频处理。
本地桌面软件的问题不在于功能，而在于分发和跨平台。你要在 Windows、macOS、Linux 上分别维护版本，还要处理编码器依赖、显卡驱动差异。云端视频处理则要解决隐私和成本问题：素材上传通常很慢，视频数据涉及版权或隐私时更是雷区，而且转码是按时长计费的，批量跑一轮可能花不少钱。
Apollodorus Video 这类方案试图走第三条路：把 Web 浏览器当成运行时。浏览器本身就是跨平台分发器，用户打开一个页面就能用；视频数据在浏览器本地读取，通过 WebAssembly 或浏览器原生能力完成计算，结果直接落回本地。它兼具了桌面软件的控制权和 Web 的分发便利性，还避开了服务器成本。
当然，浏览器方案也有天然边界。它受浏览器安全模型限制，不能碰系统级文件权限以外的路径；性能受设备 CPU、GPU 和浏览器实现水平影响；编解码兼容性取决于浏览器内置能力。所以，用浏览器做视频批处理绝不是“把桌面软件搬上网页”这么简单，它是一整套工程取舍的结果。
2. 核心概念与运行原理
要理解这类工具，先要分清三个概念：在线视频编辑、桌面视频编辑、本地浏览器视频编辑。
在线视频编辑的典型模型是：前端负责交互和预览，后端负责真正的转码和合成。用户的视频必须先上传，处理任务在服务器队列里执行，结果再传回浏览器。离线视频编辑的典型模型是：软件直接调用操作系统的文件系统和硬件加速能力。本地浏览器视频编辑则是中间态，它复用了浏览器的页面与交互模型，但计算发生在本地设备上。
实现“浏览器本地跑视频处理”依赖几个关键技术。
第一是 WebAssembly。视频处理中大量计算密集的解码、缩放、编码操作，用纯 JavaScript 跑会慢到不可用。WebAssembly 可以让 C/C++ 编写的 FFmpeg 等库在浏览器里以接近原生的速度执行。这就解释了为什么会出现 ffmpeg.wasm 这类项目——它把完整的 FFmpeg 编译成了浏览器可加载的模块。
第二是浏览器原生视频解码能力。现代浏览器内置的 H.264、HEVC、VP9、AV1 解码器，已经覆盖了绝大多数日常视频格式。通过 WebCodecs 这样的 API，JavaScript 可以更底层地接入编码器和解码器，避免走视频元素播放的老路。
第三是文件系统访问。旧版浏览器处理文件只能靠<input type="file">选择后读取内容，而 File System Access API 允许网页在用户授权下访问本地目录和文件，这让“批量选择文件夹、批量导出到指定目录”成为可能。
第四是 Web Worker。视频的解码、转码、合成都非常耗时，如果全部跑在主线程上，页面会直接卡死。正确的做法是用 Web Worker 在后台线程执行计算，主线程只负责 UI 和任务调度。
从架构上看，一个本地浏览器批量视频编辑器大致可以拆成四层：UI 层负责文件选择、参数设置、进度展示；任务调度层负责把一堆文件变成待处理队列，并管理并发数量；处理引擎层负责解封装、解码、滤镜、编码、封装；I/O 层负责读取源文件、写入目标文件。理解了这四层，后面所有实现和排查思路都有地方安放了。
这里有一个容易误解的地方。很多人以为“浏览器本地处理”等于“零配置、开箱即用”，实际上浏览器出于安全策略，仍然需要用户主动授权文件访问。页面只能读取用户授权的文件，不能扫描整个磁盘。这个限制恰恰是隐私安全的底线，也是和桌面软件最大的体验差异之一。
3. 技术选型与架构设计要点
如果你打算在自己的项目里复刻类似能力，先把技术选型的大方向定下来，后面才不会走弯路。
3.1 处理引擎选型
浏览器里的视频处理引擎主要看三套方案。
| 方案 | 核心特点 | 适合场景 |
|---|---|---|
| FFmpeg.wasm | C/C++ 编译到 WebAssembly，功能全面，通用性强 | 需要兼容多种格式、滤镜、转码的批处理工具 |
| WebCodecs | 浏览器原生编解码 API，性能好，但封装、滤镜能力弱 | 性能敏感、格式可控的场景 |
| 纯 JavaScript 解码库 | 纯软件解码，兼容性有限 | 轻量预览、教学示例 |
FFmpeg.wasm 的优点是“全家桶”，几乎能覆盖你在桌面端 FFmpeg 能做的所有事，包括容器封装、滤镜链、编码器设置。缺点是包体积大、内存占用高，首次加载需要下载若干 MB 的 WASM 二进制，并且多进程并发时内存会翻倍。WebCodecs 更轻量，但通常需要配合 mp4box.js 这类封装库才能输出完整 MP4。实际项目里，很多人会选择“FFmpeg.wasm 处理复杂任务 + WebCodecs 做高性能转码”的混合路线。
3.2 任务处理架构
批量处理天然是并行友好的。但注意，视频转码是典型的 CPU 密集型任务，在浏览器里无脑开满并发，只会让用户电脑风扇起飞。合理的做法是控制并行度到 CPU 核心数附近，同时给任务队列设计优先级和中止机制。
一个比较实用的架构是一种“单引擎 Worker 池”模式。主线程维护任务队列，多个 Web Worker 各自持有一个 FFmpeg 实例，主线程把“文件 + 参数”派发给空闲 Worker，Worker 执行完再回报结果。这种方案避免了在单个 Worker 里串行处理导致的效率浪费，也避免了无限开 Worker 带来的内存失控。
3.3 文件访问与数据流
浏览器不能像桌面程序一样随便读写文件。一般做法是先用 File System Access API 让用户选择源文件夹，再创建目标文件夹句柄，处理时逐文件读取、逐文件写出。若浏览器不支持 File System Access API，就要退回到“文件选择器读取 + 自动下载”的方式，这种方式的副作用是文件会被下载到下载目录，而不是用户指定位置。
数据流上，尽量避免把整个视频一次性读进内存。多段几 GB 的高清视频，直接把 ArrayBuffer 全塞进内存会直接崩溃。更稳的路径是边读边写：从源文件读取分块，交给解码器，处理后再编码写出。实际工程量会大不少，但这正是桌面工具和网页玩具的分水岭。
4. 环境准备与前置条件
在动手实现之前，先确认你的环境满足这些条件。
- 现代 Chromium 内核浏览器优先支持，Chrome、Edge 是首选；Firefox 和 Safari 对 File System Access API 和部分底层 API 支持不一致。
- 页面需要通过 HTTPS 或 localhost 访问，普通 HTTP 页面拿不到文件系统权限。
- 设备要有足够的内存和 CPU 余量。处理 1080p 视频，建议至少 8GB 内存；4K 视频建议 16GB 以上。
- 版本细节以实际项目为准，本文重点演示通用思路，不绑定某个具体浏览器小版本。
如果你只是使用 Apollodorus Video，那么剩下的工作主要是导入素材、配置任务参数、启动处理。如果你要二次开发或复刻它，更关心的是底层的依赖管理和模块加载。
前端工程上，建议先把核心逻辑封装成纯 JavaScript 模块，不依赖框架，这样测试起来方便。UI 层可以随意选 React 或 Vue，但处理引擎和任务调度是纯逻辑，最好保持框架无关。
5. 核心流程拆解与示例代码
现在走一遍最小可用的实现路径。假设我们要实现一个非常简单的“批量转码工具”：用户选择一批 MP4 文件，设置统一的输出尺寸和码率，然后程序批量处理并输出到指定目录。
5.1 流程总览
整个流程拆成五步。
- 选择源文件或源文件夹，获得文件句柄列表。
- 配置输出参数：分辨率、码率、格式、输出目录。
- 创建任务队列，把每个文件变成一条独立任务。
- 启动 Worker 池，逐文件执行转码。
- 收集结果，在界面上展示成功和失败状态。
5.2 读取文件列表
使用 File System Access API 选择文件夹并递归读取视频文件，是最贴近批量场景的方式。
// 文件路径：src/file-access.js export async function pickVideoFolder() { const handle = await window.showDirectoryPicker(); const list = []; async function walk(entry) { for await (const [name, child] of entry.entries()) { if (child.kind === 'file') { if (/\.(mp4|mov|mkv|webm)$/i.test(name)) { list.push({ name, handle: child }); } } else if (child.kind === 'directory') { await walk(child); } } } await walk(handle); return list; }这段代码的核心是showDirectoryPicker，它需要用户点击授权。拿到目录句柄后，用entries()遍历目录，递归进入子目录，按后缀名过滤视频文件。注意这里没有读取文件内容，只是拿句柄，真正的 I/O 留到处理阶段。
5.3 配置 Web Worker 作为处理引擎
转码任务必须放到后台线程。下面是一个 Worker 的最小骨架，它接收“文件句柄 + 转码参数”，用 FFmpeg 执行完成后把结果传回主线程。
// 文件路径：src/transcode-worker.js import { FFmpeg } from '@ffmpeg/ffmpeg'; import { fetchFile } from '@ffmpeg/util'; let ffmpeg = null; async function loadFFmpeg() { if (ffmpeg) return ffmpeg; ffmpeg = new FFmpeg(); await ffmpeg.load({ coreURL: '/ffmpeg/ffmpeg-core.js' }); return ffmpeg; } self.onmessage = async (e) => { const { id, fileHandle, fileName, params } = e.data; try { const engine = await loadFFmpeg(); const file = await fileHandle.getFile(); const inputBuffer = await file.arrayBuffer(); const inputName = `input-${id}.mp4`; const outputName = `output-${id}.mp4`; await engine.writeFile(inputName, new Uint8Array(inputBuffer)); const args = ['-i', inputName, '-vf', `scale=${params.width}:${params.height}`, '-b:v', params.bitrate, '-y', outputName]; await engine.exec(args); const output = await engine.readFile(outputName); self.postMessage({ id, ok: true, data: output, fileName: outputName }, { transfer: [output.buffer] }); } catch (err) { self.postMessage({ id, ok: false, error: err.message }); } };这里有三个关键点。首先，loadFFmpeg用coreURL加载本地部署的 WASM 资源，避免每次任务都重复加载。其次，每个任务都要writeFile写入输入文件，执行完后readFile读取结果，这代表数据在浏览器内部其实经历了“磁盘 → 内存 → WASM 文件系统 → 内存”的拷贝，大文件会明显吃内存。第三，postMessage用transfer转移 ArrayBuffer 的所有权，减少一次结构拷贝。
5.4 主线程调度
主线程维护一个 Worker 池，把文件句柄逐个派发给空闲 Worker。
// 文件路径：src/batch-scheduler.js import { pickVideoFolder } from './file-access.js'; export function createScheduler(workerCount = 2) { const workers = []; const queue = []; let current = 0; for (let i = 0; i < workerCount; i++) { const w = new Worker(new URL('./transcode-worker.js', import.meta.url)); w.onmessage = (e) => { const task = currentQueue.get(e.data.id); currentQueue.delete(e.data.id); task.resolve(e.data); // 如果队列还有任务，继续派发 pushNext(); }; workers.push(w); } const currentQueue = new Map(); function pushNext() { if (queue.length === 0) return; const idleWorker = workers.find((w) => w.busy !== true); if (!idleWorker) return; const task = queue.shift(); idleWorker.busy = true; const id = ++current; currentQueue.set(id, task); idleWorker.postMessage({ id, fileHandle: task.fileHandle, fileName: task.fileName, params: task.params }); } function addTask(fileHandle, fileName, params) { return new Promise((resolve) => { queue.push({ fileHandle, fileName, params, resolve }); pushNext(); }); } return { addTask, get pendingCount() { return queue.length; } }; }调度器的核心原则是“队列驱动，有空闲就派发”。这里把busy标记挂到了 Worker 对象上，用 Map 保存尚未收到回调的任务。实际项目里还需要加入失败重试、超时控制、取消任务等逻辑，但最小模型已经能看出批量处理的骨架了。
5.5 保存结果
处理完的 ArrayBuffer 如果想写回用户指定的目录，可以使用文件句柄的createWritable。
// 文件路径：src/save-output.js export async function saveOutput(dirHandle, fileName, data) { const fileHandle = await dirHandle.getFileHandle(fileName, { create: true }); const writable = await fileHandle.createWritable(); await writable.write(data); await writable.close(); }注意，getFileHandle的create: true表示不存在就创建。如果目录句柄不可写，浏览器会抛安全错误，需要在 UI 层提前做好提示。这套读、算、写的闭环就是“浏览器本地批量视频处理”的完整最小实现。
6. 运行结果与效果验证
代码写完后，怎么知道真的跑通了？建议按以下步骤验证。
第一步，先用两个小文件跑通全流程。选择一个 5 秒左右的低分辨率视频，设置一个最简单的转码参数，比如统一缩放到 640x360、码率 1M。观察页面是否能生成输出文件，并检查输出文件能否正常播放。
第二步，验证批处理能力。选择包含 10 个文件的文件夹，启动任务后观察进度列表是否逐个完成，Worker 是否真正并行工作。可以在浏览器开发者工具里打开 Performance 面板，确认转码期间主线程没有长时间阻塞。
第三步，观察内存。打开 Task Manager（Chrome 自带）查看页面进程内存，处理大文件时如果内存曲线一路飙升，说明数据流设计存在问题，需要改成逐块读取方式，而不是一次性读入 ArrayBuffer。
判断成功的标准很简单：源文件没被动过，输出文件全部生成，且每个输出文件播放无异常。如果出现花屏、音画不同步、文件损坏，优先检查转码参数，尤其是-vf滤镜链和-b:v码率设置。
失败时第一步看哪里？看 Worker 回传的错误信息。FFmpeg 的错误通常会带明确的日志行，比如Invalid data found when processing input说明源文件读取或封装异常，Output file is empty说明转码任务执行失败。把错误信息完整打印到页面控制台，比蒙着眼睛猜环境问题高效得多。
7. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 文件夹选择按钮无反应 | 浏览器版本不支持 File System Access API | 检查是否使用最新 Chrome/Edge；查看控制台报错 | 升级浏览器或使用 localhost 测试 |
| 页面提示“需要 HTTPS” | 非安全上下文无法调用系统能力 | 确认页面地址是否为 https 或 localhost | 本地开发用 localhost，部署用 HTTPS |
| 转码过程浏览器卡死 | 任务跑在主线程，或 Worker 并发过高 | 打开 Performance 面板看主线程占用；观察 Task Manager | 把所有处理逻辑挪到 Worker，降低并发数 |
| 输出文件损坏或花屏 | 转码参数不兼容；输出格式封装错误 | 用单个文件复现，打印 FFmpeg 日志 | 检查滤镜参数和输出容器格式，尝试换编码器 |
| 处理 4K 视频内存暴涨 | 一次性把整个文件读入 ArrayBuffer | 查看 Task Manager 内存占用 | 改成流式或分块读写，或提示用户降低分辨率 |
| Worker 加载 WASM 失败 | WASM 文件路径配置错误或跨域 | 检查 Network 面板是否正确加载 core 文件 | 确保coreURL指向可访问的静态资源路径 |
| 输出目录写入失败 | 用户未授权目录写权限 | 捕获createWritable抛出的错误 | 引导用户重新授权，并给出明确错误提示 |
| 批量任务中途失败，后续任务全部卡住 | 缺少失败重试机制 | 检查当前 Worker 是否被死循环占用 | 给每个任务加超时，失败后回收 Worker 并重试 |
补充一个容易被忽视的问题：浏览器没有真正的“文件覆盖”语义。如果输出目录已经存在同名文件，createWritable会默认覆盖，但不同浏览器的行为略有差异。稳妥的做法是在输出文件名中加入时间戳或任务 ID，避免意外覆盖源素材。
另外，FFmpeg.wasm 在处理某些封装格式（比如 MKV 中的字幕轨）时可能不支持全功能。设计阶段就应该明确告诉用户：这个工具负责的是常见 MP4/WebM 场景，高级轨道路由不在范围内。
8. 最佳实践与工程建议
如果你真的要把“浏览器本地批量视频编辑”做到生产级，光有小示例还远远不够。下面是实际项目中更重要的工程建议。
8.1 数据安全与隐私边界
本地处理的核心卖点是隐私，但这不代表你可以松懈。浏览器页面仍然可能被 XSS 攻击，如果攻击者注入了恶意脚本，用户授权的文件可能被读取。因此，项目必须做到最小权限：不要请求用户授权整个磁盘，而是只授权源文件夹和目标文件夹；不要存明文路径到任何远端日志；不要引入第三方与本地文件交互的不可信脚本。
文档里还必须写明“永久删除文件”到底删的是哪个文件，避免用户误以为删除了浏览器缓存，实际删掉了磁盘原文件。这类工具涉及文件系统时，任何删除操作都应该先进入回收站或二次确认。
8.2 任务可恢复性
批量处理很可能跑一半断掉。浏览器标签页刷新，所有 Worker 状态全部丢失。生产级方案应该在 IndexedDB 中持久化任务队列和每项任务的执行状态，刷新后自动恢复未完成任务。任务进度也应当定期落盘，而不是只存在内存里。
8.3 性能与内存控制
不要把并行度设成固定值。用navigator.hardwareConcurrency获取 CPU 核心数，然后把 Worker 池上限设为核数减一，留出一个核心给 UI 线程。在分辨率超过 1080p 时，建议强制开启质量预设，避免用户误设成“原画质 + 原始码率”导致输出体积巨大。
加载 FFmpeg.wasm 的耗时也要考虑。首次访问可以先显示一个加载进度条，之后的访问通过浏览器的缓存机制会快很多。更进阶的做法是把常用滤镜和编码器参数做成模板，用户只点选项，不接触底层参数，这能大幅降低误操作概率。
8.4 UI 与交互建议
批量任务的反馈密度很关键。用户需要知道“现在处理到第几个文件、当前文件进度、失败了几条、失败原因是什么”。建议做成列表式任务面板，每个文件名旁边显示状态、耗时、大小变化。如果某个文件失败，支持单独重试和修改参数后重试。
同时，不要用“转圈”作为唯一反馈。视频处理动辄几十秒甚至几分钟，没有具体进度会让用户感觉完全失控。可以考虑分段进度：读取阶段、转码阶段、写出阶段各给一个百分比，这样用户能判断程序是不是“还在工作”。
8.5 兼容性策略
不要试图在所有浏览器上提供完全一致的能力。建议第一版只支持 Chromium 内核，Firefox 和 Safari 用户可以提示功能降级。如果项目希望兼容更多浏览器，可以做一个能力检测页面，在用户进入前就告诉浏览器支持到哪一步，而不是等用户选完文件才报错。
8.6 开源与二次开发
像 Apollodorus Video 这类项目，社区价值往往比工具本身更大。如果你基于它做二次开发，尽量保持核心模块和 UI 模块分离，这样底层的调度引擎可以复用，UI 层可以自由换肤改造。批量处理逻辑是通用资产，不要和某个框架绑定死。
9. 从使用工具到构建工具的延伸
Apollodorus Video 的出现，本质上反映了 Web 平台能力的一个重要变化：浏览器的计算边界正在从“表单和展示”扩展到“媒体处理”。过去你以为必须用桌面软件才能干的活，现在用 Web 技术栈也能完成；过去你担心上传视频泄露隐私，现在数据可以留在本机。
不过我也要泼一点冷水。浏览器本地视频处理不会完全替代桌面工具和云端服务。桌面工具在成熟度、硬件加速、专业编解码器支持上仍然领先；云端服务在“无需用户安装环境、随时随地处理”上依然有不可替代的价值。本地浏览器方案真正能赢的场景，恰恰是“快速分发 + 隐私敏感 + 批量操作”的交叉区间。
如果你从这篇文章只记住一件事，我希望是：不要在浏览器里把视频文件一次性读入内存再暴力处理。真正想做到够用、可用、好用，靠的是合理的任务调度、受限的并行度、清晰的错误反馈和诚实的兼容性策略。
下一步建议很具体：先用一个小工具跑通单文件转码，再扩展成任务队列，再补上目录选择和进度反馈，最后加入持久化和错误重试。这条路走完，你就拥有了自己的“浏览器本地批量视频工具”。遇到具体的报错，优先看 FFmpeg 日志和浏览器控制台，工具链的本质不会变：输入、处理、输出，只是这一次，它跑在了你的浏览器里。
