浏览器本地批量视频编辑：技术原理与最小Demo实现

当第一次看到 Apollodorus Video 这个项目时，最值得关注的点不是它做了多少花哨的滤镜，而是它把“批量视频编辑”和“浏览器本地运行”这两件事放在了一起。传统视频批处理要么依赖安装客户端软件，要么把素材上传到云端转码服务；而一个运行在浏览器里、不把视频传出去的批量编辑器，在课程录制、短视频素材整理、内部培训视频打水印等场景里有非常明确的落地价值。

这篇文章会围绕“批量视频编辑、浏览器、本地运行”三个关键点展开，先拆解这类工具的技术链路，再给出一个最小可运行的批量加水印 Demo，然后讨论从原型走向生产工具时需要考虑的性能、兼容性和排错问题。无论你是想自己实现一个类似工具，还是在调研“能不能在浏览器里完成本地视频批处理”，本文都能提供一条可落地的思路。

1. 先理解“浏览器本地批量视频编辑”怎么解决现实问题

1.1 批量视频处理的真实场景和痛点

批量视频处理并不罕见。常见场景包括：

• 培训机构要给一批 MP4 课程视频统一加上“内部资料”水印。
• 短视频创作者要把一批素材统一裁剪到固定分辨率或固定时长。
• 运营人员要把多个产品宣传片段批量转成统一的码率格式。
• 剪辑师需要从长视频中提取若干片段，每个片段独立命名导出。

如果用手动剪辑软件，每打开一个视频都要重复导入、拖时间线、导出、命名，几十个文件下来非常耗时间。用桌面端脚本工具，例如 FFmpeg 命令行，效率高但需要学习命令行参数、编解码参数和批处理脚本写法，对非专业开发人员有门槛。更麻烦的是，很多公司对隐私和内容合规要求很高，素材不能随便上传到第三方云端平台。

这时，一个“运行在浏览器里、既能批量操作、又不上传文件”的工具就很有吸引力。用户只需要打开页面、拖入一批视频、设置好处理规则，然后等待浏览器在本地完成所有任务即可。

1.2 浏览器本地处理与云端在线剪辑的关键区别

要理解这类工具的价值，先要区分三种常见的视频处理方案。

浏览器本地批处理的核心优势是“部署成本低”和“隐私可控”。用户不需要安装客户端，只需要访问一个网页；视频文件通过File或拖拽方式读入浏览器内存，后续解码、渲染、编码都在本机完成。

但这里要澄清一个容易被误解的地方：所谓“本地运行”，并不是指离线单机软件。它仍然依赖浏览器引擎提供的能力，例如 WebCodecs、Canvas、MediaRecorder、File System Access API 等。如果这些 API 在当前浏览器中不支持，或者当前视频编码不在浏览器的解码能力范围内，工具仍然会失败。所以“本地运行”只是表示计算发生在用户设备上，而不是说它无所不能。

1.3 为什么“批量”和“浏览器”可以组合在一起

很多人听到“浏览器里做视频编辑”第一反应是性能不够。实际上，现代浏览器的多媒体能力已经被大幅增强。

在技术上，浏览器已经具备一条相对完整的视频处理链路：

• 通过FileAPI 读取本地视频文件。
• 通过video元素或WebCodecs VideoDecoder解码视频帧。
• 通过 Canvas 2D、WebGL 或 WebGPU 对画面做处理，例如加水印、调色、裁剪。
• 通过MediaRecorder或VideoEncoder编码输出。
• 通过Blob、URL.createObjectURL或File System Access API保存结果。

这些能力组合起来，已经可以支撑稳定的小尺寸视频批处理任务。Apollodorus Video 这类项目本质上就是把传统桌面工具里的“批量队列”逻辑搬到了浏览器前端，用浏览器的本地能力完成整个处理闭环。

当然，这类工具也有边界：面对超高清、超长视频，浏览器内存压力和编码性能仍然不如原生桌面工具。是否适合用浏览器方案，要把视频规格和任务量先算清楚。

2. 浏览器本地视频编辑依赖哪几条技术链路

2.1 文件接入：File、FileReader 与 File System Access API

浏览器读取本地文件主要靠三类 API。

第一类是<input type="file">搭配File对象。这是最基础的方式，适合用户手动选择一批视频：

<input type="file" accept="video/mp4,video/webm,video/quicktime" multiple />

选择后拿到FileList，再转为数组：

const files = Array.from(event.target.files);

