Latence en streaming : pourquoi le direct diffère de la VOD

Accueil — mécanique du streaming — 04/07

La latence en streaming désigne le délai entre un événement qui se produit réellement et son affichage sur l'écran du spectateur. Ce délai, souvent appelé glass-to-glass (de l'objectif de la caméra à l'écran du spectateur), varie énormément selon le type de contenu et les choix techniques faits en amont — de moins d'une seconde pour certains usages interactifs à plusieurs dizaines de secondes pour du direct classique non optimisé.

Pourquoi la VOD tolère une latence qui n'existe pas vraiment

Pour de la vidéo à la demande, la notion de latence glass-to-glass n'a pas vraiment de sens : le contenu existe déjà intégralement avant que le spectateur ne commence sa lecture. Le seul délai pertinent est celui entre le clic sur « lecture » et le premier freeze, un délai que les plateformes réduisent en préchargeant agressivement les premiers segments avant même l'interaction complète de l'utilisateur. Cette absence de contrainte de synchronisation avec un événement réel donne beaucoup plus de latitude : le lecteur peut construire un tampon confortable de plusieurs dizaines de secondes sans aucune conséquence perceptible, ce qui explique pourquoi la VOD tolère mieux les variations de débit que le direct.

Le direct classique : un compromis assumé

Le streaming en direct utilisant HLS ou DASH dans leur configuration standard accumule de la latence à chaque étape de la chaîne : durée des segments (plusieurs secondes chacun), nombre de segments que le lecteur maintient en tampon avant de commencer la lecture (souvent trois segments minimum par prudence), temps de propagation à travers le CDN, et délai d'encodage lui-même. Cumulés, ces facteurs produisent couramment une latence de quinze à trente secondes entre l'événement réel et son affichage — largement suffisant pour qu'un spectateur regardant un match sur un flux découvre un but par les réactions bruyantes de son voisinage avant de le voir à l'écran.

Pour beaucoup de contenus, cette latence reste acceptable : elle ne change rien à l'expérience d'un documentaire ou d'une émission sans enjeu d'interaction en temps réel. Elle devient problématique pour le sport suivi en simultané avec d'autres sources (réseaux sociaux, radio), et rédhibitoire pour tout usage interactif comme les enchères en direct ou le pari sportif synchronisé à l'événement.

Low-latency HLS et Low-latency DASH : réduire sans tout réinventer

Face à cette limite, les extensions Low-Latency HLS (LL-HLS) côté Apple et Low-Latency DASH côté standard ouvert introduisent la notion de chunks CMAF : plutôt que de livrer un segment complet uniquement une fois entièrement encodé, le segment est découpé en fragments plus petits livrés au fur et à mesure de leur disponibilité. Le lecteur peut ainsi commencer à consommer un segment avant qu'il ne soit terminé côté serveur, ce qui réduit mécaniquement la latence accumulée sans changer l'architecture générale de diffusion par segments.

Ces approches ramènent typiquement la latence glass-to-glass dans une fourchette de deux à cinq secondes, un gain significatif par rapport au direct classique tout en conservant la compatibilité générale avec l'écosystème CDN et les lecteurs existants — contrairement à des approches plus radicales qui nécessitent une infrastructure entièrement différente.

WebRTC : la latence minimale, au prix de la scalabilité

Pour les usages exigeant une latence quasi nulle (moins d'une seconde) — visioconférence, jeu en streaming interactif, certains formats d'enchères en direct — WebRTC constitue l'approche de référence. Contrairement au streaming par segments HTTP, WebRTC établit une connexion plus directe entre les participants, sacrifiant une partie de la scalabilité massive permise par le cache CDN au profit d'une réactivité quasi instantanée.

Cette approche ne s'est pas généralisée pour la diffusion vidéo grand public à grande échelle précisément à cause de cette limite de scalabilité : diffuser à quelques dizaines de participants via WebRTC est un problème bien maîtrisé, diffuser à plusieurs millions de spectateurs simultanés avec cette même architecture pose des défis d'infrastructure très différents de ceux résolus par les CDN classiques.

La synchronisation entre spectateurs, un problème à part

Au-delà de la latence absolue par rapport à l'événement réel, un problème distinct se pose pour le direct : la synchronisation entre spectateurs. Deux personnes regardant le même flux en direct peuvent se trouver décalées de plusieurs secondes l'une par rapport à l'autre, selon la variante de qualité qu'elles reçoivent, l'état de leur tampon local ou le nœud CDN qui les sert. Ce décalage devient gênant dès que les spectateurs interagissent en parallèle — un groupe qui commente un match sur un salon vocal découvre alors qu'ils ne voient pas la même action au même instant, une situation que la seule réduction de la latence absolue ne résout pas si elle ne s'accompagne pas d'une synchronisation relative entre spectateurs.

Certaines plateformes traitent ce problème séparément en imposant un tampon minimal identique à tous les spectateurs d'un même flux, sacrifiant volontairement une latence individuelle plus basse au profit d'une expérience de groupe cohérente. C'est un arbitrage produit distinct de la seule course à la latence minimale.

Ce que l'algorithme ABR change à l'équation de la latence

Le streaming adaptatif, qui ajuste la qualité en fonction du débit disponible, entre en tension directe avec la réduction de latence : un tampon plus généreux donne plus de marge à l'algorithme pour lisser les variations de débit sans changer de rendition trop fréquemment, mais un tampon généreux est précisément ce qui augmente la latence glass-to-glass. Les configurations à faible latence doivent donc composer avec une marge de manœuvre ABR plus réduite, ce qui peut se traduire par des changements de qualité plus fréquents ou plus abrupts en cas de variation du réseau, comparé à un flux VOD ou à un direct à latence standard qui dispose d'un tampon plus confortable pour absorber ces variations en douceur.

Ce compromis explique pourquoi un flux en LL-HLS peut paraître légèrement moins stable en qualité qu'un flux classique sur une connexion identique : la réduction de latence se paie en partie par une adaptation moins lissée face aux fluctuations de débit.

Mesurer sa propre latence glass-to-glass

Il est possible d'estimer grossièrement la latence d'un flux en direct sans outil spécialisé : comparer l'heure affichée par une horloge physique visible à l'écran (filmée en direct par la source) avec l'heure à laquelle cette même image apparaît sur l'appareil de réception donne une mesure directe du délai glass-to-glass. Cette méthode reste approximative mais suffit à distinguer un flux à latence standard (quinze secondes ou plus, décalage nettement visible) d'un flux en low-latency (quelques secondes, décalage à peine perceptible sans mesure précise).

Approche	Latence typique	Cas d'usage
HLS/DASH classique	15-30 secondes	Direct grand public sans contrainte d'interaction
LL-HLS / LL-DASH (CMAF)	2-5 secondes	Sport, événements suivis en simultané sur d'autres canaux
WebRTC	< 1 seconde	Interaction temps réel, faible audience simultanée

Cette gestion de la latence s'articule directement avec le streaming adaptatif décrit dans un autre dossier : les segments plus courts qui permettent une latence réduite sont aussi ceux qui permettent une adaptation de qualité plus réactive, deux bénéfices liés à la même décision technique.