HLS streaming adaptatif : guide complet pour le live et la VOD

Qu’est-ce que HLS et pourquoi domine-t-il ?

HLS (HTTP Live Streaming) est le protocole de streaming le plus largement déployé sur la planète. Créé par Apple en 2009, il diffuse la vidéo sur une infrastructure HTTP standard, ce qui signifie qu’il fonctionne avec chaque CDN, chaque serveur web, chaque proxy et chaque pare-feu existant sans configuration spéciale.

Le protocole est simple dans son concept : l’encodeur découpe la vidéo en petits fichiers (segments), écrit un fichier de playlist (manifeste) qui liste ces segments, et le lecteur télécharge les segments séquentiellement tout en les lisant. Comme tout repose sur du HTTP standard, toute l’infrastructure CDN mondiale construite pour la diffusion de contenu web fonctionne pour le HLS nativement.

Pour le streaming en direct et la vidéo à la demande, HLS offre trois capacités qui comptent le plus :

1. Débit adaptatif (ABR) : plusieurs niveaux de qualité, le lecteur sélectionnant automatiquement le meilleur pour la connexion du spectateur
2. Scalabilité massive : la mise en cache HTTP à chaque couche (périphérie CDN, cache FAI, navigateur) permet des millions de spectateurs simultanément
3. Compatibilité universelle : iOS, Android, macOS, Windows, Linux, Smart TV, consoles de jeux — HLS fonctionne partout

Ce guide couvre la configuration de HLS pour le streaming en direct et la VOD, avec des configurations spécifiques pour les échelles de débit adaptatif, le réglage des segments, l’intégration CDN et les modes basse latence.

Comment HLS fonctionne sous le capot

Comprendre la mécanique vous aide à prendre de meilleures décisions de configuration.

La playlist maître

La playlist maître (souvent appelée playlist multivariante) est le point d’entrée. Elle liste tous les niveaux de qualité disponibles (rendus) :

#EXTM3U
#EXT-X-VERSION:6

#EXT-X-STREAM-INF:BANDWIDTH=6000000,RESOLUTION=1920x1080,FRAME-RATE=60.000,CODECS="avc1.640028,mp4a.40.2"
1080p60/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=3000000,RESOLUTION=1280x720,FRAME-RATE=30.000,CODECS="avc1.4d401f,mp4a.40.2"
720p30/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=1500000,RESOLUTION=854x480,FRAME-RATE=30.000,CODECS="avc1.4d401e,mp4a.40.2"
480p30/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=600000,RESOLUTION=640x360,FRAME-RATE=30.000,CODECS="avc1.42c015,mp4a.40.2"
360p30/index.m3u8

Le lecteur lit cette playlist, estime la bande passante disponible et sélectionne le rendu approprié. À mesure que les conditions réseau changent, le lecteur commute entre les rendus de manière transparente.

Playlists média

Chaque rendu possède sa propre playlist média listant les segments vidéo réels :

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:1547

#EXTINF:4.000,
segment-1547.ts
#EXTINF:4.000,
segment-1548.ts
#EXTINF:4.000,
segment-1549.ts

Pour les flux en direct, la playlist est une fenêtre glissante : les anciens segments sont supprimés à mesure que de nouveaux sont ajoutés. Le lecteur reste près du “bord live” (les segments les plus récents).

Pour la VOD, la playlist contient tous les segments et inclut la balise #EXT-X-ENDLIST pour indiquer que le contenu est complet.

Fichiers de segments

Les segments sont les données média réelles, généralement au format conteneur MPEG-TS (.ts) ou MP4 fragmenté (.m4s). Chaque segment contient un morceau autonome de vidéo et audio :

• Segments MPEG-TS : le format traditionnel. Chaque segment commence par un PAT/PMT et peut être lu indépendamment. Largement compatible.
• Segments fMP4 : le format moderne. Plus efficace (moins de surdébit par segment), supporte des fonctionnalités comme CMAF et HEVC dans HLS. Requis pour HLS avec HEVC ou le HLS basse latence.

