EP1714458A1 - Procede d'edition d'une page multimedia avec pre-memorisation - Google Patents

Procede d'edition d'une page multimedia avec pre-memorisation

Info

Publication number
EP1714458A1
EP1714458A1 EP04710896A EP04710896A EP1714458A1 EP 1714458 A1 EP1714458 A1 EP 1714458A1 EP 04710896 A EP04710896 A EP 04710896A EP 04710896 A EP04710896 A EP 04710896A EP 1714458 A1 EP1714458 A1 EP 1714458A1
Authority
EP
European Patent Office
Prior art keywords
terminal
data
memory
instruction
multimedia
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04710896A
Other languages
German (de)
English (en)
Inventor
Cédric Gegout
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP1714458A1 publication Critical patent/EP1714458A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability

Definitions

  • the invention relates to the edition of multimedia pages with terminals, in particular in the context of multimedia services offered on mobile telephones that are designed to cooperate with cellular networks.
  • a server distributes, to one or more terminals, at least part of multimedia pages in the form of instructions for arranging objects within a multimedia page to be constructed.
  • the same object can be used in particular by several successive multimedia pages and keep, or not, the same layout parameters from one multimedia page to another.
  • multimedia page is understood to mean, for example, a graphic scene to be edited with the terminal, where appropriate embellished with one or more sound sequences to be played on the speakers or headphones of the terminal.
  • the same object for example a graphic object such as a road map
  • the same object is likely to be edited in several successive scenes if the terminal user applies an interactive command of the zoom / zoom out or "left arrow / right arrow, up / down" type to adjust a position of visualization of the plan.
  • the server on each user interaction command, the server usually transmits the same data relating to the graphic object to be edited, if necessary with parameters for the arrangement of the object in the graphic scene (for example example a zoom value), which are different.
  • the present invention provides a data storage mechanism specific to objects intended to be arranged within multimedia pages. More particularly, the invention proposes a process of transmission and decoding of “cache” functions (that is to say a read anticipation followed by a storage) of the object data, prior to the spatial-temporal arrangement. of these objects in a multimedia page.
  • One of the aims of the present invention relates to the reduction of the memory of the terminals, necessary for editing complex multimedia pages, or of a succession of such pages.
  • Another object of the present invention relates to the reduction of the computing resources necessary for editing such pages, or of a succession of these pages.
  • Another object targeted by the present invention is to provide a method making it possible to achieve the objectives referred to above while offering compatibility with conventional decoding techniques. More generally, an aim of the present invention is to offer greater flexibility in terms of requests and data exchanged between the server and the terminal.
  • the present invention firstly proposes a method of editing multimedia pages with a terminal, in which a server distributes, to one or more terminals, at least part of the multimedia pages in the form of instructions for arranging objects within a multimedia page to be constructed, the method comprising: a) at least one prior step during which the server transmits data relating to at least one object to be arranged in a multimedia page to be constructed, with an instruction to storage of said data, identified by a link, in a memory of the terminal, b) and at least one current step during which the server transmits a descriptive file comprising said link, for editing, with the terminal, said object in at least one multimedia page under construction, by reading the data stored in the terminal memory.
  • step b) alone can be repeated several times to editing the same object in several successive multimedia pages, advantageously without necessarily downloading from the server the data relating to the object for each multimedia page to be constructed.
  • the server transmits said data and the instruction to store in at least one data packet to the terminal.
  • Storage in the memory of the terminal is preferably temporary and the aforementioned storage instruction includes, in this embodiment, a timeout parameter of predetermined value defining an expiration date from its reception with the terminal.
  • the aforementioned instruction is of “cache” type between the server and the terminal, with a memory area of the terminal allocated for the storage of the data associated with this instruction, in order to accelerate a repeated subsequent execution of the step b), for, the same object.
  • the storage instruction includes information relating to a number of data that the terminal must store in memory.
  • the storage instruction may include a marker for the start of data recording and a marker for the end of data recording, so that the aforementioned number of data is defined by this pair of markers.
  • the descriptive file -precited includes a script including one or more links in the form of URL requests (for "UNIVERSAL RESSOURCE LOCATOR").
  • the storage instruction is carried out in the form of a command corresponding to a low-level function.
  • the object is a graphic type object comprising at least one of the elements from:
  • the present invention also relates to a program product in the form of computer code, and comprising a storage instruction, in a memory of a terminal. , of data relating to an object intended to be published, with said terminal, in one or more multimedia pages in which the object - is capable of intervening.
  • the present invention also relates to a signal comprising this code. This signal and / or the program product itself, can be transmitted from the server to the terminal, or even emanate from a memory medium which cooperates with a reader of the terminal (such as a CD-ROM or other reader).
  • - Figure 2 shows schematically and partially the elements of a TER terminal
  • - Figure 3 shows interacting software agents for editing multimedia pages with the TER terminal.
  • the mobile terminal TER requests one or more multimedia pages, for example graphic animation content, from a SER server (step 11).
  • the server SER returns content (step 12) comprising data (audio, video, text, or other) specific to an object, for example a graphic object to be edited in a graphic scene.
  • content is described a temporary storage function "CACHE” (corresponding to the above-mentioned storage instruction), as shown in table 12-a.
  • CACHE temporary storage function indicates that a set of graphic objects will be stored in memory in the terminal and will, if necessary, be accessible in response to a request from the same terminal.
  • This function therefore indicates to the TER terminal that it must store data relating to an object capable of intervening in one or more future graphic scenes to be constructed.
  • This object is identified by a graphic node "node i" to which we therefore associate DATA data specific to the graphic object.
  • the terminal stores this DATA data (step 13) in a memory zone ZMi of the terminal, identifiable by a link, for example a character string "node i".
  • the SER server sends (step 15) the description of a scene incorporating the "node i" object, if necessary with Attr attributes of arrangement of the object in the scene (descriptive file for example in the form of script 15-b).
  • the TER terminal recognizes the "node i" link to the memory zone ZMi and recovers (step 16) the DATA data previously stored in step 13 to edit a graphic scene including the object corresponding to the node "node i", with the Attr layout attributes that the server transmitted in step 15. If necessary, the terminal can ask the server for new attributes, for the same "node i" object, for editing a new graphic scene including this same object (step 14), if the lifetime of the storage of DATA data with the terminal allows it, as will be seen below.
  • This CACHE command is used to temporarily store a set of DATA specific to an object of a scene to be constructed.
  • This command is preferably grouped with the DATA data in the same packet (for example a - AccessUn packet in MPEG-4 / System, or even an RTP packet).
  • the server transmits following packets (containing one or more commands).
  • the terminal includes a communication module 21, in particular with the SER server, from which it receives the above-mentioned "CACHE" command.
  • CACHE CACHE command
  • This memory zone ZMi is provided in a memory MEM that the terminal TER comprises.
  • a following command transmitted by the server and relating to the object identified by the node "node i" will be interpreted by the terminal as targeting the content of the memory area ZMi and will therefore make it possible to recover the DATA data relating to this object .
  • These DATA data are then processed in a working memory 22 (for example by software of the terminal called "PLAYER"), possibly separate from the memory MEM.
  • the information allowing the editing of the scene to be constructed is then transferred to an interface 23, for example a graphical interface for displaying the scene (or even by a sound interface for a sound rendering).
  • these DATA data are preferably temporary, reference will be made to the hourly value read from a clock 24, usually provided in a terminal (in particular in its processor).
  • a "cacheObject" packet makes it possible to send in advance a content which will execute for example in response to a URL request (for example following steps 14 and 15 of FIG. 1).
  • This request can be made following a command from a user of the terminal (interactive command).
  • a cacheObject can be permanent, in its definition, and stored in memory at any time.
  • the data associated with the cacheObject has an expiration date (in the memory of the terminal) defined by the time of reception and the TTL lifetime (for "Time To Live”) of its temporarily stored data. This TTL attribute indicates in seconds the time after which the cacheObject is no longer valid.
  • the attributes which are associated with this cacheObject command are for example the following: • TTL: the duration of cacheObject validity • URL: the cacheObject data is retrieved from MEM memory, in response to this URL link • Source: DATA data to be stored and which can then be recovered.
  • Attr attributes which are then sent with the node "node i"
  • the CACHE command is declared by the instruction const bit (4) 12 which means that this command is declared by the integer "12" which must be found in the first four bits of the bit stream received by the terminal. Thus, if these first four bits have the integer "12", they will declare the CACHE command. Then, the bit (6) sglD command declares the integer msglD which, depending on its value, when it is received by the terminal, can trigger various actions with the terminal. Here, these actions are "Permanent” (indicates whether the terminal must keep the object's data in memory or not) and “Replace” (indicates whether the terminal must replace the content of its stored data with the new incoming data) . Combinations of these actions (or non-actions) are also provided, depending on the value of msglD. t
  • uint (X) commands declare: - the number of bytes to read and store "payloadLength”, - the lifetime of the data stored in memory "TTL”, and
  • the byte (8) [payloadLength] payload command indicates that the terminal must read and, if necessary (depending on the value of 0 the msglD variable), save all the data it receives from the server until it reads the "payloadLength” marker.
  • command STZString defines a way5 of reading a character string to read a URL link either to the memory of the terminal, or to html pages of the server.
  • the server transmits multimedia pages which contain links and the responses associated with these links with an instruction to store these responses on the terminal.
  • the terminal can either accept 'or refuse to store these responses, for example if they are too large or if the timeout st or5 too short too long. •
  • the terminal access priority to the response stored on the device, if it is actually stored .0
  • FIG. 3 We now refer to FIG. 3 to describe a model of transmission and rendering of graphic scenes.
  • a plurality of modules 42 are stored in memory 41 of the terminal TER, as memory residents.
  • client software 45 “PLAYER” is also stored as a memory resident in memory 41.
  • the PLAYER 45 allows you to view animated, interactive and multimedia content on the mobile terminal. Essentially, this software downloads or reads information that describes the spatio-temporal arrangement of graphic objects, the way they are synchronized and the interactions of the terminal user that are possible on this content.
  • the PLAYER 45 interprets the interactions of the user and deduces the appropriate behaviors. graphic objects or requests to be made on the content server.
  • PLAYER 45 (for example of type
  • STREAMEZZO includes functions for rendering graphic objects and engines for visualization (graphic rendering engine 50) and interaction (interaction engine
  • the PLAYER 45 uses modules 42, 43, 44 as API ("Application Program
  • Content for editing includes animated vector graphics, sound, video, and user interactions.
  • Viewing interactive multimedia content in mobile environments usually requires the use of compression techniques to ensure efficient provision of content and optimization of the rendering of the graphic objects making up that content. This content can then be viewed in good conditions on mobile terminals.
  • the information read or downloaded by the PLAYER 45 is therefore highly compressed and the PLAYER must therefore decompress this data and interpret it on the fly to play the content.
  • the PLAYER 45 comprises audio and video decoding modules, respectively 46 and 47, a decoded flow analyzer 49, a media manager 48, a rendering engine (graphic or sound) 50 and an interactivity engine 51 .
  • the operation of the PLAYER can be described in the following steps: input of the input data through a connection "Network or file playback, decompressing the data to obtain a description of graphic objects directly usable by the audio and graphic rendering engine 50, composition of the graphic objects together to create a graphic scene, - actual graphic rendering of the audio and graphic objects, by displaying visual objects or by playing a sound, taking account for user interactions, such as a click of a pointer, or pressing a key, or the like, establishing a connection to a local or remote information source if necessary.
  • this last step will consist in opening a connection to the SER server and recovering a bit stream.
  • This bit stream is analyzed by the PLAYER 45 which then creates a ScèneGraph object containing the various scene objects in the form of nodes of a graph.
  • the information flow is divided into packets which group together information which, in a preferred embodiment, is valid only at a given instant and corresponds to a single type of information (principle of 1 "AccessUnit" of the MPEG standard -4).
  • the PLAYER analyzes each packet and executes the commands described therein according to its clock (not shown in the figures), which provides the time of the multimedia scene and, if applicable, the TTL validity duration of the DATA data associated with a command. HIDDEN.
  • this PLAYER 45 in particular with the other modules 42, 43 and 44 of the terminal, can ensure the process of reception and decoding of a CACHE storage function for data of graphic objects intervening in graphic scenes, within the meaning of the present invention.
  • This storage function makes it possible to manage the representation of an object and / or the modification of its arrangement in a scene, without having to systematically download the same data of the object in the terminal.
  • this function makes it possible to link several graphic scenes in a composite multimedia service, advantageously when the same object frequently occurs in these scenes.
  • the method within the meaning of the invention allows a reduction in the memory (for example the graphic memory) of the terminal, since only the data storage instruction is stored on the graphic nodes.
  • the method within the meaning of the invention also allows a gain in the use of computing resources, since, typically, the use of programmatic content as defined above would induce a net additional computation cost, at least for certain animations.
  • the method within the meaning of the invention using a mechanism conforming to a conventional graphical command rendering process, in a preferred embodiment, is then easy. to be implemented, in particular for a system with mobile terminals cooperating with cellular networks.
  • the method within the meaning of the invention also offers compatibility with conventional decoding techniques, since the method can be implemented in most graphic rendering devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne l'édition de pages multimédia auprès d'un terminal. Un serveur (SER) distribue des pages sous forme d'instructions d'agencements d'objets au sein d'une page multimédia à construire, auprès d'un terminal (TER). Le procédé au sens de l'invention comporte a) une étape préalable (12) pendant laquelle le serveur transmet un paquet de données relatives à un objet, avec une instruction de stockage temporaire ('CACHE') de ces données (DATA), identifiées par un lien ('node i'), dans une mémoire du terminal, b) et une étape courante (15) pendant laquelle le serveur transmet un fichier descriptif comportant ce lien, pour éditer, auprès du terminal, l'objet dans une scène en construction, à partir des données stockées.

Description

PROCEDE D ' EDITION D ' UNE PAGE MULTIMEDIA AVEC PRE-MEMORISATION
L'invention concerne l'édition de pages multimédia auprès de terminaux, notamment dans le cadre de services multimédia proposés sur des téléphones mobil-es a-gencés pour coopérer avec des réseaux cellulaires.
Dans le contexte de l'invention, un serveur distribue, à un ou plusieurs terminaux, une parti-e au moins de pages multimédia sous forme d'instructions d'agencements d'objets au sein d'une page multimédia à construire.
Dans ce contexte, un même objet peut être utilis-é notamment par plusieurs pages multimédia successives et conserver, ou non, de mêmes paramètres d'a-gencements d'une page multimédia à l'autre.
On entend par "page mul timédia" par exemple une scène graphique à éditer auprès du terminal, le -cas échéant agrémentée d'une ou plusieurs séquences sonores à jou-er sur des baffles ou écouteurs du terminal.
Par exemple, pour l'édition graphique d'un plan d'une ville sur un terminal mobile, un même objet (par exemple un objet graphique tel qu'une carte routière) est susceptible d'être édité dans plusieurs scènes successives si l'utilisateur du terminal applique une commande interactive du type zoom/dézoom ou "flèche gauche/flèche droite, haut/bas" pour ajuster une position de visualisation du plan. Dans ce cas, à chaque commande d'interaction de l'utilisateur, le serveur transmet habituellement les mêmes données relatives à l'objet graphique à éditer, le cas échéant avec des paramètres d'agencement de l'objet dans la scène graphique (par exemple une valeur de zoom), qui sont différents.
Il se pose alors le problème de transmission et stockage systématiques et inutiles des données relatives à un même objet, pour plusieurs pages multimédia dans lesquelles le même objet intervient, le cas échéant avec des paramètres d'agencement différents. Ce problème devient particulièrement gênant lorsque l'on doit avoir recours à plusieurs échanges entre le terminal et le serveur d'autant plus que la bande passante allouée pour la communication entre le serveur et le terminal (notamment mobile) peut être restreinte.
La présente invention propose un mécanisme de stockage de données propres à des objets destinés à être agencés au sein de pages multimédia. Plus particulièrement, l'invention propose un processus de transmission et de décodage de fonctions de «cache» (c'est-à-dire une anticipation de lecture suivie d'une mémorisation) des données d'objets, préalablement à l'agencement spatiotemporel de ces objets dans une page multimédia.
Pour ce qui concerne l'édition de scènes graphiques, plusieurs formats de représentation graphique d'animations graphiques existent actuellement. Cependant, aucun de ces formats ne propose un mécanisme de " cache" d'informations sur les objets graphiques qui sont décrits au sein de la représentation graphique.
On connaît des techniques qui permettent de gérer des informations de " cache" d'une scène graphique en utilisant des méthodes programmatiques (par exemple en -MPEG/MPEGJ, ou VRML/EAI), ou encore protocolaires (par exemple en http, RTP, ou autres) , mais dans un but tout différent de celui de la présente invention. D'ailleurs, ces techniques souffrent d'un manque de souplesse en ce sens qu'il est impossible de télécharger des morceaux de contenu programmatique, ou encore parce que de telles techniques utilisent nécessairement les mécanismes protocolaires précités. Elles souffrent aussi d'un manque d'efficacité dans le rendu graphique en ce sens qu'il est souvent nécessaire de lancer une machine virtuelle pour traiter le contenu programmatique.
L'un des buts visés par la présente invention concerne la réduction de la mémoire des terminaux, nécessaire à l'édition de pages multimédia complexes, ou d'une succession de telles pages.
Un autre but visé par la présente invention concerne la réduction des ressources de calcul nécessaires à l'édition de telles pages, ou d'une succession de ces pages.
Un autre but visé par la présente invention est de fournir un procédé permettant d'accomplir les buts visés ci-avant tout en offrant une compatibilité avec les techniques classiques de décodage. Plus généralement, un but visé par la présente invention est d'offrir une plus grande flexibilité au niveau des requêtes et données échangées entre le serveur et le terminal.
La présente invention propose tout d'abord un procédé d'édition de pages multimédia auprès d'un terminal, dans lequel un serveur distribue, à un ou plusieurs terminaux, une partie au moins des pages multimédia sous forme d'instructions d'agencements d'objets au sein d'une page multimédia à construire, le procédé comportant : a) au moins une étape préalable pendant laquelle- le serveur transmet des données relatives à au moins un objet à agencer dans une page multimédia à construire, avec une instruction de stockage desdites données, identifiées par un lien, dans une mémoire du terminal, b) et au moins une étape courante pendant laquelle le serveur transmet un fichier descriptif comportant ledit lien, pour éditer, auprès du terminal, ledit objet dans au moins une page multimédia en construction, par lecture des données stockées dans la mémoire du terminal .
Ainsi, le procédé au sens de l'invention offre une plus grande flexibilité au niveau des requêtes et données échangées entre le serveur et le terminal, en permettant une anticipation sur le ou les objets qui seront édités dans les pages multimédia par le terminal. Typiquement, l'étape b) seule peut être réitérée plusieurs fois pour l'édition du même objet dans plusieurs pages multimédia successives, avantageusement sans télécharger nécessairement du serveur les données relatives à l'objet pour chaque page multimédia à construire.
Dans une réalisation, le serveur transmet au terminal lesdites données et l'instruction de stockage dans au moins un paquet de données.
Le stockage dans la mémoire du terminal est preferentiellement temporaire et l'instruction de stockage précitée comporte, dans cette réalisation, un paramètre de temporisation de valeur prédéterminée définissant une date d'expiration à compter de sa réception auprès du terminal.
Dans une autre réalisation, l'instruction précitée est de type " cache" entre le serveur et le terminal, avec une zone mémoire du terminal allouée pour le stockage des données associées à cette instruction, afin d'accélérer une exécution ultérieure répétée de l'étape b) , pour, le même objet.
Dans une réalisation, l'instruction de stockage comporte une information relative à un nombre de données que le terminal doit stocker en mémoire. Par exemple, l'instruction de stockage peut comporter un marqueur de début d'enregistrement des données et un marqueur de fin d'enregistrement des données, de sorte que le nombre de données précité est défini par ce couple de marqueurs. Avantageusement, le fichier descriptif -précité comporte un script incluant un ou plusieurs liens sous forme 'de requêtes URL (pour "UNIVERSAL RESSOURCE LOCATOR" ) .
De façon avantageuse, l'instruction de stockage est réalisée sous la forme d'une commande correspondant à une fonction de bas-niveau.
On indique d'ailleurs que de nombreuses scènes graphiques utilisent une représentation sous forme d'une liste de primitives (fonctions uniques d'exécution simple et dites de "bas-niveau") . Les fonctions de description de "cache" permettent alors d'anticiper la transmission et la lecture de plusieurs scènes graphiques au sein d'un service multimédia composite. Cette représentation -bas-niveau des fonctions de "cache" permet d'avoir une interaction fine avec les objets de l'animation tout en assurant un transport binaire entre le serveur et le terminal, notamment mobile. On réduit ainsi le temps de latence pour l'utilisateur final du terminal.
Dans un mode de réalisation, l'objet est un objet de type graphique comportant au moins l'un des éléments parmi :
- une image, - une séquence d'images,
- une séquence d'images synthétiques 2D,
- et une séquence d'images synthétiques 3D.
On indique que de telles séquences d'images sont susceptibles d'être utilisées par exemple par le standard MPEG-4, pour l'édition de scènes graphiques. Dès lors que cette instruction de stockage apparaît comme un moyen essentiel pour mettre en œuvre le procédé ci- avant, la présente invention vise aussi un produit programme sous forme de code informatique, et comportant une instruction de stockage, dans une mémoire d'un terminal, de données relatives à un objet destiné à être édité, auprès dudit terminal, dans une ou plusieurs pages multimédia dans lesquelles l'objet - est susceptible d'intervenir. La présente invention vise aussi un signal comportant ce code. Ce signal et/ou le produit programme lui-même, peuvent être transmis du serveur au terminal, ou encore émaner d'un support mémoire qui coopère avec un lecteur du terminal (tel qu'un lecteur de CD-ROM ou autre) .
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci- après, et des dessins annexés sur lesquels : - la figure 1 illustre les échanges entre un serveur SER et un terminal TER, pour le déroulement des étapes du procédé au sens de l'invention,
- la figure 2 représente schématiquement et partiellement les éléments d'un terminal TER, et - la figure 3 représente des agents logiciels interagissant pour l'édition de pa-ges multimédia auprès du terminal TER.
En annexe, on a retranscrit un code informatique de la commande " CACHE" (en format binaire) correspondant à l'instruction de stockage précitée. Il faut comprendre en particulier que la description et son annexe présentent des caractéristiques susceptibles de contribuer à la définition de l'invention.
En se référant à la figure 1,. le contexte d'application de l'invention peut être décrit par les étapes suivantes : - Le terminal mobile TER demande une ou plusieurs pages multimédia, par exemple un contenu d'animation graphique, à un serveur SER (étape 11) . - Le serveur SER renvoie un contenu (étape 12) comportant des données (audio, vidéo, texte, ou autres) propres à un objet, par exemple un objet graphique à éditer dans une scène graphique. Dans ce contenu est décrite une fonction de stockage temporaire "CACHE" (correspondant à l'instruction de stockage précitée), comme le montre la table 12-a. Cette fonction "CACHE" indique qu'un ensemble d'objets graphiques sera stocké en mémoire dans le terminal et sera, le cas échéant, accessible en réponse à une requête du même terminal. Cette fonction indique donc au terminal TER qu'il doit stocker des données relatives à un objet susceptible d'intervenir dans une ou plusieurs futures scènes graphiques à construire. Cet objet est identifié par un nœud graphique "node i" auquel on associe donc des données DATA propres à l'objet graphique.
- Le terminal stocke ces données DATA (étape 13) dans une zone mémoire ZMi du terminal, identifiable par un lien, par exemple une chaîne de caractère "node i".
- Le serveur SER envoie (étape 15) la description d'une scène incorporant l'objet "node i", le cas échéant avec des attributs Attr d'agencement de l'objet dans la scène (fichier descriptif par exemple sous forme de script 15-b) . - Le terminal TER reconnaît le lien "node i" vers la zone mémoire ZMi et récupère (étape 16) les données DATA préalablement stockées à l'étape 13 pour- éditer une scène graphique incluant l'objet correspondant au nœud "node i", avec les attributs d'agencement Attr qu'a transmis le serveur à l'étape 15. Le cas échéant, le terminal peut demander au serveur de nouveaux attributs, pour le même objet "node i", pour l'édition d'une nouvelle scène graphique incluant ce même objet (étape 14), si la durée de vie du stockage des données DATA auprès du terminal le permet, comme on le verra plus loin.
Cette commande CACHE est utilisée -pour stocker temporairement un ensemble de données DATA propres à un objet d'une scène à construire. Cette commande est preferentiellement regroupée avec les données DATA dans un même paquet (par exemple un - paquet Accè sUnit en MPEG-4/System, ou encore un paquet RTP) . Pour modifier une scène actuelle, le serveur transmet des paquets suivants (contenant une ou plusieurs commandes) .
On se réfère à la- figure 2 pour décrire brièvement des modules prévus classiquement dans un terminal TER. Le terminal comporte un module de communication 21, notamment avec le serveur SER, duquel il reçoit la commande "CACHE" précitée. A cette commande CACHE est associé un nœud graphique "node i" et le terminal stocke les données DATA dans une zone mémoire ZMi (i=l,2,„.) en correspondance de ce nœud "node i". Cette zone mémoire ZMi est prévue dans une mémoire MEM que comporte le terminal TER.
Ensuite, une commande suivante que transmet le serveur et relative à l'objet identifié par le nœud "node i", sera interprétée par le terminal comme visant le contenu de la zone mémoire ZMi et permettra donc de récupérer les données DATA relatives à cet objet. Ces données DATA sont ensuite traitées dans une mémoire de travail 22 (par exemple par un logiciel du terminal dit "PLAYER"), éventuellement distincte de la mémoire MEM. Les informations permettant l'édition de la scène à construire sont alors transférées vers une interface 23, par exemple une interface graphique pour un affichage de la scène (ou encore par une interface sonore pour un rendu sonore) . Comme ces données DATA sont preferentiellement temporaires, il sera fait référence à la valeur horaire lue auprès d'une horloge 24, habituellement prévue dans un terminal (notamment dans son processeur) .
On décrit ci-après la sémantique de la commande "CACHE" (décrite en format binaire dans l'annexe et appelée cacheObject) .
Un paquet "cacheObject" permet d'envoyer en avance un contenu qui s'exécutera par exemple en réponse à une requête URL (par exemple à la suite des étapes 14 et 15 de la figure 1) . Cette requête peut être faite suite à une commande d'un utilisateur du terminal (commande interactive) . Un cacheObject peut être permanent, dans sa définition, et stocké en mémoire à n'importe quel instant. Toutefois, les données associées au cacheObject ont une date d'expiration (dans la mémoire du terminal) définie par le temps de réception et la durée de vie TTL (pour "Time To Live") de ses données stockées temporairement. Cet attribut TTL indique en secondes le temps après lequel le cacheObject n'est plus valide.
Les attributs qui sont associés à cette commande cacheObject sont par exemple les suivants : • TTL : la durée de validité du cacheObject • URL : les données du cacheObject sont récupérées de la mémoire MEM, en réponse à ce lien URL • Source : les données DATA à stocker et qui pourront être récupérées ensuite.
Pour ce qui concerne les attributs Attr qui sont ensuite envoyés avec le nœud "node i", on cite à titre d'exemple une couleur et une police de caractères associées à un texte à afficher auprès du terminal, tandis que la chaîne de caractères, elle-même, du texte à afficher a été stockée préalablement en mémoire MEM du terminal, en tant que données DATA envoyées avec la commande CACHE au sens de l'invention.
On indique que la plupart des scènes graphiques nécessitent habituellement une représentation sous forme d'une liste de primitives (fonctions de bas-niveau) de rendu graphique. A chacune de ces primitives correspond une seule fonction, simple, d'attribution d'un paramètre d'édition graphique. La fonction de stockage CACHE, au sens de l'invention, se présente avantageusement comme une fonction de bas-niveau. Une représentation bas-niveau de cette fonction permet notamment d'avoir une interaction fine avec les objets de l'animation et un transport binaire entre le serveur et le terminal, notamment mobile.
Plus spécifiquement, on a retranscrit en annexe jointe l'instruction "cacheObject", en langage SDL (pour "Synthetic Description Language"), correspondant à un code adopté pour définir les formats de bitstreams (flux binaire), avec des octets associés à chaque champ. On indique que des détails relatifs à ce langage informatique peuvent être trouvés dans le descriptif de la norme ISO IEC 144-96.
On indique ici que la commande CACHE est déclarée par l'instruction const bit (4) 12 qui signifie que cette commande est déclarée par l'entier "12" qui devra se retrouver dans les quatre premiers bits du flux binaire que reçoit le terminal. Ainsi, si ces quatre premiers bits comportent l'entier "12", ils déclareront la commande CACHE. Ensuite, la commande bit (6) sglD déclare l'entier msglD qui, en fonction de sa valeur, lorsqu'il est reçu par le terminal, peut déclencher différentes actions auprès du terminal. Ici, ces actions sont "Permanent" (indique si le terminal doit garder les données de l'objet en mémoire ou non) et "Replace" (indique si le terminal doit remplacer le contenu de ses -données mémorisées par les nouvelles données arrivantes). Des combinaisons de ces actions (ou non-actions) sont aussi prévues, selon la valeur de msglD. t
13
Les commandes suivantes uint(X) déclarent : - le nombre d'octets à lire et à stocker "payloadLength", - la durée de vie des données stockées en mémoire "TTL", et
5 - un temps à lire "time", auprès d'une horloge du terminal 24 (figure 2) , pour respecter la durée de vie TTL. La commande byte(8) [payloadLength] payload indique que le terminal doit lire et, le cas échéant (selon la valeur de0 la variable msglD) , enregistrer toutes les données qu'il reçoit du serveur jusqu'à ce qu'il lise le marqueur "payloadLength" .
Enfin, la commande suivante STZString définit une manière5 de lire une chaîne de caractères pour lire un lien URL soit vers la mémoire du terminal, soit vers des pages html du serveur.
Ainsi, le serveur transmet des pages multimédia qui0 contiennent des liens et les réponses associées à ces liens avec une instruction- de stockage de ces réponses sur le terminal. Le terminal peut soit accepter,' soit refuser de stocker ces réponses, par exemple si elles sont trop volumineuses ou si le délai d'expiration st trop court ou5 trop long. Suite à une Interaction • de l'usager ou l'exécution d'un script pour une ' demande du contenu d'un lien dans une des pages multimédia, le terminal accède prioritairement à la réponse stockée sur le terminal, si elle est effectivement stockée.0 On se réfère maintenant à la figure 3 pour décrire un modèle de transmission et de rendu de scènes graphiques.
Une pluralité de modules 42 (décodeurs d'images divers), 43 (gestion de protocoles réseaux) , 44 (gestion de polices (ou caractères) de texte) , sont stockés en mémoire 41 du terminal TER, en tant que résidents mémoire. En outre, un logiciel client 45, di "PLAYER", est aussi stocké en tant que résident mémoire dans la mémoire 41.
Le PLAYER 45 permet de visualiser des contenus animés, interactifs et multimédia sur le terminal mobile. Essentiellement, ce logiciel télécharge ou lit des informations qui décrivent l'agencement spatio-temporel d'objets graphiques, la façon dont ils sont synchronisés et les interactions de l'utilisateur du terminal qui sont possibles sur ce contenu.
Le PLAYER 45 interprète alors les interactions de l'utilisateur et en déduit les comportements appropriés. des objets graphiques ou les requêtes à effectuer sur le serveur de contenus. Le PLAYER 45 (par exemple de type
" STREAMEZZO" ) inclut des fonctions de rendu d'objets graphiques et des moteurs pour la visualisation (moteur de rendu graphique 50) et l'interaction (moteur d'interaction
51) avec la scène multimédia. Le PLAYER 45 utilise les modules 42, 43, 44 en tant qu'API ("Application Program
Interface") du système du terminal mobile qui permettent : • de décoder les images (module 42) , • de récupérer un flux venant du réseau ou d'une source locale (module 43) , et • de gérer l'affichage du texte et notamment les polices résidentes en standard dans le terminal mobile (module 44) .
Les contenus pour l'édition comprennent des graphiques vectoriels animés, du son, de la vidéo et des interactions utilisateur. La visualisation de contenus multimédia interactifs, dans des environnements mobiles, nécessite habituellement l'utilisation des techniques de compression afin d'assurer une mise à disposition efficace du contenu et une optimisation du rendu des objets graphiques composant ce contenu. Ce contenu peut alors être visualisé dans de bonnes conditions sur les terminaux mobiles. Les informations lues ou téléchargées par le PLAYER 45 sont donc fortement compressées et le PLAYER doit donc décompresser ces données et les interpréter à la volée pour jouer le contenu.
Plus particulièrement, le PLAYER 45 comporte des modules de décodage audio et vidéo, respectivement 46 et 47, un analyseur de flux décodé 49, un gestionnaire de média 48, un moteur de rendu (graphique ou sonore) 50 et un moteur d'interactivité 51.
Le fonctionnement du logiciel PLAYER peut se décrire selon les étapes suivantes : saisie des données d'entrée via une connexion" réseau ou une lecture de fichier, décompression de ces données afin d'obtenir une description des objets graphiques directement utilisables par le moteur de rendu audio et graphique 50, composition des objets graphiques entre eux pour créer une scène graphique, - rendu graphique proprement dit des objets audio et graphiques, par affichage d'objets visuels ou par jeu d'un son, prise en compte des interactions utilisateurs, par exemple un clique d'un pointeur, ou la pression d'une touche, ou autres, établissement d'une connexion à une source d'information locale ou distante si nécessaire.
Suite à une requête de l'utilisateur, cette dernière étape va consister en l'ouverture d'une connexion vers le serveur SER et récupérer un flux binaire. Ce flux binaire est analysé par le PLAYER 45 qui crée alors un objet ScèneGraph contenant les différents objets de la scène sous forme de nœuds d'un graphe. Le flux d'information est découpé en paquets qui regroupent des informations qui, dans une réalisation préférée, ne sont valides uniquement qu'à un instant donné et correspondent à un seul type d'information (principe de 1 ' "AccessUnit" du standard MPEG-4) .
Le PLAYER analyse chaque paquet et exécute les commandes qui y sont décrites suivant son horloge (non représentée sur les figures), laquelle fournit le temps de la scène multimédia et, le cas échant, la durée de validité TTL des données DATA associées à une commande CACHE. Ainsi, on comprendra que ce PLAYER 45, notamment avec les autres modules 42, 43 et 44 du terminal, peut assurer le processus de réception et de décodage d'une fonction de stockage CACHE de données d'objets graphiques intervenant dans des scènes graphiques, au sens de la présente invention.
Cette fonction de stockage permet de gérer la représentation d'un objet et/ou la modification de son agencement dans une scène, sans avoir à télécharger systématiquement les mêmes données de l'objet dans le terminal. Ainsi, cette fonction permet de lier plusieurs scènes graphiques en un service multimédia composite, avantageusement lorsque le même objet intervient fréquemment dans ces scènes.
Plus généralement, le procédé au sens de l'invention permet une réduction de la mémoire (par exemple la mémoire graphique) du terminal, puisque l'on ne mémorise que l'instruction de stockage de données sur les nœuds graphiques .
Le procédé au sens de l'invention permet aussi un gain dans l'utilisation des ressources de calcul, puisque, typiquement, l'utilisation d'un contenu programmatique tel que défini ci-avant induirait un net surcoût de calcul, au moins pour certaines animations. Avantageusement, le procédé au sens de l'invention, utilisant un mécanisme conforme à un processus classique de rendu de commande graphique, dans une réalisation préférée, est alors facile à implémenter, en particulier pour un système à terminaux mobiles coopérant avec des réseaux cellulaires.
Le procédé au sens de l'invention offre aussi une compatibilité avec les techniques classiques de décodage, puisque le procédé peut être mis en œuvre dans la plupart des dispositifs de rendu graphique.
On indique que le procédé de l'invention, très général, peut s'appliquer à pratiquement toutes les descriptions d'animations graphiques actuelles telles que MPE'G-4/BΓFS, SVG, ou autres, dès lors qu'une application requiert la représentation des signaux qui la composent sous forme d'un agencement spatio-temporel d'objets graphiques.
Annexe
cacheObject { constbit(4) 12; bit (6) msglD; if (msglD == 2) { isPermanent = false; isReplace = true; } else if (msglD == 4) { isPermanent = true; isReplace = true; } else if (msglD == 6) { isPermanent = false; isReplace = false; } else if (msglD == 7) {' isPermanent = true; isReplace = false; } uint(24) payloadLength; uint(32) time; byte (8) [payloadLength] payload; uint(32) TTL; STZString url;
}
STZString { uint(5) len; uint(len) sien; byte (8) [len] UTF-string; }

Claims

Revendications
1. Procédé d'édition de pages multimédia auprès d'un terminal, dans lequel un serveur distribue, à un ou plusieurs terminaux, une partie au moins desdites pages multimédia sous forme d'instructions d'agencements d'objets au sein d'une page multimédia à construire, caractérisé en ce que le procédé comporte : a) au moins une étape préalable pendant laquelle le serveur transmet des données relatives à au moins un objet à agencer dans une page multimédia à construire, avec une instruction de stockage desdites données, identifiées par un lien, dans une mémoire du terminal, b) et au moins une étape courante pendant laquelle le serveur transmet un fichier descriptif comportant ledit lien, pour éditer, auprès du terminal, ledit objet dans au moins une page multimédia en construction, par lecture des données stockées dans la mémoire du terminal.
2. Procédé selon la revendication 1, caractérisé en ce que le serveur transmet au terminal lesdites données et l'instruction de stockage dans au moins un paquet de données .
3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que le stockage dans la mémoire du terminal est temporaire.
4. Procédé selon la revendication 3, caractérisé en ce que ladite instruction comporte un paramètre de temporisation de valeur prédéterminée définissant une date d'expiration à compter de sa réception auprès du terminal.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que ladite instruction est de type
" cache" entre le serveur et le terminal, avec une zone mémoire du terminal allouée pour le stockage des données associées à ladite instruction, afin d'accélérer une exécution ultérieure répétée de l'étape b) , pour le même objet.
6. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'instruction de stockage comporte une information relative à un nombre de données que le terminal doit stocker en -mémoire.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit fichier descriptif comporte un script incluant un ou plusieurs liens sous forme -de requêtes URL.
8. Procédé selon l'une des revendications précédentes, caractérisé en ce que ladite instruction de stockage est réalisée sous la forme d'une commande correspondant à une fonction de bas-niveau.
9. Procédé selon l'une des revendications précédentes, caractérisé en ce que le terminal est un terminal mobile agencé pour coopérer avec un réseau cellulaire.
10. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit objet est un objet de type graphique comportant au moins l'un des éléments parmi :
- une image, - une séquence d'images,
- une séquence d'images synthétiques 2D,
- et une séquence d'images synthétiques 3D.
11. Produit programme sous forme de code informatique, caractérisé en ce qu'il comporte une instruction de stockage, dans une mémoire d'un terminal, de données relatives à un objet destiné à être édité, auprès dudit terminal, dans une ou plusieurs pages multimédia dans lesquelles ledit objet est susceptible d'intervenir.
12. Signal comportant un code informatique, caractérisé en ce que le code comporte une instruction de stockage, dans une mémoire d'un terminal, de données relatives à un objet destiné à être édité, auprès dudit terminal, dans une ou plusieurs pages multimédia dans lesquelles ledit objet est susceptible d'intervenir.
EP04710896A 2004-02-13 2004-02-13 Procede d'edition d'une page multimedia avec pre-memorisation Withdrawn EP1714458A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FR2004/000337 WO2005088927A1 (fr) 2004-02-13 2004-02-13 Procede d’edition d’une page multimedia avec pre-memorisation

