Chapitre 4

Machine d'exécution multimédia

1 Introduction

Dans ce chapitre, nous présentons l'architecture et les fonctions de la machine d'exécution multimédia dans Madeus. À partir des informations de synchronisation maintenues par l'hypergraphe, la machine d'exécution effectue les fonctions de présentation en tenant compte de l'interaction utilisateur : elle gère la synchronisation entre les objets média, la navigation temporelle intra- et inter-document ainsi que l'indéterminisme de la présentation. De plus, elle se charge de gérer la création et la mise à jour de l'ensemble d'objets média supporté par Madeus.

Le plan du chapitre est le suivant. Nous présentons d'abord l'architecture générale de la machine d'exécution (voir section 2) puis, nous introduisons le modèle d'exécution d'un document multimédia Madeus (voir section 3). Enfin, nous décrivons les fonctions des différents composants de la machine d'exécution : l'ordonnanceur (voir section 4) et le gestionnaire d'objets (voir section 5).

[Table des matières]

2 Architecture de la machine d'exécution multimédia

La machine d'exécution, représentée dans la Fig 1 , est le point d'articulation entre les couches hautes indépendantes des plates-formes et les couches basses qui en dépendent. L'architecture de la machine d'exécution se compose de deux composants principaux : l'ordonnanceur et le gestionnaire d'objets. Le lecteur d'un document multimédia peut spécifier la commande de présentation qu'il souhaite à travers l'interface utilisateur, celle-ci se chargeant ensuite de notifier l'ordonnanceur avec le type de service demandé : play, pause, resume, fast forward et fast rewind. Ensuite, l'ordonnanceur décide quelle action doit être effectuée en fonction de la commande de présentation, de l'hypergraphe d'exécution qui maintient les informations sur le scénario et de l'horloge du système qui donne le temps. Enfin, le gestionnaire d'objets exécute l'action décidée par l'ordonnanceur qui peut être une création, un lancement ou une terminaison d'objet. Le gestionnaire d'objets s'occupe également d'assurer le retour d'informations sur l'état d'exécution des objets créés pour l'ordonnanceur. Ceci permet à l'ordonnanceur de gérer l'avancement de la présentation.

Fig 1. Architecture de la machine d'exécution

Dans la section 3, nous présentons le modèle d'exécution, puis nous décrivons dans la section 4 l'architecture et le fonctionnement de l'ordonnanceur et ses trois composants principaux : le gestionnaire de la synchronisation, le gestionnaire de la navigation temporelle et le gestionnaire dynamique de l'indéterminisme. Enfin, nous décrivons dans la section 5 le gestionnaire d'objets qui gère le modèle d'objets de Madeus et le médiateur d'objets.

[Table des matières]

3 Modèle d'exécution

La présentation d'un document multimédia est une séquence d'actions d'exécution appliquées aux dates correspondant à la spécification temporelle donnée par le scénario et qui s'applique sur l'ensemble des objets impliqués dans ce document. Ces actions sont les suivantes :

afficher/cacher un objet visible sur l'écran ou commencer/arrêter la sortie d'un objet audible sur un canal sonore,
jouer une entité d'un flot composant un objet continu comme par exemple une image d'une séquence vidéo ou un échantillon d'audio. Cette action nécessite des opérations supplémentaires pour accéder à cette entité et, en général, pour la décompresser,
jouer un effet de style tel que déplacer un objet sur l'écran, changer le niveau de volume d'une audio ou changer périodiquement la couleur d'un texte.

C'est l'ordonnanceur qui décide des actions de présentation à effectuer, en utilisant pour cela un ensemble d'informations fournies par différentes sources :

l'hypergraphe qui donne l'ordonnancement de la présentation d'objets selon le scénario spécifié,
le gestionnaire d'objets qui crée les objets média et retourne à l'ordonnanceur les informations sur leur état d'exécution,
l'horloge système qui donne le temps,
l'interface utilisateur qui spécifie la commande de présentation choisie par l'utilisateur.

Dans la suite, nous présentons le mécanisme d'exécution ainsi que la structure et les entités d'exécution dont il a besoin. Enfin, nous présentons la gestion du temps dans Madeus.

[Table des matières]

3.1 Le mécanisme d'exécution