Concevoir votre échelle de débit adaptatif

L’échelle de débit définit les niveaux de qualité que vous proposez aux spectateurs. Une échelle bien conçue offre une bonne qualité pour les connexions rapides et une qualité utilisable pour les connexions lentes, sans gaspiller de bande passante sur des rendus que personne n’utilisera.

Échelle de débit recommandée

Pour le streaming en direct polyvalent (sport, événements, divertissement) :

Principes de conception de l’échelle

1. Écart minimum de 1,5x entre les rendus. Si deux rendus ont des débits trop proches, le lecteur oscillera entre eux sur les connexions marginales, provoquant des changements de qualité visibles. Un écart de 1,5x donne à l’algorithme ABR une frontière de décision claire.

2. Incluez toujours un rendu à bas débit. Le rendu 240p ou 360p sert les spectateurs sur des connexions très lentes (cellulaire 2G, Wi-Fi congestionné). Sans ce rendu, ces spectateurs subissent de la mise en tampon au lieu d’une lecture en basse qualité.

3. Faites correspondre le rendu supérieur à la qualité de votre source. Il n’y a aucun avantage à proposer un rendu 4K si votre source est en 1080p. Le rendu supérieur doit correspondre à la résolution et à la fréquence d’images de votre source.

4. Considérez votre budget d’encodage. Chaque rendu nécessite un encodage séparé. Six rendus signifient six encodages simultanés. Avec le transcodage matériel (Intel QSV), c’est gérable. Avec l’encodage logiciel, cela peut nécessiter un serveur puissant. Consultez le guide de configuration serveur de streaming pour le dimensionnement matériel.

Paramètres d’encodage par rendu

Pour l’encodage H.264 de chaque rendu :

# Rendu 1080p60
-c:v h264_qsv -b:v 5500k -maxrate 6000k -bufsize 11000k
-profile:v high -level 4.2 -g 120 -keyint_min 120
-c:a aac -b:a 192k -ar 48000

# Rendu 720p30
-c:v h264_qsv -b:v 2000k -maxrate 2200k -bufsize 4000k
-profile:v main -level 3.1 -g 60 -keyint_min 60
-c:a aac -b:a 128k -ar 48000

# Rendu 480p30
-c:v h264_qsv -b:v 1000k -maxrate 1100k -bufsize 2000k
-profile:v main -level 3.0 -g 60 -keyint_min 60
-c:a aac -b:a 96k -ar 48000

Critique : alignement des images clés. Tous les rendus doivent produire des images clés aux mêmes intervalles exacts (toutes les 2 ou 4 secondes). Des images clés désalignées provoquent des problèmes de lecture lorsque le lecteur commute entre les rendus. Définissez -g (taille du GOP) sur la fréquence d’images multipliée par la durée du segment.

Durée des segments : le compromis latence vs. fiabilité

La durée des segments est le paramètre de configuration HLS le plus impactant. Elle contrôle directement à la fois la latence et la fiabilité.

Comment la durée des segments affecte la latence

La latence théorique minimale pour le HLS standard est :

Latence minimale = (duree_segment × profondeur_playlist) + delai_reseau + tampon_lecteur

Avec des segments de 6 secondes et une profondeur de playlist de 3 :

Latence minimale = (6 × 3) + 1 + 2 = ~21 secondes

Avec des segments de 2 secondes et une profondeur de playlist de 3 :

Latence minimale = (2 × 3) + 1 + 2 = ~9 secondes

Des segments plus courts signifient une latence plus faible.

Comment la durée des segments affecte la fiabilité

Les segments plus courts ont des inconvénients :

• Plus de requêtes HTTP par seconde : le lecteur et le CDN doivent gérer plus de requêtes, ce qui augmente le surdébit et le risque de manquer un segment
• Encodage moins efficace : des segments plus courts signifient plus d’images clés par rapport au contenu, réduisant l’efficacité de compression
• Plus sensible à la gigue réseau : une brève perturbation réseau a plus de chances de retarder un segment court au-delà de son échéance

