リアルタイムメディア | ビデオ会議の課題とは

ブログシリーズ「リアルタイムメディア」にようこそ。このシリーズでは、リアルタイムメディア、中でも Webex などのコラボレーションツールに関連するさまざまな技術的テーマについて、専門でない方々に参考にしていただける包括的でインサイトに満ちた記事をお届けしていきます。最初の 3 本のブログでは、リアルタイムのコラボレーションに関係するメディアの基本原則の概要を、包括的にわかりやすくご説明します。これらの基礎的なインサイトは、本シリーズの今後のブログで詳細な考察をご覧いただく際の下地となるはずです。

圧縮

オーディオストリームとビデオストリームは、どちらも圧縮形式でネットワークに送信されます。キャプチャしたりレンダリングしたりした生の形式で送信されるわけではありません。これが基本要件となるのは、帯域幅の制約があるからです。解像度が 1080p でフレームレートが 30fps の圧縮されていないビデオストリームには 1 秒あたり 1,500 メガビットが必要となりますが、1 回のビデオ通話のトラフィック量としては非現実的です。オーディオの帯域幅は、圧縮しなくてもビデオに比べればずいぶん小さいのですが、圧縮することでさらに帯域幅を抑えることができます。

ビデオの非可逆圧縮と遅延の極端な例を、元のビデオと比較

リアルタイムのオーディオやビデオの圧縮には、非可逆圧縮方式が使用されます。この圧縮方式でメディアのデータをエンコード（符号化）したうえでデコード（復号化）すると、エンコードした元データと近似したデータにはなるものの、完全に同じデータにはなりません。つまり、この圧縮プロセスを経ると、忠実度がある程度は損なわれるということです。そんな非可逆圧縮方式がリアルタイムメディアで使われるのは、可逆圧縮方式に比べ、はるかに高い圧縮レベルを実現できるからです。

コーデック

オーディオとビデオのエンコード形式とデコード形式はさまざまです。これを総称してコーデックといいます。さまざまなビットレートや品質に対応できるコーデックもありますが、固定されている（特にオーディオで使用される）コーデックもあります。品質とビットレートの間には相関関係があり、ビットレートを低く抑えれば、その分大幅に品質が低下するのは避けられません。一方、品質と計算コストの間にも相関関係があります。一般的には、新しいコーデックであればあるほど、一定の品質条件における圧縮レベルは上がり、帯域幅も小さくてすみます。言い換えると、それに対応して一定の帯域幅での品質が向上しますが、古いコーデックよりも計算コストが高くなります。

こうしたコーデック実装の特殊な性質から明らかなように、競争力に優れた最適化バージョンのオーディオおよびビデオコーデックを開発するには、エンジニアリングに相当の投資が必要となります。ビデオコーデックの場合、特にその傾向が強いでしょう。人気のあるビデオコーデックでは、最適化のためにハードウェアを活用している例が少なくありません。チップセットのシリコンの一部をビデオコーデックのエンコード/デコード専用に割り当てることで、CPU とエネルギー使用率の効率アップを実現しているのです。ソフトウェアで処理する場合でも、一般的なコーデックはほぼすべて、利用にはライセンスが必要となる独自実装です。特に人気の高いコーデックの多くには、代用できるオープンソースのソフトウェアが存在します。ただし、オープンソースを利用するにあたっては、適切なサポートを得て確実に最適化を施すことが不可欠です。また、特許ライセンス問題への懸念に対処する必要もあります。基本的なオーディオコーデック以上の機能を持つものを実装する場合は特にそうですが、独自の実装環境を構築する前に、こうした課題について入念に検討しなければなりません。

リアルタイムメディアの概念 | 遅延

リアルタイム会議におけるもう 1 つの主な懸念は遅延つまり、元のソースからキャプチャされたオーディオ/ビデオと相手先でレンダリングされたオーディオ/ビデオ間の遅延時間です。遅延が生じる原因はさまざまです。具体的には、キャプチャデバイス自体（マイク/カメラ）、Bluetooth などの内部リンク、メディアのエンコード、パケットとして送信するためのメディアのシリアル化、送信元と送信先の間のインターネット通過、デジッタリング/同期などのバッファリング遅延（Real-time Transport Protocol（RTP）については後日掲載のブログ記事を参照）、デコード、再生などが挙げられます。マルチポイントコントロールユニット（MCU）などの中間デバイスが遅延を生じさせている場合もあります。

遅延がひどいとシステムの反応の鈍さが気になってしまうので、受信側は非常に不便に感じます。オーディオの遅延は、ビデオの遅延以上に支障をきたします。ビデオが極度に遅延しても、ビデオの見え方に影響する（映像が追い付かず同期されない状態になる）だけですが、オーディオが極度に遅延すると、会話が困難になるか、場合によっては不可能になります。オーディオとビデオのどちらかを取らざるを得ないなら、一部の極めて特殊なユースケースを除き、ビデオよりオーディオの遅延の解消を優先して実装すべきです。

Ragnhild Eg 氏らの研究では、エンドツーエンドのオーディオの遅延が約 200ms を超えたところでユーザーへの影響が出始めることが示されています。遅延が 350 ～ 400ms を超えると、大半のユーザーが問題に気づきます。遅延が 250ms ～ 350ms の間の場合、ほとんどのユーザーは意識のうえでは遅延に気づきませんが、会話のなめらかさに影響が出始めます。人は、会話が途切れたら自分が話すタイミングだと判断するからです。遅延が 275ms を超えたあたりで、話の切れ間を正しく判断するのが難しくなります。そうなると、話すタイミングが相手と被ってしまうため、会話がぎこちなくなるのです。

E-model による絶対遅延の影響測定、ITU-T G.114

ビデオ会議に関するリアルタイムメディア

この種の遅延が懸念事項となるのは、一般的には、双方向メディアが存在するユースケースの場合に限られます。 1 人または複数の参加者が他の参加者にデータを送るだけで、受信側がフィードバックする手段がないかテキストチャットのような間接的な方法でしか反応を返せないユースケースでは、さらに大幅に遅延しても問題にならない場合もあります。Twitch などのライブストリーミングサービスでは、オーディオ/ビデオに数秒、場合によっては数十秒の遅延が生じるのが普通です。それだけ遅延が許容されるのであれば、TCP、HLS、バッファリングなど、ネットワーク障害からの回復の問題をずっとシンプルに解決できる他のテクノロジーを利用できます。今回のブログやこのシリーズ全体で重点的に取り上げるのはビデオ会議で使われる双方向メディアであり、遅延は大きな懸念になります。

さらに対照的な例としては、ユーザーがリモートで一緒に歌ったり音楽を演奏したりするような特殊な双方向のユースケースも存在します。オーディオの遅延を極めて低く抑える必要があるため、こうしたユースケースに最適化した専用ソフトウェアを使うのが一般的です。

進化を続けるリアルタイムコラボレーション環境を乗り切るには、こうした技術の複雑な事情を理解する必要があることがおわかりいただけると思います。次回のブログでは、ビデオ会議における双方向コミュニケーションに直接影響するトピックを取り上げながら、リアルタイムメディアのダイナミクスについて詳しく掘り下げます。どうぞご期待ください。

Webex に関するその他の記事：