FR2853797A1 - Procede et dispositif de pre-traitement de requetes liees a un signal numerique dans une architecture du type client-serveur - Google Patents

Abstract

Ce procédé de transfert d'une suite de portions d'un premier signal numérique par un serveur à un client, suivant une pluralité de requêtes à recevoir en provenance du client, comporte une étape (912) consistant à préparer, au niveau du serveur, avant le transfert du premier signal numérique, des réponses appropriées à une suite de requêtes client déduite d'un second signal numérique et anticipant la pluralité de requêtes à recevoir en provenance du client.

Description

PROCEDE ET DISPOSITIF DE PRE-TRAITEMENT DE REQUETES LIEES A UN SIGNAL

NUMERIQUE

DANS UNE ARCHITECTURE DU TYPE CLIENT-SERVEUR

La présente invention se rapporte à un procédé et à un dispositif de prétraitement de requêtes liées à un signal numérique dans une architecture du type client-serveur.

Elle appartient au domaine des systèmes de transmission progressive de données d'un serveur vers un client.

Elle est décrite ici plus particulièrement, mais de façon nullement limitative, dans son application à des signaux numériques représentant des images au format normalisé JPEG2000.

Dans le contexte de l'intégration de portions d'une image comprimée JPEG2000 dans une animation, par exemple du type Macromédia Flash, et de 15 la transmission de cette animation par un serveur à un client, dans une architecture client-serveur, le format d'animation Flash fournit notamment la possibilité d'inclure des animations prédéfinies.

La partie 9 de la norme JPEG2000, appelée JPIP (JPEG2000 Interactive Protocol), propose un protocole de transfert de portions d'images 20 JPEG2000. Ce protocole fournit une syntaxe de requêtes et de réponses, appelées requêtes JPIP et réponses JPIP.

Par conséquent, la transmission progressive, d'un serveur vers un client, d'une animation du type Flash consistant en une suite de portions d'une image JPEG2000 peut s'effectuer à travers un ensemble de requêtes JPIP 25 émises par le client et traitées par le serveur.

On cherche à minimiser, côté serveur, le temps de traitement d'un ensemble de requêtes JPIP correspondant à une animation prédéfinie telle que mentionnée ci-dessus, afin de minimiser la durée du téléchargement d'une telle animation par le client.

Le logiciel Kakadu, disponible sur Internet à l'adresse http://www. kakadusoftware.com, dédié au traitement d'images JPEG2000, permet au serveur de construire un cache qui est prêt à former et transmettre au client des messages de réponse JPIP. Cependant, les données stockées dans le cache consistent en des code-blocs (en anglais "codeblocks"), qui sont des représentations comprimées d'une partie rectangulaire élémentaire d'une image éventuellement transformée en sous-bandes. Les code-blocs sont 5 destinés à être encapsulés dans des paquets. Par conséquent, le serveur doit non seulement engendrer des en-têtes de paquets JPEG2000 mais aussi les en-têtes des messages JPIP pour transmettre des données au client. Cela augmente le temps de traitement des requêtes JPIP, ce qu'on cherche précisément à éviter.

La présente invention a pour but de remédier à cet inconvénient.

Dans ce but, la présente invention propose un procédé de transfert d'une suite de portions d'un premier signal numérique par un serveur à un client, suivant une pluralité de requêtes à recevoir en provenance du client, ce procédé étant remarquable en ce qu'il comporte une étape consistant à 15 préparer, au niveau du serveur, avant le transfert du premier signal numérique, des réponses appropriées à une suite de requêtes client déduite d'un second signal numérique et anticipant la pluralité de requêtes à recevoir en provenance du client.

La présente invention permet ainsi d'optimiser la réactivité d'un 20 serveur vis-à-vis de requêtes correspondant à une animation dans un signal numérique, prédéfinie et connue à l'avance par le serveur.

Selon une caractéristique particulière, le second signal numérique est un fichier descriptif, connu du serveur et envoyé au client, décrivant un surensemble des portions à transférer du serveur au client.

Ce fichier descriptif permet d'obtenir une description complète d'une animation formée de portions d'images. Le client pourra ensuite formuler des requêtes sur les portions qui lui manquent.

Selon une caractéristique particulière, l'étape de préparation des réponses est effectuée lorsque le client émet une requête sur le fichier descriptif 30 mentionné ci-dessus.

Cela permet d'éviter de surcharger la mémoire vive du serveur et de limiter la charge mémoire permanente du serveur aux données utiles qui présentent une forte probabilité d'être demandées dans le futur par des clients.

Dans un premier mode particulier de réalisation, les réponses 5 préparées par le serveur sont des en-têtes de messages de retour accompagnés chacun d'un pointeur vers le début d'un segment de données utiles à associer à l'en-tête, le segment de données utiles étant mémorisé dans le premier signal numérique au niveau du serveur.

Ainsi, les réponses préparées occupent une place mémoire réduite 10 dans le serveur, puisqu'elles ne contiennent que les en-têtes des messages à transmettre et autant de pointeurs sur le fichier contenant la suite de portions du premier signal numérique.

Dans un deuxième mode particulier de réalisation, les réponses préparées par le serveur sont des messages comportant chacun un en-tête et 15 un corps constitué de données comprimées du premier signal numérique.

Ainsi, le serveur n'a plus qu'à transmettre ces réponses déjà formées lorsqu'il reçoit des requêtes en provenance du client. Le délai de réponse du serveur au client est encore réduit par rapport au premier mode de réalisation car le temps d'extraction des données utiles du fichier d'origine est supprimé.

Dans un troisième mode particulier de réalisation, le procédé comporte en outre une étape consistant à insérer les réponses dans un fichier contenant la suite précitée de portions du premier signal numérique, ce fichier étant destiné au client.

Cela permet de réduire considérablement le nombre d'allers-retours 25 entre le client et le serveur pour transmettre l'ensemble de la suite de portions du premier signal numérique.

Selon une caractéristique particulière, le procédé comporte en outre une étape consistant à fragmenter le segment de données utiles.

Cette étape permet de prendre en compte l'état du cache du client 30 au moment de former les messages de réponse définitifs destinés au client et permet ainsi d'éviter de transmettre au client des données déjà stockées dans son cache.

L'étape de fragmentation peut consister à découper une suite d'octets du segment de données utiles en au moins deux portions si la taille de cette suite d'octets dépasse un seuil prédéterminé.

On peut ainsi contrôler finement le débit des données transmises au client.

Le premier signal numérique est par exemple un signal d'image.

