Meet Media API 總覽

Google Meet Media API 可讓您存取 Google Meet 會議的即時媒體。這項功能可支援各種用途，例如記錄行動項目的應用程式、提供目前會議的即時洞察資訊，或是將音訊和視訊串流至新途徑。

用途

在 Google Cloud 控制台中註冊的應用程式可以使用 Meet Media API 連線至 Meet 會議，並執行下列操作：

  • 觀看影片串流。例如：
    • 將 Meet 會議中產生的動態饋給視訊串流匯入您自己的 AI 模型。
    • 篩選自訂錄製內容的串流。
  • 收聽音訊串流。例如：
    • 直接將音訊輸入 Gemini，建立專屬的會議 AI 聊天機器人。
    • 將 Meet 會議產生的音訊串流饋送至您自己的轉錄服務
    • 生成各種語言的字幕。
    • 從擷取的音訊建立模型生成的手語動態消息。
    • 建立自己的降噪模型，移除會議中的背景和雜訊。
  • 使用參與者中繼資料。例如：
    • 偵測會議參與者，提供更優質的智慧功能和分析資料。

瞭解 Meet 媒體 API 生命週期

下圖顯示 Meet Media API 的生命週期：

  • Meet Media API 機器人嘗試加入第三方網站。
    圖 1. Meet Media API 機器人會嘗試加入第三方網站。如果帳戶含有未成年人，系統會拒絕連結。
  • 加密會議和加上浮水印的會議。
    圖 2. 會議可以標示為加密，並加上浮水印。如果會議已啟用加密或浮水印，就無法連線至 Meet Media API。
  • 確認管理員設定正確無誤。
    圖 3. 確認管理員設定正確無誤。
  • 在 Google 日曆中設定會議。
    圖 4. 在 Google 日曆中設定會議。主辦人必須在 Google 日曆設定中授予第三方應用程式權限，否則連線會遭到拒絕。
  • 通話期間變更設定。
    圖 5. 通話期間變更設定。如果主辦人在通話期間決定關閉 Meet Media API 設定，連線就會停止。
  • 發起人必須在消費者會議中。
    圖 6. 如果會議擁有者使用個人帳戶 (結尾為 @gmail.com 的帳戶)，發起人必須在會議中提供同意聲明，否則系統會拒絕連線。
  • 連線已建立。
    圖 7. 連線建立後，主辦人、共同主辦人或與主辦人同屬一個機構的任何參與者，都會看到啟動對話方塊。
  • 通話期間，任何人都可以停止使用 Meet Media API。
    圖 8. 通話期間，任何人都可以停止使用 Meet Media API。

常見詞彙

Cloud 專案編號
Google Cloud 專案的固定產生int64 ID。這些值是由 Google Cloud 控制台為每個已註冊的應用程式產生。
會議
伺服器在會議空間中產生的通話例項。使用者通常會將這個情境視為單一會議。
會議資源資料管道

與 Google Meet REST API 不同，Meet Media API 用戶端不會透過 HTTP 要求資源，而是透過資料管道向伺服器要求資源。

系統可能會為每種資源類型開啟專屬的資料管道。開啟後，用戶端就能透過管道傳送要求。資源更新會透過相同管道傳輸。

貢獻來源 (CSRC)

使用虛擬媒體串流時，您無法假設媒體串流一律指向同一位參與者。每個 RTP 封包標頭中的 CSRC 值，都會指明封包的實際來源。

當參與者加入會議時，Meet 會為每位參與者指派專屬的 CSRC 值。這個值會保持不變，直到使用者離開為止。

資料管道

WebRTC 資料通道可獨立於音訊和視訊串流，交換任意資料 (文字、檔案等)。資料通道與媒體串流使用相同的連線，可有效率地將資料交換功能新增至 WebRTC 應用程式。

互動式連線建立 (ICE)

這項通訊協定可建立連線，找出兩部電腦透過點對點 (P2P) 網路通訊的所有可能路徑，並確保連線保持暢通。

媒體串流

