FR2946820A1 - Procede de transmission de donnees et dispositif associe. - Google Patents

Abstract

Procédé de transmission d'un flux de données d'images vidéo entre un serveur et au moins un dispositif client dans un réseau de communication, mettant en oeuvre une consigne de débit pour la transmission de données sur le réseau de communication, le procédé comprenant les étapes suivantes : - obtention (910) d'une information P représentative d'une vitesse de variation dans le temps d'une consigne de débit, ladite information étant fonction d'au moins une caractéristique de l'état du trafic sur le réseau de communication, - comparaison (920) de ladite information P ainsi obtenue avec une échéance E d'un ensemble de données d'images vidéo à transmettre, - adaptation (930) de la consigne de débit délivrée par le serveur en fonction au moins du résultat de l'étape de comparaison, - compression dudit ensemble de données d'images vidéo à transmettre suivant un mode de compression qui est fonction de la consigne de débit adaptée, - transmission dudit ensemble de données d'images vidéo ainsi compressées.

Description

La présente invention concerne un procédé de transmission de données et un dispositif associé. Dans le cadre de la transmission de flux multimédia (audio et vidéo) par paquets sur Internet ou sur des réseaux locaux de type IP ( Internet Protocol ) (en anglais local area network ou LAN), un serveur de données multimédia doit émettre un ou plusieurs flux de données (de type vidéo, audio, texte ou autres) vers un ou plusieurs dispositifs clients. Dans de nombreuses situations, un client reçoit et consomme ces données au fur et à mesure de leur réception. Par exemple, le client joue la vidéo et l'audio au fur et à mesure qu'il les reçoit. On parle de multimedia streaming . Les flux multimédia sont alors caractérisés par le fait qu'ils sont constitués de données (images, portions d'images ou slices , portions de sons ou samples ) dont la durée de vie utile est limitée, c'est-à-dire que ces données doivent nécessairement être reçues et traitées par le périphérique récepteur avant une certaine échéance. Cette échéance correspond à l'instant où la donnée est requise pour être affichée ou jouée par le client. Au-delà de cette échéance, la donnée devient inutile et est purement ignorée par le client. Par exemple, dans une application de vidéo conférence, pour maintenir une bonne interactivité et donc une bonne qualité pour les utilisateurs, les échéances doivent être typiquement inférieures à 120 millisecondes. Par ailleurs, pour obtenir des débits de données émises compatibles avec celui du réseau physique utilisé, les flux de données sont généralement compressés.

Des exemples de normes de compression pour des données vidéo sont les normes MPEG 2, MPEG 4 partie 2 ou encore H.264, et pour des données audio, les normes de compression AMR, G.711, G.722.1 et AAC.

Suivant la résolution (taille des images), la qualité, et la complexité des flux à compresser, les tailles de flux peuvent varier entre lMb/s (flux de petite résolution et de basse qualité pour un téléphone portable) et 100Mb/s (flux de haute définition de très bonne qualité).

La qualité d'un flux multimédia compressé dépend de plusieurs facteurs. Tout d'abord, les méthodes de compression utilisées sont des compressions avec pertes, c'est-à-dire que plus la compression est forte, plus la donnée multimédia est dégradée.

D'autre part, la qualité d'une vidéo est aussi fonction des vitesses de variation du niveau de compression. L'oeil humain est sensible aux brusques changements de qualité dans le temps, par exemple d'une image à l'autre. Pour maintenir une bonne qualité dans une vidéo, il faut donc éviter de changer le niveau de compression trop rapidement.