第二类是拖拽读取。给页面容器绑定dragover和drop事件，然后从dataTransfer.files取文件：

container.addEventListener('drop', (event) => { event.preventDefault(); const files = Array.from(event.dataTransfer.files); });

第三类是File System Access API，也就是showOpenFilePicker()。它相比前两种多了可写的FileSystemFileHandle，处理完后可以直接写回原文件或者保存到用户指定目录。但它的浏览器兼容性不一致，落地前一定要做能力检测：

if ('showOpenFilePicker' in window) { const handle = await window.showOpenFilePicker(); }

在这个环节最需要注意的是：不要把File对象长期持有却不释放。视频文件很大，处理完一个任务后要尽快释放相关的ObjectURL，否则浏览器内存占用会快速升高。

2.2 解码与渲染：video 元素、Canvas 与 WebCodecs 的分工

视频解码是浏览器本地视频处理的核心。目前有两种主流路径。

路径一是用video元素加载视频，再把画面绘制到 Canvas 上。这种方式兼容性好、代码简单，适合做功能性原型：

const video = document.createElement('video'); video.src = URL.createObjectURL(file); video.muted = true; // 服务端静音，避免用户手势限制 video.playsInline = true;

路径二是使用 WebCodecs 的VideoDecoderAPI。它能直接解码编码后的视频帧，并且可以在 Web Worker 中运行，不会阻塞主线程。但 WebCodecs 解码的是“裸的编码帧”，并不负责解析 MP4 容器，所以通常要配合 mp4box.js 或类似 demuxer 库一起使用。

处理画面时，Canvas 2D 足够简单：

ctx.drawImage(video, 0, 0, canvas.width, canvas.height);

如果希望性能更好，可以考虑 WebGL 或 WebGPU 做 GPU 加速绘制，但复杂度会明显上升。对于一个批量处理工具，先用 Canvas 2D 跑通流程，再根据性能瓶颈决定是否替换渲染层，是比较务实的路线。

2.3 编码与导出：MediaRecorder、VideoEncoder 与 Blob URL

处理完的 Canvas 画布要变成视频文件，有两种导出途径。

MediaRecorder是最快可用的方案。它可以接收canvas.captureStream()产生的实时视频流，直接编码成 WebM 文件：

const stream = canvas.captureStream(30); const recorder = new MediaRecorder(stream, { mimeType: 'video/webm' });

MediaRecorder的缺点也很明显：编码参数控制不够精细，不同浏览器产出的容器格式和编码器不同，而且它依赖实时流录制，速度受限于视频的正常播放时间。

另一种是 WebCodecs 的VideoEncoder。它把每一帧图片作为输入，按照配置编码，再通过 muxer 封装成 MP4 或 WebM。由于它是逐帧编码，可以跳过播放环节，速度更快，也适合放到 Worker 里并行处理。但VideoEncoder需要自己管理帧的输入输出，代码复杂度和调试成本都更高。

最终导出的文件，在前端通常用Blob加URL.createObjectURL生成下载链接：

const blob = new Blob(chunks, { type: 'video/webm' }); const url = URL.createObjectURL(blob);

当用户需要“保存到原文件”时，再使用File System Access API的showSaveFilePicker()：

const handle = await window.showSaveFilePicker({ suggestedName: 'output.webm' }); const writable = await handle.createWritable(); await writable.write(blob); await writable.close();

2.4 Web Worker 与 OffscreenCanvas 的边界

批量处理意味着连续处理多个文件。如果所有工作都放在主线程，页面会卡到无法点击、无法展示进度，体验非常差。

Web Worker 可以把耗时计算移出主线程。但要记住一个边界：video元素不能放在普通的 Web Worker 中运行，因为它依赖 DOM 和浏览器媒体管道。所以比较现实的分层方式是：

• 主线程负责任务队列、文件读取、状态展示和结果保存。
• Worker 中负责可以用 API 完成的重计算任务，例如图像缩放、滤镜计算。
• 如果要用 WebCodecs 做真正的离线逐帧编解码，可以把解码、编码放入 Worker，并配合OffscreenCanvas在 Worker 里绘图。

OffscreenCanvas支持把 Canvas 的计算移出主线程：

const canvas = new OffscreenCanvas(width, height); const ctx = canvas.getContext('2d'); ctx.drawImage(imageBitmap, 0, 0);