La Fig 2 présente une vue d'ensemble du mécanisme d'exécution de Madeus. Le cycle de l'exécution commence par le lancement de la commande « Jouer Document » effectuée par l'utilisateur à travers l'interface utilisateur. Cette commande est interceptée par la boucle d'événements gérée par le gestionnaire d'exécution (voir la section V.4.3) qui la passe au gestionnaire d'événements afin de la traiter. L'ordonnanceur a donc besoin d'avoir des informations sur le scénario à jouer. Celles-ci sont récupérées à partir de la représentation interne (l'hypergraphe) du scénario, l'ordonnanceur effectuant une requête vers l'hypergraphe afin d'obtenir les informations sur les objets qui doivent être lancés. Pour chacun de ces objets, l'ordonnanceur lance une commande de création vers le gestionnaire d'objets qui, à son tour, crée une instance pour cet objet et retourne son identificateur vers l'ordonnanceur. L'ordonnanceur peut alors communiquer directement avec cet objet en utilisant son identificateur et lui envoyer des commandes de présentation, comme démarrer, suspendre, reprendre ou terminer la présentation de l'objet. L'objet génère des événements en cas de terminaison et en cas d'exception, c'est-à-dire en cas d'erreur. Ces événements sont traités par le gestionnaire d'événements de l'ordonnanceur pour décider quelle action doit être effectuée à la suite de la réception d'un événement donné. L'horloge système sert à réaliser effectivement la durée spécifiée pour différents types d'objets comme :

les délais temporels associés à certaines relations temporelles ou spécifiés explicitement par l'auteur ;
les objets discrets temporisés, par exemple une image qui s'affiche pendant 5 secondes ;
les effets de style de présentation, par exemple le déplacement d'un objet sur l'écran avec une vitesse spécifiée.

Afin de réaliser le mécanisme d'exécution proprement dit, nous avons besoin :

d'une structure d'exécution qui peut donner les informations temporelles d'un scénario,
des entités d'exécution qui s'occupent de la présentation des objets impliqués dans un scénario,
d'une gestion efficace du temps de présentation.

Tous ces besoins sont traités dans les sections qui suivent.

Fig 2. Mécanisme d'exécution

[Table des matières]

3.2 L'hypergraphe comme structure d'exécution

Une structure d'exécution est une structure qui contient toutes les informations nécessaires pour gérer une exécution d'un document multimédia. Dans Madeus, la structure d'exécution utilisée se compose de l'hypergraphe d'exécution. Les informations fournies par cet hypergraphe sont suffisamment complètes pour que l'ordonnanceur puisse les utiliser pour manipuler la présentation.

Chaque arc de l'hypergraphe est associé à un pointeur vers l'objet média qu'il représente. La position d'un arc dans l'hypergraphe donne l'ordonnancement temporel de l'objet correspondant par rapport aux autres objets du scénario. Chaque objet média garde toutes les informations sur ses attributs comme le type de média, le format, les durées nominales et effectives, les effets de style de présentation, etc. De plus, chaque objet maintient des pointeurs vers les noeuds de son début et de sa fin dans l'hypergraphe ce qui facilite la désignation de l'objet au sein de celui-ci.

Chaque noeud de l'hypergraphe contient les informations suivantes :

un ensemble d'identificateurs des objets qui terminent à ce noeud,
un ensemble d'identificateurs des objets qui débutent à ce noeud,
un compteur de synchronisation pour compter les objets qui doivent se terminer à ce noeud mais qui sont encore en cours de présentation,
un graphe de dépendance causale (Fig 3 ) entre les instants de fin des objets entrants dans ce noeud,
une date qui correspond à l'instant auquel tout les objets entrant à ce noeud se terminent. Il existe deux valeurs pour cette date : la valeur nominale qui est calculée par le formateur statique (avant de lancer la présentation) et la valeur effective qui est obtenue après la fin de la présentation de tous les objets entrant à ce noeud.

Fig 3. Graphe de dépendance causal pour un noeud d'un hypergraphe

La Fig 3 montre le graphe de dépendance causale du noeud n. Les instants de fin des objets A, B, C et D sont respectivement représentés par les symboles A⁺, B⁺, C⁺ et D⁺. Ce graphe donne les relations causales entre les instants de fin des objets A, B, C et D. Les instants A⁺ et B⁺ ont entre eux une relation causale bidirectionnelle qui indique que la terminaison d'un des deux objets cause la terminaison de l'autre objet. Les instants B⁺ et C⁺ ont également une relation causale mais unidirectionnelle qui indique que la terminaison de l'objet B cause la terminaison de l'objet C. Enfin, les instants A⁺ et D⁺ ont une relation d'égalité, c'est-à-dire une relation non-causale, qui indique que les objets A et D ont des durées qui garantissent leur terminaison au même instant. Nous pouvons donc voir que la terminaison de B cause la terminaison de A et C, que la terminaison de A cause la terminaison de B, mais que la terminaison de C ou de D n'a aucun effet sur la terminaison d'autres objets.

[Table des matières]

3.3 Les informations sur les objets média

Dans Madeus, les objets média représentent les entités actives qui s'exécutent et communiquent entre elles afin de réaliser la présentation globale d'un document multimédia. Un ensemble d'attributs est associé à chaque objet média. Ceux qui nous intéressent pour la présentation sont :

l'état d'exécution, qui peut être active, suspended ou terminated, ainsi que l'état d'avancement de la présentation, comme par exemple le numéro de l'image courante d'une vidéo,
la nature de l'objet, qui peut être de base ou composite,
les pointeurs vers les noeuds de l'hypergraphe correspondant aux instants de début et de fin de l'objet,
les dates nominales et effectives des instants de début et de fin de la présentation de l'objet,
les durées nominale, préférable et effective de l'objet,
la durée déjà passée de la présentation de l'objet.

Pendant la présentation d'un objet, les attributs comme l'état d'exécution, les dates effectives des instants de début et de fin et la durée effective de l'objet changent de valeur. La mise-à-jour de ces valeurs est effectuée par le gestionnaire d'objets et l'ordonnanceur.

[Table des matières]

3.4 La gestion du temps

La présentation d'un document multimédia est une séquence d'actions d'exécution appliquées sur des objets média, et effectuées aux instants déterminés par le scénario. Par conséquent, les objets qui subissent ces actions changent leur état d'exécution. L'état d'une présentation à un instant précis est défini par l'état des objets impliqués dans la présentation à cet instant. Nous avons donc besoin d'une structure qui puisse maintenir toutes les informations temporelles d'une présentation à un instant précis. Cette structure est appelée le contexte de présentation, et sera précisément définie dans la section 4.3. En gérant ces informations, nous pouvons accéder à l'état de présentation à tout instant afin de réaliser les fonctions de synchronisation et de navigation temporelle dans les documents multimédia.

Définition: Un instant significatif d'une présentation est un instant pendant lequel au moins un objet média subit une action d'exécution.

L'hétérogénéité des objets média rend l'utilisation d'une horloge globale difficile. En effet, les périodes entre les instants significatifs successifs, au niveau global du document, ne sont pas uniformes et dépendent des types d'objets joués. De plus, une horloge globale peut surcharger l'ordonnanceur, celui-ci devant s'occuper de la notification de chaque instant significatif aux objets concernés (voir la Fig 4 ). Dans Madeus, nous avons donc préféré que chaque objet gère sa propre horloge en décidant de ses propres instants significatifs. De plus, à chaque objet sont associées les fonctions qui réalisent les actions de son exécution (cf. la section 5) et l'ordonnanceur n'intervient qu'en cas de nécessité.

Dans Madeus, nous définissons deux types d'instants significatifs : les Tics de présentation et les Tacs de présentation dont les définitions suivent.

Fig 4. Les instants Tic d'une vidéo et d'une audio

Définition: Un Tic est un instant dans la vie de la présentation d'un objet média pendant lequel un ensemble d'actions d'exécution doit être effectué. Une présentation d'un scénario peut donc être considérée comme une séquence de Tics. Les Tics successifs sont séparés par un intervalle de temps calculé égal à la valeur minimale de temps requis pour jouer une unité d'un objet média. Par exemple, une image vidéo est jouée pendant une période de 40 msec, mais un échantillon d'audio est joué pendant une période de 125 musec. La Fig 4 illustre l'axe temporel de présentation décoré par la succession des Tics issus de l'horloge d'une vidéo et d'une audio.

Définition: Un Tac est le Tic auquel au moins un objet, de base ou composite, commence ou se termine. La Fig 5 schématise les instants Tac d'un scénario donné.

L'ordonnanceur n'intervient qu'aux instants Tics qui correspondent aux instants de début et de fin d'objets ainsi qu'aux instants qui demandent une notification pour la synchronisation fine (cf. 4.2). Il intervient également si nous avons besoin de naviguer à travers la présentation (cf. section 4.3) ou d'appliquer un algorithme de compensation qui prend en compte l'indéterminisme (cf. 4.4).

Fig 5. Les instants Tac d'un scénario

[Table des matières]

4 L'ordonnanceur de Madeus

L'ordonnanceur de Madeus présente la caractéristique réactive-prédictive. Il peut à la fois réagir aux événements reçus (réaction) et, grâce à l'hypergraphe, savoir comment la présentation doit se comporter dans l'avenir (prédiction) (cf. section II.3.4).

[Table des matières]

4.1 Organisation

L'organisation de l'ordonnanceur est décrite dans la Fig 6 . Celui-ci se compose d'un gestionnaire d'événements et de trois autres gestionnaires : le gestionnaire de synchronisation, le gestionnaire de la navigation temporelle et le gestionnaire de l'indéterminisme. Le gestionnaire d'événements de l'ordonnanceur filtre les événements engendrés par la présentation et les notifie au(x) gestionnaire(s) concerné(s). Ces différents composants sont décrits précisément dans la suite.

Fig 6. Organisation de l'ordonnanceur

[Table des matières]

4.2 Gestionnaire de synchronisation

Dans Madeus, le gestionnaire de synchronisation joue le rôle de maestro qui synchronise et décide quel objet ou quel ensemble d'objets doit être lancé à un instant donné. Dans cette section, nous allons discuter des principes de la gestion de synchronisation puis de sa mise en oeuvre dans Madeus.

[Table des matières]

4.2.1 Principes de gestion de la synchronisation

Dans Madeus, deux types de synchronisation sont réalisés : la synchronisation à gros grain qui définit la synchronisation entre les instants de début et/ou de fin des objets telle que définie dans le scénario, et la synchronisation fine qui est définie entre les unités composant les objets média synchronisés, intra-objet ou inter-objet, comme par exemple le lip-sync (cf. les sections II.2.5.1 et II.2.5.2).

Synchronisation à gros grain

Le gestionnaire de synchronisation utilise l'ensemble des informations fournies par le gestionnaire d'objets, l'hypergraphe, l'interface utilisateur et l'horloge système (cf. section 3). Ces informations aident le gestionnaire à prendre des décisions de synchronisation, comme par exemple lancer la présentation d'un ensemble d'objets simultanément, terminer la présentation d'un objet impliqué dans une relation causale, notifier périodiquement les objets liés par une synchronisation fine, etc.

Dans un hypergraphe, les objets entrant d'un même noeud du graphe ne terminent pas forcément leur présentation au même instant, malgré l'hypothèse posée lors de la création de l'hypergraphe stipulant que : « chaque noeud d'un hypergraphe cohérent représente un instant temporel de durée zéro » (voir la création d'hypergraphe en section III.4.2). Ceci est dû, en premier lieu, à la répartition non-uniforme des ressources entre les objets concurrents qui peut introduire des décalages entre les taux d'avancement de ces objets. Pour résoudre ce problème, plusieurs travaux sont en cours d'élaboration pour essayer de garantir une qualité de service d'une présentation multimédia [Barzilai 98] [Black 97] [Bourges 96] [Chu 97] [Nieh 97a]. En second lieu, supposons que les objets se terminent au même instant, leur terminaison est signalée et traitée par le gestionnaire de synchronisation de façon séquentielle. Le gestionnaire doit alors minimiser le temps correspondant aux traitements de la synchronisation inter-objet. La structure de l'hypergraphe fournie par Madeus permet au gestionnaire de synchronisation d'avoir une vue globale du scénario pour réduire le temps pris par ces traitements.

Synchronisation fine

La synchronisation fine est définie au niveau d'un seul objet ou entre deux objets qui sont fortement liés, comme par exemple un film qui se compose d'une vidéo et d'une audio. Donc, ce dernier type de synchronisation peut être géré soit de façon centralisée, soit de façon distribuée au niveau des objets synchronisés (voir Fig 7 ). Dans le premier cas, le gestionnaire s'occupe de signaler aux objets concernés de façon périodique qu'ils doivent s'aligner temporellement. Par contre, dans le deuxième cas, le gestionnaire de synchronisation désigne un objet comme un maître : c'est lui qui s'occupe de signaler aux autres objets considérés comme des esclaves qu'ils doivent s'aligner avec lui. L'objet audio est souvent choisi comme un maître parce qu'il ne tolère ni la perte de ses données, ni le changement de son taux de présentation, et exige que les autres objets s'adaptent à son taux effectif de présentation (voir SMIL [W3C 98b] et la notion de maître/esclave dans [Rousseau 98]).

Fig 7. Synchronisation fine : centralisée et distribuée

Dans Madeus, nous avons choisi le mode de gestion centralisée pour la synchronisation à gros grain qui nécessite la prise de décision au niveau global du document multimédia. Par contre, la gestion distribuée est choisie pour la synchronisation fine afin de minimiser la charge du gestionnaire. De plus, la structure des objets média s'adapte parfaitement avec ce type de gestion, parce que les fonctions qui réalisent la présentation de chaque objet média sont maintenues par l'objet lui-même, grâce à l'approche orientée objet adoptée par le gestionnaire d'objets (cf. 5).

[Table des matières]

4.2.2 La mise en oeuvre de la synchronisation à gros grain

L'exemple de la Fig 8 présente la mise en oeuvre du gestionnaire de synchronisation dans le cas d'une synchronisation à gros grain. La partie gauche de l'exemple représente l'hypergraphe correspondant aux relations A parmax B et A meets C. Pour jouer ce document, le gestionnaire fonctionne comme suit :

le gestionnaire consulte l'hypergraphe pour savoir quel est le noeud de début de la présentation ;
l'hypergraphe retourne un pointeur vers la structure du noeud qui représente le début de présentation (n1) ;
le gestionnaire de synchronisation demande au gestionnaire d'objets de créer tous les objets sortants du noeud n1, c'est-à-dire les objets A et B ;
le gestionnaire d'objets crée les objets A et B ;
le gestionnaire d'objets retourne l'identificateur des objets A et B au gestionnaire de synchronisation ;
le gestionnaire de synchronisation envoie alors aux objets A et B une commande pour démarrer leur présentation ;
si l'objet A arrive le premier à la fin de sa présentation, il signale alors sa terminaison au gestionnaire en passant le pointeur du noeud de sa fin (n2) ; en consultant la structure de n2, le gestionnaire sait qu'il y a une relation parmax entre l'objet A qui vient de terminer et l'objet B qui n'a pas encore terminé. Le gestionnaire prend alors la décision d'attendre la terminaison normale de l'objet B avant de lancer les objets sortants de ce noeud.
Le type de décision prise dépend, comme on l'a vu, du type de relation spécifiée entre les objets entrant dans le même noeud. Par exemple, si la relation entre A et B était un parmin au lieu de parmax, alors la décision serait la terminaison forcée de l'objet B et des processus associés ;
quand l'objet B arrive à la fin de sa présentation, il informe le gestionnaire de sa terminaison en lui passant le pointeur du noeud de sa fin (n2). Tous les objets entrant dans le noeud n2 sont donc maintenant terminés ;
le gestionnaire de synchronisation demande au gestionnaire d'objets de créer les objets sortant du noeud n2, c'est-à-dire l'objet C.

Cet exemple montre que grâce à la disponibilité des informations fournies par l'hypergraphe et la structure d'objets, le gestionnaire de synchronisation peut prendre ses décisions de façon immédiate.

Fig 8. Synchronisation centralisée à gros grain

Les relations de la synchronisation à gros grain que nous avons réalisées se divisent en deux classes : temporelle (comme les relations before, meets, overlaps, starts, during et equals) et causale (comme kills, parmin et parmax). Notre réalisation est fondée sur l'interprétation de l'ensemble de relations en hypergraphe. Le gestionnaire de synchronisation se charge de réaliser la coïncidence temporelle et la causalité entre les instants de début et/ou de fin des objets média à chaque noeud de l'hypergraphe.

Parfois, le gestionnaire de synchronisation ne peut pas garantir la coïncidence temporelle entre les instants de début d'un ensemble d'objets média à cause de l'insuffisance des ressources système et/ou des ressources réseau. Une solution est de précharger les objets média à l'avance. Le mode de préchargement dépend du type d'objet : discret ou continu. En effet, un objet média discret est préchargé par une seule requête d'accès, tandis que, pour un objet continu, le préchargement est effectué au niveau des composants de l'objet (comme un groupe d'images d'une vidéo ou un ensemble d'échantillons d'une audio). La technique de préchargement, par conséquent, exige l'allocation de tampons pour stocker les données média préchargées. Ainsi, un problème important, lié à la disponibilité de l'espace mémoire, se pose dans le cas où plusieurs objets média doivent être préchargés simultanément. Il est nécessaire de faire un compromis entre l'avantage de la technique de préchargement et la disponibilité de l'espace mémoire.

Pour un objet discret, la taille du tampon est égale à la taille de l'objet lui-même. Par contre pour un objet continu, la taille du tampon peut être mesurée en unité de temps aussi bien qu'en octets. Un tampon de Deltat secondes peut contenir une quantité de données qui peut être présentée pendant Deltat secondes. La taille correspondante en octets est

Taille (Deltat) = Deltat times (1/tau) times m

où : 1/tau est la taux de la présentation d'objet (unités/seconde), m est la taille maximum d'une unité (octet/unité).

Par exemple, un tampon d'une seconde pour une audio ayant un taux de présentation de 44100 échantillons/seconde (2 octets/échantillon) a une taille de 88.2 Kilooctets.

[Table des matières]

4.2.3 La mise en oeuvre de la synchronisation fine

La synchronisation fine comprend la synchronisation inter-objets comme le lip-sync ainsi que la synchronisation intra-objets qui se charge de minimiser, respectivement, les effets négatifs comme la dérive (skewing) entre- et la gigue (jittering) dans- les flux continus.

Synchronisation fine intra-objet

Le problème majeur à résoudre lors de la présentation des objets continus (comme la vidéo et l'audio) est de limiter les effets de gigue ; c'est-à-dire la différence entre le temps de présentation réel et le temps de présentation nominal pour chaque unité de l'objet continu (par exemple les images d'une vidéo ou les échantillons d'une audio) [Sharda 99] comme présenté au chapitre II en section II.2.5.1.

La technique de préchargement

Pour la synchronisation fine intra-objet, le gestionnaire utilise la même technique de préchargement que celle utilisée pour la synchronisation à gros grain présentée dans la section précédente. Pour un objet audio non compressé et stocké localement, la Fig 9 montre la valeur de la gigue en fonction du temps pour trois tailles différentes du tampon (4, 25 et 40 millisecondes). La valeur de la gigue d'une unité média est égale à la différence entre la date à laquelle elle est disponible dans le tampon et prête pour la présentation, et la date nominale de sa présentation. La valeur négative de gigue, soit -t, indique que l'unité média est bien disponible dans le tampon t unités de temps avant sa date nominale de présentation. Par contre, la valeur positive de gigue, soit t, indique que l'unité média est présentée t unités de temps après sa date nominale. La Fig 10 montre que l'augmentation de la taille du tampon de préchargement augmente la valeur négative de la gigue et, par conséquent, augmente la disponibilité des unités média avant leur présentation. Il faut donc choisir une taille de tampon qui garantit que les valeurs de la gigue soient toujours négatives et, par conséquent, les échantillons audio soient toujours disponibles avant leur présentation.

Dans le système d'exploitation Unix, l'augmentation de la charge du cpu, c'est-à-dire le nombre des processus actifs qui partagent le cpu, a un effet majeur en augmentant la valeur positive de la gigue. La raison pour cela est que le système Unix est un système de type best effort qui essaie de faire son mieux pour partager le cpu entre les processus actifs de façon juste, sans considérer les contraintes temporelles de ces processus. L'ordonnanceur de processus dans Unix utilise la stratégie de partage du temps en donnant à chaque processus un quantum de temps dans le cpu. À la fin de chaque quantum, le processus servi par le cpu libère sa place afin qu'un autre processus puisse s'en servir. Quand le nombre de processus actifs augmente, le délai entre deux quanta de temps consécutifs pour le même processus augmente donc et, par conséquent, les processus prennent plus longtemps pour finir leur exécution.

Fig 9. La gigue d'une audio en fonction du temps

Fig 10. La valeur moyenne de gigue en fonction de la taille du tampon audio

Pour un objet audio non compressé et stocké localement, nous avons trouvé qu'une valeur de 40 millisecondes est suffisante pour assurer une bonne présentation quelque soit la charge de cpu. Par contre, pour un objet vidéo compressé (format MPEG-1), le problème est plus important, même si l'objet est stocké localement.

Image
Plot_jitter_V_NOSYNC_NODROP_NOLOAD.gif

Fig 11. La gigue d'une vidéo avec une faible charge du cpu

La Fig 11 montre la gigue d'une vidéo de format MPEG-1 ayant un taux de présentation de 15 images/seconde et un nombre total d'images de 1272. Dans cette expérimentation, le cpu était chargé faiblement par 2 processus et son pourcentage d'utilisation était égal à 53%. La valeur de la gigue est largement acceptable : elle ne dépasse pas +20 msec. Par contre, quand l'utilisation de cpu atteint 100%, c'est-à-dire que le cpu est saturé et toujours occupé par un processus, l'effet de l'augmentation de la charge est dramatique. La Fig 12 montre la gigue de la même vidéo mais avec une charge de 3, 4 et 5 processus, et une utilisation du cpu égale à 100%. Nous pouvons voir que la gigue des vidéos augmente de façon linéaire et peut atteindre respectivement les valeurs 13, 37 et 85 secondes pour les valeurs de charge 3, 4 et 5. Par conséquent, la durée des vidéos augmente avec l'augmentation de charge. La raison en est que le processus de la décompression vidéo est gourmand en cpu mais que le cpu est saturé, c'est-à-dire utilisé à 100%. Dans ce type de situation, on constate une forme de gigue particulière, caractérisée par le fait que chaque image a donc une gigue positive qui s'accumule avec le temps et cette gigue augmente avec l'augmentation de la charge du cpu. Il est évident que pour les charges importantes, la solution de préchargement seul n'est pas suffisante, parce que cela nécessite l'allocation d'un tampon ayant une taille égale à la valeur maximale de la gigue positive. Cette taille peut atteindre des valeurs supérieures à 10 Moctets.

Fig 12. La gigue d'une vidéo avec des charges différentes du cpu

La technique de saut d'images

Afin de résoudre le problème présenté ci-dessus, nous proposons l'utilisation de la technique de saut d'images d'un objet vidéo. La technique est présentée dans la Fig 13 . Elle consiste à calculer la valeur de gigue pour chaque image (lignes 7-12). Il faut noter que la variable t_début est la date de début de la présentation de la vidéo, la variable t_pres est la date limite de présentation de l'image courante et la variable t_actuel est le temps actuel donné par l'horloge système. Si la valeur de gigue est inférieure à la valeur de gigue acceptable Delta_gigue, l'image est décompressée et affichée (lignes 13-15). Afin de prendre en compte le délai ajouté par les processus de la décompression et de l'affichage d'image, nous re-calculons la valeur de la gigue par rapport à l'instant actuel, c'est-à-dire le temps qui reste jusqu'à l'instant t_pres (lignes 16-18). Pour une valeur négative de gigue, c'est-à-dire lorsque l'image est en avance, le processus est bloqué pour une période égale à la valeur absolue de la gigue (lignes 19-24). Par contre, si la valeur de gigue (calculée en ligne 12) est positive et supérieure à la valeur de gigue acceptable Delta_gigue, nous n'effectuons pas la décompression de cette image et nous la sautons pour traiter l'image suivante (lignes 25-27). Il faut noter que le délai introduit par la décompression et l'affichage d'une image est simplement reporté sur le calcul de la gigue de l'image suivante.

Jouer_Video () {

1. /* Initialiser le compteur d'images pourque t_pres

2. définisse la date limite de présentation de l'image 3. courante */ 4. numéro_image = 1 5. /* Boucle de décompression et de présentation */ 6. Pour chaque image in vidéo { 7. /* Calculer la date de la présentation de l'image 8. en fonction du numéro de l'image et le taux de 9. présentation de la vidéo */ 10. t_pres = t_début + numéro_image/taux_de_présentation 11. /* Claculer la valeur de gigue */ 12. gigue = t_actuel - t_pres 13. Si (gigue < Delta_gigue) { 14. Décompresser_Image () 15. Afficher_Image () 16. /* Calculer le temps qui reste jusqu'à 17. l'instant t_pres */ 18. gigue = t_actuel - t_pres 19. Si (gigue < 0) { 20. /* Bloquer le processus pour un délai égal à 21. ((-1) * gigue) unité de temps, c'est-à-dire 22. jusqu'à la date de la présentation t_pres */ 23. Bloquer_Processus ((-1) * gigue) 24. } 25. } Sinon { 26. /* Il est trop tard : Sauter cette image */ 27. } 28. numéro_image = numéro_image + 1 29. } }

Fig 13. La boucle de l'affichage d'une vidéo avec le saut d'images

Dans le format MPEG que nous utilisons, la succession d'images dans une séquence vidéo est exploitée afin de réduire l'information nécessaire pour reconstituer l'ensemble de la séquence : c'est le principe de la compression vidéo Mpeg [Legall 91]. Le format Mpeg tire profit des similarités entre les images d'une séquence vidéo, par prédiction et interpolation (voir la Fig 14 ), afin de réduire la redondance de l'information contenue dans ces séquences. La compression crée ainsi de nouvelles dépendances entre les différentes unités de présentation liées uniquement à leur encodage. La compression produit trois différents types d'images :

image de type I (Intra frames) : Elle est compressée en utilisant seulement les informations existantes dans l'image lui-même. Ce type d'images représente des points d'accès potentiels dans le flot vidéo compressé.
image de type P (Predicted frames) : Elle est compressée en utilisant comme référence la précédente plus proche image de type I ou P. Ce type de codage est appelé prédiction unidirectionnelle (voir la Fig 14 a). Comme l'image de type I, une image de type P peut servir comme référence de prédiction pour les images de type P et B.
image de type B (Bidirectional frames) : Dans sa compression, elle utilise deux images comme références de prédiction : la précédente et la suivante plus proches images de type I et/ou P. Ce type de codage est appelé prédiction bidirectionnelle ou interpolation (voir la Fig 14 b).

Celles-ci sont très importantes à considérer pour appliquer la technique du saut d'images. En effet, avec le format MPEG le contenu de certaines images (images de type B ou P dans le codage) ne peut être reconstitué que si leur image de référence (images de type I ou P dans le codage) a été préalablement traitée (voir la Fig 14 ). La succession des images I, P, et B pour une MPEG est définie par un motif ou pattern comme IBBPBBPBBPBB...

Fig 14. L'interdépendance dans le codage MPEG

Avant de sauter une image MPEG, il faut donc garantir que toutes les images qui en dépendent sont également sautées. La technique de saut d'images commence par sauter d'abord les images de type B, puis le type P et enfin le type I. Nous avons expérimenté la technique de saut d'images avec le clip vidéo présenté précédemment dont le pattern est IBBPBBPBBPBBPBB. Nous avons appliqué une stratégie simple qui consiste à sauter les images de type B seulement. La Fig 15 et la Fig 16 montrent respectivement la gigue produite en appliquant la technique de saut d'images pour les charges de 5 et 3 avec une utilisation du cpu égale à 100%. En comparaison avec la Fig 12 , nous pouvons voir une nette amélioration par rapport à la valeur de gigue.

Image
plot_jitter_V_NOSYNC_DROP_LOAD3.gif

Fig 15. La gigue d'une vidéo utilisant le saut d'images (utilisation du cpu = 100%, charge du cpu = 5)

Le tableau de la Fig 17 montre une comparaison entre les valeurs de gigue (moyenne, minimum, maximum et pourcentage de gigue inférieur à 10 msec) sans et avec la technique de saut d'images sous différentes utilisations et charges de cpu. Nous pouvons voir que pour une faible charge (charge égale à 2 et utilisation égale à 53%), les valeurs de gigue sans et avec le saut d'images sont égales. La différence devient sensible quand le cpu commence à se saturer, c'est-à-dire une utilisation proche de 100%. Grâce à la technique de saut d'images, la valeur maximale de gigue reste inférieure à 0.85 seconde. De plus, le pourcentage de temps pendant lequel la gigue est inférieure à 10 millisecondes reste raisonnable (83.66% pour une charge égale à 3 et 23.84% pour une charge égale à 4).

Image
plot_jitter_V_NOSYNC_DROP_LOAD.gif

Fig 16. La gigue d'une vidéo utilisant le saut d'images (utilisation du cpu = 100%, charge du cpu = 3)

Fig 17. Tableau de comparaison des valeurs de gigue sans et avec le saut d'images d'une vidéo

La synchronisation fine intra-objet est la première étape pour réaliser la synchronisation fine inter-objet (synchronisation des lèvres). En effet, si on garantit que chaque objet continu respecte sa vitesse de présentation préspécifiée, alors la synchronisation fine entre ces objets devient plus facile à réaliser.

Synchronisation fine inter-objet

Pour la synchronisation fine inter-objets, le gestionnaire génère périodiquement un signal d'alarme afin de signaler aux objets synchronisés qu'ils doivent s'aligner temporellement l'un par rapport à l'autre pour réduire à zéro la valeur de dérive entre ces objets. La période entre deux signaux d'alarme consécutifs est appelée la période de notification de synchronisation Delta_sync. La valeur de cette période est égale à la période nécessaire pour jouer un nombre entier d'unités composant les objets synchronisés, tels que les images d'une vidéo ou les échantillons d'une audio. Dans l'application de visioconférence PNSVS [Owezarski 98], la valeur de Delta_sync est calculée en fonction de la valeur du seuil acceptable pour la dérive et la plus grande valeur de la gigue exercée par les unités composants les objets synchronisés. Dans cette étude, Owezarski a considéré un exemple d'un clip vidéo (10 images/seconde) lié par une relation lipsync avec un clip audio. Supposons que :

l'unité de base pour la vidéo soit une image dont la durée (Delta_unité) est égale à 100 millisecondes),
l'unité de base pour l'audio soit un ensemble d'échantillons ayant la même durée qu'une unité vidéo (Delta_unité), c'est-à-dire 100 millisecondes,
les bornes de gigue [Min_gigue, Max_gigue] pour chaque unité vidéo ou audio sont égales à [-10, +10] millisecondes,
la valeur du seuil acceptable pour la dérive (Delta_dérive) entre la vidéo et l'audio est égale à 100 millisecondes.

Donc, la plus grande valeur de dérive entre une unité vidéo et une unité audio (Max_gigue - Min_gigue) est 20 millisecondes et, pour 5 unités consécutives, elle peut monter jusqu'à 100 millisecondes. Alors, le choix d'une période de synchronisation Delta_sync égale à la période de 5 unités, c'est-à-dire 500 millisecondes, peut restreindre la dérive inférieure à la valeur maximum, c'est-à-dire 100 millisecondes. Autrement dit, la valeur de Delta_sync est calculée comme suit :

Delta_sync = Delta_unité times Delta_dérive / (Max_gigue - Min_gigue)

Il est évident que la période de la synchronisation Delta_sync est inversement proportionnelle à la différence entre la borne maximale et la borne minimale de la gigue (Max_gigue - Min_gigue) pour la même valeur du seuil de dérive Delta_dérive.

La difficulté de cette démarche est qu'elle suppose l'existence de techniques par lesquelles nous pouvons mesurer les bornes de la gigue [Owezarski 98]. En effet, les bornes de la gigue changent constamment de façon aléatoire et, par conséquent, il est possible que les valeurs de gigue mesurées pendant un intervalle de temps ne soient pas valables pour l'intervalle qui suit.

Dans Madeus, nous avons utilisé le principe décrit dans [Owezarski 98] pour calculer la période de synchronisation et l'avons adapté à notre approche de gestion distribuée. Nous avons fixé les bornes de gigue égales à [-10, 10] millisecondes. La durée Delta_unité représente la durée d'une unité du maître de la synchronisation.

Algorithme de la synchronisation fine inter-objet

L'algorithme de la synchronisation fine entre un flux audio (maître) et un flux vidéo (esclave) est le suivant (voir la Fig 18 ) :

du côté gestionnaire, il calcule une valeur pour la période de la synchronisation Delta_sync selon la méthode décrite ci-dessus, et il l'envoie au maître,
du côté maître, à tout instant t = t_début+ n*Delta_sync unités de temps (n = 0, 1, 2,...), il envoie à l'esclave un message contenant le numéro de l'échantillon audio en cours de présentation et le taux de présentation afin que l'esclave s'aligne temporellement avec lui. Le message contient un estampille de temps (t_ei) indiquant le temps de l'envoie de message,
du côté esclave, à chaque instant de réception (t_ri) du signal de maître, il calcule, pour lui et le maître, l'instant actuel de leur présentation en fonction du numéro de l'unité en cours de présentation et du taux de présentation, comme suit : t_esclave= esclave.numéro_image_courant /esclave.tauxt_maître= maître.numéro_échantillon_courant / maître.tauxEnsuite, il calcule la valeur de la dérive entre lui et le maître en tenant compte du délai de communication delta_com, c'est-à-dire le délai entre les instants de l'envoie (t_ei) et de la réception (t_ri) du message de synchronisation. delta_com = t_ri - t_eidérive = t_esclave- t_maître-delta_com
Si(dérive>Delta_dérive), c'est-à-dire si l'esclave est en avance, alors l'esclave doit se bloquer pour une durée égale à dérive unité de temps,
Si(dérive< -Delta_dérive), c'est-à-dire si l'esclave est en retard :
- alors l'esclave doit appliquer une des techniques de l'adaptation. Pour une vidéo, l'adaptation peut être faite en appliquant la technique de saut d'images, c'est-à-dire en n'affichant pas l'image courante mais celle qui la suit.
- si l'esclave ne supporte pas les techniques de l'adaptation, alors il demande au maître de se bloquer pour une durée égale à (-dérive) unité de temps afin de s'aligner avec lui. Cette solution n'est pas recommandée si le maître est un objet audio, parce que le son produit sera discontinu et le message audio deviendra incompréhensible.

Fig 18. Les communications effectuées pendant la synchronisation fine

Il faut noter que si le maître présente une gigue très faible, nous pouvons appliquer cet algorithme en utilisant une valeur égale à l'infini pour Delta_sync. Dans ce cas, le maître envoie un seul signal de synchronisation à l'esclave au début de la présentation afin de synchroniser le début des deux objets (les instants t_e0 et t_r0 dans la Fig 18 ). Ensuite, nous utilisons la technique de la synchronisation intra-objet pour chacun des objets (voir la synchronisation intra-objet au début de cette section).

L'algorithme de la synchronisation inter-objet peut être appliqué pour synchroniser deux vidéos sans aucune modification.

Maintenant, nous présentons une expérimentation de la synchronisation fine entre deux objets :

une audio au format AU, avec un taux de présentation de 8000 échantillons/seconde, et une taille de 1 octet/échantillon,
une vidéo au format MPEG-1, avec un taux de présentation de 15 images/seconde, une taille d'image de 320x240 pixels/image, 1 octet/pixel, et un nombre total d'images égale à 1272.

Les paramètres de l'expérimentation sont les suivants :

le maître est l'objet audio, soit Delta_unité égale à 40 millisecondes, et l'esclave est l'objet vidéo,
la valeur maximale de la dérive acceptable Delta_dérive est égale à 100 millisecondes,
les bornes de la gigue acceptable sont égales à -10 et 10 millisecondes.

Donc, la valeur calculée de Delta_sync est égale à 200 millisecondes. La Fig 19 et la Fig 20 montrent respectivement la dérive produite en appliquant l'algorithme de la synchronisation fine pour les charges 5 et 3 avec une utilisation du cpu égale à 100%. Le tableau de la Fig 21 montre les valeurs de dérive (moyenne, minimum, maximum et pourcentage de dérive inférieur à 100 msec) sous différentes utilisations et charges du cpu. Nous pouvons voir que pour une faible charge (charge égale à 2 et utilisation égale à 53%) la dérive est toujours inférieure à 100 msec. Quand le cpu commence à se saturer, c'est-à-dire pour une utilisation proche de 100%, la dérive augmente. Pourtant, grâce à l'algorithme de synchronisation fine inter-objet et à la synchronisation intra-objet, la moyenne de la dérive reste inférieure à 0.27 seconde. De plus, le pourcentage de temps pendant lequel la dérive est inférieure à 100 millisecondes reste raisonnable (86.79% pour une charge égale à 3 et 26.01% pour une charge égale à 4).

Fig 19. La dérive entre une audio et une vidéo liées par une synchronisation fine (Delta_dérive = 0.1 seconde, Delta_sync = 0.2 seconde) (utilisation du cpu = 100%, charge du cpu = 5)

Fig 20. La dérive entre une audio et une vidéo liées par une synchronisation fine (Delta_dérive = 0.1 seconde, Delta_sync = 0.2 seconde) (utilisation du cpu = 100%, charge du cpu = 3)

Fig 21. Performance de l'algorithme de la synchronisation fine sous différentes conditions de charge du cpu

La Fig 22 montre la variation de la dérive entre une audio et une vidéo en variant la charge de cpu. Pendant la période entre 0 et 44 secondes, le système est surchargé par une utilisation de 100 % et une charge de 12 et 8. Nous pouvons voir que la dérive augmente de façon linéaire à cause du fait que le saut des images de type B seulement n'est pas suffisant pour assurer une valeur acceptable pour la dérive. Une solution à ce problème est de commencer à sauter les images de type P et puis les images de type I. Pourtant, l'augmentation du nombre d'images sautées peut diminuer la qualité de perception de la vidéo par l'utilisateur. À partir de l'instant pour lequel la charge diminue jusqu'à 4, la vidéo rattrape rapidement son retard par rapport à l'audio et la valeur maximale de la dérive dévient 0.4 seconde. De plus, quand la charge diminue jusqu'à 2, la valeur maximale de la dérive devient 0.07 seconde. Cette expérimentation montre la capacité de la technique de synchronisation fine à limiter la dérive sous différentes charge du cpu.

Image plot_skew_SYNC_200_DROP_LOAD_VARIATION.gif

Fig 22. La dérive sous une charge variable du cpu

[Table des matières]

4.3 Gestionnaire de la navigation temporelle

Le gestionnaire de la navigation temporelle interprète les commandes de navigation lancées par l'utilisateur pour lui permettre de se déplacer temporellement à travers les documents multimédia. Afin de réaliser les différentes fonctions de la navigation temporelle, le gestionnaire utilise une structure nommée contexte de présentation. Dans cette section, nous définissons cette structure de contexte de présentation et les opérations effectuées sur celle-ci. Nous décrivons enfin la mise en oeuvre des opérations de navigation temporelle de l'environnement Madeus.

Dans la mise en oeuvre de la navigation temporelle, nous avons négligé l'indéterminisme des durées des objets incontrôlables. La raison en est que l'indéterminisme n'a aucun sens dans le contexte de la navigation temporelle. En effet, l'existence d'un objet incontrôlable à la destination d'un hyperlien n'a aucun effet sur le calcul du contexte de présentation à cet instant parce que l'effet d'indéterminisme d'un objet incontrôlable n'apparaît qu'à la présentation effective de cet objet.

[Table des matières]

4.3.1 Contexte de présentation

Le contexte de présentation à un instant donné représente les objets de base actifs à cet instant ainsi que l'état d'avancement de leur présentation.

Définition: Le contexte de présentation à un instant donné d'un scénario donne toutes les informations nécessaires pour reconstituer la présentation de ce scénario à partir de cet instant. Cet instant peut être un instant passé, présent ou futur par rapport à l'instant courant de la présentation. Considérons un contexte de présentation à un instant t, sachant que l'instant t_o = 0 correspond à l'instant de début de présentation. Nous sommes intéressés à savoir quels sont les objets qui doivent être en cours de présentation à cet instant et, pour chacun de ces objets, quel est l'état d'avancement de sa présentation. L'état d'avancement de la présentation d'un objet est représenté par l'attribut offset dont la valeur est la différence entre l'instant t et l'instant de début de l'objet.

Le contexte courant de présentation d'un scénario S à l'instant actuel est une liste dont les items sont les objets de base actuellement dans l'état actif avec leurs valeurs offset. Le contexte courant est défini par la fonction CP_actuel comme suit :

CP_actuel(S) = {(Objet, Offset (Objet)) / (Objet in S)
              et (Nature (Objet) = BASIC)
              et (Date_effective_de_début (Objet) <= temps_actuel)
              et (Date_nominale_de_fin (Objet) > temps_actuel)
              et (Offset (Objet) = temps_actuel - Date_effective_de_début (Objet)) }

On peut de même calculer le contexte de présentation de tout instant t en utilisant la date nominale du début des objets, calculée par le formateur statique, au lieu de la date effective, comme suit :

CP_t(S) = {(Objet, Offset (Objet)) / (Objet in S)
               et (Nature (Objet) = BASIC)
               et (Date_nominale_de_début (Objet) <= t)
               et (Date_nominale_de_fin (Objet) > t)
               et (Offset (Objet) = t - Date_nominale_de_début (Objet)) }

L'ordonnanceur utilise la solution temporelle calculée par le formateur statique pour déterminer, si besoin, le contexte de présentation CP_t d'un instant t. Ainsi, pour évaluer CP_t, nous utilisons :

les informations de la structuration logique et hiérarchique du document maintenues dans l'hypergraphe,
les informations temporelles des dates de début et de fin de chaque objet calculées par le formateur statique (comme Date_nominale_de_début, etc.),
les informations de l'état (actif ou non) et de la nature des objets (BASIC ou COMPOSITE).

À partir de ces informations, le temps écoulé de la présentation d'un objet à un instant t peut être calculé dynamiquement par l'ordonnanceur, comme décrit dans la section 4.3.2.

[Table des matières]

4.3.2 Manipulation du contexte de présentation

Les opérations sur le contexte de présentation qui doivent être effectuées par le gestionnaire sont les suivantes :

la mise à jour du contexte courant : le contexte courant de présentation d'un document en cours de présentation est mis à jour fréquemment. La fréquence de la mise à jour dépend de la granularité de temps qu'on utilise pour exécuter les actions de présentation. Ainsi, chaque fois que la présentation franchit un instant Tic (cf. la section 3.4), une ou plusieurs actions de présentation sont effectuées aboutissant au changement de l'état d'au moins un objet et, par conséquent, à la mise à jour du contexte de présentation ;
la sauvegarde et la restauration : quand un hyperlien est activé, le contexte courant de présentation à l'instant d'activation doit être sauvegardé. Ce contexte de présentation peut être restauré pour continuer le scénario original après le retour de la destination d'hyperlien. Les contextes de présentation sauvegardés sont maintenus dans une pile dans laquelle le dernier contexte sauvegardé (ou empilé) est le premier à restaurer (ou dépiler) ;
le calcul : quand nous avons besoin de sauter à travers le scénario vers un instant dans le futur ou dans le passé (à cause d'une activation d'un hyperlien intra-document par exemple), le contexte de présentation correspondant à cet instant doit être calculé. La valeur d'offset, associée avec chaque objet actif dans la structure du contexte de présentation, est interprétée par l'objet en termes des unités qui le composent. Par exemple, un offset de valeur 3.5 secondes d'une vidéo, ayant un taux de présentation de 15 fps, correspond à l'image numéro 53 (~ 3.5x15) dans le flot. De même, l'offset peut être interprété en termes d'une position sur l'écran pour un objet qui se déplace au fil du temps.

[Table des matières]

4.3.3 Mise en oeuvre des opérations de navigation

Les informations maintenues par la structure du contexte de présentation pour un instant donné sont suffisantes pour commencer la présentation à partir de n'importe quel instant du scénario. Cette structure peut donc aider à réaliser la navigation temporelle à travers des documents multimédia. Le principe est simple : considérons l'instant courant d'une présentation multimédia où un objet actif A est défini comme une ancre source pour un hyperlien dont l'ancre destination est l'instant de début d'un objet B. Quand cet hyperlien est activé à un instant t, l'opération de navigation est effectuée en passant par les étapes suivantes :

sauvegarder le contexte actuel de présentation (CP_t) dans la pile du contexte de présentation ;
stopper la présentation, et libérer ensuite les ressources allouées ;
calculer le contexte de présentation correspondant à l'instant de début de B (CP_B) en utilisant les informations de l'hypergraphe ;
mettre à jour le contexte actuel de présentation en lui affectant le contexte calculé CP_B puis, reprendre la présentation. La présentation commence à partir de l'instant de début de B ;
dès que la présentation de la destination de l'hyperlien est terminée, le contexte CP_t peut être restauré à partir de la pile et utilisé comme le contexte courant de présentation. Par conséquent, la présentation peut être reprise à partir de l'instant t.

La Fig 23 montre une des solutions possibles pour le document multimédia présenté dans la section III.4.3.2 du chapitre 3. L'objet Lien-Extrait est une ancre source d'un hyperlien dont l'ancre destination est l'objet Extraits. Supposons que nous activons cet hyperlien à l'instant t=8. Le contexte actuel de présentation (CP_t=8) est :

CP_t=8 = {(Titre, 8), (Lien-extrait, 8), (Musique, 8), ( Générique, 8)},

et le contexte de présentation de l'ancre destination (CP_Extraits ≡CP_t=69) est :

CP_Extraits = {(Titre, 69), (V₁, 0), (A₁, 0)}

Fig 23. Hypergraphe temporisé

Les instants Tic et Tac peuvent aussi être utilisés comme des ancres de destination pour lesquelles les contextes de présentation sont calculés. Des opérations variées de navigation peuvent être utilisées en utilisant les instants successifs de Tic et Tac comme des ancres destination. Nous avons défini trois types de navigation par Tic et/ou Tac :

1) La navigation pas à pas

L'utilisateur peut demander de sauter de l'instant actuel vers le plus proche instant Tac (dans l'avenir aussi bien que dans le passé) ; dans ce cas, à l'aide d'un bouton défini explicitement dans l'interface utilisateur, l'utilisateur peut aller et venir rapidement à travers le scénario, sans avoir besoin d'attendre la présentation pour arriver au point désiré avec la vitesse normale de la présentation. En faisant cela, le parcours de la navigation est défini comme l'ensemble de Tacs calculé et ordonné par Madeus. Par exemple, l'hypergraphe de la Fig 23 possède neuf instants de Tac dont les contextes de présentation en ordre temporel sont comme suit (les délais sont notés par deltai) :

CP_Tac1 = {(Titre, 0), (Lien-extrait, 0), (Musique, 0), (Générique, 0)},
CP_Tac2 = {(Titre, 20), (Lien-extrait, 20), (Musique, 20), (delta1, 0)},
CP_Tac3 = {(Titre, 27), (Lien-extrait, 27), (Musique, 27), (Audio, 0), (Image, 0), (Texte, 0)},
CP_Tac4 = {(Titre, 62), (Lien-extrait, 62), (Musique, 62), (delta2, 0)},
CP_Tac5 = {(Titre, 65), (delta2, 3)},
CP_Tac6 = {(Titre, 69), (V₁, 0), (A₁, 0)},
CP_Tac7 = {(Titre, 94), (V₂, 0), (A₂, 0)},
CP_Tac8 = {(Titre, 134), (V₃, 0), (A₃, 0)},
CP_Tac9 = emptyset (l'instant de la fin de la présentation).

2) La navigation structurale

La navigation structurale permet à l'utilisateur de naviguer à travers la hiérarchie de la structure logique du document au moyen d'une vue logique fournie par Madeus. L'utilisateur peut donc choisir l'objet à présenter et le gestionnaire de navigation détermine l'instant Tac correspondant au début de cet objet. Par exemple, si l'utilisateur choisit l'objet Histoire, le gestionnaire utilise CP_Tac3 comme contexte actuel de présentation.

3) La navigation définie par l'auteur et/ou le lecteur

Un auteur et/ou un lecteur peut sélectionner un groupe d'instants de présentation, i.e. des instants Tics et/ou Tacs, qui lui semblent intéressants, et les utiliser comme des ancres fonctionnelles de navigation. Par exemple, les instants de la première apparition de la vedette de film pendant les extraits E₁, E₂ et E₃. Le lecteur peut également choisir l'ancre destination de façon relative par rapport à un instant donné. Par exemple, Deltat secondes après le début du document, avant la fin du document ou après l'instant actuel de la présentation.

Discussion

Le contexte de présentation que nous avons présenté est utilisé pour gérer deux types d'ancre de navigation temporelle :

l'ancre de navigation déterminé par l'auteur et/ou le lecteur en fonction du sujet présenté par le scénario. Dans ce cas, l'ancre source et l'ancre destination sont des objets faisant partie du scénario. La navigation structurelle et la navigation définie par l'auteur et/ou le lecteur utilisent ce type d'ancre,
l'ancre de navigation qui sert à définir le parcours d'exploration d'un scénario de façon indépendante du sujet présenté. Dans ce cas, l'ancre de destination est calculée par le système Madeus et l'activation de lien est effectuée à travers des boutons spécifiques au niveau de l'interface utilisateur. La navigation pas à pas utilise ce type d'ancre.

Nous pouvons conclure que le concept du contexte de présentation, que nous avons défini ci-dessus, représente la base pour réaliser les différents types de navigation.

[Table des matières]

4.4 Gestionnaire dynamique de l'indéterminisme

Un document multimédia contient souvent des objets incontrôlables caractérisés par leur durée indéterministe, comme un bouton d'interaction et un flot vidéo ou audio subissant les délais d'accès distant. L'existence de ce type d'objets au sein d'un scénario perturbe la synchronisation de la présentation du document. En effet, il devient plus difficile de vérifier statiquement la cohérence du document et d'assurer lors de la présentation du document un formatage dynamique des objets qui permettent de respecter le scénario spécifié.

Dans cette section, nous présentons les propriétés d'un scénario temporel, qui peuvent être exploitées par le gestionnaire pour gérer l'indéterminisme (section 4.4.1). Ensuite, nous présentons deux techniques complémentaires, adoptées par Madeus, pour la compensation de l'indéterminisme. La première technique vérifie statiquement si le gestionnaire peut garantir une compensation pour l'indéterminisme pendant la présentation (section 4.4.2). La deuxième technique est appliquée afin de compenser dynamiquement l'indéterminisme en utilisant une technique d'ajournement des dates (section 4.4.3).

[Table des matières]

4.4.1 Flexibilité et contrôlabilité

D'après les deux types d'intervalles : contrôlable et incontrôlable (voir la section III.2.2.1), nous pouvons distinguer deux propriétés qui caractérisent le scénario temporel d'un document multimédia [Layaïda 96b] : la flexibilité et la contrôlabilité.

La flexibilité mesure l'aptitude d'un scénario temporel à pouvoir être adapté aux contraintes numériques induites par les spécifications de l'auteur tout en garantissant sa cohérence globale. La flexibilité d'un scénario dépend de l'élasticité des objets média (définie par la différence entre la borne supérieure et la borne inférieure de leur durée contrôlable) présents dans le document ainsi que de leur emplacement dans l'hypergraphe.

Cette flexibilité du document peut être mise à profit pour compenser le comportement indéterministe de sa présentation. Cela introduit la notion de contrôlabilité qui mesure l'aptitude d'un scénario à pouvoir être adapté dynamiquement, à l'exécution, au comportement indéterministe des objets média qu'il contient. Il s'agit donc d'une généralisation de la notion de cohérence pour les scénarios indéterministes.

Dans les sections suivantes, nous présentons les techniques qui utilisent ces deux propriétés afin de gérer l'indéterminisme.

[Table des matières]

4.4.2 Vérification statique de la contrôlabilité

Dans [Layaïda 96b], nous avons proposé une technique pour la vérification statique de la contrôlabilité d'un scénario qui contient des objets incontrôlables, c'est-à-dire la possibilité de compenser un scénario qui contient des objets incontrôlables. Cette technique est fondée sur une vérification au cas par cas qui s'appuie sur la structure du graphe [Layaïda 97]. L'objectif est de traiter ces différents cas selon leur ordre de difficulté et de ramener le graphe à une représentation qui comporte uniquement des objets contrôlables. Nous avons identifié trois cas que nous pouvons traiter.

Cas 1

Le premier cas correspond aux situations dans lesquelles la présence d'un objet incontrôlable n'est pas gênante : cet objet n'affecte pas les autres contraintes spécifiées par l'auteur. Un tel cas est illustré dans la Fig 24 .

Fig 24. Exemple du Cas 1

Dans cet exemple, le graphe peut être subdivisé en deux sous-graphes G1 et G2 qui ne sont reliés que par une chaîne contenant l'objet incontrôlable (Chaîne d'articulation). Ce genre de cas se présente dans des scénarios où, par exemple, le passage entre deux parties est effectué par l'activation d'un élément de type bouton, de durée incontrôlable. Dans une telle configuration, il est clair que quelle que soit la valeur effective de durée prise par cet objet, la cohérence du graphe n'est pas remise en question.

Cas 2

Le deuxième cas correspond à des situations dans lesquelles l'objet incontrôlable se trouve sur une chaîne dont l'extrémité droite correspond à un point d'articulation. C'est-à-dire un noeud du graphe tel que toutes les chaînes précédentes aboutissent à ce noeud. Autrement dit, cet objet ne remet pas en cause les autres contraintes spécifiées par l'auteur, à l'exception des contraintes de coïncidence temporelle, telles que celles des chaînes B et D avec la chaîne incontrôlable X dans la Fig 25 .

Fig 25. Exemple du Cas 2

Dans cet exemple, le graphe peut être subdivisé en deux sous-graphes G1 et G2 qui ne sont reliés que par l'instant de fin de la chaîne contenant l'objet incontrôlable X (le point d'articulation est X⁺). Ce type de situation ne peut être cohérent que si les chaînes B et D sont flexibles par la fin, comme le sont des éléments discrets (image ou texte). Dans ce cas, la terminaison de la chaîne X provoque la terminaison des deux autres chaînes contenant B et D. Nous nous ramenons donc au cas 1 moyennant cette simple vérification.

Cas 3

Le dernier cas consiste à vérifier, pour chaque instant permettant d'observer la durée d'un objet incontrôlable, s'il est possible de le compenser. La compensation repose sur l'utilisation de la flexibilité des éléments contrôlables dont les instants de début ou de fin se trouvent dans l'avenir par rapport à cet instant. Ces instants sont appelés les points de recouvrement. Soit par exemple une chaîne constituée de deux objets A et B (voir Fig 26 a). A est un objet incontrôlable A = [l_A, u_A]_i et delta = (u_A - l_A) représente son montant d'indéterminisme. B est un objet contrôlable B = [l_B, u_B]_c et omega = (u_B - l_B) représente son montant de flexibilité. Si la condition omega >= delta est satisfaite, alors l'indéterminisme peut être compensé dynamiquement de façon à rendre toute la chaîne contrôlable. Il suffit dans ce cas d'utiliser la flexibilité omega de façon à rendre la durée de l'objet A constante et égale à u_A, ce qui a pour conséquence d'éliminer l'effet de cet indéterminisme. On obtient ainsi une chaîne ayant un comportement contrôlable vis-à-vis du reste du graphe et de durée totale [u_A+l_B, l_A+u_B]_i.

Fig 26. Exemple du Cas 3

Si l'objet incontrôlable ne peut être compensé au niveau de sa chaîne [Layaïda 96b], la démarche proposée dans Madeus consiste à vérifier si une exploitation de la flexibilité dans les chaînes concurrentes peut permettre de réajuster le scénario. Par exemple, dans le scénario de la Fig 26 b, deux chaînes parallèles {A, X} et {Y, B} doivent être de durées égales. Pour vérifier que cette contrainte peut être satisfaite, il suffit de s'assurer que les instants de début et de fin des chaînes ont lieu à la même date. Là encore, il est facile de voir que si la flexibilité omega de la chaîne concurrente {Y, B} est supérieure à l'indéterminisme delta de la chaîne {A, X} (condition 1), et si la date de l'instant d'observation A⁺ a lieu avant le point de recouvrement B^-, alors la simultanéité des instants B⁺ et X⁺ peut être assurée. En utilisant cette technique, l'ordonnanceur peut donc déterminer statiquement le schéma de compensation pour l'indéterminisme avant de lancer la présentation.

Limitations

La technique de la vérification présentée ci-dessus ne couvre pas tous les cas d'indéterminisme. Notamment, elle ne peut pas être appliquée dans les cas suivants :

la valeur d'indéterminisme est supérieure à la valeur de la flexibilité disponible, c'est-à-dire omega < delta ;
les durées des objets incontrôlables ne sont pas bornées, c'est-à-dire les bornes supérieures peuvent valoir l'infini (delta = infty).

Dans ces deux cas, l'auteur est averti que l'ordonnanceur ne peut pas lui assurer que l'indéterminisme de son scénario pourrait être compensé pendant la présentation, mais l'auteur a le droit de choisir quand même de jouer son scénario. Dans ce cas, un algorithme complémentaire est nécessaire pour compenser l'indéterminisme dont le schéma de compensation ne peut pas être déterminé statiquement.

Cet algorithme fait l'objet de la section qui suit. Il tente de limiter dynamiquement les désynchronisations introduites par l'indéterminisme.

[Table des matières]

4.4.3 Compensation dynamique

Avant de présenter l'algorithme, nous présentons d'abord un ensemble de définitions utilisées dans la suite, suivi par une analyse du problème afin de justifier le principe de l'algorithme.

Définitions

- La durée nominale d'un objet est la durée calculée statiquement pendant la phase de formatage temporel.

- La durée effective d'un objet est la valeur exacte de la durée d'un objet, connue à la fin de sa présentation.

- Le décalage de durée d'un objet est la différence entre la durée effective et la durée nominale de cet objet. Cette valeur peut être négative, en cas de terminaison avancée, ou positive, en cas de terminaison retardée.

- La date nominale d'un instant est la date calculée statiquement pendant la phase de formatage temporel, en prenant comme référence l'instant de début du document.

- La date effective d'un instant est la valeur exacte de la date de l'instant, connue quand la présentation du scénario arrive à cet instant.

- Le décalage de date d'un instant est la différence entre la date effective et la date nominale de cet instant.

- Une présentation multimédia est initialement dans un état appelé état déterministe. Elle entre dans l'état indéterministe dans deux cas (voir la Fig 27 ) :

lorsque la présentation d'un objet incontrôlable dépasse sa durée nominale ;
lorsque la présentation d'un objet incontrôlable se termine avant sa date nominale de fin.

Dans le premier cas, la présentation retourne dans l'état déterministe lorsque l'objet se termine. Dans le deuxième cas, elle retourne dans l'état déterministe lorsque la date nominale de fin de l'objet est atteinte.

Fig 27. L'état indéterministe

Fig 28. Les périodes d'indéterminisme et de perturbation

- La période d'indéterminisme (Delta_ind) est la période pendant laquelle la présentation reste dans l'état indéterministe. Autrement dit, c'est la période entre l'instant où la présentation entre dans l'état indéterministe et l'instant où la présentation revient dans l'état déterministe (voir la Fig 28 ).

- La période de perturbation ou la période de désynchronisation est la période pendant laquelle la présentation est désynchronisée par rapport au scénario spécifié. Autrement dit, c'est la période entre l'instant où la présentation entre dans l'état indéterministe et l'instant où la présentation se débarrasse totalement de la désynchronisation (voir la Fig 28 ).

- L'objet différé est un objet média dont la présentation est différée dans le temps à cause de l'indéterminisme d'un autre objet incontrôlable.

Analyse

Deux types de désynchronisation peuvent être introduits entre les objets média à cause de l'indéterminisme : la désynchronisation séquentielle et la désynchronisation parallèle.

Fig 29. La désynchronisation : séquentielle et parallèle

Afin d'expliquer ces types de désynchronisation, prenons l'exemple de la Fig 29 . Les objets A et B sont liés par une relation de type séquentiel (meets), c'est-à-dire que l'objet B démarre immédiatement après la terminaison de l'objet A. Par contre, A et X sont reliés par une relation de type parallèle (equals), c'est-à-dire ils démarrent au même instant et se terminent au même instant. Par conséquent, par transitivité, les deux relations engendrent une relation implicite entre X et B de type séquentielle (meets). Supposons à présent que l'objet incontrôlable X dépasse sa durée nominale et donc dure plus longtemps que A, l'ordonnanceur est obligé d'attendre sa terminaison avant de démarrer l'objet B. Par conséquent, un délai delta est introduit entre A et B aboutissant à une désynchronisation séquentielle entre A et B. Donc au lieu d'un démarrage immédiat de B après la terminaison de A, le lecteur perçoit que l'objet B attend un délai delta avant de démarrer. De plus, pendant la période de l'indéterminisme dans la Fig 29 , il existe une désynchronisation parallèle qui se manifeste par le fait que les objets A et X ne terminent pas au même instant, contrairement à la spécification. Le lecteur perçoit donc que l'objet A est terminé mais l'objet X reste encore en cours de présentation pendant une période delta.

Au niveau de l'indéterminisme de la durée d'un objet incontrôlable, il existe deux cas distincts : (1) l'indéterminisme en avance, où la durée effective est inférieure à la durée nominale, et (2) l'indéterminisme en retard, où la durée effective est supérieure à la durée nominale.

Pour mieux illustrer l'influence de l'indéterminisme sur une présentation, prenons un exemple simple. Considérons la configuration de la Fig 30 a, où l'objet incontrôlable X représente un cas d'indéterminisme en avance. Dans ce cas, le noeud n, correspondant à la fin de X, doit attendre la terminaison des autres objets qui terminent à ce noeud afin de lancer les objets sortant de n. Une solution simple est d'attendre la terminaison normale des deux objets A et B. Dans ce cas là, les dates nominale et effective du noeud n restent les mêmes, et l'effet de l'indéterminisme n'affecte pas la suite de la présentation. Pourtant, il existe une désynchronisation séquentielle entre X et D, et une désynchronisation parallèle entre X et les deux objets A et B. La période de la perturbation (désynchronisation), se limite à la différence entre la durée nominale et la durée effective de X.

Fig 30. L'influence de l'indéterminisme sur une présentation

Dans le cas d'indéterminisme en retard, où X prend une durée effective supérieure à sa durée nominale (voir Fig 30 b), une désynchronisation parallèle entre X et les deux objets A et B est observée, et la date effective du noeud n est décalée dans le temps d'une valeur delta par rapport à sa date nominale (voir Fig 30 b). Il en est de même pour les instants de début et de fin des objets D et E. Par conséquent, une désynchronisation parallèle aura lieu entre les instants de fin des objets D et F, et de même pour les objets E et G. Donc, l'indéterminisme en retard est suivi par une période de perturbation qui affecte la suite de la présentation.

À la suite de la discussion ci-dessus, nous pouvons faire deux remarques que l'algorithme de compensation d'indéterminisme doit prendre en compte. La première remarque est que le cas de l'indéterminisme en retard est plus important à compenser que le cas de l'indéterminisme en avance. La raison pour cela est illustrée dans la Fig 30 . Nous pouvons voir que la désynchronisation due à l'indéterminisme en avance est localisé et ne dépasse pas le noeud n. Par contre, la désynchronisation due à l'indéterminisme en retard subsiste et peut se propager jusqu'à la fin de la présentation. La deuxième remarque est que chaque période d'indéterminisme est suivie par une période de perturbation (désynchronisation) à la fin de laquelle la présentation peut rétablir la synchronisation spécifiée par le scénario. Donc, l'objectif de l'algorithme de compensation dynamique est la réduction, dès que possible, de cette période de perturbation afin que le lecteur ne perde pas la bonne perception de la présentation. En effet, il se peut que le parallélisme dans la présentation des objets média ait une signification voulue par l'auteur du document. Par exemple, un scénario qui est composé d'un commentaire audio en parallèle à une vidéo sans contraintes fortes. Ces deux objets pouvant être sémantiquement liés, un décalage important entre les deux objets média peut avoir des conséquences négatives sur la qualité de la présentation. Par contre, dans le cas des objets présentés séquentiellement, l'insertion d'un délai dans la séquence affecte généralement moins la qualité de la présentation. Un exemple extrême peut être trouvé dans un scénario organisé sous forme d'une séquence de sous-scènes qui ne présentent aucun recouvrement temporel.

Algorithme

Dans cette section, nous présentons l'algorithme de la compensation d'indéterminisme dont l'objectif est la réduction de la période de perturbation suivant une période d'indéterminisme en retard. La solution proposée est fondée sur l'ajournement des dates de présentation d'objets multimédia dont les instants de lancement arrivent pendant et après une période d'indéterminisme. Cet ajournement est effectué afin de respecter les relations temporelles entre l'objet incontrôlable en cours de présentation, les objets différés et les objets qui seront présentés dans l'avenir.

Fig 31. Exemple 1 : Indéterminisme avec un seul objet incontrôlable

Blocage des objets démarrant pendant et après une période d'indéterminisme

Tous les objets qui démarrent leur présentation après que la présentation du document soit entré dans l'état indéterministe, comme les objets G et H dans la Fig 31 b, sont bloqués et l'ordonnancement de leur démarrage est différé jusqu'à ce que la présentation sorte de l'état indéterministe. La raison pour cela est que cet ensemble d'objets, selon le scénario idéal, commence après la terminaison de l'objet incontrôlable qui est encore en cours de présentation. Leur démarrage doit donc être différé jusqu'à ce que cet objet termine sa présentation pour maintenir l'ordonnancement temporel de l'ensemble des objets par rapport à l'objet incontrôlable.

Dans l'état indéterministe, il est possible d'avoir simultanément plusieurs objets incontrôlables dépassant leur durée nominale. Nous utilisons un compteur d'indéterminisme qui indique le nombre des objets dépassant leur durée nominale à un instant donné. Quand un objet incontrôlable dépasse sa durée nominale le compteur est augmenté, et quand il termine le compteur est diminué. La présentation rentre dans l'état déterministe quand le compteur revient à zéro.

Les objets qui doivent être bloqués sont déterminés comme suit. À l'instant où la présentation sort de l'état déterministe et entre dans l'état indéterministe (l'instant tau1 dans la Fig 31 ), nous examinons le contexte actuel de présentation (CP_tau). Dans CP_tau, nous trouvons les objets actuellement actifs (E et F sachant que A et B ont déjà terminé) dont les noeuds de fin (n et m) sont les noeuds de début pour les objets qui doivent être bloqués (G et H). Cet ensemble de noeuds est stocké dans une liste d'attente.

La sortie de l'état indéterministe et le lancement des objets différés

Au moment de la terminaison de X, s'il n'y a aucun autre objet incontrôlable en cours de présentation dépassant sa durée nominale, c'est-à-dire le compteur d'indéterminisme est égal à zéro, le gestionnaire d'indéterminisme change l'état de la présentation de l'état indéterministe à l'état déterministe. Ensuite, nous calculons la période d'indéterminisme (Delta_ind) qui vaut la période pendant laquelle la présentation était dans l'état indéterministe.

Chaque noeud dans la liste d'attente sera débloqué après un délai calculé par rapport à la date effective de la fin de l'objet incontrôlable dont la terminaison a provoqué la transition de l'état indéterministe à l'état déterministe. Les valeurs des délais sont calculées comme suit :

Étant donné que

n est le noeud ayant la date nominale de plus faible valeur parmi les noeuds bloqués dans la liste d'attente,
X est l'objet incontrôlable dont la terminaison a provoqué la transition de l'état indéterministe à l'état déterministe.

La valeur d'un délai de blocage pour un noeud k dans la liste d'attente dépend de l'ordre temporel nominal du noeud n par rapport à l'instant de fin de l'objet X. Deux cas peuvent se produire :

Le premier cas se produit lorsque la date nominale de n est supérieure ou égale à celle de la fin de X (lignes 1-10 dans la Fig 32 ), c'est-à-dire tous les noeuds dans la liste d'attente doivent arriver temporellement après la fin effective de X. Dans ce cas, la date nominale de la fin de X est prise comme référence pour calculer les délais (lignes 6-7 et lignes 9-10).
Le deuxième cas se produit lorsque la date nominale de n est inférieure à celle de la fin de X (lignes 11-19 dans la Fig 32 ), c'est-à-dire le noeud n est en retard par rapport à la fin effective de X et le noeud n doit être lancé tout de suite après la fin de X. Dans ce cas, la date nominale de n est prise comme référence pour calculer les délais (lignes 15-16 et lignes 18-19).

Pour chaque noeud k dans la liste d'attente, la valeur du délai de blocage dépend de l'ordre temporel de sa date nominale par rapport à la date effective de la fin de l'objet X (lignes 4-10 et lignes 13-19).

Calculer_délai_de_blocage () { 1. Si (n.date_nominale >= X.fin.date_nominale) 2. Alors 3. Pour chaque noeud k in liste_d'attente 4. Si (k.date_nominale < X.fin.date_effective) 5. Alors 6. k.délai_de_blocage = 7. k.date_nominale - X.fin.date_nominale 8. Sinon 9. Delta_ind = X.fin.date_effective - X.fin.date_nominale 10. k.délai_de_blocage = Delta_ind 11. Sinon 12. Pour chaque noeud k in liste_d'attente 13. Si (k.date_nominale < X.fin.date_effective) 14. Alors 15. k.délai_de_blocage = 16. k.date_nominale - n.date_nominale 17. Sinon 18. k.délai_de_blocage = 19. X.fin.date_effective - n.date_nominale }

Fig 32. Calcul des délais de blocage

Pour chaque noeud dans la liste d'attente, lorsque tous les objets entrant se terminent, il faut d'abord attendre pour une période égale au délai calculé ci-dessus avant de démarrer les objets sortant. Par conséquent, les noeuds m et n de la Fig 31 c sont différés vers les noeuds nprime et mprime. Ainsi, la synchronisation par la fin entre G et D ainsi qu'entre H et I est respectée.

Exemples

Nous présentons deux exemples que nous avons expérimentés en appliquant l'algorithme de la compensation dynamique : un exemple avec un seul objet incontrôlable X (celui de la Fig 31 c) et un autre avec deux objets incontrôlables X et Y (Fig 33 c).

Exemple 1 :

Dans cet exemple, nous décrivons le résultat de l'application de l'algorithme aux 4 étapes significatives :

début de la présentation,
fin nominale de X,
fin de la période d'indéterminisme, et
fin de la période de perturbation.

t = 0 (début de la présentation) :

La présentation commence dans l'état déterministe et les états de variables sont les suivants :

Compteur d'indéterminisme = 0
État = déterministe
Liste d'attente = emptyset

t = tau1 = 16 (fin nominale de X) :

À cet instant, la date de la fin nominale de X est atteinte. Le compteur de l'indéterminisme est incrémenté de 1 et la présentation passe dans l'état indéterministe. Les noeuds mis dans la liste d'attente sont m et n. La période de l'indéterminisme ainsi que la période de perturbation commencent à cet instant.

Compteur d'indéterminisme = 1 (l'objet X),
État = indéterministe,
Liste_d'attente = {n, m},
n.date_nominale = 18,
m.date_nominale = 22,
X.fin.date_nominale = 16.

