FR2834839A1 - Procede et dispositif de gestion des transmissions de donnees numeriques multimedia - Google Patents

Abstract

L'invention concerne un procédé de gestion des transmissions de données numériques multimédia d'un premier appareil de communication vers un deuxième appareil de communication à travers un réseau de communication, caractérisé en ce qu'il comporte les étapes suivantes :- obtention d'informations spécifiques représentatives d'un traitement, par le deuxième appareil de communication, de données qui ont été préalablement transmises, et- en fonction de ces informations spécifiques, décision quant à la possibilité de retransmettre ou non d'autres données préalablement transmises au deuxième appareil et qui ont été altérées.

Description

<Desc/Clms Page number 1>

La présente invention concerne un procédé de gestion des transmissions de données numériques multimédia d'un premier appareil de communication vers un deuxième appareil de communication à travers un réseau de communication.

De manière connue, la transmission de données numériques entre deux appareils de communication dont l'un, émetteur des données, joue le rôle d'un serveur et l'autre, récepteur des données transmises, joue le rôle d'une machine client, fait intervenir un protocole de transmission adapté à l'échange de données.

En particulier, lorsque des données multimédia sont transmises, il est impératif que le flux de données ne soit pas interrompu afin que l'affichage de ces données au niveau de la machine client soit réalisé de façon continue.

En effet, la machine client recevant les données sous forme codée en provenance du serveur les enregistre dans une mémoire de taille limitée, dans laquelle un décodeur vient lire et décoder ces données pour ensuite les afficher sur un écran de visualisation.

Le traitement de ces données au niveau de la machine client et en particulier le décodage de ces données et leur affichage se fait de façon continue, au fur et à mesure que les données codées sont reçues par cette machine.

On connaît d'après le document US 5,881, 245 de Thompson et al. intitulé"Method and apparatus for transmitting MPEG data at an adaptive data

<Desc/Clms Page number 2>

rate" cédé à la société Digital Vidéo Systèmes Inc., une méthode de régulation du flux des données vidéo entre un serveur et une machine client.

Plus particulièrement, cette méthode prévoit de transmettre davantage de nouvelles données lorsque l'espace mémoire de la machine client destiné à recevoir les données ainsi transmises est peu rempli.

Au contraire, cette méthode prévoit de transmettre moins de données lorsque cet espace mémoire est largement occupé.

De manière générale, on constate que dans certains réseaux de communication tels qu'Internet ou dans des réseaux dits "sans fil", des problèmes peuvent survenir lors de la transmission de données numériques multimédia.

En particulier, lors de l'émission de telles données par un serveur, la ou les machines client réceptrices de ces données peuvent, dans certains cas, recevoir des données entachées d'erreurs de transmission, voire même ne pas recevoir certaines données.

Il en résulte des erreurs lors de l'affichage du contenu multimédia ainsi transmis sur l'écran de visualisation de la ou des machines client.

La qualité de restitution du contenu multimédia se révèle donc préjudiciable pour l'utilisateur.

Par ailleurs, on a mis en place dans certains cas des modules de correction d'erreurs qui peuvent compenser des erreurs de transmission et, ainsi, atténuer des problèmes survenus à l'affichage de ces données.

Cependant, une trop grande quantité d'erreurs de transmission ne peuvent être compensées de cette façon et il en résulte inévitablement une diminution de la qualité de restitution du contenu multimédia transmis entre le serveur et la ou les machines client.

Face à ce problème, une solution pourrait consister à retransmettre systématiquement toutes les donnés erronées ou perdues.

Toutefois, la retransmission systématique de ces données encombrerait la bande passante qui est allouée aux transmissions entre le serveur et la ou les machines client et, ainsi, risquerait de congestionner le réseau de communication.

<Desc/Clms Page number 3>

Ce problème de la retransmission de données erronées ou perdues a été pris en compte dans différents protocoles de transmission.