但要注意，OffscreenCanvas不像普通 Canvas 那样无缝支持所有drawImage输入。从video元素获取的帧，需要先用createImageBitmap(video)转成ImageBitmap，才能传入 Worker 或绘制到离屏画布。

3. 用最小可运行 Demo 实现“多个视频批量加水印”

3.1 Demo 目标和环境要求

为了让概念落地，这里实现一个最小可运行 Demo：用户选择多个视频文件后，点击“开始批量处理”，浏览器逐个给视频添加文字水印，最后把每个处理结果变成 Blob 下载。

这个 Demo 有意使用最基础的方案：video元素解码、Canvas 绘制水印、MediaRecorder录制输出。它不追求极致性能，但能完整体现批量视频处理的核心流程，同时也保留了三个非常典型的坑：自动播放限制、录制体积过大、编码兼容性。

环境要求如下：

不要直接双击打开 HTML 文件，部分浏览器在file://协议下行为不一致，建议起一个本地静态服务器：

npx serve .

3.2 项目结构

Demo 由三个文件组成：

watermark-batch-demo/ ├── index.html ├── main.js └── processor.js

index.html提供界面，main.js管理批量队列，processor.js负责处理单个视频。

3.3 页面：选择文件与任务列表

页面部分保持最小化即可：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>批量视频加水印 Demo</title> </head> <body> <div class="panel"> <input type="file" id="videoInput" accept="video/mp4,video/webm" multiple /> <button id="startBtn" disabled>开始批量处理</button> </div> <ul id="taskList"></ul> <script type="module" src="./main.js"></script> </body> </html>

这里accept只是起到提示作用，真正能不能解码取决于浏览器能力。

3.4 主线程队列：一次只处理一个视频

批量处理最重要的设计是一次只处理一个文件，串行执行，避免多个video同时解码导致内存爆炸。

main.js代码：

import { processOneVideo } from './processor.js'; const input = document.getElementById('videoInput'); const startBtn = document.getElementById('startBtn'); const taskList = document.getElementById('taskList'); let files = []; input.addEventListener('change', (event) => { files = Array.from(event.target.files); startBtn.disabled = files.length === 0; renderTaskList(); }); startBtn.addEventListener('click', async () => { startBtn.disabled = true; let successCount = 0; let failCount = 0; for (let i = 0; i < files.length; i++) { const file = files[i]; const item = getTaskItem(i); item.textContent = `${file.name}：处理中`; try { const outputBlob = await processOneVideo(file, { watermarkText: '示例水印', }); const url = URL.createObjectURL(outputBlob); const a = document.createElement('a'); a.href = url; a.download = `watermark_${file.name}.webm`; a.textContent = `下载 ${a.download}`; item.textContent = ''; item.appendChild(a); successCount++; } catch (error) { item.textContent = `${file.name}：失败 ${error.message}`; failCount++; } } console.log(`批量完成：成功 ${successCount} 个，失败 ${failCount} 个`); startBtn.disabled = false; }); function renderTaskList() { taskList.innerHTML = ''; files.forEach((file, index) => { const li = document.createElement('li'); li.id = `task-${index}`; li.textContent = `${file.name}：等待处理`; taskList.appendChild(li); }); } function getTaskItem(index) { return document.getElementById(`task-${index}`); }

这里有一个容易被忽略的点：不要在循环里当成同步任务处理。processOneVideo返回 Promise，await之后下一个文件才开始，页面才有机会渲染状态。

3.5 单视频处理：video 播放、Canvas 绘制水印、MediaRecorder 录制

processor.js是核心处理模块：

