CHAPITRE 1 : SYSTÈME DE STREAMING : VUE D’ENSEMBLE

1.1 Introduction

Notre époque est incontestablement celle du « multimédia (1) ». En effet, les données statiques, de type texte ou image, ont perdu leur monopole au profit des données audiovisuelles, qui sont maintenant omniprésentes dans la vie quotidienne. Les brochures publicitaires se sont transformées en CDs multimédias. Les panneaux d’affichage se modernisent et deviennent progressivement des téléviseurs, capables de restituer des présentations animées, plutôt que de simples défilements d’images. Plus flagrant encore, les pages Web, qui contenaient majoritairement du texte et des images, regorgent actuellement de vidéos et d’animations.

Il existe deux moyens de consulter des contenus audiovisuels. Le premier est la restitution du contenu dont on dispose soit par la possession d’un support le contenant, soit par le téléchargement via un réseau. Ce moyen implique un temps d’attente non négligeable avant de disposer du contenu, sans parler du fait que l’on peut s’être trompé, pour une raison quelconque, et finalement s’être procuré un contenu qui ne nous intéresse guère. Le second moyen consiste à pouvoir visionner un contenu dès qu’on le souhaite, sans forcément le conserver par la suite. Le contenu est transmis via un réseau et est restitué aussitôt que les premières données arrivent. Cette méthode, appelée « streaming », n’implique pas, ou peu, de temps d’attente avant de pouvoir restituer le contenu, ce qui justifie sa popularité. L’intérêt suscité par les applications de streaming, comme la vidéo à la demande, a donné lieu à de nombreuses réalisations de systèmes permettant la mise en œuvre du streaming audiovisuel. Ces systèmes se sont fait appeler systèmes de streaming[8].

L’apparition de terminaux capables de restituer des données audiovisuelles, combinée avec l’évolution des réseaux grand public, en terme de débit, a permis une accessibilité très large au streaming audiovisuel, ceci se faisant au travers de réseaux ayant des capacités (débit, latence, etc.) très variées, et en utilisant des terminaux ayant des capacités de traitement et de restitution très différentes. Les systèmes de streaming se sont vite trouvés limités et incapables de suivre la demande, sans cesse croissante, de contenus audiovisuels de qualité acceptable et en temps réel. Dès lors est venue l’idée de concevoir des systèmes de streaming pour environnement léger permettant de pallier ces limitations.

Ce chapitre débute par une description des caractéristiques des données audiovisuelles qui imposent des contraintes strictes lorsqu’elles sont transmises en temps réel. Puis, nous poursuivons par une synthèse des différents concepts de base liés au streaming audiovisuel. La section 1.3, couvre les différentes facettes d’un système de streaming et les problématiques qui lui sont associées.

Nous décrivons la notion de cache dans les systèmes de streaming ainsi que ses rôles, ses objectifs et les politiques de gestion existantes. Nous clôturons ce chapitre par une présentation de quelques systèmes de streaming en environnement mobile.

1.2 Les données audiovisuelles

On distingue deux classes de données : les données statiques ou discrètes de type texte ou image, et les données dynamiques ou continues de type audio ou vidéo. Les données dynamiques sont constituées d’une succession cohérente et ordonnée d’entités statiques ayant des dépendances temporelles entre elles. Ces entités peuvent être des échantillons dans le cas d’un son, ou bien des images dans le cas d’une vidéo.

1.2.1 Caractéristiques

À l’opposé des données statiques, les données audiovisuelles sont marquées par leur nature isochrone et extrêmement volumineuse.

Isochronisme

Une caractéristique contraignante et inhérente aux données dynamiques est leur dimension temporelle, appelée aussi contrainte temps réel ou contrainte de continuité. Ces données doivent être restituées à un rythme constant. Par exemple, une séquence vidéo n’est correctement visualisable que si les images la constituant sont affichées à une fréquence constante, en l’occurrence 25 images/seconde (2) (voir Figure 1.1). Cette dimension temporelle impose donc des contraintes strictes en matière de délais à respecter afin d’assurer la continuité des données. Ces contraintes se répartissent à tous les niveaux du cheminement des données audiovisuelles, depuis leur source jusqu’au point de restitution. Les unités de stockage doivent être capables de fournir les données avec un débit approprié.

FIGURE 1.1 – Isochronisme dans une séquence vidéo [3].

Volume important

À l’inverse des données statiques, les données dynamiques sont extrêmement volumineuses et exigent une capacité de stockage très importante (voir Tableau 1.1). Des techniques de compression dédiées ont alors été développées afin d’en réduire le volume, tout en conservant la meilleure qualité possible d’écoute et de visualisation. Ces techniques permettent aux données audiovisuelles d’occuper moins d’espace de stockage. Toutefois, même après compression, les données audiovisuelles demeurent volumineuses. Par exemple, deux heures de vidéo, compressées selon le standard MPEG-2 avec un débit de 4 Mb/s, nécessitent approximativement un espace de stockage de 3,6 Go (cf. table 1.1).

TABLE 1.1: Volume des différents types de données.

1.2.2 Encodage

En raison de leur volume colossal, les données audiovisuelles sont compressées avant d’être emmagasinées (ou transmises), puis sont décompressées avant d’être restituées au spectateur. Les opérations de compression et de décompression, appelées aussi encodage et décodage, ont des caractéristiques opposées. En effet, si les algorithmes de compression peuvent être lents, complexes et coûteux, à l’exception de l’encodage en temps réel comme c’est le cas dans les visioconférence, il n’en va pas de même pour la décompression, qui est quant à elle simple et rapide. La compression ne s’effectue, généralement, qu’une fois au moment de la création, alors que la décompression s’effectue à chaque fois que le contenu est lu par un lecteur audiovisuel.

L’encodage/décodage de données audiovisuelles est effectué par un codec. Les codecs peuvent être logiciels ou matériels, par le biais de cartes dédiées. D’ailleurs, ils sont souvent spécialisés pour l’encodage et/ou le décodage de données audio ou vidéo. On parle alors de codec audio et de codec vidéo. Néanmoins, les différents codecs, après avoir appliqué des algorithmes dédiés au son ou à la vidéo, font appel à des méthodes de compression dites entropiques pour compresser davantage le flux audiovisuel résultant. Il s’agit de techniques de compression de données binaires sans tenir compte de leurs significations comme l’encodage par plage (RLE), l’encodage de Huffman [33, 35] ou plus récemment l’encodage arithmétique [04, 05]. À titre d’exemple, dans le codage par plage, toute suite de bits identique est remplacée par un couple (nombre d’occurrences, suite répétée).

FIGURE 1.2 – Principaux standards de codage audiovisuel.

Encodage audio

Il existe plusieurs techniques de codage pour les contenus sonores, certaines sont dites destructrices et impliquent une perte de qualité, et d’autres non. Les techniques non destructrices exploitent les limites de perception de l’oreille humaine. Cette dernière entend les fréquences situées dans la gamme 20 Hz à 20 kHz. Si un morceau contient des fréquences hors de cette gamme, elles sont simplement supprimées. Une autre technique, considérée non destructrice, s’appuie sur le principe des fréquences masquées [39]. En effet, si dans un groupe de fréquences, certaines ont un niveau sonore beaucoup plus élevé que d’autres, il n’est pas nécessaire de conserver les fréquences de niveau sonore faible : on ne les entendra pas. Par exemple, l’oreille humaine n’est pas capable de percevoir le pépiement des oiseaux lors du passage d’un Concorde.

FIGURE 1.3 – Son numérisé à différentes fréquences d’échantillonnage représenté pour différents nombres de bits [3].

Au rang des techniques destructrices, on trouve principalement les techniques qui permettent de modifier la qualité du son numérisé. La qualité du son est fonction de deux facteurs : la fréquence d’échantillonnage et le nombre de bits utilisés pour représenter chaque échantillon. La figure 1.3 illustre l’influence de ces deux facteurs. La qualité du son compressé est tributaire de la technique utilisée pour son encodage. Les techniques de compression s’étendent des algorithmes peu complexes qui produisent des taux de compression faibles et un son de mauvaise qualité comme la compression selon la loi-A, aux algorithmes complexes qui produisent des taux de compression élevés et un son de bonne qualité comme l’algorithme de compression MP3, en passant par les algorithmes d’une complexité moyenne qui produisent un son de qualité moyenne comme la compression différentielles adaptative (ADPCM).