Fig 33. Exemple 2 : Indéterminisme avec deux objets incontrôlables

t = tau2 = 21 (fin de la période d'indéterminisme) :

L'objet X termine et le compteur d'indéterminisme est décrémenté de 1. Si le compteur passe à zéro, alors la présentation passe dans l'état déterministe. La période de l'indéterminisme peut être calculée ainsi que le délai de blocage pour chaque noeud dans la liste d'attente.

Compteur d'indéterminisme = 0,
État = déterministe,
Delta_ind = tau2 - tau1 = 5,
n.délai_de_blocage = 2,
m.délai_de_blocage = 5.

t = 27 (fin de la période de perturbation) :

La période de la perturbation est terminée et la présentation a restauré la synchronisation spécifiée par le scénario idéal. La période de la perturbation est égale à 11.

État = déterministe,
Période de perturbation = 11.

Si l'algorithme n'est pas appliqué, on obtient la situation illustrée dans la Fig 31 b avec une période de perturbation égale à 24.

Exemple 2 :

Dans cet exemple, nous traitons une présentation ayant deux objets indéterministes. Nous décrivons le résultat de l'application de l'algorithme aux 5 étapes significatives :

début de la présentation,
fin nominale de X,
fin nominale de Y,
fin de la période d'indéterminisme, et
fin de la période de perturbation.

t = 0 (début de la présentation) :

La présentation commence dans l'état déterministe et les états de variables sont les suivants :

Compteur d'indéterminisme = 0
État = déterministe
Liste d'attente = emptyset

t = tau1 = 16 (fin nominale de X) :

À cet instant, la date de la fin nominale de X est atteinte. Le compteur de l'indéterminisme est incrémenté de 1 et la présentation passe dans l'état indéterministe. Les noeuds mis dans la liste d'attente sont n, l et m. La période de l'indéterminisme ainsi que la période de perturbation commencent à cet instant.

Compteur d'indéterminisme = 1 (l'objet X),
État = indéterministe,
Liste_d'attente = {n, l, m},
n.date_nominale = 18,
l.date_nominale = 22,
m.date_nominale = 25,
X.fin.date_nominale = 16.