export function processOneVideo(file, options) { return new Promise((resolve, reject) => { const watermarkText = options.watermarkText || '水印'; const video = document.createElement('video'); const objectUrl = URL.createObjectURL(file); let timer = null; video.preload = 'auto'; video.muted = true; video.playsInline = true; video.src = objectUrl; const cleanup = () => { if (timer) clearInterval(timer); URL.revokeObjectURL(objectUrl); }; video.onloadedmetadata = () => { const canvas = document.createElement('canvas'); canvas.width = video.videoWidth; canvas.height = video.videoHeight; const ctx = canvas.getContext('2d'); const stream = canvas.captureStream(30); const mimeType = MediaRecorder.isTypeSupported('video/webm;codecs=vp9') ? 'video/webm;codecs=vp9' : 'video/webm'; const recorder = new MediaRecorder(stream, { mimeType, videoBitsPerSecond: 2_500_000, }); const chunks = []; recorder.ondataavailable = (event) => { if (event.data.size > 0) chunks.push(event.data); }; video.onplay = () => { recorder.start(1000); const drawFrame = () => { ctx.drawImage(video, 0, 0, canvas.width, canvas.height); ctx.font = '40px sans-serif'; ctx.fillStyle = 'rgba(255, 255, 255, 0.9)'; ctx.shadowColor = 'rgba(0, 0, 0, 0.6)'; ctx.shadowBlur = 10; ctx.fillText(watermarkText, 24, canvas.height - 40); }; drawFrame(); timer = setInterval(drawFrame, 1000 / 30); }; video.onended = () => { if (recorder.state !== 'inactive') recorder.stop(); }; recorder.onstop = () => { const blob = new Blob(chunks, { type: mimeType }); cleanup(); resolve(blob); }; recorder.onerror = (event) => { cleanup(); reject(event.error || new Error('MediaRecorder 录制失败')); }; video.play().catch((error) => { cleanup(); reject(error); }); }; video.onerror = () => { cleanup(); reject(new Error('视频加载或解码失败')); }; }); }

这段代码的关键点是：

• video.muted = true是为了绕过浏览器自动播放限制，否则没有用户手势时播放会被拒绝。
• canvas.captureStream(30)表示从画布捕获实时视频流，帧率按 30fps 处理。
• MediaRecorder的videoBitsPerSecond控制输出码率，码率太低画面模糊，太高文件体积大。
• recorder.start(1000)表示每 1 秒触发一次ondataavailable，避免一次性收集太多数据导致内存峰值。

3.6 结果保存与下载

Demo 中导出的是Blob，通过临时链接下载：

const url = URL.createObjectURL(blob); const a = document.createElement('a'); a.href = url; a.download = 'output.webm'; a.click();

批量下载时，浏览器经常拦截多个自动点击的下载链接。一个稳妥做法是不自动触发下载，而是把每个任务的结果渲染成“下载”链接，让用户手动点击。

3.7 运行验证与预期输出

运行 Demo 后，预期行为是：

1. 选择一个或多个视频。
2. 点击“开始批量处理”。
3. 列表中的任务状态从“等待处理”变成“处理中”，再变成“下载 xxx.webm”。
4. 下载的视频带有“示例水印”文字。
5. 控制台输出批量统计信息。

如果控制台出现浏览器拦截播放的错误，说明video.play()没有被单击事件直接覆盖，可以检查是否在异步链中丢失了用户手势上下文，或者是否遗漏了muted。

4. 从 Demo 到真实批处理：WebCodecs 与 Worker 生产架构

4.1 为什么 video 元素方案不适合真正的批量任务

上面的 Demo 能跑通，但离可用的批量工具还有一段距离。video元素加MediaRecorder有三个明显问题：

第一，处理速度受限于播放速度。视频必须真实播放完一遍，录制才会结束。一个 30 分钟的视频，浏览器要花 30 分钟完成处理，用户很难接受。

第二，MediaRecorder是实时流编码，输出的封装格式通常是 WebM。很多业务场景要求输出 MP4，浏览器原生并不保证MediaRecorder能直接产出 MP4。

第三，video元素不能放进 Worker，所有解码和绘制都在主线程，批量任务一多，页面就会无响应。

生产环境推荐改成 WebCodecs 管线：先 demux 分离容器，再用VideoDecoder解码，经过 Canvas 或OffscreenCanvas处理后，用VideoEncoder编码，最后 mux 封装成目标格式。

4.2 生产级处理管线：demux、解码、处理、编码、mux

一条完整的生产级管线大致如下：

File -> ArrayBuffer -> demuxer -> VideoDecoder -> 帧处理 -> VideoEncoder -> muxer -> Blob

第一步先把视频文件读取为ArrayBuffer：

const buffer = await file.arrayBuffer();

然后交给 demuxer 解析容器。浏览器没有内置的 MP4 demuxer，通常使用 mp4box.js 或类似库。demuxer 会从容器中分离出视频轨道和音频轨道的编码样本，再交给VideoDecoder：

