La latence en live : le seul chiffre qui compte

Les discussions techniques autour d'un direct tournent presque toujours autour du débit, parfois autour du codec, rarement autour de la latence — jusqu'au jour où quelqu'un dans la salle constate que l'écran de retour affiche l'orateur avec quarante secondes de retard, ou qu'une question posée en ligne arrive alors que le sujet est clos depuis longtemps. La latence est le seul paramètre qui se remarque immédiatement quand il est mauvais et que personne ne mesure quand il est bon.

Elle a aussi la particularité de ne pas être une propriété du protocole que l'on choisit, contrairement à ce que laissent entendre les tableaux comparatifs qui circulent. La latence est une somme, et chaque maillon de la chaîne y contribue avec une marge de manœuvre différente. Comprendre où elle s'accumule vaut mieux que mémoriser un chiffre par acronyme.

Une somme, pas une caractéristique

Le forum DASH Industry a publié la seule décomposition normative réellement citable, sous un nom qui ne s'invente pas : la hand-waving latency, la latence qu'on mesure en agitant la main devant la caméra et en regardant l'écran. Elle est définie comme le délai accumulé entre un geste effectué devant l'objectif et le moment où il devient visible chez un spectateur, et elle s'additionne en six termes : le temps que met l'encodeur à produire un segment, le temps d'envoi de ce segment vers le serveur d'origine, le temps de récupération par le serveur de périphérie, le temps de récupération par le lecteur, la distance à laquelle le lecteur choisit de se placer en retrait du point de diffusion, et enfin le temps de remplissage de son tampon avant que la lecture ne démarre.

Le document ajoute une précision qui contient à elle seule l'essentiel du sujet : pour les quatre premières étapes, en transfert HTTP non fragmenté, le délai est une fonction linéaire de la durée du segment. Autrement dit, tant qu'on transporte des segments entiers, allonger le segment allonge mécaniquement la latence à quatre endroits distincts de la chaîne. C'est la raison pour laquelle toutes les techniques de réduction de latence commencent par découper plus fin.

Pourquoi le HLS classique traîne autant

La spécification d'Apple destinée aux auteurs de flux recommande une durée de segment nominale de six secondes et des images clés toutes les deux secondes. Elle impose surtout, par l'attribut HOLD-BACK, que le lecteur ne démarre pas plus près du point de diffusion qu'une distance d'au moins trois fois la durée cible de segment, l'absence de l'attribut impliquant précisément cette valeur. Le calcul se fait tout seul : trois segments de six secondes, soit dix-huit secondes de retard côté lecteur, avant même d'avoir compté l'encodage, la remontée vers l'origine et la distribution.

Amazon formulait ce même calcul dès 2019 en notant qu'un tampon d'avance de dix-huit secondes est très confortable pour la stabilité de lecture et catastrophique pour la latence, et situait la latence d'une chaîne HLS classique entre quarante et soixante secondes, parfois davantage, à comparer aux huit à dix secondes d'une diffusion télévisée traditionnelle. Le forum DASH Industry, de son côté, relève que les mesures sur les réseaux de diffusion classiques convergent plutôt vers trois à dix secondes entre acquisition et affichage.

Ces écarts ne sont pas des contradictions mais des périmètres différents, et ils illustrent le principal piège du sujet : aucun de ces chiffres ne vient d'une norme. Les spécifications normalisent des paramètres — durée de segment, retrait minimal, taille de tampon, multiplicateur — et jamais une latence bout en bout. Tout tableau qui annonce « HLS : 45 secondes, WebRTC : 0,5 seconde » est une synthèse commerciale, pas une mesure.

Ce que LL-HLS change, et ce qu'il exige en retour

Le HLS à faible latence conserve les segments mais les découpe en parties. La règle de retrait s'applique alors à ces parties plutôt qu'aux segments, et le rapport de trois se reporte sur une unité beaucoup plus courte. Apple recommande une durée de partie d'une seconde et impose que la valeur de PART-HOLD-BACK vaille au moins trois fois cette durée, ce qui ramène le retrait du lecteur à trois secondes environ. Il faut signaler, parce que les deux documents émanent du même éditeur, que la version IETF de la spécification est légèrement plus permissive et n'impose que le double, en recommandant le triple.

Ce gain se paie en contraintes. Apple exige que la durée de partie soit au moins égale au temps d'aller-retour réseau que subissent 95 % des clients, et recommande qu'elle en vaille trois fois autant : un public géographiquement dispersé impose donc des parties plus longues, donc une latence plus élevée, ce qui n'a rien d'un réglage libre. Cloudflare, qui annonce une latence inférieure à trois secondes de bout en bout sur son offre, impose en contrepartie un intervalle d'images clés d'une seconde et le codec H.264.

