FR2926177A1 - Procede et disositif de transmission de donnees avec partage specifique des ressources de debit d'un reseau. - Google Patents

Abstract

Pour transmettre un flux de données entre un serveur et au moins un client dans un réseau de communication, le serveur mettant en oeuvre un mécanisme de contrôle de congestion du réseau, le flux de données étant codé avec un débit variable : dans le serveur, on modifie (410, 455) un paramètre de réactivité (r) du mécanisme de contrôle de congestion, en fonction de l'état de charge du réseau, on contrôle le débit de codage du flux de données en fonction d'un objectif de qualité (Qobj) et on modifie (425, 460) l'objectif de qualité (Qobj) en fonction du paramètre de réactivité (r).Application à des réseaux à architecture de type réparti.

Description

1

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é, l'invention proposant un partage spécifique des ressources de débit du réseau.

Dans toute la suite, on utilise indifféremment les expressions "débit réseau" ou "bande passante réseau". L'invention 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 Protocof').

Elle concerne de façon générale le partage de la bande passante dans un réseau à architecture du type réparti (appelé aussi réseau distribué). Un exemple non limitatif d'application de l'invention consiste à procéder à un partage non équitable de la bande passante, afin de favoriser les flux de données issus d'un serveur mettant en oeuvre l'invention, ces flux requérant davantage de bande passante que les flux de données issus des autres serveurs du réseau, tout en garantissant une bande passante minimale pour ces autres flux. A titre d'exemple nullement limitatif, l'invention sera décrite ici dans le cas où le flux de données considéré est un flux vidéo. Dans un serveur relié au réseau de communication de données considéré, des images sont codées suivant un format de compression numérique, avant d'être transmises sur le réseau vers un ou plusieurs clients. De plus en plus d'équipements disponibles pour le grand public correspondent à cette définition et sont capables d'envoyer des flux vidéo : caméscope, appareil photo, caméra de vidéosurveillance, serveur de vidéo domestique, récepteur TV, ordinateur, téléphone, etc. Les flux vidéo destinés à être envoyés peuvent être stockés et comprimés à l'avance sur l'appareil émetteur ; ils peuvent également être saisis, comprimés et envoyés sur un réseau à destination de l'appareil récepteur.

On sait aussi que de nombreux appareils peuvent maintenant être raccordés à un réseau numérique tel qu'un réseau de type Ethernet, ou peuvent fonctionner sur un réseau sans fil, ou peuvent être reliés directement à 2

