WebRTC 画面共有は本当に優れているのか? 4 つのコーデックをテストしてみた

WebRTC 経由の画面共有に関して、さまざまなコーデックがどのように比較されるのか、ずっと興味がありました。そこで、最も一般的な 4 つのコーデックである VP8、VP9、H.264、AV1 をテストして、自分で調べてみることにしました。

結果が確実であることを確認するために、さまざまなコンテンツ タイプとネットワーク条件でテストを実行しました。視覚的な印象だけに頼るのではなく、フレームごとの比較を使用し、ピーク信号対雑音比 (PSNR) を計算し、詳細な WebRTC 統計を取得して、明確でデータに基づいたビューを取得しました。

さらに一歩進んで、エンコードとデコードの両方で CPU 使用率を追跡するカスタム Chrome プラグインも作成しました。これにより、各コーデックがシステム パフォーマンスにどのように影響するかを詳しく調べることができました。品質は素晴らしいですが、それに追いつこうとしてコンピューターが燃え尽きてしまうようでは意味がありません。

私は、ビットレート、フレーム レート、解像度、量子化 (QP)、PSNR、CPU 負荷などの主要な指標を調べました。それらすべてに基づいて、WebRTC 画面共有を独自のユースケースに合わせて最適化しようとしている人に役立つ実用的な推奨事項をいくつか考え出しました。

実験について

画面共有が見た目ほど簡単ではない理由

ビデオ通話中に画面を共有したときに、画質が低下したり、ビデオが途切れたりしたことに気づいたことがある人は、あなただけではありません。画面共有を鮮明かつスムーズに保つことは、実は思ったよりも難しいのです。

問題は、多様性です。コンテンツの中には、スライド デッキやドキュメントのように静止しているものもあります。また、動きの速いビデオを共有することもあります。これらの異なる種類のコンテンツは、コーデックにまったく異なるものを要求します。たとえば、動きの速いビデオは大量の帯域幅を消費しますが、静止画像は圧縮アーティファクトの影響を受けやすく、ぼやけたりブロック状に見えたりすることがあります。

パケット損失や帯域幅の低下など、実際のインターネットの問題が加わると、状況はさらに複雑になります。そのため、適切なコーデックを選択し、その動作を微調整することが、画面共有を高品質かつ応答性の高いものにするために非常に重要です。

一般的なストリーミング シナリオでビデオ コーデックがどのように機能するかについては、すでに多くの研究が行われています。しかし、画面共有には独特の癖があります。これは単にビデオを見るだけではなく、リアルタイムでやり取りすることであり、コンテンツの種類は多岐にわたります。つまり、通常の研究が必ずしも当てはまるとは限りません。

私がやろうとしたこと

私はこの特定のユースケースをさらに深く掘り下げたいと考えました。私の目標は、特にさまざまなコンテンツ タイプや予測できないネットワーク状態などの現実世界の制約下で、画面共有に関してさまざまなコーデックがどのように機能するかを確認することでした。

そのために、私は画面共有の品質をできるだけ正確に評価する方法を設計しました。見た目だけではなく、確かな指標とデータに基づいて評価する方法です。その過程で、どのコーデックが最も優れているか、リアルタイム アプリケーションでパフォーマンスを向上させるために微調整する方法について多くのことを学びました。

すぐに明らかになったことが 1 つあります。画面共有のパフォーマンスは、共有する内容によって大きく左右されるということです。テンポの速いビデオの動作は、静的なドキュメントや Web ページのゆっくりとしたスクロールとはまったく異なります。

公平性と一貫性を保つために、すべてのテストがまったく同じ条件 (同じ解像度、同じ開始点、同じ期間) で実行されるようにしました。こうすることで、結果はすべてコーデックのパフォーマンスに関するものであり、偶発的な変数によるものではないと確信できました。

実際の画面共有状況をシミュレートするために、2 つの異なるテスト ケースを作成しました。

• ハイモーション ビデオ- これは、森の中を猛スピードで走るバイクの実際のクリップです。素早い動き、詳細な風景、絶えず変化する視覚環境など、圧縮の限界を押し上げるのに最適です。

• 自動スクロールテキスト- テキストと画像を含むシンプルな HTML ページを作成し、JavaScript を使用して一定の速度でスクロールしました。これは、ドキュメントの共有や Web ページの読み取りなどの一般的な使用例を模倣したものです。