Enfin, à cause de la compression, les redondances sont supprimées dans le flux multimédia. Toute erreur introduite dans le flux, par exemple pendant la transmission, peut donc avoir des conséquences durant un temps relativement long et peut donc provoquer une baisse de qualité qui se propage. De plus en plus d'équipements disponibles pour le grand public, tels que caméscope, appareil photo, caméra de vidéo surveillance, serveur de vidéo domestique, récepteur TV, ordinateur, téléphone, sont capables d'envoyer de tels flux de données. Les flux multimédias (vidéo, audio, texte) destinés à être envoyés peuvent être stockés et compressés à l'avance sur l'appareil émetteur ou, au contraire, être capturés ou reçus d'un premier réseau, compressés immédiatement et envoyés à la volée sur un réseau de communication à destination d'un appareil récepteur. Ces flux multimédia sont transmis sur des réseaux de communications constitués de noeuds d'interconnexion (routeurs, commutateurs, etc.) afin d'orienter et de transmettre les paquets de données depuis les dispositifs source jusqu'aux dispositifs destinataires. Ils partagent ces réseaux de communication avec d'autres flux de données (par exemple de la navigation Internet, un jeu vidéo, ou le transfert d'un fichier vers une imprimante). Tous ces flux de données sont susceptibles de créer de la congestion sur les réseaux de communication quand ils transitent par un même lien réseau de capacité insuffisante. Les paquets en surplus finissent par être détruits par le noeud d'interconnexion situé à l'entrée du lien. La structure du réseau n'est pas connue par les dispositifs émetteurs et récepteurs. En effet, dans le cas de dispositifs portables, ces derniers peuvent être déplacés et branchés à des réseaux différents. Chaque dispositif peut aussi communiquer avec des dispositifs différents à travers des réseaux différents. De même, les flux présents ne se connaissent pas et leur nombre et leur comportement peuvent être très variables dans le temps. Le dispositif émetteur ne connait donc pas à l'avance les caractéristiques du réseau qui va être utilisé. Il doit donc détecter et s'adapter dynamiquement aux conditions courantes qui peuvent varier en cours de communication. De plus, les caractéristiques des réseaux sont variables. Par exemple, le temps de communication aller retour peut varier entre 0,1 ms (cas d'un réseau local) à 300 ms (cas d'une communication inter continentale).

Egalement, le débit peut varier entre 1 Gb/s (cas d'un réseau local) et quelques Mb/s (cas d'un accès Internet ADSL montant). Idéalement, un équipement doit détecter et s'adapter à ces différentes conditions. Traditionnellement, les serveurs et les clients utilisent des protocoles de communication mettant en oeuvre des mécanismes de contrôle de congestion afin d'éviter de perdre continuellement une grande quantité de données en cas de congestion et de garantir une utilisation équitable du réseau. Ces algorithmes permettent de détecter la présence de congestion en fonction des pertes de paquets. Ils agissent sur le débit d'émission du flux de données afin de le réduire ou de l'augmenter de manière à être compatible avec la bande passante globale du réseau.

Par ailleurs, dans le cas d'une transmission multimédia avec des échéances limitées, il est nécessaire d'adapter le débit de codage du flux multimédia au débit courant disponible sur le réseau par l'intermédiaire d'un algorithme de contrôle du débit de codage.

En effet, si le flux multimédia est de taille trop importante, certains paquets ne pourront pas être envoyés à temps. Un débit multimédia plus grand que le débit réseau provoque ainsi des pertes et donc une forte baisse de la qualité. Dans le même temps, un débit multimédia trop faible réduit aussi la qualité à cause de la compression. Il est donc nécessaire d'ajuster la compression pour l'adapter au débit disponible sur le réseau. Le débit de transmission calculé par certains algorithmes de contrôle de congestion peut varier de manière très rapide. Par exemple, l'algorithme AIMD ( Additive Increase Multiplicative Decrease ) qui est l'algorithme classique de TCP ( Transmission Control Protocol , l'un des protocoles de base d'Internet) peut diviser brusquement le débit par deux. D'autres algorithmes, comme TFRC ( TCP Friendly Rate Control ) ont également été proposés. On connaît du document "Comparison of equation based and AIMD congestion controt' de Floyd et al., Technical report ACIRI, disponible à l'adresse httpitwww.icir.orgItfrclaimd.pdf, une méthode utilisant une évaluation des caractéristiques du contrôle de congestion GAIMD, en particulier la période d'oscillation du contrôle de congestion. La variabilité du contrôle de congestion est évaluée, les caractéristiques du réseau sont prises en compte, et plusieurs paramètres de contrôle de congestion sont évalués.

On connaît également du document US 7 394 762 B2 une méthode pour modifier les paramètres du contrôle de congestion de type GAIMD, pour améliorer le comportement d'un flux dans un réseau à haut débit, tout en maintenant la compatibilité avec les flux TCP dans les réseaux à bas débit. Les algorithmes de contrôle de congestion connus ne permettent pas d'avoir un taux de compression qui varie toujours de manière douce, ce qui entraine un rendu vidéo de mauvaise qualité pour l'oeil humain dans certains cas.

L'invention permet de résoudre ce problème en proposant un contrôle de congestion adapté aux conditions du réseau et permettant d'obtenir une bonne qualité pour le flux multimédia avec des variations de taux de compression lissées.

Pour cela il est proposé un procédé de transmission d'un flux de données d'images vidéo entre un serveur et au moins un dispositif client dans un réseau de communication, mettant en oeuvre une consigne de débit pour la transmission de données sur le réseau de communication, le procédé comprenant les étapes suivantes : - obtention d'une information P, représentative d'une vitesse de variation dans le temps d'une consigne de débit possible, ladite information étant fonction d'au moins une caractéristique de l'état du trafic sur le réseau de communication, - comparaison de ladite information Pc ainsi obtenue avec une 15 échéance Eä d'un ensemble de données d'images vidéo à transmettre, û adaptation de la consigne de débit délivrée par le serveur en fonction au moins du résultat de l'étape de comparaison, - compression dudit ensemble de données d'images vidéo à transmettre suivant un mode de compression qui est fonction de la consigne de 20 débit adaptée, - transmission dudit ensemble de données d'images vidéo ainsi compressées. Ce procédé permet d'avoir un taux de compression qui varie de manière douce, ce qui offre un bon rendu à l'oeil humain. Cela est obtenu grâce 25 à l'adaptation de la consigne de débit en fonction de la comparaison entre l'échéance des données et la vitesse de variation qui serait obtenue pour une consigne de débit candidate (consigne de débit possible). Selon une caractéristique avantageuse, en fonction du résultat de l'étape de comparaison, le mode de compression est soit adapté en fonction 30 d'une moyenne de valeurs de la consigne de débit adaptée prises pendant une période de temps d'ordre de grandeur égal à l'échéance Ev, soit adapté en fonction d'une valeur instantanée de ladite consigne de débit.

Ainsi, la valeur de consigne de débit prise en compte pour la compression est adaptée aux contraintes d'utilisation du client. Selon une autre caractéristique avantageuse, l'échéance Eä dépend d'une valeur de cadence des images du flux de données.

Une telle valeur d'échéance est facile à obtenir. De plus, cette caractéristique permet d'éviter d'avoir une mémoire tampon de taille importante sur le serveur. Selon une autre caractéristique avantageuse l'échéance Eä dépend de contraintes temporelles d'utilisation du dispositif client.

Cela permet de tenir compte précisément des échéances réelles liées à l'utilisation des données par le dispositif client, et d'offrir une meilleure utilisation des ressources de celui-ci. Selon une mise en oeuvre intéressante, en fonction du résultat de l'étape de comparaison, la consigne de débit adaptée est soit une consigne considérée, soit une consigne alternative. Cette caractéristique offre une plus grande flexibilité dans le choix d'adaptation de la consigne de débit réseau. Selon une autre caractéristique avantageuse, la consigne de débit alternative est la fonction TFRC.

La fonction TFRC est standardisée, par exemple dans le protocole DCCP (IETF RFC 4342), et est donc disponible sur de nombreux systèmes. Elle offre l'avantage d'avoir un comportement équitable par rapport à des flux TCP (contrôlés par une consigne de type AIMD) et d'offrir une vitesse de variation de consigne plus lente que AIMD.

Selon une alternative également intéressante, la consigne de débit alternative est une fonction GAIMD lissée. Cela permet une transmission du flux de données d'images vidéo sur le réseau sur lequel sont transmis simultanément d'autres flux de données avec la fonction AIMD, la transmission étant assurée avec une bande passante demandée qui est égale à celle d'un flux de données transmis de façon concurrente avec la fonction AIMD.

Ainsi, la consigne alternative (qu'il s'agisse de TFRC ou d'un GAIMD lissé) a un comportement équitable vis-à-vis des autres flux présents sur le réseau et qui sont, pour la plupart, des flux AIMD. De plus, les tailles des images successives varient doucement, ce qui donne des variations de qualité douces et donc globalement un bon rendu pour la vidéo. L'algorithme GAIMD offre l'avantage d'avoir un comportement facilement analysable, une implémentation très proche de celle de l'algorithme AIMD qui ne nécessite donc pas de développements importants (pas de création de nouveaux messages en particulier, ni de modification au niveau du dispositif client). Enfin l'algorithme GAIMD permet d'avoir plusieurs consignes différentes avec des comportements variés : on peut en particulier avoir différentes vitesses de variations de consignes adaptées à différentes caractéristiques du trafic sur le réseau. Selon une caractéristique intéressante, la consigne de débit 15 considérée est la fonction AIMD. L'algorithme AIMD étant une consigne courante sur les réseaux IP, il est ainsi facile de la mettre en oeuvre, notamment quand des flux concurrents sont présents sur le réseau. L'invention consiste également, suivant une deuxième définition 20 générale, en un dispositif de transmission d'un flux de données d'images vidéo entre un serveur et au moins un dispositif client dans un réseau de communication, mettant en oeuvre une consigne de débit pour la transmission de données sur le réseau de communication, le dispositif comprenant des moyens pour : 25 - obtenir une information Pc représentative d'une vitesse de variation dans le temps d'une consigne de débit possible, ladite information étant fonction d'au moins une caractéristique de l'état du trafic sur le réseau de communication, - comparer ladite information Pc ainsi obtenue avec une échéance Eä 30 d'un ensemble de données d'images vidéo à transmettre, û adapter la consigne de débit délivrée par le serveur en fonction au moins du résultat de l'étape de comparaison, - compresser ledit ensemble de données d'images vidéo à transmettre suivant un mode de compression qui est fonction de la consigne de débit adaptée, - transmettre ledit ensemble de données d'images vidéo ainsi 5 compressées. Les caractéristiques relatives au procédé selon l'invention qui ont été présentées ci-dessus s'appliquent également au dispositif ainsi défini. C'est également le cas des avantages précités. Selon une troisième définition générale de l'invention, celle-ci 10 consiste en un programme d'ordinateur comprenant une suite d'instructions aptes, lorsqu'elles sont exécutées par un microprocesseur, à mettre en oeuvre un procédé selon l'invention. Les caractéristiques relatives au procédé selon l'invention qui ont été présentées ci-dessus s'appliquent également au programme d'ordinateur ainsi 15 défini. C'est également le cas des avantages précités. L'invention va maintenant être présentée en détails, en relation avec les figures annexées, parmi lesquelles, - la figure 1 est un schéma d'un réseau de communication de données, dans le contexte duquel la présente invention peut être mise en 20 oeuvre ; - la figure 2 représente une architecture de dispositif émetteur auquel peut s'appliquer l'invention ; - la figure 3 représente les modules fonctionnels d'un dispositif émetteur selon un mode de réalisation de l'invention ; 25 - la figure 4 représente une séquence d'images codées suivant un type de codage vidéo auquel l'invention peut s'appliquer ; - la figure 5 représente une évolution au cours du temps de la consigne donnée par un module de contrôle de congestion à un module ordonnanceur de paquets ; 30 - la figure 6 représente le niveau de remplissage de la mémoire tampon d'envoi d'un dispositif émetteur comme celui de la figure 2 au cours du temps, alors que le débit demandé par le module de contrôle de congestion varie ; - la figure 7 représente une compression d'images successives en présence d'un débit demandé par un module de contrôle de congestion dans une première situation selon l'art antérieur ; - la figure 8 représente une compression d'images successives en présence d'un débit demandé par un module de contrôle de congestion dans une deuxième situation selon l'art antérieur ; - la figure 9 représente un algorithme de choix d'un algorithme de module de contrôle de congestion selon un mode de réalisation de l'invention ; - la figure 10 représente la simulation d'une consigne donnée par un module de contrôle de congestion à un module ordonnanceur de paquets, effectuée à un instant donné, au cours d'une mise en oeuvre d'un mode de réalisation de l'invention ; - la figure 11 illustre un une compression d'images successives en présence d'un débit demandé par un module de contrôle de congestion dans une première situation, au cours d'une mise en oeuvre d'un mode de réalisation de l'invention ; - la figure 12 représente un une compression d'images successives en présence d'un débit demandé par un module de contrôle de congestion dans une deuxième situation, au cours d'une mise en oeuvre d'un mode de réalisation de l'invention. La figure 1 montre un exemple de réseau de communication de données dans lequel 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 dispositif client 102 à travers un réseau de communication 100. Le réseau 100 peut contenir des noeuds d'interconnexion 103 (aussi appelés routeurs) et des liaisons 104 qui créent des chemins entre les dispositifs émetteur et récepteur. Le même réseau peut être utilisé par de nombreux dispositifs serveurs et clients mettant ou non en oeuvre l'invention.

Les noeuds d'interconnexion 103 reçoivent les paquets, les mémorisent temporairement dans une mémoire locale, puis les retransmettent dès que possible sur un lien de sortie. 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 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, b ou g), ou un réseau Ethernet, ou encore, tel Internet, il peut être composé de liens de différents types. Le dispositif émetteur 101 peut être n'importe quel type de dispositif de traitement de données susceptible de compresser et de transmettre un flux de données compressées à un dispositif récepteur. A titre d'exemple nullement limitatif, le dispositif émetteur 101 peut être un serveur de flux capable de fournir un contenu à des clients sur demande, par exemple en utilisant le protocole RTP (protocole de transport en temps réel, en anglais "Real-time Transport Protocof'), UDP (protocole de datagramme utilisateur, en anglais "User Datagram Protocof') ou DCCP (protocole de contrôle de congestion de datagramme, en anglais "Datagram Congestion Control Protocof') ou n'importe quel autre type de protocole de communication. Le dispositif émetteur 101 peut mettre en oeuvre un algorithme de 20 contrôle de congestion du type mentionné plus haut, à savoir, TFRC ou encore AIMD. La figure 2 illustre un exemple de 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 25 de traitement (UC) 201 capable d'exécuter des instructions de programmes informatiques provenant d'une mémoire morte (ROM) 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. 30 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 5 de la mémoire ROM de programmes 203 par exemple. De façon générale, un moyen de stockage d'informations qui peuvent être lues par un ordinateur ou par un microprocesseur, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. 10 Ce moyen de stockage est intégré ou non au dispositif 101 et est éventuellement amovible. L'exécution du ou des programmes mentionnés ci-dessus peut avoir lieu, par exemple, lorsque les informations stockées dans le moyen de stockage sont lues par l'ordinateur ou par le microprocesseur. L'application logicielle, lorsqu'elle est exécutée par l'UC 201, 15 entraîne l'exécution des étapes du procédé selon l'invention. 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 paquets en provenance d'autres dispositifs 102 reçus 20 par le biais de l'interface réseau 204 et pour fournir des paquets à d'autres dispositifs 102 par l'intermédiaire du réseau 100. Le dispositif émetteur 101 peut comporter en outre une interface utilisateur 205, comprenant par exemple un écran, un clavier ou un dispositif de pointage tel qu'une souris ou un crayon optique, pour afficher des informations 25 pour un utilisateur ou bien recevoir des entrées de celui-ci. Cette interface est optionnelle. Le dispositif émetteur 101 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 30 vidéosurveillance (par exemple du type Webcam), un lecteur DVD, un serveur multimédia ou bien encore un élément routeur dans un réseau.

Le dispositif émetteur 101 peut comprendre un capteur numérique d'images, ou être connecté à différents périphériques tels que, par exemple, une caméra numérique, un scanner ou tout moyen d'acquisition ou de stockage d'images relié à une carte graphique et fournissant à l'appareil des données multimédia. Le dispositif émetteur 101 peut aussi avoir accès à des données multimédia sur un support de stockage (par exemple le disque dur 206) ou encore recevoir un flux multimédia à traiter, par exemple en provenance d'un réseau. En référence à la figure 3, le serveur 101 dispose en entrée d'une 10 source de données vidéo en provenance par exemple d'un capteur, qui peut être une caméra 305, ou un lecteur de disque. Les données vidéo sont fournies à un codeur vidéo ou codec (module de codage-décodage) 310 qui code ou compresse la vidéo dans un format connu (par exemple H264) avant de stocker le résultat dans une 15 mémoire tampon (buffer) 325 sous forme de paquets prêts à être envoyés. Le fonctionnement de la mémoire tampon 325 sera décrit plus en détail en relation avec la figure 6. Selon une variante de réalisation, des données vidéo déjà compressées sont reçues en provenance d'un autre réseau. On peut par 20 exemple utiliser une passerelle résidentielle ( home gateway ) recevant une chaîne de télévision par Internet. Dans ce cas, le codec permet de transcoder la vidéo pour adapter son débit à la bande passante du réseau domestique qui peut être un réseau sans fil. Comme dans le premier cas, les données créées sont stockées dans la mémoire tampon 325. 25 Le codeur vidéo 310 est contrôlé par un module de contrôle de débit de codage vidéo 320. Celui-ci détermine des paramètres de fonctionnement pour le codeur 310, notamment la quantité et le type de données à produire. Pour cela, il utilise des informations de consigne de débit réseau délivrées par un module de contrôle de congestion 335, ainsi que le nombre de paquets en 30 attente dans la mémoire tampon 325. Le fonctionnement du module de contrôle de débit de codage vidéo 320 sera décrit plus en détail en relation avec la figure 4.

Les paquets stockés dans la mémoire tampon 325 sont lus et transmis sur le réseau par le module ordonnanceur de paquets 330 chargé de l'envoi des paquets. L'algorithme de l'ordonnanceur de paquets 330 décide des dates ou instants d'envoi (échéances) des paquets en fonction de la consigne de débit réseau instantané délivrée par l'algorithme du module de contrôle de congestion 335. Pour ce faire, l'ordonnanceur de paquets 330 est activé de manière répétée, soit par l'ordonnanceur 330 soit par une horloge (non représentée, mais présente dans le serveur 101).

L'ordonnanceur peut aussi s'activer par lui-même, grâce à un algorithme d'attente active. Selon une variante, on déclenche l'ordonnanceur lors de la réception de paquets réseau provenant du dispositif récepteur 102 (cette méthode est couramment utilisée), ou lors d'un autre événement déclencheur.

Lorsqu'il est activé, l'ordonnanceur 330 utilise la consigne de débit réseau instantané calculée par le module de contrôle de congestion 335 pour calculer le nombre de paquets à envoyer de telle sorte que la consigne soit respectée. Ensuite, l'ordonnanceur 330 envoie sur le réseau un nombre de paquets tel que calculé.

L'algorithme du module de contrôle de congestion 335 estime le débit disponible sur le réseau 100. Pour effectuer ce calcul le module 335 utilise les informations reçues du client 102 à travers le réseau 100. Il s'agit, notamment, des informations d'occurrence de pertes de paquets et de la valeur de temps de communication aller retour sur le réseau du récepteur 102 à l'émetteur 101 (RTT Round Trip Time ). Ces informations sont déterminées par le récepteur 102 et transmises classiquement en utilisant les messages RTCP ( Real-time Transport Control Protocol ) du protocole RTP. L'algorithme du module de contrôle de congestion 335 sera présenté en détail en relation avec la figure 5.

La figure 4 représente schématiquement une séquence d'images compressées selon un format de compression vidéo tel que H.264 ou MPEG-4 partie 2. Il s'agit de formats basés sur l'application d'une transformation par blocs (par exemple une Transformation en Cosinus Discrète, dite DCT, dans le cas du format MPEG4 partie 2) de la séquence vidéo, sur la compensation de mouvement et sur une quantification. Classiquement, une séquence 400 codée selon un tel format contient des images de type I (ou images INTRA) 401, qui sont décodables indépendamment des autres images de la séquence, et des images Inter qui sont décodables à l'aide d'une ou de plusieurs images voisines. Parmi les images Inter, on distingue les images de type P (ou images prédites) 402 et les images de type B (ou images bi-prédites) 403.

On définit des groupes d'images ( group of images GOP) constitués d'une image de type I suivie d'un nombre prédéterminé d'images de type P ou B. La taille des images de type I, P et B est variable. Généralement, les images de type I sont moins compressées car leur compression n'utilise pas de compensation de mouvement. Les images de type P sont mieux compressées que les images I et les images de type B sont les plus compressées. Les images sont compressées par macro-blocs, qui sont des blocs de 16x16 pixels groupés en tranches ( slices ) 420. Dans le cas d'un envoi d'une vidéo sur un réseau, chaque tranche 420 est mise dans un ou plusieurs paquets RTP et transmise sur le réseau vers le récepteur. Plusieurs paramètres peuvent être modifiés par le module de contrôle de débit de codage vidéo 320 pour moduler le taux de compression d'une vidéo. Par exemple, le pas de quantification peut être modifié, pour chaque bloc intra et inter. Certaines images peuvent également être supprimées, ce qui induit un changement de fréquence d'affichage. La structure du groupe d'images GOP est ainsi modifiée. Le taux de compression obtenu pour un ensemble de paramètres n'est pas fixe car le résultat de la compression dépend du type d'image et de vidéo et du contenu de la scène. Notamment, le taux de compression dépend de la quantité d'informations non redondantes présentes dans la séquence d'origine.

Par exemple, un film avec une scène statique ou un petit objet en mouvement de translation régulier peut être fortement compressé, mais pas un film d'action qui contient une grande quantité de données non redondantes. Les techniques décrites peuvent être appliquées lors d'un codage ou d'un transcodage d'une vidéo. Dans le cas d'un codage, un capteur numérique (comme le capteur 305 de la figure 3) génère des images qui sont ensuite codées. En début du groupe d'images GOP, une image I est générée, puis les images suivantes sont compressées en mode P ou B suivant la structure du GOP.

Dans le cas d'un transcodage, la vidéo représentée a déjà été codée auparavant mais son taux de compression doit être modifié pour faire baisser le débit de la séquence. D'autres techniques de compression et d'adaptation de bande passante peuvent être utilisées. Par exemple, certains codages permettent d'avoir un codage sur plusieurs niveaux (codage extensible ou scalable video coding ). La vidéo est alors composée de plusieurs couches. Chaque couche ajoute des informations supplémentaires et donc du débit en plus, améliorant par conséquent la qualité du rendu visuel final. L'adaptation du débit consiste alors à sélectionner le nombre de couches que l'on désire.

L'algorithme du module de contrôle de débit de codage vidéo 320 calcule d'abord la taille de la prochaine image pour respecter les objectifs de débit réseau (consigne) fixés par le module de contrôle de congestion 335 et ne pas faire déborder la mémoire tampon 325 de sortie. Si on note T la quantité de données dans la mémoire tampon 325, C la consigne reçue du contrôle de congestion, Ev la durée maximale avant envoi des données de la prochaine image, et M la taille maximale de la prochaine image, cette dernière s'exprime sous la forme suivante M = C Ev û T. L'algorithme du module de contrôle de débit de codage vidéo 320 calcule ensuite les paramètres de compression optimisés pour respecter la taille ainsi calculée tout en maximisant la qualité du rendu final de la vidéo. Une technique classique consiste à utiliser un modèle débit-distorsion. A titre d'exemple, des modèles connus utilisés dans le cadre de la compression MPEG sont TMN-5 ou TMN-8. L'algorithme du module de contrôle de débit de codage vidéo 320 est appelé régulièrement pour calculer les modes de compression et les pas de quantification pour chaque image et chaque macrobloc. Suivant le type du codec 310 utilisé, l'algorithme du module 320 peut être appelé pour chaque image, chaque macrobloc ou une seule fois par GOP. Nous appellerons Fv la fréquence à laquelle l'algorithme du module de contrôle de débit de codage vidéo 320 est activé et prend en compte la consigne de débit réseau calculée par le module de contrôle de congestion 325. Par exemple, dans le cas d'une vidéo à 50 images par seconde, si l'algorithme de contrôle de débit de codage vidéo est exécuté à chaque nouvelle image compressée, il sera exécuté toutes les 20 ms, c'est-à-dire selon une fréquence Fä de 50Hz.

Classiquement, l'algorithme du module de contrôle de débit de codage vidéo 320 est activé à chaque image. Il prend alors en compte la consigne de débit réseau pour calculer la taille et le type de l'image suivante. Ensuite, chaque macrobloc est compressé par le codec 310. Le pas de quantification de chaque macrobloc est ensuite évalué en fonction des tailles des macroblocs compressés précédemment pour atteindre la taille cible et du modèle débit distorsion. Le modèle est lui-même remis à jour en fonction des résultats des compressions des macroblocs. La méthode présentée est également applicable quand l'algorithme de contrôle de débit est exécuté pour chaque macrobloc ou chaque tranche.

En référence à la figure 51 l'algorithme du module de contrôle de congestion 335 calcule la quantité de données à envoyer sur le réseau par le module ordonnanceur de paquets 330. La valeur de débit ainsi calculée par le module de contrôle de congestion 335 est la consigne de débit réseau précédemment présentée en figure 3. Cette consigne est représentée en ordonnées (en nombre de paquets par envoi) en fonction du temps représenté en abscisses.

Le nombre de paquets à transmettre est adapté à l'état de congestion du réseau. Si le réseau est encombré, l'envoi des paquets est lissé dans le temps. L'algorithme du module de contrôle de congestion 335 le plus connu 5 est celui de TCP qui est de type AIMD ( Additive Increase Multiplicative Decrease ). Cet algorithme calcule un nombre de paquets à envoyer pendant un temps de communication aller retour (RTT pour Round Trip Time ), appelé fenêtre W (pour Window ), et l'augmente de manière progressive tant que le 10 dispositif client 102 signale que les paquets sont bien reçus. En moyenne l'algorithme AIMD commande l'envoi d'un paquet de données supplémentaire à chaque réception d'une information d'aller retour satisfaisante, ce qui induit une augmentation linéaire de W. Lorsque le module de contrôle de congestion constate qu'une perte 15 de paquets est intervenue sur le réseau, cela signifie que le réseau est congestionné. En réaction la taille de la fenêtre W est divisée par 2, c'est-à-dire que moitié moins de paquets seront dorénavant transmis pendant un RTT. Ceci entraîne une diminution du débit de paquets émis par le module ordonnanceur de paquets 330 d'un facteur 2. 20 Lorsqu'il n'y a pas de pertes sur le réseau 100, la consigne de débit augmente linéairement en fonction du temps. Les événements de pertes 510, 512, 514, 516 provoquent par contre une chute du débit demandé au module ordonnanceur de paquets 330. On peut parfois avoir plusieurs événements de pertes très rapprochés tels 514, 516 et donc une baisse rapide et importante du 25 débit demandé. A cause du temps de transmission du dispositif serveur au dispositif client et du temps pour recevoir l'information de bonne réception du dispositif client au dispositif serveur, l'algorithme AIMD a un comportement qui est lié au temps de communication aller retour du réseau (RTT). 30 Dans un réseau local ou à courte distance, la valeur de RTT peut être de l'ordre de 0.1 milliseconde. On peut donc avoir des variations de débit réseau rapides au vu de la vitesse du codeur 310, qui peut être d'une image toute les 20 ms (cadence des images du flux de données). Comme l'algorithme AIMD, un algorithme de type TFRC (pour TCP Friendly Rate Control ) fonctionne en utilisant les événements de pertes de paquets, ainsi qu'un calcul de RTT. Il calcule la consigne de débit en suivant une équation qui doit donner un débit comparable à celui de l'algorithme TCP avec un temps RTT équivalent, mais avec des variations plus lissées. Les baisses et les augmentations sont moins rapides que celles de l'algorithme AIMD mais, confronté aux mêmes conditions qu'AIMD, l'algorithme TFRC utilise en moyenne la même fraction de la bande passante. Dans le cas de l'algorithme TFRC, le module de contrôle de congestion 335 se trouve au niveau du dispositif client 102. Le calcul du débit disponible est donc réalisé par le client qui transmet ainsi la consigne de débit évaluée au serveur 101.

Dans les deux cas, le module de contrôle de congestion 335 utilise des informations liées aux événements de perte ainsi que le temps d'aller retour sur le réseau (RTT). En utilisant ces informations, il calcule une valeur de débit réseau disponible estimée. Il peut donc informer le module ordonnanceur de paquets 330 d'une estimation du débit disponible sur le réseau pour la transmission de données sur le réseau. La valeur de débit disponible estimée (consigne de débit réseau) est également fournie au module de contrôle de débit de codage vidéo 320 afin que celui-ci puisse l'utiliser pour contrôler la taille des prochaines images compressées par le codeur 310.

Il existe de nombreux algorithmes de contrôle de congestion. Le mode de réalisation décrit ici utilise l'algorithme GAIMD ( Generalized Additive Increase Multiplicative Decrease ). Cependant, l'invention est applicable à n'importe quel autre algorithme de contrôle de congestion. L'algorithme GAIMD(a,b), c'est-à-dire GAIMD utilisant les paramètres a et b qui sont des valeurs numériques positives non dimensionnées, est une généralisation de l'algorithme AIMD. La taille de la fenêtre W est évaluée à chaque retour d'information en provenance du client 102 qui acquitte les paquets reçus. La consigne de débit de transmission de données est par conséquent également réévaluée aussi souvent. Sur chaque période de temps aller retour sans erreur, la consigne de débit est augmentée d'un nombre de paquets égal à a. En cas d'erreur, la consigne de débit est multipliée par (1-b). On notera que b est compris entre 0 et 1 et que la multiplication du débit par (1-b) revient à réduire le débit. On notera en outre que l'algorithme GAIMD avec les valeurs de paramètres a=1 et b=0,5 correspond à l'algorithme AIMD. Par contre, d'autres valeurs peuvent être choisies. Par exemple GAIMD(0,3125 ; 0,13) a des propriété intéressantes : d'une part, il présente des variations lissées par rapport à l'algorithme AIMD et, d'autre part, il permet d'avoir un partage de bande passante équitable, ce qui lui permet d'être transmis sur un réseau de façon concurrente avec AIMD. C'est donc une alternative à l'algorithme TFRC. La figure 7 illustre, comme à la figure 5, une compression d'images contrôlée par le module de contrôle de débit de codage vidéo 320 suivant les indications d'un module de contrôle de congestion 335 qui fait varier rapidement la consigne de débit réseau 735 en fonction du temps (par exemple AIMD). Ainsi, des baisses de la consigne de débit réseau se produisent, par exemple, à un rythme qui est compris entre 1/4 et 1 fois le rythme d'émission des images.

Le codeur 310 prend en compte une nouvelle consigne de débit de codage vidéo à intervalles réguliers (d'une durée égale à 11Fä) aux instants 725, chacun de ces instants coïncidant avec une image à coder par exemple. Chaque image est envoyée avant l'image suivante à coder. Le temps d'envoi est représenté à titre d'illustration par la référence 730.

Une telle compression d'images présente deux inconvénients. Tout d'abord, le débit disponible pour l'envoi de l'image suivante est difficilement prévisible. Si le module de contrôle de débit de codage vidéo 320 se base sur la valeur courante de la consigne de débit réseau calculée par le module de contrôle de congestion 335, il risque de créer des images trop volumineuses dans certains cas. Elles ne pourront donc pas être envoyées à temps. C'est le cas de l'image 710 qui est compressée juste avant que le débit réseau ne diminue fortement et envoyée en partie après cette diminution de débit réseau. Dans d'autres cas, les images créées peuvent être trop petites compte tenu du débit réseau disponible. C'est le cas par exemple de l'image 720. Ensuite, la vidéo est de mauvaise qualité, car l'oeil humain est sensible aux variations de résolution des images dans une vidéo. Par exemple, la baisse brutale des tailles des images 710, 715 et 720 donne une mauvaise qualité visuelle. Les variations brutales de taille d'une image à l'autre sont à éviter au maximum. Il convient de noter que la figure est ici simplifiée pour ne pas surcharger l'exposé. Le temps d'envoi 730 de chaque image est artificiellement présenté comme constant. Cependant, comme expliqué en relation avec la figure 6 ci-dessous, le temps d'envoi réel est variable en fonction du débit réseau et du contenu de la mémoire tampon. Par contre, les dates 725 de prise en compte par le codeur 310 de la consigne de débit de codage vidéo fournie par le module de contrôle de débit de codage vidéo 320 sont bien périodiques comme l'illustre la figure. La figure 8 montre une autre mise en oeuvre au cours de laquelle la consigne de débit réseau (fournie par le module de contrôle de congestion 335 et représentée en ordonnée) varie lentement mais le rythme des variations est du même ordre de grandeur que la cadence de prise en compte par le codeur d'images 310 de la consigne de débit de codage vidéo fournie par le module de contrôle de débit de codage vidéo 320. Dans ce cas les variations de débit du réseau sont peu prédictibles et les changements de taille d'une image à l'autre sont très importants. On a donc aussi dans ce cas une qualité faible pour la vidéo. Pour pallier aux inconvénients ci-dessus, il est donc important que la vitesse de variation de la consigne de débit réseau, et donc le choix d'un algorithme de contrôle de congestion délivrant des consignes plus ou moins lissées, soit prise en compte pour garantir que les données soient envoyées à temps, tout en évitant une variation brutale dans la qualité. La figure 9 représente un algorithme selon un mode de réalisation de l'invention. Il permet de déterminer l'algorithme de contrôle de congestion le plus approprié permettant d'adapter le débit de codage vidéo au débit du réseau effectivement disponible lors de l'envoi des données codées (images compressées). Cet algorithme de détermination/sélection est exécuté par le dispositif serveur 101, au début de la transmission d'un flux, par exemple, lorsque la demande pour un nouveau flux est reçue. Il peut aussi être exécuté de nouveau en cours de transmission pour vérifier si l'algorithme de contrôle de congestion sélectionné est toujours adapté aux conditions qui ont varié (par exemple, l'état du trafic sur le réseau) ou s'il doit être modifié.

Tout d'abord, la première étape 900 de l'algorithme est une étape de détermination de la durée maximale dont dispose le serveur pour transmettre les données générées à partir du moment où elles lui sont envoyées par la source de données telle que le capteur 305 ou un lecteur de disque. Cette durée maximale (durée de validité d'un ensemble de données) est notée Ev.

Elle permet de déterminer, à partir du moment d'envoi des données par la source, la date d'échéance de l'ensemble des données de la vidéo, c'est-à-dire l'instant le plus tardif pour transmettre ces données. Dans un premier mode de mise en oeuvre, la durée Eä est choisie égale à la période séparant deux images de la vidéo. Dans ce premier mode de mise en oeuvre, la fréquence Fä est prise égale à la fréquence de réception des images, c'est-à-dire que le module de contrôle de débit de codage vidéo 320 prend en compte une nouvelle valeur de consigne de débit réseau à chaque image. On a donc dans ce cas Ev = 1/Fv. Ce choix est avantageux car Fä est une donnée facile à obtenir et la mise en oeuvre se fait, dans ce cas, sans que l'on n'ait besoin d'une mémoire tampon 325 de taille trop importante. Dans un deuxième mode de mise en oeuvre, on utilise comme échéance, la date d'envoi des images la plus tardive possible qui soit acceptable par le client. La durée maximale dont dispose le serveur pour transmettre les données est notée dans ce cas Pv. On a donc Ev = Pv. Ce choix est avantageux, dans la mesure où il permet de tenir compte de façon précise des échéances réelles liées aux données et à leur utilisation par le client. Il permet une meilleure utilisation des ressources du client. La figure 6 donne un exemple de calcul de la durée Pv mentionnée ci-dessus. Sur cette figure, on a représenté sur la courbe 6a les variations du niveau de remplissage de la mémoire tampon 325 (en ordonnées) en fonction du temps (représenté en abscisse), en réponse à une variation de la consigne de débit réseau (en nombre de paquets par envoi) calculé par le module de contrôle de congestion 335. Cette variation du débit en fonction du temps est représentée sur la courbe 6b.

Si le débit du réseau est fixe, la mémoire tampon 325 se remplit à chaque création d'une image compressée, puis se vide au rythme d'envoi des paquets sur le réseau. Idéalement, la mémoire tampon 325 est vide au moment où le module de compression 310 lui communique une image compressée qui est introduite en entier La mémoire se vide ensuite lentement et se retrouve vide avant ou, au plus tard, au moment où une nouvelle image compressée est introduite. Si la consigne de débit réseau baisse brutalement, la mémoire tampon 325 se vide plus lentement pendant une phase, qui sur la figure est représentée entre les instants t1 (repère 820) et t2. Elle n'est pas entièrement vide à l'instant d'arrivée 830 de l'image suivante. Cependant, le module de contrôle de débit de codage vidéo 320 réagit pour réduire la taille des images suivantes. Les tailles des images arrivant aux instants 830 et 835 sont plus faibles que la taille des images qui arrivaient avant l'instant t1 (820). Ces nouvelles tailles adaptées permettent à la mémoire tampon 325 de se vider progressivement. L'image arrivée à l'instant t1 (820) continue d'être transmise après que les images 830 et 835 ont été produites. Elle n'est totalement transmise qu'à l'instant 840. En fonction de l'application, le retard pris par cette image peut être tout à fait acceptable.

L'impact de ce retard dépend du temps maximum de réception de l'image qui est acceptable par le dispositif client 102. Si le dispositif client est en train d'afficher la vidéo, la date (ou l'instant) limite de réception par le client est égale à la date d'affichage de l'image. A titre d'indication, une valeur typique de la durée entre la date limite de réception par le client et la date de production d'une image dans le cas d'une vidéo conférence est de 125 ms. La durée limite d'envoi pour une image Pv doit tenir compte du temps de transfert dans le réseau. La durée Pv est égale au temps maximum de réception par le client duquel est soustrait le temps de transfert. Par exemple, dans le cas d'une vidéo conférence (retard maximal 125 ms) et d'un réseau avec un temps de communication aller retour de 10ms (RTT=10 ms) on peut estimer que le temps de transfert est égal à la moitié du RTT (5 ms) et donc que Pv = 120 ms. Dans le cas d'un temps RTT plus faible, l'impact du temps de transfert réseau est rapidement négligeable mais il peut être important pour les valeurs de RTT supérieures à 10 ms. La date (ou l'instant) limite d'envoi peut être calculée à partir d'informations fournies par le client dans des messages RTCP : date 15 d'affichage des images et temps de transfert réseau. A cause, d'une part, de la mémoire tampon 325 servant à l'envoi des images et, d'autre part, de l'échéance des images (cette échéance peut être plus longue que le temps inter image), la prédiction de taille d'une image doit être basée sur une prédiction ou estimation de débit moyen sur la durée 20 maximale d'envoi des images. De retour à la figure 9, l'étape suivante 910 consiste à obtenir, par exemple par calcul, une information représentative d'une vitesse de variation dans le temps d'une consigne de débit possible (valeur représentative du rythme d'oscillation du contrôle de congestion 335) à l'instant de mise en oeuvre 25 de l'algorithme de sélection, noté instant t. Cette valeur, qui est donc une valeur instantanée, est calculée suivant la méthode illustrée à la figure 10. En référence à la figure 10, on calcule une pseudo-période P d'une consigne de débit considérée possible, qui peut être la consigne délivrée par le module de contrôle de congestion actuellement sélectionnée (dite consigne 30 effective) représentée en figure 5, ou une consigne candidate que l'on envisage d'obtenir en sélectionnant un algorithme de contrôle de congestion différent, notamment un algorithme de référence, comme AIMD.

La figure 10 représente une courbe simulée de débit d'information en fonction du temps (comme en figure 5). La simulation est faite en tenant compte d'au moins une caractéristique instantanée de l'état réel du trafic sur le réseau prise à l'instant t.

Cette courbe simulée représente une consigne de débit considérée du type de celle obtenue par un algorithme GAIMD de paramètres a et b, et générant un débit moyen Bm identique à celui généré par la consigne effective à l'instant t. La valeur de Bm est calculée sur la base des valeurs prises par la consigne de débit effective pendant une période écoulée récente (qui peut être de quelques secondes). Pour l'étape 910, on prend (a, b) = (1, 0.5). La simulation de cette courbe est faite avec l'hypothèse (ou contrainte) que l'état du trafic sur le réseau (occurrence des événements de perte et temps d'aller-retour) amène l'algorithme GAIMD(a ; b) à émettre une commande de débit périodique de période P et de moyenne Bm. Cette hypothèse n'est en général pas vérifiée, comme on peut le voir en figure 5. C'est pour cela que la valeur calculée P est qualifiée de pseudo-période. La simulation peut également être faite en prenant en compte le temps d'aller-retour R entre le client et le serveur à l'instant t et la taille des paquets S à ce même instant.

Une méthode de calcul mise en oeuvre dans un mode de réalisation préféré est celle utilisée dans le document S. Floyd et al. mentionné plus haut. On appelle N le nombre d'aller-retour du serveur au client durant la période P, et on a P = N*R, où R désigne le temps aller-retour RTT. On appelle W la valeur maximale de la taille de fenêtre atteinte avant qu'une erreur ne se produise et que le débit ne baisse. Comme déjà mentionné, la fenêtre après erreur est égale à (1-b)W. Comme durant une période P un nombre N d'aller retour de durée R ont lieu et comme la fenêtre augmente de a paquets à chaque aller retour, on dispose des égalités suivantes : (1-b)W + Na = W, d'où N = bW/a. Par conséquent, la pseudo-période s'écrit P = bWR/a. calculée à partir des retours précédents du client, le débit Bm est calculé comme le débit moyen obtenu pendant une durée de plusieurs oscillations précédant le calcul (par exemple la moyenne de débit pendant la dernière seconde), et les valeurs a et b sont les paramètres de l'algorithme de contrôle de congestion GAIMD considéré (s'il s'agit de la fonction de référence, alors a = 1 et b = 0,5, c'est-à-dire les valeurs correspondant à AIMD). A l'étape suivante 920, l'information obtenue à l'étape 910 (pseudopériode Pc) est comparée à la durée d'échéance Ev de l'ensemble des données vidéo à transmettre, cette durée étant déterminée selon le premier ou le deuxième mode de mise en oeuvre. En fonction du résultat de l'étape de comparaison 920, l'étape suivante 930 prévoit d'adapter la consigne de débit délivrée par le serveur et, plus particulièrement, par le module de contrôle de congestion. Si la pseudo-période du contrôle de congestion P, est nettement inférieure à l'échéance de la vidéo Eä (par exemple si elle est plus petite que E,110), on sélectionne alors l'algorithme AIMD comme algorithme de contrôle de congestion pour fournir une consigne de débit adaptée aux conditions (étape 930). Cet algorithme constitue un algorithme de référence, couramment utilisé sur les réseaux IP. Si l'algorithme AIMD était déjà sélectionné, on le conserve.

Le fait que la durée Pc soit beaucoup plus petite que Ev indique que durant la durée de transmission d'une image on a une forte probabilité que le débit réseau varie très souvent. En prenant la valeur moyenne du débit réseau sur la durée Ev on a donc de grandes chances d'avoir une valeur plus stable que la valeur instantanée du débit réseau par application du théorème de la limite centrale. Dans un cas où AIMD est sélectionné et où Eä est égale à 125ms- RTT/2 (cas où Ev = Pv pour une vidéo conférence), la table suivante montre en grisé les valeurs de P, inférieures à 120 ms divisé par 10, soit 12ms pour les valeurs de RTT inférieures à 10ms (voir les trois premières lignes de la table), pour lesquelles on conserve AIMD comme algorithme de contrôle de congestion. Pour une valeur élevée de RTT (supérieure à 10ms, voir la dernière ligne de la table), Ev décroit rapidement tandis que Pc croit rapidement, et il n'est pas possible d'avoir P, Ev.

Dans ce cas, on utilise une durée pendant laquelle on moyenne la consigne de débit vidéo. Ceci permet au module de contrôle de débit de codage vidéo 320 de ne pas utiliser la valeur courante de la consigne de débit réseau fournie par le module de contrôle de congestion 335 mais une valeur moyenne de celle-ci qui varie moins brutalement. La durée sur laquelle on effectue ainsi une moyenne peut être l'échéance de la vidéo Ev. On obtient un débit réseau calculé et des tailles d'images compressées comme représenté à la figure 11. La figure 11 illustre une première mise en oeuvre utilisant un contrôle de congestion qui varie de manière rapide dans le temps. Les baisses de débit se produisent avec un rythme plus rapide qu'à la figure 7 et beaucoup plus rapide que le rythme des images (cadence des images). Dans ce cas, le module de contrôle de débit de la vidéo 320 utilise, non pas la dernière valeur du débit calculée par le module de contrôle de congestion 335, mais une moyenne des débits passés. Ainsi, la moyenne des débits calculés a une variance plus faible que les débits calculés. La moyenne des débits constitue donc un meilleur indicateur de prévision des futurs débits que le débit courant. Les tailles des images ont donc une variation qui n'est pas trop brutale, ce qui permet en moyenne de conserver une bonne qualité de vidéo.

De retour à l'étage 920 de la figure 9, si la pseudo-période du contrôle de congestion P, n'est pas nettement inférieure à l'échéance Ev, on évalue alors la pseudo-période Pg qu'aurait la consigne de débit réseau délivrée par un algorithme de contrôle de congestion alternatif, dans les circonstances RTT(s) 0,0001 0,001 0,002 0,01 0,1 B(b/s) 1 000 000 5 000 000 10 000 000 20 000 000 50 000 000 100 000 000 0,022222222 0,027777778 0,055555556 0,111111111 0,277777778 0,555555556 0,5555556 2,777777778 5,555555556 11,11111111 27,77777778 55,55555556 données (caractéristiques relatives au trafic sur le réseau). Ces circonstances sont définies par la taille des paquets S fixée à la taille requise par le réseau, la valeur du temps aller retour RTT calculée à partir des derniers retours en date, le débit Bm calculé comme le débit moyen obtenu pendant une durée de plusieurs oscillations précédant le calcul. Les valeurs a et b sont les paramètres du contrôle de congestion alternatif choisi, qui est ici un algorithme GAIMD lissé, par exemple avec a= 0.3125 et b=0.13 (étape 940). On compare ensuite Pg avec la durée 1/Fä entre deux images de la vidéo (étape 950). Si Pg est largement supérieure à 1/Fä (par exemple Pg > 81Fä), on utilise le contrôle de congestion lissé pour calculer le débit réseau et la consigne à envoyer au contrôle de débit de la vidéo est égale au débit réseau instantané (étape 960). On adapte ainsi la consigne de débit délivrée par le serveur en fonction du résultat des étapes 920, 940 et 950. On notera que la période d'oscillation Pg est ici comparée avec la durée 1/Fä car on n'utilise pas de lissage du débit réseau pour le calcul de la consigne de débit vidéo. Le fait d'avoir une période d'oscillation Pg beaucoup plus grande que le rythme entre les images indique qu'il y a de fortes probabilités que le débit réseau varie peu entre deux images. Le débit vidéo reste donc relativement stable, ce qui donne une bonne qualité.

Par exemple dans le cas de GAIMD (0,3125 ;0,13) et de 1/Fä égale à 20 ms (dans le cas d'une vidéo classique à 50 images par secondes avec, de plus, une activation de l'algorithme de contrôle de débit à chaque image), la table suivante montre en grisé les valeurs de Pg assez grandes, c'est-à-dire supérieures à 8 fois 20 ms, soit 160ms, pour lesquelles on choisit l'algorithme de contrôle de congestion lissé. 3,708E-07 1,85383E-06 3,70766E-06 7,41533E-06 1,85383E-05 3,70766E-05 3,708E-05 0,000185383 0,000370766 0,000741533 0,001853832 0,003707665 0,0001483 0,000741533 0,001483066 0,002966132 0,00741533 0,01483066 0,0037077 0,018538324 0,037076649 0,074153298 B(b/s) RTT(s) 1 000 000 5 000 000 10 000 000 20 000 000 50 000 000 100 000 000 0,0001 0,001 0,002 0,01 0,1 Les variations de taille entre images sont alors faibles. On obtient un débit demandé et des tailles d'images compressées comme représenté en figure 12. La figure 12 illustre une deuxième mise en oeuvre avec cette fois-ci un autre cas d'algorithme de contrôle de congestion délivrant une consigne qui varie dans le temps de manière douce (par exemple sur la base de l'algorithme TFRC) avec un rythme de variation de l'ordre de plusieurs images. Dans ce cas, d'une part, le débit réseau disponible pour envoyer l'image suivante peut être prédit de manière sûre et, d'autre part, les tailles des images successives varient doucement, ce qui fournit des variations de qualité douces et donc globalement une bonne qualité pour la vidéo. Cet exemple montre que dans certains cas il peut être avantageux d'avoir un contrôle de congestion plus lissé que AIMD. De retour à l'étage 950 de la figure 9, si le test est négatif, on se trouve alors essentiellement dans les circonstances suivantes : RTT = 0,01 s et Bm est compris entre 5 000 000 et 20 000 000 bits/s, ou RTT = 0,02 s et Bm = 100 000 000 bits/s. Dans ce cas, on modifie les paramètres du contrôle de congestion pour sélectionner un autre algorithme de contrôle de congestion alternatif qui délivre une consigne variant plus vite (étape 970). On adapte ainsi la consigne de débit réseau délivrée par le serveur en fonction du résultat des étapes 920, 940 et 950. Dans un mode de réalisation, on prend GAIMD(4 ; 0,25). La table suivante donne les valeurs de pseudo-période de cet algorithme dans les circonstances données, c'est-à-dire à nouveau la taille des paquets S fixée à la taille requise par le réseau, la valeur du temps aller retour RTT calculée à partir des derniers retours en date, le débit Bm calculé comme le débit moyen obtenu pendant une durée de plusieurs oscillations précédant le calcul.

Dans les cas où l'étape 970 est mise en oeuvre (en grisé dans le tableau) on obtient une pseudo-période inférieure à 12 ms et on utilise une durée sur laquelle on effectue une moyenne de la consigne de débit réseau. La durée sur laquelle la consigne est ainsi moyennée peut être l'échéance Ev. On notera que les données à transmettre sont compressées suivant un mode de compression adapté qui est fonction de la consigne de débit réseau adaptée aux étapes 930, 960 et 970.

Les données ainsi compressées sont ensuite transmises sur le réseau vers le dispositif client pour utilisation par ce dernier. B(b/s) 1 000 000 5 000 000 10 000 000 20 000 000 5 0000 000 10 000 0000 5,952E-08 2,97619E-07 5,95238E-07 1,19048E-06 2,97619E-06 5,95238E-06 5,952E-06 2,97619E-05 5,95238E-05 0,000119048 0,000297619 0,000595238 ................................. ................................. ................................. 2,381E-05 0,000119048 0,000238095 0,00047619 0,001190476 !#7`tt3$t#O .......................................................................... ............................. .......................................................................... ............................. 0,0005952 { 297 19 tOOOt 5 $ O119t47 0029761905 0,05952381 .......................................................................... ............................. 0,0595238 0,297619048 0,595238095 1,19047619 2,976190476 5,952380952 Rtt(s) 0,0001 0,001 0,002 0,01 0,1

Claims (10)

1. REVENDICATIONS1. Procédé de transmission d'un flux de données d'images vidéo entre un serveur (101) et au moins un dispositif client (102) dans un réseau de communication (100), mettant en oeuvre une consigne de débit pour la transmission de données sur le réseau de communication, le procédé comprenant les étapes suivantes : - obtention (910) d'une information P, représentative d'une vitesse de variation dans le temps d'une consigne de débit, ladite information étant fonction d'au moins une caractéristique de l'état du trafic sur le réseau de communication, - comparaison (920) de ladite information Pc ainsi obtenue avec une échéance Eä d'un ensemble de données d'images vidéo à transmettre, - adaptation (930) de la consigne de débit délivrée par le serveur en fonction au moins du résultat de l'étape de comparaison, - compression dudit ensemble de données d'images vidéo à transmettre suivant un mode de compression qui est fonction de la consigne de débit adaptée, - transmission dudit ensemble de données d'images vidéo ainsi 20 compressées.
2. 2. Procédé de transmission selon la revendication 1, caractérisé en ce qu'en fonction du résultat de l'étape de comparaison (920), le mode de compression est soit fonction d'une moyenne de valeurs de la consigne de 25 débit adaptée prises pendant une période de temps d'ordre de grandeur égal à l'échéance Eä (930 ; 970), soit fonction d'une valeur instantanée de ladite consigne de débit (960).
3. 3. Procédé de transmission selon la revendication 1 ou la 30 revendication 2, caractérisé en ce que l'échéance Eä dépend d'une valeur de cadence des images du flux de données.
4. 4. Procédé de transmission selon l'une des revendications 1 à 3, caractérisé en ce que l'échéance Eä dépend de contraintes temporelles d'utilisation du dispositif client (102).
5. 5. Procédé de transmission selon l'une des revendications 1 à 4, caractérisé en ce que la consigne de débit servant à l'obtention de l'information P, dans l'étape d'obtention est déterminée suivant un premier algorithme de contrôle de congestion.
6. 6. Procédé de transmission selon la revendication 5, caractérisé en ce que le premier algorithme de contrôle de congestion est la fonction AIMD (930).
7. 7. Procédé de transmission selon la revendication 5 ou la 15 revendication 6, caractérisé en ce que l'adaptation de la consigne de débit consiste à choisir entre le premier algorithme de contrôle de congestion et un second algorithme de contrôle de congestion alternatif en fonction du résultat de l'étape de comparaison (920) et de déterminer une valeur de consigne de débit adaptée selon l'algorithme de contrôle de congestion choisi (930 ; 960 ; 20 970).
8. 8. Procédé de transmission selon la revendication 7, caractérisé en ce que le second algorithme de contrôle de congestion est la fonction TFRC ou une fonction GAIMD lissée (960 ; 970). 25
9. 9. Dispositif de transmission d'un flux de données d'images vidéo entre un serveur (101) et au moins un dispositif client (102) dans un réseau de communication (100), mettant en oeuvre une consigne de débit pour la transmission de données sur le réseau de communication, le dispositif 30 comprenant des moyens pour : - obtenir (910) une information Pc représentative d'une vitesse de variation dans le temps d'une consigne de débit, ladite information étant 10 fonction d'au moins une caractéristique de l'état du trafic sur le réseau de communication, - comparer (920) ladite information P, ainsi obtenue avec une échéance Eä d'un ensemble de données d'images vidéo à transmettre, - adapter (930) la consigne de débit délivrée par le serveur en fonction au moins du résultat de l'étape de comparaison, - compresser ledit ensemble de données d'images vidéo à transmettre suivant un mode de compression qui est fonction de la consigne de débit adaptée, - transmettre ledit ensemble de données d'images vidéo ainsi compressées.
10. 10. Programme d'ordinateur comprenant une suite d'instructions aptes, lorsqu'elles sont exécutées par un microprocesseur, à mettre en oeuvre un procédé selon l'une des revendications 1 à 8.