Qu’est-ce que HLS ?

HLS (HTTP Live Streaming) est un protocole de streaming à débit adaptatif développé par Apple. Il fonctionne en découpant un flux vidéo continu en courts segments (généralement de 2 à 6 secondes chacun) et en les diffusant via HTTP standard. Un fichier manifeste (.m3u8) indique au lecteur quels segments sont disponibles et à quels niveaux de qualité. Le lecteur télécharge les segments séquentiellement, basculant entre les paliers de qualité en fonction des conditions réseau du spectateur.

HLS est devenu le protocole dominant pour la diffusion vidéo aux utilisateurs finaux. Il fonctionne dans tous les navigateurs web modernes, sur toutes les plateformes mobiles et derrière tous les CDN. Quand vous regardez de la vidéo en direct sur un site web ou une application mobile, vous regardez presque certainement du HLS.

HLS dans l’architecture Vajra Cast

Vajra Cast prend en charge HLS en tant que protocole de sortie. Cela signifie que vous pouvez recevoir des flux via SRT, RTMP ou tout protocole d’ingest pris en charge, et les distribuer en HLS pour la lecture web. L’architecture suit le flux standard à trois étapes de Vajra Cast :

  1. Ingest — réception via SRT, RTMP, HTTP/TS ou UDP
  2. Traitement — transcodage optionnel pour le palier de débit adaptatif (accélération matérielle avec Intel QSV/VAAPI)
  3. Redistribution — sortie HLS avec segments configurables, servie par le serveur HTTP intégré de Vajra Cast

La sortie HLS inclut un lecteur web intégré avec un indicateur de latence en direct, vous permettant de vérifier la qualité de lecture sans aucun outil externe.

Configuration de la sortie HLS

Sortie HLS de base

Ajouter une sortie HLS à une route Vajra Cast :

  1. Créez ou sélectionnez une route existante avec une entrée active
  2. Ajoutez une sortie et sélectionnez le protocole HLS
  3. Configurez la durée des segments et la longueur de la playlist
  4. Le point d’accès HLS devient immédiatement disponible à l’URL générée

Durée des segments

La durée des segments contrôle le compromis entre latence et fiabilité :

Durée du segmentImpact sur la latenceFiabilitéCas d’usage
2 secondesPlus faible (~6-8s au total)Plus sensible à la gigue réseauÉvénements à faible latence
4 secondesModérée (~12-16s au total)Bon équilibreStreaming en direct général
6 secondesPlus élevée (~18-24s au total)La plus fiableRéseaux instables, cache CDN

La latence totale est d’environ 3 fois la durée du segment (le lecteur met généralement en mémoire tampon 2 à 3 segments avant de démarrer la lecture) plus les délais d’encodage et de réseau.

Longueur de la playlist

La longueur de la playlist détermine combien de segments sont listés dans le manifeste .m3u8 à un instant donné. Une playlist plus longue offre aux spectateurs plus de marge pour se remettre d’interruptions réseau, mais utilise plus d’espace disque.

  • Minimum recommandé : 3 segments
  • Standard : 5-10 segments
  • Mode DVR : 30+ segments (permet aux spectateurs de rembobiner)

Structure d’URL de la sortie HLS

Vajra Cast génère des sorties HLS accessibles à :

http://votre-serveur:port/hls/[route-id]/index.m3u8

Cette URL peut être transmise directement à n’importe quel lecteur compatible HLS (Safari, hls.js, Video.js, VLC) ou utilisée comme URL d’origine pour un CDN.

Streaming à débit adaptatif

Le débit adaptatif (ABR) est la proposition de valeur fondamentale du HLS. Au lieu de servir une seule qualité, vous encodez plusieurs rendus du même flux à différentes résolutions et débits. Le lecteur sélectionne automatiquement le meilleur rendu en fonction de la bande passante disponible.

Construction d’un palier ABR

Un palier ABR typique pour le streaming en direct :

RenduRésolutionDébitCodecProfil
1080p1920x10806 000 kbpsH.264High
720p1280x7203 000 kbpsH.264Main
480p854x4801 500 kbpsH.264Main
360p640x360800 kbpsH.264Baseline
Audio uniquement128 kbpsAACLC

Transcodage pour l’ABR dans Vajra Cast

Créer plusieurs rendus nécessite du transcodage. Vajra Cast prend en charge le transcodage avec accélération matérielle via Intel QSV et VAAPI, ce qui signifie que vous pouvez générer un palier ABR complet sans saturer votre CPU :

  1. Configurez l’entrée de votre route sur la source en pleine qualité (par exemple, ingest SRT en 1080p)
  2. Ajoutez plusieurs sorties HLS, chacune configurée avec une résolution et un débit différents
  3. Vajra Cast utilise FFmpeg avec accélération matérielle pour générer chaque rendu
  4. Une playlist maître référence tous les rendus, et le lecteur sélectionne automatiquement

