De nos jours, la notion de présentation multimédia est devenue de plus en plus répandue et utilisée dans les différents domaines, par exemple l'enseignement, la publicité, les présentations commerciales, etc. Un système de présentation multimédia est un système informatique intégré caractérisé par sa capacité à traiter des informations exprimées dans plusieurs média, comme le son, la vidéo, l'image, le graphique, le texte, etc. Ce type de systèmes est devenu possible et réalisable grâce à l'apparition d'une nouvelle génération d'ordinateurs caractérisés par leur grande capacité de stockage et leur grande rapidité de traitement. De plus, la disponibilité de périphériques nécessaires pour le traitement des données multimédia (comme les cartes vidéo ou audio haute qualité et les lecteurs CD) facilite la mise en oeuvre d'applications multimédia. Enfin, l'évolution rapide des réseaux à haut débit rend possible l'échange de l'information multimédia entre des sites interconnectés, notamment sur le web.
Cette avancée technologique au niveau de la puissance des ordinateurs, des périphériques et des réseaux a abouti à la création d'un grand nombre d'applications multimédia, comme par exemple le télé-enseignement, la visioconférence, la vidéo à la demande, etc. Leur fonction principale, appelée présentation multimédia, consiste à présenter les objets média de façon synchronisée selon un scénario spécifié. Garantir cette synchronisation est un problème qui est au coeur de nombreux travaux de recherche récents. Ainsi, des études sont effectuées sur les modes de synchronisation entre les objets média dans les documents multimédia distribués, notamment au niveau de la spécification (comme les études présentées dans [Blakowski 96] et [Wahl 94] sur les modèles temporels qui peuvent être utilisés pour spécifier la synchronisation entre objets média) et au niveau de la présentation (comme les études présentées dans [Hafid 98] sur la gestion des paramètres qui affectent la qualité d'une présentation, dans [Steinmetz 96] sur l'effet de la désynchronisation sur la perception du lecteur, et dans [Steinmetz 95] sur les services dont la présentation multimédia a besoin au niveau système d'exploitation). L'objectif du groupe multimédia au sein de l'équipe Opéra est d'intégrer ces deux aspects des documents multimédia, c'est-à-dire la spécification et la présentation, dans une seule application appelée Madeus.
Dans ce chapitre, nous nous intéressons à l'étude des principales caractéristiques des présentations multimédia et des fonctions qui doivent être fournies par une application d'édition et de présentation multimédia. Cependant, pour mieux apprécier l'ensemble du problème posé par les systèmes multimédia, nous élargissons notre étude à d'autres systèmes multimédia non orientés vers l'édition.
Tout d'abord, nous présentons dans la section 2 les besoins et les caractéristiques d'une présentation multimédia. Ensuite, dans la section 3, nous introduisons les fonctions qui doivent être fournies par un système de présentation multimédia pour prendre en compte les besoins et les caractéristiques définis dans la section précédente. Ces fonctions seront illustrées à travers leurs mises en oeuvre dans différents systèmes existants. Enfin, dans la section 4, nous étudions les principes de quelques standards multimédia et les façons dont ils traitent les fonctions précédemment identifiées.
Dans cette section, nous présentons les principales propriétés qui caractérisent les présentations multimédia. Les caractéristiques identifiées ci-dessous doivent être prises en compte par le système de présentation et permettront de définir, dans la section suivante, l'ensemble des fonctions que doivent fournir les systèmes de présentation multimédia.
Les objets média qui font partie d'une présentation multimédia ont des caractéristiques hétérogènes. Celles-ci peuvent être classées selon un certain nombre de critères dont les plus importants sont :
1) Le mode de perception de l'information par l'utilisateur : Il spécifie la manière selon laquelle l'utilisateur perçoit les objets média. Ces derniers peuvent ainsi être audibles (comme un message audio ou un clip de musical) ou visibles (comme un texte, une image, une animation ou une vidéo).
2) Le comportement temporel : Il caractérise la façon selon laquelle les objets média se comportent temporellement pendant leur présentation. On peut identifier les types de comportements temporels suivants :
3) Le format de codage :
Des différents types de format de codage ont été définis pour stocker les objets. Ces formats servent fondamentalement à :
4) L'adaptabilité : Ce critère définit la capacité des objets média à répondre aux exigences de la qualité du service rendu. Les objets tels que les clips vidéo et les images peuvent être adaptables (selon le codage utilisé) puisqu'ils tolèrent des dégradations dans leur qualité de présentation (par exemple réduire le nombre de couleurs utilisées) en fonction des ressources système disponibles. D'un autre côté, les objets comme le texte et le son ne sont le plus souvent pas adaptables aux exigences de la qualité de service puisqu'ils ne tolèrent aucune perte de leur contenu ou de leurs données.
5) Le volume : Les objets média sont caractérisés par leur taille volumineuse qui exige une grande capacité de stockage. Pour résoudre ce problème, de nombreux travaux ont porté sur la définition d'algorithmes de compression pour différents types d'objets. Le taux de compression obtenu dépend de l'algorithme appliqué, du type d'objet média (image, vidéo, audio, vidéo/audio, etc.), du contenu des objets média et de la relation entre les unités successives d'un objet média (par exemple la répétition des informations dans les images successives d'une vidéo ou dans les échantillons successifs d'une audio).
Pour réaliser l'importance de la compression, nous prenons l'exemple d'une vidéo non compressée ayant une taille de 320x240 pixel/image (1 octet/pixel) et une vitesse de présentation de 25 images/seconde. Un nombre total de 1000 images, soit une durée de 40 secondes, nécessite 76.8 Moctet pour la stocker. Si la vidéo doit être présentée sur un site distant de son lieu de stockage, alors les données doivent être transférées avec un taux minimum de 1.92 Moctet/seconde. Le format de compression MPEG peut offrir un important taux de compression (par exemple jusqu'à 1 : 40) dépendant du contenu des images, de la relation entre les contenus des images successives et de la méthode appliquée pour la décompression. Par contre, les données compressées exigent la disponibilité d'une unité de décompression du côté client, ce qui ajoute une charge supplémentaire sur les ressources cpu. Un compromis entre le délai de traitement et la consommation d'espace mémoire/disque est donc indispensable.
La nature variée des objets média que nous venons d'identifier doit être prise en compte au sein des systèmes multimédia, ce qui induit de nouvelles difficultés techniques.
Une présentation multimédia n'est pas une simple présentation d'objets média indépendants. C'est un processus qui traite un ensemble d'objets média organisés logiquement, spatialement et temporellement, cet ensemble d'objets étant appelé un document multimédia.
La spécification de l'organisation logique correspond à la décomposition d'un système d'information en composants. Ainsi, l'auteur détermine le sujet à présenter et commence à définir les composants différents et la façon selon laquelle ils seront synchronisés. Par exemple, un sujet comme les activités de l'équipe Opéra peut être décomposé en deux composants : une partie générique qui présente une introduction de l'équipe et une partie qui met en lumière les thèmes de recherche abordés au sein de l'équipe. L'opération de décomposition est récursive, c'est-à-dire que chaque composant peut être également décomposé en d'autres composants. Par exemple, le composant générique peut être décomposé en une musique de fond avec un message audio et une vidéo du directeur (voir Fig 1 ). L'opération de décomposition termine lorsque nous arrivons à décomposer le sujet en objets média de base (comme un texte, une image, une vidéo, une audio, etc.). Le résultat de cette opération donne une structure logique hiérarchique pour la présentation.
Fig 1. Structure logique d'une présentation
La spécification de l'organisation temporelle définit l'ordonnancement temporel de la présentation des différents composants afin de construire le scénario souhaité. Cette spécification est développée dans la section 2.5 consacrée à la synchronisation. Par exemple, la Fig 2 présente un scénario temporel complet pour la présentation de l'équipe Opéra. De par la complexité de la tâche de spécification temporelle, il est nécessaire d'avoir un mécanisme efficace pour structurer les scénarios temporels. De plus, ce mécanisme doit pouvoir être supporté par un ensemble d'algorithmes pour vérifier la cohérence du scénario spécifié.
La spécification de l'organisation spatiale définit le placement des objets média les uns par rapport les autres sur l'écran pendant la présentation [Carcone 97]. Nous n'allons pas détailler l'organisation spatiale d'une présentation multimédia parce qu'elle ne fait pas l'objet de cette thèse.
Fig 2. Scénario temporel d'une présentation
Du fait de la nature temporelle des documents multimédia, un besoin de perception globale du scénario apparaît tant pour l'auteur que pour le lecteur. Ce besoin peut être couvert soit par des techniques de visualisation de l'axe du temps (illustré dans la Fig 2 ) qui donne l'ordonnancement temporel des objets média les uns par rapport aux autres (comme dans CMIFed [Hardman 98], Macromedia Director [Macromedia 95] et Madeus [Jourdan 98b]), soit par des fonctions de navigation en activant des hyperliens lors de l'exécution (cf. section 3.2).
Jusqu'à présent, il n'existe pas encore de plate-forme standard, c'est-à-dire une référence pour les ordinateurs, les systèmes d'exploitation ou bien pour les périphériques (comme par exemple les cartes audio) qui permette de traiter de façon homogène les objets média. Ceci pose un problème au niveau de la portabilité des applications multimédia. D'une part le code de l'application qui s'exécute sur une plate-forme peut ne pas s'exécuter sur une autre. D'autre part, les objets média créés sur une plate-forme donnée ne peuvent pas forcément être joués sur une autre. Un besoin très important de l'utilisateur des documents multimédia est donc la disponibilité de logiciels qui peuvent interpréter les documents multimédia et jouer tous les types d'objets média sur les différentes plates-formes existantes.
La présentation d'un document multimédia se distingue de la présentation d'un document statique à cause, principalement, de la dimension temporelle qui apparaît de façon interne aux objets média (comme pour l'audio et la vidéo qui possèdent des propriétés temporelles inhérentes), ainsi que de façon externe aux objets (comme pour les relations temporelles définies explicitement par l'auteur entre des objets média). L'état d'un objet média dans un document multimédia change au fur et à mesure que la présentation avance dans le temps. Par exemple, un objet média qui joue au présent peut s'arrêter dans le futur et vice versa. De même, pour un objet média continu, tel qu'une vidéo, son image affichée change avec le temps selon une vitesse prédéterminée. La présentation multimédia peut donc être définie comme suit :
La façon selon laquelle les changements d'état doivent avoir lieu est définie par le mode de synchronisation de la présentation multimédia et est analysée ci-dessous.
La synchronisation est une caractéristique importante des applications multimédia qui concrétise la sémantique d'une présentation multimédia conçue par un auteur. Dans le cas des objets média continus, le facteur temps apparaît comme une dimension essentielle de l'information. Une synchronisation peut être définie entre :
Dans la suite de cette section, nous détaillons les quatre formes principales de synchronisation que nous venons d'identifier : la synchronisation intra-objet, la synchronisation inter-objet
, celle avec l'environnement et la synchronisation de groupe.Ce type de synchronisation est inhérent à l'objet média continu qui est considéré comme une suite ordonnée d'unités de présentation ayant des relations temporelles implicites entre elles [Blakowski 96]. Pour ce type d'objets média, les informations de synchronisation sont stockées dans l'objet lui-même lors de sa capture. Par exemple la vitesse de présentation d'une séquence vidéo (25 images/seconde) ou d'une séquence audio (8000 ou 44100 échantillons/seconde) spécifie la durée de présentation de chaque composant dans cette séquence. Ainsi, une image vidéo est présentée pour une durée de 40 millisecondes (voir Fig 3 ). Néanmoins, l'auteur d'un document multimédia peut spécifier une vitesse de présentation autre que la vitesse normale pour jouer l'objet plus rapidement ou plus lentement.
Fig 3. Exemple d'une synchronisation intra-objets
La synchronisation inter-objets peut être synthétique ou naturelle. La synchronisation synthétique inter-objets est celle spécifiée explicitement par l'auteur entre différents objets média afin de décrire un scénario souhaité. Elle est définie sous forme de relations temporelles entre les instants de début et/ou les instants de fin de différents objets média (voir Fig 4 ). Ce type de synchronisation est appelé la synchronisation à gros grain.
Fig 4. Synchronisation inter-objets
Par contre, la synchronisation naturelle inter-objets est celle qui synchronise deux types d'objets média, souvent une vidéo avec une audio, où les paramètres de synchronisation sont déterminés lors de la capture des objets. Par exemple, si nous enregistrons une vidéo et son commentaire audio avec des vitesses respectives de 25 images/seconde et 8000 échantillons/seconde, une synchronisation naturelle est alors établie dont le paramètre est d'afficher une image vidéo tous les 320 échantillons audio. Ce type de synchronisation est appelé la synchronisation fine ou la synchronisation de lèvres (lip-sync).
Un axe de recherche très important concernant le multimédia consiste à étudier comment exprimer la synchronisation temporelle souhaitée entre les différents objets d'une application multimédia. Dans le domaine de l'intelligence artificielle, Allen [Allen 83] a proposé un ensemble d'opérateurs qualitatifs binaires qui peut exprimer l'ordonnancement temporel entre des tâches dans une application de planification. Une approche possible était donc l'adaptation de cet ensemble d'opérateurs afin de les utiliser pour exprimer la synchronisation temporelle multimédia, comme dans OCPN [Little 90] et Madeus [Layaïda 97]. Par ailleurs, Schloss et al. [Schloss 94] ont proposé une algèbre d'événements pour construire des structures temporelles spécifiant la synchronisation entre les objets média. Dans un but de standardisation, le World Wide Web Consortium (W3C) travaille sur la spécification d'un standard nommé SMIL (Synchronized Multimedia Integration Language) [W3C 98b] qui permet de spécifier la synchronisation sous la forme d'un arbre d'opérateurs. Pour conclure, on peut classer les approches de spécification de la synchronisation en trois grandes familles :
La comparaison entre les trois approches peut être faite selon trois critères : la puissance expressive qui caractérise la possibilité de spécifier des schémas de synchronisation plus ou moins complexes, la facilité de spécifier un scénario temporel d'un document multimédia et la facilité de le modifier. Nous n'allons pas détailler les approches de spécification, ni la comparaison entre elles, parce que ce n'est pas dans l'objectif de cette thèse [Jourdan 98b].
Ce type de synchronisation permet à une application multimédia d'effectuer des actions de présentation en réponse à l'arrivée d'un événement venant de l'extérieur. Par exemple, l'utilisateur peut contrôler le déroulement de la présentation (comme démarrer, stopper ou ralentir) ce qui a pour effet de modifier le comportement temporel normal de l'application multimédia. Dans la section 3.2, nous présentons un type de synchronisation avec l'environnement : les fonctions de navigation via les documents multimédia en réponse à l'interaction utilisateur.
Ce type de synchronisation vise à réaliser le principe "What You See Is What I See" (WYSIWIS) utilisé dans les applications multimédia coopératives [Stefik 87], comme par exemple la téléconférence (MAJIC [Okada 97]), le tableau blanc (en anglais, white board) (MMwb [ZhangY 97]) et le télé-enseignement (MITS [Al-Shammari 98]). Dans une session d'une application coopérative, tous les participants doivent recevoir au même instant la même vue des fenêtres partagées et le même message audio.
Grâce à l'évolution dans le domaine de la communication entre ordinateurs, les objets média faisant partie d'une même application multimédia peuvent être distribués sur différents serveurs : soit sur le même site, soit sur des sites différents. Du fait de sa grande taille et des aléas du débit des liaisons numériques, l'accès à un objet peut subir un délai plus ou moins important et d'une valeur aléatoire. Par conséquent, la qualité de la présentation de ces objets peut être dégradée à cause du non respect des échéances temporelles. Un autre point crucial est le risque de perte de données qu'un objet média peut subir pendant un accès distant et le comportement des objets face à la perte de leurs données. Par exemple, une vidéo peut tolérer la perte d'un pourcentage de ses données sans sérieusement affecter la qualité de perception par l'utilisateur, alors qu'un texte ou une audio ne tolère aucune perte de ses données.
Ainsi, les protocoles d'accès utilisés pour accéder aux objets média doivent tenir compte de leur nature temps réel et de leur comportement vis-à-vis la perte de données. De plus, les canaux de communication doivent fournir les bandes passantes nécessaires pour manipuler les gros volumes des objets média.
L'indéterminisme d'une présentation multimédia est la divergence entre la présentation et le scénario spécifié par l'utilisateur. Cette divergence peut avoir plusieurs sources, la plus importante étant la présentation d'un ou plusieurs objets incontrôlables. Un objet est incontrôlable dans deux cas : soit c'est un objet indéterministe comme un bouton d'interaction pour lequel nous ne savons pas à priori à quel instant l'utilisateur va l'activer, soit c'est un objet continu ou discret pour lequel la durée de présentation diffère de celle attendue en raison des délais subis par l'objet pendant son accès distant et/ou pendant son traitement.
Au niveau de la synchronisation spécifiée par le scénario, l'indéterminisme introduit donc des décalages et, par conséquent, une désynchronisation entre les objets média. Celle-ci peut dégrader la perception humaine du scénario. Des études expérimentales [Steinmetz 96] ont été effectuées sur les seuils de décalage acceptables par la perception humaine. Le tableau de la Fig 5 montre les valeurs des seuils de décalage entre les différents types d'objets média. Ces valeurs peuvent être utilisées pour mesurer la qualité de service offerte par le système de présentation.
Fig 5. Seuils de décalages entre les différents types d'objets média
Afin de ne pas dépasser les seuils de décalage, le système de présentation doit appliquer des mécanismes pour diminuer la désynchronisation introduite par les objets indéterministes. Dans la section 3.7, nous présentons quelques mécanismes pour gérer l'indéterminisme de la présentation.
À partir des caractéristiques identifiées ci-dessus, nous présentons les fonctions nécessaires que doit fournir un système de présentation multimédia. Pour chacune de ces fonctions, nous citons, quand ils existent, des travaux qui les mettent en oeuvre. Parmi ces travaux existants, nous avons choisi notamment :
Une présentation plus détaillée des principaux standards multimédia (comme HyTime, SMIL, MHEG et PREMO) est faite dans la section 4.
Les besoins de spécification de l'information multimédia ne sont pas développées ici car ils sont bien établis dans la communauté multimédia [Blakowski 96]. Il est clair cependant que les deux aspects la spécification et la présentation ne sont pas complètement indépendants.
La gestion des objets média peut être effectuée à deux niveaux : la présentation et l'organisation.
Gestion au niveau de la présentation
La gestion des objets média au niveau de la présentation consiste à prendre en compte l'hétérogénéité de ces objets en spécifiant les outils et les logiciels qui prennent en charge la manipulation et la présentation de chaque type d'objet. De plus, une application multimédia doit être capable de gérer les nouveaux types et formats d'objets média au fur et à mesure de leur apparition ; cette caractéristique est appelée l'extensibilité. Quelques travaux, comme MHEG [Meyer 95] et PREMO [Herman 95], ont proposé des modèles objet pour les applications multimédia afin de profiter des caractéristiques qu'offre l'approche orientée objet et notamment de la facilité de mettre en oeuvre cette fonction d'extensibilité. Ces deux modèles sont décrits en section 4. De plus, dans la section IV.5.1, nous présenterons le modèle objet que nous utilisons dans notre application Madeus.
Gestion au niveau du stockage
La gestion des objets média au niveau du stockage consiste à gérer les objets média soit sur des serveurs spécialisés (comme un serveur vidéo et/ou audio pour une application de vidéo à la demande), soit sous la forme de base de données multimédia orientée objet. Un exemple d'une base de données multimédia est celle utilisée par l'application interactive de téléenseignement (Multimedia Interactive Telelearning System (MITS)) [Huang 98] développée dans le laboratoire MMARL [MMARL 98] de l'université d'Ottawa. MITS utilise le terme courseware présentant aux étudiants un cours éducatif de façon interactive. Le rôle de MITS est donc d'offrir un environnement pour la création et la présentation de coursewares, et la gestion d'une base de données de coursewares et de leurs composants (c'est-à-dire les objets média). Le modèle de données de courseware est une architecture de document multimédia orienté objet. La conséquence en est la simplicité de la création et de la manipulation de coursewares au sein du système de base de données multimédia [Al-Shammari 98]. Afin de faciliter l'accès à la base de données, le laboratoire MMARL a développé une stratégie d'adressage multimédia par le contenu. Celle-ci demande la mise en oeuvre des techniques d'indexation de vidéo et d'audio afin de répondre aux requêtes lancées par l'étudiant.
L'accès distant à la base de données courseware est géré de la manière suivante : le serveur courseware reçoit une requête d'accès puis il l'interprète et commence à récupérer les composants courseware de la base. Ensuite, il génère à la volée les pages HTML correspondantes pour les envoyer à l'étudiant à travers le réseau Internet [ZhangZ 98].
Pour répondre au besoin de maîtriser la complexité de perception de la présentation des documents multimédia, le système de présentation doit offrir des fonctions de navigation. Ces fonctions réalisent :
Ces fonctions peuvent être gérées par un support de navigation inter- et intra-document. Dans cette section, nous présentons les types de navigation qu'un gestionnaire de navigation multimédia doit fournir à l'utilisateur et les informations nécessaires afin de réaliser ces fonctions.
La caractéristique temporelle d'une présentation multimédia s'avère dominante lors de la gestion de la navigation. Ainsi, la navigation à travers les scénarios multimédia est une navigation non seulement dans l'espace à l'intérieur de contenus d'objets média, mais encore dans le temps.
Les systèmes actuels de présentation multimédia, comme GRiNS [Bulterman 98], gèrent la navigation sans tenir compte de l'aspect temporel. Cela signifie que la destination d'un hyperlien est toujours un instant du document où tous les objets sont à leur début. Cette limite est due à la difficulté à déterminer l'état d'une présentation à un instant précis (correspondant à l'instant destination de l'ancre). Par exemple, la Fig 6 montre un document multimédia MM1 ayant un hyperlien intra-document (lien 1) et deux hyperliens inter-document (liens 2 et 3 respectivement vers les documents MM2 et MM3). La destination d'un hyperlien peut être l'instant de début ou un point au milieu de la présentation d'un objet média. Celui-ci peut se trouver soit dans le même document que la source (lien intra-document), soit dans un autre document (lien inter-document). Les instants t1, t2 et t3 sont respectivement les destinations des hyperliens 1, 2 et 3. Pour jouer un document à partir d'un instant donné, il faut déterminer tous les objets qui doivent jouer à cet instant et, pour chacun de ces objets, il faut déterminer l'instant correspondant de son départ. C'est simple pour t3, car c'est le début d'une scène (tous les objets sont à leurs débuts). Par contre, c'est difficile pour t2, car cet instant correspond à un instant au milieu de la présentation d'un groupe d'objets média. Il faut donc d'abord calculer l'état de présentation pour ces objets à l'instant t2 pour lancer la présentation du document MM2 à partir de cet instant.
Afin de réaliser ce support de navigation, des informations temporelles sur l'état de la présentation aux différents instants, notamment aux instants correspondant aux destinations d'hyperliens, doivent être gérées [Sabry 97]. La gestion de ces informations exige la disponibilité d'une structure globale du scénario (fournie par une représentation interne comme montrée dans la section 3.4).
Fig 6. Hyperliens intra- et inter-document
Dans la section IV.4.3, nous présenterons le fonctionnement et la mise en oeuvre du gestionnaire de navigation temporelle de Madeus qui gère les fonctions de navigation en tenant compte de l'aspect temporel des documents multimédia.
Le système de présentation multimédia gère la portabilité à différents niveaux de la représentation de l'information multimédia :
Outre les besoins de synchronisation fine (intra-objet et inter-objet) identifiés en sections 2.5.1 et 2.5.2 pour les des solutions seront proposées dans le chapitre IV (section IV.4.2.3), la présentation d'un document multimédia a besoin d'un ordonnanceur qui peut gérer dynamiquement les différents types de synchronisation spécifiés par l'auteur sous une forme de scénario (cf. section 2.5.2). Les événements, générés pendant une présentation multimédia sont gérés de deux façons : réactive ou prédictive.
L'approche réactive
Dans le cas de l'approche réactive, l'ordonnanceur connaît le point de départ de la présentation. Il gère le scénario sous une forme d'une liste de condition-action(s) définissant le comportement du scénario (voir la Fig 7 ). La condition est une expression booléenne fonction des attributs d'objets média et des événements générés pendant la présentation, et l'action constitue l'action de présentation à effectuer si la condition correspondante est validée. Pendant la présentation, l'ordonnanceur fonctionne comme suit : il reçoit des événements générés par les objets média et l'interaction de l'utilisateur, et chaque fois qu'une condition est validée, il lance des commandes pour exécuter l'action correspondante. Il faut noter que l'ordonnanceur, dans cette approche, n'a pas de vue globale du scénario. Cette approche est adoptée par les systèmes réalisant le standard MHEG [Berkom 98][Bitzer 96]. Dans [Vazirgiannis 97], Vazirgianis et al. utilisent l'approche réactive avec un modèle orienté objet pour les différents types d'événements qui peuvent avoir lieu durant l'interaction entre l'utilisateur et une application multimédia interactive. Ils proposent un schéma de composition d'événements qui permet de définir des interactions complexes.
Fig 7. L'approche réactive
L'avantage de cette approche est la simplicité du traitement et de la structure de l'ordonnanceur. Par contre, certaines actions de présentation exigent des opérations préliminaires avant de s'exécuter et qui ne s'accordent pas avec l'approche réactive. Par exemple, l'action d'affichage d'une simple image exige d'abord un accès local ou distant à cette image, une décompression selon son format, une allocation de couleurs et la création d'une fenêtre sur l'écran. Toutes ces fonctions préliminaires peuvent ajouter un délai qui aboutit à un affichage retardé de l'image. Dans le cas des objets continus, ce délai peut générer des effets de gigue, c'est-à-dire des délais de valeurs aléatoires introduits entre les instants pendant lesquels les images d'une vidéo ou les échantillons d'une audio sont joués. De plus, si deux objets continus sont liés par une synchronisation fine (par exemple une vidéo avec son commentaire audio), l'effet de gigue sur chaque objet peut aboutir à un effet de dérive, c'est-à-dire une désynchronisation entre les deux objets. Une approche prédictive s'avère utile pour résoudre ce problème.
L'approche prédictive
Dans le cas de l'approche prédictive, l'ordonnanceur peut savoir comment la présentation d'un scénario doit se comporter dans le futur, et c'est l'ordonnanceur qui génère les événements. En effet, l'ordonnanceur a une vue globale du scénario grâce à une structure interne. Flinn [Flinn 95] décrit l'utilisation d'un ordonnanceur prédictif afin de réaliser la synchronisation entre des objets média gérés par des applications indépendantes. Il gère une liste d'événements triés selon leurs estampilles temporelles et chacun de ces événements est déclenché à la date qui lui est attachée. L'ordonnanceur initialise une alarme en utilisant l'estampille du premier événement, et ensuite il attend l'alarme. Quand l'alarme se déclenche, l'ordonnanceur envoie l'événement vers le gestionnaire approprié de média. Dans la Fig 8 , nous avons un scénario dans lequel trois objets (Objet01, Objet02 et Objet03) se jouent en séquence. À l'instant t2, l'ordonnanceur peut non seulement donner la commande de lancer l'objet Objet02 mais aussi donner la commande d'accéder à l'objet Objet03 afin qu'il soit prêt pour la présentation après la fin d'Objet02.
Fig 8. L'approche prédictive
L'avantage de cette approche est la possibilité d'effectuer les actions préliminaires en avance afin de diminuer le délai et la gigue pendant la présentation multimédia. Par contre, une approche prédictive pure ne peut pas être utilisée parce qu'elle ne peut pas supporter l'interactivité requise par les applications multimédia. En effet, dans ce type d'approche, l'ordonnanceur réagit seulement aux événements émis par une alarme.
L'approche hybride
On peut conclure qu'afin de diminuer le délai et de réaliser l'interactivité dans les applications multimédia, il vaut mieux que l'ordonnanceur utilise une approche hybride qui intègre les deux approches : réactive et prédictive. Afin de représenter l'organisation temporelle du scénario, l'approche prédictive utilise une représentation interne qui lui permet d'avoir une vue globale du scénario :
Structure linéaire temporelle
L'organisation temporelle d'un scénario est représentée selon la forme d'une liste d'instants de temps auxquels des actions de présentation doivent être effectuées [Flinn 95]. Cette liste peut correspondre au placement par l'auteur des objets média sur un axe de temps absolu en spécifiant explicitement (en absolu ou en relatif par rapport à un objet positionné en absolu) la date de début et de fin de chaque objet média, comme dans Macromedia Director [Macromedia 95].
Arbre de relation temporelle
L'organisation temporelle est représentée sous forme d'un arbre dont les noeuds portent les relations alors que les feuilles contiennent les objets média. Le standard SMIL [W3C 98b] utilise cette approche pour représenter l'organisation temporelle d'un scénario. Il faut noter que la représentation interne d'un système de présentation qui utilise SMIL peut être un graphe. Par exemple le système GRiNS qui est une application d'édition et de présentation des documents SMIL utilise le réseau de Pétri comme représentation interne.
Graphe des relations temporelles
L'organisation temporelle est représentée sous forme d'un graphe dont les noeuds constituent les instants temporels alors que les arcs constituent les objets média, comme dans le réseau de Pétri d'OCPN [Little 90][Pérez 96], le graphe orienté acyclique d'ISIS [Song 96] et l'hypergraphe de Madeus présenté dans chapitre .
Dans la section 2.6, nous avons vu que la nature distribuée des objets média nécessite un support d'accès aux objets distants qui tienne compte de l'échéance temporelle du scénario et des objets média eux-mêmes. Le délai d'accès aux objets média sur le réseau joue un rôle majeur dans la valeur du délai de bout en bout, c'est-à-dire le temps entre l'instant où un client demande l'accès à une information média située sur un serveur distant et l'instant de sa présentation du côté client. Le délai d'accès sur le réseau dépend de sa charge qui est une variable de nature aléatoire.
Une approche de préchargement d'objets média peut donc être employée afin de diminuer l'effet du délai d'accès sur la présentation. Des algorithmes sont proposés dans [Ng 96] pour les préchargements intelligents d'un objet média continu. Cette technique nécessite l'utilisation d'une approche prédictive de synchronisation et la gestion de tampons du côté client pour maintenir les données préchargées jusqu'à leur présentation. La taille d'un tampon est calculée en fonction de la vitesse de présentation des objets média continus, du débit de réseau, des ressources mémoire disponibles du côté client, etc.
Il est évident qu'un protocole comme HTTP (Hypertext Transfer Protocol), utilisé à grande échelle pour l'échange des documents HTML sur le Web, n'est pas suffisant pour accéder aux objets média car malgré sa fiabilité il ne respecte pas l'échéance temporelle d'objets média dans un scénario. Afin de résoudre ce problème, l'Internet Engineering Task Force (IETF) [IETF 98] a amorcé le développement d'un ensemble de protocoles qui doivent servir à mieux gérer le transfert des données média entre les clients et les serveurs. Il s'agit des protocoles pour la réservation de ressources RSVP (Ressource Reservation Protocol) [Braden 97][ZhangL 93], le transport temps réel de données RTP (Real-time Transport Protocol) [Schulzrinne 96b][Schulzrinne 97a] et le contrôle temps réel de transport RTCP (RTP Control Protocol) [Bettai 95]. La réalisation de ces protocoles vient de commencer sur les réseaux basés sur IP. Pourtant, il n'est pas sûr que tous les protocoles seront supportés par l'infrastructure actuelle du réseau Internet. En effet, l'acceptation générale sur la réservation de ressources n'a pas encore eu lieu [Bulterman 97] et les efforts sont plutôt orientés vers l'approche utilisée par HTTP qui précharge les données dans un tampon local avant de les jouer (fetch-and-buffer).
La Fig 9 situe les différents protocoles standard d'Internet [Pujolle 97][Rifflet 90] :
Ces protocoles sont souvent réalisés comme des composants du noyau du système d'exploitation, comme dans les systèmes UNIX.
Fig 9. Les différents protocoles d'accès pour les objets multimédia
Owezarski et al. [Owezarski 98] ont déduit que la classification des deux protocoles TCP et UDP, selon leur fiabilité et leur ordonnancement de données transportées, suggère l'existence d'une autre famille de protocoles de transport entre TCP et UDP. Ils proposent donc l'utilisation d'une extension appelée Partial Order Connection (POC) dans laquelle TCP et UDP sont deux cas spéciaux. Le POC est une connection de bout en bout qui permet la définition et l'utilisation d'un mode de transfert partiellement ordonné/partiellement fiable qui se situe entre les deux extrêmes : le mode totalement ordonné/totalement fiable (comme TCP) et le mode non ordonné/non fiable (comme UDP). Dans POC, la fiabilité et l'ordonnancement de données transportées sont traités comme deux paramètres de la qualité de service spécifiés pendant la phase de l'établissement de connexion. Owezarski et al. [Owezarski 98] montrent que le concept du POC est convenable pour les données multimédia, car, en premier lieu, l'ordre de réception des paquets de différents objets média n'est pas important si leur présentation est en parallèle. En second lieu, certains types d'objets média peuvent tolérer le manque de fiabilité, c'est-à-dire la perte de données. Le POC est implanté dans l'application PNSVS (Petri Net Synchronized Visioconference System) [Owezarski 98]. Pourtant, le POC ne traite pas l'aspect temps réel du transfert de données multimédia. Dans la suite, nous présentons les protocoles RTP et RTCP qui supportent le transfert de données avec échéances temps réel.
Les protocoles temps réel RTP et RTCP sont construits au dessus des protocoles TCP et UDP, respectivement. Ils sont actuellement réalisés dans les applications elles-mêmes, plutôt qu'au sein du support système de bas niveau. C'est probablement une période d'essai pour garantir d'abord l'efficacité de ces protocoles avant de décider quelles parties de protocoles doivent être intégrées dans le noyau de système d'exploitation.
Les deux protocoles RTP et RTCP forment une paire de protocoles de transport qui peuvent supporter le transfert de données ayant des caractéristiques temporelles. Ils supportent le transfert point à point (unicast) et multipoint (multicast) si les couches sous-jacentes les supportent. Le protocole RTP s'occupe principalement du transfert de données du serveur au(x) client(s) (voir Fig 10 ). Il découpe les données média pour les emballer en paquets et les étiquette par des estampilles temporelles qui représentent leurs échéances de présentation. Par contre, le protocole RTCP se charge de transférer des paquets portant les statistiques sur le transfert et les messages de contrôle (comme par exemple accélérer/décélérer, démarrer ou stopper le flot de données) entre le serveur et le(s) client(s) (voir Fig 10 ).
Fig 10. Les protocoles RTP et RTCP
RTSP (Real-time Streaming Protocol) [Schulzrinne 97b] est un protocole du niveau application gérant la présentation d'un flot de données au fur et à mesure de leur arrivée sans avoir besoin d'attendre la fin de transfert du flot pour les présenter. RTSP se sert de la couche fournie par les protocoles RTP, RTCP et RSVP. Aujourd'hui, RTSP est utilisé par RealNetworks et fait partie de leur suite RealAudio/RealVideo [Real 98b].
Une application multimédia utilise de nombreuses ressources afin d'effectuer les traitements nécessaires à sa présentation (comme par exemple interpréter le scénario temporel, décompresser les objets média, allouer un tableau de couleurs, etc.). Les différents types de ressources peuvent être groupés en deux classes principales :
Gestion des ressources de la machine cliente
En général, une présentation multimédia a besoin d'un support pour la qualité de service de bout en bout. Les mécanismes de gestion de ressources doivent donc être fournis non seulement par le réseau mais aussi par la machine cliente. Sur la machine cliente, le système d'exploitation s'occupe de l'allocation des ressources nécessaires pour la présentation. Un problème important réside dans la gestion, par le système d'exploitation, de l'allocation des ressources requises par des processus interdépendants d'une application multimédia ayant des caractéristiques temps réel.
Prenons l'exemple d'une application multimédia qui gère deux processus : le premier joue une vidéo en parallèle avec le deuxième processus qui joue son commentaire audio. Il est évident que les deux processus sont interdépendants à cause des besoins d'échange des données de synchronisation afin que chacun traite ses données en fonction de l'avancement de l'autre. Le mode de communication entre processus peut jouer un rôle important dans la performance globale de l'application. Dans [Bourges 96], il a été montré que la communication par la mémoire partagée au lieu de tubes de communication permet d'optimiser l'application et d'améliorer considérablement la performance. Pourtant, même si la structure de l'application est optimisée, le fait que la synchronisation entre processus n'est pas considérée par le mécanisme d'ordonnancement de processus au niveau du système d'exploitation peut aboutir à la dégradation de la performance.
Pour résoudre le problème présenté ci-dessus, trois approches principales ont été proposées :
Dans la suite de cette section nous détaillons ces trois solutions.
Classe de priorité temps réel
Le système d'exploitation doit donner une priorité pour traiter les objets média continus ayant des caractéristiques temps réel mais sans priver les objets discrets d'être traités au bon moment, comme le texte et l'image. Le système SVR4 UNIX a ajouté une classe appelée « Real Time » (RT) qui a une priorité plus haute que celles des deux classes « System » et « Time Shared ». Owezarski et al. [Owezarski 97] ont présenté une application de visioconférence synchronisée qui utilise la classe RT afin de gérer la synchronisation entre l'audio et la vidéo. Pourtant, utiliser la classe de priorité RT peut être pénalisant car les tâches système ne peuvent plus s'exécuter lorsque nécessaire puisqu'elles sont différées quand un processus RT s'exécute [Owezarski 97]. Les tâches temps-réel doivent donc être courtes. De plus, l'expérience a montré que l'attribution de cette priorité aux processus interdépendants peut aboutir à un interblocage global au niveau du système d'exploitation [Nieh 93]. La classe RT doit donc être utilisée avec prudence. Enfin, les algorithmes d'ordonnancement de tâches temps réel comme EDF (Earliest Deadline First) et RM (Rate Monotonic) ne peuvent être utilisés comme tels parce qu'ils sont utiles seulement pour traiter les processus indépendants [Bourges 96].
Interface au dessus le système d'exploitation classique
Une interface, appelée SMART (Scheduler for Multimedia And Real-Time), est proposée dans [Nieh 97a][Nieh 97b] pour le système UNIX System V Release 4 afin de fournir un mécanisme efficace d'ordonnancement de processus pour satisfaire les besoins dynamiques des applications multimédia. Cette interface facilite la propagation d'information entre les applications et l'ordonnanceur de processus. Par exemple, une application peut passer à l'ordonnanceur les informations sur ses contraintes temporelles à travers l'interface qui, à son tour, optimise l'enchaînement des demandes d'allocations de ressources de façon à ce que toutes les contraintes temporelles soient respectées. Si une ou plusieurs contraintes ne peuvent être respectées, alors l'interface SMART notifie ce fait à l'application. L'algorithme d'ordonnancement utilisé par SMART est basé sur l'algorithme EDF (Earliest Deadline First) [Liu 73].
Système d'exploitation temps réel
La troisième approche pour gérer les ressources en temps réel est l'utilisation d'un système d'exploitation temps réel. Le système Nemesis [Black 97] est un exemple de système d'exploitation multimédia qui supporte les applications ayant des contraintes temps réel. Autrement dit, l'allocation des ressources est effectuée en tenant compte de la qualité de service de toutes les ressources système (comme le cpu, la mémoire et la bande passante de disque) et des échéances temporelles d'objets média. Un défaut reconnu dans un système d'exploitation classique est qu'une grande partie du code exécuté par le système n'a pas besoin d'un privilège supplémentaire ou d'une protection quelconque, et par conséquent un pourcentage considérable du temps de système est perdu. L'idée du système Nemesis est de transférer ce code au niveau de l'application et de ne garder au niveau du noyau que le code qui exige des privilèges supplémentaires afin de mieux utiliser le noyau du système pour l'allocation des ressources en temps réel. Cette architecture de système d'exploitation est appelée l'architecture verticale.
Discussion
Pour choisir une solution parmi celles présentées ci-dessus, il faut tenir compte de deux facteurs très importants : l'efficacité de la solution pour gérer l'aspect temps réel d'une présentation multimédia, et la faisabilité de la solution sans affecter la capacité à exécuter les autres tâches qui ne sont pas temps réel. Le choix sera donc entre les deux dernières solutions. La troisième solution est plus efficace que la deuxième parce que l'allocation des ressources en temps réel est traitée au niveau du noyau système. Par contre, la deuxième solution est plus facilement réalisable que la troisième parce qu'elle n'exige aucune modification au niveau du noyau système existant, tandis que la troisième solution propose un nouveau système d'exploitation ce qui exige la reprogrammation des applications existantes avant leur exécution sur ce système. Pour conclure, nous voyons, pour l'instant, que la deuxième solution est la plus acceptable jusqu'à ce que l'on puisse trouver une solution qui réalise les avantages des deux dernières solutions.
Gestion des ressources réseau
La gestion des ressources réseau est faite par les protocoles de communication. Ces protocoles doivent donc réaliser les besoins des applications multimédia au niveau de la latence d'accès et de la transmission multipoint. Face à ces besoins, la suite de protocoles de transport RTP, RTCP et RSVP, présentée dans la section 3.5, est proposée. Le protocole RSVP, en particulier, est un protocole de réservation de ressources conçu pour les applications utilisant le transfert multipoint unidirectionnel mais il peut être aussi utilisé pour les applications simples utilisant le transfert point à point. Pendant la phase d'initialisation d'une application, une requête d'allocation peut être faite afin d'allouer des ressources réseau, comme la bande passante, en respectant un certain niveau de qualité de service pendant toute la vie de l'application. Ce protocole nécessite que les informations sur les ressources réservées soient maintenues au niveau des machines client/serveur ainsi qu'au niveau des routeurs. Cependant, la structure actuelle de l'Internet ne supporte pas ce besoin.
L'Internet Engineering Task Force (IETF) effectue actuellement des modifications globales au niveau conceptuel de l'architecture d'Internet pour répondre aux besoins des applications nouvelles, notamment celles du multimédia [Barzilai 98]. Le but de ces modifications est d'avoir une architecture intégrée des services Internet avancés pour mieux supporter les protocoles de réservation de ressources comme RSVP.
Une autre façon de gérer les ressources réseau est l'utilisation de la technique d'IP multipoint (multicasting IP) dans le cas où l'application multimédia envoie la même information à plusieurs destinations, comme dans une application de téléconférence. La technique IP multipoint groupe les destinations en leur donnant une seule adresse (multicast address) à laquelle l'information est envoyée une seule fois. Ensuite, le routeur le plus proche de chaque destination s'occupe de faire une copie de l'information pour cette destination. Cependant, dans le cas de l'application de la vidéo à la demande, plusieurs utilisateurs peuvent demander simultanément la même vidéo, mais chacun d'entre eux peut agir différemment en demandant des fonctions différentes de manipulation comme démarrer, stopper, faire une pause et reprendre un flot vidéo. Par conséquent, les décalages entre les flots vidéos délivrés aux différents utilisateurs changent dynamiquement. De ce fait, l'utilisation de la technique statique de IP multipoint (multicasting IP) est inappropriée.
Le laboratoire MCL [MCL 98] (Multimedia Communications Laboratory) de l'université de Boston a proposé un protocole dynamique d'agrégation, DSAP (Dynamic Service Aggregation Protocol) [Basu 98] qui groupe dynamiquement un ensemble de flots décalés de la même vidéo dans un seul flot en appliquant le multicasting IP. Ce protocole est appliqué en deux phases :
Le système MPEG-1 [ISO 93] est utilisé à la base de l'application de vidéo à la demande pour réaliser le protocole DSAP. En effet, le format MPEG fournit un grand taux de compression et une flexibilité dans la manipulation de la vitesse de présentation et de la qualité du flot vidéo délivré.
Le problème d'indéterminisme se révèle important dans le domaine de la planification de tâches en robotique [Vidal 95] ainsi que dans le domaine de la spécification de scénario multimédia [Layaïda 96b]. L'indéterminisme des durées de tâches participant à un plan quelconque peut aboutir à l'échec du respect de ce plan. Dans le domaine multimédia, malgré le fait que nous ne pouvons pas éviter l'indéterminisme, la présentation doit toujours respecter le scénario spécifié.
Jusqu'à présent, il n'y a pas de solution générale pour résoudre ce problème, mais il existe quelques solutions partielles. Dans le domaine de la planification, une solution a été proposée [Courtiat 96] qui se consiste à utiliser l'automate d'états finis temporisé afin d'explorer de façon exhaustive toutes les exécutions possibles d'un plan donné. L'automate est analysé par un gestionnaire pour déterminer les exécutions menant aux états d'erreur et donc les éviter.
Dans le domaine du multimédia, l'indéterminisme ne pose aucun problème pour les systèmes purement réactifs (cf. section 3.4) parce qu'ils réagissent simplement dès qu'ils reçoivent un événement qui n'a aucune contrainte sur la date de son arrivée. Par contre, les systèmes dits prédictifs ou hybrides (cf. section 3.4) sont sensibles à l'indéterminisme parce qu'ils ont une vue globale du scénario et, par conséquent, ils ont un modèle pour la présentation et un ordre prévu pour l'arrivée des événements.
Des solutions ont été proposées pour une classe particulière de scénarios de documents multimédia. Dans [Layaïda 97], la solution proposée consiste à déterminer statiquement (c'est-à-dire avant de lancer la présentation) si l'indéterminisme peut être compensé totalement de façon dynamique (c'est-à-dire pendant la présentation) afin de respecter le scénario spécifié. Dans la section IV.4.4, nous proposons une solution complémentaire dans le cas où la solution précédente ne peut pas être appliquée. Elle consiste à observer l'indéterminisme pendant la présentation et puis à y réagir en appliquant un algorithme qui peut éliminer rapidement la désynchronisation résultant de l'indéterminisme.
Parmi les fonctions présentées dans la section précédente, un certain nombre ont fait l'objet de travaux de standardisation, que ce soit au niveau du langages de spécification comme les standards HyTime et SMIL, ou au niveau des systèmes de présentation comme les standards MHEG et PREMO. Dans les sections qui suivent, nous présentons brièvement ces standards et leurs limites dues notamment au manque de réalisations pour les valider. Dans la section 4.5, nous faisons un bilan comparatif de ces standards.
HyTime est un langage standard proposé par l'ISO (International Organization for Standardization) pour la structuration des documents multimédia et hypermédia, et notamment pour la représentation des liens hypertexte, de l'ordonnancement des événements spatiaux et temporels et de leur synchronisation [ISO 97] [Erfle 93] [Derose 94]. Il constitue une application de SGML [Goldfarb 90] qui est un standard de représentation de documents structurés statiques.
HyTime définit des éléments de type espace fini de coordonnées (Finite Coordinate Space : FCS) qui supportent la spécification d'un scénario en définissant des événements à des dates précises du temps absolu et/ou à des positions géométriques sur l'écran. Chaque type d'objet média (texte, audio ou vidéo) est associé à un FCS particulier. Par exemple un objet vidéo peut avoir quatre axes de coordonnée dans son FCS où chacun de ces axes a une unité de mesure différente (temps, position x et y sur l'écran et numéro d'image dans une séquence). Tout point d'un FCS correspond donc à un événement potentiel de la présentation d'un document. De ce fait, la spécification d'un événement se fait par un ensemble de points associés à différents FCS. L'ensemble de ces points détermine le lieu géométrique et temporel d'occurrence de l'événement.
HyTime étend les capacités de désignation de SGML en permettant de définir des pointeurs associés à des données dispersées (contenues dans divers documents ou disséminées à travers un réseau) qui contiennent, de manière transparente, des informations relatives à leur localisation. HyTime peut supporter trois types d'adressage : par nom, par position dans un espace de coordonnées (position temporelle ou spatiale sur écran) et par référence sémantique (lien hypermédia).
Le mode de désignation des objets média à plusieurs niveaux de granularité offre un bon support d'hyperliens géré par le module d'hyperliens (Hyperlinking Module). Les informations sur les liens HyTime peuvent être stockées à l'intérieur (comme les liens contextuels clink) ou à l'extérieur (comme les liens indépendants ilink) du document contenant les ancres sources. Ce dernier type de liens permet la modification de l'ensemble des liens sans modifier les documents liés.
Il existe un nombre très faible de réalisations et d'outils pour le standard HyTime, probablement à cause de sa complexité et de la difficulté que les développeurs rencontrent pour le lire et le comprendre [HyTime 97]. Néanmoins, quelques travaux ont été effectués à partir de HyTime comme par exemple les spécifications SMDL [SMDL 98] (Standard Music Description Language) qui est un langage conforme au standard HyTime pour représenter les informations musicales accompagnées par d'autres informations textuelles et graphiques. Les axes absolus (FCS) de HyTime conviennent parfaitement pour l'organisation linéaire de la musique sur l'axe du temps. Un autre exemple de l'utilisation de HyTime est le travail de thèse de P. François [François 97] qui a étudié, spécifié et prototypé une structure d'accueil SGML/HyTime répondant aux besoins de stockage et d'exploitation de la documentation technique des avions. Un dernier exemple est la spécification du langage XLink (XML Linking Language) [W3C 98e] qui se base, en partie, sur la même façon de spécifier des liens que celle utilisée par HyTime. XLink est utilisé par le standard XML [W3C 97] pour décrire les hyperliens.
L'un des principaux avantages du standard HyTime est le fait qu'il propose une modélisation générale d'un document hypermédia capable de supporter la représentation d'un grand nombre de configurations de documents. Du point de vue de l'expression des contraintes temporelles, il permet de modéliser tous les scénarios de présentation possibles si les objets média ont des comportements temporels déterministes. En revanche, le standard HyTime ne supporte pas les objets média indéterministes à cause de l'utilisation des axes de temps absolus qui minimisent la capacité d'adaptation aux conséquences d'indéterminisme.
SMIL (Synchronized Multimedia Integration Language) [W3C 98b] est un langage déclaratif développé par le W3C dont le but est de spécifier des documents multimédia sur le Web et de les jouer par des navigateurs SMIL. Un tel navigateur peut être soit un système de présentation isolé qui peut être configuré suivant les besoins d'une communauté d'utilisateurs, soit intégré dans un navigateur Web existant.
SMIL est un format d'intégration, c'est-à-dire qu'il ne décrit pas le contenu des objets média faisant partie d'une présentation multimédia, mais plutôt leur composition temporelle et spatiale ainsi que les hyperliens qui lient ces objets. En effet, un auteur d'un document SMIL peut :
Les apports principaux de SMIL se situent au niveau de la portabilité du langage de spécification des documents multimédia et de la spécification de la navigation. En effet, dans SMIL, les ancres des liens hypermédia peuvent être définies activables pendant des intervalles de temps et/ou sur des sous-régions de la fenêtre où l'objet média est affiché. Par exemple, la Fig 11 illustre un fragment d'un document SMIL qui spécifie les ancres associées à un objet vidéo, et la Fig 12 visualise les intervalles où les ancres sont activables en temps et en espace. Les axes X et Y prennent comme repère le coin supérieur gauche de la vidéo.
<video src="http://www.inria.fr/coolstuff">
<anchor id="loay" begin="0s" end="5s"
coords="0%,
20%, 50%, 50%"
href="http://www.inria.fr/MyPage"/>
<anchor id="car" begin="3s" end="7s"
coords="50%,
50%, 100%, 100%"
href="http://www.inria.fr/MyCar"/>
<anchor id="friend" begin="6s" end="9s"
coords="25%,
0%, 75%, 50%"
href="http://www.inria.fr/MyFriend"/>
</video>
Fig 12. Les ancres source de SMIL définies en temps et en espace
SMIL est en cours de construction (work in progress) et plusieurs sociétés d'informatique ont déjà annoncé leur support pour SMIL [Layaïda 98]. Ceci montre que SMIL jouera, dans un futur proche, un rôle important dans le domaine de la spécification et de l'échange de documents multimédia. De plus, un certain nombre de réalisations sont déjà effectuées, par exemple :
HPAS et GRiNS accèdent aux objets média en utilisant le protocole HTTP, tandis que RealSystem G2 utilise les protocoles temps réel RTP, RTCP et RTSP. Par contre, ces réalisations ne supportent ni les mécanismes d'extensibilité pour les objets média de base, ni la navigation dépendante du contexte, et les deux systèmes HPAS et GRiNS ne supportent pas la synchronisation de lèvres (lip-sync) entre une vidéo et une audio associée. Dans la suite de cette section, nous présentons brièvement le système GRiNS comme un exemple d'une réalisation qui s'appuie sur le langage SMIL.
GRiNS (GRaphical INterface for creating and playing Smil documents) :
GRiNS [Bulterman 98] est un système d'édition et de présentation de documents SMIL. C'est une partie de la suite CHAMELEON , un projet de recherche et de développement dont le but est de fournir un ensemble d'outils pour éditer et présenter les documents multimédia adaptatifs. Un document adaptatif est celui qui peut être transformé en plusieurs formats de présentation en fonction des besoins des auteurs. GRiNS et CHAMELEON sont basés sur la technologie développée pour l'environnement CMIF [Van-Rossum 93][Hardman 98] du CWI [CWI 98].
L'environnement d'édition de GRiNS permet de créer un document SMIL à l'aide de trois vues :
Les deux premières vues sont utilisées pendant la phase d'édition, c'est-à-dire qu'elles ne sont pas disponibles lorsqu'un document est joué dans la vue de présentation.
Fig 13. La vue logique et la vue de l'axe virtuel de temps dans GRiNS
Le moteur de présentation de GRiNS consiste en un interpréteur de documents qui s'occupe d'exécuter les documents SMIL et de gérer leur présentation en réponse à l'interaction utilisateur. Le moteur contient également un processeur de liens et un ordonnanceur de canaux (channel scheduler) qui construit une représentation du document sous forme d'un réseau de Pétri. La présentation des objets média est effectuée par des processus légers (channel threads) qui communiquent avec les périphériques de présentation.
Dans GRiNS, la gestion des objets média est limitée par un nombre fixe de types d'objets et par conséquent, le système n'est pas extensible face à l'évolution de nouveaux types et formats d'objets média. Au niveau de la synchronisation, GRiNS gère uniquement la synchronisation à gros grain qui garantit seulement la synchronisation des débuts d'objets commençant simultanément. Le support de navigation est conçu sur les mêmes principes que ceux utilisés dans HTML, c'est-à-dire qu'il ne tient pas compte de la dimension temporelle d'un document multimédia. Au niveau de la distribution, les objets média distants sont accédés par le protocole HTTP.
Le but du groupe MHEG [Meyer 95] (Multimedia and Hypermedia Information Coding Experts Group) est la définition et la standardisation d'un format portable de représentation multimédia pour faciliter l'échange d'objets entre sites. Il faut noter que MHEG, par opposition à HyTime et à SMIL, gère la forme finale de la présentation, c'est-à-dire qu'il garde seulement les informations sur les relations temporelles et spatiales mais il supprime les informations sur la structuration logique de la présentation. Ceci a abouti à un modèle objet constitué d'une hiérarchie de classes objet MHEG comprenant les classes Content (qui permettent de décrire le contenu d'objets média), Script (pour définir des comportements sous forme de programmes), Composite, Link et Macro, ces trois dernières étant décrites ci-dessous.
Les objets composites sont utilisés comme container pour un groupe d'objets MHEG appartenant à une partie d'une application multimédia, formant ainsi un objet complexe. Ils permettent donc d'emballer les composants d'une application multimédia en un ensemble d'objets composites pour faciliter l'échange de l'application entre sites. Le début de la présentation correspond à un objet composite nommé l'objet racine. Les objets composites sont liés entre eux à travers des pointeurs. De plus, les objets composites permettent la synchronisation entre parties d'une application multimédia à l'aide de primitives de composition spatiale et temporelle. Deux primitives temporelles binaires : serial (qui définit une exécution en séquence entre des objets média) et parallel (qui indique une exécution simultanée des objets média) sont utilisées pour spécifier les scénarios multimédia.
Les objets MHEG links ne sont pas les liens hypermédia (hyperliens) conventionnels mais permettent de spécifier les relations spatiales, temporelles et conditionnelles entre les objets média ainsi que les actions effectuées par ou sur ces objets. Un MHEG link consiste en une condition (LinkCondition) et un effet (LinkEffect) qui est une liste d'actions à exécuter sur un ou plusieurs objets cibles lorsque la LinkCondition est vérifiée (voir la Fig 14 ). En ce sens, le modèle d'exécution de MHEG est fondé sur la programmation par événements. Un MHEG link peut être un composant d'un objet composite ou bien un objet totalement à part.
Fig 14. L'utilisation d'un objet MHEG Link dans la spécification des relations temporelles et spatiales
Les objets Macro constituent une autre façon de construire les objets complexes en utilisant des macros paramétrées. Les valeurs de paramètres sont définies par l'application qui utilise la macro correspondante.
Au niveau de l'interaction utilisateur, MHEG permet à l'utilisateur d'effectuer deux types d'interaction :
La Fig 15 montre comment MHEG est utilisé au sein d'une application multimédia : un site A supporte un environnement interactif pour la création d'objets média ainsi qu'un formateur MHEG. Le rôle de ce dernier est de transformer chaque objet média créé en objet MHEG pour permettre de le transmettre à un site B à travers différents moyens de transfert (World Wide Web, LAN, disques locaux, etc.). Le site B dispose d'un interpréteur MHEG dont le rôle est d'interpréter les objets MHEG reçus pour construire une structure pour la présentation multimédia prête à l'utilisation.
Fig 15. Échange des objets MHEG
Le standard MHEG se compose de plusieurs parties notamment les parties MHEG-5 et MHEG-6. La partie MHEG-5 est destinée à supporter la distribution des applications multimédia dans une architecture client/serveur à travers différents types de plates-formes. MHEG-5 est spécifiée afin de permettre le développement d'un interpréteur du format d'échange MHEG, qui requiert très peu de ressources (voir Fig 15 ). Les applications MHEG résident sur un serveur et le client charge les portions d'application dont il a besoin. L'interpréteur réside sur le client qui s'occupe d'interpréter le format d'échange MHEG, de présenter l'application à l'utilisateur et de traiter les interactions de l'utilisateur.
La partie MHEG-6 est destinée à apporter la portabilité à MHEG-5 (cf. section 3.3) en ajoutant des fonctions de traitement de données, des fonctions de communication entre les serveurs et les clients et des fonctions d'interface avec les périphériques. Pour réaliser cela, MHEG-6 propose l'exploitation :
java.lang, java.util, java.io) afin de
fournir un accès aux fonctions de base d'une plate-forme donnée.
Afin de permettre l'accès aux objets MHEG-5 et aux services fournis par
l'interpréteur MHEG-5, une interface est définie comme une
spécification Java qui consiste en un package Java appelé
iso.mheg5 (voir Fig 16 ).
Fig 16. Le modèle MHEG-5 étendu par MHEG-6
MHEG est à l'origine de plusieurs prototypes d'application multimédia. Le projet GLUE [Berkom 98] de DeTeBerkom est une réalisation du système MHEG-5 comme décrit en Fig 15 . Le projet MAJA [Bitzer 96], qui est un projet plus récent chez DeTeBerkom, consiste en une Java Applet dont le rôle est de présenter des applications MHEG en reliant, au moyen de la technologie de communication CORBA, un client de présentation MHEG à un moteur MHEG sur un site serveur. Le principe de fonctionnement est le suivant :
Le standard MHEG ne spécifie pas un protocole d'accès quelconque pour accéder aux objets média distants, mais il donne au développeur la liberté de structurer l'architecture du gestionnaire de distribution.
Le projet GLASS (GLobally Accessible ServiceS) [Geyer 97] de DeTeBerkom a pour objectif de réaliser un système qui peut offrir différents services comme la vidéo à la demande ou bien la TV interactive. La présentation au sein de ce système est fondée sur la norme MHEG. La Fig 17 illustre une scène de l'application GLASS et la Fig 18 montre une partie du pseudo-code correspondant. La scène se compose d'une image du fond avec trois objets de type texte formant les options d'un menu. À chaque texte est associé un objet MHEG Link qui décrit son comportement vis à vis de l'interaction d'utilisateur.
Fig 17. Une scène de l'application GLASS
(Composite:InfoScene
<autres attributs ici...>
group-items:
(bitmap:
BgndInfo
content-hook:
#bitmapHook
original-box-size:
(320 240)
original-position:
(0 0)
content-data:
referenced-content: "InfoBngd")
(text:
Option1
content-hook:
#textHook
original-box-size:
(280 20)
original-position:
(40 50)
content-data:
included-content: "1. STAR ...")
links:
(link:
Link1
event-source:
Option1
event-type:
#UserInput
link-effect:
action: transition-to: InfoStar)
)
Fig 18. Pseudo-code de la scène
L'objectif de la norme PREMO (PResentation Environments for Multimedia Objects) développée par l'ISO [Herman 95] est de fournir un environnement de développement standard et portable pour les applications multimédia. PREMO s'intéresse essentiellement aux techniques de présentation des données multimédia selon une approche objet issue du modèle développé par le consortium OMG (Object Management Group) et qui permet de spécifier les caractéristiques visibles des objets (PREMO objects) indépendamment de leur réalisation. Le modèle objet PREMO est défini à partir de trois composants (hiérarchies de classes d'objets) [ISO 96a] : le composant Foundation pour la spécification abstraite des informations multimédia [ISO 96b], le composant Multimedia System Services pour la spécification des traitements de bas niveau sur les données multimédia [ISO 96c], et le composant Modelling, Presentation, and Interaction pour la présentation des média en scènes [ISO 96d].
Fig 19. Hiérarchie des objets PREMO du composant Foundation
Ainsi, le composant Foundation est une collection d'objets réalisant des services utiles pour une large variété d'autres composants. Ces objets sont (cf. Fig 19 ) :
Dans PREMO, la synchronisation est exprimée en termes de classes parallel et sequential. Celles-ci représentent des objets containers groupant un ensemble d'objets média avec les relations temporelles par et seq, respectivement. De plus, PREMO utilise un modèle d'événements, illustré dans la Fig 20 , qui réalise la synchronisation à base d'événements. Le modèle d'exécution spécifié par PREMO est donc fondé sur la programmation par événements.
Fig 20. Le modèle d'événements de PREMO
En ce qui concerne les périphériques entrée/sortie de présentation, PREMO les représente de façon abstraite sous la forme de périphériques logiques afin de maintenir la généralité de la norme. En revanche, la gestion de la distribution des objets média n'est pas clairement traitée.
Au niveau de la réalisation, il n'y a aucune application réelle basée sur PREMO. Les travaux ont essentiellement portés sur la description formelle de PREMO en utilisant le langage Object-Z [Duke 97].
Le tableau de la Fig 21 donne une comparaison entre les standards que nous venons de présenter par rapport à la gestion de l'extensibilité, de la navigation, de la synchronisation et de la distribution. Il faut rappeler que les standards HyTime et SMIL sont définis au niveau du langage de spécification, et les standards MHEG et PREMO sont définis au niveau du système de présentation. Pourtant, les standards MHEG et PREMO proposent également un mécanisme simple pour spécifier la synchronisation d'un scénario temporel (cf. section 4.3 et 4.4). L'extensibilité n'est pas une caractéristique du langage de spécification ; elle concerne plutôt la capacité du système de présentation de gérer la présentation de différents types et formats d'objets média.
Fig 21. Comparaison entre les différents standards multimédia
La complexité du standard HyTime a retardé son utilisation dans les applications hypermédia. Par contre, le langage SMIL spécifié par le W3C (World Wide Web Consortium) risque fort de remplacer HyTime. En effet, SMIL est fondé sur le nouveau standard XML (eXtensible Markup Language) [W3C 97] [W3C 98a] dont les objectifs sont de supporter plusieurs types d'applications (y compris les applications multimédia), d'être compatible avec SGML et utilisable sur l'Internet (i.e. il supporte les hyperliens) et d'être notamment plus simple à lire, à comprendre et à mettre en oeuvre que SGML et HyTime.
La comparaison entre les deux standards MHEG et PREMO peut s'effectuer selon deux directions : la modélisation objet utilisée (et donc les possibilités d'expression d'applications multimédia) et les domaines dans lesquels chacun d'eux paraît le plus adapté.
La différence principale entre les hiérarchies de classes de MHEG et PREMO vient de la fonctionnalité de la classe Composite de MHEG qui n'a pas son équivalent dans PREMO. Il n'est en effet pas possible dans PREMO d'encapsuler les données et le comportement d'objets composites (ils sont éclatés dans les objets « TimeSynchronizable » et « Controller »). Cependant, la classe Composite de MHEG n'offre qu'un support limité pour une telle encapsulation car les données des composites sont supposées être redécoupées en un seul flot, par exemple audio et vidéo, ce qui ne correspond pas à la réalité du transport et du traitement de ces média.
Sur le plan de leur utilisation dans les applications multimédia, MHEG et PREMO peuvent être considérés comme potentiellement complémentaires. En effet, PREMO supporte principalement les fonctions de présentation et d'interaction alors que MHEG définit principalement un format d'échange ainsi qu'une spécification du processus d'échange. L'alliance de MHEG et PREMO pourrait s'avérer intéressante si l'on utilisait les capacités de présentation fournies par PREMO pour définir la partie du moteur MHEG qui s'occupe de présenter les objets MHEG après leur décodage.
Notons que malgré les efforts importants effectués pour établir les standards HyTime, PREMO et MHEG, les réalisations qui s'y réfèrent sont peu nombreuses (les publications [Berkom 98] [Bitzer 96] [Foquet 96] décrivent quelques réalisations pour MHEG, et la publication [SMDL 98] décrit le standard SMDL qui est fondé sur le standard HyTime). Deux raisons principales à cela : d'une part leur état non encore stabilisé (sauf pour HyTime), et d'autre part leur complexité surtout dans le cas de HyTime et PREMO. Néanmoins, le standard MHEG-5 a été adopté dans les spécifications DAVIC (Digital Audio VIsual Council) comme un format à utiliser dans les services de la télévision numérique [Kate 98].
Les deux standards PREMO et MHEG ne s'adaptent pas aux applications d'édition qui requièrent des méthodes pour modifier les objets (ajout/suppression de relations par exemple) et des moyens d'abstraction encore plus évolués que ceux proposés dans ces standards, notamment pour faciliter la réutilisation de parties de documents ou pour exploiter les informations temporelles des composites dans les phases de vérification et de formatage.
Kate et al. ont présenté, dans [Kate 98], une approche pour la transformation des documents de format SMIL en format MHEG-5. Une telle transformation a été proposé afin d'atteindre l'interopérabilité entre le domaine du web qui utilise SMIL comme un langage de spécification pour les présentations multimédia interactives et le domaine de la télévision numérique qui utilise le standard MHEG-5 comme un format d'application. L'expérience présentée dans [Kate 98] a montré que la transformation d'un format à l'autre peut être envisagée bien qu'ils diffèrent sensiblement.
Il faut noter qu'il n'existe pas encore de standard intégré qui puisse satisfaire efficacement et simultanément les besoins des deux aspects principaux d'une application multimédia, c'est-à-dire la spécification et la présentation.
Dans ce chapitre, nous avons présenté la nature des problèmes liés aux caractéristiques des systèmes de présentation multimédia en général et la manière selon laquelle ils sont traités au sein des standards et des systèmes multimédia existants. De cette étude, nous pouvons déduire que le système de présentation d'une application d'édition/présentation de documents multimédia interactifs doit fournir les fonctions suivantes :
Selon notre étude de l'état de l'art, nous pouvons constater que les points (2), (6) et (7) ne sont pas résolus et que les autres points, c'est-à-dire (1), (3), (4) et (5), ne le sont que partiellement.
Le chapitre suivant est dédié à l'introduction du système Madeus que nous avons créé pour éditer/présenter les documents multimédia et dans lequel nous tentons de résoudre une bonne partie de ces points.