CRIM ― Documentation/Communications
Rapport technique
État de l’art des technologies et protocoles de diffusion
de contenu vidéo sur Internet
Première version
CRIM-14/12-01/DETI
Philippe Collard
Agent de recherche senior
Développement et technologies Internet
1er décembre 2014
Partenaire financier :
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
TABLE DES MATIÈRES
INTRODUCTION.................................................................................................... 3
1. TECHNOLOGIES DE DIFFUSION DE CONTENU VIDÉO SUR INTERNET.................................3
1.1 Téléchargement progressif (progressive download)...........................................3
1.2 Lecture continue (streaming)......................................................................4
1.3 Lecture continue adaptative (adaptive streaming)............................................5
2. PROTOCOLES DE LECTURE CONTINUE ADAPTATIVE DE CONTENU VIDÉO SUR INTERNET.......6
2.1 RTMP (Real Time Messaging Protocol)...........................................................7
2.1.1 Port............................................................................................. 7
2.1.2 DRM (Digital Rights Management)..........................................................7
2.1.3 Statistiques....................................................................................7
2.1.4 Plateformes et lecteurs.....................................................................7
2.1.5 Serveur......................................................................................... 8
2.1.6 Avantages et inconvénients de RTMP......................................................8
2.2 HLS (HTTP Live Streaming).........................................................................8
2.2.1 Port...........................................................................................10
2.2.2 DRM........................................................................................... 10
2.2.3 Statistiques..................................................................................11
2.2.4 Plateformes et lecteurs....................................................................11
2.2.5 Serveur.......................................................................................12
2.2.6 Avantages et inconvénients de HLS......................................................12
2.3 HDS (HTTP Dynamic Streaming)..................................................................13
2.4 HSS (HTTP Smooth Streaming)...................................................................13
2.5 Tableau résumé http (HLS, HDS’ HSS) vs RTMP.......................................................................14
2.6 Conclusions........................................................................................... 14
LISTE DES FIGURES.............................................................................................. 15
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
INTRODUCTION
Ce rapport technique propose de faire un examen des technologies et protocoles de
diffusion de contenu vidéo sur internet. Il propose d’abord un survol rapide des
technologies historiques. Bien que certaines soient encore utilisées de nos jours,
l’objectif de leur mention dans le contexte du présent rapport est surtout de mettre
en évidence leurs limites et d’apprécier les progrès ayant mené aux technologies
actuelles. Les technologies actuelles et les protocoles sous-jacents seront par contre
examinés en détail, pour permettre au lecteur éventuel de guider son choix dans le
cadre de son cas d’utilisation spécifique.
1. TECHNOLOGIES DE DIFFUSION DE CONTENU VIDÉO SUR INTERNET
L’ensemble des technologies de diffusion de contenu vidéo sur internet fonctionne sur
le modèle client-serveur : le client (typiquement un lecteur vidéo contenu dans une
page d’un site internet) fait une requête à un serveur distant pour un contenu vidéo.
Le serveur répond en envoyant un flux de données au client. Les données sont placées
temporairement dans la mémoire tampon du navigateur et le lecteur vidéo commence
la lecture dès que le volume de données reçues est suffisant pour jouer la vidéo sans
interruption.
1.1 Téléchargement progressif (progressive download)
Le téléchargement progressif ne nécessite pas de serveur spécialisé. Le fichier vidéo
est placé dans le répertoire public d’un site internet comme le serait une image, et le
lecteur vidéo lit le fichier sur le protocole HTTP.
Le lecteur vidéo attend en réponse du serveur les en-têtes contenant les métadonnées
du fichier ainsi qu’un volume de données suffisant pour commencer la lecture. Le
téléchargement du fichier s’effectue en un seul bloc du début à la fin (top to bottom)
et à l’aveugle sans communication du lecteur au serveur. Si la bande passante de
l’usager diminue en cours de lecture, le lecteur se met en pause en attendant la
reprise du téléchargement.
Avantage :
Les vidéos peuvent être diffusées par un serveur conventionnel tel que’Apache
dans son installation la plus simple.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
Inconvénients :
Impossibilité pour l’usager de sauter d’un point à l’autre de la vidéo, à moins que
celle-ci ait été téléchargée complètement.
Impossibilité de s’adapter à la qualité de la connexion côté client. Le diffuseur
peut mettre à disposition plusieurs versions de son contenu, mais c’est l’usager qui
doit choisir au départ la version qui lui convient.
Le fichier vidéo est téléchargé sur le disque dur de l’utilisateur dans le cache du
navigateur, ce qui ouvre la porte à la diffusion de multiples copies illégales.
Aucune gestion de droits d’auteur n’est possible.
1.2 Lecture continue (streaming)
En lecture continue, le contenu vidéo est diffusé en de multiples fragments de petite
taille. Le lecteur vidéo peut commencer la lecture immédiatement sans avoir à
attendre le remplissage d’une mémoire tampon importante. L’usager peut également
avancer et reculer dans la vidéo, et le lecteur peut initier la lecture à l’endroit choisi
presqu’immédiatement.
La lecture continue propose également pour certains protocoles un ensemble de
mesures visant à assurer une certaine qualité de service par une communication
bidirectionnelle entre le serveur et le lecteur. Par exemple, si la mémoire tampon du
lecteur ne se remplit pas suffisamment rapidement, le lecteur signale au serveur et se
met en pause en attendant la réception du fragment suivant.
Notons que l’on parle ici de lecture continue d’un seul et même fichier original, de
taille unique, sans variante de débit binaire. La lecture de plusieurs variantes d’un
même fichier fait l’objet du paragraphe sur la lecture continue adaptative ci-dessous.
La lecture continue nécessitait jusqu’à récemment la mise en place d’une
infrastructure côté serveur spécialisée, le plus souvent propriétaire et coûteuse; on
pense par exemple à Flash Media Server. Cet état de fait a changé dernièrement avec
l’introduction de protocoles de diffusion continue sur HTTP qui seront discutés plus loin
dans ce document.
Avantages :
La lecture peut se faire à partir de n’importe quel point de la vidéo choisi par
l’usager sans attendre le téléchargement au complet.
Meilleure utilisation de la bande passante.
Meilleure protection des droits d’auteurs, puisque la vidéo n’est jamais
téléchargée complètement sur le disque dur de l’usager.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
Inconvénients :
Peut être plus coûteuse à implémenter en infrastructure et logiciels selon le
protocole et la solution choisie.
La lecture continue peut être offerte sur les mêmes protocoles que la lecture
continue adaptative. Pour plus de détails, lire le chapitre 2. Par contre,
mentionnons la possibilité qu’offrent certains serveurs et lecteurs de diffuser du
contenu vidéo en mode byte serving : le serveur ne livre alors qu’une partie du
fichier vidéo, et ce, à partir de n’importe quel point de lecture spécifié par
l’usager dans le lecteur. Cette solution permet une lecture continue de n’importe
quel format et codec de vidéo supportés par un lecteur HTML5.
1.3 Lecture continue adaptative (adaptive streaming)
Ici, un diffuseur met à disposition sous une URL unique plusieurs variantes d’un même
original encodées à différentes résolutions et à différents débits binaires (bit rates).
Un lecteur vidéo capable de faire usage de cette technique peut automatiquement
passer d’un débit à l’autre en fonction des variations de la bande passante du client ou
de l’utilisation du processeur sur le poste du client.
Par exemple, un lecteur vidéo se connecte sur un flux de vidéo sur demande. Si après
quelques secondes, le lecteur détecte une trop grande utilisation du processeur du
poste client ou que sa mémoire tampon ne se remplit pas suffisamment rapidement
pour assurer une lecture fluide, il va automatiquement effectuer une transition vers
une variante à moindre débit, comme illustré ci-dessous (la ligne du bas côté serveur
représente un faible débit, la ligne du haut un grand débit).
Figure 1. Lecture continue adaptative (Source : Long Tail Video)
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
En proposant la lecture continue adaptative, un diffuseur peut garantir une expérience
optimale, que le client visionne la vidéo sur un téléphone branché à un réseau
cellulaire ou sur un poste fixe raccordé à une ligne sur fibre optique.
La lecture continue adaptative est la technique la plus répandue de nos jours et
facilement identifiable comme la plus pertinente pour la majorité des diffuseurs de
contenu :
Elle permet de livrer du contenu vidéo à une majorité de clients, peu importe leur
bande passante ou la capacité de leur processeur. On peut livrer la même vidéo (à
des niveaux de qualité différents bien sûr) à un téléphone mobile connecté au
réseau 3G ou à un ordinateur personnel disposant d’une connexion haute vitesse.
La qualité de visionnement sera toujours la meilleure possible quelles que soient
les ressources disponibles au niveau du client.
Elle permet de diffuser des vidéos à la demande et des événements en direct.
Puisqu’il s’agit de lecture continue, donc sans conservation du flux ou des
fragments de la vidéo dans le cache du navigateur, elle assure un minimum de
protection de droits d’auteurs.
Elle est utilisable par la plupart des lecteurs vidéo commerciaux ou en logiciel libre
présentement disponibles.
La lecture continue adaptative est développée par plusieurs compagnies et peut opérer
selon plusieurs protocoles dont les principaux sont RTMP (Adobe), HLS (Apple), HDS
(Adobe) et HSS (Microsoft). Ces protocoles sont discutés au chapitre suivant.
2. PROTOCOLES DE LECTURE CONTINUE ADAPTATIVE DE CONTENU VIDÉO SUR
INTERNET
On peut faire une première distinction des protocoles de lecture continue adaptative
en fonction du port sur lequel ils opèrent.
Le protocole RTMP (Real Time Messaging Protocol) fut le premier protocole de lecture
continue adaptative. Développé par Macromedia, il rejoint le catalogue Adobe lors du
rachat de la compagnie. Ce protocole propriétaire a été développé dans la seule
optique d’assurer la diffusion à partir de Flash Media Server vers un lecteur vidéo
Flash. Ce protocole utilise par défaut le port 1935. À noter cependant l’existence de la
variante RTMPT (Real Time Messaging Protocol Tunneling) qui encapsule RTMP pour le
transport sur HTTP.
HLS (HTTP Live Streaming), HDS (HTTP Dynamic Streaming) et HSS (HTTP Smooth
Streaming) utilisent par défaut le port 80.
Cette distinction est intéressante dans l’optique où les protocoles plus récents (HLS,
HDS et HSS) opèrent sur le port standard HTTP afin d’offrir un accès le moins restrictif
possible. Par exemple, en entreprise, ce port est toujours ouvert dans les pare-feux
corporatifs, alors qu’il est possible que le port 1935 nécessaire à RTMP soit fermé.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
2.1 RTMP (Real Time Messaging Protocol)
RTMP est un protocole développé par Macromedia, maintenant propriété d’Adobe, pour
diffuser en continu du contenu audio et/ou vidéo sur internet entre un serveur Flash
Media Server et un lecteur vidéo Flash. Ce protocole est défini comme stateful à savoir
qu’une session est établie entre le lecteur et le serveur dès que le lecteur initie la
connexion. La session ne sera abandonnée que quand le client se déconnectera. Au
cours de la session, le serveur reçoit une notification de chaque action de l’usager
(play, pause, stop) et envoie au lecteur un flux continu de données audio et/ou vidéo.
2.1.1 Port
RTMP utilise le port 1935 qui peut être bloqué par certains pare-feux d’entreprise,
empêchant l’usager de visionner la vidéo. Certains lecteurs corrigent cette situation en
tentant de se connecter sur un autre port au cas où la connexion sur le port 1935
échoue. Pour pallier à cet inconvénient, un diffuseur pourrait décider d’utiliser la
variante RTMPT du protocole (RTMP Tunneling). En RTMPT, le flux et les messages sont
encapsulés dans des requêtes HTTP pour traverser les pare-feux. RTMPT implique un
certain coût en bande passante, car les paquets sont plus volumineux.
2.1.2 DRM (Digital Rights Management)
RTMP offre un support de DRM avancé et généralement considéré comme acceptable
dans des contrats de droits de diffusion. Cette gestion des droits repose sur
l’encryption des flux, soit en RTMPE (RTMP Encrypted) qui est un mécanisme
d’encryption léger propriétaire à Adobe, soit en RTMPS (RTMP Secure) qui diffuse
simplement le flux en SSL. Ces protocoles dérivés empêchent la sauvegarde d’un
fichier vidéo sur un poste local, décourageant la multiplication de copies illicites.
2.1.3 Statistiques
RTMP permet de connaître de façon très granulaire des actions de l’usager dans le
lecteur. D’un point de vue statistique, il s’agit du protocole le plus avancé puisqu’on
peut savoir exactement, par exemple, jusqu’où la vidéo à été écoutée, combien de
minutes, ou l’usager a-t-il avancé ou reculé à un autre point de la vidéo avec la barre
de défilement.
2.1.4 Plateformes et lecteurs
L’inconvénient majeur du protocole RTMP, puisqu’il a été développé au départ pour un
lecteur Flash, est qu’il est difficile de diffuser sur iOS et Android avec ce protocole,
puisque aucune de ces deux plateformes ne supporte Flash. Une recherche montre
qu’il existe des façons de contourner cette limitation, mais aucune ne s’est révélée
facile pour diffusion sur un site internet, la plupart demandant le développement
d’une application native.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
2.1.5 Serveur
Un autre inconvénient à noter est la nécessité de diffuser via un serveur spécialisé, à
savoir Adobe Media Server. Certaines infrastructures de CDN (Content Delivery
Network) peuvent également avoir un prix plus élevé pour la diffusion de flux RTMP.
2.1.6 Avantages et inconvénients de RTMP
Avantages :
Technologie mature et largement adoptée.
Statistiques de visionnement avancées.
Gestion des droits avancée.
Inconvénients :
Nécessite un serveur spécialisé.
Nécessite un lecteur Flash, donc pas de diffusion sur iOS ou Android.
Port 1935, donc risque de blocage, RTMPT possible, mais plus coûteux au point de
vue bande passante et overhead.
Les CDN peuvent être plus chers.
2.2 HLS (HTTP Live Streaming)
HLS a été développé par Apple et, contrairement à ce que son nom l’indique, permet
aussi bien la diffusion d’événements en direct que de vidéos à la demande. À l’origine,
ce protocole a été développé pour iOS et le lecteur QuickTime, mais le support pour
Android a été récemment ajouté, ce qui en fait un candidat idéal pour la diffusion sur
plateformes mobiles. Un nombre important de lecteurs vidéo sont compatibles avec ce
protocole, par exemple JWPlayer, ainsi que le lecteur HTML5 de plusieurs navigateurs.
HLS se caractérise par le fait que ce n’est pas le fichier vidéo original qui est
disponible dans le flux, mais une segmentation de celui-ci en de multiples fragments
de courte durée, typiquement 10 secondes, qui sont livrés les uns après les autres dans
la mémoire tampon du lecteur, de façon similaire à la lecture progressive.
Les segments vidéo HLS portent l’extension .ts et sont référencés dans un manifeste
(ou playlist) portant l’extension .m3u8 que le lecteur va utiliser pour référencer les
fragments.
Exemple de manifeste simple :
#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10.0,
http://example.com/movie1/fileSequenceA.ts
#EXTINF:10.0,
http://example.com/movie1/fileSequenceB.ts
#EXTINF:10.0,
http://example.com/movie1/fileSequenceC.ts
#EXTINF:9.0,
http://example.com/movie1/fileSequenceD.ts
#EXT-X-ENDLIST
Le manifeste ci-dessus définit un flux HLS simple sans variante, c’est-à-dire sans
possibilité de lecture adaptative. Pour définir un flux de lecture continue adaptative,
on va fournir au lecteur vidéo un manifeste qui pointe vers d’autres manifestes, chacun
définissant une variante. Par exemple :
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-
ID=1,BANDWIDTH=150000,RESOLUTION=416x234, \
CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/low/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-
ID=1,BANDWIDTH=240000,RESOLUTION=416x234, \
CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/lo_mid/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-
ID=1,BANDWIDTH=440000,RESOLUTION=416x234, \
CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/hi_mid/index.m3u8
#EXT-X-STREAM-INF:PROGRAM-
ID=1,BANDWIDTH=640000,RESOLUTION=640x360, \
CODECS="avc1.42e00a,mp4a.40.2"
http://example.com/high/index.m3u8
À noter que, tout comme pour la lecture progressive, il n’y a pas de communication
avancée entre le lecteur et le serveur : le serveur livre des fichiers à la façon typique
d’un serveur web sans aucune connaissance de ce qui se passe au niveau du lecteur.
C’est le lecteur qui va gérer la concaténation des segments ou le passage d’une qualité
de flux à une autre, en adaptant tout simplement la destination de ses requêtes HTTP
vers un autre fichier manifeste.
La segmentation du fichier original est faite au niveau du transcodage en
postproduction (segmenteur), les segments .ts sont alors générés à partir du fichier
original et stockés sur le disque, ou générés au vol à partir du fichier original. C’est par
exemple le modèle d’opérations d’Adobe Media Server.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
Figure 2. HLS Streaming Architecture (Source : Auro Tripathy)
2.2.1 Port
HLS opère sur le port standard HTTP. Il n’y a donc aucune restriction vis-à-vis des pare-
feux. Ceci permet aussi également la diffusion du contenu par un CDN, et ce, sans coût
additionnel.
À noter que comme les fragments peuvent être générés au transcodage en
postproduction et stockés tels quels sur disque, il n’est pas nécessaire d’avoir un
serveur spécialisé pour HLS. Un serveur web standard, Apache ou IIS, est capable de
livrer un flux vidéo HLS. Cependant, pour la génération au vol des segments, un
serveur spécialisé est nécessaire. Adobe Media Server offre cette fonctionnalité, ce qui
réduit grandement les efforts en postproduction, surtout si le diffuseur dispose d’un
inventaire de fichiers vidéos volumineux qu’il souhaite mettre en ligne.
2.2.2 DRM
La gestion des droits de diffusion avec HLS n’est pas aussi complète ni globalement
acceptée juridiquement qu’avec RTMP. Cependant, des progrès ont été faits
dernièrement et HLS spécifie maintenant un mécanisme d’encryption utilisant AES
(Advanced Encryption Strandard) et une méthode de distribution de clés sécurisées sur
HTTPS. Cependant, il semble que ces mécanismes soient ardus à mettre en œuvre.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
2.2.3 Statistiques
Le manque de statistiques avancées est probablement l’inconvénient majeur de HLS et
ceci est dû à la technologie elle-même.
HLS est stateless, ce qui signifie qu’il n’y a pas d’établissement d’une session entre le
lecteur et le serveur. On ne peut pas avoir de statistiques en rapport à une session, par
exemple pas de corrélation entre les téléchargements de fichiers manifestes et de
fragments.
Nombre d’entrées dans les logs du serveur : Vu le nombre élevé de fragments et le
nombre de variantes du fichier original pour différents débits binaires, il est très
difficile de générer des statistiques de visionnement à partir des logs d’accès du
serveur.
Problème de cache : Comme les fragments sont transportés sur http, il est possible
qu’ils soient mis en cache à un point quelconque du réseau entre le serveur et le
lecteur (serveur, CDN, proxy). Un même fragment peut être servi plusieurs fois à
différents usagers par exemple et son téléchargement n’apparaîtra donc pas dans les
logs.
Il est cependant possible de palier à ces inconvénients en implémentant des
déclencheurs d’événements dans l’API Javascript d’un lecteur, par exemple pour
garder une trace des play, pause, stop, forward, etc., et en injectant ces événements
par exemple dans Google Analytics.
2.2.4 Plateformes et lecteurs
HLS a été développé principalement pour offrir la lecture continue adaptative sur iOS
et pour le lecteur QuickTime. Par la suite, Apple a ajouté le support pour Android et
pour le lecteur HTML5 dans Safari. Officiellement, Apple ne supporte que ces
plateformes. Cependant, il est important de noter que plusieurs lecteurs Flash offrent
maintenant un support pour HLS. On pense par exemple à JWPlayer (commercial) ou a
Strobe Media Playback (logiciel libre). Dans ce dernier cas, le lecteur ne supporte pas
HLS par défaut, mais il existe un plugin en logiciel libre développé en marge du projet
principal pour supporter HLS.
Vu la possibilité de lire un flux HLS en natif sur iOS, dans un lecteur HTML5 sur Safari,
sur une partie des appareils Android et que plusieurs lecteurs Flash offrent la
possibilité de supporter HLS, on peut considérer que ce protocole est un excellent
candidat pour une diffusion la plus large possible. Bien sûr, il n’est pas supporté
nativement par plusieurs navigateurs, mais l’ajout d’un lecteur Flash propriétaire, par
exemple JWPlayer, supportant HLS permet de palier à cet inconvénient pour un coût
minime.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
2.2.5 Serveur
Un flux HLS peut être servi par un serveur web standard, puisqu’il suffit de livrer dans
un premier temps un fichier manifeste, puis les fragments un par un, comme s’il
s’agissait de tout autre contenu disponible sur HTTP (image, texte, PDF). C’est le
lecteur qui contrôle entièrement le choix du débit binaire à travers le manifeste, le
téléchargement des fragments et leur assemblage pour une lecture fluide.
Cependant, ce cas d’utilisation implique que les fichiers maîtres aient été au préalable
segmentés ou fragmentés en postproduction et placés dans l’arborescence du serveur,
ce qui demande des ressources importantes en temps et utilisation du matériel.
À titre d’essai, nous avons expérimenté le logiciel Anderson Squeeze.
Source : vidéo au format .mp4 / résolution 640x400 px / durée 1 min. / taille 5.5 MB
Destination : deux ensembles de fragments .ts pour HLS / deux résolutions différentes
/ six débit binaires différents pour chaque résolution.
Durée de la conversion sur un Mac i7 avec 16GB de RAM : 2 minutes 5 secondes.
Résultat : 413 fichiers (fragments et manifestes) pour un total de 243,3 MB.
On le voit, même si en théorie on peut servir des flux HLS avec un serveur web
traditionnel, le processus de fragmentation en postproduction, le nombre de fichiers
générés et leur volume rendent l’opération assez peu pratique.
Heureusement, les serveurs spécialisés comme Adobe Media Server peuvent fragmenter
au vol et à la demande des fichiers originaux, au coût d’un peu plus d’utilisation de
ressources du serveur, mais avec le bénéfice de ne pas avoir à gérer la fragmentation
en postproduction et les centaines de fichiers générés.
2.2.6 Avantages et inconvénients de HLS
Avantages :
Sur le port 80, donc pas de restriction au niveau des pare-feux.
Peut-être diffusé à partir d’un serveur web standard (à partir du moment où les
fichiers originaux sont segmentés en postproduction).
Les fragments disposent des mêmes mécanismes de mise en cache que tout autre
contenu sur HTTP.
Pas de coût supplémentaire pour les CDN.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
Inconvénients :
Statistiques de base uniquement (pouvant être améliorées par l’API Javascript des
lecteurs).
DRM moins avancé que RTMP.
Si pas de serveur spécialisé, les fichiers vidéo doivent être segmentés en
postproduction, le processus étant assez lourd.
Pas officiellement supporté dans un lecteur Flash (mais beaucoup de lecteurs
implémentent le protocole sous forme de plugin).
2.3 HDS (HTTP Dynamic Streaming)
HDS a été développé par Adobe afin de proposer une alternative à leur propre
protocole RTMP. HDS propose une lecture continue adaptative sur HTTP à destination
de toutes les plateformes disposant d’Adobe Flash ou Air. D’après Adobe, le bénéfice
majeur de HDS est de permettre la diffusion de contenu grâce un serveur web
classique, sans la nécessité d’un serveur spécialisé comme Adobe Media Server. Adobe
a d’ailleurs développé un module (plugin) de diffusion HDS pour Apache disponible
gratuitement.
Techniquement, HDS fonctionne de façon très similaire à HLS, en fragmentant un
fichier source en de multiples segments courts, puis en les diffusant sur HTTP. Une
différence importante est que les fichiers manifestes sont écrits au format XML, alors
que les manifestes HLS sont écrits en texte plein. Également, comme on l’a noté ci-
dessus, HDS n’est compatible qu’avec Adobe Flash ou Air.
On peut dès lors se demander quels sont les avantages réels de HDS par rapport à HLS?
On trouve sur internet quelques articles le plus souvent écrits par des employés
d’Adobe vantant les mérites de HDS, notamment la séparation des métadonnées du
contenu audio ou vidéo qui permettrait de diffuser un même fichier vidéo, mais en
différentes langues, ou permettant à l’usager de choisir son angle de vue, un DRM
intégré au format MPEG-4 dont HDS peut faire usage, ou encore une meilleure
utilisation des mécanismes de cache et de bande passante.
Dans les faits, Adobe, au lieu de tenter d’obtenir une implémentation de plus en plus
improbable de Flash sur les plateformes mobiles, a décidé de supporter Apple HLS dans
Adobe Media Server et Flash Media Encoder. Peut-être un aveu implicite de leur part
signifiant que le futur de la diffusion de vidéos sur internet passe par des lecteurs
n’étant pas bâtis sur Flash.
2.4 HSS (HTTP Smooth Streaming)
HSS est la tentative de Microsoft d’entrer dans le marché de la lecture continue
adaptative. HSS est livré par Microsoft IIS et lu dans un lecteur Silverlight qui agit
comme un lecteur Flash en détectant l’utilisation de la bande passante et du
processeur, et en adaptant en conséquence la qualité du flux. HSS est fortement
configurable et est compatible avec de nombreux codecs audios et vidéos. Il est parfois
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
utilisé pour des diffusions à grande échelle, par exemple la couverture des jeux
olympiques par NBC, et fait partie de la panoplie de diffusions de Netflix.
Les flux HSS fonctionnent comme HLS et HDS. Les fichiers originaux sont segmentés au
vol par IIS et diffusés sur HTTP. Une des différences techniques entre HSS et HLS est
que pour HLS, le lecteur fait une requête implicite vers le nom du fragment qu’il veut
lire, tandis que HSS fait une requête pour le nom du fichier original plus un timecode
pour identifier le segment à lire. IIS peut donc stocker les fichiers sous une forme
agrégée, alors qu’un serveur web standard doit stocker l’ensemble des fragments sous
forme de fichiers séparés. Donc, moins de fichiers, moins de problèmes de stockage. Le
revers de la médaille est que ISS demande plus de ressources pour livrer un flux HSS en
segmentant au vol les fichiers originaux, tout comme Adobe Media Server le fait pour
les flux HLS.
2.5 Tableau résumé http (HLS, HDS’ HSS) vs RTMP
HTTP (HLS, HDS, HSS) RTMP
Serveur Standard Spécialisé
Sécurité et DRM Base Avancé
Mise en cache Native Spécialisée
Interactivité avec le lecteur Base Avancée
Disponibilité d’un lecteur sur Excellente Restrictions (iOS, Android)
diverses plateformes
Pare-feux Pas de restriction Restions possibles
2.6 Conclusion
HDS et HSS sont des nouveaux venus qui ne semblent pas être des joueurs majeurs dans
l’industrie ou s’appliquer particulièrement à un modèle de diffusion large de contenu
vidéo sur internet, donc le choix d’un diffuseur reviendrait logiquement à HLS ou
RTMP. Il faut alors peser les pour et les contre pour chaque aspect tel que résumé dans
le tableau ci-dessus, en s’attardant surtout aux plateformes ciblées, à la nécessité
d’un DRM avancé et à l’interactivité avec le lecteur. En tenant compte également du
fait que RTMP est une technologie plus mature, mais peut-être en voie d’être
supplantée par HLS.
Tous droits réservés 2014 Le 1er décembre
2014
Rapport technique
État de l’art des technologies et protocoles de diffusion de contenu video sur Internet
LISTE DES FIGURES
Figure 1. Lecture continue adaptative.....................................................................5
Figure 2. HLS Streaming Architecture.....................................................................10
Tous droits réservés 2014 Le 1er décembre
2014