La compression selon la loi-A [25], qui a fait l’objet d’un avis de normalisation de l’ITU-T, permet de réduire la qualité du son numérisé et résulte d’une fréquence d’échantillonnage de 8kHz codée sur 8 bits. Cette technique convient pour la compression de la parole et a été longtemps utilisée pour la téléphonie numérique ISDN. La technique de compression différentielle adaptative (ADPCM) tire profit du fait que les échantillons voisins sont semblables, et conserve uniquement la différence entre eux, améliorant par conséquent et la qualité du son compressé et le taux de compression [52]. L’algorithme de compression spécifié par le standard MPEG-1, connu sous le nom MP3, exploite le principe de fréquences masquées et atteint des taux de compression nettement plus élevés par rapport aux techniques précédentes [52]. Mieux encore, cet algorithme préserve la qualité du son perçu par l’oreille humaine. En effet, dans une série de tests, dont les détails se trouvent dans [23], des auditeurs experts n’ont pas pu faire la différence entre une bande son stéréo échantillonnée à 48kHz et représentée par 16bits, et sa version compressée avec cet algorithme à 256Kb/s, soit un taux de compression de 6 :1.

Il existe d’autres techniques pour l’encodage audio telles que l’encodage hiérarchique [18] ou l’encodage par descriptions multiples [57]. Plus élaborées, ces techniques sont aussi utilisées pour l’encodage vidéo et sont décrites par la suite.

Encodage vidéo et compression

Encodage vidéo : Tout algorithme d’encodage/décodage vidéo exploite principalement les redondances résiduelles dans une séquence vidéo. Ces redondances sont à la fois spatiales, à l’intérieur d’une image, et temporelles, entre des images successives d’une vidéo. Nous distinguons trois méthodes d’encodage : encodage temporel, encodage hiérarchique et encodage par descriptions multiples.

Encodage temporel : L’encodage temporel se base sur deux principes : l’estimation et la compensation de mouvement entre les images successives d’une séquence vidéo [22]. Ces deux principes sont mis en œuvre respectivement par des opérations de prédiction et d’interpolation.

La prédiction se fait à partir d’images de référence dans une séquence vidéo. Ces images, baptisées images Intra (I), sont compressées de manière indépendante et contiennent toutes les données nécessaires à leur décodage. Les images Prédites (P), contiennent uniquement les différences par rapport à une autre image, qui peut être une image de référence ou une image prédite.

L’interpolation est effectuée de manière bidirectionnelle en utilisant deux images, prédites ou de référence, produisant des images dénommées Bi-prédites (B). Ainsi, certaines images ne peuvent être reconstituées que si leur image de référence a été préalablement traitée. Une erreur produite lors d’un traitement, ou d’une transmission, d’une image de référence est donc propagée aux images prédites et interpolées suivantes. La figure 1.4 illustre l’ordre de décodage de différents types d’images selon le standard MPEG-1.

FIGURE 1.4 – Ordre de codage dans le modèle IPB de la norme MPEG-1 [3].

Notons que toutes les images, après encodage temporel, sont encodées spatialement par transformation en cosinus discrète [43]. Le but est de représenter les données dans un autre espace, en l’occurrence celui des fréquences spatiales. Les images sont ensuite quantifiées. Il s’agit de la seule étape de la chaîne de compression qui occasionne des pertes de données (par exemple : unification de plages de couleurs comportant des variations relativement petites).

La quantification peut donc ne pas introduire de perte de qualité en tirant profit des limites de perception de l’oeil humain. Toutefois, afin d’atteindre un taux de compression élevé, un sacrifice sur la qualité peut s’avérer nécessaire.

Encodage hiérarchique : L’encodage hiérarchique d’une séquence vidéo en multi-couche (layered compression), appelé aussi compression échelonnée ou encodage scalable, se traduit par une décomposition en ondelettes [13, 14]. Il consiste à compresser un contenu en plusieurs couches correspondant à différents niveaux de qualité, une couche de base (« base layer », BL) et une ou plusieurs couches d’amélioration (« enhancement layer », EL) que l’on peut utiliser l’une après l’autre pour raffiner la qualité de la couche de base. Notons que l’amélioration de la qualité peut prendre des dimensions spatiales [54] ou temporelles [24, 17], voire une combinaison des deux [37] (cf. Figure 1.5). L’encodage hiérarchique est incontestablement meilleur que l’encodage temporel en termes de flexibilité, d’efficacité et surtout de scalabilité [56]. En effet, en cas de besoin, on peut abandonner des couches d’amélioration, en commençant par la dernière, donnant un contenu de moindre taille nécessitant moins de débit, mais aussi de moindre qualité. Son seul inconvénient est qu’il nécessite plus de puissance de calcul que l’encodage temporel et atteint des taux de compression à peine moins élevés à cause des données supplémentaires nécessaires à la gestion de la hiérarchie.

Encodage par description multiple : L’encodage par descriptions multiples (MDC) est une technique très robuste pour la transmission de contenus audiovisuels en temps réel [26]. Cet encodage se traduit par la construction de plusieurs descriptions indépendantes pouvant contribuer à la restitution spatiale ou temporelle d’un contenu dynamique. Ces descriptions peuvent avoir la même importance ou des importances différentes, on parle respectivement d’encodage MDC équilibré et d’encodage MDC déséquilibré.

FIGURE 1.5 – Hiérarchisation spatiale et temporelle[3].

Compression irrégulière : Bien que chaque technique de compression de données audiovisuelles possède sa propre recette, elles sont toutes basées sur les mêmes principes. En effet, elles exploitent les limites de la perception humaine en éliminant tout ce qui est imperceptible par l’oeil et/ou l’oreille humaine.

Aussi, ces techniques s’appuient-elles sur le principe de l’élimination des ressemblances dans des données contiguës. Ainsi, moins la vidéo contient de changements entre des images successives, plus les possibilités de compression sont importantes et vice versa.

Une vidéo peut contenir à la fois des séquences riches en mouvement et d’autres moins riches. Son taux de compression est donc amené à varier. Il en résulte une variabilité du débit lors de la lecture d’une séquence audiovisuelle compressée, mais sa qualité reste constante. Ces données sont appelées données à taux d’échantillonnage variable ou données VBR.

Il existe d’autres méthodes de compression de contenus audiovisuels qui produisent des données à taux d’échantillonnage fixe au détriment de la qualité, qui devient variable. Ces données sont appelées données CBR.

Les données CBR sont stockées en blocs ayant la même taille et la même durée, tandis que pour les données VBR deux options sont envisageables (voir Figure 1.6) pour le stockage de données en blocs :

– CTL (Constant Time Length) les blocs auront la même durée mais des tailles différentes,
– CDL (Constant Data Length) les blocs auront la même taille mais des durées différentes.

FIGURE 1.6 – Techniques de découpage de données audiovisuelles VBR [3].

Il est difficile de prendre en compte la variabilité du débit dans les données VBR. Des techniques de traitement ont donc été développées spécialement pour ces données. Néanmoins, dans leur majorité, les travaux de recherche dans le domaine de streaming audiovisuel font l’hypothèse que les données continues, après compression, ont un débit constant. On accepte une faible dégradation, souhaitée invisible, de la qualité. Ainsi, dans le reste de ce manuscrit, sauf mention explicite, nous nous focalisons sur des données audiovisuelles à débit constant.

1.2.3 Formats audiovisuels

Les codecs compressent les données audiovisuelles dans des formats précisés par des standards. Ceux-ci peuvent être libres tels que H.261/3/4 [29, 30, 6] de l’ITU-T ou MPEG-1/2/4 [42, 40, 41] de l’ISO ou bien propriétaires comme les solutions proposées par RealNetworks®, Apple® ou Microsoft®. Les différents formats peuvent correspondre à différents besoins en qualité de restitution, de temps de compression ou de décompression, de débit du flux après compression ou de taille du contenu compressé résultant. Voici un bref descriptif de quelques uns des formats audiovisuels les plus utilisés :

MPEG : Ces formats sont définis par les normes MPEG-1/2/4. En particulier, la couche audio du standard MPEG-1, souvent référencée comme la 3e couche, MP3, est très populaire grâce à son taux de compression très intéressant.

AAC : Ce format, devenu maintenant un standard, est le successeur de MP3. En effet, il offre un meilleur rapport qualité/compression que le format MP3.

