FR2927749A1 - Procede et dispositif de transmission de donnees, notamment video. - Google Patents

Abstract

Le procédé de transmission de paquets de données depuis un serveur à destination d'au moins un client, comporte :- une étape (301 à 304) d'estimation d'une durée séparant la transmission d'un premier et d'un deuxième paquets successifs, en fonction d'une information relative au premier paquet et- une étape (306, 307) de déclenchement et de définition de retransmission du deuxième paquet, en fonction de ladite durée.Dans des modes de réalisation, le client estime ladite durée en fonction du type du deuxième paquet et de résultats statistiques concernant le type du deuxième paquet et demande la retransmission d'un paquet attendu plus longtemps que cette durée.Dans des modes de réalisation, le serveur estime la durée en fonction du type de charge utile d'un premier paquet à retransmettre et d'au moins un deuxième paquet suivant ledit premier paquet à retransmettre et effectue spontanément la retransmission du deuxième paquet avec le premier paquet en fonction de cette durée.

Description

La présente invention concerne un procédé et un dispositif de transmission de données, notamment de données vidéo. Elle vise, en particulier, une transmission de données vidéo mettant en oeuvre un contrôle d'erreur par retransmission de données. Dans le cas de la transmission vidéo par paquets sur un réseau où le protocole RTP (acronyme de Real-Time Transport Protocol pour protocole de transport en temps-réel) est utilisé, le réseau n'est pas fiable puisqu'il n'assure pas des conditions de transmission stables et que des pertes peuvent survenir. Dans le contexte du codage vidéo H.264 ou SVC (acronyme de Scalable video coding ou codage vidéo adaptable), l'unité de transport de données vidéo est le NAL (acronyme de network abstraction layer pour couche d'abstraction de réseau). Le NAL peut être vu comme un conteneur qui regroupe les données vidéo derrière un en-tête ( header ) fournissant une description de ces données.

L'IETF (acronyme de Internet Engineering Task Force pour force de travail d'ingénierie de l'Internet) a défini des charges utiles RTP pour transporter des NAL AVC (acronyme de Advanced Video Coding pour codage vidéo avancé) comme exposé, par exemple, dans l'article de S. Wenger et autres, RTP payload format for H.264 video , de février 2005.

Ce format de charge utile a été ensuite complété pour le codage SVC comme exposé, par exemple, dans l'article de S. Wenger et autres, RTP payload format for SVC video du 9 juillet 2007. Dans ce contexte, quatre types de charge utile ont été définis : - paquet unitaire à NAL unique, - paquet d'agrégation à temps unique, ou STAP, (acronyme de Single time aggregation packet ), - paquet d'agrégation à temps multiple, ou MTAP, (acronyme de Multiple time aggregation packet ) et - paquet unitaire fragmenté, ou FU (acronyme de Fragmented unit packet ).