Dans une application privilégiée de l'invention, le signal d'image est représentatif d'une image codée suivant la norme JPEG2000.

Selon une caractéristique particulière, la suite précitée de portions du 10 premier signal numérique est représentative d'une animation du type Flash et le fichier descriptif précité est encapsulé dans cette animation.

Selon une caractéristique particulière, le procédé conforme à l'invention met en oeuvre le protocole de transfert JPIP (JPEG2000 Interactive Protocol).

Dans le même but que celui mentionné plus haut, la présente invention propose également un dispositif de transfert d'une suite de portions d'un premier signal numérique par un serveur à un client, suivant une pluralité de requêtes à recevoir en provenance du client, ce dispositif étant remarquable en ce qu'il comporte des moyens pour préparer, au niveau du serveur, avant le 20 transfert du premier signal numérique, des réponses appropriées à une suite de requêtes client déduite d'un second signal numérique et anticipant la pluralité de requêtes à recevoir en provenance du client.

La présente invention vise aussi un appareil de communication comportant un dispositif tel que ci-dessus. 25 L'invention vise aussi: - un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, permettant la mise en oeuvre d'un procédé tel que ci-dessus, et - un moyen de stockage d'informations amovible, partiellement ou 30 totalement, lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, permettant la mise en oeuvre d'un procédé tel que ci-dessus.

L'invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable et comportant des séquences d'instructions pour mettre en oeuvre un procédé tel que ci-dessus, lorsque ce programme est chargé et exécuté par l'appareil programmable.

Les caractéristiques particulières et les avantages du dispositif, de l'appareil de communication, des différents moyens de stockage et du produit programme d'ordinateur étant similaires à ceux du procédé selon l'invention, ils ne sont pas rappelés ici.

D'autres aspects et avantages de l'invention apparaîtront à la lecture 10 de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemple non limitatif. La description se réfère aux dessins qui l'accompagnent, dans lesquels: - la figure 1 illustre de façon schématique les interactions entre les différentes entités intervenant dans la mise en oeuvre de l'invention, dans un 15 mode particulier de réalisation; - la figure 2 représente de façon schématique un dispositif mettant en oeuvre la présente invention, dans un mode particulier de réalisation; - la figure 3 fournit un exemple de suite de portions d'une image JPEG2000 susceptible d'être transmise par un serveur à un client 20 conformément à la présente invention; - la figure 4 illustre la notion de "precinct" - la figure 5 illustre la notion d'incrément de precinct (en anglais "precinct data-bin incremenr'); - la figure 6 est un synoptique illustrant un premier mode particulier 25 de réalisation du procédé conforme à la présente invention; - la figure 7 représente de façon schématique le contenu des réponses JPIP partielles préparées à l'avance pour une animation Flash, dans le premier mode de réalisation; - la figure 8 est un organigramme illustrant les principales étapes du 30 fonctionnement du client dans le premier mode de réalisation; - la figure 9 est un organigramme illustrant les principales étapes du fonctionnement du serveur dans le premier mode de réalisation; - la figure 10 représente de façon schématique le contenu des réponses JPIP préparées à l'avance pour une animation Flash, dans un deuxième mode particulier de réalisation de l'invention; et - la figure 11 est un synoptique illustrant un troisième mode particulier de réalisation de l'invention.

On rappelle tout d'abord certaines notions de base relatives aux données manipulées, d'une part, conformément à la norme JPEG2000 et, d'autre part, conformément au protocole JPIP.

Dans la norme JPEG2000, un fichier est composé d'un préambule 10 JPEG2000 optionnel, et d'un flux de données codées (en anglais "codestream") comportant un en-tête principal et au moins une tuile.

Une tuile représente de façon comprimée une partie rectangulaire de l'image d'origine considérée. Chaque tuile est formée d'un en-tête de tuile (en anglais "tile header') et d'un ensemble de données d'image comprimée appelé 15 flux binaire de tuile (en anglais "tile bitstream").

Chaque flux binaire de tuile comporte une séquence de paquets.

Chaque paquet contient un en-tête et un corps. Le corps d'un paquet contient au moins un code-bloc, qui, comme indiqué plus haut, est une représentation comprimée d'une partie rectangulaire élémentaire d'une image éventuellement 20 transformée en sous-bandes. L'en-tête de chaque paquet résume d'une part la liste des code-blocs contenus dans le corps considéré, et contient d'autre part des paramètres de compression propres à chacun de ces code-blocs. Chaque code-bloc est comprimé sur plusieurs niveaux de qualité incrémentaux: une couche de base et des couches de raffinement. Chaque niveau ou couche de 25 qualité d'un code-bloc est contenu dans un paquet distinct.

Un paquet d'un flux binaire de tuile d'un fichier JPEG2000 contient donc un ensemble de code-blocs correspondant à une tuile, une composante, un niveau de résolution, un niveau de qualité et une position spatiale (également appelée "precinct") donnés.

La portion de flux de données codées correspondant à une tuile peut être divisée en plusieurs segments contigus appelés portions de tuile (en anglais "tile-parts"). Autrement dit, une tuile contient au moins une portion de tuile. Une portion de tuile contient un en-tête (l'en-tête de portion de tuile, en anglais "tile-part heade,') et une séquence de paquets. La division en portions de tuile est opérée à des frontières entre paquets.

Le protocole JPIP permet de transférer des portions de fichier 5 JPEG2000. Différentes classes d'entités d'un fichier JPEG2000, appelées aussi "data-bin" en anglais, sont prévues par la future norme JPIP: méta-données (en anglais "meta data-bin"): consiste en la suite d'octets consécutifs du train binaire (en anglais "byte-range") contribuant à un ensemble donné de méta-informations sur une image comprimée JPEG2000; 10 en-tête principal (en anglais "main header data- bin"): consiste en la suite d'octets consécutifs du train binaire JPEG2000 initial contribuant à l'entête principal du fichier JPEG2000; - en-tête de tuile (en anglais "tile header data-bin"): consiste en la suite d'octets consécutifs du train binaire JPEG2000 initial contribuant à un en15 tête de tuile de l'image JPEG2000 d'origine; - precinct (en anglais "precinct data-bin"): dans la terminologie JPIP, un precinct consiste en l'ensemble des paquets des différentes couches de qualité de l'image qui correspondent à une même position spatiale; - tuile (en anglais "tile data-bin"): consiste en une suite d'octets 20 consécutifs contribuant à une même portion de tuile.

