WebRTC 会議における仮想メディア ストリームは、Selective Forwarding Unit（SFU）によって生成されるメディア ストリームで、複数の参加者からのメディアを集約して配信します。大規模な会議で複雑な接続のメッシュを作成する直接のピアツーピア メディア ストリームとは異なり、仮想メディア ストリームはトポロジを簡素化します。SFU は、各参加者から個々のメディア ストリームを受信し、アクティブなストリームまたは関連するストリームを選択的に他の参加者に転送し、それらをより小さな固定の送信仮想メディア ストリームに多重化します。
このアプローチにより、各参加者が処理する必要がある同時受信ストリームの数が減り、処理と帯域幅の要件が軽減されます。各仮想ストリームには、スピーカーのアクティビティや動画の割り当てなどの要因に基づいて SFU によって動的に調整される、1 人の参加者からのメディアを一度に含めることができます。参加者はこれらの仮想ストリームを受信し、他のすべての参加者からの個々のストリームを管理する必要なく、会議の合成ビューを効果的に確認できます。仮想メディア ストリームによって提供されるこの抽象化は、WebRTC 会議を多数の参加者にスケーリングするために不可欠です。
音声を受信するには、クライアントは3 つの音声メディア記述を 正確に提供して、3 つのローカル音声 トランシーバーを作成する必要があります。動画を受信するには、クライアントは 1 ～ 3 個の動画メディア記述を提供して、その数の動画トランシーバーを確立する必要があります。
レシーバー
クライアント所有の各トランシーバーには、専用の
RtpReceiverと、Meet
サーバーから音声 RTP ストリームを受信する専用の"media track"があります。
各トラックには一意の ID があり、特定のメディアソースから独自の RTP パケット ストリームを受信します。たとえば、 トラック A は production-1 から音声を受信し、 トラック B は production-2 から音声を受信します。
SSRC
各 RTP パケットには、同期ソース (SSRC) ヘッダー値があり、 特定のトラックに関連付けられます。
Meet Media API を介した音声セッションでは、3 つの異なるメディア ストリームを使用します。各ストリームには独自の静的 SSRC があります。確立されると、これらの SSRC 値はセッションの有効期間中変更されません。
仮想ストリーム
Meet Media API は 仮想メディア ストリームを使用します。これらは セッション全体で静的ですが、最も関連性の高いフィードを 反映するようにパケットのソースが 変更されることがあります 。仮想メディア ストリームは、音声と動画で同じように動作します。
RTP パケット ヘッダーの Contributing Source (CSRC) は、RTP パケットの真のソースを識別します。Meet は、 会議に参加したときに、会議の各参加者に固有の CSRC を割り当てます。この値は、参加者が退出するまで一定です。
SSRC の数は Meet Media API セッション全体で一定であるため、次の 3 つのシナリオが考えられます。
利用可能な SSRC より参加者が多い:
Meet は、3 つの SSRC で最も大きな 3 人の音声を送信します。各 RTP ストリームは専用の SSRC 上にあるため、ストリーム間の混在はありません。
図 1.Meet は、3 つの SSRC で最も大きな 3 人の音声を送信します。 会議の元のストリームが最も大きなストリームのいずれかでなくなった場合、Meet は SSRC を構成する RTP パケットを最も大きなストリームに切り替えます。
図 2.Meet は RTP パケットを新しい最も大きな音声の参加者に切り替えます。 アクティブな参加者の数が 3 つの音声 SSRC より少ない:
会議のストリームよりも多くの SSRC が利用可能なシナリオでは、Meet は利用可能な音声パケットを独自の固有の SSRC にマッピングします。未使用の SSRC は引き続き使用できますが、RTP パケットは送信されません。
図 3.Meet は利用可能な音声パケットを独自の固有の SSRC にマッピングします。 アクティブな参加者の数が 3 つの音声 SSRC と等しい:
参加者と利用可能な SSRC が等しいシナリオでは、各参加者のメディアが専用の SSRC にマッピングされます。これらのマッピングは、この特定のシナリオが続く限り保持されます。
図 4.Meet は各参加者のメディアを専用の SSRC にマッピングします。