Les paquets à NAL unique ont été définis pour la compatibilité arrière avec les standards antérieurs mais leur usage n'est pas recommandé. On suppose, dans ce qui suit, que ce type de paquet n'est pas utilisé. Les autres types de charge utile sont décrits en regard de la figure 1, dans laquelle sont représentés un flux de données vidéo 105, en ligne supérieure et ce flux vidéo encapsulé en paquets 110 à 130, en ligne inférieure. Comme on l'observe, un paquet STAP contient un (cas du paquet 115) ou plusieurs (cas du paquet 110) NALs qui correspondent au même instant, par exemple à des couches, ou slices , c'est-à-dire à des portions décodables indépendamment les unes des autres de la même trame. Un paquet MTAP 130 contient plusieurs NALs qui correspondent à des instants différents. Un paquet FU 120 ou 125 est utilisé pour transporter des NALs qui ne peuvent être transportés par un seul paquet, par exemple à cause d'une limitation de taille de paquet. Le MTU (acronyme de "Maximum Transfer Unit pour unité de transfert maximum) définit la taille de paquet maximale qui garantit que le paquet ne sera pas fragmenté par le réseau. Des mécanismes de contrôle d'erreur basés sur la retransmission sont généralement regroupés sous le nom ARQ (acronyme de Automatic Repeat Request pour requête de répétition automatique). ARQ est un outil très efficace pour retrouver des données perdues. Il est basé sur la détection, au niveau du client, des pertes et la transmission d'un accuse de réception, ou ACK (abréviation de acknowledgement ) ou d'un accusé de non réception, ou NACK (abréviation de Non ACK ). Le serveur retransmet les données non reçues, objets d'un NACK. Cependant, ce mécanisme a été conçu pour des applications sans contraintes de temps, comme celles de transferts de fichiers. Il est généralement admis que ce type de mécanisme est trop lent pour des applications ne supportant pas de retard, comme la vidéoconférence ou de très courts retards, comme la vidéo à la demande. Le retard induit pas ARQ est la combinaison de deux retards. Le premier dépend du réseau et on considère qu'il ne peut être réduit. Il correspond à la durée de transmission du NACK et à celle de retransmission du paquet perdu. Le second est lié au délai de détection de la perte de données. Quand des paquets RTP sont transmis sur le réseau, un numéro séquentiel est inséré dans chaque paquet. Les paquets successivement transmis possèdent ainsi des numéros successifs. Le client détecte des pertes lorsqu'il identifie un manque dans les numéros successivement reçus. Ainsi, lorsqu'un paquet est perdu, le client doit attendre de recevoir le paquet suivant celui qui est perdu pour détecter la perte du paquet. Ce délai augmente encore lorsque plusieurs paquets successifs sont perdus. Plusieurs solutions ont été proposées pour améliorer la réactivité des ARQ en réduisant ce second retard. Le document US 7,124,343 décrit un serveur qui transmet un paquet à un client sur un premier lien et un indicateur de la transmission de ce paquet sur un deuxième lien. Lorsqu'il reçoit l'indicateur, le client lance une mesure de temps avec laquelle il estime la durée d'arrivée du paquet. Lorsque le client estime que le paquet aurait déjà du être arrivé, il transmet un NACK au serveur. Cependant cette solution impose l'utilisation de deux liens, ou canaux, ce qui n'est pas toujours faisable et réduit la bande passante disponible pour les données vidéo. Le document US 2004 0,013,114 décrit des applications client/serveur dans lesquelles un intervalle de temps est alloué au serveur pour transmettre des paquets. Le serveur retransmet tous ces paquets s'il reçoit un NACK concernant l'un de ces paquets. Cependant cette solution réduit aussi la bande passante disponible pour les données vidéo. La présente invention vise à remédier à ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé de transmission de paquets de données depuis un serveur à 30 destination d'au moins un client, caractérisé en ce qu'il comporte : - une étape d'estimation d'une durée séparant la transmission d'un premier et d'un deuxième paquets successifs, en fonction d'une information relative au premier paquet et - une étape de déclenchement et de définition de retransmission du deuxième paquet, en fonction de ladite durée. Grâce à ces dispositions, la réactivité de la retransmission est améliorée car, d'une part, le client peut détecter la perte d'un paquet sans attendre la réception du paquet suivant et, d'autre part, le serveur peut anticiper le risque de perte conjointe des paquets à transmettre et, en conséquence, retransmettre les paquets les plus susceptibles d'être perdus à la suite de la perte d'un premier paquet. De plus, la mise en oeuvre de l'invention permet d'adapter la réactivité au type de paquet, ce qui réduit la proportion de retransmissions qui serait injustifiées si on n'en tenait pas compte. Selon des caractéristiques particulières, l'information relative au premier paquet est représentative d'un type de contenu du deuxième paquet et, au cours de l'étape d'estimation de durée, on estime la durée séparant la transmission du premier et du deuxième paquets en fonction du type de contenu du deuxième paquet. Selon des caractéristiques particulières, l'information relative au premier paquet est représentative d'un type de contenu du premier paquet et, au cours de l'étape d'estimation de durée, on estime la durée séparant la transmission du premier et du deuxième paquets en fonction du type de contenu du premier paquet. Selon des caractéristiques particulières, au cours de l'étape d'estimation de durée, on estime la durée en fonction du type de charge utile du premier paquet. Selon des caractéristiques particulières, au cours de l'étape d'estimation de durée, on estime ladite durée en fonction du fait que le premier et le deuxième paquets transportent, ou non, des données d'image de la même image. Selon des caractéristiques particulières, lesdites données sont des données vidéo et l'information relative au premier paquet représente la fragmentation entre au moins le premier et le deuxième paquets de données vidéo correspondants à un même instant temporel. Les inventeurs ont, en effet, déterminé que tout ou partie de ces paramètres influence la durée s'écoulant entre la réception de deux paquets par le client et/ou le risque de perte conjointe de paquets transmis par le serveur. Selon des caractéristiques particulières, au cours de l'étape d'estimation de durée, le client estime ladite durée en fonction du type du premier paquet et de résultats statistiques concernant la durée séparant la réception du premier et du deuxième paquets en fonction du type de contenu du premier paquet. Selon des caractéristiques particulières, au cours de l'étape d'estimation de durée, le client estime ladite durée pour les paquets possédant chaque type de charge utile, à partir des durées séparant la réception de deux paquets successifs constatées pour les paquets reçus, lorsque la charge utile du premier de ces deux paquets reçus successivement possède ledit type de charge utile. Selon des caractéristiques particulières, au cours de l'étape d'estimation de durée, le client estime ladite durée en fonction du rang du premier paquet dans un train de paquets possédant le même type de charge utile. Les inventeurs ont, en effet, déterminé que tout ou partie de ces paramètres influence la durée s'écoulant entre la réception de deux paquets par le client. Selon des caractéristiques particulières, au cours de l'étape de déclenchement et de définition de retransmission d'au moins un desdits paquets, en fonction de ladite durée, le client mesure la durée écoulée depuis la réception du premier paquet et émet, à destination du serveur, un message de demande de retransmission du deuxième paquet, si le deuxième paquet n'est pas encore reçu, en fonction d'une comparaison entre ladite durée écoulée et ladite durée estimée. Selon des caractéristiques particulières, au cours de l'étape d'estimation de durée, le serveur estime ladite durée en fonction du type de charge utile d'un premier paquet à retransmettre et d'au moins un deuxième paquet suivant ledit premier paquet à retransmettre. Les inventeurs ont, en effet, déterminé que tout ou partie de ce type de charge utile influence la durée s'écoulant entre l'émission de deux paquets successifs par le serveur. Selon des caractéristiques particulières, au cours de l'étape de déclenchement et de définition de retransmission d'au moins un desdits paquets, en fonction de ladite durée, le serveur détermine une probabilité de perdre au moins un deuxième paquet à transmettre en fonction de son type de charge utile, sachant que le premier paquet a été perdu. Selon des caractéristiques particulières, au cours de l'étape de déclenchement et de définition de retransmission d'au moins un desdits paquets, en fonction de ladite durée, le serveur détermine une probabilité de perdre au moins un deuxième paquet à transmettre en fonction du type de charge utile du premier paquet à retransmettre, sachant que le premier paquet a été perdu. Selon des caractéristiques particulières, ladite probabilité tient compte d'un modèle de perte. Selon des caractéristiques particulières, ledit modèle de perte tient 20 compte d'un effet de mémoire du canal de transmission entre ledit serveur et ledit client. Selon des caractéristiques particulières, ledit modèle de perte tient compte de valeurs de paramètres différentes pour les paquets possédant différents types de charge utile. 25 Selon des caractéristiques particulières, lesdites valeurs de paramètres sont déterminées en fonction de données transmises par le client. Selon des caractéristiques particulières, au cours de l'étape de déclenchement et de définition de retransmission, le serveur détermine un nombre de paquets à transmettre avec le premier paquet à retransmettre en 30 fonction de leur probabilité de perte conjointe.