DivX® : Ce format, développé par DivX® Inc., est à la vidéo ce que le MP3 est à la musique. Il est l’implémentation la plus connue du standard MPEG-4. Il permet d’avoir des fichiers de taille très réduite avec une qualité d’image supérieure à celle obtenue avec beaucoup d’autres formats.

QuickTime® : Ce format, développé par Apple® Computer Inc., est devenu un standard de fait pour les éditeurs professionnels de contenus audiovisuels.

Real® Media : Ces formats, créés par RealNetworks®, sont parmi les premiers formats conçus spécialement pour la diffusion de contenus audiovisuels en temps réel.

Flash® Media : Ces formats sont actuellement développés par Adobe® Systems Inc. qui a acquis leur créateur Macromedia® Inc. L’utilisation de ces formats est en forte croissance pour la transmission de séquences audiovisuelles en temps réel sur le Web.

Windows® Media : Ces formats sont développés par Microsoft® Corporation pour être utilisés uniquement avec son lecteur Windows® Media Player.

Theora et Vorbis : Ces formats, créés par la fondation Xiph, existent à la fois pour la vidéo (Theora) et pour le son (Vorbis). Ils sont développés de façon totalement libre et gratuite, et ne font l’objet d’aucun brevet logiciel.

Aucun des ces formats n’est vraiment parvenu à s’assurer l’hégémonie sur le marché de l’audiovisuel. La plupart des éditeurs de contenus audiovisuels sont donc obligés de proposer leurs contenus sous au moins deux formats, et ce dans le but de toucher le plus de spectateurs possible. Tous ces formats devraient donc cohabiter encore un certain temps.

Les éditeurs de contenus audiovisuels privilégient souvent l’un ou l’autre de ces formats, en fonction de son domaine d’application. Lorsque les données continues sont destinées à être transmises en temps réel, le format adopté est souvent tributaire du débit de connexion des usagers.

Salué pour l’excellente qualité de ses images, QuickTime® est privilégié pour la diffusion vidéo à haut débit. Sur le segment des connexions à faible et moyen débit, les formats de RealNetworks® et Microsoft® semblent être mieux adaptés.

1.3 Streaming audiovisuel

Stream est un mot anglais signifiant flux. Tout type de données, même textuelles, peut être transmis en flux continu. Ceci permet de les rendre disponibles pour les restituer aussitôt qu’elles arrivent et éviter ainsi l’attente du téléchargement de l’ensemble des données. Le terme streaming peut être défini comme l’ensemble des technologies permettant le téléchargement et la restitution en simultané de données via un réseau. Dans ce mémoire, nous nous focalisons sur les données audiovisuelles. Nous appelons stream, un flux de données audiovisuelles et nous entendons par streaming, la « transmission en continu » de données audiovisuelles.

Les contraintes temps réel inhérentes aux données audiovisuelles font que la mise en oeuvre du streaming n’est pas une tâche aisée. Cette section introduit le streaming en le comparant avec d’autres modèles de transmission. Les avantages, les modes et les applications du streaming sont également présentés.

1.3.1 Streaming versus téléchargement

Les données dynamiques peuvent être affichées à partir d’une machine locale ou d’une machine distante. Dans le premier cas, les données sont entièrement disponibles localement, stockées sur un disque dur ou disponible sur un DVD par exemple. Lorsqu’un spectateur demande la restitution d’un contenu audiovisuel, les données sont récupérées depuis l’espace de stockage local, décodées, puis passées à la carte graphique et/ou carte son qui se charge(nt) de les lui restituer.

Lorsqu’un spectateur demande la restitution d’un contenu audiovisuel se trouvant sur une machine distante, les données sont récupérées depuis l’espace de stockage de cette machine, puis sont transmises à la machine de l’utilisateur par l’intermédiaire d’un réseau. Trois modèles de transmission sont possibles : téléchargement simple, streaming, ou téléchargement progressif.

Téléchargement simple

Dans ce modèle, appelé aussi emmagasiner puis restituer, les données sont entièrement téléchargées d’une machine distante vers un espace de stockage local avant de commencer leur décodage puis leur restitution (voir Figure 1.7a). Le transfert de données peut se faire à l’aide d’un serveur HTTP ou FTP standard. Le temps de transfert augmente avec le nombre de requêtes à servir simultanément. Il est fonction de la taille du contenu à télécharger et du débit de transfert :

Taille du contenu (Mb) = Temps de transfert (s) / Débit de transfert (Mb/s)

Streaming

Ce modèle [2, 38], appelé aussi restitution instantanée, permet la lecture d’un flux peu après la réception des premières données, sans attendre le téléchargement complet du contenu. Les données sont récupérées depuis une machine distante par l’intermédiaire d’un réseau, puis décodées et restituées à l’utilisateur dès qu’elles arrivent à sa machine (voir Figure 1.7b). Les données ne sont pas enregistrées dans l’espace de stockage local. Toutefois, elles peuvent être mises en mémoire tampon avant d’être décodées (« bufferisation »).

Cette technique n’est envisageable que si la machine émettrice ainsi que le réseau peuvent garantir les contraintes de continuité des données dynamiques. Le streaming est très sensible aux délais de propagation. Suivant l’application considérée, les données perdues ou qui ne sont pas arrivées dans un certain délai (de l’ordre de quelques dizaines de millisecondes) deviennent inutiles.

 

FIGURE 1.7 – Téléchargement versus streaming[3].

La restitution des données risque par conséquent d’être perturbée. Une autre condition contraignante de l’utilisation du streaming est que les données dynamiques doivent être encodées de manière à ce que les fragments soient décodables indépendamment les uns des autres.

D’une manière formelle, le streaming peut être exprimé comme une suite de contraintes. Supposons que les fragments de données doivent être restitués à des intervalles de Δ secondes. Chaque fragment doit être délivré et décodé avant l’instant de sa restitution :

– le fragment N doit être délivré et décodé avant le moment de sa restitution : TN ;
– le fragment N + 1 doit être délivré et décodé avant TN + Δ ;
– le fragment N + 2 doit être délivré et décodé avant TN + 2 Δ;
– etc.

Téléchargement progressif

Ce modèle, appelé également pseudo streaming, permet de commencer la lecture avant l’arrivée complète du contenu. L’affichage commence dès qu’une quantité suffisante de données est localement disponible. Le reste des données continue à être récupéré et emmagasiné dans l’espace de stockage local. Au final, les données seront entièrement stockées dans l’espace de stockage local.
Le téléchargement progressif permet ainsi au client de lire le début du contenu pendant que le reste se télécharge et aussi de conserver une copie locale du contenu. Le modèle peut être considéré comme un cas spécial du téléchargement simple ou alors un cas spécial du streaming.

1.3.2 Avantages du streaming

La transmission de données audiovisuelles en streaming présente plusieurs avantages :

– Il permet aux usagers de commencer à visualiser, ou entendre, un contenu audiovisuel, volumineux par nature, sans attendre que la totalité des données soit téléchargée.
– Il offre la possibilité au spectateur de se rétracter à tout moment, si le contenu ne correspondait pas à ce qu’il attendait ;
– Il ne nécessite pas de disposer d’un espace de stockage chez l’utilisateur. Toutefois, un espace limité de mémoire tampon peut être demandé pour le décodage des données.
– Aucune copie locale n’est conservée. Ceci est très utile pour le partage de contenus soumis à des licences restrictives quant à la distribution de contenus (mais qui en autorise la diffusion).
– Il est bien adapté pour la transmission des événements en direct.

1.3.3 Modes

En fonction de l’efficacité de transmission, on peut distinguer deux modes de transmission de données audiovisuelles : la diffusion individuelle et la multidiffusion.

Diffusion individuelle

Dans ce mode, appelé aussi transmission point à point ou un vers un, un émetteur envoie un flux de données audiovisuelles par spectateur, il y a autant de flux que d’auditeurs (voir Figure 1.8). La diffusion individuelle (« unicast », « one-to-one ») nécessite donc des émetteurs puissants et dotés d’une bande passante de sortie très élevée. Un canal de retour (« feedback ») est souvent associé au canal d’émission donnant la possibilité à l’émetteur de modifier son comportement en fonction de l’état du récepteur ou du canal. Ce mode de diffusion permet au récepteur de contrôler le flux de données en le mettant en pause par exemple. La vidéo à la demande est une application très populaire utilisant ce mode de transmission.

