La démocratisation d'Internet fait apparaître de nouveaux besoins. En effet, le format HTML, grâce à sa convivialité et sa facilité d'accès, a grandement contribué à la popularisation d'Internet. Aujourd'hui, le monde statique des pages HTML est révolu et la demande de produits vidéos et sonores est de plus en plus grandissante. Hélas, les réseaux constituant Internet n'ont pas été construis dans le but de véhiculer des flots de données temps réels. Ainsi, les services de diffusion de vidéo ou de son sont de véritables challenges. D'autre part, jusqu'à aujourd'hui, la distribution de vidéos était réduite à des vidéos de quelques minutes seulement. Pour ce genre d'application la véhiculation du flot d'information par le protocole HTTP suffisait mais, à l'heure où la diffusion de film est désormais possible avec un niveau de qualité acceptable pour les technologies Internet haut débit, il devient impératif d'introduire une interactivité entre le serveur de contenu et le client. Toutes ces contraintes font finalement émerger des solutions complètes de diffusion, regroupant en leur sein les principaux protocoles introduits par le streaming. Nous allons donc vous présenter dans un premier temps, les aspects généraux sur les difficultés de réaliser un service de streaming sur Internet. Dans un deuxième temps nous essaierons de vous sensibiliser aux différents protocoles mis en oeuvre pour répondre à ces difficultés. Puis nous passerons à la présentation des principales solutions existantes assurant un service de diffusion audio ou vidéo.

2 Présentation générale du streaming

Le streaming est utilisé pour rendre accessible un flux audio ou vidéo à des utilisateurs distants. Ce terme vient de l’anglais « stream » qui signifie « flot ». Cette technique permet la diffusion de son et de vidéo en continu (sans interruption) et en temps réel (au moment où se passe l’événement). Le streaming est utilisé sur les réseaux de télécommunications : internet, cable, télévision numérique,… Cela permet de diffuser le même flot de données à plusieurs utilisateurs en même temps. Pour cela, plusieurs techniques existent :

Diffusion en broadcast

Diffusion en multicast

Diffusion en unicast

2.1 Le broadcast (ex : télévision satellite)

Lors d’une diffusion en broadcast, un seul flux est émis pour tous les utilisateurs. Cette technique a l’avantage de diminuer la bande passante nécessaire et de diminuer la charge au niveau du serveur. En effet, il n’a plus à gérer N connexions distinctes.

2.2 Le multicast

Ce principe de diffusion fonctionne un peu comme le broadcast, en effet un seul flux est émis à partir du serveur. Ce flux est reçu par tous les clients. Cependant, les clients doivent s’abonner au groupe pour recevoir le flux, il ne s’agit plus de diffusion pure et dure comme dans le cas du broadcast. Cette technique est utilisée dans le streaming sur internet mais pose quelques problèmes d’implémentation au niveau des routeurs (les routeurs doivent gérer le multicast).

2.3 L’unicast

Cette technique consiste à associer un flux à chaque utilisateur. Le serveur est évidemment plus sollicité mais cela permet une plus grande souplesse vis-à-vis des clients. En effet, ces derniers peuvent choisir le débit qui convient à leur infrastructure.

Ce procédé est le plus utilisé sur Internet car il fonctionne bien sur le réseau actuel et n’a pas les problèmes d’implémentation rencontrés avec le multicast.

Parmi ces trois techniques de diffusion, seules deux sont utilisées par les logiciels que nous testerons : le multicast et l’unicast. Certains logiciels fonctionnent uniquement en unicast, d’autres peuvent utiliser les deux.

Aujourd’hui le streaming est principalement utilisé sur internet, par l’intermédiaire de radios et de vidéos. Certains sites se sont spécialisés dans l’émission de programmes de télévision, ce qui nécessite des solutions de streaming vidéo performantes.


Diffusion multicast	Diffusion unicast

3 La Problèmatique

Les solutions de streaming doivent toutes faire face à des difficultés dûes au réseau physique. En effet, sur Internet comme sur les réseaux privés, la bande passante est limitée. Ceci est particulièrement valable sur Internet : si le haut débit commence à se démocratiser, son utilisation est encore trop marginale pour envisager un serveur de streaming fonctionnant uniquement en haut débit. La plupart des sites possèdent d’ailleurs deux types de flux : bas débit (56Kb/s) et haut débit (quelques centaines de Kb/s voire Mb/s).

Le but d’un serveur de streaming est de diffuser un flux avec la meilleure qualité possible (sonore ou visuelle) et d’empêcher toutes interruptions. Il y a vraiment un compromis entre qualité et débit. Pour éviter les interruptions pendant la diffusion, une technique est utilisée : le buffering. Elle consiste à mémoriser une partie du flux afin de pouvoir continuer la transmission même si le trafic est perturbé. Le buffering nécessite donc à chaque connexion un temps pour remplir le buffer (mémoire), sa taille est variable et dépends de chaque serveur.

La taille du buffer est un paramètre important. Si celui-ci est trop petit, il n’empêchera pas les interruptions de flux, au contraire si il est trop important le client mettra plus de temps au démarrage et les performances globales seront dégradées (traitements inutiles effectués par le client).

4 Les techniques et protocoles

4.1 La gestion des applications temps réel