これら 2 種類のコンテンツを組み合わせることで、動きに対応することから、より静的なシーンでの鮮明さの維持まで、各コーデックがさまざまな課題にどのように対処するかをテストするのに適した組み合わせが得られました。

すべてをセットアップする方法

コーデックを適切にテストするには、送信内容と受信内容の両方をキャプチャできる堅牢なセットアップが必要でした。私はwebrtc-sandboxというツールから始めました (ちなみに、このツールとその他のツールについては、私の別の投稿「 WebRTC の実践学習: 最適なツールとデモ」で学べます)。これは、WebRTC の内部をいじるのに最適です。最終的には、画面共有をより適切に処理し、送信ビデオ ストリームと受信ビデオ ストリームの両方を記録できるように、かなり調整しました。テストを実行するたびに、送信内容と受信内容の 2 つのビデオ ファイルが作成され、後で並べて分析するために使用しました。

しかし、私はビデオだけに留まりませんでした。裏で何が起こっているかも追跡したかったのです。そのために、Chrome ブラウザから詳細な WebRTC 統計情報を直接取得しました。これらの統計情報から、各コーデックのパフォーマンスや、各テスト中のシミュレートされたネットワークの動作を把握することができました。

パズルの大きなピースの 1 つはCPU 使用率でしたが、これは少し難しいことがわかりました。Chrome の通常バージョンでは、プラグインが個々のタブの CPU 負荷を監視できないため、ブラウザの開発ビルドを使用して、これを回避するための独自のプラグインを作成しました。

私は特に、画面共有を送信または受信しているタブの CPU 使用率を測定することに焦点を当てました。こうすることで、ブラウザーの他の部分からの無関係なレンダリング タスクを除外しました。送信と受信の両方が同じタブで行われたため、取得した数値は組み合わせたビューでしたが、それでも実際の使用例で見られるものとかなり近いものでした。(ネタバレ: エンコードは通常、デコードよりも CPU に大きな負荷をかけます。)

データの収集: 157 回のテスト実行後...

セットアップの準備ができたら、実際の実験を実行する時間です。私は実験を何度も実行しました。ネットワーク条件とコーデック設定を変えて、同じマシンで何度もテストを繰り返し、結果を確認しました。合計で157 のデータ ポイントを収集し、テスト条件のあらゆる組み合わせが適切に表現されていることを確認しました。

これにより、作業に使用できる確実なデータセットが得られ、さまざまなシナリオで WebRTC の画面共有がどのように動作するかを詳細に分析できるようになりました。具体的にテストした内容は次のとおりです。

• ビデオタイプ:
  一般的な使用例を反映するために、2 種類の画面共有コンテンツを使用しました。
  • ハイモーション ビデオ- フレームごとに大量のピクセルが変化する現実世界の映像。
  • 自動スクロール テキスト- ほとんどは静的なビジュアルですが、テキストがスクロールするとピクセルの位置が移動します。
• コーデック:
  最も人気のある 4 つの画面共有コーデックをテストしました。
  • AV1
  • 264 形式
  • VP8
  • VP9
• ネットワーク帯域幅:
  帯域幅はビデオ品質（特にビデオ通話）に大きな役割を果たすため、さまざまなネットワーク条件をシミュレートして、各コーデックが厳しい帯域幅や変動する帯域幅をどの程度うまく処理できるかを確認しました。

これらの変数を構造的に組み合わせることで、ビデオ通話、ライブ デモ、共同リモート セッションなどで発生するような、実際の画面共有シナリオを模倣することができました。

不具合の修正: テストの信頼性を高める方法

ほとんどの実験と同様に、最初の数回の実行は期待したほどスムーズにはいきませんでした。すぐに 2 つの大きな問題が発生しました。

1. 手動開始 = タイミングが乱雑。最初は、画面共有を手動で開始していました。文字通りボタンをクリックして開始していました。問題は、録画の開始とビデオ コンテンツの開始を同期させることがほぼ不可能だったことです。つまり、テスト実行ごとにタイミングがわずかに異なり、比較がうまくいかなかったのです。
2. 送信と受信 = 同期が取れていない。タイミングが正しい場合でも、リアルタイム ビデオには独自の癖があります。エンコード、デコード、ネットワークの遅延により、送信ストリームと受信ストリームが完全に揃うことはありませんでした。そのため、フレームごとの品質比較はほぼ不可能でした。

これらの問題を解決するために、いくつかの重要な改善を加えました。