FIGURE 1.8 – Diffusion individuelle de vidéos à la demande [3].

Multidiffusion

La multidiffusion, appelée aussi transmission multipoints ou un vers plusieurs, est certainement plus efficace pour la distribution de contenus audiovisuels à un très grand nombre de récepteurs, sous réserve qu’elle soit supportée par le réseau sous-jacent. Par un mécanisme d’abonnement, les spectateurs peuvent s’enregistrer dans un groupe de multidiffusion. Un émetteur, appartenant au groupe, peut ainsi envoyer, en une fois, un flux des données audiovisuelles à l’ensemble des récepteurs enregistrés dans le groupe (cf. Figure 1.9). Ce mode augmente donc la capacité de l’émetteur à servir simultanément plus de spectateurs, cependant le retour d’informations d’un récepteur vers l’émetteur est généralement infaisable limitant ainsi la capacité de l’émetteur à s’adapter aux récepteurs. Le spectateur ne peut donc pas piloter le flux ; il doit suivre le programme imposé comme pour une télédiffusion. La radio en ligne ou la télévision en ligne sont des exemples courants d’applications utilisant ce mode de streaming.

Un cas particulier de ce mode est la diffusion large (« broadcast », « one-to-all »), où un émetteur envoie un flux de données audiovisuelles à tous les spectateurs connectés.

FIGURE 1.9 – Multidiffusion d’un événement en direct[3].

Bien que la multidiffusion soit de plus en plus utilisée, elle n’est pas encore déployée à large échelle sur Internet. Ceci est la conséquence directe du fait que les communications sur Internet se font aujourd’hui en utilisant principalement des transmissions point à point.

1.3.4 Applications

Les applications de streaming existent et fonctionnent selon plusieurs modèles.

Diffusion en direct : Les données audiovisuelles peuvent être capturées et encodées en temps réel pour être diffusées, tout de suite, en direct (« Live »). Nous appelons le stream résultant stream vivant, alors que nous appelons le résultat d’une transmission en streaming des données audiovisuelles préalablement encodées et stockées, streaming rémanent.

Diffusion à la demande : Dans ce type d’applications, un utilisateur émet une requête qui est traitée uniquement pour lui (voir Figure 1.8). Le stream rémanent est délivré en différé vers les spectateurs qui en ont fait la demande. Les usagers de ce type d’applications tolèrent, en général, un temps de latence initial avant le démarrage du flux demandé. La durée des streams est toujours connue à l’avance et peut être longue (films de cinéma) ou relativement courte (nouvelles, publicités, etc.). Ils peuvent être structurés ou indépendants les uns des autres. Par streams indépendants, nous entendons qu’ils ne possèdent pas de liens structurels et sémantiques les reliant.

L’exemple le plus courant de ce type d’applications est le média à la demande (3) (« Media-On-Demand » , MOD) qui se décline en trois catégories selon le degré de l’interactivité permise à l’usager [38, 12] : True Media-On-Demand (T-MOD), Near Media-On-Demand (N-MOD) et Quasi Media-On-Demand (Q-MOD).

Visioconférence Dans les applications examinées ci-dessus, les utilisateurs sont isolés, sans interactions entre eux. Dans une application de visioconférence (ou de téléphonie par Internet), les utilisateurs deviennent des interlocuteurs ; ils se parlent et se voient en temps réel par le biais de streams vivants. En plus des contraintes temps réel inhérentes aux données audiovisuelles, ce type d’applications interactives nécessite des temps de réponse très courts, de l’ordre de 150ms [2].

La visioconférence permet de transformer les réunions physiques en réunions virtuelles réduisant le temps perdu et les coûts de voyage. D’ailleurs, on observe une demande croissante d’environnements, fonctionnels et peu onéreux, pour les téléréunions internationales, les téléformations à distance, etc. L’Auditorium [15] est un exemple d’un système de visioconférence, basé sur la technologie Java.

1.4 Système de streaming

Un système de streaming , appelé aussi environnement de streaming, se décompose en trois parties : le serveur chargé de « streamer » les données audiovisuelles, c’est-à-dire de les transmettre en flux continu ; les lecteurs qui restituent ces données aux utilisateurs ; et le réseau les connectant (voir Figure 1.10). Chacune de ces parties doit satisfaire à certaines conditions requises pour que le streaming soit faisable. Dans cette section, nous examinons, plus ou moins en détails, chacune de ces trois parties. Nous décrivons également les deux catégories de systèmes de streaming, en l’occurrence « client pull » et « serveur push ».

1.4.1 Lecteur audiovisuel

Dans un système de streaming, la partie qui est en contact direct avec les utilisateurs est le lecteur audiovisuel. Dans la terminologie du génie logiciel, le lecteur audiovisuel est appelé client.

Le client est un logiciel permettant de lire des données audiovisuelles ; il permet de les décoder et de les restituer. En plus, il comporte une interface utilisateur qui prend en compte certains désirs des usagers par le biais d’un certain nombre d’interactions. Dans la suite, nous introduisons les trois composants principaux d’un client : le décodeur, le démultiplexeur et le contrôleur. Un panorama des lecteurs audiovisuels les plus populaires est ensuite présenté.

FIGURE 1.10 – Système de streaming[3].

Décodeur : Comme cela a été mentionné dans la Section I.1, en raison de leur nature extrêmement volumineuse, les données audiovisuelles sont emmagasinées et transmises sous forme compressée. Le décodeur est le composant chargé de décompresser (décoder) les données avant leur restitution. Un décodeur est souvent spécialisé dans la décompression de données audio ou vidéo. On parle alors de décodeur audio et décodeur de vidéo. Plus les décodeurs disposent d’algorithmes de décodage, plus le lecteur est capable de lire de formats de données différents.

Démultiplexeur : Les données audiovisuelles, après encodage, se trouvent souvent groupées dans des conteneurs, appelés aussi « containers » ou « wrappers », afin de faciliter leur stockage et/ou leur transmission. On parle alors de données multiplexées. Certain conteneurs, tels que Matroska ou Ogg, peuvent inclure la vidéo d’un film, plusieurs pistes audio et plusieurs pistes de sous-titres. Ce groupement, ou multiplexage, de données compressées, est effectué par des logiciels appelés multiplexeurs, alors que le dégroupement (démultiplexage) ou l’extraction de différents flux, toujours compressés, depuis des données multiplexées est effectué par des démultiplexeurs. Le démultiplexeur est ainsi le composant chargé d’extraire les différents flux de données multiplexées.

Contrôleur : Le rôle principal du contrôleur est de gérer les interactions des utilisateurs, mais aussi de superviser le cheminement des données audiovisuelles. Les différentes commandes des utilisateurs sont déléguées au système d’exploitation sous-jacent (OS), chargé de les exécuter, par le biais d’une interface (API) qui lui est associée [34]. Le chemin qu’empruntent les données audiovisuelles comprend, quant à lui, trois phases. Les données compressées et multiplexées sont d’abord récupérées depuis une source jusqu’au démultiplexeur qui extrait les données audio et vidéo compressées. Les données sont ensuite décompressées par les décodeurs appropriés. Enfin, les données décodées sont acheminées jusqu’au point de restitution (voir Figure 1.11).

Les interactions classiquement offertes aux utilisateurs par un lecteur audiovisuel sont l’augmentation ou la diminution du volume sonore, la mise en pause, l’arrêt, la reprise, l’avance rapide, le recul rapide et la navigation temporelle dans un contenu audiovisuel. Un client doit également fournir une interface permettant aux usagers de sélectionner les contenus qui les intéressent.

FIGURE 1.11 – Composants d’un lecteur audiovisuel [3].

1.4.2 Clients existants

Il existe de nombreux clients permettant la lecture des données audiovisuelles. Plutôt qu’une énumération exhaustive mais sommaire, nous en décrivons quelques uns parmi les lecteurs les plus populaires.

VLC media player : Le lecteur VLC est la partie cliente du projet VideoLAN, qui constitue une solution complète pour la lecture et la diffusion de données audiovisuelles. Un des grands atouts de VLC est qu’il intègre les codecs nécessaires à la lecture de la plupart des formats audio et vidéo. Il est disponible sur la plupart des plates-formes. À l’origine, il était développé par les étudiants de l’École Centrale Paris et a été diffusé pour la première fois le 1er février 2001 sous licence GPL. Il est aujourd’hui développé par des contributeurs du monde entier. Le projet reste toutefois coordonné par des élèves de deuxième année et plus de l’École Centrale Paris.