Les réseaux dans lesquels sont susceptibles d'être déployées des applications offrant du streaming peuvent être de nombreuses natures, dépendant essentiellement du type de public visé. Dans le cas d'un site regroupant toutes les bandes annonces de films parus ou à paraître, le public visé peut être mondial et la diffusion des bandes annonces passera obligatoirement par le réseau Internet. Pour remédier aux problèmes de séquencements et de synchronisation induis par l'usage d'un réseau sans qualité de service tel que Internet, le protocole RTP a été conçu.

Protocoles de streaming

4.1.1 Le protocole RTP

Ce protocole se base sur la couche TCP ou UDP de la pile TCP/IP et doit être intégré au sein de l'application temps réelle mise en oeuvre. Il permet la diffusion de manière synchrone des flux temps réel transportés et n'inclu pas le contrôle de la qualité de la communication. Le contrôle passe par l'intermédiaire du protocole RTCP présenté ci-dessous.

Ce protocole ne gère pas la qualité de service au sein du transport des données mais son implémentation est fortement recommandée afin d'assurer le bon séquencement des données sur le poste client. D'autre part, l'usage de UDP pour le transport des données ne pose aucun problème pour ce genre d'application parce que les paquets IP venant à être réémis en cas de perte en mode TCP arriveraient pour la plupart après l'instant auquel ces données aurait du être présentées au client. De plus, le protocole RTP intègre un mode connecté équivalent à celui employé avec TCP.

Ce protocole intègre:

Le champ Version V de 2 bits de longueur indique la version du protocole (V=2)

Le champ padding P : 1 bit, si P est égal à 1, le paquet contient des octets additionnels de bourrage (padding) pour finir le dernier paquet.

Le champ extension X : 1 bit, si X=1 l'en-tête est suivie d'un paquet d'extension

Le champ CSRC count CC : 4 bits, contient le nombre de CSRC qui suivent l'entête

Le champ marker M : 1 bit, son interprétation est définie par un profil d'application (profile)

Le champ payload type PT : 7 bits, ce champ identifie le type du payload (audio, vidéo, image, texte, html, etc.)

Le champ séquence number : 16 bits, sa valeur initiale est aléatoire et il s'incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets perdus

Le champ timestamp : 32 bits, reflète l'instant où le premier octet du paquet RTP a été échantillonné. Cet instant doit être dérivé d'une horloge qui augmente de façon monotone et linéaire dans le temps pour permettre la synchronisation et le calcul de la gigue à la destination

Le champ SSRC : 32 bits, identifie de manière unique la source, sa valeur est choisie de manière aléatoire par l'application. Le champ SSRC identifie la source de synchronisation (ou dit simplement "la source"). Cet identificateur est choisi de manière aléatoire avec l'intérêt qu'il soit unique parmi toutes les sources d'une même session La liste des CSRC identifie les sources (SSRC) qui ont contribuées à l'obtention des données contenues dans le paquet qui contient ces identificateurs. Le nombre d'identificateurs est donné dans le champ CC

Le champ CSRC : 32 bits, identifie les sources

4.1.2 Le protocole RTCP