• プログラムによる同期: すべてを手動で開始する代わりに、ビデオの開始またはスクロールするテキストを録画プロセスと同期するコードを作成しました。こうすることで、すべてのテスト実行が両端でまったく同じ瞬間に開始され、問題が解決しました。
• QR コード フレーム マッチング: 同期ずれの問題を解決するために、共有ビデオに小さな QR コード オーバーレイを追加しました。この小さなマーカーはタイムスタンプのように機能し、送信ストリームと受信ストリームのフレームを正確に一致させることができました。突然、フレームごとの分析が可能になりました (しかも、はるかに正確になりました)。

考慮する必要のあることがもう 1 つありました。WebRTCのアダプティブ ビットレートです。WebRTC の優れた機能の 1 つは、利用可能な帯域幅に基づいてビデオ品質を自動的に調整することです。ただし、この調整は即座に行われるわけではなく、安定するまでに数秒かかります。そのため、実際の録画を開始する前に短い遅延を追加しました。これにより、システムがターゲット ビットレートに落ち着く時間ができ、結果には、物事が安定した後に得られる実際の品質が反映されます。

これらの変更により、実験の信頼性が大幅に向上し、収集したデータが実際の画面共有の動作を反映していることに自信が持てるようになりました。

私が測定した内容（そしてそれがなぜ重要なのか）

これらのテスト中に大量のデータを収集しましたが、わかりやすく比較しやすいように、画面共有シナリオで各コーデックがどのように機能するかを実際に示すいくつかの主要なメトリックに焦点を当てました。

私が調べたのは以下のものです:

• フレームレート
  これは、実際にエンコード、送信、受信された 1 秒あたりのフレーム数を示します。これは、ビデオ ストリームの滑らかさを示す良い指標です。通常、フレーム レートが高いほど、よりスムーズなエクスペリエンスが得られます。
• 解決
  解像度は、視覚的な詳細がどれだけ保持されるかにかかっています。私は、各段階 (送信と受信) でフレームあたりのピクセル数を追跡し、コーデックが画像品質を維持したか、それとも帯域幅を節約するために画質を落としたかを確認しました。
• ビデオ品質
  ここではいくつかの重要な指標を使用しました。
  • 量子化パラメータ (QP) – 一般的に、QP が低いほど品質は良くなります。
  • ピーク信号対雑音比 (PSNR) – 受信したビデオが元のビデオとどの程度異なるかを数値で表します。高いほど良いです。
• CPU使用率
  コーデックのパフォーマンスは、目に見えるものだけではありません。マシンが舞台裏で何を実行しているかも関係します。私は、各テスト中にエンコードとデコードに使用された CPU パワーを時間の経過と共に正規化して測定し、どのコーデックが軽量で、どのコーデックがリソースを大量に消費するかを確認しました。

これらの指標で細かく分析することで、品質だけでなく、スムーズさ、効率性、要求の厳しさについてもコーデックを比較することができました。これにより、実際の画面共有状況で各コーデックが優れている点と、劣っている点が明らかになりました。

最後に結果です

コンテンツの種類はどの程度重要ですか？想像以上に重要です

私の実験から得られた最も驚くべき結果の 1 つは、共有するコンテンツの種類が、ビデオ品質とリソース使用量の両方の点で、画面共有のパフォーマンスにどれほど影響を与えるかということでした。これは、私がテストしたすべてのコーデックに当てはまりました。

その背後にある考え方は非常に単純です。フレーム間でピクセルが変化すると（動きの速いビデオなど）、システムはより多くの処理を行わなければなりません。つまり、より多くの帯域幅が必要になり、CPU はそれに追いつくためにより多くの処理を行わなければなりません。

たとえば、 AV1 を見てみましょう。1.5 メガピクセルの画面を共有するために AV1 を使用した場合、共有する内容によって必要な帯域幅が大きく変化しました。コンテンツがより動的だった場合、スムーズなストリームを維持するために AV1 は大幅に多くのデータをプッシュする必要がありました。次のグラフにこれを示しましたが、コンテンツの複雑さが帯域幅の使用にどれほど劇的な影響を与えるかを示しています。

しかし、帯域幅だけの問題ではありません。ハードウェアもそれを感じます。

次のグラフは、共有されるコンテンツに応じて CPU 使用率がどのように変化するかを示しています。ここでも AV1 を例にすると、より複雑なビジュアルでは、同じフレーム レートと解像度で動作し続けるために、より多くの CPU パワーが必要になることがはっきりとわかります。

