Sortie HLS : Diffusion adaptive pour le web
Configurez la sortie HLS depuis Vajra Cast avec des paliers de débit adaptatif, le réglage des segments et l'intégration CDN pour le streaming web.
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 :
- Ingest — réception via SRT, RTMP, HTTP/TS ou UDP
- Traitement — transcodage optionnel pour le palier de débit adaptatif (accélération matérielle avec Intel QSV/VAAPI)
- 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 :
- Créez ou sélectionnez une route existante avec une entrée active
- Ajoutez une sortie et sélectionnez le protocole HLS
- Configurez la durée des segments et la longueur de la playlist
- 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 segment | Impact sur la latence | Fiabilité | Cas d’usage |
|---|---|---|---|
| 2 secondes | Plus faible (~6-8s au total) | Plus sensible à la gigue réseau | Événements à faible latence |
| 4 secondes | Modérée (~12-16s au total) | Bon équilibre | Streaming en direct général |
| 6 secondes | Plus élevée (~18-24s au total) | La plus fiable | Ré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 :
| Rendu | Résolution | Débit | Codec | Profil |
|---|---|---|---|---|
| 1080p | 1920x1080 | 6 000 kbps | H.264 | High |
| 720p | 1280x720 | 3 000 kbps | H.264 | Main |
| 480p | 854x480 | 1 500 kbps | H.264 | Main |
| 360p | 640x360 | 800 kbps | H.264 | Baseline |
| Audio uniquement | — | 128 kbps | AAC | LC |
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 :
- Configurez l’entrée de votre route sur la source en pleine qualité (par exemple, ingest SRT en 1080p)
- Ajoutez plusieurs sorties HLS, chacune configurée avec une résolution et un débit différents
- Vajra Cast utilise FFmpeg avec accélération matérielle pour générer chaque rendu
- 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 :
| SRT | HLS | |
|---|---|---|
| Objectif | Transport point à point (contribution) | Diffusion un-vers-plusieurs (distribution) |
| Latence | 20ms - 4s | 6s - 30s |
| Spectateurs | Un par connexion | Illimité via CDN |
| Chiffrement | AES-256 natif | HTTPS (TLS) |
| Correction d’erreurs | Retransmission ARQ | Remise 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
- Retournez au Guide de la passerelle de streaming SRT pour la vue d’ensemble complète de l’architecture
- Découvrez les détails du protocole SRT pour la configuration de l’ingest
- Apprenez à convertir RTMP en SRT pour la compatibilité avec les encodeurs anciens
- Explorez l’infrastructure de streaming OTT pour construire une plateforme de streaming complète