Grâce à l'utilisation de ces probabilités, et éventuellement de ces modèles et paramètres, on optimise la retransmission d'au moins un deuxième paquet. Selon un deuxième aspect, la présente invention vise un dispositif de 5 transmission de paquets de données depuis un serveur à destination d'au moins un client, caractérisé en ce qu'il comporte : - un moyen d'estimation d'une durée séparant la transmission d'un premier et d'un deuxième paquets successifs, en fonction d'une information relative au premier paquet et 10 - un moyen de déclenchement et de définition de retransmission du deuxième paquet, en fonction de ladite durée. Selon des caractéristiques particulières, le moyen de déclenchement et de définition de retransmission est incorporé au client, et ledit dispositif comporte : 15 - un moyen de mesure de la durée écoulée depuis la réception du premier paquet ; - un moyen de comparaison de la durée mesurée et d'une valeur représentative de la durée estimée ; et - un moyen d'émission, à destination du serveur, d'un message de 20 demande de retransmission du deuxième paquet en fonction du résultat fournit par le moyen de comparaison, si le deuxième paquet n'est pas encore reçu. Selon des caractéristiques particulières, le moyen d'estimation de durée est incorporé au serveur, et le dispositif comporte : - un moyen de détermination d'une probabilité de perdre le 25 deuxième paquet sachant que le premier paquet a été perdu, dite probabilité conjointe de perte, en fonction de la durée estimée ; et - un moyen de retransmission au client du deuxième paquet en fonction de la probabilité conjointe de perte déterminée. Selon un troisième aspect, la présente invention vise un programme 30 d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé de transmission objet de la présente invention tel que succinctement exposé ci-dessus. Selon un quatrième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé de transmission objet de la présente invention tel que succinctement exposé ci-dessus. Les avantages, buts et caractéristiques de ce dispositif de transmission, de ce programme d'ordinateur et de ce support d'informations étant similaires à ceux du procédé de transmission objet de la présente invention, tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels : - la figure 1 représente différents types de charges utiles de paquets de données vidéo transmis sur un réseau, - la figure 2 représente, schématiquement, un couple client/serveur au cours de la transmission de données depuis le serveur à destination du client, - la figure 3 représente, sous forme d'un logigramme, des étapes mises en oeuvre par un client, dans un premier mode de réalisation du procédé objet de la présente invention, - la figure 4 représente, sous forme d'un logigramme, des étapes mises en oeuvre par un serveur, dans un deuxième mode de réalisation du procédé objet de la présente invention, - la figure 5 représente, schématiquement, un modèle de pertes de paquets sur un réseau de transmission, - la figure 6 représente, schématiquement, des probabilités mises en oeuvre dans le deuxième mode de réalisation du procédé objet de la présente invention, - la figure 7 représente, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention pouvant être utilisé comme serveur et comme client et - la figure 8 représente, sous forme d'un logigramme des étapes 5 mises en oeuvre dans un troisième mode de réalisation du procédé objet de la présente invention. Dans la description qui va suivre, on décrit, d'abord deux modes de réalisation particuliers du procédé de transmission objet de la présente invention, le premier, illustré en figures 2, 3 et 7, étant adapté à être implémenté 10 côté client, le second, illustré en figures 2 et 4 à 7, étant adapté à être implémenté côté serveur. Ces deux premiers modes de réalisation peuvent être implémentés indépendamment ou ensemble, cette dernière combinaison améliorant d'autant plus l'efficacité de la transmission. En regard de la figure 8, on décrit un troisième mode de réalisation dans lequel le serveur et le client 15 effectue, chacun, des étapes améliorant la réactivité du système de retransmission. On note ici que l'on appelle serveur le système électronique qui fournit des données, quel que soit sa forme, même s'il n'est pas basé sur un serveur au sens informatique. De même, on appelle client le système 20 électronique qui reçoit les données de la part du serveur. Ainsi, un client peut être un serveur dans une seconde transmission de données. Dans les figures, on n'a représenté qu'un seul client. Cependant, la présente invention ne se limite pas au cas où le serveur ne transmet des données qu'à un seul client mais s'étend, bien au contraire, au cas où plusieurs 25 clients sont destinataires des données émises par le serveur. Dans la suite de la description, on considère la transmission de données vidéo codées selon l'un des codages H.264 ou SVC, sur un réseau local ou LAN (acronyme de local area network ), par paquets RTP. Comme on l'observe en figure 2, pour mettre en oeuvre le procédé 30 objet de la présente invention, un serveur 201 et un client 202 communiquent par l'intermédiaire d'un réseau 210. Le serveur 201 comporte notamment une unité de calcul 203, une unité de stockage 204 et une unité réseau 205. L'unité de calcul 203 effectue, d'une part, les calculs nécessaires à la mise en forme des données à transmettre, selon le codage vidéo utilisé et met en oeuvre les programmes conservés par l'unité de stockage 204, d'autre part. L'unité de stockage 204 conserve, d'une part, un programme implémentant le procédé objet de la présente invention et, notamment les étapes illustrées en figure 4 et, d'autre part, des données vidéos à transmettre, avant et après traitement par l'unité de calcul 203. L'unité réseau 205 effectue, d'une part, la transmission et, éventuellement la retransmission, sur le réseau 210, des paquets comportant les données vidéo à transmettre, et, d'autre part, la réception de messages provenant du client 202, notamment des messages d'accusé de réception, positifs ACK ou négatifs, NACK . Le serveur 201 est capable de réguler le flux de données vidéo (en anglais bitrate ) pour le faire correspondre à la bande passante disponible sur le réseau 210. Cette bande passante est estimée grâce à des informations en provenance du client 202, par l'intermédiaire de paquets RTCP (acronyme de Real Time Transport Control Protocol pour protocole de contrôle de transport temps réel), en mettant en oeuvre un algorithme TFRC (acronyme de TCP friendly rate contrôle pour contrôle de débit amical avec TCP). De plus, le serveur 201 est capable de retransmettre des paquets lorsqu'il reçoit un accusé de réception négatif NACK. Eventuellement, une source de données vidéo (non représentée), telle qu'une camera vidéo, peut être ajoutée, l'unité de calcul 203 effectuant alors aussi la compression des données vidéo provenant de cette source de données vidéo.