Internet via un réseau téléphonique. Sur ce réseau numérique, on peut avoir un ou plusieurs appareils récepteurs. Généralement, pour avoir un débit compatible avec celui du réseau, les flux vidéo sont comprimés par exemple selon les normes de compression 5 MPEG-2 ou MPEG-4 part 2 ou H.264. Or les réseaux de communication de données peuvent s'avérer peu fiables, en raison d'erreurs de transmission, de phénomènes de congestion ou d'arrêts temporaires des liaisons, lesquels entraînent une perte de paquets de données. De nombreux réseaux de données de type IP ou ATM (mode de 10 transfert asynchrone, en anglais "Asynchronous Transfer Mode") comprennent des noeuds d'interconnexion (routeurs, commutateurs, etc.) afin de router 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 15 pertes quand différents flux de données (par exemple de la navigation Internet, un jeu vidéo, ou le transfert d'un fichier vers une imprimante en plus des transmissions vidéo) sont amenés à transiter par un même lien de capacité insuffisante. Les paquets en surplus finissent par être rejetés par le noeud d'interconnexion situé à l'entrée du lien. 20 Si aucune action préventive n'est effectuée, des pertes de paquets de données vont se produire pendant la transmission vidéo, se traduisant par des dégradations de la qualité visuelle de l'affichage : image ou morceaux d'images "gelés" (c'est-à- dire absence de mouvement), chaque erreur se propageant ensuite aux images suivantes. Ces pertes de données peuvent 25 ainsi entraîner des dégradations importantes. Pour éviter de tels inconvénients, il est connu de réduire la bande passante utilisée par chaque flux vidéo pour que celle-ci soit compatible avec la bande passante globale du réseau. Par exemple, une telle réduction se fait au niveau de l'appareil émetteur, en comprimant la vidéo plus fortement pour 30 réduire le débit. En pratique, la compression consiste à augmenter le pas de quantification, à diminuer la fréquence des images, ou à réduire la résolution 3

des images. Une telle compression peut cependant avoir un impact plus ou moins important sur la qualité visuelle de la vidéo affichée en fonction du type de vidéo. Par exemple, une vidéo qui montre une pièce avec peu de mouvement (caméra de vidéosurveillance) peut être comprimée fortement sans dégradation trop importante de la qualité visuelle. Au contraire, un film d'action trop comprimé risque de subir une dégradation inacceptable au plan visuel pour un utilisateur. Une autre difficulté est que les utilisateurs ont des attentes en termes de qualité qui peuvent varier en fonction du de la nature du contenu vidéo et/ou en fonction du type de dispositif d'affichage : par exemple, l'utilisateur espère généralement pouvoir disposer d'une meilleure qualité pour une vidéo d'un film enregistré destinée à être visionnée sur un grand écran, que pour un dessin animé d'une chaîne de télévision destiné à être affiché sur un téléviseur à petit écran.

Se pose donc le problème d'adapter la bande passante d'un flux vidéo en fonction de la qualité visuelle de l'image visualisée, en fonction de l'utilisation qui en est faite et en fonction de l'utilisation du réseau par d'autres communications concurrentes. Une solution connue pour calculer la bande passante globale allouée à un flux vidéo envoyé suivant le protocole RTP (protocole de transport en temps réel, en anglais "Real-Ume Transport Protocof', RFC 1889), consiste à utiliser un algorithme de calcul de la bande passante disponible compatible avec celui utilisé par le modèle d'architecture réseau TCP/IP bien connu de l'homme du métier (ce modèle met en oeuvre le protocole de transport TCP ou protocole de commande de transmission - en anglais "Transmission Control Protocof' - et le protocole réseau IP ou protocole Internet - en anglais "Internet Protocof'). L'algorithme TFRC ("TCP Friendly Rate Controf', IETF RFC 3448) ou l'algorithme AIMD ("Additive Increase/Multiplicative Decrease", IETF RFC 2581) permet ainsi de calculer une bande passante disponible pour un flux vidéo sur le protocole RTP en fonction des pertes de paquet détectées. 4

Cela permet de répartir équitablement la bande passante entre toutes les communications réseau : chaque communication obtient ainsi une part égale en moyenne. Un système de traitement vidéo, appelé "streaming" en anglais, fondé sur cet algorithme, réduit alors la bande passante de chaque vidéo pour l'adapter à la bande passante calculée. Si on a plusieurs vidéos circulant sur le réseau, toutes les vidéos ont donc un débit identique en moyenne. Cependant, cela se traduit par une dégradation de la qualité visuelle variable en fonction du type de vidéo. De plus, cette solution de l'art antérieur présente l'inconvénient de ne tenir compte, ni du contenu de la vidéo, ni de l'utilisation qui est faite de la vidéo, ni des attentes de l'utilisateur. Une autre solution connue consiste à prévoir un serveur central, en charge de la régulation de toutes les communications dans le réseau et pouvant tenir compte de la qualité.

Néanmoins, une telle solution n'est envisageable que sur un réseau local très contrôlé, avec une coopération forte de tous les équipements. Dans le cas où on ne contrôle pas tous les équipements émetteurs, une telle solution n'est pas utilisable. On connaît par le document US-A-6 075 768 un système de partage équitable de la bande passante dans un réseau ATM. Un serveur envoie des données vidéo vers un client. Le réseau informe le serveur de la charge du réseau. Le contrôle de congestion utilise ce retour pour adapter le débit et la qualité de la vidéo envoyée, de sorte que la qualité augmente lorsque le réseau est disponible et diminue lorsque le réseau est surchargé.

Cette solution ne permet donc pas de tenter de maintenir la qualité de la vidéo en cas de congestion du réseau. En outre, cette solution n'offre pas la possibilité de faire varier l'objectif de qualité en tenant compte de paramètres tels que la complexité de la vidéo et/ou les préférences de l'utilisateur. Par conséquent, il n'est pas possible de privilégier un flux de données par rapport à d'autres flux sur le réseau. L'invention a pour but de remédier aux inconvénients et lacunes précités de l'art antérieur.

Dans ce but, la présente invention propose un procédé de transmission d'un flux de données entre un serveur et au moins un client dans un réseau de communication, le serveur mettant en oeuvre un mécanisme de contrôle de congestion du réseau, le flux de données étant codé avec un débit 5 variable, ce procédé étant remarquable en ce qu'il comporte des étapes consistant, pour le serveur, à : - modifier un paramètre de réactivité du mécanisme de contrôle de congestion, en fonction de l'état de charge du réseau, - contrôler le débit de codage du flux de données en fonction d'un 10 objectif de qualité, et - modifier l'objectif de qualité en fonction du paramètre de réactivité. Ainsi, la présente invention permet de faire varier simultanément des paramètres du contrôle de congestion du réseau et du contrôle de débit du codage du flux de données, afin de trouver un bon compromis entre la qualité 15 du flux de données et le respect des autres flux sur le réseau. En outre, l'invention ne nécessite pas une connaissance globale de l'ensemble des flux du réseau. Chaque serveur de flux de données calcule son propre débit, indépendamment des autres serveurs. Par ailleurs, l'invention n'implique aucune modification des clients ou 20 du réseau par rapport aux systèmes actuels. De plus, elle est compatible avec les évolutions prévues des réseaux, telles que le développement des réseaux IP à haut et très haut débit et des réseaux sans fil. Selon une caractéristique particulière, l'étape de modification de 25 l'objectif de qualité consiste à baisser l'objectif de qualité lorsqu'on augmente la réactivité et à augmenter l'objectif de qualité lorsqu'on baisse la réactivité. Une telle adaptation de l'objectif de qualité en fonction de la réactivité permet d'obtenir une stabilisation du système, c'est-à-dire qu'on atteint ainsi un point d'équilibre dans la répartition de la bande passante entre les différents flux 30 de données dans le réseau. 6

Dans un mode particulier de réalisation, le procédé comporte en outre une étape consistant, pour le serveur, à modifier l'objectif de qualité en fonction de la complexité du flux de données. Cela permet de répartir la bande passante avec un meilleur équilibrage des qualités. Dans ce mode de réalisation, l'étape de modification de l'objectif de qualité en fonction de la complexité du flux de données peut par exemple consister à faire varier l'objectif de qualité en raison inverse de la complexité. Cela permet d'équilibrer les qualités des différentes vidéos transmises sur le réseau, même si elles présentent des complexités différentes. Dans un mode particulier de réalisation, le procédé peut comporter en outre une étape consistant, pour le serveur, à modifier l'objectif de qualité en fonction des préférences du client concernant la qualité du flux de données. On optimise ainsi la répartition de la bande passante en tenant compte des besoins de l'utilisateur. Selon une caractéristique particulière, le flux de données est un flux vidéo. Dans le même but que celui indiqué plus haut, la présente invention propose également un serveur de transmission d'un flux de données à au moins un client dans un réseau de communication, le serveur comportant un module de contrôle de congestion du réseau, le flux de données étant codé avec un débit variable, le serveur étant remarquable en ce qu'il comporte : - un module pour modifier un paramètre de réactivité du module de contrôle de congestion, en fonction de l'état de charge du réseau, - un module pour contrôler le débit de codage du flux de données en fonction d'un objectif de qualité, et - un module pour modifier l'objectif de qualité en fonction du paramètre de réactivité. Toujours dans le même but, la présente invention vise aussi un système de télécommunications comprenant une pluralité de dispositifs terminaux reliés à travers un réseau de télécommunications, remarquable en ce 7

qu'il comprend au moins un serveur de transmission tel que succinctement décrit ci-dessus. Toujours dans le même but, la présente invention vise aussi un moyen de stockage d'informations pouvant être lues par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, remarquable en ce qu'il est adapté à mettre en oeuvre un procédé de transmission tel que succinctement décrit ci-dessus, lorsque les informations précitées sont lues par l'ordinateur ou le microprocesseur. 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 produit programme d'ordinateur est chargé dans et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du serveur de transmission, du système de télécommunications, 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é à mettre en oeuvre la présente invention ; 8

- la figure 3 représente de façon schématique l'architecture d'un serveur susceptible de mettre en oeuvre la présente invention, dans un mode particulier de réalisation ; - la figure 4 est un organigramme illustrant les principales étapes d'un algorithme de détermination d'un objectif de qualité mis en oeuvre par un serveur conforme à la présente l'invention, dans un mode particulier de réalisation ; - la figure 5 est un graphique schématisant le fonctionnement du contrôle de congestion du réseau en relation avec un paramètre de réactivité ; - la figure 6a est un graphique illustrant schématiquement une séquence d'images comprimées selon un format de compression vidéo connu du type utilisé par la présente invention ; - la figure 6b est un organigramme illustrant les principales étapes d'un algorithme de contrôle de débit mis en oeuvre par un serveur conforme à la présente invention, dans un mode particulier de réalisation ; et - la figure 7 est un graphique illustrant de façon schématique le principe de la détermination d'un objectif de qualité conformément à la présente invention, dans un mode particulier de réalisation. La figure 1 montre un exemple de réseau de communication de 20 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 un réseau de communication de données 100. Le réseau 100 peut contenir des noeuds d'interconnexion 103 et des 25 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 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 30 / 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 ou des combinaisons des deux. 9

Un exemple d'un tel flux de données est un flux audio vidéo MPEG comprenant différents types de trames vidéo telles que des trames clés (I), des trames prédictives avant (P), et des trames prédictives avant et arrière (B), où les trames clés et les trames P servent de base au traitement des trames prédictives avant et arrière. 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 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 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 du type représenté sur la figure 2, décrite ci-dessous.

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 10

de la 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. 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, entraîne l'exécution des étapes des organigrammes des figures 4 ou 6b. 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 pour 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, un serveur multimédia ou encore un élément routeur dans un réseau. Cet appareil peut intégrer directement un capteur numérique d'images, ou, en option, ê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'appareil 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. 11

La figure 3 illustre plus en détail l'architecture d'un serveur 101 conforme à la présente invention, dans un mode particulier de réalisation. Le serveur dispose en entrée d'une vidéo provenant par exemple d'un capteur 305. Le capteur 305 est par exemple une caméra.

La vidéo est fournie à un codeur vidéo ou codec 310 qui code la vidéo dans un format connu, par exemple MPEG H.264/AVC, puis mémorise le résultat dans une mémoire tampon 315 (en anglais "buffer") sous forme de paquets prêts à être envoyés. En variante, le serveur peut recevoir une vidéo déjà codée en provenance d'un autre réseau, par exemple dans le cas d'une passerelle domestique (en anglais "home gateway') recevant une chaîne de télévision par Internet. Dans ce cas, le codec 310 transcode la vidéo pour adapter son débit à la bande passante du réseau à la maison, lequel est par exemple un réseau sans fil. De même que dans le premier cas, les données créées sont mémorisées dans le tampon 315. Le codec 310 est contrôlé par un module de contrôle de débit 320. Ainsi, le module 320 met notamment en oeuvre un algorithme qui détermine le pas de quantification de la prochaine image ou du prochain macrobloc de données (un macrobloc étant généralement défini comme un ensemble de quatre blocs carrés de 8x8 pixels d'une image), en fonction des tailles des images passées, du niveau de remplissage du tampon 315 et d'un objectif de qualité. Un mode particulier de réalisation de l'algorithme de contrôle de débit mis en oeuvre dans le module de contrôle de débit 320 est décrit en détail plus loin en référence à la figure 6b.

Les données mémorisées dans le tampon 315 sont retirées et envoyées sur le réseau par un module de contrôle de congestion 325, chargé à la fois de l'envoi des paquets de données et du contrôle de congestion du réseau. L'algorithme de contrôle de congestion est décrit en détail plus loin en référence à la figure 5.

Le module de contrôle de congestion 325 évalue à chaque instant la bande passante disponible sur le réseau et décide des instants où des paquets peuvent être envoyés. Pour effectuer ces calculs, le module 325 utilise des 12

informations reçues du client à travers le réseau, notamment les événements de perte de paquets et le temps de communication aller-retour (Rtt, en anglais "Round-trip time"). Les modules de contrôle de débit 320 et de contrôle de congestion 325 sont eux-mêmes contrôlés par un module de détermination d'objectif de qualité 330, dont le fonctionnement est décrit en détail ci-après en référence à la figure 4. Le module de détermination d'objectif de qualité 330 est en charge d'un deuxième niveau de contrôle de débit : il contrôle des objectifs de qualité à long terme pour le contrôle de débit (ou bande passante) du codeur. Le module de détermination d'objectif de qualité 330 contrôle aussi des paramètres du contrôle de congestion, en particulier la réactivité (notée r dans toute la suite de la description). L'organigramme de la figure 4 illustre les principales étapes d'un mécanisme de décision sur la qualité qui est susceptible d'être mis en oeuvre par un serveur conforme à la présente l'invention, dans un mode particulier de réalisation. Ce mécanisme peut être exécuté à intervalles réguliers sur le serveur. Il peut notamment être mis en oeuvre par le module de détermination d'objectif de qualité 330 représenté sur la figure 3. Il permet de calculer un objectif de qualité ainsi que de déterminer les paramètres de fonctionnement du mécanisme de contrôle de congestion du réseau, lequel peut notamment être mis en oeuvre par le module de contrôle de congestion 325 représenté sur la figure 3. Lors d'une étape initiale 400, les données d'entrée suivantes sont 25 fournies au module de détermination d'objectif de qualité 330 : -en provenance du module 320 de contrôle de débit codeur (voir figures 6a et 6b) : • la qualité courante, notée Q ; • le débit courant de la vidéo, noté B ; et 30 • le taux de variation, noté a, du débit en fonction de la qualité (ce paramètre caractérise la complexité de la vidéo). 13

- en provenance du module de contrôle de congestion réseau 325 (voir figure 5) : • la bande passante courante, notée Bcur ; et • un indicateur, noté D, fournissant une information sur les disponibilités de bande passante du réseau. - les valeurs suivantes sont calculées à l'initialisation en fonction des caractéristiques du client (voir figure 7) : • des constantes Qo et C, qui dépendent respectivement de la qualité optimale pour le client et des caractéristiques du client et du réseau ; • les valeurs limites de la réactivité r, notées rmin (réactivité minimale) et rmax (réactivité maximale) ; • les valeurs limites de la qualité, notées Qopt (qualité optimale) et Qmin (qualité minimale).

A la première exécution de l'algorithme, l'objectif de qualité, noté Qobi, est fixé égal à Qopt. Cette valeur peut évoluer à chaque exécution de l'algorithme. Puis un test 405 consiste à comparer la qualité courante Q avec l'objectif de qualité Qobi. Si la qualité est inférieure à l'objectif (test 405 positif), l'étape suivante est l'étape 410. Dans le cas où la valeur de l'objectif est atteinte voire dépassée (test 405 négatif), on passe à l'étape 450. Les étapes 410 à 430 visent à évaluer s'il est possible d'augmenter le débit réseau pour essayer d'améliorer la qualité courante de la vidéo. L'étape 410 consiste à calculer une nouvelle valeur possible du paramètre de réactivité r du contrôle de congestion, selon l'équation suivante : r'=r(1+A) où A est une constante prédéterminée. A titre d'exemple non limitatif, on peut choisir A = 0,1. On augmente ainsi le paramètre de réactivité pour augmenter le débit réseau. La valeur de la réactivité r est bien entendu également comparée à la valeur limite maximale rmax, de façon à ne pas la dépasser. Puis l'étape 415 consiste à calculer le nouveau débit réseau, noté B'r, estimé pour la nouvelle valeur r'. Les détails de ce calcul en fonction de l'algorithme de contrôle de congestion sont expliqués plus loin en liaison avec la figure 5 et l'équation 5a. La valeur du nouveau débit réseau B'r, est donnée par l'équation : B'r, = r' N + B r' où BT est la bande passante totale du réseau et N est le 5 nombre total de flux de données TOP. En considérant que A est petit, une approximation de l'équation précédente est donnée par : B'r, r' BT =Br(1+A)=Bcur(1+A) N+r On peut ainsi estimer la nouvelle bande passante sans 10 nécessairement connaître la bande passante totale du réseau, ni le nombre de flux de données présents. Ensuite, à l'étape 420, on peut évaluer la nouvelle qualité Q' obtenue pour la nouvelle bande passante. On donne ci-après, en liaison avec les figures 6a et 6b, des détails sur l'évaluation de la qualité de la vidéo en fonction du 15 débit. On peut donner une approximation de la variation de qualité en utilisant le taux de variation a, donné par le contrôle de débit : r' a On a ainsi augmenté le débit et la qualité prévus pour la vidéo. Ensuite, à l'étape 425, on calcule la nouvelle valeur de l'objectif de 20 qualité Q'obj. Les détails de ce calcul sont donnés ci-après en référence à la figure 7 et à l'équation 7. La nouvelle valeur de l'objectif de qualité est donnée par: r' C Q'0b=QoûCa=Qob;û0= On diminue ainsi l'objectif de qualité. On vérifie cependant que cet 25 objectif reste supérieur ou égal à la valeur minimale de qualité Qmin. Puis un test 430 consiste à comparer les valeurs de qualité calculées aux étapes 420 et 425, à savoir, l'évaluation de la nouvelle qualité Q' et la nouvelle valeur objectif Q'obj. 15

Si la qualité est inférieure à l'objectif (test 430 positif), on passe à l'étape 435 pour continuer à modifier le contrôle de congestion. Dans le cas où la qualité estimée atteint ou dépasse le nouvel objectif de qualité (test 430 négatif), on arrête les calculs en passant à l'étape 465.

L'étape 435 consiste à modifier les valeurs mémorisées de r, Qob; et Br pour les remplacer par les nouvelles valeurs calculées aux étapes 410, 415 et 425. On revient ensuite à l'étape 410 pour tenter une nouvelle évaluation des paramètres de contrôle de congestion. A l'étape 465, les dernières valeurs mémorisées sont envoyées : - l'objectif de qualité Qobi est transmis par le module de détermination d'objectif de qualité 330 au module de contrôle de débit 320 du codeur ; - le paramètre de réactivité r est transmis par le module de détermination d'objectif de qualité 330 au module de contrôle de congestion 325. Cela termine le mécanisme de décision sur la qualité dans le cas où la qualité est insuffisante. Dans le cas où la qualité est suffisante lors du test 405, on évalue la disponibilité du réseau à l'étape 450. En fonction de l'indicateur D donné par le contrôle de congestion, on peut savoir si de la bande passante est disponible sur le réseau. Dans le cas où il n'y a pas de bande passante disponible, le mécanisme de décision sur la qualité prend fin, à l'étape 490. Dans le cas contraire, on essaie d'augmenter la qualité des données envoyées. Pour cela, on commence par calculer une nouvelle valeur de la réactivité r, lors d'une étape 455: on remplace la valeur r par la valeur de l'expression r(1- A). On baisse ainsi la réactivité. On vérifie cependant que cette nouvelle valeur reste supérieure ou égale à la valeur limite minimale rmjn de la réactivité.

Ensuite, à l'étape 460, on peut calculer le nouvel objectif de qualité en utilisant la formule expliquée ci-après en référence à la figure 7 et à l'équation 7. La nouvelle valeur de l'objectif de qualité est donnée par : 16 Q'ob; = Qo û C a = Qob; + Or a On augmente ainsi l'objectif de qualité. On vérifie cependant que cet objectif reste inférieur ou égal à la valeur maximale de qualité Qopt. Les nouvelles valeurs r et Qobj sont directement mémorisées et peuvent ensuite être transmises aux modules 320 et 325, à l'étape 465 décrite ci-dessus. Le graphique de la figure 5 illustre le fonctionnement du mécanisme de contrôle de congestion réseau et du paramètre de réactivité r. On peut avantageusement utiliser un algorithme de contrôle de congestion de type MuITCP, connu de l'homme du métier. Cependant, cet exemple n'est aucunement limitatif : on peut utiliser tout autre algorithme de contrôle de congestion (comme par exemple MuITFRC), à condition qu'il fournisse un moyen de paramétrer dynamiquement son comportement pour faire varier la répartition de bande passante.

L'invention est présentée ici dans l'exemple non limitatif d'un algorithme de contrôle de congestion sur un réseau IP. Il s'agit d'une application très générale, car cet algorithme de contrôle de congestion peut être utilisé de façon distribuée sur n'importe quel réseau IP (et en particulier sur Internet). Néanmoins, l'invention peut aussi être utilisée dans d'autres cas, comme par exemple dans le cas d'un réseau totalement contrôlé, dans lequel on peut agir sur les algorithmes des routeurs, ou dans le cas du multiplexage de plusieurs flux de données sur un même lien, dans la mesure où on peut agir dynamiquement sur les proportions des différents paquets de données envoyés.

Dans le cas d'un routeur, une politique connue d'ordonnancement des paquets est WFQ (de l'anglais "Weighted Fair Queuing"). Un ordonnanceur sélectionne les paquets à envoyer dans plusieurs files d'attente provenant de plusieurs flux à envoyer avec des probabilités (ou poids) w; qui peuvent être différentes pour chaque flux. L'invention s'applique à un tel cas dès lors qu'on peut modifier dynamiquement la probabilité w; du flux de la vidéo qu'on cherche à envoyer. En effet, en faisant augmenter ce poids w; en cas de congestion, on 17

augmente la proportion des paquets de la vidéo transmis au détriment des autres flux. Inversement, en baissant le poids w;, on peut laisser plus de place à d'autres flux qui pourraient éventuellement en avoir besoin ; s'il n'y a pas de congestion, la diminution du poids w; n'entraîne pas nécessairement une diminution de la quantité de paquets transmis. Ainsi, dans le cas d'un routeur, le paramètre de réactivité r est le poids w; associé au flux de données qu'on cherche à envoyer. Dans le cas d'un algorithme de contrôle de congestion, celui-ci contrôle la quantité de données envoyées à chaque instant sur le réseau. Le plus connu est celui du protocole de transport TOP, qui est de type AIMD (en anglais "Additive Increase/Multiplicative Decrease", comme mentionné dans l'introduction de la présente description). En bref, cet algorithme fonctionne en augmentant de façon progressive le débit des données envoyées, tant que le client signale que les paquets sont bien reçus. En moyenne, TCP envoie un paquet supplémentaire pour chaque aller-retour correct, ce qui donne une augmentation linéaire. Lorsqu'une erreur apparaît, le débit est divisé par 2. La courbe 520, représentée en tirets sur la figure 5, illustre un tel comportement. Le débit est noté d. L'algorithme de contrôle de congestion MuITCP se comporte comme s'il y avait r flux TCP en parallèle. Le débit augmente donc de r paquets à chaque aller-retour correct et, à chaque erreur, le débit n'est réduit que de 1/2r. L'utilisation de l'algorithme MuITCP a été proposée pour avoir des services différenciés, mais aussi pour mieux utiliser les réseaux IP haut débit ou pour mieux résister aux erreurs dans les réseaux sans fil. Ce comportement est représenté par la courbe 510, représentée en traits continus sur la figure 5. On peut généraliser ces formules à des valeurs de r non entières. On appelle r le paramètre de réactivité du contrôle de congestion. Intuitivement, on comprend que r permet de faire varier la vitesse de réaction du contrôle de congestion : ainsi, une forte valeur de r donne un contrôle de congestion très agressif, c'est-à-dire qui cherche à prendre une place importante sur le réseau. On décrit maintenant comment déterminer la bande passante lorsqu'elle est répartie entre plusieurs flux. Lorsqu'on a un total de N flux TOP, 18 la bande passante totale BT est répartie équitablement entre chaque flux TCP : on obtient doncB = N . Un flux de type MuITCP avec un paramètre de réactivité de valeur r se comporte comme r flux TOP. Lorsqu'on a simultanément 1 flux MuITCP avec N flux TOP, alors en moyenne, la bande passante qui est accordée au flux MuITCP sera r fois la bande passante de chaque flux TCP concurrent : Br Br =r N+r (équation 5a) Cette équation permet d'estimer la nouvelle bande passante si on modifie le paramètre r à l'étape 415 de la figure 4.

Dans le cas d'un algorithme WFQ, on obtiendrait la même répartition avec un flux de poids r en présence de N flux de poids 1. On décrit maintenant le processus de détection de réseau disponible. Le mécanisme de contrôle de congestion détermine les instants où des données peuvent être envoyées, ainsi que la quantité de données qui peut être envoyée. Lorsqu'il a déterminé que des données peuvent être envoyées, il prend les paquets en attente dans le tampon du serveur pour les envoyer sur le réseau. Si le débit réseau estimé devient supérieur au débit de codage de la vidéo, les paquets vont être envoyés plus vite qu'ils ne sont produits. On va donc se retrouver avec un tampon vide. Dans ce cas, le débit d'envoi sur le réseau va plafonner et ne pourra plus suivre le débit calculé. On peut donc détecter cette situation, soit en vérifiant l'état du tampon (s'il est souvent vide), soit en comparant le débit réel des données envoyées par rapport au débit estimé.

Dans un tel cas, le module de contrôle de congestion 325 (figure 3) peut prévenir le module de détermination d'objectif de qualité 330, par exemple à l'aide de l'indicateur D mentionné plus haut, pour que le module 330 puisse augmenter la qualité si besoin (cf. étape 450 de la figure 4). On décrit maintenant comment déterminer certaines valeurs limites 30 du paramètre de réactivité r. 19

En effet, plus la valeur de r est importante, plus le mécanisme de contrôle de congestion réagit rapidement. A la limite, cela peut créer un trop grand nombre de congestions sur le réseau. Inversement, plus la valeur de r est faible, plus le mécanisme de contrôle de congestion réagit lentement lorsque de la bande passante est disponible. A la limite, cela peut poser un problème de vitesse de convergence du débit. Pour évaluer les valeurs limites du paramètre de réactivité r, on suppose qu'on a un comportement périodique, de période notée T. Dans ce cas, on peut calculer la longueur de la période T en fonction du débit maximal et du taux d'augmentation du débit. Si on note BT la bande passante disponible, P la taille d'un paquet et Rtt le temps de communication aller-retour entre le serveur et le client, la période est donnée par l'équation suivante : 2 T = B~RPt (équation 5b) En effet, le débit augmente de r paquets de taille P à chaque Rtt (A = rP/R t) et il diminue de BT/2r à chaque période T (AT = BT /2r ). L'équation 5b ci-dessus peut ainsi être utilisée pour évaluer des bornes sur les valeurs du paramètre de réactivité r.

Si la valeur de la réactivité r est faible, la durée nécessaire pour augmenter le débit de façon à atteindre un débit cible (par exemple, la valeur de débit maximale possible pour le flux vidéo) ne doit pas être trop longue. Typiquement, la valeur de la période T doit rester inférieure à quelques secondes. Cela constitue une première contrainte, sur la valeur minimale de la réactivité r. Cette contrainte est utilisée dans le mode particulier de réalisation illustré sur la figure 7 décrite plus loin. A chaque oscillation, on a un événement de perte. Si la valeur de la réactivité r est trop élevée, le taux de pertes (égal à 1/T) pourra être important. En fonction des mécanismes utilisés pour résister aux erreurs, un taux d'erreur fixé peut être supporté. Cela constitue une seconde contrainte, sur la valeur 20

maximale de la réactivité, également utilisée dans le mode de réalisation de la figure 7. La figure 6a permet d'illustrer le compromis débit-distorsion dans le cas d'un codage vidéo du type utilisé par la présente invention, dans un mode particulier de réalisation où le flux de données transmis est un flux vidéo. La figure 6a représente schématiquement une séquence d'images comprimées selon un format de compression vidéo tel que H.264 ou MPEG-4, ces exemples n'étant pas limitatifs. Ces formats sont bien connus de l'homme du métier ; ils utilisent la transformation en cosinus discrète (DCT, en anglais "Discrete Cosine Transform"), appliquée par blocs sur la séquence de données considérée, ainsi que la compensation de mouvement, suivie d'une quantification. Classiquement, une séquence codée selon un tel format contient des images de type I ou INTRA, qui peuvent être décodées de façon indépendante les unes des autres, des images prédites P et des images bi-prédites B. On définit des groupes d'images (GOP, en anglais "Group Of Pictures") constitués d'une image I suivie d'un nombre prédéterminé d'images de type P et B. La taille des images I, P et B est très variable. Généralement, l'image I est moins comprimée (car elle n'utilise pas de compensation de mouvement), les images P sont mieux comprimées et les images B sont les plus petites.