t = 22 (fin nominale de Y) :

La date de la fin nominale de Y est atteinte. Le compteur de l'indéterminisme est incrémenté de 1 et la présentation reste dans l'état indéterministe.

Compteur d'indéterminisme = 2 (les objets X et Y),
État = indéterministe,
Y.fin.date_nominale = 22.

t = 24 (fin de l'objet X) :

L'objet X termine et le compteur de l'indéterminisme est décrémenté de 1. La présentation est encore dans l'état indéterministe.

Compteur d'indéterminisme = 1 (l'objet Y),
État = indéterministe.

t = tau2 = 27 (fin de l'objet Y) :

L'objet Y termine et le compteur de l'indéterminisme est décrementé de 1. Si le compteur passe à zéro, alors la présentation passe dans l'état déterministe. La période d'indéterminisme peut être calculée ainsi que les délais de blocage pour les noeuds dans la liste d'attente.

Compteur d'indéterminisme = 0,
État = déterministe,
Delta_ind = tau2 - tau1 = 11,
n.délai_de_blocage = 0,
l.délai_de_blocage = 4,
m.délai_de_blocage = 7.

t = 39 (fin de la période de perturbation) :

La période de la perturbation est terminée et la présentation a restauré la synchronisation spécifiée par le scénario idéal. La période de la perturbation est égale à 23.

État = déterministe,
Période de perturbation = 23.

Si l'algorithme n'est pas appliqué, on obtient la situation illustrée dans la Fig 33 b avec une période de perturbation égale à 27.

Discussion

Les deux exemples précédents présentent une comparaison entre le cas d'indéterminisme sans et avec l'algorithme de compensation. Nous observons que sans compensation la période de perturbation a subsisté jusqu'à la fin de la présentation, tandis qu'avec la technique de compensation, la période de perturbation est plus limitée et la présentation a retrouvé plus rapidement la synchronisation spécifiée par le scénario idéal.

Une limitation de l'algorithme se manifeste lorsque la période d'indéterminisme acquiert une valeur importante. Dans ce cas, l'ajournement des dates est perçu par le lecteur comme si la présentation était partiellement interrompue et une importante désynchronisation séquentielle est engendrée. Une façon pour éliminer cette limitation est de tirer profit de la flexibilité des objets contrôlables, s'ils existent. Par exemple, dans la Fig 31 , si l'objet E est un objet contrôlable (comme un texte ou une image), alors nous pouvons le laisser démarrer sans ajournement pour sa date de début mais nous différons seulement sa date de fin, c'est-à-dire nous prolongeons la durée de l'objet E par une valeur Delta_ind. Par contre, pour un objet continu de type audio, il est difficile de changer sa durée parce que sa vitesse de présentation est un paramètre crucial qui doit rester fixe afin de mieux préserver son intelligibilité. En revanche, un objet continu de type vidéo nous permet de prolonger sa durée en le jouant un peu moins vite.

[Table des matières]

5 Gestionnaire d'objets

Le gestionnaire d'objets est le composant de Madeus qui traite l'hétérogénéité des objets média. Il permet d'ajouter facilement des nouveaux types d'objets média, en fonction des besoins de l'application, sans recompilation. Dans Madeus, le gestionnaire d'objets gère une hiérarchie de classes d'objets média qui définissent les caractéristiques et les actions de présentation de ces objets. De plus, le gestionnaire d'objets exécute les commandes lancées par l'ordonnanceur pour créer et pour initialiser des instances d'objets.

La Fig 34 schématise l'architecture du gestionnaire d'objets et son interaction avec les autres composants de Madeus. Son architecture et son fonctionnement sont détaillés dans les sous-sections qui suivent.

Fig 34. Gestionnaire d'objets de Madeus

[Table des matières]

5.1 Le modèle objet de Madeus

Le modèle objet de Madeus permet un accès efficace à l'information nécessaire pour manipuler les différentes dimensions de présentation d'un document multimédia (structurale, temporelle, spatiale et sémantique). Il permet aussi de bien représenter l'activité des objets média et les besoins de synchronisation. La présentation d'un document multimédia est représentée sous Madeus par :

un ensemble d'objets média, constituant le document multimédia, ayant entre eux des relations temporelles, spatiales, structurelles et sémantiques spécifiant la présentation du document ;
une horloge pouvant être utilisée pour certains styles de présentation comme pour le mouvement, les fondus en entrée et les fondus en sortie (e.g., pour la vidéo et l'audio) ainsi que des délais entre des objets média ;
un ordonnanceur pour observer et contrôler la progression de la présentation des objets média en fonction d'un scénario de référence. Le fonctionnement de l'ordonnanceur est fondé sur les événements de présentation et les diagrammes de transitions des objets média (cf. 5.1.2).

Dans Madeus, nous considérons qu'un objet média de base peut avoir une ou plusieurs des caractéristiques suivantes : visible, audible, continu et opaque (cf. la section II.2.1). Les objets média opaques sont les objets sur lesquels nous n'avons pas de vrai contrôle, comme les plugins et les applets. Les objets média peuvent être continus ou discrets, par exemple un clip vidéo est continu alors qu'une image est discrète. Madeus introduit aussi des objets d'interactions, comme les boutons. La hiérarchie des classes Madeus prend en compte ces différents aspects des objets média. Chacune de ces caractéristiques est décrite par une classe.

[Table des matières]

5.1.1 Hiérarchie des classes Madeus

Dans la hiérarchie des classes Madeus, nous avons essayé de représenter tous les composants qui apparaissent dans la présentation d'un document multimédia : les objets média, l'horloge et l'ordonnanceur. Les classes que l'on propose sont hiérarchisées comme montré dans la Fig 35 . Dans la suite, nous allons expliquer cette hiérarchie et le rôle de chaque classe.

La classe MadeusObject (racine) :

La Fig 35 schématise la hiérarchie des classes Madeus.

MadeusObject représente la racine du graphe d'héritage. Elle définit le comportement commun de toutes les classes d'objets média. L'attribut ObjectID identifie chaque objet média. Les méthodes de cette classe permettent d'initialiser un objet média à sa création, de le détruire en cas de besoin, et d'avoir des informations le concernant lui ou sa superclasse.

Les classes Clock, Callback, Interval et Monitor sont les sous-classes directes de MadeusObject.

Fig 35. Hiérarchie des classes Madeus

La classe Clock :

La classe Clock permet de traiter la dimension temporelle des documents multimédia de Madeus. Les attributs de cette classe sont currentTick qui représente l'instant courant et timeResolution qui indique la plus petite unité temporelle non divisible retenue (e.g. seconde, milliseconde, microseconde). La méthode GetTick retourne la valeur de l'instant courant. La classe Clock est une classe abstraite ayant deux sous classes directes: SysClock et Timer.

La classe SysClock :

Les instances de la classes SysClock donnent l'heure dans une zone déterminée avec une précision donnée (méthode GetTime).

La classe Timer :

Les instances de la classe Timer engendrent un événement lors de chaque écoulement de n unités de temps à partir de l'activation de cette instance, où n est représenté par l'attribut timerPeriod. Chaque instance de classe Timer est considérée comme un chronomètre dont les différents états sont décrits dans la Fig 36 . L'état d'une instance est mémorisé dans l'attribut currentState et la méthode GetCurrentState retourne l'état courant d'un objet de type Timer. L'état d'une instance change en accord avec l'état d'exécution de l'objet qu'elle représente, c'est-à-dire l'état de l'instance peut être suspendu (suspended), actif (running) ou stoppé (stopped). La valeur du temps écoulé à partir de l'activation d'un objet Timer est mémorisée dans l'attribut elapsedTime. La méthode GetInfo retourne les valeurs de timerPeriod et elapsedTime. La méthode startTimer permet d'activer un objet de type Timer, la méthode PauseTimer permet de suspendre l'exécution, la méthode ResumeTimer permet de reprendre l'exécution d'un objet Timer suspendu et la méthode ResetTimer permet de réinitialiser un objet Timer.

Fig 36. Graphe de transitions de l'objet Timer

Le rôle d'un objet Timer est de réaliser la durée associée à un objet média discret et les durées des effets de style de présentation de n'importe quel type d'objet média. Ces effets de style peuvent être réalisés par la variation périodique de valeurs d'attributs tels que la position et la dimension d'un objet sur l'écran, la couleur d'un objet visible, le volume d'un objet audible, etc.

La classe Callback :

Le rôle de la classe Callback est de prendre en charge les occurrences d'événements survenant lors de la présentation d'un document Madeus et d'organiser l'exécution des actions correspondantes. L'attribut eventList mémorise tous les événements significatifs pour un objet de type Callback et la méthode Action permet de déterminer le comportement qu'il faut adopter en réponse à cet événement. L'attribut currentEvent mémorise l'événement pris en compte par la méthode Action. Callback est une classe abstraite car la méthode Action ne peut être définie d'une manière générale. Chaque sous-classe de Callback doit donc définir la méthode Action appropriée.

La classe Interval :

La classe Interval définit la structure et le comportement communs à tous les objets média. Elle est sous-classe directe de MadeusObject, Timer et Callback. Elle réalise par conséquent les caractéristiques communes à tous les objets Madeus définies dans MadeusObject, le comportement temporel hérité de Timer et la gestion des événements/actions héritée de Callback. Le comportement générique des objets média à différents états de présentation est défini dans cette classe par les méthodes MapObject, PlayObject, PauseObject, ResumeObject, KillObject, UnmapObject, etc. La méthode PlayOneStep réalise les actions d'exécution à effectuer à chaque instant Tic (voir la définition de Tic dans la section 3.4). La méthode CreateConnectionLink gère l'établissement de liens de communication entre les objets Interval. Ce type de communication est utile pour réaliser la synchronisation fine entre deux objets de classe Interval.

La classe Basic :

La classe Basic réalise la structure et le comportement communs à tous les objets média de base. L'extension de cette classe, par la relation d'héritage, permet de répondre à l'évolution de nouveaux types d'objets média. Sa structure comprend un identificateur du processus processID correspondant à un objet média de base et un pointeur sur un hyperlien destination hyperlinkDestination indiquant l'emplacement de l'objet média. Les sous-classes directes de la classe Basic déterminent les différents types d'objets média de base que nous avons distingués dans Madeus:

Classe Audible : inclut tous les objets média que l'on peut entendre. La structure de cette classe définit l'attribut audioChannelsList qui mémorise les canaux audio qu'un objet de ce type peut utiliser. Les méthodes spécifiques à cette classe sont GetVolume et SetVolume pour lire ou modifier le niveau du volume sonore, SetBalance et GetFormat.
Classe Visible : inclut tous les objets média que l'on peut voir. La structure de cette classe définit la liste de fenêtres windowsList utilisées par l'objet et la table de couleurs colormap associée. Les méthodes spécifiques à cette classe sont : GetWidth, GetHeight, GetColormap et GetFormat, qui récupèrent les informations sur les caractéristiques visuelles d'un objet.
Classe Continuous : inclut tous les objets média ayant un flot continu de données avec des contraintes temporelles de présentation. L'attribut streamBuffer est un pointeur sur le flot de données. Les méthodes OpenStream, CloseStream, StopStream, ResumeStream, CompressStream et DecompressStream permettent de manipuler le flot de données (ouvrir, fermer, suspendre, reprendre, compresser, décompresser, etc.).
Classe Opaque : inclut tous les objets média sur lesquels Madeus ne peut avoir un contrôle de présentation (plug-ins, applets java). Madeus peut seulement lancer l'exécution de ce types d'objets média et définir des durées à la fin desquelles Madeus termine leur exécution. L'attribut windowsList mémorise une liste de fenêtres nécessaires à la présentation de l'objet. Les méthodes GetTypeOfInterface, InitializeTypeOfInterface, OpenInterface, CloseInterface sont des fonctions pour manipuler une interface générique, définie par Madeus, qui permet la communication entre Madeus et les objets de type Opaque. Un objet opaque peut être composé d'un ensemble d'objets de base dont le contrôle est masqué de Madeus.

La classe Composite :

La classe Composite permet de définir un objet média (composé) à partir d'autres objet média (composants) en établissant entre eux des relations temporelles et spatiales. Les relations temporelles considèrent l'ordonnance temporelle de l'exécution des objets média composants les uns par rapport aux autres. Par exemple un clip vidéo démarre à la fin d'un autre clip vidéo, ou encore un clip audio démarre en même temps qu'un clip vidéo, etc. Les relations spatiales considèrent la position spatiale des objets média composants les uns par rapports aux autres. Par exemple une image doit toujours être alignée horizontalement par rapport à une autre. Les objets de ce type définissent la structure hiérarchique d'un document multimédia [Layaïda 96a]. L'attribut intervalList mémorise tous les objets composants d'objet de type Composite. Les attributs temporalRelations et spatialRelations mémorisent respectivement les relations temporelles et spatiales entre les objets. L'attribut graphNodesList maintient les informations sur l'hypergraphe qui représente les relations temporelles.

Les méthodes de cette classe sont définies pour permettre d'ajouter ou de supprimer des objets, des relations temporelles ou spatiales [Layaïda 96b][Layaïda 96a] nécessaires pour l'édition de documents multimédia. De plus, ces méthodes réalisent les fonctions nécessaires pour construire l'hypergraphe correspondant à cet objet ; dans cet hypergraphe, les objets appartenant à la liste intervalList et liés par les relations temporelles mémorisées dans temporalRelations sont représentés par les arcs de l'hypergraphe. La classe composite est donc celle qui décrit la représentation interne d'un document multimédia (l'hypergraphe) dans la hiérarchie du modèle objet de Madeus.

La classe Monitor :

La classe Monitor définit la structure et le comportement communs à toutes les classes réalisant le fonctionnement de l'ordonnanceur qui prend en charge la présentation des objets média dans un document. L'attribut traceFlag permet d'avoir les informations concernant les objets média dans un document. Les méthodes ShowUpdatedInfo et SetTraceFlag permettent respectivement de lire la valeur de traceFlag ou de la modifier. Ceci permet à un auteur d'un document multimédia de vérifier le scénario qu'il est en train de concevoir. Les sous-classes directes de la classe Monitor sont EventHandler et StateHandler.

La classe EventHandler :

La classe EventHandler permet d'acheminer un événement donné aux objets concernés. Les objets de ce type peuvent enregistrer de nouveaux événements et les objets concernés, supprimer des événements, recevoir des événements et les acheminer aux objets concernés. La gestion d'événements dans Madeus sera préséntée en section V.4.3 du chapitre 5.

La classe StateHandler :

La classe StateHandler permet de gérer les états et les transitions des objets Timer et des objets média. Les transitions peuvent être le résultat d'une activité interne (fin normale de l'exécution d'un objet) ou externe (un objet est considéré terminé à l'occurrence de certains événements externes comme le changement de document). Cette classe permet de mémoriser l'état courant, de valider et de traiter les différentes transitions pour chaque objet média.