Dans le protocole de contrôle de transmission appelé TCP (connu en terminologie anglo-saxonne sous le terme"Transmission Contro/Protocof'), l'appareil de communication jouant le rôle du serveur transmet un paquet de données à l'appareil de communication jouant le rôle du client, par l'intermédiaire du réseau.

Lorsque ce paquet a bien été reçu par la machine client, celle-ci renvoie au serveur un accusé de réception (connu en terminologie anglosaxonne sous le terme "Acknow/edgmenf').

Dans le cas où le serveur ne reçoit pas un tel accusé de réception à l'expiration d'un intervalle de temps prédéterminé, il retransmet systématiquement le paquet de données concerné à la ou aux machines client concernées.

Ce traitement est effectué pour tous les paquets de données transmis sur le réseau et non acquittés par la ou les machines client.

Il convient de noter que la retransmission systématique de paquets de données non acquittés n'améliore pas toujours la qualité de restitution du contenu multimédia transmis entre le serveur et la ou les machines client.

En effet, certains paquets de données retransmis peuvent être inutilisables par la machine client lorsqu'ils sont réceptionnés tardivement par rapport aux contraintes temporelles d'affichage du contenu multimédia sur l'écran de visualisation.

On connaît également le protocole de retransmission de données RTP ("Retransmission Payload Format en terminologie anglo-saxonne) IETF AudioNidéo Transport Working Group, July 18, 2001, en cours de standardisation.

Le protocole RTP est un protocole de transport pour des applications temps réel.

Ce protocole autorise la retransmission de données erronées ou perdues en fonction de la priorité qui leur est affectée.

<Desc/Clms Page number 4>

En particulier, un paquet de données auquel a été affecté une priorité élevée sera retransmis alors qu'un paquet affecté d'une priorité moins élevée ne sera pas retransmis.

Soit la machine client décide d'envoyer une demande de retransmission à la machine serveur suivant la priorité du paquet de données, soit la machine client demande une retransmission pour tous les paquets erronés ou non reçus et c'est alors la machine serveur qui décide de retransmettre ou non le paquet de données suivant sa priorité.

Les méthodes de transmission évoquées ci-dessus se révèlent peu adaptées aux contraintes de transmission et de traitement en continu des données numériques multimédia, ainsi qu'aux problèmes de transmission pouvant survenir dans le réseau de communication (erreurs, perte de données, ...) lors de la transmission de telles données.

La présente invention vise à remédier à au moins un des inconvénients précités en proposant un procédé de gestion des transmissions de données numériques multimédia d'un premier appareil de communication vers un deuxième appareil de communication à travers un réseau de communication, caractérisé en ce qu'il comporte les étapes suivantes : - obtention d'informations spécifiques représentatives d'un traitement, par le deuxième appareil de communication, de données qui ont été préalablement transmises, et - en fonction de ces informations spécifiques, décision quant à la possibilité de retransmettre ou non d'autres données préalablement transmises au deuxième appareil et qui ont été altérées.

Corrélativement, l'invention concerne également un dispositif de gestion des transmissions de données numériques multimédia d'un premier appareil de communication vers un deuxième appareil de communication à travers un réseau de communication, caractérisé en ce qu'il comporte : - des moyens d'obtention d'informations spécifiques représentatives d'un traitement, par le deuxième appareil de communication, de données qui ont été préalablement transmises, et

<Desc/Clms Page number 5>

- des moyens de décision, en fonction de ces informations spécifiques quant à la possibilité de retransmettre ou non d'autres données préalablement transmises au deuxième appareil et qui ont été altérées.

Ainsi, en tenant compte du traitement en cours ou à effectuer sur les données déjà reçues par le deuxième appareil de communication, il est possible de prévoir si cet appareil sera apte, ultérieurement, à recevoir d'autres données retransmises ou bien de nouvelles données en vue de leur traitement.

En effet, si le deuxième appareil de communication se révèle indisponible pendant un certain temps pour traiter de nouvelles données, alors il est possible, selon l'invention, d'envisager la retransmission de certaines données qui avaient été préalablement transmises mais sous une forme altérée.

La détermination de l'aptitude du deuxième appareil à recevoir des données retransmises peut être effectuée avant ou après avoir pris connaissance de l'altération de certaines données transmises.

Il convient de noter que les deux étapes précédemment mentionnées peuvent être effectuées dans le premier ou le deuxième appareil de communication.

Lorsqu'il s'agit du premier appareil, l'avantage réside dans le fait que cet appareil peut prendre des décisions sans savoir si des données ont réellement été altérées quand elles ont été transmises au deuxième appareil.

La nécessité de retransmettre des données est, quant à elle, déterminée par le deuxième appareil.

En outre, le premier appareil peut ainsi jouer le rôle d'appareil centralisateur de ce type de décisions pour plusieurs autres appareils du deuxième type.

Le premier appareil qui est, par exemple, un serveur peut également avoir une meilleure connaissance du réseau que le deuxième appareil et, ainsi, prendre une décision de meilleure qualité que ce deuxième appareil.

En revanche, si les deux étapes sont effectuées dans le deuxième appareil, cela évite d'avoir à transmettre les informations spécifiques au premier

<Desc/Clms Page number 6>

appareil, ce qui peut être avantageux si les transmissions sont de mauvaise qualité ou si la bande passante s'avère peu disponible.

En outre, l'invention permet d'optimiser les flux de transmission entre les appareils de communication et d'utiliser au mieux les ressources allouées à ces transmissions.

En particulier, lorsque le deuxième appareil de communication est accaparé par des opérations de traitement de données qui ont été reçues sous une forme non altérée, on profite de l'indisponibilité temporaire de cet appareil pour retransmettre, du premier vers ce deuxième appareil, des données qui avaient préalablement été transmises mais sous une forme altérée (données erronées ou perdues).

De plus, la retransmission de données, lorsque le deuxième appareil est considéré comme apte à recevoir de telles données, permet d'obtenir un bon compromis entre la situation où aucune retransmission n'est effectuée et la situation où toutes les données altérées sont systématiquement retransmises.

Par ailleurs, la retransmission de données altérées étant prévue, selon l'invention, de façon adaptée à la disponibilité du deuxième appareil, les données retransmises sont utilisées avec une plus grande efficacité (taux d'erreur réduit...) que dans le cas où la retransmission est systématique et où les données retransmises risquent d'arriver tardivement.

En effet, selon l'invention, la plus grande efficacité tient à ce que ces données sont retransmises au moment opportun et sont donc prises en compte dans les opérations ultérieures de traitement et, par conséquent, dans l'exploitation ultérieure des données traitées.

Dans le cas de données vidéo, on constate ainsi une meilleure qualité de restitution des données lors de leur visualisation.

Selon une caractéristique, la décision est plus particulièrement prise en fonction du résultat d'une comparaison entre les informations spécifiques représentatives du traitement de données par le deuxième appareil et au moins un critère prédéterminé.

<Desc/Clms Page number 7>

Ce ou ces critères prédéterminés sont représentatifs d'un état d'occupation ou de disponibilité du deuxième appareil de communication audelà duquel cet appareil est apte à recevoir d'autres données retransmises.

Selon une première approche, les informations spécifiques sont représentatives du temps nécessaire au deuxième appareil de communication pour traiter une quantité de données prédéterminée.

Ainsi, connaissant le temps de traitement des données déjà reçues par l'appareil et en cours de traitement ou à traiter, on peut prévoir la disponibilité ou l'indisponibilité ultérieure de cet appareil pour recevoir et/ou traiter des données retransmises.

Par exemple, la décision quant à la possibilité de retransmettre d'autres données est prise lorsque le temps nécessaire au deuxième appareil de communication pour traiter une quantité de données prédéterminée est au moins égal au temps pris pour la retransmission de ces autres données.

Selon une deuxième approche, les informations spécifiques sont représentatives du taux d'occupation par les données à traiter d'un espace mémoire MEM alloué à ces données.

En se basant sur ce taux d'occupation, on peut déterminer la disponibilité ou l'indisponibilité ultérieure de l'appareil pour recevoir et/ou traiter des données retransmises.

Plus particulièrement, la décision quant à la possibilité de retransmettre ou non d'autres données est prise en fonction de la valeur du taux d'occupation de l'espace mémoire par rapport à un seuil prédéterminé.

Si, par exemple, le taux d'occupation est supérieur au seuil, alors cela signifie que le deuxième appareil est accaparé par des opérations de traitement de données déjà reçues et est donc apte à recevoir et/ou à traiter des données retransmises.

Connaissant le temps de traitement par l'appareil d'une quantité de données prédéterminée, on peut évaluer le temps nécessaire pour libérer de la place dans l'espace mémoire et, ainsi, décider de l'aptitude de l'appareil à recevoir et/ou à traiter des données retransmises, compte tenu du temps consacré à la retransmission de données.

<Desc/Clms Page number 8>

Selon une caractéristique, les données successivement transmises constituant plusieurs entités multimédia distinctes, les données reçues par le deuxième appareil de communication sont stockées dans un espace mémoire intermédiaire TEMP comportant plusieurs zones mémoires TEMPi, i = 1 à N destinées à recevoir chacune les données correspondant à une même entité multimédia.

Selon une caractéristique dépendant de la précédente, à chaque zone mémoire TEMPi est affectée une variable Ti ayant une valeur représentative du nombre de transmissions demandées pour les données concernant ladite zone mémoire.

La variable Ti permet ainsi de connaître à tout moment le nombre de demandes de retransmission en cours concernant les données.

Selon une caractéristique, le procédé comporte une étape de détermination du type d'altération qu'ont subies les données transmises, à savoir s'il s'agit de données erronées ou perdues.

D'ailleurs, cette détermination est effectuée de façon différente pour détecter des données erronées ou perdues
En effet, on détermine si les données sont erronées sur les données courantes en cours d'analyse alors, que l'on vérifie si des données qui, normalement, devraient avoir été reçues antérieurement, ont bien été reçues.

Suivant une application, les données numériques multimédia sont des données vidéo.

Dans cette application, les entités multimédia sont, par exemple, des images.

L'invention concerne également un appareil de communication comportant un dispositif tel que brièvement exposé ci-dessus.

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

<Desc/Clms Page number 9>

- 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 brièvement exposé 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, à l'appareil de communication comportant un tel dispositif, aux moyens de stockage d'informations 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 de la présente invention apparaîtront plus clairement à la lecture de la description qui va suivre, faite en référence aux dessins annexés, sur lesquels : - la figure 1 représente de manière schématique une architecture de communication de type client-serveur dans laquelle l'invention peut être mise en oeuvre ; - la figure 2a illustre un algorithme de traitement d'une requête par le serveur de la figure 1 ; - la figure 2b illustre un algorithme de traitement d'une requête de retransmission de données par le serveur de la figure 1 ; - la figure 3 représente différentes mémoires et unités de traitement de paquets de données intégrées dans les éléments de l'architecture de communication de la figure 1 ; - la figure 4a représente un algorithme de gestion des retransmissions de données numériques multimédia selon l'invention ; - la figure 4b représente un algorithme détaillant les opérations effectuées lors de l'exécution de l'étape E307 de la figure 4a ; - la figure 5 est un mode de réalisation d'un appareil programmable mettant en oeuvre l'invention.

<Desc/Clms Page number 10>

Sur la figure 1 est représenté une architecture de communication du type client-serveur dans laquelle l'invention est avantageusement mise en oeuvre.

Sur cette figure, un premier appareil de communication 1 jouant le rôle du serveur est relié à un deuxième appareil de communication 2 qui est la machine client, par l'intermédiaire d'un réseau de communication 3 et d'une connexion qui est considérée comme étant établie.

Ce réseau est par exemple un réseau de communication utilisant le protocole Internet IP connu de l'homme de l'art.

Il s'agit dans l'exemple considéré d'une transmission point à point de données entre le serveur 1 et la machine client 2.

Cependant, le principe reste applicable au cas où le serveur est connecté simultanément à plusieurs machines client qui peuvent requérir du serveur des données numériques multimédia.

Ces données peuvent aussi avoir été créées par un appareil d'acquisition de données tel que, par exemple, un caméscope pour des données constituant des images d'une séquence vidéo.

Les données regroupées sous le terme données multimédia peuvent être, de manière non limitative, des images fixes, des vidéos, du son, des données de type texte (ex : documents graphiques...), des documents en langage HTML, des signaux issus d'un télécopieur ou d'une imprimante...

Dans l'exemple de réalisation considéré, on considérera uniquement des données vidéo qui seront transmises sur le réseau 3, regroupées sous la forme de paquets de données, avec des erreurs de transmission.

Ainsi, les données peuvent ne pas être reçues par la machine client 2 ou contenir des erreurs dues à la transmission et être reçues par la machine client dans un ordre différent de celui dans lequel elles ont été transmises par le serveur 1.

Le serveur 1 de la figure 1 peut comporter des éléments électroniques et/ou des éléments logiciels.

<Desc/Clms Page number 11>

Le serveur comprend une unité 4 de stockage de données numériques telles que des vidéos qui peut être interne ou externe comme illustré sur la figure 1.

Cette unité peut être, par exemple, une base de données locale ou distribuée.

On notera que les données stockées dans le serveur ou de façon associée à celui-ci peuvent avoir été reçues d'un environnement extérieur à l'ensemble comprenant les deux appareils 1 et 2 et le réseau 3, par exemple, par un autre réseau de communication.

En outre, les vidéos sont stockées soit sous forme non compressée, par exemple suivant un format YUV, soit sous forme compressée, en utilisant le format de compression conforme au standard MPEG-4 intitulé "Information technology-generic coding of audio-visual objects = part 2 : visual, ISOIIEC JTC 11SC 29/wiz M3056, December2000".

On notera qu'un format vidéo de type YUV signifie que la vidéo concernée possède trois composantes : la composante Y pour la luminance et les composantes U et V pour la chrominance.

Le serveur 1 comprend également une unité de stockage 11 destinée à mémoriser de façon temporaire des données numériques et des vidéos codées, et une unité 12 de récupération de données caractéristiques des vidéos à partir de l'unité de stockage 4.

Les données récupérées par l'unité 12 sont, soit les valeurs associées à chacun des pixels de chaque image d'une vidéo, soit les informations propres à cette vidéo, à savoir la taille du fichier vidéo, le chemin permettant d'accéder à cette vidéo et, dans le cas où la vidéo est stockée sous forme compressée, les paramètres de codage qui ont été utilisés pour coder cette vidéo.

Le serveur 1 comprend une unité 13 qui permet d'effectuer la transmission de données compressées ou non à la machine client 2 à travers le réseau 3, ainsi que la réception de données provenant de la machine client.

Le serveur comprend aussi une unité 14 de gestion des requêtes de données vidéo provenant de la machine client 2, voire d'autres machines client.

<Desc/Clms Page number 12>

L'unité 14 gère également la retransmission des données vers la machine client 2.

Le serveur 1 comporte également une unité de commande 15 des différentes opérations exécutées dans le serveur.

On notera que les différentes unités qui composent le serveur résident sur la même machine.

Cependant, il pourra être envisagé de distribuer ces unités sur plusieurs machines de type serveur et d'établir des communications entre ces différentes unités à travers le réseau de communication 3.

Cette distribution des unités ne modifiant en rien la mise en oeuvre de l'invention, on considérera par la suite, pour des raisons de simplicité, que toutes les unités sont localisées sur la même machine que nous appelons serveur.

La machine client 2, quant à elle, comporte une unité de transmission/réception de données numériques 20.

Cette unité 20 permet d'effectuer la transmission de données au serveur 1, à travers le réseau 3, et la réception de données provenant du serveur.

La machine client 2 comporte également une unité 21 de stockage de données numériques qui comporte, plus particulièrement, un espace mémoire MEM 51 alloué au stockage des données codées, image par image, et qui vont être traitées par le décodeur
L'unité 21 comporte aussi un espace mémoire intermédiaire TEMP 52 destiné à recevoir tous les paquets de données provenant du serveur 1.

Les caractéristiques de ces mémoires seront détaillées ultérieurement en référence à la figure 3.

La machine client 2 comporte une unité 22 de décodage (décodeur) et une unité de visualisation 23, permettant de visualiser des vidéos décodées.

On notera toutefois que l'invention s'applique également dans le cas où les données sont transmises sous forme non compressée.

<Desc/Clms Page number 13>

La machine client 2 comporte une unité 24 d'établissement des requêtes de retransmissions entre la machine client 2 et le serveur 1, ainsi qu'une unité 25 de gestion des retransmissions du serveur 1 à la machine client 2.

On notera que le dispositif de gestion des transmissions selon l'invention correspond, par exemple, à la machine client 2.

Toutefois, le dispositif selon l'invention peut alternativement correspondre uniquement aux différentes unités de la machine client qui mettent en oeuvre l'invention.

L'unité de gestion 25 permet de prendre une décision sur l'aptitude de la machine client à recevoir et/ou à traiter des retransmissions de paquets de données en fonction de sa charge de travail.

Cette charge de travail est évaluée en considérant les opérations de traitement en cours ou à venir sur les données préalablement reçues par la machine client 2.

En tenant ainsi compte du temps nécessaire, par exemple, au décodage des images codées stockées dans l'espace mémoire MEM ou, ce qui revient au même, en tenant compte du taux d'occupation de cet espace mémoire, l'unité 25 est capable de déterminer s'il est possible ou non d'envisager des retransmissions de paquets de données qui ont été préalablement transmis de façon altérée.

L'unité 24 pourra alors, en fonction de la décision prise par l'unité de gestion 25, et si cela s'avère nécessaire, établir une ou plusieurs requêtes de retransmission de paquets qui seront transmises au serveur 1 par l'unité 20.

Par ailleurs, la machine client 2 comporte une unité 26 de reconstruction des paquets de données reçus par l'unité 20, ces paquets étant alors stockés de façon ordonnée dans l'espace mémoire TEMP de l'unité 21.

La figure 2a illustre un algorithme comportant différentes instructions ou portions de code logiciel correspondant à des étapes du procédé de traitement, par le serveur 1 de la figure 1, d'une requête visant à obtenir la transmission de données vidéo.

Une telle requête émane de la machine client 2.

<Desc/Clms Page number 14>

Le programme d'ordinateur qui est basé sur cet algorithme est mémorisé dans l'unité de stockage temporaire de données 11 de la figure 1 et exécuté par l'unité de commande 15.

L'algorithme de la figure 2a comporte une première étape notée E200 au cours de laquelle le serveur 1 et, plus particulièrement, l'unité de gestion des requêtes 14 reçoit une requête émise par la machine client 2 à partir de l'unité de transmission 20.

Par exemple, cette requête se présente sous la forme d'une chaîne de caractères permettant d'identifier de façon unique des données vidéo mémorisées dans l'unité de stockage 4 du serveur 1.

Au cours de l'étape suivante E201, la requête provenant de la machine client 2 est transférée à l'unité de stockage temporaire 11 aux fins de mémorisation.

L'étape E201 est suivie d'une étape E202 au cours de laquelle il est prévu de récupérer les données vidéo disponibles dans l'unité de stockage 4 et de les mémoriser temporairement dans l'unité de stockage 11.

Les données vidéo sont plus particulièrement les valeurs associées à chacun des pixels de chaque image de la séquence vidéo.

Il convient de noter que l'étape E201 prévoit d'effectuer préalablement un test afin de déterminer si les données vidéo sont disponibles dans l'unité de stockage 4.

Au cours de l'étape suivante E203, l'unité de commande 15 du serveur 1 vient lire dans l'unité 11 les données vidéo stockées et l'unité de transmission 13 du serveur procède à la transmission des données vidéo compressées ou non vers la machine client 2.

Lorsque des données ont été transmises, elles restent accessibles dans l'unité de stockage intermédiaire 11 pendant une durée prédéterminée afin de permettre une éventuelle retransmission de tout ou partie de ces données.

On notera que la transmission des données vidéo compressées se fait préférentiellement à la volée (connu en terminologie anglo-saxonne sous le terme"streaming"), c'est-à-dire que les informations nécessaires à

<Desc/Clms Page number 15>

l'utilisateur pour reconstruire une image sont mémorisées dans l'unité de stockage 11, puis sont transmises à la machine client 2 avant que toutes les données vidéo ne soient compressées, lorsque la compression est envisagée.

On peut également considérer que les données sont transmises à la machine client avant même que toute la séquence vidéo ne soit mémorisée dans l'unité 11.

Ainsi, l'utilisateur reçoit au niveau de la machine client 2 les données par paquets de données, dans chacun desquels se trouvent des informations permettant à cet utilisateur de décoder tout ou partie d'une image courante.

Dans la machine client, on n'attend pas d'avoir reçu toute la séquence vidéo pour procéder au décodage des données, lorsque cela est nécessaire, et à leur affichage, mais on effectue ces opérations au fur et à mesure que les données sont reçues.

Plus particulièrement, les paquets de données transmis sur le réseau de communication 3 de la figure 1 sont transmis suivant le protocole de communication appelé UDP signifiant Protocole de datagramme ou Protocole sans connexion (connu en terminologie anglo-saxonne sous le terme"User

Datagram Protocol).

Ce protocole est particulièrement simple à mettre en oeuvre et prévoit d'ajouter un en-tête aux données transmises.

L'en-tête ajouté contient l'adresse de la source dont proviennent les données, à savoir l'adresse du serveur 1 de la figure 1, l'adresse de destination de ces données, à savoir la machine client 2, une somme de contrôle (connu en terminologie anglo-saxonne sous le terme"Checksum") et une variable Retrans.

On notera que la somme de contrôle appelée"Checksum"permet de vérifier le nombre de bits transmis dans le paquet et ainsi de déceler d'éventuelles erreurs de transmission.

On peut notamment utiliser d'autres techniques de contrôle telles que celles utilisant le bit de parité ou le code de redondance cyclique (connu en terminologie anglo-saxonne sous le terme de "Cyclic Redundancy Code").

<Desc/Clms Page number 16>

En outre, la variable Retrans peut prendre deux valeurs : la valeur 1 si le paquet correspond à une retransmission et la valeur 0 dans les autres cas.

Afin de gérer le séquencement des paquets de données, c'est-à-dire le cas où les paquets de données transmis dans un certain ordre par le serveur sont reçus dans un ordre différent par la machine client, on ajoute un en-tête aux données transmises sur le réseau, en plus de l'en-tête UDP mentionné cidessus.

Ce second en-tête contient un numéro de séquence qui, lorsque les données multimédia sont conformes au standard MPEG-4 mentionné cidessus, comprend deux nombres : le numéro du VoP et le numéro d'un paquet num.

Comme défini dans le standard MPEG-4, un VoP peut être considéré comme un objet vidéo qui correspond à l'ensemble des données constitutives d'une image et le numéro associé à cette image est noté vop~id.

On notera qu'un objet vidéo ou VoP (acronyme signifiant en terminologie anglo-saxonne"Video Object Plane") peut être découpé en un ou plusieurs paquets comme illustré sur la figure 3.

Le numéro de paquet noté num est incrémenté d'une unité pour chaque nouveau paquet de données transmis par le serveur, et ce numéro peut ainsi être utilisé par la machine client pour détecter d'éventuelles pertes de paquets ou pour rétablir l'ordre des paquets qui seraient reçus par la machine client dans le désordre.

On notera que la valeur initiale du numéro de paquet num est zéro et qu'elle est réinitialisée pour chaque nouvelle image transmise (VoP).

Comme indiqué plus haut, les paquets de données transmis sur le réseau sont conservés de façon temporaire pendant une durée prédéterminée dans l'unité de stockage 11 du serveur 1 et sont identifiables dans cette unité par leur numéro de séquence (VoP, num).

La figure 2b illustre un algorithme comportant différentes instructions ou portions de code logiciel correspondant à des étapes du procédé de traitement, par le serveur 1 de la figure 1, d'une requête provenant de la

<Desc/Clms Page number 17>

machine client 2 et visant à obtenir la retransmission de certaines données vidéo.

Le programme informatique qui est basé sur cet algorithme est mémorisé dans l'unité de stockage temporaire de données 11 de la figure 1 et exécuté par l'unité de commande 15.

L'algorithme de la figure 2b comporte une première étape notée E210 au cours de laquelle le serveur 1 et, plus particulièrement, l'unité de gestion des requêtes 14, reçoit une requête émise par la machine client 2 à partir de l'unité de transmission 20.

Cette requête demande au serveur de retransmettre un paquet identifié par un numéro de séquence donné.

Plus particulièrement, cette requête se présente sous la forme d'une chaîne de caractères contenant le numéro de séquence du paquet à retransmettre (VoP, num).

Au cours de l'étape suivante E211, il est prévu de mémoriser la chaîne de caractères de la requête dans l'unité de stockage temporaire 11.

Au cours de l'étape suivante E212, on recherche si le paquet identifié dans la requête reçue à l'étape E210 est toujours stocké dans l'unité 11. Dans la négative, le paquet n'est plus disponible étant donné que les paquets sont, par exemple, conservés dans l'unité 11 pendant une durée prédéterminée, ce qui met fin a l'algorithme.

Lorsque le paquet à retransmettre a été identifié dans l'unité de stockage 11, l'étape suivante E213 positionne à 1 la valeur de la variable Retrans dans l'en-tête du paquet trouvé dans l'unité 11.

On transmet ensuite ce paquet à la machine client 2 à partir de l'unité de transmission 13.

Ceci met fin à l'algorithme de la figure 2b.

On notera que le dispositif de gestion des transmissions selon l'invention, gérant plus particulièrement les retransmissions et qui a été introduit plus haut en référence à la description de la machine client 2 pourrait, à titre de variante, être intégré au serveur 1 de la figure 1.

<Desc/Clms Page number 18>

Dans ce cas de figure, la décision sur la possibilité de retransmettre des paquets de données, compte tenu de la disponibilité de la machine client 2, serait prise par le serveur 1.

Ce dernier traite alors la requête de retransmission provenant de la machine client 2 conformément à la décision qu'il aura prise préalablement sur la possibilité de telles retransmissions.

Ainsi, lorsque de telles retransmissions ne sont pas envisageables, l'étape E210 de la figure 2b est directement suivie d'une étape de transmission d'une réponse à la requête de la machine client, informant celle-ci du fait que la ou les retransmissions demandées ne sont pas autorisées.

Il est également possible de ne pas répondre à la requête provenant de la machine client si les retransmissions ne sont pas envisagées.

Par ailleurs, lorsque l'invention est mise en oeuvre dans le serveur, on peut prévoir que la prise de décision quant à la possibilité de retransmettre des données déjà transmises à la machine client est effectuée à intervalle régulier.

Toutefois, dans la variante où l'invention est mise en oeuvre dans le serveur 1 de la figure 1, il est nécessaire que le serveur obtienne des informations de la machine client, à sa demande ou automatiquement, sur la disponibilité de celle-ci, comme cela a été défini plus haut.

On va maintenant décrire en référence à la figure 3, de façon plus détaillée le processus de transmission des paquets de données du serveur 1 de la figure 1 à la machine client 2 de cette même figure.

Sur cette figure 3, seuls ont été représentés les éléments du serveur 1 et de la machine client 2 utiles pour illustrer la transmission des paquets de données à travers le réseau de communication 3.

Comme mentionné plus haut à titre d'exemple, les paquets de données sont transmis sur le réseau au format MPEG-4.

Comme représenté sur la figure 3, les données, par exemple, de type vidéo, sont mémorisées dans une partie de l'unité de stockage temporaire 11 de la figure 1 qui est numérotée 30 sur la figure 3.

<Desc/Clms Page number 19>

Dans cette unité 30, les données vidéo sont mémorisées sous la forme d'images codées correspondant aux entités précédemment dénommées VoP.

Sur la figure 3, les images ou VoP notées 21,22, 23,24 et 25 constituent une suite d'images correspondant à une séquence vidéo appelée VoL ou Couche d'objet Video (connu en terminologie anglo-saxonne sous le terme "Video Object Layer') et définie dans le standard MPEG-4.

Comme représenté sur la figure 3, chaque image VoP est stockée dans une zone mémoire correspondante de l'unité 30.

Le serveur 1 de la figure 3 comporte également une unité 31 faisant partie de l'unité de commande 15 de la figure 1 et qui a pour fonction de découper chaque image VoP en plusieurs paquets de données de taille identique.

Il convient de noter que les images VoP n'ont pas nécessairement des tailles identiques compte tenu du codage vidéo défini par le standard MPEG-4.

Dans l'exemple de la figure 3, l'unité 31 partitionne l'image VoP 21 en plusieurs paquets de taille identique qui sont stockés, après partitionnement, dans la mémoire 32 qui fait partie de l'unité de stockage 11 de la figure 1.

Les paquets de données constituant l'image VoP 21 ainsi séparés sont ensuite transmis par l'unité de transmission 13 du serveur 1 à la machine client 2 de la figure 1.

L'unité de transmission/réception 20 de la machine client 2 reçoit un à un ces paquets de données et procède, au moyen de l'unité de reconstruction 26, à la reconstruction de l'image VoP 21 au fur et à mesure de la réception des paquets.

Dans la machine client 2, la mémoire TEMP 51 est allouée, par l'unité de réception 20 de la figure 1, comme espace mémoire de travail et correspond à une zone mémoire de taille limitée de l'unité de stockage 21 dans laquelle les données multimédia transmises par le serveur 1 sont stockées.

<Desc/Clms Page number 20>

Dans l'exemple de réalisation considéré, l'espace mémoire TEMP peut mémoriser jusqu'à cinq images VoP dans des zones mémoires respectives nommées TEMP1, TEMP 2, TEMP 3, TEMP4 et TEMP5.

Par ailleurs, à chaque zone mémoire TEMPi, avec i allant de 1 à 5, est affectée une variable Ti qui possède une valeur représentative du nombre de retransmissions demandées pour les données concernant la zone mémoire considérée.

Ainsi, la valeur Ti est égale à zéro si aucune demande de retransmission n'a été transmise au serveur concernant les paquets de données mémorisés dans la zone mémoire TEMPi.

Par contre, dans le cas contraire, Ti est égal au nombre de demandes de retransmissions en attente de réponse du serveur pour les paquets de données associés à la zone mémoire TEMPi considérée.

On notera que chacune des zones mémoires TEMPi est destinée à recevoir les données correspondant à une même entité multimédia qui, dans l'exemple considéré, est une image mais pourrait, dans d'autres cas, correspondre à d'autres signaux numériques tels que par exemple des signaux sonores.

Dans la machine client 2, un numéro d'image (vopjd) est associé à une zone mémoire TEMPi de l'espace mémoire TEMP.

L'unité de reconstruction 26 de la machine client 2 stocke les paquets de données reçus et appartenant à une même image dans une zone mémoire TEMPi associée au numéro de VoP, vopjd, du paquet considéré de l'espace mémoire intermédiaire TEMP.

A l'intérieur d'une même zone mémoire TEMPi, les paquets de données sont placés dans l'ordre du numéro num qui leur a été affecté au serveur.

Ainsi, par exemple, le paquet reçu avec un numéro de paquet num égal à cinq correspond au cinquième paquet de la zone mémoire TEMPi de l'espace mémoire intermédiaire TEMP.

<Desc/Clms Page number 21>

Lors du stockage des paquets de données, au fur et à mesure de leur réception dans la machine client 2, la valeur de la variable Ti est mise à jour.

On notera que, lors de la réception d'un nouveau paquet de données, cette variable Ti se voit affecter la valeur zéro tant qu'il n'a pas été procédé à l'analyse de la validité de ce paquet. L'analyse de la validité d'un paquet consiste à déterminer si celui-ci comporte des erreurs de transmission ou non.

Par ailleurs, la machine client 2 comporte également un espace mémoire MEM 52 sur la figure 3, et dans lequel sont stockées les différentes images VoP, dès lors qu'il a été considéré qu'aucune demande de retransmission de paquets n'était en attente pour chacune de ces images.

Il convient de noter que dans certaines situations, même si une ou plusieurs demandes de retransmissions de paquets de données concernant une image attendent une réponse du serveur, la machine client 2 peut décider de ne plus attendre ces retransmissions afin de ne pas gêner le traitement ultérieur des données (ex : décodage et affichage).

Comme représenté sur la figure 3, l'espace mémoire MEM comporte déjà, dans des zones distinctes de cet espace mémoire, des images en cours de traitement ou à traiter notées VoP16, VoP17, VoP18, VoP19 et VoP20.

On notera par ailleurs que l'espace mémoire TEMP servant de mémoire intermédiaire simplifie le traitement selon l'invention.

En effet, cet espace mémoire intermédiaire gère les paquets de données venant d'être reçus et non encore traités, ainsi que ceux qui ont été analysés suivant l'algorithme de la figure 4a et qui, soit ne nécessitent pas de retransmission, soit sont en attente de retransmission.

Par contre, dès que tous les paquets de données associés à un même numéro de VoP (vop~id) et disponibles dans la zone mémoire TEMPi concernée sont transférés dans une zone mémoire définie de l'espace mémoire MEM 52, alors on ne modifie plus la structure de l'image VoP ainsi stockée.

<Desc/Clms Page number 22>

La figure 4a illustre un algorithme comportant différentes instructions ou portions de code logiciel correspondant à des étapes du procédé selon l'invention.

Le programme informatique noté"Progr"qui est basé sur cet algorithme est mémorisé dans l'unité de stockage 21 de la machine client 2 de la figure 1 et exécuté par l'unité de gestion 25, ce qui permet ainsi de mettre en oeuvre le procédé selon l'invention.

Ce programme est également stocké dans l'appareil de la figure 5 qui sera décrit ultérieurement.

L'algorithme de la figure 4a détaillant le schéma de fonctionnement de la machine client 2 comporte une première étape E300 au cours de laquelle l'unité 20 de la machine reçoit un paquet de données transmis par l'unité 13 du serveur 1.

Au cours de l'étape suivante E301, ce paquet de données est stocké dans l'espace mémoire de travail ou mémoire temporaire TEMP appartenant à l'unité de stockage 21.

Au cours de l'étape suivante E301, on détermine la zone mémoire TEMPi de l'espace mémoire TEMP 51 dans laquelle le paquet reçu doit être mémorisé.

La zone mémoire TEMPi est déterminée en fonction du numéro de séquence contenu dans l'en-tête ajouté à l'en-tête UDP.

Ce numéro de séquence comprend, plus particulièrement, le numéro d'image vop~id auquel est associé une zone mémoire TEMPi et le numéro num correspondant à la place du paquet dans cette zone mémoire.

L'algorithme comporte une étape suivante E302 au cours de laquelle plusieurs opérations sont effectuées.

Tout d'abord, on vérifie à partir de l'en-tête du paquet la variable Retrans pour déterminer, selon que sa valeur est à 1 ou à 0, si le paquet considéré correspond à une retransmission ou à un nouveau paquet (première transmission).

<Desc/Clms Page number 23>

Après avoir déterminé la nature de la transmission, on procède au cours de cette même étape, à une mise à jour de la variable Ti affectée à la zone mémoire TEMPi.

Ainsi, par exemple, lorsque la variable Retrans est égale à 1, ce qui correspond à un paquet de retransmission, alors la variable Ti est décrémentée d'une unité.

Au contraire, si la variable Retrans est égale à 0, cela signifie que le paquet est un nouveau paquet et donc la variable Ti est mise à 0.

Au cours de l'étape E302, on vérifie également si une erreur de transmission est intervenue lors du transfert du paquet sur le réseau de communication (validité du paquet).

Pour ce faire, on vérifie une donnée de contrôle ("Checksum") qui est présente dans l'en-tête du paquet considéré.

Par exemple, avant de transmettre le paquet, l'unité de transmission 13 du serveur 1 calcule la somme modulo 256 (sans retenue) des octets du paquet de données à transmettre et inscrit cette valeur dans l'en-tête du paquet considéré.

A la réception de ce paquet (étape E302), la machine client peut effectuer le même calcul à partir des octets du paquet de données reçu.

Si une différence apparaît entre la valeur de la donnée de contrôle présente dans l'en-tête du paquet est celle recalculée, alors une erreur de transmission est détectée.

Ainsi, au cours de l'étape E302, on procède à la mise à jour et à l'enregistrement du numéro de séquence N du paquet reçu ainsi qu'à sa validité VN dans l'unité de stockage 21 de la machine client 2 (figure 1).

En particulier, la validité VN d'un paquet de données est égale à 0 si le paquet contient des erreurs de transmission et à 1 si ce paquet n'en contient pas. Si le paquet reçu n'est pas valide (VN = 0), il est effacé de la mémoire TEMPi correspondante.

L'algorithme de la figure 4a comporte également une étape E303 au cours de laquelle on procède à la détermination d'informations spécifiques qui sont représentatives du traitement des données ayant été préalablement

<Desc/Clms Page number 24>

transmises à la machine client, que ce traitement soit en cours ou sur le point d'être réalisé sur de telles données.

En d'autres termes, il s'agit de déterminer la charge de travail ou la disponibilité de la machine client.

Pour ce faire, on peut par exemple, déterminer le taux d'occupation de l'espace mémoire MEM 52 de la figure 3.

Alternativement, on peut également déterminer le temps nécessaire à la machine client et, plus particulièrement, à l'unité de décodage 22 de celleci, pour effectuer le traitement des données présentes dans l'espace mémoire MEM.

Consécutivement à l'obtention de ces informations spécifiques (ex : taux d'occupation mémoire), l'étape suivante E304 prévoit un test afin de déterminer s'il est possible ou non d'envisager de retransmettre à la machine client des paquets de données qui ont déjà été transmis mais sous une forme altérée.

Au cours de cette étape, il s'agit en quelque sorte de déterminer l'état du protocole de transmission qu'il est possible d'appliquer, à savoir "retransmissions possibles"ou"pas de retransmissions".

Le test pratiqué lors de cette étape est basé sur les résultats fournis à l'étape E303, à savoir les informations spécifiques obtenues et, plus particulièrement, sur une comparaison entre ces informations spécifiques et un critère prédéterminé.

Prenons comme exemple le cas où les informations spécifiques sont représentatives du taux d'occupation de l'espace mémoire MEM alloué aux données à traiter ou en cours de traitement par la machine client 2.

Il est possible dans ce cas, par exemple, de définir un taux d'occupation correspondant à dix images stockées dans cet espace mémoire.

Ainsi, selon que le taux d'occupation de l'espace mémoire alloué MEM est supérieur ou inférieur à dix images, le procédé selon l'invention prévoit de fixer l'état du protocole de transmission respectivement à"retransmissions possibles"ou"pas de retransmissions".

<Desc/Clms Page number 25>

En effet, lorsque le taux d'occupation de l'espace mémoire est supérieur à un critère prédéterminé, alors on peut considérer que la machine client ne peut recevoir pour le moment de nouvelles données et, ainsi, on peut envisager des retransmissions de paquets de données qui avaient été préalablement transmis sous forme altérée (erreurs, perte...).

De telles retransmissions de paquets de données n'interrompront en aucune façon le flux de traitement et/ou d'affichage des données dans la machine client.

Au contraire, lorsque le taux d'occupation de l'espace mémoire MEM est inférieur à un critère prédéterminé, alors, pour ne pas interrompre le traitement du flux de données, l'invention prévoit de ne pas permettre la retransmission d'autres paquets de données.

En effet, une telle retransmission retarderait la transmission de nouveaux paquets de données, ce qui risquerait d'interrompre le flux de traitement et/ou d'affichage des données.

On notera que l'on peut également se baser sur un critère qui est le temps nécessaire à la machine client pour traiter une quantité de données prédéterminée, présente dans son espace mémoire MEM, en vue de décider si des retransmissions sont envisageables ou non.

En effet, lorsque le temps nécessaire à la machine client pour traiter cette quantité de données prédéterminée est au moins égal au temps pris pour la retransmission d'autres données, alors on peut prendre la décision d'envisager de retransmettre ultérieurement d'autres données.

Après avoir pris la décision, à l'étape E304, quant à la possibilité de retransmettre ou non des données déjà transmises à la machine client et lorsque des retransmissions sont envisageables, alors cette étape est suivie d'une étape E305.

Au cours de cette étape, on procède à un test sur la validité du paquet de données en cours d'analyse en récupérant la variable VN dans l'unité de stockage 21 de la figure 1.

Lorsque le test pratiqué à l'étape E305 fait apparaître que VN est égal à 1 (E306), cela signifie que le paquet reçu et en cours d'analyse ne

<Desc/Clms Page number 26>

contient pas d'erreur de transmission et cette étape est alors suivie d'une étape E307.

Au contraire, lorsque l'étape E305 révèle que la variable VN est égale à 0 (E308), cela signifie que le paquet reçu et en cours d'analyse contient des erreurs de transmission et cette étape est alors suivie d'une étape E309.

Au cours de cette dernière étape, la machine client 2 transmet au serveur 1 une requête de retransmission du paquet reçu et en cours d'analyse, en précisant dans cette requête le numéro de séquence N concerné par le paquet et récupéré dans l'unité de stockage 21.

Par ailleurs, lors de cette même étape E309, la variable Ti correspondant à la zone mémoire TEMPi qui devrait contenir ce paquet est incrémentée d'une unité pour indiquer qu'une demande de retransmission de paquet vient d'être effectuée.

On notera que les paquets dont on a demandé la retransmission seront à leur tour analysés suivant l'algorithme de la figure 4a après avoir été reçus.

Consécutivement aux étapes E306 et E309, au cours de l'étape suivante E307 précédemment citée, un test est pratiqué afin de déterminer si des paquets de données que la machine client devait recevoir n'ont pas été reçus (paquets perdus).

Le détail des opérations effectuées lors de cette étape est illustré sur la figure 4b.

L'algorithme de la figure 4b qui fait partie intégrante de celui de la figure 4a débute par une première étape E310 au cours de laquelle on recherche un paquet prédéterminé parmi les paquets qui sont supposés avoir été préalablement reçus et stockés par la machine client.

Ainsi, après avoir reçu et analysé un paquet courant affecté du numéro num, on recherche la présence dans les paquets précédents du paquet portant, par exemple, le numéro num-5, pour le numéro d'image vop~id identique à celui du paquet courant.

<Desc/Clms Page number 27>

Afin de pouvoir répondre à cette question, un test est pratiqué à l'étape suivante E311 pour déterminer si le numéro num est inférieur à 5 ou non.

On notera que le chiffre 5 a été choisi pour tenir compte de l'éventuelle réception des paquets de manière désordonnée.

Toutefois, un autre chiffre aurait pu être pris en considération sans que cela ne remette en cause le principe de l'invention.

Lorsque le résultat du test pratiqué à l'étape E311 est positif, alors cela signifie que la zone mémoire TEMPi contient moins de cinq paquets. On est donc obligé de prendre en compte un autre critère afin de poursuivre la recherche parmi les paquets de données stockés dans la zone mémoire précédant celle contenant le paquet courant.

Ainsi, au cours de l'étape suivante E312, on pratique un test afin de déterminer si les paquets de données concernant l'image portant le numéro vopjd-1 se trouvent toujours dans l'une des zones mémoire TEMPi de l'espace mémoire TEMP 51 de la figure 3.

Dans la négative, il est mis fin à l'étape de recherche et l'étape E312 est suivie de l'étape E313 de l'algorithme de la figure 4a qui sera décrite ultérieurement.

Dans l'affirmative, l'étape E312 est suivie d'une autre étape E314 au cours de laquelle un test est pratiqué afin de déterminer si le paquet portant le numéro (numMax-5 + num) est présent dans la zone mémoire correspondant au numéro d'image vopjd - 1.

On notera que la valeur numMax correspond au plus grand numéro de paquet pour le numéro d'image vop~id -1 considéré.

Lorsque le test pratiqué à l'étape E314 est positif, alors le paquet prédéterminé recherché a bien été trouvé et cette étape est suivie de l'étape E313 de l'algorithme de la figure 4a.

Au contraire, lorsque le test pratiqué à l'étape E314 est négatif, cela signifie que le paquet a été perdu et cette étape est alors suivie d'une étape E315 de l'algorithme de la figure 4a qui sera décrite ultérieurement.

<Desc/Clms Page number 28>

De retour au test pratiqué à l'étape E311, lorsque le résultat de celuici est négatif, alors cette étape est suivie d'une étape E316.

Au cours de cette étape, un autre test est pratiqué, afin de déterminer si le paquet affecté du numéro num-5 est présent dans l'image affectée du numéro vopjd.

Dans l'affirmative, le paquet prédéterminé recherché a bien été identifié, et l'étape E315 est alors suivie de l'étape E313 de l'algorithme de la figure 4a.

Au contraire, lorsque le résultat du test pratiqué à l'étape E316 est négatif, cela signifie que le paquet est perdu et cette étape est alors suivie de l'étape E315 de l'algorithme 4a.

De retour à l'algorithme de la figure 4a, lorsque le paquet a été considéré comme perdu (E307), suite aux résultats négatifs des tests pratiqués aux étapes 314 et 316 de la figure 4b, alors la machine client procède à la transmission de requêtes vers le serveur (E315).

Ces requêtes visent à obtenir la retransmission du paquet prédéterminé qui n'a pas été retrouvé, en indiquant le numéro de séquence de celui-ci.

* Au cours de cette étape E315, on incrémente d'une unité la variable Ti correspondant à la zone mémoire TEMPi qui devrait contenir le paquet recherché et non trouvé.

L'étape E313 qui a été citée plus haut, consécutivement aux résultats positifs trouvés lors de l'exécution des étapes E314 et E316 (figure 4b), comporte un test afin de vérifier si le paquet reçu à l'étape E300 et analysé suivant l'algorithme de la figure 4a contient un champ dénommé vop~start~code défini par le format MPEG-4.

On notera que chaque objet vidéo VoP commence par un champ vop~startcode indiquant le debut d'un VoP.

Ce champ indique dans le paquet reçu un changement du numéro d'image vop.

Il convient de noter que ce test revient à identifier un numéro de paquet num égal à zéro.

<Desc/Clms Page number 29>

Lorsque le paquet reçu ne contient pas un tel champ, alors il est mis fin à l'algorithme de la figure 4a et l'on s'intéresse alors à la réception et à l'analyse d'un autre paquet.

Au contraire, si le paquet reçu et en cours d'analyse contient un champ vop~start~code, l'étape E313 est suivie d'une étape E317.

Au cours de cette étape, on vérifie si aucune demande de retransmission n'est en attente pour l'un des paquets de l'image précédente (VoP précédent), ce qui revient à comparer la valeur de la variable Ti par rapport à la valeur 0.

Si la variable Ti prend la valeur 0, alors cela signifie qu'aucune demande de retransmission n'est en cours d'attente.

L'image précédente, telle que, par exemple, l'image stockée dans la zone mémoire TEMP5 de la figure 3, est alors déplacée de la mémoire TEMP vers l'espace mémoire MEM réservé, par exemple, au décodage, lors de l'étape suivante E318.

La position de cette image dans l'espace mémoire MEM est obtenue avec le numéro vop~id de cette image.

Consécutivement à l'étape E318, il est mis fin à l'algorithme de la figure 4a.

Si, au contraire, la variable Ti ne prend pas la valeur 0, cela signifie qu'au moins une demande de retransmission est en attente pour l'un des paquets de l'image précédente.

Il est alors mis fin à l'algorithme de la figure 4a.

De retour à l'étape E304, lorsque le test qui y est pratiqué conduit à une décision qui ne permet pas d'envisager des retransmissions de paquets de données pour des paquets déjà transmis à la machine client 2 sous une forme altérée, alors cette étape est suivie d'une étape E319 identique à l'étape E313 précédemment décrite.

Si le paquet reçu et en cours d'analyse ne comporte pas d'indication de changement d'image, alors il est mis fin à l'algorithme de la figure 4a.

Au contraire, en cas d'indication de changement d'image, l'étape E319 est suivie d'une étape E320 au cours de laquelle on procède, de même

<Desc/Clms Page number 30>

qu'à l'étape E318 précédemment décrite, au déplacement des paquets de données constituant l'image précédente (VoP précédent) de la zone mémoire TEMPi (par exemple, la zone mémoire TEMP5 de la figure 3) vers une zone localisée de l'espace mémoire MEM réservé, par exemple, au décodage.

La position de cette image dans l'espace mémoire MEM est obtenue avec le numéro d'image vopjd.

Ceci met fin à l'algorithme de la figure 4a.

Comme mentionné plus haut, il est possible de prendre une décision, dans le serveur de la figure 1, sur la possibilité de retransmettre ou non à la machine client des données déjà transmises à celle-ci.

Selon cette approche, le serveur demande à la machine client ou aux machines client, à intervalle régulier (par exemple toutes les secondes), les informations spécifiques visées à l'étape E303 de l'algorithme de la figure 4a.

Il convient de noter qu'il peut être prévu que ce soit la machine client qui transmette spontanément ces informations au serveur.

Pour chaque machine client, le serveur détermine ainsi l'état du protocole de transmission (E304) qu'il est possible d'appliquer en fonction de ces informations spécifiques.

L'obtention de ces informations spécifiques permet au serveur d'évaluer l'aptitude de la machine client à recevoir d'éventuelles retransmissions de paquets de données.

Suivant cette deuxième approche, les machines de type client ne gèrent pas la retransmission des paquets de données comme le fait le serveur et se contentent d'émettre des requêtes en vue de la retransmission de paquets de données perdus ou contenant des erreurs de transmission.

Le serveur recevant ces différentes requêtes de retransmission provenant des machines client décide alors de retransmettre ou de ne pas retransmettre tel ou tel paquet de données, suivant l'aptitude de la machine client considérée à recevoir des paquets de données.

Il est également possible pour le serveur de tenir compte d'autres critères pour prendre cette décision (ex. : bande passante disponible...).

<Desc/Clms Page number 31>

On comprend que la gestion des retransmissions, que ce soit au niveau de la machine client 2 ou au niveau du serveur 1 se fasse de façon dynamique dans la mesure où la disponibilité ou l'indisponibilité de la machine client évolue au cours du temps.

Lorsque la deuxième approche précédemment mentionnée est envisagée, il convient de noter que seules les étapes E303 et E304 de l'algorithme de la figure 4a sont exécutées au niveau du serveur.

En référence à la figure 5, est décrit un exemple d'appareil programmable mettant en oeuvre l'invention. Cet appareil est adapté à recevoir et à traiter des données numériques multimédia ou à recevoir et à transmettre de telles données.

Selon le mode de réalisation choisi et représenté à la figure 5, un appareil mettant en oeuvre l'invention est par exemple un micro-ordinateur 500 ou une station de travail connecté à différents périphériques, par exemple une caméra numérique 501 (ou un scanner, ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant à l'appareil des données notamment vidéo à traiter (par exemple : décodage) et à afficher ou, éventuellement à transmettre.

L'appareil 500 comporte un bus de communication 502 auquel sont reliés : - une unité centrale de traitement 503 (microprocesseur), qui exerce la fonction de l'unité de commande 15 de la figure 1, - une mémoire morte 504, pouvant comporter le programme"Progr", - une mémoire vive 506, comportant des registres 507 adaptés à enregistrer des variables créées et modifiées au cours de l'exécution du programme précité et notamment les variables P, MEM, TEMP, TEMP1, TEMP2, TEMP3, TEMP4, TEMP5, T1, T2, T3, T4, T5, VN, N mentionnées en référence aux figures précédentes, - un écran 508 permettant de visualiser les données traitées (par exemple décodées) et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec le programme selon l'invention, à l'aide d'un clavier 510 ou

<Desc/Clms Page number 32>

de tout autre moyen tel qu'un dispositif de pointage non représenté, comme par exemple une souris ou un crayon optique, - un disque dur 512 pouvant comporter le programme"Progr" précité, - un lecteur de disquette 514 adapté à recevoir une disquette 516 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention, - une interface de communication 518 reliée à un réseau de communication 520, par exemple le réseau Internet ou un réseau de type sans fil conforme à la norme IEEE802. 11, l'interface étant apte à transmettre et à recevoir des données.

Les données à traiter par l'appareil 500 peuvent également à titre d'alternative, être reçues par l'intermédiaire du réseau de communication 520.

Dans le cas de données audio, l'appareil comprend en outre une carte d'entrée/sortie reliée à un microphone qui sont tous deux non représentés.

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

Le code exécutable du programme"Progr"permet à l'appareil programmable de mettre en oeuvre notamment les étapes du procédé pour, d'une part, la récupération des informations spécifiques représentatives du traitement en cours ou à effectuer sur des données déjà reçues par l'appareil (exemple : taux d'occupation de l'espace mémoire alloué au décodage des données) et, d'autre part, la décision quant à la possibilité de retransmettre ou non d'autres données préalablement transmises à l'appareil sous forme altérée. Ce code peut être stocké par exemple dans le disque dur 512 ou en mémoire morte 504 comme représenté sur la figure 5.

Bien qu'un seul programme soit identifié, il est possible d'avoir plusieurs programmes ou sous programmes pour mettre en oeuvre l'invention.

<Desc/Clms Page number 33>

Selon une variante, la disquette 516, peut contenir le code exécutable du ou des programmes selon l'invention qui, une fois lu par l'appareil 500, sera stocké dans le disque dur 512.

En seconde variante, le code exécutable du ou des programmes pourra être téléchargé par l'intermédiaire du réseau de communication 520, via l'interface 518, pour être stocké de façon identique à celle décrite précédemment.

Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un programme dont l'exécution permet la mise en oeuvre du procédé selon l'invention.

De manière plus générale, le programme pourra être chargé dans un des moyens de stockage de l'appareil 500 avant d'être exécuté.

L'unité centrale 503 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 512 ou la mémoire ROM 504, sont transférés dans la mémoire vive RAM 506 qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que les registres 507 pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention.

Il convient de noter que l'appareil de traitement de données comportant le dispositif selon l'invention peut également être un appareil programmé.

Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).

On notera que l'appareil de la figure 5 qui contient le programme "Progr"précédemment mentionné peut être, dans le cadre d'une architecture de communication du type client-serveur, la machine client 2 de la figure 1.

<Desc/Clms Page number 34>

Par ailleurs, à titre d'alternative, l'appareil de la figure 5 peut être le serveur 1 de la figure 1.

Dans cette dernière hypothèse, l'appareil comporte, mémorisé dans un moyen de stockage, le code exécutable du programme"Progr"qui permet à l'appareil de mettre en oeuvre) les étapes du procédé pour, d'une part, la récupération des informations spécifiques représentatives du traitement en cours ou à effectuer sur des données déjà reçues par la machine client 2 de la figure 1 et, d'autre part, la décision quant à la possibilité de retransmettre ou non vers cette machine d'autres données préalablement transmises à cette dernière sous forme altérée.