これは AV1 に限ったことではありません。すべてのコーデックは、ビデオのエンコードとデコードに同じ基本原理を採用しているため、同様の動作を示すことが予想されますが、データは異なることを示しています。CPU 負荷はコンテンツによって変化するだけでなく、使用しているコーデックによっても変化します。

比較しやすくするために、次の表を作成しました。これは、1.5 メガピクセルのビデオを約 24 フレーム/秒でストリーミングする場合に各コーデックが使用する CPU の量を示しています。これは、スムーズな画面共有のための一般的な設定です。この結果から、ハードウェアの使用に関して各コーデックがどれだけ効率的であるかという大きな違いが明らかになります。

したがって、WebRTC 画面共有に依存する何かを構築または最適化している場合、重要なのは、コンテンツとコーデックの選択の両方が重要であるということです。非常に重要です。

コーデック対決: フレームレート、CPU 負荷、品質の実際のコスト

画面共有に関して、最初に気づくことの 1 つは、ビデオがどれだけスムーズに感じられるか (または滑らかでないか) です。ここでフレーム レートが重要になります。ビデオ再生やアニメーションなど、動きの激しいコンテンツを共有する場合、途切れ途切れで見づらいストリームを避けるために、フレーム レートを高くすることが不可欠です。

実験のこの部分では、他のすべてを一定に保ちながら、さまざまcontentHintコーデックでのフレーム レート パフォーマンスに焦点を当てました。つまり、各テストで同じ解像度 (約 1.5 メガピクセル) と同じコンテンツを使用しました。contentHint WebRTC 設定を使用して、解像度が全体的に固定されていることを確認しました。

次の画像では、帯域幅が増加するにつれて、さまざまなコーデックが動きの激しいコンテンツをどのように処理するかがわかります。 x 軸: Mbps 単位のビットレート。 y 軸: 1 秒あたりのフレーム レート (fps)。

注目すべき点は次のとおりです:

• 帯域幅が 2 Mbps 以上に達すると、 H.264とAV1が先行し、どちらも 20 fps 以上を実現しました。これは、適切な 3G 接続でも実現可能なスムーズなエクスペリエンスです。
• VP8とVP9 は、それほど追いついていませんでした。同じ条件下ではフレーム レートが約半分で推移し、実際に使用できると感じるには 4 Mbps 以上が必要でしたが、これはローエンドのネットワークでは必ずしも現実的ではありません。

次に、動きの少ないコンテンツ(ゆっくりスクロールするテキスト ページ) に切り替えて、フレーム間であまり変化がない場合にコーデックがどのように機能するかを確認しました。

当然のことながら、このシナリオではH.264とAV1 の両方がさらに優れた結果を示し、 AV1 がトップに立っています。これは、AV1 が画面の変更されていない部分の再エンコードをスキップできるIntra Block Copyという機能のおかげです。これは、静的または半静的な画面共有に非常に効果的です。

次のグラフでは、AV1 がこれらの動きの少ない状況をいかに効率的に処理し、高画質を維持しながら帯域幅の使用量を大幅に抑えているかがわかります。

しかし…トレードオフがあります。

AV1 は、より優れたビジュアルと圧縮を提供しますが、 CPU の消費量も多くなります。次の画像では、これがはっきりと示されています。AV1 の CPU 使用率は、ビットレートが増加するにつれて着実に上昇し、H.264 をはるかに上回っています。H.264 は、広範囲にわたるハードウェア アクセラレーションにより、CPU 負荷が低く安定しているため、この点で大きな利点があります。

興味深いことに、 VP9 はAV1 よりもさらに多くのCPU を使用します。同様の傾向ですが、ピーク値は高くなります。VP9 と AV1 はどちらも、優れた品質を実現するために複雑なアルゴリズムに依存していますが、それにはコストがかかります。つまり、プロセッサに大きな負荷がかかります。

動きの少ないコンテンツを再検討したところ、意外な結果が生まれました。今回は、次のグラフに示すように、 VP8 と VP9 は実際にはかなり効率的で、AV1 よりも CPU の使用量が少ないことがわかりました。

AV1 は、画面共有を念頭に置いて設計されているにもかかわらず、依然として CPU を最も多く使用しています。なぜでしょうか? 動きの激しいビデオを圧縮するのに役立つすべての最適化によって、画面上であまり何も起こっていない場合でもオーバーヘッドが追加されます。