Ce protocole est chargé de la partie contrôle du flux de la connexion temps réel avec le client. Il est souvent adjoint à l'usage du protocole RTP pour assurer une dynamique face aux problèmes de congestion éventuel. Le contrôle s'effectue sur la base de rapports (messages RTCP) construits et envoyés périodiquement par chacun des acteurs. Ces rapports contiennent des statistiques sur le nombre de paquets émis, le nombre de paquets perdus et le délai moyen d'envoie. Ce rapport est utilisé dans le but d'optimiser la qualité de la communication en augmentant ou en diminuant le débit employé pour la communication. Dans le cas de dialogues avec plusieurs clients, la charge introduite par l'envoi de messages RTCP peut être importante, c'est pourquoi on doit prendre garde à ajuster l'intervalle de temps entre chaque création de rapport. Celle-ci devra être choisie de manière à ce que les messages RTCP n'occupe que 5% de la bande passante à disposition (25% pour l'émetteur et 75% pour les récepteurs).

Le protocole RTCP est composé des champs suivants :

Le champ version (2 bits)

Le champ padding (1 bits) indique qu'il y a du bourrage dont la taille est indiquée dans le dernier octet

Le champ réception report count (5 bits): nombre de comptes-rendus dans le paquet

Le champ packet type (8 bits) 200 pour SR

Le champ length (16 bits) longueur du paquet en mots de 32 bits

Le champ SSRC (32 bits): identification de la source spécifique à l'émetteur

Le champ NTP timestamp (64 bits)

Le champ RTP timestamp (32 bits)

Le champ sender's packet count (32 bits)

Le champ sender's octet count (32 bits) statistiques

Le champ SSRC-n (32 bits) numéro de la source dont le flux est analysé

Le champ fraction lost (8 bits)

Le champ cumulative number of packets lost (24 bits)

Le champ extended highest sequence number received (32 bits)

Le champ interarrival jitter (32 bits). C'est une estimation de l'intervalle de temps d'un packet de donnés RTP qui est mesuré avec le timestamp et qui est sous forme d'un entier. C'est en fait le temps relatif de transit entre deux paquets de donnés. L'interarrival jitter est calculé à chaque packet de donnée reçu par la source

Le champ last SR timestamp (32 bits)

Le champ delay since last SR (32 bits)

4.1.3 Le protocole RSVP

Le protocole RSVP est une proposition de standard faite par l'IETF pour répondre aux besoins de qualité de service sur les réseaux IP tel qu'Internet. Ce protocole a été conçu de manière à donner une priorité à chaque application de « streaming », que ce soit de l'audio ou de la vidéo, du moment qu'elle génère un trafic continu. RSVP fonctionne en permettant à une application qui transmet ses données à travers une certaine route, de réserver un certain niveau de bande passante sur cette route. Cette réservation de ressource est appelée réservation "soft" car pour qu'elle perciste il est nécessaire au client de réémettre des demandes de réservation. Deux classes de réservation ont été définies :

Une réservation contrôlant la charge qui se rapproche du mode best effort en mode non congestionné

Une réservation de garantie de service apportant un service qui garanti à la fois la bande passante et le délai de transmission

Dans cette solution chaque équipement disposé sur la route entre le client et le serveur devra réserver pendant tout le temps de la communication la bande passante préconisée par l'application temps réelle.

4.1.4 Le protocole RTSP

RTSP est un protocole de niveau applicatif, qui propose de fournir un protocole solide pour délivrer en Unicast ou Multicast du contenu multimédia. Il propose également d'assurer l'interopérabilité par l'intermédiaire d'un standard entre les clients et les serveurs provenant de différents développeurs. Les flux multimédias diffusés par les serveurs de stream sont, en général, lu par le client à la volée. L'idée principale derrière l'utilisation de RTSP est de proposer au client une sorte de « télécommande réseau » pour commander le serveur de diffusion. Ainsi, par l'intermédiaire du protocole RTSP, le client est libre d'arrêter le flux provenant du serveur (mode pause) ou de manière plus intéressante, d'accéder directement une partie avancée du média sans avoir à télécharger la partie passée (mode avance rapide). Il propose également au client la possibilité de négocier certaines options avec le serveur comme par exemple le type de protocole de transport à utiliser (UDP ou TCP). De la même manière le serveur peut être amener à envoyer des requêtes au client comme la demande d'émission de compte rendu sur la qualité de la connexion pour adapter, si il est nécessaire, la nature du flux.

Voici les principaux points forts du protocole RTSP :

Extensible (nouveaux paramètres et nouvelles méthodes peuvent être aisément implémentés)

Facile à lire (les parseurs standard HTML ou MIME peuvent être utilisés)

Sécurisé (méthode d'authentication HTTP, mécanisme de sécurité applicable sur les couches transports ou réseaux)

Indépendant de la méthode de transport (les protocoles tels que UDP, RDP et TCP sont supportés)

Capacité à gérer plusieurs serveur de diffusion (il peut y avoir plusieurs flux de différents serveurs de diffusion à l'intérieur d'une même présentation)

Commande de contrôle de l'enregistrement (les deux fonctions de lecture et d'enregistrement peuvent être utilisées par le client)

Séparation du contrôle du flux multimédia et de la commande d'ouverture du média

Description des données neutre (pas de format particulier imposé, le format des descriptions doit nécessairement contenir au minimum l'URI RTSP du média)

Fonctionne avec proxy ou firewall

Fonctionne avec HTTP (RTSP réutilise les concepts HTTP)

Control du serveur distant

Type du transport négociable (la méthode de transport peut être négociée avant la diffusion du média)

Capacité de négociation (le client doit avoir le moyen de savoir si certains services de base ont été retirés du serveur)

Protocole RTSP sur RTP

Messages échangés lors d’une connexion RTSP

4.1.5 Comparaison de RTP / RTSP dans HTTP

Nous avons jugé important d’aborder cet aspect du fonctionnement de la diffusion de contenu multimédia sur Internet parce que cette situation peut être rencontrée dans de nombreux cas. En effet, nous savons bien aujourd’hui qu’une faible minorité des stations personnelles connectées disposent d'une adresse IP publique et donc que la majeur partie des utilisateurs d'Internet se trouve placés derrière des firewalls ou des proxys.

Pour les flots temps réels, l'encapsulation des données par HTTP n'est pas envisageable. Par contre, pour tout autre type de diffusion vidéo cette solution a de bonnes raisons d'etre employée.

Les pour et les contre sur l'usage de RTP / RTSP :

Pour	Contre
Seule solution pour transmettre du contenu temps réel	Nécessite un serveur de streaming et un broadcaster
Support des modes broadcast et multicast (un seul flux pour de plusieurs clients)	La vidéo est coupée si le flux de donnees est supérieur à la bande passante disponible
Accès aléatoire pour les vidéos pré-enregistrées	Les transmissions sont plus sujètes à la perte de données
N'utilise jamais plus de bande passante que nécesaire	Peut etre bloqué par certains NAT ou FireWall
Ne laisse pas de copie de la vidéo sur le disque dur du client

Les pour et les contre sur l'usage du protocole HTTP :

Pour	Contre
Pas de serveur particulier nécessaire	Ne peut pas utiliser les modes de fonctionnement en broadcast ou multicast
Les vidéos transitent du serveur au client sans besoin particulier de qualité de services	Ne peut pas transmettre de flot temps réel
Dans ce mode de fonctionnement la vidéo est lu au fure et à mesure qu'elle est téléchargée ce qui donne un aspect de streaming au client	Ne peut pas sauter un passage de la vidéo sans télécharger tout le début
Permet de délivrer tout type de médias	Dépose une copie du média sur le disque dur du client
Les paquets perdus sont retransmis jusqu'à ce qu'ils soient reçus
Pas de problèmes particuliers avec les FireWall ou les NAT

4.1.6 Le protocole SMIL (Synchronized Multimedia Integration Language)

SMIL, Synchronized Multimedia Integration Language (prononcé "smile"), a été approuvé par le World Wide Web Consortium en 1998 en tant que marqueur standard pour les applications de streaming. Ce protocole est principalement utilisé pour les services de streaming vidéo à la demande pour introduire au sein de la présentation une interactivité plus forte avec l'utilisateur. Il a été conçu par le consortium W3C. Son implémentation permet d'introduire du texte, des animations ou des liens hypertextes à une vidéo de manière synchrone. Ainsi, les vidéos peuvent être enrichies à loisir de textes explicatifs, de liens hypertextes, ou bien d'animations faisant ressortir les points importants. Ces exemples peuvent être abondamment employés dans le cadre de vidéos sur demande, de e-learning, de présentations commerciales ou bien encore tout autre cas où le streaming enrichi peut rendre les utilisateurs plus captif. SMIL permet la combinaison de médias riches dans un ensemble cohérent. A travers l'utilisation de SMIL, il est désormais possible de concevoir et de diffuser du contenu multimédia et interactif à toute personne possédant un ordinateur et connectée à Internet.

4.2 La compression des médias

4.2.1 Présentation

Comme nous l'avons vu dans la partie introductive de notre présentation, le frein majeur au développement des applications multimédia proposant du contenu audio ou vidéo provient de la faible bande passante disponible chez chacun des clients. Le format de la vidéo transmise au client dépend donc principalement de la bande passante dont les principaux clients vont disposer. C'est pourquoi la qualité des algorithmes de compression utilisés n'est pas un point à mettre de coté lors de la sélection du serveur de streaming.

Il existe deux familles différentes de compression : la compression sans perte et celle avec. La compression sans perte se base sur la fréquence d'apparition de mots binaires dans le flux binaire représentant une image ou une source audio. Elle réduit la quantité d'information à transmettre aux clients en comptabilisant le nombre de fois qu'apparaît continuellement chacun des mots binaires les plus fréquemment rencontrés. La compression avec perte, quand à elle, réduit la quantité d'information à transmettre en dégradant sensiblement les données tout en conservant l'information la plus pertinente du média.

Les perceptions auditives et visuelles humaines ayant une limite, les formats de compression les plus fréquemment rencontrés pour la compression des médias du type audio ou vidéo appartiennent à la famille des compressions avec perte. Ces formats de compression permettent d'obtenir des ratios avoisinant le 1:10 tout en conservant une qualité visuelle ou auditive.

D'un autre coté, ce qui fait l'intérêt d'un algorithme, vient de sa légèreté, en terme de puissance de calcul nécessaire, à compresser et à décompresser la source. Cette qualité, caractérisera la capacité du serveur de streaming à répondre aux demandes.

4.2.2 Les formats de compression audio

La compression est une compression destructrice, cependant non perceptible par l’oreille humaine. En effet, c’est la partie inaudible du spectre du signal qui est supprimée.

Dans l'industrie du streaming audio il existe trois principaux concurrents en matière de format de compression :

Le format MPEG Layer III, communément appelé format MP3 qui est certainement le plus répandu

Le format OGG Vorbis, qui est employé de manière similaire au format MP3 mais il reste moins répandu malgré toutes ses qualités

Le format RealAudio est un format propriétaire développé par Sony sous le sigle : ATRAC3

Windows Média Server propose également le format de fichier propriétaire WMA

Support	RealAudio	ICE-Cast	Shout-Cast	Windows Media	Darwin (QuickTime)
Codec	MP3 / Sony ATRAC3	MP3 / OGG	MP3	MP3 / WMA	MOV / MP3

4.2.3 Les formats de compression vidéo

4.2.3.1 Présentation

Les formats de compression vidéo ont subi de grosses modifications lors de ces deux dernières années en proposant des formats capables de réduire de plus de 60% la taille d'une vidéo avec un taux de perte avoisinant les 15%. Aujourd'hui la qualité des codecs de compression est telle qu'il est possible de diffuser un film de qualité VHS à des clients équipés de liaison Câble ou DSL ce qui devient de plus en plus courant. Mais il ne faut en aucun cas négliger les personnes connectées en bas débit, c'est pourquoi les majors de la diffusion de vidéo (RealNetworks et Microsoft), qui se sont principalement concentrés sur la diffusion de flux vidéo sur le réseau Internet, ont choisi d'orienter leurs serveurs respectifs de manière à ce que la qualité vidéo restituée au client soit choisie en fonction de la qualité de sa connexion. Cette qualité peut être évaluée sur de multiples critères comme la bande passante, le taux de perte, etc. D'un autre coté, le troisième gros fournisseur de vidéo sur demande (QuickTime Media) ne se restreint pas à la diffusion de vidéo sur Internet mais est également très fréquemment utilisé dans le cadre d'applications interactives disponibles sur cédéroms ou sur tout autres types de médias de grande capacité de stockage et de taux de transfert.

4.2.3.2 Les codecs standards

H 261 : flux constant P*64 kbit/s privilégie la fluidité de l'animation à la qualité

H 263 : identique à H 261 mais supporte les hautes qualités

MJPEG : compression des frames une à une au format JPEG sans corrélation entre elles utilisé pour les softs de montage vidéo pour minimiser les traitements

MPEG-1: faible bit/rate 1-1,5 Mbit/s introduit des infos de prédiction -> léger retard de N frames pour la vidéo conférence ! Ce format a une haute sensibilité à la perte de paquet ! De plus, il segmente le flux vidéo par suppression des frames d'information B et P -> dégradation de la qualité d'image

MPEG-2 : amélioration du MPEG-1 pour autoriser le support des hautes résolutions -> augmentation de la BP nécessaire : 4-15 Mbit/s. Il est utilisé pour la diffusion TV Sat et DVD. 5 chaînes TV MPEG-2 passé sur un canal radio satellite autrefois réservé à un chaîne analogique

MPEG-4 : Ce format n'est pas un format de compression classique comme les précédents puisqu'il intègre dans ses fondements la notion de couches (layer en anglais) ce qui permet de diffuser un contenu multimédia riche. Plus généralement il permet la description standard d'une scène. D'autre part il introduit de puissants algorithmes de compression pour la vidéo basés sur la compression spatiale et temporelle.

5 Présentation des principales solutions existantes

5.1 Shoutcast

5.1.1 Présentation

Shoutcast est une solution de streaming audio développé par Nullsoft, société créatrice de Winamp (lecteur mp3). Shoutcast est un serveur de streaming de mp3, utilisable gratuitement pour une utilisation privée et soumis à l’achat d’une licence pour une utilisation commerciale (299$ par serveur). Cette solution est donc très répandue sur internet. En effet, ce serveur fonctionne bien et est assez simple à utiliser. Initialement développé sous Windows, Shoutcast a été porté sous Unix (Linux, Solaris, BSD).

5.1.2 Fonctionnement

Un serveur Shoutcast fonctionne sur la machine serveur. De plus, le flux audio à transmettre doit être envoyé au serveur shoutcast. Cela se fait par l’intermédiaire d’un lecteur mp3 disposant d’un pluggin lui permettant de se connecter au serveur Shoutcast (Winamp sous Windows ou XMMS sous Linux). Le choix des morceaux à diffuser se fait grâce à l’interface du lecteur mp3. Le flux audio est alors encodé par le pluggin. Il se charge du réencodage du mp3 à l’échantillonnage désiré et de la transmission vers le serveur. Le serveur relaie ensuite le flux audio à chaque client. Le protocole utilisé est TCP/IP. Une nouvelle connexion TCP est créée pour chaque client.

5.2 ICE Cast

5.2.1 Présentation

ICE-Cast est un système de diffusion de contenu audio sur Internet basé sur la technologie MPEG. Il permet à toute personne dotée d'un ordinateur et d'une connexion à Internet de diffuser un flux audio à autant de clients que sa bande passante le permet. La plate-forme de développement d'icecast est une plate-forme Linux, mais les créateurs l'ont testé sur les plus importants systèmes Unix. Depuis sa version 1.3 icecast peut etre employé sur des machines ayant un système d'exploitation Microsoft (Windows 98/NT). De plus, il existe également une version Java en développement qui rend possible l'utilisation de ce serveur sur les plate-formes équipées de systèmes OS/2 ou BeOS.

ICE-Cast est le concurent direct de Shout-Cast.

5.2.2 Organisation de l'application

Le coeur de l'application est constitué du serveur de diffusion de contenu et d'un mini serveur HTTP destiné à son administration. Ce serveur HTTP est optionnel et le serveur ICE-Cast peut très bien fonctionner sans son utilisation. Autour de ce serveur ont été développés de nombreux services destinés à gérer le contenu audio à diffuser. Ces services regroupes les fonctions de choix des morceaux à diffuser (ce choix peut être fixé ou laissé à l'utilisateur), choix de la qualité (taux de compression / fréquence d'échantillonnage) du flux audio à diffuser, diffuser du contenu audio live ou bien encore mixer plusieurs flux audio entre eux (type radio FM).

5.3 Real Server

RealServer est un serveur de streaming assurant un grand nombre de services à des coûts plus ou moins faible dépendant principalement du nombre de clients que le serveur va être amené à servir. Ce serveur de streaming assure un faible coût d'administration (Possiblité de configurer et de surveiller à distance le fonctionnement du serveur par l'intermédiaire d'une interface web simple et bien fournie).

D'autre part le serveur permet une répartition des médias sur plusieurs serveurs RealServer pour découper le coût en bande passante et pour assurer une redondance des équipements et des médias assurant le non-arrêt du service en cas de panne de l'un des serveurs.

Le serveur RealServer permet la diffusion de clip multimédia à travers l'usage de fichiers de type SMIL il est possible de combiner plus de 45 types de médias pour créer des présentations interactives incluant par exemple des MP3 et du Flash 4 de Macromedia.

De plus, RealAudio 8 intègre le format audio Sony ATRAC3, et un format vidéo offrant une qualité visuelle équivalente à un format VHS classique pour un débit de 80kbit/s.

Pour conclure cette présentation, il est important de noter que son déploiement sera indépendant du type d'OS utilisé, RealSystem supporte 10 systèmes d'exploitation, incluant Windows 2000, Windows NT, Linux, Solaris, HP/UX, AIX et FreeBSD.

5.4 Windows Media Server

5.4.1 Présentation

La solution de streaming de Microsoft se divise en deux produits principaux :

Windows Media Services : service de streaming de Windows NT et 2000 Server.

Windows Media Encoder : logiciel Microsoft permettant le streaming de flux video/audio en temps réel sous Windows 98 / ME / NT / XP / 2000

5.4.2 Fonctionnement

5.4.2.1 Windows Media Services

Windows Media Services est un serveur de streaming qui fonctionne en tant que service de Windows NT 4 ou Windows 2000 Server.

Windows Media Services peut utiliser trois protocoles différents : UDP, TCP, ou HTTP.

Quand un client se connecte sur le serveur, le protocole UDP est d’abord utilisé. Si la connexion ne peut se faire correctement en UDP, TCP sera utilisé. Si aucun de ces deux protocoles ne peut garantir une bonne qualité de connexion, HTTP sera alors utilisé. Ainsi à chaque fois, Windows Media Player utilise le protocole de diffusion le mieux adapté à la connexion de l’utilisateur.

En plus de ces trois protocoles standards, Windows Media Services utilises trois autres protocoles pour transférer des informations entre différents serveurs Media Services et des données unicast : HTTP, Media Stream Broadcast Distribution (MSBD) et Microsoft Media Server (MMS) protocol.

5.4.2.2 Windows Media Encoder

Cet outil permet la conversion des fichiers AVI, WAV et MP3. Il permet aussi la diffusion de flux vidéo ou audio via unicast ou multicast. Cette diffusion se fait soit à partir d’un fichier à streamer, soit à partir d’un périphérique d’acquisition comme une caméra ou un carte de capture vidéo. Windows Media Encoder peut aussi encoder des données qui seront diffusées ultérieurement via Windows Media Services.

5.5 Darwin

5.5.1 Présentation

Darwin est un projet OpenSource développé par l’initiative d’Apple et regroupant tout une série d’outils libres de droits. Parmi ces outils nous retrouvons un serveur de streaming audio / vidéo libre de droit et regroupant la quasi-totalité des services proposés par ses concurrents directs. L’approche d’Apple est très proche de celle adoptée par RealNetworks. Ce serveur est capable de gérer jusqu’à 4000 connexions et permet de construire un véritable réseau de serveurs très simplement. De plus, ce serveur a été porté sur la plupart des OS, ce qui le rend indépendant de la plate-forme désirée. En plus de ses nombreux avantages il est important de noter que sa nature Open Source lui confère l’assurance que les futurs standards gravitant autour de la diffusion de contenus multimédias ont de grandes chances d’être implémentés.

5.5.2 Fonctionnement

Le serveur est constitué de trois éléments différents. Le serveur central reçoit les requêtes des clients, construit une session, joint la source désirée et renvoie le flux temps réel associé aux clients. Les serveurs de diffusions sont la plupart du temps sur une machine indépendante de celle recevant les demandes de médias. Dans la solution développée par Apple seul le serveur central est fourni, les logiciels d’encodage et de broadcasting doivent être récupérés ailleurs. Mais pour un fonctionnement « sur demande », le serveur de streaming de Darwin propose deux modules supplémentaires (un pour le son, l’autre pour la vidéo) capables de diffuser des fichiers sons ou vidéos pré-formatés.

Ce serveur peut être interrogé par l’intermédiaire du protocole RTSP. D’autre part pour assurer un compatibilité avec le maximum d’utilisateur d’Internet il autorise l’usage de RTP / RTSP encapsulés dans le protocole HTTP. Ce transport de message permet la communication avec des stations situées derrière des proxy ou des firewall sans poser le moindre problème de compatibilité à condition que le proxy supporte la norme 1.1 du protocole HTTP puisque la méthode POST est abondamment employée dans ce cas.

6 Tests des applications

6.1 Tableau Récapitulatif

Support	Real Media Server	ICE-Cast	Shout-Cast	Windows Media	Darwin (QuickTime)
Audio	Oui	Oui	Oui	Oui	Oui
Vidéo	Oui	Non	Non	Oui	Oui
Codec	MP3 / Sony ATRAC3 / MPEG-4	MP3 / OGG	MP3	WMA / WMC / WME / ASF / MPEG-4	MOV / MP3 / MPEG-4
Administration distante	Oui	Oui	Oui	Oui	Oui
Intitulé des médias	Oui	Oui	Oui	Oui	Oui
Choix du média	Oui	Oui	Oui	Oui	Oui
Type de connexion	UDP / TCP / HTTP	TCP	TCP	UDP / TCP / HTTP	UDP / TCP / HTTP
Multicast	Oui	Non	Non	Oui	Oui
Unicast	Oui	Oui	Oui	Oui	Oui
Rééchantillonage	Oui	Oui	Oui	Oui	Oui
Qualité adaptative	Oui	Non	Non	Oui	Non
Fichier de log	Oui	Oui	Oui	Oui	Oui
RTP	Oui	Non	Non	Oui	Oui
SMIL	Oui	Non	Non	Non	Oui
RTSP	Oui	Non	Non	Oui, implémentation très efficace	Oui, implémentation très proche du standard
RSVP	Oui	Non	Non	Oui	Oui
Multi-processeur	Oui	Oui	Oui	Oui	Oui
Coût	Payant pour plus de 500 connexions simultanées	Gratuit	Gratuit	Payant	Gratuit
OS	Windows 95 Windows 98 Windows 2000 Windows NT Linux Solaris 8 HP/UX AIX FreeBSD	Windows 95 Windows 98 Windows NT Windows 2000 Linux glibc FreeBSD 3.x BSDi Solaris 8 Mac OS X	Windows 95 Windows 98 Windows NT Windows 2000 Linux glibc FreeBSD BSDi Solaris 8	Windows 98 SE Windows ME Windows NT 4 Windows 2000 Windows 2000 Server	Windows 95 Windows 98 Windows NT Windows 2000 Linux Solaris 8 FreeBSD Mac OS X

6.2 Shoutcast DNAS (Distributed Network Audio Server)

Nous avons testé le serveur Shoutcast sous Windows 2000 et sous Linux (noyau 2.4) : les performances sont équivalentes, il n’y a pas de réelles différences entre ces deux versions. On pourra préférer la solution fonctionnant sous Linux pour des raisons de stabilité dû au système d’exploitation et non à Shoutcast. Cependant la version Windows est plus aboutie est présente moins de bugs (bug sur l’historique des morceaux diffusés par exemple).

6.2.1 Trafic généré

Pour chaque client une connexion est établie, et un flux audio est transféré, il ne s’agit pas de multicast mais plutôt d’unicast (un flux par client). Le trafic se compose d’un flux audio et d’un flux de données. Le flux de données est un flux http permettant de gérer l’interface utilisateur et l’administration à distance du serveur. Le protocole utilisé est TCP, cela permet d’envoyer un flux audio et un flux de données sur la même connexion (même port).

Le flux audio dépend de la qualité d’échantillonnage choisi. Le serveur envoie 1024 octets de données pour chaque client puis s’arrête pendant une certain temps (833 microsecondes par défaut). Il recommence ensuite le processus. Cela permet de réduire l’occupation processeur sans nuire à la qualité de transmission.

6.2.2 Choix des morceaux par le client

Le client peut soit écouter le flux audio transmis par défaut, soit choisir un morceau spécifique. En effet, le serveur possède un répertoire « content » par défaut, qui contiendra tous les mp3 accessibles par le public. Cette fonctionnalité est la même que celle fournie par IceCast. Cependant le serveur IceCast possède par défaut la possibilité d’avoir la liste des morceaux au niveau de l’interface client.

6.2.3 Echantillonnage

Un grand nombre d’échantillonnages différents sont supportés par Shoutcast.

Voici un tableau les présentant :

Quality	Transfer Rate	Attributes
Voice	14.4kbps	8 kBit/s, 11,025 Hz, Mono
Voice	19.2kbps	20 kBit/s, 11,025 Hz, Mono
Radio	28.8kbps	20 kBit/s, 11,025 Hz, Stereo
Radio	33.6kbps	24 kBit/s, 11,025 Hz, Stereo
Record	48.0kpbs	32 kBit/s, 11,025 Hz, Stereo
Cassette Tape	64kbps ISDN	48 kBit/s, 22,050 Hz, Stereo
Cassette Tape	96kbps ISDN	56 kBit/s, 22,050 Hz, Stereo
Concert	128kbps ISDN	64 kBit/s, 44,100 Hz, Stereo
CD Audio	384kbps DSL or Equivilent	128 kBit/s, 44,100 Hz, Stereo

Interface du serveur Shoutcast

Interface du broadcaster Shoutcast

6.3 IceCast

6.3.1 Caractéristiques

Le logiciel IceCast a été testé sous Linux. Cette application se rapproche beaucoup de Shoutcast, cependant elle possède quelques avantages en plus : des fonctionnalités plus nombreuses et de plus grandes possibilités d’administrations. En effet, IceCast peut-être entièrement administré à distance (par serveur web, ou par connexion de type telnet). Les mêmes fonctions sont accessibles aussi bien en local qu’à distance. De plus, IceCast permet à l’utilisateur de choisir le morceau qu’il désire écouter : il se connecte sur le serveur web intégré et consulte la liste des morceaux disponibles. Pour chaque morceau choisi, un flux unicast sera créé vers le client.

En effet, comme Shoutcast, IceCast fonctionne principalement en unicast, le multicast n’étant pas encore suffisamment intégré dans le réseau public.

6.3.2 Occupation du processeur

Comme Shoutcast, le serveur en lui-même occupe très peu de processeur. Ce sont les traitement d’échantillonnage, d’une part, et les traitements de diffusion, d’autre part, qui vont être consommateur de CPU. Par conséquent on pourrait croire que plus le nombre d’utilisateurs est important, plus le serveur consomme de temps processeur. En pratique, ce n’est pas le cas, le serveur occupe un pourcentage de temps processeur négligeable, c’est le ré-échantilloneur mp3 qui travaille le plus.

Que l’on est 1 ou 10 clients connectés la charge CPU affichée est la même. L’ordinateur utilisé pour le test est un Pentium II 500Mhz et le gestionnaire de tâche n’affiche aucune différence.

Ce serveur apparaît comme un très bon produit, gratuit et doté de nombreuses possibilités.

6.4 Windows Media Server

Les tests effectués ont portés sur Windows Media Encoder qui se charge se charge de l’encodage et de la diffusion.

6.4.1 Trafic généré

Le trafic peut être soit en unicast, soit en multicast.

Il est possible d’utiliser l’une ou l’autre des solutions. Il est recommandé d’utiliser l’unicast sur Internet et le multicast sur son propre réseau. En effet, les routeurs traitant les flux de données doivent être capable de traiter les flux multicasts et ce n’est pas le cas de tous les routeurs présents sur internet.

Les flux audio et vidéo dépendent de la qualité d’échantillonnage choisie et de la taille de la vidéo.

Windows Media Server est capable de faire de la diffusion vidéo en s’adaptant au réseau du client. Le débit peut alors varier en fonction de la qualité de connexion du client (taux de perte, délais de transmission). Bien entendu cela n’est valable que pour la diffusion unicast, en effet lors de la diffusion multicast les clients n’ont pas de connexion avec le serveur et ne peuvent pas négocier leur propre bande passante, il n’y a qu’un seul flux.

6.4.2 Occupation du processeur

Si le streaming audio ne demande pas beaucoup de travail au processeur, la diffusion de vidéo est beaucoup plus coûteuse. L’encodage est assez lourd : sur un Pentium II 500, 128 Mo RAM, Windows 2000, le serveur prends 80% du temps processeur.

Cependant cela dépend de ce que l’on diffuse, un fichier compressé en divx est beaucoup plus gourmand en terme de processeur qu’un simple fichier avi ou mpg.

Component	Minimum required	Recommended	Optimal
Processor	Intel Pentium 166 MHz	Dual Intel Pentium II 400 MHz or better; Alpha processor	Eight Pentium IV-type processors (the fastest available)
Memory	128 megabytes (MB)	256 MB or greater	512 MB
Network card	10-Mbps TCP/IP Ethernet card	10/100-Mbps TCP/IP Ethernet card	Two 10/100 Mbps TCP/IP Ethernet cards
Available hard disk space	21 MB for Windows Media Services; enough disk space for content storage	21 MB for Windows Media Services; 500 MB or more disk space for content storage; SCSI RAID 0	Sufficient storage for on-demand content; SCSI RAID 0
Software	Internet Explorer 4.01 or later; Windows NT Server 4.0 with Service Pack 4	Internet Explorer 4.01 or later; Windows NT Server 4.0 with Service Pack 4 or later or Windows 2000 Server	Internet Explorer 4.01; Windows NT Server 4.0 with Service Pack 5 or Windows 2000 Server

Windows Media Server requirements

Interface de Windows Media Encoder

6.5 Darwin

Tout comme ses concurrents Darwin peut fonctionner en mode Unicast ou Multicast. En fonctionnement unicast, il construit une session pour chaque demande de connexion et relaye les flux multimédias demandés. Lorsque toutes les clients associés à ces flux sont déconnectés il libère les ressources mises en œuvre pour la connexion avec le broadcaster.

Les tests effectués sur le serveur Darwin se sont portés uniquement sur le serveur central de réception et de traitement des requêtes.

Il est intéressant de noter que l’inter-opération entre l’encodeur / broadcaster est moins évidente que dans les solutions offertes par les concurrents. Mais d’un autre point de vue, elle parait plus standard et devrait fonctionner avec la majeur partie des logiciel de broadcast.

Interface de Darwin

6.6 Real Server

RealServer intègre un panneau d'administration plus complet que Darwin. Il intègre une gestion des droits plus évolué puisqu'elle peut s'appuyer sur une base de données. Nous comparons ici l'interface des RealServer et de Darwin puisqu'elle s'appuie toutes deux sur une interface HTML (+ Java pour RealServer).

Dans les fonctions particulières de RealServer, on apréciera tout particulièrement l'ajout de bannière d'information pouvant être publicitaire ou informationnelle. D'autre part il est important de noter que RealServer est compatible avec les fonctions de base du protocole RTSP.

Interface d’administration de Real Server

7 Conclusion

Le monde du streaming sur Internet est en perpétuelle évolution et les premiers services de diffusion réellement basés sur RTP sont difficilement déployables. Ceci est principalement dû à la présence fréquente de firewall ou de proxy.

HTTP fonctionne partout pour tout le monde, c'est donc le type de connexion qu'on retrouve la plupart du temps, meme pour les services professionnels. La diffusion audio peut se contenter du protocole HTTP mais la vidéo nécessite des services supplémentaires comme RTP, RTCP pour atteindre un niveau de qualité acceptable dans le cas de la diffusion de vidéos longue durée.

En matière de diffusion vidéo, dans le cadre du déploiement d’une solution professionnelle, notre choix s’appuierait plutôt sur la solution offerte par RealNetworks car, d’un point de vue technique, elle offre plus de choix de configuration. De plus, tout comme la solution d’Apple, elle permet une très grande interopérabilité avec les logiciels de diffusion. En prenant en compte l’aspect financier du déploiement d’un service de diffusion sur Internet, le choix du serveur de streaming peut être amené à pencher pour la solution OpenSource et gratuite proposée par Apple. Quand à la solution de Microsoft, qui est propriétaire de bout en bout, elle fournie une alternative attrayante pour les entreprises entièrement équipées de produits Microsoft.