[Table des matières]

5.1.2 Les états d'exécution des objets

Les graphes de transitions permettent de décrire un comportement générique (ne tenant pas compte des détails de la réalisation) ainsi que l'évolution d'un objet média en fonction des événements qui lui sont adressés et des actions qu'il effectue ou qu'il subit. La Fig 37 montre le graphe de transitions retenu pour les objets média, c'est-à-dire les objets de type Interval.

Fig 37. Graphe de transitions des objets de type Interval dans Madeus

La classe Interval (Fig 35 ), réalise le graphe de transitions des objets média : l'état courant d'un objet est mémorisé dans l'attribut state de la classe Interval et le comportement d'un objet correspondant à chaque état du graphe de transitions est réalisé par une méthode appropriée (mapObject, playObject, etc.). Les différents états d'un graphe de transitions dans Madeus sont :

Unmapped: si l'objet n'est pas exécuté et qu'aucune ressource de présentation ne lui est allouée ou s'il est terminé et que toutes ses ressources de présentation sont libérées. Les ressources de présentation dépendent du type de l'objet média. Par exemple, les médias visibles nécessitent des ressources écran alors que les médias audibles ont besoin de ressources au niveau des canaux sonores.
Mapped : l'objet est prêt à être exécuté. Le flot de données qu'il doit interpréter est prêt et les ressources de présentation sont allouées comme par exemple, la fenêtre d'affichage, la palette de couleurs et le module de décompression pour une image d'un format donné (GIF, JPEG, PNG, etc.) ou bien l'ouverture d'un canal sonore et le module de décompression pour une audio d'un format donné (AIFF, MIDI, MPEG, AU, etc.).
Active: l'objet média est en cours d'exécution.
Suspended : l'objet média est suspendu pour des raisons externes (un utilisateur a suspendu l'objet) ou internes (pour une synchronisation : l'objet est suspendu jusqu'à l'occurrence d'un événement donné).
Terminated: l'exécution de l'objet média s'est terminée mais toutes les ressources de présentation sont encore allouées. À partir de cet état, un objet peut être rejoué sans avoir besoin d'allouer de nouveau des ressources de présentation.
Stored: un objet média atteint cet état lorsque, par exemple, un hyperlien vers un autre document est activé. À ce moment, le contexte courant de présentation est sauvegardé, l'exécution de tous les sous-objets actifs est interrompue, puis ces objets passent dans l'état Stored (cf. 4.3.1) [Sabry 97]. Les informations sur la présentation et l'exécution de l'objet média sont alors stockées (e.g. numéro d'une image courante d'un clip vidéo). Ces informations peuvent être réutilisées pour réactiver l'objet à partir du moment exact de sa suspension. Les ressources de présentation d'un objet média lorsqu'il est dans l'état Stored peuvent être libérées pour être réallouées plus tard.