Durées de segments recommandées

Pour la plupart du streaming en direct, des segments de 4 secondes avec une profondeur de playlist de 3 à 5 segments offrent un bon équilibre. Pour le sport et les autres contenus sensibles à la latence, utilisez des segments de 2 secondes et acceptez les compromis.

Configurer la sortie HLS dans Vajra Cast

Vajra Cast inclut un serveur HLS intégré capable de générer des flux adaptatifs directement, sans nécessiter de serveur média séparé.

Sortie HLS basique

Pour créer une sortie HLS à partir d’une ingestion existante :

1. Créez une nouvelle sortie et sélectionnez HLS comme protocole
2. Configurez la durée des segments (défaut : 4 secondes)
3. Définissez la profondeur de playlist (défaut : 3 segments)
4. Choisissez le passthrough (sans transcodage) ou sélectionnez des profils d’encodage pour une sortie adaptative

Pour une sortie HLS à rendu unique (pas de débit adaptatif), le flux est servi directement depuis l’ingestion sans transcodage :

Entrée (SRT 1080p60 8 Mbps) → Sortie HLS (passthrough)
Disponible à : http://votre-serveur:port/hls/nom-du-flux/index.m3u8

HLS adaptatif multi-rendus

Pour une sortie à débit adaptatif, configurez plusieurs rendus sur la même sortie HLS. Vajra Cast crée automatiquement la playlist maître et les playlists média par rendu :

1. Créez la sortie HLS
2. Ajoutez les rendus :
   • 1080p60 à 5 500 Kbps (transcodage matériel)
   • 720p30 à 2 000 Kbps (transcodage matériel)
   • 480p30 à 1 000 Kbps (transcodage matériel)
   • 360p30 à 500 Kbps (transcodage matériel)
3. Activez la sortie

Avec le transcodage matériel Intel QSV, quatre rendus depuis une source unique 1080p60 utilisent un CPU minimal. Le moteur QSV gère les quatre encodages simultanément.

L’endpoint HLS sert à la fois la playlist maître et toutes les playlists et segments des rendus.

Nombre de spectateurs en direct

Le serveur HLS intégré de Vajra Cast suit les spectateurs actifs en temps réel en surveillant les requêtes de playlist. Ce nombre de spectateurs est disponible dans le tableau de bord et via l’endpoint de métriques Prometheus, vous donnant des analyses d’audience en direct sans outils externes.

Intégration CDN

Pour les deployments de production servant plus de quelques dizaines de spectateurs simultanés, vous avez besoin d’un CDN entre votre origine HLS (Vajra Cast) et vos spectateurs.

Configuration de l’origine

Vajra Cast agit comme serveur d’origine. Le CDN récupère les segments depuis Vajra Cast et les met en cache dans des emplacements périphériques à travers le monde :

Vajra Cast (origine) → CDN (cache périphérique) → Spectateurs

Configurez votre CDN pour récupérer depuis l’endpoint HLS de Vajra Cast :

URL d'origine : http://serveur-vajracast:port/hls/

Stratégie de mise en cache CDN

La mise en cache HLS est simple car les segments sont immuables (le contenu d’un segment ne change jamais une fois écrit) et la playlist est le seul fichier qui change :

Le TTL de cache de la playlist média est critique. Si le CDN met en cache la playlist média de manière trop agressive, les spectateurs ne verront pas les nouveaux segments et le flux sera bloqué. Définissez le TTL à la moitié de la durée du segment (par ex. 2 secondes pour des segments de 4 secondes).

Choix du CDN

Tout CDN HTTP fonctionne pour HLS. Choix populaires :

Pour les tests et les petites audiences (moins de 100 spectateurs simultanés), vous pouvez servir le HLS directement depuis Vajra Cast sans CDN. Pour toute audience plus importante, utilisez un CDN pour décharger la bande passante et assurer la performance mondiale.