C'est la taille de chaque image qui est représentée sur la figure 6a. Le calcul du débit d'une vidéo est donc effectué en moyenne, sur une séquence, et non image par image. Le débit moyen ainsi déterminé est noté M dans la suite. Plusieurs paramètres peuvent être utilisés pour modifier le taux de compression d'une vidéo.

Par exemple, le pas de quantification peut être modifié, pour chaque bloc. C'est la technique la plus classique, détaillée plus loin. Certaines images peuvent être supprimées dans la vidéo : cela correspond au changement de fréquence d'affichage. La structure du groupe d'images (GOP) peut ainsi être modifiée.

On peut également modifier la résolution spatiale des images. 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 21

vidéo et du contenu de la scène. En effet, un film avec une scène statique ou un petit objet en mouvement régulier de translation est en général fortement comprimé, tandis qu'un film d'action, par exemple, engendre encore une grande quantité de données. Le taux de compression dépend notamment de la quantité d'informations non redondantes dans la séquence d'origine. Les techniques décrites peuvent être appliquées lors du codage ou du transcodage d'une vidéo. Dans le cas du codage, un capteur numérique engendre des images qui sont ensuite codées. Au début du groupe d'images GOP, une image I est engendrée, puis les images suivantes sont comprimées en P (ou B suivant la structure du GOP). Pour obtenir un débit moyen (ou bande passante moyenne) constant, le résultat de la compression est pris en compte et les paramètres de compression sont adaptés dynamiquement à chaque image (ou à chaque macrobloc de données) pour atteindre le débit moyen fixé.