Chaque classe possède un identifiant "Class-ld" unique. Une réponse JPIP consiste en un paragraphe d'en-tête conforme au protocole HTTP, suivi d'une suite de messages ou incréments (en anglais "data-bin increments") JPIP. Chaque message de réponse consiste en une suite d'octets 25 consécutifs contribuant chacun de façon incrémentale à un data-bin donné. Il est constitué d'un en-tête et d'un corps. L'en-tête d'un message contient les champs suivants: "Bin-lc', "[, Csn]", "Msg-Offset", "MsgLength" et "[, Aux]".

Les champs Bin-ld et [, Csn] ont pour but d'identifier de façon unique le data-bin auquel le message considéré contribue. Ils transportent les trois 30 informations suivantes: - l'indice du flux de données codées auquel appartient le data-bin, dans le cas o le fichier initial JPEG2000 contient plusieurs flux de données codées; - l'identifiant de la classe (Class-ld) du data-bin considéré; - l'identifiant du data-bin au sein de la classe à laquelle il appartient ou "In-Class-Icf'.

Les champs Msg-Offset et Msg-Length qui suivent dans l'en-tête du message indiquent quels sont les octets transportés par les données utiles contenues dans le message JPIP. En effet, le data-bin identifié par le début de 10 l'en-tête correspond à un segment de données contenu dans le fichier JPEG2000 initial. Le champ Msg-Offset indique la position du premier octet des données utiles du data-bin dans ce segment de données. Le champ MsgLength indique le nombre d'octets de données utiles contenus dans le data-bin et extraits du segment de données cité ci-dessus à partir de la position Msg15 Offset.

Enfin, le corps de chaque message est constitué d'une portion de MsgLength octets des données utiles transportées par le data-bin. Cette portion de données est extraite du train binaire JPEG2000 d'origine, et correspond à la suite d'octets consécutifs du train binaire (Msg-Offset, Msg20 Iength) spécifiée dans l'en-tête du message.

