• Informatique/AV d'entreprise

Le 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 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 la concurrence. 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 de marché ultérieur, entre 1999 et 2004, les ventes de VHS ont été dépassées, puis rapidement éclipsées, par celles des DVD.

 

Transformation des technologies vidéo au fil des décennies
Du Beta au VHS puis au DVD : études de cas sur la rapidité avec laquelle l’écosystème vidéo peut basculer.
Sources : Business History Review, Nexus Research.

 

Les médias en ligne ont connu des bouleversements similaires. En janvier 2010, seulement 10 % des vidéos en ligne étaient encodées au format de compression H.264. Moins de deux ans plus tard, ce chiffre avait explosé pour atteindre 80 % (MeFeedia).

 

Pourcentage de vidéos encodées en H264

 

Dans chacun de ces horizons d'événements, l'inertie du marché a cédé la place à une technologie médiatique dont l'heure était venue. Et en 2015, le secteur approche de son prochain point de non-retour.

 Ces dix à douze dernières années, la vidéo en ligne est devenue incontournable dans les loisirs, l'apprentissage et la communication des entreprises. On estime que plus des deux tiers du trafic internet mondial des consommateurs sont déjà constitués de vidéo ( Cisco ), et que les grandes entreprises visionnent déjà plus de 14 heures de vidéo par employé et par mois (Gartner).

 

La vidéo en pourcentage du trafic web total

La vidéo continue de croître et représente déjà une part prépondérante du trafic internet total. Source : Cisco

 

Durant cette période, la technologie de distribution des médias a évolué en quatre phases.

 

L'évolution de la technologie de diffusion multimédia en ligne

1. Téléchargement HTTP

Lorsque les fichiers vidéo ont été partagés en ligne pour la première fois, ils étaient distribués via le protocole de transfert hypertexte (HTTP) — le même mécanisme de diffusion utilisé par les pages HTML, les images, les documents et autres types de contenu web.

Au départ, les vidéos devaient être téléchargées intégralement avant de pouvoir être visionnées. Ce processus, appelé « téléchargement et lecture » , présentait plusieurs inconvénients majeurs. Premièrement, avec des débits de connexion commutés de 28 à 56 kbit/s, les utilisateurs subissaient presque systématiquement de longs délais de lecture. Deuxièmement, aucun mécanisme ne permettait de gérer efficacement plusieurs visionnages simultanés. Enfin, la bande passante limitée était souvent gaspillée pour 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 téléchargées inutilement sur le réseau.

Apple a résolu certains problèmes liés au téléchargement vidéo via HTTP en introduisant la prise en charge de Fast Start , plus communément appelé téléchargement progressif HTTP. Cette approche place les métadonnées importantes en haut du fichier multimédia, permettant ainsi de commencer la lecture vidéo avant même que le fichier ne soit entièrement téléchargé. 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 dédiés, conçus pour un nouveau type de diffusion vidéo en ligne : le streaming .

 

Illustration de la diffusion vidéo HTTP progressive

Le téléchargement HTTP progressif a amélioré le temps de démarrage, mais souffrait toujours d'un gaspillage de bande passante et d'une capacité limitée.

 

2. Protocoles de diffusion personnalisés

Comparativement aux autres types de contenu partagés en ligne, les fichiers vidéo sont volumineux. Une seule minute de vidéo iPhone peut occuper entre 80 et 120 Mo d'espace disque. Dans le même espace, on pourrait 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, avec la généralisation de la vidéo sur le web et dans les réseaux d'entreprise, les sociétés de médias et les éditeurs de logiciels ont commencé à développer des protocoles personnalisés pour la diffusion vidéo. RealNetworks et Netscape ont collaboré au développement et à la normalisation du protocole RTSP (Real Time Streaming Protocol). Adobe, suite à l'acquisition de Macromedia, a implémenté le protocole RTMP (Real Time Messaging Protocol) pour la diffusion vidéo Flash. Microsoft a développé un troisième protocole de diffusion, Microsoft Media Server (MMS), destiné à diverses applications Windows.

