- Entreprise TI/AV
Le mode de fonctionnement du streaming vidéo en ligne a changé
Dans l'écosystème vidéo, il est rare que des technologies concurrentes coexistent pacifiquement pendant longtemps.
La désormais célèbre guerre des formats de cassettes vidéo de la fin des années 1970 et des années 1980 a démontré la rapidité avec laquelle l'industrie pouvait basculer en faveur d'une technologie, et l'impact dévastateur que cela pouvait avoir sur ses concurrents. Lorsque l'industrie a voté collectivement pour le VHS en 1975, il a fallu moins de trois ans pour que cette technologie supplante le Betamax. Lors d'un changement ultérieur du marché entre 1999 et 2004, les ventes de VHS ont été dépassées, puis rapidement éclipsées, par les DVD.
From Beta to VHS to DVD: Case studies in how suddenly the video ecosystem can tip.
Sources: Business History Review, Nexus Research.
Les médias en ligne ont connu des changements sismiques similaires. En janvier 2010, seulement 10 % des vidéos en ligne étaient codées à l'aide du format de compression H.264. Moins de deux ans plus tard, ce chiffre était passé à 80 % (MeFeedia).
À chacun de ces horizons, l'inertie du marché a cédé à une technologie média dont le temps était venu. Et en 2015, l'industrie s'approche de son prochain point de non-retour.
Au cours des dix à douze dernières années, la vidéo en ligne est devenue essentielle à la façon dont les gens se divertissent, dont les étudiants apprennent et dont les entreprises communiquent. On estime que plus des deux tiers du trafic Internet grand public mondial est déjà constitué de vidéo (Cisco), et que les grandes entreprises diffusent déjà plus de 14 heures de vidéo par employé et par mois (Gartner).
Au cours de cette période, la technologie de distribution des médias a évolué en quatre phases.
L'évolution de la technologie de diffusion de médias en ligne
1. Téléchargement HTTP
Lorsque les fichiers vidéo ont été partagés en ligne pour la première fois, ils ont été distribués à l'aide du protocole de transfert hypertexte (HTTP), le même mécanisme de diffusion que celui utilisé par les pages HTML, les images, les documents et d'autres types de contenu sur le web.
Au départ, les vidéos devaient être téléchargées dans leur intégralité avant de pouvoir être lues. Ce processus, appelé download and play, présentait plusieurs inconvénients notables. Premièrement, les vitesses d'accès par ligne commutée de 28 à 56 kbps signifiaient que les utilisateurs devaient presque toujours faire face à de longs délais de lecture. Ensuite, il n'existait pas de mécanisme permettant de s'adapter efficacement à plusieurs utilisateurs simultanés. Enfin, la bande passante limitée était souvent gaspillée sur des segments de vidéo non visionnés. Par exemple, si un utilisateur cliquait sur une vidéo de 10 minutes et n'en regardait que les trois premières, les sept minutes restantes étaient inutilement téléchargées sur le réseau.
Apple a résolu certains des problèmes liés au téléchargement de vidéos par HTTP en mettant en place la prise en charge de Fast Start, plus connue sous le nom de téléchargement HTTP progressif. Cette approche plaçait les métadonnées importantes en haut du fichier multimédia, ce qui permettait de commencer la lecture de la vidéo avant le téléchargement complet du fichier. Bien que le téléchargement progressif soit encore utilisé aujourd'hui, il a été largement supplanté au début des années 2000 par des protocoles et des serveurs personnalisés conçus pour un nouveau type de diffusion vidéo en ligne appelé streaming.
Le téléchargement HTTP progressif a amélioré le temps de démarrage, mais il a toujours souffert du gaspillage de la bande passante et d'une échelle limitée.
2. Protocoles de streaming personnalisés
Comparés à d'autres types de contenus partagés en ligne, les fichiers vidéo sont massifs. Une seule minute de vidéo iPhone peut occuper jusqu'à 80 à 120 Mo d'espace disque. Dans ce même espace, vous pourriez stocker entre 250 et 350 documents Word de taille moyenne (Microsoft).
Cette caractéristique rendait difficile la distribution de fichiers vidéo sur des réseaux à bande passante limitée. Ainsi, à mesure que la vidéo devenait plus courante sur le Web et dans les réseaux d'entreprise, les sociétés de médias et les fournisseurs de logiciels ont commencé à développer des protocoles personnalisés pour le streaming vidéo. RealNetworks et Netscape ont collaboré au développement et à la normalisation du protocole RTSP (Real Time Streaming Protocol). Adobe, par le biais de son acquisition de Macromedia, a mis en œuvre le protocole RTMP (Real Time Messaging Protocol) pour la diffusion vidéo en continu basée sur Flash. Microsoft a développé un troisième protocole de diffusion en continu, Microsoft Media Server (MMS), destiné à être utilisé dans diverses applications Windows.
RTSP, RTMP et MMS ont tous traité la vidéo comme un cas particulier. Ils ont construit des "réseaux superposés" dans lesquels des serveurs de diffusion en continu spécifiques au protocole côtoient des serveurs HTTP traditionnels. Lorsqu'un utilisateur lance une demande de lecture d'une vidéo, celle-ci est acheminée vers le serveur de diffusion en continu, qui ouvre alors une connexion persistante (ou " à état ") avec le lecteur vidéo de l'utilisateur.
Les protocoles de streaming personnalisés ont nécessité des serveurs spécialisés, la configuration d'un pare-feu et une infrastructure de mise en cache distincte.
Les protocoles de streaming personnalisés ont permis de surmonter bon nombre des difficultés liées au téléchargement progressif HTTP. La vidéo est mise en mémoire tampon, traitée et lue au fur et à mesure qu'elle est diffusée sur le réseau, ce qui permet aux utilisateurs d'abandonner une vidéo au milieu du flux avec une perte minimale de bande passante. L'accès aléatoire est pris en charge, ce qui permet aux spectateurs de rechercher et de lancer rapidement la lecture à partir de n'importe quel point de la vidéo. La connexion permanente entre le serveur de streaming et le client a permis de mieux prévoir la latence. Et dans tous les cas, ces réseaux superposés ont aidé les entreprises à décharger le trafic vidéo du transport WAN primaire, réduisant ainsi le risque que la congestion vidéo compromette la diffusion d'informations et de données transactionnelles plus prioritaires.
RTMP, RTSP et MMS n'étaient cependant pas sans limites. Comme ces protocoles traitaient la vidéo comme un type de données particulier, ils augmentaient le coût et la complexité de la diffusion vidéo. Tout d'abord, ces protocoles nécessitaient le déploiement d'un ensemble distinct de serveurs spécialisés sur le réseau de l'entreprise, ce qui augmentait les coûts d'infrastructure matériels et logiciels. Deuxièmement, les protocoles de diffusion en continu créaient un lien entre les mécanismes de diffusion et de mise en cache. Les entreprises devaient donc prendre en charge deux technologies de mise en cache distinctes (une pour le trafic HTTP, une pour la vidéo), ce qui doublait la complexité de la gestion du réseau. Troisièmement, RTMP, RTSP et MMS ont obligé les administrateurs à ouvrir des ports réseau supplémentaires pour la communication (1935, 554 et 1755 respectivement). Cela élargit la surface d'attaque du réseau et augmente la probabilité que les protocoles soient bloqués par les pare-feu de l'entreprise. Enfin, les protocoles de streaming personnalisés étaient souvent incompatibles avec les appareils mobiles. Par exemple, RTMP nécessitait Flash pour la lecture, un format qui, comme on le sait, n'est pas pris en charge par les appareils iOS. Au-delà de l'écosystème iOS, les clients mobiles connaissent fréquemment des interruptions de connectivité et des changements d'adresse IP. La connexion RTMP active doit donc souvent être rétablie plusieurs fois au cours d'un même événement.
3. Technologie de diffusion vidéo multicast
L'affirmation selon laquelle la multidiffusion a constitué une phase distincte de la diffusion vidéo en ligne est généreuse, étant donné que la technologie n'a jamais atteint la masse critique ni dans les entreprises ni sur l'Internet grand public. Cependant, le multicast pour la vidéo a suscité un vif intérêt au milieu des années 2000 et la technologie persiste dans certains réseaux d'entreprise.
La multidiffusion est une technologie de réseau qui permet à un expéditeur de distribuer les mêmes données à plusieurs destinataires en même temps. D'un point de vue conceptuel, c'est un peu comme écouter la radio. Un seul signal radio est envoyé à tous les auditeurs, plutôt que d'envoyer des signaux uniques à chaque personne qui écoute. Lorsqu'elle est mise en œuvre correctement, la multidiffusion permet de réaliser des gains d'efficacité incroyables dans la transmission des données. Cela a suscité une période d'intérêt pour l'utilisation de la multidiffusion pour la diffusion vidéo.
Grâce à la multidiffusion, une organisation peut théoriquement diffuser des vidéos en direct sur le réseau de l'entreprise en utilisant une fraction de la bande passante requise par la transmission traditionnelle unicast . Par conséquent, les entreprises ont souvent considéré la multidiffusion comme un moyen d'obtenir un retour sur investissement supplémentaire de leurs réseaux à bande passante limitée plutôt que de mettre à niveau leur infrastructure réseau.
La transmission unicast (à gauche) envoie un flux unique pour chaque client connecté, tandis que la transmission multicast (à droite) envoie un flux unique qui est partagé par tous les clients abonnés.
Malheureusement, les exigences en matière d'infrastructure de la multidiffusion la rendaient irréalisable pour la plupart des organisations. Pour distribuer de la vidéo (ou toute autre donnée) à l'aide de la multidiffusion, la source, les destinataires et l'infrastructure du réseau de connexion devaient tous prendre en charge le protocole. Plus précisément, chaque routeur, concentrateur, commutateur et pare-feu d'un réseau d'entreprise devait être compatible avec la multidiffusion. Cette exigence d'une infrastructure homogène n'était ni pratique ni résiliente.
Par exemple, si une tentative de communication multicast échouait, la solution de repli était généralement une transmission unicast traditionnelle. Dans la plupart des cas, cette transmission monodiffusion ne bénéficiait d'aucune optimisation du réseau, comme la mise en cache des données ou d'autres techniques d'accélération du réseau étendu, puisque la multidiffusion était la seule forme d'optimisation mise en œuvre.
En outre, comme la multidiffusion exigeait un environnement de réseau homogène, elle était fondamentalement incompatible avec les topologies de réseau qui dominent encore les communications en ligne des entreprises et des consommateurs. L'internet est conçu pour un large éventail de vitesses de réseau, de types de connexion, de qualité de service (QoS) et de dispositifs d'extrémité. Son fondement est le protocole HTTP, un protocole sans état et indépendant du support, conçu spécifiquement pour fonctionner dans cet environnement hétérogène. De même, les réseaux situés derrière les pare-feu des entreprises sont de plus en plus hétérogènes. La tendance au BYOD (bring-your-own-device) signifie que les employés transportent toute une série de tablettes et de smartphones aux capacités et aux exigences réseau variées. Et la consolidation continue du secteur fait qu'il est de moins en moins probable qu'une succursale nouvellement acquise à Londres utilise la même architecture réseau que le siège social à Seattle.
En résumé, la multidiffusion était une aspiration noble mais irréaliste pour la diffusion vidéo. Au cours de la dernière décennie, l'intérêt pour cette technologie n'a cessé de diminuer.
Intérêt pour la multidiffusion, 2004-2015. Source : Google Trends.
4. Streaming HTTP moderne
En 2008, Microsoft a introduit Smooth Streaming, une approche hybride de la diffusion vidéo qui offrait de nombreux avantages des protocoles de diffusion personnalisés tout en exploitant HTTP et l'infrastructure réseau existante. Smooth Streaming prenait également en charge la diffusion à débit binaire adaptatif (ABR), offrant aux spectateurs des temps de démarrage et de recherche plus rapides, une mise en mémoire tampon minimale et une expérience de lecture plus fluide.
Le streaming à débit binaire adaptatif offre des temps de démarrage et de recherche plus rapides, une mise en mémoire tampon minimale et une expérience de lecture fluide en ajustant dynamiquement la qualité vidéo en fonction de la vitesse de connexion du client.
Le streaming basé sur le protocole HTTP a rapidement pris de l'ampleur, et d'autres leaders du marché ont rapidement investi dans cette technologie. En 2009, Apple est entré sur le marché avec l'introduction du streaming HTTP Live (HLS). En 2010, Adobe s'est détourné des protocoles de streaming personnalisés en lançant HTTP Dynamic Streaming (HDS). Et depuis 2010, les principales sociétés de streaming et de médias, dont Microsoft, Google, Adobe, Netflix, Ericsson et Samsung, collaborent sur MPEG-DASH, une norme ouverte pour le streaming vidéo adaptatif sur HTTP.
Des innovations telles que Smooth Streaming, HLS, HDS et DASH ont entraîné une résurgence de la diffusion vidéo basée sur le protocole HTTP et un bouleversement de la manière dont les entreprises distribuent la vidéo sur leurs réseaux.
En savoir plus sur le streaming vidéo en ligne
Dans notre dernier livre blanc, Modern vidéo Streaming in the Enterprise : Protocoles, mise en cache et optimisation du réseau étendu, nous examinerons plus en détail les changements techniques qui conduisent à l'évolution vers le streaming moderne, y compris les sept caractéristiques qui font qu'un protocole de streaming vidéo est moderne.
Nous examinerons également les nouvelles possibilités qu'offre le Streaming moderne aux organisations pour utiliser l'infrastructure réseau existante afin de diffuser des vidéos de manière plus évolutive et plus rentable.
Téléchargez votre exemplaire dès aujourd'hui !