Une Video API plus intelligente et plus sûre

La vidéo en temps réel peut être un défi. Les participants se connectent à partir de différents appareils, sur différents réseaux, dans différentes parties du monde. Les conditions changent au milieu de l'appel : un appareil mobile peut passer du Wi-Fi aux données cellulaires (par exemple, de la 5G à la 4G), un pare-feu d'entreprise peut bloquer certains chemins UDP, et un ordinateur portable bas de gamme peut avoir du mal à supporter la charge du processeur.

L'API Video de Vonage s'articule autour d'un ensemble de fonctions intelligentes et complémentaires permettant d'adapter en permanence la session aux conditions changeantes, et ces fonctions sont organisées en trois couches, chacune s'adressant à un niveau différent de la pile :

  • Niveau topologique: Infrastructure de session, optimisation du routage et cycle de vie du serveur. Ces éléments concernent tous les participants à une session et ne nécessitent pas de configuration par flux.
  • Au niveau de la connexion entre pairs: Comment les clients individuels se connectent et négocient avec le routeur multimédia. Ces paramètres s'appliquent une fois par client, mais il peut y avoir plusieurs clients dans le même appareil de l'utilisateur final.
  • Au niveau du cours d'eau: Boutons de qualité par flux : codec, résolution, débit, etc. Ils peuvent être réglés indépendamment pour chaque éditeur et chaque abonné.

Les éléments constitutifs

Les caractéristiques sont organisées en trois couches concentriques. Les couches extérieures affectent tous les participants ; les couches intérieures peuvent être réglées par flux.

╔══════════════════════════════════════════════════════════════════════╗
║  TOPOLOGY LAYER                                                      ║
║  Routed vs. Relayed · Adaptive media routing · Media Mesh            ║
║  Session migration                                                   ║
║  ┌──────────────────────────────────────────────────────────────┐    ║
║  │  PEER-CONNECTION LAYER                                       │    ║
║  │  Single peer connection (SPC) · Codec negotiation            │    ║
║  │  ┌────────────────────────────────────────────────────┐      │    ║
║  │  │  STREAM LAYER                                      │      │    ║
║  │  │  Scalable video · Bitrate presets                  │      │    ║
║  │  │  Publisher resolution/frame rate                   │      │    ║
║  │  │  Subscriber preferred resolution/frame rate        │      │    ║
║  │  │  Audio fallback · FEC / NACK / DTX                 │      │    ║
║  │  └────────────────────────────────────────────────────┘      │    ║
║  └──────────────────────────────────────────────────────────────┘    ║
║  Monitoring: client observability · sender-side stats · MOS          ║
╚══════════════════════════════════════════════════════════════════════╝

La couche de surveillance s'étend sur les trois, offrant une visibilité sur la qualité à tous les niveaux.

Sous le capot : la pile WebRTC

De nombreuses garanties de fiabilité proviennent de fonctions intégrées à la pile WebRTC qui ne nécessitent pas d'appel explicite à l'API. Les comprendre permet de raisonner sur le comportement de la qualité et d'utiliser plus efficacement les API de niveau supérieur.

Contrôle de la congestion et adaptation du débit

Les implémentations WebRTC utilisent par défaut le contrôle de congestion de Google (GCC). Le GCC sonde en permanence la bande passante disponible, estime le goulot d'étranglement actuel et signale à l'encodeur d'augmenter ou de réduire son débit cible. Il s'agit du principal mécanisme permettant de maintenir une session en vie en cas d'encombrement transitoire. Tout paramètre de la Video API de Vonage qui affecte le débit binaire agit comme un mécanisme de GCC. plafond au-dessus de GCC, et GCC continue de s'adapter dynamiquement en dessous de ce plafond.

Correction d'erreur directe (FEC)

Les flux audio tentent de négocier le FEC Opus par défaut. Le codec Opus incorpore une copie de qualité inférieure de chaque trame audio dans le fichier suivant trame. Si la première trame est perdue en cours de route, le récepteur la reconstruit à partir de la copie contenue dans le paquet suivant, au prix d'une petite surcharge de bande passante. Cette méthode est particulièrement efficace en cas de perte aléatoire de paquets, comme c'est le cas sur les réseaux Wi-Fi ou cellulaires encombrés.