Les protocoles RTSP, RTMP et MMS traitaient la vidéo comme un cas particulier. Ils construisaient des « réseaux superposés » où des serveurs de streaming dédiés coexistaient avec des serveurs HTTP classiques. Lorsqu'un utilisateur lançait une requête de lecture vidéo, celle-ci était acheminée vers le serveur de streaming, qui établissait alors une connexion persistante (ou « avec état ») avec le lecteur vidéo de l'utilisateur.

 

Protocoles de diffusion vidéo personnalisés illustrés

Les protocoles de streaming personnalisés nécessitaient des serveurs spécialisés, une configuration de pare-feu et une infrastructure de mise en cache distincte.

 

Les protocoles de streaming personnalisés ont permis de surmonter de nombreuses difficultés liées au téléchargement progressif HTTP. La vidéo était mise en mémoire tampon, traitée et lue en temps réel lors de sa diffusion sur le réseau, permettant ainsi aux utilisateurs d'interrompre la lecture d'une vidéo en cours avec une consommation de bande passante minimale. L'accès aléatoire était pris en charge, permettant aux spectateurs de se positionner et de démarrer rapidement la lecture à partir de n'importe quel point de la vidéo. La connexion permanente entre le serveur de streaming et le client garantissait une latence plus prévisible. Enfin, dans tous les cas, ces réseaux superposés ont permis aux organisations de décharger le trafic vidéo du réseau étendu principal, réduisant ainsi le risque que la congestion du trafic vidéo ne compromette la diffusion d'informations prioritaires et de données transactionnelles.

Les protocoles RTMP, RTSP et MMS présentaient toutefois des limitations. Considérant la vidéo comme un type de données particulier, ils augmentaient le coût et la complexité de sa diffusion. Premièrement, ils nécessitaient le déploiement d'un ensemble distinct de serveurs spécialisés sur le réseau d'entreprise, engendrant des coûts d'infrastructure matérielle et logicielle supplémentaires. Deuxièmement, les protocoles de streaming créaient une interdépendance entre les mécanismes de diffusion et de mise en cache. Les entreprises devaient ainsi prendre en charge deux technologies de mise en cache distinctes (une pour le trafic HTTP, l'autre pour la vidéo), ce qui doublait la complexité de la gestion du réseau. Troisièmement, RTMP, RTSP et MMS exigeaient des administrateurs l'ouverture de ports réseau supplémentaires pour la communication (respectivement 1935, 554 et 1755). Cela augmentait la surface d'attaque du réseau et le risque de blocage des protocoles par les pare-feu d'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 notoirement incompatible avec les appareils iOS. En dehors de l'écosystème iOS, les clients mobiles subissent de fréquentes interruptions de connexion et des changements d'adresse IP. Cela nécessitait souvent de rétablir la connexion RTMP active à plusieurs reprises au cours d'un même événement.

 

3. Technologie de diffusion vidéo multicast

Affirmer que la multidiffusion constituait une phase distincte de la distribution vidéo en ligne est une affirmation optimiste, étant donné que cette technologie n'a jamais atteint une masse critique, ni en entreprise ni auprès des particuliers. Cependant, la multidiffusion vidéo a suscité un vif intérêt au milieu des années 2000 et, comme elle persiste dans certains réseaux d'entreprise, elle mérite d'être examinée.

La multidiffusion était une technologie réseau permettant à un émetteur de distribuer les mêmes données à plusieurs destinataires simultanément. Le principe était similaire à l'écoute de la radio : un seul signal radio est envoyé à tous les auditeurs, au lieu de signaux distincts pour chaque personne à l'écoute. Correctement mise en œuvre, la multidiffusion offrait des gains d'efficacité considérables en matière de transmission de données, ce qui a suscité un vif intérêt pour son utilisation dans la diffusion vidéo.

Grâce à la multidiffusion, une organisation peut théoriquement diffuser de la vidéo en direct sur son réseau d'entreprise en utilisant une fraction de la bande passante requise par la transmission unicast traditionnelle. De ce fait, les organisations se tournent souvent vers la multidiffusion pour optimiser le retour sur investissement de leurs réseaux à bande passante limitée, plutôt que de moderniser leur infrastructure réseau.

 

