低帯域での画面共有でH.264の動画ストリーミングをJPEG形式のスクリーンショットの連続表示に置き換えて解決する

クラウドサンドボックス内で自律コーディングエージェントが動作する企業向けAIプラットフォーム「HelixML」では、AIアシスタントの動作を監視するため、画面をリモートで共有する仕組みが搭載されています。この画面共有は基本的にH.264でエンコードされた動画を配信して行われていますが、低帯域環境だと画面共有できない問題を「JPEG形式でスクリーンショットを取得して送信する」という方法で解決したと、開発チームがブログで解説しています。

We Mass-Deployed 15-Year-Old Screen Sharing Technology and It's Actually Better
https://blog.helix.ml/p/we-mass-deployed-15-year-old-screen

画面共有で動画を送受信する仕組みとしては、WebRTCが存在します。しかし、企業ネットワークではUDPが塞がれたり優先度を落とされたりしやすく、WebRTCはTURNプロトコルの都合でUDPが使用されるため、「社内環境だと映像がつながらない」という問題に直面しやすいとのこと。

そのため、開発チームはあらゆるプロキシやファイアウォールをHTTPSの443番ポートに寄せ、WebSocketで映像フレームを流す構成に切り替えました。実装としては、GStreamerとundefinedでH.264をハードウェアエンコードし、ブラウザ側はWebCodecsでハードウェアデコードすることで、フレームレート60fps・ビットレート40Mbps・レイテンシ100ms未満で動画を配信できるというところまで作り込んだそうです。

しかし、この動画配信システムは開発環境だと快適に動作したものの、カフェなどの不安定なWi-Fi環境では破綻してしまったとのこと。これは、TCP(WebSocket)が順序保証をするためで、ネットワークが混雑するとTCPのバッファリングによって遅延が蓄積し、実際の操作から映像が数秒、時には数十秒単位で遅れてしまいました。

当初、この問題を解決するため、開発チームは「キーフレーム」だけを送信するモードを作ろうとしました。

動画配信で一般的に使われるH.264というコーデックは、データ量を節約するために全てのフレームを完全な画像として送ることはせず、前の画面から変化した部分だけの情報である｢差分｣データを中心に送信しています。すべての情報を持つ基本となるフレームをキーフレーム、差分で表現されるフレームをPフレームと呼びます。

60fpsの動画の場合、通常は1秒当たり60枚のフレームを送りますが、そのうち59枚のPフレームをすべて捨ててしまい、残りの1枚となるキーフレームだけを送信するように設定しました。こうすると、動画は1fpsのカクカクした動きになりますが、通信量は大幅に削減できます。

ところが、実際に運用してみると、映像は最初の1枚が表示されたきりで、画面は完全に止まってしまいました。その原因は、通信の土台として使っていたMoonlightプロトコルの仕様にありました。このMoonlightプロトコルに「フレームを消費しないなら次を出さない」といった制御が存在したため、部分的なフレーム破棄にうまく対応できなかったというわけです。

この問題を解決したのが、デバッグ用に用意していたスクリーンショット取得APIでした。

このAPIを叩くと、1枚あたり100KBから150KB程度の軽量なJPEG画像を秒間数回取得することが可能。ブラウザで開くと、1080pデスクトップのJPEG画像が一瞬で表示され、更新を連打すると5fps程度できれいな静止画が届きます。

JPEG画像は1枚で自己完結しているため、届けば必ず完全な画像として表示され、動画のような「次のキーフレーム待ち」や「デコーダ状態の破損」が起きにくいのが強み。しかも、H.264のキーフレームが200KBから500KBという容量なのに対し、JPEG画像は70％品質・1080pのJPEG画像が100KBから150KB程度であることから、状況によってはJPEGのほうが1フレーム当たりの転送量も軽いケースもあり得ます。

そこで、開発チームは「良い回線ではH.264を使い、悪い回線ではJPEGポーリングへ切り替える」というハイブリッド構成を採用しました。ネットワークの往復遅延時間(RTT)が150ms未満の良好な接続ではH.264による滑らかな動画を表示し、150msを超えると自動的に動画を停止してJPEG画像送信に切り替えるというわけです。

ただし、H.264配信を止めるとWebSocketが軽くなってRTTが改善し、監視ロジックが「回線回復」と誤判定して動画を再開し、再開すると再び混雑してスクリーンショットへ戻る、という約2秒周期での切り替わりが連続することも起こります。そのため、開発チームはH.264配信への復帰は自動ではなく、ユーザーが手動でボタンをクリックする仕様としました。

この経験を通じて開発チームは、「洗練された複雑な技術よりも、古くて単純な解決策の方が現実世界の厳しい環境下では有効である場合がある」と結論づけ、15年を遡るような古い技術が現在の問題を解決する鍵となったことを「逆説的に優れている」と評価しています。

なお、ソーシャルニュースサイトのHacker Newsでは「遅延が積み上がる根本原因は輻輳制御や帯域推定が弱い点にあるとして、初期の帯域プローブや送信遅延の増加を混雑シグナルとしてビットレートやフレームレートを落とす制御を入れるべき」「HTTP Live Streamingで動画のチャンクを配信し、適応ビットレート再生で回線状況に応じて品質を切り替えるのはどうか」「画面を動画にして送るのではなく、文字列などのアプリケーションデータとして送り、受け手側で再構成するのはだめなのか」「TCPであっても送り手側でフレームをため込まない設計と、フィードバックを前提にした送信制御を入れるべき。FFmpegなど、挙動を理解しやすい低レベルなライブラリを使うのもあり」といった意見も見られました。