Publications (1)

Publication Number Publication Date
EP1714458A1 true EP1714458A1 (fr) 2006-10-25

Family

ID=34957123

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04710896A Withdrawn EP1714458A1 (fr) 2004-02-13 2004-02-13 Procede d'edition d'une page multimedia avec pre-memorisation

Country Status (3)

Country Link
US (1) US20080243857A1 (fr)
EP (1) EP1714458A1 (fr)
WO (1) WO2005088927A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105224561A (zh) * 2014-06-24 2016-01-06 鸿合科技有限公司 一种基于分页文件的缓存保存方法和装置

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2890815B1 (fr) * 2005-09-14 2007-11-23 Streamezzo Sa Procede de transmission d'un contenu multimedia vers un terminal de radiocommunication, programme d'ordinateur, signal, terminal de radiocommunication et serveur de diffusion correspondants
KR101392166B1 (ko) * 2006-12-18 2014-05-08 삼성전자주식회사 휴대용 디스플레이 장치의 이미지 편집 방법, 편집 이미지생성 방법 및 편집된 이미지 저장 방법 및 장치

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6591288B1 (en) * 1998-05-19 2003-07-08 Nortel Networks Limited Data network accelerated access system
US6085198A (en) * 1998-06-05 2000-07-04 Sun Microsystems, Inc. Integrated three-tier application framework with automated class and table generation
FI113231B (fi) * 2000-01-17 2004-03-15 Nokia Corp Menetelmä sanomien sisältämän informaation esittämiseksi multimediapäätelaitteessa, multimediasanomien välitysjärjestelmä ja multimediapäätelaite
US6938079B1 (en) * 2000-09-19 2005-08-30 3Com Corporation System and method for automatically configuring a client device
US6954754B2 (en) * 2001-04-16 2005-10-11 Innopath Software, Inc. Apparatus and methods for managing caches on a mobile device
US6813690B1 (en) * 2001-06-12 2004-11-02 Network Appliance, Inc. Caching media data using content-sensitive identifiers
US9342459B2 (en) * 2002-08-06 2016-05-17 Qualcomm Incorporated Cache management in a mobile device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005088927A1 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105224561A (zh) * 2014-06-24 2016-01-06 鸿合科技有限公司 一种基于分页文件的缓存保存方法和装置
CN105224561B (zh) * 2014-06-24 2020-04-17 鸿合科技股份有限公司 一种基于分页文件的缓存保存方法和装置