Pour la vidéo, tous les codecs prennent en charge le RTP RED FEC lorsqu'il est négocié. Le FEC est transparent pour votre application. Il ajoute de la redondance au flux média, ce qui permet au récepteur de récupérer les paquets perdus ou corrompus sans avoir à les retransmettre. Pour plus d'informations, vous pouvez lire le RFC 8854.

NACK et RTX (Retransmission)

Lorsqu'un paquet vidéo est perdu, le récepteur envoie un ACK négatif (NACK) pour demander la retransmission. Le NACK/RTX ajoute un temps de latence proportionnel au temps d'aller-retour (généralement entre 50 et 200 ms).

Transmission discontinue (DTX)

Opus DTX détecte les silences sur le microphone et arrête d'envoyer des paquets audio pendant les périodes de silence, réduisant ainsi la bande passante audio à presque zéro. Vous pouvez activer DTX par l'intermédiaire de l'option enableDtx du SDK de votre choix lors de l'initialisation de l'éditeur.

DTLS-SRTP et protocole de transport sécurisé en temps réel

Tous les médias sont cryptés par défaut à l'aide de DTLS-SRTP. La négociation des clés de chiffrement s'effectue dans le cadre de la poignée de main WebRTC, avant tout flux de données. Pour une sécurité accrue, la clé de chiffrement AES-256 fonction complémentaire fournit un cryptage de 256 bits. Ces méthodes de chiffrement de la couche transport (DTLS-SRTP et AES-256) fonctionnent parallèlement à la fonction optionnelle de chiffrement de bout en bout (E2EE), qui ajoute une couche supplémentaire de chiffrement au niveau de l'application. Voir la page Guide de chiffrement de bout en bout pour plus de détails.

ICE et TURN

L'établissement interactif de la connectivité (ICE) essaie plusieurs chemins entre les points d'extrémité (UDP direct, STUN-réflexif, relais TURN) et choisit le meilleur. Si le meilleur chemin change en cours d'appel (ce qui est fréquent lorsqu'un appareil mobile change de réseau), l'ICE peut redémarrer et trouver un nouveau chemin sans interrompre l'appel. Pour les sessions traversant des pare-feux restrictifs, voir la section Guide des serveurs TURN configurables et le Guide des réseaux restreints.

Optimisations au niveau de la topologie

Les caractéristiques au niveau de la topologie déterminent la l'infrastructure à travers lesquels les médias circulent. Ils sont définis lors de la création d'une session ou de la connexion à celle-ci et affectent tous les participants de la même manière. Une topologie correcte est la base sur laquelle tout le reste se construit.

Mode média : Acheminé ou relayé

La décision la plus fondamentale en matière de topologie est la suivante mode média.

  • Sessions relayées: Les clients tentent d'envoyer des flux audio-vidéo directement les uns aux autres (poste à poste), en se rabattant sur le relais TURN si un pare-feu bloque le chemin direct. Les sessions relayées ont une latence plus faible pour les petits groupes mais ne peuvent pas utiliser la vidéo évolutive, le repli audio de l'abonné, la connexion d'un seul pair ou les statistiques du côté de l'émetteur.
  • Sessions routées: Les médias passent par le routeur vidéo de Vonage. Cela permet d'accéder à l'ensemble des fonctions intelligentes : vidéo évolutive, repli audio de l'abonné, connexion monoposte (SPC), statistiques côté émetteur, diffusion en direct, archivage, interconnexion SIP, et plus encore.

Pour les sessions avec trois participants ou plus, utilisez toujours une session routée. Voir l'article Création d'un guide de session.

Routage adaptatif des médias