その大きな理由は、 AV1 にはまだ広範なハードウェア エンコード サポートがないことです。デコードは比較的軽量ですが、エンコードは依然として主にソフトウェアで行われ、特にエンコードとデコードの両方が絶えず行われる画面共有などのリアルタイム シナリオでは、CPU を集中的に使用するタスクになります。

ノートパソコンやタブレットなどのポータブル デバイスでは、この点が問題になります。ハードウェア アクセラレーションがないと、AV1 などのコーデックは電力を急速に消費し、リソースを大量に消費します。外出先で使用する場合には理想的ではありません。より優れたハードウェア サポートが普及するまで、AV1 の高度な機能には、かなり顕著なパフォーマンス コストが伴います。

コーデックと解像度: フレーム レートを優先すると何が起こるでしょうか?

これまで私が共有した結果は、解像度を一定に保ったテストから得たものです。帯域幅が逼迫すると、システムはフレーム レートを下げることで対応します。これは、静的コンテンツやテキストなどには理にかなっています。しかし、解像度を犠牲にしても、物事をスムーズに動かし続けることが目標の場合はどうでしょうか。

これを調査するために、フレーム レートを優先するように WebRTC を構成する新しい一連の実験を実行しました。これは、WebRTC のcontentHint設定を使用して実行されました。これにより、高解像度とスムーズな動きのどちらがより重要であるかをブラウザーに伝えることができます。

私は、フレーム レートを30 fpsで一定に保つことを目指しました。これは、スムーズで快適な視聴に最適な値として広く認識されています。これを一定に保つのは困難でした。アダプティブ ストリーミングでは常に多少の変動があるからです。しかし、この結果から、各コーデックがこのトレードオフをどのように処理するかについて貴重な洞察が得られました。

この動作を分析するために、新しい指標を導入しました。

1秒あたりの送信ピクセル数 = フレームレート × 解像度

これにより、FPS や解像度だけを見るよりも完全な画像が得られます。さまざまな条件下でコーデックが 1 秒あたりに実際に配信している視覚データの量が表示されます。

モーションの激しいビデオでは、 AV1 が再びトップに立ちました。しかも、その差は歴然としています。低いビットレートでも、他のコーデックよりも 1 秒あたりに大幅に多くのピクセルを転送できました。これは、システムが高いフレーム レートを維持するプレッシャーにさらされているときに、AV1 が動的コンテンツをいかにうまく処理できるかを明確に示しています。次のグラフをご覧ください。

スクロールするテキストのあるウェブページのような動きの少ないコンテンツに切り替えると、競争は少し均衡しました。次の画像でわかるように、すべてのコーデックのパフォーマンスはより均一になりました。ただし、特に高ビットレートでは、 AV1 が依然としてリードを保っていました。圧縮の最適化により、リソース使用量を大幅に増やすことなく、強力なスループットを維持できました。

これらは実際には何を意味するのでしょうか?

そうですね、ビデオウォークスルー、ライブアニメーション、ゲームストリーミングなど、動的で動きの激しいビジュアルを使用するユースケースの場合、フレームレートを優先することで大きな違いが生まれ、AV1 はそのような環境で特に優れていることが証明されています。

動きの遅いコンテンツでも、AV1 は強さを発揮し続けています。差は小さいかもしれませんが、高度な圧縮戦略により、AV1 は一貫してより多くの映像データを送信でき、同じかそれ以下の帯域幅でより優れた品質を実現しています。

どちらの場合も、 「1 秒あたりの送信ピクセル数」の指標は、帯域幅が制限されているときにコーデックが解像度とフレーム レートのバランスをどのように取るかを理解するのに役立ちました。また、これらの条件下での AV1 のパフォーマンスは、システムが追加の CPU 要求を処理できる場合、最も有能なオプションであることをさらに確固たるものにしています。

画像はどれくらいきれいですか? PSNRについて話しましょう

フレーム レート、解像度、CPU 使用率の他に、画面共有パズルのもう 1 つの重要な要素があります。受信した画像が元の画像にどれだけ近いかということです。ここで、ピーク信号対雑音比 (PSNR) が重要になります。

