Pendant des années, il y a eu deux modèles de base pour la diffusion en continu sur l'internet : la technologie propriétaire basée sur le serveur, comme le RTMP, ou le téléchargement progressif. La diffusion en continu sur serveur permet de fournir des flux à plusieurs débits qui peuvent être commutés à la demande, mais elle nécessite un logiciel coûteux pour l'obtention d'une licence. Le téléchargement progressif peut se faire via Apache, mais le changement de débit nécessite l'arrêt de la lecture.
L'avènement des protocoles de diffusion en continu basés sur HTTP, tels que HLS et Smooth Streaming, a rendu possible la diffusion en continu sur des connexions HTTP standard à l'aide d'une technologie de serveur de base telle qu'Apache ; la commutation transparente du débit binaire est devenue courante et la diffusion par CDN était simple, car elle était fondamentalement identique à la diffusion de n'importe quel fichier par HTTP. La diffusion en continu par HTTP n'est rien de moins qu'une révolution dans la diffusion de médias en continu, réduisant considérablement le coût et la complexité de la diffusion en continu de haute qualité.
Lors de la conception d'une plateforme vidéo, d'innombrables éléments doivent être pris en compte. Cependant, l'une des décisions les plus importantes et les plus souvent négligées concerne le traitement des fichiers manifestes basés sur HTTP.
Fichiers manifestes statiques
Dans le monde physique, lorsque vous achetez une vidéo, vous regardez l'emballage, vous prenez la boîte, vous vous rendez à la caisse, vous payez le caissier, vous rentrez chez vous et vous insérez la vidéo dans votre lecteur.
La plupart des plateformes vidéo sont structurées de manière assez similaire. Fondamentalement, un groupe de métadonnées (la boîte) est associé à un élément multimédia lisible (la vidéo). La plupart des plates-formes vidéo commencent avec le concept d'une URL unique qui relie les métadonnées à une seule vidéo mp4. Lorsqu'une plateforme vidéo devient plus complexe, il peut y avoir plusieurs URL connectées aux métadonnées représentant plusieurs débits binaires, résolutions ou éventuellement d'autres médias associés à l'élément principal, tels que des aperçus ou des fonctions spéciales.
Les choses se compliquent lorsqu'on essaie d'étendre le modèle physique à un monde de streaming en ligne qui inclut des protocoles de streaming basés sur HTTP tels que HLS. HLS est basé sur de nombreux fragments d'un fichier vidéo liés entre eux par un fichier texte appelé manifeste. Lors de la mise en œuvre du protocole HLS, la méthode la plus simple consiste à ajouter une URL qui renvoie au manifeste ou au fichier m3u8. Cette méthode a l'avantage d'être extrêmement simple et de s'inscrire dans le modèle existant.
L'inconvénient est que la HLS ne ressemble pas vraiment à un média statique. Par exemple, un MP4 ressemble beaucoup à une piste vidéo sur un DVD ; il s'agit d'une seule vidéo à une résolution et un débit uniques. Le manifeste HLS se compose très probablement de plusieurs débits binaires, résolutions et de milliers de morceaux de vidéo fragmentés. HLS a la capacité de faire beaucoup plus qu'un MP4, alors pourquoi le traiter de la même manière ?
Listes de lecture HLS
Une liste de lecture HLS comprend des métadonnées qui décrivent les éléments de base du flux et un ensemble ordonné de liens vers des fragments de la vidéo. En téléchargeant chaque fragment ou segment de la vidéo et en les lisant dans l'ordre, l'utilisateur peut regarder ce qui semble être une seule vidéo continue.
- EXTM3U
- #EXT-X-PLAYLIST-TYPE:VOD
- #EXT-X-TARGETDURATION:10
- #EXTINF:10,
- file-0001.ts
- #EXTINF:10,
- file-0002.ts
- #EXTINF:10,
- file-0003.ts
- #EXTINF:10,
- file-0003.ts
- #EXT-X-ENDLIST
Voici une liste de lecture m3u8 de base. Elle renvoie à quatre segments vidéo. Pour générer ces données par programme, il suffit d'indiquer le nom du fichier du premier élément, la durée cible des segments (dans ce cas, 10) et le nombre total de segments.
Manifeste HLS
Un manifeste HLS est une série non ordonnée de liens vers des listes de lecture. Il y a deux raisons d'avoir plusieurs listes de lecture : pour fournir différents débits binaires et pour fournir des listes de lecture de sauvegarde. Voici une liste de lecture typique où chaque .m3u8 est un lien relatif vers une autre liste de lecture HLS.
- #EXTM3U
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
- fichier-2040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
- fichier-1540k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
- fichier-1040k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
- fichier-640k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
- fichier-440k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
- fichier-240k.m3u8
- #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
- fichier-64k.m3u8
Les listes de lecture ont des débits et des résolutions variables afin d'assurer une lecture fluide quelles que soient les conditions du réseau. Pour générer un manifeste, il suffit de connaître les débits binaires de chaque liste de lecture et leurs chemins d'accès relatifs.
Remplir les blancs
Il existe de nombreuses autres informations importantes qu'une plateforme de vidéo en ligne doit capturer pour chaque ressource vidéo encodée : le codec vidéo, le codec audio, le conteneur et le débit binaire total n'en sont que quelques-unes. Les données stockées pour un seul élément vidéo doivent être significatives pour le spectateur (description, classement, distribution), significatives pour la plateforme (durée, vues, engagement) et significatives pour les applications (format, résolution, débit binaire). Grâce à ces données, vous permettez au spectateur de décider ce qu'il veut regarder, au système de décider comment programmer et à l'application de décider comment lire.
En saisissant les données nécessaires à la génération programmatique d'une liste de lecture, d'un manifeste et des informations sur les codecs pour chacune des listes de lecture, il devient possible de disposer d'un système dans lequel les manifestes et les listes de lecture sont générés par demande.
Exemple - La première liste de lecture
La spécification HLS détermine que la liste de lecture qui vient en premier dans le manifeste sera la première à être lue. Dans l'exemple de la section précédente, le premier élément de la liste était également la piste de meilleure qualité. Cela convient aux utilisateurs disposant d'une connexion internet rapide et stable, mais pour les personnes disposant d'une connexion plus lente, la lecture mettra un certain temps à démarrer.
Il serait préférable de déterminer si l'appareil semble disposer d'une bonne connexion internet, puis de personnaliser la liste de lecture en conséquence. Heureusement, grâce à la génération de manifestes dynamiques, c'est exactement ce que le système est conçu pour accomplir.
Pour les besoins de cet exercice, supposons qu'une demande de manifeste soit faite avec un tableau ordonné de débits binaires. Par exemple, la requête [2040,1540,1040,640,440,240,64] renverrait une liste de lecture identique à celle de la section précédente. Sur iOS, il est possible de déterminer si l'utilisateur est en connexion WiFi ou cellulaire. Étant donné que des données ont été saisies sur chaque liste de lecture, notamment le débit binaire, la résolution et d'autres paramètres de ce type, une application peut décider intelligemment de la manière d'ordonner le manifeste.
Par exemple, on peut déterminer qu'il est préférable de commencer entre 800-1200kbps si l'utilisateur est en WiFi et entre 200-600kbps si l'utilisateur est en connexion cellulaire. Si l'utilisateur est en WiFi, l'application demandera un tableau qui ressemblera à quelque chose comme : [1040,2040,1540,640,440,240,64]. Si l'application ne détecte qu'une connexion cellulaire, elle demandera [440,2040,1540,1040,640,240,64].
Exemple - Le dispositif hérité
Sur Android, la prise en charge de la vidéo est un peu une boîte noire. Pendant des années, la documentation officielle d'Android n'a pris en charge que les vidéos mp4 h.264 de 640×480, même si certains modèles pouvaient prendre en charge le 1080p. Dans le cas de HLS, le support est encore plus fragmenté et difficile à comprendre.
Heureusement, Android est dominé par une poignée d'appareils de premier plan. Grâce aux manifestes dynamiques, l'application peut non seulement cibler la meilleure liste de lecture pour commencer, mais aussi exclure les listes de lecture jugées incompatibles.
Étant donné que nos éléments multimédias capturent également des données telles que la résolution et les informations sur le codec, l'assistance peut être ciblée sur des appareils spécifiques. Une application pourrait décider d'envoyer tous les rendus : [2040,1540,1040,640,440,240,64]. Ou bien, un appareil plus ancien qui ne prend en charge que les images jusqu'à 720p pourrait supprimer le rendu le plus élevé : [1540,1040,640,440,240,64]. En outre, au-delà du monde des appareils mobiles, si l'application est une télévision connectée, elle pourrait supprimer les rendus de qualité inférieure : [2040,1540,1040,640].
Dynamique ou statique
Le choix d'un modèle de manifeste statique est parfaitement acceptable. Une certaine flexibilité est perdue, mais il n'y a rien de mal à la simplicité. De nombreux cas d'utilisation, en particulier dans le monde du contenu généré par l'utilisateur, ne requièrent pas le degré de complexité qu'implique la génération dynamique ; cependant, la génération dynamique de manifestes ouvre de nombreuses portes à ceux qui sont prêts à franchir le pas.
La façon dont les manifestes sont traités aura un impact significatif sur la flexibilité à long terme d'une plateforme vidéo, et c'est un point qui doit être discuté avec votre spécialiste de la compression.