Dans les sessions routées (à partir du SDK v2.24.7+ pour le Web et v2.27.0+ pour le natif), la plateforme utilise automatiquement routage adaptatif des médias afin d'optimiser le trafic entre les participants. Lorsque les éditeurs n'ont qu'un seul abonné et qu'aucune fonction de routage (archivage, diffusion en direct, SIP, etc.) n'est activée, le média est acheminé directement entre les éditeurs et les abonnés, sans qu'il soit nécessaire de déclarer une session relayée au préalable. Dès qu'un éditeur a plus d'un abonné ou qu'une fonction d'acheminement seulement est activée, le routeur de médias prend en charge l'acheminement de manière transparente. Par exemple, dans les cas d'utilisation conversationnelle (tous les participants publient et s'abonnent en même temps) sans fonctions d'acheminement uniquement, dès que le troisième participant se joint à la session, celle-ci est transférée de manière transparente vers le routeur de médias.

Cela signifie qu'en pratique, vous pouvez déclarer une session routée dans tous les cas et obtenir une latence proche du relais pour les appels 1:1. Le routage adaptatif des médias est activé par défaut et ne nécessite aucune configuration. Voir la page Création d'un guide de session.

Maillage des médias

La plateforme utilise Maillage des médias pour connecter automatiquement chaque participant au centre de données Media Router le plus proche de lui (vous pouvez vérifier ici la liste de tous les centres de données disponibles). Dans le cas d'une session géographiquement distribuée (par exemple, des participants à New York, Francfort et Sydney), Media Mesh garantit que chaque client achemine les médias via le serveur régional le plus proche plutôt que de passer par un seul centre de données, potentiellement distant. Il en résulte une latence plus faible et une meilleure qualité pour tous les participants, en particulier dans les grandes sessions internationales.

Media Mesh est activé par défaut et ne nécessite aucune configuration. Si vous souhaitez mieux contrôler l'acheminement des médias, vous disposez de deux options de personnalisation :

  • Indication d'emplacement (meilleur effort) : vous pouvez indiquer un centre de données de signalisation préféré. La plate-forme tentera d'utiliser l'emplacement demandé dans la mesure du possible, mais cela n'est pas garanti et peut se rabattre sur un autre centre de données en fonction de la disponibilité, de la capacité ou d'autres considérations opérationnelles. Voir la page Création d'un guide de session pour plus d'informations.

  • Regional Media Zone (enforced) : si vous devez maintenir l'acheminement des médias dans une région spécifique (pour des raisons de résidence des données ou de conformité), configurez une Regional Media Zone. Ce paramètre est forcé : la signalisation et les médias seront acheminés via la zone sélectionnée au lieu de choisir automatiquement le centre de données le plus proche. Une documentation supplémentaire est disponible dans la section Guide des zones médiatiques régionales.

Migration de la session

Ce qu'il fait : Transfert transparent de tous les participants à une session vers un nouveau serveur Media Router lors d'une rotation planifiée des serveurs, sans déconnecter qui que ce soit. Aucune manipulation côté application n'est nécessaire (les Applications n'ont pas besoin d'implémenter leur propre logique de transfert/reconnexion ; la plateforme s'en charge pour elles).

Pourquoi c'est important : L'infrastructure en nuage n'est jamais statique. Les serveurs font l'objet de correctifs, sont mis à l'échelle et remplacés. Sans migration de session, une rotation de serveur oblige chaque participant à se déconnecter et à se reconnecter, ce qui peut s'avérer perturbant lorsque la session dure plus de 8 heures. Lorsque la migration de session est activée (SDK v2.30.0+), la transition est invisible : les flux se poursuivent, aucun événement de reconnexion n'est déclenché et l'audio/vidéo existante n'est pas interrompue.

Ce qui nécessite encore un redémarrage : Les enregistrements (archives), les diffusions en direct et les instances d'Experience Composer prennent fin lorsqu'une session migre et doivent être redémarrés via le rappel de notification de la session. Archives automatiques redémarrer automatiquement.

Comment l'activer : Passez sessionMigration: true dans les options d'initialisation de la session pour chaque client. Par défaut, il s'agit de false. Voir le Guide de rotation des serveurs et de migration des sessions pour la syntaxe complète spécifique au SDK, le déclenchement manuel et pour des détails sur la gestion du rappel de notification de session.

Reconnexion automatique

Ce qu'il fait : Lorsqu'un client perd inopinément sa connexion à une session, le SDK tente automatiquement de rétablir la connexion sans nécessiter de code d'application.

