単独開発者として TypeScript ビデオエディタを構築する-jsチュートリアル-php.cn

エキサイティングな SaaS 構築の旅に着手してから 4 年が経過し、アプリの重要なコンポーネントの 1 つを再構築する適切な時期が来ました。

JavaScript で書かれたソーシャルメディアビデオ用のシンプルなビデオエディター。

これは、この書き換えに使用することに決めたスタックであり、現在作業中です。

スヴェルト 5

私たちのフロントエンドは SvelteKit で書かれているため、これが私たちのユースケースに最適なオプションです。

ビデオエディターは、フロントエンドに簡単に追加できる別個のプライベート npm ライブラリです。ヘッドレスライブラリであるため、ビデオエディターの UI は完全に分離されています。

ビデオエディターライブラリは、ビデオおよびオーディオ要素とタイムラインの同期、アニメーションとトランジションのレンダリング、HTML テキストのキャンバスへのレンダリングなどを行います。

SceneBuilderFactory は、シーン JSON オブジェクトを引数として受け取り、シーンを作成します。 StateManager.svelte.ts は、ビデオエディターの現在の状態をリアルタイムで保持します。

これは、タイムラインでの再生ヘッドの位置の描画や更新などに非常に便利です。

ピクシー.js

Pixi.js は、優れた JavaScript キャンバスライブラリです。

当初、私はこのプロジェクトを Pixi v8 でビルドし始めましたが、この記事の後半で説明するいくつかの理由により、Pixi v7 を使用することにしました。

ただし、ビデオエディターライブラリは依存関係と緊密に結合されていないため、必要に応じて依存関係を置き換えたり、別のツールをテストしたりするのは簡単です。

GSAP

タイムライン管理と複雑なアニメーションには、GSAP を使用することにしました。

これほど簡単な方法で、ネストされたタイムライン、組み合わせたアニメーション、または複雑なテキストアニメーションを構築できるツールは、JavaScript エコシステムで他にありません。

私は GSAP ビジネスライセンスを持っているので、追加のツールを活用してより多くのことをシンプルにすることもできます。

主要な課題

バックエンドで使用するものについて詳しく説明する前に、JavaScript でビデオエディタを構築する際に解決する必要があるいくつかの課題を見てみましょう。

ビデオ/オーディオをタイムラインと同期する

この質問は GSAP フォーラムでよく聞かれます。

タイムライン管理に GSAP を使用するかどうかは関係ありません。必要なことはいくつかあります。

各レンダリングティック:

タイムラインに対するビデオの相対時間を取得します。ビデオがタイムラインの 10 秒マークで最初から再生を開始するとします。

そうですね、10 秒前まではビデオ要素は実際には気にしませんが、タイムラインに入ったらすぐに同期を保つ必要があります。

ビデオの相対時間を計算することでこれを行うことができます。これは、ビデオ要素の currentTime から計算し、現在のシーン時間と比較し、許容可能な「ラグ」期間内で計算する必要があります。

遅延が、たとえば 0.3 秒より大きい場合は、ビデオ要素を自動シークして、メインタイムラインとの同期を修正する必要があります。これはオーディオ要素にも当てはまります。

考慮する必要があるその他の事項:

再生/一時停止/終了状態を処理します
ハンドルを探しています

再生と一時停止は簡単に実装できます。シークのために、ビデオシークコンポーネント ID を svelte StateManager に追加します。これにより、状態が自動的に「読み込み中」に変更されます。

StateManager には EventManager 依存関係があり、状態が変化するたびに自動的に「changestate」イベントがトリガーされるため、$effect を使用せずにこれらのイベントをリッスンできます。

シークが終了し、ビデオを再生する準備ができた後も、同じことが起こります。

これにより、一部のコンポーネントの読み込み時に UI に再生/一時停止ボタンの代わりに読み込みインジケーターを表示できます。

テキストのレンダリングは思っているほど単純ではありません

CSS、GSAP、および GSAP の TextSplitter を使用すると、テキスト要素で本当に素晴らしいことができます。

ネイティブキャンバステキスト要素は制限されており、アプリの主な使用例はソーシャルメディア用の短い形式のビデオを作成することであるため、適切ではありません。

幸いなことに、ほぼすべての HTML テキストをキャンバスにレンダリングする方法を見つけました。これはビデオ出力のレンダリングに不可欠です。

