Passer au contenu

La vidéo sur Internet, avec le Streaming media

Le Streaming sort de son rôle de gadget à la mode attirant les cybernautes sur les sites Web. Aujourd’hui, la technologie ambitionne de s’emparer des marchés de la formation et de la communication à distance.

Petite image deviendra grande ! Pour la plupart des internautes, le Streaming media n’est encore qu’une vidéo au format d’un timbre-poste, animée par à-coups sur l’écran de leur PC. Mais, rapidement, la donne va changer, grâce aux accès Internet à hauts débits, offerts par l’ADSL et les réseaux câblés. Le Streaming disposera alors de la largeur de bande nécessaire pour s’épanouir en tant que moyen de diffusion privilégié d’informations multimédias, qu’il s’agisse d’audio, de vidéo ou d’une simple présentation PowerPoint.
Le Streaming bouleversera la communication, comme le fit, en son temps, la télévision hertzienne. Les entreprises nord-américaines ne s’y sont d’ailleurs pas trompées. Selon le cabinet d’études Dataquest, elles sont déjà 9 % à utiliser le Streaming sur leur site Web ou sur leur Intranet. Elles devraient être 30 %, dès la fin de cette année !

Un décodage au fur et à mesure de la réception des données

En France, des opérateurs importants, comme Isdnet ou KPNQwest, entament la commercialisation de leurs offres de Streaming sur Internet. C’est, pour les entreprises, la possibilité de dispenser des formations à moindre coût ou de répandre la bonne parole de leurs p.-d.g. sur toute la planète. A terme, c’est l’émergence de chaînes de télévision ou de radio spécifiques au Web qui se profile.
A la base de cette révolution se trouve une technologie baptisée Streaming, ou flux continu. A la différence du traditionnel téléchargement de fichiers, également appelé Downloading, le Streaming n’attend pas qu’un fichier soit récupéré dans sa totalité avant d’en autoriser l’utilisation. Le décodage des images et du son s’effectue au fur et à mesure de leur réception. Cela évite notamment de devoir attendre pendant des heures le téléchargement complet d’un fichier vidéo. Un clip de huit minutes numérisé au rythme de trente images par seconde avec une résolution de 350 par 240 points dépasse les 140 Mo. Son délai de chargement sur une ligne téléphonique équipée d’un modem à 56 kbit/s prendrait au minimum cinq heures !

Un stock tampon pour éviter les encombrements du Net

Lors du décodage en temps réel, une précaution est toutefois nécessaire pour préserver au mieux la fluidité des images. Elle consiste à stocker par avance sur le PC quelques secondes de vidéo dans un fichier tampon. On constitue ainsi un rempart minimal contre les embouteillages d’Internet. C’est dans ce fichier que puise le logiciel de lecture multimédia. RealPlayer, de RealNetworks ; Windows Media Player, de Microsoft ; et QuickTime, d’Apple, sont les lecteurs les plus connus du marché. Au bout du compte, le Streaming répond de manière satisfaisante à des besoins multiples. On visualisera ainsi un clip préenregistré, mais on assistera également à un événement filmé en direct, à condition de raccorder la caméra sur un dispositif de codage numérique. La transmission s’effectuera aussi bien vers un seul destinataire que vers plusieurs milliers de personnes. Dans certains cas, l’interactivité sera possible : pause, retour en arrière ou avance rapide, à la façon d’une télécommande de magnétoscope. Lors de téléconférences en direct, l’image de l’intervenant sera synchronisée avec des schémas explicatifs, et il dialoguera par écrit avec le public. Ces différents scénarios réclament des mécanismes de transmission ad hoc.
Dans une diffusion en point à point, mode qualifié d’unicast sur Internet, le flux de paquets IP émis par le serveur source n’atteint qu’un seul destinataire à la fois. Inconvénient majeur, le réseau doit être dimensionné de telle sorte qu’il puisse transporter la somme de tous les flux vidéo, ou streams, acheminés en parallèle. Si les spectateurs regardent la même émission, il y a manifestement un gâchis de la bande passante.

Une communication très protocolaire, qui ne favorise pas toujours le dialogue