Pourquoi c'est important : Sans reconnexion automatique, une brève interruption du réseau obligerait l'utilisateur à rejoindre manuellement la session. Avec la reconnexion automatique, le SDK gère la reprise de manière transparente. Les flux auxquels l'utilisateur s'est abonné s'interrompent et reprennent automatiquement lorsque la connexion est rétablie.

Comment cela fonctionne-t-il ? Aucune configuration n'est nécessaire. Lorsque la connexion est interrompue et que le client tente de se reconnecter :

  • L'objet Session envoie un sessionReconnecting événement.
  • Si la connexion est rétablie, l'objet Session envoie un message sessionReconnected événement.
  • Si la connexion ne peut pas être rétablie, le client se déconnecte de la session et le système sessionDisconnected est déclenché.

Votre application peut éventuellement écouter ces événements pour afficher des indicateurs d'état à l'utilisateur :

session.on({
  sessionReconnecting: function() {
    // Display a "reconnecting..." indicator
  },
  sessionReconnected: function() {
    // Hide the indicator
  },
  sessionDisconnected: function() {
    // Handle permanent disconnection
  }
});

Les signaux envoyés lors d'une déconnexion temporaire sont mis en file d'attente et délivrés une fois la connexion rétablie. Voir la page Rejoindre un guide de session pour des exemples complets et des noms d'événements spécifiques au SDK.

Stratégies au niveau de la connexion avec les pairs

Les fonctionnalités au niveau de la connexion entre pairs régissent la façon dont les connexions WebRTC d'un client au routeur multimédia sont structurées et les codecs qu'elles négocient. Ces paramètres s'appliquent une fois par client (et non par flux) et ont un effet important sur la consommation de ressources et la compatibilité.

Connexion à un seul pair (SPC)

Ce qu'il fait : Regroupe tous les flux d'abonnés d'un client en une seule connexion pair WebRTC au routeur multimédia, au lieu d'une connexion par flux.

Pourquoi c'est important : Chaque connexion d'égal à égal supplémentaire ajoute des frais généraux : des candidats ICE distincts, des poignées de main DTLS et l'état des sockets au niveau du système d'exploitation. Sur un appareil mobile abonné à dix flux, dix connexions homologues peuvent solliciter l'appareil et consommer beaucoup d'énergie. SPC réduit ce nombre à une seule connexion, ce qui diminue la consommation de ressources et permet des sessions plus importantes sur les clients mobiles natifs.

Avantage supplémentaire : le contrôle des taux : Avec une seule connexion, le contrôleur de congestion WebRTC voit tous Les flux entrants sont considérés comme un seul paquet et peuvent prendre des décisions plus éclairées en matière d'adaptation du débit. Dans le modèle à connexions multiples, chaque connexion sonde et s'adapte indépendamment, ce qui peut entraîner une oscillation et un partage sous-optimal de la bande passante.

Comment l'activer : SPC est désactivé par défaut. Régler singlePeerConnection: true lors de l'initialisation de la session. Pour le SDK web, transmettez-le en tant que propriété dans l'élément OT.initSession() l'objet "options". Pour les autres SDK :

  • Android : Session.Builder.setSinglePeerConnection(true)
  • iOS : OTSessionSettings.singlePeerConnection = YES
  • Fenêtres : SinglePeerConnection propriété sur Session.Builder
  • Linux/macOS : otc_session_settings_set_single_peer_connection()
  • React Native : enableSinglePeerConnection dans l'OTSession options étai

Voir le Création d'un guide de session pour des exemples complets.

Quand l'utiliser ? Activez le SPC chaque fois que vous avez plus d'une poignée d'abonnés dans une session acheminée, en particulier sur les plateformes mobiles. Les avantages augmentent avec le nombre de flux.

Sélection du codec

Ce qu'il fait : Sélectionne le codec vidéo utilisé entre chaque paire éditeur-abonné.

Pourquoi c'est important : Le choix du codec a une incidence sur la qualité à un débit donné, l'utilisation du processeur, la disponibilité de l'accélération matérielle et la compatibilité avec la vidéo évolutive. VP8 est le codec par défaut le plus sûr : il est universellement pris en charge, bénéficie d'une accélération matérielle sur la plupart des plateformes et est compatible avec la vidéo évolutive. VP9 offre une meilleure qualité au même débit, mais avec un coût d'unité centrale plus élevé. H.264 bénéficie d'encodeurs matériels sur iOS et certains appareils Android, ce qui réduit la consommation de la batterie, mais ne prend pas en charge la vidéo évolutive.