Claims (32)

REVENDICATIONS

1. Procédé de gestion des transmissions de données numériques multimédia d'un premier appareil de communication vers un deuxième appareil de communication à travers un réseau de communication, caractérisé en ce qu'il comporte les étapes suivantes : - obtention (E303) d'informations spécifiques représentatives d'un traitement, par le deuxième appareil de communication, de données qui ont été préalablement transmises, et - en fonction de ces informations spécifiques, décision (E304) quant à la possibilité de retransmettre ou non d'autres données préalablement transmises au deuxième appareil et qui ont été altérées.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte une étape de comparaison (E304) des informations spécifiques avec au moins un critère prédéterminé, l'étape de décision étant effectuée en fonction du résultat de cette comparaison.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les informations spécifiques sont représentatives du temps nécessaire au deuxième appareil de communication pour traiter une quantité de données prédéterminée.

4. Procédé selon la revendication 3, caractérisé en ce que la décision quant à la possibilité de retransmettre d'autres données est prise lorsque le temps nécessaire au deuxième appareil de communication pour traiter une quantité de données prédéterminée est au moins égal au temps pris pour la retransmission de ces autres données.

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que les informations spécifiques sont représentatives du taux d'occupation par les données à traiter d'un espace mémoire (MEM) alloué à ces données.

