Exemple de mises à jour SVG - Descriptions de scènes multimédia : représentations et optimisat

Cette solution est envisageable en utilisant la version 1.2 de la norme SVG, qui intègre l'élément

discard. Cette solution est également envisageable dans un format combinant les normes XHTML et SMIL dans le cadre d'un document CDF. Nous verrons, dans le chapitre 6, l'impact de l’élément

discard sur la consommation mémoire dans de tels cas. Nous verrons également dans la section 6 comment nous avons exploité cette solution dans une architecture de streaming de contenu SVG. Enfin, il faut remarquer que cette solution est simple du point de vue descriptif. Cependant, elle n'est pas très expressive car elle ne permet que le remplacement d'une valeur d'un attribut, qui plus est de la valeur de présentation. Elle n’est pas aussi expressive que les mises à jour Flash, BIFS ou LASeR car elle ne permet pas, entre autres, l'insertion d'éléments. Par ailleurs, elle implique que les mises à jour SVG soient présentes dans le même document que la scène initiale.

2.3.3.3.2 Utilisation d’un langage de programmation

Une autre méthode d'animation des scènes SVG ou HTML est également possible en utilisant la norme DOM (Document Object Model). Cette norme définit un modèle et des interfaces pour

Chapitre 2 – Descriptions de scènes et animations

manipuler les documents XML. Ce modèle permet à des programmes ou des scripts d’accéder et de modifier de manière dynamique le contenu ou la structure d’un document. L’association d’un document XML (au format SVG, SMIL, XHTML ou autres), du modèle DOM et d’un langage de programmation du type de ECMAScript ou Java donne les moyens, en quelque sorte, de mettre à jour et d’animer le document et la scène qu’il représente. Un exemple déjà très répandu de cette combinaison de technologies est connu sous le nom « Dynamic HTML ».

On pourrait donc tout à fait envisager de définir un flux de descriptions de scènes basé sur ces technologies. Pour cela, nous inspirant des exemples précédents, nous définirions une mise à jour comme :

• un ensemble de code ECMAScript;

• suivi d’éventuels fragments de documents XML.

Le code ECMAScript a pour rôle, en faisant appel aux interfaces DOM, de modifier le document. Ces modifications utilisent le cas échéant les données XML fournies dans la mise à jour. Une telle architecture fournit en quelque sorte des mises à jour analogues à celles des formats Flash, BIFS ou LASeR. Les possibilités en termes de mises à jour de ce format sont bien évidemment plus vastes que celles offertes par l'animation discrète SMIL et limitées uniquement par l’interface DOM. Si on ajoute le fait qu’il est naturellement possible de naviguer dans le document XML grâce à DOM et que ce dernier s’intègre aussi bien avec XPath et XPointer, ces mises à jour ne sont pas limitées par un mécanisme d’adressage.

En revanche, en termes de complexité et de vitesse d’exécution, cette solution est plus coûteuse pour plusieurs raisons. Tout d’abord, du point de vue de la taille de l’implémentation et de sa complexité, le surcoût d’une interface DOM est non négligeable dans le développement d’un moteur de composition de scène. Pour cette raison notamment, la version 1.2 du profile Tiny de la norme SVG spécifie une version simplifiée de DOM, appelé MicroDOM [55]. Cette version simplifiée dédiée aux documents SVG utilise notamment des objets typés et non des chaînes de caractères ; et réduit les appels possibles. Néanmoins, même dans ce cas, le temps nécessaire pour l’exécution du moteur de script est également important comparé au temps nécessaire à l’exécution d’une mise à jour Flash, BIFS ou LASeR. Le Tableau 2.1 montre le temps moyen nécessaire pour 1000 exécutions de mises à jour LASeR par rapport au temps de 1000 exécutions d'un script MicroDOM effectuant les mêmes opérations dans l'implémentation que nous avons utilisée décrite au chapitre 7.

Mise à jour LASeR Code MicroDOM/ECMAScript 16,82 604,89

Tableau 2.1 – Durée (en millisecondes) de 1000 exécutions d'un ensemble de mises à jour LASeR par rapport à 1000 exécutions d'un code MicroDOM/ECMAScript équivalent