Fonctionnement automatique : La plateforme Vonage négocie le codec pour chaque paire éditeur-abonné, en respectant la préférence au niveau du projet tout en revenant au VP8 si le codec préféré n'est pas pris en charge par les deux points d'extrémité.

Quand intervenir ? Voir le Guide des codecs vidéo pour les critères de décision complets, le Guide vidéo scalable VP9 pour les comportements spécifiques au VP9, et le Préférences de codecs SDK API pour l'emporter sur le principe de l'éditeur.

Chiffrement de bout en bout (E2EE)

Ce qu'il fait : Chiffre les données utiles des médias au niveau du client afin qu'elles restent chiffrées dans le routeur de médias et qu'elles ne puissent être déchiffrées que par d'autres participants à la même session. Il s'agit d'une couche de cryptage supplémentaire qui s'ajoute au cryptage de transport DTLS-SRTP standard.

Pourquoi c'est important : Dans les sessions routées standard, le routeur multimédia peut accéder aux médias non cryptés (ce qui est nécessaire pour des fonctions telles que l'archivage, le transcodage et la sélection de couches vidéo évolutives). L'E2EE empêche le routeur média d'accéder au contenu média, ce qui est nécessaire pour les cas d'utilisation où une stricte confidentialité des données doit être maintenue de bout en bout.

Des contraintes importantes : Lorsque l'E2EE est activé, les fonctionnalités qui nécessitent un décodage média au niveau du Media Router ne sont pas disponibles : archivage, diffusion en direct, Experience Composer, Audio Connector et interconnexion SIP. Assurez-vous de tenir compte de ces limitations avant d'activer E2EE.

Comment l'activer : E2EE est une fonction supplémentaire qui doit d'abord être activée pour votre compte Vonage Video. Une fois la fonction activée, créez la session avec e2ee: true à l'aide de l'API Video de Vonage côté serveur, et définir le secret de cryptage lors de l'initialisation de la session dans le client :

vonage.video.createSession({ mediaMode: "routed", e2ee: true });

Tous les participants à la session doivent utiliser le même secret de cryptage pour recevoir des médias intelligibles. Le secret peut être modifié à la volée une fois que la session est connectée. Voir la page Guide de chiffrement de bout en bout pour obtenir des instructions d'installation complètes et des exemples spécifiques au SDK.

Contrôles de qualité au niveau des cours d'eau

Les caractéristiques au niveau du flux sont les boutons les plus granulaires disponibles. Elles peuvent être définies indépendamment pour chaque éditeur et chaque abonné, et nombre d'entre elles peuvent être modifiées dynamiquement en cours d'appel. C'est à ce niveau que votre application participe activement à la gestion de la qualité.

Vidéo évolutive

Ce qu'il fait : L'éditeur encode plusieurs couches spatiales et temporelles du même flux. Chaque abonné reçoit la couche qui correspond à sa bande passante disponible et à ses besoins d'affichage, sans que l'éditeur n'envoie des flux pleine résolution en double.

Pourquoi c'est important : Dans une session avec dix abonnés, l'envoi de dix flux Full-HD indépendants depuis l'éditeur est un gaspillage, tandis que l'adaptation d'un flux unique à l'abonné le plus limité est loin d'être optimale. La vidéo évolutive envoie un flux avec plusieurs couches de qualité ; le routeur multimédia sélectionne et transmet la couche appropriée à chaque abonné. Lorsque le réseau d'un abonné se dégrade, le routeur média rétrograde sa couche en temps réel, tandis que l'éditeur n'est pas affecté, continuant à diffuser toutes ses couches pour que le routeur média prenne la décision.

