%20(1).webp)
En 2009, Apple a présenté HTTP Live Streaming (HLS) comme moyen de diffuser du contenu audio et vidéo en direct et à la demande sur Internet. C'est maintenant le protocole de streaming vidéo le plus utilisé dans le monde entier, avec prise en charge de tous les principaux navigateurs et appareils.
Dans ce blog, nous expliquerons pourquoi LL-HLS a été créé, de quoi il s'agit, en quoi il diffère de ll hls par rapport à hls, quelles sont ses principales caractéristiques, comment il se comporte par rapport à LL-DASH et quelques points à garder à l'esprit. tout en le mettant en œuvre.
Les
Comme indiqué ci-dessus, HLS est un protocole de diffusion multimédia en streaming qui utilise HTTP pour diffuser du contenu vidéo et audio sur Internet. Il s'agit d'un protocole assez populaire utilisé par les fournisseurs de services OTT et d'autres navigateurs et appareils majeurs.
D'autre part, ll hls est une variante de HLS optimisée pour le streaming à faible latence. Il réduit le temps entre le moment où un utilisateur lance la lecture et le moment où il voit ou entend le contenu (appelé « latence »). Cela peut être particulièrement important pour les diffusions en direct, où même quelques secondes de retard peuvent rendre l'expérience moins agréable pour les téléspectateurs.
La principale différence technique entre hls et hls à faible latence réside dans le protocole utilisé par les deux pour gérer le streaming. La diffusion en direct HTTP utilise un mécanisme de mise en mémoire tampon unique qui attend que l'intégralité du segment soit téléchargé avant la diffusion. Cela peut avoir un impact sur la latence, car les téléspectateurs doivent attendre que l'intégralité du segment soit téléchargée avant de pouvoir profiter du contenu vidéo.
Le streaming à faible latence hls utilise le push du serveur, ce qui contribue à réduire la latence. Cela signifie que le serveur pousse les segments de la vidéo vers le destinataire. La lecture de la vidéo commence dès que les premiers segments de la vidéo sont téléchargés. Cela réduit finalement la latence car les téléspectateurs peuvent regarder la vidéo pendant que les autres segments sont en cours de téléchargement.
Étant donné que hls à faible latence utilise un codage de transfert fragmenté, il réduit la latence. Par conséquent, la faible latence du HLS est généralement d’environ 2 à 5 secondes, contre 6 à 30 secondes pour le HLS. Cela fait du streaming à faible latence hls un meilleur choix pour les applications de streaming en direct où la latence est critique.
Maintenant, passons aux choses sérieuses.
HLS, le prédécesseur de LL-HLS, a été lancé pour diffuser du contenu de haute qualité à grande échelle sur tous les appareils et plates-formes. Cependant, son architecture de streaming orientée vers l'échelle avait un prix, à savoir la latence. Pour les non-initiés, la latence est le temps qu'il faut entre la création vidéo (sur une caméra) et sa lecture finale (sur l'appareil d'un utilisateur), également appelée « latence verre à verre ». Entre les deux, ce flux vidéo doit être codé (à la fois audio et vidéo), segmenté, empaqueté, répertorié, téléchargé, livré, décodé, synchronisé sur les lèvres et mis en mémoire tampon avant sa lecture. Le protocole de streaming (comme HLS) gère tout ce gros travail.
Même si HLS a fait un excellent travail en termes de qualité et de compatibilité, au fil des années, son développement a systématiquement compromis sur la latence. Et c’était logique. À l’époque, la latence n’était pas un problème. Cependant, ce n’est plus le cas. Avec l’avènement des médias sociaux et du streaming en direct, les gens veulent désormais du contenu en temps réel. Ils ne veulent pas attendre plus longtemps. Ici, un retard de 30 à 50 secondes est tout simplement insupportable.
Il est logique qu’Apple (qui gère HLS) propose éventuellement une solution optimisée pour le streaming à faible latence. Alors, ils l’ont fait ! En 2019, à la WWDC, Apple a annoncé le HLS à faible latence ou LL-HLS. Il a été construit sur les spécifications HLS existantes avec quelques modifications pour obtenir une faible latence (<5 s). Voyons comment LL-HLS fait cela sans compromettre la qualité ou la compatibilité :
LL-HLS apporte des modifications majeures à la spécification HLS existante. Ces changements incluent :
Dans LL-HLS, les segments sont ensuite divisés en parties (segments partiels HLS), ce qui diminue la taille des fichiers individuels. Cela permet de démarrer la lecture avant même que le segment entier ne soit téléchargé (contrairement au HLS où il faut attendre le segment complet).
La liste de lecture est mise à jour en LL-HLS avec des coûts de transfert inférieurs à ceux de HLS. Cela se fait en demandant au serveur de fournir des mises à jour delta, qui mettent à jour les parties pertinentes de la liste de lecture déjà disponibles avec le client.
La requête HTTP GET d'un joueur peut contenir des « Delivery Directives » en LL-HLS. Il s'agit de paramètres de requête spéciaux demandant un segment futur dans la réponse de la playlist. Le serveur bloque ensuite cette requête jusqu'à ce que le segment spécifié soit disponible. Il élimine l'interrogation des listes de lecture et, par conséquent, libère la bande passante du serveur et du réseau.
Pour réduire davantage la latence, LL-HLS introduit des astuces de préchargement. Il s'agit de balises spéciales dans la liste de lecture qui indiquent au lecteur de commencer à récupérer un segment avant même qu'il ne soit requis pour la lecture. Ainsi, le segment peut être joué immédiatement, sans aucun délai, en cas de besoin.
LL-HLS minimise le nombre d'allers-retours lors de l'adaptation du débit binaire. Cela se fait en ajoutant des balises EXT-X-RENDITION-REPORT pour toutes les listes de lecture multimédia dans une liste de lecture multivariée. Ces balises fournissent des informations, telles que le dernier numéro de séquence multimédia et la dernière partie actuellement dans la liste de lecture multimédia. De cette façon, le client peut demander les parties requises au serveur sans avoir à récupérer une toute nouvelle liste de lecture multimédia.
Il existe certaines différences clés entre eux que vous devez connaître avant de décider laquelle convient le mieux à votre cas d'utilisation.
Voici quelques différences et similitudes entre LL-HLS et HLS :
Comme nous l'avons vu, la plus grande différence entre LL-HLS et HLS est la latence. Avec LL-HLS, Apple a réussi à le réduire considérablement (à moins de 5 secondes) par rapport au HLS classique (qui a une latence d'environ 30 secondes. Cette latence est encore inférieure à la latence du streaming de télévision par câble HD. En tant que Par conséquent, LL-HLS offre aux utilisateurs une expérience de visualisation en temps quasi réel et doit être prioritaire si la latence est importante pour un cas d'utilisation donné.
Il n’y a pas de différence notable de qualité entre les flux LL-HLS et HLS. Les deux fournissent un streaming vidéo de haute qualité à grande échelle. Cependant, LL-HLS n’est pas le meilleur pour les conditions de faible bande passante réseau.
L’un des avantages de HLS et de LL-HLS est leur compatibilité avec tous les principaux navigateurs et appareils. Certains les navigateurs populaires prenant en charge LL-HLS incluent AVPlayer (iOS), Exoplayer (Android), THEOPlayer, JWPlayer, HLS.js, VideoJS et AgnoPlay. Ainsi, contrairement à d’autres protocoles, vous n’avez pas à vous soucier de savoir si vos téléspectateurs pourront ou non regarder votre flux.
Le déploiement d’un HLS classique est moins cher que le LL-HLS.
L'implémentation de LL-HLS est plus complexe que HLS en raison de ses fonctionnalités supplémentaires (telles que les conseils de préchargement et les rapports de rendu). Vous devrez donc bien comprendre son fonctionnement avant de pouvoir le mettre en œuvre.
Examinons maintenant quelques avantages et inconvénients de l'utilisation de LL-HLS pour le streaming à faible latence :
Les avantages de l’utilisation de LL-HLS pour le streaming à faible latence incluent :
Comme son nom l’indique clairement, LL-HLS a été conçu en pensant à la latence. Le protocole de streaming offre une expérience visuelle verre à verre en temps quasi réel. Dans certains scénarios, en utilisant LL-HLS, une latence <2 secondes peut également être obtenue. Cela le rend idéal pour les diffusions en direct, telles que les sports en direct, les actualités, le streaming de jeux, etc., où chaque seconde compte.
Un autre avantage de l’utilisation de LL-HLS est qu’elle ne sacrifie pas la qualité au profit de la latence. Il utilise les mêmes codecs (comme H.264 et H.265) que le HLS classique et offre une expérience de streaming vidéo de haute qualité dans les conditions de réseau souhaitées.
Le défi de la plupart des protocoles de streaming, en particulier ceux impliquant une faible latence, est qu'ils sont difficiles à mettre à l'échelle. Ce n’est pas le cas du LL-HLS. Il s'appuie sur HLS et utilise un packaging HLS standard, ce qui le rend considérablement facile à mettre en œuvre et à faire évoluer. En conséquence, vous pouvez engager des milliers d’utilisateurs simultanés sans aucun problème.
L'un des avantages de LL-HLS est qu'il est compatible avec tous les principaux navigateurs et appareils, notamment iOS, Android, macOS, Windows, tvOS, etc. Cette compatibilité permet de toucher un public plus large avec vos streams en direct sans avoir à se soucier de savoir s'ils pourront le regarder ou non.
LL-HLS est un nouveau protocole de streaming et ne bénéficie donc pas d'un support aussi étendu que son prédécesseur. Cela peut rendre difficile la recherche de certaines informations ou la résolution des problèmes auxquels vous pourriez être confronté lors du déploiement du protocole.
Un autre inconvénient de l'utilisation de LL-HLS est que sa mise en œuvre est plus complexe que celle du HLS classique en raison de ses fonctionnalités supplémentaires. Outre les principales solutions de contournement déjà mentionnées, LL-HLS propose plusieurs optimisations qui peuvent parfois devenir assez écrasantes.
Le coût impliqué dans la mise en œuvre de LL-HLS est également plus élevé que celui du HLS classique en raison de l'infrastructure supplémentaire requise pour le streaming à faible latence. Cependant, ce coût en vaut la peine si votre cas d'utilisation exige la diffusion de contenu en temps réel.
Bien que LL-HLS soit souvent également comparé à WebRTC, sa seule comparaison juste est avec LL-DASH.
Voici une comparaison rapide des deux protocoles de streaming :
LL-HLS utilise HTTP Live Streaming (HLS) qui est un protocole propriétaire d'Apple, tandis que LL-DASH utilise le standard ouvert Dynamic Adaptive Streaming over HTTP (DASH).
LL-HLS est conçu spécifiquement pour les appareils Apple. Cependant, comme il est rétrocompatible avec les lecteurs HLS, il bénéficie également d'une prise en charge multiplateforme et multi-appareils. LL-DASH n'est pas pris en charge par les appareils Apple.
La latence de LL-HLS et LL-DASH est comparable. Cependant, selon le cas d'utilisation et le calcul requis, l'un ou l'autre peut avoir une latence plus élevée ou plus faible.
Alors que les "parties" LL-HLS sont adressables individuellement (sous forme de petits fichiers ou de plages d'octets dans le segment entier), les "morceaux" (ou "fragments") LL-DASH ne le sont pas. Cela signifie que dans LL-DASH, le client n'a pas besoin d'attendre que le serveur encode complètement le segment avant d'envoyer les morceaux précédents.
Dans les protocoles HLS et DASH, le client interroge le serveur à intervalles réguliers (disons 10 secondes) pour vérifier les mises à jour afin de récupérer du nouveau contenu. Cependant, il est possible de réaliser une mise à jour de la liste de lecture sans aucune interrogation des clients dans LL-HLS et LL-DASH. Alors que LL-HLS le fait avec ses directives de livraison (_HLS_msn= , _HLS_part= , & _HLS_skip=YES|v2), LL-DASH ne dépend pas de la mise à jour du manifeste pour qu'un joueur donne un sens à un nouveau morceau.
.webp)
Dans les protocoles LL-HLS et LL-DASH, la protection du contenu utilise les normes MPEG-CENC (Common Encryption). Ces deux protocoles prennent également en charge le Common Media Application Format (CMAF). En termes de codecs, alors que LL-DASH est indépendant du codec, LL-HLS n'autorise que des codecs spécifiques pour l'encodage.
Les deux protocoles offrent un streaming à débit adaptatif. Ils aident les joueurs à basculer automatiquement entre plusieurs rendus en fonction des conditions changeantes du réseau sans interrompre l'expérience de lecture des spectateurs. Cependant, LL-HLS est différent dans la mesure où il dispose de plusieurs flux pour différents débits et résolutions. LL-DASH n'a qu'un seul flux pour un débit binaire et une résolution particuliers.
Un autre avantage de LL-HLS par rapport à LL-DASH est lié au mécanisme de protection du contenu, c'est-à-dire comment savoir si votre encodeur a produit un fichier crypté avec des signatures valides ? Afin de vérifier cela, le protocole HLS utilise des balises EXT – X – KEY tandis que DASH s'appuie sur des boîtes PSSH à l'intérieur des fichiers MP4 ou des segments d'initialisation séparés en dehors des MP4 appelés xlinks – les deux méthodes nécessitent des allers-retours réseau supplémentaires qui peuvent introduire des retards importants lors des événements de diffusion en direct. Pour résoudre ce problème et rendre les choses plus simples et efficaces, Apple a proposé une solution qui inclut les valeurs KEY ID et IV directement dans la liste de lecture m3u8 afin que les joueurs puissent les valider avant de télécharger un segment – aucune demande/réponse supplémentaire n'est nécessaire !
LL-HLS est un excellent choix pour le streaming à faible latence si vous recherchez un protocole compatible avec tous les principaux navigateurs et appareils. Cependant, il est important de garder à l’esprit que sa mise en œuvre est plus complexe que celle du HLS classique.
Au cas où vous auriez besoin d'aide, n'hésitez pas à nous contacter.
Vous avez aimé cette lecture ?