Meet Media API 總覽

Google Meet Media API 可讓您存取 Google Meet 會議的即時媒體。這項功能支援多種用途，例如記錄行動事項、提供當下會議的即時洞察資料，或是將音訊和視訊串流至新介面。

用途

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

  • 觀看影片串流。
  • 取用音訊串流。
  • 使用參與者中繼資料。

瞭解 Media API 生命週期

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

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

同意者規定

只有在通話中有獲准代表會議提供同意聲明的人員時，Meet Media API 應用程式才能加入會議。

適用於 Google Workspace 會議

如要在 Google Workspace 會議中提供同意聲明，您必須屬於擁有該會議的機構。在大多數情況下，會議擁有者與發起人相同。如果主辦人或發起人已加入會議且屬於擁有該會議的機構，系統會優先向他們顯示開始對話方塊。

個人帳戶會議

如果是透過 Gmail 帳戶發起的會議，發起人必須在會議中提供同意聲明。

常見詞彙

雲端專案編號
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 動態管理。