hyperframes - HTMLをフレーム単位でシークしてMP4へ書き出す動画レンダリング基盤

HTMLで動く画面を作ることと、その画面をフレーム単位で動画へ変換することには、時間制御の違いがある。実時間の経過に依存するアニメーションでは、任意の時刻へ移動して同じ状態を描画するための配慮が要る。HyperFramesのREADMEも、Remotionとの比較でライブラリクロック型アニメーションの扱いを論点にしている。ただし、これはHyperFrames側の説明であり、Remotion全体が正確なフレーム描画に適さないと結論づける根拠にはならない。

HyperFramesが置く前提は、アニメーションをシーク可能にしてから動画化することだ。レンダラがフレームの時刻を指定し、ページがその時刻の画を返せる構成にする。HTML/CSSの記述だけで動画制作が完結するわけではなく、要素の配置に加えて、時間とアニメーション状態の対応を設計する必要がある。

READMEはRemotionに着想を得たと明記し、双方がヘッドレスChromeとFFmpegを使う点を共通項に挙げる。差として示すのは、主に動画を記述するモデルだ。HyperFramesはHTML＋CSS＋シーク可能なアニメーションを入力とし、RemotionはReactコンポーネントで記述する、と説明している。ビルド工程についても、HyperFramesは不要、Remotionはバンドラが必要という比較だ。これらのRemotion側の条件は独立検証されていない。

HyperFramesのREADMEによれば、index.htmlはビルドなしでブラウザ再生できる。エージェントへ渡す成果物もプレーンHTMLになる。一方、一般的なWebドキュメントには動画制作固有のパターンが不足するため、スキルで補うという構成を採る。入力形式の簡素さと、動画として有効な内容を作るための知識は分けて考える必要がある。

10月1日のGitHub Trending観測では54,742スター、日次増加349スターだった。これは選定時の注目を示す数字であり、10月4日の掲載時点まで勢いが継続した証拠ではない。取得したリリース一覧の最新はv0.8.99で、直近の変更にはStudioをホスト製品へ組み込むための拡張が含まれる。

「Built for agents」という説明の具体性は、非対話CLIと制作スキルから読み取れる。ただし、スター数やエージェント対応をレンダリング品質の根拠にはできない。READMEはHeyGenでの本番利用やコミュニティ事例を報告するが、事例の本文、運用規模、稼働条件は取得されていない。本記事で評価できるのは、文書に示された入力モデルと処理の分担、その周囲に残る未確認事項である。

動画のルート要素にはdata-composition-id、data-start、data-width、data-heightを付ける。これがコンポジションの識別子、開始時刻、画面寸法を宣言する。内部のクリップにはclass="clip"と、data-start、data-duration、data-track-indexを付け、いつ、どれだけの長さ、どのトラックに置くかを指定する。videoやaudioも時間属性で配置し、音声にはdata-volumeなどを与える。

READMEの例では、launchというコンポジション内の見出しを開始時刻1、継続時間4、トラック1のクリップとして宣言している。要素の存在時間を記述する属性と、見た目を変えるアニメーションは別に置かれている。この二つを読むことで、何が時間軸上に存在し、その要素がどう動くかを把握できる。coreスキルはさらにサブコンポジション、変数、フレームワークが管理するメディア再生、決定性ルールを扱うが、詳細な契約は取得範囲では確認できない。

GSAPのサンプルでは、gsap.timeline({ paused: true })で停止状態のタイムラインを作る。そこへ見出しの不透明度や位置を変えるアニメーションを追加し、window.__timelines.launchへ登録する。launchはコンポジションIDに対応する。自走するアニメーションを眺める構成ではなく、コンポジションに対応するタイムラインを、指定時刻へシークできる形でレンダラにつなぐ構成だ。

対応する表現はGSAPだけではない。CSS、Lottie、Three.js、Anime.js、WAAPI、独自のフレームアダプタも挙がる。これらのライブラリは置き換え対象ではなく、映像の動きや描画を担う部品になる。@hyperframes/coreには、その接続を担うフレームアダプタが含まれる。ただし、GSAP以外の登録方式や、各ランタイムでどの状態までシークできるかは、取得した説明だけでは判断できない。対応名の一覧を、そのまま全機能の再現性保証として読むべきではない。

レンダリングを支える主要パッケージはCore、Engine、Producerだ。@hyperframes/coreは型、パーサ、ジェネレータ、リンタ、ランタイム、フレームアダプタを持つ。@hyperframes/engineはPuppeteerとFFmpegを用いるページから動画へのキャプチャエンジン。@hyperframes/producerはキャプチャ、エンコード、オーディオミックスをまとめるパイプラインを担う。

hyperframes renderからの流れは、コンポジションを解析し、Puppeteer経由でヘッドレスChromeを駆動し、各フレームへシークして描画結果をキャプチャし、FFmpegでMP4へエンコードする、というものだ。音声はProducerがミックスする。audio要素の時間属性と音量属性は、この処理へ渡す宣言になる。ただし、フレームの受け渡し方式、描画完了の待機条件、並列化、音声同期やミックスの実装は未確認である。READMEが示すパッケージの分担から、それらの具体的なアルゴリズムまでは導けない。