6. Procédé selon la revendication 5, caractérisé en ce que la décision quant à la possibilité de retransmettre ou non d'autres données est prise en fonction de la valeur du taux d'occupation de l'espace mémoire par rapport à un seuil prédéterminé.

<Desc/Clms Page number 36>

7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que, les données successivement transmises constituant plusieurs entités multimédia distinctes, les données reçues par le deuxième appareil de communication sont stockées dans un espace mémoire intermédiaire (TEMP) comportant plusieurs zones mémoires (TEMPi, i = 1 à N) destinées à recevoir chacune les données correspondant à une même entité multimédia.

8. Procédé selon la revendication 7, caractérisé en ce qu'à chaque zone mémoire (TEMPi) est affectée une variable (Ti) ayant une valeur représentative du nombre de transmissions demandées pour les données concernant ladite zone mémoire.

9. Procédé selon la revendication 8, caractérisé en ce qu'en cas de réception de données retransmises, le procédé comporte une étape de mise à jour d'au moins une variable (Ti) affectée à au moins une zone mémoire à laquelle lesdites données sont destinées.

10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce qu'il comporte une étape (E305) de détermination du type d'altération des données transmises.

11. Procédé selon les revendications 7 et 10, caractérisé en ce que, les données transmises étant regroupées dans des paquets de données numérotés, après réception d'un paquet courant affecté d'un numéro (num), l'étape de détermination comporte une étape de recherche (E307) d'un paquet prédéterminé parmi les paquets qui sont supposés avoir été préalablement reçus.