Pour les cas d’usage en passthrough (qualité unique, sans transcodage), la sortie HLS ajoute une latence minimale et une utilisation CPU quasi nulle. Le flux est simplement repackagé de MPEG-TS en segments HLS.

Prise en charge HEVC/H.265

Pour une meilleure efficacité, Vajra Cast prend également en charge l’encodage HEVC (H.265) via accélération matérielle. Le HEVC offre la même qualité à environ la moitié du débit du H.264, réduisant les coûts de bande passante pour votre CDN. Cependant, la prise en charge de la lecture HEVC dans les navigateurs est encore limitée (Safari le prend en charge nativement ; Chrome et Firefox nécessitent des conditions spécifiques). Pour une compatibilité maximale, utilisez le H.264 pour votre palier ABR et envisagez le HEVC uniquement pour les environnements de lecture contrôlés (décodeurs, applications natives).

Intégration CDN

HLS est conçu pour la diffusion via CDN. Les segments sont des fichiers HTTP standard que les serveurs de bordure du CDN mettent en cache et distribuent efficacement.

Configuration d’origine

Vajra Cast agit comme le serveur d’origine pour votre flux HLS. Le CDN récupère les segments depuis Vajra Cast et les met en cache aux emplacements de bordure dans le monde entier :

Origine : http://serveur-vajracast:port/hls/[route-id]/index.m3u8
         |
         v
Bordure CDN (en cache) --> Spectateur A
Bordure CDN (en cache) --> Spectateur B
Bordure CDN (en cache) --> Spectateur C

Compatibilité CDN

La sortie HLS de Vajra Cast est compatible avec tous les principaux CDN :

  • Cloudflare Stream / R2 — extraction depuis l’origine, cache de bordure mondial
  • AWS CloudFront — configuration d’origine avec TTL correspondant à la durée des segments
  • Akamai — configuration standard d’extraction d’origine HLS
  • Fastly — mise en cache en temps réel avec purge instantanée pour les mises à jour de segments
  • Bunny CDN — option économique pour les déploiements de plus petite taille

Configuration du cache

Pour le HLS en direct, configurez le TTL du cache de votre CDN pour qu’il corresponde à la durée de vos segments. Si vos segments durent 4 secondes, définissez le TTL du cache à 4 secondes. Cela garantit que le CDN sert toujours des segments frais tout en maximisant l’efficacité du cache.

Le manifeste .m3u8 doit avoir un TTL plus court (1-2 secondes) pour que les spectateurs découvrent rapidement les nouveaux segments.

Comptage des spectateurs en direct

La sortie HLS de Vajra Cast inclut un comptage intégré des spectateurs. Comme le serveur HLS s’exécute à l’intérieur de Vajra Cast, il peut suivre le nombre de requêtes de manifeste actives et signaler un nombre approximatif de spectateurs en direct dans le tableau de bord. C’est utile pour surveiller la taille de l’audience sans s’appuyer sur les analyses du CDN (qui ont généralement un délai).

Notez que lors de l’utilisation d’un CDN, le comptage des spectateurs dans Vajra Cast reflète les requêtes de bordure du CDN vers l’origine, pas les spectateurs individuels. Pour un comptage précis des utilisateurs finaux avec un CDN, utilisez les analyses propres du CDN.

HLS basse latence (LL-HLS)

Le HLS standard a une latence inhérente de 10 à 30 secondes en raison de la mise en mémoire tampon des segments. L’extension Low-Latency HLS (LL-HLS) d’Apple réduit cette latence à 2-5 secondes en :

  • Utilisant des segments partiels (sous-segments transmis via HTTP/2)
  • Fournissant des indices de préchargement qui informent le lecteur des segments à venir
  • Bloquant les requêtes de playlist jusqu’à ce que de nouveaux segments soient disponibles

Le LL-HLS est bien adapté aux cas d’usage interactifs (enchères en direct, sports avec engagement en temps réel). Pour la diffusion standard où 10-15 secondes de latence sont acceptables, le HLS classique est plus simple et plus robuste.

HLS vs SRT : des rôles différents

Il est important de comprendre que HLS et SRT remplissent des rôles différents dans une architecture de streaming :

SRTHLS
ObjectifTransport point à point (contribution)Diffusion un-vers-plusieurs (distribution)
Latence20ms - 4s6s - 30s
SpectateursUn par connexionIllimité via CDN
ChiffrementAES-256 natifHTTPS (TLS)
Correction d’erreursRetransmission ARQRemise en mémoire tampon du lecteur

SRT déplace votre flux de la source vers la passerelle. HLS le diffuse de la passerelle vers votre audience. Vajra Cast gère les deux extrémités de ce pipeline.

Prochaines étapes