HLS : qu’est-ce que c’est, protocole et principe de fonctionnement

Qu’est-ce que HLS ?

HTTP Live Streaming (HLS) est un protocole de diffusion multimédia développé par Apple en 2009 et présenté pour la première fois dans iOS 3.0 et Safari. En 2017, le protocole a été proposé comme standard Internet via la RFC 8216, confirmant son statut de spécification ouverte disponible pour mise en œuvre sur toute plateforme.

L’idée principale de HLS consiste à diviser un flux multimédia continu en segments courts de 2 à 10 secondes. Chaque segment est un fichier indépendant qui peut être téléchargé via une requête HTTP normale. La gestion du flux s’effectue via des listes de lecture textuelles au format M3U8, qui contiennent des références aux segments et des métadonnées pour leur lecture correcte.

L’adaptativité est l’avantage clé de HLS. Le serveur prépare plusieurs versions du même contenu avec des débits différents, de 200 Kbps pour les connexions faibles à plus de 20 Mbps pour la vidéo 4K. Le client sélectionne automatiquement le débit approprié en fonction de la bande passante actuelle du canal. Selon une recherche Apple (WWDC 2024), LL-HLS réduit le temps de commutation entre les débits à 500 millisecondes, garantissant des changements de qualité fluides sans pauses notables.

Historique du développement de HLS

La première version de HLS (2009) ne prenait en charge que les segments MPEG-2 TS avec le codec audio AAC et le codec vidéo H.264. iOS 8 (2014) a ajouté la prise en charge des segments fMP4 (fragmented MP4), permettant d’utiliser HLS avec des codecs plus modernes, dont HEVC (H.265). iOS 11 (2017) a introduit la prise en charge de HDR10 et Dolby Vision. iOS 13 (2019) a introduit Low-Latency HLS, réduisant la latence de 6 à 30 secondes traditionnelles à 2 à 6 secondes.

En 2023, Apple a étendu HLS avec la prise en charge des codecs AV1 et EVC (Essential Video Coding), et a introduit Content Steering — un mécanisme de redirection dynamique des clients entre les serveurs CDN pour une répartition optimale de la charge. Content Steering permet au serveur de modifier les URL des segments à la volée, redirigeant le client vers le nœud CDN le plus proche ou le moins chargé sans interrompre la lecture.

Comment fonctionne HLS ?

L’architecture HLS se compose de trois composants principaux : le côté serveur (serveur d’origine + encodeur), le réseau de distribution (CDN) et le côté client (lecteur compatible HLS). L’ensemble du processus, de la capture vidéo à la lecture sur l’appareil de l’utilisateur, comprend plusieurs étapes séquentielles, chacune cruciale pour la qualité du streaming.

Encodage et segmentation

La vidéo source est d’abord encodée en plusieurs variantes avec des débits et résolutions différents. Les encodeurs professionnels, tels que FFmpeg ou AWS Elemental MediaConvert, créent simultanément 4 à 12 variantes de flux : de 240p (400 Kbps) à 4K (40 Mbps). Chaque variante est divisée en segments de durée égale, généralement 2 à 6 secondes pour LL-HLS ou 6 à 10 secondes pour le HLS traditionnel.

Pour chaque variante, une liste de lecture de variante (variant playlist) est créée, contenant les URL de tous les segments et leur durée. De plus, une liste de lecture maître (master playlist) est créée, regroupant toutes les variantes et contenant des informations sur chacune : résolution, débit, codec et pistes audio. Le client charge d’abord la liste maître, puis sélectionne la variante appropriée en fonction de l’analyse de la vitesse de connexion.

Distribution via CDN

Les segments et les listes de lecture sont mis en cache sur des serveurs CDN situés géographiquement près des utilisateurs. L’utilisation du protocole HTTP standard pour la distribution donne à HLS un avantage critique : tout CDN, équilibreur de charge ou serveur proxy compatible avec HTTP fonctionne avec HLS sans configuration supplémentaire. Cela distingue HLS des protocoles en temps réel tels que RTMP ou WebRTC, qui nécessitent des serveurs spécialisés.

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-codec:v", "libx264",
    "-codec:a", "aac",
    "-hls_time", "6",
    "-hls_list_size", "0",
    "-var_stream_map", "v:0,a:0 v:1,a:1",
    "-map", "v:0", "-b:v:0", "5000k",
    "-map", "v:1", "-b:v:1", "1000k",
    "-f", "hls",
    "stream/output.m3u8"
])

Le côté client utilise un algorithme de sélection de débit adaptatif (ABR). Le lecteur HLS charge la liste maître, analyse les variantes disponibles et commence la lecture au débit le plus approprié. Pendant la lecture, le lecteur surveille en permanence la vitesse de téléchargement des segments et le niveau du tampon, décidant de passer à un débit plus élevé ou plus faible. Les algorithmes ABR modernes prennent en compte non seulement la vitesse du réseau, mais aussi la taille du tampon, le type de contenu et même la consommation énergétique de l’appareil.

Structure du flux HLS : listes de lecture et segments

Comprendre la structure d’un flux HLS est nécessaire pour configurer correctement l’encodage, la distribution et le débogage des problèmes de lecture. Chaque flux HLS se compose de deux niveaux de listes de lecture et de nombreux segments médias organisés dans une hiérarchie stricte.

Liste de lecture maître (Master Playlist)