Fonctionnement automatique : Dans les sessions acheminées avec plus de deux participants, le routeur multimédia active automatiquement la vidéo évolutive (l'option Auto le cadre du projet). Le SDK de chaque éditeur négocie la structure d'évolutivité (le simulcast VP8 utilise les couches L1T1/L2T1/L3T1 ; le SVC VP9 peut également utiliser des couches spatiales).

Quand intervenir ? Pour les flux de partage d'écran, activez explicitement la vidéo évolutive lorsque vous souhaitez que le routeur multimédia réduise l'échelle pour les abonnés disposant d'une bande passante plus faible. Voir l'article Guide vidéo évolutif.

Préréglages de débit et débit maximal de l'éditeur

Ce qu'il fait : Permet de limiter le débit maximal utilisé par un éditeur pour la vidéo de la caméra, à l'aide de préréglages nommés (DEFAULT, BW_SAVER, EXTRA_BW_SAVER) ou des valeurs brutes.

Pourquoi c'est important : Sur une connexion avec compteur ou encombrée, un éditeur sans contrainte sera en concurrence avec toutes les autres applications de l'appareil pour l'obtention de la bande passante. En définissant un préréglage plus bas, vous réduisez votre empreinte vidéo, ce qui laisse une plus grande marge de manœuvre aux autres applications sur le même appareil. Lorsque vous utilisez VP8 avec la vidéo évolutive activée, le préréglage contrôle également les couches d'encodage actives. BW_SAVER limite effectivement le flux à deux couches spatiales (basse et moyenne), et EXTRA_BW_SAVER la limite à un (faible).

Interaction avec le contrôle des taux : Le contrôle de congestion de Google (GCC) s'adapte toujours de manière dynamique en dessous du plafond prédéfini. Réglage BW_SAVER est un plafond et non un plancher.

N'utilisez pas les préréglages de débit pour le partage d'écran. Les encodeurs de partage d'écran fonctionnent différemment ; l'application d'un plafond de débit à un partage d'écran peut produire une sortie floue, à faible fréquence d'images, sans l'économie de bande passante escomptée. Voir la page Guide du débit maximal de l'éditeur.

Contrôles de la résolution et de la fréquence d'images de l'éditeur

Outre les préréglages de débit, vous pouvez contrôler directement la résolution et la fréquence d'images auxquelles un éditeur encode la vidéo. Il existe deux approches : les définir au moment de la publication ou les ajuster dynamiquement après le début de la publication.

Définition de la résolution et de la fréquence d'images au moment de la publication (Web SDK) :

const publisher = OT.initPublisher(targetElement, {
  resolution: '1280x720', // '1920x1080', '1280x720', '640x480', '320x240'
  frameRate: 15,          // 30, 15, 7, or 1
});

L'initialisation de l'éditeur se fait toujours au moment de la maximum (le SDK ne peut que réduire la valeur initiale, et non l'augmenter).

Ajustement dynamique de la résolution et de la fréquence d'images (Web SDK) :

Une fois la publication commencée, vous pouvez modifier la résolution et la fréquence d'images préférées de l'éditeur sans redémarrer le flux :

// Reduce resolution
await publisher.setPreferredResolution({ width: 320, height: 180 });

// Reduce frame rate
await publisher.setPreferredFrameRate(7);

Scénarios courants dans lesquels l'ajustement dynamique est utile :

  • Répondre aux qualityLimitationReason: "cpu" d'après les statistiques de l'éditeur : réduire la fréquence d'images pour soulager le processeur.
  • Réponse à une baisse soudaine de la bande passante avant que le repli audio ne se déclenche.

Conseils sur le contenu vidéo (Web SDK) : Pour les flux de partage d'écran, définissez l'indice de contenu pour guider la stratégie d'encodage du navigateur :

publisher.setVideoContentHint("text");    // Prioritises sharp text/static content
publisher.setVideoContentHint("motion");  // Prioritises smooth motion (default camera behaviour)
publisher.setVideoContentHint("detail");  // Prioritises fine detail at lower frame rates

Voir le Guide des contraintes vidéo de l'éditeur et le Publication d'un flux - Guide web.

Préférence de dégradation vidéo de l'éditeur

Ce qu'il fait : Contrôle la priorité accordée par le moteur vidéo à la réduction de la résolution et à la réduction de la fréquence d'images lorsque la bande passante ou les ressources de l'unité centrale sont limitées.

Pourquoi c'est important : Lorsque le réseau ou l'appareil ne peut pas supporter la qualité vidéo actuelle, l'encodeur doit procéder à une dégradation. Par défaut, le moteur vidéo décide de manière autonome. La préférence de dégradation vous permet d'exprimer la priorité de votre application : par exemple, une session de partage d'écran bénéficie du maintien de la résolution (la netteté du texte est plus importante que la fluidité des mouvements), tandis qu'un flux de caméra bénéficie du maintien de la fréquence d'images (la fluidité des mouvements est plus naturelle que les blocs d'images fixes).

Relation avec le contenu Indice : Conseils sur le contenu vidéo et la préférence de dégradation ont des objectifs différents mais liés. L'indice de contenu décrit le type de contenu transmis (par exemple, "text" pour le partage d'écran), tandis que la préférence de dégradation contrôle explicitement la stratégie d'encodage. Lorsque vous définissez une indication de contenu, le moteur vidéo sélectionne automatiquement une préférence de dégradation appropriée - par exemple, "text" sélectionne automatiquement le maintien de la résolution. Une préférence de dégradation explicitement définie remplace la sélection automatique de Content Hint.

