Diffusion en direct HTTP

Le protocole HTTP Live Streaming (également connu sous le nom de HLS ) est un protocole de communication de diffusion en continu à débit adaptatif basé sur HTTP , développé par Apple Inc. et lancé en 2009. Il est largement pris en charge par les lecteurs multimédias, les navigateurs web, les appareils mobiles et les serveurs de diffusion multimédia. En 2022, une enquête annuelle menée auprès du secteur de la vidéo a systématiquement confirmé qu'il s'agissait du format de diffusion le plus populaire.

HLS ressemble à MPEG-DASH en ce qu'il fonctionne en divisant le flux global en une séquence de petits téléchargements de fichiers HTTP, chacun téléchargeant un court segment d'un flux de transport global potentiellement illimité. Une liste des flux disponibles, encodés à différents débits binaires, est envoyée au client à l'aide d'une liste de lecture M3U étendue.

Basé sur les transactions HTTP standard, le streaming en direct HTTP peut traverser n'importe quel pare-feu ou serveur proxy autorisant le trafic HTTP standard, contrairement aux protocoles UDP tels que RTP . Ceci permet également de proposer du contenu depuis des serveurs HTTP classiques et de le distribuer via des réseaux de diffusion de contenu HTTP largement disponibles . La norme inclut également un mécanisme de chiffrement standard et une distribution sécurisée des clés via HTTPS , qui constituent ensemble un système de gestion des droits numériques (DRM) simple . Les versions ultérieures du protocole offrent également la possibilité d'avancer et de reculer rapidement, ainsi que l'intégration de sous-titres.

Apple a documenté le protocole HTTP Live Streaming sous forme de brouillon Internet (soumission individuelle), première étape du processus de publication en tant que RFC ( Request for Comments ). En décembre 2015, les auteurs de ce document ont demandé à l'éditeur indépendant des flux RFC (ISE) de le publier en tant que RFC informatif (non standard), en dehors du processus de consensus de l'IETF . En août 2017, la RFC 8216 a été publiée pour décrire la version 7 du protocole.

Le streaming en direct HTTP utilise un serveur web classique , compatible avec le protocole HLS (HTTP Live Streaming), pour diffuser du contenu audiovisuel. Il nécessite un logiciel spécifique, tel qu'OBS , pour convertir le contenu dans un format approprié ( codec ) en vue de sa transmission en temps réel sur un réseau . L'architecture du service comprend :

Serveur

Le flux vidéo entrant est codifié et encapsulé dans un format approprié pour la diffusion. Il est ensuite préparé pour la distribution en le segmentant en différents fichiers. Lors de la réception, la vidéo est encodée et segmentée afin de générer des fragments vidéo et un fichier d'index.

• Encodeur : code les fichiers vidéo au format H.264 et l'audio au format AAC , MP3 , AC-3 ou EAC-3 . Ceci est encapsulé par MPEG-2 Transport Stream (MPEG-TS) ou MPEG-4 Part 14 (MP4) pour le transporter.
• Segmenteur : divise le flux en fragments de longueur égale. Il crée également un fichier d’index contenant les références des fichiers fragmentés, enregistré au format .m3u8 .

Distributeur

Formé par un serveur web standard, il accepte les requêtes des clients et fournit toutes les ressources (fichier de playlist .m3u8 et fichiers de segment .ts) nécessaires à la diffusion en continu .

Client

Le logiciel client demande et télécharge tous les fichiers et ressources, puis les assemble pour les présenter à l'utilisateur sous forme de vidéo en continu. Il télécharge d'abord le fichier index via une URL , puis les différents fichiers multimédias disponibles. Le logiciel de lecture assemble ensuite la séquence pour permettre un affichage continu.

Le protocole HTTP Live Streaming (HLS) offre aux lecteurs des mécanismes d'adaptation aux réseaux instables, sans interruption de lecture perceptible pour l'utilisateur. Par exemple, sur un réseau sans fil peu fiable, le HLS permet au lecteur d'utiliser une vidéo de qualité inférieure, réduisant ainsi la consommation de bande passante. La haute disponibilité des vidéos HLS peut être assurée par la mise à disposition de plusieurs serveurs pour une même vidéo, permettant au lecteur de basculer automatiquement en cas de défaillance d'un serveur.

Pour permettre au lecteur de s'adapter à la bande passante du réseau, la vidéo originale est encodée en plusieurs niveaux de qualité distincts . Le serveur propose un index, appelé liste de lecture principale , de ces encodages , appelés flux de variantes . Le lecteur peut alors choisir entre les flux de variantes pendant la lecture, en passant de l'un à l'autre de manière transparente en fonction des variations de la qualité du réseau.

Lors de la WWDC 2016, Apple a annoncé l'intégration de l'adressage par plage d'octets pour les fichiers MP4 fragmentés (fMP4), permettant ainsi la lecture de contenu via HLS sans multiplexage dans un flux de transport MPEG-2 . L'industrie a considéré cela comme un pas vers la compatibilité entre HLS et MPEG-DASH .