Les requêtes de données d'image, selon le protocole JPIP, sont constituées de plusieurs types de champs: - les champs de fenêtre de visualisation indiquent au serveur la zone d'intérêt courante désirée par le client. Ces champs incluent notamment le 25 niveau de résolution de l'image associé à la zone, la position de la fenêtre dans l'image, la taille de la fenêtre (hauteur et largeur), les composantes de l'image incluses dans la zone d'intérêt. De plus, la future norme JPIP prévoit plusieurs paramètres optionnels, utiles pour contrôler la quantité de données contenues dans la réponse du serveur. Ces paramètres peuvent limiter le nombre 30 maximum d'octets de données utiles à retourner pour la zone considérée, le nombre maximum de couches de qualité à retourner ou encore le facteur de qualité d'image à satisfaire pour la zone d'intérêt; - des champs relatifs au cache du client fournissent au serveur des informations relatives au cache du client émetteur de la requête: * model=<model-elements> Cette instruction indique au serveur comment mettre à jour le 5 modèle de cache qu'il maintient pour un client donné, au sein d'une session donnée. Chaque entité de la chaîne de caractères "model-elements" indique, selon une syntaxe définie par JPIP, un élément du cache du client, éventuellement précédé du signe soustractif '-'. Les éléments précédés de '-' indiquent des entités 10 que le client a retirées de son cache. Les autres sont additifs et indiquent des entités que le client possède et a stockées dans son cache. Ce type d'instruction est seulement valable pour un serveur dit "à état" (en anglais "statefui servne') (cette notion est définie plus loin).

* need=<bin-descriptors> Cette instruction indique au serveur que seuls les incréments indiqués, et pertinents vis-à-vis de la zone d'intérêt, font partie de la requête du client. Cette instruction s'applique uniquement à un serveur dit "sans état" (en anglais "stateless serve/') (cette notion 20 est définie plus loin).

On suppose ici que les données sont transférées du serveur vers le client sous forme de données d'en-tête (méta-données, en-tête principal et entête de tuile) et de données comprimées sous la forme d'incréments de precinct ou d'incréments de tuile. Autrement dit, on se place ici dans un cas particulier 25 non limitatif o les données JPIP retournées du serveur vers le client sont conformes au type de média (en anglais "media- type") JPP-STREAM.

Conformément à l'invention, on prépare, au niveau du serveur JPIP, des réponses JPIP appropriées à la suite de requêtes JPIP correspondant à une animation Flash. En effet, le fichier Flash contenant l'animation considérée 30 est initialement localisé au niveau d'un serveur de fichiers Flash, éventuellement identique au serveur JPIP considéré. Par conséquent, le serveur connaît déjà l'animation contenue dans le fichier avant de transmettre celle-ci au client. Le serveur peut donc en déduire la suite de requêtes JPIP susceptibles de lui être transmises par un client lorsque l'utilisateur désirera visualiser l'animation.

La présente invention se fonde sur cette hypothèse et permet de 5 préparer à l'avance les réponses JPIP adaptées à la suite de requêtes JPIP déduite de l'animation considérée. Ainsi, lorsque le serveur reçoit des requêtes JPIP en provenance d'un client, il dispose déjà de la réponse JPIP pré-formatée correspondante et n'a plus qu'à transmettre celle-ci au client considéré. Cela minimise donc le temps de traitement de requêtes JPIP correspondant à une 10 animation Flash prédéfinie et connue du serveur.

La préparation des réponses JPIP peut prendre diverses formes, correspondant à différents modes de réalisation de l'invention proposée.

Une première forme possible de réponse préformée par le serveur consiste en des en-têtes de messages de retour JPIP (cf. ci-dessus la 15 description des classes de data-bin), suivis chacun par un pointeur sur la position dans le fichier JPEG2000 du début du segment de données utiles à associer à l'en-tête pour terminer le message JPIP. Ainsi, à la réception d'une requête JPIP, le serveur n'a plus qu'à extraire les données utiles du fichier pour chaque incrément à transmettre et à les concaténer à la suite de l'en-tête du 20 message JPIP correspondant. Un avantage de ce premier mode de réalisation réside en ce que les réponses préformées occupent un espace restreint en mémoire ou sur le disque dur du serveur, dans la mesure o elles ne contiennent que les en-têtes des messages JPIP à transmettre et autant de pointeurs sur le fichier JPEG2000. Ce premier mode de réalisation est décrit 25 plus en détail ci- après en liaison avec les figures 6 à 9.

Un deuxième mode de réalisation de l'invention consiste à construire entièrement des messages de réponse JPIP tels que décrits plus haut. Ces messages JPIP entièrement construits contiennent donc à la fois chacun un entête et un corps constitué de données comprimées du signal d'origine. 30 L'avantage de ce deuxième mode de réalisation est que le serveur n'a plus qu'à transmettre ces réponses déjà formées lorsqu'il reçoit des requêtes JPIP en provenance du client. L'avantage par rapport au premier mode de réalisation il est un délai de réponse inférieur du serveur, correspondant à la suppression du temps d'extraction des données utiles du fichier d'origine. En revanche, ce mode de réalisation nécessite un plus grand espace de stockage pour le cache du serveur. Ce deuxième mode de réalisation est décrit plus en détail ci-après en liaison avec la figure 10.

Un troisième mode de réalisation de l'invention proposée consiste à construire des messages de réponse JPIP complets côté serveur, et à les insérer directement dans le fichier contenant l'animation Flash. Ce mode de réalisation suppose une utilisation particulière du protocole JPIP, o le 10 paradigme de base, similaire à celui de HTTP et consistant à associer exactement une réponse serveur à une requête client, n'est plus respecté.

Néanmoins, le grand avantage de ce scénario de type "streaming" de l'animation Flash est l'absence de requêtes de la part du client. Cela permet de réduire considérablement le nombre d'allers-retours entre le client et le serveur 15 pour transmettre l'ensemble de l'animation, Ce troisième mode de réalisation est décrit plus en détail ci-après en liaison avec la figure 11.

La figure 1 illustre le contexte dans lequel s'applique la présente invention. Un scénario typique d'utilisation de l'invention implique un serveur JPIP 12 et un serveur de fichiers Flash 14, éventuellement localisés sur la 20 même machine, et un client.

Le client est constitué d'un client Flash 16 et d'un client JPIP 18. Le client Flash 16 est apte à rapatrier des données représentatives d'une animation Flash en provenance du serveur Flash 14 via un réseau de communication 22 puis à décomprimer et afficher cette animation au moyen 25 d'une interface homme-machine 24. Le client JPIP 18 est capable d'envoyer des requêtes JPIP, de recevoir des réponses JPIP en provenance du serveur JPIP 12, et de stocker celles-ci dans un cache 20.

Un scénario typique consiste dans un premier temps, pour le client Flash 16, à rapatrier un fichier Flash en provenance du serveur Flash 14, ce 30 fichier Flash contenant une séquence d'images animée prédéfinie. Cette séquence consiste en une suite de portions d'image(s) JPEG2000, telle que celle illustrée à titre d'exemple non limitatif sur la figure 3. La séquence consiste en une suite de zones d'intérêt rectangulaires successives, numérotées de 1 à 4 sur le dessin. Du point de vue de l'utilisateur, le rendu de cette animation, au moyen du logiciel FlashPlayer, apparaîtra comme un défilement progressif du paysage représenté sur la figure 3. Cette séquence, 5 décrite sous forme d'un script adapté, est ensuite interprétée en termes de requêtes JPIP par le client JPIP 18. Celui-ci transmet au serveur JPIP 12 des requêtes JPIP successives correspondant à l'animation désirée. Le serveur JPIP 12 traite alors ces requêtes dans l'ordre et renvoie au client JPIP 18 des réponses JPIP en conséquence.

Les données JPIP reçues en réponse sont stockées à la volée dans le cache 20, utile pour éviter toute retransmission de données JPIP déjà transmises.

Selon le mode de réalisation choisi et représenté à la figure 2, un dispositif mettant en oeuvre l'invention est par exemple un microordinateur 10 15 connecté à différents périphériques, par exemple une caméra numérique 101 (ou un scanner, ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant des informations à comprimer selon l'invention.

Le dispositif 10 comporte une interface de communication 118 reliée 20 à un réseau de communication 113 apte à transmettre des données numériques à comprimer ou à transmettre des données comprimées par le dispositif. Le dispositif 10 comporte également un moyen de stockage 112 tel que par exemple un disque dur. Il comporte aussi un lecteur de disquettes 114.

Une disquette 116 comme le disque dur 112 peuvent contenir des données 25 comprimées selon l'invention ainsi que le code de l'invention qui, une fois lu par le dispositif 10, sera stocké dans le disque dur 112. Selon une variante, le programme permettant au dispositif de mettre en oeuvre l'invention pourra être stocké en mémoire morte 104 (appelée ROM sur le dessin). En seconde variante, le programme pourra être reçu pour être stocké de façon identique à 30 celle décrite précédemment par l'intermédiaire du réseau 1 13.

Le dispositif 10 est relié à un microphone 111 par l'intermédiaire d'une carte d'entrée/sortie 105. Les données à transmettre selon l'invention seront dans ce cas du signal audio.

Ce même dispositif possède un écran 108 permettant de visualiser 5 les données à décomprimer (cas du client) ou de servir d'interface avec l'utilisateur qui pourra paramétrer certains modes d'exécution du serveur ou du client, à l'aide d'un clavier 110 ou de tout autre moyen (souris par exemple).

Une unité centrale 103 (CPU, en anglais "Central Processing Unitr') exécute les instructions relatives à la mise en oeuvre de l'invention, ces 10 instructions étant stockées dans un fichier ("Progr' sur le dessin) en mémoire morte 104 ou dans les autres éléments de stockage. Lors de la mise sous tension, les programmes de décompression stockés dans une mémoire non volatile, par exemple la ROM 104, sont transférés dans une mémoire vive RAM 106 qui contiendra alors le code exécutable de l'invention ainsi que des 15 registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention.

Bien entendu, les disquettes peuvent être remplacées par tout support d'information tel que CD-ROM, DVD-ROM ou carte mémoire. De façon plus générale, un moyen de stockage d'information, lisible par un ordinateur ou 20 par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé d'exécution du serveur ou du client.

Un bus de communication 102 permet la communication entre les différents éléments inclus dans le micro-ordinateur 10 ou reliés à lui. La 25 représentation du bus 102 n'est pas limitative et notamment l'unité centrale 103 est susceptible de communiquer des instructions à tout élément du microordinateur 10 directement ou par l'intermédiaire d'un autre élément du microordinateur 10.

La figure 4 illustre la notion de "precinct" dans une image 30 JPEG2000. Comme le montre le dessin, un precinct est un groupement de code-blocs des sous-bandes d'un même niveau de résolution et correspondant à une même zone spatiale de l'image. De plus, l'image est composée de plusieurs niveaux ou couches de qualité. La portion de train binaire correspondant à une couche de qualité et un precinct forme une suite contiguë d'octetsappelée paquet du train binaire JPEG2000.

Autrement dit, en termes de train binaire JPEG2000, un precinct peut 5 être vu comme une pile de paquets successifs. Ces derniers contribuent de façon incrémentale à la qualité de reconstruction des code-blocs contenus dans le precinct.

La figure 5 illustre la notion d'incrément de precinct. Dans toute la suite, on considère que les données retournées par le serveur JPIP sont de la 10 classe des incréments de precinct mentionnée plus haut (type de données conforme au type JPP-STREAM défini par JPIP). Néanmoins, le principe de l'invention est le même si on considère des incréments de tuile.

Comme le montre la figure 5, un incrément de precinct correspond à une suite d'octets consécutifs contribuant à un même precinct. Deux incréments 15 de precinct distincts sont représentés sur le dessin.

Sur le dessin, chaque incrément de precinct contient plusieurs paquets. Ce n'est pas systématique, car le serveur a la liberté de choisir la quantité de données utiles à insérer dans un incrément de precinct. Par conséquent, un incrément de precinct peut contenir seulement une portion d'un 20 paquet, ou plusieurs paquets, et n'est pas tenu de commencer ni de se terminer à la frontière d'un paquet.

Chaque incrément de precinct est désigné par un identifiant P, qui est calculé à partir de: - t, indice de la tuile dans l'image; - c, indice de la composante dans l'image; - s, numéro de séquence du precinct dans sa tuile à travers les niveaux de résolution; - num_comps, nombre total de composantes; et - numtiles, nombre total de tuiles.

La formule de calcul de P est donnée sur le dessin.

Le synoptique de la figure 6 illustre le procédé proposé dans un premier mode de réalisation de l'invention. Elle présente les étapes successives (repérées par des numéros d'ordre sur le dessin) du scénario envisagé dans ce mode de réalisation.

Tout d'abord, le client Flash envoie une requête au serveur Flash visant à rapatrier un fichier Flash (flèche 1). Le serveur Flash envoie les 5 données Flash au client Flash (flèche 2 du serveur Flash vers le client Flash).

De plus, il détecte la présence d'une animation dans le fichier Flash désiré, consistant en un parcours au sein d'une image JPEG2000, tel que présenté précédemment (figure 3). Il transmet donc la description de l'animation au serveur JPIP (flèche 2 du serveur Flash vers le serveur JPIP). Ces étapes 10 simultanées illustrées par les flèches 2 permettent au serveur, conformément à la présente invention, de commencer à préparer les incréments JPIP avant même que le fichier en format Flash soit reçu par le client.

Dans un mode particulier de réalisation, la description de l'animation contenue dans le fichier Flash d'origine peut être directement exprimée en 15 termes de requêtes JPIP. Si l'animation n'est pas décrite sous forme de requêtes JPIP, le serveur JPIP la traduit en une suite de requêtes JPIP. Il prépare ensuite les réponses JPIP adaptées à ces requêtes JPIP successives.

Ensuite, le client Flash constate la présence d'une animation Flash du type de celle de la figure 3. Il invoque alors le client JPIP (flèche 3) afin que 20 celui-ci rapatrie en provenance du serveur JPIP les données JPIP pour restituer l'animation considérée (flèche 4). La suite du scénario consiste en la transmission de réponses JPIP du serveur JPIP vers le client JPIP (flèche 5).

Ce dernier remplit enfin deux tâches (flèches 6): - le décodage des données reçues et la restitution des images 25 successivement décomprimées au client Flash, et - le stockage des données JPIP reçues dans le cache du client JPIP.

La figure 7 illustre les réponses JPIP partielles préparées à l'avance pour l'animation Flash traitée, dans le cadre du premier mode de réalisation de 30 l'invention.

Les réponses préparées à l'avance par le serveur JPIP consistent en une suite d'en-têtes de messages de retour, chacun étant associé à une adresse pointant au moyen de pointeurs (ptrO, ptrl, ptr2, ptr3 sur le dessin) sur une position dans le fichier JPEG2000 d'origine. Cette adresse indique la position, dans le fichier JPEG2000, du segment de données utiles à extraire pour former le corps du message de retour JPIP.

Dans la suite, pour simplifier, on considère des fichiers JPEG2000 ne contenant qu'un seul flux de données codées. Les en-têtes de messages de retour préparés par le serveur sont donc de la forme suivante: Bin-Id, MsgOffset, Msg-Length.

La figure 7 représente 8 incréments de precinct qui ont été préparés 10 par le serveur. Comme le montre le dessin, les 4 premiers messages préparés correspondent à 4 incréments contribuant à un même precinct, identifié par la valeur "Bin-ID". Les 4 incréments suivants contribuent à un autre precinct, identifié par la valeur "Bin-IDl".

Ainsi, comme les en-têtes de chaque message sont déjà formés, le 15 serveur n'a plus qu'à concaténer à chacun d'entre eux le segment de données qui lui correspond pour terminer de construire le message et le transmettre.

Notons que la figure 7 illustre des incréments de precinct fragmentés, c'est-à-dire que pour un identifiant de precinct donné, plusieurs incréments de precinct sont préformés. Par exemple, pour le precinct 20 d'identifiant Bin-ID, 4 incréments, correspondant à des positions respectivement définies par les variables "OffsetO", "Offsetl", "Offset2" et "Offset3" sont préformés. Ces quatre incréments ont des longueurs respectives de données utiles "LengthO", "Lengthl", "Length2" et "Length3". Former ces quatre incréments revient à former un unique incrément de precinct, correspondant à 25 la position définie par la variable OffsetO, et ayant une longueur de données utiles égale à: LengthO + Lengthl + Length2 + Length3, ce qui, a priori, paraîtrait plus simple. Cependant, fragmenter les réponses préformées en de multiples incréments de precinct présente plusieurs avantages, expliqués cidessous.

Notons que les requêtes JPIP traduites à partir de l'animation Flash prennent des formes différentes selon que le serveur JPIP utilisé est dit "à état" ou non. Un serveur JPIP est dit à état s'il maintient un modèle du cache du client. Plus précisément, un serveur JPIP à état mémorise les données JPIP qu'il transmet à un client donné, au cours d'une session. On parle également de session à état. Par conséquent, au cours d'une session à état, le client envoie des requêtes JPIP indiquant uniquement la zone d'intérêt désirée. En début de 5 session, il indique néanmoins, s'ils existent, les éléments déjà contenus dans son cache pour l'image considérée. Le client n'a pas besoin d'informer le serveur de l'état de son cache, sauf s'il supprime des données de son cache.

Le serveur à état est capable de ne transmettre que les données JPIP pertinentes vis-à-vis de cette zone d'intérêt et qui n'ont pas encore été reçues 10 et stockées dans le cache du client. Au contraire, un serveur "sans état" ne mémorise pas les données successivement envoyées à un client donné. Dans ce cas, le client envoie des requêtes indiquant à la fois la zone d'intérêt et l'état du cache du client par rapport à cette zone d'intérêt. Cela permet au client d'éviter de recevoir des données JPIP déjà présentes dans son cache.

Fragmenter les réponses préformées présente notamment les deux avantages suivants: - le serveur JPIP ne sait pas à l'avance quel sera l'état du cache du client au moment de la réception des requêtes JPIP. Dans le cas d'un serveur à état, cela est vrai notamment au moment de recevoir la première requête liée à 20 la séquence animée. Dans le cas d'un serveur sans état, cela est vrai pour toutes les requêtes de la séquence. Par conséquent, si les incréments de precinct formés sont fragmentés, le serveur peut ajuster avec finesse ses réponses en fonction de l'état du cache du client. Au contraire, si un seul incrément était préformé pour chaque precinct, le serveur ne pourrait pas 25 transmettre une portion des données constituant un precinct donné; - dans le cas d'un serveur avec ou sans état, engendrer des incréments fragmentés permet de contrôler le débit. En effet, des champs optionnels ("len", "layers" ou "quality") des requêtes JPIP visent à limiter la quantité d'informations retournées par le serveur, afin de contrôler la bande 30 passante occupée. Par ailleurs, dans une réalisation particulière, un serveur JPIP peut décider lui-même de limiter la taille de ses réponses JPIP en fonction de la bande passante disponible sur le réseau. Des incréments de precinct fragmentés sont également particulièrement pratiques dans ce cas. En effet, des incréments de faible longueur permettent d'approcher au mieux une contrainte de taille fixée pour une réponse JPIP, non connue au moment de préformer la réponse.

On décrit ci-dessous une stratégie possible, simple, de génération d'incréments de precinct fragmentés.

Avantageusement, cette stratégie de fragmentation des incréments de precinct est indépendante de la requête. En effet, le contraire risquerait d'engendrer la transmission de données d'image comprimée déjà présentes 10 dans le cache du client, ce qui nuirait à l'efficacité de l'utilisation du protocole JPIP. Une stratégie de fragmentation simple peut consister à former des incréments de precinct contenant exactement une couche de qualité.

Cependant, si le paquet correspondant à une couche de qualité donnée est vide, on décide de l'insérer dans le même incrément que le paquet 15 de la couche de qualité supérieure. Si les paquets de plusieurs couches de qualité successives sont vides, ils sont tous concaténés et rassemblés dans le même incrément que le premier paquet non vide qui suit. Enfin, si la taille de la suite d'octets formée par un paquet non vide, éventuellement concaténé à un ou plusieurs paquets vides, dépasse un certain seuil, cette suite d'octets est 20 découpée en au moins deux portions. On engendre alors au moins deux incréments contenant les portions successives de cette suite d'octets.

Avantageusement, cette découpe en plusieurs portions est toujours opérée de la même façon par le serveur, afin que la fragmentation des incréments soit la même d'une requête JPIP à une autre. Le seuil mentionné ci-dessus, pour 25 décider de la découpe en plusieurs incréments, dépend du protocole de transport sous-jacent utilisé.

L'organigramme de la figure 8 illustre le fonctionnement du client dans le premier mode de réalisation de l'invention. On désigne ici par client l'ensemble des clients Flash et JPIP réunis. Tout d'abord, lors d'une étape 800, 30 le client envoie, sur demande de l'utilisateur, via un navigateur Internet par exemple, une requête au serveur distant, dans le but de rapatrier un fichier Flash. A l'étape suivante 802, le client Flash reçoit les données demandées, les lit et affiche le résultat via l'interface homme-machine.

Dans le cas o le fichier Flash contiendrait une animation consistant en un parcours au sein d'une image JPEG2000 (test 804 positif), cette 5 animation est traitée par le client JPIP. Ce dernier analyse l'animation et la traduit en termes de requêtes JPIP (étape 806). Notons qu'en variante, l'animation contenue dans le fichier Flash peut être directement exprimée en termes de requêtes JPIP. Dans ce cas, aucune traduction en requêtes JPIP n'est nécessaire (l'étape 806 n'est dans ce cas pas effectuée).

Puis on parcourt l'ensemble des requêtes en initialisant la requête courante à la première requête JPIP de la séquence (étape 808) et la suite de l'algorithme consiste, pour les requêtes JPIP formées dont la réponse n'est pas déjà entièrement stockée dans le cache client (test 810 négatif), à envoyer successivement ces requêtes JPIP (étape 812) et à recevoir leurs réponses 15 respectives. Les données JPIP reçues sont stockées dans le cache du client JPIP. Le client JPIP décode également ces données d'images comprimées reçues et fournit les images successivement reconstruites au logiciel FlashPlayer pour affichage (étape 814). Le client Flash joue alors la séquence vidéo désirée au fur et à mesure que les images successives sont décodées et 20 lui sont fournies.

Tant que la requête courante n'est pas la dernière requête (test 816 négatif), on passe à la requête suivante (étape 818) et on réitère les étapes 810 à 816. Lorsque le test 816 est positif (dernière requête traitée), le décodage des images et l'affichage de la séquence animée prennent fin (étape 820).

Lors du test 810, au cas o les données sont déjà entièrement stockées dans le cache, on passe directement au test 816.

Lors du test 804, au cas o le fichier Flash ne contient pas d'animation au sein d'une image JPEG2000, l'affichage des données Flash prend fin (étape 822) et l'algorithme est terminé.

Dans le cas d'un serveur à état, le client envoie des requêtes indiquant uniquement les zones d'intérêt successives liées à l'animation traitée, à l'exception de la première requête, comme expliqué précédemment. Dans le cas d'un serveur sans état, le client envoie des requêtes indiquant à la fois la zone d'intérêt et les incréments de data-bin qu'il désire dans cette zone.

L'organigramme de la figure 9 illustre le comportement du serveur dans le cadre du premier mode de réalisation de l'invention. On désigne ici par 5 serveur l'ensemble des serveurs Flash et JPIP réunis. Cependant, on a représenté sur le dessin dans deux colonnes séparées les étapes effectuées par le serveur Flash et celles effectuées par le serveur JPIP. Le début de l'algorithme consiste en l'attente, puis la réception d'une requête d'un fichier Flash émise par un client Flash (étapes 900 et 902). Le serveur répond de 10 façon connue à cette requête en transmettant le fichier Flash considéré (étape 904). De plus, dans le cas o une animation consistant en un parcours dans une image JPEG2000 est incluse dans le fichier Flash (test 906 positif), le serveur Flash fournit au serveur JPIP l'animation considérée (étape 908) puis le processus reprend à partir de l'étape 900 d'attente d'une nouvelle requête. Au 15 cas o le test 906 est négatif, il est directement suivi d'un retour à l'étape 900.

Le serveur JPIP traduit cette animation en termes de requêtes JPIP (étape 910). Il est à noter qu'en variante, les animations au sein d'images JPEG2000 peuvent être directement décrites sous forme de requêtes JPIP.

Dans ce cas, l'étape 910 n'est pas effectuée. La suite de l'algorithme consiste à 20 former les réponses JPIP (étape 912) à chaque requête JPIP fournie par l'étape de traduction 910. Les réponses sont préformées suivant la forme illustrée par la figure 7. Il est à noter que pour chaque precinct contribuant à la zone d'intérêt liée à une requête, l'ensemble des données utiles incluses dans les incréments préformés contient toutes les couches de qualité du precinct considéré. La 25 quantité de données à envoyer pour chaque precinct est décidée ultérieurement, en fonction de la contrainte de débit fixée par le client JPIP ou décidée par le serveur et en fonction de l'état du cache du client. Les incréments déjà inclus dans le cache du client ne sont pas transmis.

La suite de l'algorithme exécuté par le serveur JPIP consiste à se 30 mettre en attente des requêtes JPIP relatives à l'animation considérée (étape 914). A chaque réception d'une telle requête JPIP (étape 916), le serveur lance un processus 90 de traitement de requête JPIP préparée à l'avance, encadré en tirets sur la figure 9. Parallèlement au lancement de ce processus de traitement, le serveur se remet en attente d'une autre requête JPIP (retour à l'étape 914).

On décrit maintenant le traitement des requêtes JPIP préparées à l'avance par le serveur JPIP (cadre 90).

Le serveur JPIP dispose déjà de messages de retour préformés sous la forme d'incréments de precinct partiels. Le serveur détermine donc, de façon connue, pour la requête courante JPIP, l'ensemble des incréments de precinct à transmettre (étape 918). On note les messages de retour préparés à l'avance 10 correspondants {(bini,offseti,length_iptr-i), i = 0, ..., num messages-1}, o - bin i désigne l'identifiant du precinct concerné, - offseti désigne la position du premier octet de données de l'incrément de precinct, - lengthji désigne le nombre d'octets de données utiles contenues 15 dans l'incrément, - ptri désigne le pointeur indiquant la position du segment de données correspondant dans le fichier JPEG2000 considéré et - num_messages est le nombre total de messages de retour préparés à l'avance.

Pour chaque incrément de precinct ainsi déterminé, les données d'image comprimée correspondantes sont extraites du fichier JPEG2000 initial (étape 922). Cette extraction utilise le pointeur ptr-i, qui se positionne tout d'abord au premier incrément de precinct à transmettre (initialisation de la variable i à la valeur 0 à l'étape 920). Le segment de données extrait est 25 concaténé à l'en-tête préformé du message de retour (duquel on retire le pointeur ptr-i) préformé (étape de finalisation 924). L'incrément ainsi constitué est alors prêt à être transmis (étape d'envoi 926). Tant que i n'est pas l'indice du dernier incrément (test 928 négatif), on incrémente d'une unité la valeur de i (étape 930) et on réitère les étapes 922 à 928. Une fois tous les incréments de 30 precinct pertinents transmis (test 928 positif), le serveur JPIP termine la réponse JPIP en cours par un message de fin de réponse (étape 932), conformément à la norme JPIP. Cela met fin au processus de traitement de la requête JPIP. La réponse ainsi formée a été préparée auparavant, ce qui accélère le processus de traitement de requête JPIP. En effet, les en-têtes de tous les incréments de precinct transmis ont déjà été formés, et le serveur n'a plus qu'à leur ajouter les données comprimées. Celles-ci consistent en une suite d'octets, référencée par l'incrément préformé, comme décrit plus haut.

La figure 10 représente de façon schématique le contenu des réponses JPIP préparées à l'avance pour une animation Flash, dans un deuxième mode particulier de réalisation de l'invention. Les messages de retour préparés ici sont complets, c'est-à-dire que les incréments de precinct formés 10 contiennent un en-tête, identique à celui du premier mode de réalisation, et un corps contenant des données extraites du fichier d'origine JPEG2000. Un avantage de ce mode de réalisation par rapport au premier est que la phase d'extraction de données du fichier d'origine JPEG2000 est effectuée à l'avance.

Le serveur n'a donc plus qu'à transmettre les incréments déjà complètement 15 formés pour répondre aux requêtes JPIP, ce qui augmente sa réactivité. En revanche, les messages de retour JPIP préformés occupent bien évidemment un plus grand espace mémoire.

Il est à noter que la même stratégie de fragmentation des messages de retour que celle décrite précédemment est adoptée dans ce deuxième mode 20 de réalisation. Cela procure les mêmes avantages que ceux avancés précédemment.

Le synoptique de la figure Il illustre un troisième mode de réalisation de l'invention. Celui-ci consiste, pour un fichier Flash contenant une animation au sein d'une image JPEG2000, à insérer directement les réponses 25 JPIP correspondant à l'animation considérée dans le fichier Flash, en utilisant par exemple le même type de messages de retour JPIP que ceux illustrés sur la figure 10. L'insertion des réponses dans le fichier Flash est effectuée lors d'une étape de pré-traitement. Pour ce faire, préalablement à toute requête d'un client, le serveur Flash invoque le serveur JPIP (flèche 0 sur le dessin) et lui 30 fournit la séquence animée destinée à être transportée au sein du fichier Flash.

Le serveur JPIP construit alors les messages de retour correspondants en extrayant les données nécessaires du fichier JPEG2000 d'origine (flèche 1) .

Les serveurs Flash et JPIP forment alors le fichier Flash contenant intégralement les messages de réponse JPIP correspondant à la séquence animée considérée (flèche 2). Ainsi, à réception d'une requête client pour recevoir le fichier Flash (flèche 3), les données JPIP nécessaires pour restituer 5 l'animation considérée sont transmises à la suite des données Flash (flèche 4), sans attendre de requête JPIP en provenance du client.

Un avantage de ce mode de réalisation est qu'il permet d'éviter de transmettre des requêtes JPIP du client vers le serveur. Cela implique donc une diminution du nombre d'allers-retours entre le client et le serveur, et donc une 10 augmentation de la rapidité de transmission de la séquence animée. En revanche, la transmission des données JPIP ne tient plus compte de la bande passante disponible sur le réseau ni de l'état du cache du client. En effet, les données sont insérées sans connaître l'état de ces paramètres. Ce mode de réalisation peut s'avérer utile et performant par exemple dans le cas 15 d'animations de courte durée, représentant donc un volume de données restreint.

Claims (28)

REVENDICATIONS

1. Procédé de transfert d'une suite de portions d'un premier signal numérique par un serveur à un client, suivant une pluralité de requêtes à 5 recevoir en provenance dudit client, ledit procédé étant caractérisé en ce qu'il comporte une étape (912) consistant à préparer, au niveau dudit serveur, avant le transfert dudit premier signal numérique, des réponses appropriées à une suite de requêtes client déduite d'un second signal numérique et anticipant ladite pluralité de requêtes à recevoir en provenance dudit client.

2. Procédé selon la revendication 1, caractérisé en ce que ledit second signal numérique est un fichier descriptif, connu du serveur et envoyé au client, décrivant un sur-ensemble des portions à transférer du serveur au client.

3. Procédé selon la revendication 2, caractérisé en ce que ladite 15 étape (912) de préparation des réponses est effectuée lorsque le client émet une requête sur ledit fichier descriptif.

4. Procédé selon la revendication 1, 2 ou 3, caractérisé en ce que lesdites réponses sont des en-têtes de messages de retour accompagnés chacun d'un pointeur vers le début d'un segment de données utiles à associer à 20 l'en-tête, ledit segment de données utiles étant mémorisé dans le premier signal numérique au niveau du serveur.

5. Procédé selon la revendication 1, 2 ou 3, caractérisé en ce que lesdites réponses sont des messages comportant chacun un en-tête et un corps constitué de données comprimées dudit premier signal numérique.

6. Procédé selon la revendication précédente, caractérisé en ce qu'il comporte en outre une étape consistant à insérer lesdites réponses dans un fichier contenant ladite suite de portions du premier signal numérique, ledit fichier étant destiné au client.

7. Procédé selon la revendication 4 ou 5, caractérisé en ce qu'il 30 comporte en outre une étape consistant à fragmenter ledit segment de données utiles.

8. Procédé selon la revendication précédente, caractérisé en ce que l'étape de fragmentation consiste à découper une suite d'octets du segment de données utiles en au moins deux portions si la taille de ladite suite d'octets dépasse un seuil prédéterminé.

9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit premier signal numérique est un signal d'image.

10. Procédé selon la revendication précédente, caractérisé en ce que le signal d'image est représentatif d'une image codée suivant la norme JPEG2000.

11. Procédé selon la revendication 2, caractérisé en ce que ladite suite de portions du premier signal numérique est représentative d'une animation du type Flash et ledit fichier descriptif est encapsulé dans ladite animation.

12. Procédé selon la revendication 10 ou 11, caractérisé en ce qu'il 15 met en oeuvre le protocole de transfert JPIP (JPEG2000 Interactive Protocol).

13. Dispositif de transfert d'une suite de portions d'un premier signal numérique par un serveur à un client, suivant une pluralité de requêtes à recevoir en provenance dudit client, ledit dispositif étant caractérisé en ce qu'il comporte des moyens pour préparer, au niveau dudit serveur, avant le transfert 20 dudit premier signal numérique, des réponses appropriées à une suite de requêtes client déduite d'un second signal numérique et anticipant ladite pluralité de requêtes à recevoir en provenance dudit client.

14. Dispositif selon la revendication précédente, caractérisé en ce que ledit second signal numérique est un fichier descriptif, connu du serveur et 25 envoyé au client, décrivant un sur-ensemble des portions à transférer du serveur au client.

15. Dispositif selon la revendication précédente, caractérisé en ce que lesdits moyens de préparation des réponses sont adaptés à préparer des réponses lorsque le client émet une requête sur ledit fichier descriptif.

16. Dispositif selon la revendication 13, 14 ou 15, caractérisé en ce que lesdites réponses sont des en-têtes de messages de retour accompagnés chacun d'un pointeur vers le début d'un segment de données utiles à associer à l'en-tête, ledit segment de données utiles étant mémorisé dans le premier signal numérique au niveau du serveur.

17. Dispositif selon la revendication 13, 14 ou 15, caractérisé en ce que lesdites réponses sont des messages comportant chacun un en-tête et un corps constitué de données comprimées dudit premier signal numérique.

18. Dispositif selon la revendication précédente, caractérisé en ce qu'il comporte en outre des moyens pour insérer lesdites réponses dans un fichier contenant ladite suite de portions du premier signal numérique, ledit fichier étant destiné au client.

19. Dispositif selon la revendication 16 ou 17, caractérisé en ce qu'il comporte en outre des moyens pour fragmenter ledit segment de données utiles.

20. Dispositif selon la revendication précédente, caractérisé en ce que les moyens de fragmentation sont adaptés à découper une suite d'octets 15 du segment de données utiles en au moins deux portions si la taille de ladite suite d'octets dépasse un seuil prédéterminé.

21. Dispositif selon l'une quelconque des revendications 13 à 20, caractérisé en ce que ledit premier signal numérique est un signal d'image.

22. Dispositif selon la revendication précédente, caractérisé en ce 20 que le signal d'image est représentatif d'une image codée suivant la norme JPEG2000.

23. Dispositif selon la revendication 14, caractérisé en ce que ladite suite de portions du premier signal numérique est représentative d'une animation du type Flash et ledit fichier descriptif est encapsulé dans ladite 25 animation.

24. Dispositif selon la revendication 22 ou 23, caractérisé en ce qu'il met en oeuvre le protocole de transfert JPIP (JPEG2000 Interactive Protocol).

25. Appareil de communication, caractérisé en ce qu'il comporte un dispositif selon l'une quelconque des revendications 13 à 24.

26. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé selon l'une

quelconque des revendications 1 à 12.

27. Moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur conservant des 5 instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 12.

28. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé selon l'une quelconque des 10 revendications 1 à 12, lorsque ce programme est chargé et exécuté par l'appareil programmable.