FR 2922391 A1 20090417 FR 0758316 A 20071015 La présente invention concerne un procédé et un dispositif de transmission de données. Elle s'intéresse, en particulier, à un ordonnancement de paquets de données vidéo adapté au mécanisme de contrôle congestion. Encore plus particulièrement, la présente invention trouve une application dans une application client/serveur de transmission vidéo sur un réseau de paquets non fiable dont la bande passante varie dans le temps, pour pallier les limites d'un mécanisme de contrôle de congestion. On décrit, ci-dessous, brièvement, un principe de contrôle de congestion. Les réseaux ayant une bande passante limitée et étant partagés par plusieurs applications aux comportements difficilement prévisibles, il est nécessaire de contrôler le débit de ces applications. En effet, sans contrôle, le réseau subirait continuellement des phénomènes de congestion provoquant des pertes de données. Ces méthodes de contrôle sont en générale appelées � méthode de régulation ou de contrôle de débit � ou méthode de � contrôle de congestion �. Elles permettent, à chaque source, de transmettre des données avec un débit compatible avec les capacités du réseau à un instant donné. La plupart des applications de transmission sur réseaux sont régies pas le protocole TCP (acronyme de � Transmission Control Protocol � pour � protocole de contrôle de transmissions �). Ce protocole utilise un algorithme de contrôle de congestion appelé AIMD (acronyme de � Additive Increase, Multiplicative Decrease � pour accroissement additionnel, décroissance multiplicative). Cet algorithme consiste à accroître lentement le débit de transmission tant qu'aucune perte de paquet ne se produit. Dès qu'une perte est constatée par la source, le débit de celle-ci est divisé par deux. Cet algorithme permet un partage des ressources réseau. Toutefois, le protocole TCP a été défini essentiellement pour des applications de transfert de fichiers non contraintes par le temps. De plus, l'algorithme de contrôle de congestion de TCP occasionne des variations de débit qui ne sont pas compatibles avec des applications demandant une qualité de service constante ou variant lentement dans le temps. Ce protocole n'est donc pas adapté au transfert de vidéos. Pour ce type d'applications on a donc cherché des algorithmes de contrôle de congestion différents mais devant être compatibles avec le protocole TCP. En effet, il s'agissait de continuer à partager les bandes passantes disponibles sur les réseaux de manière équitable, comme le ferait le protocole TCP mais sans les inconvénients identifiés de ce protocole TCP. Même si certaines applications contraintes par le temps ont continué à utiliser des versions plus ou moins modifiées d'AIMD, d'autres plus exigeantes ont utilisé d'autres protocoles, tels que �TFRC � (acronyme de � TCP-Friendly Rate Control � pour contrôle de débit TCP-compatible). TFRC est un algorithme de contrôle de congestion adapté aux applications vidéo. Il assure un partage équitable de la bande passante disponible entre les applications TCP et les applications vidéo. Cet algorithme est basé sur l'équation suivante pour estimer la bande passante disponible sur le réseau: Rx. j2xbxp/3 +(tRTO x3x. j3xbxp/8 xpx(1+32x p2)) équation dans laquelle : - X est l'estimation de la bande passante disponible sur le réseau, - R est le temps d'aller/retour des paquets sur le réseau, ou 20 � RTT � (acronyme de � Round Trip Time �), - b est le nombre de paquets acquittés par un accusé de réception de TCP, -p est le taux d'événement de perte sur le réseau et - tRTO est le délai d'attente avant retransmission. 25 Un événement de perte est une série de pertes de paquets consécutives. Dans l'article "Optimal Scheduling for Streaming of Scalable Media", Z. Miao, A. Ortega, Proc. of Asilomar Conf. on Signais, Systems and Computers, Pacific Grove, CA, Oct-Nov. 2000, les auteurs proposent une 30 méthode d'ordonnancement de paquets, chaque paquet transportant une image dans un niveau de scalabilité donné. Cette méthode est basée sur une X= S évaluation relativement complexe de l'importance de chaque paquet en fonction de la distorsion induite par les images transportés, les dépendances entre les images, les contraintes de délais de réception des images, le taux d'erreurs sur le canal, le RTT, le débit disponible sur le réseau, etc. L'ordre de transmission des paquets est ensuite déterminé en fonction de leur importance. Toutefois, cette méthode considère la valeur de débit estimée par son algorithme de contrôle de débit comme fiable. Or, si on prend l'exemple de TFRC et AIMD, ces algorithmes ne sont pas totalement fiables. En effet, l'évaluation du débit s'appuie sur la détection de pertes sur le réseau. Si aucune perte ne se produit, ces algorithmes ont tendance à augmenter le débit de la source en considérant que l'absence de détection de pertes implique une libération de bande passante sur le réseau. Or cette absence de détection de pertes peut être la conséquence de deux situations. Dans une première situation, elle peut, en effet, signifier que de la bande passante s'est libérée sur le réseau et que cette bande passante disponible peut être utilisée. Dans une autre situation, une source transmet à un débit très proche du débit disponible sur le réseau, le taux de pertes est quasi nul et aucune congestion ne se produit. Toutefois, toute augmentation de débit supplémentaire provoquerait des pertes de paquets. Etant incapables de différentier ces deux situations, les algorithmes de contrôle de congestion surévaluent le débit restant disponible et le risque de perte à venir augmente. Il semble intéressant d'éviter la transmission de données importantes durant ces périodes risquées. Le document US 2003/231,589 propose une solution basée sur la distinction entre débit utile et débit global de la source. Le débit utile est ici le débit d'une source vidéo seul. Cette source est suivie d'un module de génération de redondance sous la forme de FEC (acronyme de � Forward Error Correction � pour correction adaptative d'erreurs sans voie de retour). La combinaison du débit de la source et de la redondance constitue le débit global. Un algorithme de contrôle de congestion remet à jour le débit global avec une période P1 alors que le débit utile n'est remis à jour qu'avec une période P2 supérieure à P1. Le débit de la redondance est donc ajusté à la valeur de la différence entre le débit utile et le débit global. Cette solution permet de ne pas augmenter directement le débit de la source à chaque augmentation du débit global. Toutefois, ce système n'est pas adaptatif. Les périodes P1 et P2 sont constantes, ce qui nuit à la réactivité du système. De plus, cette méthode n'est mise en oeuvre qu'en cas d'augmentation de débit et n'apporte pas de solution en cas de réduction du débit. Enfin, cette méthode a pour objectif d'éviter les variations rapides de la qualité de la vidéo. La présente invention vise à remédier à ces inconvénients. Elle vise notamment à améliorer le fonctionnement de l'algorithme de contrôle de congestion mis en oeuvre par le serveur pour améliorer la qualité perçue par l'utilisateur. Elle vise aussi à fournir un mécanisme simple à implémenter qui peut se rajouter aux mécanismes de contrôle de congestion existants pour les améliorer et rapide pour des applications temps réel. On observe que le client est de type connu dans l'art antérieur. A cet effet, selon un premier aspect, la présente invention vise un procédé de transmission de paquets de données sur un réseau, chaque paquet de données étant associé à un niveau d'importance parmi au moins deux niveaux d'importance, comportant une étape d'estimation de débit disponible sur le réseau, caractérisé en ce qu'il comporte une étape de détection d'une variation de débit disponible estimé et, en cas de détection d'une variation de débit disponible estimé supérieure à une première valeur prédéterminée : - une étape de détection d'une augmentation du temps d'aller-retour sur ledit réseau supérieure à une deuxième valeur prédéterminée et - en cas de détection d'une augmentation du temps d'aller-retour, une étape de transmission de paquets de données à un débit inférieur au débit disponible estimé. Ainsi, lors d'une variation de débit disponible sur le réseau, on caractérise cette variation en analysant le temps d'aller/retour et, selon le résultat de cette analyse, on ajuste le débit de paquets de données. Ce débit est ainsi fonction du risque encouru estimé lors de l'envoi des paquets de données. On observe que, dans des modes de réalisation particuliers, l'invention est mise en oeuvre dans un module qui se positionne en aval du contrôle de débit. Ce module prend donc comme entrée la consigne de débit calculée selon l'algorithme de contrôle de débit, sans que cet algorithme n'ait été modifié. Cette invention permet ainsi d'améliorer le fonctionnement du contrôle de congestion sans modifier l'algorithme de contrôle de congestion mais en considérant les limites et les imperfections de celui-ci. Selon des caractéristiques particulières, en cas de détection d'une variation de débit disponible estimé supérieure à une première valeur prédéterminée et avant l'étape de détection d'une augmentation du temps d'aller-retour, on effectue une étape de transmission de paquets de niveau d'importance inférieur à la moyenne des dits niveaux d'importance. Ainsi, en cas de perte de paquets lors des étapes de détection, ce sont des paquets moins importants qui sont perdus. Selon des caractéristiques particulières, au cours de l'étape de transmission de paquets de niveau d'importance inférieur au niveau d'importance moyen, on met en oeuvre le débit disponible estimé courant. Ainsi, si le risque de perte n'est pas confirmé par la deuxième étape de détection, qui concerne le délai d'aller-retour, c'est le débit disponible estimé qui a été mis en oeuvre et on n'a donc pas perdu de temps dans l'attente de cette confirmation. Selon des caractéristiques particulières, au cours de l'étape de détection d'une augmentation du temps d'aller-retour, on détermine le temps d'aller/retour sur l'envoi de paquets transmis au cours de l'étape de transmission de paquets de niveau d'importance inférieur. Le temps d'aller-retour est ainsi analysé sur des paquets de données transmis avec le nouveau débit ayant suivi la variation de débit. Selon des caractéristiques particulières, au cours de l'étape de transmission de paquets de données à un débit inférieur au débit disponible estimé, si la variation de débit disponible estimé est un accroissement, on met en oeuvre le débit disponible estimé précédant l'étape de détection de la variation de débit disponible estimé. Selon des caractéristiques particulières, au cours de l'étape de transmission de paquets de données à un débit inférieur au débit disponible estimé, si la variation de débit disponible estimé est une diminution, on met en oeuvre une fraction du débit disponible estimé courant. Selon des caractéristiques particulières, au cours de l'étape de transmission de paquets de données à un débit inférieur au débit disponible estimé, on met en oeuvre une partie du débit disponible estimé courant pour transmettre des paquets de données et une partie du débit estimé courant pour transmettre des paquets de données redondantes. Selon des caractéristiques particulières, les données redondances sont des données de FEC (acronyme de � forward Error Correction � pour correction adaptative d'erreurs sans voie de retour). Grâce à chacune de ces dispositions, les paquets de données utiles sont mieux protégés contre les erreurs survenant en cas de perte. Selon des caractéristiques particulières, le procédé objet de la présente invention, tel que succinctement exposé ci-dessus comporte une étape de contrôle de congestion mettant en oeuvre le protocole TFRC (acronyme de � TCP-Friendly Rate Control � pour contrôle de débit TCP-compatible) pour fournir ladite estimation de débit disponible. La mise en oeuvre de la présente invention est particulièrement adaptée à contrer les défauts de TFRC. Selon un deuxième aspect, la présente invention vise un dispositif de transmission de paquets de données sur un réseau, chaque paquet de données étant associé à un niveau d'importance parmi au moins deux niveaux d'importance, comportant un moyen d'estimation de débit disponible sur le réseau, caractérisé en ce qu'il comporte un moyen de détection d'une variation de débit disponible estimé supérieure à une première valeur prédéterminée et un moyen de transmission adapté, en cas de détection d'une variation de débit disponible estimé : - à détecter une augmentation du temps d'aller-retour supérieure à une deuxième valeur prédéterminée sur ledit réseau et - en cas de détection d'une augmentation du temps d'aller-retour, à transmettre des paquets de données à un débit inférieur au débit disponible estimé. Selon un troisième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé 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é objet de la présente invention tel que succinctement exposé ci-dessus. Les avantages, buts et caractéristiques de ce dispositif, de ce programme d'ordinateur et de ce support d'information étant similaires à ceux du procédé, tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques particulières 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, schématiquement, des systèmes mis en oeuvre pour la transmission de données, - la figure 2 représente, schématiquement, des étapes mises en oeuvre pour la transmission de données, - la figure 3 représente, sous forme d'un logigramme, des étapes 25 mises en oeuvre 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 dans un deuxième mode de réalisation du procédé objet de la présente invention et 30 - la figure 5 représente, schématiquement, un mode de réalisation particulier du dispositif objet de la présente invention. Comme illustré en figure 1, un système de transmission vidéo mettant en oeuvre le procédé objet de la présente invention est constitué d'un serveur 101 et d'un client 102. Le serveur 101 est constitué d'une unité de stockage 104 contenant des vidéos préalablement compressées et des programmes d'ordinateur mis en oeuvre par le serveur 101, d'une unité de calcul 103 mettant en oeuvre ces programmes et d'une unité réseau 105 chargée de transmettre les données vidéo sur le réseau 120 , de type connu. Une unité d'acquisition (non représentée) pourrait être insérée dans le serveur 101. Dans ce cas, l'unité de calcul 103 mettrait en oeuvre un programme d'ordinateur de compression de vidéo, ce programme étant stocké sur l'unité de stockage 104. Le client 102 est constitué d'une unité de stockage 106 stockant les programmes mis en oeuvre par le client, dont un programme de décompression des données vidéo, d'une unité de calcul 110 mettant en oeuvre ces programmes, d'une unité réseau 108 permettant la réception des données vidéos et d'une unité d'affichage 109 telle qu'un écran permettant de visualiser la vidéo reçue. Le serveur 101 transmet les données sur le réseau de paquets 120. Dans ce mode de réalisation, on utilise le protocole de niveau application RTP/RTCP (acronyme de � Real-time Transport Protocol/Real-time Transport Control Protocol � pour protocole de transport temps-réel/protocole de contrôle de transport temps réel) pour transmettre les données depuis le serveur 101vers le client 102, mais aussi pour transmettre des rapports de transmission du client 102 vers le serveur 101. Comme on l'observe en figure 2, la transmission de paquets 25 comporte une étape 201 d'estimation de la bande passante disponible de TFRC basé sur l'équation Rx. j2xbxp/3 +(tRTO x3x. j3xbxp/8 xpx(1+32x p2)) détaillée ci-dessus. Comme exposé ci-dessus, l'utilisation de cette équation nécessite la connaissance d'informations telles que le taux 30 d'évènement de pertes (p), le RTT (R), le nombre de paquets acquittés par un accusé de réception de TCP (b), et le délai d'attente avant retransmission X= S (tRTO ). b est une constante du réseau. tRTO est approximé par 4xR. On suppose ici que le client 102 insère, dans les rapports RTCP, des informations représentatives du taux d'évènement de pertes courant (p). Cette fonctionnalité n'est rendue possible qu'avec l'utilisation de rapports RTCP dédiés mais de type connu (voir, par exemple, le document � Extended RTP Profile for Realtime Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF). RFC4585. http://www.rfc-editor.org/rfc/rfc4585.txt �) Le RTT est calculé en insérant, dans les rapports RTCP, le temps passé entre l'arrivée d'un paquet et le départ de l'acquittement correspondant à ce paquet. De cette manière, le serveur 101, connaissant l'instant de départ d'un paquet et l'instant d'arrivée de son acquittement peut calculer le RTT. En injectant l'ensemble de ces informations dans l'équation Rx. j2xbxp/3 +(tRTO x3x. j3xbxp/8 xpx(1+32x p2)) le serveur 101 obtient une estimation du débit disponible sur le réseau appelée 15 � débit disponible estimé courant � Puis, au cours d'une étape 203, les données vidéo sont générées. Ces données peuvent être générées de deux manières. La première consiste à les extraire d'un fichier vidéo existant. Cette solution est particulièrement avantageuse dans le cas d'une vidéo compressée avec un codeur vidéo 20 scalable. On peut en effet extraire du train binaire d'une vidéo scalable une portion correspondant au débit disponible estimé courant. La seconde solution consiste à compresser la vidéo, celle-ci pouvant être générée par une unité d'acquisition vidéo. La régulation du débit des paquets de données de la vidéo pour le faire correspondre au débit disponible estimé courant est alors réalisée 25 durant sa compression. Cette étape est suivie, de manière optionnelle, d'une étape 205 de génération de redondances sous forme de FEC ou données de correction d'erreurs par anticipation. Une méthode simple de génération de FEC consiste à appliquer un encodeur de Reed-Solomon systématique aux données vidéo afin de générer des données redondantes. On décrit plus loin, 30 en regard de la figure 4, comment, dans des modes de réalisation du procédé objet de la présente invention, le débit des données redondantes est régulé. X= S Puis, au cours d'une étape 207, on insère les données générées dans des paquets RTP. On note que les données vidéo et les données de redondance FEC sont transportées dans des paquets différents. Ces paquets sont, ensuite, transmis sur le réseau 120, lors d'une étape 209 au cours de laquelle on met en oeuvre le procédé objet de la présente invention. Comme illustré en figure 3, la mise en oeuvre d'un premier mode de réalisation du procédé objet de la présente invention dans laquelle on suppose que ces paquets sont d'importances inégales, l'importance d'un paquet étant fonction de son contenu, comme exposé ci-dessus. Par exemple, dans le cas de la transmission d'une vidéo non scalable telle qu'une vidéo selon le standard H.264, les paquets transportant des images INTRA sont considérés comme plus importants que des paquets transportant des images prédites. De la même manière, des paquets transportant des images prédites constituées d'un grand nombre de macroblocs INTRA sont considérées comme plus importants que des paquets transportant des images prédites constituées de peu de macroblocs INTRA. En effet les images et les macroblocs INTRA sont importants car ils sont capables de resynchroniser une séquence vidéo compressée en cas de pertes de paquets. Selon un autre exemple, dans le cas d'une transmission d'une vidéo scalable utilisant par exemple le format SVC, on peut transmettre une vidéo constituée de plusieurs niveaux de scalabilité dont un niveau de base et au moins un niveau d'amélioration. Un paquet transportant des données du niveau de base est considéré comme plus important. En effet, dans la scalabilité SVC, beaucoup de données des niveaux d'amélioration font référence, directement ou indirectement, au niveau de base. De plus, le niveau de base est important car il permet à l'utilisateur de recevoir au moins la qualité minimale de la séquence vidéo. Les données des niveaux d'amélioration sont considérées comme moins importantes. Par exemple, les niveaux d'importance des données sont décroissants en fonction du niveau d'amélioration auquel elles appartiennent. Selon un autre exemple, comme exposé ci-dessus, on met en oeuvre une évaluation plus complexe de l'importance de chaque paquet en fonction de la distorsion induite par les images transportées, des dépendances entre les images, des contraintes de délais de réception des images et/ou du taux d'erreurs sur le canal. Dans toute la description, on ne considère que deux niveaux d'importance. Cependant, l'homme du métier saura aisément adapter l'enseignement de la présente invention à un nombre de niveaux d'importance supérieur. Par exemple, un niveau d'importance moyen permettant de différencier les paquets de données considérés comme les plus ou les moins importants permet de revenir aux modes de réalisation présenté ici. Alternativement, la mise en oeuvre d'une pluralité de valeurs de seuils en remplacement de chacune des valeurs de seuil mentionnées ci-dessous, permet de gérer plus de deux niveaux d'importance. Dans le premier mode de réalisation, le procédé objet de la présente invention débute par une étape 301 au cours de laquelle on procède à l'estimation du débit disponible sur le réseau, estimation notée � D,�. Puis, au cours d'une étape 305, on détermine si la valeur absolue de la différence entre ce débit disponible estimé courant D, et la valeur précédente de ce débit est supérieure à une première valeur de seuil do, prédéterminée empiriquement. Sinon, on considère que le débit est stable et on transmet les paquets contenant les données sur le réseau, au débit Dc, au cours d'une étape 311. L'étape 311 est suivie d'un retour à l'étape 301 pour une nouvelle évaluation du débit. Si le résultat de l'étape 305 est positif, c'est-à-dire si la variation de débit disponible estimé est importante, au cours d'une étape 307, on traite un 25 ensemble de paquets à transmettre. L'importance des paquets étant définie comme exposé plus haut, on transmet au débit Dc, dans un premier temps, les paquets de plus faible importance. En effet, la constatation que la variation de débit est importante est un indice d'entrée dans une phase d'incertitude sur l'estimation du débit, aussi 30 appelé � période risquée �. Ce type d'ordonnancement des paquets présente deux avantages. Le premier est de transmettre des paquets dont l'éventuelle perte aurait un faible impact visuel pendant les périodes où le taux de perte est susceptible d'augmenter. Le second est que la transmission de ces paquets permet de mesurer l'évolution de l'état du réseau au cours d'une étape 313. Au cours d'une étape 309, on attend la réception, de la part du client, d'un accusé de réception correspondant à au moins un paquet de faible importance transmis au cours de l'étape 307. Cet accusé de réception permet au serveur d'évaluer le temps d'aller-retour courant, ou � RTTC �, au cours de l'étape 313. Au cours d'une étape 317, on détermine si la différence entre la valeur de RTTC et la valeur précédente de RTT, notée RTTpre, est supérieure à une deuxième valeur de seuil prédéterminée, notée ARTT• Sinon, au cours d'une étape 311, on poursuit la transmission de l'ensemble des paquets au débit Dc, indépendamment de leur importance. Si oui, cela signifie que le temps RTT a augmenté anormalement, ce qui est un nouvel indice que les files d'attentes dans les routeurs du réseau sont en cours de saturation. Dans ce cas, si la transmission se poursuivait à ce débit Dc, une congestion pourrait apparaître et entraîner des pertes de paquets. Puis, au cours d'une étape 319, on détermine si le débit courant D, est supérieur au débit précédent Dpre. Si oui, au cours d'une étape 321, on arrête la transmission au débit D, estimé lors de l'étape 301 pour revenir au débit précédent. On revient ainsi à un débit qui n'avait pas provoqué de congestion précédemment. Si D, est inférieur à Dpre, on détermine une fraction de la valeur du débit estimé courant, par exemple, on divise par deux la valeur du débit courant, au cours d'une étape 323. Cette étape 323 revient à estimer que la baisse de débit de l'étape 301 n'est pas suffisante pour éviter une congestion. On amplifie donc cette baisse. Lors de l'étape 325 les paquets sont transmis au débit déterminé au cours de l'une des étapes 321 ou 323, indépendamment de leur importance, et on retourne à l'étape 301 pour une nouvelle estimation du débit D,. On observe que, dans les deux cas des étapes 321 et 323, on a remis en cause l'estimation de débit de l'algorithme de contrôle de congestion. La mise en oeuvre de la présente invention permet ainsi d'accroître la réactivité du système. C'est d'autant plus vrai avec l'algorithme de contrôle de congestion TFRC, dans lequel les estimations de débit ne sont pas seulement le résultat de l'équation Rx. j2xbxp/3 +(tRTO x3x. j3xbxp/8 xpx(1+32x p2)) mais aussi d'une moyenne pondérée prenant en compte des mesures passées. De plus, on a évité de transmettre des paquets importants durant les périodes risquées. La figure 4 concerne un deuxième mode de réalisation de la présente invention, avec mise en oeuvre de FEC. Les inventeurs ayant constaté que le non respect, par une source du débit estimé par TFRC, pouvait provoquer des phénomènes d'oscillation dans l'estimation de ce débit, les fortes variations du débit se concrétisant alors par de fortes variations de la qualité, ils ont réalisé le deuxième mode de réalisation illustré en figure 4. La figure 4 reprend les étapes 301 à 319 de la figure 3. Si le résultat de l'étape 319 est positif, c'est-à-dire si D, > Dpre, au cours d'une étape 421, le débit Dtrans correspondant au débit de transmission des données vidéos prend la valeur Dpre. En revanche, si le résultat de l'étape 319 est négatif, c'est-à- dire si D, REVENDICATIONS 1. Procédé de transmission de paquets de données sur un réseau, chaque paquet de données étant associé à un niveau d'importance parmi au moins deux niveaux d'importance, comportant une étape d'estimation de débit disponible sur le réseau (513), caractérisé en ce qu'il comporte une étape (305) de détection d'une variation de débit disponible estimé et, en cas de détection d'une variation de débit disponible estimé supérieure à une première valeur prédéterminée : - une étape (309-317) de détection d'une augmentation du temps d'aller-retour sur ledit réseau supérieure à une deuxième valeur prédéterminée et - en cas de détection d'une augmentation du temps d'aller-retour, une étape (319-325, 421-427) de transmission de paquets de données à un débit inférieur au débit disponible estimé. 2. Procédé selon la revendication 1, caractérisé en ce que, en cas de détection d'une variation de débit disponible estimé supérieure à une première valeur prédéterminée et avant l'étape (309-317) de détection d'une augmentation du temps d'aller-retour, on effectue une étape (307) de transmission de paquets de niveau d'importance inférieur à la moyenne des dits niveaux d'importance. 3. Procédé selon la revendication 2, caractérisé en ce que, au cours de l'étape (307) de transmission de paquets de niveau d'importance inférieur au niveau d'importance moyen, on met en oeuvre le débit disponible estimé courant. 4. Procédé selon l'une quelconque des revendications 2 ou 3, caractérisé en ce que, au cours de l'étape (309-317) de détection d'une augmentation du temps d'aller-retour, on détermine le temps d'aller/retour sur l'envoi de paquets transmis au cours de l'étape (307) de transmission de paquets de niveau d'importance inférieur. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, au cours de l'étape (319-325, 421-427) de transmission de paquets de données à un débit inférieur au débit disponible estimé, si la variation de débit disponible estimé est un accroissement, on met en oeuvre le débit disponible estimé précédant l'étape de détection de la variation de débit disponible estimé. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, au cours de l'étape (319-325, 421-427) de transmission de paquets de données à un débit inférieur au débit disponible estimé, si la variation de débit disponible estimé est une diminution, on met en oeuvre une fraction du débit disponible estimé courant. 7. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, au cours de l'étape (421-427) de transmission de paquets de données à un débit inférieur au débit disponible estimé, on met en oeuvre une partie du débit disponible estimé courant pour transmettre des paquets de données et une partie du débit estimé courant pour transmettre des paquets de données redondantes. 8. Procédé selon la revendication 7, caractérisé en ce que les données redondances sont des données de FEC (acronyme de � forward Error Correction � pour correction adaptative d'erreurs sans voie de retour). 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comporte une étape de contrôle de congestion mettant en oeuvre le protocole TFRC (acronyme de � TCP-Friendly Rate Control � pour contrôle de débit TCP-compatible) pour fournir ladite estimation de débit disponible. 10. Dispositif (520) de transmission de paquets de données sur un réseau (513), chaque paquet de données étant associé à un niveau d'importance parmi au moins deux niveaux d'importance, comportant un moyen (500-503) d'estimation de débit disponible sur le réseau, caractérisé en ce qu'il comporte un moyen (500, 503) de détection d'une variation de débit disponible estimé supérieure à une première valeurprédéterminée et un moyen (500-503, 512) de transmission adapté, en cas de détection d'une variation de débit disponible estimé : - à détecter une augmentation du temps d'aller-retour supérieure à une deuxième valeur prédéterminée sur ledit réseau et - en cas de détection d'une augmentation du temps d'aller-retour, à transmettre des paquets de données à un débit inférieur au débit disponible estimé. 11. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 9. 12. 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é selon l'une quelconque des revendications 1 à 9.