Il existe deux extensions HLS sans lien entre elles, portant un nom de faible latence et un acronyme correspondant :

• Apple Low Latency HLS (ALHLS) a été annoncé par Apple lors de la WWDC2019
• LHLS communautaire (LHLS) qui est antérieur à la publication d'Apple et est supposément plus simple

Le reste de cette section décrit ALHLS d'Apple. Ce système réduit la latence de bout en bout lors de la diffusion en continu via HLS en diminuant le temps nécessaire au démarrage de la lecture du flux en direct et en maintenant ce temps pendant toute la durée de la diffusion. Son fonctionnement repose sur l'ajout de fichiers de segments multimédias partiels, à l'instar du format fMP4 de MPEG-CMAF. Contrairement à CMAF, ALHLS prend également en charge les fichiers de transport MPEG-2 TS partiels. Un segment multimédia partiel est un segment standard (par exemple, 6 secondes) divisé en segments égaux de moins d'une seconde (par exemple, 200 millisecondes). Le premier segment standard est remplacé par la série de segments partiels. Les segments suivants conservent leur taille standard. Le protocole HTTP/2 est requis pour transmettre les segments avec la liste de lecture, ce qui réduit la surcharge liée à l'établissement de connexions HTTP/TCP répétées.

Parmi les autres caractéristiques :

• Mises à jour Delta des listes de lecture : envoi uniquement des modifications entre les listes de lecture, qui tiennent généralement dans une seule MTU, ce qui rend le chargement des listes de lecture plus efficace, lesquelles peuvent être assez volumineuses avec de grandes fenêtres DVR.
• Blocage du rechargement des listes de lecture : lors de la requête de listes de lecture de médias en direct, attendre que le premier segment soit également prêt, puis renvoyer les deux simultanément (ce qui permet d’économiser des requêtes HTTP/TCP supplémentaires).
• Rapports de rendu : ajoutez des métadonnées aux autres rendus multimédias pour accélérer la transition entre les rendus ABR.
• Nouvelles étiquettes ajoutées : EXT-X-SERVER-CONTROL / EXT-X-PART / EXT-X-SKIP / EXT-X-RENDITION-REPORT
• Ajout des rappels URL QUERY_STRING ?_HLS

Apple a également ajouté de nouveaux outils : tsrecompressor produit et encode un flux audio et vidéo continu à faible latence. L’ outil mediastreamsegmenter est désormais disponible en version faible latence. Il s’agit d’un segmenteur HLS qui prend en entrée un flux UDP/MPEG-TS provenant de tsrecompressor et génère une liste de lecture multimédia, incluant les nouvelles balises mentionnées ci-dessus.

La prise en charge du protocole HLS à faible latence est disponible dans tvOS 13 bêta et iOS et iPadOS 14. Le 30 avril 2020, Apple a ajouté les spécifications de faible latence à la deuxième édition de la spécification HLS principale.

L'insertion dynamique de publicités est prise en charge par HLS grâce aux informations de jonction basées sur la spécification SCTE-35 . Le message de jonction SCTE-35 est inséré dans le fichier de liste de lecture multimédia à l'aide de la balise EXT-X-DATERANGE. Chaque section d'information SCTE-35 (splice_info_section()) est représentée par une balise EXT-X-DATERANGE dotée d'un attribut SCTE35-CMD. Une paire de jonctions SCTE-35 (sortie/entrée) signalée par les commandes splice_insert() est représentée par une ou plusieurs balises EXT-X-DATERANGE possédant le même attribut ID. La commande de jonction SCTE-35 (sortie) doit posséder l'attribut SCTE35-OUT et la commande de jonction (entrée) doit posséder l'attribut SCTE35-IN.

Entre les deux balises EXT-X-DATERANGE contenant respectivement les attributs SCTE35-OUT et SCTE35-IN, peut se trouver une séquence d'URI de segments multimédias. Ces segments représentent généralement des programmes publicitaires pouvant être remplacés par une publicité locale ou personnalisée. Le remplacement de la publicité ne nécessite pas le remplacement des fichiers multimédias ; seules les URI dans la liste de lecture doivent être modifiées pour pointer vers d'autres programmes publicitaires. Ce remplacement peut être effectué sur le serveur d'origine ou sur le périphérique de lecture multimédia du client.

Parmi les implémentations serveur notables prenant en charge le streaming HTTP en direct, on peut citer :

