画面共有を4倍高速化した方法

画面共有のレイテンシは、悪いときにしか気づかない類の問題です。発表者がクリックして次のスライドに進むと、共有画面を見ている会場には一拍半遅れて表示されます。壊れているわけではないものの、どこかずれている。私たちは数回のリリースにわたって、Cliqerの画面共有で遅延がどこから生じているのかを徹底的に調べ、常時発生していたレイテンシを2秒超から約0.5秒まで短縮し、およそ4倍の改善を実現しました。本記事では、その方法をわかりやすく説明します。

コードネームでごまかしたり、たった一つの特効薬があったかのように装ったりするつもりはありません。実際には3つの独立した修正があり、それぞれが遅延の潜む別々の箇所を狙ったもので、その効果が積み重なりました。

そもそも画面共有が遅れる理由

画面を共有するとき、視聴者がフレームを目にするまでに3つのことが起きる必要があります。お使いのマシンがフレームをキャプチャし、映像にエンコードし、送信することです。これらのどのステップも人知れず遅延を加える可能性があり、その影響は積み重なります。遅いエンコーダー、慎重すぎるバッファ、次の完全なフレーム更新の待機が重なれば、高速な回線でも簡単に2、3秒に達します。

厄介なのは、どれも単体では壊れているように見えないことです。キャプチャは動作し、エンコードも動作し、ストリームも届きます。ただ遅れているだけで、「ただ遅れているだけ」という問題は、各段階を個別に計測しなければ診断が困難です。

修正その1：同じ画像を二度エンコードしない

最初の遅延の原因は無駄な処理でした。画面共有とNDI共有は裏側で出力経路ごとに一度ずつ、計二度エンコードされており、静止したスライドも画面上に何の変化もないのに絶えず再エンコードされていました。これにより、見た目の利点が何もないままエンコーダーの負荷が倍増し、パイプラインは常に必要以上に混雑した状態となって、すべてのフレームがキューの後ろへと押しやられていました。

重複したエンコード処理を取り除き、画像に変化がないときは再エンコードをスキップするようにしたことで、すぐに大きなCPUの余裕が生まれました。エンコーダーでの競合が減れば、エンコードが必要なフレームはすべて、より早く処理されます。

修正その2：耐障害性を損なわずにバッファを詰める

2つ目の原因は、エンコーダーとネットワークの間にあるバッファでした。これは一瞬のネットワークの乱れを吸収し、回線上の途切れが画面上の途切れにつながらないようにするための部分です。この種のバッファは本質的にトレードオフです。小さすぎればわずかな乱れで目に見える不具合が起き、大きすぎれば、後で何か問題が起きた場合に備えて、すべてのフレームに遅延を加えることになります。

このバッファは余裕を持たせたサイズに設定されていたため、まれなケースに備えるために、通常のケースでもすべてのフレームに遅延を加えていました。バッファを詰めたことで、最悪の場合の遅れは数秒から1秒を大きく下回るまでに短縮され、しかも一瞬のネットワークの乱れは目に見える不具合なしに乗り切れます。差分上では小さな数値の変更に見えても、実際にはどちらの障害モードを選ぶかという判断が問われる、そんな種類の修正です。

修正その3：新しい視聴者を次のキーフレームまで待たせない

3つ目の修正は、特につらい瞬間、つまりすでに進行中の共有に誰かが参加したときを対象としたものです。映像圧縮は、キーフレームと呼ばれる完全なフレームをときどきだけ送り、その間は「前回から何が変わったか」だけを伝える軽量なフレームを送る仕組みです。ストリームの途中から参加した視聴者は、基準となるキーフレームを受け取るまで、その中間フレームを解釈できません。これまでは、最大3秒先にある次の定期的なキーフレームを待つ必要がありました。

修正では、最新のキーフレームをキャッシュしておき、新しい視聴者が参加した瞬間にそれを渡すようにしました。次の予定されたキーフレームを待たせることはありません。画面共有のドキュメントで説明している間隔ベースのフレームタイミングと組み合わせることで、新しい視聴者は最大3秒も次のキーフレームを待つことなく、共有に参加してから数ミリ秒以内に映像を見られるようになりました。

3つの修正をすべて積み重ねた結果、多くの人が今ひとつ信頼しきれなかった2秒超の常時レイテンシは約0.5秒となり、およそ4倍の改善を達成しました。しかも以前よりCPUと帯域幅の使用量も減っています。ここではフルフレームレートも重要です。プログラム映像は、ソースにかかわらず人知れず約31fpsに制限されていましたが、今では60fpsの共有が、受信側でも発表者自身の画面と同じくらい滑らかに表示されます。

今プレゼンしているなら、これは何を意味するのか

設定の変更は一切必要ありません。これらはデスクトップアプリの画面共有パイプラインに組み込まれており、小さな会場に1台のモニターを共有する場合でも、複数のソースを使った本格的なStudioプロダクションを運用する場合でも適用されます。高速で予測可能なフィードに頼るvMixのワークフローも同様です。Cliqer 3では、Mac上のStudioの映像はゼロコピーです。カメラフレーム、ソース、ProgramはGPUメモリ上に留まり、ハードウェアエンコーダーはGPUサーフェスから直接Programを読み取ります。さらにCliqer 3では、Programのフレームレート、GPU負荷、CPU負荷を常にStudioのステータスラインに表示するため、本番中にご自身でフレームレートを確認できます。レイテンシの改善に加えて画質と帯域幅のバランスを調整したい場合は、画面共有の設定でコーデック、解像度、ビットレートを選べます。また、デスクトップ版2.2.0では、システム音声やマイク音声を共有に直接含めるオプションが追加されました。

遅延が最も目立っていたハイブリッド環境、特にリモートの発表者が共有画面を見ながらリアルタイムで反応する場面については、ハイブリッド会議での画面共有のレイテンシを解消するためのガイドや、映像側と同じく操作側でもプレゼンリモコンのレイテンシ（ミリ秒単位）が重要である理由を解説した記事もあわせてご覧ください。

残りのレイテンシはどこで生じるのか

画面共有は道のりの一部にすぎません。もう一方はネットワーク経路そのものです。発表者と視聴者の接続が直接か中継か、そして直接のピアツーピア通信をブロックするネットワークでは何が起きるのか。一部のネットワークではそれを完全には解消できない理由も含め、その側面についてはTURNサーバーの仕組みとWebRTCは安全かで解説しています。

よくある質問

実際に試してみましょう

違いを実感する一番の近道は、画面を共有して、それを見た相手の表情を観察することです。Cliqerを無料でダウンロードしてご自身の環境で画面共有を試すか、画面共有で全機能をご覧いただき、料金でプランを比較してください。