Procédés et dispositifs pour optimiser les ressources nécessaires à la présentation de contenus multimédias

La présente invention concerne le domaine des applications multimédias, notamment des applications multimédias pour clients légers tels que les téléphones mobiles et les boîtiers décodeurs (set-top box), et plus particulièrement des procédés et des dispositifs pour optimiser les ressources nécessaires à la présentation de contenus multimédias. Certaines applications multimédias permettent l'accès à un contenu multimédia composé, en particulier, de textes, d'images, de sons, de vidéo et de graphiques. Un tel contenu multimédia est parfois appelé média riche {rich content). Ces différents éléments peuvent être structurés et agrégés par une description de scène, spécifiant la restitution visuelle et sonore, éventuellement variant dans le temps du contenu multimédia.

Il existe plusieurs formats spécifiant une scène multimédia, aussi appelée scène graphique, notamment les formats suivants :

- le format propriétaire Flash de la société Adobe ;

- le format standard BIFS développé par l'organisme de standardisation ISO/IEC JTC1/SC29/WG1 1 (ISO/IEC 14496-

1 1 : Scène description and application engine) ;

- le format standard SVG (Scalable Vector Graphics) développé par l'organisme de standardisation Web Consortium (W3C) ; et, - le format standard LASeR développé par l'organisme de standardisation ISO/IEC JTC1/SC29/WG1 1 (ISO/IEC 14496- 20: Information technology — Coding of audio-visual objects — Part 20: Lightweight Application Scène Représentation (LASeR) and Simple Aggregation Format (SAF). Ce format est basé sur le format SVG, sur lequel il définit des extensions.

Ces différents formats de scène multimédia peuvent inclure des objets multimédias tels qu'une image, une vidéo ou un enregistrement audio.

Ces objets peuvent être codés dans plusieurs formats. Parmi ces formats, certains présentent une propriété intéressante appelée scalabilité. Un format est dit scalable lorsqu'il est possible de restituer une version adaptée du contenu en accédant à et en décodant une partie seulement des données. Il est par exemple possible d'adapter une vidéo en diminuant sa taille, sa fréquence temporelle ou sa qualité.

Selon le codage vidéo scalable, le train de bits (bit stream) est organisé selon une syntaxe hiérarchique permettant l'extraction des seules données nécessaires à la présentation du contenu multimédia. La scalabilité peut être, en particulier, spatiale et/ou temporelle. Elle peut également être liée à d'autres paramètres tels que la qualité des images ou du son ou la sélection d'une zone de la vidéo. Plusieurs types de scalabilité peuvent être utilisés simultanément. Par exemple, dans un flux de données vidéo de 720x576 pixels à 25 images par seconde, il est possible d'extraire une vidéo de résolution inférieure comme 360x288 pixels avec une fréquence temporelle inférieure telle que 10 images par seconde, sans qu'il soit nécessaire de décoder le contenu multimédia dans sa totalité, c'est-à-dire dans sa résolution maximale.

Il existe plusieurs formats de contenu multimédia scalable, notamment : - JPEG2000 développé par l'organisme de standardisation

ISO/IEC JTC1/SC29/WG1 (ISO/IEC 15444-1 :2004 : Core coding System) ; et,

- Scalable Video Coding (SVC) développé par l'organisme de standardisation ISO/IEC JTC1/SC29/WG1 1 (ISO/IEC 14496- 10, amendement 3 : Scalable Video Coding).

L'utilisation de tels formats pour un objet multimédia invoqué dans une scène multimédia permet, le cas échéant, d'obtenir, décoder et restituer une partie seulement des données, et ceci de façon optimale par rapport à leur utilisation dans la scène multimédia. Par ailleurs, certaines applications de télévision permettent de visualiser en même temps un programme principal affiché sur tout l'écran ainsi qu'un programme secondaire affiché selon une taille réduite, par exemple dans

un coin de l'écran. Généralement, l'application permet à l'utilisateur de basculer le mode d'affichage pour présenter le programme secondaire en plein écran et inversement. Ce type d'application, appelé Picture in Picture en anglais, est appelé image dans l'image dans la suite de la description. Une scène multimédia telle qu'évoquée précédemment permet de spécifier l'agrégation des différents objets, par exemple la vidéo et l'audio de deux programmes différents, et la possibilité pour l'utilisateur d'interagir avec ces objets, par exemple de basculer depuis un programme vers l'autre, ou de déplacer la position du programme secondaire sur l'écran. Alors que l'utilisation de codage vidéo scalable permet une diffusion de contenu multimédia vers des systèmes de décodage et de présentation ayant des capacités de traitement, d'affichage et de restitution sonore variées, certains appareils tels les clients légers, en particulier les téléphones mobiles et les boîtiers décodeurs, ne sont pas adaptés à traiter des volumes de données importants. De plus l'environnement de communication de ces appareils est généralement limité en terme de bande passante. Il existe donc un besoin pour optimiser les ressources nécessaires à la présentation de contenus multimédias, en particulier sur des clients légers.

L'invention permet de résoudre au moins un des problèmes exposés précédemment.

L'invention a ainsi pour objet un procédé pour accéder à une partie d'un contenu multimédia à partir d'une scène multimédia comprenant au moins une référence à au moins un objet pouvant être transmis sous forme de flux de données, ce procédé comprenant les étapes suivantes, - identification dans ladite scène multimédia d'une source dudit au moins un objet selon ladite au moins une référence audit au moins un objet ;

- identification dans ladite scène multimédia d'au moins une instruction liée à ladite au moins une référence comprenant au moins un paramètre d'adaptation dudit au moins un objet ; - transmission à ladite source d'au moins une indication relative à ladite au moins une instruction ; et,

- accès à au moins un flux de données représentant au moins une partie dudit objet, ledit au moins un flux de données étant adapté selon ladite au moins une indication.

Ce procédé selon l'invention permet ainsi d'optimiser les ressources utilisées pour accéder à une présentation multimédia en adaptant les paramètres à la source. En particulier, ce procédé selon l'invention permet d'optimiser les moyens de décodage de l'appareil sur lequel est présenté le contenu multimédia et la bande passante utilisée pour la transmission des données si une partie du contenu multimédia est transmise depuis un serveur distant. Une partie du contenu multimédia peut ainsi être mémorisée dans des moyens de stockage locaux ou dans des moyens de stockage distants.

L'invention a également pour objet un procédé pour modifier dynamiquement une scène multimédia de présentation d'un contenu multimédia, ladite scène multimédia comprenant au moins une référence à au moins un objet pouvant être transmis sous forme de flux de données, ce procédé comprenant les étapes suivantes,

- identification dans ladite scène multimédia de ladite au moins une référence audit au moins un objet ;

- réception d'au moins une instruction comprenant au moins un paramètre d'adaptation dudit au moins un objet ; et,

- insertion dans ladite scène multimédia d'au moins une indication relative à ladite au moins une instruction comprenant ledit au moins un paramètre d'adaptation dudit au moins un objet, permettant à une source dudit au moins un objet d'adapter ledit flux de données selon ledit au moins un paramètre.

Ce procédé selon l'invention permet ainsi de créer des scènes multimédia optimisées et d'optimiser dynamiquement les ressources d'accès à une partie du contenu multimédia selon les choix de l'utilisateur.

Dans un mode de réalisation particulier, l'objet accédé est codé selon un codage scalable.

Toujours dans un mode de réalisation particulier, le paramètre d'adaptation est une contrainte d'adaptation, c'est-à-dire une contrainte sur le résultat d'adaptation.

Les scènes multimédia sont avantageusement codées selon un langage de type XML, SVG, LASeR, BIFS ou VRML.

Les objets accèdes peuvent être du type séquences vidéo, images, audio et/ou graphiques.

Le procédé décrit précédemment peut avantageusement être utilisé pour la présentation de séquence vidéo ou d'images dans des applications du type image dans l'image.

L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment.

L'invention a aussi pour objet un dispositif pour accéder à une partie d'un contenu multimédia à partir d'une scène multimédia comprenant au moins une référence à au moins un objet pouvant être transmis sous forme de flux de données, ce dispositif comprenant les moyens suivants,

- des moyens d'identification dans ladite scène multimédia d'une source dudit au moins un objet selon ladite au moins une référence audit au moins un objet ;

- des moyens d'identification dans ladite scène multimédia d'au moins une instruction liée à ladite au moins une référence comprenant au moins un paramètre d'adaptation dudit au moins un objet ;

- des moyens de transmission à ladite source d'au moins une indication relative à ladite au moins une instruction ; et,

- des moyens d'accès à au moins un flux de données représentant au moins une partie dudit objet, ledit au moins un flux de données étant adapté selon ladite au moins une indication.

Ce dispositif selon l'invention permet ainsi d'optimiser les ressources utilisées pour accéder à une présentation multimédia en adaptant les paramètres à la source. En particulier, le dispositif selon l'invention permet d'optimiser les moyens de décodage de l'appareil sur lequel est présenté le

contenu multimédia et la bande passante utilisée pour la transmission des données si une partie du contenu multimédia est transmise depuis un serveur distant. Avantageusement, ce dispositif selon l'invention comprend des moyens pour accéder à une partie du contenu multimédia pouvant être mémorisée dans des moyens de stockage locaux ou dans des moyens de stockage distants.

L'invention a également pour objet un dispositif pour modifier dynamiquement une scène multimédia de présentation d'un contenu multimédia, ladite scène multimédia comprenant au moins une référence à au moins un objet pouvant être transmis sous forme de flux de données, ce dispositif comprenant les moyens suivants,

- des moyens d'identification dans ladite scène multimédia de ladite au moins une référence audit au moins un objet ;

- des moyens de réception d'au moins une instruction comprenant au moins un paramètre d'adaptation dudit au moins un objet ; et, - des moyens d'insertion dans ladite scène multimédia d'au moins une indication relative à ladite au moins une instruction comprenant ledit au moins un paramètre d'adaptation dudit au moins un objet, permettant à une source dudit au moins un objet d'adapter ledit flux de données selon ledit au moins un paramètre. Ce dispositif selon l'invention permet ainsi de créer des scènes multimédia optimisées et d'optimiser dynamiquement les ressources d'accès à une partie du contenu multimédia selon les choix de l'utilisateur.

Dans un mode de réalisation particulier, le dispositif selon l'invention comprend en outre des moyens de décodage adaptés à décoder un objet codé selon un codage scalable.

L'invention a également pour objet un programme d'ordinateur pour présenter un contenu multimédia comprenant au moins une partie d'au moins un objet pouvant être transmis sous forme de flux de données, ce programme d'ordinateur étant caractérisé en ce qu'il comprend les instructions suivantes, - une instruction pour accéder à ladite au moins une partie dudit au moins un objet depuis une source ; et,

- une instruction comprenant au moins un paramètre pour adapter ledit flux de donnée de ladite au moins une partie dudit au moins un objet selon ledit paramètre.

L'invention permet ainsi de coder un contenu multimédia de façon optimisée permettant de limiter les ressources nécessaires pour accéder à une partie de ce contenu multimédia en permettant une adaptation à la source des paramètres. En particulier, l'invention permet d'optimiser les moyens de décodage de l'appareil sur lequel est présenté le contenu multimédia et la bande passante utilisée pour la transmission des données si une partie du contenu multimédia est transmise depuis un serveur distant.

D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :

- la figure 1 montre un exemple d'appareil permettant d'implémenter l'invention ;

- la figure 2 illustre un mode standard de présentation d'un contenu multimédia lié à une scène ;

- la figure 3 illustre un exemple de présentation d'un contenu multimédia lié à une scène, selon l'invention ; et, - la figure 4 décrit schématiquement certaines étapes d'un algorithme pour mettre en œuvre l'invention selon un mode de réalisation adapté à une architecture de type client serveur.

Selon l'invention, l'auteur de la scène et donc de l'application peut optimiser les ressources de décodage et/ou de bande passante en spécifiant dans la scène multimédia des paramètres permettant d'adapter à la source les objets multimédias obtenus.

L'invention réside ainsi dans la production de scènes multimédias comprenant une description des paramètres spécifiant l'adaptation des données sources, dans les scènes multimédias qui en résultent et dans l'utilisation et l'interprétation de ces scènes. Ces paramètres peuvent être modifiés suite à des actions de l'utilisateur.

La figure 1 illustre un exemple d'appareil 100 adapté à mettre en œuvre l'invention, tel qu'une livebox, un boîtier décodeur, un téléphone mobile, un assistant personnel communiquant ou un ordinateur portable.

De préférence, l'appareil 100 comporte un bus de communication 120 auquel sont reliés,

• une unité centrale de traitement 102 telle qu'un microprocesseur (CPU) ;

• une mémoire morte 104 ou Read OnIy Memory (ROM), pouvant comporter un ou plusieurs programmes ; • une mémoire vive 106 ou Random Access Memrory (RAM), comportant des registres adaptés à mémoriser des variables et des paramètres créés et modifiés au cours de l'exécution des programmes précités ;

• une interface de communication 108 reliée à un réseau de communication distribué 1 18, par exemple le réseau GPRS ou UMTS ou un réseau WiFi, l'interface étant apte à transmettre et à recevoir des données ; et,

• un écran 1 10 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention. Alternativement, ou de façon complémentaire, un écran externe peut être connecté à l'appareil 100 par une connexion vidéo. L'appareil 100 peut disposer optionnellement de l'un, de plusieurs ou de tous les dispositifs suivants :

• un clavier 1 12 ou tout autre moyen tel qu'un dispositif de pointage, comme par exemple une molette de sélection ou un crayon optique, un écran tactile ou une télécommande, permettant à l'utilisateur d'interagir avec les programmes ; et,

• un lecteur de cartes mémoires 1 14 adapté à recevoir une ou plusieurs cartes mémoires 116 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Les cartes mémoires peuvent être par exemple du type SD {Secure Digital), miniSD, MMC {MultiMedia Card) ou CF {Compact Flash)

Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil 100 ou reliés

à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil 100, directement ou par l'intermédiaire d'un autre élément de l'appareil 100. Le code exécutable du ou des programme(s) permettant à l'appareil

100 de mettre en œuvre les processus selon l'invention, peut être stocké, par exemple, en mémoire morte 104.

Selon une variante, la carte mémoire 1 16 peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil 100, peuvent être stockés dans la mémoire 106.

Alternativement, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 118, via l'interface 108, pour être stocké de façon identique à celle décrite précédemment.

Les cartes mémoires peuvent être remplacées par tout support d'information lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, et adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en œuvre des procédés selon l'invention.

De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage de l'appareil 100 avant d'être exécutés.

L'unité centrale 102 contrôle l'exécution des instructions ou portions de code logiciel du ou des programme(s) selon l'invention, instructions qui sont stockées dans la carte mémoire 1 16, dans la mémoire morte 104 ou dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes stockés dans une mémoire non volatile, par exemple la mémoire morte 104, sont transférés dans la mémoire vive 106 (RAM), qui contient alors le code exécutable du ou des programme(s) selon l'invention, ainsi que des registres pour mémoriser les variables et les paramètres nécessaires à la mise en œuvre de l'invention.

Il convient de noter que l'appareil comportant le dispositif selon l'invention peut également être un appareil programmé. Les instructions du ou

des programme(s) mettant en œuvre l'invention peuvent, par exemple, être implémentées dans un circuit intégré programmable ou spécifique {Application- Specific Integrated Circuit, ASIC).

Dans la suite de la description, un scénario image dans l'image est présenté à titre d'illustration, où les vidéo sont fournies au format SVC. Dans un mode de réalisation, il existe des paramètres d'adaptation dont la syntaxe et la sémantique sont connues des différents modules intervenant dans l'application. Ces paramètres peuvent être spécifiques au format de codage de l'objet multimédia utilisé ou génériques. Par exemple, l'encodage d'un flux SVC peut être spécifié par un certain nombre de paramètres définissant par exemple le nombre de couches de décomposition spatiale, temporelle et de qualité. Un flux SVC est structuré comme une séquence de segments de données appelés Network Abstraction Layer Unit (NALUnit), chaque NALUnit comportant des paramètres indiquant à quelle couche spatiale, temporelle et de qualité elle appartient. Ces paramètres sont respectivement appelés dependency id, temporal level et quality level. Il est alors possible d'extraire une version adaptée de ce flux en spécifiant une valeur maximale pour ces paramètres dependency_id_max, temporal_level_max et quality_level_max. Ces paramètres d'adaptation sont spécifiques au format de codage SVC et peuvent être utilisés selon l'invention pour déterminer l'adaptation du flux à la source.

Inversement, il est également possible de spécifier des paramètres d'adaptation qui ne soient pas spécifiques à un format de codage donné. Par exemple, il est possible de spécifier un paramètre nommé "scale" définissant une opération d'adaptation de la taille, indépendamment du format de codage.

Pour les besoins de la description, des paramètres génériques et spécifiques sont utilisés dans les exemples suivants.

Une scène multimédia, ou scène graphique, peut être décrite en langage SVG, lui-même basé sur le langage XML (langage de balisage extensible ou Extensible Markup Language en anglais) qui permet de décrire une structure de données hiérarchisées. Ce langage est standardisé par le comité de standardisation W3C (une description du langage peut être trouvée à

l'adresse http://www.w3.org/TR/REC-xml). XML est de plus en plus utilisé pour la transmission de données numériques. En pratique, XML est un format de description de données, et non un format de représentation ou d'affichage de données. XML est une syntaxe permettant de définir de nouveaux langages. Ainsi, il est possible de définir une pluralité de langages XML qui peuvent être traités en utilisant des outils génériques. En outre, la syntaxe XML permet de structurer des données, ce qui permet d'élaborer des documents contenant les descriptions structurelles des données. Enfin, la syntaxe XML est textuelle et peut être lue ou écrite aisément par un utilisateur. La suite de la description est illustrée, en particulier, par l'utilisation de scène multimédia écrite dans le format SVG, lui-même basé sur le langage XML. Cependant, il doit être compris que l'invention peut être mise en œuvre par n'importe quel type de langage interprétable par un appareil tel que celui décrit par référence à la figure 1 , en particulier par n'importe quel type de langage à balisage. L'invention s'applique également à d'autres formats de présentation de scène tels que BIFS ou VRML ( Virtual Reality Modeling Language). A titre d'illustration, certains exemples sont également donnés selon le langage BIFS

La figure 2 illustre un mode standard de présentation d'un contenu multimédia. Selon la scène multimédia considérée à titre d'exemple, deux flux vidéo reçus d'un réseau tel qu'Internet, sont présentés simultanément, un premier flux représente une première vidéo (Vidéo 1 ) et un second flux représente une deuxième vidéo (Vidéo 2). L'utilisateur peut, à sa convenance, regarder la première vidéo en plein écran et la seconde vidéo sous forme de vignette, c'est-à-dire sous forme d'une vidéo de taille réduite placée dans un coin de l'écran, ou regarder la seconde vidéo en plein écran et la première vidéo sous forme de vignette. Quelque soit le mode de visualisation, les flux vidéo correspondant aux deux programmes sont transmis en pleine résolution. Par ailleurs, il convient de noter que, dans cet exemple, l'élément vidéo inclut également le signal audio. L'attribut audio-level indique que l'audio du deuxième programme ne doit pas être restitué bien qu'il soit transmis.

La scène multimédia suivante, décrite selon le langage SVG, illustre un exemple d'implémentation d'application de type image dans l'image tel que celui présenté sur la figure 2 lorsque la première vidéo est affichée en plein écran alors que la seconde vidéo est affichée sous forme de vignette. <?xml version="1.0" encoding="UTF-8"?>

<s vg xmlns= "http://www. w3. org/2000/s vg " xmlns:xlink= "http://www. w3. org/1999/xlink " version="1.2" baseProfile="tiny"xml:id="svg-root" width="100%" height="100%" viewBox="0 0 800 600" >

<video xml:id="Video 1 " xlink:href=" rtsp://myServer.com/myVideo1.mp4"/>

<g transform="translate(400, 10) scale(0.25)" audio-level="0">

<video xml:id="Video2" xlink:href=" rtsp://myServer.com/myVideo2.mp4"/> </g </svg>

Comme indiqué précédemment, la même scène multimédia peut être décrite selon d'autre langage, par exemple selon le langage BIFS. Selon ce langage, la même scène se présente alors sous la forme suivante, Group { children [

Transform2D { children Shape {

Appearance appearance { texture Movietexture { url "rtsp://myServer.com/myVideo 1.mp4"j

} geometry Bitmap {}

} } Transform2D { translation 400 10 scale 0.250.25 children [ Shape { Appearance appearance { texture Movietexture { url "rtsp://myServer.com/myVideo2.mp4" }

} geometry Bitmap {}

J ]

J ] }

Dans cet exemple, le programme principal Vidéo 1 est représenté en plein écran et le programme secondaire Vidéo 2 est restitué avec une taille réduite dans un coin de l'écran. Un langage de représentation de scène

multimédia comme SVG ou BIFS offre fréquemment la possibilité pour l'utilisateur de modifier la scène de façon interactive. Par exemple, il est possible pour l'auteur de la scène de spécifier un script déclenché lors d'une action de l'utilisateur, telle que le fait d'appuyer sur un bouton, qui modifie la scène.

Dans un souci de clarté, le script, bien connu de l'homme de l'art, n'est pas représenté ici, mais la scène multimédia de l'exemple suivant est un exemple du résultat de l'action d'un tel script : les deux programmes sont inversés : Vidéo 2 est le nouveau programme principal et Vidéo 1 est le programme secondaire. Dans les deux cas, le programme secondaire est restitué avec une taille réduite. La scène multimédia suivante illustre donc un exemple d'implémentation d'application de type image dans l'image tel que celui présenté sur la figure 2 lorsque la première vidéo est regardée sous forme de vignette alors que la seconde vidéo est regardée en plein écran. <?xml version="1.0" encoding="UTF-8"?>

<s vg xmlns= "http://www. w3. org/2000/s vg " xmlns:xlink= "http://www. w3. org/1999/xlink " version="1.2" baseProfile="tiny"xml:id="svg-root" width="100%" height="100%" viewBox="0 0 800 600" >

<video xml:id="Video2" xlink:href=" rtsp://myServer.com/myVideo2.mp4"/>

<g transform="translate(400, 10) scale(0.25)" audio-level="0">

<video xml:id="Video 1 " xlink:href=" rtsp://myServer.com/myVideo 1.mp4"/> </g> </svg>

A nouveau, la même scène peut être décrite dans un autre langage, en particulier dans le langage BIFS. La même scène se présente alors sous la forme suivante, Group { children [

Transform2D { children Shape {

Appearance appearance { texture Movietexture { url "rtsp://myServer.com/myVideo2.mp4"}

} geometry Bitmap {}

}

J Transform2D { translation 400 10 scale 0.250.25

children [ Shape { Appearance appearance { texture Movietexture { url "rtsp://myServer.com/myVideo1.mp4" } i geometry Bitmap {}

} 1 } ]

}

La figure 3 illustre un mode de présentation d'un contenu multimédia résultant de l'invention. De façon similaire à l'exemple présenté en référence à la figure 2 et selon la scène utilisée, deux flux vidéo sont reçus d'un réseau tel qu'Internet, et présentés simultanément. Un premier flux représente une première vidéo (Vidéo 1 ) et un second flux représente une seconde vidéo (Vidéo 2). L'utilisateur peut, à sa convenance, regarder la première vidéo en plein écran et la seconde vidéo sous forme de vignette ou regarder la seconde vidéo en plein écran et la première vidéo sous forme de vignette. Selon l'invention, le mode d'adaptation du flux vidéo est lié au mode d'affichage de ce flux, tel qu'il est spécifié dans la scène. Si par exemple la première vidéo est affichée en plein écran et que la seconde vidéo est affichée sous forme de vignette, alors la première vidéo est transmise en pleine résolution et en pleine qualité alors que la seconde vidéo est transmise dans une résolution et dans une qualité inférieures, adaptée à la taille de la vignette et à la résolution de l'affichage. De même, si la première vidéo est affichée sous forme de vignette et que la seconde vidéo est affichée en plein écran, alors la première vidéo est transmise dans une résolution et dans une qualité adaptées à la taille de la vignette et à la résolution de l'affichage alors que la seconde vidéo est transmise en pleine résolution et en pleine qualité.

L'exemple suivant de scène multimédia permet de mettre en œuvre la solution présentée précédemment par référence à la figure 3 lorsque la première vidéo est affichée en plein écran alors que la seconde vidéo est affichée sous forme de vignette. Une fonction graphique, ici spécifiée sous forme d'un attribut lsr:adaptSource, indique au moteur restituant la scène d'adapter le programme secondaire à la source en appliquant un facteur d'échelle, ici un facteur d'échelle de 4 et en réduisant la qualité en définissant

une valeur quality level max. En effet, il est supposé dans l'exemple que le flux vidéo a été encodé avec une couche de rehaussement de qualité en plus de la couche dite de base. Les couches sont numérotées ici 0 (couche de base) et 1 (couche de rehaussement). En spécifiant quality_level_max=0, il est indiqué à la source de l'objet multimédia de supprimer la couche de rehaussement, celle- ci n'étant pas utile pour une visualisation avec une taille réduite. De plus, un troisième paramètre indique que l'audio n'est pas requise (nAudioChannels=0). Il peut ainsi être remarqué qu'une adaptation peut être composée de plusieurs adaptations élémentaires, chaque adaptation élémentaire pouvant être spécifiée par des paramètres spécifiques au format de codage ou non. Il convient de noter que le préfixe "ter" indique que l'attribut spécifié appartient à un espace de noms urn:mpeg:mpeg4:LASeR:2005. Le langage LASeR est en effet un langage de description de scène basé sur SVG et sur lequel il définit des extensions telles que l'attribut lsr:adaptSource introduit ici. <?xml version="1.0" encoding="UTF-8"?>

<svg xmlns="http://www. w3. org/2000/svg " xmlns:xlink= "http://www. w3. org/1999/xlink" version="1.2" xmlns:lsr="urn:mpeg:mpeg4:LASeR:2005" baseProfile="tiny"xml:id="svg-root" width="100%" height="100%" viewBox="0 0 800 600 ">

<video xml:id= "Video 1 " xlink:href= "rtsp://myServer. com/myVideo 1. mp4 "/>

<g transform="translate(400, 10) "> <video xml:id="Video2" xlink:href="rtsp://myServer.com/myVideo2.mp4" lsr:adaptSource="scale=0.25 quality_level_max=0 nAudioChannels=0"/> </g> </svg> Lorsque la même scène est décrite selon le langage BIFS, elle se présente sous la forme suivante,

Group { children [

Transform2D { children Shape {

Appearance appearance { texture Movietexture { url "rtsp://myServer.com/myVideo1.mp4" }

} geometry Bitmap {} j i Transform2D {

translation 400 10 children [ Shape {

Appearance appearance { texture Mo vietexture { url "rtsp://myServer. com/my Video2. mp4 " }

J geometry Bitmap {}

J

AdaptSource{ url "rtsp://myServer. com/my Video2.mp4" scale 0.250.25 quality_level_max 0 nAudioChannels=0

} ]

}

1

}

Dans cet exemple, la fonction graphique, ici appelée AdaptSource, indique au moteur restituant la scène d'adapter le programme secondaire à la source en appliquant notamment un facteur d'échelle.

De façon similaire, l'exemple suivant de scène multimédia permet de mettre en œuvre la solution présentée précédemment par référence à la figure

3 lorsque la première vidéo est affichée sous forme de vignette alors que la seconde vidéo est affichée en plein écran. A nouveau, une fonction graphique spécifiée sous forme d'un attribut IsπadaptSource, indique au moteur restituant la scène d'adapter le premier programme, à la source, en appliquant notamment un facteur d'échelle, ici un facteur d'échelle de 4. Cet exemple montre que l'invention permet de réduire la consommation de ressources sans que la perception de l'utilisateur de la présentation du contenu multimédia soit affectée.

<?xml version="1.0" encoding="UTF-8"?>

<s vg xmlns= "http://www. w3. org/2000/s vg " xmlns:xlink= "http://www. w3. org/1999/xlink " version="1.2" xmlns:lsr="urn:mpeg:mpeg4:LASeR:2005" baseProfile="tiny"xml:id="svg-root" width="100%" height="100%" viewBox="0 0 800 600" >

<video xml:id="Video2" xlink:href="rtsp://myServer.com/myVideo2.mp4"/>

<g transform="translate(400, 10) ">

<video xml:id="Video1 " xlink:href="rtsp://myServer.com/myVideo1.mp4" lsr:adaptSource="scale=0.25 quality_level_max=0 nAudioChannels=0"/> </g>

Si la scène est décrite selon le langage BIFS, elle se présente sous la forme suivante,

Group { children [ Transform2D { children Shape { Appearance appearance { texture Movietexture { url "rtsp://myServer.com/myVideo2.mp4"}

} geometry Bitmap {}

}

J Transform2D { translation 400 10 children [

Shape { Appearance appearance { texture Movietexture { url "rtsp://myServer.com/myVideo1.mp4" }

} geometry Bitmap {}

J AdaptSource{ url "rtsp://myServer.com/myVideo 1.mp4" scale 0.250.25 quality_level_max 0 nAudioChannels=0 J ]

J ]

}

La fonction graphique peut spécifier l'adaptation du contenu à la source comme une combinaison d'adaptations élémentaires. Ces adaptations élémentaires peuvent notamment être les suivantes : - adaptation de la taille (ceci s'applique notamment à une vidéo, une image fixe ou une scène multimédia) ;

- adaptation de la fréquence des images pour une vidéo ;

- adaptation de la qualité (ceci s'applique notamment à une vidéo, une image ou une audio) ; et, - adaptation du nombre de canaux notamment pour un contenu audio.

Cette liste n'est évidemment pas limitative.

II est également possible de spécifier qu'une composante de l'objet ne doit pas être restituée. En particulier, dans l'exemple d'application image dans l'image, il est inutile d'obtenir l'audio du programme secondaire.

Il est également possible de spécifier une contrainte sur le résultat de l'adaptation. Par exemple, la scène peut indiquer une contrainte en terme de débit maximal requis pour l'objet adapté. C'est alors à la source de l'objet multimédia d'adapter l'objet pour respecter cette contrainte.

L'adaptation à la source peut se faire de plusieurs façons. Dans le cas d'une ressource disponible localement sous forme, par exemple, d'un fichier, adapter la source permet au client de ne lire et de ne décoder que les données utiles. Ceci permet d'économiser les ressources de traitement du client. Dans le cas d'une ressource disponible de façon délocalisée, par exemple dans une application de lecture en continu {streaming), la mise en œuvre de l'invention permet de n'obtenir que les données utiles et donc d'économiser à la fois de la bande passante et les ressources de traitement du client. Ainsi, selon l'invention, que l'objet multimédia soit accédé localement, par l'intermédiaire d'un serveur distant à travers un réseau ou directement à sa source de production (par exemple pour une émission en direct de télévision), les ressources nécessaires à la présentation du contenu multimédia sont optimisées.

La création de la scène multimédia comprenant les instructions nécessaires à l'optimisation des ressources de transmission et/ou de présentation du contenu multimédia est similaire aux méthodes de l'art antérieur pour générer des scènes multimédias mais comprend en outre une étape supplémentaire d'insertion d'instructions de paramétrage de l'adaptation des objets compris dans la présentation multimédia. Ainsi, pour chaque objet dont le flux de données correspondant doit être adapté avant son utilisation, ou est susceptible d'être adapté, une instruction est ajoutée à la scène multimédia. Chaque instruction fait ainsi indirectement référence à l'entité devant effectuer la modification, ici la source du flux multimédia, et comprend le type d'adaptation devant être effectuée ainsi que les paramètres liés à la modification du flux de données. Les instructions peuvent être mémorisées

sous forme d'attribut de l'élément dont elles dépendent. Par exemple, comme mentionné précédemment, l'instruction lsr:adaptsource="scale=0.25" est un attribut qui indique qu'une adaptation doit être faite à la source du flux de données dont dépend l'attribut, avec scale=0.25 comme paramètre. Le paramètre scale=0.25 est interprété par le client qui transmet une requête à la source du flux de données dont dépend l'attribut pour que la source modifie le flux de données avant sa transmission. Cette requête est, de préférence, une requête standard de paramétrage d'adaptation de données. Il convient de noter que l'attribut peut également être placé dans un élément parent de l'élément référençant l'objet multimédia dans le but de factoriser l'information. Dans l'exemple, l'attribut adaptSource est appliqué à l'élément video, mais il peut également s'appliquer notamment aux éléments audio, images, animations ou graphiques.

Ainsi qu'il l'a été mentionné précédemment, une scène multimédia peut être dynamiquement modifiée par l'utilisateur à l'aide d'un script prédéterminé. Dans ce cas, le script contient une description des instructions ou des attributs qui doivent être supprimés et une description de ceux qui doivent être ajoutés ou modifiés.

La figure 4 illustre schématiquement certaines étapes d'un algorithme pour mettre en œuvre l'invention selon un mode de réalisation adapté à une architecture de type client serveur. Selon ce mode de réalisation, la scène multimédia utilisée pour afficher le contenu multimédia peut avoir été transmise par un module externe, par exemple par un serveur (étape 400) ou peut être stockée localement dans des moyens de stockage du client. Cette scène multimédia peut être un fichier de description au format SVG tel que les exemples présentés précédemment.

Dans un souci de clarté, la description suivante repose sur l'utilisation connue de l'homme de l'art du protocole de streaming temps-réel RTSP {Real Time Streaming Protocol) développé par I ¹ I ETF et publié en 1998. Cependant, il doit être compris que l'invention peut être mise en œuvre avec d'autres protocoles de communication.

Après avoir accédé à la scène multimédia, le client analyse cette scène (étape 405) selon une méthode standard adaptée au format de la scène, ici le SVG. La scène multimédia peut contenir, par exemple, des références de deux programmes audio-vidéo (P1 et P2) disponibles sur un serveur. Les références et les paramètres de présentation du contenu multimédia sont mémorisés par le client. Parmi ces paramètres figurent, en particulier, l'indication selon laquelle le second programme audio-vidéo est affiché sous forme de vignette.

Le client transmet alors une requête au serveur, de préférence une requête de type RTSP DESCRIBE, demandant une description des ressources à transmettre sous forme de flux, c'est-à-dire les flux audio et vidéo de chaque programme (étape 410).

Après réception de cette requête, le serveur transmet au client une description de la session, de préférence de type SDP, décrivant les flux audio et vidéo disponibles pour chaque programme (étape 415).

Le client transmet alors une requête, avantageusement une requête de type RTSP SETUP, demandant au serveur de préparer les sessions de transfert des flux de données pour chaque programme (étape 420).

Le client transmet également une requête, avantageusement une de type RTSP SET PARAMETER, comprenant les paramètres liés au second programme audio-vidéo pour adapter le flux à la source, c'est-à-dire avant la transmission (étape 425). Dans cet exemple, la taille de la vidéo doit être réduite d'un facteur quatre et le flux audio ne doit pas être transmis. Ainsi, pour le second programme, le serveur ne fournira que les données nécessaires à l'affichage du flux vidéo correspondant à la taille réduite, sans le flux audio.

Ensuite, le client envoie une requête, de préférence une requête de type RTSP PLAY, demandant au serveur de commencer à transmettre les flux requis (étape 430).

A la réception de la requête du client, le serveur transmet les flux vidéo des deux programmes ainsi que le flux audio du premier programme

(étape 435). L'utilisateur peut ainsi visualiser les deux programmes (étape 440).

Le programme secondaire a été adapté avant d'être transmis c'est-à-dire que

seules les données utiles (vidéo de taille réduite sans audio) sont envoyées, comme requis par la scène.

De préférence, l'utilisateur actionne un bouton sur sa télécommande pour basculer du mode d'affichage du premier programme en plein écran avec affichage du second programme sous forme de vignette au mode d'affichage du second programme en plein écran avec affichage du premier programme sous forme de vignette. Le bouton de la télécommande actionne un script déclaré dans la scène qui modifie la scène elle-même.

Dans la nouvelle scène obtenue, un paramètre d'adaptation est défini pour le premier programme et non plus pour le second. Le second programme est maintenant le programme principal, affiché en plain écran, et le premier programme devient le programme secondaire, affiché sous forme de vignette. Le client envoie alors une requête, de préférence une requête de type RTSP SET PARAMETER, demandant au serveur de modifier les paramètres d'adaptation de chaque programme (étape 445).

A la réception de cette requête, le serveur modifie les paramètres de transmission et continue la transmission des flux avec les nouveaux paramètres selon lesquels le premier programme est transmis selon un format réduit, sans le flux audio, et le second programme est transmis en pleine résolution, avec le flux audio (étape 435). Il existe plusieurs possibilités pour le serveur de transmettre et d'adapter les données. Dans un premier cas, la vidéo est envoyée comme un seul flux, et l'adaptation consiste à supprimer des données dans le flux. Dans un deuxième cas, la vidéo est transmise sur plusieurs flux. Par exemple, un premier flux correspond à la couche de base et un deuxième flux correspond à la couche de rehaussement. L'adaptation consiste alors à ne transmettre qu'un flux. Une combinaison des deux possibilités ci-dessus est bien entendu possible.

L'affichage du client est modifié en conséquence (étape 440).

Les étapes 440, 445 et 435 sont avantageusement répétées chaque fois que l'utilisateur actionne le bouton de sa télécommande pour modifier le mode d'affichage.

Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.