Dans le cas du transcodage, la vidéo représentée sur la figure 6a a déjà été codée auparavant, mais on souhaite modifier son taux de compression pour faire baisser le débit moyen M de la séquence. La technique la plus simple, mais relativement coûteuse en temps de calcul, consiste à décoder la vidéo puis à la comprimer à nouveau, avec un taux de compression différent du taux de compression initial. Une technique plus efficace consiste à décoder partiellement la vidéo et à la requantifier, afin d'augmenter le taux de compression tout en réutilisant les vecteurs de mouvement sans les modifier. Cette technique permet de faire baisser la taille de chaque image I, P ou B. Une autre technique consiste à supprimer certaines images. Les images de type B peuvent être enlevées simplement car elles ne sont pas réutilisées par d'autres images. Comme dans le cas du codage, les paramètres de compression sont modifiés de façon dynamique à chaque macrobloc, en fonction des compressions obtenues précédemment, pour atteindre le débit moyen fixé. D'autres techniques de compression et d'adaptation de bande passante peuvent être utilisées. Par exemple certains codages permettent d'avoir un codage dit hiérarchique ou à plusieurs niveaux (encore appelé extensible, en anglais "scalable"). La vidéo est alors composée de plusieurs 22

couches, chaque couche apportant des informations supplémentaires (et par conséquent, du débit en plus) et de la qualité. L'adaptation du débit consiste alors à sélectionner le nombre de couches souhaité. On décrit maintenant le mécanisme de contrôle de débit utilisé par la présente invention (module 320 de la figure 3), en référence à la figure 6b. On cherche à calculer des paramètres de compression appropriés pour respecter les objectifs de débit et ne pas faire déborder le tampon de sortie, tout en maximisant la qualité de la vidéo. Une technique classique consiste à utiliser un modèle débit- distorsion. A titre d'exemples non limitatifs, des modèles connus utilisés dans le cadre de la compression MPEG sont TMN-5 ou TMN-8. Ces modèles sont fondés sur une loi quadratique : Bframe = a/q + b/q2 (équation 6) où: - Bframe est l'objectif de débit pour l'image courante qui a un type prédéfini dans le cas d'un GOP à structure fixe, -q est le pas de quantification moyen utilisé dans l'image, - a et b sont des paramètres du modèle estimé par régression linéaire à partir des images précédentes de même type (I, P ou B).

