Meet Media API の概要

Google Meet Media API を使用すると、Google Meet 会議のリアルタイム メディアにアクセスできます。これにより、アクション アイテムを記録するアプリ、現在の会議に関するリアルタイムの分析情報を提供するアプリ、音声と動画を新しいサーフェスにストリーミングするアプリなど、さまざまなユースケースが可能になります。

ユースケース

Google Cloud コンソールに登録されているアプリは、Meet Media API を使用して Meet 会議に接続し、次のことを行えます。

• 動画ストリームを使用する 。例:
  • Meet 会議で生成された動画ストリームを独自の AI モデルにフィードする。
  • カスタム録画用にストリームをフィルタする。
• 音声ストリームを使用する 。例:
  • 音声を Gemini に直接フィードし、独自の会議 AI チャットボットを作成する。
  • Meet 会議で生成された音声ストリームを独自の音声文字変換サービスにフィードする
  • さまざまな言語で字幕を生成する。
  • キャプチャした音声から、モデル生成の手話フィードを作成する。
  • 独自のノイズ除去モデルを作成して、会議から背景やノイズのアーティファクトを除去する。
• 参加者のメタデータを使用する 。例:
  • 会議に参加している参加者を検出し、インテリジェンスと分析を改善する。

Meet Media API のライフサイクル

次の図は、Meet Media API のライフサイクルを示しています。

同意者の要件

Meet Media API アプリは、会議の代理として同意を提供できる参加者が 通話に参加している場合にのみ、会議に参加できます。

Google Workspace 会議の場合

Google Workspace 会議で同意を提供するには、 会議を所有する組織に所属している必要があります。ほとんどの場合、会議のオーナーは 主催者と同じです。主催者または開始者が会議に参加していて、会議を所有する組織に所属している場合、開始ダイアログが優先的に表示されます。

一般ユーザー向け会議の場合

Gmail アカウントで主催される会議の場合、同意を提供するには、開始者が会議に参加している必要があります。

よく使用する用語

Cloud プロジェクト番号

Google Cloud プロジェクトの不変の生成済み int64 ID。これらの値は、登録済みアプリごとに Google Cloud コンソールによって生成されます。

会議

会議スペース 内の通話のサーバー生成インスタンス。通常、ユーザーはこのシナリオを 1 つの会議と見なします。

会議リソース データチャネル

Meet Media API クライアントは、 Google Meet REST API のように HTTP 経由でリソースをリクエストするのではなく、データチャネル経由でサーバーからリソースをリクエストします。

リソース タイプごとに専用のデータチャネルを開くことができます。開くと、クライアントはチャネル経由でリクエストを送信できます。リソースの更新は同じチャネル経由で送信されます。

提供元（CSRC）

仮想メディア ストリームでは、メディア ストリームが常に同じ参加者を指しているとは限りません。各 RTP パケットのヘッダーの CSRC 値は、パケットの実際の送信元を示します。

Meet は、会議 に参加した参加者ごとに一意の CSRC 値を割り当てます。この値は、参加者が退出するまで変わりません。

データチャネル

WebRTC データチャネル を使用すると、 音声ストリームや動画ストリームとは独立して任意のデータ（テキスト、ファイルなど）を交換できます。データチャネルはメディア ストリームと同じ接続を使用するため、WebRTC アプリケーションにデータ交換を効率的に追加できます。

Interactive Connectivity Establishment（ICE）

接続性を確立し、2 台のコンピュータがピアツーピア（P2P）ネットワーキング経由で相互に通信できるすべてのルートを見つけて、接続を維持するためのプロトコル。

メディア ストリーム

WebRTC メディア ストリーム は、カメラやマイクなどの デバイスからキャプチャされたメディアデータ（通常は音声または動画）のフローを表します。1 つ以上の メディア ストリーム トラックで構成され、それぞれが単一のメディアソース（ 動画トラックや音声トラックなど）を表します。

メディア ストリーム トラック

RTP パケットの単一の単方向フローで構成されます。メディア ストリーム トラックは音声または動画にできますが、両方にすることはできません。双方向の Secure Real-time Transport Protocol 接続は通常、ローカルからリモートピアへの出力とリモートピアからローカルピアへの入力の 2 つのメディア ストリーム トラックで構成されます。

会議スペース

会議が開催される仮想の場所または永続オブジェクト（会議室など）。1 つのスペースでアクティブな会議を 1 つだけ開催できます。会議スペースは、ユーザーが会議に参加して共有リソースを見つけるのにも役立ちます。

