HLS, DASH et la lecture adaptative : ce qui se passe pendant que vous regardez

Quand vous lancez une vidéo en ligne, vous ne recevez pas un fichier. Vous recevez une liste, puis une succession de petits morceaux choisis un par un, en temps réel, par un algorithme qui parie sur les quelques secondes à venir. Comprendre ce mécanisme explique la plupart des comportements qu'on trouve agaçants sans savoir à quoi les attribuer.

Le manifeste

Tout commence par un fichier texte: une liste de lecture en HLS, une description de présentation en DASH. Les deux formats diffèrent dans leur syntaxe et leur histoire — l'un vient d'Apple, l'autre est une norme ouverte — mais décrivent la même chose: quelles versions du contenu existent, à quels débits, dans quelles résolutions, et où trouver les morceaux de chacune.

Ces versions forment ce qu'on appelle l'échelle de débits. Le même contenu est encodé plusieurs fois, typiquement de quelques centaines de kilobits par seconde jusqu'à plusieurs mégabits, chaque barreau visant une combinaison de résolution et de qualité. Construire cette échelle est un métier en soi: trop de barreaux gaspille du stockage et de l'encodage, trop peu produit des sauts de qualité brutaux et visibles.

Les segments

Chaque version est découpée en segments de durée fixe, souvent deux à six secondes. Le point essentiel est que tous les barreaux sont découpés aux mêmes instants, et que chaque segment commence par une image complète et autonome. C'est ce qui rend le passage d'une qualité à l'autre possible: le lecteur peut terminer un segment en haute qualité et enchaîner sur le suivant en qualité réduite sans rien casser.

La durée des segments est un compromis direct. Des segments courts permettent de réagir vite à une variation de débit et réduisent le délai en direct, mais multiplient les requêtes et dégradent l'efficacité de compression, puisque chaque segment redémarre sur une image complète coûteuse. Des segments longs font l'inverse. La plupart des services se rangent entre deux et six secondes selon qu'ils privilégient la latence ou l'efficacité.

La décision, segment par segment

Avant chaque téléchargement, le lecteur choisit un barreau. Il dispose de deux informations: le débit qu'il a effectivement obtenu sur les segments précédents, et la quantité de vidéo déjà en réserve dans son tampon.

Les premiers algorithmes ne regardaient que le débit mesuré. C'est intuitif et c'est instable: une mesure prise sur quelques secondes est très bruitée, et le lecteur oscille entre deux qualités, produisant l'effet de scintillement que tout le monde a déjà vu. Les approches suivantes ont déplacé la décision vers l'occupation du tampon: tant que la réserve est confortable, on tente un barreau supérieur; quand elle fond, on descend, quelle qu'ait été la mesure de débit. C'est plus stable, parce que le tampon intègre naturellement l'historique.

Les lecteurs modernes combinent les deux, avec des règles asymétriques assumées: on descend rapidement et on remonte prudemment. Une descente tardive coûte un gel de l'image, ce que le spectateur remarque immédiatement; une remontée tardive coûte quelques secondes de qualité moindre, ce qu'il ne remarque presque pas.

Le tampon, et pourquoi le démarrage est lent

Le lecteur ne peut pas afficher la première image dès qu'il l'a reçue: il lui faut une réserve suffisante pour survivre au prochain creux de débit. Cette réserve est ce qui rend le démarrage perceptible.

D'où une tension permanente. Un gros tampon protège des interruptions mais allonge le démarrage et, en direct, augmente le retard sur l'action réelle — plusieurs dizaines de secondes dans les cas les moins soignés, ce qui devient inacceptable quand les voisins crient un but avant vous. Un petit tampon fait l'inverse. Beaucoup de services démarrent volontairement sur un barreau bas pour remplir le tampon vite, puis montent en qualité une fois la réserve constituée. C'est pourquoi les premières secondes sont souvent floues.

Ce qui casse en pratique

Trois causes reviennent constamment. Une échelle de débits mal construite, où l'écart entre deux barreaux est trop grand: chaque changement se voit. Un réseau domestique qui n'est pas lent mais irrégulier, ce qui est bien pire pour un algorithme qui essaie d'estimer une tendance. Et des segments dont la durée réelle ne correspond pas à ce que le manifeste annonce, ce qui fausse tous les calculs de réserve du lecteur.

La leçon que j'en tire est que le débit brut est un mauvais indicateur de qualité perçue. Un lien de cinq mégabits stable donne une bien meilleure expérience qu'un lien de vingt mégabits qui s'effondre trois fois par minute. C'est la régularité qui compte, pas le maximum.