Also Published As

Publication number Publication date
WO2005088927A1 (fr) 2005-09-22
US20080243857A1 (en) 2008-10-02

Similar Documents

Publication Publication Date Title
US20070005795A1 (en) Object oriented video system
EP2109077A2 (fr) Procédé et produit de programme informatique pour la fourniture de publicités ? un dispositif d'utilisateur mobile
CN111818354B (zh) 动画配置、播放方法、装置、电子设备、系统和介质
WO2007051784A1 (fr) Procede d'optimisation de rendu d'une scene multimedia, programme, signal, support de donnees, terminal et procede de reception correspondants
CN107659831A (zh) 媒体数据处理方法、客户端、及存储介质
CN114245228A (zh) 页面链接投放方法、装置及电子设备
EP1696670A2 (fr) Signal de données de modification d'une scène graphique, procédé et dispositif correspondants
US6753863B1 (en) System and method for streaming real time animation data file
FR2899364A1 (fr) Procede de calcul des parametres d'animation des objets d'une scene mulitmedia.
WO2005088927A1 (fr) Procede d’edition d’une page multimedia avec pre-memorisation
EP1762068B1 (fr) Procede d'edition de pages multimedia aupres d'un terminal,avec pre-memorisation de parametres d'objets intervenant dans les scenes
EP1997040A1 (fr) Procédé, dispositif et système de gestion d'informations structurées au sein d'une scène graphique
US20020007419A1 (en) Internet service provider server system, method of providing data, method of advertising using moving pictures, and recording media therefor
EP1004206B1 (fr) Signal d'animation d'une scene graphique, procede et dispositif correspondants
FR2765984A1 (fr) Signal de donnees d'animation d'une scene graphique a objet de quantification, procede et dispositif correspondants
FR2928803A1 (fr) Fourniture de services a partir d'objets filmes ou photographies depuis un terminal mobile.
EP1383336B1 (fr) Procédé de décompression et de restitution d'un flux de données multimédia numériques compressées comprenant une pluralité d'entités encodées. Dispositif, système et signal correspondants
EP1314109B1 (fr) Procede pour l'exploitation d'applications graphiques sur un terminal mobile
Arsov A framework for distributed 3D graphics applications based on compression and streaming
CN115581124A (zh) 用于处理dash和cmaf带内事件的扩展的w3c媒体扩展
WO2023280623A1 (fr) Augmentation d'un environnement vidéo ou externe avec des graphiques 3d
WO2020234030A1 (fr) Restitution d'un contenu en arrière-plan ou sous forme d'incrustation dans le cadre d'un téléchargement progressif adaptatif de type has
CN117121493A (zh) 关于3d对象的用户输入的分析方法、装置和程序
Chen et al. Streaming MPEG Animation on Mobile Devices
CHEN STREAMING MPEG ANIMATIONS

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060814

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20070201

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110506