Poussée par la montée en puissance des connexions à haut débit, la vidéo en ligne continue sa progression.
Quoique simple en pratique, la diffusion peut s'inscrire dans plusieurs schémas bien distincts.
Il est important de choisir le sien avant de se lancer.

par Erwan Barret
SVM Mac 130 - Juillet - Août 2001

La notion de streaming n'a pas vraiment d'équivalent en français. La traduction "enchaînement", proposée par Apple, est un peu vague, la notion étant plus proche de la livraison de données en flux tendu. Pour commencer, il existe un faux streaming qui n'est que la lecture progressive d'un fichier distant pendant son téléchargement. Il impose un temps de latence, nécessaire au chargement des premières secondes. La suite du fichier est chargée pendant la lecture de ces premières secondes et ainsi de suite. Souvent montré du doigt comme un défaut de cette méthode de transmission, le temps de latence se retrouve en fait avec le "vrai streaming", qui nécessite la mise en phase du client et du serveur.

Le vrai streaming consiste à envoyer au client uniquement les informations dont il a besoin, sans qu'il ait jamais à les stocker dans leur ensemble. Le cas le plus courant est la bande-annonce d'un film, préparée à l'avance et stockée sur un serveur. Elle est bien envoyée au client dans son intégralité, mais seulement sous forme de morceaux, effacés après visualisation, à mesure qu'arrivent les suivants. Le fin du fin, c'est le streaming en temps réel, parfait équivalent de ce qu'est le direct à la télévision. Une caméra vidéo est branchée sur une machine chargée de l'encodage en temps réel, elle-même reliée à une autre machine servant à la diffusion. C'est sur cette dernière que se trouve le serveur de diffusion.

Les atouts de QuickTime

Format de streaming par excellence sous Mac OS, QuickTime est connu pour sa capacité à gérer de très nombreux formats de fichiers, dont la majorité peut être transmise en RTP (Realtime Transport Protocol). Les flux vidéo, audio (y compris MP3), texte et MIDI reconnus offrent déjà plus de possibilités que n'en réclament la plupart des programmes. Seules les fonctions spécifiques ajoutées à QuickTime dans sa version 3 (effets spéciaux et pistes de sprites) requièrent une transmission classique en HTTP ou FTP. Pour pouvoir diffuser un fichier en streaming, il est donc nécessaire d'adapter, mais aussi d'indexer son contenu. Au moment de l'export avec le lecteur QuickTime, il faut choisir l'option Export Movie to Hinted Movie pour créer un fichier plus volumineux. Il contiendra toutes les informations nécessaires au serveur de diffusion.

Tout fichier transmis en continu possède une piste de streaming (strm), qui comporte, en fait, l'URL des différents médias à charger, quelle que soit leur nature. En réalité, la souplesse de QuickTime va encore plus loin, puisque plusieurs fichiers source peuvent être combinés en un seul fichier cible. On peut très bien lire, sur son navigateur, une séquence dont le son et l'image ne proviennent pas des mêmes fichiers. Peu utile pour des applications simples, cette souplesse prend tout son sens en diffusion professionnelle. Une chaîne d'actualité peut ainsi proposer du direct, du différé, un habillage et un résumé en texte, le tout sur une seule occurrence du lecteur client, et à partir d'autant de sources qu'il y a de médias concernés.

Le streaming est apparu avec la version 3 de QuickTime, qui autorisait le chargement progressif. Presque toujours employée en HTTP (le protocole du Web), cette fonction est aussi disponible en FTP (protocole de téléchargement). Tous deux font appel à l'option d'enregistrement QuickStart, destinée à autoriser la lecture d'un fichier avant qu'il soit complètement chargé. Comme il s'agit, en fait, d'un simple transfert de fichiers amélioré, on peut enregistrer le document source à la fin du chargement. Autre avantage : on peut envoyer absolument n'importe quel type de fichier QuickTime ; rien n'est modifié et les firewalls ne posent généralement aucun problème. Mais on est encore loin du streaming de la version 4, basé sur le protocole RTP.