const decoder = new VideoDecoder({ output(frame) { // 在 OffscreenCanvas 上绘制并做水印处理 const bitmap = new ImageBitmap(); const canvas = new OffscreenCanvas(frame.codedWidth, frame.codedHeight); const ctx = canvas.getContext('2d'); ctx.drawImage(frame, 0, 0); encoder.encode(canvas.transferToImageBitmap(), { keyFrame: false }); frame.close(); }, error(e) { console.error(e); }, });

这里要特别注意frame.close()。VideoFrame是浏览器底层资源，不调用close()会持续占用内存，跑几个视频就可能导致标签页崩溃。

编码完成后，需要把VideoEncoder输出的EncodedVideoChunk交给 muxer，封装成 MP4 文件。不要自己去拼接二进制，格式细节非常多，直接用成熟的 muxer 库更稳妥。

4.3 并行度的取舍与内存预算

批量视频处理是不是并行任务越多越好？不是。视频处理对内存非常敏感。

单个 1080p 视频解码后的原始帧大约是 1920 * 1080 * 4 字节 ≈ 8.3 MB。如果同时处理 4 个视频，再算上编码器缓冲、Canvas 离屏缓冲、JS 对象开销，内存峰值很容易超过 1 GB。

可以考虑在 Worker 中并行处理，但要设置上限。一个简单做法是使用并发信号量：

class TaskPool { constructor(limit) { this.limit = limit; this.running = 0; this.queue = []; } async run(task) { this.queue.push(task); if (this.running >= this.limit) return; this.running++; this.runNext(); } async runNext() { while (this.queue.length && this.running <= this.limit) { const task = this.queue.shift(); await task(); } this.running--; } }

实际项目中的建议是：学习环境可以逐个处理，生产环境最好根据设备内存动态设置并行度，例如 4 核设备最多 2 个并行任务。

4.4 关键参数对工具的影响

如果是MediaRecorder方案，能控制的参数更少，通常只有videoBitsPerSecond和帧率。这也是为什么生产方案建议迁到 WebCodecs。

5. 常见问题排查：从打开文件到导出损坏

5.1 排查顺序总览

本地视频批处理一旦出问题，不要一头扎进代码细节，按下面的顺序排查：

文件是否能读 -> 元数据是否能解析 -> 视频是否能解码 -> 编码器是否支持 -> 内存是否足够 -> 导出文件是否完整

每一个环节都有关键验证方法。

5.2 视频文件读取失败的常见原因

现象：选择了视频文件，但处理一直卡在加载阶段，或者立刻报错。

常见原因有：

• 文件后缀是视频，但编码格式不被浏览器支持。例如某些.mp4内部是 H.265 编码，Chrome 对 H.265 的支持是有限的。
• 视频损坏或没有完整的 moov 盒，MP4 元数据解析失败。
• 文件路径来自网络驱动器或加密盘，File.arrayBuffer()读取时权限有问题。

检查方式：

console.log(file.size, file.type);

如果file.type为空，说明浏览器无法从二进制内容推断 MIME 类型。此时仍然可以尝试读取，但大概率不支持解码。

处理建议：先准备一个公开的标准 H.264 MP4 文件做对照测试。如果标准文件能通过而用户文件失败，那就是源视频编码问题，不是代码问题。

5.3 MediaRecorder 导出文件无法播放

现象：处理过程全部成功，Blob 也生成了，但下载后的 WebM 在播放器里无法播放，或者不能拖动进度条。

原因：MediaRecorder录制的 WebM 在不流式封装的情况下，有时不包含正确的 duration 元数据。播放器无法估算时长，就会出现“片长 00:00”或拖动崩溃。

另外，不同浏览器对 WebM 内部编码的支持不同。Chrome 可能产出vp8、vp9或av1，而部分播放器只支持vp8。

检查方式：

const supported = MediaRecorder.isTypeSupported('video/webm;codecs=vp9');

处理建议：

• 在页面上用<video>标签验证生成的 Blob 是否能播放。
• 如果必须输出 MP4，放弃MediaRecorder，使用 WebCodecs 加 muxer。
• 如果只是做内部预览，可以接受 WebM 输出，但不建议作为跨平台交付格式。

5.4 批处理中途卡死或内存暴涨

现象：处理完 2 到 3 个视频后，浏览器标签页越来越卡，最后崩溃或白屏。

原因大多有这三个：

• 没有及时调用URL.revokeObjectURL，导致视频对象一直占用内存。
• 使用 WebCodecs 时没有调用frame.close()，解码帧持续累积。
• 多个任务并发执行，解码器缓冲区互相叠加。

处理建议：

• 在每个任务的 finally 中统一销毁临时资源。
• 串行执行任务，或者用并发池限制同时运行的任务数。
• 引入一个简单的内存监控，当浏览器内存超过阈值时停止加入新任务。

示例：

const before = performance.memory ? performance.memory.usedJSHeapSize : 0; // 处理完一个视频后 const after = performance.memory.usedJSHeapSize; console.log('内存增量 MB：', (after - before) / 1024 / 1024);

注意performance.memory是 Chrome 的非标准实现，不能作为生产级监控，但可以作为开发期观察手段。

5.5 浏览器兼容性引起的二次问题

有些问题在不同浏览器下表现完全不一样。例如 Safari 对MediaRecorder的mimeType支持不如 Chrome，某些版本不支持canvas.captureStream()；Firefox 对 WebCodecs 的支持进度也不同。

生产项目必须在页面启动时做能力探测，并把不支持的能力直接展示给用户：

const capabilities = { fileApi: 'File' in window, mediaRecorder: 'MediaRecorder' in window, webCodecs: 'VideoDecoder' in window && 'VideoEncoder' in window, fileSystemAccess: 'showSaveFilePicker' in window, }; console.table(capabilities);

建议用一个前置校验页面，明确告诉用户“当前浏览器不满足运行要求”，而不是让用户在任务中途才遇到诡异报错。

6. 生产工具还要补哪些设计

6.1 任务持久化与断点续跑

批量任务通常很长。如果处理到第 8 个视频时用户不小心刷新了页面，良好体验应当是“继续处理而不是重头开始”。

可以用 IndexedDB 保存任务状态：

{ id: 'task-001', fileName: 'course-01.mp4', status: 'done', outputSize: 123456, updatedAt: 1700000000000 }

页面加载时读取未完成的任务，让用户选择继续或跳过。相比纯前端内存队列，这是一个体验差别很大的设计。

视频文件本身通常不会放入 IndexedDB，因为体积太大。更稳妥的做法是让用户重新选择文件，然后通过文件名和文件大小匹配历史任务。

6.2 错误分级、日志和用户反馈

批量工具最失败的设计是“某个视频失败，但所有结果都是失败”。生产工具应该对错误分类：

日志建议直接输出到页面的日志面板，同时保留浏览器控制台输出。这样用户遇到问题时，可以复制日志给开发者定位。

6.3 可扩展方向：插件化处理步骤与 WebAssembly

从“能跑的最小原型”到“可扩展的批量视频工具”，中间还需要抽象处理步骤。

可以把每个视频处理步骤定义成统一接口：

class WatermarkStep { apply(ctx, videoFrame, index) { ctx.drawImage(videoFrame, 0, 0); ctx.fillText('水印', 24, 24); } }

这样缩放、裁剪、调色、加水印都可以作为独立步骤组合起来，用户在前端拖拽配置顺序。

另一个扩展方向是引入 WebAssembly 版本的 FFmpeg。WebAssembly 方案可以先读取完整文件，在内存中完成转码，能复用大量 FFmpeg 的参数逻辑，但内存占用和编译体积都不小。是否需要引入，取决于业务场景：如果只做加水印，原生浏览器 API 已经足够；如果要做复杂编码转换，WASM 可能是更省事的方案。

6.4 哪些场景适合浏览器本地批处理，哪些不适合

适合的场景：

• 视频数量多，但单个视频短，总量可控。
• 操作逻辑简单，例如加水印、裁剪时间、统一导出 WebM。
• 对隐私要求高，素材不允许上传。
• 团队已经使用浏览器作为主要工具，不希望增加安装维护成本。

不适合的场景：

• 超高清长视频，例如 4K 一小时素材。
• 需要精确控制编码参数的专业交付。
• 对处理速度要求极高，需要批量流水线式吞吐。

浏览器本地批处理的边界，通常不在于“能不能处理”，而在于“处理到多大不崩溃”。只要在工具入口把视频大小和处理时间的预期讲清楚，它完全可以在很多业务场景中替代桌面软件和云端服务。

回到 Apollodorus Video 这个项目，它最有价值的地方并不是某段具体代码，而是证明了“批量任务 + 本地隐私 + 零安装”可以同时成立。对开发者来说，想复现类似工具，最优的路径是从本文的video + canvas + MediaRecorder最小 Demo 入手，跑通完整流程后，再逐步把解码和编码迁移到 WebCodecs，同时补上任务持久化、并行池和错误分级。每走一步，都会更接近一个真正可交付的本地批量视频编辑器。