12. Procédé selon la revendication 11, caractérisé en ce que l'étape de recherche prend en compte un critère permettant de rechercher des paquets de données stockés dans une zone mémoire différente de celle contenant le paquet courant (num).

13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce que les données numériques multimédia sont des données vidéo.

14. Procédé selon les revendications 7 et 13, caractérisé en ce que les entités multimédia sont des images.

<Desc/Clms Page number 37>

15. Dispositif de gestion des transmissions de données numériques multimédia d'un premier appareil de communication vers un deuxième appareil de communication à travers un réseau de communication, caractérisé en ce qu'il comporte : - des moyens d'obtention d'informations spécifiques représentatives d'un traitement, par le deuxième appareil de communication, de données qui ont été préalablement transmises, et - des moyens de décision, en fonction de ces informations spécifiques, quant à la possibilité de retransmettre ou non d'autres données préalablement transmises au deuxième appareil et qui ont été altérées.

16. Dispositif selon la revendication 15, caractérisé en ce qu'il comporte des moyens de comparaison des informations spécifiques avec au moins un critère prédéterminé, la décision étant prise en fonction du résultat de cette comparaison.

17. Dispositif selon la revendication 15 ou 16, caractérisé en ce que les informations spécifiques sont représentatives du temps nécessaire au deuxième appareil de communication pour traiter une quantité de données prédéterminée.