Cet intervalle d'images clés est d'ailleurs le paramètre le plus sous-estimé de toute la chaîne. Amazon quantifie son effet sans détour : deux secondes d'intervalle produisent une latence de démarrage de l'ordre de six à sept secondes, une seconde la ramène à trois ou quatre, et au-delà de cinq secondes le service déconseille la configuration. Le revers existe, et il est documenté : des images clés très rapprochées multiplient les décisions d'adaptation du lecteur et augmentent le risque de rebuffering.

La segmentation en fragments CMAF permet d'échapper partiellement à cet arbitrage, puisqu'un fragment n'est pas tenu de commencer par un point d'accès aléatoire, contrairement à un segment. On peut donc réduire la granularité du transport sans raccourcir les groupes d'images ni perdre en efficacité de codage. Le forum DASH Industry précise même que, lorsque les frontières de fragment sont correctement placées, l'empaquetage n'ajoute pas de délai au-delà du réordonnancement propre à l'encodeur, soit de l'ordre de cent soixante à deux cents millisecondes à vingt-cinq images par seconde.

SRT : une latence qu'on règle, pas qu'on subit

SRT est régulièrement rangé dans les tableaux comparatifs avec une valeur de latence, ce qui est un contresens : SRT ne définit pas une latence, il définit un budget que l'on configure. Le paramètre porte ce nom, il est borné — la documentation de Haivision indique une plage allant jusqu'à huit secondes, avec une divergence sur la borne basse entre les documents, de vingt à quatre-vingts millisecondes selon la version consultée — et sa valeur par défaut dans la bibliothèque de référence est de cent vingt millisecondes. Lorsque les deux extrémités ont des réglages différents, c'est la plus élevée des deux valeurs qui s'applique.

Ce budget sert à une chose précise : donner le temps nécessaire aux retransmissions. SRT détecte les paquets manquants et les redemande, et la latence configurée détermine combien de tentatives sont possibles avant que le paquet ne soit de toute façon trop tard. D'où la règle de dimensionnement officielle, qui est un multiple du temps d'aller-retour : Haivision recommande, sur un réseau de bonne qualité présentant 0,1 à 0,2 % de perte sans rafale, un multiplicateur d'environ quatre.

Deux tableaux de multiplicateurs circulent dans la documentation du même éditeur, et l'écart mérite d'être expliqué plutôt que masqué : l'un modélise une perte constante, l'autre une perte en rafale, et le surcoût de bande passante se calcule différemment dans les deux cas. Le guide de déploiement pose par ailleurs deux garde-fous utiles : ce surcoût ne devrait pas dépasser 50 %, sa valeur par défaut étant de 25 %, et la latence configurée doit toujours excéder la durée de la pire rafale de pertes attendue, faute de quoi le flux présentera des artefacts. La formule qui résume le protocole tient en une phrase de leur documentation : une transmission SRT a besoin soit de bande passante, soit de temps.

RIST, son concurrent normalisé par la Video Services Forum, fonctionne sur le même principe sans publier davantage de latence bout en bout : la recommandation technique se contente de suggérer, à titre informatif, un tampon de réception d'une seconde et une fenêtre de réordonnancement de soixante-dix millisecondes.

WebRTC, où la latence cesse d'être le problème

En dessous de la seconde, la question change de nature. Les plateformes gérées annoncent des valeurs très basses — Cloudflare évoque moins de cinq cents millisecondes sur son offre WHIP/WHEP, Amazon moins de trois cents sur la sienne — et le débat se déplace vers la distribution.

Les quotas publiés le montrent mieux que n'importe quelle analyse. Sur le service temps réel d'Amazon, le nombre de diffuseurs par scène est plafonné à douze et ce plafond n'est pas ajustable, la résolution de publication est limitée à 720p, le débit par participant à 8,5 Mb/s, et la durée d'une session à vingt-quatre heures ; le nombre de spectateurs, lui, est ajustable jusqu'à dix mille. Cette asymétrie décrit exactement le modèle : un serveur de routage maintient une session média par spectateur, là où un réseau de diffusion HTTP sert un objet mis en cache à une audience de taille arbitraire.

Il faut cependant noter que les plafonds varient fortement d'un opérateur à l'autre, Cloudflare annonçant pour sa part n'imposer aucune limite fixe de spectateurs simultanés tout en ne proposant ni enregistrement ni comptage d'audience en direct. Aucun de ces deux acteurs n'est une source neutre, et il n'existe pas de comparaison de coût publiée avec une méthodologie vérifiable : c'est un domaine où il vaut mieux mesurer sur son propre cas que citer un ratio.

Quelle latence pour quel usage

La seule référence normative disponible sur le seuil perceptif concerne la conversation, et elle est ancienne autant que solide. La recommandation G.114 de l'UIT-T fixe pour la planification générale des réseaux un délai à ne pas dépasser de quatre cents millisecondes dans un seul sens, note que les tâches fortement interactives peuvent être affectées dès cent millisecondes, et conclut que sous cent cinquante millisecondes l'interactivité reste essentiellement transparente pour la plupart des applications. Il faut lire ce document avec précision : il mesure un trajet dans un seul sens, pas un aller-retour, et il vise la conversation, pas la diffusion.