Une question de protocole

Le RTP repose lui-même sur le protocole UDP (User Datagram Protocol), qui ne renvoie pas les trames perdues en cours de route, afin de privilégier l'enchaînement du son et des images, plutôt que l'intégrité des données. La qualité peut en souffrir si laliaison est mauvaise, mais c'est un mal nécessaire à la diffusion en direct. Comme le fait TCP/IP, le protocole UDP, ou plus précisément UDP/IP, assure le transfert des données entre deux machines, mais sans aucun des nombreux contrôles disponibles avec TCP (Transfer Control Protocol), que ce soit pour assurer l'intégrité des données ou leur acheminement.

Dans le cadre même du streaming, deux possibilités se présentent au diffuseur. La première consiste à envoyer simultanément un flux de données vers tous les clients qui en font la requête. On est dans le cas d'une liaison point à point multiple, ou unicast, généralement en usage sur Internet. L'autre solution est le multicast : on diffuse un flux unique vers un réseau, dont les clients lisent simultanément les mêmes informations. C'est une solution plutôt adaptée aux réseaux d'entreprise. Les deux modes de diffusion diffèrent, l'un faisant appel à un protocole supplémentaire parallèlement au RTP, l'autre se servant directement d'un fichier de description.

Diffusions multicast et unicast peuvent être combinées à l'aide de serveurs de réflexion, pour transmettre des données à la fois vers Internet et vers des réseaux interconnectés qui n'acceptent qu'une diffusion unicast.

Exploité dans le cadre de la diffusion unicast, le protocole RTSP (Realtime Streaming Protocol) n'assure aucune transmission de données, mais transfère au serveur les requêtes du client. Il permet notamment d'employer les commandes du logiciel lecteur sur une séquence en différé, sans devoir charger les segments intermédiaires.

En unicast, le protocole RTP assure le transport unilatéral des données. Le seul rôle du protocole RTSP est de faire transiter requêtes et informations entre le client et le serveur.

Associé au RTP, il offre une souplesse presque équivalente à celle de la lecture d'un fichier en local. Le protocole RTP assure le transport des données proprement dites (on pourrait parler de fichier de streaming), alors que le protocole RTSP ne véhicule que les informations de description d'une session de streaming, un peu à la manière d'une EDL (liste de montage utilisée en vidéo) exportée d'un système de montage numérique à un autre. Alors qu'on pourrait assimiler l'unicast aux applications de VOD (Video On Demand) déjà opérationnelles dans le cadre de la télévision numérique, le multicast reprend le principe de la télévision. Un programme est diffusé vers un nombre plus ou moins grand d'utilisateurs, qui peuvent le voir à un instant donné. De même qu'on fait appel à un programme pour choisir une émission, on se raccorde à un flux multicast en ouvrant un fichier SDP (Session Description Protocol), créé avant la session par un système d'encodage en temps réel comme le Broadcaster de Sorenson. Au lieu d'un numéro de chaîne et d'un horaire, on y trouve une adresse, un numéro de port et les informations sur les différents flux (image, son, texte) qui composent une session. Ce document prend place sur le serveur, dans le dossier destiné à abriter les fichiers à diffuser. Ce même type de fichier sert aux transmissions en direct, quelle que soit la diffusion retenue. Il est lisible par le lecteur ou le plug-in, tout comme une séquence normale.

Encodage et diffusion

Si l'on veut diffuser un programme en direct, il faut réserver une machine à l'encodage du programme et une autre à sa diffusion. Sous Mac OS, c'est le broadcaster de Sorenson qui se charge de l'encodage à la volée.

 