Dans leur grande sagesse, les pères fondateurs d’Internet ont donc prévu la diffusion point à multipoint sélective, ou multicast. Le serveur émet toujours un flux unique, mais il est décodé simultanément par plusieurs lecteurs. Les routeurs ne transmettent qu’un seul flot IP, même si des milliers de stations sont à l’écoute. Le flux est dupliqué lorsque cela devient indispensable, c’est-à-dire aux embranchements où les différentes destinations abritent des stations concernées par l’émission. Afin que tous les destinataires d’un flux soient identifiés, une adresse IP identique, dite de classe D ou de multicast, leur est affectée. Elle se choisit dans la tranche allant de 224.0.0.0 à 239.255.255.255. A tout moment, un poste client peut rejoindre ou quitter le groupe multicast. De leur côté, les routeurs cherchent à localiser les stations rattachées aux groupes actifs. Pour cela, ils dialoguent en employant des protocoles spécifiques tels que DVMRP (Distance vector multicast routing), MOSPF (Multicast OSPF) ou PIM (Protocol independant multicast).
Afin de s’inscrire à un groupe multicast, les stations emploient le protocole IGMP (Internet group management protocol) pour dialoguer avec le routeur multicast le plus proche. Actuellement, la montée en puissance des commutateurs d’entreprise amène certains d’entre eux à adopter des protocoles habituellement disponibles sur les routeurs. Des commutateurs de niveau 3 incluent désormais des protocoles tels que IGMP, PIM, DVMRP ou MOSPF. Les commutateurs traditionnels, similaires à des ponts Ethernet, sont ignorants de la couche IP. Certains, toutefois, comprennent le protocole IGMP. Ils interceptent ces paquets et calculent les filtres afin de n’acheminer le trafic vidéo que vers les stations concernées. Le procédé s’appelle IGMP Snooping. Un nouveau venu, le protocole GMRP (GARP multicast registration protocol), remplit le même rôle. Ce mode de fonctionnement est impossible sur des réseaux équipés de commutateurs trop anciens, ou avec des concentrateurs Ethernet. Comme ils ne tiennent pas compte des spécificités des trames multicast, les trames sont répétées sur tous leurs ports. Le gain en bande passante est nul.
Si, sur le papier, le multicast est une solution séduisante, dans la pratique, peu de réseaux IP en exploitation commerciale acceptent ce mode de fonctionnement de bout en bout, surtout lors des interconnexions entre différents opérateurs. Dès lors, la transmission en point à point, ou unicast, reste le mode de communication privilégié.

Des fonctions identiques à celles d’un magnétoscope

Mais, sur un réseau purement unicast, comment procéder de façon efficace lorsqu’il s’agit, par exemple, de diffuser en temps réel un événement sportif vers plusieurs milliers, voire plusieurs millions, de destinataires ?
Une des réponses apportées par l’opérateur Isdnet s’appuie sur la technologie RealSystem fournie par RealNetworks. Lorsqu’il s’agit de ne pas noyer une infrastructure télécoms sous des dizaines de milliers de paquets identiques émis simultanément, Isdnet a recours au Splitting, ou multiplexage. Dans chacun de ses points de présence, en France et en Europe, Isdnet installe un splitter, ou multiplexeur. C’est un serveur dédié à la réception du flux multimédia unicast émis en temps réel à partir de son centre de calcul parisien. Le splitter duplique ensuite le signal vers les différents utilisateurs locaux. Dans le centre de calcul se trouvent les splitters source, qui dialoguent avec les splitters distants et jouent également le rôle de frontal vers les serveurs vidéo.

Le serveur de cache inclut les commandes spécifiques aux afficheurs multimédias

Le splitter se différencie du cache. Dans le cas de la vidéo à la demande (VOD), le cache peut héberger des clips déjà téléchargés à partir du Web par un utilisateur. KPNQwest, pour sa part, s’appuie sur ces caches pour de la vidéo ou de la radio émises en direct. Une vingtaine de secondes d’émission, rafraîchies en permanence, sont stockées temporairement sur le cache. Lorsque plusieurs utilisateurs du réseau local réclament la même vidéo, seule la première requête donne naissance à un flux, ou stream, entre le PC et le serveur distant, installé quelque part sur Internet. Les autres destinataires sont alimentés à partir du serveur de cache local, qu’il soit hébergé dans l’entreprise ou chez l’ISP.
Les serveurs de cache ne se sont mis que récemment au Streaming. Ainsi, Inktomi et Network Appliance ont doté leurs serveurs des technologies de Microsoft et de RealNetworks. Leurs systèmes comprennent donc les commandes spécifiques aux afficheurs multimédias, tels Pause, Avance, Retour en arrière… Les protocoles de communication des couches basses _ MMS (Microsoft Media Server), promu par Microsoft ; et RTSP, employé par RealNetworks _ sont aussi intégrés.
Ces protocoles jouent un rôle majeur, car ils doivent transmettre, en continu, un flux vidéo ou audio sur un réseau susceptible d’être embouteillé à tout moment. RTSP, par exemple, se situe presque au niveau des applications dans les sept couches du modèle OSI. RTSP a été conçu pour de la diffusion à la fois dans les modes point à point et point à multipoint. Il fournit les fonctions évoluées des télécommandes vidéo associées aux lecteurs multimédias : Retour en arrière ou Recherche, par exemple. RTSP, en tant que standard défini par l’IETF (Internet Engineering Task Force), favorise également l’interopérabilité de lecteurs multimédias et de serveurs vidéo provenant d’éditeurs différents. Il peut être employé conjointement avec RSVP (Resource reservation protocol) afin de réserver des ressources (bande passante, mémoire et puissance CPU) pour des sessions vidéo, tout au long de la chaîne de transmission (serveurs, routeurs, commutateurs…).

Une dégradation d’image qui ne nuit pas au confort de lisibilité