MPlayer : C’est un lecteur audiovisuel libre et distribué sous licence GPL, porté sur plusieurs plates-formes telles que Mac OS® X, Microsoft® Windows® et SolarisTM. Il est connu pour prendre en charge un très grand nombre de formats vidéo. Il est accompagné de Mencoder, qui est à la fois un outil d’encodage (ou transcodage) et de montage audio et vidéo.

Windows® Media Player : C’est un lecteur audiovisuel propriétaire produit par l’entreprise Microsoft®. Il est essentiellement disponible pour les systèmes d’exploitation Microsoft® Windows®.

Selon une étude de Nielsen [50], il occupe la première place du marché mondial du streaming

RealPlayer® : C’est un lecteur audiovisuel édité par RealNetworks®. Il est très semblable à Windows Media Player en termes de rapidité, de qualité de son et de qualité de l’image lors de la lecture de vidéos ou de DVD. Il fonctionne grâce à un moteur à sources ouvertes (« open source ») appelé HelixTM. Il existe des versions « basiques » gratuites de ce client ainsi que des versions payantes avec des fonctionnalités supplémentaires. Il est également disponible sur la plupart des plates-formes.

QuickTime® et iTunes® : Ce sont des lecteurs distribués gratuitement par Apple® . Ils sont disponibles officiellement sur Mac OS® X, Microsoft® Windows® , et officieusement sur les systèmes GNU/Linux. Selon la même étude de Nielsen [36], ils occupent, en tant que logiciels de streaming, la 3e place du marché derrière Windows® Media Player et RealPlayer®.

Adobe® Flash® Player : Il est officiellement compatible avec les systèmes d’exploitation Windows®, GNU/Linux, Mac OS® X, SolarisTM, mais sa compatibilité GNU/Linux se résume aux architecturesx86 32 bits. Aujourd’hui sa popularité se voit en stricte croissance grâce à son plug-in disponible pour la majorité des navigateurs Web, car ce plugin est fortement utilisé par les sites Web consacrés au partage de vidéo en streaming comme Youtube ou Dailymotion.

1.4.3 Serveur de streaming

Le serveur occupe la position centrale d’un système de streaming. Il joue un rôle essentiel en essayant d’offrir un service de streaming de qualité qui se traduit par sa faculté à garantir des streams non saccadés à toutes les requêtes admises. Pour cela, il doit tenir compte de la nature des streams, qui est très volumineuse, gourmande en bande passante et impose des contraintes strictes en matière de délai d’acheminement des données aux clients. Une machine, hébergeant un serveur de streaming doit être capable de supporter un grand nombre de clients, en tout cas, elle doit être capable de supporter le nombre désiré de clients. Elle doit donc avoir une bande passante de sortie très importante. En effet, la bande passante requise pour diffuser des données audiovisuelles en continu est, à l’instar du coût, proportionnelle à l’importance de l’audience. D’ailleurs, une machine hébergeant un serveur de streaming doit posséder également un grand espace de stockage capable de fournir les données avec des débits très élevés.

Dans cette section, nous synthétisons les fonctionnalités principales d’un serveur de streaming à l’aide d’un modèle à cinq composants [48] : une interface d’administration, un ordonnanceur, un gestionnaire de ressources, un gestionnaire de stockage et un gestionnaire de transmission (voir Figure 1.12). Au passage, nous identifions et comparons plusieurs techniques qui interviennent dans les différents composants. Il est à noter qu’il n’existe pas de technique optimale propre à chaque composant, mais plutôt un compromis global. La conception d’un serveur de streaming s’apparente donc à un exercice d’équilibre structurant ces différents modules. En fin de section, nous dressons un panorama des serveurs les plus présents dans le monde du streaming d’aujourd’hui.

Avant de nous pencher sur les détails fonctionnels du serveur et les rôles respectifs de ses composants, citons les principaux critères utilisés pour évaluer et comparer la performance des différents serveurs :

La capacité du serveur (« throughput ») : Elle est définie par le nombre de streams que le serveur est capable de gérer simultanément. Cette capacité est fonction des ressources mises à sa disposition. Selon la capacité du serveur on distingue les serveurs à petite échelle (« smallscale servers »), à échelle moyenne (« medium-scale server ») ou bien à grande échelle (« large-scale servers »). On trouve les serveurs à petite échelle dans les avions, les hôtels, etc.

Les serveurs à échelle moyenne sont capables de servir jusqu’à 50 streams simultanés sur un réseau local. Quant aux serveurs à grande échelle, on parle de milliers des streams simultanés sur un réseau métropolitain, voire sur Internet. Si une technique donnée permet au serveur d’avoir une capacité plus élevée, pour les mêmes ressources, que d’autres techniques, elle est considérée comme une meilleure solution.

FIGURE 1.12 – Composants d’un serveur de streaming [3].

Coût par stream : C’est le coût total du serveur, y compris celui de la plate-forme matérielle l’hébergeant, divisé par sa capacité.

Latence de démarrage d’un stream (« startup latency ») : C’est le temps écoulé entre l’instant d’arrivée d’une requête au serveur et l’instant où le stream commence à être restitué à l’usager qui a lancé la requête (voir Figure 1.7). Lorsqu’un usager est connecté, via un réseau local, à un serveur à échelle moyenne, il prévoit une latence de démarrage de l’ordre de quelques secondes, alors qu’il tolère des latences plus élevées lorsqu’il est connecté à un serveur à grande échelle.

Modèle fonctionnel du serveur

Afin d’illustrer les différentes tâches qu’un serveur effectue en réponse à des requêtes demandant l’accès en streaming à des séquences audiovisuelles, nous utilisons un modèle fonctionnel à cinq composants : une interface d’administration, un ordonnanceur, un gestionnaire de stockage, un gestionnaire de ressources et un gestionnaire de transmission. Ces composants travaillent en collaboration dans le processus d’acheminement des données audiovisuelles (voir Figure 1.14).

Un problème survenant dans n’importe quel composant peut donc dégrader la performance de toute la chaîne. Notons que ce modèle fonctionnel fait abstraction de tout choix d’architecture matérielle ou d’implémentation, et ne se focalise pas particulièrement sur des techniques adaptées à une classe spécifique d’application de streaming.

Interface d’administration : Elle représente l’interface de gestion et de configuration du serveur. Elle permet de configurer le serveur en choisissant les techniques employées pour les différents composants. Afin de suivre le comportement du serveur en temps réel, elle fournit des moyens pour placer des points de surveillance dans les différents composants. Elle donne des statistiques concernant tous les composants auxquels un point de surveillance est associé.

Ces statistiques sont utilisées pour évaluer la performance des différentes techniques de gestion et d’ordonnancement.

Ordonnanceur : Si le gestionnaire de ressources juge que les ressources disponibles à un moment donné ne suffisent pas pour accepter une nouvelle requête, l’usager demandant l’accès à un contenu donné doit attendre la libération des ressources avant que sa requête soit acceptée par le serveur. Plus le temps d’attente est long, plus forte est la probabilité que l’utilisateur se rétracte de sa demande. Il incombe à l’ordonnanceur d’établir une sorte de priorité sur les différentes requêtes et de décider quelle sera la prochaine requête à servir, lorsque suffisamment de ressources se trouvent disponibles pour gérer un nouveau stream.

Par ailleurs, l’accès aux contenus audiovisuels n’est pas uniforme, c’est-à-dire qu’il est fréquent qu’une grande partie des spectateurs accède à un ensemble restreint de données, appelées données chaudes. En prenant en compte cet accès biaisé aux contenus audiovisuels, l’ordonnanceur cherche à augmenter la capacité du serveur. Pour cela, il regroupe, autant que faire se peut, les requêtes demandant l’accès à un contenu donné et les traite comme une seule requête diffusée en mode multipoint. Néanmoins, l’efficacité de ce regroupement n’est effective que si les utilisateurs tolèrent un délai, plus ou moins long, avant la restitution du contenu demandé.