Le client 202 comporte une unité de calcul 206, une unité de stockage 207, une unité réseau 208 et une unité d'affichage 209. L'unité de calcul 206 effectue, d'une part, les calculs nécessaires au décodage des données reçues de la part du serveur 201, selon le codage vidéo utilisé et met en oeuvre les programmes conservés par l'unité de stockage 207, d'autre part.

L'unité de stockage 207 conserve, d'une part, un programme implémentant le procédé objet de la présente invention et, notamment les étapes illustrées en figure 3 et, d'autre part, des données vidéos reçues, avant et après traitement par l'unité de calcul 206. L'unité réseau 208 effectue, d'une part, la réception, depuis le réseau 210, des paquets comportant les données vidéo transmis par le serveur 201, et, d'autre part, l'émission de messages à destination du serveur 201, notamment des messages d'accusé de réception, positifs ACK ou négatifs, NACK . L'unité d'affichage 209 est adaptée à afficher les images qui lui sont fournies par l'unité de calcul 206. Les inventeurs ont déterminé que la durée de l'intervalle de temps entre les instants de transmission, et donc de réception lorsqu'aucun problème ne survient, de deux paquets successifs dépend du type de contenu et, notamment, du type de charge utile d'au moins un de ces paquets. En particulier, lorsque deux paquets successifs transportent des données de la même image, la durée entre arrivées de paquets successifs, ou PIAT ( packet inter arrivai time ) est généralement plus courte que la durée analogue pour des paquets successifs transportant des données de différentes images, ou tranches. En effet, lorsqu'une image comporte une quantité de données nécessitant sa fragmentation, les paquets résultants sont envoyés par trains (en anglais burst ) pour assurer leur arrivée la plus simultanée possible. En revanche, les paquets successifs transportant des données de différentes images, ou tranches, sont généralement émis au rythme des trames.

Dans le cas des codages H.264 et SVC, les données d'images fragmentées sont transportées dans des paquets de type FU. Les données d'images non fragmentées sont transportées dans des paquets de type STAP ou MTAP. La présente invention met en oeuvre cette particularité pour déterminer, côté client, quand il peut considérer qu'un paquet est perdu et demander sa retransmission et, côté serveur, combien de paquets doivent être retransmis. En ce qui concerne le premier mode de réalisation du procédé objet de la présente invention, implémenté côté client, comme illustré en figure 3, on commence par une étape 301, au cours de laquelle le client détermine si le dernier paquet reçu est de type FU . Si non, le client passe à une étape 304. Si oui, au cours d'une étape 302, le client détermine si ce dernier paquet reçu est le dernier d'un train ( burst ) de paquets FU, c'est-à-dire le dernier qui transporte des données d'image de la même image. L'étape 303 consiste à déterminer dans le deuxième octet de l'en-tête du paquet FU, si le drapeau E vaut 1 . Si oui, il s'agit du dernier paquet FU d'un train de paquets FU.

Si le résultat de l'étape 302 est positif, le client passe à l'étape 304. Sinon, au cours d'une étape 303, le client détermine que la durée normale I entre l'instant d'arrivée du dernier paquet reçu et l'instant d'arrivée du paquet suivant est une première durée prédéterminée Al. En revanche, au cours de l'étape 304, le client détermine que la durée normale I entre l'instant d'arrivée du dernier paquet reçu et l'instant d'arrivée du paquet suivant est une deuxième durée prédéterminée A2 supérieure à la première durée prédéterminée A1. A la suite de l'une des étapes 303 ou 304, au cours d'une étape 305, le client détermine si un nouveau paquet a été reçu. Si oui, le client effectue une étape 309 d'établissement de statistiques. Ces statistiques concernent, notamment, le délai écoulé entre la réception du premier paquet au cours de l'étape 301 et la réception du deuxième paquet, au cours de l'étape 305, lorsque les premiers paquets ont des charges utiles de type FU , d'une part, et lorsque les premiers paquets ont des charges utiles de type STAP ou MTAP , d'autre part. A partir de ces statistiques, les valeurs des première durée prédéterminée Al et deuxième durée prédéterminée A2 sont déterminées, par exemple pour qu'elles englobent le délai d'attente de 90 des deuxièmes paquets de chaque type déjà arrivés. On note que, lorsque le même deuxième paquet, dont la retransmission a été demandée par le client est reçu deux fois, les statistiques ne tiennent compte que de la durée séparant la réception du premier paquet et la première réception du deuxième paquet. On note aussi que, au cours de l'étape 309, le client établit, le cas échéant, les valeurs de paramètres pour le modèle mis en oeuvre par le serveur, lorsque le serveur implémente le deuxième mode de réalisation du procédé illustré en figure 4. A la suite de l'étape 309, le client retourne à l'étape 301, le nouveau paquet reçu étant alors considéré comme le dernier paquet reçu.

