FR2948249A1 - Procedes et dispositifs d'estimation d'un niveau d'utilisation d'un reseau de communication et d'adaptation d'un niveau d'abonnements a des groupes multipoints - Google Patents

Abstract

L'invention a notamment pour objet un procédé et un dispositif d'estimation d'un niveau d'utilisation d'un réseau de communication reliant un serveur et au moins un client, ledit réseau de communication étant utilisé pour transmettre un flux de données à un débit de transmission correspondant à la fréquence temporelle dudit flux de données, ledit flux de données comprenant au moins une information caractérisant un débit théorique dépendant dudit débit de transmission dudit flux de données. Après avoir obtenu (121) ledit débit théorique dudit flux de données, le débit réel de réception d'au moins une partie dudit flux de données est évalué (109). Ledit débit théorique et ledit débit évalué sont ensuite comparés (113) pour estimer ledit niveau d'utilisation dudit réseau de communication. Le niveau d'abonnements d'un client à des groupes multipoints peut être adapté selon le niveau d'utilisation du réseau de communication.

Description

La présente invention concerne la transmission de données entre un serveur et un client à travers un réseau de communication et plus particulièrement des procédés et des dispositifs d'estimation d'un niveau d'utilisation d'un réseau de communication et d'adaptation d'un niveau d'abonnements à des groupes multipoints selon le niveau d'utilisation du réseau. L'invention se place dans le cadre de la transmission d'un flux de données tel qu'une séquence vidéo entre un serveur et au moins un client sur un réseau de communication non fiable, c'est-à-dire dans lequel les conditions de transmission ne sont pas stables et où des pertes de données peuvent se produire. Un tel réseau de communication est par exemple le réseau Internet selon lequel les données sont transmises par paquets. H.264/AVC (sigle d'Advanced Video Coding en terminologie anglo-saxonne) est un standard de compression vidéo offrant une bonne qualité vidéo pour un taux de transfert relativement bas. Il s'agit d'une compression par blocs mettant en oeuvre des algorithmes d'estimation et de compensation de mouvement. Il a été développé pour être facilement utilisable dans un grand nombre d'applications et de conditions. Une extension du standard H.264/AVC est le standard SVC (sigle de Scalable Video Coding en terminologie anglo-saxonne) qui a pour objet de coder un flux vidéo de haute qualité en un ensemble de flux binaires comprenant un flux de base et plusieurs flux d'amélioration qui, lorsqu'ils sont décodés avec le flux de base, viennent améliorer la qualité de celui-ci Un tel codage de séquences vidéo est dit hiérarchique ou "scalable", c'est-à-dire qu'il met en oeuvre un ou plusieurs niveaux hiérarchiques, appelés aussi niveaux ou couches de scalabilité. Trois types de scalabilité ont été définis dans la norme SVC : scalabilité spatiale, temporelle et en qualité, la scalabilité en qualité étant également connue sous le nom de scalabilité SNR (sigle de Signal to Noise Ratio en terminologie anglo-saxonne, représentant le rapport signal à bruit). La scalabilité temporelle permet de modifier la résolution temporelle d'une séquence (c'est-à-dire le nombre d'images par seconde représentées par les données codées) en supprimant certaines images, cette suppression prenant en compte les dépendances éventuelles entre les images. La scalabilité spatiale consiste à insérer plusieurs résolutions spatiales (correspondant à différents nombres de pixels représentés par les données codées) dans un flux vidéo, la résolution la plus basse étant utilisée pour la prédiction des résolutions supérieures. La scalabilité en qualité vise trois formes différentes : la scalabilité à grains grossiers ou CGS (sigle de Coarse Grain Scalability en terminologie anglo-saxonne), la scalabilité à grains moyens ou MGS (sigle de Medium Grain Scalability en terminologie anglo-saxonne) et la scalabilité à grains fins ou FGS (sigle de Fine Grain Scalability en terminologie anglo-saxonne). La scalabilité CGS utilise les mêmes concepts que la scalabilité spatiale, à ceci près que pour CGS, les opérations de sur-échantillonnage de la prédiction inter-couche sont omises. La scalabilité FGS permet la création d'un flux binaire qui peut être tronqué en un point quelconque tout en restant décodable. La scalabilité MGS a été définie comme intermédiaire entre CGS et FGS : elle offre des points de décodage dans le flux binaire plus fins que CGS mais ne permet pas la troncature en n'importe quel point comme FGS. La scalabilité MGS est souvent considérée comme offrant une granularité suffisante pour des conditions réseau réalistes.

La transmission d'une vidéo sur un réseau est facilitée par l'introduction de la notion d'entité NAL (acronyme de Network Abstraction Layer en terminologie anglo-saxonne). Une NAL est une unité élémentaire de transfert du flux binaire qui fournit dans son en-tête des éléments de description des données transportées dans la partie données de la NAL.

Toutes les NALs correspondant à un même instant temporel forment une entité appelée AU (en anglais "Access Unit").

Des messages de type SEI (sigle de Supplemental Enhancement Information en terminologie anglo-saxonne) peuvent être utilisés pour faciliter certaines opérations telles que le décodage et l'affichage. Ces messages sont également transmis sous forme de NAL. Parmi ces messages, il en existe notamment un appelé "scalability information SEI" dont les champs indiquent des caractéristiques de scalabilité du flux de données dans lequel le message est transmis. En particulier, un tel message, appelé message SEI de scalabilité dans la suite de la description, peut comprendre une information relative au débit moyen lié à une couche de scalabilité i, référencée Avg bitrate[i], ainsi qu'une information relative au débit maximal lié à une couche de scalabilité ide la séquence SVC concernée par le message SEI, référencée Max bitrate layer[i]. La présence de ces informations est renseignée par un indicateur noté bitrate info present flag[i]. Les couches de scalabilité sont généralement transmises à travers un réseau de communication, par exemple sous forme de paquets, selon des groupes multipoints, appelées multicast sessions en terminologie anglo-saxonne, permettant à des clients de souscrire des abonnements auprès d'un ensemble de groupes multipoints, c'est-à-dire d'adhérer à ces groupes, selon ses capacités, en particulier ses capacités de réception, de décodage, de traitement et d'affichage. Un problème lié aux réseaux de communication est la variation de leur capacité. La bande passante et le taux d'erreur de transmission varient souvent en fonction des comportements des clients mais également indépendamment de leur comportement, en raison notamment du trafic engendré par d'autres applications. Si les applications utilisant le réseau ne réagissent pas de façon adéquate en fonction de ses capacités, il existe un risque de congestion pouvant provoquer la perte de paquets ou, au contraire, une possible sous-utilisation du réseau. Il convient de noter ici que la perte de données dans des flux vidéo transmis induit des erreurs de reconstruction des données vidéo au niveau des dispositifs clients. Il est donc préférable d'éviter les problèmes de congestion durant leur transmission.

Les problèmes de congestion surviennent notamment lorsque les mémoires tampons d'un routeur sont pleines. Cependant, au début d'une période de congestion, il existe une période durant laquelle aucun paquet n'est perdu et durant laquelle des caractéristiques particulières peuvent être identifiées. En effet, lorsqu'un paquet est transmis durant cette période, il est mémorisé un certain temps dans le routeur au lieu d'être routé quasi directement. Ainsi, le temps global passé par un paquet dans le réseau, entre le serveur et un client, augmente. L'identification de cette période particulière permet d'anticiper la perte de paquets et donc de réagir en conséquence.

Une solution pour détecter un début de congestion, avant la perte de paquet, consiste à mesurer une période de temps appelé RTT (sigle de Round Trip Time en terminologie anglo-saxonne) correspondant au temps que met un paquet pour faire l'aller/retour entre un serveur et un client. Une augmentation du RTT indique une congestion ou un début de congestion. Le RTT peut se mesurer en transmettant un premier paquet, contenant l'instant auquel il est transmis, depuis un client vers un serveur. A la réception de ce premier paquet, le serveur transmet au client un second paquet, contenant l'instant auquel ce premier paquet a été transmis et le temps écoulé entre la réception du premier paquet et la transmission du second, depuis le serveur vers le client. A la réception de ce second paquet, le client compare l'instant auquel le premier paquet a été transmis avec celui de réception du second paquet, en tenant compte du temps écoulé entre la réception du premier paquet et la transmission du second. Bien que cette solution offre une bonne estimation du RTT, et donc d'une congestion ou d'un début de congestion, elle présente néanmoins les deux inconvénients majeurs suivants : - la nécessité de mettre en oeuvre, côté serveur, des outils permettant de recevoir et d'émettre les paquets utilisés pour mesurer le RTT ainsi que de mesurer le temps entre la réception des premiers paquets et l'émission des seconds ; et, - le manque de scalabilité (la solution devient inefficace lorsque le nombre de clients augmente).

D'autres solutions sont basées sur le temps mis par un paquet pour atteindre un client à partir de son émission du serveur. Cependant, si ces solutions permettent de détecter efficacement un début de congestion, elles nécessitent une synchronisation entre serveurs et clients.

Réciproquement, il existe des solutions pour détecter une augmentation de la bande passante. Par exemple, lorsqu'un client ne détecte aucune perte de paquet, il peut souscrire un abonnement auprès d'un autre groupe multipoints pour recevoir des données supplémentaires afin d'améliorer la qualité de la vidéo reçue. Cette procédure peut être répétée jusqu'à ce que la bande passante optimale soit identifiée, c'est-à-dire jusqu'à ce que la perte de paquets soit identifiée. Cependant, une telle solution entraîne nécessairement une congestion pour atteindre la bande passante optimale. Une autre solution consiste à permettre au serveur d'augmenter le débit de transmission des données et à mesurer le temps nécessaire pour recevoir un accusé réception lié à la réception de chaque paquet par le client. Quand ce temps augmente, le serveur cesse d'augmenter le débit de transmission (il a atteint le débit provoquant une congestion). Cependant, cette solution nécessite des outils spécifiques du côté du serveur pour augmenter le débit de transmission et mesurer le temps lié à la réception d'accusés réception ainsi que la coopération du client qui doit transmettre des accusés réception pour chaque paquet reçu. Par conséquent, il existe un besoin d'améliorer la transmission de flux de données scalables à travers un réseau de communication, entre un serveur et un client, selon la bande passante disponible.

L'invention permet de résoudre au moins un des problèmes exposés précédemment. Plus précisément, l'invention propose un système d'abonnement et de désabonnement à des groupes multipoints de transmission de données scalables selon les caractéristiques du réseau de communication mis en oeuvre. A ces fins, le système permet à un client de mesurer la charge ou le niveau d'utilisation du réseau pour détecter une congestion avant que des données ne soient perdues.

L'invention a ainsi pour objet un procédé pour ordinateur d'estimation d'un niveau d'utilisation d'un réseau de communication reliant un serveur et au moins un client, ledit réseau de communication étant utilisé pour transmettre un flux de données à un débit de transmission correspondant à la fréquence temporelle dudit flux de données, ledit flux de données comprenant au moins une information caractérisant un débit théorique dépendant dudit débit de transmission dudit flux de données, ce procédé comprenant les étapes suivantes mises en oeuvre par ledit au moins un client : - obtention dudit débit théorique dudit flux de données ; - évaluation du débit réel de réception d'au moins une partie dudit flux de données ; - comparaison dudit débit théorique et dudit débit évalué ; - en réponse à ladite comparaison, estimation dudit niveau d'utilisation dudit réseau de communication.

Le procédé selon l'invention permet ainsi à un client d'évaluer facilement et efficacement le niveau d'utilisation du réseau de communication le reliant au serveur sans nécessiter d'adaptation du côté du serveur ni perturber le réseau de communication. Selon un mode de réalisation particulier ladite étape de comparaison dudit débit théorique et dudit débit évalué comprend une étape d'analyse de l'évolution de la différence entre ledit débit théorique et ledit débit évalué, ladite évolution de la différence entre ledit débit théorique et ledit débit évalué caractérisant un niveau d'utilisation adapté dudit réseau de communication, une sous utilisation dudit réseau de communication ou une congestion dudit réseau de communication. Le procédé selon l'invention permet ainsi au client de savoir s'il peut bénéficier de plus de bande passante ou, au contraire, s'il doit en libérer. Ledit flux de données est, de préférence, un flux de données scalables, ledit débit théorique pouvant être déterminé selon un débit théorique associé à chaque couche de scalabilité dudit flux de données. Le procédé selon l'invention peut ainsi utiliser les données transmises par un serveur pour déterminer un débit théorique sans nécessiter d'information supplémentaire.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de correction de ladite au moins une information caractérisant ledit débit théorique dudit flux de données afin d'améliorer l'estimation du comportement d'un réseau de communication.

Ladite étape de correction comprend avantageusement une étape d'estimation, pour une période de temps prédéterminée, d'un débit instantané théorique, ledit débit instantané théorique étant dépendant du contenu dudit flux de données reçu pendant ladite période de temps. Le procédé selon l'invention s'adapte donc rapidement aux conditions de transmission liées au réseau de communication. Ladite étape de correction n'est effectuée que si la variance de l'évolution dudit débit théorique est supérieure à un seuil prédéterminé pour éviter des calculs qui ne seraient pas réellement utiles. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'un état dudit au moins un client, ledit état dudit au moins un client étant déterminé selon la variation de la différence entre ledit débit théorique et ledit débit évalué et selon la variation du nombre desdites couches de scalabilité dudit flux de données reçu par ledit au moins un client, le procédé comprenant en outre une étape de transmission d'une indication dudit état dudit au moins un client audit serveur si ledit état dudit au moins un client est stable pour indiquer audit serveur d'augmenter ledit débit de transmission dudit flux de données pour que, de préférence, ledit débit de transmission dudit flux de données soit supérieur au débit de transmission correspondant à la fréquence temporelle dudit flux de données. Le procédé selon l'invention permet ainsi d'améliorer la détection de l'augmentation de la bande passante. Avantageusement, le procédé comprend en outre une étape d'analyse de l'évolution dudit débit évalué et une étape de détermination de sous utilisation dudit réseau de communication, ladite détermination étant basée sur l'analyse dudit état dudit au moins un client et sur ladite analyse de ladite évolution dudit débit évalué. Le procédé selon l'invention permet ainsi de détecter rapidement et efficacement une sous utilisation du réseau de communication. Toujours selon un mode de réalisation particulier, le procédé comprend en outre en outre une étape de détermination d'un état dudit au moins un client, ledit état dudit au moins un client étant déterminé selon la variation de la différence entre ledit débit théorique et ledit débit évalué et selon la variation du nombre desdites couches de scalabilité dudit flux de données reçu par ledit au moins un client, le procédé comprenant en outre, si ledit état dudit au moins un client est stable, les étapes suivantes : - comparaison dudit débit théorique avec au moins un débit de réception d'au moins une partie dudit flux de données évalué sur au moins un intervalle de temps passé ; et, - détermination d'une sous utilisation dudit réseau de communication si ledit au moins un débit de réception d'au moins une partie dudit flux de données évalué sur au moins un intervalle de temps passé est supérieur audit débit théorique. Le procédé selon l'invention permet ainsi d'éviter d'impliquer le serveur tout en permettant d'améliorer la détection de l'augmentation de la bande passante.

L'invention a également pour objet un procédé pour ordinateur d'adaptation d'un niveau d'abonnements à des groupes multipoints pour recevoir des données scalables dans un système comprenant un serveur et au moins un client, ledit serveur et ledit au moins un client étant reliés par un réseau de communication, ce procédé comprenant les étapes suivantes : - estimation du niveau d'utilisation dudit réseau de communication selon le procédé décrit précédemment ; et, - en réponse à ladite étape d'estimation dudit niveau d'utilisation dudit réseau de communication, modification du débit de réception dudit flux de données en adaptant ledit niveau d'abonnements auxdits groupes multipoints.

Le procédé selon l'invention permet ainsi d'optimiser la qualité des données reçues en fonction de l'état du réseau de communication transmettant des données. Ainsi, de façon avantageuse, si ledit réseau de communication est sous utilisé ledit client souscrit à un abonnement pour recevoir une couche de scalabilité supérieur et si ledit réseau de communication est congestionné ledit client abandonne un abonnement à une couche de scalabilité reçue. L'invention a aussi pour objet un procédé pour ordinateur de traitement d'un flux de données scalables, ledit flux de données scalables comprenant au moins un message comprenant au moins une information caractérisant un débit théorique dudit flux de données, le procédé étant mis en oeuvre dans un serveur et comprenant les étapes suivantes : - estimation d'un débit instantané théorique selon la quantité de 10 données dudit flux de données à transmettre durant une période de longueur prédéterminée ; - comparaison du débit théorique avec ledit débit instantané théorique ; et, - en réponse à ladite comparaison, création d'un message 15 comprenant ledit débit instantané théorique si la différence entre ledit débit théorique et ledit débit instantané théorique est supérieure à un seuil prédéterminé. Le procédé selon l'invention permet ainsi de faciliter et d'améliorer l'estimation du niveau d'utilisation du réseau sur un dispositif client en 20 fournissant au dispositif client le débit instantané théorique estimé sur une période donnée. Selon un mode de réalisation particulier, ledit flux de données est un flux vidéo, ledit débit théorique étant déterminé pour la fréquence temporelle de la séquence vidéo représentée par ledit flux vidéo. 25 L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur, des moyens de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur 30 comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé décrit précédemment ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur, ces moyens de stockage et ce dispositif sont similaires à ceux évoqués précédemment.

D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement un système de transmission d'un flux vidéo entre un serveur et un client dans un réseau de communication ; - la figure 2 illustre un exemple d'algorithme, selon un premier mode de réalisation, pour estimer le niveau d'utilisation d'un réseau et l'évolution de ses capacités afin d'adapter le comportement d'un client pour lui permettre, en particulier, de s'abonner ou se désabonner à des groupes multipoints ; - la figure 3 illustre une variante de l'algorithme illustré sur la figure 2 comprenant notamment des étapes supplémentaires permettant le calcul d'un débit instantané théorique afin d'améliorer l'estimation du comportement d'un réseau ; - les figures 4 et 5 illustrent des exemples de l'évolution du débit moyen observé et du débit instantané théorique par rapport au débit moyen théorique ; - la figure 6 illustre un exemple d'algorithme pouvant être mis en oeuvre par un serveur pour évaluer des variations importantes du débit de transmission par rapport au débit moyen théorique et générer des messages SEI correspondants ; - la figure 7 illustre un exemple de résultats produits par l'algorithme illustré sur la figure 6 ; - la figure 8 illustre une faible différence entre le débit moyen théorique et la somme des valeurs du paramètre Max bitrate layer[i] pour chaque couche reçue par un client, pour laquelle il n'est pas nécessaire de calculer le débit instantané théorique ; et, - la figure 9 illustre une forte probabilité qu'une partie de la bande passante soit disponible lorsqu'un client a, dans le passé, estimé un débit moyen observé supérieur au débit moyen théorique, sans identifier de début de congestion, lui permettant de souscrire un abonnement à de nouveaux groupes multipoints. La description qui suit vise, à titre d'illustration, la transmission d'un flux vidéo scalable. Cependant, l'invention peut être mise en oeuvre avec tout autre type de données, de préférence scalables, transmises d'un serveur à un client via un réseau de communication selon un mode de communication basé sur l'adhésion à des groupes multipoints. Bien qu'il soit considéré dans la suite de la description que chaque groupe multipoint correspond à une couche de scalabilité, il peut en être autrement. En particulier, il est possible de mettre en oeuvre l'invention avec un nombre de groupes multipoints inférieur au nombre de couches scalabilité. La figure 1 illustre schématique un système de transmission d'un flux vidéo entre un serveur 1 et un client 2 via un réseau de communication 3, par 15 exemple un réseau Ethernet. Le serveur 1 comprend ici une unité de traitement 4, aussi appelée processeur ou CPU (sigle de Central Processing Unit en terminologie anglo-saxonne) adaptée à exécuter un ou plusieurs programmes. Il comprend également une unité de stockage 5 et une interface réseau 6 qui permet au 20 serveur, en particulier, de transmettre des données via le réseau de communication 3. Les données sont avantageusement transmises selon le protocole RTP (sigle de Real-Time Transport Protocol en terminologie anglo-saxonne). Le serveur peut également comprendre des moyens d'acquisition et de codage (non représentés) pour recevoir un flux vidéo d'une source telle 25 qu'une caméra et le transmettre sous forme d'un flux de données scalables. L'unité de stockage 5 permet notamment de mémoriser des données telles que des données vidéo codées de type SVC. Il est considéré ici que les données sont transmises de façon continue sous forme d'un flux SVC selon un mode de communication basé sur 30 l'adhésion à des groupes multipoints, chaque couche de scalabilité spatiale étant associée à un groupe. En outre, selon un mode de réalisation préféré, les données sont transmises selon la fréquence temporelle de la séquence.

De façon similaire, le client 2 comprend une unité de traitement 7 permettant notamment d'exécuter le programme selon l'invention, une unité de stockage 8, une interface réseau 9 adaptée à recevoir les données scalables transmises par le serveur et une unité d'affichage 10 telle qu'un écran.

La figure 2 illustre un exemple d'algorithme, selon un premier mode de réalisation, pour estimer le niveau d'utilisation d'un réseau de communication et l'évolution de ses capacités afin d'adapter le comportement d'un client pour lui permettre, en particulier, de s'abonner ou se désabonner à des groupes multipoints.

Une première étape (étape 101) a pour objet l'abonnement du client à un ensemble de groupes multipoints. Cet ensemble de groupes peut correspondre à la totalité ou à une partie des groupes multipoints auxquels sont associés les niveaux de qualité du flux vidéo transmis. Cette première étape permet ainsi de déterminer la variable Imax correspondant au nombre de groupes multipoints auxquelles s'abonne le client (à l'exception de celui correspondant au flux de base), c'est-à-dire ici au nombre de couches de scalabilité reçues (à l'exception de la couche correspondant au flux de base). La variable Dcurr, représentant la différence entre le débit moyen observé et le débit moyen théorique, est initialisé à la valeur zéro (étape 102).

Les paquets RTP sont ensuite reçus (étape 103). Cette étape de réception peut viser un seul paquet RTP ou un nombre prédéterminé de paquets RTP. Par conséquent, les étapes suivantes, référencées 103 à 139, sont effectuées pour un seul ou pour plusieurs paquets RTP de telle sorte que tous les paquets reçus soient traités.

Après avoir reçu au moins un paquet RTP, la NAL transportée par ce paquet est extraite (étape 105) et un test est effectué pour déterminer si la NAL correspond à un message SEI de scalabilité (étape 107). Il est considéré ici que le serveur transmet systématiquement au moins un message SEI de scalabilité par séquence vidéo transmise.

Si le paquet reçu correspond à un tel message, une variable i est initialisée à zéro (étape 115) et une variable BTh représentant le débit moyen théorique de la séquence, selon l'abonnement du client, est également initialisée à zéro (étape 116). Un test est ensuite effectué pour déterminer si la variable i est inférieure ou égale à la variable Imax (étape 117). Si la variable i est inférieure ou égale à la variable Imax, le débit moyen correspondant à la couche ayant l'index i est extrait du message SEI de scalabilité (étape 119). Il est supposé ici que l'indicateur bitrate info present flag[i] est systématiquement présent pour chaque couche. Par conséquent, la valeur Avg bitrate[i] représentant le débit moyen pour la couche ayant l'index i et la valeur Max bitrate layer[i] représentant le débit maximal pouvant être utilisé pour la couche ayant l'index i sont toujours disponibles pour chaque couche de scalabilité. Selon ce mode de réalisation, seul le débit moyen théorique associé à la couche ayant l'index i, noté bTh , égal au débit moyen indiqué dans le message SEI de scalabilité (bTh = Avg bitrate[i]), est utilisé pour déterminer le débit moyen théorique de la séquence (Brh). Le débit moyen théorique de la séquence, selon l'abonnement du client, est ensuite obtenu (étape 121) en cumulant les débits moyens théoriques associés à chaque couche. A cette fin, l'index i est incrémenté de un et les étapes précédentes (étapes 117 à 121) sont répétées tant que la valeur de la variable i est inférieure ou égale à celle de la variable Imax. Il convient de remarquer ici que, comme indiqué précédemment, le flux vidéo étant transmis selon la fréquence temporelle de la séquence, le débit moyen théorique est en principe respecté. Lorsque le débit moyen théorique a été évalué, c'est-à-dire lorsque la valeur de l'index i est supérieure à celle de la variable Imax, ou si le paquet reçu ne correspond pas à un message SEI de scalabilité, le débit moyen observé, noté TH (pour throughput en terminologie anglo-saxonne) est estimé (étape 109). Pour estimer cette valeur, le client accumule la taille des paquets reçus durant un temps prédéterminé selon un mécanisme de fenêtre glissante d'une longueur A, exprimé ici en secondes, dont la fin correspond à l'instant présent. La taille cumulée des paquets reçus est alors divisée par la longueur A de la fenêtre glissante pour obtenir le débit moyen observé TH.

La valeur de la variable Dcurr est alors mémorisée dans une variable Dprev (étape 111) puis la nouvelle valeur de la variable Dcurr est calculée (étape 113). Comme décrit précédemment, elle correspond à la différence entre le débit moyen observé TH et le débit moyen théorique de la séquence BTh, selon l'abonnement du client. Pour suivre l'évolution de cette différence, le client calcule ensuite sa dérivée, notée dD, selon la relation suivante : Dcurr ûD prev dD = où 8 correspond à la différence de temps entre les instants où les deux derniers débits moyens observés ont été calculés. La valeur de la dérivée est ensuite analysée. Selon cette valeur, le client peut décider de maintenir son niveau d'abonnement, de souscrire à de nouveaux abonnements ou d'abandonner certains abonnements. Si la valeur de la dérivée est égale à zéro (étape 125), c'est-à-dire s'il n'y a pas de variation entre le débit moyen théorique et le débit moyen observé, le client décide, de préférence, de conserver son niveau d'abonnement (étape 131) car dans ce cas, le niveau d'utilisation du réseau de communication par le client est adapté. Si la valeur de la dérivée est inférieure à zéro (étape 127), le client peut en déduire une congestion ou un début de congestion, c'est-à-dire une diminution de bande passante. Un test est alors réalisé (étape 133) pour déterminer si le client est abonné à plusieurs groupes multipoints, c'est-à-dire si la valeur de la variable Imax est égale à zéro ou non. Si le client est abonné à plusieurs groupes multipoints, il peut décider de renoncer à l'abonnement relatif au groupe multipoints correspondant à la plus haute couche de scalabilité reçue (étape 137). Si le client ne reçoit que le flux de base, le client ne modifie pas son abonnement (étape 131). Si la valeur de la dérivée est supérieure à zéro, c'est-à-dire si elle n'est pas égale ni inférieure à zéro, le client en déduit que la bande passante augmente et donc que le réseau est en sous utilisation. Le client peut donc potentiellement recevoir plus de données. Un test est alors effectué (étape 135) s pour déterminer si le client est abonné à tous les groupes multipoints. A cette fin, la variable Imax est comparée avec une variable MAX correspondant au nombre de groupes multipoints auxquelles peut s'abonner le client, à l'exception de celui correspondant au flux de base, c'est-à-dire le nombre de groupes multipoints générés par le serveur, toujours à l'exception de celui correspondant au flux de base. Dans l'affirmative, le client ne modifie pas son abonnement (étape 131). Si, au contraire, le client n'est pas abonné à tous les groupes multipoints, il peut s'abonner à un nouveau groupe multipoints associé à une couche de scalabilité supérieure (étape 139).

Le processus se répète tant que de nouveaux paquets sont reçus, à partir de l'étape 103. Une limite de ce premier mode de réalisation est liée à l'utilisation d'une valeur moyenne de débit théorique visant une séquence dans son ensemble. En effet, il peut survenir des variations autour de cette valeur moyenne qui peuvent induire des modifications dans la différence entre le débit moyen observé et le débit moyen théorique. De telles modifications peuvent entraîner des interprétations erronées selon lesquelles il y aurait une augmentation ou une réduction de la bande passante. Pour éviter ce phénomène, il est possible de remplacer le calcul de la valeur du débit moyen théorique Brh par le calcul d'une variable BTh correspondant à la valeur du débit instantané théorique. Cette valeur dépend du contenu de la portion de la séquence vidéo considérée pour ce calcul. Comme décrit précédemment, la valeur de la variable BTh est calculée sur un intervalle de temps A. Le serveur respectant la fréquence temporelle de la séquence, il transmet systématiquement la même quantité d'images pour chaque période A. Celle-ci peut, par exemple, correspondre à un GOP (acronyme de Group Of Pictures en terminologie anglo-saxonne) ou à un ensemble de GOPs consécutifs. Ainsi, selon le contenu de la séquence vidéo ayant une durée A (mouvements rapides ou lents, nature des textures, etc.), le débit instantané théoriqueBTh varie autour du débit moyen théorique Brh. La figure 3 illustre une variante de l'algorithme illustré sur la figure 2 comprenant notamment des étapes supplémentaires permettant le calcul d'un débit instantané théorique afin d'améliorer l'estimation du comportement d'un réseau de communication. Outre les étapes décrites en référence à la figure 2, comprenant les mêmes références, l'algorithme comprend ici les étapes 104a, 104b, 122a et 122b. Par ailleurs, l'étape 113 est modifiée. Ainsi, pour calculer le débit instantané théoriqueBTh, l'algorithme comprend les étapes 104a et 104b, exécutées après les étapes de réception des paquets RTP (étape 103) et leur analyse (étape 105). Après avoir reçu un ou plusieurs paquets, le client calcule le débit moyen global observé depuis le début de la réception du flux vidéo, appelé THA (étape 104a). Cette étape consiste à cumuler la taille des paquets reçus depuis le début de cette réception et à diviser le total par le temps écoulé depuis cet instant. Le client calcule ensuite le débit moyen observé durant une période A, appelé THo (étape 104a). Cette étape consiste à cumuler la taille de tous les paquets reçus durant cette période A et à diviser le total obtenu par la longueur de cette période. Par ailleurs, après avoir calculé le débit moyen théorique BTh (étapes 117 à 121) et avant de calculer le débit moyen observé TH, le client calcule un facteur de correction appelé a (étape 122a), pouvant être une valeur positive ou négative. Elle est par exemple calculée à l'aide de la relation suivante : a= THA -THA THA Le débit instantané théorique BTh est ensuite estimé à partir du débit moyen théorique BTh et de ce facteur de correction a (étape 122b), par exemple selon la relation suivante, B iTh _ (1+a)BTh Si le facteur de correction a est positif, le débit instantané théorique est supérieur au débit moyen théorique. Inversement, si le facteur de correction a est négatif, le débit instantané théorique est inférieur au débit moyen théorique.

L'étape 113 est modifiée (étape 113') de telle sorte que la variable Dm-, représente la différence entre le débit observé TH et le débit instantané théorique BTh . Il convient de noter ici que d'autres approches peuvent être utilisées pour déterminer le débit instantané théorique BTh . A titre d'illustration, le facteur de correction a peut être estimé pour chaque couche scalable traitée. Une autre solution consiste à prendre en compte les données reçues durant la période A afin d'estimer plus précisément les données devant encore être reçues. Il est également possible de comparer la valeur de la dérivée dD avec des seuils prédéterminés pour éviter, par exemple, de modifier le niveau d'abonnement d'un client si cette valeur, bien qu'étant différente de zéro, est sensiblement égale à zéro. Ainsi, si cette valeur est comprise entre un premier et un second seuil, le client peut décider de ne pas modifier son niveau d'abonnements, si elle est inférieure au seuil le plus faible, il peut décider de renoncer à un abonnement et si elle est supérieure au seuil le plus élevé, il peut décider de souscrire, si c'est possible, à un nouvel abonnement. La figure 4 illustre un premier exemple de l'évolution du débit moyen observé et du débit instantané théorique par rapport au débit moyen théorique. L'axe des abscisses représente ici le temps tandis que l'axe des ordonnées représente le débit. La référence 400 vise ici le débit moyen associé à la couche ayant l'index i, c'est-à-dire Avg bitrate[i], tandis que la référence 405 vise le débit maximal associé à la couche ayant l'index i, c'est-à-dire Max bitrate layer[i]. La référence 410 représente l'évolution du débit moyen observé TH et la référence 415 représente l'évolution du débit instantané théorique BTh . Jusqu'à l'instant noté t9, la différence entre le débit moyen observé TH et le débit instantané théoriqueBTh est sensiblement constante. Il n'est donc pas nécessaire que le client modifie son niveau d'abonnements. A partir de l'instant t9, la différence entre ces débits (en valeur absolue) augmente. En analysant le comportement de cette différence, le client peut, à l'instant t2, l'instant t2 suivant l'instant t9 selon une période de temps A, détecter un début de congestion. Plus précisément, comme illustré par la flèche référencée 420, la dérivée dD étant ici négative, le client en déduit qu'il doit se désabonner à un groupe multipoints pour ne plus recevoir les données de la couche de scalabilité la plus élevée reçue.

La figure 5 illustre un second exemple de l'évolution du débit moyen observé et du débit instantané théorique par rapport au débit moyen théorique. Comme pour la figure 4, l'axe des abscisses représente ici le temps tandis que l'axe des ordonnées représente le débit. De même, les références 400 et 405 visent ici le débit moyen associé à la couche ayant l'index i, c'est-à-dire Avg bitrate[i], et le débit maximal associé à la couche ayant l'index i, c'est-à-dire Max bitrate layer[i] , respectivement. La référence 425 représente l'évolution du débit moyen observé TH et la référence 430 représente l'évolution du débit instantané théoriqueBTh . La différence entre le débit moyen observé TH et le débit instantané théorique étant ici constante, la dérivée dD est nulle et, par conséquent, le client ne modifie pas son niveau d'abonnements. Le calcul d'un débit instantané théorique permet d'obtenir une valeur proche du débit moyen théorique réel. Cependant, une autre solution consiste à s'assurer que le débit moyen théorique transmis dans les messages SEI de scalabilité est représentatif du débit de transmission, c'est-à-dire, en d'autres termes, que le débit de transmission ne varie que faiblement par rapport au débit moyen théorique. Pour assurer cette caractéristique, une solution consiste à impliquer le serveur tout en maintenant ses capacités de scalabilité. L'idée consiste ici à transmettre de nouveaux messages SEI dès qu'une variation du débit de transmission est trop importante par rapport au débit moyen théorique. Cette solution permet, pour le client, d'éviter le calcul du débit instantané théorique BTh , le débit moyen théorique étant suffisant. Ce procédé peut être mis en oeuvre hors ligne, durant l'analyse ou le codage de la séquence vidéo, ou en ligne, durant la transmission de la séquence vidéo. La figure 6 illustre un exemple d'algorithme pouvant être mis en oeuvre par un serveur pour évaluer des variations importantes du débit de transmission par rapport au débit moyen théorique et générer des messages SEI correspondants. Cet algorithme est ici du type hors ligne. Durant une phase d'initialisation, le serveur calcul un débit moyen théorique pour chaque couche de scalabilité, pour toute la séquence. A ces fins, une première étape consiste à initialiser les variables i et k à la valeur zéro (étape 601). Un test est ensuite effectué pour déterminer si toutes les couches de scalabilité spatiale ont été traitées (étape 603), c'est-à-dire si la valeur de l'index i est inférieure ou égale à celle de la variable Max représentant le nombre de couches de scalabilité spatiale, à l'exception de celle correspondant au flux de base. Si toutes les couches de scalabilité spatiale n'ont pas été traitées, les variables Ci et C° sont initialisées à zéro (étape 605) et l'index i est incrémenté de un (étape 607), ces deux étapes étant répétées jusqu'à ce que toutes les couches de scalabilité spatiale soient traitées. La variable Ci représente ici le débit moyen théorique pour la couche ayant l'index i, pour toute la séquence, tandis que la variable C° représente le débit moyen théorique pour la couche ayant l'index i, pour une fenêtre glissante d'une longueur A. Lorsque toutes les couches de scalabilité spatiale ont été traitées, un test est effectué pour déterminer si toutes les NAL qui contiennent la séquence vidéo ont été traitées (étape 609), c'est-à-dire si la valeur de la variable k est inférieure à celle de la variable N qui représente le nombre de NAL de la séquence. Si toutes les NAL n'ont pas été traitées, la NAL ayant l'index k est analysée (étape 611). Cette étape consiste notamment à extraire l'en-tête de la NAL pour identifier le paramètre Did qui détermine la couche de scalabilité spatiale à laquelle appartient la NAL. La valeur de l'index i est alors modifiée (étape 613) pour être égale à l'index de la couche de scalabilité spatiale à laquelle appartient la NAL (i = Did). La taille de la NAL traitée est alors ajoutée à la variable Ci (étape 615), la valeur de l'index k est incrémentée de un (étape 617) et les étapes précédentes (étapes 609 à 617) sont répétées jusqu'à ce que toutes les NAL soient traitées. Lorsque toutes les NAL ont été traitées, la valeur de la variable Ci est divisée par la durée de la séquence. Cette variable représente alors le débit moyen théorique pour la séquence. La valeur de l'index k est ensuite initialisée à zéro (étape 619) et un test est effectué pour déterminer si toutes les NAL ont été traitées (étape 621), c'est-à-dire pour déterminer si la valeur de l'index k est inférieure à celle de N. La NAL ayant l'index k est ensuite analysée (étape 623). Comme l'étape 611, cette étape consiste notamment à extraire l'en-tête de la NAL pour identifier le paramètre Did qui détermine la couche de scalabilité spatiale à laquelle appartient la NAL. La valeur de l'index i est alors modifiée (étape 625) pour être égale à l'index de la couche de scalabilité spatiale à laquelle appartient la NAL (i = Did).

La valeur de la variable C° pour la couche ayant l'index i est alors calculée en fonction d'une fenêtre glissante correspondant à la période A se terminant sur la NAL ayant l'index k (étape 627) selon la relation suivante, si NAL je A A où SNAL est la taille de la j-ième NAL de la fenêtre glissante correspondant à la période A se terminant sur la NAL ayant l'index k. Un test est ensuite effectué pour déterminer si la valeur de la variable C° appartient à l'intervalle [Ci û R; Cz + 13] où R représente une différence autorisée par rapport au débit moyen théorique pour la couche ayant l'index i (étape 629). R peut notamment exprimer un pourcentage de la variable CZ , par exemple 5%. Si la valeur de la variable C° appartient à l'intervalle [Ci û ; C Z + R ], la valeur de l'index k est incrémentée de un (étape 631) et les étapes précédentes sont répétées (à partir de l'étape 621) jusqu'à ce que toutes les NAL soient traitées.

Si la valeur de la variable C° n'appartient pas à l'intervalle [Ci û R; Cz +13], il est considéré que le débit moyen théorique pour la couche ayant l'index i, pour une fenêtre glissante d'une période A, C°, est trop différent du débit moyen théorique pour la couche ayant l'index i, pour toute la séquence, Ci . Par conséquent, la variable Ci prend la valeur de la variable C° (étape 633) et un nouveau message SEI de scalabilité est généré dans le flux, avant la première NAL de la fenêtre glissante correspondant à la période A et se terminant sur le NAL ayant l'index k (étape 635). Dans ce message SEI, le paramètre Avg bitrate[i] prend comme valeur celle de la variable Ci . La valeur de l'index k est ensuite incrémentée de un (étape 631) et les étapes précédentes sont répétées (à partir de l'étape 621) jusqu'à ce que toutes les NAL soient traitées. Si plusieurs changements de débit moyen théorique pour la couche ayant l'index i, pour une fenêtre glissante d'une période A, interviennent pour plusieurs couches d'une même fenêtre glissante, un seul message SEI de scalabilité est généré. II convient de noter qu'au début du processus, les étapes 629 à 631 ne sont effectuées que lorsque le nombre de NAL traitées atteint le nombre de NAL compris dans la fenêtre glissante de longueur A.

Une représentation des résultats produits par l'algorithme illustré sur la figure 6 est donnée sur la figure 7. Sur cette représentation, le paramètre Max bitrate layer[i] est réévalué pour chaque période A. Comme pour les figures 4 et 5, l'axe des abscisses représente ici le temps tandis que l'axe des ordonnées représente le débit. Les références 700 et 705 visent ici le débit moyen associé à la couche ayant l'index i, c'est-à-dire Avg bitrate[i], et le débit maximal associé à la couche ayant l'index i, c'est-à-dire Max bitrate layer[i], respectivement. La référence 710 désigne le débit réel de transmission. Comme illustré, les valeurs du débit moyen associé à la couche ayant l'index i, Avg bitrate[i], et du débit maximal associé à la couche ayant l'index i, Max bitrate layer[i], sont adaptées en fonction du débit réel de transmission. Ainsi, il n'est pas nécessaire, pour le client, de calculer le débit instantané théoriqueBTh . La référence 715 indique les instants auxquels sont transmis les messages SEI de scalabilité permettant au client d'adapter ses abonnements en fonction de la bande passante disponible. Alors que, selon le mode de réalisation décrit en référence à la figure 3, le débit instantané théorique est systématiquement calculé pour chaque fenêtre glissante de longueur A, il est possible d'éviter ce calcul systématique en utilisant le paramètre Max bitrate layer[i], disponible dans les messages SEI de scalabilité. En effet, si le débit moyen théorique et le débit maximal sont assez proches l'un de l'autre, les variations du débit instantané théorique sont faibles. Dans ce cas, la variance des variations est faible. Ainsi, comme illustré sur la figure 8, lorsque la différence entre le débit moyen théorique BTh et la somme des valeurs du paramètre Max bitrate layer[i] pour chaque couche reçue par le client est faible, c'est-à-dire inférieure à un seuil prédéterminé, il n'est pas nécessaire de calculer le débit instantané théoriqueBTh . Comme pour les figures 4, 5 et 7, l'axe des abscisses représente ici le temps tandis que l'axe des ordonnées représente le débit. Les références 800 et 805 visent le débit moyen associé à la couche ayant l'index i, c'est-à-dire Avg bitrate[i], et le débit maximal associé à la couche ayant l'index i, c'est-à-dire Max bitrate layer[i], respectivement. La référence 810 désigne le débit réel de transmission. Comme illustré, il n'est pas nécessaire de calculer le débit instantané théoriqueBTh car les variations théoriques sont limitées.

Selon le premier mode de réalisation décrit en référence à la figure 2, le client détecte une augmentation de la bande passante lorsque la dérivée de la différence entre le débit moyen observé et le débit moyen théorique est positive, c'est-à-dire lorsque le débit moyen observé augmente par rapport au débit moyen théorique. En réalité, il y a peu de chance que le débit moyen observé augmente par rapport au débit moyen théorique lorsque le serveur transmet le flux de données avec un débit de transmission lié à la fréquence temporelle de la séquence vidéo transmise. Pour améliorer la détection de l'augmentation de la bande passante selon ce mode de réalisation, une solution consiste à impliquer le serveur et à détecter, dans le client, un état stable sur une période de temps dont la longueur est supérieure à la période A utilisée. Un état stable est ici identifié en analysant plusieurs valeurs successives de la dérivée. Si ces valeurs sont égales à zéro, ou proches de zéro, le client considère qu'il se trouve dans un état stable. Cette situation intervient notamment lorsque le niveau d'abonnements du client utilise toute ou une partie de la bande passante disponible. Dans ce cas, le client peut envoyer un message au serveur pour indiquer qu'il est dans un état stable. En réponse, le serveur augmente progressivement le débit de transmission en transmettant les données selon un débit supérieur à la fréquence temporelle de la séquence transmise. Si cette augmentation n'entraîne pas de congestion, le client peut s'abonner à un nouveau groupe multipoints associé à une couche de scalabilité supérieure. Lorsque le client souscrit à un tel abonnement, il transmet un autre message au serveur pour le lui indiquer. En réponse, le serveur réadapte le débit de transmission compatible avec la fréquence temporelle de la séquence transmise. Si, au contraire, cette augmentation entraîne un début de congestion, le client transmet un message au serveur pour l'indiquer. En réponse, le serveur réadapte le débit de transmission selon la fréquence temporelle de la séquence transmise.

Pour éviter d'impliquer le serveur, le client peut, lorsqu'il identifie un état stable, analyser le comportement du débit moyen observé au cours du temps passé. Si le client a, dans le passé, c'est-à-dire sur au moins un intervalle de temps passé, estimé un débit moyen observé supérieur au débit moyen théorique, sans identifier de début de congestion, c'est-à-dire que le débit instantané théorique était consistant avec le débit moyen observé, il peut en déduire qu'il existe une forte probabilité pour qu'une partie de la bande passante soit disponible, donc que le réseau de communication soit en état de sous-utilisation. Dans ce cas, le client peut décider de souscrire un abonnement à de nouveaux groupes multipoints pour accéder à une couche supérieure de scalabilité. La figure 9 illustre une telle situation.

Comme pour les figures 4, 5, 7 et 8, l'axe des abscisses représente ici le temps tandis que l'axe des ordonnées représente le débit. Les références 900 et 905 visent le débit moyen associé à la couche ayant l'index i, c'est-à-dire Avg bitrate[i], et le débit maximal associé à la couche ayant l'index i, c'est-à-dire Max bitrate layer[i], respectivement.

Les références 910 et 915 désignent le débit moyen observé et le débit moyen théorique, respectivement. Comme illustré, la différence est sensiblement constante et, par conséquent, la dérivée de la différence est sensiblement égale à zéro. Ainsi, entre les instants t9 et t2, l'état est stable. De plus, il est observé au cours de cette période que le débit moyen observé peut être augmenté. Le client peut donc, à l'instant t2, souscrite un abonnement à de nouveaux groupes multipoints pour accéder à une couche supérieure de scalabilité. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (25)

1. REVENDICATIONS1. Procédé pour ordinateur d'estimation d'un niveau d'utilisation d'un réseau de communication (3) reliant un serveur (1) et au moins un client (2), ledit réseau de communication étant utilisé pour transmettre un flux de données à un débit de transmission correspondant à la fréquence temporelle dudit flux de données, ledit flux de données comprenant au moins une information caractérisant un débit théorique dépendant dudit débit de transmission dudit flux de données, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes mises en oeuvre par ledit au moins un client : - obtention (121) dudit débit théorique dudit flux de données ; - évaluation (109) du débit réel de réception d'au moins une partie dudit flux de données ; - comparaison (113) dudit débit théorique et dudit débit évalué ; - en réponse à ladite comparaison, estimation dudit niveau d'utilisation dudit réseau de communication.
2. 2. Procédé selon la revendication précédente selon lequel ladite étape de comparaison dudit débit théorique et dudit débit évalué comprend une étape d'analyse de l'évolution de la différence entre ledit débit théorique et ledit débit évalué, ladite évolution de la différence entre ledit débit théorique et ledit débit évalué caractérisant un niveau d'utilisation adapté dudit réseau de communication, une sous utilisation dudit réseau de communication ou une congestion dudit réseau de communication.
3. 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel ledit flux de données est un flux de données scalables et selon lequel ledit débit théorique est déterminé selon un débit théorique associé à chaque couche de scalabilité dudit flux de données.
4. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de correction (122b) de ladite au moins une information caractérisant ledit débit théorique dudit flux de données.
5. 5. Procédé selon la revendication précédente selon lequel ladite étape de correction comprend une étape d'estimation (104b), pour une période de temps prédéterminée, d'un débit instantané théorique, ledit débit instantané théorique étant dépendant du contenu dudit flux de données reçu pendant ladite période de temps.
6. 6. Procédé selon la revendication 4 selon lequel ladite étape de correction n'est effectuée que si la variance de l'évolution dudit débit théorique est supérieure à un seuil prédéterminé.
7. 7. Procédé selon l'une quelconque des revendications 3 à 6, dépendantes de la revendication 2, comprenant en outre une étape de détermination d'un état dudit au moins un client, ledit état dudit au moins un client étant déterminé selon la variation de la différence entre ledit débit théorique et ledit débit évalué et selon la variation du nombre desdites couches de scalabilité dudit flux de données reçu par ledit au moins un client, le procédé comprenant en outre une étape de transmission d'une indication dudit état dudit au moins un client audit serveur si ledit état dudit au moins un client est stable pour indiquer audit serveur d'augmenter ledit débit de transmission dudit flux de données.
8. 8. Procédé selon la revendication précédente selon lequel ledit débit de transmission dudit flux de données est supérieur au débit de transmission correspondant à la fréquence temporelle dudit flux de données.
9. 9. Procédé selon la revendication précédente comprenant en outre une étape d'analyse de l'évolution dudit débit évalué et une étape de détermination de sous utilisation dudit réseau de communication, ladite détermination étant basée sur l'analyse dudit état dudit au moins un client et sur ladite analyse de ladite évolution dudit débit évalué.
10. 10. Procédé selon l'une quelconque des revendications 3 à 6, dépendantes de la revendication 2, comprenant en outre une étape de détermination d'un état dudit au moins un client, ledit état dudit au moins un client étant déterminé selon la variation de la différence entre ledit débit théorique et ledit débit évalué et selon la variation du nombre desdites couches de scalabilité dudit flux de données reçu par ledit au moins un client, le procédécomprenant en outre, si ledit état dudit au moins un client est stable, les étapes suivantes : - comparaison dudit débit théorique avec au moins un débit de réception d'au moins une partie dudit flux de données évalué sur au moins un intervalle de temps passé ; et, - détermination d'une sous utilisation dudit réseau de communication si ledit au moins un débit de réception d'au moins une partie dudit flux de données évalué sur au moins un intervalle de temps passé est supérieur audit débit théorique.
11. 11. Procédé pour ordinateur d'adaptation d'un niveau d'abonnements à des groupes multipoints pour recevoir des données scalables dans un système comprenant un serveur et au moins un client, ledit serveur et ledit au moins un client étant reliés par un réseau de communication, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes : - estimation du niveau d'utilisation dudit réseau de communication selon l'une quelconque des revendications précédentes ; et, - en réponse à ladite étape d'estimation dudit niveau d'utilisation dudit réseau de communication, modification (137, 139) du débit de réception dudit flux de données en adaptant ledit niveau d'abonnements auxdits groupes multipoints.
12. 12. Procédé selon la revendication précédente selon lequel si ledit réseau de communication est sous utilisé ledit client souscrit à un abonnement pour recevoir une couche de scalabilité supérieur et si ledit réseau de communication est congestionné ledit client abandonne un abonnement à une couche de scalabilité reçue.
13. 13. Procédé pour ordinateur de traitement d'un flux de données scalables, ledit flux de données scalables comprenant au moins un message comprenant au moins une information caractérisant un débit théorique dudit flux de données, le procédé étant mis en oeuvre dans un serveur et étant caractérisé en ce qu'il comprend les étapes suivantes :- estimation (627) d'un débit instantané théorique selon la quantité de données dudit flux de données à transmettre durant une période de longueur prédéterminée ; - comparaison (629) du débit théorique avec ledit débit instantané théorique ; et, - en réponse à ladite comparaison, création (635) d'un message comprenant ledit débit instantané théorique si la différence entre ledit débit théorique et ledit débit instantané théorique est supérieure à un seuil prédéterminé.
14. 14. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit flux de données est un flux vidéo, ledit débit théorique étant déterminé pour la fréquence temporelle de la séquence vidéo représentée par ledit flux vidéo.
15. 15. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
16. 16. Moyens de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 14.
17. 17. Dispositif d'estimation d'un niveau d'utilisation d'un réseau de communication (3) reliant un serveur (1) et au moins un client (2), ledit réseau de communication étant utilisé pour transmettre un flux de données à un débit de transmission correspondant à la fréquence temporelle dudit flux de données, ledit flux de données comprenant au moins une information caractérisant un débit théorique dépendant dudit débit de transmission dudit flux de données, ce dispositif étant mis en oeuvre dans ledit au moins un client et étant caractérisé en ce qu'il comprend les moyens suivants : - moyens pour obtenir ledit débit théorique dudit flux de données ;- moyens pour évaluer le débit réel de réception d'au moins une partie dudit flux de données ; - moyens pour comparer ledit débit théorique et ledit débit évalué ; - moyens pour estimer ledit niveau d'utilisation dudit réseau de communication selon ledit débit théorique et ledit débit évalué.
18. 18. Dispositif selon la revendication précédente selon lequel lesdits moyens pour comparer ledit débit théorique et ledit débit évalué comprennent des moyens pour analyser l'évolution de la différence entre ledit débit théorique et ledit débit évalué, ladite évolution de la différence entre ledit débit théorique et ledit débit évalué caractérisant un niveau d'utilisation adapté dudit réseau de communication, une sous utilisation dudit réseau de communication ou une congestion dudit réseau de communication.
19. 19. Dispositif selon la revendication 17 ou la revendication 18 comprenant en outre des moyens pour corriger ladite au moins une information caractérisant ledit débit théorique dudit flux de données.
20. 20. Dispositif selon la revendication précédente selon lequel lesdits moyens pour corriger ladite au moins une information caractérisant ledit débit théorique dudit flux de données comprennent des moyens pour estimer, pour une période de temps prédéterminée, un débit instantané théorique, ledit débit instantané théorique étant dépendant du contenu dudit flux de données reçu pendant ladite période de temps.
21. 21. Dispositif selon la revendication 19 ou la revendication 20, dépendantes de la revendication 18, comprenant en outre des moyens pour déterminer un état dudit au moins un client, ledit état dudit au moins un client étant déterminé selon la variation de la différence entre ledit débit théorique et ledit débit évalué et selon la variation du nombre desdites couches de scalabilité dudit flux de données reçu par ledit au moins un client, le dispositif comprenant en outre des moyens pour transmettre une indication dudit état dudit au moins un client audit serveur si ledit état dudit au moins un client est stable pour indiquer audit serveur d'augmenter ledit débit de transmission dudit flux de données.
22. 22. Dispositif selon la revendication précédente comprenant en outre des moyens pour analyser l'évolution dudit débit évalué et des moyens pour déterminer une sous utilisation dudit réseau de communication selon l'analyse dudit état dudit au moins un client et l'analyse de ladite évolution dudit débit évalué.
23. 23. Dispositif selon la revendication 19 ou la revendication 20, dépendantes de la revendication 18, comprenant en outre des moyens pour déterminer un état dudit au moins un client, ledit état dudit au moins un client étant déterminé selon la variation de la différence entre ledit débit théorique et ledit débit évalué et selon la variation du nombre desdites couches de scalabilité dudit flux de données reçu par ledit au moins un client, le dispositif comprenant en outre, si ledit état dudit au moins un client est stable, les moyens suivants : - moyens pour comparer ledit débit théorique avec au moins un débit de réception d'au moins une partie dudit flux de données évalué sur au moins un intervalle de temps passé ; et, - moyens pour déterminer une sous utilisation dudit réseau de communication si ledit au moins un débit de réception d'au moins une partie dudit flux de données évalué sur au moins un intervalle de temps passé est supérieur audit débit théorique.
24. 24. Dispositif d'adaptation d'un niveau d'abonnements à des groupes multipoints pour recevoir des données scalables dans un système comprenant un serveur et au moins un client, ledit serveur et ledit au moins un client étant reliés par un réseau de communication, ce dispositif étant caractérisé en ce qu'il comprend les moyens suivants : - moyens pour estimer un niveau d'utilisation dudit réseau de communication selon l'une quelconque des revendications 17 à 23 ; et, - moyens pour modifier le débit de réception dudit flux de données en adaptant ledit niveau d'abonnements auxdits groupes multipoints selon ledit niveau d'utilisation dudit réseau de communication.
25. 25. Dispositif de traitement d'un flux de données scalables, ledit flux de données scalables comprenant au moins un message comprenant au moinsune information caractérisant un débit théorique dudit flux de données, ce dispositif étant mis en oeuvre dans un serveur et étant caractérisé en ce qu'il comprend les moyens suivants : - moyens pour estimer un débit instantané théorique selon la 5 quantité de données dudit flux de données à transmettre durant une période de longueur prédéterminée ; - moyens pour comparer ledit débit théorique avec ledit débit instantané théorique ; et, - moyens pour créer un message comprenant ledit débit instantané 10 théorique si la différence entre ledit débit théorique et ledit débit instantané théorique est supérieure à un seuil prédéterminé.