Nous examinons, dans cette section, les techniques utilisées pour ordonner, regrouper et définir une priorité sur les requêtes. Nous commençons d’abord par introduire les deux paradigmes qui modélisent la rétractation des utilisateurs. Nous présentons ensuite les objectifs recherchés par les techniques d’ordonnancement de requêtes. Une taxinomie de ces techniques clôt cette section. Notons que l’ordonnanceur ne se limite pas à l’ordonnancement des requêtes ; il est aussi responsable de la gestion interne du serveur. Néanmoins, cette dernière est fortement liée à la fois à la plate-forme matérielle utilisée et à l’environnement de développement adopté. Ainsi, par souci de généralité, elle ne sera pas traitée.

Objectifs d’ordonnancement de requêtes

Les objectifs de l’ordonnancement de requêtes sont les suivants :

– Minimiser le temps moyen d’attente des utilisateurs ;
– Minimiser la probabilité de rétractation à long terme, c’est-à-dire minimiser le ratio du nombre des utilisateurs qui se rétractent divisé par le nombre total des utilisateurs ;
– Minimiser la probabilité de rétractation en période de pointe à court terme, c’est-à-dire minimiser le ratio du nombre des utilisateurs qui se rétractent dans une période courte divisé par le nombre des utilisateurs qui sont connectés pendant cette période ;
– Assurer l’équité entre les contenus. Intuitivement, une politique d’ordonnancement est équitable si la probabilité de rétractation pour tous les contenus est la même. Or, le nombre de requêtes demandant l’accès à un contenu « froid » peut être très faible. La probabilité de rétractation concernant ce contenu, et donc la non-équité, peut être difficile à estimer.

Ainsi, les contenus sont groupés en N groupes de façon à ce que chaque groupe reçoive le même nombre de requêtes. La non-équité (« unfairness »), ou la variance de la probabilité de rétractation U, entre les groupes, peut ensuite être mesurée. Une étude formelle de ce problème a été fait par [50].

Gestionnaire de ressources : Étant donné que les ressources mises à disposition du serveur (espace mémoire, bande passante du système de stockage, etc.) sont limitées, ce dernier ne peut servir simultanément qu’un nombre limité de requêtes. Le gestionnaire de ressources est le composant chargé d’exercer un contrôle d’admission vis-à-vis des nouvelles requêtes lors de leur soumission. Ce contrôle sert à vérifier que le nouveau stream produit par l’acceptation d’une nouvelle requête n’altérera pas les stream déjà admis. Il s’assure ainsi que le serveur possède suffisamment de ressources (processeur, mémoire, débit de transfert du système de stockage, bande passante réseau, etc.) pour supporter simultanément l’ensemble des streams tout en respectant les contraintes imposées par ces streams. Ces contrôles affectent tous les dispositifs de la plate-forme hébergeant le serveur et se répercutent jusqu’au système de stockage. Par souci de généralité, [50] n’a présenté que l’impact du contrôle d’admission sur la taille de la mémoire disponible dans le serveur et sur le débit de transfert du système de stockage.

Gestionnaire de stockage : Le système de stockage est sans doute une partie fondamentale de la machine hébergeant un serveur de streaming puisqu’il est à la base du stockage et de l’envoi des données audiovisuelles. Les tâches dévolues au gestionnaire de stockage sont : le placement et la répartition des données au sein du système de stockage ainsi que l’ordonnancement d’accès à ces données [51], les différentes techniques employées par ce composant afin de maximiser l’efficacité du système de stockage, le rendre tolérant aux pannes et s’assurer que les streams seront servis à un rythme garantissant leur continuité sont sommairement étudiés par [50].

Gestionnaire de transmission : Ce composant est responsable du streaming proprement dit : il gère la transmission des blocs de données aux clients à travers le réseau. Le gestionnaire de transmission fait donc usage de protocoles dédiés au transfert de données possédant des contraintes de temps réel. Rappelons que la retransmission d’un paquet est effectuée uniquement si le paquet retransmis peut arriver avant qu’il soit temps de le décoder et de le restituer.

Sinon, la retransmission est non seulement inutile mais risque de retarder l’arrivée d’autres paquets. Ainsi, le gestionnaire de transmission est chargé d’optimiser la transmission en employant des techniques d’adaptation de contenus à l’état du réseau. Le gestionnaire de transmission est amené à se servir de techniques permettant la protection des données contre les pertes et/ou les transformations possibles lors d’une transmission.

1.4.4 Serveurs existants

Après avoir présenté les différent aspects d’un serveur de streaming, nous clôturons cette section par une liste, non exhaustive, des serveurs de streaming les plus utilisés et qui sont les principaux acteurs du monde du streaming.

HelixTM : Il est l’héritier d’une longue lignée de serveurs de streaming développés par RealNetworks® depuis une dizaine d’années. Fondés sur une technologie propriétaire, les serveurs HelixTM sont disponibles en version d’essai gratuite, mais avec des capacités limitées. Ils permettent de diffuser n’importe quel type de fichier audio ou vidéo. Ce sont les seuls à être compatibles avec les formats Real®.

Windows® Media Service : Comme son noml’indique, c’est un serveur développé par Microsoft®.

Les dernières versions de ce logiciel sont payantes et ne fonctionnent que sur un serveur disposant de Windows® 2003 Server. QuickTime® /Darwin Streaming Server : Ce sont des serveurs de streaming à la fois audio et vidéo, fondés sur une architecture QuickTime® . Si le serveur QuickTime® est payant, son homologue Darwin a l’avantage d’être un logiciel libre et disponible gratuitement pour une multitude de systèmes d’exploitation. Ils ont aussi l’avantage d’être très simples d’emploi.

VideoLAN : C’est une solution de streaming gratuite, développée par les étudiants de l’Ecole Centrale de Paris. Ce logiciel permet de mettre en place très rapidement un flux de streaming entre deux ordinateurs distants et a l’avantage de diffuser des formats tels que le DivX®, MPEG-4, ou encore le contenu des DVD vidéo.

1.5 Réseaux et streaming

Dans un système de streaming, le terme réseau englobe les infrastructures matérielles et les protocoles logiciels permettant de transmettre au serveur les commandes des utilisateurs et de délivrer aux clients les données audiovisuelles choisies, tout en respectant leur isochronisme. Or, la transmission sans garantie, offerte par les réseaux à commutation de paquets, a des effets néfastes sur la continuité des données audiovisuelles. Pour contrer ces effets, deux voies sont envisageables : les applications ajustent leur comportement en fonction de l’état du réseau, et/ou le réseau s’adapte au transfert des données dynamiques.

Au niveau applicatif, on trouve dans la littérature des techniques comme le streaming adaptatif ou bien la correction des erreurs de transmission. Ces techniques sont examinées dans la suite de ce mémoire. Au niveau réseau, un ensemble de protocoles répondant aux besoins temps réel des données audiovisuelles a été proposé. Dans cette section, nous décrivons d’abord les problématiques liées au streaming sur des réseaux à commutation de paquets, en particulier les réseaux basés sur le protocole IP. Puis, nous présentons les différents protocoles conçus spécialement pour le streaming de données audiovisuelles.

1.5.1 Problématiques dues aux réseaux

Dans les réseaux à commutation de paquets, comme l’est actuellement Internet, le délai de transmission d’un paquet n’est pas garanti. D’ailleurs, ce délai présente des fluctuations importantes.

La variation du délai de transmission est communément appelée gigue. La gigue a des effets perturbateurs voire destructeurs des relations temporelles intrinsèques aux données dynamiques, causant ainsi la désynchronisation de celles-ci. Elle peut empêcher la reconstitution correcte des données dynamiques qui doivent être décodées et restituées à une cadence constante. Afin de réduire l’effet de la gigue, un tampon de lecture est souvent utilisé du côté client. Cette technique, située au niveau applicatif, est décrite plus amplement dans la Section I.4.

L’arrivée des paquets n’est pas garantie non plus dans les réseaux à commutation de paquets.

En outre, les données peuvent être altérées lors de la transmission. La perte ou la transformation des données a des effets nuisibles à la qualité des données reconstituées. Au vu des contraintes temporelles inhérentes aux données dynamiques, les paquets perdus ne sont retransmis que s’ils peuvent être délivrés avant qu’il soit temps de les décoder pour être restitués au spectateur.
Néanmoins, des paquets perdus ou transformés peuvent être reconstitués par des mécanismes de contrôle d’erreur qui sont décrits dans [50].

