Cette page a été traduite par l'API Cloud Translation.

Présentation de l'API Meet Media

L'API Google Meet Media vous permet d'accéder aux contenus multimédias en temps réel des conférences Google Meet. Cela permet divers cas d'utilisation, comme les applications qui documentent les tâches à effectuer, offrent des insights en temps réel sur la réunion en cours ou diffusent de l'audio et de la vidéo sur une nouvelle surface.

Cas d'utilisation

Les applications enregistrées dans la console Google Cloud peuvent utiliser l'API Meet Media pour se connecter aux conférences Meet, ce qui leur permet :

Consommer des flux vidéo Exemple :
- Intégrez les flux vidéo générés lors des conférences Meet dans vos propres modèles d'IA.
- Filtrer les flux pour les enregistrements personnalisés.
Écouter des flux audio Exemple :
- Envoyez directement de l'audio à Gemini et créez votre propre chatbot d'IA pour les réunions.
- Transférer les flux audio générés dans les conférences Meet vers votre propre service de transcription
- Générez des sous-titres dans différentes langues.
- Créez des flux de langage des signes générés par le modèle à partir de l'audio capturé.
- Créez vos propres modèles de suppression du bruit pour éliminer les artefacts de bruit et d'arrière-plan de la conférence.
Utilisez les métadonnées des participants. Exemple :
- Détecter les participants à la conférence, ce qui permet d'améliorer l'intelligence et les analyses.

Cycle de vie de l'API Meet Media

Les images suivantes illustrent le cycle de vie de l'API Meet Media :

Figure 1. Le bot de l'API Meet Media tente de rejoindre le site Web tiers. La connexion est refusée en présence de comptes appartenant à des mineurs.
Figure 2 : Les réunions peuvent être marquées comme chiffrées et comporter un filigrane. L'API Meet Media ne peut pas être connectée lorsqu'une réunion est chiffrée ou comporte un filigrane.
Figure 3. Assurez-vous que le paramètre d'administrateur est correct.
Figure 4. Configurez la réunion dans Agenda. L'hôte doit autoriser l'application tierce dans les paramètres de l'agenda. Sinon, la connexion est refusée.
Figure 5 : Modification d'un paramètre pendant l'appel. Si l'organisateur décide de désactiver le paramètre de l'API Meet Media pendant un appel, la connexion s'arrête.
Figure 6 : Si le propriétaire de la réunion possède un compte personnel (un compte se terminant par @gmail.com), l'organisateur doit être présent pour donner son consentement à la connexion, sinon celle-ci est refusée.
Figure 7. Une fois la connexion établie, l'organisateur, le coorganisateur ou tout participant appartenant à la même organisation que l'organisateur voient la boîte de dialogue d'initiation.
Figure 8 : Tous les participants peuvent arrêter l'API Meet Media pendant l'appel.

Termes courants

Numéro du projet Cloud

Identifiant int64 immuable généré pour un projet Google Cloud. Ces valeurs sont générées par la console Google Cloud pour chaque application enregistrée.

Conférence

Instance d'appel générée par le serveur dans un espace de réunion. Les utilisateurs considèrent généralement ce scénario comme une seule et même réunion.

Canal de données sur les ressources de conférence

Contrairement à l'API REST Google Meet, qui demande des ressources via HTTP, les clients de l'API Meet Media demandent des ressources au serveur via des canaux de données.

Un canal de données dédié peut être ouvert pour chaque type de ressource. Une fois le canal ouvert, le client peut envoyer des requêtes. Les mises à jour des ressources seront transmises sur le même canal.

Source contributrice (CSRC)

Avec les flux multimédias virtuels, vous ne pouvez pas supposer qu'un flux multimédia pointe toujours vers le même participant. La valeur CSRC dans l'en-tête de chaque paquet RTP identifie la véritable source du paquet.

Meet attribue à chaque participant à une conférence une valeur CSRC unique lorsqu'il rejoint la réunion. Cette valeur reste constante jusqu'à ce qu'il quitte la réunion.

Canaux de données

Les canaux de données WebRTC permettent d'échanger des données arbitraires (texte, fichiers, etc.) indépendamment des flux audio et vidéo. Les canaux de données utilisent la même connexion que les flux multimédias, ce qui permet d'ajouter efficacement l'échange de données aux applications WebRTC.

ICE (Interactive Connectivity Establishment)

Protocole permettant d'établir une connectivité, de trouver toutes les routes possibles pour que deux ordinateurs communiquent entre eux via un réseau peer-to-peer (P2P), puis de s'assurer que vous restez connecté.

Flux multimédia

Un flux multimédia WebRTC représente un flux de données multimédias, généralement audio ou vidéo, capturées à partir d'un appareil tel qu'une caméra ou un micro. Il se compose d'une ou plusieurs pistes de flux multimédia, chacune représentant une source multimédia unique (par exemple, une piste vidéo ou une piste audio).

Piste de flux multimédia

Il s'agit d'un flux unidirectionnel de paquets RTP. Une piste de flux multimédia peut être audio ou vidéo, mais pas les deux. Une connexion Secure Real-time Transport Protocol (SRTP) bidirectionnelle se compose généralement de deux pistes de flux multimédias : une piste de sortie du pair local vers le pair distant et une piste d'entrée du pair distant vers le pair local.

