Points clés à retenir
- La mise en mémoire tampon à la capture, l’analyse anticipée de l’encodeur, la durée des segments, le transport réseau, le comportement du CDN et la mise en mémoire tampon du lecteur y contribuent tous.
- Une latence plus faible réduit la tolérance du système à la gigue et augmente souvent la complexité opérationnelle.
- Les enchères interactives et les conversations nécessitent des objectifs différents de ceux des diffusions sans retour du public.
La latence est le temps écoulé entre le moment où un événement se produit et celui où un spectateur le voit. Elle s’accumule à plusieurs étapes ; modifier un seul tampon du lecteur ne résout donc pas tous les retards.
L’essentiel
- Mesurez la latence de bout en bout avec des marqueurs synchronisés au lieu de citer le délai configuré d’un seul composant.
Définir la latence du point de vue du spectateur
La latence vidéo est le temps écoulé entre le moment où un événement se produit et celui où le spectateur le voit ou l’entend. Pour un produit proposant du direct, la mesure utile est généralement la latence de bout en bout, de la scène capturée au rendu lors de la lecture. Le délai entre la caméra et l’encodeur, l’écart par rapport au point courant du direct, le temps de démarrage du lecteur et le temps aller-retour d’une réponse sont des mesures liées, mais elles répondent à des questions différentes. Précisez les points de mesure chaque fois que vous présentez un résultat.
Un objectif de latence doit décrire l’interaction qu’il permet. Les conversations à distance, les enchères, les jeux et l’assistance en direct nécessitent des retours plus rapides qu’une conférence sans réponse du public. Une latence plus faible n’est pas automatiquement préférable, car les tampons absorbent les variations du réseau. Les réduire peut remplacer le retard par des interruptions de lecture, une baisse de qualité ou un échec de lecture. Choisissez la latence la plus élevée qui permette encore à l’interaction prévue de sembler naturelle, puis répartissez un budget de latence sur toute la chaîne de diffusion.
Définir le seuil acceptable pour l’expérience
Décrivez ce qui devient gênant ou incorrect lorsque le retard dépasse l’objectif, par exemple des prises de parole qui se chevauchent ou des enchères tardives.
Présenter les distributions
La médiane, le comportement en queue de distribution, l’appareil, le réseau et la région sont plus utiles qu’une seule observation dans les meilleures conditions.
Mesurer de bout en bout avec des données synchronisées
Un test simple consiste à afficher une horloge qui avance ou un compteur d’images devant la caméra source et à capturer l’écran du spectateur dans le même enregistrement. La différence entre le marqueur source et le marqueur affiché permet d’estimer le délai de bout en bout. Pour les tests distribués, synchronisez soigneusement les horloges et consignez les horodatages lors de la capture, de l’ingestion, de l’empaquetage, de la réception par le lecteur, du décodage et du rendu. Répétez le test suffisamment longtemps pour observer la dérive et la reprise après des variations du réseau.
Effectuez les mesures sur des téléphones, des navigateurs, des téléviseurs, des réseaux d’entreprise, des réseaux Wi-Fi domestiques et des connexions mobiles représentatifs. Distinguez le démarrage à froid de l’écart par rapport au point courant du direct en régime stable. Consignez les interruptions de lecture, les changements de qualité, les images perdues et les erreurs en plus de la latence, car une faible valeur pendant une lecture instable n’est pas un résultat satisfaisant. Testez plusieurs régions et présentez les percentiles pour qu’une moyenne ne masque pas des retards importants occasionnels.
Automatiser l’analyse des marqueurs
Les identifiants d’images lisibles par machine rendent les tests de non-régression répétés plus cohérents que des vérifications manuelles au chronomètre.
Mesurer les temps aller-retour des interactions
Pour les sondages, les enchères et les conversations, incluez la signalisation de l’application et l’accusé de réception du serveur, plutôt que le seul délai vidéo.
Repérer les retards dans l’ensemble du pipeline
Le matériel de capture peut mettre des images en mémoire tampon pour l’exposition, la conversion, la synchronisation ou le traitement d’image. Les encodeurs peuvent ajouter du réordonnancement d’images, de l’analyse anticipée, de longs intervalles entre les images clés ou des files d’attente. Le transport de contribution introduit des délais liés à la propagation, à la récupération des paquets, à la congestion et au routage vers l’ingestion. Le transcodage et l’empaquetage côté serveur créent ensuite des versions encodées et préparent les médias pour la distribution. Optimiser uniquement le lecteur ne peut pas supprimer le retard déjà accumulé en amont.
La distribution et la lecture ajoutent leurs propres files d’attente. La diffusion segmentée traditionnelle peut attendre que les segments soient complets avant de les rendre disponibles, tandis que le CDN met les objets en cache et les transfère. Le lecteur conserve généralement des médias en avance sur la lecture pour faire face à la gigue et aux changements de version encodée. Le décodage et la planification de l’affichage ajoutent un délai qui dépend de l’appareil. Instrumentez les points de passage entre les étapes lorsque c’est possible, puis réglez l’étape qui consomme la plus grande part du budget au lieu de modifier plusieurs variables à la fois.
Vérifier ensemble l’audio et la vidéo
Une mise en mémoire tampon ou une reprise indépendante peut créer des problèmes de synchronisation, même lorsque la latence vidéo seule semble acceptable.
Surveiller la croissance des files d’attente
Une latence qui augmente pendant un programme indique souvent un traitement plus lent que le temps réel, une congestion ou un lecteur qui prend du retard par rapport au point courant du direct.
Choisir une approche de diffusion adaptée à l’interaction
HLS et MPEG-DASH, dans leurs formes classiques, sont des approches adaptatives fondées sur HTTP qui fonctionnent bien avec la distribution par CDN et de vastes écosystèmes de lecteurs, mais les segments complets et les tampons des lecteurs peuvent ajouter du retard. Les variantes à faible latence exposent des parties de média plus petites afin que le transfert puisse commencer avant qu’un segment entier soit complet. Elles nécessitent des encodeurs, des outils de conditionnement, des serveurs d’origine, un comportement du CDN et des lecteurs compatibles. Un seul maillon non pris en charge peut annuler l’amélioration attendue.
WebRTC est conçu pour la communication en temps réel et peut offrir des interactions beaucoup plus réactives, mais la distribution des flux à un large public, l’enregistrement, les statistiques, le comportement des appareils et les coûts diffèrent de ceux d’une diffusion HTTP ordinaire. Les protocoles de contribution tels que SRT assurent un transport fiable depuis un encodeur et ne déterminent pas, à eux seuls, la latence côté spectateur. Choisissez l’architecture complète en fonction de la taille du public, des interactions, de la compatibilité, des besoins de reprise et des capacités d’exploitation, plutôt qu’en fonction de la seule désignation d’un protocole.
Vérifier chaque maillon
La diffusion d’objets partiels, la mise en cache, le comportement des requêtes, les manifestes et la logique du lecteur doivent tous prendre en charge le mode à faible latence choisi.
Prévoir une solution de repli
Définissez si les appareils non pris en charge reçoivent un flux à latence plus élevée, un autre protocole ou un message explicite sur la compatibilité.
Équilibrer mise en mémoire tampon, débit et fiabilité
Un tampon de lecture plus petit rapproche la lecture du point le plus récent du direct, mais protège moins contre les paquets retardés et les variations de débit réseau. Une lecture de rattrapage agressive peut réduire le retard accumulé, mais des changements de vitesse excessifs peuvent nuire à la compréhension ou à la qualité audio. Définissez la dérive maximale, la tolérance aux remises en mémoire tampon et le comportement de reprise. Testez la réaction du lecteur après une mise en arrière-plan sur un téléphone, un changement de réseau ou une pause suivie d’une reprise.
Les réglages de l’encodeur imposent eux aussi des compromis. Des intervalles plus courts entre les images clés peuvent faciliter la segmentation et la reprise, mais réduire l’efficacité de la compression. Les préréglages à faible délai peuvent limiter l’analyse anticipée des images, ce qui augmente le débit à qualité comparable ou réduit la qualité à débit égal. Une échelle de renditions adaptatives plus étendue offre davantage de choix selon le réseau, mais augmente les besoins en capacité d’encodage en temps réel et les coûts d’exploitation. Adaptez cette échelle à la qualité de la source et aux appareils du public.
Ajuster une variable à la fois
Modifiez une seule étape, puis comparez la latence, les interruptions de lecture, la qualité, le débit et la reprise aux mesures de référence.
Définir une politique de reprise
Déterminez quand le lecteur doit rattraper son retard, passer à une version encodée de qualité inférieure, rejoindre le point courant du direct ou demander au spectateur de relancer la lecture.
Adapter les objectifs aux cas d’usage réels
Les entretiens bidirectionnels et le contrôle à distance nécessitent un objectif de latence adapté à la conversation et, souvent, un circuit média en temps réel. Les ventes aux enchères exigent que la vidéo, les offres, leur ordonnancement côté serveur et les retours au présentateur partagent un modèle temporel cohérent. Les démonstrations commerciales peuvent tolérer davantage de retard vidéo si la disponibilité des produits et le chat sont synchronisés. Pour le sport et les événements publics, la stabilité à grande échelle, les sous-titres et la couverture des appareils comptent souvent aussi, en plus de la réduction du délai.
L’accessibilité modifie la manière d’évaluer l’objectif. Les sous-titres en direct et l’interprétation peuvent introduire un délai de traitement, et forcer la vidéo à les devancer peut rendre l’expérience inutilisable pour les spectateurs qui en dépendent. Mesurez la synchronisation des sous-titres et les commandes d’interaction avec la même rigueur que les images. Les contrôles de sécurité, les décisions relatives aux droits d’accès, le délai de modération et le routage régional peuvent aussi ajouter un délai justifié. Ne supprimez pas de protections dans le seul but d’améliorer une mesure de latence.
Synchroniser les états associés
Utilisez des horodatages ou des identifiants de séquence pour les offres, les produits, les sondages, les sous-titres et les réactions afin qu’ils restent cohérents avec une vidéo retardée.
Privilégier un niveau de service stable
Un objectif atteignable de manière constante est plus utile qu’une valeur inférieure obtenue uniquement avec des appareils et des réseaux idéaux.
Tester les défaillances, le passage à l’échelle, la sécurité et les coûts
Effectuez des tests prolongés avec des pertes de paquets, de la gigue, des variations de bande passante, des reconnexions de l’encodeur, des erreurs du CDN, des mises en arrière-plan du lecteur et des perturbations régionales. Observez la détection, le basculement, l’augmentation de la latence, la synchronisation des sous-titres, la continuité de l’enregistrement et le retour au point le plus récent du direct. Les tests de charge doivent distinguer les diffuseurs simultanés des spectateurs simultanés, car ils sollicitent des ressources différentes. Surveillez l’état de l’ingestion, la vitesse d’encodage, les requêtes vers l’origine, le comportement du cache du CDN, les interruptions de lecture et la latence en queue de distribution.
Une latence plus faible peut augmenter la fréquence des requêtes vers l’origine, réduire l’efficacité du cache, nécessiter une infrastructure en temps réel supplémentaire ou compliquer le basculement. Modélisez les coûts d’encodage, d’empaquetage, d’origine, de CDN, de signalisation, de diffusion, d’observabilité et d’assistance en conditions normales et lors des pics de charge. Protégez les informations d’identification pour l’ingestion, autorisez l’accès des spectateurs et appliquez les règles d’accès aux parties de segments média comme aux manifestes. Excluez les points de terminaison d’administration et les URL de flux privés des journaux côté client, et vérifiez que les modes de repli préservent les contrôles d’autorisation.
Inclure les réseaux dégradés dans les critères de mise en production
La faible latence ne doit pas être mise en production sur la seule base de tests réalisés avec une connexion haut débit en laboratoire et des appareils haut de gamme actuels.
Déclencher des alertes selon l’impact sur les spectateurs
Combinez la latence avec le taux d’interruption de lecture, les échecs de lecture, la qualité et la reprise plutôt que de déclencher des alertes d’astreinte sur une seule valeur de configuration.
Distinguer la latence du direct du traitement VOD
Un enregistrement finalisé répond à des objectifs différents de ceux du circuit de diffusion en direct. La VOD peut consacrer davantage de temps à la compression, à la normalisation, aux sous-titres, aux miniatures et aux paquets adaptatifs, car elle n’a plus à suivre le rythme d’un événement en cours. Sa lecture peut démarrer rapidement et permettre des déplacements efficaces dans la vidéo, mais il s’agit de performances de démarrage, et non de latence de la caméra à l’écran en direct. Maintenez des objectifs de service, des tests et des états distincts pour ces circuits.
Transloadit peut préparer des sorties VOD à partir de fichiers, mais ne réduit pas la latence du direct et n’exploite pas de réseau de diffusion à faible latence. Une fois qu’un fournisseur spécialisé dans le direct a finalisé l’enregistrement, une Assembly peut utiliser /video/encode pour créer des versions encodées adaptées et /video/adaptive pour empaqueter les versions encodées regroupées en HLS, MPEG-DASH ou CMAF. /video/thumbs et /speech/transcribe peuvent servir à produire des images d’affiche et des sous-titres. Utilisez ce flux de travail après le direct sans l’intégrer au circuit de diffusion sensible à la latence.
Ne pas comparer des mesures de nature différente
La rapidité de démarrage de la VOD, le temps nécessaire pour terminer le traitement et la latence de la caméra à l’écran en direct mesurent des mécanismes distincts.
Archiver la source mesurée
Associez les résultats des tests de latence aux versions exactes de l’encodeur, de la plateforme, du lecteur, de l’appareil, du réseau et de la configuration pour pouvoir analyser de futures régressions.
Détails techniques à connaître
- Le HLS traditionnel accumule de la latence en raison des segments média complets et de la mise en mémoire tampon du lecteur ; les variantes à faible latence rendent disponibles des segments partiels plus petits pour que la diffusion puisse commencer plus tôt.
- Réduire le tampon du lecteur diminue le délai, mais supprime aussi une protection contre la gigue réseau : le risque de remise en mémoire tampon et la latence sont donc les deux facettes d’un même choix de réglage.
- WebRTC peut atteindre une latence d’interaction bien inférieure à celle du HLS ordinaire, mais la diffusion vers un grand nombre de spectateurs, l’enregistrement, la prise en charge des appareils, l’observabilité et les coûts diffèrent sensiblement pour les publics nombreux.
- Les annonces de latence devraient préciser les points de mesure et les percentiles, car le délai entre la caméra et le démarrage du lecteur, l’écart par rapport au point le plus récent du direct et le temps de réponse aux interactions ne sont pas interchangeables.
- Les réseaux de diffusion de contenu doivent prendre en charge la diffusion d’objets partiels et adopter un comportement de cache adapté au protocole d’empaquetage à faible latence choisi.
- Les préréglages de l’encodeur qui réduisent le délai de compression peuvent augmenter le débit ou réduire l’efficacité, déplaçant ainsi les enjeux de coût et de qualité vers d’autres parties du système.
Une approche pratique
- 1
Définissez l’interaction qui rend le retard perceptible et fixez un budget de latence pour chaque étape.
- 2
Établissez une mesure de référence sur des réseaux et des appareils représentatifs.
- 3
Réglez une étape à la fois en observant les interruptions de lecture, les changements de qualité et la reprise après erreur.
- 4
Gardez le circuit de traitement VOD séparé de la diffusion en direct sensible à la latence.
Quand Transloadit est utile
Pour la VOD, Transloadit peut contrôler la structure d’encodage et empaqueter des sorties adaptatives. Pour la latence du direct, choisissez et configurez une infrastructure spécialisée dans le direct, puis utilisez Transloadit pour l’enregistrement finalisé.
Périmètre architectural
Transloadit peut préparer des fichiers et des paquets adaptatifs pour la lecture à la demande, mais ne réduit pas la latence de bout en bout entre la caméra et l’écran en direct et n’exploite pas de réseau de diffusion à faible latence.
Questions fréquentes
Une latence plus faible améliore-t-elle toujours les performances vidéo ?
Non. Un délai réduit peut améliorer l’interaction, mais des tampons plus petits rendent la lecture plus sensible à la gigue et aux variations de débit. Évaluez la latence en tenant également compte des interruptions, des échecs de lecture, de la qualité, de la synchronisation, du rétablissement, du coût et de l’accessibilité.
Comment mesurer une faible latence dans une application mobile ?
Utilisez à la source un marqueur synchronisé, visuel ou lisible par machine, et comparez-le à l’image affichée sur le mobile. Testez le démarrage à froid et le régime établi sur différents appareils et systèmes d’exploitation, avec des connexions Wi-Fi et cellulaires, lors du passage de l’application en arrière-plan et des changements de réseau.
Pourquoi la latence peut-elle augmenter pendant une diffusion en direct ?
Les files d’attente peuvent s’allonger lorsque l’encodage prend du retard sur le temps réel, que le réseau sature, que le CDN ou le serveur d’origine retarde certaines parties, ou que le lecteur s’éloigne du point le plus récent du direct après une interruption. Les horodatages de chaque étape et la télémétrie du lecteur aident à déterminer où cet allongement commence.
WebRTC est-il toujours le bon choix pour la vidéo à faible latence ?
Non. WebRTC convient bien aux communications interactives, mais la taille du public, la ramification des flux, l’enregistrement, le coût de diffusion, l’observabilité, la prise en charge des appareils et la complexité opérationnelle peuvent rendre préférable une diffusion HTTP à faible latence ou une architecture hybride.
Transloadit peut-il réduire la latence d’un flux en direct ?
Non. Transloadit assure le traitement de fichiers et l’empaquetage adaptatif pour la VOD, mais pas l’ingestion en direct ni la diffusion à faible latence. Utilisez une infrastructure spécialisée dans le direct pour la diffusion, puis traitez son enregistrement finalisé avec Transloadit lorsque des sorties VOD sont nécessaires.