Meet Media API の概要

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

ユースケース

Google Cloud コンソールに登録されたアプリは、Meet Media API を使用して Meet 会議に接続し、次の操作を行うことができます。

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

Meet Media API のライフサイクル

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

  • Meet Media API ボットがサードパーティのウェブサイトに参加しようとします。
    図 1. Meet Media API ボットがサードパーティのウェブサイトに参加しようとします。未成年者のアカウントが存在する場合、接続は拒否されます。
  • 暗号化された会議と透かし入りの会議。
    図 2. 会議を暗号化済みとしてマークし、透かしを入れることができます。会議に暗号化または透かしが含まれている場合、Meet Media API に接続できません。
  • 管理者設定が正しいことを確認します。
    図 3. 管理者設定が正しいことを確認します。
  • カレンダーで会議を設定します。
    図 4. カレンダーで会議を設定します。ホストは、カレンダーの設定でサードパーティ製アプリに権限を付与する必要があります。権限が付与されていない場合、接続は拒否されます。
  • 通話中の設定変更。
    図 5. 通話中の設定変更。通話中に主催者が Meet Media API の設定をオフにすると、接続が停止します。
  • コンシューマーとの会議には、イニシエーターが参加する必要があります。
    図 6. 会議の所有者が一般ユーザー向けアカウント（末尾が @gmail.com のアカウント）を持っている場合、会議の開始者が会議に参加して同意しないと、接続は拒否されます。
  • 接続が確立されました。
    図 7. 接続が確立されると、主催者、共同主催者、または主催者と同じ組織に所属する参加者に開始ダイアログが表示されます。
  • 通話中に Meet Media API を停止できるのは、通話の参加者全員です。
    図 8. 通話中に Meet Media API を停止できます。

よく使用する用語

Cloud プロジェクト番号
Google Cloud プロジェクトの不変の生成済み int64 識別子。これらの値は、登録されたアプリごとに Google Cloud コンソールによって生成されます。
会議
ミーティング スペース内の通話のサーバー生成インスタンス。ユーザーは通常、このシナリオを 1 つの会議と見なします。
会議リソース データチャンネル

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

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

貢献元（CSRC）

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

Meet では、会議に参加した各参加者に一意の CSRC 値が割り当てられます。この値は、ユーザーが退出するまで一定です。

データ チャネル

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

Interactive Connectivity Establishment（ICE）

接続を確立し、2 台のコンピュータがピアツーピア（P2P）ネットワークを介して相互に通信するための可能なルートをすべて見つけ、接続を維持するためのプロトコル。

メディア ストリーム

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

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

RTP パケットの単一の単方向フローで構成されます。メディア ストリーム トラックは音声または動画のいずれかですが、両方ではありません。双方向の Secure Real-time Transport Protocol（SRTP）接続は通常、ローカルからリモート ピアへの下り（外向き）とリモート ピアからローカル ピアへの上り（内向き）の 2 つのメディア ストリーム トラックで構成されます。

会議スペース

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

参加者

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

関連するストリーム

クライアントが開くことができる仮想オーディオ ストリームと仮想ビデオ ストリームの数には上限があります。

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

Selective Forwarding Unit（SFU）

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

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

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

SDP 応答

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

SDP オファー

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

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

同期ソース（SSRC）

SSRC は、RTP（リアルタイム転送プロトコル）セッション内のメディア ストリームの単一ソースを一意に識別する 32 ビットの識別子です。WebRTC では、SSRC は、異なる参加者から発信された異なるメディア ストリーム、または同じ参加者の異なるトラック（異なるカメラなど）を区別するために使用されます。

RtpTransceiver

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

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

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

各メディアの説明には、専用のトランシーバがあります。したがって、複数の RTP ストリームを含むピアツーピア セッションには、ピアごとに複数の RtpSenders と RtpReceiver を含む複数のトランシーバがあります。

仮想メディア ストリーム

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