参加者

会議に参加しているユーザー、 コンパニオン モードを使用しているユーザー、 閲覧者として視聴しているユーザー、通話に接続されている会議室デバイス。参加者が会議に参加すると、一意の ID が割り当てられます。

関連ストリーム

クライアントが開くことができる仮想音声ストリームと仮想動画 ストリームの数には上限があります。

会議の参加者数がこの数を超える可能性は十分にあります。このような場合、Meet サーバーは「最も関連性の高い」と判断された参加者の音声ストリームと動画ストリームを送信します。 関連性は、画面共有や参加者が発言した頻度など、さまざまな特性から判断されます。

Selective Forwarding Unit（SFU）

Selective Forwarding Unit（SFU）は、WebRTC 会議のサーバーサイド コンポーネントで、メディア ストリームの配信を管理します。参加者は SFU にのみ接続し、SFU は関連するストリームを選択的に他の参加者に転送します。これにより、クライアントの処理と帯域幅のニーズが軽減され、スケーラブルな会議が可能になります。

セッション記述プロトコル（SDP）

WebRTC が P2P 接続をネゴシエートするために使用するシグナリング メカニズム。RFC 8866 で規定されています。

SDP アンサー

SDP オファーへのレスポンス。アンサーは、リモートピアから受信したストリームを拒否または受け入れます。また、オファーピアに送信するストリームをネゴシエートします。SDP アンサーでは、最初のオファーからシグナリングされたストリームを追加できないことに注意してください。たとえば、オファーピアがリモートピアから最大 3 つの音声ストリームを受け入れることをシグナリングした場合、このリモートピアは送信用に 4 つの音声ストリームをシグナリングできません。

SDP オファー

オファーとアンサーのピアツーピア ネゴシエーション フローの最初の SDP。オファーは開始ピアによって作成され、ピアツーピア セッションの条件を決定します。オファーは常に Meet Media API クライアントによって作成され、Meet サーバーに送信されます。

たとえば、オファーは、オファー元が送信する（または受信できる）音声ストリームまたは動画ストリームの数と、データチャネルを開くかどうかを示す場合があります。

同期ソース（SSRC）

SSRC は、RTP（Real-time Transport Protocol）セッション内のメディア ストリームの単一ソースを一意に識別する 32 ビットの ID です。WebRTC では、SSRC は、異なる参加者からの異なるメディア ストリーム、または同じ参加者の異なるトラック（異なるカメラなど）を区別するために使用されます。

RtpTransceiver

RFC 8829 で詳しく説明されているように、 トランシーバーはピアツーピア セッションの RTP ストリームの抽象化です。

1 つのトランシーバーは、SDP の 1 つのメディア記述にマッピングされ、記述されます。トランシーバーは RtpSender と RtpReceiver で構成されます。

RTP は双方向であるため、各ピアには同じ RTP 接続に対して独自のトランシーバー インスタンスがあります。ローカルピアの特定のトランシーバーの RtpSender は、リモートピアの特定のトランシーバーの RtpReceiver にマッピングされます。その逆も当てはまります。リモートピアの同じトランシーバーの RtpSender は、ローカルピアの RtpReceiver にマッピングされます。

すべてのメディア記述には、専用のトランシーバーがあります。したがって、複数の RTP ストリームを使用するピアツーピア セッションには、ピアごとに複数の RtpSenders と RtpReceivers を持つ複数のトランシーバーがあります。

仮想メディア ストリーム

仮想メディア ストリームは、WebRTC 会議の Selective Forwarding Unit (SFU) によって生成される集約されたメディア ストリームです。各参加者が個々のストリームを他のすべての参加者に送信するのではなく、SFU は選択した参加者のストリームをより少ない送信仮想ストリームに多重化します。これにより、接続トポロジが簡素化され、参加者の負荷が軽減され、スケーラブルな会議が可能になります。各仮想ストリームには、SFU によって動的に管理される複数の参加者のメディアを含めることができます。

関連トピック

• Meet Media API クライアントの開発を開始する方法については、 スタートガイドの手順に沿って操作してください。

• Meet Media API リファレンス クライアントのサンプルを設定して実行する方法については、C++ リファレンス クライアント クイックスタートをご覧ください。

• コンセプトの概要については、Meet Media API コンセプトをご覧ください。

• WebRTC の詳細については、WebRTC For The Curious をご覧ください。

• 認証と認可の処理など、Google Workspace API を使用した開発の詳細については、Google Workspace での開発をご覧ください。