18. Dispositif selon la revendication 17, caractérisé en ce que la décision quant à la possibilité de retransmettre d'autres données est prise lorsque le temps nécessaire au deuxième appareil de communication pour traiter une quantité de données prédéterminée est au moins égal au temps pris pour la retransmission de ces autres données.

19. Dispositif selon l'une des revendications 15 à 18, caractérisé en ce que les informations spécifiques sont représentatives du taux d'occupation par les données à traiter d'un espace mémoire (MEM) alloué à ces données.

20. Dispositif selon la revendication 19, caractérisé en ce que la décision quant à la possibilité de retransmettre ou non d'autres données est prise en fonction de la valeur du taux d'occupation de l'espace mémoire par rapport à un seuil prédéterminé.

21. Dispositif selon l'une des revendications 15 à 20, caractérisé en ce que, les données successivement transmises constituant plusieurs entités

<Desc/Clms Page number 38>

multimédia distinctes, les données reçues par le deuxième appareil de communication sont stockées dans un espace mémoire intermédiaire (TEMP) comportant plusieurs zones mémoires (TEMPi, i = 1 à N) destinées à recevoir chacune les données correspondant à une même entité multimédia.

22. Dispositif selon la revendication 21, caractérisé en ce qu'à chaque zone mémoire (TEMPi) est affectée une variable (Ti) ayant une valeur représentative du nombre de transmissions demandées pour les données concernant ladite zone mémoire.

