Meet Media API の概要

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

ユースケース

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

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

よく使用する用語

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

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

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

Contributing Source（CSRC）

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

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

データ チャネル

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

Interactive Connectivity Establishment（ICE）

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

メディア ストリーム

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

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

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

会議スペース

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

参加者

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

関連するストリーム

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

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

選択的転送ユニット（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 ストリームを抽象化したものです。

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

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

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

仮想メディア ストリーム

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