Pixi HTMLText

これが最も単純な解決策だったでしょう。残念ながら、私には効果がありませんでした。

GSAP を使用して HTML テキストをアニメーション化すると、大幅に遅れが生じ、また、GSAP で試した多くの Google フォントもサポートされませんでした。

サトリ

Satori は素晴らしいもので、より単純なユースケースで使用されることが想像できます。残念ながら、一部の GSAP アニメーションは、Satori と互換性のないスタイルを変更するため、エラーが発生します。

異物を含む SVG

最後に、これを解決するためのカスタムソリューションを作成しました。

難しい部分は絵文字とカスタムフォントのサポートでしたが、なんとか解決できました。

次のような SVG を生成する、generateSVG メソッドを持つ SVGGenerator クラスを作成しました。

<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}" viewBox="0 0 ${width} ${height}" version="1.1">${styleTag}<foreignObject width="100%" height="100%"><div xmlns="http://www.w3.org/1999/xhtml" style="transform-origin: 0 0;">${html}</div></foreignObject></svg>

ログイン後にコピー

styleTag は次のようになります:

<style>@font-face { font-family: ${fontFamilyName}; src: url('${fontData}') }</style>

ログイン後にコピー

これが機能するには、渡す HTML のインラインスタイル内に正しいフォントファミリが設定されている必要があります。フォントデータは、data:font/ttf;base64,longboringstring

のような、base64 でエンコードされたデータ文字列である必要があります。

3. コンポーネントのライフサイクル

継承よりも構成、と彼らは言います。

実際に手を動かす練習として、継承ベースのアプローチからフックベースのシステムにリファクタリングしました。

私のビデオエディタでは、VIDEO、AUDIO、TEXT、SUBTITLES、IMAGE、SHAPE などの要素をコンポーネントと呼んでいます。

これを書き換える前は、BaseComponent という抽象クラスがあり、各コンポーネントクラスはそれを拡張しており、VideoComponent にはビデオなどのロジックがありました。

問題は、すぐにめちゃくちゃになってしまうことでした。

コンポーネントは、レンダリング方法、Pixi テクスチャの管理方法、アニメーション方法などを担当します。

現在、コンポーネントクラスは 1 つだけあり、非常に単純です。

これには 4 つのライフサイクルイベントが含まれています:

<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}" viewBox="0 0 ${width} ${height}" version="1.1">${styleTag}<foreignObject width="100%" height="100%"><div xmlns="http://www.w3.org/1999/xhtml" style="transform-origin: 0 0;">${html}</div></foreignObject></svg>

ログイン後にコピー

Building a TypeScript Video Editor as a Solo Dev

このコンポーネントクラスには、動作を変更する addHook というメソッドがあります。

フックはコンポーネントのライフサイクルイベントにフックし、アクションを実行できます。

たとえば、ビデオとオーディオのコンポーネントに使用する MediaHook があります。

MediaHook は、基礎となるオーディオ要素またはビデオ要素を作成し、それをメインのタイムラインと自動的に同期させます。

コンポーネントを構築するために、ディレクターパターンとともにビルダーパターンを使用しました (リファレンスを参照)。

このようにして、オーディオコンポーネントを構築するときに、それに MediaHook を追加し、ビデオコンポーネントにも追加します。ただし、ビデオには次の追加のフックも必要です。

テクスチャの作成
スプライトの設定
シーン内の適切な位置を設定する
レンダリングの処理

このアプローチにより、レンダリングロジックやシーン内でのコンポーネントの動作の変更、拡張、修正が非常に簡単になります。

バックエンドとレンダリング

最速かつ最もコスト効率の高い方法でビデオをレンダリングする方法について、複数の異なるアプローチを試しました。

2020 年、私は最も単純なアプローチ、つまり多くのツールで行われているフレームを次々にレンダリングすることから始めました。

試行錯誤した後、レンダリングレイヤーのアプローチに切り替えました。

これは、SceneData ドキュメントにコンポーネントを含むレイヤーが含まれていることを意味します。

これらの各レイヤーは個別にレンダリングされ、ffmpeg と結合されて最終出力が作成されます。

レイヤーには同じタイプのコンポーネントのみを含めることができるという制限がありました。