Aussi, les réseaux à commutation de paquets n’offrent pas la possibilité de réserver une bande passante pour le transfert des données audiovisuelles, volumineuses par nature. De plus, l’hétérogénéité des infrastructures réseaux, utilisant des technologies très variées, implique de grandes différences quant à leurs capacités en bande passante. Ainsi, la bande passante entre deux points sur Internet est en général inconnue et variable dans le temps. Si un émetteur envoie à un débit supérieur au débit supporté par le réseau, il y a congestion, ce qui implique que des paquets sont perdus et donc la qualité des streams diminue considérablement. En revanche, si la transmission se fait à un débit très en-dessous de la bande disponible, le stream transmis est sous-optimal. Afin de remédier à ce problème, on adapte le taux de transmission de données au débit de transmission dicté par les conditions du réseau, on parle alors de streaming adaptatif.

Des difficultés supplémentaires apparaissent lorsque les données traversent des réseaux sans fil caractérisés par une bande passante réduite, des délais considérablement plus élevés, des taux d’erreurs plus élevés, et des problèmes de connexion intermittente. Les streams doivent donc être adaptés à ces environnements mobiles. Cette adaptation se traduit par une diminution du débit des streams.

1.5.2 Protocoles dédiés au streaming

Afin de masquer la complexité et l’hétérogénéité des infrastructures réseaux aux développeurs d’applications et aux utilisateurs finaux, les différents aspects de la communication sont modélisés en plusieurs couches. En principe, une couche ne peut communiquer qu’avec les couches de rang immédiatement supérieur et/ou inférieur. La modélisation en couches permet de modifier et même de remplacer une couche sans affecter les autres, tant que leurs interfaces restent inchangées. Un des modèles les plus répandus est le modèle, baptisé OSI de l’ISO, à sept couches : physique, liaison de données, réseau, transport, session, présentation et application. Nous utilisons ce modèle pour situer les différents protocoles dédiés au streaming dans la couche correspondant à leurs fonctionnalités (cf. Figure 1.13). Nous nous focalisons sur les protocoles normalisés par l’IETF suivants : RTP, RTSP, SIP, RTCP et RSVP.

Protocoles de transport

Dans les réseaux basés sur IP, deux protocoles de transfert de données sont principalement utilisés : TCP et UDP. À l’opposé du protocole UDP, qui introduit des pertes ou une arrivée désordonnée des paquets, le protocole TCP garantit la livraison des données en les expédiant à nouveau si nécessaire et effectue un contrôle de congestion lors de la transmission des données [11].

FIGURE 1.13 – Classement des protocoles de streaming dans les couches du modèle OSI [3].

Un contenu audiovisuel peut tolérer la perte d’un certain pourcentage de ses données, sans pour autant affecter la qualité perçue par le spectateur, ceci sous réserve que les données perdues ne soient pas consécutives. Ainsi, la fiabilité de livraison des données dynamiques, à l’opposé des données statiques, est souvent inutile. D’ailleurs, il ne sert à rien de retransmettre un paquet perdu si le paquet retransmis arrive lorsque la séquence à laquelle il appartient a déjà été utilisée. Non seulement la retransmission est inutile mais elle consomme des ressources, au risque de retarder d’autres paquets. Par ces faits, l’utilisation du protocole UDP convient mieux au transfert des données audiovisuelles que TCP. Cependant, UDP ne fait pas de contrôle de congestion et il n’est pas optimisé pour le transfert des données ayant des contraintes temps réel. Ces deux inconvénients sont contournés en utilisant des protocoles compatibles avec TCP [27], pour le premier, et un protocole spécialisé dans le transfert des données audiovisuelles, nommé RTP [60], pour le second.

Protocoles compatibles avec TCP : Un inconvénient majeur du protocole UDP est qu’il n’effectue pas de contrôle de congestion d’une manière compatible avec TCP. En effet, il continue à augmenter le débit de transfert jusqu’à saturation du réseau. Il ne partage pas équitablement la bande passante avec les trafics bâtis sur TCP. Ceci conduit à l’effondrement du réseau en privant toutes les autres applications de bande passante (tout protocole confondu).

Dans le cas du streaming, le contrôle de la congestion revient à superviser le débit. Le contrôle du débit (« rate control ») peut être géré au niveau de l’émetteur (serveur), du récepteur (client), ou des deux (hybride). Des mécanismes de contrôle et de régularisation du débit issu du trafic UDP ont été développés pour le rendre compatible avec son homologue TCP [27, 34]. Un trafic est considéré compatible avec TCP, ou « TCP-friendly », s’il ne réduit pas, à long terme, le débit d’autres trafics plus que « sa version TCP » ne le réduirait dans les mêmes conditions.

Protocole de transmission temps réel RTP : C’est un protocole optimisé pour le transfert de données dynamiques sur un réseau point à point tout en respectant leurs contraintes de temps réel. Il est également utilisé pour la multidiffusion. Ce protocole effectue un découpage intelligent des données pour que chaque paquet soit décodable indépendamment des autres. Les paquets RTP sont marqués temporellement de manière à être réorganisés, en cas de réception désordonnée ou tardive, afin d’afficher le stream de manière cohérente et synchronisée chez l’utilisateur. Ces marques temporelles permettent également la détection d’éventuelles pertes de paquets. RTP ne gère pas la réservation de ressources réseau et ne garantit pas de qualité du service temps réel. On y adjoint le protocole RTCP, présenté plus loin, pour effectuer le contrôle des données.

Protocoles de session

Les protocoles situés dans cette couche surveillent le transfert des données et génèrent des rapports de diagnostics dont le but est de prévenir certaines anomalies. Nous décrivons les deux protocoles principaux : RTCP [28, 28] et RTSP [36].

Protocole de contrôle temps réel, RTCP : Ce protocole de contrôle est conçu pour fonctionner conjointement avec RTP. Il permet le « monitoring » de manière extensible des données transférées et fournit des fonctionnalités de contrôle et d’identification. Les paquets RTCP, envoyés périodiquement, ne comportent pas de données audiovisuelles mais contiennent des statistiques utiles à l’application telles que le taux de perte, le débit observé, la gigue, etc.

Toutefois, RTCP ne spécifie pas comment l’application devrait réagir à ces rapports. Les applications sont donc libres de choisir leur manière de s’adapter vis-à-vis des rapports RTCP.

Le protocole de streaming temps réel, RTSP : Ce protocole est destiné à satisfaire les critères d’efficacité d’acheminement des données continues sur des réseaux IP. Il utilise RTP pour former et transférer les paquets contenant les données multimédias. Ce protocole permet de contrôler les streams en offrant des fonctionnalités typiques d’un lecteur audiovisuel telles que lecture, pause et navigation temporelle. Il est à noter que les solutions les plus répandues actuellement, qu’elles soient de RealNetworks®, d’Apple® ou de Microsoft®, ont toutes opté pour RTSP. Notons qu’il existe d’autres protocoles équivalents à RTSP comme SIP [20] de l’IETF ou la norme H.323 [21, 9] de l’ITU-T, qui sont dédiés aux sessions de visioconférence.

Protocoles d’application

Le protocole de réservation de ressources RSVP [44, 1] permet aux applications de réserver dynamiquement des ressources dans un réseau basé sur IP, afin de satisfaire leurs besoins en termes de bande passante nécessaire, délais de transfert autorisé, etc. Il émet périodiquement des messages de réservation, ou de libération, des ressources afin de maintenir dynamiquement les chemins utilisés.

Ces messages, destinés aux routeurs, circulent le long du chemin qu’emprunterait le trafic des données à travers le réseau. Notons qu’il existe d’autres protocoles de réservation de ressources comme DiffServ [58], etc.

1.6 « Client pull » versus « serveur push »

Selon le paradigme d’interaction adopté entre le client et le serveur, on peut distinguer deux catégories de systèmes de streaming : les systèmes dits ouverts (« open-loop ») et les systèmes dits fermés (« closed-loop »). Les systèmes ouverts emploient le modèle d’interaction offre par le serveur (« serveur push ») tandis que les systèmes fermés emploient le modèle demande par le client (« client pull »).

1.6.1 Offre par le serveur (serveur push)

Dans cette approche, le serveur se charge de la gestion de la continuité des streams. Un client envoie une seule requête d’accès à un contenu donné et c’est au serveur de gérer et d’envoyer le stream correspondant en assurant le respect de ses contraintes de temps réel (voir Figure 1.14).