Si le résultat de l'étape 305 est négatif, au cours d'une étape 306, le client détermine si la durée i écoulée depuis la réception du dernier paquet est supérieure à la durée prédéterminée I à laquelle le client a ajouté une marge d'erreur prédéterminée E.

Si non, le client réitère l'étape 305. Si oui, au cours d'une étape 307, le client considère que le paquet attendu est perdu et émet, à destination du serveur, un accusé de réception négatif, ou NACK , identifiant, par son numéro séquentiel, le paquet attendu en incrémentant le numéro du dernier paquet reçu. Puis, au cours d'une étape 308, le client réinitialise à l'instant présent, l'instant à partir duquel on mesure la durée i et retourne à l'étape 301. On note que les valeurs des première et deuxième durées prédéterminées sont préférentiellement définies à partir des durées séparant la réception de deux paquets successifs constatées pour les paquets reçus, respectivement lorsque la charge utile du premier de ces deux paquets reçus successivement est de type FU et lorsque la charge utile du premier de ces deux paquets reçus successivement est de type STAP ou MTAP. Dans le deuxième mode de réalisation particulier du procédé objet de la présente invention, illustré en figure 4, on met en oeuvre une caractéristique d'un effet mémoire du processus de perte dans un réseau de paquets. On rappelle ici que l'effet mémoire du canal consiste en ce que si un paquet est perdu, pour chacun des paquets suivants, les risques de perte de paquet sont accrus. La longueur de la mémoire du canal caractérise la durée de l'influence de la perte d'un paquet sur les paquets suivants. En conséquence de cet effet mémoire, les pertes de paquets arrivent par groupes. Le deuxième mode de réalisation de la présente invention exploite cette connaissance pour améliorer la réactivité du processus de retransmission ARQ. Puisque les pertes surviennent par groupes, si le serveur est avisé d'une perte, il peut déterminer le risque qu'un ou plusieurs paquets suivants, dans leur ordre séquentiel, soient aussi perdus. De plus, les paquets de type FU étant transmis par trains, ils ont une probabilité d'être perdu conjointement (appelée probabilité conjointe ) plus élevée que les paquets de type STAP ou MTAP qui suivent le rythme des trames.

Dans le deuxième mode de réalisation illustré en figure 4, au cours d'une étape 401, le serveur reçoit d'abord un accusé de réception négatif, ou NACK . Puis, au cours d'une étape 402, le serveur détermine le type de charge utile du paquet identifié dans l'accusé de réception négatif reçu.

S'il s'agit d'un type de charge utile MTAP ou STAP, au cours d'une étape 405, le serveur effectue la retransmission du paquet perdu. Puis, au cours d'une étape 407, le serveur initialise la valeur d'une variable x à 2 . La variable x représente la longueur de la mémoire du canal de transmission. Puis, au cours d'une étape 409, on effectue une estimation de probabilité de perte conjointe du paquet perdu et des x-1 ièmes paquets suivants. Si le canal est modélisé par un modèle de Bernouilli, qui ne prend pas en compte d'effet mémoire, la probabilité conjointe de perdre x paquets consécutifs est donnée par la formule JLP(x) = Px où P est la probabilité de perte d'un paquet. Cependant, la mémoire du canal est mieux modélisée par le modèle connu sous le nom de Elliott-Gilbert qui est un modèle de Markov à deux états illustré en figure 5. Ce modèle met en oeuvre deux paramètres, p et q , p étant la probabilité de passer de l'état reçu à l'état perdu et q la probabilité de passer de l'état perdu à l'état reçu . En conséquence, 1-p est la probabilité de rester dans l'état reçu et 1-q la probabilité de rester dans l'état perdu . Selon ce modèle, la probabilité de perdre x paquets successifs est donnée par la formule JLP(x) = p(1-q)X-' Les valeurs de P, p et q sont calculées par le client (voir l'étape 309 de la figure 3) et transmis au serveur par des paquets propriétaires RTCP. On note, cependant, que, dans le cas présent, le client discrimine les événements survenant sur des paquets possédant une charge utile de type STAP ou MTAP, d'une part, des paquets possédant une charge utile de type FU, d'autre part. En conséquence, deux jeux de paramètres de modèle de perte sont transmis au serveur, l'un (PFU, PFU et qFu) pour les paquets à charge utile de type FU et l'autre (PAP, PAP et qAp) pour les paquets à charge utile de type STAP ou MTAP. Ces différents jeux de valeurs de paramètres permettent au serveur de calculer la probabilité conjointe de perdre des paquets successifs JPL 5 adaptée au type de charge utile des paquets mis en oeuvre. En conséquence, la probabilité JPL(x) est : - pour le modèle de Bernouilli JPL(x) = PFUtPApk où t et k sont, respectivement, le nombre de paquets FU et STAP ou MTAP, dans un jeu de x paquets consécutifs (t+k = x) 10 - pour le modèle de Elliott-Gilbert JPL(x) = pFUouAP (1-gFU)y (1-gAP)Z où y est le nombre de transitions entre les états FU perdu et FU perdu (en d'autre termes, le nombre de paquets consécutifs perdus dont la charge utile est de type FU), z est le nombre de transitions entre les états FU perdu et STAP ou MTAP perdu , STAP ou MTAP perdu et FU 15 perdu , et STAP ou MTAP perdu et STAP ou MTAP perdu (en d'autres termes, le nombres de pertes de paquets n'impliquant pas la perte de deux paquets consécutifs dont la charge utile est de type FU), toutes ces transitions étant représentées en figure 6, avec y+z=x-1. La sélection entre PFU et PAP dépend du paquet reconnu au cours de 20 l'étape 403. Par exemple, si le paquet perdu identifié est un paquet dont la charge utile est de type STAP et que ce paquet est suivi par deux paquets dont la charge utile est de type FU, la probabilité de perte conjointe est JPL(3) = PAP ( 1-qAP ) (1-qFU). A la suite de l'étape 409, au cours d'une étape 411, on détermine si 25 la valeur de probabilité conjointe est supérieure à une troisième valeur limite valeur3 qui correspond à une valeur limite au-delà de laquelle on considère que la retransmission conjointe des x paquets suivants le paquet perdu est efficace. Si le résultat de l'étape 411 est positif, au cours d'une étape 413, on 30 décide de retransmettre les x-1 paquets suivants le paquet perdu. Puis au cours d'une étape 415, on incrémente la valeur de x et on retourne à l'étape 409.

