ビデオ会議システム は複雑です。ビデオ会議システムはハードウェアやソフトウェアと共に数十年の間進歩を続け、接続性はかなり向上し手軽な価格となりました。それでもまだビデオ会議システムは複雑で、今後も複雑さはなくならないでしょう。その中でも大きな問題の 1 つである会議参加者数の拡張性という課題に取り組むための私たちのアプローチをここで紹介します。また、私たちのソリューションがユーザーにより良いエクスペリエンスを提供するのにどのように役に立つのかについても説明します。
私たちのことをご存じない方のため自己紹介をさせていただきます。私たちはアトラシアンの新メンバー、Jitsi チームです。リアルタイム通信が専門です。アトラシアンの一員となった今、マルチユーザービデオ会議システムに私たちの専門知識を投入し HipChatをこれまで以上にすばらしいものへと改良していきます。
ビデオ会議システム 入門
1 対 1 のビデオ電話はユビキタスです。すなわち、至るところに存在しています。IETF (インターネット技術タスクフォース) が適切な Nat トラバーサル (NAT 越え) を見い出した後、1 対 1 通話の設定は簡単になりました。携帯電話、タブレット、あらゆるノートパソコンで 1 対 1 通話を実行できます。しかし、その通話により多くの参加者を追加しようとすると難しくなります。
3 方向通話はまったくサーバーインフラがなくてもフルメッシュ型トポロジーを使う (すなわち、全員を全員に接続する) ことで達成できます。
3 人を超えると複雑になります。フルメッシュ型ネットワークは拡張できないと言って問題ないでしょう。
拡張範囲が 4 人を超える場合はサーバーコンポーネントが必要です。サーバーを中心にスター型トポロジーで参加者とサーバーを接続します。使用されるサーバーコンポーネントには主に 2 種類のグループがあります:
多地点制御装置 (MCU: Multipoint Control)
これはクライアントから送信されるマルチメディアを処理するサーバーコンポーネントです。通常、音声ミックス、コンポジット映像の作成、「ミックス」された単一ストリームの各クライアントへの送信を行います。 このメディア処理が原因で CPU の点ではこの装置は非常に高額となりますが、どちらかと言えばシンプルなクライアントソフトウェアを実現できます。
選択的転送装置 (SFU: Selective Forwarding Unit)
SFU はルーターのように動作し、メディア処理をすることなく単にパケットを転送します。これは CPU 効率が非常に高い導入を可能にしますが、一般的に必要とされるネットワーク リソースは大きくなります。
最も単純な事例では SFU は何も選択することなくすべてを転送します。したがって、転送されるストリーム数 (それに伴い必要となる帯域幅の量) が参加者数の 2 乗に従って増加します。例えば 3 人の参加者の場合のストリーム数は 3×2=6、10 人の場合のストリーム数は 10×9=90 となります。最大 10～15 人程度の参加者数まで拡張可能ですがそれ以上になると途切れ途切れになります。何も選択しない場合は SFU は単なる FU (転送装置) です。
Last-n
私たちのサーバーコンポーネントは Jitsi Videobridge と呼ばれるものです。CPU 効率がかなり良い SFU です。CPU サイクルのほとんどは RTP (メディア) パケットの暗号化 / 復号に使用されていますので CPU 使用率はビットレートに比例します (詳細については「Jitsi Videobridge Performance Evaluation」参照)。大規模会議の帯域幅問題を解決すれば深刻な CPU 問題も解決します。
拡張問題を解決するため私たちが選択的に使用する方法の 1 つは、私たちが last-n と呼んでいるものです。参加者数 n のサブセットを選択するという考え方です。n 人の参加者のビデオを表示して他者からのビデオを停止します。発言者に応じて表示する参加者のサブセットを動的に自動調整します。効率良く直近で発言した n 人のビデオだけを表示します。
拡張問題の解決にどのように役立つのか? 転送するストリーム数 (それによって発生する通信量) は 直線的に増加します:
それはどういう意味か? 同じサーバーリソースを使うことで以下のどちらかを実現できるということです:
- 会議参加者数の増加
- 会議数の増加
クライアント、UI、UX への影響は?
- ネットワークリソースの低下 – 受信ストリーム数の低下
- CPU リソースの低下 – デコードされるストリーム数の低下
- 不要物の低減 – UI のビデオエレメント数の低下
- インタラクションの必要なし – 発言者があれば発言者のビデオを自動的に表示
ほとんどの会議では積極的に発言をするのは数名に過ぎません。この特徴を利用して last-n を採用しつつ全員の参加を可能にします。
last-n の難点の 1 つは表示する参加者を見極めることです。これは「Dominant Speaker Identification」(主要な発言者の特定) と呼ばれる難解な問題です。私たちは音声ストリームをデコードせずに SFU 上でその発言者を特定する必要があるのでこの問題はさらに複雑となります。
last-n については私たちが最近発表した論文に詳細が記されています: Last N: マルチメディア会議におけるビデオ転送の関連性選択 (原題: Last N: Relevance-Based Selectivity for Forwarding Video in Multimedia Conferences)
実際の last-n の動作を確認したい方は、実験評価用インストレーションをご覧ください:
実験評価用インストレーションでは set n=5 を使っていますので last-n の効果を確認するには最低 7 人が必要となることにご注意ください。また、これは単なる試験環境であり安定性にかけるかもしれない点にご注意ください。
以上が Jitsi チームが取り組んでいる内容の基本的な概要です。私たちはアトラシアンの一員となり胸が高鳴っています。両チームが協力することでこれから可能となる発展をとても楽しみにしています。
*本ブログは Atlassian Developers の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2015 年 7 月 15 日投稿 "Video conferencing with last-n"