当前位置：首页 > news >正文

Remotion 渲染视频脚本，自动化编辑视频 Node.js 层面是“单线程 JS”，但在实际渲染时是“高度并行”的。

news 2026/5/11 13:35:51

Remotion 渲染脚本，在 Node.js 层面是“单线程 JS”，但在实际渲染时是“高度并行”的。

我给你一个非常明确、工程级的结论，不绕概念。

✅ 一句话结论

你的脚本：

JS 主逻辑：单线程
Remotion 实际渲染：多线程 + 多进程
最终效果是：会吃满 CPU

🧠 详细拆解

1️⃣ Node.js JS 层：确实是单线程

await bundle(…)
await selectComposition(…)
await renderMedia(…)

• 这些都是异步但串行

• 没有：

• worker_threads

• Promise.all（并发渲染）

• 手动多进程

✅ JS 执行模型 = 单线程 Event Loop

2️⃣ 但 renderMedia() 内部 ≠ 单线程（重点）

@remotion/renderer 在底层做了这些事：

🔹 Puppeteer（Chrome）

• 启动 Chrome 进程

• 每一帧 = 从 Chrome 截图 / 抓取媒体

• Chrome 本身是多线程 + GPU 加速

🔹 帧渲染并发

Remotion 会：
• 并行渲染多个帧（不是一帧一帧死循环）

• 使用线程池 / 并发任务队列

即使你没有写并发代码，Remotion 已经帮你并发了

🔹 音频处理

• 音频混合、编码

• 使用 FFmpeg / 原生音频库

• FFmpeg 是重度多线程

✅ 实际渲染 = 多进程 + 多线程

3️⃣ 你这个脚本的真实并发情况

层级是否多线程

Node.js JS 主线程 ✅ 单线程

Puppeteer / Chrome ❌ 多线程

帧渲染并发 ❌ 多线程

FFmpeg 编码 ❌ 多线程

音频混合 ❌ 多线程

👉 结论：CPU 会被吃满

4️⃣ 为什么你感觉“像单线程”？

因为：

• 你看到的日志是线性打印

• onProgress 是回调汇总后的结果

• JS 没写 for + spawn

但这只是 API 封装得好，不是真的单线程。

5️⃣ 如果你想控制并发（很重要）

Remotion 支持限制并行度（防止机器卡死）：
await renderMedia({
composition,
serveUrl: bundled,
codec: “h264”,
outputLocation: outputPath,
browserExecutable: CHROME_PATH,
concurrency: 4, // ← 最大并行帧数
});

推荐设置（Windows + 桌面 CPU）

CPU concurrency

8 核 4–6

12 核 6–8

16 核 8–10

如果不设：
• Remotion 会自动根据 CPU 核心数决定

• 很容易 100% 占满

6️⃣ 最终总结（给你一个“能拿去说”的版本）

该脚本在 Node.js 中是单线程执行，但由于 Remotion 内部使用 Chrome + FFmpeg + 帧级并发渲染，实际渲染过程是多线程、多进程的，能够充分利用多核 CPU。

如果你愿意，我可以帮你：
• ✅ 评估当前渲染是不是 CPU 瓶颈

• ✅ 优化 concurrency + Chrome 参数

• ✅ 判断音频渲染慢还是帧渲染慢

• ✅ 给你一套 Windows 下最稳的 Remotion 配置

那我就专门针对你的这颗 1055T（6 核老 U），给你一套能跑、不炸机、尽量快的 Remotion 渲染配置。

下面都是实战向结论，不是理论。

✅ 一、先给结论（直接用）

✅ 推荐 renderMedia 参数（1055T 专用）

await renderMedia({
composition,
serveUrl: bundled,
codec: “h264”,
outputLocation: outputPath,
browserExecutable: CHROME_PATH,

// ✅ 关键：限制并发
concurrency: 2,

// ✅ 降低 Chrome 资源占用
chromiumOptions: {
args: [
“–disable-gpu”,
“–disable-dev-shm-usage”,
“–single-process”,
],
},

onProgress: ({ progress, stage }) => {
const pct = (progress * 100).toFixed(1);
if (progress % 0.05 < 0.005) {
console.log([${stage}] ${pct}%);
}
},
});

🧠 二、为什么这样配（针对 1055T）

1️⃣ concurrency: 2 是最稳选择

设置结果

concurrency: 3 ⚠️ 容易满载、掉速

concurrency: 4+ ❌ 严重卡顿 / 崩溃

concurrency: 2 ✅ 稳定 + 可接受速度

原因：
• 1055T 单核弱

• Chrome + FFmpeg 本身就很吃线程

• 留点余量给系统，避免 IO / 音频卡死

2️⃣ --single-process 非常关键

这颗 U 不适合 Chrome 多进程：
默认 Chrome：
├─ Browser
├─ Renderer × N
├─ GPU
├─ Audio

👉 在 1055T 上会：
• 进程爆炸