Brevet FR2864407A1 — publié le 20050624

L'invention concerne un procédé et un dispositif de transmission continue d'une vidéo d'un serveur vers plusieurs machines clients à travers un réseau de communication. Il est connu de transmettre des vidéos sur un réseau de communication, comme par exemple l'Internet. Cependant, la mise en oeuvre d'une telle transmission reste difficile dans la mesure où ce type de réseau a plutôt été conçu pour transmettre des fichiers et non des données continues à haut débit. La difficulté s'accroît lorsqu'il est question de transmettre une vidéo d'un serveur vers plusieurs machines clients dont les caractéristiques sont hétérogènes. En effet, il convient dans ce cas de satisfaire plusieurs utilisateurs de machines clients connectées au serveur qui possèdent des bandes passantes différentes ainsi que des capacités de calcul et d'affichage qui leur sont propres. On connaît un système de transmission de vidéos à travers un réseau de communication d'après l'article intitulé "Adaptive Video Distribution Mode! of QHD (Quadruple HD) with JPEG2000". D'après ce système, un serveur transmet une vidéo au format Motion JPEG2000 vers plusieurs utilisateurs qui reçoivent chacun la même quantité de données et qui peuvent localement effectuer des manipulations sur les données constitutives de cette vidéo, en fonction de leurs besoins propres. Cependant, cette méthode n'est pas satisfaisante dans la mesure où la transmission d'une version unique de la vidéo avec un débit fixe ne satisfera pas tous les utilisateurs. 2 2864407 En effet, certains utilisateurs recevront trop de débit, ce qui provoquera des pertes de données, tandis que d'autres ne recevront pas suffisamment de données au regard de leur bande passante disponible. On connaît également un autre système de transmission d'après l'article 5 intitulé "TCP-compatible rate contrai for FGS layered multicast video transmission based on a clustering algorithm". Un tel système prévoit de transmettre des vidéos au format MPEG-4 sur un réseau multipoint entre un serveur et plusieurs utilisateurs qui possèdent des bandes passantes hétérogènes. Chaque utilisateur qui souhaite recevoir la vidéo transmet un paquet vers le serveur pour l'informer de la bande passante maximale qu'il peut recevoir. Les différents paquets provenant des différents utilisateurs sont rassemblés dans les noeuds du réseau afin de ne transmettre ensuite au serveur qu'un seul paquet contenant les informations relatives à tous les utilisateurs. De son côté, le serveur forme alors des groupes d'utilisateurs en fonction des contraintes de débit propres à ces derniers et crée, à partir de la vidéo à transmettre, autant de niveaux de "scalabilité" ou d'échelonnabilité (niveaux hiérarchiques) temporelle ou de "scalabilité" en termes de qualité qu'il y a de groupes d'utilisateurs formés. Chaque niveau de scalabilité est alors transmis sur une adresse multipoint du réseau. Les utilisateurs s'abonnent ensuite à un nombre de niveaux de scalabilité compatible avec leurs contraintes de débit et reçoivent ainsi chacun un débit compatible avec leur contrainte de bande passante. Compte tenu des techniques proposées dans l'art antérieur et brièvement exposées ci-dessus, la Demanderesse s'est aperçue qu'il serait intéressant d'améliorer encore les performances des systèmes existants de transmission de vidéos sur des réseaux de communication en réduisant davantage la quantité de données transmises sur le réseau et éventuellement en augmentant la capacité du serveur à satisfaire le plus finement possible les souhaits des clients. A cet effet, la présente invention a ainsi pour objet un procédé de transmission continue d'une vidéo d'un serveur vers plusieurs machines clients à travers un réseau de communication, caractérisé en ce qu'il comporte les étapes suivantes: - obtention de requêtes provenant de machines clients, au moins plusieurs des requêtes obtenues spécifiant chacune au moins une zone spatiale d'intérêt dans une ou plusieurs images de la vidéo, une zone spatiale représentant un ensemble de données numériques, - traitement des requêtes obtenues afin de déterminer une ou plusieurs intersections définissant des données communes entre les zones spatiales d'intérêt de la vidéo, - création d'une session réseau multipoint pour chaque intersection ainsi déterminée. Corrélativement, l'invention concerne également un dispositif de transmission continue d'une vidéo d'un serveur vers plusieurs machines clients à travers un réseau de communication, caractérisé en ce que le dispositif comporte: - des moyens d'obtention de requêtes provenant de machines clients, au moins plusieurs des requêtes obtenues spécifiant chacune au moins une zone spatiale d'intérêt dans une ou plusieurs images de la vidéo, une zone spatiale représentant un ensemble de données numériques, - des moyens de traitement des requêtes obtenues afin de déterminer une ou plusieurs intersections définissant des données communes entre les zones spatiales d'intérêt de la vidéo, - des moyens de création d'une session réseau multipoint pour chaque intersection ainsi déterminée. L'invention permet ainsi d'organiser de façon encore plus efficace qu'auparavant le traitement des requêtes émanant des machines clients en déterminant les données provenant de zones spatiales spécifiées par les utilisateurs et qui sont communes à au moins deux d'entre eux, ceci afin d'éviter des transmissions multiples de données identiques. Un tel traitement permet de réduire le nombre de sessions réseau multipoint sur le réseau par rapport au nombre de requêtes provenant des machines clients. Selon une caractéristique, le procédé comporte une étape de transmission point à point sur le réseau, à partir du serveur, d'un descriptif du contenu de chaque session réseau multipoint destiné à informer chaque machine client. 4 2864407 Ainsi, les machines clients ayant émis des requêtes sont informées de la façon dont sont organisées les différentes sessions réseau multipoint par le serveur. Selon une caractéristique, le procédé comporte une étape d'obtention d'une requête d'abonnement d'une des machines clients à un sous-ensemble ou à l'ensemble des sessions multipoints créées par le serveur, ce sousensemble ou cet ensemble étant destiné à transporter les données satisfaisant la requête initiale de la machine client, ladite requête d'abonnement étant transmise par ladite machine client après consultation par celle-ci du descriptif du contenu d'au moins une session réseau multipoint. En effet, lorsqu'un utilisateur a consulté le descriptif du contenu d'une ou de plusieurs sessions réseaux multipoints, il est alors capable, s'il le souhaite, d'établir une nouvelle requête afin de recevoir les données destinées à être transportées via cette ou ces sessions en utilisant, par exemple, le protocole IGMP. Selon une autre caractéristique, le procédé comporte une étape de transmission vers la machine client concernée des données transportées par le sous-ensemble ou l'ensemble des sessions réseaux multipoints. Par ailleurs, selon une autre caractéristique, le procédé comporte une étape de création d'au moins une session réseau multipoint ou point à point pour 20 les données non contenues dans les intersections déterminées. Là encore, le serveur prévoit de ne pas retransmettre la totalité des données spécifiées dans la requête de la machine client, mais uniquement celles qui lui sont propres et qui ne sont pas déjà transmises par une session réseau multipoint déjà créée. Selon une caractéristique, le procédé comporte une étape de transmission vers les machines clients concernées des données non contenues dans les intersections déterminées L'invention concerne également un appareil de communication comportant un dispositif tel que brièvement exposé cidessus. Selon un autre aspect, l'invention vise aussi: - un moyen de stockage d'informations, lisible par un ordinateur ou un microprocesseur, comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'invention tel que celui exposé brièvement ci-dessus, et - un moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur, comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'invention tel que celui exposé brièvement ci- dessus. Selon encore un autre aspect, l'invention vise un programme d'ordinateur chargeable dans un appareil programmable, comportant des séquences d'instructions ou portions de code logiciel pour mettre en oeuvre des étapes du procédé selon l'invention tel que brièvement exposé ci-dessus, lorsque ledit programme d'ordinateur est chargé et exécuté sur l'appareil programmable. Les caractéristiques et avantages relatifs au dispositif selon l'invention, à l'appareil de communication comportant un tel dispositif, aux moyens de stockage d'information et au programme d'ordinateur étant les mêmes que ceux exposés ci-dessus concernant le procédé selon l'invention, ils ne seront pas rappelés ici. D'autres caractéristiques et avantages apparaîtront au cours de la description qui va suivre, donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés, sur lesquels: - la figure 1 représente de manière schématique une architecture de type client-serveur dans un réseau de communication selon l'invention; - la figure 2 représente un algorithme d'échange d'informations entre le serveur et les machines clients de la figure 1; - la figure 3 est un algorithme décrivant de façon plus détaillée les étapes effectuées lors de l'exécution de l'étape E406 de la figure 2; - la figure 4 est un algorithme représentant de façon plus détaillée les étapes effectuées lors de l'exécution de l'étape E517 de la figure 3; - la figure 5 est un algorithme illustrant les principales étapes effectuées par une machine client; - la figure 6 est une vue schématique d'un appareil de communication selon l'invention. Dans la description d'un exemple de réalisation de l'invention qui va suivre, on considère qu'un serveur diffuse une vidéo en continu sur un réseau de communication tel qu'illustré par la figure 1. Cette vidéo est codée en temps réel au format du standard MJPEG2000 à 30 images/s dans le serveur 10. Cette vidéo peut, par exemple, correspondre à un programme de télévision diffusé sur Internet. On notera que, contrairement à une application de vidéo à la demande, les utilisateurs de différentes machines clients 12, 14, 16, 18, 20, 22, 24, 26, 28, 30 n'ont aucune influence sur le déroulement temporel de la vidéo qui est diffusée quelles que soient les interventions des utilisateurs. Les utilisateurs disposent d'une interface graphique qui permet de requérir l'obtention de la vidéo et permettra également, au cours de la session vidéo reliant le ou les utilisateurs au serveur, de modifier les paramètres d'affichage. On notera la présence, dans le réseau multipoint de la figure 1, de plusieurs routeurs multipoints 32, 34, 36, 38, 40, 42. Dans un réseau de communication multipoint, un émetteur ne transmet pas ses données vers un récepteur, comme cela est fait classiquement dans les réseaux point à point, mais vers une adresse multipoint à laquelle devra s'abonner un utilisateur souhaitant recevoir les données émises. Si aucun utilisateur ne s'abonne, aucune donnée ne transitera par le réseau et si un seul utilisateur se connecte, la charge du réseau sera équivalente à celle supportée par un réseau point à point. Le bénéfice d'un réseau multipoint intervient lorsque plusieurs utilisateurs s'abonnent à une même adresse puisque, dans ce cas, contrairement au réseau point à point, les données sont transmises une seule fois à un routeur multipoint qui est apte à dupliquer les données si nécessaire. Au contraire, dans un réseau point à point, l'émetteur doit transmettre 25 le flux de données à un routeur point à point autant de fois qu'il y a de clients demandeurs. Par conséquent, le routeur multipoint permet de réduire la quantité de données transitant entre l'émetteur et le routeur. On peut noter enfin que le protocole IGMP (signifiant "Internet Group 30 Management Protocol" en terminologie anglosaxonne) a été défini pour gérer les abonnements/désabonnements à une adresse multipoint. Le standard de compression vidéo Motion JPEG2000 (MJPEG2000) correspond à la partie 3 du standard JPEG2000 (Motion JPEG2000 final draft international standard 1.0, ISO/lEC 15444-3 (JPEG2000, Part 3)) dont les spécifications indiquent qu'une séquence MJPEG2000 est constituée de plusieurs parties. La première partie, appelée "Movie box", contient des données descriptives ("Meta-data") décrivant le train binaire. On y trouve notamment une description de chaque media (son, vidéo,...), une description des outils permettant la lecture des média, des informations permettant l'accès à un échantillon tel qu'une image, etc. La seconde partie d'une séquence MJPEG2000 contient les données 10 utiles, telles que les données vidéo ou audio du train binaire. Ces deux parties peuvent être contenues dans un même fichier (dans ce cas les données utiles sont insérées dans une media data box), ou dans des fichiers séparés et, dans ce cas, la première partie, movie box, contient I'URL du fichier de données utiles. Le second fichier peut être constitué d'une suite d'images JPEG2000 ou peut prendre la forme de tout autre fichier contenant des images JPEG2000, tel qu'un fichier au standard MPEG-4 défini dans le document ISO/IEC JTC 1/SC 29/ WG 11, Information technology-Coding of audio-visual objects, Parti: Systems (ISO/lEC 14496-1), Dec. 1998. Dans l'exemple de réalisation, on considère que le fichier de données utiles ne contient qu'une suite d'images JPEG2000. L'intérêt majeur du standard MJPEG2000 réside dans les fonctionnalités nouvelles qu'il offre par rapport à des standards équivalents tel que Motion JPEG. Grâce à l'organisation du train binaire d'une image JPEG2000 et aux propriétés intrinsèques de son algorithme de compression basé sur une décomposition en ondelettes, on peut facilement faire varier la résolution, la qualité et les points de vue. II est également possible de faire varier le débit d'images. On notera de plus que, contrairement aux standards de compression utilisant la prédiction temporelle telle que H264 (ISO/IEC 14496-10, ITUT Rec.H.264, Joint video Specification, October 2002), il n'existe aucune dépendance entre les images. 8 2864407 Ces multiples vues d'une même image permettront par la suite à l'utilisateur d'ajuster finement sa vidéo à ses contraintes et à ses souhaits. Structure du train binaire JPEG2000 Dans le standard JPEG2000, un fichier est composé d'un préambule JPEG2000 optionnel, et d'un train binaire ("codestream" en terminologie anglosaxonne) comportant un en-tête principal et au moins une tuile. Une tuile représente de façon compressée une partie rectangulaire de l'image originale considérée. Chaque tuile est formée d'un en-tête de tuile (appelée "tile-part header" en terminologie anglosaxonne), et d'un ensemble de données d'image compressées (appelé "tile part bitstream" en terminologie anglosaxonne) qui comporte une séquence de paquets. Chaque paquet contient un en-tête et un corps contenant au moins un bloc de données ("code-block" en terminologie anglosaxonne) qui est une représentation compressée d'une partie rectangulaire élémentaire d'une image éventuellement transformée en sous-bandes de fréquences. L'en-tête de chaque paquet résume d'une part la liste des blocs contenus dans le corps considéré, et contient d'autre part des paramètres de compression propres à chacun de ces blocs. Chaque bloc est compressé sur plusieurs niveaux de qualité incrémentaux: une couche de base et des couches de raffinement. Chaque niveau ou couche de qualité d'un bloc est contenu dans un paquet distinct. Un paquet d'un ensemble de données d'image compressées ("Ne -part bitstream") d'un fichier JPEG2000 contient donc un ensemble de blocs de données, correspondant à une tuile, une composante, un niveau de résolution, un niveau de qualité et une position spatiale (appelée "precinct" en terminologie anglosaxonne) donnés. Il convient de noter que la portion de train binaire correspondant à une tuile peut être divisée en plusieurs segments contigus appelés tile-parts. Autrement dit, une tuile contient au moins un segment qui contient un entête ("tue-part header" en terminologie anglosaxonne) et une séquence de paquets. La division en segments s'opère donc obligatoirement à des frontières de paquets. Dans la partie 9 du standard JPEG2000 image coding system Part 9: lnteractivity tools, APIs and protocols Final Committee Draft. 1S0/1EC 9 2864407 JTC1/SC29 WG1 N3052, R. Prandolini, S. Houchin, G. Colyer, 25 july 2003 sont venues se greffer de nouvelles fonctionnalités destinées à la manipulation à distance des images conformes au standard à travers un réseau. Cette partie, connue sous le nom de JPIP (JPEG2000 sur IP), définit des requêtes (dites requêtes JPIP) permettant à des ordinateurs distants de s'échanger des parties ou la totalité d'une image JPEG2000. Les requêtes JPIP permettent dans le cadre de l'invention de requérir une vidéo et d'agir sur sa qualité d'affichage. Les deux paragraphes suivants décrivent les formats des données échangées par le protocole JPIP. Données de retour JPIP (annexe A de JPEG2000 image coding system Part 9: lnteractivity tools, APIs and protocols Final Committee Draft. ISO/lEC JTC1/SC29 WG 1 N3052, R. Prandolini, S. Houchin, G. Colyer, 25 july 2003). Le protocole JPIP permet de transférer des portions de fichier JPEG2000 et cinq classes d'unités de transferts principales sont prévues par le 15 futur standard JPIP: - Meta data-bin ou incrément de méta-données: un incrément de méta- données consiste en une suite d'octets consécutifs du train binaire contribuant à un ensemble donné de meta informations sur l'image compressée JPEG2000. - Main header data-bin ou incrément d'en-tête principal: un main header data-bin consiste en une suite d'octets successifs du train binaire JPEG2000 initial et contribuant à l'en-tête principal du fichier JPEG2000. - Tile header data-bin ou incrément d'en-tête de tuile: on désigne par entête de tuile une partie de l'en-tête du premier tile-part header d'une tuile donnée; un tlle-header data-bin consiste en une suite d'octets successifs du train binaire JPEG2000 initial et contribuant à un en-tête de tuile de l'image JPEG2000 originale. - Precinct data-bin ou incrément de precinct: dans la terminologie JPIP, un precinct consiste en l'ensemble des paquets des différentes couches de qualité de l'image et correspondant à une même position spatiale; un incrément de precinct désigne une suite d'octets consécutifs contribuant à un precinct donné ; on parle également de byte-range d'un precinct donné. 2864407 - Tile data-bin ou incrément de tuile: un incrément de tile-part consiste en une suite d'octets consécutifs ou byte-range contribuant à un même tile-part. Chaque classe possède un identifiant unique, également appelé 5 Class-ld. Une réponse JPIP consiste en un en-tête conforme au protocole http version 1.1, suivi d'une suite de messages ou data-bins JPIP. Chaque message JPIP est constitué d'un en-tête et d'un corps, l'en-tête d'un message contenant les champs suivants Bin-Id[, Csn], Msg-Offset, Msg- Length [, Aux]. Les champs Bin-ld et [, Csn] ont pour but d'identifier de façon unique le data-bin considéré et ils transportent les trois informations suivantes: l'indice du train binaire auquel appartient le data-bin, dans le cas où le fichier initial JPEG2000 contient plusieurs trains binaires; l'identifiant de la classe (Class-ld) du data-bin considéré ; 15 l'identifiant du data-bin au sein de la classe à laquelle il appartient (on parle aussi de ln-Class-ld); Les champs Msg-Offset et Msg-Length qui suivent dans l'en-tête du message indiquent 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 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 Msg-Length indique le nombre d'octets de données utiles contenus dans le data-bin et extraits du segment de données mentionné ci-25 dessus à partir de la position Msg-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 original et correspond au byte-range (Msg-Offset, Msg-length) spécifié dans l'en-tête du message. Requêtes JPIP (Annexe C de JPEG2000 image coding system Part 9: lnteractivity tools, APIs and protocols Final Committee Draft. ISO/lEC JTC 1/SC29 WG 1 N3052, R. Prandolini, S. Houchin, G. Colyer, 25 july 2003) . Les requêtes de données d'image, selon le protocole JPIP, sont constituées de dix types de champs: - des champs relatifs à la requête transmise, indiquant le type de commande JPIP, le nom de l'image demandée, l'identifiant de l'image, l'identifiant de la requête et le niveau priorité de la requête; - des champs de gestion des sessions réseaux; des champs de fenêtre de visualisation indiquant au serveur la zone d'intérêt courante désirée par le client; ces champs incluent notamment le 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, le futur standard 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 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 de méta-données; - des champs permettant des spécifier des limites pour la réponse à une requête (taille, débit...) ; - des champs spécifiant quelles devront être les réactions du serveur face à une requête (par exemple le serveur devra traiter toutes les requêtes précédant la requête courante ou bien la requête courante annulera toutes les requêtes précédentes) ; - des champs permettant de demander des portions de documents au format XML; - des champs relatifs au cache du client et qui fournissent au serveur des informations relatives au cache du client émetteur de la requête; - des champs permettant l'envoi de données vers un serveur; - des champs indiquant les capacités du client. Une fois formée, la requête JPIP est encapsulée dans une requête conforme au protocole http version 1.1. La figure 2 illustre un algorithme de traitement des requêtes provenant de différentes machines clients 1, 2, ..., n correspondant, par exemple, aux machines clients 12 à 30 de la figure 1, par le serveur 10. Le détail de certains aspects du traitement des requêtes par le serveur est également illustré par les algorithmes des figures 3 et 4. Au cours de chacune des étapes E400a, E400b, ..., E400n, pour la première requête, chaque client se contente de préciser la taille de sa fenêtre d'affichage. Un algorithme de mise en oeuvre d'un client JPIP se charge ensuite de formater une requête compatible avec le standard à l'étape suivante E402 correspondante. En référence à l'annexe C du standard JPIP (JPEG2000 image coding system Part 9: Interactivity tools, APIs and protocols Final Committee Draft. ISO/IEC JTC1/SC29 WG1 N3052, R. Prandolini, S. Houchin, G. Colyer, 25 july 2003), le client JPIP formate la requête en y incluant le champ target contenant l'adresse de la vidéo MJPEG2000. Ce champ est suivi du champ new channel qui indique qu'une nouvelle session JPIP doit être créée. Le client indique ensuite la taille de la fenêtre d'affichage du client à l'aide du champ frame size. Ce champ est suivi par un champ client capability à l'aide duquel le client indique à quel débit maximal il souhaite recevoir la vidéo. On suppose ici que le client connaît la bande passante dont il dispose ou, du moins, qu'il est capable à tout moment de l'estimer. Enfin, le client insère un champ codestream dans lequel on donnera la valeur now au sous-champ now-range, afin de débuter l'envoi des images à partir de l'image dont l'instant de capture correspond à l'instant de réception de la requête par le serveur. Un exemple de requête de début de session vidéo peut alors prendre la forme suivante: GET http:llget. ipeq.orq?target=/video/video. mj2&cnew&fsiz=640, 480&cap=mbw=384K &stream=now HTTP/1.1 CRLF Une fois formatée la requête JPIP est encapsulée dans une requête http qui est elle-même encapsulée dans un (ou plusieurs) paquet(s) du protocole de transport à l'étape E402a, E402b, ..., E402n suivant la machine client 13 2864407 considérée. Le protocole de transport utilisé est, par exemple, le protocole TCP/IP. Lors de cette encapsulation, le protocole de transport insère l'adresse IP de l'émetteur de la requête dans chaque paquet et cette adresse permettra au 5 serveur d'identifier les différents clients. On notera que les requêtes envoyées par les clients n'ont nullement besoin d'être envoyées de manière synchronisée. Une fois formatée et encapsulée, la première requête est transmise au serveur à l'étape E402a pour le client 1, E402 b pour le client 2, ..., E402n pour 10 le client n. Lorsque la requête JPIP transmise par le client n'est pas la première requête, son formatage diffère de celui décrit ci-dessus, mais le processus d'encapsulation reste toutefois identique. Chaque client 1, 2, ..., n peut intervenir sur la vidéo reçue en cours de session vidéo et, à l'aide de son interface graphique, il peut spécifier une résolution, un débit d'image et une zone spatiale d'intérêt d'une ou de plusieurs images de la vidéo qu'il souhaite afficher à l'étape correspondante E401a, E401 b, ..., E401 n. Chaque zone spatiale spécifiée par le client représente un ensemble de données numériques contenues dans la ou les images précitées. Toujours en référence à l'annexe C du standard JPIP mentionné ci-dessus, le client JPIP formate à l'étape E402 correspondante la requête en y incluant le champ target contenant l'adresse de la vidéo MJPEG2000. Ce champ est suivi du champ channe/ id identifiant la session JPIP du client et ce dernier indique ensuite la taille de sa fenêtre d'affichage à l'aide du champ frame size. Si le client souhaite afficher une zone particulière, il insère les champs Offset identifiant le point en haut à gauche de la zone à afficher et Region Size indiquant la taille de la région à afficher. Si le client souhaite faire varier le débit d'image, il utilise le champ sampling rate dans lequel il indique le débit d'image qu'il souhaite obtenir. On notera toutefois que le standard offre une autre méthode pour faire varier le débit d'image et qui consiste à utiliser le champ delivery rate. Ce champ est suivi par 14 2864407 un champ client capability àl'aide duquel le client indique à quel débit maximal il souhaite recevoir la vidéo. Enfin, tous les champs proposés dans le standard pouvant être utilisés, le client pourra spécifier d'autres champs dans sa requête. On notera que si le client souhaite modifier à tout moment l'affichage de sa vidéo, le champ wait devra toujours être à no, indiquant ainsi que la réponse à une requête peut être stoppée par l'arrivée d'une nouvelle requête. Un exemple de requête JPIP en cours de session vidéo peut alors prendre la forme suivante: GET http:l/get.jpeg.org?target=/video/video. mi2&cid=10&fsiz=640,480&roff=13,13&rsiz =300,200&srate=15&cap=mbw=384K HTTP/1.1 CRLF Une fois formatée et encapsulée comme décrit ci-dessus, la requête est transmise au serveur. On supposera que le serveur vérifie régulièrement l'arrivée de nouvelles requêtes sur son port réseau. Dès réception d'une nouvelle requête d'un client à l'étape E403, le 20 serveur vérifie si ce client est connu à l'étape suivante E404. A cet effet, le serveur recherche le champ cnew dans la requête indiquant la demande d'ouverture d'une nouvelle session réseau. Si ce champ est retrouvé, le serveur crée à l'étape E405a une nouvelle session réseau pour ce nouveau client et stocke son adresse IP et le contenu de la requête en mémoire. En créant une nouvelle session, le serveur crée un identifiant de session pour ce nouveau client et cette information sera également stockée en mémoire dans le serveur. Si, au contraire, le champ cnew est absent,le serveur recherche le numéro de session inscrit dans la requête. Le serveur remplace ensuite à l'étape E405b la précédente requête JPIP stockée en mémoire pour cette session par la nouvelle requête. Les étapes E405a et E405b sont immédiatement suivies de l'étape E406 qui procède à l'organisation des réponses aux requêtes. 2864407 L'étape E406 est plus particulièrement décrite en référence à l'algorithme de la figure 3 qui fait partie intégrante de l'algorithme de la figure 2. Au cours de l'étape E406, toutes les requêtes présentes dans une mémoire du serveur seront traitées comme illustré sur la figure 3. L'algorithme comporte une première étape E501 d'extraction des informations contenues dans une requête dite courante. A la fin de cette étape le serveur connaît la ou les zones spatiales d'intérêt spécifiées dans cette requête, sa résolution et le débit d'image auquel devra être jouée la vidéo. Le serveur pourra déduire, grâce au débit maximum indiqué dans le champ capacity et au débit d'image, le débit moyen que devra respecter une image de la séquence vidéo. Cette dernière information permettra de déduire le nombre de niveaux de qualité à envoyer pour cette zone. On suppose ici que, pour une requête donnée, le nombre de niveaux de qualité induit par la requête sera stable d'une image à l'autre. L'étape E501 est ensuite suivie de l'étape E502 au cours de laquelle le serveur représente sur une image virtuelle qu'il stocke dans une mémoire, la zone d'image couverte par la requête courante. Cette zone peut ne pas être exactement la zone demandée par la machine client. En effet, le serveur peut être amené à élargir la zone demandée de manière à inclure des frontières de "precincts" (un precinct est un ensemble de blocs de données ayant la même localisation spatiale dans les sous-bandes de fréquence de l'image transformée). L'étape E502 est suivie de l'étape E503 au cours de laquelle le serveur compare la zone courante (zone demandée ou zone élargie) avec les autres zones déjà représentées dans l'image virtuelle et provenant de requêtes précédentes. Ce processus consiste à vérifier qu'aucun point des zones existantes ne possède à la fois une abscisse comprise entre l'abscisse du point haut-gauche et celle du point bas-droit de la zone courante et une ordonnée comprise entre l'ordonnée du point haut-gauche et celle du point bas-droit de la zone courante. L'étape E503 est suivie de l'étape E504 au cours de laquelle on détermine si la zone courante possède une ou plusieurs parties communes (intersections) avec des zones spatiales d'intérêt existantes d'autres requêtes. Si aucune partie commune n'est détectée, l'étape E504 est suivie de l'étape E515 au cours de laquelle une session réseau multipoint ou point à point est créée. L'étape E515 est alors suivie de l'étape E516 au cours de laquelle on vérifie que toutes les requêtes ont bien été traitées. Dans l'affirmative, l'étape E516 est suivie de l'étape E517 dont la 10 description sera faite ultérieurement en référence à la figure 4. Dans la négative, on retourne à l'étape E501 déjà décrite pour traiter une nouvelle requête. De retour à l'étape E504, si une ou plusieurs intersections ont été déterminées (la zone demandée ou élargie peut, par exemple, se retrouver en entier dans une zone plus grande d'une ou de plusieurs autres requêtes, ou bien seulement une partie des données de la zone demandée ou élargie peut se retrouver dans une ou plusieurs autres requêtes), l'étape E504 est suivie de l'étape E505 qui prévoit d'effectuer successivement sur toutes les intersections, les étapes suivantes E506 à E511. II s'agit en quelque sorte d'effectuer un tri entre les parties communes et les autres parties. Au cours de l'étape E506 on compare le nombre de niveaux de qualité demandé dans la requête courante au nombre de niveaux de qualité déjà demandés dans une ou plusieurs autres requêtes pour cette même intersection. Cette étape est suivie de l'étape E507 au cours de laquelle on crée une nouvelle session multipoint si certains niveaux de qualité manquent. On peut également créer une nouvelle session multipoint en subdivisant une session existante. Ce cas de figure se présente si tous les niveaux demandés dans la requête courante sont déjà transmis par des sessions multipoints existantes et si aucune session multipoint existante, ni aucune combinaison de sessions existantes ne permet de répondre précisément à cette requête. Par exemple, si la requête courante spécifie les trois premiers niveaux de qualité et si les sessions existantes transmettent les deux premiers niveaux de 17 2864407 qualité sur une première session et les deux suivants sur une seconde session, on ne peut répondre précisément à la requête courante, même si toutes les données nécessaires sont déjà transmises. II faudra alors subdiviser la deuxième session multipoint en deux sessions, de manière à transmettre les deux derniers niveaux de qualité sur deux sessions multipoints séparées. L'étape E507 est suivie de l'étape E508 au cours de laquelle on compare le débit d'image demandé par la requête courante aux débits d'image déjà demandés dans d'autres requêtes pour l'intersection considérée. On suppose ici que, par exemple, seuls quatre débits d'image différents peuvent être demandés: 30 Images/s (correspondant au débit de la séquence originale), 15 Images/s, 5 Images/s et 1 Image/s. La séquence originale est divisée en une succession de groupes de trente images. Lorsqu'un débit de 30 Im/s sera demandé, toutes les images de 15 chaque groupe seront transmises. Lorsqu'un débit de 15 lm/s sera demandé, une image sur deux sera envoyée en commençant par la première image d'un groupe de trente images. Lorsqu'un débit de 5 Im/s sera demandé, une image sur cinq sera envoyée en commençant par la première image d'un groupe de trente images. Enfin, lorsqu'un débit de 1 Im/s sera demandé, la première image d'un groupe de trente images sera envoyée. Une telle organisation garantit que deux clients demandant le même débit d'image recevront les mêmes images. Si des images manquent (c'est-à-dire qu'elles n'ont pas déjà été demandées dans une requête) ou si aucune combinaison de sessions multipoints ne permet de répondre à la requête courante, soit on crée une session pour les images manquantes, soit on subdivise des sessions existantes à l'étape E509. L'étape E509 est ensuite suivie de l'étape E510 au cours de laquelle on compare la résolution demandée par la requête courante aux résolutions déjà demandées. Si aucune combinaison de sessions existantes ne permet de répondre à la requête courante, on crée une nouvelle session multipoint ou on subdivise des sessions existantes (étape E511). 18 2864407 Dès que toutes les intersections ont été parcourues et traitées, l'étape E511 est suivie de l'étape E512 au cours de laquelle on vérifie qu'il ne reste pas de zones de l'image qui n'auraient pas été représentées dans les intersections. Si de telles zones non contenues dans les intersections sont identifiées, une nouvelle session multipoint ou point à point est alors créée à l'étape E513 pour les envoyer ultérieurement. Sinon on passe directement à l'étape E516 déjà décrite ci-dessus. De retour à l'étape E516, lorsque toutes les requêtes ont été traitées, l'étape E517 tente alors de réduire le nombre de sessions multipoints qui ont été créées. Il se peut en effet que certaines sessions multipoints correspondant à des zones spatiales différentes soient en fait requises par un même groupe d'utilisateurs. Dans ce cas, le serveur peut combiner ces sessions en une seule dans un souci de rationalisation. On notera que l'étape E517 est optionnelle. Le processus mis en oeuvre à cette étape est représenté plus en détails sur l'algorithme de la figure 4 qui fait partie intégrante de l'algorithme de la figure 3. L'algorithme débute à l'étape E601 par l'initialisation de variables i et j 20 à 0. Ces deux variables sont destinées à assurer le décompte des sessions multipoints et représentent chacune deux sessions multipoint parmi l'ensemble des sessions multipoints créées par le serveur. L'étape E601 est suivie de l'étape E602 au cours de laquelle on vérifie 25 que toutes les sessions multipoints ont été testées. Dans l'affirmative, le processus se termine. Sinon, on passe à l'étape E603 au cours de laquelle on vérifie que la variable j n'a pas atteint la valeur du nombre de sessions multipoints Nbsession. Si cette valeur Nbsession est atteinte, on passe à l'étape E610 qui incrémente la valeur de i d'une unité et affecte la valeur 0 à j. Dans le cas contraire, l'étape E603 est suivie de l'étape E604 au cours de laquelle on s'assure de ne considérer que les sessions distinctes l'une de l'autre (on exclut i = j). 19 2864407 Au cours de l'étape suivante E605, on vérifie que le groupe de demandeurs de la session multipoint i est identique au groupe de demandeur de la session j. Si c'est le cas, on vérifie que le nombre de niveaux de qualité pour les 5 sessions i et j sont identiques. Si c'est le cas, on vérifie que les débits d'images pour les sessions i et j sont identiques. Si à une de ces questions, la réponse est non, on passe à l'étape E609 qui incrémente la valeur de j d'une unité. Sinon, l'étape E605 est suivie de l'étape E606 au cours de laquelle on regroupe les precincts transmis dans les deux sessions i et j. L'étape E606 est ensuite suivie de l'étape E607 au cours de laquelle on supprime la session multipoint j de la liste des sessions. Cette étape est suivie de l'étape E608 au cours de laquelle on 15 décrémente d'une unité le nombre de sessions multipoints et l'on passe ensuite à l'étape E609 déjà décrite. Le processus de la figure 4 se termine lorsque toutes les sessions ont été traitées. De retour à la figure 2, lors de l'étape E407 qui suit l'étape E406 d'organisation des réponses par le serveur, ce dernier informe chaque client du contenu de chaque session réseau multipoint (descriptif de contenu). Au préalable, le serveur aura défini une adresse multipoint différente pour chaque session réseau multipoint. Plus particulièrement, à l'étape E407 le serveur insère cette information, ainsi qu'une description de chaque session réseau créée dans un fichier texte ou XML qui est ensuite transmis successivement à chaque client (identifié par son adresse IP) dans un paquet TCP/IP. Toutefois, avant de l'envoyer à un client donné, le serveur insère dans ce fichier l'identifiant de la session JPIP qu'il a affectée à ce client. On notera parmi les sessions créées par le serveur celles créées aux étapes E513 et E515 visées ci-dessus et qui peuvent être de type multipoint ou point à point. On notera également que, par souci de simplification, chaque machine client ayant émis une requête reçoit le même descriptif du contenu de toutes les sessions créées par le serveur. L'étape E407 est suivie de l'étape E408 au cours de laquelle le 5 serveur transmet chaque session réseau multipoint sur les adresses multipoints définies à l'étape précédente. Le serveur transmet également les sessions réseaux point à point, s'il en existe. Dès réception du ou des paquets décrivant la ou les sessions réseaux, 10 chaque client peut s'abonner aux sessions multipoints correspondant à sa requête initiale. Plus particulièrement, le client concerné 1, 2, ..., n transmet au serveur une requête d'abonnement à un sous-ensemble ou à l'ensemble des sessions multipoints créées par le serveur (aux étapes respectives E409a, E409b, ..., E409n). Le sous-ensemble ou l'ensemble des sessions est destiné à transporter les données d'image satisfaisant à la requête initialement transmise au serveur. L'algorithme de la figure 5 représente de façon schématique et récapitulative les différentes et principales étapes effectuées par chacune des machines clients 12 à 30 représentées à la figure 1 et dont le fonctionnement vient d'être décrit en référence aux figures 2 à 4. On notera que cet algorithme ne traite pas le cas où le client envoie une première requête avant même de recevoir la vidéo. Ce cas est supposé avoir eu lieu avant l'exécution de l'algorithme de la figure 5. L'algorithme de la figure 5 comporte une première étape E650 au cours de laquelle la machine client reçoit la vidéo diffusée en continu par le serveur. Au cours de l'étape suivante E652, il est prévu d'analyser la vidéo afin d'élaborer une requête spécifiant une zone spatiale d'intérêt, voire plusieurs zones, concernant une image ou une pluralité d'images de la vidéo. 21 2864407 Au cours de l'étape suivante E654, la requête ainsi élaborée est transmise au serveur. Le serveur reçoit les requêtes et les traite comme on l'a vu précédemment à partir de l'étape E403 de la figure 2 jusqu'à la génération et la transmission des descriptifs de contenus des sessions réseaux multipoints préalablement créées par le serveur. Le descriptif transmis à l'étape E407 par le serveur est reçu par la machine client concernée à l'étape E656. La machine client procède ensuite à une consultation du descriptif 10 reçu à l'étape E658 afin de déterminer si le contenu de la ou des sessions qui lui sont proposées satisfait à sa requête initiale. Dans l'affirmative, l'étape E658 est suivie d'une étape E660 au cours de laquelle la machine client transmet au serveur une requête d'abonnement à au moins certaines des sessions réseaux multipoints créées par le serveur. A l'étape suivante E662, la machine client concernée reçoit ainsi les données spécifiées dans sa requête initiale. Il convient de noter que les données d'image répondant à la requête initiale d'une machine client proviennent d'une ou de plusieurs sessions réseaux multipoints créées par le serveur pour la ou les intersections déterminées entre les différentes zones spatiales d'intérêt demandées dans l'ensemble des requêtes traitées par le serveur. L'ensemble de données spécifiques à la ou aux zones spatiales d'intérêt demandées par la machine client considérée et qui n'est pas contenu dans les intersections précitées est obtenu par une ou plusieurs sessions réseaux multipoints ou point à point préalablement créées par le serveur. Si l'un des utilisateurs ne souhaite qu'une zone d'une image, il n'est pas nécessaire que toute l'image lui soit transmise afin d'éviter de gaspiller la bande passante disponible sur le réseau. On notera que l'invention est particulièrement intéressante lorsque 30 plusieurs utilisateurs demandent simultanément la même vidéo. On notera que l'invention s'applique même si deux utilisateurs demandent deux zones spatiales d'intérêt distinctes lorsque ces deux zones ne permettent pas à elles seules de reconstituer l'image, ou bien demandent deux zones spatiales d'intérêt présentant une ou plusieurs parties communes (intersections). Par ailleurs, l'invention permet de satisfaire intégralement les demandes formulées par les machines clients. On notera que chaque client a la charge de sa propre régulation de débit, ce qui soulage le serveur de cette tâche. Grâce à l'invention, le serveur rationalise les réponses aux requêtes formulées par les machines clients et réduit ainsi les quantités de données transmises sur le réseau, ce qui permet de mieux s'adapter à la bande passante disponible sur le réseau et également de ne pas congestionner inutilement ce dernier. Un serveur intelligent organise au mieux le traitement de l'ensemble des requêtes reçues des différentes machines clients, ce qui permet de réduire le nombre de sessions ouvertes par rapport à l'ensemble des requêtes reçues. Notons que lorsqu'un client souhaite mettre fin à sa session vidéo, il doit en informer le serveur et, pour ce faire, il lui envoie une requête JPIP contenant le champ channel close ainsi que l'identifiant de la session. Dès réception de cette requête, le serveur supprime la session et exécute le processus de la figure 2 à partir de l'étape E406. Dans un mode de réalisation, les procédés de codage de la vidéo au format MJPEG2000, de traitement des requêtes (notamment de récupération des requêtes, de recherche des parties communes entre les zones spatiales d'intérêt des différentes requêtes) et de transmission des données suivant l'organisation des réponses selon l'invention sont mis en oeuvre sous la forme de programmes d'ordinateur. II en est de même pour les étapes du procédé illustrées à la figure 5. Ces programmes comportent une ou plusieurs séquences d'instructions dont l'exécution par un ordinateur ou, de manière plus générale, par un appareil de communication programmable qui joue le rôle du serveur 10 (figure 1), permet la mise en oeuvre des étapes desdits procédés en conformité avec l'invention. De manière générale, un moyen de stockage d'informations, lisible par un ordinateur ou par un microprocesseur, intégré ou non à cet ordinateur, et 23 2864407 éventuellement amovible, est adapté à mémoriser un programme apte à mettre en oeuvre ces procédés en conformité avec l'invention. Dans la figure 6, l'ordinateur 700 qui peut être un micro-ordinateur ou une station de travail, est connecté à différents périphériques, par exemple une caméra numérique 701 pour la capture de la vidéo ou tout autre dispositif d'acquisition ou de stockage d'images, tel qu'un scanner, fournissant à l'ordinateur des vidéos à transmettre. Ces vidéos peuvent être stockées dans les moyens de stockage dont dispose l'ordinateur. L'ordinateur 700 comporte également une interface de communication 718 qui est reliée à un réseau de communication 720, par exemple le réseau Internet, et qui est apte à transmettre et à recevoir des informations numériques. L'ordinateur 700 comporte également des moyens de stockage de données tels qu'un disque dur 712, un lecteur de disquettes 714 permettant d'écrire des données sur une disquette 716 et de lire ces données. L'ordinateur peut également comporter un lecteur de compact disques (CDROM ou DVDROM) non représenté, sur lequel peuvent être stockées les vidéos ainsi qu'un lecteur de cartes informatiques (PC-CARD) non représenté. Les codes exécutables du ou des programmes permettant de mettre en oeuvre les différentes parties de l'invention, sont, par exemple, mémorisés 20 dans le disque dur 712. Selon une variante de réalisation, les codes exécutables de ces programmes sont stockés dans une mémoire ROM ("Read Only Memory") 704 de l'ordinateur. L'ordinateur 700 comporte en outre un écran 708 permettant de visualiser les vidéos et un dispositif de pointage (non représenté), tel qu'une souris ou un crayon optique, et/ou un clavier 710 de manière à pouvoir interagir avec le programme. L'ordinateur comporte une unité centrale de traitement (CPU) 703, par exemple un microprocesseur, qui commande et dirige l'exécution des instructions du (ou des) programme(s) de l'invention stocké(s) dans la mémoire ROM 704 ou dans le disque dur 712. L'ordinateur 700 comporte également une mémoire RAM ("Random Access Memory") 707. Comme on peut le voir sur la représentation agrandie de la mémoire RAM 707, cette dernière comporte des registres destinés à mémoriser les variables créées et modifiées pendant l'exécution du (ou des) programme(s) selon l'invention, notamment les variables mentionnées plus haut dans l'exposé, en relation avec les figures 3 et 4. L'appareil de communication programmable 700 (serveur) comporte tous les moyens nécessaires à la mise en oeuvre de l'invention pour coder les données, transmettre une vidéo, recevoir les requêtes, les traiter, transmettre un descriptif du contenu des sessions créées, ainsi que les données des zones spécifiées dans les requêtes ou des zones élargies. La structure des machines clients est identique à celle de la figure 6 mais les fonctions remplies diffèrent: réception et analyse des vidéos, élaboration et transmission de requêtes initiales, consultation du ou des descriptifs reçus, génération et transmission de requêtes d'abonnement et réception de données satisfaisant aux requêtes initiales. A ces fonctions s'ajoutent notamment le codage et le décodage de données, l'affichage des vidéos et la mise en oeuvre d'une interface graphique qui permet d'intervenir sur la qualité d'affichage. REVENDICATIONS 1. Procédé de transmission continue d'une vidéo d'un serveur vers plusieurs machines clients à travers un réseau de communication, caractérisé en ce 5 qu'il comporte les étapes suivantes: - obtention de requêtes provenant de machines clients, au moins plusieurs des requêtes obtenues spécifiant chacune au moins une zone spatiale d'intérêt dans une ou plusieurs images de la vidéo, une zone spatiale représentant un ensemble de données numériques, - traitement des requêtes obtenues afin de déterminer une ou plusieurs intersections définissant des données communes entre les zones spatiales d'intérêt de la vidéo, - création d'une session réseau multipoint pour chaque intersection ainsi déterminée. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte une étape de transmission point à point sur le réseau, à partir du serveur, d'un descriptif du contenu de chaque session réseau multipoint destiné à informer chaque machine client. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comporte une étape d'obtention d'une requête d'abonnement d'une des machines clients à un sous-ensemble ou à l'ensemble des sessions multipoints créées par le serveur, ce sous-ensemble ou cet ensemble étant destiné à transporter les données satisfaisant la requête initiale de la machine client, ladite requête d'abonnement étant transmise par ladite machine client après consultation par celle-ci du descriptif du contenu d'au moins une session réseau multipoint. 4. Procédé selon la revendication 3, caractérisé en ce qu'il comporte une étape de transmission vers la une machine client concernée des données transportées par le sous-ensemble ou l'ensemble des sessions réseaux multipoints. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il comporte une étape de création d'au moins une session réseau multipoint ou point à point pour les données non contenues dans les intersections déterminées. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte une étape de transmission vers les machines clients concernées des données non contenues dans les intersections déterminées. 7. Dispositif de transmission continue d'une vidéo d'un serveur vers plusieurs machines clients à travers un réseau de communication, caractérisé en ce que le dispositif comporte: - des moyens d'obtention de requêtes provenant de machines clients, au moins plusieurs des requêtes obtenues spécifiant chacune au moins une zone spatiale d'intérêt dans une ou plusieurs images de la vidéo, une zone spatiale représentant un ensemble de données numériques, - des moyens de traitement des requêtes obtenues afin de déterminer une ou plusieurs intersections définissant des données communes entre les zones 10 spatiales d'intérêt de la vidéo, - des moyens de création d'une session réseau multipoint pour chaque intersection ainsi déterminée. 8. Dispositif selon la revendication 7, caractérisé en ce qu'il comporte des moyens de transmission point à point sur le réseau, à partir du serveur, d'un descriptif du contenu de chaque session réseau multipoint destiné à informer chaque machine client. 9. Dispositif selon la revendication 8, caractérisé en ce qu'une session réseau multipoint comporte une adresse multipoint dans le réseau. 10. Dispositif selon la revendication 9, caractérisé en ce que l'adresse 20 multipoint correspond à l'adresse d'un routeur multipoint du réseau. 11. Dispositif selon l'une des revendications 8 à 10, caractérisé en ce qu'il comporte des moyens d'obtention d'une requête d'abonnement d'une des machines clients à un sous-ensemble ou à l'ensemble des sessions multipoints créées par le serveur, ce sous-ensemble ou cet ensemble étant destiné à transporter les données satisfaisant à la requête initiale de la machine client. 12. Dispositif selon la revendication 11, caractérisé en ce qu'il comporte des moyens de transmission vers la machine client concernée des données transportées par le sous-ensemble ou l'ensemble des sessions réseaux multipoints. 13. Dispositif selon l'une des revendications 7 à 12, caractérisé en ce qu'il comporte des moyens de création d'au moins une session réseau multipoint ou point à point pour les données non contenues dans les intersections déterminées. 14. Dispositif selon la revendication 13, caractérisé en ce qu'il comporte des moyens de transmission vers les machines clients concernées des données non contenues dans les intersections déterminées. 15. Appareil de communication comportant un dispositif selon l'une des revendications 7 à 14. 16. Moyen de stockage d'informations, lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'une des revendications 1 à 6. 17. Moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur, comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'une des revendications 1 à 6. 18. Programme d'ordinateur chargeable dans un appareil programmable, comportant des séquences d'instructions ou portions de code logiciel pour mettre en oeuvre des étapes du procédé selon l'une des revendications 1 à 6, lorsque ledit programme d'ordinateur est chargé et exécuté par l'appareil programmable.