Lors d'une transmission en direct en multicast, les données capturées sont numérisées (si l'on est muni d'un équipement analogique) ou simplement transférées (c'est le cas du DV, notamment) sur un ordinateur avec un logiciel d'encodage. C'est le rôle de la machine de diffusion (improprement appelée broadcaster), qui ne diffuse en fait qu'un seul flux vers un serveur de streaming. C'est depuis ce dernier que QuickTime Streaming Server ou un logiciel serveur équivalent (voir encadré) envoie le flux encodé, reçu par l'intermédiaire du réseau local. Si le contenu vidéo est inclus dans une page Web,l'intégration doit être configurée à ce niveau. Dans le cas contraire, on accède à la vidéo en se connectant directement depuis le lecteur QuickTime. Le flux est ensuite transmis soit vers un MBone (Multicast Backbone), sur lequel les clients peuvent se brancher directement à l'aide d'un fichier SDP, soit vers un serveur de réflexion, qui relaie ce flux si nécessaire. On emploie généralement ce type de serveur pour contourner un firewall ou un réseau à configuration particulière, au lieu de recourir à l'encapsulation d'un flux RTP dans des trames HTTP.

La page Web de configuration de QuickTime Streaming Server. Le paramètrage se fait par l'intermédiaire d'une page Web (sur le port 1220 de la machine Localhost). Cette façon d'opérer le rend à la fois simple, facile à mettre à jour et portable.

Trafic limité

Bien que d'autres protocoles soient à l'étude, le multicast basé sur RTP est la plus aboutie des solutions opérationnelles à l'heure actuelle, car elle limite au strict minimum le trafic sur le réseau. Mais qu'on travaille en unicast ou en multicast, il s'agit bien de streaming et non plus de chargement avec lecture simultanée. Conséquence directe : on ne peut pas enregistrer le fichier visionné à la fin du transfert, puisqu'il n'a tout simplement jamais existé. On a lu morceau par morceau un fichier enregistré sur un disque distant, à partir duquel on ne peut pas copier de fichiers en direct, puisque le protocole lui-même l'interdit. Ce qui est finalement l'un des buts de ce type de transmission.

 

Serveurs : QTSS ou DSS ?
Sur quelle plate-forme diffuser ? Si la question se pose aussi ouvertement, c'est que la mise à disposition en Open Source du Darwin Streaming Server (DSS), le serveur au cœur de Mac OS X, permet à n'importe qui de l'intégrer dans son propre système. On retrouve ainsi DSS sous FreeBSD 4.3 (très proche de Darwin), Red Hat 6.2, Solaris 7 et Windows NT Server 4.0/2000, mais il existe aussi des serveurs de fichiers QuickTime chez des sociétés telles IBM ou Cisco.

Comme le QuickTime Streaming Server, qui est la version pour Mac OS X de ce système, ces serveurs gèrent jusqu'à 2000 connexions simultanées, ce qui, ajouté aux possibilités illimitées des serveurs de réplication, permet une diffusion à très vaste échelle. QuickTime Streaming Server est encore en version 2, mais on peut aussi charger la mouture préliminaire de la version 3 sur le site d'Apple.

Tous ces systèmes offrent à la fois simplicité et souplesse : leur configuration, basée sur une interface Web, n'exige pas de grandes compétences, mais seulement la connaissance de quelques paramètres de l'infrastructure informatique de départ. Le travail du webmestre se limite souvent à copier dans un dossier les fichiers à diffuser, et dans un autre, les éventuels documents de remplacement destinés aux logiciels clients plus anciens, obligés d'utiliser HTTP.

Le choix du serveur dépend principalement de l'équipement de l'entreprise. La plate-forme Macintosh est très adaptée à l'encodage en temps réel, pour ceux qui veulent faire du direct. Après, les solutions de diffusion existent sous Mac OS 9, mais elles sont limitées. Enfin, il serait dommage de se priver des performances de Mac OS X Server 2.0 (multiprocesseur), mais il ne faut pas négliger pour autant les solutions concurrentes, peut-être un peu moins performantes, mais souvent plus cohérentes avec le parc de serveurs d'une entreprise.