Meet Media API 總覽

Google Meet Media API 可讓您存取 Google Meet 會議的即時媒體內容。這可支援各種用途，例如記錄待辦事項、提供目前會議的即時洞察資料，或將音訊和視訊串流至新途徑。

用途

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

  • 使用影片串流。例如：
    • 將 Meet 會議產生的影片串流饋送至您自己的 AI 模型。
    • 篩選自訂錄影的串流。
  • 使用音訊串流。例如：
    • 直接將音訊輸入 Gemini，打造專屬的會議 AI 聊天機器人。
    • 將 Meet 會議產生的音訊串流饋送至您自己的轉錄服務
    • 產生多種語言的字幕。
    • 根據擷取的音訊內容，建立模型產生的手語動態饋給。
    • 建立自己的降噪模型，移除會議中的背景和雜訊。
  • 使用參與者中繼資料。例如：
    • 偵測會議中的參與者，以便提供更精確的智慧和分析資訊。

常見詞彙

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

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

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

貢獻來源 (CSRC)

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

當參與者加入會議時，Meet 會為他們指派一個不重複的 CSRC 值。這個值會保持不變，直到使用者離開為止。

資料管道

WebRTC 資料管道可讓使用者獨立於音訊和視訊串流之外，交換任意資料 (文字、檔案等)。資料管道會使用與媒體串流相同的連線，提供一種有效的方式，可將資料交換功能新增至 WebRTC 應用程式。

Interactive Connectivity Establishment (ICE)

用於建立連線的通訊協定，可找出兩部電腦透過點對點 (P2P) 網路互相通訊的所有可能路徑，然後確保連線維持暢通。

媒體串流

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

媒體串流音軌

包含單一單向 RTP 封包流。媒體串流曲目可以是音訊或影片，但不能同時是兩者。雙向 安全即時傳輸通訊協定 (SRTP) 連線通常包含兩個媒體串流音軌，分別是從本機傳出至遠端同端節點，以及從遠端同端節點傳入本機同端節點。

會議空間

舉辦會議的虛擬地點或持續性物件 (例如會議室)。一個空間一次只能進行一場會議。會議空間還可協助使用者進行會議及尋找共用資源。

參與者

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

相關串流

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

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

選取轉送單元 (SFU)

選擇性轉送單元 (SFU) 是 WebRTC 會議中的伺服器端元件，可管理媒體串流分配作業。參與者只會連線至 SFU，後者會選擇性地將相關串流轉送給其他參與者。這麼做可減少用戶端的處理和頻寬需求，讓會議可隨時調整規模。

會話描述通訊協定 (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 動態管理。