Faute de bande passante généreuse, mais aussi d’un fonctionnement prévu pour la communication asynchrone, Internet n’est pas adapté aux exigences de la vidéo. Toute information envoyée à l’aide du protocole IP est en effet préalablement découpée en paquets. Ces derniers sont ensuite régis de façon anarchique : chacun emprunte le chemin qui lui convient le mieux à travers le maillage d’Internet pour parvenir tous à la même destination. Si les tables de routage sont là pour domestiquer un peu cette anarchie, c’est tout de même la possibilité de prendre différentes routes qui fait la force du Réseau des réseaux. Cette liberté a forcément un prix : certains paquets se perdent en route, d’autres arrivent en retard, bloqués par un routeur surchargé, ou purement et simplement éliminés, leurs délais de vie ayant expiré ! IP sait heureusement régénérer des paquets perdus pour reconstituer un message. Mais le message n’est recomposé que lorsque tous les paquets répondent à l’appel. Quand on connaît la taille d’un fichier vidéo, on se doute qu’il n’est pas possible d’attendre les retardataires.C’est précisément à ce niveau qu’intervient la technologie streaming en permettant à l’utilisateur de commencer à visualiser une vidéo avant que la totalité des données n’ait été téléchargée sur son disque dur. Premier éditeur à avoir proposé une solution de streaming opérationnelle, RealNetworks a été suivi de près par Microsoft dès 1997, puis par Apple. En plus de ces trois acteurs, d’autres solutions existent, telles que VDOLive destinée à la vidéo. Parrallèlement, la technologie streaming ayant depuis également été reprise par les éditeurs de lecteurs de musique.
L’art d’accommoder l’asynchrone en flux de données synchrones
Le fonctionnement de la technologie streaming est relativement simple. Quand l’utilisateur clique sur un lien pour déclencher une vidéo, la requête est automatiquement transmise au serveur de vidéo par le serveur Web. Le premier déclenche la création d’une sorte de fichier temporaire sur le disque de l’utilisateur. Ce dernier contient notamment l’adresse du fichier vidéo mentionné dans le lien. Le lecteur multimédia se déclenche alors et lit le lien du fichier temporaire. Il envoie une requête au serveur de vidéo pour l’informer qu’il est prêt à réceptionner les données. Un canal se crée alors entre le lecteur et le serveur de vidéo, qui servira à l’envoi des flux de données par groupes de paquets aussi appelés stream. Chargés dans le fichier temporaire, ces groupes de paquets sont reconstitués et commencent alors à être joués par le lecteur pendant que le fichier continue en tâche de fond à engranger des données.Ce fonctionnement de base a évolué pour s’adapter à différents débits. Ainsi, le plupart des serveurs de vidéo sont aujourd’hui capables de calquer dynamiquement la diffusion sur le débit de l’utilisateur final. Si le réseau vient à être trop engorgé, le lecteur prendra en effet l’initiative de faire attendre un peu plus l’utilisateur afin de stocker suffisamment d’informations pour lui garantir par la suite une meilleure fluidité de l’image. De même, les vidéos peuvent être paramétrées pour être diffusées selon différents niveaux de qualité : le serveur dégradera alors automatiquement la qualité des images, réduira la taille de l’écran de visualisation… si le débit de l’utilisateur est trop limité, sans qu’il soit nécessaire de prévoir différents fichiers vidéos.
Diffusion : économiser la bande passante
Deux modes de diffusion streaming cohabitent. Le plus ancien repose sur le principe de l’unicast : chaque utilisateur reçoit son propre paquet qui lui est routé de bout en bout (du serveur au client). Or, ce mode de diffusion n’est adapté qu’à un faible nombre de connexions simultanées, car il demande une bande passante très importante (équivalente au nombre de connexions multiplié par la bande passante de chaque connexion). Une vidéo de qualité nécessitant environ 30 Ko/s de bande passante, on imagine aisément les limites de cette approche quand il faut adresser des milliers d’utilisateurs.Le protocole IPMulticast prévoit un mode plus économique de la bande passante d’Internet. Les données sont acheminées sur un seul segment de réseau, plus ou moins long, jusqu’à un répétiteur qui prend ensuite le relais en diffusant autant de fois la vidéo qu’il y a d’utilisateurs. Bien qu’économique, IPMulticast n’est toutefois pas adapté au streaming. Pour recevoir la vidéo, les utilisateurs doivent en effet préalablement s’inscrire auprès du répétiteur. Ce qui suppose que tous les utilisateurs regardent la même vidéo au même moment, l’envoi des données étant effectué une seule fois, justement pour économiser la bande passante. Proche du mode de visualisation broadcast de nos télévisions traditionnelles, et donc adapté au direct mais pas à la consultation d’archives, IPMulticast ne bénéficie pas en outre d’une prise en compte suffisante sur les routeurs du réseau pour que sa mise en ?”uvre soit possible.En attendant, les opérateurs reproduisent une architecture similaire : localisé sur les Pop (Point of Presence) quand c’est possible ou en tout cas le plus près des utilisateurs, un splitter ou serveur frontal récupère les requêtes. Il les transmet à un serveur source chargé de capter le signal et de faire circuler les flux, la vidéo étant généralement stockée sur un troisième niveau. Grâce à de telles architectures, on réduit la consommation de bande passante entre le serveur source et le splitter en n’envoyant qu’un seul flux de données, ensuite répliqué autant de fois qu’il y a d’utilisateurs. Les traitements étant effectués par différents serveurs, aidés ou non d’outils de répartition de charge, ces architectures contribuent à de meilleurs temps de réponse.Reste que ce mode de fonctionnement n’est valable, comme IPMulticast, que si tous les utilisateurs regardent la même vidéo en même temps, dans le cadre de diffusions en direct qui ne constituent qu’une partie infime des possibilités offertes par Internet. Un des grands avantages du streaming sur IP consiste en effet à permettre à l’utilisateur de consulter sa vidéo quand il le souhaite. La seule alternative est alors de répliquer les serveurs de vidéo sur les Pop afin de limiter les transferts de données au seul segment entre le Pop et l’utilisateur, et éviter ainsi de parcourir les maillages d’Internet.
Des contenus enrichissent le streaming pour donner du Rich Media
Au fonctionnement du streaming, il faut encore ajouter la possibilité d’enrichir la vidéo par des contenus (textes, images, sons, présentations, etc.) synchronisés sur la vidéo. Connu sous le nom de Rich Media, ce concept a donné lieu à une norme standardisée par le W3C : Smil (Synchronised Multimedia Integration Language). Adopté par RealNetworks et Apple, Smil a été boudé par Microsoft pour la simple raison que, outre les tendances propriétaires de la société, l’éditeur disposait déjà d’un équivalent opérationnel en 1997 : ASF (Advanced Streaming Format). Très similaire dans ses objectifs, voire dans sa conception, ASF se différencie toutefois par l’utilisation du langage VB (Visual Basic) là où Smil utilise XML (eXtensible Markup Language). Si les serveurs Apple et RealNetworks sont désormais capables de gérer indifféremment les fichiers de l’un ou l’autre grâce à un récent accord de partenariat, le marché est clairement divisé aujourd’hui entre ces 2 technologies de streaming incompatibles. Se gardant bien de prendre parti dans une bataille aujourd’hui dominée par RealNetworks, mais dont le destin risque étrangement de ressembler à celui de Netscape qui, à ses heures de gloire, dominait également le marché du navigateur, les sites proposent en général les deux formats.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