La liste de lecture maître est le point d’entrée du lecteur HLS. Le fichier avec l’extension .m3u8 contient des références à toutes les variantes du flux et leurs caractéristiques. Le lecteur charge ce fichier en premier et, sur la base des informations sur les débits et les résolutions, prend la décision initiale sur la variante à sélectionner. La liste maître peut également contenir des références à des pistes audio alternatives, des sous-titres et des listes de lecture I-Frame pour une recherche rapide.

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/video.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
360p/video.m3u8

Liste de lecture média (Media Playlist)

La liste de lecture média contient la liste réelle des segments pour une variante de flux. Chaque segment est spécifié avec sa durée et son URI. La liste de lecture média peut être statique (pour VOD — une liste complète de tous les segments) ou mise à jour dynamiquement (pour les diffusions en direct — les anciens segments sont supprimés, de nouveaux sont ajoutés).

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

Formats de segments

HLS prend en charge deux formats principaux de segments médias : MPEG-2 Transport Stream (.ts) et Fragmented MP4 (.m4s ou .mp4). MPEG-2 TS est le format original de HLS, offrant une compatibilité maximale. fMP4 est un format plus moderne prenant en charge HDR, HEVC et une compression plus efficace. Apple recommande fMP4 pour tous les nouveaux projets à partir d’iOS 10 et macOS Sierra.

Les éléments supplémentaires du flux HLS incluent les listes de lecture I-Frame pour une recherche rapide, les métadonnées ID3 pour synchroniser les sous-titres et les marqueurs publicitaires, et les Données de session (Session Data) pour transmettre les informations de visualisation aux serveurs d’analyse. Tous ces éléments sont facultatifs, mais leur utilisation améliore la qualité de l’expérience utilisateur.

Avantages et inconvénients de HLS

HLS domine le marché du streaming vidéo grâce à plusieurs avantages architecturaux, mais il a aussi des limites à prendre en compte lors du choix d’un protocole pour un projet spécifique. Comparons HLS avec les protocoles alternatifs de distribution vidéo.

Le principal avantage de HLS est la prise en charge native sur tous les appareils Apple (iPhone, iPad, Apple TV, Mac) via l’AVPlayer intégré. Cela fait de HLS le standard de facto pour les applications iOS/macOS. De plus, l’utilisation de HTTP standard pour la distribution permet de mettre en cache le contenu sur n’importe quel CDN et serveur proxy sans configuration supplémentaire, ce qui simplifie considérablement l’infrastructure de distribution.

Les inconvénients de HLS incluent une latence plus élevée par rapport à RTMP ou WebRTC pour les diffusions en direct. Même avec LL-HLS, la latence minimale est de 2 à 6 secondes, ce qui est inacceptable pour les scénarios interactifs en temps réel. De plus, HLS génère plus de fichiers sur le serveur (chaque segment est un fichier séparé), ce qui peut créer une charge sur le système de fichiers avec un grand nombre de flux simultanés.

HLS dans les applications mobiles

L’intégration de HLS dans les applications mobiles diffère selon la plateforme. Sur iOS et macOS, HLS est pris en charge au niveau du système d’exploitation via AVFoundation et AVPlayer, offrant un décodage accéléré par le matériel et une consommation d’énergie minimale. Sur Android, HLS n’est pas pris en charge par le MediaPlayer intégré mais est disponible via ExoPlayer — le lecteur multimédia officiel de Google.

HLS sur iOS via AVPlayer

Sur la plateforme Apple, la lecture HLS est aussi simple que possible grâce à la prise en charge intégrée dans AVPlayer. Il suffit de créer un AVPlayer avec l’URL de la liste maître, et le système gère automatiquement la commutation adaptative de débit, la sélection des pistes audio et le traitement des sous-titres. Le développeur obtient également un contrôle total sur la lecture via AVPlayerItem et AVAssetResourceLoader.

import AVFoundation

let url = URL(string: "https://example.com/stream.m3u8")!
let player = AVPlayer(url: url)
let controller = AVPlayerViewController()
controller.player = player
present(controller, animated: true) {
    player.play()
}

HLS sur Android via ExoPlayer

Pour Android, on utilise ExoPlayer, qui prend en charge HLS via un module d’extension séparé. ExoPlayer offre un contrôle plus fin du flux HLS : on peut gérer la sélection du débit, configurer la mise en mémoire tampon et gérer les erreurs de chargement des segments individuellement. LL-HLS nécessite ExoPlayer version 2.14.0 ou supérieure.

val player = ExoPlayer.Builder(this).build()

val uri = Uri.parse("https://example.com/stream.m3u8")
val mediaItem = MediaItem.fromUri(uri)

player.setMediaItem(mediaItem)
player.prepare()
player.play()

Optimisation de HLS pour les réseaux mobiles

Les applications mobiles nécessitent une approche spécifique de la configuration HLS en raison de l’instabilité des réseaux cellulaires et des limitations de trafic. Les principales recommandations incluent : configurer le débit initial en fonction du type de réseau (Wi-Fi ou cellulaire), utiliser des durées de segment plus courtes (2 à 4 secondes) pour une adaptation plus rapide, précharger le tampon lors du passage au Wi-Fi et prioriser la piste audio sur les signaux faibles.

Apple, dans la spécification HLS Authoring Specification for Apple Devices (2024), recommande d’utiliser une taille de segment ne dépassant pas 6 secondes pour les appareils mobiles et au moins 4 variantes de débit. Pour économiser le trafic sur les réseaux mobiles, le serveur doit distribuer les segments avec l’en-tête HTTP Cache-Control, permettant de mettre en cache le contenu sur les serveurs proxy intermédiaires des opérateurs de télécommunications.