HLS basse latence (LL-HLS)

Le HLS standard présente une latence inhérente due à la livraison par segments. Le HLS basse latence, défini dans la révision de la spécification HLS en 2020, réduit la latence à 2-5 secondes tout en maintenant les avantages de compatibilité du HLS.

Comment fonctionne LL-HLS

LL-HLS introduit deux concepts clés :

1. Segments partiels : au lieu d’attendre qu’un segment complet soit terminé, le serveur publie des segments partiels (généralement 200-300 ms chacun) à mesure qu’ils sont générés. Le lecteur peut commencer à télécharger un segment partiel pendant que le segment complet est encore en cours d’encodage.

2. Rechargement bloquant de la playlist : au lieu que le lecteur interroge la playlist selon un minuteur, le lecteur envoie une requête bloquante que le serveur maintient ouverte jusqu’à ce qu’un nouveau segment ou segment partiel soit disponible. Cela élimine le délai d’interrogation.

Le résultat : la latence passe de 15-30 secondes à 2-5 secondes, compétitive avec la livraison basée sur RTMP.

Exigences LL-HLS

LL-HLS nécessite :

• Support serveur : le serveur d’origine doit générer des segments partiels et supporter les réponses de playlist bloquantes
• Support CDN : le CDN doit supporter le push HTTP/2 ou la propagation rapide des segments partiels
• Support lecteur : le lecteur vidéo doit implémenter les extensions LL-HLS

Le support navigateur est large : Safari (natif), hls.js (la bibliothèque HLS web dominante) et la plupart des lecteurs natifs mobiles supportent LL-HLS.

Quand utiliser LL-HLS

LL-HLS ajoute de la complexité côté serveur et est plus sensible à la configuration CDN. Utilisez-le quand la latence importe ; utilisez le HLS standard quand ce n’est pas le cas.

Compatibilité des lecteurs

HLS fonctionne sur pratiquement toutes les plateformes, mais les détails varient.

Support HLS natif

Support HLS navigateur (via hls.js)

Les navigateurs autres que Safari ne supportent pas nativement HLS. L’approche standard consiste à utiliser hls.js, une bibliothèque JavaScript qui analyse les manifestes HLS et alimente les segments vers l’API Media Source Extensions (MSE) du navigateur :

<video id="video" controls></video>
<script src="https://cdn.jsdelivr.net/npm/hls.js@latest"></script>
<script>
  const video = document.getElementById('video');
  if (Hls.isSupported()) {
    const hls = new Hls({
      lowLatencyMode: true,
      liveSyncDurationCount: 3,
      liveMaxLatencyDurationCount: 5,
    });
    hls.loadSource('https://votre-cdn.com/hls/flux/index.m3u8');
    hls.attachMedia(video);
  } else if (video.canPlayType('application/vnd.apple.mpegurl')) {
    // HLS natif Safari
    video.src = 'https://votre-cdn.com/hls/flux/index.m3u8';
  }
</script>

Options de configuration hls.js pour le streaming en direct :

Lecteur web intégré Vajra Cast

Vajra Cast inclut un lecteur web intégré pour chaque sortie HLS, accessible directement depuis le tableau de bord. Ce lecteur affiche :

• Le flux vidéo en direct
• Un indicateur de latence montrant le délai du spectateur par rapport au direct
• Les métadonnées du flux (résolution, codec, débit)

C’est utile pour une surveillance rapide et pour partager un lien de visionnage direct avec les parties prenantes qui doivent prévisualiser le flux sans configurer leur propre lecteur.

HLS pour la VOD (Vidéo à la Demande)

Bien que ce guide se concentre sur le streaming en direct, HLS est tout aussi efficace pour la livraison VOD. Les principales différences :

Playlist VOD

Une playlist VOD inclut tous les segments et la balise #EXT-X-ENDLIST :

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-PLAYLIST-TYPE:VOD

#EXTINF:6.000,
segment-0000.ts
#EXTINF:6.000,
segment-0001.ts
...
#EXTINF:4.200,
segment-0847.ts
#EXT-X-ENDLIST