La gestion de la continuité au niveau du serveur, même si elle reste une tâche complexe, permet d’exploiter la périodicité des données dynamiques et d’optimiser par conséquent l’utilisation des ressources mises à sa disposition. De ce fait, ce paradigme a été largement adopté dans les systèmes de streaming, notamment pour les applications de type diffusion en direct.

En revanche, le support des interactions utilisateur, et les fonctions de magnétoscope en particulier, sont très difficiles à mettre en oeuvre dans un système employant ce modèle.

FIGURE 1.14 – « Client pull » versus « serveur push » [3].

À l’inverse de l’approche précédente, la gestion de la continuité des streams est laissée à la charge du client. Ainsi, l’accès aux données se traduit par un ensemble de sous-requêtes que le client envoie au serveur à chaque fois qu’il en a besoin (voir Figure 1.14). Le serveur est donc déchargé de la contrainte de temps réel qui se voit réduite à assurer des temps de réponse minimaux. En ce sens, ce paradigme ne diffère pas fondamentalement d’un serveur de fichiers classique.

Ce modèle, du fait du dialogue permanent entre le client et le serveur, génère un trafic supplémentaire. Ce trafic reste négligeable compte tenu du volume colossal des données audiovisuelles.

En effet, il n’induit pas de délais supplémentaires lors de la transmission des données. Néanmoins, la capacité d’un serveur se trouve réduite de 5 à 20% dans un système fermé par rapport à un système ouvert [59]. Ceci s’explique par le fait que les opportunités d’optimisation au niveau du serveur se trouvent réduites.

En revanche, ce modèle présente plusieurs avantages. Il permet une meilleure gestion des ressources mises à disposition du client puisque ce dernier ne demande que ce dont il a besoin.

Aussi, la gestion d’interactions utilisateur se trouve grandement simplifiée dans un système fermé. Ceci est particulièrement vrai pour les fonctions de magnétoscope qui se traduisent souvent par des accès à des blocs de données non consécutifs dans le stream. Il est mieux adapté aux systèmes de streaming comprenant plusieurs serveurs, distribués, car il ne nécessite pas une synchronisation entre les différents émetteurs [19], cette synchronisation étant effectuée par le client.

1.7 Les caches dans les systèmes de streaming

Le terme cache est un mot anglais signifiant un endroit où des choses peuvent être cachées ou gardées. Ce terme, utilisé en informatique pour se référer à une préservation des données pendant des périodes plus ou mois éphémères, fait référence à plusieurs sortes de caches selon leurs localisations dans un système de streaming. Un tel système est composé, comme nous l’avons vu, de trois parties : le client, le serveur et le réseau les connectant. On distingue donc trois sortes de caches, chacune ayant des rôles et des objectifs bien distincts : cache situé au niveau du client appelé cache de lecture (« player buffer »), cache situé au niveau du serveur appelé cache de serveur et enfin cache situé au niveau du réseau appelé cache de réseau ou proxy (voir Figure 1.15).

FIGURE 1.15 – Les caches dans un système de streaming [3].

Un cache, quel que soit son type, est typiquement piloté par un gestionnaire qui optimise son utilisation. Afin de mesurer l’efficacité d’une technique donnée de gestion de cache, on mesure le taux de succès, appelé aussi hit rate. Le taux de succès correspond au ratio entre le nombre de blocs de données trouvés dans le cache lorsqu’ils sont demandés et le nombre total de blocs auxquels on a accédé. Une métrique alternative est le taux d’échec, appelé aussi miss ratio, qui correspond au ratio entre le nombre de blocs de données non trouvés dans le cache lorsqu’ils sont demandés et le nombre total de blocs accédés (taux d’échec = 1 – taux de succès). Plus le taux de succès est élevé lors de l’utilisation d’une technique de gestion donnée, meilleure est la technique. La gestion de caches a fait l’objet d’une abondante littérature et plusieurs politiques de gestion de caches ont été créées. Dans cette section, nous décrivons les rôles et les objectifs des différentes sortes de caches et nous détaillons quelques unes des techniques de gestion les plus représentatives.

1.7.1 Cache de lecture

Un cache, appelé « buffer », est introduit au niveau d’un client afin de restituer les streams sans saccades et de combattre les effets de la gigue présente dans les réseaux à commutation de paquets (cf. Section I.3.2.1). Il permet donc d’apporter une meilleure qualité de service, chose à laquelle l’utilisateur est particulièrement sensible. Un cache de lecture est constitué d’une mémoire tampon (« buffer ») placée dans la machine hébergeant le client. Il sert à stocker temporairement les données audiovisuelles avant leur décodage et leur restitution à un usager. La mise en cache de données peut se décomposer en la mise en cache initiale («prebuffering» ou «preroll») et mise en cache durant le streaming du contenu («buffering» ou «rebuffering»).

Mise en cache initiale : Elle sert à remplir le cache de lecture du client avant le démarrage de la restitution du contenu. Ceci permet d’absorber les saccades éventuelles issues de la perte ou de l’arrivée tardive de paquets lors de la transmission, en les récupérant à nouveau avant qu’il soit temps de les restituer. La mise en cache initiale introduit donc un délai avant le démarrage d’un stream. Or, ce délai reste négligeable et même toléré par les spectateurs. Les lecteurs actuels utilisent couramment des caches de lecture capables d’emmagasiner 5 à 15 secondes de données audiovisuelles compressées.

Afin de réduire au maximum le temps de remplissage initial du cache, certains systèmes actuels effectuent une mise en cache accélérée (« over-buffering ») en transférant les données à des taux supérieurs aux taux nominaux dictés par les streams, si le serveur et le réseau le permettent. Cette technologie est appelée « Instant-on/Always-on » chez Microsoft®, «TurboPlay » chez RealNetworks® et « Instant-on Streaming » chez Apple®.

Mise en cache durant la lecture : Comme nous venons de le voir, avant le démarrage de la restitution d’un stream, des données sont mises en cache. Ces données sont renouvelées durant la restitution du stream de manière à assurer une restitution non saccadée. Parmi les politiques de remplacement utilisées à ce niveau, on recense FIFO et LRU [55]. FIFO remplace les blocs de données dans l’ordre où ils y ont été insérés, premier arrivé premier remplacé, tandis que LRU se base sur la date de la dernière utilisation de blocs, premier utilisé premier remplacé. Étant donné que les données peuvent arriver, dans un réseau à commutation de paquets, de façon désordonnée, LRU est meilleure que FIFO pour la gestion de caches de lecture.

Les caches au niveau du client peuvent avoir d’autres objectifs, comme nous allons le voir au chapitre 3, où nous utilisons un cache de lecture afin de fusionner les couches d’images à temps avant leur restitution au spectateur.

1.7.2 Cache de serveur

Lorsqu’un serveur transmet des données, celles-ci sont momentanément stockées dans la mémoire, appelée cache de serveur, avant d’être expédiées. La problématique de la gestion du cache de serveur peut être divisée en deux tâches principales. La première concerne directement les politiques de gestion proprement dites, c’est-à-dire le remplacement de blocs. La deuxième s’intéresse aux opportunités d’optimisation de l’utilisation du cache. La frontière entre les deux tâches est souvent floue. En effet, les techniques proposées dans la littérature sont, dans leur majorité, des techniques dites intégrées, combinant à la fois les techniques de gestion et d’optimisation de l’utilisation des caches. Notons que l’objectif de toutes ces stratégies est de diminuer le taux d’échec du cache lors de la récupération de blocs de données et de réduire par conséquent le besoin de récupérer des données depuis le système de stockage du serveur.

1. De nos jours, le terme « média » est utilisé à tort et à travers. À l’origine, le mot média est le pluriel du mot latin médium qui signifie milieu ou intermédiaire (média de transmission,média de stockage, etc.). Dans ce manuscrit, par le mot média (ou média de base), nous entendons donnée. Les données (les médias) sont groupées et structurées dans des conteneurs appelés objets médias, documents médias ou tout simplement contenus.
2. La fréquence d’affichage est de 25 images/seconde pour les standards européens PAL et SECAM, alors qu’elle est de 30 images/seconde pour le standard américain NTSC.
3. La vidéo à la demande (VOD) est un cas particulier.

Page suivante : CHAPITRE 2 : STREAMING EN ENVIRONNEMENTS LÉGERS

Retour au menu : Adaptation de flux vidéo en environnements limités et dynamiques : Proposition d’une solution par encodage vidéo multicouche