Hyperframes vs Remotion

Remotion 是一个很棒的项目，我们在 HeyGen 的生产管线中使用了 Remotion 数月之久。Remotion 推广了使用代码来编排和动画视频制作的理念，并证明了 headless Chrome 可以成为可靠的、确定性的视频渲染器。Hyperframes 源代码中的几个模式直接来自 Remotion 团队开创的内容——Chrome 启动标志、端口选择、image2pipe 流式传输到 FFmpeg、有序帧缓冲。我们在代码中有意保留了归属注释，以便任何阅读源代码的人都能看到传承。

本指南是 Hyperframes 与 Remotion 差异的诚实分析，由构建 Hyperframes 的团队编写。我们选择了不同的押注；每个都有对方没有的优势，本文档会逐一分析。

为什么构建 Hyperframes

随着我们在 HeyGen 扩大代码到视频的管线，我们在 React 优先的创作模型中不断遇到相同的限制。我们内部讨论是继续在 Remotion 上构建还是从头编写渲染器。两个因素推动我们构建了 Hyperframes。

1. Agent 原生工作流

在我们的评估中，LLM 编写 Remotion 合成产生的视觉输出创意性更低，并且比相同的 LLM 直接编写 HTML + GSAP 合成需要更多的防护栏和提示。

两个相关问题加剧了这一点：

• 拥有自己内部时钟的动画库（GSAP、Anime.js、Motion One）无法与 React 的逐帧渲染干净地组合。
• 不是作为 React 编写的任意 HTML 或 CSS 没有干净的路径进入 React 合成——你必须重写它。

2. 人类编辑工作流

我们希望相同的代码既是渲染层又是数据层，因为我们需要在 agentic 体验之上构建人类 UI。

HTML 既是渲染层又是可编辑的真实来源——相同的 DOM 既是你看到的也是你编辑的。这让构建真正的可视化编辑器（选择、拖放、属性面板、时间线）更加自然，就像 Paper.Design 那样。使用 Remotion，真实来源是代码加上构建步骤，因此通过可视化编辑器往返既痛苦又脆弱。Remotion 团队在这方面取得了进展，但在 React 之上构建实时编辑器比在 HTML 之上困难得多。

我们将 Hyperframes 构建为对 agent 最原生的，同时使其易于在上面构建人类界面。

一览

本指南其余部分会分析每行的含义以及每个工具实际占优的地方。

核心差异：React vs HTML

Hyperframes 和 Remotion 都驱动 headless Chrome。两者都是确定性的。两者都提供 agent skills。它们在一个决策上不同：主要创作者写什么。

Remotion 的押注是 React。视频合成是 React 组件。你获得类型化的 JSX、React 生态系统、组件复用以及整个 React 工具链。Remotion 的优势来自于对该平台的承诺：多年的生产使用、超大规模的 Lambda、大型社区、精心设计的类型安全 API。

Hyperframes 的押注是 HTML。视频合成是 HTML 页面。你可以粘贴一个落地页、一个设计系统组件或一个 CodePen 演示并对其做动画。我们认为对于两个特定用例这是正确的平台：AI agent 编写视频，以及直接在渲染器使用的 DOM 上构建可视化编辑器。

不同的押注，不同的优势。本文档其余部分分析每个优势的体现。

差异在实践中的意义

Agent 在 HTML 中比在 React 中更好地表达视觉

当 LLM 编写 Hyperframes 时，它在编写它接受训练最多的媒介。浏览器看到的 Web——HTML、CSS、JavaScript、来自 CodePen 的 GSAP 惯用法、25 年积累的 Web 动画内容——是模型训练数据中最深的资源。React 特定的资源只占很小一部分。

从在两个系统中运行生产的经验来看：被要求编写 Remotion 合成的 agent 会花费 token 学习框架规则（哪些 hooks 被允许、哪些 API 被禁止、如何创建项目脚手架）然后才能发挥创意。输出倾向于收敛到一个狭窄的视觉词汇——居中标题、库存过渡、传统排版。相同的 agent 使用 GSAP 编写 HTML 则会触及更广泛的创意范围，因为那是其训练数据的样貌。