Relation avec la vidéo évolutive : Lorsque la vidéo évolutive est active, le moteur vidéo peut décider de supprimer une couche temporelle ou spatiale plutôt que de dégrader la résolution du flux restant. La préférence de dégradation s'applique toujours comme guide dans les couches actives.

API spécifiques au SDK :

Voir les guides de publication spécifiques à chaque plateforme pour des exemples complets : Android, iOS, iOS (Swift), Linux, Fenêtres.

Résolution et fréquence d'images préférées de l'abonné

Lorsque vous vous abonnez à un flux vidéo évolutif, vous pouvez indiquer au routeur multimédia la couche de qualité à fournir à chaque abonné. Il s'agit de l'outil principal pour créer des mises en page adaptatives. Par exemple, une grande grille de conférence où les vignettes doivent recevoir une couche basse résolution et où l'orateur actif doit recevoir la pleine résolution.

Définition de la résolution préférée au moment de la souscription (Web SDK) :

session.subscribe(stream, targetElement, {
  preferredResolution: 'auto', // Recommended: SDK picks the layer based on element size
  // Or specify explicitly:
  // preferredResolution: { width: 320, height: 240 },
  // preferredFrameRate: 7,
});

Les "auto" est recommandé dans la plupart des cas : le SDK Web déduit automatiquement la résolution déduit automatiquement la résolution préférée de la taille rendue de l'élément vidéo de l'abonné de l'abonné et demande la couche vidéo évolutive la plus appropriée. Il faut savoir que que "auto" est sensible à la mise en page. Si votre application modifie fréquemment la taille des tuiles de l'abonné (par ex. la taille des tuiles d'abonnés (par exemple, commutation de haut-parleur actif, flux d'épinglage/dépinglage, relais de grille réactifs ou transitions animées), le SDK pourrait de la grille réactive ou des transitions animées), le SDK peut mettre à jour à plusieurs reprises la résolution préférée. mettre à jour de manière répétée la résolution préférée. Cela peut déclencher des changements de couche plus fréquents et une "montée en puissance" de la bande passante. Cela peut déclencher des changements de couche plus fréquents et des cycles de "montée/descente" de la bande passante sur le routeur multimédia, ce qui peut augmenter la saturation du réseau et réduire la stabilité visuelle. Pour les mises en page très dynamiques, envisagez de définir une résolution preferredResolution (et l'actualiser uniquement lorsque l'interface utilisateur se stabilise), ou limiter les changements de résolution pour éviter une oscillation rapide. pour éviter une oscillation rapide.

Ajustement dynamique après l'abonnement :

// Downgrade a tile when moving it to a thumbnail position
subscriber.setPreferredResolution({ width: 320, height: 240 });
subscriber.setPreferredFrameRate(7);

// Upgrade when the subscriber becomes the active speaker
subscriber.setPreferredResolution({ width: 1280, height: 720 });
subscriber.setPreferredFrameRate(30);

