FR 2917880 A1 20081226 FR 0755902 A 20070620 La présente invention se situe dans le domaine du traitement de scène multimédia pour un affichage sur un terminal. Plus particulièrement, l'invention concerne un procédé d'adaptation du format d'une scène multimédia pour l'affichage de cette scène sur un terminal. On entend par scène multimédia un ou plusieurs objets audio et/ou vidéo tels que du son, du texte, des images fixes, des images animées, des représentations en deux ou en trois dimensions ou encore toute combinaison de plusieurs de ces différents objets. Des scènes multimédia sont notamment, mais pas seulement, utilisées pour la fourniture d'applications ou de services multimédia sur des terminaux comme par exemple de la consultation de services d'information, de la gestion musicale, des services interactifs ou encore du téléchargement de logos, sonneries, jeux, séquences vidéo... Pour utiliser une scène multimédia dans une application ou un service multimédia, il est nécessaire que les objets audio et/ou vidéo qui composent cette scène multimédia soient identifiés, décrits et que leur restitution sonore et/ou visuelle, éventuellement dans le temps et dans l'espace, soit spécifiée. Ces différentes informations d'identification, de description et de restitution constituent une description de scène. Il existe plusieurs formats de description de scène parmi lesquels : - le format propriétaire Flash de la société Adobe, - le format standard SVG (pour Scalable Vector Graphics en anglais) développé par le World Wide Web Consortium (W3C), - le format standard BIFS (pour Blnary Format for Scene en anglais) développé par l'organisme de normalisation ISO (pour International Organization for Standardization en anglais) (ISO/IEC 14496-11: Scene description and application engine), - le format standard LASeR (pour Lightweight Application Scene Representation en anglais) développé par l'organisme de normalisation ISO (ISO/IEC 14496-20: Information technology ù Coding of audio-visual objects ù Part 20: Lightweight Application Scene Representation (LASeR) and Simple Aggregation Format (SAF)). Ce format est basé sur le format SVG. Pour afficher une scène multimédia, un terminal utilise soit un programme dédié à une application ou à un service multimédia donné soit un lecteur de description de scène. L'inconvénient d'une solution basée sur un programme dédié est que le déploiement de nouvelles applications ou de nouveaux services multimédia nécessite le développement et l'implémentation de nouveaux programmes dédiés, aptes à interpréter ces nouvelles applications ou ces nouveaux services. L'utilisation d'un lecteur de description de scène présente aussi des inconvénients dus aux formats de description de scène. Les formats Flash et SVG permettent de produire des images à partir de graphiques vectoriels. Ces graphiques vectoriels sont une représentation d'objets visuels géométriques (lignes, points, polygones, courbes...) ayant des attributs de forme, de position, de couleur... L'inconvénient des formats Flash et SVG est qu'ils sont limités à la description d'objets en deux dimensions. Le format BIFS a été spécifié par le groupe de travail SC 29/WG 11 du comité technique mixte JTC 1 de l'ISO dont les travaux s'inscrivent dans le cadre du groupe d'experts MPEG (en anglais pour Moving Picture Experts Group) qui ont défini la norme de codage de scènes audiovisuelles MPEG-4. Le format BIFS permet de décrire des scènes multimédia comportant des objets en deux ou trois dimensions ou encore un mélange des deux. Le format BIFS est basé sur le langage binaire VRML (pour Virtual Reality Modeling Language en anglais) de description d'objets en trois dimensions auquel on a ajouté des particularités, comme le traitement d'objets en deux dimensions et la possibilité de mélanger des objets en deux dimensions et des objets en trois dimensions. Pour être lu et interprété par un terminal, le format BIFS nécessite l'implémentation sur ce terminal d'un programme informatique écrit en langage de programmation informatique comme par exemple Java. L'exécution d'un tel programme requiert la mise en oeuvre sur le terminal d'un environnement d'exécution informatique spécifique. L'exécution de ce type de programme informatique nécessite également qu'un ensemble de bibliothèques comportant des requêtes d'accès aux ressources et fonctions du terminal (comme par exemple l'accès au clavier du terminal ou la connexion à un réseau) soit défini. Par exemple, pour Java, ces bibliothèques sont appelées JSR (pour Java Specification Requests en anglais). L'utilisation du format BIFS pour la description d'une scène multimédia destinée à être affichée sur un terminal présente des inconvénients liés au format BIFS lui-même et des inconvénients liés au langage de programmation Java. Concernant le format BIFS, celui-ci est très complexe ce qui rend son utilisation impossible sur un terminal dont les capacités en taille mémoire sont restreintes et dont l'autonomie en énergie est limitée. L'exécution du programme informatique destiné à lire et interpréter le format BIFS est commandée par le processeur du terminal. Or, le processeur du terminal peut être peu puissant notamment pour un terminal de taille réduite. De plus, l'exécution de ce programme informatique peut nécessiter de passer par l'intermédiaire de l'environnement d'exécution spécifique requis par l'utilisation d'un langage de programmation tel que Java. L'enchaînement de ces opérations combiné le cas échéant à la faible puissance d'un processeur rend l'exécution du programme informatique destiné à lire et interpréter le format BIFS très lente. Par ailleurs, les bibliothèques comportant les requêtes d'accès aux fonctions du terminal sont figées et non extensibles donc si une requête manque, il n'est pas possible de l'ajouter. Le format de description de scène LASeR a lui aussi été défini par le groupe de travail SC 29/WG 11 du comité technique mixte JTC 1 de l'ISO dans le but de palier les inconvénients dus à la complexité du format BIFS. Cependant, il présente l'inconvénient de ne pas pouvoir décrire de scènes multimédia comportant des objets en trois dimensions. Par conséquent, certains des formats de description de scène décrits précédemment, ne permettent pas l'affichage sur un terminal, par l'intermédiaire d'un lecteur de description de scène, de scènes multimédia comportant des objets audio et/ou vidéo en deux et trois dimensions. Les autres formats présentent une telle complexité que ce type d'affichage est difficile à mettre en oeuvre sur la plupart des terminaux et impossible sur des terminaux de taille mémoire et de capacité en énergie limitées. Il existe donc le besoin d'une technique permettant à n'importe quel terminal d'afficher des scènes multimédia comportant tous types d'objets audio et/ou vidéo, par l'intermédiaire d'un lecteur de description de scène. A cet effet, l'invention a pour objet procédé d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, caractérisé en ce qu'il comporte des étapes de : - extraction du graphe de scène initial de la scène multimédia, - codage du graphe de scène initial sous un format modifié de graphe de scène pour obtenir un graphe de scène modifié, -lecture du graphe de scène initial pour détecter et extraire des noeuds d'interactivité et des noeuds image, - codage d'un contenu d'un champ adresse des noeuds d'interactivité sous un format précompilé de représentation d'un noeud d'interactivité pour obtenir un contenu modifié d'un champ adresse des noeuds d'interactivité. Le procédé d'adaptation du format d'une scène multimédia pour l'affichage de cette scène sur un terminal porte d'une part sur la modification du format de représentation du graphe de scène qui correspond à la description de cette scène multimédia et d'autre part sur la modification du format de représentation du contenu du champ adresse des noeuds d'interactivité, éléments constitutifs du graphe de scène. Les deux nouveaux formats définis dans le cadre de l'invention sont plus simples que les formats de description de scène de l'état de l'art décrits précédemment. Ils sont également plus rapides à exécuter, nécessitent moins de capacité mémoire et un processeur de moindre puissance. Ainsi, le procédé de l'invention, permet l'affichage de tout type de scène multimédia, en particulier des scènes contenant des objets audio et/ou vidéo en deux et trois dimensions sur des terminaux ayant une mémoire et un processeur de capacités limitées. Selon une caractéristique préférée, l'étape de lecture du graphe de scène initial comporte la détection et l'extraction de noeuds d'appel, et le procédé d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, comporte une étape de traitement des noeuds d'appel selon un processus récursif qui, pour une scène appelée par un noeud d'appel et représentée sous la forme d'un graphe de scène initial, comporte des sous- étapes de : - extraction du graphe de scène initial de la scène appelée, - codage du graphe de scène initial de la scène appelée sous un format modifié de graphe de scène pour obtenir un graphe de scène modifié de la scène appelée, - lecture du graphe de scène initial de la scène appelée pour détecter et extraire des noeuds d'interactivité de la scène appelée et des noeuds image de la scène appelée, - codage d'un contenu d'un champ adresse des noeuds d'interactivité de la scène appelée sous un format précompilé de représentation d'un noeud d'interactivité pour obtenir un contenu modifié d'un champ adresse des noeuds d'interactivité de la scène appelée. L'application récursive du procédé selon l'invention aux scènes appelées facilite l'exécution de scènes multimédia en cascade. Selon une caractéristique préférée, le procédé d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, comporte une étape d'identification des images correspondant aux noeuds image. L'identification des images utilisées dans la scène multimédia permet de les enregistrer spécifiquement et d'y accéder plus rapidement. Selon une caractéristique préférée, le procédé d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, comporte une étape d'enregistrement dans un fichier de sauvegarde du graphe de scène modifié, du contenu modifié d'un champ adresse des noeuds d'interactivité, des images correspondant aux noeuds image. Ainsi, l'enregistrement de toutes les données utiles à l'affichage d'une scène multimédia par un terminal dans un seul et même fichier de sauvegarde simplifie l'accès à ces données. La mutualisation des données utilisées à plusieurs reprises, comme par exemple une même image qui apparaît plusieurs fois lors de l'affichage de la scène multimédia, réduit la capacité mémoire nécessaire à l'affichage de cette scène et les temps de connexion pour accéder à une image sont optimisés. Selon une caractéristique préférée, dans le format modifié de représentation d'un graphe de scène, un noeud comporte des champs, est désigné par un identifiant et est caractérisé par un type. Dans le format modifié de représentation d'un graphe de scène selon l'invention, un noeud étant désigné par un identifiant et donc accessible par ce identifiant rend l'exécution du programme d'affichage de la scène multimédia plus rapide. Par ailleurs, l'utilisation de types pour caractériser un noeud et la réutilisation par plusieurs noeuds des mêmes caractéristiques réduit la capacité mémoire nécessaire à la description de la scène multimédia considérée. Ainsi, l'utilisation du format modifié de représentation d'un graphe de scène de l'invention limite la capacité mémoire et la puissance du processeur nécessaires à l'affichage de la scène multimédia sur un terminal. Selon une caractéristique préférée, le format précompilé de représentation d'un noeud d'interactivité est un langage de type assembleur. Ainsi, l'utilisation d'un format précompilé de représentation d'un noeud d'interactivité basé sur un langage de type assembleur et comportant un nombre restreint d'instructions conduit à une représentation réduite, facile à implémenter et à interpréter. Ceci répond aux contraintes des terminaux dont la capacité mémoire et la puissance du processeur sont limitées. Selon une caractéristique préférée, le format de la scène multimédia correspond à l'un des formats suivants : LASER, BIFS, VRML, SVG, LASeR textuel, BIFS textuel. En adaptant différents formats d'une scène multimédia, l'invention rend accessible à un terminal toute sorte de scène multimédia incluant des objets audio et/ou vidéo et en particulier des objets vidéo combinant des représentations en deux et en trois dimensions. L'invention s'appuie sur des standards existants dont les performances permettent d'envisager le développement d'applications et de services multimédia très variés pour des terminaux mobiles. L'invention a également pour objet un dispositif d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, caractérisé en ce qu'il comporte : - un module d'extraction du graphe de scène initial de la scène multimédia, -un module de codage du graphe de scène initial sous un format modifié de graphe de scène pour obtenir un graphe de scène modifié, - un module de lecture du graphe de scène initial pour obtenir des noeuds d'interactivité initiaux et des noeuds image, - un module de codage d'un contenu d'un champ adresse des noeuds d'interactivité sous un format précompilé de représentation d'un noeud d'interactivité pour obtenir un contenu modifié d'un champ adresse des noeuds d'interactivité. L'invention porte aussi sur un serveur de communication à travers un réseau comprenant un dispositif d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal tel que décrit précédemment. L'invention a également pour objet un terminal apte à solliciter à travers un réseau un dispositif d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur ledit terminal tel que décrit ci-dessus. L'invention porte aussi sur un programme d'ordinateur comportant des instructions pour mettre en oeuvre le procédé décrit précédemment. L'invention sera mieux comprise à la lumière de la description qui suit d'un mode particulier de réalisation du procédé selon l'invention en référence aux dessins annexés sur lesquels : - la figure 1 représente un organigramme du procédé de l'invention d'adaptation du format d'une scène multimédia pour l'affichage de cette scène sur un terminal, - la figure 2 représente la structure d'un fichier de sauvegarde mis en oeuvre par le procédé de la figure 1, - la figure 3 illustre un exemple de remplissage d'un fichier de sauvegarde selon la figure 3, - la figure 4 représente un dispositif apte à mettre en oeuvre le procédé de la figure 1. Dans le mode de réalisation décrit ci-après, l'invention repose sur les caractéristiques du format BIFS qui est un langage binaire qui permet de décrire une scène multimédia et de la modifier dynamiquement. La description d'une scène multimédia au format BIFS est représentée par un graphe de scène. Un graphe de scène correspond à une représentation hiérarchique des différents objets audio et/ou visuels qui composent la scène multimédia considérée. Chaque objet audio et/ou visuel est représenté par un noeud (node en anglais). Un noeud est lui-même composé d'un ou plusieurs champs (field en anglais) qui définissent les caractéristiques et le comportement de ce noeud comme par exemple sa taille, sa couleur, son mouvement... Certains noeuds peuvent comporter des champs qui contiennent des noeuds d'où une structure hiérarchique encore appelée structure en arbre (tree structure en anglais). Il existe une centaine de noeuds permettant de décrire une scène multimédia parmi lesquels : - le noeud d'interactivité (script node en anglais). Ce noeud contient un mini programme informatique dont l'exécution entraine un changement dans le graphe de scène. Par exemple, on peut citer le mouvement d'une barre de défilement dans un menu affiché sur l'écran d'un terminal. Le déplacement de cette barre, sollicité par un utilisateur qui appuie sur une touche de fonction du terminal, est commandé par un noeud d'interactivité. L'exécution du mini programme informatique contenu dans le noeud d'interactivité entraine un changement dans le noeud qui décrit la barre de défilement. Ce changement correspond au mouvement que doit accomplir la barre de défilement pour exécuter le déplacement sollicité. -le noeud image (image texture node en anglais). Un tel noeud décrit une image. Dans l'exemple précédent, la barre de défilement est représentée par un noeud image. - le noeud d'appel (inline node en anglais) Ce noeud permet, à partir d'une scène multimédia, d'appeler une autre scène multimédia. Par exemple, un utilisateur sélectionne un item dans un menu à l'aide d'une barre de défilement. Si l'item sélectionné commande l'ouverture d'une nouvelle application mettant en oeuvre une scène multimédia alors cette scène multimédia est appelée par un noeud d'appel. Chaque noeud est défini par un ou plusieurs champs parmi lesquels le champ adresse (url field en anglais). Le champ adresse contient une chaîne de caractères. Cette chaîne de caractères correspond à des adresses URL (pour Uniform Resource Locator en anglais) pointant vers des données interprétables ou cette chaîne de caractères correspond directement à des données interprétables. Les données interprétables représentent un mini programme informatique écrit en langage de programmation ECMAScript. Pour un noeud d'interactivité, le champ adresse contient directement un mini programme informatique écrit en langage de programmation ECMAScript. Dans le cas d'un noeud image, le champ adresse pointe vers une image. Pour un noeud d'appel, le champ adresse pointe vers une description de scène correspondant à la scène multimédia appelée via ce noeud. En référence à la figure 1, on décrit ci-après le procédé de l'invention dans une application particulière à un terminal qui sollicite l'exécution d'une application de consultation d'un catalogue vidéo. A l'étape 11, un lecteur de description de scène ouvre et lit un "fichier BIFS" contenant une scène multimédia qui représente le catalogue vidéo et destinée à être affichée sur le terminal. Le lecteur de description de scène est hébergé sur un serveur qui est interrogé par le terminal par l'intermédiaire d'un autre lecteur (player en anglais). Ce dernier lecteur est présent en natif dans le terminal ou téléchargé dans le terminal lors de l'exécution de l'application de consultation du catalogue vidéo. Pour la mise en oeuvre de l'application de consultation d'un catalogue vidéo, le lecteur de description de scène lit le "fichier BIFS" et interprète les données et instructions contenues dans les différents noeuds de ce fichier. Ces données et instructions ainsi interprétées sont transmises au lecteur du terminal qui les fait exécuter, permettant ainsi l'affichage du catalogue vidéo selon les caractéristiques contenues dans les différents noeuds. Pour la mise en oeuvre de l'invention, dans un premier temps, le lecteur de description de scène extrait du fichier la description de la scène multimédia, autrement dit, le lecteur de description de scène extrait le graphe de scène représentatif de la scène multimédia. Il s'agit d'un ensemble de données binaires qui correspondent au graphe de scène. Ces données binaires décrivent les noeuds correspondant aux objets audio et/ou vidéo qui composent le catalogue vidéo. Dans un second temps, les données binaires représentatives du graphe de scène précédemment extraites sont décodées. Au cours de ce décodage, on identifie parmi la liste de tous les noeuds possibles, ceux qui sont utilisés pour décrire la scène. On obtient ainsi un ensemble de noeuds au format binaire parmi lesquels des noeuds d'interactivité, des noeuds image et des noeuds d'appel. Les données binaires des champs de chacun des noeuds obtenus sont elles aussi décodées. Au cours de ce décodage, on identifie les champs qui sont renseignés et les valeurs correspondantes, en particulier pour le champ adresse. L'ensemble des noeuds décodés ainsi obtenus constitue un premier graphe de scène au format binaire que l'on désigne par l'expression "graphe de scène initial". Ce graphe de scène initial est enregistré dans la mémoire d'exécution du programme lié à l'application de consultation d'un catalogue vidéo. En référence à la figure 1, à l'étape 12, le graphe de scène initial est codé selon un nouveau format de représentation d'un graphe de scène. Dans ce nouveau format, outre le fait qu'un noeud comporte des champs tel que décrit précédemment, un noeud possède également les caractéristiques suivantes : il est codé sur un nombre restreint d'octets, par exemple un octet, il est désigné par un identifiant de noeud qui peut être un numéro et il est caractérisé par un "type". On identifie trois "types" : un "premier type" est affecté aux noeuds qui ne présentent aucune caractéristique particulière, puis pour les noeuds qui apparaissent plusieurs fois dans le graphe de scène, la première occurrence est définie par un "deuxième type" et les occurrences suivantes par un "troisième type". Par exemple, si une scène multimédia comporte une voiture avec quatre roues, on affecte le "deuxième type" au noeud qui représente une première roue, on lui affecte un identifiant et on renseigne un ensemble de champs pour décrire les propriétés de la roue (taille, couleur, mouvement...). Pour décrire les trois roues suivantes, on les représente par un noeud auquel on affecte le "troisième type". Pour ces trois roues, on ne décrit pas les champs du noeud qui les caractérise, on renvoie vers les champs du noeud décrivant la première roue auxquels on accède en spécifiant l'identifiant de ce noeud. Ainsi, la mutualisation de données communes à plusieurs noeuds permet d'obtenir une représentation du graphe de scène de taille réduite et plus rapide à lire. A l'issue de l'étape 12, on dispose d'un graphe de scène qui comporte le même nombre de noeuds et des noeuds de même nature que le graphe de scène initial extrait à l'étape 11, mais dont le format est différent. On désigne par "format modifié de graphe de scène", ce nouveau format de représentation du graphe de scène dont les propriétés ont été décrites précédemment. De même, on convient d'appeler "graphe de scène modifié", GM, le graphe de scène codé sous le "format modifié de graphe de scène". Cette première version du graphe de scène modifié GM est enregistrée dans une partie PGM d'un fichier de sauvegarde FS tel que décrit ci-dessous au cours de l'étape 17. En référence à la figure 1, l'étape 13 est la lecture du graphe de scène initial enregistré à l'étape 11 dans la mémoire d'exécution du programme lié à l'application de consultation d'un catalogue vidéo. Au cours de cette lecture du graphe de scène initial, on détecte et on extrait les noeuds d'interactivité, les noeuds image et les noeuds d'appel contenus dans ce graphe de scène initial. Puis, chacun des noeuds précédemment extraits est traité au cours des étapes 14 à 16 décrites ci-après. L'étape 14 représentée à la figure 1 est le codage des noeuds d'interactivité qui s'effectue par la lecture et le codage du contenu du champ adresse des noeuds d'interactivité. Le but de ce codage est d'obtenir des noeuds d'interactivité plus compacts, donc moins volumineux à stocker et plus facilement et rapidement interprétables. Au cours d'une première phase, on lit le contenu du champ adresse des noeuds d'interactivité. Pour une scène multimédia dont le graphe de scène est décrit au format BIFS, ce champ contient une chaîne de caractères correspondant à un mini programme écrit en langage de programmation ECMAScript. Pour l'exécution de ce mini programme, le lecteur du terminal sollicite un interprète du langage ECMAScript. Le rôle de cet interprète est de lire, analyser, traduire et exécuter successivement les instructions contenues dans ce programme. Au cours d'une deuxième phase, on modifie le format de la chaîne de caractères contenue dans le champ adresse des noeuds d'interactivité du graphe de scène initial. Ainsi, une instruction du programme, contenu dans le champ adresse et écrit en langage de programmation ECMAScript, est décrite par une ou plusieurs macro-instructions d'un nouveau format. Ce nouveau format de représentation du champ adresse correspond à un langage précompilé et on le désigne par l'expression "format précompilé de représentation d'un noeud d'interactivité". Le format précompilé de représentation d'un noeud d'interactivité comporte un nombre limité d'instructions fonctionnant avec des registres et permettant d'effectuer des calculs, des comparaisons, des sauts conditionnels ainsi que des appels à des fonctions externes. Le format précompilé de représentation d'un noeud d'interactivité se caractérise par sa capacité à gérer des données de différents types (nombre entier, nombre décimal, chaîne de caractères, durée...). Les opérations effectuées entre deux données dépendent du type de ces données. Par exemple, l'addition d'un nombre entier et d'un nombre décimal produit un nombre décimal tandis que l'addition d'une chaîne de caractères et d'un nombre entier produit une chaîne de caractères correspondant à la concaténation de la chaîne de caractères initiale avec la représentation littérale du nombre entier. Une autre caractéristique du format précompilé de représentation d'un noeud d'interactivité est qu'il référence chacun des champs d'un noeud d'interactivité par un index. Dans le cas d'un champ adresse écrit en langage ECMAScript, l'accès aux champs d'un noeud d'interactivité, puis récursivement, l'accès aux champs de ces champs se fait par lecture puis interprétation du langage ECMAScript. Dans le cas du format précompilé de représentation d'un noeud d'interactivité, l'accès en cascade à des champs se fait par lecture d'index successifs. L'utilisation du format précompilé de représentation d'un noeud d'interactivité pour décrire le mini programme contenu dans le champ adresse du noeud d'interactivité considéré facilite l'exécution de ce mini programme. En effet, le rôle de l'interprète nécessaire à l'exécution de ce mini programme se limite à l'exécution du mini programme. Les opérations de lecture, analyse et traduction du code sont réalisées préalablement, lors du changement de format, c'est-à-dire lors du passage du format ECMAScript au format précompilé de représentation d'un noeud d'interactivité. Ainsi, le mini programme au format précompilé de représentation d'un noeud d'interactivité contenu dans le champ adresse de ce noeud est plus compact. Il est également plus simple et donc l'interprète nécessaire au niveau du terminal pour son interprétation et son exécution est plus simple et moins volumineux qu'un interprète du langage ECMAScript. A l'issue de cette deuxième phase de l'étape 14, on obtient, pour chaquenoeud d'interactivité extrait à l'étape 13, une nouvelle version du contenu du champ adresse que l'on appelle contenu modifié CM du champ adresse. Au cours d'une troisième phase de l'étape 14, on réalise successivement les deux opérations suivantes : - la première opération est l'enregistrement dans une partie PcM du fichier de sauvegarde FS, tel que décrit à l'étape 17, du contenu modifié CM du champ adresse de chaque noeud d'interactivité après codage, - la deuxième opération est la modification de la première version du graphe de scène modifié GM, enregistrée dans la partie PGM du fichier de sauvegarde FS à l'issue de l'étape 12. Pour cela, on remplace, dans cette première version du graphe de scène modifié GM, le contenu du champ adresse de chaque noeud d'interactivité codé, à savoir le mini programme en langage de programmation ECMAScript, par l'adresse dans le fichier de sauvegarde FS de la partie PcM dans laquelle est enregistré le contenu modifié CM du champ adresse. On obtient ainsi une deuxième version du graphe de scène modifié GM que l'on enregistre dans la même partie PGM du fichier de sauvegarde FS que précédemment. En référence à la figure 1, l'étape 15 est l'étape de traitement des noeuds image. Tout d'abord, pour un noeud image, extrait à l'étape 13 de lecture du graphe de scène binaire, on identifie l'image I correspondant à ce noeud image et on l'enregistre dans une partie P, du fichier de sauvegarde FS tel que décrit à l'étape 17 ci-après. Ensuite, on modifie, dans la deuxième version du graphe de scène modifié GM et enregistrée à l'issue de l'étape 14, le champ adresse du noeud image considéré. Pour ce faire, on indique, dans ce champ adresse, dans quelle partie P, du fichier de sauvegarde FS se trouve l'image correspondante enregistrée. On obtient ainsi une troisième version du graphe de scène modifié GM que l'on enregistre dans la même partie PGM du fichier de sauvegarde FS que précédemment. Au cours de l'étape 16 représentée à la figure 1, on traite les noeuds d'appel extraits au cours de l'étape 13. Tout d'abord, on lit le contenu du champ adresse des noeuds d'appel obtenus. Pour une scène multimédia dont le graphe de scène est décrit au format BIFS, le champ adresse d'un noeud d'appel pointe vers la description d'une nouvelle scène multimédia que l'on désigne par scène appelée. Le traitement des noeuds d'appel est un processus récursif qui commence à l'étape 11 avec l'extraction du graphe de scène au format initial de la scène appelée et qui déroule les étapes 11 à 15 décrites précédemment. Au cours du traitement d'un noeud d'appel, on obtient, pour la scène appelée, un graphe de scène modifié désigné par graphe de scène modifié de la scène appelée, un contenu modifié du champ adresse des noeuds d'interactivité désigné par contenu modifié du champ adresse des noeuds d'interactivité de la scène appelée, des images correspondant à des noeuds image désignées par images de la scène appelée. Si la scène appelée comporte des noeuds d'appel, c'est-à-dire si elle- même appelle de nouvelles scènes multimédia alors, on reproduit récursivement le même procédé. A l'issue de l'étape 16, on enregistre le graphe de scène modifié de la scène appelée, le contenu modifié du champ adresse des noeuds d'interactivité de la scène appelée et les images de la scène appelée, chacun respectivement dans une partie du fichier de sauvegarde FS qui lui est propre tel que décrit au cours de l'étape 17. Ensuite, on modifie, dans la troisième version du graphe de scène modifié GM enregistrée à l'étape 15, les champs adresse des noeuds d'appel qui ont été détectés et extraits à l'étape 13. Pour cela, on identifie dans quelle partie du fichier de sauvegarde FS se trouve le graphe de scène modifié de la scène appelée. On obtient ainsi une quatrième version du graphe de scène modifié GM que l'on enregistre dans la même partie PGM du fichier de sauvegarde FS que précédemment. En référence à la figure 1, l'étape 17 est une étape d'enregistrement. En référence à la figure 2, le fichier de sauvegarde FS est structuré de telle sorte que chaque élément E enregistré occupe une partie PE (chunk en anglais) du fichier de sauvegarde FS indépendante des autres parties. Une partie PE du fichier de sauvegarde FS comprend un identifiant numérique IN désignant la partie considérée, un identifiant textuel IT correspondant au nom de l'élément E sauvegardé, un identifiant numérique IL correspondant à la longueur des données sauvegardées et les données D de l'élément E sauvegardé. A titre d'exemple, la figure 3 illustre la structure d'un exemple de fichier de sauvegarde EFS lorsqu'une scène multimédia désignée par l'expression scène appelante appelle une autre scène multimédia désignée par l'expression scène appelée. Pour l'exemple on considère que la scène multimédia appelante comporte deux noeuds d'interactivité N1 et N2, trois noeuds image NI1, NI2 et NI3 et un noeud d'appel de la scène multimédia appelée. Toujours pour l'exemple, on considère que la scène multimédia appelée comporte un noeud d'interactivité N3 et quatre noeuds image NI1, NI3, NI4 et NI5. Le déroulement des étapes 11 et 12 fournit le graphe de scène modifié de la scène appelante enregistré dans la partie P1 de l'exemple de fichier de sauvegarde EFS. Au cours du déroulement des étapes 13 à 15, on obtient le contenu modifié du champ adresse des noeuds d'interactivité N1 et N2 de la scène appelante que l'on appelle respectivement CM1 et CM2. On obtient également les images 11, 12 et 13 correspondant respectivement aux noeuds image NI1, N I2 et NI3. Le contenu modifié du champ adresse des noeuds d'interactivité CM1 et CM2 ainsi que les images 11, 12 et 13 de la scène appelante sont enregistrés respectivement dans les parties P2, P3, P6, P7 et P8 de l'exemple de fichier de sauvegarde EFS. Les versions successives du graphe de scène modifié de la scène appelante obtenues au cours des étapes 13 à 15 sont à chaque fois enregistrées dans la partie P1 de l'exemple de fichier de sauvegarde EFS. Le déroulement des étapes 13 et 16 aboutit à l'obtention du graphe de scène modifié de la scène appelée, du contenu modifié CM3 du champ adresse du noeud d'interactivité N3 et à l'obtention des images 11, 13, 14 et 15 correspondant respectivement aux noeuds image NI1, NI3, NI4 et NI5. Le graphe de scène modifié de la scène appelée est enregistré dans la partie P4 de l'exemple de fichier de sauvegarde EFS. Le contenu modifié CM3 du champ adresse du noeud d'interactivité N3 est enregistré dans la partie P5 de l'exemple de fichier de sauvegarde EFS. Les images 14 et 15 de la scène appelée sont enregistrées respectivement dans les parties P9 et P10 de l'exemple de fichier de sauvegarde EFS. Les images 11 et 13 ne sont pas à nouveau enregistrées puisque enregistrées lors du traitement de l'image multimédia appelante. Ainsi, avant la mise en oeuvre de l'invention, la scène multimédia à afficher sur un terminal est au format BIFS, elle est décrite dans un "fichier BIFS", le graphe de scène représentatif de la scène multimédia est au format binaire et le champ adresse des noeuds d'interactivité contient un miniprogramme informatique codé en langage ECMAScript. Après la mise en oeuvre du procédé selon l'invention, la scène multimédia à afficher sur un terminal est décrite dans un fichier de sauvegarde FS dont la structure est détaillée ci-dessus, le graphe de scène est codé selon un "format modifié de graphe de scène" et le contenu du champ adresse des noeuds d'interactivité correspond à un mini programme informatique codé selon un "format précompilé de représentation d'un noeud d'interactivité". L'affichage sur un terminal de la scène multimédia considérée s'effectue par l'intermédiaire d'un lecteur de description de scène qui lit et interprète le contenu du fichier de sauvegarde FS. La figure 4 illustre un dispositif 40 d'adaptation du format d'une scène multimédia pour l'affichage de cette scène sur un terminal. Ce dispositif comprend un module 41 d'extraction d'un graphe de scène initial d'une scène multimédia. En référence à l'étape 11, ce module reçoit un fichier contenant les données binaires de description d'une scène multimédia et en extrait les données binaires représentatives du graphe de scène associé à la scène multimédia considérée. Le module 41 d'extraction restitue un graphe de scène au format binaire désigné par "graphe de scène initial". Le dispositif 40 comprend aussi un module 42 de codage d'un graphe de scène initial qui modifie le format du graphe de scène initial obtenu précédemment pour obtenir un graphe de scène modifié tel que décrit à l'étape 12. Le module 42 de codage du graphe de scène initial sollicite un module 47 d'enregistrement décrit ci-dessous pour l'enregistrement du graphe de scène modifié dans un fichier de sauvegarde FS. En référence à l'étape 13, le dispositif 40 comporte un module 43 de lecture d'un graphe de scène initial, tel que celui restitué par le module 41 d'extraction. Ce module 43 de lecture permet de détecter et d'extraire des noeuds d'interactivité, des noeuds image et des noeuds d'appel contenus dans le graphe de scène initial. Le dispositif comprend en outre un module 44 de codage de noeuds d'interactivité. En référence à l'étape 14, le module 44 de codage de noeuds d'interactivité décode le contenu du champ adresse des noeuds d'interactivité initiaux au format binaire extraits par le module 43 de lecture d'un graphe de scène binaire et les code sous un format précompilé de représentation d'un noeud d'interactivité. A l'issue du traitement effectué par le module 44 de codage de noeuds d'interactivité, on obtient un contenu modifié du champ adresse des noeuds d'interactivité. Le module 44 de codage de noeuds d'interactivité procède également à la mise à jour du graphe de scène modifié fourni par le module 42 de codage d'un graphe de scène initial. Ensuite, le module 44 de codage de noeuds d'interactivité sollicite le module 47 d'enregistrement pour l'enregistrement dans un fichier de sauvegarde FS du contenu modifié du champ adresse des noeuds d'interactivité et d'une nouvelle version du graphe de scène modifié. Le dispositif 40 comprend aussi un module 45 de traitement de noeuds image. En référence à l'étape 15, le module 45 de traitement de noeuds image identifie l'image correspondant à un noeud et sollicite le module 47 d'enregistrement pour enregistrer dans un fichier de sauvegarde FS les images ainsi identifiées. Le module 45 de traitement de noeuds image modifie également la version du graphe de scène restituée par le module 44 de traitement de noeuds d'interactivité et fait enregistrer cette nouvelle version par le module 47 d'enregistrement. Le dispositif 40 comprend également un module 46 de traitement de noeuds d'appel. En référence à l'étape 16, le module 46 de traitement de noeuds d'appel sollicite les différents modules 41 à 45 et 47 pour le traitement de la scène multimédia identifiée dans le noeud d'appel traité. En référence à l'étape 17, le dispositif 40 comporte un module 47 d'enregistrement dans un fichier de sauvegarde FS des éléments restitués par les modules 42, 44, 45 et 46. Le dispositif 40 comprend en outre une unité centrale de commande, non représentée, connectée à chacun des modules 41 à 47 et adaptée pour commander leur fonctionnement. Les modules 41 à 47 ainsi que l'unité centrale de commande peuvent être des modules logiciels formant un programme d'ordinateur. L'invention concerne donc également un programme d'ordinateur pour un dispositif d'adaptation du format d'une scène multimédia pour l'affichage de cette scène sur un terminal comprenant des instructions logicielles pour faire exécuter le procédé précédemment décrit par le dispositif. Le module logiciel peut être stocké dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support transmissible tel qu'un signal électrique, optique ou radio. Le dispositif 40 d'adaptation du format d'une scène multimédia pour l'affichage de cette scène sur un terminal peut être incorporé dans un serveur de communication intégré dans un réseau. L'invention concerne aussi un tel serveur. Le dispositif 40 d'adaptation du format d'une scène multimédia pour l'affichage de cette scène sur un terminal peut être sollicité au travers du réseau puis intégré dans un terminal. L'invention concerne aussi un tel terminal. Dans le mode particulier de réalisation de l'invention décrit ci-dessus le format de la scène multimédia qui est adapté est un format BIFS. Dans d'autres modes de réalisation, le format de la scène multimédia à adapter peut être de type LASER, VRML, SVG, LASeR textuel ou BIFS textuel. Pour une scène multimédia au format LASER, le graphe de scène initial se présente sous un format binaire. Dans les autres cas, le graphe de scène initial de la scène multimédia se présente sous un format texte. Le procédé de l'invention s'applique aux terminaux mobiles qui sont contraints en taille de mémoire et en autonomie d'énergie quel que soit le système d'exploitation utilisé (J2ME, Windows Mobile ou Symbian OS). Le procédé de l'invention s'applique également à des terminaux qui présentent moins de contraintes tels que les ordinateurs de bureau ou les ordinateurs portables. REVENDICATIONS 1. Procédé d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, caractérisé en ce qu'il comporte des étapes de : - extraction (11) du graphe de scène initial de la scène multimédia, - codage (12) du graphe de scène initial sous un format modifié de graphe de scène pour obtenir un graphe de scène modifié, - lecture (13) du graphe de scène initial pour détecter et extraire des noeuds d'interactivité et des noeuds image, - codage (14) d'un contenu d'un champ adresse des noeuds d'interactivité sous un format précompilé de représentation d'un noeud d'interactivité pour obtenir un contenu modifié d'un champ adresse des noeuds d'interactivité. 2. Procédé selon la revendication 1, caractérisé en ce que - l'étape de lecture (13) du graphe de scène initial comporte la détection et l'extraction de noeuds d'appel, et - en ce qu'il comporte une étape de traitement (16) des noeuds d'appel selon un processus récursif qui, pour une scène appelée par un noeud d'appel et représentée sous la forme d'un graphe de scène initial, comporte des sous-étapes de : extraction du graphe de scène initial de la scène appelée, codage du graphe de scène initial de la scène appelée sous un format modifié de graphe de scène pour obtenir un graphe de scène modifié de la scène appelée, lecture du graphe de scène initial de la scène appelée pour détecter et extraire des noeuds d'interactivité de la scène appelée et des noeuds image de la scène appelée,codage d'un contenu d'un champ adresse des noeuds d'interactivité de la scène appelée sous un format précompilé de représentation d'un noeud d'interactivité pour obtenir un contenu modifié d'un champ adresse des noeuds d'interactivité de la scène appelée. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comporte une étape d'identification des images correspondant aux noeuds image. 10 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte aussi une étape (17) de : - enregistrement dans un fichier de sauvegarde (FS) du graphe de scène modifié, du contenu modifié d'un champ adresse des noeuds d'interactivité, des images correspondant aux noeuds image. 15 5. Procédé selon la revendication 1 ou 2, caractérisé en ce que, dans le format modifié de représentation d'un graphe de scène, un noeud comporte des champs, est désigné par un identifiant et est caractérisé par un type. 20 6. Procédé selon la revendication 1 ou 2, caractérisé en ce que le format précompilé de représentation d'un noeud d'interactivité est un langage de type assembleur. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé 25 en ce que le format de la scène multimédia correspond à l'un des formats suivants : - LASER, - BIFS, - VRML, 30 - SVG, - LASeR textuel,5- BIFS textuel. 8. Dispositif (40) d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, caractérisé en ce qu'il comporte : - un module (41) d'extraction du graphe de scène initial de la scène multimédia, - un module (42) de codage du graphe de scène initial sous un format modifié de graphe de scène pour obtenir un graphe de scène modifié, - un module (43) de lecture du graphe de scène initial pour obtenir des noeuds d'interactivité initiaux et des noeuds image, - un module (44) de codage d'un contenu d'un champ adresse des noeuds d'interactivité sous un format précompilé de représentation d'un noeud d'interactivité pour obtenir un contenu modifié d'un champ adresse des noeuds d'interactivité. 9. Serveur de communication à travers un réseau, comprenant un dispositif d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur un terminal, selon la revendication 8. 10. Terminal apte à solliciter à travers un réseau un dispositif d'adaptation du format d'une scène multimédia, représentée sous la forme d'un graphe de scène initial, pour l'affichage de cette scène sur ledit terminal, selon la revendication 8. 11. Programme d'ordinateur comportant des instructions pour mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 7 lorsque le procédé est exécuté par un ordinateur. 25