Dans les couches plus basses encore, quel mécanisme de transport choisir ? RTSP, par exemple, s’appuie sur TCP (Transport control protocol), UDP (User datagram protocol) ou RTP. Au départ, il semble que TCP, le complément traditionnel d’IP sur Internet, puisse convenir. Ce qui est demandé est finalement très proche d’un simple transfert de fichier à la façon de FTP (File transfert protocol). Or, le besoin de fluidité impératif à toute vidéo s’accommode mal de la personnalité pointilleuse de TCP. Celui-ci n’hésite pas à faire patienter une application tant qu’il n’a pas reçu la confirmation de la bonne réception des informations déjà expédiées. Il procédera même à la retransmission des paquets perdus à cause de la surcharge soudaine d’un routeur, quelque part sur le réseau. Cette fiabilité, habituellement si précieuse, se métamorphose alors en handicap. C’est pourquoi le protocole UDP est souvent préféré à TCP pour le transport d’applications dites temps réel telles que la vidéo numérique.
UDP s’affranchit des garde-fous usuellement respectés par TCP. C’est alors l’application, en charge de la réception des paquets de données, qui rétablit l’ordonnancement des informations reçues, et accepte la disparition de certaines d’entre elles. L’?”il, en effet, accepte facilement des lacunes dans une image, qui sera, de toute façon, rapidement effacée par la suivante. RTP, un des protocoles de transmission multimédia les plus anciens, s’appuie sur UDP, mais peut également être employé avec TCP et permet aux paquets d’arriver comme bon leur semble avant d’être réordonnés sur le PC de réception. RTP est ainsi utilisé sur le réseau MBone (Multicast backbone), pour des sessions audio et vidéo interactives, utilisées lors de conférences. Dans la pratique, RTP ajoute un en-tête de 10 octets aux paquets UDP. Il adjoint ainsi des informations sur l’heure d’émission, le numéro de séquence, et le type de compression employée. Cela afin que, arrivé à destination, le tout soit correctement synchronisé avec les images précédentes. RTP s’accompagne d’un autre protocole, RTCP (Real time control protocol), qui contrôle cycliquement la qualité de la transmission.

La bataille fait rage entre Microsoft et RealNetworks

Si l’on remonte dans les couches applicatives, la situation s’est récemment compliquée. Microsoft et RealNetworks sont, en effet, à couteaux tirés, après une période de relative coopération. Le premier est encore à la traîne du second. On le critique, notamment, sur les limitations de ses serveurs en nombre de destinataires simultanés acceptés et de streams. Mais, comme à son habitude, Microsoft compte sur sa puissance de feu pour écraser son adversaire. Concernant le client, RealNetworks pousse son RealPlayer, diffusé gratuitement à plus de 95 millions d’exemplaires, contre le Windows Media Player de son rival honni.
C’est du côté du serveur que la partie se gagnera. RealServer G2 affronte Windows Media Technologies et est basé sur la toute récente technologie Smil (Synchronized multimedia integration language), employée pour la description de pages multimédias. Elle permet de synchroniser des pages Web avec de la vidéo, ce qui se révèle particulièrement pratique pour de la formation en ligne. Or, si RealServer G2 est facturé selon le nombre d’utilisateurs connectés simultanément, Microsoft, lui, livre ses services de Streaming avec Windows 2000. Autant dire qu’ils sont gratuits. Une méthode qui avait déjà bien réussi à l’éditeur lors de sa lutte avec Netscape pour la suprématie sur le marché des navigateurs Internet. Les faiblesses actuelles d’Internet ont conduit RealNetworks à définir une architecture intégrée capable de réagir aux incessantes modifications de largeur de bande passante. Résultat : SureStream, une technologie permettant de se replier sur une vitesse inférieure, en cas de ralentissement du débit effectif de la ligne de transmission. Le fichier à transmettre contient donc, en fait, tous les encodages de la même séquence vidéo, selon les diverses vitesses de connexion possibles pour le poste client, qu’il s’agisse d’un modem à 28,8 kbit/s, 56,6 kbit/s, 64 kbit/s ou 128 kbit/s. Si un blocage intervient sur un stream à 20 kbit/s, le serveur vidéo se replie sur la partie du fichier codée pour une transmission à 16 kbit/s. Si une autre baisse de régime se produit, il passe à 11 kbit/s. En face, Microsoft riposte avec IntelligentStream, une offre similaire, et son propre format de fichier vidéo, ASF.

Des moteurs de Streaming appuyés par les opérateurs IP

Restent les outsiders comme QuickTime, d’Apple, ou des logiciels sous Linux, tel Icecast. La technologie Streaming QuickTime, par exemple, est disponible pour le monde Macintosh ainsi que pour l’univers Windows. QuickTime accepte les formats MP3, les animations flashes et la compression vidéo Sorenson, les protocoles RTP et RTSP assurant la transmission dans les couches réseaux. La plupart des opérateurs IP soutiennent ces différents moteurs de Streaming afin d’être ouverts à la multitude d’applications en cours de développement sur Internet. ;

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Jean-Pierre Blettner