Brevet FR2916600A1 — publié le 20081128

La présente invention se rapporte à un procédé de transmission de données entre un serveur et au moins un client dans un réseau de communication, ainsi qu'à un serveur mettant en oeuvre un tel procédé. Elle appartient au domaine de la transmission de données multimédia, notamment audio et/ou vidéo, dans un réseau de communication tel qu'un réseau IP ("Internet Protocot'). Elle s'applique en particulier à l'ordonnancement des paquets de données d'un flux de données transmis d'un dispositif émetteur, tel qu'un serveur, à un dispositif récepteur, tel qu'un client. Un exemple non limitatif d'application de l'invention concerne la transmission d'une vidéo en direct (en anglais "live") à partir d'une caméra vers un ou plusieurs clients qui, simultanément, affichent la vidéo avec un temps de retard (désigné dans toute la suite par le terme "latence") très faible (typiquement, quelques dizaines de millisecondes) et enregistrent le flux vidéo pour permettre sa visualisation ultérieure. Une telle situation survient par exemple dans le cas d'une petite caméra de vidéosurveillance numérique ou de visioconférence reliée à un réseau de communication. Les images sont codées dans un format de compression numérique, puis mémorisées localement dans une mémoire tampon ayant une capacité très limitée avant d'être transmises sur un réseau de communication de données vers un ou plusieurs clients. La vidéo peut être codée conformément à une des normes décrites dans les recommandations H263, H264 de l'ITU-T, ou encore MPEG4. Ces formats permettent en effet facilement de créer des données ayant deux couches ou niveaux de qualité, au sens de la hiérarchie de codage ou scalabilité (en anglais "scalability') temporelle. Certains formats permettent d'avoir de nombreux niveaux de qualité, chaque niveau ajoutant de la qualité aux niveaux inférieurs ; c'est le cas des formats H263+, MPEG4 part 2 FGS, ou encore SVC (codage vidéo hiérarchique, en anglais "Scalable Video Coding"). Dans le cas nullement limitatif où l'invention est appliquée à des données vidéo, elle peut s'appliquer à n'importe quel format vidéo offrant au moins deux niveaux de qualité. Les réseaux de communication de données peuvent s'avérer peu fiables en raison d'erreurs de transmission, de congestions ou d'arrêts temporaires des liaisons, lesquels peuvent entraîner des pertes plus ou moins importantes de paquets de données. Ainsi, de nombreux réseaux de données comme le réseau IP ou le mode de transfert asynchrone (ATM) comprennent des noeuds d'interconnexion (routeurs, commutateurs, etc.) afin d'acheminer les paquets de données en provenance de dispositifs source jusqu'à des dispositifs destinataires. Dans ce type de réseaux, la congestion est la source principale de pertes quand différents flux de données sont amenés à transiter par un même lien de capacité insuffisante. Les paquets en surplus finissent généralement par être rejetés par le noeud d'interconnexion situé à l'entrée du lien. De plus, les mécanismes de contrôle de congestion généralement mis en oeuvre dans les réseaux IP sont de type TFRC ("TCP Friendly Rate ControP', IETF RFC3448) ou AIMD ("Additive Increase/Multiplicative Decrease", IETF RFC2581) ; or ces mécanismes produisent, par nature, une pluralité de congestions, même si elles sont de courte durée. En cas de congestion, les noeuds d'interconnexion rejettent un nombre plus ou moins élevé de paquets de données afin de maintenir le niveau de remplissage des tampons de réception en dessous d'un seuil acceptable. On a donc à la fois un débit de communication limité et variable et des pertes de paquets. Dans le cas mentionné plus haut d'une caméra de vidéosurveillance, l'utilisateur a besoin de voir en direct la scène filmée. Un paquet de données qui arrive plus de 100 ms après la prise de vue n'a plus d'intérêt car il n'est plus exploitable par l'utilisateur. Ainsi, si un paquet est perdu, le serveur a peu de chances de pouvoir le renvoyer suffisamment rapidement. En outre, la sauvegarde de la vidéo par le client peut être utile si un événement important s'est produit, pour permettre au client de revoir ce qui s'est passé. Dans ce second cas, la latence n'a pas besoin d'être faible : typiquement, le dispositif qui reçoit la vidéo peut stocker plusieurs secondes de données avant de les sauvegarder sur un support. Tant qu'ils ne sont pas sauvegardés, les paquets peuvent être réordonnancés. Cependant, un tel système ne tolère pas une latence excessivement longue : en effet, cette méthode nécessite de la mémoire en accès aléatoire, laquelle reste de taille limitée. Les paquets en retard doivent être donc reçus dans une limite de temps qu'on appellera "latence longue" (typiquement, quelques secondes). Dans ce second cas, les paquets de retransmission sont très utiles car ils permettent de corriger de façon optimale les pertes réseau. Un autre problème lié à la faible latence est que pour s'adapter aux variations de débit du réseau, le codeur sur la caméra va devoir changer le taux de compression des images de façon très rapide. En effet, s'il ne baisse pas rapidement la quantité de données produite pour chaque image lorsque le débit réseau baisse, rapidement les données vont prendre du retard et donc une partie des données risque d'arriver trop tard pour le client désirant les afficher. Cependant, des changements rapides du taux de compression vont conduire à une dégradation importante de la qualité visuelle ressentie par un utilisateur. En effet, le système psycho-visuel humain est particulièrement sensible au changement de qualité des images. Dans le cas d'une latence plus longue, le codeur peut adapter le taux de compression de façon douce et continue pour éviter un changement brutal de qualité. Cette adaptation douce est intéressante à la fois pour la baisse de qualité et pour l'augmentation de qualité. Ainsi, la solution simple consistant à utiliser les mêmes données à la 25 fois pour la vidéo affichée en direct et pour la vidéo enregistrée ne permet pas d'utiliser au mieux les caractéristiques de latence de chaque client. L'autre solution simple consistant à envoyer deux flux différents indépendants n'est pas satisfaisante non plus : la bande passante du réseau est limitée et on ne peut donc pas transmettre simultanément deux flux, car cela 30 nécessiterait de comprimer la vidéo de façon trop importante. Le serveur ne peut pas non plus mémoriser systématiquement les données non envoyées pour les transmettre plus tard car on a à la fois une mémoire limitée sur le serveur et une limite sur le retard acceptable pour le client stockant les données. L'article de R. REJAIE et al. intitulé "Layered Quality Adaptation for Internet Video Streaming", publié dans IEEE Journal on Selected Areas of Communications, hiver 2000, décrit un système permettant d'adapter le débit de transmission d'une vidéo codée sous forme de plusieurs niveaux. Le nombre de niveaux est adapté à la moyenne du débit calculé par un algorithme de contrôle de congestion de type AIMD dont la valeur calculée oscille. Le serveur calcule une bande passante réseau instantanée et une bande passante moyenne sur la longueur de la période d'oscillation de l'algorithme AIMD. L'algorithme présente, d'une part, une phase de remplissage, lorsque le débit instantané est fort. Dans ce cas, les données les plus importantes sont envoyées en avance et stockées sur le client. L'algorithme présente d'autre part une phase de vidage, où le client utilise les données stockées pour compléter les données reçues. Cette solution ne peut pas être appliquée lorsqu'on utilise des données codées en direct (auquel cas on ne peut pas envoyer des données en avance). La présente invention a pour but de remédier aux inconvénients, 20 limites et lacunes précités de l'art antérieur. Dans ce but, la présente invention propose un procédé de transmission de données entre un serveur et au moins un client dans un réseau de communication, ces données devant respecter une première latence de transmission, convenant à un traitement d'un premier type à effectuer par un 25 premier client, et une seconde latence de transmission, supérieure à la première latence de transmission et convenant à un traitement d'un second type à effectuer par un second client, les premier et second clients pouvant être distincts ou non, ce procédé étant remarquable en ce qu'il comporte des étapes consistant, pour le serveur, à : 30 - déterminer, à partir des données précitées, en tenant compte de la bande passante disponible dans le réseau, un premier flux de données ayant un débit permettant de respecter la première latence ; - transmettre le premier flux de données aux premier et second clients ; - déterminer, à partir des données non comprises dans le premier flux de données, en tenant compte de la bande passante disponible dans le réseau, un second flux de données ayant un débit permettant de respecter la seconde latence ; et - transmettre le second flux de données au second client. Ainsi, l'invention permet de créer une partition des données en deux flux : le premier flux permet au premier client d'obtenir par exemple la partie la plus importante des données avant une première échéance temporelle et le second flux, en complément du premier flux, permet au second client d'obtenir par exemple la donnée complète (avec par exemple une meilleure qualité) avant la seconde échéance. Les deux échéances sont respectées et la qualité pour le second client peut être ainsi améliorée. L'invention permet aussi de déterminer l'instant d'envoi des données en respectant le débit ou bande passante du réseau, pour obtenir par exemple un bon compromis entre la qualité du flux de données décodé par le client avec une faible latence et la qualité du même flux de données décodé avec un délai plus long. Cela permet d'éviter des variations brutales de qualité du flux de données enregistré par le client. Dans le cas où le flux de données est une vidéo, la qualité visuelle de la vidéo enregistrée est donc améliorée par rapport à une solution classique qui consisterait à enregistrer la vidéo en direct, sachant que le système psycho-visuel est très sensible aux variations brutales de qualité. En outre, la qualité de la vidéo affichée en direct est maintenue bonne : elle est aussi lissée, ce qui permet d'éviter certaines variations brutales. En outre, le mécanisme est adapté à un réseau non fiable comportant par exemple un système de retransmission en cas de paquet perdu et un système de correction d'erreurs du type FEC ("Forward Error Correction'. Selon une caractéristique particulière, l'étape de détermination du premier flux comporte une étape consistant à déterminer la bande passante instantanée disponible dans le réseau. Le débit du premier flux peut dans ce cas être inférieur ou égal à la bande passante instantanée disponible déterminée. Cette caractéristique est particulièrement avantageuse lorsque la première latence ou échéance est courte par comparaison avec l'incertitude (ou la variabilité) de la mesure du débit réseau. A titre d'exemple, c'est le cas pour une première latence de 20 ms et une mesure TFRC sur un réseau avec un temps de communication aller-retour (en anglais "Round-Trip Time", RTT) de 5 ms. En variante, l'étape de détermination du premier flux peut comporter une étape consistant à déterminer la bande passante moyenne disponible dans le réseau sur une période de temps correspondant à la première latence. Le débit du premier flux peut dans ce cas être inférieur ou égal à la bande passante moyenne disponible déterminée. Cette variante est particulièrement avantageuse lorsque la première latence ou échéance est longue par comparaison avec l'incertitude (ou la variabilité) de la mesure du débit réseau. A titre d'exemple, c'est le cas pour une première latence de 100 ms et une mesure AIMD sur un réseau avec un temps de communication aller-retour de 1 ms. Dans un premier mode particulier de réalisation où les données sont codées suivant un premier niveau de qualité et un second niveau de qualité supérieur au premier niveau, le premier flux peut comprendre au moins une partie des données ayant le premier niveau de qualité et le second flux peut comprendre au moins une partie des données ayant le second niveau de qualité. Ce mode de réalisation est particulièrement avantageux notamment en cas de codage en temps réel avec deux niveaux de qualité. L'invention s'applique ainsi à de nombreux formats de vidéo. Dans ce mode de réalisation, lorsque les données sont organisées en paquets, une date de création étant associée à chaque paquet, selon une caractéristique particulière, le procédé peut comporter une étape consistant, pour le serveur, à comparer la date de création des paquets non transmis ayant le premier niveau de qualité avec la date courante et à déterminer si la différence entre ces deux dates est inférieure à la première latence diminuée du temps de transmission entre le serveur et le premier client. Cette caractéristique particulière est avantageuse par exemple dans le cas d'une transmission utilisant le protocole RTP (protocole de transport en temps réel, en anglais "Real-time Transport Protocot') dans un réseau IP. Dans un deuxième mode particulier de réalisation où les données sont codées suivant une première pluralité de niveaux de qualité et une seconde pluralité de niveaux de qualité supérieurs aux niveaux de la première pluralité de niveaux, l'étape de détermination du premier flux de données peut comporter des étapes consistant, pour le serveur, à : - déterminer la bande passante instantanée du réseau ; - comparer cette bande passante instantanée et la bande passante du niveau de qualité maximal de la première pluralité de niveaux de qualité ; - si la bande passante instantanée précitée est inférieure à la bande passante du niveau de qualité maximal, diminuer le niveau de qualité maximal de la première pluralité de niveaux de qualité de façon que la bande passante du niveau de qualité maximal diminué soit inférieure à la bande passante instantanée précitée et que la bande passante du niveau de qualité immédiatement supérieur au niveau de qualité maximal diminué soit supérieure à la bande passante instantanée précitée. Ce deuxième mode particulier de réalisation est avantageux notamment en cas de codage avec un format permettant d'avoir plusieurs niveaux hiérarchiques ou de scalabilité. Le codeur est ainsi simplifié car il n'a pas besoin de s'adapter de façon dynamique aux variations du réseau. L'invention s'applique particulièrement bien à un réseau de communication sans fil. De même, elle s'applique particulièrement bien au cas d'un flux de données vidéo. Dans le même but que celui indiqué plus haut, la présente invention propose également un serveur de transmission de données entre un serveur et au moins un client dans un réseau de communication, ces données devant respecter une première latence de transmission, convenant à un traitement d'un premier type à effectuer par un premier client, et une seconde latence de transmission, supérieure à la première latence de transmission et convenant à un traitement d'un second type à effectuer par un second client, les premier et second clients pouvant être distincts ou non, ce serveur étant remarquable en ce qu'il comporte : -des moyens pour déterminer, à partir des données précitées, en tenant compte de la bande passante disponible dans le réseau, un premier flux de données ayant un débit permettant de respecter la première latence ; - des moyens pour transmettre le premier flux de données aux premier et second clients ; - des moyens pour déterminer, à partir des données non comprises dans le premier flux de données, en tenant compte de la bande passante disponible dans le réseau, un second flux de données ayant un débit permettant de respecter la seconde latence ; et - des moyens pour transmettre le second flux de données au second client. Toujours dans le même but, la présente invention vise aussi un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, remarquable en ce qu'il permet la mise en oeuvre d'un procédé de transmission tel que succinctement décrit ci-dessus. Dans un mode particulier de réalisation, le moyen de stockage est partiellement ou totalement amovible. Toujours dans le même but, la présente invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, remarquable en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de transmission tel que succinctement décrit ci-dessus, lorsque ce programme est chargé et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du serveur de transmission, du moyen de stockage d'informations et du produit programme d'ordinateur étant similaires à ceux du procédé de transmission, ils ne sont pas répétés ici. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels : - la figure 1 représente de façon schématique un réseau de communication de données du type réparti susceptible de mettre en oeuvre la présente invention ; - la figure 2 représente de façon schématique un mode particulier de réalisation d'un dispositif émetteur adapté pour mettre en oeuvre la présente invention ; - la figure 3 est un schéma de principe illustrant les principales étapes d'un procédé de transmission conforme à la présente invention, dans un mode particulier de réalisation ; - la figure 4 est un graphique montrant le principe général d'un premier algorithme mettant en oeuvre l'invention ; - les figures 5a, 5b et 5c sont des organigrammes illustrant les principales étapes des algorithmes utilisés par un serveur conforme à la présente invention, dans un mode particulier de réalisation ; - les figures 6a, 6b et 6c sont des graphiques montrant des cas particuliers pour le calcul du débit réseau moyen conformément à la présente invention, dans des modes particuliers de réalisation ; - les figures 7a, 7b et 7c sont des organigrammes illustrant les principales étapes des algorithmes utilisés par un serveur conforme à la présente invention, dans une variante de réalisation ; - la figure 8 est un graphique représentant de façon schématique le contenu de la mémoire tampon d'un serveur mettant en oeuvre la présente invention, dans un mode particulier de réalisation ; et - la figure 9 est un organigramme illustrant les principales étapes d'un procédé de transmission de données conforme à la présente invention, dans sa généralité. La figure 1 montre un exemple de réseau de communication de données où la présente invention peut être mise en oeuvre. Un dispositif émetteur ou serveur 101 transmet des paquets de données d'un flux de données à un dispositif récepteur ou client 102 à travers 5 un réseau de communication de données 100. Le réseau 100 peut contenir des noeuds d'interconnexion 103 et des liaisons 104 qui créent des chemins entre les dispositifs émetteur et récepteur. Les noeuds d'interconnexion 103 et le dispositif récepteur 102 peuvent rejeter des paquets de données en cas de congestion, c'est-à-dire en 10 cas de débordement de la mémoire de réception. Le réseau 100 peut être par exemple un réseau sans fil du type WiFi / 802. 11a ou b ou g, ou un réseau Ethernet, ou Internet. Le flux de données fourni par le serveur 101 peut comprendre des informations vidéo, des informations audio, des combinaisons des deux, ou 15 n'importe quel autre type d'informations qui peut incorporer une couche de base (ou premier niveau de qualité) et au moins une couche d'amélioration (ou second niveau de qualité). Un exemple d'un tel flux de données est un flux vidéo MPEG comprenant différents types de trames vidéo telles que des trames clés (I), des 20 trames prédictives avant (P), et des trames prédictives avant et arrière (B), où les trames clés servent de base au traitement des trames prédictives avant et arrière. Les trames I représentent donc les données de base puisque la perte d'une seule trame I rend impossible le traitement correct des trames P et B associées. Les trames P représentent le premier niveau de données 25 d'amélioration puisque leur absence n'empêche pas le décodeur au niveau du dispositif récepteur de traiter les trames I, et n'entraîne qu'une qualité dégradée (temporellement). De même, les trames B représentent un deuxième niveau d'amélioration puisque leur absence n'empêche pas de décoder les trames I et P. 30 On peut aussi utiliser un format de codage qui fournit plusieurs niveaux de scalabilité : par exemple, H263+ ou MPEG4 part 2 FGS, ou encore le nouveau format SVC. Dans ces formats, on peut avoir non seulement de la scalabilité temporelle comme décrit précédemment mais aussi de la scalabilité spatiale et/ou en termes de rapport signal sur bruit (SNR, en anglais "Signal to Noise Ratio"). On peut aussi considérer les mécanismes de code correcteur d'erreur (du type FEC) comme une couche d'amélioration. En effet, les FEC permettent d'engendrer des paquets d'information de redondance qui, s'ils sont reçus, permettront de corriger des pertes de paquets éventuelles dans la couche de base. Conformément à la présente invention, on peut décomposer la donnée initiale en une couche de base qui peut être décodée en fournissant un premier niveau de qualité et une couche d'amélioration qui, si elle est décodée avec la couche de base, permet d'obtenir une meilleure qualité. Le dispositif émetteur 101 peut être n'importe quel type de dispositif de traitement de données susceptible de fournir un flux de données à un dispositif récepteur. A titre d'exemple nullement limitatif, le dispositif émetteur peut être un serveur de flux capable de fournir un contenu à des clients sur demande, par exemple en utilisant le protocole RTP sur UDP (protocole de datagramme utilisateur, en anglais "User Datagram Protocot') ou DCCP (protocole de contrôle de congestion de datagramme, en anglais "Datagram Congestion Control Protocot") ou n'importe quel autre type de protocole de communication. Le dispositif émetteur peut mettre en oeuvre un algorithme de contrôle de congestion du type mentionné plus haut, à savoir, TFRC ou encore AIMD. Tant le dispositif émetteur 101 que le dispositif récepteur 102 peut être par exemple un dispositif tel que représenté sur la figure 2. Les terminaux peuvent communiquer directement par l'intermédiaire du réseau global 100. La figure 2 illustre en effet notamment un dispositif émetteur 101 adapté pour incorporer l'invention, dans un mode particulier de réalisation. De préférence, le dispositif émetteur 101 comporte une unité centrale de traitement (UC) 201 capable d'exécuter des instructions provenant d'une mémoire morte (ROM) de programmes 203 à la mise sous tension du dispositif émetteur, ainsi que des instructions concernant une application logicielle provenant d'une mémoire principale 202 après la mise sous tension. La mémoire principale 202 est par exemple du type mémoire vive (RAM) et fonctionne comme zone de travail de l'UC 201. La capacité de mémoire de la RAM 202 peut être augmentée par une RAM facultative connectée à un port d'extension (non illustré). Les instructions concernant l'application logicielle peuvent être chargées dans la mémoire principale 202 à partir d'un disque dur 206 ou bien de la ROM de programmes 203 par exemple. De façon 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 ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Une telle application logicielle, lorsqu'elle est exécutée par l'UC 201, entraîne l'exécution des étapes des organigrammes des figures 3 ou 5 ou 7. Le dispositif émetteur 101 comporte en outre une interface réseau 204 qui permet sa connexion au réseau de communication 100. L'application logicielle, lorsqu'elle est exécutée par l'UC 201, est adaptée pour réagir à des requêtes du client 102 reçues par le biais de l'interface réseau 204 et pour fournir au client 102 des flux de données par l'intermédiaire du réseau 100. Le dispositif émetteur 101 comporte de plus une interface d'utilisateur 205, constituée par exemple d'un écran et/ou d'un clavier et/ou d'un dispositif de pointage tel qu'une souris ou un crayon optique, pour afficher des informations à un utilisateur et/ou recevoir des entrées de celui-ci. Un appareil mettant en oeuvre l'invention est par exemple un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable, un caméscope numérique, un appareil photo numérique, une caméra de vidéosurveillance (par exemple du type Webcam), un lecteur DVD ou encore un serveur multimédia. Cet appareil peut intégrer directement un capteur numérique d'images, ou optionnellement être connecté à différents périphériques tels que, par exemple, une caméra numérique (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 multimédia. L'organigramme de la figure 9 illustre les principales étapes d'un procédé de transmission de données conforme à la présente invention dans sa généralité. On considère un réseau de communication du type du réseau 100 de la figure 1. L'invention a pour objet la transmission de données entre un serveur (du type du serveur 101 de la figure 1) et un ou plusieurs clients (du type du client 102 de la figure 1). Les données à transmettre sont soumises à une double contrainte : d'une part, elles doivent pouvoir être transmises avec une durée inférieure ou égale à une première latence (appelée par la suite latence "faible" ou "courte"), de façon à permettre à un premier client d'appliquer à ces données un premier type de traitement. A titre d'exemple non limitatif, si les données sont de type vidéo, le premier type de traitement peut être l'affichage en direct des données reçues du serveur. D'autre part, les données doivent également pouvoir être transmises avec une durée inférieure ou égale à une seconde latence (appelée par la suite latence "longue"), supérieure à la première latence, de façon à permettre à un second client d'appliquer à ces données un second type de traitement. Les premier et second clients peuvent en pratique constituer un seul et même client, ou être distincts. Dans le cas précité de données vidéo, le second type de traitement 25 peut être la mémorisation ou enregistrement des données reçues, en vue de leur visualisation ultérieure. Comme le montre la figure 9, une première étape 901 consiste, pour le serveur, à déterminer, à partir de l'ensemble des données à transmettre et en tenant compte de la bande passante disponible sur le réseau, un premier flux 30 de données ayant un débit permettant de respecter la latence courte. Dans l'exemple non limitatif où les données sont de type vidéo, ces données sont codées sous forme d'au moins deux couches ou niveaux de qualité, dont une couche de base et une ou plusieurs couches dites d'amélioration. Dans le cadre de cet exemple, les données codées comprises dans le premier flux peuvent être constituées d'un sous-ensemble de couches de qualité et/ou de portions de couches de qualité : par exemple, la couche de base (ou bien, de façon plus générale,la ou les couche(s) de plus basse qualité). Dans un mode particulier de réalisation, l'étape 901 consiste à déterminer la bande passante instantanée disponible et à attribuer au premier flux de données un débit inférieur ou égal à celle-ci. En variante, l'étape 901 peut consister à déterminer la bande passante moyenne disponible, cette valeur moyenne étant calculée sur une période de temps correspondant à la latence courte, et à attribuer au premier flux de données un débit inférieur ou égal à cette valeur moyenne. Après l'étape 901, une étape 903 consiste, pour le serveur, à transmettre le premier flux aux premier et second clients avec le débit qui a été attribué à ce premier flux. De cette façon, le premier flux est transmis en respectant la latence courte. A la suite de l'étape 901, une étape 905 consiste, pour le serveur, à déterminer, à partir des données non comprises dans le premier flux et en tenant compte de la bande passante disponible sur le réseau, un second flux de données ayant un débit permettant de respecter la latence longue. Dans l'exemple précité où les données sont de type vidéo, les données comprises dans le second flux peuvent être constituées d'au moins une partie des données qui sont les complémentaires de celles contenues dans le premier flux. Par exemple, les données codées du second flux peuvent être constituées d'un sous-ensemble de couches d'amélioration et/ou de portions de couches d'amélioration qui sont des complémentaires des couches et/ou portions de couches du premier flux. Dans l'exemple non limitatif où la couche de base est transmise en partie dans le premier flux, le reste de la couche de base peut être transmis dans le second flux. L'étape 905 a été illustrée sur la figure 9 après l'étape 903 de transmission du premier flux. Néanmoins, l'étape 905 peut également être effectuée entre les étapes 901 et 903. Après l'étape 905, une étape 907 consiste, pour le serveur, à transmettre le second flux au second client avec le débit attribué à ce second flux. Le second flux est ainsi transmis en respectant la latence longue. Le débit du second flux est calculé de telle sorte qu'il évite de créer une congestion du réseau. A titre d'exemple, le débit du second flux peut être calculé comme la différence entre le débit du premier flux et la mesure de débit instantané disponible dans le réseau au moment de la transmission du second flux. Ainsi, pour des données codées suivant une ou plusieurs couches (par exemple, couche de base) présentant une qualité de bas niveau et une ou plusieurs couches (par exemple, couche d'amélioration) présentant une qualité d'un niveau plus élevé : - le premier flux contient au moins une portion de couche (par exemple couche de base) présentant une qualité de bas niveau ; il peut être transmis avec un débit relativement faible qui respecte la latence courte ; et - le second flux contient des éléments de données non transmis dans le premier flux, qui se rapportent à au moins une portion de couche (par exemple, couche d'amélioration) non transmise dans le premier flux et présentant une qualité d'un niveau plus élevé que la portion de couche (par exemple couche de base) du premier flux se rapportant aux mêmes données ; le second flux peut être transmis avec un débit plus important qui respecte la latence longue. On décrit ci-après plus en détail, en liaison avec les figures 3, 5 et 7, des modes particuliers de réalisation de l'invention où les données à transmettre sont codées sous forme de plusieurs niveaux ou couches de qualité. La figure 3 présente les principales étapes de mise en oeuvre de l'invention, dans un premier mode particulier de réalisation. Un utilisateur se trouve devant un écran qui est connecté à un réseau. Un appareil capable d'engendrer un flux vidéo est connecté à ce même réseau. Dans l'exemple illustré sur la figure 3, cet appareil est une caméra vidéo. Comme le montre la figure 3, lors d'une étape 1 de démarrage de l'application, l'utilisateur configure le client pour qu'il se connecte au serveur. Pour cela, le client envoie une requête demandant à recevoir une vidéo. Dans cette requête, le client précise au serveur que la vidéo a un double usage : le client souhaite, d'une part, pouvoir afficher la vidéo avec une faible latence et d'autre part, pouvoir la sauvegarder, en vue d'une visualisation éventuelle ultérieure. Cette requête peut être envoyée en utilisant par exemple le protocole RTSP (protocole de streaming temps réel, en anglais "Real-Time Streaming Protocof'). Puis lors d'une étape 2, le serveur code la vidéo sous forme de deux niveaux de qualité ou couches : une première couche de base et une couche d'amélioration. Le débit de chaque couche est calculé en fonction d'une évaluation du débit (ou bande passante) disponible sur le réseau. Les données codées sont stockées dans une mémoire tampon locale avant d'être transmises au client. Ensuite, lors d'une étape 3, le serveur sélectionne une partie des données de la mémoire locale à envoyer. La couche de base est transmise avec une faible latence. La couche d'amélioration est transmise avec une latence variable. Le client reçoit, décode et affiche immédiatement les données qui 20 arrivent avec une latence suffisamment faible (étape 4). Ces données contiennent au moins la couche de base. Simultanément (étape 5), le client stocke l'ensemble des données reçues : couche de base et couche d'amélioration. Ultérieurement (étape 6), l'utilisateur peut demander à visualiser la 25 vidéo stockée. II peut alors visualiser une vidéo de meilleure qualité que celle visualisée en direct, puisque l'ensemble des données (couche de base et couche d'amélioration) sont disponibles. On pourrait envisager d'autres exemples de mise en oeuvre de l'invention. En particulier, le rôle du client pourrait être réparti entre plusieurs 30 dispositifs : un premier dispositif émettant une requête (étape 1) pour recevoir la vidéo en direct (étape 4) avec une latence faible et un deuxième dispositif demandant le même flux avec une seconde requête RTSP tolérant une latence longue de réception (étape 1 bis, en même temps que l'étape 1) pour stocker la vidéo (étape 5). Dans une telle mise en oeuvre, le serveur envoie la vidéo en utilisant deux communications multipoint (en anglais "multicast") : la première communication (concernant la couche de base) est diffusée simultanément aux deux clients, tandis que la deuxième (concernant la couche d'amélioration) est reçue uniquement par le dispositif de stockage. Le graphique de la figure 4 montre le principe d'un premier algorithme mettant en oeuvre la présente invention. L'algorithme calcule le débit des couches de base et d'amélioration et procède à la sélection des données à envoyer. Sur la figure 4, la courbe Dl montre un exemple d'évolution du débit instantané du réseau vu par le serveur. Ce débit peut être évalué de différentes façons. Le serveur peut par exemple utiliser un algorithme de contrôle de congestion tel que TFRC ou encore AIMD (semblable à TCP) pour déterminer à chaque instant la quantité de données à envoyer. Le débit Dl peut être directement la valeur donnée par l'algorithme de contrôle de congestion, ou bien il peut être mesuré en calculant une moyenne de cette valeur sur une courte durée inférieure à la latence de l'affichage en direct. Le serveur calcule également un débit réseau moyen D2, en calculant une moyenne du débit instantané sur une durée plus longue, égale par exemple à la latence du dispositif de stockage ou à la longueur de la mémoire tampon du serveur. Dans l'exemple illustré sur la figure 4, le débit instantané Dl subit une chute importante et rapide pendant une courte période, avant de revenir à son niveau initial. Le débit moyen D2 baisse donc progressivement, puis remonte lentement. Le principe de l'algorithme est d'avoir une phase d'enregistrement (appelée "phase 1" sur le dessin) lorsque le débit instantané Dl est inférieur au débit moyen D2. Durant cette phase, le serveur code une couche de base au débit Dl et l'envoie immédiatement au client. Les données d'amélioration sont créées au débit D2 -- Dl et sont stockées dans la mémoire tampon du serveur. Dans une deuxième phase (appelée "phase 2" sur le dessin), lorsque le débit instantané est suffisant (Dl est supérieur à D2), le serveur code la couche de base au débit D2 et l'envoie immédiatement. En revanche, il ne crée pas de donnée d'amélioration et la différence entre le débit instantané et le débit moyen est utilisée pour envoyer au client les données stockées dans la mémoire tampon du serveur. L'utilisateur va ainsi obtenir, lors de la visualisation en direct, une qualité correspondant à la couche de base au débit D = min (D1, D2) et lors de la visualisation de l'enregistrement, une qualité correspondant au débit D2 qui sera supérieure à la qualité du direct. L'organigramme de la figure 5a illustre les principales étapes de l'algorithme utilisé par le serveur dans le premier mode particulier de réalisation de l'invention, pour calculer le débit de codage des couches de la vidéo. Ce mode de réalisation est particulièrement approprié dans le cas où le flux de données est organisé sous forme de paquets et où le serveur et le client utilisent un système d'acquittement des paquets reçus et de retransmission en cas de paquet perdu. Au cours d'une étape préalable non représentée, deux informations de latence ont été communiquées au serveur : une latence faible avec laquelle le client souhaite pouvoir afficher la vidéo reçue en direct et une latence plus grande avec laquelle le client peut recevoir la vidéo pour la sauvegarder en vue d'un affichage éventuel ultérieur. A l'étape 500, le serveur prend l'image suivante à coder. A l'étape suivante 501, le serveur calcule le débit (ou bande passante) instantané Dl du réseau. Ce calcul peut être effectué par exemple en utilisant un algorithme de contrôle de congestion du type TFRC comme mentionné précédemment. Puis à l'étape 502, le serveur détermine le nouveau débit (ou bande passante) moyen D2 du réseau à l'instant courant. Pour cela, le serveur peut utiliser la valeur du débit Dl au même instant et la valeur du débit moyen à l'instant précédent, mémorisée dans la même variable D2. La nouvelle valeur du débit moyen est obtenue en effectuant une somme pondérée de ces deux valeurs : a.Dl + b.D2 avec, par exemple, a = 0,1 et b = 0,9. Cependant, si la mémoire tampon du serveur est vide, D2 est fixé égal à D1. Ce cas particulier est expliqué plus loin en liaison avec la figure 6. Le serveur compare ensuite le débit instantané Dl avec le débit moyen D2 (test 510). Si le débit instantané est plus faible que la moyenne (Dl A l'issue de l'étape 515 ou 520, lors d'une étape 530, le serveur crée les paquets, par exemple conformément au protocole RTP, à envoyer. La donnée est découpée en tenant compte de la structure en tranches (en anglais "siices") de la vidéo ainsi que de la taille maximale des paquets réseaux. Les en-têtes RTP sont ajoutés. A chaque paquet est associée une information de date de création (l'heure à laquelle l'image a été saisie) et l'indication de la couche. Les paquets avec les informations associées sont ensuite stockés dans la mémoire tampon locale (étape 535). Dans le cas où la mémoire est trop limitée dans le tampon du serveur, il peut être nécessaire de détruire le plus ancien paquet du tampon pour faire de la place pour le nouveau paquet. L'organigramme de la figure 5b illustre les étapes de sélection des paquets à envoyer. Cet algorithme est exécuté à chaque fois que le serveur décide d'envoyer un paquet. Dans le cas où on utilise un algorithme de contrôle de congestion du type TFRC, c'est cet algorithme qui détermine l'instant d'envoi d'un paquet (étape 550). Le serveur teste d'abord s'il existe au moins un paquet récent non envoyé de la couche de base (test 555). Un paquet récent est un paquet qui pourra arriver avec la latence faible d'affichage. Pour évaluer si un paquet est récent, on compare sa date associée et la date courante ; on considère que le paquet est récent si la différence entre ces deux dates est inférieure à la latence courte moins le temps de transmission au client. Si on trouve au moins un tel paquet, on peut passer à l'étape 570. Si aucun paquet n'a été trouvé, le serveur recherche alors tous les paquets non envoyés de la couche de base et qui ne sont pas trop anciens, c'est-à-dire qui peuvent être reçus en respectant la latence longue (test 560). Si on trouve au moins un tel paquet, on peut passer à l'étape 570. Sinon, le serveur recherche tous les paquets restants non envoyés (c'est-à-dire tous les paquets de la couche d'amélioration) et qui ne sont pas trop anciens (test 565). Si on trouve au moins un tel paquet, on peut passer à l'étape 570. A l'étape 570, le serveur prend le paquet ayant la date la plus ancienne parmi tous les paquets sélectionnés. Ce paquet est marqué comme envoyé avec sa date d'envoi (il sera détruit ultérieurement, comme décrit plus loin en liaison avec la figure 5c) et il est envoyé au client (étape 571). Si aucun paquet n'est sélectionné, le serveur n'envoie rien (étape 575). L'organigramme de la figure 5c illustre les principales étapes permettant de mettre à jour la mémoire tampon du serveur. Le serveur va exécuter régulièrement cet algorithme, à savoir, à chaque fois qu'il reçoit un retour du client indiquant qu'un paquet a été reçu et sur la base d'une temporisation donnée (en anglais "timer" ). A l'étape 580, les paquets dont la réception a été confirmée par le client (éventuellement après une demande de répétition automatique ARQ (en anglais "Automatic Repeat reQuest'), si une correction d'erreur est nécessaire) sont détruits. A l'étape 585, les paquets trop anciens sont détruits. Un paquet trop ancien est un paquet dont la date de création indique qu'il ne peut plus être reçu en respectant la latence de réception du client pour le stockage. Enfin, à l'étape 590, le serveur vérifie les paquets envoyés mais dont la réception n'a pas été confirmée. Si un temps trop long s'est écoulé (typiquement, une durée supérieure au temps de communication aller-retour entre le serveur et le client), l'état du paquet est changé pour que ce paquet puisse de nouveau être envoyé : on enlève le marqueur indiquant que le paquet avait été envoyé. Le graphique de la figure 6a illustre un cas particulier de l'étape 502. II s'agit du cas où la bande passante, évaluée par exemple au moyen d'un algorithme de contrôle de congestion du type TFRC, reste stable à un premier niveau faible pendant une longue période, puis augmente brusquement à un deuxième niveau élevé. Dans ce cas, la valeur moyenne du débit va augmenter lentement (cela est illustré par la courbe en tirets sur le dessin). Cela permettrait au serveur d'envoyer d'éventuelles données stockées. Cependant, dans le cas où aucune donnée n'est présente dans le tampon du serveur, il est inutile de réserver de la bande passante. C'est la raison pour laquelle on effectue le test sur l'état du tampon (mentionné dans la description de l'étape 502 de la figure 5a) pour décider de la valeur du débit moyen D2. De façon plus générale, on peut utiliser le niveau de remplissage du 20 tampon et les niveaux relatifs de Dl et D2 pour modifier les pondérations a et b de Dl et D2 dans la formule utilisée à l'étape 502. Le cas symétrique d'une diminution continue du débit réseau est illustré sur la figure 6b. Le débit instantané Dl du réseau est évalué à un haut niveau puis baisse brutalement à un niveau plus faible mais ne remonte jamais. 25 Dans ce cas, on a une phase de création de données d'amélioration qui sont stockées ("phase 1" sur le dessin). Cependant, ces données ne peuvent pas être envoyées par la suite. Conformément à l'algorithme de la figure 5c, le serveur finira par supprimer ces données sans les envoyer. Une variante tenant compte de l'état du tampon du serveur pour 30 calculer le débit moyen D2 pourrait consister à diminuer temporairement le débit de codage pour permettre l'émission des données d'amélioration. Un autre cas particulier, illustré sur la figure 6c, peut être pris en compte avec un calcul plus complexe de D2. En effet, à l'étape 502, D2 peut être calculé en tenant compte également de la complexité de l'image et de la vidéo. L'algorithme de contrôle de débit peut choisir les paramètres de quantification, et donc le débit, en fonction de plusieurs paramètres : - un modèle débit-distorsion (à titre d'exemple, des modèles connus utilisés dans le cadre de la compression MPEG sont TMN-5 ou TMN-8), - la bande passante évaluée, - le pas de quantification courant, - un modèle psycho-visuel (sachant que les variations rapides de pas de quantification sont à éviter), et - le taux de remplissage du tampon du serveur. On peut ainsi décider d'éviter des modifications rapides du pas de quantification lorsque le tampon est peu rempli, même si le débit réseau instantané n'est de ce fait pas respecté temporairement. Ainsi, comme le montre la figure 6c, après un début stable, une scène de la vidéo devient plus complexe à coder (par exemple, en raison de mouvements complexes et rapides). Dans ce cas, pour garder une qualité stable, il est nécessaire de coder la vidéo avec un débit plus important. Comme le débit réseau n'a pas changé, le débit de la couche de base reste inchangé, avec par conséquent une qualité dégradée. Cependant, une couche d'amélioration est créée et stockée localement dans le tampon du serveur. Dans une seconde phase, la complexité de la vidéo diminue. Le serveur peut alors décider de diminuer le débit accordé à la vidéo, dans le but de pouvoir envoyer les données stockées et donc la couche d'amélioration. Les organigrammes des figure 7a, 7b et 7c illustrent un second mode particulier de réalisation de l'invention, dans le cas où le serveur utilise un codage multicouche, par exemple avec un codec de type SVC, qui permet d'avoir plusieurs couches d'amélioration. On note LO, L1, ..., Ln les couches d'amélioration successives de la vidéo. La valeur Lb est le niveau de la limite entre les couches envoyées en direct (couches de base) et les couches envoyées de façon retardée. L'organigramme de la figure 7a montre le codage d'une image. Au cours d'une première étape 700, le serveur reçoit une nouvelle image. II la code (étape 705) sous forme de plusieurs couches Li de telle sorte que l'ensemble de tous les niveaux fournit une qualité maximale. Les données sont stockées dans le tampon du serveur. Le serveur calcule ensuite le débit (ou bande passante) instantané D1 (étape 710), par exemple en prenant la valeur fournie par l'algorithme de contrôle de congestion TFRC. Le serveur compare ensuite le débit du niveau Lb des données à envoyer en priorité (noté B(Lb)) avec le débit instantané réseau D1 (étape 715). Si le débit du niveau Lb est trop grand, c'est-à-dire si B(Lb) > D1, le serveur recalcule le niveau Lb des données à envoyer en direct. En l'occurrence, il diminue Lb. Pour cela, le serveur calcule le niveau Lb de telle sorte que le débit de la couche Lb (incluant les couches LO jusqu'à Lb) soit inférieur au débit instantané D1 (B(Lb) D1) (étape 720). Le niveau Lb est ensuite utilisé lors de la sélection des paquets à envoyer (décrite ci-dessous en liaison avec la figure 7b). Ce calcul permet, lors de la phase 1 d'enregistrement des données d'amélioration, de baisser rapidement le niveau de qualité des données envoyées en direct lors d'une baisse du débit réseau, comme dans le mode de réalisation de la figure 5a. L'organigramme de la figure 7b montre la sélection des paquets à envoyer. De même que dans le mode de réalisation de la figure 5b, l'algorithme de la figure 7b est exécuté à chaque fois que le serveur décide d'envoyer un paquet. De même également, dans le cas où on utilise un algorithme de contrôle de congestion du type TFRC, c'est cet algorithme qui détermine l'instant auquel un paquet doit être envoyé (étape 750). Le serveur commence par vérifier s'il existe des paquets récents non envoyés appartenant à une couche à envoyer en direct (couche de niveau inférieur ou égal à Lb) (test 755). Comme dans le mode de réalisation de la figure 5b, un paquet récent est un paquet qui peut être reçu avant l'échéance de la période de latence faible. Si de tels paquets existent, ils sont sélectionnés et on passe à l'étape 770. Sinon, on passe au test 760. Le test 760 consiste, pour le serveur, à tester s'il existe au moins un paquet non envoyé d'une couche inférieure ou égale à Lb et qui ne soit pas trop ancien (c'est-à-dire qui peut être reçu en respectant la latence longue). Si tel est le cas, tous les paquets correspondants sont sélectionnés et on passe à l'étape 770. Sinon, on passe à l'étape 765, où la valeur de Lb est augmentée pour passer à la couche immédiatement supérieure (Lb+1) avant de revenir à l'étape 755. Cette étape permet, lors de la seconde phase (envoi des données d'amélioration), une augmentation progressive du niveau de qualité des données envoyées rapidement en même temps que l'envoi des données d'amélioration précédemment stockées. Si la valeur maximale de Lb est atteinte (Lb = Ln), aucun paquet n'est disponible et donc, aucun paquet ne peut être envoyé (étape 775). A l'étape 770, le serveur choisit le paquet le plus ancien dans l'ensemble de tous les paquets sélectionnés. Le paquet choisi est envoyé (étape 771) et retiré du buffer. L'organigramme de la figure 7c illustre l'algorithme de mise à jour (par destruction des données) du tampon du serveur, qui est exécuté 25 régulièrement, au moins avant chaque codage d'image. Les données déjà envoyées sont supprimées (étape 780). Les données trop anciennes sont ensuite détruites (étape 785). Une donnée est estimée trop ancienne si elle ne peut pas être reçue avant l'échéance de la période de latence longue. 30 Le serveur vérifie ensuite si la place mémoire disponible dans le tampon est suffisante pour stocker la prochaine image codée (test 790). Si la place disponible n'est pas suffisante, le serveur supprime les données de la couche maximale encore présente dans le tampon (étape 795) avant de revenir au test 790. Si la place disponible est suffisante, l'algorithme de mise à jour se termine. Il est à noter que dans ce second mode de réalisation, de même que dans le premier et comme illustré sur la figure 4, une baisse du débit instantané D1 conduit à une baisse de la qualité des données envoyées en direct et à la mémorisation des données d'amélioration (phase 1) et une hausse du débit instantané D1 provoque une hausse progressive de la qualité avec envoi de données mémorisées (phase 2). En outre, les deux variantes de l'invention présentées sur les figures 5a, 5b et 5c, d'une part, et sur les figures 7a, 7b et 7c, d'autre part, gèrent la mémoire tampon du serveur de façon similaire. Le contenu de la mémoire tampon du serveur est schématisé sur la figure 8. Les nouvelles données correspondant à une nouvelle image sont insérées par le codeur à droite sur le graphique (par date de génération croissante). Les données sont représentées par importance croissante de bas en haut. Le seuil correspondant à la limite entre couche de base envoyée en direct et couche d'amélioration envoyée plus tard est visualisé par le seuil Lb. Deux seuils temporels existent : - la latence courte : les données à droite de ce seuil sur le dessin peuvent être envoyées à temps pour être reçues et affichées par le client. - la latence longue : les données plus anciennes que ce seuil n'ont plus d'intérêt et peuvent être détruites. Les deux modes de réalisation décrits précédemment envoient en priorité les données de la zone 810: les données récentes et relatives à la couche de base. Ces données sont envoyées par date d'échéance croissante. Lorsque la zone 810 est vide, les données du reste du tampon (zone 820) sont envoyées. Ces données restantes sont envoyées par importance croissante puis, pour les données de même importance, par échéance croissante. REVENDICATIONS 1. Procédé de transmission de données entre un serveur (101) et au moins un client (102) dans un réseau de communication (100), lesdites données devant respecter une première latence de transmission, convenant à un traitement d'un premier type à effectuer par un premier client, et une seconde latence de transmission, supérieure à la première latence de transmission et convenant à un traitement d'un second type à effectuer par un second client, lesdits premier et second clients pouvant être distincts ou non, ledit procédé étant caractérisé en ce qu'il comporte des étapes consistant, pour le serveur (101), à : - déterminer (901), à partir desdites données, en tenant compte de la bande passante disponible dans ledit réseau, un premier flux de données ayant un débit permettant de respecter ladite première latence ; - transmettre (903) ledit premier flux de données auxdits premier et second clients ; - déterminer (905), à partir des données non comprises dans ledit premier flux de données, en tenant compte de la bande passante disponible dans ledit réseau, un second flux de données ayant un débit permettant de respecter ladite seconde latence ; et - transmettre (907) ledit second flux de données audit second client. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape (901) de détermination du premier flux comporte une étape consistant à déterminer la bande passante instantanée disponible dans ledit réseau (100) et en ce que le débit du premier flux est inférieur ou égal à la bande passante instantanée disponible déterminée. 3. Procédé selon la revendication 1, caractérisé en ce l'étape (901) de détermination du premier flux comporte une étape consistant à déterminer la bande passante moyenne disponible dans ledit réseau (100) sur une période de temps correspondant à la première latence et en ce que le débit du premier flux est inférieur ou égal à la bande passante moyenne disponible déterminée. 4. Procédé selon la revendication 1, 2 ou 3, dans lequel les données sont codées suivant un premier niveau de qualité et un second niveau de qualité supérieur au premier niveau, caractérisé en ce que ledit premier flux comprend au moins une partie des données ayant ledit premier niveau de qualité et ledit second flux comprend au moins une partie des données ayant ledit second niveau de qualité. 5. Procédé selon la revendication précédente, dans lequel les données sont organisées en paquets, une date de création étant associée à chaque paquet, caractérisé en ce qu'il comporte une étape consistant, pour le serveur (101), à comparer la date de création des paquets non transmis ayant ledit premier niveau de qualité avec la date courante et à déterminer si la différence entre ces deux dates est inférieure à ladite première latence diminuée du temps de transmission entre le serveur (101) et ledit premier client. 6. Procédé selon la revendication 1, 2 ou 3, dans lequel les données sont codées suivant une première pluralité de niveaux de qualité et une seconde pluralité de niveaux de qualité supérieurs aux niveaux de ladite première pluralité de niveaux, caractérisé en ce que ladite étape (901) de détermination du premier flux de données comporte des étapes consistant, pour le serveur (101), à : - déterminer (710) la bande passante instantanée (Dl) du réseau (100) ; - comparer (715) ladite bande passante instantanée (Dl) et la bande passante du niveau de qualité maximal (Lb) de ladite première pluralité de niveaux de qualité ; - si ladite bande passante instantanée (Dl) est inférieure à ladite bande passante du niveau de qualité maximal (Lb), diminuer (720) le niveau de qualité maximal (Lb) de ladite première pluralité de niveaux de qualité de façon que la bande passante du niveau de qualité maximal diminué soit inférieure à ladite bande passante instantanée (Dl) et que la bande passante du niveau de qualité immédiatement supérieur au niveau de qualité maximal diminué soit supérieure à ladite bande passante instantanée (Dl). 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le réseau de communication (100) est un réseau sans fil. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le flux de données est un flux vidéo. 9. Serveur (101) de transmission de données entre un serveur (101) et au moins un client (102) dans un réseau de communication (100), lesdites données devant respecter une première latence de transmission, convenant à un traitement d'un premier type à effectuer par un premier client, et une seconde latence de transmission, supérieure à la première latence de transmission et convenant à un traitement d'un second type à effectuer par un second client, lesdits premier et second clients pouvant être distincts ou non, ledit serveur étant caractérisé en ce qu'il comporte : - des moyens pour déterminer, à partir desdites données, en tenant compte de la bande passante disponible dans ledit réseau, un premier flux de données ayant un débit permettant de respecter ladite première latence ; - des moyens pour transmettre ledit premier flux de données auxdits premier et second clients ; - des moyens pour déterminer, à partir des données non comprises dans ledit premier flux de données, en tenant compte de la bande passante disponible dans ledit réseau, un second flux de données ayant un débit permettant de respecter ladite seconde latence ; et - des moyens pour transmettre ledit second flux de données audit second client. 10. Serveur selon la revendication 9, caractérisé en ce que les moyens de détermination du premier flux sont adaptés à déterminer la bande passante instantanée disponible dans ledit réseau (100) et en ce que le débit du premier flux est inférieur ou égal à la bande passante instantanée disponible déterminée. 11. Serveur selon la revendication 9, caractérisé en ce les moyens 30 de détermination du premier flux sont adaptés à déterminer la bande passante moyenne disponible dans ledit réseau (100) sur une période de temps correspondant à la première latence et en ce que le débit du premier flux est inférieur ou égal à la bande passante moyenne disponible déterminée. 12. Serveur selon la revendication 9, 10 ou 11, dans lequel les données sont codées suivant un premier niveau de qualité et un second niveau de qualité supérieur au premier niveau, caractérisé en ce que ledit premier flux comprend au moins une partie des données ayant ledit premier niveau de qualité et ledit second flux comprend au moins une partie des données ayant ledit second niveau de qualité. 13. Serveur selon la revendication précédente, dans lequel les données sont organisées en paquets, une date de création étant associée à chaque paquet, caractérisé en ce qu'il comporte des moyens adaptés à comparer la date de création des paquets non transmis ayant ledit premier niveau de qualité avec la date courante et à déterminer si la différence entre ces deux dates est inférieure à ladite première latence diminuée du temps de transmission entre le serveur (101) et ledit premier client. 14. Serveur selon la revendication 9, 10 ou 11, dans lequel les données sont codées suivant une première pluralité de niveaux de qualité et une seconde pluralité de niveaux de qualité supérieurs aux niveaux de ladite première pluralité de niveaux, caractérisé en ce que lesdits moyens de détermination du premier flux de données sont adaptés à : - déterminer la bande passante instantanée (Dl) du réseau (100) ; - comparer ladite bande passante instantanée (Dl) et la bande passante du niveau de qualité maximal (Lb) de ladite première pluralité de niveaux de qualité ; - si ladite bande passante instantanée (Dl) est inférieure à ladite bande passante du niveau de qualité maximal (Lb), diminuer (720) le niveau de qualité maximal (Lb) de ladite première pluralité de niveaux de qualité de façon que la bande passante du niveau de qualité maximal diminué soit inférieure à ladite bande passante instantanée (Dl) et que la bande passante du niveau de qualité immédiatement supérieur au niveau de qualité maximal diminué soit supérieure à ladite bande passante instantanée (Dl). 15. Serveur selon l'une quelconque des revendications 9 à 14, caractérisé en ce que le réseau de communication (100) est un réseau sans fil. 16. Serveur selon l'une quelconque des revendications 9 à 15, caractérisé en ce que le flux de données est un flux vidéo. 17. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé de transmission selon l'une quelconque des revendications 1 à 8. 18. Moyen de stockage selon la revendication 17, caractérisé en ce qu'il est partiellement ou totalement amovible. 19. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de transmission selon l'une quelconque des revendications 1 à 8, lorsque ce programme est chargé et exécuté par l'appareil programmable.