Illustration de la diffusion vidéo multicast et unicast

La transmission unicast (à gauche) envoie un flux unique pour chaque client connecté, tandis que la multicast (à droite) envoie un flux unique partagé par tous les clients abonnés.

 

Malheureusement, les exigences d'infrastructure du multicast le rendaient impraticable pour la plupart des organisations. Pour diffuser de la vidéo (ou toute autre donnée) via multicast, la source, les destinataires et l'infrastructure réseau de connexion devaient tous prendre en charge le protocole. Concrètement, chaque routeur, concentrateur, commutateur et pare-feu du réseau d'entreprise devait être compatible avec le multicast. Cette exigence d'une infrastructure homogène était à la fois peu pratique et peu fiable.

Par exemple, en cas d'échec d'une communication multicast, le recours se faisait généralement par transmission unicast classique. Dans la plupart des cas, cette transmission unicast ne bénéficiait d'aucune optimisation réseau, comme la mise en cache des données ou d'autres techniques d'accélération WAN, puisque la multicast était la seule forme d'optimisation mise en œuvre.

De plus, comme la multidiffusion exigeait un environnement 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. Internet est conçu pour une grande variété de débits, de types de connexion, de qualités de service (QoS) et de terminaux. 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 protégés par les pare-feu d'entreprise sont de plus en plus hétérogènes. La tendance au BYOD (Bring-Your-Do-Device) implique que les employés utilisent divers appareils (tablettes et smartphones) aux capacités et aux exigences réseau variées. Enfin, la consolidation continue du secteur rend de moins en moins probable qu'une succursale récemment acquise à Londres utilise la même architecture réseau que le siège social à Seattle.

En résumé, la multidiffusion était une ambition certes louable, 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.

 

L'intérêt pour la multidiffusion au fil du temps

Intérêt pour la multidiffusion, 2004-2015. Source : Google Trends.

 

4. Flux HTTP modernes

En 2008, Microsoft a lancé Smooth Streaming, une approche hybride de diffusion vidéo qui offrait de nombreux avantages des protocoles de streaming personnalisés tout en tirant parti du protocole HTTP et de l'infrastructure réseau existante. Smooth Streaming prenait également en charge la diffusion à débit adaptatif (ABR), offrant ainsi aux utilisateurs 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.

 

Diffusion en continu à débit adaptatif illustrée

Le streaming à débit 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 via HTTP a rapidement gagné en popularité, et d'autres acteurs majeurs du marché ont rapidement investi dans cette technologie. En 2009, Apple a fait son entrée sur le marché avec le lancement de HTTP Live Streaming (HLS). En 2010, Adobe a abandonné les protocoles de streaming personnalisés avec la sortie de HTTP Dynamic Streaming (HDS). Depuis 2010, les principales entreprises de streaming et de médias, dont Microsoft, Google, Adobe, Netflix, Ericsson et Samsung, collaborent au développement de MPEG-DASH, une norme ouverte pour le streaming vidéo adaptatif via HTTP.

Des innovations telles que Smooth Streaming, HLS, HDS et DASH ont entraîné une renaissance de la diffusion vidéo basée sur HTTP et un bouleversement dans la manière dont les entreprises distribuent la vidéo sur leurs réseaux.

 

En savoir plus sur le streaming vidéo en ligne

ICON - CTA - Vidéo en streaming moderne en entreprise - WANopDans notre dernier livre blanc, Diffusion vidéo moderne en entreprise : protocoles, mise en cache et optimisation WANNous examinerons plus en détail les changements techniques qui sous-tendent la transition vers le streaming moderne, notamment les sept caractéristiques qui rendent moderne un protocole de streaming vidéo.

Nous examinerons également les nouvelles opportunités offertes par le streaming moderne aux organisations pour utiliser l'infrastructure réseau existante afin d'obtenir une diffusion vidéo plus évolutive et plus rentable.

Téléchargez votre exemplaire dès aujourd'hui !