23. Dispositif selon la revendication 22, caractérisé en ce que le dispositif comporte des moyens de mise à jour d'au moins une variable (Ti) affectée à au moins une zone mémoire à laquelle lesdites données sont destinées.

24. Dispositif selon l'une des revendications 15 à 23, caractérisé en ce qu'il comporte des moyens de détermination du type d'altération des données transmises.

25. Dispositif selon les revendications 21 et 24, caractérisé en ce que, les données transmises étant regroupées dans des paquets de données numérotés, après réception d'un paquet courant affecté d'un numéro (num), les moyens de détermination comportent plus particulièrement des moyens de recherche d'un paquet prédéterminé parmi les paquets qui sont supposés avoir été préalablement reçus.

26. Dispositif selon la revendication 25, caractérisé en ce que les moyens de recherche prennent en compte un critère permettant de rechercher des paquets de données stockés dans une zone mémoire différente de celle contenant le paquet courant (num).

27. Dispsositif selon l'une des revendications 15 à 26, caractérisé en ce que les données numériques multimédia sont des données vidéo.

28. Dispositif selon les revendications 21 et 27, caractérisé en ce que les entités multimédia sont des images.

29. Appareil de communication, caractérisé en ce qu'il comporte un dispositif de gestion des transmissions selon l'une des revendications 15 à 28.

<Desc/Clms Page number 39>

30. 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é de gestion des transmissions selon l'une des revendications 1 à 14.

31. 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é de gestion des transmissions selon l'une des revendications 1 à 14.

32. Programme d'ordinateur chargeable dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions ou des portions de code logiciel pour mettre en oeuvre les étapes du procédé de gestion des transmissions selon l'une des revendications 1 à 14, lorsque ce programme d'ordinateur est chargé et exécuté par l'appareil programmable.