PSNR は、圧縮されたビデオの品質を測定するために広く使用されている指標です。エンコード中にどの程度の歪み、つまり「ノイズ」が発生したかを示します。これはデシベル (dB)で測定され、経験則は単純で、高いほど良いということです。PSNR が高いということは、画像が元の画像とほぼ同じように見えることを意味し、スコアが低いということは、劣化が目に見えることを意味します。

これを理解するために、私は 2 つの異なるシナリオでコーデック間の PSNR 値をテストしました。1 つは解像度が優先される場合、もう 1 つはフレーム レートが優先される場合です。一貫性を保つために、両方のテストで同じ高モーション ビデオ コンテンツを使用しました。

この設定では、鮮明さが重視されます (ビデオが多少途切れても)。H.264は特に優れたパフォーマンスを発揮し、歪みを最小限に抑えて鮮明な映像を実現します。滑らかさがそれほど重要でない場合は、H.264 が強力な選択肢となります。

滑らかな動きを維持することに目標が移ると、特に高ビットレートではAV1 が優位になります。フレーム レートの目標を達成するために積極的に圧縮しながらも、画質を維持することができます。

コーデック間の PSNR の違いは必ずしも劇的ではありませんが、コーデックを選択する際のトレードオフが強調されます。鮮明さを優先するものもあれば、スムーズな動きを狙うものもあります。使用状況によっては、どちらかが他方よりも適している場合があります。

次に、スクロールされたテキスト コンテンツを使用して、同じテストを再度実行しました。これは、解像度と明瞭さの重要性を非常に強調するものです。

モーションを優先すると、すべてのコーデックの PSNR 値は非常に似たものになります。コンテンツはあまり変化しないため、圧縮戦略の違いは全体的な画像品質にそれほど影響しません。

ここからが面白いところです。解像度を優先すると、特に高ビットレートではAV1 が他のコーデックよりはるかに優れています。ここでのパフォーマンスは抜群です。

なぜでしょうか? AV1 には、テキストなどの静的で反復的なコンテンツを処理するための特別な最適化が含まれています。これにより、画像の忠実度を高く維持し、アーティファクトを回避し、より効率的に圧縮できます。そのため、ドキュメントの共有やコードのウォークスルーなど、鮮明で読みやすい詳細が本当に重要となるユースケースでは、AV1 は最適な選択肢となります。

つまり、PSNR は、画面共有品質の微妙だが重要な側面を強調するのに役立ちます。動きを優先するか鮮明さを優先するかにかかわらず、さまざまな制約の下でコーデックがどのように動作するかを理解することで、ジョブに適したコーデックを選択できます。

QP とは何ですか? 圧縮と品質を理解する

画面共有の品質におけるもう 1 つの重要な要素は、量子化パラメータ( QP)と呼ばれるものです。圧縮中にどの程度の詳細が失われるかを制御するものが何なのか疑問に思ったことがあるなら、それがこれです。

簡単に言えば、 QP はエンコーダーにビデオをどの程度圧縮するかを指示します。

• QP が低いほど圧縮が少なくなり、画像の品質が向上します。
• QP が高いと圧縮率が高くなり、帯域幅を節約できますが、ビデオの見栄えが悪くなる可能性があります。

PSNR は、画質がどの程度維持されたかという結果を示しますが、 QP はエンコーダーが何を目指していたかを示します。そのため、私は両方を調べました。

この研究では、

• QP 値は標準の WebRTC メトリックから取得されました。
• PSNR は、各元のフレームを受信したバージョンと比較することによって事後に測定されました。

ここからが面白いところです。AV1は最高の PSNR スコアを持ち、つまり画像品質を最もよく維持していましたが、 QP 値も他のコーデックより最大 4 倍も高かったです。一見すると矛盾しているように思えます。

しかし、ここに落とし穴があります。各コーデックは QP を異なる方法で定義および処理するため、値を直接比較することはできません。あるコーデックの QP が 50 だからといって、別のコーデックの QP が 50 だからといって、必ずしも同じレベルの圧縮を意味するわけではありません。

それでも、QP の傾向は役に立つ情報を与えてくれます。すべてのコーデックで、帯域幅が増加すると QP が減少することがわかりました。これは理にかなっています。利用可能な帯域幅が増えると、コーデックは圧縮を減らして画像品質を向上させることができます。

したがって、QP 番号をコーデック間で並べて表示することはできませんが、利用可能なネットワークの状態に基づいて各コーデックが圧縮を動的に調整する方法は示されます。