Espace de réunion

Lieu virtuel ou objet persistant (comme une salle de réunion) où se tient une conférence. Vous ne pouvez organiser qu'une seule conférence active à la fois dans un espace. Un espace de réunion permet également aux utilisateurs de se rencontrer et de trouver des ressources partagées.

Participant

Une personne qui participe à une conférence ou qui utilise le mode Compagnon, qui regarde la réunion en tant que spectateur ou qui utilise un appareil de salle connecté à un appel. Lorsqu'un participant rejoint la conférence, un ID unique lui est attribué.

Flux pertinents

Le nombre de flux audio virtuels et de flux vidéo virtuels qu'un client peut ouvrir est limité.

Il est tout à fait possible que le nombre de participants à une conférence dépasse ce nombre. Dans ces situations, les serveurs Meet transmettent les flux audio et vidéo des participants considérés comme "les plus pertinents". La pertinence est déterminée à partir de diverses caractéristiques, telles que le partage d'écran et la date à laquelle un participant a pris la parole pour la dernière fois.

Unité de transfert sélectif (SFU)

Une unité de transfert sélectif (SFU, Selective Forwarding Unit) est un composant côté serveur dans les conférences WebRTC qui gère la distribution des flux multimédias. Les participants se connectent uniquement à l'unité SFU, qui transmet sélectivement les flux pertinents aux autres participants. Cela réduit les besoins en bande passante et en traitement côté client, ce qui permet d'organiser des visioconférences évolutives.

SDP (Session Description Protocol)

Mécanisme de signalisation utilisé par WebRTC pour négocier une connexion P2P. RFC 8866.

Réponse SDP

Réponse à une offre SDP. La réponse refuse ou accepte tous les flux reçus du pair distant. Il négocie également les flux qu'il prévoit de retransmettre au pair de l'offre. Il est important de noter que la réponse SDP ne peut pas ajouter de flux signalés à partir de l'offre initiale. De manière anecdotique, si un pair d'offre signale qu'il accepte jusqu'à trois flux audio de son pair distant, ce pair distant ne peut pas signaler quatre flux audio pour la transmission.

Offre SDP

SDP initial dans le flux de négociation peer-to-peer offre-réponse. L'offre est créée par le pair initiateur et définit les conditions de la session peer-to-peer. L'offre est toujours créée par le client de l'API Meet Media et envoyée aux serveurs Meet.

Par exemple, une offre peut indiquer le nombre de flux audio ou vidéo que l'offrant envoie (ou est capable de recevoir) et si des canaux de données doivent être ouverts.

Source de synchronisation (SSRC)

Un SSRC est un identifiant de 32 bits qui identifie de manière unique une source unique d'un flux multimédia au sein d'une session RTP (Real-time Transport Protocol). Dans WebRTC, les SSRC permettent de distinguer les différents flux multimédias provenant de différents participants ou même de différentes pistes du même participant (comme différentes caméras).

RtpTransceiver

Comme indiqué dans RFC 8829, un émetteur-récepteur est une abstraction autour des flux RTP dans une session peer-to-peer.

Un seul émetteur-récepteur est mappé à une seule description de support dans le SDP et décrit par celle-ci. Un émetteur-récepteur se compose d'un RtpSender et d'un RtpReceiver.

Comme RTP est bidirectionnel, chaque pair possède sa propre instance d'émetteur-récepteur pour la même connexion RTP. Le RtpSender d'un émetteur-récepteur donné pour le pair local est mappé au RtpReceiver d'un émetteur-récepteur spécifique dans le pair distant. L'inverse est également vrai. Le RtpSender du même émetteur-récepteur du pair distant est mappé au RtpReceiver du pair local.

Chaque description de contenu multimédia possède son propre émetteur-récepteur dédié. Par conséquent, une session peer-to-peer avec plusieurs flux RTP comporte plusieurs émetteurs-récepteurs avec plusieurs RtpSenders et RtpReceiver pour chaque pair.

Flux multimédias virtuels

Les flux multimédias virtuels sont des flux multimédias agrégés générés par une unité de transfert sélectif (SFU) dans les conférences WebRTC. Au lieu que chaque participant envoie des flux individuels à tous les autres, la SFU multiplexe les flux de participants sélectionnés sur un nombre réduit de flux virtuels sortants. Cela simplifie la topologie de connexion et réduit la charge sur les participants, ce qui permet d'organiser des conférences évolutives. Chaque flux virtuel peut contenir des contenus multimédias provenant de plusieurs participants, gérés de manière dynamique par l'unité SFU.

Pour apprendre à développer un client Meet Media API, suivez la procédure décrite dans Premiers pas.
Pour savoir comment configurer et exécuter un exemple de client de référence de l'API Meet Media, consultez le démarrage rapide du client de référence C++.
Pour obtenir une présentation conceptuelle, consultez Concepts de l'API Meet Media.
Pour en savoir plus sur WebRTC, consultez WebRTC For The Curious.
Pour en savoir plus sur le développement avec les API Google Workspace, y compris sur la gestion de l'authentification et de l'autorisation, consultez Développer sur Google Workspace.