Introduction à HTTP Live Streaming : HLS sur Android et plus

Publié: 2022-03-11

Le streaming vidéo fait partie intégrante de l'expérience Internet moderne. Il est partout : sur les téléphones portables, les ordinateurs de bureau, les téléviseurs et même les appareils portables. Il doit fonctionner parfaitement sur tous les appareils et types de réseaux, que ce soit sur des connexions mobiles lentes, le WiFi, derrière des pare-feu, etc. Le HTTP Live Streaming (HLS) d'Apple a été créé exactement avec ces défis à l'esprit.

Presque tous les appareils modernes sont dotés d'un matériel moderne suffisamment rapide pour lire la vidéo, de sorte que la vitesse et la fiabilité du réseau apparaissent comme le plus gros problème. Pourquoi donc? Jusqu'à il y a quelques années, la manière canonique de stocker et de publier des vidéos était des protocoles basés sur UDP comme RTP. Cela s'est avéré problématique à bien des égards, pour n'en citer que quelques-uns :

  1. Vous avez besoin d'un service de serveur (démon) pour diffuser du contenu.
  2. La plupart des pare-feu sont configurés pour autoriser uniquement les ports standard et les types de trafic réseau, tels que http, e-mail, etc.
  3. Si votre audience est mondiale, vous avez besoin d'une copie de votre service de démon de streaming fonctionnant dans toutes les régions principales.

Bien sûr, vous pouvez penser que tous ces problèmes sont faciles à résoudre. Stockez simplement des fichiers vidéo (par exemple, des fichiers mp4) sur votre serveur http et utilisez votre service CDN préféré pour les diffuser partout dans le monde.

Là où le streaming vidéo hérité est insuffisant

C'est loin d'être la meilleure solution pour plusieurs raisons, l'efficacité étant l'une d'entre elles. Si vous stockez des fichiers vidéo originaux en pleine résolution, les utilisateurs des zones rurales ou des régions du monde avec une mauvaise connectivité auront du mal à en profiter. Leurs lecteurs vidéo auront du mal à télécharger suffisamment de données pour les lire en cours d'exécution.

Par conséquent, vous avez besoin d'une version spéciale du fichier afin que la quantité de vidéo téléchargée soit approximativement la même que celle pouvant être lue. Par exemple, si la résolution et la qualité vidéo sont telles qu'en cinq secondes, il peut télécharger cinq autres secondes de vidéo, c'est optimal. Cependant, s'il faut cinq secondes pour télécharger seulement trois secondes de vidéo, le lecteur s'arrêtera et attendra le prochain morceau de flux à télécharger.

D'un autre côté, réduire davantage la qualité et la résolution ne ferait que dégrader l'expérience utilisateur sur des connexions plus rapides, car vous économiseriez inutilement de la bande passante. Cependant, il existe une troisième voie.

Streaming à débit adaptatif

