L'API Google Meet Media ti consente di accedere ai contenuti multimediali in tempo reale dalle conferenze Google Meet. Ciò consente una serie di casi d'uso, ad esempio app che documentano gli elementi di azione, offrono approfondimenti in tempo reale sulla riunione in corso o trasmettono audio e video a una nuova superficie.
Casi d'uso
Le app registrate nella console Google Cloud possono utilizzare l'API Meet Media per connettersi alle conferenze Meet, consentendo loro di:
- Consumare stream video. Ad esempio:
- Inserisci i flussi video generati nelle conferenze di Meet nei tuoi modelli di AI.
- Filtra gli stream per le registrazioni personalizzate.
- Consumare stream audio. Ad esempio:
- Invia l'audio direttamente a Gemini e crea il tuo chatbot AI per le riunioni.
- Invia i flussi audio generati nelle conferenze Meet al tuo servizio di trascrizione
- Generare sottotitoli codificati in varie lingue.
- Crea feed di lingua dei segni generati dal modello dall'audio acquisito.
- Crea i tuoi modelli di riduzione del rumore per rimuovere il rumore di fondo e gli artefatti dalla conferenza.
- Utilizzare i metadati dei partecipanti. Ad esempio:
- Rileva i partecipanti alla conferenza, consentendo una migliore intelligence e analisi.
Ciclo di vita dell'API Meet Media
Le seguenti immagini mostrano il ciclo di vita dell'API Meet Media:
-
Figura 1. Il bot dell'API Meet Media tenta di accedere al sito web di terze parti. La connessione viene rifiutata quando sono presenti account di minorenni. -
Figura 2. Le riunioni possono essere contrassegnate come criptate e avere una filigrana. L'API Meet Media non può essere connessa quando una riunione ha la crittografia o una filigrana. -
Figura 3. Assicurati che l'impostazione dell'amministratore sia corretta. -
Figura 4. Configura la riunione in Calendar. L'organizzatore deve concedere l'autorizzazione all'app di terze parti nell'impostazione del calendario, altrimenti la connessione viene rifiutata. -
Figura 5. Modifica di un'impostazione durante la chiamata. Se l'organizzatore decide di disattivare l'impostazione API Meet Media durante una chiamata, la connessione si interrompe. -
Figura 6. Se il proprietario della riunione ha un account consumer (un account che termina con @gmail.com), l'iniziatore deve essere presente alla riunione per dare il consenso, altrimenti la connessione viene rifiutata. -
Figura 7. Una volta stabilita la connessione, l'organizzatore, il co-organizzatore o qualsiasi partecipante della stessa organizzazione dell'organizzatore visualizza la finestra di dialogo di avvio. -
Figura 8. Chiunque può interrompere l'API Meet Media durante la chiamata.
Termini comuni
- Numero di progetto Cloud
- Un identificatore
int64
generato e immutabile per un progetto Google Cloud. Questi valori vengono generati dalla console Google Cloud per ogni app registrata. - Conferenza
- Un'istanza generata dal server di una chiamata all'interno di uno spazio di riunione. Gli utenti in genere considerano questo scenario come una singola riunione.
- Canale di dati delle risorse per le conferenze
Anziché richiedere risorse tramite HTTP, come con l'API REST di Google Meet, i client dell'API Meet Media richiedono risorse dal server tramite canali di dati.
Per ogni tipo di risorsa può essere aperto un canale di dati dedicato. Una volta aperto, il cliente può inviare richieste tramite il canale. Gli aggiornamenti delle risorse verranno trasmessi sullo stesso canale.
- Fonte di contributo (CSRC)
Con gli stream multimediali virtuali, non puoi presupporre che uno stream multimediale punti sempre allo stesso partecipante. Il valore CSRC nell'intestazione di ogni pacchetto RTP identifica la vera origine del pacchetto.
Meet assegna a ogni partecipante a una conferenza un valore CSRC univoco quando partecipa. Questo valore rimane costante finché non se ne va.
- Canali di dati
I canali di dati WebRTC consentono lo scambio di dati arbitrari (testo, file e così via) indipendentemente dai flussi audio e video. I canali di dati utilizzano la stessa connessione dei flussi multimediali, fornendo un modo efficiente per aggiungere lo scambio di dati alle applicazioni WebRTC.
- Interactive Connectivity Establishment (ICE)
Un protocollo per stabilire la connettività, trovare tutti i percorsi possibili per due computer per comunicare tra loro tramite il networking peer-to-peer (P2P) e poi assicurarsi che la connessione rimanga attiva.
- Stream di contenuti multimediali
Uno stream multimediale WebRTC rappresenta un flusso di dati multimediali, in genere audio o video, acquisiti da un dispositivo come una videocamera o un microfono. È composto da una o più tracce di stream multimediali, ognuna delle quali rappresenta una singola origine di contenuti multimediali, ad esempio una traccia video o una traccia audio.
- Traccia del flusso multimediale
Consiste in un flusso unidirezionale singolo di pacchetti RTP. Una traccia di stream multimediale può essere audio o video, ma non entrambi. Una connessione Secure Real-time Transport Protocol (SRTP) bidirezionale in genere è costituita da due tracce di flussi multimediali, uscita dal peer locale a quello remoto e ingresso dal peer remoto a quello locale.
- Spazio per le riunioni
Un luogo virtuale o un oggetto persistente (ad esempio una sala riunioni) in cui si tiene una conferenza. In uno spazio può essere attiva una sola conferenza alla volta. Uno spazio per riunioni aiuta anche gli utenti a incontrarsi e trovare risorse condivise.
- Partecipante
Una persona che ha partecipato a una conferenza o che utilizza la modalità Complementare, che guarda come spettatore o un dispositivo per sale connesso a una chiamata. Quando un partecipante si unisce alla conferenza, viene assegnato un ID univoco.
- Stream pertinenti
Esiste un limite al numero di flussi audio virtuali e flussi video virtuali che un client può aprire.
È molto probabile che il numero di partecipanti a una conferenza superi questo numero. In queste situazioni, i server di Meet trasmettono i flussi audio e video dei partecipanti considerati "più pertinenti". La pertinenza è determinata da varie caratteristiche, come la condivisione dello schermo e la data dell'ultimo intervento di un partecipante.
- Selective Forwarding Unit (SFU)
Un'unità di inoltro selettivo (SFU) è un componente lato server nelle conferenze WebRTC che gestisce la distribuzione dei flussi multimediali. I partecipanti si connettono solo all'SFU, che inoltra selettivamente i flussi pertinenti ad altri partecipanti. In questo modo si riducono l'elaborazione del client e le esigenze di larghezza di banda, consentendo conferenze scalabili.
- Session Description Protocol (SDP)
Il meccanismo di segnalazione utilizzato da WebRTC per negoziare una connessione P2P.
RFC 8866
.- Risposta SDP
La risposta a un'offerta SDP. La risposta rifiuta o accetta tutti i flussi ricevuti dal peer remoto. Inoltre, negozia i flussi che intende trasmettere al peer dell'offerta. È importante notare che la risposta SDP non può aggiungere flussi segnalati dall'offerta iniziale. A livello aneddotico, se un peer che offre segnala di accettare fino a tre flussi audio dal peer remoto, questo peer remoto non può segnalare quattro flussi audio per la trasmissione.
- Offerta SDP
L'SDP iniziale nel flusso di negoziazione peer-to-peer offerta-risposta. L'offerta viene creata dal peer che avvia la sessione e ne detta i termini. L'offerta viene sempre creata dal client dell'API Meet Media e inviata ai server di Meet.
Ad esempio, un'offerta può indicare il numero di stream audio o video che l'offerente sta inviando (o è in grado di ricevere) e se i canali di dati devono essere aperti.
- Synchronization Source (SSRC)
Un SSRC è un identificatore a 32 bit che identifica in modo univoco una singola origine di un flusso multimediale all'interno di una sessione RTP (Real-time Transport Protocol). In WebRTC, gli SSRC vengono utilizzati per distinguere i diversi flussi multimediali provenienti da partecipanti diversi o anche da tracce diverse dello stesso partecipante (ad esempio videocamere diverse).
- RtpTransceiver
Come descritto in dettaglio in
RFC 8829
, un transceiver è un'astrazione degli stream RTP in una sessione peer-to-peer.Un singolo ricetrasmettitore viene mappato e descritto da una singola descrizione multimediale nel SDP. Un ricetrasmettitore è composto da un
RtpSender
e da unRtpReceiver
.Poiché RTP è bidirezionale, ogni peer ha la propria istanza di ricetrasmettitore per la stessa connessione RTP. L'
RtpSender
di un determinato ricetrasmettitore per il peer locale è mappato all'RtpReceiver
di un ricetrasmettitore specifico nel peer remoto. Questo è vero anche in caso contrario. IlRtpSender
dello stesso transceiver del peer remoto viene mappato alRtpReceiver
del peer locale.Ogni descrizione del media ha il proprio ricetrasmettitore dedicato. Pertanto, una sessione peer-to-peer con più stream RTP ha più ricetrasmettitori con più
RtpSenders
eRtpReceiver
per ogni peer.- Virtual Media Streams
I flussi multimediali virtuali sono flussi multimediali aggregati generati da un'unità di inoltro selettivo (SFU) nelle conferenze WebRTC. Anziché inviare singoli stream a tutti gli altri, l'SFU esegue il multiplexing degli stream dei partecipanti selezionati in un numero inferiore di stream virtuali in uscita. In questo modo la topologia di connessione viene semplificata e il carico sui partecipanti ridotto, consentendo conferenze scalabili. Ogni flusso virtuale può contenere contenuti multimediali di più partecipanti, gestiti dinamicamente dall'SFU.
Argomenti correlati
Per scoprire come iniziare a sviluppare un client API Meet Media, segui i passaggi descritti in Inizia.
Per scoprire come configurare ed eseguire un client di riferimento dell'API Meet Media di esempio, leggi la guida rapida al client di riferimento C++.
Per una panoramica concettuale, consulta Concetti dell'API Meet Media.
Per saperne di più su WebRTC, consulta la pagina WebRTC For The Curious.
Per informazioni sullo sviluppo con le API Google Workspace, inclusa la gestione dell'autenticazione e dell'autorizzazione, consulta Sviluppare su Google Workspace.