Restriction de la fréquence d'images (Web SDK) : subscriber.restrictFrameRate(true) limite l'abonné à une image par seconde ou moins. Il peut être utile pour les participants non actifs à de grandes sessions d'économiser l'unité centrale et la bande passante tout en affichant une tuile de "présence". Appel restrictFrameRate(false) pour rétablir la fréquence d'images normale.

Pour les API inter-SDK, voir la section Guide vidéo évolutif et le S'abonner au guide de qualité.

Repli audio

Ce qu'il fait : Lorsque le réseau d'un éditeur ou d'un abonné ne peut plus supporter la vidéo, le SDK désactive automatiquement la vidéo pour ce flux, en conservant l'audio, et la réactive lorsque les conditions s'améliorent.

Pourquoi c'est important : Une image vidéo figée est dérangeante ; un flux audio interrompu interrompt complètement la conversation. Le repli audio garantit que lorsque la bande passante s'épuise, les participants peuvent toujours s'entendre. Associé à Opus FEC et DTX, l'audio reste intelligible même à des débits très faibles.

Deux modes complémentaires :

  • Repli audio de l'éditeur: Déclenché par l'évaluation du réseau du client qui publie. Lorsque les mesures d'encombrement de l'éditeur montrent que la vidéo n'est pas viable, l'éditeur désactive sa piste vidéo. Disponible dans les sessions relayées et routées.
  • Repli audio de l'abonné: Déclenché par le routeur média au nom d'un abonné spécifique. Seul l'abonné concerné perd la vidéo ; les autres abonnés continuent de la recevoir. Disponible uniquement dans les sessions acheminées.

Les deux fonctions sont activées automatiquement. Pour plus d'informations, voir le Guide de repli audio.

Contrôle et observabilité

La couche de surveillance s'étend sur les trois couches de la pile, offrant une visibilité sur la qualité à tous les niveaux, depuis la topologie de l'infrastructure jusqu'aux mesures des flux individuels.

Suivi de la qualité et observabilité des clients

Ce qu'il fait : L'API d'observabilité client fournit un flux continu de statistiques par flux - perte de paquets, débit binaire, fréquence d'images, résolution décodée, nombre d'arrêts sur image et autres - pour les éditeurs et les abonnés. Le SDK web fournit également un score d'opinion moyen (MOS) pour la vidéo, qui est un score de qualité simulant l'échelle de score MOS pour l'audio, ainsi qu'un contrôle des performances de l'unité centrale.

Pourquoi c'est important : Sans visibilité sur ce qui se passe à chaque point d'extrémité, vous ne pouvez pas distinguer "le réseau de l'utilisateur est mauvais" de "l'appareil de l'utilisateur est surchargé". Les statistiques permettent à votre application de prendre des décisions intelligentes : avertir l'utilisateur avant que la qualité ne se dégrade davantage, ajuster les mises en page ou déclencher des actions basées sur des politiques.

Capacités clés :

  • API de statistiques de haut niveau: Mesures agrégées par éditeur ou par abonné, normalisées en fonction des transitions de connexion entre pairs. A utiliser pour le suivi de la production et l'UX adaptative.
  • La qualité de la vidéo a changé événements: Déclenché lorsque la qualité change avec un code de raison (bande passante, CPU, changement de codec, changement de résolution). Utilisez-les pour piloter l'état de l'interface utilisateur sans interrogation.
  • Score d'opinion moyen (MOS): Un score de qualité standard de 1 à 5 (web uniquement). Intégrez-le à votre pile d'observation pour suivre les tendances de la qualité des appels au fil du temps.
  • Surveillance des performances de l'unité centrale: Détecte le stress du processeur du côté de l'appareil avant qu'il n'entraîne une perte d'images (Web uniquement). Réagissez en désactivant les fonctions gourmandes en ressources processeur, comme le flou d'arrière-plan.
  • Tests préalables à l'appel: Utilisez la fonction Bibliothèque de test du réseau vidéo de Vonage pour estimer le MOS et vérifier la publiabilité audio/vidéo avant que l'utilisateur ne rejoigne une session.

Voir le Guide d'observabilité pour les clients pour obtenir la référence statistique complète et des exemples de code spécifiques au SDK.

Pour en savoir plus