Bien que vous puissiez télécharger différentes versions de vidéo pour différents utilisateurs, vous devez alors avoir la possibilité de contrôler leurs lecteurs et de calculer quel est le meilleur flux pour leur connexion et leur appareil. Ensuite, le joueur doit basculer entre eux (par exemple, lorsqu'un utilisateur passe de la 3G au WiFi). Et même alors, que se passe-t-il si le client change le type de réseau ? Ensuite, le lecteur doit passer à une vidéo différente, mais la lecture doit commencer non pas depuis le début, mais quelque part au milieu de la vidéo. Alors, comment calculez-vous la plage d'octets à demander ?

Une chose intéressante serait que les lecteurs vidéo puissent détecter les changements de type de réseau et de bande passante disponible, puis basculer de manière transparente entre différents flux (de la même vidéo préparée pour différentes vitesses) jusqu'à ce qu'ils trouvent le meilleur.

C'est exactement ce que résout le streaming à débit adaptatif.

Remarque : Ce didacticiel HLS ne couvrira pas le chiffrement, les lectures synchronisées et IMSC1.

Qu'est-ce que le HLS ?

HTTP Live Streaming est un protocole de streaming à débit binaire adaptatif introduit par Apple en 2009. Il utilise des fichiers m3u8 pour décrire les flux multimédias et il utilise HTTP pour la communication entre le serveur et le client. Il s'agit du protocole de diffusion multimédia par défaut pour tous les appareils iOS, mais il peut être utilisé sur Android et les navigateurs Web.

Illustration de la couverture de la diffusion en direct HTTP

Les blocs de construction de base d'un flux HLS sont :

  1. Listes de lecture M3U8
  2. Fichiers multimédias pour divers flux

Listes de lecture M3U8

Commençons par répondre à une question basique : que sont les fichiers M3U8 ?

M3U (ou M3U8) est un format de fichier texte brut créé à l'origine pour organiser des collections de fichiers MP3. Le format est étendu pour HLS, où il est utilisé pour définir les flux multimédias. Dans HLS, il existe deux types de fichiers m3u8 :

  • Liste de lecture multimédia : contenant les URL des fichiers nécessaires au streaming (c'est-à-dire des morceaux de la vidéo originale à lire).
  • Liste de lecture principale : contient des URL vers des listes de lecture multimédia qui, à leur tour, contiennent des variantes de la même vidéo préparées pour différentes bandes passantes.

Une soi-disant URL de diffusion en direct M3U8 n'est rien de plus que des URL vers des fichiers M3U8, tels que : https://s3-us-west-2.amazonaws.com/hls-playground/hls.m3u8.

Exemple de fichier M3U8 pour le flux HLS

Un fichier M3U8 contient une liste d'URL ou de chemins de fichiers locaux avec des métadonnées supplémentaires. Les lignes de métadonnées commencent par #.

Cet exemple illustre à quoi ressemble un fichier M3U8 pour un flux HLS simple :

 #EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-ALLOW-CACHE:YES #EXT-X-TARGETDURATION:11 #EXTINF:5.215111, 00000.ts #EXTINF:10.344822, 00001.ts #EXTINF:10.344822, 00002.ts #EXTINF:9.310344, 00003.ts #EXTINF:10.344822, 00004.ts ... #EXT-X-ENDLIST
  • Les quatre premières lignes sont des métadonnées globales (en-tête) pour cette liste de lecture M3U8.
  • L' EXT-X-VERSION est la version du format M3U8 (doit être au moins 3 si nous voulons utiliser les entrées EXTINF ).
  • La balise EXT-X-TARGETDURATION contient la durée maximale de chaque "morceau" vidéo. Typiquement, cette valeur est d'environ 10s.
  • Le reste du document contient des paires de lignes telles que :
 #EXTINF:10.344822, 00001.ts

Il s'agit d'un "morceau" de vidéo. Celui-ci représente le bloc 00001.ts qui dure exactement 10,344822 secondes. Lorsqu'un lecteur vidéo client doit démarrer une vidéo à partir d'un certain point de ladite vidéo, il peut facilement calculer le fichier .ts qu'il doit demander en additionnant les durées des morceaux précédemment visionnés. La deuxième ligne peut être un nom de fichier local ou une URL vers ce fichier.

Le fichier M3U8 avec ses fichiers .ts représente la forme la plus simple d'un flux HLS - une liste de lecture multimédia.

Veuillez garder à l'esprit que tous les navigateurs ne peuvent pas lire les flux HLS par défaut.

Liste de lecture principale ou fichier index M3U8

L'exemple M3U8 précédent pointe vers une série de morceaux .ts . Ils sont créés à partir du fichier vidéo d'origine, qui est redimensionné, encodé et divisé en morceaux.

Cela signifie que nous avons toujours le problème décrit dans l'introduction - qu'en est-il des clients sur des réseaux très lents (ou inhabituellement rapides) ? Ou, des clients sur des réseaux rapides avec de très petites tailles d'écran ? Cela n'a aucun sens de diffuser un fichier en résolution maximale s'il ne peut pas être affiché dans toute sa splendeur sur votre nouveau téléphone brillant.

M3U8 en HSL

HLS résout ce problème en introduisant une autre "couche" de M3U8. Ce fichier M3U8 ne contiendra pas de pointeurs vers des fichiers .ts , mais il contient des pointeurs vers d'autres fichiers M3U8 qui, à leur tour, contiennent des fichiers vidéo préparés à l'avance pour des débits et des résolutions spécifiques.

Voici un exemple d'un tel fichier M3U8 :

 #EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=1296,RESOLUTION=640x360 https://.../640x360_1200.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=264,RESOLUTION=416x234 https://.../416x234_200.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=464,RESOLUTION=480x270 https://.../480x270_400.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1628,RESOLUTION=960x540 https://.../960x540_1500.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2628,RESOLUTION=1280x720 https://.../1280x720_2500.m3u8

Le lecteur vidéo sélectionnera des paires de lignes telles que :

 #EXT-X-STREAM-INF:BANDWIDTH=1296,RESOLUTION=640x360 https://.../640x360_1200.m3u8

On les appelle des variantes de la même vidéo préparées pour différentes vitesses de réseau et résolutions d'écran. Ce fichier M3U8 spécifique ( 640x360_1200.m3u8 ) contient les morceaux de fichier vidéo de la vidéo redimensionnés à 640x360 pixels et préparés pour des débits de 1296kbps . Notez que le débit binaire signalé doit tenir compte à la fois des flux vidéo et audio de la vidéo.

Le lecteur vidéo commencera généralement à jouer à partir de la première variante de flux (dans l'exemple précédent, il s'agit de 640x360_1200.m3u8). Pour cette raison, vous devez faire particulièrement attention à décider quelle variante sera la première de la liste. L'ordre des autres variantes n'a pas d'importance.

Si le premier fichier .ts prend trop de temps à télécharger (provoquant une "mise en mémoire tampon", c'est-à-dire en attendant le prochain morceau), le lecteur vidéo passera à un flux avec un débit binaire plus petit. Et, bien sûr, s'il est chargé assez rapidement, cela signifie qu'il peut passer à une variante de meilleure qualité , mais seulement si cela a du sens pour la résolution de l'affichage.

Si le premier flux de la liste d'index M3U8 n'est pas le meilleur, le client aura besoin d'un ou deux cycles jusqu'à ce qu'il s'installe avec la bonne variante.

Donc, maintenant nous avons trois couches de HLS :

  1. Fichier d'index M3U8 (la liste de lecture principale) contenant des pointeurs (URL) vers des variantes.
  2. Fichiers de variante M3U8 (la liste de lecture multimédia) pour différents flux pour différentes tailles d'écran et vitesses de réseau. Ils contiennent des pointeurs (URL) vers des fichiers .ts.
  3. Fichiers .ts (morceaux) qui sont des fichiers binaires avec des parties de la vidéo.

Vous pouvez regarder un exemple de fichier d'index M3U8 ici (encore une fois, cela dépend de votre navigateur/système d'exploitation).

Parfois, vous savez à l'avance que le client est sur un réseau lent ou rapide. Dans ce cas, vous pouvez aider le client à choisir la bonne variante en fournissant un fichier d'index M3U8 avec une première variante différente. Il y a deux façons de le faire.

  • La première consiste à préparer plusieurs fichiers d'index pour différents types de réseaux et à préparer le client à l'avance pour demander le bon. Le client devra vérifier le type de réseau puis demander par exemple http://.../index_wifi.m3u8 ou http://.../index_mobile.m3u8 .
  • Vous pouvez également vous assurer que le client envoie le type de réseau dans le cadre de la requête http (par exemple s'il est connecté à un réseau wifi ou mobile 2G/3G/…), puis faire préparer dynamiquement le fichier d'index M3U8 pour chaque requête. Seul le fichier d'index M3U8 a besoin d'une version dynamique, les flux uniques (fichiers M3U8 variantes) peuvent toujours être stockés sous forme de fichiers statiques.

Préparation des fichiers vidéo pour HLS

Il existe deux éléments constitutifs importants du streaming en direct HTTP d'Apple. L'un est la façon dont les fichiers vidéo sont stockés (pour être servis via HTTP plus tard) et l'autre sont les fichiers d'index M3U8 qui indiquent au lecteur (l'application client de streaming) où obtenir quel fichier vidéo.

Commençons par les fichiers vidéo. Le protocole HLS s'attend à ce que les fichiers vidéo soient stockés en petits morceaux de longueur égale, généralement de 10 secondes chacun. À l'origine, ces fichiers devaient être stockés dans des fichiers MPEG-2 TS ( .ts ) et encodés au format H.264 avec audio au format MP3, HE-AAC ou AC-3.

Vidéo HLS

Cela signifie qu'une vidéo de 30 secondes sera divisée en 3 fichiers .ts plus petits, chacun d'environ 10 secondes.

Notez que la dernière version de HLS autorise également les fichiers .mp4 fragmentés. Comme il s'agit encore d'une nouveauté et que certains lecteurs vidéo doivent encore l'implémenter, les exemples de cet article utiliseront des fichiers .ts .

Images clés

Les blocs doivent être encodés avec une image clé au début de chaque fichier. Chaque vidéo contient des images. Les cadres sont des images, mais les formats vidéo ne stockent pas d'images complètes, cela prendrait trop d'espace disque. Ils encodent juste la différence par rapport à la trame précédente. Lorsque vous passez à un point médian de la vidéo, le lecteur a besoin d'un "point de départ" à partir duquel appliquer tous ces diffs afin d'afficher l'image initiale, puis commencer à lire la vidéo.

C'est pourquoi les morceaux .ts doivent avoir une image clé au début. Parfois, les joueurs doivent commencer au milieu du morceau. Le joueur peut toujours calculer l'image actuelle en ajoutant tous les "diffs" de la première image clé. Mais, s'il démarre 9 secondes après le début, il doit calculer 9 secondes de "diffs". Pour rendre ce calcul plus rapide, il est préférable de créer des images clés toutes les quelques secondes (meilleur cca 3s).

Points de rupture HLS

Dans certaines situations, vous souhaitez que plusieurs clips vidéo soient lus successivement. Une façon de procéder consiste à fusionner les fichiers vidéo d'origine, puis à créer les flux HLS avec ce fichier, mais cela pose problème pour plusieurs raisons. Que faire si vous souhaitez diffuser une annonce avant ou après votre vidéo ? Peut-être que vous ne voulez pas faire cela pour tous les utilisateurs, et que vous voulez probablement des annonces différentes pour différents utilisateurs. Et, bien sûr, vous ne voulez pas préparer à l'avance des fichiers HLS avec différentes publicités.

Afin de résoudre ce problème, il existe une balise #EXT-X-DISCONTINUITY qui peut être utilisée dans la liste de lecture m3u8. Cette ligne indique essentiellement au lecteur vidéo de se préparer à l'avance au fait qu'à partir de ce moment, les fichiers .ts peuvent être créés avec une configuration différente (par exemple, la résolution peut changer). Le joueur devra tout recalculer et éventuellement passer à une autre variante et il devra être préparé à de tels points de « discontinuité ».

Diffusion en direct avec HLS

Il existe essentiellement deux types de "streaming vidéo". L'un est la vidéo à la demande ( VOD ) pour les vidéos enregistrées à l'avance et diffusées à l'utilisateur lorsqu'il le décide. Et il y a la diffusion en direct . Même si HLS est une abréviation pour HTTP Live Streaming, tout ce qui a été expliqué jusqu'à présent a été centré sur la VOD, mais il existe également un moyen de diffuser en direct avec HLS.

Il y a quelques changements dans vos fichiers M3U8. Tout d'abord, il doit y avoir une balise #EXT-X-MEDIA-SEQUENCE:1 dans le fichier variante M3U8. Ensuite, le fichier M3U8 ne doit pas se terminer par #EXT-X-ENDLIST (qui sinon doit toujours être placé à la fin).

Pendant que vous enregistrez votre flux, vous aurez constamment de nouveaux fichiers .ts . Vous devez les ajouter dans la playlist M3U8 et chaque fois que vous en ajoutez une nouvelle, le compteur dans #EXT-X-MEDIA-SEQUENCE:<counter> doit être augmenté de 1.

Le lecteur vidéo vérifiera le compteur. S'il a changé depuis la dernière fois, il sait s'il y a de nouveaux morceaux à télécharger et à lire. Assurez-vous que le fichier M3U8 est servi avec les en-têtes sans cache, car les clients continueront à recharger les fichiers M3U8 en attendant que de nouveaux morceaux soient lus.

VTT

Une autre fonctionnalité intéressante pour les flux HLS est que vous pouvez y intégrer des fichiers Web Video Text Track (VTT). Les fichiers VTT peuvent être utilisés pour diverses utilisations. Par exemple, pour un lecteur Web HLS, vous pouvez spécifier des instantanés d'image pour différentes parties de la vidéo. Lorsque l'utilisateur déplace la souris sur la zone de la minuterie vidéo (sous le lecteur vidéo), le lecteur peut afficher des instantanés à partir de cette position dans la vidéo.

Les sous-titres sont une autre utilisation évidente des fichiers VTT. Le flux HLS peut spécifier plusieurs sous-titres pour plusieurs langues :

 #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-,NAME="English",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,LANGUAGE="en",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog, public.accessibility.describes-music-and-sound",URI="subtitles/eng/prog_index.m3u8"

Ensuite, theprog_index.m3u8 ressemble à :

 #EXTM3U #EXT-X-TARGETDURATION:30 #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:30, 0000.webvtt #EXTINF:30, 0001.webvtt ...

Le VTT réel (par exemple 0000.webvtt ):

 WEBVTT X-TIMESTAMP-MAP=MPEGTS:900000,LOCAL:00:00:00.000 00:00:01.000 --> 00:00:03.000 Subtitle -Unforced- (00:00:01.000) 00:00:03.000 --> 00:00:05.000 <i>...text here... -Unforced- (00:00:03.000)</i> <i>...text here...</i>

En plus des fichiers VTT, Apple a récemment annoncé que HLS prendra en charge IMSC1, un nouveau format de sous-titres optimisé pour la diffusion en continu. Son avantage le plus important est qu'il peut être stylisé à l'aide de CSS.

Outils de diffusion en direct HTTP et problèmes potentiels

Apple a introduit un certain nombre d'outils HSL utiles, qui sont décrits plus en détail dans le guide HLS officiel.

  • Pour les flux en direct, Apple a préparé un outil nommé mediastreamsegmenter pour créer des fichiers de segment à la volée à partir d'un flux vidéo en cours.
  • Un autre outil important est mediastreamvalidator . Il vérifiera vos listes de lecture M3U8, téléchargera les fichiers vidéo et signalera divers problèmes. Par exemple, lorsque le débit signalé n'est pas le même que celui calculé à partir des fichiers .ts.
  • Bien sûr, lorsque vous devez encoder/décoder/mux/demux/chunk/strip/merge/join/… des fichiers vidéo/audio, il y a ffmpeg. Soyez prêt à compiler votre ou vos propres versions personnalisées de ffmpeg pour des cas d'utilisation spécifiques.

L'un des problèmes les plus fréquemment rencontrés en vidéo est la synchronisation audio. Si vous constatez que l'audio de certains de vos flux HLS n'est pas synchronisé avec la vidéo (par exemple, un acteur ouvre la bouche, mais vous remarquez que la voix est en avance ou en retard de quelques millisecondes), il est possible que le fichier vidéo d'origine ait été filmé en utilisant un framerate variable. Assurez-vous de le convertir en bitrate constant.

Si possible, il est encore mieux de s'assurer que votre logiciel est configuré pour enregistrer la vidéo à une fréquence d'images constante.

Exemple de diffusion HTTP en direct

J'ai préparé une application Android HLS qui diffuse un HLS prédéfini à l'aide du lecteur ExoPlayer de Google. Il affichera une vidéo et une liste des "événements" HLS en dessous. Ces événements incluent : chaque fichier .ts téléchargé ou chaque fois que le lecteur décide de passer à un flux à débit supérieur ou inférieur.

Passons en revue les parties principales de l'initialisation de la visionneuse. Dans la première étape, nous allons récupérer le type de connexion actuel de l'appareil et utiliser ces informations pour décider quel fichier m3u8 récupérer.

 String m3u8File = "hls.m3u8"; ConnectivityManager connectivity = (ConnectivityManager) this.getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo activeNetwork = connectivity.getActiveNetworkInfo(); if (activeNetwork != null && activeNetwork.isConnectedOrConnecting()) { int type = activeNetwork.getType(); int subType = activeNetwork.getSubtype(); if (type == ConnectivityManager.TYPE_MOBILE && subType == TelephonyManager.NETWORK_TYPE_GPRS) { m3u8File = "hls_gprs.m3u8"; } } String m3u8URL = "https://s3-us-west-2.amazonaws.com/hls-playground/" + m3u8File;

Notez que ce n'est pas strictement nécessaire. Le lecteur HLS s'ajustera toujours à la bonne variante HLS après quelques morceaux, mais cela signifie que dans les 5 à 20 premières secondes, l'utilisateur pourrait ne pas regarder la variante idéale du flux.

N'oubliez pas que la première variante du fichier m3u8 est celle avec laquelle le visualiseur commencera. Puisque nous sommes du côté client et que nous pouvons détecter le type de connexion, nous pouvons au moins essayer d'éviter le basculement initial du joueur entre les variantes en demandant le fichier m3u8 qui est préparé à l'avance pour ce type de connexion.

Dans l'étape suivante, nous initialisons et démarrons notre lecteur HLS :

 Handler mainHandler = new Handler(); DefaultBandwidthMeter bandwidthMeter = new DefaultBandwidthMeter.Builder() .setEventListener(mainHandler, bandwidthMeterEventListener) .build(); TrackSelection.Factory videoTrackSelectionFactory = new AdaptiveTrackSelection.Factory(bandwidthMeter); TrackSelector trackSelector = new DefaultTrackSelector(videoTrackSelectionFactory); LoadControl loadControl = new DefaultLoadControl(); SimpleExoPlayer player = ExoPlayerFactory.newSimpleInstance(this, trackSelector, loadControl);

Ensuite, nous préparons le lecteur et l'alimentons avec le bon m3u8 pour ce type de connexion réseau :

 DataSource.Factory dataSourceFactory = new DefaultDataSourceFactory(this, Util.getUserAgent(this, "example-hls-app"), bandwidthMeter); HlsMediaSource videoSource = new HlsMediaSource(Uri.parse(m3u8URL), dataSourceFactory, 5, mainHandler, eventListener); player.prepare(videoSource);

Et voici le résultat:

Exemple de streaming HLS sous Android

Compatibilité du navigateur HLS, développements futurs

Apple exige que les applications de streaming vidéo sur iOS utilisent HLS si les vidéos durent plus de 10 minutes ou dépassent 5 Mo. Cela en soi est une garantie que HLS est là pour rester. Il y avait quelques inquiétudes concernant HLS et MPEG-DASH et lequel sera le gagnant dans l'arène des navigateurs Web. HLS n'est pas implémenté dans tous les navigateurs modernes (vous l'avez probablement remarqué si vous avez cliqué sur les exemples d'url m3u8 précédents). Sur Android, par exemple, dans les versions inférieures à 4.0, cela ne fonctionnera pas du tout. De 4.1 à 4.4, cela ne fonctionne que partiellement (par exemple, l'audio est manquant, ou la vidéo est manquante mais l'audio fonctionne).

Mais cette "bataille" est devenue un peu plus simple récemment. Apple a annoncé que le nouveau protocole HLS autorisera les fichiers mp4 fragmentés ( fMP4 ). Auparavant, si vous vouliez avoir à la fois le support HLS et MPEG-DASH, vous deviez encoder vos vidéos deux fois. Désormais, vous pourrez réutiliser les mêmes fichiers vidéo et reconditionner uniquement les fichiers de métadonnées ( .m3u8 pour HLS et .mpd pour MPEG-DASH).

Une autre annonce récente concerne la prise en charge du codec vidéo à haute efficacité (HEVC). S'il est utilisé, il doit être emballé dans des fichiers mp4 fragmentés. Et cela signifie probablement que l'avenir de HLS est fMP4 .

La situation actuelle dans le monde des navigateurs est que seules certaines implémentations de navigateur de la <video> liront HLS par défaut. Mais il existe des solutions open source et commerciales qui offrent une compatibilité HLS. La plupart d'entre eux offrent HLS en ayant une solution de secours Flash, mais il existe quelques implémentations entièrement écrites en JavaScript.

Emballer

Cet article se concentre spécifiquement sur HTTP Live Streaming, mais conceptuellement, il peut également être lu comme une explication du fonctionnement de Adaptive Bitrate Streaming (ABS). En conclusion, nous pouvons dire que HLS est une technologie qui résout de nombreux problèmes importants dans le streaming vidéo :

  • Il simplifie le stockage des fichiers vidéo
  • CDN
  • Lecteurs clients gérant différentes bandes passantes client et commutant entre les flux
  • Sous-titres, cryptage, lectures synchronisées et autres fonctionnalités non couvertes par cet article

Que vous finissiez par utiliser HLS ou MPEG-DASH, les deux protocoles devraient offrir des fonctionnalités similaires et, avec l'introduction du mp4 fragmenté (fMP4) dans HLS, vous pouvez utiliser les mêmes fichiers vidéo. Cela signifie que dans la plupart des cas, vous devrez comprendre les bases des deux protocoles. Heureusement, ils semblent aller dans le même sens, ce qui devrait les rendre plus faciles à maîtriser.