Le protocole IP est très prisé par l’audiovisuel pour son interactivité jusqu’alors inégalée en télévision numérique. En revanche, le réseau Internet s’adapte mal à la diffusion de vidéos. D’abord parce que la vidéo est très gourmande en débit. Même compressée, il lui faut un minimum de 300 kbit/s pour obtenir la qualité d’une télévision classique. À l’exception des entreprises qui maîtrisent leur bande passante en intranet, les utilisateurs disposant d’un tel débit restent rares. Au-delà, le fonctionnement du protocole IP n’offre pas de garantie suffisante à la diffusion d’images de qualité. En effet, IP n’a pas été prévu pour des communications synchrones. Ce protocole sait reconstituer les paquets de données perdus ou bloqués dans le maillage du réseau, ce qui a fortement contribué à son adoption. Mais cette caractéristique n’a plus de valeur dans le cadre de la vidéo : le temps de réceptionner tous les paquets, de reconstituer le message et les éventuelles données manquantes, et la consultation de vidéo est saccagée par des sauts d’images, pire, par des blancs sonores ou visuels qui rendent sa visualisation difficile, voire impossible.
Les technologies prêtes pour adapter les infrastructures IP
Pour que le marché émergent de la télévision sur Internet se concrétise, il faut forcément des infrastructures haut débit capables de garantir un flux de données constant, y compris lorsqu’il ne s’agit que de diffuser des images de la taille d’un timbre poste. Jean-Michel Laveissière, responsable des opérations de l’infrastructure broadcast d’ISDNet, le souligne : ‘ Il existe deux marchés pour la vidéo sur Internet, celui du broadband et du narrowband ‘. Classique, le marché du broadband (diffusion à large bande/échelle) adresse une population traditionnelle de la télévision qui exige une image de qualité de la taille de l’écran. Tandis que le marché du narrowcast (diffusion de proximité/bande étroite) cible les sites de commerce électronique et autres portails d’information sur Internet ou en intranet qui veulent illustrer leur communication de vidéos ou s’en servir comme d’un outil d’aide à la vente. C’est déjà le cas sur CD and Co;, un site de vente de CD.
Dans tous les cas, les technologies qui garantissent le débit nécessaire à la vidéo sont aujourd’hui opérationnelles. On sait en effet réserver de la bande passante avec RSVP (Resource ReserVation Protocol) ou garantir la livraison des paquets avec RTP (Real Time Transport Protocol) et RTCP (Real Time Control Protocol). Le premier ajoute des informations aux paquets IP pour mieux gérer les transmissions, tandis que le second agit directement sur la qualité des transferts en émettant des rapports détaillés sur les pertes de paquets, les délais, etc. Agissant au niveau de la couche applicative, ces protocoles ne sont toutefois pas utilisés pour la remontée des flux vidéo. Comme le souligne Jean-Michel Laveissière : ‘ Lorsqu’il faut remonter un flux qui vient d’être encodé jusqu’au centre de diffusion, qui va ensuite servir les requêtes des utilisateurs, on doit être en mesure de garantir le débit quoi qu’il arrive, surtout si l’on est en direct. Les protocoles au-dessus de la couche IP n’ont que peu d’intérêt dans ce cas précis, d’autant plus qu’ils n’offrent pas les mêmes garanties de fiabilité que des liaisons établies à de plus bas niveaux. ‘ Pour remonter les flux vidéo jusqu’à son centre de diffusion, ISDNet utilise donc un chemin virtuel privé (CVS), équivalent du tunnel établi par RSVP, mais cette fois-ci au niveau de la couche réseau Frame Relay. En revanche, les technologies Internet trouvent leur sens dès qu’il s’agit de diffuser jusqu’au client final. On peut alors établir un canal de diffusion au niveau de la couche applicative pour garantir un flux de données entre le serveur de vidéo et le lecteur multimédia.
La course aux débits pour une meilleure qualité d’image
Le britannique Kingston a opté pour la solution 3DSL (Third Dimension Space Limit) de Newbridge, racheté par Alcatel. 3DSL est un mélange de technologies ATM et xDSL qui cible le marché du broadband sans pour autant remettre en cause le parc de postes de télévision existant. Outre le modem xDSL qui connecte la TV au réseau, un boîtier convertit les données numériques en signal vidéo. Réalisé en ATM, le c?”ur de réseau encapsule la vidéo découpée en paquets IP dans un flux ATM. Cette dernière technologie permettant d’allouer des ressources, il est donc possible de réserver la bande passante jusqu’au point de raccordement au réseau téléphonique. La transmission est prise en charge par les technologies xDSL qui offrent un débit suffisant à la diffusion d’images de qualité broadcast, soit 6 Mo/s lorsque le point de basculement entre les deux réseaux n’est pas situé à plus de 2 km du domicile du particulier. Combinant le mode de diffusion classique (broadcast) à l’interactivité du protocole d’Internet (IP), 3DSL fonctionne en mode multicast ou unicast. Dans le premier cas, un seul flux de données transite sur le réseau ATM afin d’économiser la bande passante. Il est ensuite répliqué sur le réseau téléphonique pour desservir les différents utilisateurs. Dans le second cas, un canal virtuel est créé de bout en bout entre l’utilisateur et le serveur.
Moins ambitieux en terme d’infrastructure, le projet de TAK (filiale de Microsoft et de Thomson Multimédia) mixe les technologies hertziennes au maillage d’Internet : les images sont diffusées par les moyens traditionnels hertziens, tandis que l’interactivité est offerte par un modem intégré au poste de télévision qui lui permet de communiquer en IP. Contrairement à la solution de Newbridge, l’offre de TAK implique l’achat d’un poste numérique et donc le renouvellement du parc de télévisions.
Enfin, streaming et IP ne sont pas incompatibles d’autres types de communication comme les réseaux satellitaires et le câble, solutions qui se développent à grande vitesse et devraient offrir un débit suffisant à la diffusion d’images de qualité.
Serveurs cache et réseaux spécialisés au secours de la vidéo sur IP
En attendant les réseaux à haut débit et les infrastructures maîtrisées pour la vidéo, éditeurs et constructeurs trouvent des palliatifs afin d’optimiser les temps de réponse. Ainsi, les acteurs majeurs du marché du cache, Inktomi et NetworkAppliance, ont ajouté la gestion de la vidéo à leur serveur afin de rapprocher le stockage des fichiers des utilisateurs. Ils réduisent ainsi la consommation de bande passante et optimisent la qualité de service. Travaillant de concert avec les éditeurs de lecteurs multimédias, Microsoft et RealNetworks, cette évolution a nécessité la gestion de commandes spécifiques aux players (avance, stop, lecture), ainsi que l’ajout d’outils pour établir des statistiques sur les vidéos consultées. Cela afin de faciliter la facturation dans le cadre de diffusions payantes. Enfin, l’adaptation des serveurs cache au streaming implique la gestion des protocoles spécifiques à chaque éditeur, MMS (Microsoft Media Server) chez Microsoft, RTSP (Real Time Streaming Protocol, préconisé par le W3C) chez RealNetworks. Que l’un soit propriétaire et l’autre standardisé ne change pas grand-chose pour les éditeurs de cache qui, jusqu’alors, n’acceptaient aucun des deux. En revanche, les routeurs gèrent RTSP. Une infrastructure de réseau optimisée pour la vidéo, y compris à l’échelle d’Internet, est donc plus facile à mettre en ?”uvre avec le serveur de RealNetworks.
Enfin, RealNetworks et Akamaï disposent également de réseaux de serveurs répartis à travers le monde, dont l’objectif est similaire à celui du cache. En répliquant les données sur différents points de la planète, ils rapprochent les serveurs de diffusion des utilisateurs finaux et peuvent ainsi contribuer à l’amélioration de la qualité de service.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