CLIは作成、lint、検査、スナップショット、プレビュー、レンダリングなどを担い、READMEでは既定で非対話とされる。基本の入口はinit、preview、renderで、previewはライブリロードに対応する。スキルが教える流れは、計画→有効なHTML→シーク可能なアニメーション→素材追加→lint→プレビュー→レンダリングだ。エージェント向け設計の具体的な部分は、この制作工程を明示している点にある。

スキルはルータ、制作ワークフロー、ドメインスキルの階層を持つ。frame.mdはWeb向けデザインをカメラ向けに組み替え、エージェントがスケールを推測する負担を減らす位置づけだ。/media-useは素材を固定されたローカルファイルとledger記録へ解決する。Catalogには字幕、チャート、遷移などの再利用部品があり、npx hyperframes addで導入する。入力の生成だけでなく、映像の仕様と素材を制作ループへ持ち込む仕組みだが、それによって出力品質がどこまで改善するかの検証結果は示されていない。

Studioはブラウザ上のコンポジションエディタで、Playerは埋め込み用の<hyperframes-player> Webコンポーネントだ。v0.8.97とv0.8.98のリリースノートには、ホストによる右クリックメニューへの項目追加、タイムラインの読み取り専用化、ツールメニューの制限が含まれる。これは、レンダリング基盤をホスト型オーサリング製品へ組み込む用途と整合する。

実行先にはローカル、Docker、AWS Lambda、HeyGenのホスト型クラウドレンダリングがある。@hyperframes/aws-lambdaは分散レンダリング用のSDKとデプロイ面を提供し、手元やCIから実行する経路を持つ。一方、分割単位、並列実行の効果、結果の集約方法は取得範囲にない。制作UIを持つことと、分散レンダリングの運用が成熟していることは、別の評価項目になる。

適合しやすいのは、製品紹介、PR解説、データ可視化、字幕付きSNS動画などを、コードやエージェントから繰り返し生成する工程だ。/pr-to-videoはgh CLIでPRを読むワークフローを持つ。HTML/CSSやGSAPの知見があるチームなら、既存の表現技術を動画の入力へつなげる候補になる。

Remotionとは記述モデルの選択で競合する。Reactの資産を維持したいチームには、HTML中心へ移る負担がある。移植スキルも一方向であり、双方を自在に往復する仕組みとは説明されていない。ライセンスはHyperFramesがApache-2.0で、READMEはRemotionをsource-availableのRemotion Licenseと比較する。一方、GSAPやLottieなどとは補完関係にある。ブラウザでの制作画面も備えるが、Studioは「Available, evolving」であり、手作業中心の本格的な動画編集の代替としては成熟度の確認が要る。

開発元は、フレームごとにシークして描画する方式から「同じ入力から同じ動画」が得られると説明し、CIや回帰テスト向けと位置づける。READMEにはgolden回帰テスト用のMP4ベースラインをGit LFSで管理しているとの記載もある。ただし、比較がバイト一致なのか、許容差付きなのかは不明で、検証結果も示されていない。

Chromeのバージョン、OS、フォント、GPUの有無といった再現条件は取得ソースにない。さらにGSAPのサンプルは、jsDelivrのgsap@3というメジャーバージョン指定を使う。外部から取得するものも入力になりうるため、固定やオフライン化は利用側の検討事項だ。フォントや素材の読み込み制御も未確認である。CIで採用するなら、何を同一出力とみなし、どの環境と入力を固定して確かめるかを先に定めたい。

エージェントが生成したHTML/JavaScriptをヘッドレスChromeで実行するため、信頼できない入力を扱う場合はサンドボックスと外部アクセスの方針が論点になる。取得ソースにはその方針がなく、SECURITY.mdも未取得だ。第三者の入力を無検証でレンダリングする用途に、そのまま適用できるとは判断できない。

ローカル実行にはNode.js 22以上とFFmpegが必要になる。ホスト型クラウドレンダリングや、/media-useによるTTS・音楽・画像モデルの素材生成を選ぶ場合は、外部サービス依存とデータ送信が生じうる。利用条件、料金、使用モデルは取得範囲では不明だ。ローカルで描画できる経路があることと、選んだ制作ワークフロー全体がローカルで完結することを混同せず、素材取得とレンダリング先の両方を確認する必要がある。

取得時点のバージョンは0.8.xで、API安定性の保証は見当たらない。Studioも進化中とされているため、組み込み先ではAPIや挙動が変わりうる前提で扱うのが無難だ。スキル更新はmainから取得され、ルータが必要なワークフローへ入る前に実行する。固定運用を望む場合は、バージョン付きプラグインとの使い分けも検討したい。別の導入経路であるnpx skills addには、レジストリがmainより数時間遅れる場合があるという注記もある。

速度、CPU・メモリ使用量、並列化の効果を示すベンチマークは取得されていない。AWS Lambdaの経路があるだけでは、処理時間や費用の優位性は判断できない。README自身もRemotion Lambdaを成熟したクラウドレンダラと表現している。大規模な分散処理が必要なチームは、入力モデルの利点に加え、対象動画での資源消費、更新管理、実行先の運用条件を評価する必要がある。