Descriptions de scènes multimédia : représentations et optimisations

- 46 -

2.3.3.3.3 REX

Devant l'absence de méthode déclarative normative, complète, efficace et compatible avec les standards DOM et XML pour mettre à jour et animer un document XML, le W3C a décidé en 2006 de démarrer une activité de spécification d'un langage déclaratif pour permettre la modification d'un document XML. Cette nouvelle spécification, encore à l'état d'ébauche, au moment où cette thèse est rédigée, se nomme REX (Remote Events for XML) [59]. REX est un langage XML permettant de représenter les évènements de la spécification DOM 3 Events [60].

Dans ce langage, les évènements sont décrits en XML par des éléments event. Un élément event

peut décrire plusieurs évènements de même type mais dont les cibles sont différentes. Les cibles sont adressées par une expression XPath. Le principe du langage REX est que ces éléments event

peuvent être transmis à un terminal distant dans un message REX.

Quand un terminal distant reçoit un message REX, la spécification indique :

• qu'il doit déclencher le ou les évènements décrits par chaque élément event;

• et si un des évènements déclenchés est un évènement de modification de l'arbre (mutation event), qu'il doit, en plus, appliquer à l'arbre DOM la modification qui aurait pour conséquence de déclencher cet évènement.

Les évènements de modification de l'arbre actuellement envisagés dans la spécification REX sont :

DOMNodeInserted, DOMNodeRemoved, DOMAttrModified et

DOMCharacterDataModified.

La solution REX permet donc, de manière déclarative, d'insérer ou de supprimer des éléments et de modifier le contenu d'un attribut ou le contenu textuel d'un élément dans un arbre DOM. Il s'agit d'une solution équivalente aux mises à jour BIFS ou LASeR à la différence près que la syntaxe REX ne permet pas actuellement de faire des manipulations sur des données typées. Il n'est pas possible par exemple d'exprimer que l'on souhaite remplacer la nième valeur dans un attribut contenant plusieurs valeurs. De même, il n'est pas possible de remplacer une valeur par la somme de cette valeur et de la nouvelle valeur, comme l'autorise le langage LASeR.

Enfin, l’inconvénient de cette solution est le coût dû à la lecture du XML. Ce coût pourrait néanmoins être réduit ou supprimé par des méthodes de compression appropriées comme nous le verrons dans le chapitre 3, mais il faudrait dans ce cas quelques modifications aux modèles DOM ou MicroDOM pour ajouter ces API.

2.3.4 Synthèse sur les méthodes de mise à jour de scènes

Nous avons vu qu'il existait différents langages pour effectuer des mises à jour discrètes d'une scène multimédia, mais que tous suivent la même approche : l'envoi d'instructions, qui doivent être

Chapitre 2 – Descriptions de scènes et animations

exécutées soit à la réception, soit à un temps explicite dans la base de temps, soit suite à un évènement utilisateur. La différence entre les langages réside principalement dans le vocabulaire et dans la manière de formuler ces instructions : déclarative ou programmatique, utilisant des évènements, des animations discrètes ou des mises à jour …

2.4 Conclusion

Nous avons présenté les deux grandes approches déclaratives de l'état de l'art pour l'animation de descriptions de scènes que sont : l'interpolation et la mise à jour discrète. L’utilisation d’une approche plutôt que l’autre dépend de deux facteurs : la méthode utilisée pour créer les animations et le scénario de consommation de la scène. Nous avons vu que pour les animations continues, un bon candidat pour représenter ces animations était le mécanisme d’interpolation et que pour les autres cas, les mécanismes de mise à jour étaient plus pertinents.

En ce qui concerne le scénario de consommation de la scène, on distingue deux cas. Dans le cas où la scène est obtenue par téléchargement, par exemple en utilisant un protocole du type HTTP [105], MMS [106] ou FLUTE [76], le lecteur n’ayant plus de contact avec le serveur une fois le téléchargement terminé, il est indispensable que tous les états de la scène soient connus dès le début de la lecture. Une description par interpolation est donc appropriée.