Encodage VOD

Pour la VOD, vous pouvez utiliser des presets d’encodage plus lents (medium ou slow) puisqu’il n’y a pas de contrainte temps réel. Cela produit une qualité significativement meilleure au même débit par rapport à l’encodage en direct. Pré-encodez tous les rendus et téléchargez-les vers votre CDN ou stockage.

DVR / Timeshift

Une approche hybride entre le live et la VOD est le mode DVR (également appelé timeshift). Le serveur conserve les anciens segments au-delà de la fenêtre live normale, permettant aux spectateurs de mettre en pause et de rembobiner le contenu en direct :

Fenêtre live : 3 segments les plus récents (lecture quasi-live)
Fenêtre DVR : 2 dernières heures de segments (pause, rembobinage, recherche)

Cela nécessite plus de stockage à l’origine et au CDN, mais offre une meilleure expérience spectateur pour les événements longs.

Dépannage des problèmes HLS courants

Mise en tampon

Symptôme : le lecteur s’arrête et affiche une icône de chargement.

Causes et solutions :

1. Bande passante CDN insuffisante : augmentez votre CDN ou montez en gamme de plan
2. Origine trop lente : les segments ne sont pas générés assez rapidement. Vérifiez la charge CPU du serveur.
3. Durée de segment trop courte pour le réseau du spectateur : augmentez la durée des segments ou ajoutez un rendu à débit plus faible
4. Tampon lecteur trop petit : augmentez maxBufferLength dans hls.js

Changements de qualité (visibles)

Symptôme : le spectateur voit des sauts de qualité notables (net à flou et inversement).

Solutions :

1. Augmentez l’écart de débit entre les rendus adjacents (minimum 1,5x)
2. Ajustez l’algorithme ABR du lecteur pour être moins agressif avec abrBandWidthFactor dans hls.js
3. Assurez-vous que les images clés sont alignées sur tous les rendus

Désynchronisation audio/vidéo

Symptôme : l’audio est en avance ou en retard sur la vidéo.

Causes :

1. Le pipeline d’encodage introduit un délai variable entre les pistes audio et vidéo
2. Les limites de segments désalignent l’audio et la vidéo
3. Problème de synchronisation côté lecteur

Solution : assurez-vous que votre encodeur produit des horodatages audio et vidéo synchronisés. Utilisez des segments fMP4 (au lieu de MPEG-TS) pour un timing plus précis.

Playlist périmée (le flux semble figé)

Symptôme : le lecteur cesse de recevoir de nouveaux segments et le flux se fige sur une image.

Causes :

1. Le CDN met en cache la playlist média de manière trop agressive. Réduisez le TTL de cache de la playlist.
2. L’origine a cessé de générer des segments. Vérifiez le pipeline d’encodage.
3. Problème réseau entre l’origine et le CDN. Vérifiez la connectivité de l’origine.

Conclusion

Le HLS adaptatif est le fondement de la diffusion vidéo moderne. Sa combinaison de débit adaptatif, de compatibilité CDN et de support universel des lecteurs en fait le choix par défaut pour atteindre de larges audiences sur n’importe quel appareil.

Les clés d’une configuration HLS réussie sont : concevoir votre échelle de débit avec des écarts clairs entre les rendus, choisir votre durée de segment en fonction de vos exigences de latence, aligner les images clés sur tous les rendus et configurer correctement la mise en cache CDN pour les fichiers de playlist.

Le serveur HLS intégré de Vajra Cast simplifie le côté origine, gérant la génération de segments, la gestion des playlists et la création de rendus adaptatifs avec transcodage matériel accéléré. Pour la contribution et l’ingestion, associez-le à SRT pour un transport fiable et chiffré depuis le terrain. Consultez le guide de passerelle SRT pour l’architecture complète d’ingestion, et le guide de streaming multi-destinations pour combiner la sortie HLS avec la livraison RTMP vers les plateformes.