WebRTC 媒體串流代表媒體資料流，通常是從攝影機或麥克風等裝置擷取的音訊或視訊。其中包含一或多個媒體串流軌，每個軌代表單一媒體來源，例如視訊軌或音訊軌。

媒體串流軌

由單向 RTP 封包流組成。媒體串流軌可以是音訊或影片，但不能同時是兩者。雙向安全即時傳輸通訊協定 (SRTP) 連線通常包含兩個媒體串流軌，分別是從本機到遠端對等互連的傳出，以及從遠端對等互連到本機對等互連的傳入。

會議空間

虛擬空間或持續存在的物件 (例如會議室)，用來舉辦會議。一個空間一次只能有一場進行中的會議。會議空間也能協助使用者開會及尋找共用資源。

參與者

加入會議或使用夥伴模式的使用者、以觀眾身分觀看會議的使用者，或是連線至通話的會議室裝置。參與者加入會議時，系統會指派專屬 ID。

相關訊息串

用戶端可開啟的虛擬音訊串流和虛擬影片串流數量設有上限。

會議的參與者人數很可能超過這個數字。在這些情況下，Meet 伺服器會傳輸系統判定為「最相關」參與者的音訊和視訊串流。系統會根據各種特徵判斷相關性，例如螢幕分享和參與者最近的發言時間。

選擇性轉送單元 (SFU)

選擇性轉送單元 (SFU) 是 WebRTC 會議中的伺服器端元件，負責管理媒體串流分配作業。參與者只會連線至 SFU，SFU 會選擇性地將相關串流轉送給其他參與者。這項技術可減少用戶端處理作業和頻寬需求，進而支援可擴充的會議。

Session Description Protocol (SDP)

WebRTC 用於協商 P2P 連線的信號傳遞機制。RFC 8866。

SDP 答案

對 SDP 提案的回覆。答案會拒絕或接受遠端對等互連裝置收到的任何串流。此外，它也會協商要傳輸回提供對等互連的串流。請注意，SDP 答案無法從初始提案新增已發出信號的串流。舉例來說，如果提供者同層級信號表示最多可接受來自遠端同層級的三個音訊串流，則遠端同層級無法信號傳輸四個音訊串流。

SDP 優惠

提議-應答對等互連協商流程中的初始 SDP。發起端會建立提案，並決定對等互連工作階段的條款。優惠一律由 Meet Media API 用戶端建立，並提交至 Meet 伺服器。

舉例來說，提議可能指出提議者傳送 (或能夠接收) 的音訊或視訊串流數量，以及是否要開啟資料通道。

同步來源 (SSRC)

SSRC 是 32 位元的 ID，可唯一識別 RTP (即時傳輸通訊協定) 工作階段中的單一媒體串流來源。在 WebRTC 中，SSRC 用於區分來自不同參與者的不同媒體串流，甚至是來自同一參與者的不同軌道 (例如不同攝影機)。

RtpTransceiver

如 RFC 8829 一文所述，收發器是點對點工作階段中 RTP 串流的抽象概念。

單一收發器會對應至 SDP 中的單一媒體說明，並由該說明進行描述。收發器由 RtpSender 和 RtpReceiver 組成。

由於 RTP 是雙向的，因此每個對等互連都有自己的收發器執行個體，用於相同的 RTP 連線。特定收發器的 RtpSender 會對應至遠端對等互連中的特定收發器 RtpReceiver。反之亦然。遠端對等互連的相同收發器 RtpSender 會對應至本機對等互連的 RtpReceiver。

每個媒體說明都有專屬的收發器。因此，具有多個 RTP 串流的對等互連工作階段，會為每個對等互連裝置提供多個收發器，以及多個 RtpSenders 和 RtpReceiver。

虛擬媒體串流

虛擬媒體串流是由 WebRTC 會議中的選擇性轉送單元 (SFU) 產生的匯總媒體串流。SFU 會將選定的參與者串流多工處理成較少的傳出虛擬串流，而不是讓每位參與者將個別串流傳送給其他人。這項功能可簡化連線拓撲，並減少參與者的負擔，進而實現可擴充的會議。每個虛擬串流可包含多位參與者的媒體，並由 SFU 動態管理。