A l’inverse, dans le cas où la scène est obtenue par un protocole de diffusion continue (streaming broadcasting, ou téléchargement progressif), la description par trame d’animation offre plus de flexibilité car le serveur peut décider au milieu de la session, sur interaction utilisateur ou sur une décision du diffuseur, de modifier les états suivants de l'animation. Dans ce cas, l'animation par mise à jour est préférable.

Le Tableau 2.2 récapitule les avantages des deux modèles. Bien sûr, les modèles peuvent être combinés dans un même langage. C’est le cas de BIFS qui intègre le modèle d’interpolation repris de VRML mais ajoute le modèle par trame d’animation. C’est également le cas du format LASeR. Il est ainsi possible, par exemple dans un scénario de streaming, d'insérer dans la scène ou de modifier, via des mises à jour, des animations décrites par des interpolations. Il faut néanmoins prendre garde que la modification par mise à jour d'une animation en cours d'exécution peut avoir un impact sur la fluidité de l'animation car la mise à jour peut invalider les précalculs faits à l'initialisation de l'animation.

Descriptions de scènes multimédia : représentations et optimisations

- 48 -

Critère de

comparaison Modèle par trame d’animation Modèle d’animation par interpolation Applicabilité Décrit des animations non

paramétriques, non continues. Besoin de mises à jour complexes.

Décrit des animations continues du temps.

Connaissance de tous les états de l'animation au début de la diffusion. Relation avec la

notion de temps de scène

Déroulement de l’animation indiqué par le flux (possibilité de pilotage par un serveur).

Contrôle du déroulement de l’animation plus fin au niveau client (choix de la fréquence de rafraîchissement) mais nécessite le maintien d'une notion de temps. Animation en boucle possible. Relation avec les

mécanismes de transport

Possibilités de stockage et transport plus importantes, en utilisant les mécanismes de synchronisation existants.

Compacité de la représentation

Ne nécessite pas de voie descendante permanente.

Complexité Nécessite l'implémentation d'un mécanisme d'application d'une mise à jour.

Nécessite l'implémentation d'un moteur d'animation et d'un mécanisme d'application de l'animation.

Chapitre 3

Descriptions de scènes et Compression

3.1 Introduction

Dans ce chapitre, nous présentons tout d’abord les caractéristiques des descriptions de scènes qui s’avèrent pertinentes pour la compression, en introduisant en particulier la distinction primordiale entre données et structure de scène. Puis nous donnons un état de l’art des techniques de compression de la structure de scène ainsi que certaines techniques de codage de données.

Nous nous sommes intéressés à la compression de descriptions de scènes car il nous est vite apparu que les descriptions de scènes complexes pouvaient être volumineuses. C’est le cas par exemple pour les contenus graphiques vectoriels. Mais ce n’est pas toujours le cas. Quand la scène ne contient pas beaucoup d’objets, quand elle est statique ou de courte durée, la compression n’a pas beaucoup d’intérêts en terme de gain de débit. Il faut également relativiser l’intérêt de ce gain en prenant en compte la taille de la scène, compressée ou non, par rapport à la taille des flux médias associés à la scène. Ainsi, si une scène ne décrit que quelques objets graphiques, quelques interactions possibles et quelques animations, sa taille, compressée ou non, sera négligeable comparée à celle d’un flux audio ou vidéo. Par exemple, dans le cas d'une application de type slideshow d'images, une scène SVG représentant une séquence de 7 images occupe 4,5 Ko à comparer avec les 7 images au format JPEG, de dimension 300x200 qui occupent 55 Ko. Néanmoins, même dans les cas où la compression n’a que peu d’intérêt en débit, la représentation binaire est toujours intéressante car elle permet une lecture plus rapide comme nous le verrons dans le chapitre 7.

Une scène véhicule une information structurée comme nous l'avons décrit dans le chapitre 1. Si l’on s’intéresse à la compression de descriptions de scènes, il faut donc connaître le rapport entre le volume nécessaire pour la représentation de l’information et celui nécessaire pour la représentation de la structure.

Il est intéressant de noter le travail du groupe Efficient XML Interchange (EXI) au sein du W3C [61][62]. Ce groupe étudie les mécanismes génériques de compression de document XML. Il propose une classification des contenus XML selon la taille du fichier et la densité d'information. La densité d'information est définie par ce groupe comme le rapport entre le nombre d'octets utilisés pour décrire