拥有自己时钟的动画库

要求 agent 将 GSAP 动画或现有网页移植到 Remotion 会在第一次尝试时丢失细节：时间微调、音频级别关系、文本尺寸。HTML 优先路径完全避免了翻译步骤。

我们给两个工具相同的 4 秒 GSAP 时间线："HYPERFRAMES" 的 11 个字母以 back-out 缓动交错进入，保持 1.5 秒，然后每个字母旋转并掉出帧。相同的动画代码，相同的缓动，相同的交错。我们唯一改变的是渲染器。

Hyperframes 输出——动画应有的样子：

所有四秒都被使用。字母一个个飞入，完整单词在中心保持约一秒半，然后字母旋转并掉落。

Remotion 输出——相同的时间线、相同的代码：

GSAP 在渲染挂钟时间的大约第一秒内播放完其完整的 4 秒动画。当 Remotion 捕获后面的帧时，GSAP 的时间线已经完成，每个字母已经退出——渲染的剩余部分捕获的是空舞台。

原因： GSAP 通过 performance.now() 驱动自己的时间线，在渲染期间以实时速度运行。Hyperframes 暂停 GSAP 并在每帧捕获前将其搜索到 frame / fps，因此库与输出同步运行。Remotion 没有等效的原语，因此 GSAP 的内部定时器以挂钟速度飞过时间线，而 Remotion 在入场期间捕获少量帧，之后捕获的大部分是空帧。

GSAP 支持的一切——SplitText、ScrollTrigger、MotionPath、Physics、CodePen 上 15 年的代码片段——在 Hyperframes 中以相同方式工作。这个模式适用于 Anime.js、Motion One 和任何其他有自己的时钟的库；任何没有自己时钟的 JS 库直接工作。将库时钟包装在 Remotion 组件中是可能的但很笨拙，而且你会放弃库擅长的大部分功能。

参见 GSAP 动画指南了解如何集成，以及确定性渲染了解搜索驱动捕获的工作原理。

任意 HTML、CSS、JavaScript

每个网页都是潜在的 Hyperframes 合成。落地页、Claude Design 产物、设计系统文档、CodePen 嵌入。你粘贴 HTML 并渲染。

Remotion 要求你先翻译：将 HTML 重写为 JSX，将 CSS 转换为 React，用 React 组件和 refs/effects 包装命令式代码（Canvas、WebGL、GSAP）。每个翻译步骤都是 agent 或人类丢失保真度或引入 bug 的机会。翻译无论如何都是往返工作——两个框架最终都向浏览器提供 HTML 进行渲染。

website-to-video 指南详细介绍了 HTML 优先模型实现的完整捕获到渲染管线。

边缘原语的自动回退

Hyperframes 有两种捕获模式。

• BeginFrame 模式（Linux + chrome-headless-shell）通过 HeadlessExperimental.beginFrame 原子地驱动 Chrome 合成器，在不同机器间产生字节级可重现的帧。
• Screenshot 模式（macOS、Windows，以及作为自动回退）实时运行 Chrome 并截取普通截图——与 Remotion 使用的方法相同。

渲染器在编译时检查每个合成，当发现 BeginFrame 无法处理的原语时回退到 screenshot 模式：内联 <iframe>、帧适配器之外的原始 requestAnimationFrame 循环。它注入虚拟时间填充，使 rAF 和 iframe 内容保持帧驱动而非挂钟驱动。你会收到解释回退的诊断信息，渲染产生视觉上正确的输出。当合成可以在 BeginFrame 模式下运行时，你免费获得确定性。

实践中：GSAP 时间线、CSS @keyframes（通过 Web Animations API 适配器）、Lottie、Three.js 和 Web Animations API 都在 BeginFrame 模式下确定性渲染。原始 canvas 循环和实时 web 嵌入自动获得 screenshot 模式。

React 组件复用（Remotion 的主场）