Si le résultat de l'étape 411 est négatif, on effectue la retransmission décidée précédemment et on retourne à l'étape 401. Si, au cours de l'étape 403, on détermine que le type de la charge utile du paquet perdu, on effectue des étapes 417 à 427 respectivement identiques aux étapes 405 à 415, mais mettant en oeuvre l'autre jeu de valeurs de paramètres, pour les calculs de probabilité, comme exposé ci-dessus. On observe, en figure 7, un mode de réalisation particulier du dispositif 700 objet de la présente invention, pouvant servir de serveur de données ou de client destinataire de données, et différents périphériques adaptés à implémenter la présente invention. Dans le mode de réalisation illustré en figure 7, le dispositif 700 est un micro-ordinateur de type connu connecté, par le biais d'une carte d'entrée 704, à un moyen 701 d'acquisition ou de stockage de données, par exemple vidéo. Le dispositif 700 comporte une interface de communication 718 15 reliée à un réseau 734 apte à transmettre des données, des requêtes et/ou messages d'accusé de réception. Le dispositif 700 comporte également un moyen de stockage 712, par exemple un disque dur, et un lecteur 714 de disquette 716. La disquette 716 et le moyen de stockage 712 peuvent contenir des données à encoder ou à 20 décoder, des données vidéo et un programme informatique adapté à implémenter le procédé objet de la présente invention. Selon une variante, le programme permettant au dispositif de mettre en oeuvre la présente invention est stocké en mémoire morte ROM (acronyme de read only memory pour mémoire non réinscriptible) 706. Selon une autre 25 variante, le programme est reçu par l'intermédiaire du réseau de communication 734 avant d'être stocké. Ce même dispositif 700 possède un écran 705 permettant de visualiser les données vidéo et servant d'interface avec l'utilisateur pour paramétrer certains modes d'exécution du dispositif 700, à l'aide d'un clavier 30 710 et/ou d'une souris par exemple. Une unité centrale CPU (acronyme de central processing unit ) 703 exécute les instructions du programme informatique et de programmes nécessaires à son fonctionnement, par exemple un système d'exploitation. Lors de la mise sous tension du dispositif 700, les programmes stockés dans une mémoire non volatile, par exemple la mémoire morte 706, le disque dur 712 ou la disquette 716, sont transférés dans une mémoire vive RAM (acronyme de random access memory pour mémoire à accès aléatoire) 708 qui contient alors le code exécutable du programme implémentant le procédé objet de la présente invention ainsi que des registres pour mémoriser les variables nécessaires à sa mise en oeuvre. Bien entendu, la disquette 716 peut être remplacée par tout support d'information amovible, tel que disque compact, clé ou carte mémoire. De manière plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé de codage objet de la présente invention. Un bus de communication 702 permet la communication entre les différents éléments inclus dans le dispositif 700 ou reliés à lui. La représentation, en figure 7, du bus 702 n'est pas limitative et notamment l'unité centrale 703 est susceptible de communiquer des instructions à tout élément du dispositif 700 directement ou par l'intermédiaire d'un autre élément du dispositif 700.

On observe, en figure 8, une étape 802, de réception d'un premier paquet par un client. Puis, au cours d'une étape 804, le client effectue une estimation d'une durée séparant la transmission du premier paquet et du paquet suivant, appelé, dans la description des étapes concernant le client deuxième paquet. Dans ce contexte client, la transmission concerne la réception des paquets. Dans des modes de réalisation, tels que celui illustré en figure 3, au cours de l'étape d'estimation de durée 804, le client estime la durée en estimant un type de contenu du deuxième paquet. En particulier, comme exposé en regard de la figure 3, le client peut estimer la durée en estimant un type de charge utile du deuxième paquet. Dans des variantes, le type de contenu concerne le type des données représentées par le paquet, par exemple des données liées au protocole de transmission sur le réseau, des données de texte, des données audio, vidéo ou image. Dans le cas illustré en figure 3, le client estime la durée en fonction d'une information relative au premier paquet. Plus précisément, dans le mode de réalisation illustré en figure 3, cette information est extraite du premier paquet et concerne, à la fois, le type de charge utile du premier paquet et, dans le cas où ce type de charge utile est FU , le fait que ce premier paquet soit, ou non, le dernier paquet d'un train de paquets relatifs à la même image ou à la même tranche, ou, ce qui revient au même, le fait que le premier et le deuxième paquets transportent, ou non, des données d'image de la même image ou la même tranche. Dans des variantes, l'information extraite du premier paquet est une information de type de contenu ou de charge utile du deuxième paquet. Dans ce dernier cas, il est prévu, dans au moins une partie des paquets, par exemple leur en-tête ou leur terminaison ( footer ), une information décrivant au moins le paquet suivant. Par exemple, cette information indique le nombre de paquets du train de paquets en cours de transmission duquel le deuxième paquet fait partie. Dans des modes de réalisation, le client estime la durée en fonction de résultats statistiques, par exemple, pour chaque type de charge utile du premier paquet, à partir des durées séparant la réception de deux paquets successifs constatées pour les paquets reçus, lorsque la charge utile du premier de ces deux paquets reçus successivement possède ledit type de charge utile.