Pour un événement d'entreprise diffusé à sens unique, la contrainte n'est pas conversationnelle et les ordres de grandeur documentés sont plus généreux : le forum DASH Industry situe les exigences de délai de démarrage entre une et deux secondes, relève que les services visent typiquement un changement de chaîne en une seconde, et retient pour un flux d'accompagnement une cible de latence bout en bout d'au moins cinq secondes. Dès qu'une voie de retour existe — questions du public, vote en direct —, le même document estime que la réponse doit rester en deçà de cinq secondes pour ne pas être perçue comme gênante.

Le cas des paris et des enchères en direct est celui où les sources sérieuses manquent le plus, et il vaut mieux le dire : aucune norme ni aucun texte réglementaire consulté ne chiffre une latence maximale pour ces usages. Le vrai problème y est d'ailleurs moins la latence absolue que l'écart entre spectateurs, puisqu'un pari doit être clos avant que le plus rapide d'entre eux n'ait vu l'action. Le forum DASH Industry documente le canal de fuite le plus souvent négligé, en estimant à environ cinq secondes le délai entre un événement et sa notification sur un réseau social, pour un délai de diffusion télévisée de sept à douze secondes aux États-Unis : le spoiler ne vient pas du voisin, il vient du téléphone.

Questions fréquentes

Peut-on réduire la latence sans changer de protocole ?

Oui, et c'est souvent le premier levier. Raccourcir l'intervalle d'images clés produit un effet mesurable sur le délai de démarrage, réduire la durée des segments agit linéairement sur quatre étapes de la chaîne, et abaisser la durée de vie des manifestes en cache évite qu'un serveur de périphérie ne serve une liste périmée. Ces trois réglages se font sans toucher à l'architecture.

Une latence plus faible dégrade-t-elle la stabilité ?

Elle réduit la marge dont dispose le lecteur pour absorber un incident réseau, ce qui est la définition même du tampon. Amazon signale explicitement qu'un intervalle d'images clés très court multiplie les décisions d'adaptation et augmente le risque d'interruption. La bonne latence n'est donc pas la plus basse atteignable, mais la plus basse que la qualité de la liaison permette de tenir sans interruption.

Faut-il régler la latence SRT au plus bas ?

Non : une latence SRT inférieure à la durée de la pire rafale de pertes garantit des artefacts, puisque les retransmissions arriveront après l'échéance de lecture. La règle documentée consiste à partir d'environ quatre fois le temps d'aller-retour sur une liaison de bonne qualité, puis à augmenter si les pertes surviennent en rafale.

Pourquoi les tableaux comparatifs de latence se contredisent-ils autant ?

Parce qu'ils mesurent des choses différentes sans le dire, et qu'aucun ne s'appuie sur une norme. Certains comptent à partir de l'encodeur, d'autres depuis le capteur ; certains incluent le tampon du lecteur, d'autres s'arrêtent à la sortie du réseau de diffusion ; et la plupart émanent d'éditeurs qui commercialisent l'une des technologies comparées. Les spécifications, elles, ne normalisent que des paramètres.

Sources

• DASH-IF et DVB, Report on Low-Latency Live Service with DASH — décomposition de la latence bout en bout et cas d'usage.
• DASH-IF, CR: Low-latency Modes for DASH, révision 8, 27 mars 2020 — fragments CMAF, latences cibles.
• Apple, HLS Authoring Specification for Apple Devices (révision du 26 juin 2025) — durée de segment, images clés, PART-HOLD-BACK.
• R. Pantos (Apple), HTTP Live Streaming 2nd Edition, draft-pantos-hls-rfc8216bis-19, IETF, 9 janvier 2026 — HOLD-BACK et PART-HOLD-BACK.
• Haivision, documentation SRT 1.5.3 (pages Latency et RTT Multiplier) et SRT Deployment Guide v1.1 ; bibliothèque libsrt, options de socket.
• Video Services Forum, TR-06-1:2020 — profil simple RIST.
• AWS, blog Media & Entertainment (26 juin 2019) et documentation Amazon IVS — intervalle d'images clés, quotas du service temps réel.
• Cloudflare, Stream Low-Latency HLS (25 septembre 2023) et documentation WebRTC.
• UIT-T, recommandation G.114 (05/2003), One-way transmission time.

Pour aller plus loin

Dans le prolongement de cet article :

• Réussir un live streaming : encodeur, bitrate, latence et plateformes — les réglages qui font tenir un direct de bout en bout
• Streaming live professionnel : le guide complet — la chaîne complète, du signal source au spectateur
• Choisir protocole de streaming SRT, RTMP WebRTC — l'outil de décision entre SRT, RTMP et WebRTC