L'organigramme de la figure 6b illustre plus en détail un exemple de mécanisme de contrôle de débit. Un premier test 610 consiste à évaluer si le tampon 315 (figure 3) risque de se remplir, voire déborder. Si un niveau trop élevé (par exemple supérieur à un seuil de remplissage prédéterminé) est atteint, le débit de codage devra être diminué pour adapter le débit de la vidéo au débit du réseau, l'objectif de qualité ne pouvant pas être respecté dans ce cas. Si le niveau de remplissage du tampon 315 est considéré comme élevé (test 610 positif), on passe à l'étape 620 pour calculer un nouveau débit cible. Ce débit peut être calculé de façon à être inférieur au débit moyen du réseau pendant les dernières images, pour pouvoir baisser le niveau de remplissage du tampon 315. 23

Puis à l'étape 625, on calcule une répartition du débit moyen sur les différents types d'images du GOP (I, B, P, comme illustré sur la figure 6a) en fonction de la complexité des images précédentes. Le nouveau débit moyen est réparti entre toutes les images du GOP en fonction de leur nombre (donné par la structure du GOP) et de leur complexité (donnée par les modèles débit-distorsion fondés sur l'équation 6 ci-dessus), pour assurer une répartition équilibrée de la qualité entre les images. Cette répartition fournit ainsi un objectif de taille pour la prochaine image. A l'étape suivante 630, on utilise la formule quadratique du modèle débit-distorsion (voir ci-dessus équation 6) pour calculer le pas de quantification moyen pour l'image suivante. Dans le cas où le niveau de remplissage du tampon est considéré comme faible à l'issue du test 610 (test 610 négatif), on utilise l'objectif de qualité donné par le module de détermination d'objectif de qualité 330 pour calculer, à l'étape 640, le pas de quantification de l'image suivante. On limite ainsi l'augmentation de qualité de la vidéo pour ne pas dépasser l'objectif de qualité fixé par le module 330. A l'issue de l'étape 630 ou de l'étape 640, on dispose du pas de quantification qui est utilisé, à l'étape 650, pour coder l'image suivante.

Le résultat du codage (notamment la taille de l'image codée) peut ensuite être utilisé, à l'étape 660, pour mettre à jour le modèle utilisé par la loi quadratique. On peut évaluer la qualité du codage par exemple en calculant l'amplitude maximale du rapport signal sur bruit (PSNR, en anglais "Peak Signal to Noise Ratio") de l'image. On peut ainsi estimer la complexité de la séquence. On définit la complexité comme le rapport du débit par la qualité. Une autre façon d'évaluer la qualité de l'image consiste à utiliser directement 1/q comme paramètre de qualité : Q = 1/q. Dans ce cas, la complexité peut être définie par la valeur a issue du modèle débit-distorsion donné par l'équation 6 : Bframe = a.Q (équation 6b) 24

Les valeurs de débit, qualité et complexité sont ensuite fournies au module de détermination d'objectif de qualité 330. La figure 7 illustre le principe du calcul de l'objectif de qualité (en liaison avec les étapes 425 et 460 de la figure 4 décrite plus haut).

L'objectif de qualité est calculé en fonction du paramètre de réactivité r de l'algorithme de contrôle de congestion. Ainsi, sur le graphique de la figure 7, l'axe des abscisses représente le paramètre de réactivité et l'axe des ordonnées représente le paramètre de qualité. On évalue d'abord les bornes de variation des deux paramètres.

L'objectif de qualité varie entre une valeur maximale, la qualité optimale Qopt, et une valeur minimale Qmin. Dans l'application de l'invention à un flux de données vidéo, décrite ici à titre nullement limitatif, Qopt est la qualité optimale de la vidéo à regarder. Cette valeur peut être déterminée en fonction de nombreux paramètres, parmi lesquels : la qualité de l'affichage du client : notamment taille et résolution d'écran ; la qualité du contenu : par exemple, disque vidéo numérique à haute définition (HD DVD, en anglais "High Definition Digital Video Disc") ou chaîne de télévision diffusée en norme numérique SD ; les préférences utilisateur : type du contenu (l'utilisateur peut par exemple décider d'attribuer de façon systématique une qualité optimale relativement faible aux émissions pour enfants), de l'identité de la personne qui regarde, ou de l'identité du récepteur (l'utilisateur peut par exemple décider d'avoir une qualité optimale relativement faible pour le poste de réception situé dans la cuisine). Les paramètres de qualité d'affichage client et certaines préférences utilisateur peuvent être mémorisés au niveau du client et transmises au serveur avec la demande pour recevoir un flux vidéo en utilisant par exemple le protocole de streaming en temps réel (RTSP, en anglais "Real Time Streaming Protocof', IETF RFC 2326).

La qualité optimale peut ainsi être calculée comme le minimum des différents objectifs maximums de qualité. On note Qmin la qualité minimale acceptable. La qualité minimale acceptable peut être évaluée en fonction de plusieurs critères semblables à ceux utilisés pour le calcul de la qualité optimale Qopt. Ainsi, la qualité minimale peut être le maximum des qualités minimales pour le client, la source du flux de données et l'utilisateur. Le taux de réactivité r varie entre deux valeurs : rmin : c'est le taux de réactivité minimal. Comme expliqué plus haut en référence à la figure 5, l'algorithme de contrôle de congestion MuITCP se comporte comme s'il y avait r flux TCP en parallèle ; donc dans le cas de MuITCP, une réactivité de valeur 1 donne un comportement identique à TCP. Si on baisse trop la réactivité, un flux MuITCP peut avoir des difficultés à occuper la bande passante disponible. Le taux de réactivité minimal rmin peut être calculé en fonction de la vitesse pour atteindre un débit vidéo normal. rmax : c'est le taux de réactivité maximal. Comme expliqué plus haut en référence à la figure 5, un niveau trop important de réactivité peut conduire à des niveaux de perte importants. Le principe de base du calcul de l'objectif de qualité consiste à faire décroître l'objectif de qualité avec l'augmentation de la réactivité r. Cette baisse permet une convergence du système global pour atteindre un point d'équilibre dans la répartition de bande passante entre les différents flux dans le réseau.

Deux exemples sont représentés sur la figure 7 : Dans l'exemple 705, le niveau de réactivité est noté ri et l'objectif de qualité est noté Qobj. En raison des phénomènes de congestions évoqués précédemment, le niveau de l'objectif de qualité n'est pas atteint : la qualité obtenue par le mécanisme de contrôle de débit atteint une valeur QI inférieure à Qopt. On augmente alors la réactivité pour augmenter le débit et donc la qualité. On baisse l'objectif de qualité pour permettre une stabilisation du système (étapes 410 à 430 de la figure 4).

Dans l'exemple 710, le niveau de réactivité est noté r2 et, dans ce second exemple, la qualité atteinte est égale à l'objectif de qualité Q1. Si le réseau a de la bande passante disponible, on baisse la réactivité et on augmente l'objectif de qualité (étapes 455 à 460 de la figure 4).

On peut préciser la variation de l'objectif de qualité en fonction de la complexité de la vidéo calculée par le mécanisme de contrôle de débit (cf. figure 6b décrite précédemment) : l'objectif de qualité varie de façon préférentielle suivant l'inverse de la complexité (1/a) : Qobj = Qo -c r (équation 7) a où Qo et C sont des constantes calculées de façon que, pour une complexité moyenne amoy, on obtienne les bornes prévues : Qopt = Qo ù Ci rmin amoy

Qmin _ ù Qo ùCi rmax amoy On peut ainsi avoir une répartition de bande passante permettant un équilibrage des qualités.

Par exemple, si on a deux vidéos ayant des objectifs semblables (Qo et C identiques) mais des complexités différentes, notées a, et a2, le point d'équilibre sera atteint lorsque les qualités des deux vidéos, notées Q1 et Q2, seront identiques. En effet, en notant BI et B2 les débits respectifs des deux vidéos et ri et r2 les réactivités respectivement associées à ces vidéos : L'équation 5a donne B, = B2 = BT r, r2 r, + r2 L'équation 6b indique que BI = aiQi et B2 = a2Q2. On obtient donc a1Q1 =a2Q2 r, r2

L'équation 7 donne Q, = Qo ùC et Q2 = Qo ùC r2 . a, a2 Il vient alors facilement a= a et donc, QI = Q2. r, r2 27

On peut aussi préférer donner un avantage à certains flux de données par rapport à d'autres : - soit en modifiant les objectifs pour l'un des flux, ce qui modifie systématiquement la qualité ; - soit en augmentant le paramètre C pour l'un des flux, ce qui fera décroître plus rapidement sa qualité en cas de congestion. A titre d'exemple nullement limitatif, cette méthode peut être utilisée pour faire baisser la qualité du flux d'un dessin animé pour enfant plus vite que la qualité du flux d'une chaîne de télévision de reportage en haute définition (HD) pour les parents, en cas de congestion uniquement, tout en laissant une qualité maximale au cas où de la bande passante est disponible.

Claims (16)

REVENDICATIONS

1. Procédé de transmission d'un flux de données entre un serveur (101) et au moins un client (102) dans un réseau de communication (100), ledit serveur mettant en oeuvre un mécanisme de contrôle de congestion dudit réseau, ledit flux de données étant codé avec un débit variable, ledit procédé étant caractérisé en ce qu'il comporte des étapes consistant, pour le serveur (101), à: - modifier (410, 455) un paramètre de réactivité (r) dudit mécanisme de contrôle de congestion, en fonction de l'état de charge du réseau, - contrôler (630, 640) le débit de codage dudit flux de données en fonction d'un objectif de qualité (Qobj), et - modifier (425, 460) ledit objectif de qualité (Qobj) en fonction dudit paramètre de réactivité (r).

2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de modification dudit objectif de qualité (Qobj) consiste à baisser (425) l'objectif de qualité (Qobj) lorsqu'on augmente (410) la réactivité (r) et à augmenter (460) l'objectif de qualité (Qobj) lorsqu'on baisse (455) la réactivité (r).

3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comporte en outre une étape consistant, pour ledit serveur (101), à modifier ledit objectif de qualité (Qob;) en fonction de la complexité (a) dudit flux de données.

4. Procédé selon la revendication 3, caractérisé en ce que ladite étape de modification dudit objectif de qualité (Qob;) en fonction de la complexité (a) dudit flux de données consiste à faire varier l'objectif de qualité (Qobj) en raison inverse de la complexité.

5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape consistant, pour ledit serveur (101), à modifier ledit objectif de qualité (Qobj) en fonction des préférences dudit client (102) concernant la qualité dudit flux de données. 29

6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit flux de données est un flux vidéo.

7. Serveur (101) de transmission d'un flux de données à au moins un client (102) dans un réseau de communication (100), ledit serveur comportant des moyens (325) de contrôle de congestion dudit réseau, ledit flux de données étant codé avec un débit variable, ledit serveur étant caractérisé en ce qu'il comporte : - des moyens (330) pour modifier un paramètre de réactivité (r) desdits moyens (325) de contrôle de congestion, en fonction de l'état de charge 10 du réseau, - des moyens (320) pour contrôler le débit de codage dudit flux de données en fonction d'un objectif de qualité (Qobj), et - des moyens pour modifier ledit objectif de qualité (Qobj) en fonction dudit paramètre de réactivité (r). 15

8. Serveur selon la revendication 7, caractérisé en ce que lesdits moyens pour modifier ledit objectif de qualité (Qobj) sont adaptés à baisser l'objectif de qualité (Qobj) lorsque lesdits moyens pour modifier le paramètre de réactivité (r) augmentent ladite réactivité (r) et à augmenter l'objectif de qualité (Qobj) lorsque lesdits moyens pour modifier le paramètre de réactivité (r) 20 baissent ladite réactivité (r).

9. Serveur selon la revendication 7 ou 8, caractérisé en ce que lesdits moyens pour modifier ledit objectif de qualité (Qobj) sont en outre adaptés à modifier ledit objectif de qualité (Qobj) en fonction de la complexité (a) dudit flux de données. 25

10. Serveur selon la revendication 9, caractérisé en ce que lesdits moyens pour modifier ledit objectif de qualité (Qobj) en fonction de la complexité (a) dudit flux de données sont adaptés à faire varier l'objectif de qualité (Qobj) en raison inverse de la complexité.

11. Serveur selon l'une quelconque des revendications 7 à 10, 30 caractérisé en ce que lesdits moyens pour modifier ledit objectif de qualité (Qobj) sont en outre adaptés à modifier ledit objectif de qualité (Qobj) en fonction des préférences dudit client (102) concernant la qualité dudit flux de données. 30

12. Serveur selon l'une quelconque des revendications 7 à 11, caractérisé en ce que ledit flux de données est un flux vidéo.

13. Système de télécommunications comprenant une pluralité de dispositifs terminaux reliés à travers un réseau de télécommunications, caractérisé en ce qu'il comprend au moins un serveur de transmission selon l'une quelconque des revendications 1 à 6.

14. Moyen de stockage d'informations pouvant être lues par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il est adapté à mettre en oeuvre un procédé de transmission selon l'une quelconque des revendications 1 à 6, lorsque lesdites informations sont lues par ledit ordinateur ou ledit microprocesseur.

15. Moyen de stockage selon la revendication 14, caractérisé en ce qu'il est partiellement ou totalement amovible.

16. 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 à 6, lorsque ledit produit programme d'ordinateur est chargé dans et exécuté par ledit appareil programmable.