Puis, au cours d'une étape 806, le client mesure la durée écoulée depuis la réception du premier paquet. Au cours d'une étape 808, le client effectue le déclenchement et/ou la définition d'une retransmission d'au moins un paquet, en fonction de la durée estimée et de la durée mesurée. Comme exposé en regard de la figure 3, lorsque la durée mesurée dépasse la durée estimée ajoutée à une marge d'erreur, le client requiert du serveur la retransmission du deuxième paquet. En variante, le client indique combien de paquets doivent être retransmis, notamment s'il connaît le nombre de paquet restant à recevoir pour un train de paquets. Par exemple, pour requérir cette transmission, le client émet, pour chaque paquet à retransmettre, un accusé de réception négatif NACK identifiant ce paquet. Au cours d'une étape 810, le serveur effectue la réception d'un premier paquet par un client. Puis, au cours d'une étape 812, le serveur effectue une estimation d'une durée séparant la transmission du paquet dont la retransmission est demandée par le client, appelé, dans la description des étapes concernant le serveur, premier paquet et la transmission du paquet suivant, appelé, dans la description des étapes concernant le serveur, deuxième paquet . Dans ce contexte serveur, la transmission concerne l'émission des paquets. Dans des modes de réalisation, tels que celui illustré en figure 4, au cours de l'étape d'estimation de durée 812, le serveur estime la durée en estimant un type de contenu du deuxième paquet. En particulier, comme exposé en regard de la figure 4, le client peut estimer la durée en estimant un type de charge utile d'au moins un des premier et deuxième paquets. Dans des variantes, le type de contenu concerne le type des données représentées par le paquet, par exemple des données liées au protocole de transmission sur le réseau, des données de texte, des données audio, vidéo ou image, le type de charge utile du paquet et, dans le cas où ce type de charge utile est FU , le fait que ce premier paquet soit, ou non, le dernier paquet d'un train de paquets relatifs à la même image ou, ce qui revient au même, le fait que le premier et le deuxième paquets transportent, ou non, des données d'image de la même image.

Dans des variantes, la durée est estimée en fonction d'une information de priorité du paquet. Puis, au cours d'une étape 814, le serveur effectue une étape de déclenchement et de définition de retransmission d'au moins un deuxième paquet, en fonction de la durée estimée. Dans le mode de réalisation illustré en figure 4, au cours de l'étape de déclenchement et de définition de retransmission d'au moins un desdits paquets, en fonction de ladite durée estimée, le serveur détermine une probabilité conjointe de perdre au moins un deuxième paquet à transmettre en fonction du type de charge utile du premier et des paquets suivants, sachant que le premier paquet a été perdu. Puis, en fonction de cette probabilité conjointe, le serveur détermine le nombre de paquets suivants à retransmettre avec le premier paquet.

Dans des variantes, cette probabilité est remplacée par une table de correspondance entre les types de paquets, par exemple définis par leur type de charges utile, leur contenu ou leur priorité, et le nombre de paquets suivants à retransmettre avec le premier paquet. En variante, applicable tant au mode de réalisation illustré en figure 4 qu'à celui illustré en figure 8, l'utilisation, par le serveur, de la réception d'une requête de retransmission de paquet, notamment d'un accusé de réception négatif NACK , est remplacé par une durée d'attente d'un accusé de réception. Ainsi, si le serveur ne reçoit pas d'accusé de réception dans un intervalle de temps d'une durée prédéterminée suivant l'émission d'un paquet, il considère que ce paquet a été perdu et effectue les étapes de retransmission du procédé objet de la présente invention.

Claims (10)

REVENDICATIONS

1 - Procédé de transmission de paquets de données (110 à 130) depuis un serveur (201) à destination d'au moins un client (202), caractérisé en ce qu'il comporte : - une étape (301 à 304, 403 à 409, 417 à 421, 804, 812) d'estimation d'une durée séparant la transmission d'un premier et d'un deuxième paquets successifs, en fonction d'une information relative au premier paquet et - une étape (306, 307, 411 à 415, 423 à 427, 806, 808, 812, 814) de déclenchement et de définition de retransmission du deuxième paquet, en fonction de ladite durée.

2 û Procédé selon la revendication 1, caractérisé en ce que l'information relative au premier paquet est représentative d'un type de contenu du deuxième paquet et, au cours de l'étape (302, 409, 421) d'estimation, on estime la durée séparant la transmission du premier et du deuxième paquets successifs, en fonction du type de contenu du deuxième paquet.

3 û Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que l'information relative au premier paquet est représentative d'un type de contenu du premier paquet et, au cours de l'étape (301, 403) d'estimation, on estime la durée séparant la transmission du premier et du deuxième paquets successifs, en fonction du type de contenu du premier paquet.

4 û Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, au cours de l'étape (301 à 304, 403 à 409, 417 à 421, 804, 812) d'estimation de durée, on estime ladite durée en fonction du fait que le premier et le deuxième paquets transportent, ou non, des données d'image de la même image.

