ライブデータを共有可能な動画へ自動変換する方法
(recoveredfactory.net)- 数日ごとに更新されるライブデータを、人が毎回編集することなくソーシャル動画にするため、Webベースのワークフローを構築
- 動画の元になるのは編集ファイルではなく隠しWebページで、Playwrightがブラウザをフレーム単位で動かし、ffmpegがそれをMP4とGIFにまとめる
- 短い storyboard.ts と単一のplayheadが、今日の数値、フェード、2024年12月の開始点、18か月の成長区間を約14秒のクリップとして構成する
- スケジュール実行されるGitHub Actionがデータ変更を検知してサイトを再ビルド・再デプロイし、比率と言語の組み合わせに応じた4本のカットを生成してCloudFront CDNに公開する
- YouTubeは非公開の下書きアップロードが可能だが、Instagramは即時公開投稿しかサポートしないため、最終確認とキャプション編集のための人による承認ステップを維持する
Webページを動画素材として使う構成
- 動画は別個の編集プロジェクトではなく、Webサイト内の専用の隠しページから始まる
- このページは、Reels、Shorts、TikTokで使われる縦型の9:16画面に合わせて設計されている
- 画面にはライブサイトの既存要素を再利用する
- ヘッドライン
- 大きな機関数値
- アニメーションチャート
- 全国地図
- 小さなクレジット行
- Webブラウザのタイムラインアニメーションとモーション効果を活用し、コンピューターがユーザーには見えないヘッドレスブラウザを制御する
- 通常のWebページと同じようにブラウザで直接開き、前後に移動しながらプレビューやデバッグができる
- サイトの多言語フレームワークをそのまま継承し、対応言語ごとの動画をキャプチャできる
- このプロジェクトのasset bakery、データパイプライン、フロントエンドはopen sourceとして公開されている
storyboard.tsとplayhead
- storyboard.ts という1つのファイルが、動画のタイミングと変換を監督のショットリストのように定義する
- 構成はいくつかの名前付きbeatと継続時間からなる
- 今日の全体数値を1.5秒保持
- 0.7秒のフェード
- データが始まる2024年12月時点を1.5秒保持
- その後、18か月の成長区間を前方へ再生
- 再び今日の画面に落ち着く
- 全体の成果物は約14秒のクリップ
- チャート描画、地図上の点表示、カウンター増加は、1つのplayheadに結び付けられて動く
- playheadは特定のtimestampで全コンポーネントが同じ状態をレンダリングするようにし、画面要素が互いにずれないようにする
フレーム単位で「焼く」方式
- 実際の動画ファイルは、ヘッドレスブラウザでWebページを開き、PlaywrightでChromiumを制御して作成する
- 当初は仮想的に再生ボタンを押して画面録画でキャプチャできると考えていたが、リアルタイム録画ではフレーム落ちや途切れが発生し得た
- 同じ動画でもローカルでは滑らかに動き、クラウドハードウェアでは異なる挙動になることがあり、初期実験中には時々異常に速く再生されることもあった
- より安定した結果のため、リアルタイム録画の代わりにflipbookのようにフレームを1枚ずつ生成する
- ページに「0.04秒時点の見た目を表示してほしい」と指示する
- スクリーンショットを撮る
- 0.08秒へ移動して再びスクリーンショットを撮る
- このプロセスを数百回繰り返す
- 凍結したページを手でめくるように進めるため、各画像は完全にレンダリングされた状態でキャプチャされる
- 結果は決定的でテスト可能であり、2回実行すれば検証可能な形で同一フレームが得られるべきである
- フレーム数を2倍にすれば、レンダリングに必要な計算時間と保存容量もおおむね2倍になる
サーバーレンダリングを安定させる細部の処理
- 全国地図にはMapLibre GL JSを使い、通常はGPUを前提とするWebGLコードでレンダリングする
- サーバーにはGPUがないため、Chromiumがソフトウェアレンダリングを使うよう設定する
- 実際のグラフィックハードウェアより遅い
- ほぼすべてのプラットフォームで同じ品質で実行可能
- 各フレームはPNGではなくJPEGで保存する
- スクリーンショットではPNGエンコードが遅い部分になる
- 最終動画の見た目は同じなので、数百フレーム全体で速度面の利得が生まれる
- ヘッドレスブラウザをコンテナ内のbare serverで安定して実行するにはいくつかのフラグが必要で、詳細はすべて公開リポジトリにある
- 生成された数百枚の画像はffmpegでMP4とループGIFにつなぎ合わせる
GitHub Actionベースの自動化
- 全工程は、スケジュール実行されるGitHub Actionの自動データパイプラインに接続されている
- 1日に数回、データが変わったかどうかを確認する
- 新しいデータが入ると、ジョブは次を実行する
- サイトの再ビルド
- サイトの再デプロイ
- 正方形/縦長比率と英語/スペイン語の組み合わせによる4本のカット生成
- CloudFront CDNへの公開
- 公開ダウンロードページは、対応言語ごとの最新カットを提供する
- 最後のステップには、YouTubeの下書きアップロードとInstagram投稿通知が含まれる
- YouTube用スクリプトはpublish-social-youtube.mjs
- Instagram投稿準備通知はnotify-social-ready.mjs
- TikTok連携も予定されている
自動化と編集コントロールの境界
- このプロジェクトは完全自動化を排除してはいないが、すべての動画が出る前に人による確認を維持している
- ヘッドラインとキャプションに対する編集コントロール、最終レビュー、投稿方法の判断は人が担う
- 入力データが悪かったり、システムが誤った結果を作ったりする可能性があるため、盲目的な自動投稿は避ける
- YouTubeは公式APIで非公開の下書き動画を作成する
- Instagram APIは即時公開投稿しかサポートしないため、新しいデータがあるたびにYouTube下書きを作成し、Instagram投稿を手動で作るよう促すメール通知を送る
Webデザインで完結するソーシャル動画制作
- この方式の利点は、動画デザインがそのままWebデザインになることにある
- After Effects、手動での再書き出し、古い数値、多忙なWebプロデューサーに依存しない
- 色やラベルの変更は1行の修正で済み、次のレンダリングに反映される
- システム全体は、既存ツールの周囲にある数百行規模のglue codeで構成される
- データパイプライン
- ヘッドレスブラウザ
- サイトですでに使っている地図とチャート
- ffmpeg
- 実行コストは月数ドル程度
- 比較対象として挙げられたMissouri Vehicle Stops MCPは、現在月約50ドルのコストがかかるように見える
- asset bakeryはMCPよりユーザーあたりのコストが低く、MCPはより深いデータ関与を提供するツールに近い
戦略と「shortcut」の役割
- 高品質な共有用の自動生成アセットで主流プラットフォームに対応しつつ、深く関わるユーザー向けにはMCPのような現代的なデータツールも併せてサポートする戦略
- 目標はバイラルな見世物でも、不明確な一般大衆でも、すべての人に合う単一製品でもない
- shortcutはごまかしではなく、すでにあるリソースを活用して、より遠くへ進み、消耗を減らすための方法である
- GitHub Actionで既存リソースをつなげば、動画を作りたいとき、あるいは状況が本当に求めるときだけ、動画について考えればよい
まだコメントはありません。