Descriptions de scènes multimédia : représentations et optimisations

- 50 -

le contenu textuel (dans les attributs ou entre les balises XML) et la taille du document en octets. Ainsi, un document est considéré comme très structuré si la densité d'information est inférieure à 50%. A l'inverse, il est considéré comme peu structuré si la densité d'information est supérieure à 50%, c'est- à-dire si le fichier contient plus de données que de balises. Les résultats de ce groupe indiquent 3 catégories de fichier XML : les fichiers peu structurés, les fichiers de petites tailles très structurés, et enfin, les fichiers volumineux très structurés.

Notre expérience est légèrement différente. En effet, avec les documents XML représentant des descriptions de scène, nous n'avons pas rencontré de contenu à la fois très structuré et très volumineux. D'après notre expérience des descriptions de scènes SVG ou XMT, il existe deux types de contenus : les contenus peu volumineux où la part de la structure est prédominante – contenus interactifs du type portail, avec peu de graphiques vectoriels et peu de texte – et les contenus volumineux où la part des données est très importante – contenus du type dessins animés ou du type cartographique. La Figure 3.1 indique le résultat du calcul de densité d'information sur les séquences SVG utilisées dans les phases de conformité du langage LASeR. La taille des fichiers SVG est indiquée en abscisse, en octets, selon une échelle logarithmique. On distingue, sauf pour quelques exceptions, que la densité d'information n'est supérieure à 50% que pour les contenus volumineux.

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 1000 10000 100000 1000000 10000000

Densité d'information importante

Densité d'information faible

Figure 3.1 – Densité d'information dans les séquences SVG pour la conformité LASeR en fonction de la taille en octets du fichier SVG

A partir de ce constat, la problématique de la compression de descriptions de scènes est donc double. Il s’agit de trouver des mécanismes de compression des informations de structure efficaces en

Chapitre 3 – Descriptions de scènes et Compression

complexité de décodage ou offrant des caractéristiques de scalabilité pour coder les contenus très structurés. Dans le même temps, il faut trouver des mécanismes de compression de données efficaces, avec ou sans perte, pour réduire significativement le débit des contenus, peu structurés, les plus volumineux, tout en maîtrisant le rapport facteur de compression/qualité. Enfin, il faut combiner les techniques pour les documents très structurés et les documents transportant beaucoup de données sans en perdre les avantages respectifs.

3.2 Compression de la structure des scènes multimédia

Nous présentons dans cette section les méthodes utilisées pour compresser la structure des descriptions de scènes. La compression dans ce domaine consiste à représenter sous forme binaire la structure des descriptions de scènes, c'est-à-dire l'arbre de scène, sans perte, mais en réduisant la redondance de cette structure. On parle également de « binarisation ». Il est intéressant de noter que certaines techniques de réduction de la structure impliquent également une réduction des données à coder. Par exemple dans le domaine XML, moins il y a d'éléments à coder, moins il y a d'attributs à coder. Parmi ces techniques, nous présentons les techniques de prétraitement qui permettent de réduire l’information redondante avant la « binarisation ». Nous présentons également un rapide état de l’art des techniques de représentation binaire de documents structurés.

3.2.1 Factorisation des structures redondantes

L’efficacité de la compression de la structure des descriptions de scènes est fortement dépendante de la représentation non compressée choisie et de la connaissance de la redondance dans cette représentation. En effet, il est possible à partir d’une même scène issue d'un même langage de descriptions d’aboutir à des représentations différentes plus ou moins redondantes. Les exemples ci- dessous illustrent comment un arbre de scène VRML (Figure 3.2) peut être représenté différemment en XMT-A (Code 3.2), XMT-O (Code 3.3) et X3D (Code 3.1). Les exemples de codes XML omettent, pour plus de concision, les déclarations d’espaces de noms, l’instruction indiquant l’encodage du fichier et d'autres informations non nécessaires pour la compréhension.

Descriptions de scènes multimédia : représentations et optimisations

- 52 -

Figure 3.2 – Exemple d’arbre de scène VRML

Dans le document Descriptions de scènes multimédia : représentations et optimisations (Page 67-75)