Files
heygen-com__hyperframes/docs/developers/index.mdx

105 lines
3.8 KiB
Plaintext

---
title: "Build on HyperFrames"
sidebarTitle: "Developers"
description: "Choose the smallest HyperFrames surface for automation, editing, playback, rendering, or generated compositions."
---
<Frame>
<video
alt="A HyperFrames composition shown through the CLI, SDK, Player, and rendering infrastructure."
className="aspect-video w-full bg-zinc-100 object-cover dark:bg-zinc-900"
src="https://static.heygen.ai/hyperframes-oss/docs/images/showcase/journey-developers-v2.mp4"
poster="https://static.heygen.ai/hyperframes-oss/docs/images/showcase/journey-developers-v2.jpg"
controls
playsInline
preload="metadata"
/>
</Frame>
Building on HyperFrames means using an HTML composition inside your own product or production system. The same source can be generated, inspected, edited, embedded, and rendered without translating it into a second format.
## The source of truth is HTML
A composition is a normal HTML document with explicit timing:
```html
<div
id="main"
data-composition-id="intro"
data-duration="5"
data-width="1920"
data-height="1080"
>
<h1 class="clip" data-start="0" data-duration="5">
Hello from HyperFrames
</h1>
</div>
```
The `data-*` attributes tell HyperFrames when elements appear and how long the composition lasts. CSS controls the look. JavaScript animation timelines remain seekable, so the same frame can be reproduced in the Player, Studio, a local render, or a cloud worker.
## What you can build
- **Automated video pipelines** that generate or update composition files, validate them, and render the result.
- **Template systems** that change copy, media, colors, or timing through the SDK.
- **Embedded previews** that play and seek a composition inside your application.
- **Editing tools** that combine the SDK for source changes with the Player for live playback.
- **Rendering services** that run locally, in your own infrastructure, or through a managed backend.
## Start at the highest useful layer
For a script or CI job, the CLI is usually enough:
```bash
npx hyperframes check
npx hyperframes render --output video.mp4
```
Use the SDK only when your application must inspect or change the composition itself:
```ts
import { openComposition } from "@hyperframes/sdk";
const composition = await openComposition(html);
composition.setText("hf-title", "A new title");
const updatedHtml = composition.serialize();
```
Use the Player when your application only needs playback:
```html
<hyperframes-player src="/compositions/intro.html" controls></hyperframes-player>
```
Move down to Producer or Engine only when you need to own the rendering pipeline or exact frame capture. Most integrations do not need to begin there.
## Choose your surface
<CardGroup cols={2}>
<Card title="CLI" icon="terminal" href="/developers/cli">
**First result:** validate and render one known project from a terminal or CI job.
</Card>
<Card title="SDK quickstart" icon="code" href="/sdk/quickstart">
**First result:** open a composition, query an element, change a value, and save it.
</Card>
<Card title="Player" icon="circle-play" href="/packages/player">
**First result:** embed one composition and seek it from your application.
</Card>
<Card title="Rendering infrastructure" icon="cloud" href="/deploy/overview">
**First result:** connect one render request to a local, managed, or self-hosted worker.
</Card>
<Card title="Composition and schema" icon="brackets-curly" href="/reference/html-schema">
**First result:** generate one valid composition with clips, timing, tracks, and media.
</Card>
</CardGroup>
The complete mental model is:
```text
composition → inspect or edit → play or render
```
## Reference
[Technical overview →](/developers/overview) · [Packages →](/packages/core) · [Contributing →](/contributing)