如果你的团队已经有 React 组件的设计系统，Remotion 让你使用与应用中相同的原语来组合视频。类型安全、IDE 补全、跨文件重构——React 带来的一切开发体验。对于已有 React 投资的团队，这是 Hyperframes 不试图匹敌的真正优势。

分布式渲染

Remotion Lambda 将长视频拆分到数百个 AWS Lambda 函数中。它是成熟的、经过生产验证的、文档完善的——团队已使用多年的东西。

Hyperframes 现在提供 AWS Lambda 部署路径：一个 Lambda 函数在 Step Functions 工作流后面，将渲染分发到 chunk worker，在 S3 中存储中间结果，并暴露 lambda render、lambda render-batch、进度轮询和 SDK 使用。该接口比 Remotion Lambda 更新，因此实际权衡是成熟度与 Hyperframes 的 HTML 原生合成模型。

渲染源上的可视化编辑（Hyperframes 的自然押注）

你渲染的 DOM 就是你编辑的 DOM。Hyperframes Studio 在实时 iframe 中预览合成，由于渲染器和编辑器共享一个 DOM，直接操作作用于渲染管线消费的相同真实来源。那个用户体验——点击选择、拖动重新定位、在面板中编辑属性——已经为字幕发布了，更广泛的元素覆盖正从相同的架构基础上构建出来。

在 React 之上构建相同的编辑器更困难，因为真实来源是代码加上构建步骤。将可视化编辑回 JSX 意味着重新编译。这就是为什么 Paper.Design 等工具选择 HTML 作为可编辑源。

HDR 输出

两个工具目前都通过 headless Chrome 渲染，输出 sRGB。Remotion 记录为不支持。Hyperframes 支持 HDR 输出，通过将 DOM 层与原生 HLG/PQ 视频结合的两遍合成管线。

开源 vs 源代码可用

这是两个项目之间最明显的差异之一，也是团队选择其中一个的最常见原因之一。

两个项目都在 GitHub 上发布源代码，但许可证的工作方式非常不同。Apache 2.0 是 Open Source Initiative 批准的许可证——你可以自行托管、修改、再分发并在任何规模商业使用 Hyperframes，无每次渲染费用且无席位上限。Remotion 许可证是自定义商业许可证：你可以阅读代码并为小团队自行托管，但超过其阈值的商业使用需要付费公司许可证。

如果开源许可证对你很重要——OSI 合规、再分发权利、无每次使用费用、长期独立于供应商定价决策——这是首要决策点。如果你的用例在 Remotion 的免费层内或你的公司接受商业许可证，这不是问题。参见 Remotion 许可证页面了解其当前条款。

我们以 Apache 2.0 开源 Hyperframes，以便任何人都可以在其上构建——包括在任何规模商业使用——并且项目可以超越任何单一公司的优先事项。

总结

Remotion 和 Hyperframes 之间的唯一区别是选择 React vs HTML（+ CSS + JavaScript）。这个决策导致了许多下游差异。对于我们的需求——对 agent 最原生、架构为支持人类 UI 层——HTML + CSS + JavaScript 是明显的押注：

1. Agent 已经"用 HTML 思考"。LLM 见过大量的 Web 代码。
2. 真正的"一个文件输入，视频输出"。没有 package.json、没有安装、没有打包器配置、没有合成设置。更少的可变部分 = 自动化和 agentic 工作流中少得多的随机失败。
3. 最高的创意上限——浏览器能渲染的任何东西，HTML 都能表示。
4. HTML 既是渲染层又是可编辑的真实来源。相同的 DOM 既是你看到的也是你编辑的。

我们 HeyGen 全力投入 Hyperframes，但我们无法独自完成——这就是为什么我们以 Apache 2.0 开源它，以便我们共同构建 agentic 视频创作的基础。

延伸阅读

• 确定性渲染 — 搜索驱动帧捕获的工作原理
• GSAP 动画指南 — 实践中的库时钟集成
• 帧适配器 — 动画运行时的扩展点
• 网站转视频 — HTML 优先的捕获到渲染管线