[Table des matières]

5.2 Le médiateur d'objets

Madeus gère une table contenant les formats média qu'il supporte, cette table pouvant être enrichie dynamiquement lors de l'édition d'un document. À partir de cette table et du document, l'ordonnanceur transmet les informations nécessaires (type d'objet à créer, la source de flot de données, etc.) au médiateur d'objets (Fig 34 ). Ce dernier, à partir de ces informations, crée une instance d'objet de la classe appropriée (Vidéo, Audio, etc.). Les opérations de liaison entre cet objet et le code binaire correspondant à ses méthodes sont effectuées par le gestionnaire d'exécution, présenté dans le chapitre suivant.

Lors de l'ajout d'un objet média dans un document Madeus, le système d'édition vérifie, à partir de la table des formats, si l'objet est supporté. S'il n'est pas supporté, l'auteur doit fournir les informations nécessaires, notamment le type de l'objet média (video, audio, etc.), le format de son flot de données et le code binaire pouvant lire et manipuler ce format. Ces informations sont ensuite enregistrées dans la table de formats. Les informations de cette table sont stockées dans un fichier de ressources qui est exploité par le gestionnaire d'objets et le gestionnaire d'exécution.

[Table des matières]

6 Conclusion

Dans ce chapitre, nous avons présenté l'architecture et le fonctionnement de la machine d'exécution de Madeus. Le rôle de cette machine est d'ordonnancer la présentation d'un document multimédia au niveau de la synchronisation entre les objets média, de la navigation temporelle, de la gestion d'événements et de la gestion dynamique de l'indéterminisme produit lors de l'exécution des objets incontrôlable. De plus, la machine d'exécution gère un modèle d'objets mis en oeuvre pour faciliter la gestion et l'ajout de nouveaux types d'objets média.

Afin que la machine d'exécution puisse bien remplir son rôle, un modèle pour l'exécution est défini. Le fonctionnement de ce modèle repose sur les informations fournies par une structure d'exécution organisée sous forme d'un hypergraphe. Nous avons défini la structure du contexte de présentation pour représenter un instant donné dans la vie d'une présentation. Nous avons également défini les instants de Tic et de Tac qui peuvent être utilisés comme des ancres d'hyperlien et des points de synchronisation.

Ainsi, l'ordonnanceur de Madeus gère la synchronisation fine et à gros grain, la navigation temporelle, la compensation dynamique de l'indéterminisme et les événements d'exécution.

Le gestionnaire de synchronisation utilise la gestion centralisée comme stratégie pour la synchronisation à gros grain puisque à ce niveau, la maîtrise globale du scénario est nécessaire. Par contre, la gestion distribuée est utilisée pour la synchronisation fine du fait de la localité de cette synchronisation et afin de ne charger le gestionnaire de la synchronisation qu'en cas de nécessité. De plus, la gestion distribuée s'adapte bien à la structure d'objets média adoptée dans Madeus. Nous avons présenté également les techniques, comme le préchargement de données et le saut d'images vidéo, que nous utilisons pour éliminer les effets de la gigue et de la dérive qui caractérise les objets continus. Nous avons vu que ces techniques sont nécessaires afin de réaliser une synchronisation fine de bonne qualité.

Le gestionnaire de navigation temporelle est mis en oeuvre grâce aux fonctions de manipulation de la structure du contexte de présentation : la mise à jour, la sauvegarde et le calcul. Un groupe d'opérations de navigation, spécifiques aux documents multimédia, est réalisé en utilisant les instants Tic et Tac.

Le gestionnaire dynamique de l'indéterminisme emploie un algorithme de compensation qui utilise les informations de l'hypergraphe de façon dynamique afin de compenser l'indéterminisme produit. Cet algorithme a montré une réduction importante dans la période de perturbation qui suit la détection de l'indéterminisme.

Le gestionnaire d'objets adopte l'approche objet qui s'adapte bien aux applications multimédia caractérisées par une hétérogénéité et une évolution continue des objets média. En effet, les objets média ne cessent d'évoluer et il existe de plus en plus de nouveaux formats. Il était donc nécessaire de définir un support permettant d'étendre ce système afin de supporter ces nouveaux objets. Notre étude nous a amené à définir un gestionnaire d'objets composé du modèle objet Madeus et d'un médiateur d'objets permettant d'étendre dynamiquement le système pour intégrer ces nouveaux formats.

Dans le chapitre suivant, nous présentons la deuxième partie du système de présentation le « gestionnaire de présentation » qui se charge d'effectuer les fonctions de présentation au niveau du système d'exploitation et du système de communication. En effet, il gère la création des processus qui se chargent de la présentation des différents objets média et la communication entre eux et avec le processus qui gère la synchronisation de la présentation. Il gère également les périphériques de présentation ainsi que l'accès aux objets média locaux et distants.