たとえば、ビデオを含むレイヤーにはテキスト要素を含めることはできません。他のビデオのみを含めることができます。

これには明らかに長所と短所があります。

Lambda 上でアニメーション付きの HTML テキストを個別にレンダリングし、透明なビデオに変換し、最終出力のために他のチャンクと組み合わせるのは非常に簡単でした。

一方、ビデオコンポーネントを含むレイヤーは ffmpeg で単純に処理されました。

しかし、このアプローチには大きな欠点がありました。

ビデオの拡大縮小、フェード、回転を行うキーフレームシステムを実装したい場合は、fluent-ffmpeg でこれらの機能のポートを作成する必要があります。

それは間違いなく可能ですが、私には他のすべての責任があるため、それができませんでした。

そこで、最初のアプローチ、つまり 1 つのフレームを次々にレンダリングする方法に戻ることにしました。

Express と BullMQ

レンダリングリクエストは Express を使用してバックエンドサーバーに送信されます。

このルートは、ビデオがまだレンダリングされていないかどうかを確認し、レンダリングされていない場合は、BullMQ キューに追加します。

劇作家 / 人形遣い

キューがレンダリングの処理を開始すると、ヘッドレス Chrome の複数のインスタンスが生成されます。

注: この処理は、AMD EPYC 7502P 32 コアプロセッサーと 128 GB RAM を搭載した専用の Hetzner サーバーで実行されるため、非常にパフォーマンスの高いマシンです。

Chromium にはコーデックがないので、Chrome のインストールが簡単になる Playwright を使用していることに注意してください。

それでも、何らかの理由でビデオフレームが真っ黒になってしまいました。

きっと何かが足りなかったんだと思います。ただし、ビデオを使用する代わりに、ビデオコンポーネントを個々の画像フレームに分割し、サーバーレスブラウザで使用することにしました。

それでも、最も重要なのはスクリーンショットの使用を避けることです。

すべてが 1 つのキャンバスにあるため、キャンバス上で .getDataURL() を使用して画像に取り込むことができ、はるかに高速になります。

これを簡単にするために、ビデオエディタをバンドルし、いくつかの機能をウィンドウに追加する静的ページを作成しました。

これは Playwright/Puppeteer でロードされ、各フレームで次のように呼び出すだけです。

<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}" viewBox="0 0 ${width} ${height}" version="1.1">${styleTag}<foreignObject width="100%" height="100%"><div xmlns="http://www.w3.org/1999/xhtml" style="transform-origin: 0 0;">${html}</div></foreignObject></svg>

ログイン後にコピー

これにより、画像として保存するか、ビデオチャンクをレンダリングするためにバッファに追加できるフレームデータが得られます。

このプロセス全体は、ビデオの長さに応じて 5 ～ 10 個の異なるワーカーに分割され、最終出力にマージされます。

これの代わりに、Lambda などにオフロードすることもできますが、私は RunPod を使用することに傾いています。彼らのサーバーレスアーキテクチャの唯一の欠点は、私があまり詳しくない Python を使用していることです。

この方法では、レンダリングがクラウド上で処理される複数のチャンクに分割される可能性があり、60 分のビデオのレンダリングでも 1 ～ 2 分で完了できます。それは嬉しいことですが、それは私たちの主な目標や使用例ではありません。

(まだ)解決できなかったこと

Pixi 8 から Pixi 7 にダウングレードした理由は、Pixi 7 には 2D キャンバスをサポートする「レガシー」バージョンもあるためです。これはレンダリングがはるかに高速です。 60 秒のビデオはサーバー上でレンダリングするのに約 80 秒かかりますが、キャンバスに WebGL または WebGPU コンテキストがある場合、1 秒あたり 1 ～ 2 フレームしかレンダリングできませんでした。

興味深いことに、私のテストによると、WebGL キャンバスをレンダリングする際、サーバーレス Chrome はヘッドフル Firefox に比べてはるかに遅かったです。

専用の GPU を使用しても、レンダリングの速度は大幅に向上しませんでした。私が何か間違ったことをしたか、単にヘッドレス Chrome が WebGL であまりパフォーマンスが良くないかのどちらかです。

私たちのユースケースにおける WebGL は、通常非常に短い遷移に最適です。

これに関してテストする予定の方法の 1 つは、WebGL チャンクと非 WebGL チャンクを別々にレンダリングすることです。