結論: QP は品質スコアではなく設定です。ただし、帯域幅に応じて QP がどのように変化するかを追跡すると、エンコーダが舞台裏で何を実行しているかを把握するのに役立ちます。また、PSNR と組み合わせると、コーデックの動作をより完全に把握できます。

最終的な考察: WebRTC 画面共有にとってこれが何を意味するか

WebRTC が内部でどのように機能するかを詳しく調べてみると、1 つ明らかなことが分かります。それは、すべてのコーデックが同じように作成されているわけではなく、最適な選択は優先順位と環境によって決まるということです。

私の実験から得られた重要なポイントは次のとおりです。

AV1: 最高品質、最高コスト

AV1 は、動きの速いビデオを共有する場合でも、ゆっくりスクロールするテキストを共有する場合でも、一貫して最高の画質を提供しました。高度な圧縮と最適化により、非常に効率的ですが、それには代償が伴います。AV1 はCPU を大量に消費し、ハードウェアのサポートがまだ追いついていないため、低電力デバイスやモバイルデバイスにはまだ適していません。

H.264: 万能な万能選手

パフォーマンスと効率のバランスを求める場合、H.264 は依然として優れた選択肢です。H.264 は広くサポートされており、ほとんどのプラットフォームでハードウェア アクセラレーションが行われ、ほぼすべてのシナリオで優れたパフォーマンスを発揮します。特に、システム リソースやバッテリー寿命が懸念される場合に有効です。

コンテンツはあなたが思っている以上に重要です

共有するコンテンツの種類は、パフォーマンスに大きな影響を与えます。動きの激しいビデオは、ドキュメントやテキストなどの静的コンテンツよりも CPU と帯域幅に多くの負荷をかけます。コンテンツに適切なコーデックと適切な設定を選択すると、品質とリソース使用量に大きな違いが生じます。

CPU使用率は単なる脚注ではない

私が作成したカスタム Chrome プラグインのおかげで、画面共有中の CPU 使用率を正確に測定できました。結果では、各コーデックの要求度に大きな違いが見られました。これは、モバイル デバイスやエネルギーに敏感な環境では特に重要になります。

次は何か？この研究はどこへ向かうのか

この実験は、いくつかのエキサイティングな次のステップへの扉を開きました。今後の取り組みがさらに大きな影響を与える可能性があると思うのは次の点です。

モバイルデバイスでのテスト

これまでのところ、すべてのテストはデスクトップで行われていますが、画面共有は携帯電話やタブレットでも同様に（あるいはそれ以上に）一般的です。これらのコーデックがモバイルでどのように機能するかをテストすると、特に応答性と電力使用量の点で、より完全な画像が得られます。

エネルギー効率

電力について言えば、コーデックは CPU を消費するだけでなく、バッテリー寿命も消費します。今後の研究では、特にポータブル デバイスでの長時間の画面共有セッションの場合、どのコーデックが最もエネルギー効率が良いかを探る必要があります。

AIを活用したコーデックチューニング

WebRTC が現在のコンテンツとネットワーク速度に基づいてコーデック設定を自動的に調整できるとしたらどうでしょう。AIはそれを可能にし、品質とパフォーマンスの最適なバランスをリアルタイムで動的に見つけ出します。

まとめ

コーデックの選択は単なる技術的な決定ではありません。画面共有エクスペリエンスの品質、スムーズさ、リソースの使用に直接影響します。ビデオ会議ツールやコラボレーション プラットフォームを構築する場合でも、独自のワークフローを最適化する場合でも、さまざまな条件下でこれらのコーデックがどのように動作するかを理解することで、よりスマートで効果的な決定を下すことができます。

WebRTC が進化し続けるにつれて、それに関連するツールやテクニックも進化していきます。この詳細な説明が、舞台裏で何が起こっているのか、そして画面共有スタックを最大限に活用する方法を他の人に理解してもらうのに役立つことを願っています。

自分でデータを探索してみませんか?

結果をさらに詳しく調べたり、独自の分析を実行したりしたい場合は、この研究の完全なデータセットをここで公開しています。

Kaggleでデータセットをダウンロードする

フレーム レート、解像度、PSNR、QP、CPU 使用率などの生のメトリックが含まれており、すべてコーデック、コンテンツ タイプ、帯域幅の状態別に整理されています。独自の実験やベンチマークに自由に使用したり、さまざまなシナリオで WebRTC がどのように動作するかを調べたりできます。