Accueil — mécanique du streaming — 01/07
Quand un lecteur vidéo bascule de la 1080p à la 480p en pleine lecture sans interrompre le flux, ce n'est pas un hasard ni un défaut : c'est le mécanisme central du streaming adaptatif (ABR, adaptive bitrate streaming), dont les deux implémentations dominantes sont HLS (HTTP Live Streaming, développé par Apple) et MPEG-DASH (Dynamic Adaptive Streaming over HTTP, standard ISO/IEC ouvert). Les deux suivent le même principe général avec des différences de format.
Le principe : plusieurs variantes, un choix continu
À l'encodage, une même vidéo source est déclinée en plusieurs renditions — des combinaisons de résolution et de débit, par exemple 1080p à 5 Mbit/s, 720p à 2,5 Mbit/s, 480p à 1 Mbit/s. Chaque rendition est découpée en segments de courte durée, généralement entre deux et dix secondes selon la configuration. Le lecteur ne télécharge jamais l'intégralité d'une rendition : il récupère segment par segment, et peut changer de rendition à chaque nouvelle requête sans que cela soit perceptible pour peu que les points de découpe soient alignés entre les différentes variantes.
Ce choix de rendition est piloté par un algorithme ABR qui tourne côté client, dans le lecteur lui-même. Il mesure en continu deux signaux principaux : le débit effectif obtenu lors du téléchargement des derniers segments, et le niveau de remplissage du tampon local (combien de secondes de vidéo sont déjà téléchargées et prêtes à être jouées). Si le débit mesuré dépasse largement celui de la rendition en cours et que le tampon se remplit facilement, l'algorithme monte en qualité ; si le tampon se vide ou que le débit chute, il redescend avant que la lecture ne s'interrompe complètement. Cette logique explique pourquoi une chute brève de débit provoque souvent une baisse de qualité plutôt qu'une coupure : le lecteur préfère anticiper.
Le manifeste : la carte des variantes disponibles
Pour savoir quelles renditions existent et où trouver leurs segments, le lecteur s'appuie sur un fichier manifeste, téléchargé avant même le premier segment vidéo. En HLS, ce manifeste est un fichier texte au format .m3u8 qui liste les variantes disponibles (playlist principale) puis, pour chacune, la liste ordonnée de ses segments (playlist média). En DASH, l'équivalent est un fichier XML au format .mpd (Media Presentation Description), structurellement plus riche mais fonctionnellement proche.
Le manifeste principal contient typiquement, pour chaque rendition, sa résolution, son débit cible et l'URL du sous-manifeste correspondant. C'est cette structure qui rend le changement de qualité possible sans redemander d'information au serveur à chaque bascule : le lecteur a déjà toute la carte en main dès le départ, et ne fait qu'y naviguer selon ses propres mesures.
Segments courts ou longs : un compromis, pas un détail
La durée des segments n'est pas un paramètre neutre. Des segments courts (deux à quatre secondes) permettent une adaptation plus fine et plus réactive : le lecteur peut changer de rendition plus souvent et récupérer plus vite d'une chute de débit. Mais ils multiplient aussi le nombre de requêtes HTTP nécessaires, ce qui augmente la charge sur les serveurs et peut introduire une latence supplémentaire liée à l'établissement de chaque connexion. Des segments plus longs (huit à dix secondes) réduisent cette charge mais rendent l'adaptation plus lente à réagir — un changement de rendition ne prend effet qu'au segment suivant, donc jusqu'à dix secondes plus tard dans le pire cas.
Les plateformes ajustent ce paramètre selon leur priorité : le direct à faible latence tend vers des segments courts (voir le dossier sur la latence), tandis que la vidéo à la demande peut se permettre des segments plus longs sans impact perceptible, le spectateur disposant généralement d'un tampon plus confortable en VOD.
HLS et DASH : convergence plus que rivalité
Historiquement, HLS était associé à l'écosystème Apple (obligatoire pour toute application iOS diffusant de la vidéo) et DASH à un usage plus large côté web et Android. Cette frontière s'est nettement estompée avec l'adoption de CMAF (Common Media Application Format), un format de segment unique que HLS et DASH peuvent tous deux référencer depuis leurs manifestes respectifs. Une plateforme peut ainsi encoder ses segments une seule fois au format CMAF et générer ensuite un manifeste HLS pour les clients Apple et un manifeste DASH pour les autres, sans dupliquer l'encodage vidéo lui-même — un gain d'infrastructure significatif par rapport à l'époque où les deux formats nécessitaient des chaînes de production distinctes.
Différences pratiques entre HLS et DASH
| Aspect | HLS | DASH |
|---|---|---|
| Format du manifeste | Texte (.m3u8) | XML (.mpd) |
| Origine | Apple | Standard ISO/IEC ouvert |
| Support natif | Obligatoire sur iOS/Safari | Large sur Android et navigateurs desktop |
| Codecs supportés en spécification | Historiquement H.264/HEVC | Agnostique au codec (AV1, VP9 compris) |
| DRM associé le plus courant | FairPlay | Widevine, PlayReady |
Cette agnosticité de DASH vis-à-vis du codec explique en partie sa popularité pour diffuser de l'AV1 ou du VP9, deux codecs sans lien avec l'écosystème Apple. Un service qui vise une large compatibilité d'appareils finit souvent par générer les deux types de manifestes en parallèle plutôt que de choisir l'un contre l'autre, précisément grâce à la mutualisation permise par CMAF.
Le rôle du buffer côté lecteur
Le tampon (buffer) local mérite un mot à part, car il conditionne directement la marge de manœuvre de l'algorithme ABR. Un tampon de trente secondes de vidéo déjà téléchargée offre une marge confortable : même si le débit chute brutalement pendant quelques secondes, le lecteur peut continuer à jouer les segments déjà en réserve tout en réévaluant la rendition à demander pour la suite. Un tampon réduit à quelques secondes, en revanche, laisse beaucoup moins de marge et augmente le risque qu'une chute de débit se traduise directement par une interruption visible, quelle que soit la qualité de l'algorithme ABR utilisé.
La taille du tampon cible est un choix de configuration côté plateforme, pas une caractéristique universelle du streaming adaptatif. Un service qui privilégie la réactivité (changement rapide de chaîne, contenu très interactif) tend à limiter la taille du tampon ; un service centré sur la vidéo à la demande longue peut se permettre un tampon plus généreux sans que cela ne coûte grand-chose à l'expérience, l'utilisateur ne changeant pas de contenu aussi fréquemment.
Ce qui échappe encore à l'algorithme ABR
Aussi sophistiqué soit-il, un algorithme ABR ne mesure que ce qui se passe entre le serveur (ou le nœud CDN) et le lecteur : il ne sait rien de ce qui cause une variation de débit. Une chute peut venir d'une congestion sur le réseau local, d'une saturation du CDN à un nœud donné, ou d'une limitation imposée par un fournisseur d'accès sur un type de trafic. L'algorithme réagit au symptôme (le débit mesuré) sans distinguer la cause, ce qui explique pourquoi deux utilisateurs avec le même abonnement peuvent vivre une expérience très différente selon l'état du réseau qu'ils traversent réellement à un instant donné — y compris entre deux sessions sur le même appareil, à quelques heures d'écart, si les conditions de congestion locales ont changé.
Le streaming adaptatif ne rend pas une connexion plus rapide : il évite qu'une connexion instable ne se traduise par des coupures, en sacrifiant de la qualité plutôt que de la continuité. Une connexion durablement insuffisante reste durablement limitée en qualité, quel que soit l'algorithme ABR utilisé côté lecteur.
Le dossier suivant détaille les codecs vidéo utilisés pour produire ces renditions, dont le choix influence directement le débit nécessaire pour une qualité donnée — et donc la fréquence à laquelle l'algorithme ABR doit réellement descendre en résolution.