5 û Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lesdites données (110 à 130) sont des données vidéo et l'information relative au premier paquet représente la fragmentation entre aumoins le premier et le deuxième paquets de données vidéo correspondants à un même instant temporel.

6 ù Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, au cours de l'étape (301 à 304, 804) d'estimation de durée, le client (202) estime ladite durée en fonction du type du premier paquet et de résultats statistiques concernant la durée séparant la réception du premier et du deuxième paquets en fonction du type de contenu du premier paquet.

7 ù Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, au cours de l'étape (301 à 304, 804) d'estimation de durée, le client (202) estime ladite durée pour les paquets possédant chaque type de charge utile, à partir des durées séparant la réception de deux paquets successifs constatées pour les paquets reçus, lorsque la charge utile du premier de ces deux paquets reçus successivement possède ledit type de charge utile.

8 ù Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, au cours de l'étape (301 à 304, 804) d'estimation de durée, le client (202) estime ladite durée en fonction du rang du premier paquet dans un train de paquets possédant le même type de charge utile.

9 ù Procédé selon l'une quelconque des revendications 6 à 8, caractérisé en ce que, au cours de l'étape (307, 808) de déclenchement et de définition de retransmission d'au moins un desdits paquets, en fonction de ladite durée estimée, le client (202) mesure la durée écoulée depuis la réception du premier paquet et émet, à destination du serveur (201), un message de demande de retransmission du deuxième paquet, si le deuxième paquet n'est pas encore reçu, en fonction d'une comparaison (306) entre ladite durée écoulée et ladite durée estimée.

10 ù Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, au cours de l'étape (403 à 409, 417 à 421, 812) d'estimation de durée, le serveur (201) estime ladite durée en fonction du type de charge utile d'un premier paquet à retransmettre et d'au moins un deuxième paquet suivant ledit premier paquet à retransmettre.11 ù Procédé selon la revendication 10, caractérisé en ce que, au cours de l'étape (411 à 415, 423 à 427) de déclenchement et de définition de retransmission d'au moins un desdits paquets, en fonction de ladite durée estimée, le serveur (201) détermine une probabilité de perdre au moins un deuxième paquet à transmettre en fonction de son type de charge utile, sachant que le premier paquet a été perdu. 12 ù Procédé selon l'une quelconque des revendications 10 ou 11, caractérisé en ce que, au cours de l'étape (411 à 415, 423 à 427) de déclenchement et de définition de retransmission d'au moins un desdits paquets, en fonction de ladite durée, le serveur (201) détermine une probabilité de perdre au moins un deuxième paquet à transmettre en fonction du type de charge utile du premier paquet à retransmettre, sachant que le premier paquet a été perdu. 13 ù Procédé selon l'une quelconque des revendications 10 à 12, caractérisé en ce que ladite probabilité tient compte d'un modèle de perte. 14 ù Procédé selon la revendication 13, caractérisé en ce que ledit modèle de perte tient compte d'un effet de mémoire du canal de transmission entre ledit serveur et ledit client. 15 ù Procédé selon l'une quelconque des revendications 13 ou 14, caractérisé en ce que ledit modèle de perte tient compte de valeurs de paramètres différentes pour les paquets possédant différents types de charge utile. 16 ù Procédé selon la revendication 15, caractérisé en ce que lesdites valeurs de paramètres sont déterminées en fonction de données 25 transmises par le client (202). 17 ù Procédé selon l'une quelconque des revendications 10 à 16, caractérisé en ce que, au cours de l'étape (411 à 415, 423 à 427) de déclenchement et de définition de retransmission, le serveur (201) détermine un nombre de paquets à transmettre avec le premier paquet à retransmettre en 30 fonction de leur probabilité de perte conjointe.18 -Dispositif de transmission de paquets de données (110 à 130) depuis un serveur (202) à destination d'au moins un client (201), caractérisé en ce qu'il comporte : - un moyen (203, 206, 703, 708) d'estimation d'une durée séparant la transmission d'un premier et d'un deuxième paquets successifs, en fonction d'une information relative au premier paquet et - un moyen (203, 205, 206, 208, 703, 708) de déclenchement et de définition de retransmission du deuxième paquet, en fonction de ladite durée. 19 û Dispositif selon la revendication 18, caractérisé en ce que le moyen (203, 703, 708) de déclenchement et de définition de retransmission est incorporé au client (202), et en ce que ledit dispositif comporte : - un moyen (206, 703, 708) de mesure de la durée écoulée depuis la réception du premier paquet ; - un moyen (206, 703, 708) de comparaison de la durée mesurée et d'une valeur représentative de la durée estimée ; et - un moyen (208, 718) d'émission, à destination du serveur (201), d'un message de demande de retransmission du deuxième paquet en fonction du résultat fournit par le moyen de comparaison, si le deuxième paquet n'est pas encore reçu. 20 - Dispositif selon la revendication 18, caractérisé en ce que le moyen (203, 703, 708) d'estimation de durée est incorporé au serveur (201), et en ce que ledit dispositif comporte : - un moyen (203, 703, 708) de détermination d'une probabilité de perdre le deuxième paquet sachant que le premier paquet a été perdu, dite probabilité conjointe de perte, en fonction de la durée estimée ; et - un moyen (208, 718) de retransmission au client (202) du deuxième paquet en fonction de la probabilité conjointe de perte déterminée. 21 - Programme d'ordinateur chargeable dans un système informatique (700), ledit programme contenant des instructions permettant la mise en oeuvre du procédé de transmission selon l'une quelconque des revendications 1 à 17.22 - Support d'informations (706, 712) lisibles par un ordinateur (700) ou un microprocesseur (703), amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé de transmission selon l'une quelconque des revendications 1 à 17.