【ITニュース解説】Rendering live broadcast graphics without a GPU, and what four hours actually cost

ライブ放送の現場では、映像にテロップやスコア、アニメーションといったグラフィックを重ねて表示する「オンエアグラフィック」が欠かせない。これまでは、このグラフィックの生成と合成のために、高性能なGPU（Graphics Processing Unit）を搭載した専用のワークステーションが必須とされてきた。しかし、このニュース記事では、VSporteという企業が、このGPUワークステーションを使わずに、ライブ放送グラフィックをレンダリングする画期的な方法を開発した経緯と、その具体的な技術、そしてコスト削減効果について詳しく説明している。

開発のきっかけは、従来のシステムが抱えていたいくつかの課題だった。以前は、グラフィックが「vMix」というミキサーのメモリに直接読み込まれており、グラフィックのテストや修正が難しかった。また、グラフィックのデザイン作業が開発者に依存しており、効率が悪かった。そこで、まずグラフィックをvMixから切り離し、ウェブページとしてミキサーに入力する形に変更することで、テストのしやすさを向上させた。次に、「Rive」というツールを導入し、グラフィックのレイアウト作業を開発者からデザイナーへ移行した。

このRiveの導入が予期せぬ大きな転換点となる。Riveで作られたグラフィックは、内部に「ステートマシン」と呼ばれる、特定の条件に応じて表示やアニメーションが変化する仕組みを持つファイルとなる。そして、このファイルは「プレーンなデータ」で駆動されるため、グラフィックのレンダリング（コンピュータが計算して画像を作り出すこと）に、必ずしもウェブブラウザやGPUが必要ではないことに気づいたのだ。これまでGPUが必要だと思われていたのは、単にそれらのグラフィックを生成する「ツール」がGPUを使うように設計されていたからだった。

この発見が、GPUなしでのレンダリングへの挑戦へとつながった。最初は、ヘッドレスブラウザ（画面を持たないブラウザ）を使ってグラフィックのスクリーンショットを撮る方法を試したが、これは効率が良くなかった。次に、WebAssembly（ウェブブラウザ以外でもウェブ技術を動かす技術）を使ってCPU上でレンダリングする方法を試した。最終的にたどり着いたのが、RiveのネイティブビルドをCPU上で直接動かす方法だった。特に、「Skia」という高性能な2Dグラフィックライブラリを組み合わせることで、GPUなしでもスムーズなレンダリングが可能になった。SkiaはGoogle Chromeのウェブページ描画やAndroidのユーザーインターフェース描画にも使われている、実績のある技術である。この組み合わせにより、8コアのCPUでフルHD（1080p）画質のグラフィックを毎秒30フレームでレンダリングできる性能を達成した。ただし、この方法ではフォントの種類や自動レイアウトなど、一部の高度な機能が利用できないという制約もある。

新しいシステムは「Dockerコンテナ」という、アプリケーションとその実行環境をまとめてパッケージ化した技術として実装された。このコンテナ内では、主に四つの役割（スレッド）が並行して動いている。一つ目は「StateManager」で、グラフィックの状態情報（表示するRiveファイルやアニメーションの種類など）をウェブソケットという技術でリアルタイムに受け取り、必要なグラフィックデータや素材をダウンロードする。二つ目は「SrtReceiver」で、入力されてくるライブ映像データ（SRTストリームという動画伝送技術で送られてくる）をデコードして、コンピューターで処理できる生の映像フレームに変換する。三つ目が肝心な「RiveRenderer」で、StateManagerから受け取ったグラフィック情報とSkiaを使って、CPU上でグラフィックをピクセルデータに変換する（ラスタライズする）。そして四つ目の「Compositor」が、SrtReceiverでデコードされた映像フレームの上にRiveRendererが生成したグラフィックを重ね合わせ、再び動画データ（libx264という圧縮技術でエンコード）に変換して、SRTストリームとして出力する。

このシステムの大きな特徴は、その構成（トポロジー）にある。グラフィックのない「クリーンフィード」（元の映像）は、このコンテナを経由せず、直接ミキサーに送られる。コンテナが処理するのは、グラフィックを合成する「ダーティパス」と呼ばれる映像だけである。この仕組みにより、たとえグラフィックを処理するコンテナが故障しても、ミキサーにはクリーンフィードが届き続けるため、放送が完全に停止することなく、一時的にグラフィックなしの映像に切り替わるだけで済む。これは、国際的なパートナーや広告挿入を行う際にも重要なポイントとなる。

ライブ放送において最も重要な要素の一つは「遅延」（レイテンシ）である。映像の入力からグラフィックが合成されて出力されるまでの時間をいかに短く抑えるかが鍵となる。このシステムでは、遅延を最小限に抑えるための工夫がいくつも施されている。例えば、SRTストリームの入力では、ネットワークのパケット損失から回復するためのバッファが数100ミリ秒かかるが、これは映像の安定性を優先した「意図的な遅延」である。グラフィックの状態変化はウェブソケットでリアルタイムに伝えられるため、この部分の遅延はほぼゼロだ。映像のエンコードには、遅延を最小限に抑えるよう最適化されたlibx264が使われ、フレームの再配置などの遅延要因となる処理は無効化されている。さらに、コンテナ内部の異なるスレッド間でデータを受け渡すためのキューが長くなりすぎると遅延が発生するため、あえてフレームをドロップすることで、見えない遅延が蓄積するのを防ぐ対策も取られている。

この新しいシステムによって得られる最大のメリットは、コストの大幅な削減である。GPUを搭載しないCPUノードは、同等のGPUワークステーションと比較して非常に安価だ。記事の試算では、8vCPUと16GBのRAMを搭載したクラウドインスタンス（仮想サーバー）で、フルHD画質、30フレーム/秒、6メガビット/秒のグラフィック処理を4時間行った場合、約1ドルから2ドル程度の費用で済むとされている。これは、従来のGPUワークステーションを並行する放送ごとにレンタルルームに設置し、購入していたコストと比較すると格段に安い。ただし、クラウドサービスを利用する際には、データ転送にかかる「トラフィック費用」が別途発生する場合があるため、その点も考慮に入れる必要があると注意を促している。特に、多数の低価格な並行イベントを行う場合に、このコスト削減効果が顕著になる。

しかし、この技術が万能ではないことも明確にされている。例えば、3Dグラフィックや重いパーティクルエフェクトなど、シェーダー（GPUが高速に処理するプログラム）を本格的に必要とするグラフィックには、CPUベースのレンダリングは不向きだ。また、SDI入出力やゲンロック（映像信号の同期）といった、スタジオの専用ハードウェアとの厳密なフレーム同期が必要なシステムには、ネットワーク上のクラウドコンテナは適していない。さらに、このコストメリットはフルHD画質で30フレーム/秒という条件を前提としており、欧州の放送で一般的な毎秒50フレームや、4K解像度、高ビットレートといった要求になると、CPUの処理能力では追いつかなくなり、結局高性能なハードウェアが必要になる可能性もある。

この取り組みから得られる最も重要な教訓は、「技術インフラのどの部分が、実際にやりたい『仕事』のために必要なものであり、どの部分が、これまでの『ツール』がたまたま必要としていたものなのか」を常に問い続けることだ。VSporteのケースでは、GPUが「仕事」ではなく「古いツール」によって必要とされていた部分であり、それを見直すことで、思いがけないコスト削減と効率化が実現した。クラウドへの移行は、最初から目的としていたわけではなく、技術的な課題を一つ一つ解決していった結果として、最終的に最も効率的な手段として浮かび上がってきたものなのである。