• Adobe Media Server prend en charge HLS pour les appareils iOS (HLS) et la diffusion en direct HTTP protégée (PHLS).
• Akamai prend en charge HLS pour les flux en direct et à la demande.
• AT&T prend en charge le protocole HLS dans tous les formats, en direct ou à la demande.
• Ant Media Server prend en charge HLS et HLS à faible latence pour les flux en direct et à la demande.
• Les caméras IP Axis Communication prennent en charge HLS via l'application CamStreamer ACAP.
• Instart prend en charge HLS pour les flux à la demande.
• Amazon CloudFront prend en charge HLS pour les flux à la demande.
• Bitmovin prend en charge HLS pour la diffusion à la demande et en direct.
• CDNetworks prend en charge le protocole HLS pour les flux en direct et à la demande.
• Cisco Systems : prend en charge la diffusion de bout en bout complète des services Live/TSTV/VOD/HLS et Cloud DVR.
• Cloudflare prend en charge HLS pour les flux en direct et à la demande.
• EdgeCast Networks prend en charge la diffusion multiplateforme via HLS.
• Fastly prend en charge HLS pour les flux en direct et à la demande.
• Le serveur universel Helix de RealNetworks prend en charge iPhone OS 3.0 et versions ultérieures pour la diffusion en direct et à la demande de contenu H.264 et AAC via HTTP Live ou à la demande sur iPhone, iPad et iPod.
• IIS Media Services de Microsoft prend en charge la diffusion en direct et à la demande Smooth Streaming et HTTP Live Streaming.
• Le niveau 3 prend en charge les flux HLS en direct et à la demande.
• Limelight Networks prend en charge HLS pour certains comptes.
• Nginx, avec le module nginx-rtmp-module, prend en charge HLS en mode direct. La version commerciale Nginx Plus, qui inclut le module ngx_http_hls_module , prend également en charge la VOD HLS/HDS.
• Nimble Streamer prend en charge HLS en mode direct et VOD, et la spécification Apple Low Latency HLS est également prise en charge.
• Node.js avec le package hls-server prend en charge l'encodage hls en mode direct et la conversion de fichiers locaux.
• OvenMediaEngine est un projet open source qui prend en charge le protocole HLS à faible latence (LL-HLS) et le protocole HLS pour la diffusion en direct.
• PeerTube prend en charge HLS
• Storm Streaming Server prend en charge HLS comme mode de secours pour son lecteur Media Source Extensions
• Le CDN de Tata Communications prend en charge HLS pour les flux en direct et à la demande.
• TVersity prend en charge le protocole HLS associé au transcodage à la volée pour la lecture de tout contenu vidéo sur les appareils iOS.
• Ustream prend en charge la diffusion HLS des flux en direct. Le flux ingéré est retranscodé si le codec audio et vidéo d'origine ne répond pas aux exigences HLS.
• VLC Media Player prend en charge le protocole HLS pour la diffusion de flux en direct et à la demande à partir de la version 2.0.
• Le moteur de streaming Wowza de Wowza Media Systems prend en charge HLS et HLS crypté pour la diffusion en direct (avec DVR), la diffusion à la demande et la spécification Apple Low Latency HLS.

• Google a ajouté la prise en charge du streaming HTTP en direct dans Android 3.0 (Honeycomb).
• HP a ajouté la prise en charge du streaming HTTP en direct dans webOS 3.0.5.
• Microsoft a ajouté la prise en charge du streaming HTTP en direct dans le moteur de rendu EdgeHTML de Windows 10 en 2015.
• Microsoft a ajouté la prise en charge de la diffusion en direct HTTP dans IIS Media Services 4.0.
• Yospace a ajouté la prise en charge du streaming HTTP en direct dans Yospace HLS Player et SDK pour la version 1.0 de Flash.
• Sling Media a ajouté la prise en charge de la diffusion en direct HTTP à ses Slingbox et à ses applications SlingPlayer.
• En 2014/15, la BBC a introduit les flux HLS-AAC pour ses services de radio Internet en direct et ses services audio à la demande, et prend en charge ces flux avec ses clients iPlayer Radio .
• Twitch utilise HTTP Live Streaming (HLS) pour transmettre et adapter la diffusion en direct à de nombreux spectateurs simultanés, prenant également en charge plusieurs variantes (par exemple, 1080p, 720p, etc.).

La diffusion en direct HTTP est prise en charge nativement par les systèmes d'exploitation suivants :

• Windows 10 versions 1507 à 2004 ( Microsoft Edge Legacy) (n'est plus pris en charge)
• Lecteur multimédia Windows 11
• macOS 10.6+ ( Safari et QuickTime )
• iOS 3.0+ ( Safari )
• Android 4.1+ ( Google Chrome )

Windows 10 prenait en charge nativement le streaming HTTP en direct grâce à EdgeHTML , un moteur de rendu propriétaire utilisé par Microsoft Edge (désormais appelé Edge Legacy) avant la transition vers le moteur de rendu Blink basé sur Chromium . Edge Legacy était inclus dans Windows 10 jusqu'à la version 2004. Il a été remplacé par Edge Chromium dans la version 20H2. Avec Windows 11 , Microsoft a publié une version mise à jour du Lecteur Windows Media prenant en charge nativement le protocole HLS.