La latence de la diffusion en direct s'accumule au niveau du client d'ingestion, du serveur et du client de lecture. Identifiez l'étape à l'origine de la latence, puis appliquez les configurations appropriées pour la réduire.
Causes de la latence de la diffusion en direct
Sur le client d'ingestion
Le Group of Pictures (GOP) est l'unité fondamentale de l'encodage et du décodage vidéo ; il débute par une image clé. La diffusion en direct horodate chaque image avant sa transmission sur le réseau. Une taille de GOP élevée retarde le démarrage de la lecture, car le client de lecture doit mettre en mémoire tampon davantage de données avant de pouvoir commencer la lecture.
Pour résoudre les problèmes de saccades, la plupart des logiciels tiers d'ingestion augmentent la mémoire tampon d'encodage. Toutefois, une mémoire tampon d'encodage trop grande accroît la latence.
Des limitations matérielles peuvent empêcher l'encodeur de respecter les paramètres requis en matière de débit binaire, de fréquence d'images et de profil d'encodage. Le délai d'encodage qui en résulte s'ajoute à la latence de bout en bout. Pour remédier à ces causes, consultez la section Configurer le client d'ingestion.
Côté serveur
Avant le début de la lecture, une partie des données de diffusion en direct est mise en cache afin d'assurer un démarrage rapide et de réduire les saccades. Ce cache garantit la fluidité du flux de données, mais les données mises en cache ajoutent de la latence. Pendant la lecture, les fluctuations du réseau peuvent empêcher les données d'atteindre le client, ce qui ajoute 2 à 3 secondes de latence.
Pour réduire le cache côté serveur, consultez la section Configurer le niveau de latence côté serveur.
Sur le client de lecture
La plupart des clients de lecture qui ne prennent pas en charge l'avance rapide commencent à décoder le flux en direct uniquement une fois la mémoire tampon de réception pleine. Le client de lecture doit remplir cette mémoire tampon avant que la lecture ne puisse démarrer.
Réduire la latence de la diffusion en direct
Les configurations suivantes réduisent la latence aux trois étapes où elle s'accumule : le client d'ingestion, le protocole de streaming et le serveur. Si votre client de lecture utilise HLS, commencez par le protocole de streaming, car HLS présente une latence plus élevée qu'HTTP-FLV et RTMP. Dans le cas contraire, configurez d'abord le client d'ingestion, puis réduisez le cache côté serveur. Pour une latence de l'ordre de la milliseconde, consultez la section Real-Time Streaming (RTS).
Configurer le client d'ingestion
Taille du GOP — Définissez la taille du GOP (intervalle entre les images clés) sur 1 à 2 secondes afin de raccourcir le temps de chargement des données GOP par le lecteur et de réduire la latence. Pour définir la taille du GOP dans la console, consultez la rubrique Transcodage personnalisé. Pour configurer la taille du GOP via une opération API, consultez la rubrique AddCustomLiveStreamTranscode.
Mémoire tampon d'encodage — Si une mémoire tampon d'encodage trop grande est à l'origine de la latence, utilisez le SDK Push d'Alibaba Cloud pour la réduire.
Mode d'encodage — Sur les appareils iOS utilisés pour l'ingestion, privilégiez l'encodage matériel, car il est efficace et économe en énergie. Sur Android, la grande variété de modèles d'appareils et de types de CPU signifie que l'encodage matériel peut entraîner des problèmes de compatibilité ; utilisez donc l'encodage logiciel pour l'ingestion sur Android.
Sélectionner un protocole de streaming
ApsaraVideo Live prend en charge trois protocoles de streaming : HTTP-FLV, HLS et RTMP. Tenez compte des contraintes de lecture suivantes avant d'en choisir un :
Dépendance au lecteur — HTTP-FLV et RTMP nécessitent un lecteur Flash. HLS est pris en charge nativement par la plupart des navigateurs web modernes.
Navigateurs mobiles — Pour regarder des diffusions en direct dans un navigateur mobile, vous ne pouvez utiliser que le protocole HLS.
Latence et compatibilité — HTTP-FLV et RTMP offrent une latence plus faible et conviennent aux scénarios nécessitant une lecture à faible latence. HLS présente une latence plus élevée mais une meilleure compatibilité, et convient aux scénarios peu sensibles à la latence mais nécessitant une lecture sur davantage d'appareils. Le tableau suivant compare les protocoles HTTP-FLV, HLS et RTMP.
| Protocole | Description | Protocole de transport | Format de conteneur | Cas d'utilisation |
| HTTP-FLV | Développé par Adobe. Encapsule les données de streaming au format FLV et transmet les données aux clients via HTTP, avec environ 2 secondes de latence. Prend en charge la transmission chiffrée via HTTPS et la lecture sur les appareils mobiles Android. | HTTP | FLV, TAG | Streaming à faible latence |
| HLS | Développé par Apple. Protocole de streaming basé sur HTTP. Divise les données de streaming en segments TS consécutifs. Chaque segment dure plus de 5 secondes et le nombre de segments est généralement de 3 à 4, de sorte que la latence totale est d'environ 10 à 30 secondes, mais la lecture est fluide. Principalement utilisé sur les appareils iOS, il fournit des services tels que le streaming audio et vidéo en direct et le contenu enregistré. | HTTP | M3U8, TS | Compatibilité multiplateforme |
| RTMP | Développé par Adobe. Lors de la transmission, les messages sont divisés en chunks plus petits, les chunks sont transmis via TCP et le récepteur réassemble les chunks en données de streaming. Cette complexité peut provoquer une instabilité du flux. Sur iOS, un décodeur tiers est requis pour la lecture. | TCP | FLV, TAG | Diffusion en direct interactive |
Si votre client de lecture utilise le protocole HLS, la latence indiquée dans le tableau précédent est normale. Pour la réduire, ajustez les paramètres côté serveur. Pour obtenir une latence plus faible, passez du protocole HLS au protocole FLV.
Configurer le niveau de latence côté serveur
Réduisez le cache côté serveur pour diminuer la latence de la diffusion en direct. Dans la console ApsaraVideo Live, vous pouvez définir la latence pour chaque protocole de streaming. Plus le paramètre de latence est bas, plus le cache côté serveur est réduit.
Connectez-vous à la console ApsaraVideo Live.
Dans le volet de navigation de gauche, cliquez sur Domain Names pour accéder à la page Domain Management.
Recherchez le domaine de streaming que vous souhaitez configurer et cliquez sur Domain Settings dans la colonne Actions.
Cliquez sur . La page affiche les paramètres de niveau de latence pour trois protocoles : RTMP Latency, FLV Latency et HLS Latency. Cliquez sur Modify Configuration pour ajuster les paramètres. La latence réelle dépend à la fois du niveau de latence défini et de la taille du GOP du flux d'ingestion ; maintenez donc la taille du GOP entre 1 et 2 secondes.
Après avoir réduit le cache, les données ne peuvent pas être téléchargées à temps lorsque le réseau est instable, ce qui provoque des saccades dans la diffusion en direct. En cas de saccades, cliquez à nouveau sur Modify Configuration et restaurez le niveau de latence précédent. Pour plus d'informations, consultez la rubrique Paramètres de latence.
Real-Time Streaming (RTS)
Si les configurations précédentes ne permettent pas de ramener la latence en dessous des 3 à 6 secondes typiques de la diffusion en direct traditionnelle, utilisez Real-Time Streaming (RTS). RTS offre une latence de diffusion en direct de l'ordre de la milliseconde dans des scénarios comptant des dizaines de millions de spectateurs simultanés. Il convient aux grands scénarios de streaming interactif et offre peu de saccades ainsi qu'un démarrage rapide.
**Facturation de RTS** — La facturation de RTS diffère de celle de la diffusion en direct standard. Pour connaître les règles de facturation, consultez la page de tarification d'Alibaba Cloud.
**Activer le service RTS** — Pour savoir comment activer le service RTS et l'utiliser, consultez la rubrique Présentation de RTS.