FR 2960320 A1 20111125 FR 1053947 A 20100521 Procédé de gestion d'une transmission de données depuis un dispositif émetteur, produit programme d'ordinateur, moyen de stockage et dispositif émetteur correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui de la transmission de données entre un dispositif émetteur et un dispositif récepteur. L'invention s'applique notamment, mais non exclusivement, à la transmission de données, dans un système de distribution vidéo, entre une application source (qui génère par exemple un contenu vidéo issu d'un lecteur DVD), placée en amont du dispositif émetteur, et au moins une application réceptrice (par exemple un téléviseur), placée en aval du dispositif récepteur. Le domaine de l'invention se situe en outre au niveau de la gestion du codage source (encodage) mis en oeuvre par un encodeur compris dans le dispositif émetteur situé en amont d'un canal de transmission, par exemple de type synchrone et à bande passante constante (c'est-à-dire à débit constant). 2. ARRIÈRE-PLAN TECHNOLOGIQUE Dans un système de distribution vidéo entre une application source et au moins une application réceptrice, les données applicatives à transmettre sont préalablement stockées dans une mémoire tampon du dispositif émetteur avant de procéder au transport de ces données via le canal de transmission mis en oeuvre dans le système. Cette mémoire tampon est destinée à absorber la différence de rythme entre une horloge applicative définissant le cadencement de production de données applicatives et une horloge réseau définissant le cadencement de transmission des données applicatives via le canal de transmission. Cependant, cette différence de rythme n'est pas entièrement absorbée par la mémoire tampon et il subsiste un écart entre le rythme de production des données par la couche applicative et le rythme de transport de ces données par la couche transport. Un tel écart peut entraîner une modification de la latence de bout en bout du système. Pour des systèmes de distribution temps réel à faible latence, supportant par exemple des applications vidéo interactives, le canal de transmission privilégié est de type synchrone et à bande passante constante (« Constant Bit Rate » en anglais), ce qui permet de garantir un temps de transmission constant. Cependant, au regard de cette propriété de bande passante constante, il est nécessaire d'adapter, dans le dispositif émetteur, la quantité de données à transmettre à la capacité du canal de transmission. Les données (par exemple de type vidéo) brutes issues de l'application sont alors compressées par le dispositif émetteur avant transmission. Les systèmes de transmission radio à 60 GHz (bande d'ondes RF millimétriques) sont particulièrement bien adaptés pour la transmission de données à très haut débit sur courtes distances. Cependant, le caractère aléatoire du canal de transmission peut amener la couche réseau à modifier la bande passante allouée à une application, afin d'adapter son schéma de retransmission, ou son schéma de correction d'erreur, aux nouvelles conditions de transmission. Dans de tels cas, l'application doit également adapter son volume de données à la nouvelle capacité du canal de transmission qui lui est dédiée et ainsi modifier les paramètres de son codage source. Un des principaux problèmes liés à la modification du codage source (c'est-à-dire des paramètres d'encodage utilisés par l'encodeur pour encoder les blocs de données applicatives) suite à une réallocation de la bande passante, est de maintenir une qualité de service constante, c'est-à-dire éviter toute interruption de l'application vis-à- vis de l'utilisateur. Pour éviter ce genre de désagrément, le système doit pouvoir maintenir une latence de bout en bout constante malgré les changements conjugués de bande passante et de codage source. Ainsi, lorsque la bande passante diminue, respectivement augmente, le taux de compression du codage source doit être plus élevé, respectivement plus faible. De plus, dans un système à faible latence de transmission, c'est-à-dire où les ressources mémoire sont faibles, il existe peu de marge de manoeuvre pour compenser des modifications de la latence de bout en bout, même transitoires, celles-ci entraînant des débordements de mémoire tampon du dispositif émetteur et/ou du dispositif récepteur. Dans l'état de la technique, il existe plusieurs techniques de modification de codage source tenant compte des paramètres du réseau. Selon une approche connue, présentée dans le document de brevet GB 2306073, les paramètres de quantification ainsi que les besoins en débit sont calculés en fonction des paramètres de « leaky bucket » (« sceau percé » en français) et du taux de remplissage des différentes mémoires tampons (appelées « buffers » en anglais), ceci afin d'éviter les phénomènes de congestion. Un inconvénient de cette approche connue réside dans l'aspect non prédictible du basculement effectif au niveau du transport entre des données applicatives ayant subies un premier codage source et des données applicatives ayant subies un second codage source. Ainsi, dans le contexte précité d'un changement conjugué de bande passante et de codage source, en utilisant l'approche connue précitée, le codage source peut ne pas être cohérent avec la bande passante allouée durant plusieurs périodes de transport, ce qui peut entraîner une modification de la latence de bout en bout ou une mauvaise utilisation de la bande passante allouée à l'application. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, il est souhaitable de fournir une technique de transmission de données entre un dispositif émetteur et un dispositif récepteur, permettant de maintenir une latence de bout en bout constante dans le cadre d'un changement conjugué de bande passante et de codage source, quels que soient les rythmes de l'horloge applicative et de l'horloge réseau. Il est aussi souhaitable de maximiser l'utilisation de la bande passante lors d'un changement conjugué de bande passante et de codage source pour garantir le meilleur rendu (visuel) possible au regard de la bande passante disponible. Il est aussi souhaitable de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion d'une transmission d'un flux de données depuis un dispositif émetteur, le dispositif émetteur recevant des blocs de données applicatives à transmettre à un dispositif récepteur selon un cadencement défini par des périodes de transport, les blocs de données applicatives étant encodés avant transmission par application d'un premier codage source jusqu'à traitement d'une requête de changement. Le dispositif émetteur est tel qu'il effectue des étapes consistant à : - déterminer une dérive entre un nombre de blocs de données applicatives reçus par le dispositif émetteur et un nombre de blocs de données applicatives transmis après encodage par le dispositif émetteur ; - déterminer, en prenant en compte la dérive déterminée, un bloc de données applicatives de transition à partir duquel un second codage source est appliqué en réponse à ladite requête de changement ; - adapter la transmission dudit flux de telle sorte que la transmission du bloc de données de transition encodé soit alignée sur un début de période de transport. Ainsi, la dérive entre le rythme de production des données applicatives et le rythme de transport des données applicatives encodées est prise en compte dans la détermination du bloc de données (bloc de données de transition) sur lequel le changement de codage source doit s'opérer, et s'assurer que ce bloc de données déterminé sera transmis au début d'une période de transport. Ceci permet de maintenir une latence de bout en bout constante et un alignement adapté du bloc de données de transition sur un début de période de transport, permettant ainsi une gestion de retransmission aisée et une coopération inter-couches protocolaires basée sur un événement commun qui est ce début de période de transport. De façon avantageuse, l'étape consistant à déterminer une dérive comprend des étapes consistant à : - identifier le dernier bloc de données encodé qui a été transmis pendant la période de transport qui précède le traitement de ladite requête de changement ; - déterminer la quantité de données transmises dudit dernier bloc de données encodé identifié; Avantageusement, le bloc de données applicatives de transition est déterminé en prenant également en compte la quantité de données transmises déterminée. Ainsi, on détermine, de manière simple, la dérive cumulée au fil des périodes de transport à partir d'une quantité de données transmises du dernier bloc de données 30 encodé qui a été transmis pendant la période de transport qui précède le traitement de ladite requête de changement. Selon une caractéristique avantageuse, le dispositif émetteur effectue une étape consistant à : - choisir un décalage temporel à appliquer entre l'instant de début de réception desdits blocs de données applicatives et l'instant de début de transmission desdits blocs de données encodés, en fonction d'une période de temps nécessaire à l'exécution des étapes consistant à déterminer ladite dérive et à déterminer ledit bloc de données applicatives de transition. En choisissant un décalage temporel (aussi appelé par la suite latence initiale globale) entre l'instant de début de réception des données et l'instant de début de transmission des données, il est possible de choisir le bloc de données de transition qui va permettre d'utiliser le maximum de bande passante allouée ; c'est-à-dire que l'étape consistant à adapter la transmission de telle sorte que la transmission du bloc de données de transition encodé soit alignée sur un début de période de transport améliore la consommation de bande passante (minimisation d'une période de temps pendant laquelle la bande passante est surdimensionnée par rapport au codage source appliqué). Un choix judicieux de la valeur du décalage temporel permet de rendre le système plus réactif, c'est-à-dire qu'il est possible de minimiser la durée entre l'instant de traitement de la requête de changement et l'instant auquel ce changement est effectif. De façon avantageuse, le dispositif émetteur effectue des étapes consistant à : - déterminer un nombre de bloc(s) de données applicatives représentant un cumul de variation de taille de blocs de données encodés à transmettre par rapport à une valeur de taille cible ; - déterminer ledit bloc de données applicatives de transition, en prenant également en compte le nombre de bloc(s) de données applicatives déterminé. Ainsi, on ajuste le bloc de données de transition en fonction de la bande passante réellement utilisée. De cette façon, il est possible de diminuer la contrainte de compression sur certains blocs de données (par exemple, des blocs de données correspondant à des zones d'une image à fortes complexités) et de resserrer cette contrainte sur d'autres blocs de données (par exemple, des blocs de données correspondant à des zones d'une image à faibles complexités). Selon une caractéristique avantageuse, l'étape consistant à adapter la transmission dudit flux comprend une étape consistant à ajouter, en complément du bloc de données encodé qui est transmis juste avant le bloc de données de transition encodé, des données de bourrage jusqu'à ce que le bloc de données de transition encodé soit aligné sur un début de période de transport. Ajouter des données de bourrage permet, dans un système synchrone sans utilisation d'étiquetage temporel (« timestamping » en anglais), d'une part d'aligner le bloc de données de transition encodé sur un début de période de transition, et d'autre part de corriger la dérive entre le nombre de blocs de donnée produits par l'application et le nombre de blocs de donnée transmis. De façon avantageuse, la taille des blocs de données applicatives est choisie en fonction de la précision d'une horloge en charge de définir ledit cadencement. Ainsi, le fait d'avoir une période de bloc de données (par exemple un macrobloc) adaptée à la précision de l'horloge, qui définit le cadencement du transport des données encodées et qui sert de référence commune à chaque dispositif du système, permet d'éviter de détériorer la précision globale du système. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). Dans un mode de réalisation particulier de l'invention, il est proposé un dispositif émetteur comprenant des moyens pour gérer une transmission d'un flux de données, le dispositif émetteur recevant des blocs de données applicatives à transmettre à un dispositif récepteur selon un cadencement défini par des périodes de transport, les blocs de données applicatives étant encodés avant transmission par application d'un premier codage source jusqu'à traitement d'une requête de changement. Le dispositif émetteur est tel qu'il comprend les moyens suivants : - des moyens pour déterminer une dérive entre un nombre de blocs de données applicatives reçus par le dispositif émetteur et un nombre de blocs de données applicatives transmis après encodage par le dispositif émetteur ; - des moyens pour déterminer, en prenant en compte la dérive déterminée, un bloc de données applicatives de transition à partir duquel un second codage source est appliqué en réponse à ladite requête de changement ; - des moyens pour adapter la transmission dudit flux de telle sorte que la transmission du bloc de données de transition encodé soit alignée sur un début de période de transport. Avantageusement, le dispositif émetteur comprend des moyens de mise en oeuvre des étapes du procédé tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 décrit l'architecture d'un système de distribution vidéo temps réel, selon un mode de réalisation particulier de l'invention ; - la figure 2 présente un exemple de noeud émetteur, qui implémente des mécanismes selon un mode de réalisation particulier de l'invention ; - la figure 3 présente un exemple de noeud récepteur, qui implémente des mécanismes selon un mode de réalisation particulier de l'invention ; - la figure 4 présente un mode de réalisation particulier d'un algorithme de comptage, tel qu'implémenté au sein d'un module de traitement (compris dans le noeud émetteur de la figure 2) ; - la figure 5 présente un mode de réalisation particulier d'un algorithme de paquétisation des données, tel qu'implémenté au sein d'un module de gestion de transmission (compris dans le noeud émetteur de la figure 2) ; - la figure 6 représente un mode de réalisation particulier de l'étape 522 de la figure 5 (algorithme de paquétisation des données) ; - la figure 7 représente un mode de réalisation particulier de l'étape 511 de la figure 5 (algorithme de paquétisation des données) ; - la figure 8 présente un mode de réalisation particulier d'un algorithme de calcul de macro-bloc de transition, tel qu'implémenté au sein d'un module de gestion de changement de codage source (compris dans le noeud émetteur de la figure 2) ; - la figure 9 présente un mode de réalisation particulier d'un algorithme d'application de codage source (encodage) selon un rendement donné, tel qu'implémenté au sein du module de traitement (compris dans le noeud émetteur de la figure 2) ; - la figure 10 présente un mode de réalisation particulier d'un algorithme de traitement de délimiteurs de bloc de données et de délimiteurs de changement de codage source, tel qu'implémenté au sein d'un module de gestion de réception (compris dans le noeud récepteur de la figure 3) ; - la figure 11 illustre un exemple d'une table de stockage comprise dans le noeud émetteur de la figure 2 ; - la figure 12 illustre schématiquement le principe d'un mode de réalisation particulier de l'invention, à travers un exemple de correction d'une dérive entre un rythme de production de données et un rythme de transport de ces données ; et - la figure 13 illustre schématiquement le principe d'un mode de réalisation particulier de l'invention, à travers un exemple de correction d'une dérive entre un rythme de production de données et un rythme de transport de ces données, dans le cas d'un changement de codage source. 6. DESCRIPTION DÉTAILLÉE La figure 1 décrit l'architecture d'un système de distribution vidéo temps réel, selon un mode de réalisation particulier de l'invention. Ce système de distribution 30 permet d'afficher, au niveau d'un écran, le contenu d'une source vidéo. 15 20 25 Une telle architecture est donnée à titre purement illustratif et la présente invention peut être mise en oeuvre dans d'autres systèmes de transmission de données, et quelque soit le type de ces données transportées, l'invention ne se limitant pas à la distribution temps-réel de données vidéo. Plus particulièrement, le système de distribution vidéo temps réel comprend : - un canal de transmission synchrone 105 de type TDM (pour « Time Division Multiplexing » en anglais, et « multiplexage temporel » en français) ; - un noeud émetteur 102, aussi appelé par la suite dispositif émetteur (« transmitting device » en anglais) comprenant une première extrémité connectée au canal 105 et une seconde extrémité connectée à une source vidéo 101 (par exemple un lecteur DVD) générant des données applicatives audiovisuelles brutes ; - un noeud récepteur 103, aussi appelé par la suite dispositif récepteur, (« receiving device » en anglais) comprenant une première extrémité connectée au canal 105 et une seconde extrémité connectée à un dispositif d'affichage vidéo (ou écran) 104. Le noeud émetteur 102 reçoit, au rythme d'une horloge applicative, les données applicatives venant de la source vidéo 101, puis traite les données applicatives reçues, avant transmission sur le canal 105, au rythme d'une horloge réseau. L'horloge applicative et l'horloge réseau sont décorrélées l'une de l'autre. Il est donc nécessaire de veiller à ce que le noeud émetteur 102 transmet via le canal 105 autant de données applicatives qu'il en reçoit de la source vidéo 101, et ce de manière à permettre une transmission synchronisée des données jusqu'à un dispositif récepteur, tout en conservant une faible latence de bout en bout. La figure 2 présente un exemple de noeud émetteur, qui implémente des mécanismes selon un mode de réalisation particulier de l'invention. Le noeud émetteur 102 est connecté en entrée à une application génératrice de données (par exemple de type vidéo) brutes (blocs de données applicatives), au travers de l'interface Video_in 201, et en sortie au canal de transmission 105, au travers de l'interface D_out 244. Le noeud émetteur 102 a pour objectif d'adapter la quantité de données produites par l'application à la bande passante allouée sur le canal de transmission pour cette application. Le noeud émetteur 102 comprend : - un module de traitement vidéo 210, aussi appelé par la suite encodeur, destiné à réduire le débit applicatif par compression, à hauteur de la capacité de débit du canal de transmission synchrone 105 ; - un module de gestion de transmission 240; - un module de gestion de changement de codage source 250. Le module de traitement 210 effectue une compression par bloc de données. Le module de traitement 210 applique donc un codage source sur les données (par exemple de type vidéo) brutes fournies par l'application, au travers de l'interface Video_in 201, en fonction d'une valeur cible de codage source CS_consigne 212 (ou valeur cible de « bitrate »), ou tout paramètre équivalent (comme par exemple un type de transformation à appliquer), provenant du module de gestion de changement de codage source 250. Le module de traitement 210 produit alors des macro-blocs compressés (blocs de données encodées) et les fournit au module de gestion de transmission 240, au travers de l'interface MB_Data_in 214. L'algorithme d'application de codage source par le module de traitement 210 est décrit ci-dessous en relation avec la figure 9. Comme décrit ci-dessous en relation avec la figure 4, le module de traitement 210 est en charge de détecter un événement réseau network_event 217 (correspondant à un événement de début de période de transport) généré par le module de gestion de transmission 240. Sur détection d'un événement réseau network_event 217, le module de traitement 210 détermine le nombre maximal de macro-blocs à transmettre pendant la période de transport courante. Pour cela, le module de traitement 210 détermine un macro-bloc, appelé macro-bloc seuil. Le nombre maximal de macro-blocs à transmettre est atteint lorsque le macro-bloc seuil est atteint. Ce macro-bloc seuil doit être transmis pendant la période de transport suivante. Le module de traitement 210 enregistre le macro-bloc seuil dans une table de stockage 220, au travers de l'interface MB seuil 221. Le module de gestion de transmission 240, dont l'algorithme de traitement est décrit ci-dessous en relation avec la figure 7, reçoit les macro-blocs compressés, au travers de l'interface MB_Data_in 214, et les stocke dans une unité de stockage 230, au travers de l'interface E_Data 231. Le module de gestion de transmission 240 utilise un signal MB taille 215 provenant du module de traitement 210 pour marquer les frontières entre les macro-blocs avant de les stocker. Le module de gestion de transmission 240 est également chargé de mettre en forme les données à transmettre sur le canal de transmission 105 au travers de l'interface D_out 244, et d'insérer un délimiteur de bloc de données dans le flux de données à transmettre, après chaque envoi d'un nombre prédéfini de macro-blocs. Ce nombre prédéfini de macro-blocs dépend de la valeur cible de codage source CS_consigne 212. Dans un mode de réalisation particulier, le délimiteur est un délimiteur de tuile. Une tuile est un groupe de macroblocs qui ne peuvent pas être décodés indépendamment les uns des autres (un macrobloc sert de prédicteur pour le macro-bloc suivant). Au niveau du dispositif récepteur, il faut attendre ce délimiteur pour commencer le décodage de toute la tuile. Le module de gestion de transmission 240 est également en charge de déterminer le nombre de paquet de transport à utiliser pour chaque période de transport. Ce nombre est déterminé en fonction du nombre de macro-blocs à transporter par période de transport et en fonction des macro-blocs seuil enregistrés dans la table de stockage 220. Le nombre de macro-blocs à transporter pendant la première période de transport est reçu du module de traitement vidéo 210, au travers du signal First_transportMB 216. La première période de transport est la période de transport qui comprend le début de transmission des blocs de données encodés. Le module de gestion de changement de codage source 250, dont l'algorithme de traitement est décrit ci-dessous en relation avec la figure 8, fournit une valeur cible de codage source CS_consigne 212 au module de traitement 210, par bloc de données ou par groupe de bloc de données. La valeur cible de codage source CS_consigne 212 n'est modifiée qu'en cas de réception d'une requête de changement Change_rq 241 provenant du module de gestion de transmission 240. Le module de gestion de transmission 240 génère la requête de changement Change_rq 241 en cas de changement de l'environnement de transmission. Par exemple, un tel changement peut se produire en cas de dégradation ou d'amélioration des conditions de transmission, en cas de déclaration de nouveaux noeuds ayant des données à transmettre, suppression de noeuds (émetteurs) du réseau, etc. Ainsi, le module de gestion de transmission 240 génère la requête Change_rq 241 à chaque modification de la répartition de la bande passante allouée à l'application. Le module de gestion de changement de codage source 250 est également en charge de déterminer le bloc de données applicatives (aussi appelé bloc de données de transition) sur lequel le changement de codage source doit s'opérer. Le module de gestion de changement de codage source 250 fournit le bloc de données de transition au module de traitement 210 et au module de gestion de transmission 240, au travers de l'interface MB_transition 213. De cette façon, le module de gestion de transmission 240 est capable de générer et d'insérer un délimiteur de changement de codage source dans le flux de données à transmettre. Les informations de bloc de données de transition (MB_transition 213) et de valeur cible de codage source (CS_consigne 212) sont transmises au module de traitement 210 en même temps qu'une requête de changement de codage source (change_CS 211). Le module de gestion de changement de codage source 250 détermine le bloc de données de transition à partir de l'index (ou numéro) du dernier macro-bloc transporté ou en cours de transport (index MB 242) et la quantité de données restante à transporter pour celui-ci (offset MB 243). La figure 3 présente un exemple de noeud récepteur, qui implémente des mécanismes selon un mode de réalisation particulier de l'invention. Le noeud récepteur 103 est connecté en sortie du canal de transmission 105, au travers de l'interface D_in 301, et à une application consommatrice de données (par exemple de type vidéo) brutes, au travers de l'interface Video_out 331. Le noeud récepteur 103 a pour objectif de décoder les données compressées reçues du canal de transmission pour fournir les données brutes à l'application consommatrice. Le noeud récepteur 103 comprend : - un module de gestion de réception 310, destiné à traiter les données compressées reçues du canal de transmission, puis à les stocker dans une unité de stockage 320, dont l'accès se fait au travers de l'interface Rx_Data 311 ; - un module de traitement vidéo 330 (décodeur). Le module de gestion de réception 310 est chargé de l'analyse du délimiteur de changement de codage source afin de fournir une valeur cible de codage source consigne_CS 312 au module de traitement 330. Le module de gestion de réception 310 fournit également au module de traitement 330 un signal start_decodage 313 lui indiquant la réception d'un délimiteur de bloc de données ou de la quantité de données correspondant à un macro-bloc encodé (en fonction du type de codage source). Sur réception du signal start_decodage 313, le module de traitement 330 démarre le décodage des données compressées. L'algorithme de traitement du module de gestion de réception 310 est décrit ci-dessous en relation avec la figure 10. Le module de traitement 330 (décodeur) est destiné à reconstituer les données compressées issues du module de gestion de réception 310. Ainsi, sur réception du signal start_decodage 313, le module de traitement 330 lit les données stockées dans l'unité de stockage 320, au travers de l'interface MB_Data_out 321. Le module de traitement 330 décode ces données en appliquant la fonction de transfert inverse (codage source-1) à celle appliquée par l'encodeur 210 du noeud émetteur 102. Pour déterminer la bonne fonction de transfert, le module de traitement 330 utilise la valeur cible de codage source consigne_CS 312 fournie par le module de gestion de réception 310. Le module de traitement 330 lit la valeur cible de codage source consigne_CS 312 à chaque réception du signal start_decodage 313, avant de commencer la lecture des données stockées dans l'unité de stockage 320. Le module de gestion de changement de codage source 250 et le module de gestion de transmission 240, compris dans le noeud émetteur 102, ainsi que le module de gestion de réception 310, compris dans le noeud récepteur 103, se réalisent chacun indifféremment : - sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou - sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC). Dans le cas d'une réalisation d'un module sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non amovible, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. On décrit ci-après en relation avec les figures 4, 5, 6 et 7, des exemples d'algorithmes pour la mise en oeuvre d'un mécanisme de correction de différence de rythme entre l'horloge applicative définissant le cadencement de production des données applicatives et l'horloge réseau définissant le cadencement de transmission des données applicatives via le canal de transmission. Une mise en oeuvre du mécanisme de correction repose sur l'utilisation de deux compteurs. Le premier compteur est en charge de compter le nombre de données produites par la couche applicative. Ce premier compteur s'incrémente au rythme de l'horloge applicative (par exemple, fournie au travers d'une interface HDMI, pour « High Definition Multimedia Interface » en anglais). Le deuxième compteur est en charge de compter le nombre de données transportées par la couche transport. Ce deuxième compteur s'incrémente au rythme d'un multiple de l'horloge réseau ou de manière synchrone à l'horloge réseau. Les valeurs des premier et deuxième compteurs évoluent avec un décalage initial (appelé ci-après latence initiale globale) égale à la somme de la latence inhérente au système, c'est-à-dire la latence due au temps de traitement préalable à la transmission, c'est-à-dire au temps de traitement pour la compression (encodage) dans l'exemple traité, des données plus le temps de transit des données dans la mémoire tampon, et d'un décalage introduit par le système afin de permettre un alignement des données lors d'un changement de codage source dynamique. Ainsi, en comparant les valeurs des deux compteurs, on obtient, pour une période de transport donnée, la différence entre le nombre de données applicatives reçues par le noeud émetteur 102 et le nombre de données applicatives encodées transmises par le noeud émetteur 102. En d'autres termes, on obtient la dérive entre le rythme de production des données par l'application et le rythme de transport de ces données par la couche transport. A titre d'exemple, dans la suite de la description, on suppose que le bloc de données servant à la comparaison est le macro-bloc de format 16 par 16 (matrice de 16 lignes par 16 pixels, soit 256 pixels). En effet, dans l'exemple de la figure 1, la précision de l'horloge réseau, c'est-à-dire la gigue (« jitter » en anglais), sur l'événement réseau ne nécessite pas une précision inférieure au macro-bloc de format 16 par 16. Dans un autre mode de réalisation, le bloc de données servant à la comparaison peut être le macro-bloc de format 8 par 8, ou le pixel, ou un ensemble de macro-blocs. La figure 4 présente un mode de réalisation particulier d'un algorithme de comptage, tel qu'implémenté au sein du module de traitement 210 (compris dans le noeud émetteur 102). Cet algorithme de comptage comprend une phase d'initialisation comprenant elle-même les étapes 400 à 406, et une phase d'utilisation en régime établi comprenant elle-même les étapes 407 à 423. On décrit ci-après les étapes 400 à 406 de la phase d'initialisation. Lors d'une étape d'initialisation 400, il est procédé à l'initialisation des variables et compteurs suivants : Cpt_pixel = 0 ; Cpt_ApplicatifMB = 0 ; Nb_pixel_per_MB = (LINE_SIZExNB_LINE)/(NB_MB_PER_PICTURE) ; Nb_AppMB_per_Period=(TransportPeriod/PicturePeriod)xNB_MB_PER_PICTURE ; Initial_value = ~h Nb_MB_per_Period ; First_transportMB = 0 ; MBseuil = 0 ; Delta = 0 ; Offset = 0. Cpt_pixel est un compteur de pixels. Il est incrémenté au rythme de l'horloge applicative. Comme on le verra par la suite (étapes 420 à 423 de la figure 4), lorsque le compteur de pixels atteint la valeur 256 (pour un macro-bloc de format 16 par 16), le compteur de macro-blocs applicatif est incrémenté d'une unité. Cpt_ApplicatifMB est un compteur de macro-blocs applicatif utilisé comme référence pour adapter le rythme de transport. La variable Nb_ pixel_per_MB est une constante liée au format de la vidéo d'entrée et au nombre NB_MB_PER_PICTURE de macro-blocs par image pour cette vidéo. Le format de la vidéo d'entrée est caractérisé par un nombre de lignes NB_LINE (par exemple 750 lignes pour un format 720p) et un nombre de pixels par ligne LINE_SIZE (par exemple 1650 pixels pour un format 720p). Ainsi, la variable Nb_ pixel_per_MB représente le rapport entre le nombre total de pixels pour une image et le nombre total de macro-blocs. La variable Nb_AppMB_per_Period correspond au nombre de macro-blocs produits par l'application par période de transport. Ainsi, la variable Nb_AppMB_per_Period correspond au nombre de macro-blocs par image (PicturePeriod qui correspond au nombre d'image(s) par seconde, « frame rate » en anglais) ramené à la durée d'une période de transport TransportPeriod. La variable Initial_value (exprimée en nombre de macro-blocs) correspond au temps nécessaire pour permettre au système de calculer le macro-bloc de transition lors d'un changement de codage source. On note qu'un choix judicieux de la valeur de la variable Initial_value permet de minimiser l'allocation de bande passante nécessaire au changement de codage source, et donc minimiser la quantité de données de bourrage nécessaire pour aligner le transport du macro-bloc de transition sur un début de période de transport. Ainsi, un choix judicieux de la valeur de la variable Initial_value permet de rendre le système plus réactif, c'est-à-dire qu'il est possible de minimiser la durée entre l'instant de génération de la requête de changement de codage source et l'instant auquel ce changement est effectif. La variable First_transportMB correspond au nombre de macro-blocs à transporter lors de la première période de transport. La variable MBseuil (décrit ci-dessous en relation avec la figure 7) correspond à l'index du macro-bloc seuil d'une période de transport donnée. En d'autres termes, la variable MB seuil indique, pour la période de transport donnée, le macro-bloc à partir duquel la couche transport ne doit plus transporter d'autre macro-bloc. La variable Delta correspond à un nombre de macro-blocs qui peut être ajouté ou retranché à la variable MB seuil pour diminuer ou augmenter la contrainte sur le transport des macro-blocs. Ainsi, la variable Delta permet de définir un nouveau macrobloc seuil, dont l'index est supérieur ou inférieur au macro-bloc seuil préalablement défini (MBseuil). Par exemple, lorsque la taille des macro-blocs, dans le cadre d'une compression à débit variable, est inférieure à la taille cible (par exemple la valeur moyenne de taille sur une période donnée correspondant à la valeur moyenne de taux binaire (« bit rate » en anglais) ou la valeur maximale de cette taille) sur des zones de faible complexité, l'ajout de la variable Delta à la variable MBseuil permet à la couche transport de transporter plus de macro-blocs que ce qui était imposé initialement. En d'autres termes, la somme des écarts (ou variations), des macro-blocs encodés, par rapport à une valeur cible de taille de macro-block, sur une période de transport est au moins égale à cette valeur cible de taille de macro-bloc ; on peut donc transporter un macro-bloc supplémentaire en lieu et place de données de bourrage. Il peut aussi être nécessaire d'appliquer un Delta négatif (zones de forte complexité sur une période de transport). De cette façon, on réduit le nombre de données de bourrage transportées et diminue la contrainte sur l'algorithme de compression sur des zones de forte complexité. Ceci permet de revenir à une position d'équilibre entre le nombre de macroblocs produits et le nombre de macro-blocs transportés. Ainsi, pour une bande passante allouée constante, le nombre de macro-blocs transmis peut être différent par période de transport, mais la moyenne du nombre de macro-blocs transmis sur un nombre donné de périodes de transport reste constante. Ceci peut être intéressant lorsque le codage source fournit des macro-blocs de tailles variables suivant leur complexité. Comme on le verra par la suite, cette valeur Delta est stockée dans la table de stockage 220 et est utilisée par le module de gestion de changement de codage source 250 pour déterminer le macro-bloc de transition, lors d'un changement de codage source. La variable Offset correspond à l'écart temporel entre l'instant de détection d'un événement de début d'image et l'instant de détection d'un événement réseau network_event 217 le précédant. Il est à noter qu'au démarrage, un événement réseau network_event 217 se produit avant un événement de début d'image. Après l'étape d'initialisation 400, on passe à une étape 401 d'attente d'un événement réseau network_event 217 (marquant le début d'une période de transport) ou d'un événement de début d'image. Sur détection d'un événement réseau network_event 217 (étape 402), il est procédé à la réinitialisation (mise à zéro) d'un compteur d'offset (étape 403). Ce compteur d'offset est incrémenté au rythme de l'horloge réseau. Puis un retour dans l'état d'attente 401 est opéré. Sur détection d'un événement de début d'image (étape 404), le module de traitement 210 enregistre la valeur du compteur d'offset (variable Offset) (étape 405), avant de passer à l'étape 406. A l'étape 406, il est procédé à la mise à jour de la variable Initial_value, en fonction de la valeur de la variable Offset enregistrée, et au calcul de la variable First_transportMB (comme décrit ci-après). Ensuite, la variable First_transportMB est transmise vers le module de gestion de transmission 240. La variable First_transportMB est déterminée (étape 406) par la formule suivante (où le symbole « % » représente l'opération « modulo ») : First _ transportMB = ((1 ransportPeriod - offset) x Nb _ AppMB _ per _ Period + Initial _ value)%(TransportPeriod x Nb _ AppMB _ perPeriod) On note que la variable First_transportMB a une influence sur la latence initiale globale du système. En effet, si à l'issue de la latence initiale inhérente au système, le temps restant de la première période de transport ne permet pas de transporter le nombre First_transportMB de macro-blocs (déterminé lors de l'initialisation), alors on attend la période de transport suivante (latence supplémentaire) pour transporter les First_transportMB macro-blocs ou on modifie la valeur de la variable Initial_value pour obtenir un nouveau nombre First_transportMB de macro-blocs qui peuvent être transmis pendant le temps restant de la première période de transport. Ainsi, la valeur de la variable Initial_value peut être augmentée ou diminuée (dans la limite du temps de calcul nécessaire au choix du macro-bloc de transition) de façon à obtenir une valeur First_transportMB adaptée à la latence initiale inhérente au système. L'augmentation de la valeur de la variable Initial value aura comme conséquence d'augmenter le temps de réaction lors d'un changement de codage source. On décrit maintenant les étapes 407 à 423 de la phase d'utilisation en régime établi. Après l'étape 406, on passe à une étape 407 d'attente d'un événement réseau network_event 217 ou d'un événement d'horloge applicative. Sur détection d'un événement réseau network_event 217 (étape 410), le module de traitement 210 enregistre la valeur du compteur de macro-bloc applicatif Cpt_ApplicatifMB (étape 411), avant de passer à l'étape 412. A l'étape 412, il est procédé au calcul de la variable MBseuil, c'est-à-dire de l'index du macro-bloc seuil pour la période de transport courante, et à l'écriture de cet index dans la table de stockage 220, au travers de l'interface MB seuil 221. L'index du macro-bloc seuil est obtenu en additionnant la valeur du compteur de macro-bloc applicatif Cpt_ApplicatifMB (enregistrée à l'étape 411) et la valeur de la variable Initial value déterminée lors de l'initialisation. A cette même étape 412, on définit une variable Delta, par exemple, en fonction de la taille des derniers macro-blocs encodés produits, pour la variable MBseuil, puis on écrit cette variable Delta dans la table de stockage 220. On rappelle que cette variable Delta correspond à un nombre de macro-blocs qui peut être ajouté ou retranché à la variable MB seuil pour diminuer ou augmenter la contrainte sur le transport des macroblocs. On note que la profondeur de la table de stockage 220 dépend de la latence initiale globale par rapport à la période de transport. Par exemple, si la latence initiale globale est supérieure à une période de transport mais inférieure à deux périodes de transport, alors la profondeur de la table de stockage 220 est égale à la taille de deux macro-blocs. La profondeur de la table correspond à la valeur de latence initiale globale en nombre de période de transport arrondie à l'entier supérieur (NB_period). Après l'étape 412, un retour dans l'état d'attente 407 est opéré. Sur détection d'un événement d'horloge applicative (étape 420), le compteur de pixels Cpt pixel est incrémenté d'une unité (étape 421). Ensuite, un test est effectué (étape 422) pour déterminer si la valeur du compteur de pixels Cpt_pixel est égale au nombre Nb_ pixel_per_MB de pixels par macro-bloc. Si la valeur du compteur de pixels Cpt_pixel est égale au nombre Nb_ pixel_per_MB, alors le compteur de pixels Cpt_pixel est remis à zéro et le compteur de macro-blocs Cpt_ApplicatifMB est incrémenté d'une unité (étape 423), puis un retour dans l'état d'attente 407 est opéré. Sinon, un retour dans l'état d'attente 407 est directement opéré. La figure 5 présente un mode de réalisation particulier d'un algorithme de paquétisation des données, tel qu'implémenté au sein du module de gestion de transmission 240 (compris dans le noeud émetteur 102). Lors d'une étape d'initialisation 500, il est procédé à l'initialisation des variables et compteurs suivants : - Nb_transportPacket_per_MB = 0 ; - Nb_transportPacket_per_Period = 0 ; - Cpt_transportPacket = 0 ; - Nb_Packet_To_transport = 0 ; - Cpt_TransportMB = 0 ; La variable Nb_transportPacket_per_MB correspond au nombre de paquet de transport nécessaire au transfert d'un macro-bloc (après encodage ou après compression) vers le noeud récepteur 103. La variable Nb_transportPacket_per_MB dépend du format de la vidéo d'entrée, du nombre NB_MB_PER_PICTURE de macroblocs par image pour cette vidéo, de l'encodage (compression) appliqué sur les données applicatives (et donc de la bande passante allouée à l'application) et de la taille des paquets de transport. Par exemple, pour une vidéo en 720p, c'est-à-dire 1280 pixels actifs par ligne par 720 lignes actives avec des macro-blocs 16 par 16 et une compression de 444 vers 420 (passage de 24 bits par pixel à 12 bits par pixel), il faut 64 paquets de transport de 48 bits chacun (64x48 = 16x16x12). La variable Nb_transportPacket_per_Period correspond au nombre de paquet de transport alloué par période de transport. Cette variable Nb_transportPacket_per_Period représente donc la bande passante allouée à l'application par période de transport. Cette variable Nb_transportPacket_per_Period dépend de la période de transport, du format de la vidéo d'entrée, de l'encodage (compression) appliqué sur les données applicatives (et donc de la bande passante allouée à l'application exprimée en bit par seconde) et de la taille des paquets de transport. Par exemple, pour une vidéo en 720p, avec 60 trames par seconde et une compression de type 4 : 4 : 4 vers 4:2:0 par suppression d'informations de chrominance, et avec une période de transport de 1 milliseconde, il faut 13824 paquets de transport de 48 bits chacun (1280x720x60/4x1000 : nombre de pixels actifs par ligne x nombre de lignes actives x 60 trames par seconde / rapport entre nombre de bits par pixel et nombre de bits par paquets de transport x l'inverse de la période de transport). Cpt_transportPacket est un compteur de paquet de transport. La variable Nb_Packet_To_transport correspond au nombre de paquet à transporter pour la période de transport courante. Comme on le verra par la suite, cette variable est utilisée par le module de gestion de transmission 240. Cpt_TransportMB est un compteur de macro-blocs transportés. Chaque macro- bloc seuil stocké dans la table de stockage 220 représente une valeur cible de macrobloc à ne pas dépasser par le compteur Cpt_TransportMB pendant une période de transport donnée. Ce compteur est incrémenté à chaque frontière entre deux macroblocs lors de la paquétisation. Après l'étape d'initialisation 500, on passe à une étape 501 d'attente de la première donnée à transporter ou d'un événement réseau network_event 217 (marquant le début d'une période de transport). On décrit ci-après les étapes 520 à 526 relatives à une phase d'initialisation. Sur réception de la première donnée à transporter (étape 520), il est procédé à la lecture (étape 521) de la variable First_transportMB (calculée et transmise par le module de traitement 210), correspondant au nombre de macro-blocs à transporter pendant la première période de transport. La première période de transport démarre après la latence initiale globale. A l'étape 522, on détermine le nombre de paquet de transport nécessaire pour transporter les First_transportMB macro-blocs. Cette étape 522 est détaillée ci-après, en relation avec la figure 6. A l'étape 523, on attend l'écoulement d'une durée correspondant à la latence initiale globale. Cette durée est exprimée en sous multiple de la période de transport. A l'étape 524, le module de gestion de transmission 240 remplit le premier paquet de transport. A cette même étape 524, le compteur de paquet de transport Cpt_transportPacket est incrémenté d'une unité. A l'étape 525, un test est effectué pour déterminer si la valeur du compteur de paquet de transport Cpt_transportPacket est égale au nombre Nb_Packet_To_transport de paquet à transporter pour la première période de transport. Si la valeur du compteur de paquet de transport Cpt_transportPacket est égale au nombre Nb_Packet_To_transport, alors le compteur de paquet de transport Cpt_transportPacket est remis à zéro (étape 526), puis un retour dans l'état d'attente 501 est opéré. Sinon, on retourne à l'étape 524 pour remplir le paquet de transport suivant. On décrit ci-après les étapes 510 à 516 relatives à une phase d'utilisation en régime établi. Sur détection d'un événement réseau network_event 217 (étape 510), le module de gestion de transmission 240 détermine le nombre Nb_Packet_To_transport de paquet à transporter pour la période de transport courante (étape 511). A l'étape 512, le module de gestion de transmission 240 remplit le premier paquet de transport. A cette même étape 512, le compteur de paquet de transport Cpt_transportPacket est incrémenté d'une unité. A l'étape 513, un test est effectué pour déterminer si la valeur du compteur de paquet de transport Cpt_transportPacket est égale au nombre Nb_Packet_To_transport de paquet à transporter pour la période de transport courante. Si la valeur du compteur de paquet de transport Cpt_transportPacket est égale au nombre Nb_Packet_To_transport, alors l'étape 514 est effectuée, sinon on retourne à l'étape 512 pour remplir le paquet de transport suivant. A l'étape 514, un test est effectué pour déterminer si tous les paquets de transport alloué à l'application ont été remplis pour la période de transport courante. En d'autres termes, on détermine si la bande passante allouée à l'application a été entièrement utilisée. Si tous les paquets de transport ont été remplis, alors le compteur de paquet de transport Cpt_transportPacket est remis à zéro (étape 516), puis un retour dans l'état d'attente 501 est opéré. S'il est détecté un ou plusieurs paquets de transport non rempli(s), alors des données de bourrage sont ajoutées pour compléter le ou les paquets de transport non remplis (étape 515), puis le compteur de paquet de transport Cpt_transportPacket est remis à zéro (étape 516), et un retour dans l'état d'attente 501 est opéré. On présente maintenant, en relation avec la figure 6, un mode de réalisation particulier de l'étape 522 de la figure 5 (algorithme de paquétisation des données effectué par le noeud émetteur). Après démarrage (étape 600), un test est effectué (étape 601) pour déterminer si la valeur du compteur de macro-blocs transportés Cpt_TransportMB est égale au nombre First_transportMB de macro-blocs à transporter pendant la première période de transport. Si la valeur du compteur de macro-blocs transportés Cpt_TransportMB est inférieure au nombre First_transportMB, alors il est procédé à la lecture de la taille du macro-bloc suivant (étape 602), le macro-bloc suivant devenant le macro-bloc courant lors d'une prochaine itération. Ensuite, le compteur de macro-blocs transportés Cpt_TransportMB est incrémenté d'une unité (étape 603). Puis, on détermine le nombre de paquet de transport nécessaire pour transporter le macro-bloc courant (étape 604), et un retour au test de l'étape 601 est opéré. Si la valeur du compteur de macro-blocs transportés Cpt_TransportMB est égale au nombre First_transportMB, alors le module de gestion de transmission 240 enregistre la quantité de données restante à transporter pour le dernier macro-bloc de la première période de transport, ainsi que l'index (ou numéro) de ce dernier macro-bloc (étape 606). Par exemple, si First_transportMB = 12.8 et que la taille du 13ème macro-bloc est 6144 bits, l'index du dernier macro-bloc est 13, et la quantité de données restante à transporter est 1228 bits (6144 - 6144x0.8). Après exécution de l'étape 606, on passe à l'étape 523 (figure 5). On présente, en relation avec la figure 7, un mode de réalisation particulier de l'étape 511 de la figure 5 (algorithme de paquétisation des données effectué par le noeud émetteur). Après démarrage (étape 700), on lit la table de stockage 220 afin d'obtenir le macro-bloc seuil pour la période de transport courante (étape 701). A l'étape 710, un test est effectué pour déterminer si le macro-bloc courant a été totalement transporté. Ainsi, à cette étape 710 on vérifie si la quantité de données restante à transporter pour le dernier macro-bloc de la période de transport courante (enregistrée aux étapes 606 et 706) est égale à zéro. Si le macro-bloc courant a été totalement transporté, alors, avant de passer à l'étape 713, il est procédé à la lecture de la taille du macro-bloc suivant (étape 711) (le macro-bloc suivant devenant le macrobloc courant lors d'une prochaine itération) et à l'incrémentation d'une unité du compteur de macro-blocs transportés Cpt_TransportMB (étape 712). Sinon, on passe directement à l'étape 713. A l'étape 713, un test est effectué pour déterminer si la valeur du compteur de macro-blocs transportés Cpt_TransportMB est égale à l'index du macro-bloc seuil obtenu par lecture de la table de stockage 220 à l'étape 701. Si la valeur du compteur de macro-blocs transportés Cpt_TransportMB est égale à l'index du macro-bloc seuil, alors l'étape 716 est effectuée. Si la valeur du compteur de macro-blocs transportés Cpt_TransportMB est inférieure à l'index du macro-bloc seuil, alors on détermine le nombre de paquet de transport nécessaire pour transporter le macro-bloc courant (étape 714), Ensuite, un test est effectué (étape 715) pour vérifier si le dernier paquet de transport pour la période de transport courante est utilisé pour transporter le macro-bloc courant. En cas de vérification positive, l'étape 706 est effectuée, sinon on revient à l'étape 711 pour lire la taille du macro-bloc suivant. A l'étape 716, un test est effectué pour vérifier si le macro-bloc seuil correspond au macro-bloc de transition. Si le macro-bloc seuil correspond au macro-bloc de transition, alors le module de gestion de transmission 240 génère et insère un délimiteur de changement de codage source dans le flux de données à transmettre (étape 717), puis il effectue l'étape 706, sinon il effectue directement l'étape 706. A l'étape 706, le module de gestion de transmission 240 enregistre la quantité de données restante à transporter (telle que décrite ci-avant en relation avec la figure 6) pour le dernier macro-bloc de la période de transport courante, ainsi que l'index (ou numéro) de ce dernier macro-bloc. Après exécution de l'étape 706, on passe à l'étape 512 (figure 5). Lors d'un changement d'allocation de bande passante allouée à l'application, il est nécessaire d'adapter le codage source (c'est-à-dire le taux de compression appliqué sur les données applicatives) de manière à conserver une capacité de transport suffisante. Pour éviter des problèmes de qualité de service (c'est-à-dire maintenir une latence de bout en bout constante), le système doit synchroniser le changement de codage source et le changement effectif de bande passante. Le système doit donc aligner le bloc de donnée sur lequel est appliqué le nouveau codage source et le changement de bande passante. Pour cela, sur réception d'une requête de changement de codage source (Change_rq 241), le système effectue le calcul du bloc de données de transition (ou macro-bloc de transition) en tenant compte de la latence initiale globale et de la dérive de rapport entre le nombre de blocs de données applicatives produits par l'application et le nombre de blocs de données applicatives transmis après encodage par la couche transport. La figure 8 présente un mode de réalisation particulier d'un algorithme de calcul de macro-bloc de transition, tel qu'implémenté au sein du module de gestion de changement de codage source 250 (compris dans le noeud émetteur 102). Lors d'une étape d'initialisation 801, il est procédé à l'initialisation des variables suivantes (décrites en relation avec la figure 5) : - Nb_transportPacket_per_MB ; - Nb_transportPacket_per_Period. Après l'étape d'initialisation 801, on passe à une étape 802 d'attente d'une requête de changement de codage source Change_rq 241. Sur réception d'une requête de changement de codage source Change rq 241 (étape 803), le module de gestion de changement de codage source 250 obtient l'index du dernier macro-bloc transporté lors de la période de transport précédente au travers de l'interface index MB 242 (étape 804) et la quantité de données restante à transporter pour ce dernier macro-bloc au travers de l'interface offset MB 243 (étape 805). On détermine alors dans cette étape la valeur QI et la valeur drift_per_period utilisées dans la formule ci-dessous à l'étape 806. On détermine ainsi une dérive entre un nombre de blocs de données applicatives reçus et un nombre de blocs de données applicatives transmis après encodage. A l'étape 806, il est procédé au calcul du macro-bloc de transition sur lequel le changement de codage source doit s'opérer. Le macro-bloc de transition est déterminé par la formule suivante : IndexMB + QI + (NB_period x (Nb_AppMB_per_Period +drift_per_period)) + Delta où - IndexMB correspond à l'index du dernier macro-bloc de la période de transport précédente ; - QI correspond à la quantité de données de ce dernier macro-bloc transportées pendant la période de transport précédente. QI est définie comme étant la taille du dernier macro-bloc moins la quantité de données restante à transporter. La valeur QI est alors un indicateur du cumul des dérives des périodes de transport précédentes ; - NB_period correspond à la durée de la latence initiale globale divisée par la durée de la période de transport arrondi au supérieur ; - Nb_AppMB_per_Period correspond au nombre de macro-blocs par image ramené à la durée d'une période de transport TransportPeriod ; - drift_per_period correspond à la dérive entre le nombre de macro-blocs produit par l'application et le nombre de macro-blocs transportés par période de transport ; et - Delta correspond au nombre de macro-blocs qui est utilisé pour ajuster la variable MBseuil, et donc le nombre maximal de macro-blocs à transmettre pendant une période de transport donnée. Si une valeur Delta a été ajoutée à la variable MBseuil, alors cette même valeur Delta sera prise en compte dans le calcul du macro-bloc de transition. Comme décrit ci-après en relation avec la figure 13, le macro-bloc de transition est aligné sur un début de période de transport de façon à synchroniser le changement de codage source et le changement effectif de bande passante. Ensuite à cette même étape 806, le module de gestion de changement de codage source 250 met à jour la table de stockage 220 en remplaçant les index des macro-blocs seuils par l'index du macro-bloc de transition calculé. De cette façon, on empêche une éventuelle correction de dérive de s'opérer. Le macro-bloc de transition est identifié dans la table de stockage 220 au moyen d'un bit supplémentaire. A l'étape 807, le module de gestion de changement de codage source 250 met à jour le nombre de paquet à transporter pour la période de transport courante (Nb_Packet_To_transport). Une telle mise à jour (modification de la variable Nb_Packet_To_transport) permet : - d'aligner le macro-bloc de transition sur le début de la période de transport suivante, si la durée de la latence initiale est inférieure à la durée d'une période de transport ; ou - d'annuler une éventuelle correction de dérive qui aurait décalé le macro-bloc de transition et donc faussé l'alignement de celui-ci sur un début de période de transport. A l'étape 808, le module de gestion de changement de codage source 250 transmet vers le module de traitement 210 une requête de changement de codage source (change_CS 211) accompagnée d'une valeur cible de codage source (CS_consigne 212) et de l'index du macro-bloc de transition calculé à l'étape 806 (MB transition 213). Puis un retour dans l'état d'attente 802 est opéré. La figure 9 présente un mode de réalisation particulier d'un algorithme d'encodage de données, tel qu'implémenté au sein du module de traitement vidéo 210 (compris dans le noeud émetteur 102). Lors d'une étape d'initialisation 900, on définit un premier codage source à appliquer sur les données (par exemple de type vidéo) brutes fournies par l'application. Après l'étape d'initialisation 900, on passe à une étape 901 d'attente d'une requête de changement de codage source ou d'un bloc de données (macro-bloc) à encoder. Sur réception d'une requête de changement de codage source change CS 211 (étape 920), le module de traitement vidéo 210 obtient l'index du macro-bloc de transition (étape 921) calculée à l'étape 806. Puis un retour dans l'état d'attente 901 est opéré. Sur détection d'un bloc de données à encoder (étape 910), il est procédé à l'incrémentation d'une unité de l'index du macro-bloc courant (étape 911). Ensuite, un test est effectué pour déterminer si l'index du macro-bloc courant est égal à l'index du macro-bloc de transition (étape 912). Si l'index du macro-bloc courant est égal à l'index du macro-bloc de transition, en d'autres termes si le macro-bloc courant est le macro-bloc de transition, alors on modifie le codage source à appliquer sur les données provenant de l'application (étape 913), c'est-à-dire qu'on passe du premier codage source au second codage source défini par l'information CS_consigne. Les données sont alors encodées selon le second codage source (étape 914), y compris le macro-block de transition. Puis, l'étape 915 est effectuée. Si l'index du macro-bloc courant est différent de l'index du macro-bloc de transition, alors les données sont encodées selon le premier codage source (étape 914). Puis, l'étape 915 est effectuée. A l'étape 915, le module de traitement vidéo 210 envoie au module de gestion de transmission 240 le macro-bloc compressé (données encodées) et une information relative à la taille du macro-bloc compressé. Puis un retour dans l'état d'attente 901 est opéré. La figure 10 présente un mode de réalisation particulier d'un algorithme de traitement de délimiteurs de bloc de données et de délimiteurs de changement de codage source, tel qu'implémenté au sein du module de gestion de réception 310 (compris dans le noeud récepteur 103). Après une étape d'initialisation 1000, on passe à une étape 1001 d'attente d'un événement de réception d'un délimiteur de bloc de données ou d'un délimiteur de changement de codage source. Sur réception d'un délimiteur de bloc de données (étape 1010), le module de gestion de réception 310 envoie (étape 1011) au module de traitement 330 un signal start_decodage 313, afin d'autoriser celui-ci à commencer la lecture et le décodage des données compressées, stockées dans l'unité de stockage 320. Puis un retour dans l'état d'attente 1001 est opéré. Sur réception d'un délimiteur de changement de codage source (étape 1020), la valeur cible de codage source consigne_CS 312, fournie au module de traitement 330, est mise à jour (étape 1021). Puis un retour dans l'état d'attente 1001 est opéré. Il est à noter qu'au démarrage, le module de gestion de réception 310 reçoit d'abord un délimiteur de changement de codage source indiquant le premier traitement à effectuer, avant de recevoir le premier délimiteur de bloc de données qui permet de déclencher le décodage des données. La figure 11 illustre un exemple d'une table de stockage 220 comprise dans le noeud émetteur 102. Chaque ligne de la table de stockage 220 correspond à une période de transport. La première colonne 1100 de la table de stockage 220 indique l'index du macro- bloc seuil ou l'index du macro-bloc de transition pour une période de transport donnée, suivant la valeur contenue dans la deuxième colonne 1101. Ainsi, lorsque la deuxième colonne 1101 contient la valeur 0, cela signifie que la première colonne 1100 contient l'index du macro-bloc seuil. En revanche, lorsque la deuxième colonne 1101 contient la valeur 1, cela signifie que la première colonne 1100 contient l'index du macro-bloc de transition. Le macro-bloc seuil est déterminé par le module de traitement 210 à chaque début de période de transport. Le macro-bloc de transition (c'est-à-dire le bloc de données applicatives sur lequel le changement de codage source doit être effectué) est déterminé par le module de gestion de changement de codage source 250 à chaque modification de la répartition de la bande passante allouée à l'application. La troisième colonne 1102 de la table de stockage 220 indique un nombre Delta de bloc de données encodées à ajouter ou à retrancher au nombre MB seuil pour atteindre la valeur « normale » du MBseuil. Cette indication est utilisée par le module de gestion de changement de codage source 250 lors du calcul du MB de transition. Cette valeur de Delta permet de diminuer ou augmenter ponctuellement la contrainte sur la couche transport, et donc de diminuer la contrainte sur l'algorithme de compression mis en oeuvre par le module de traitement vidéo 210. La figure 12 illustre schématiquement le principe d'un mode de réalisation particulier de l'invention, à travers un exemple de correction d'une dérive entre le rythme de production des données par la couche applicative et le rythme de transport de ces données par la couche transport. La figure 12 se décompose en une partie haute et une partie basse, référencées 1220 et 1230 respectivement. La partie haute 1220 illustre la génération (au niveau de la couche applicative) des blocs de données (macro-blocs) encodées par application d'un codage source sur les données applicatives brutes fournies par l'application. La partie haute 1220 comprend quatre périodes temporelles 1200 (représentée partiellement), 1201, 1202 et 1203 correspondant à quatre fenêtres d'encodage. Le début de chaque fenêtre d'encodage est aligné sur un événement réseau 1210. Chaque fenêtre d'encodage a la même durée qu'une période de transport et est destinée à cadencer l'encodage des données à transporter pendant une période de transport. Dans l'exemple illustré, l'application commence à fournir des blocs de données applicatives (par exemple de type vidéo) au cours de la période 1200. Chaque début de bloc de données applicatives est représenté par une flèche en pointillée 1211. Chaque bloc de données applicatives brutes est fourni par l'application à intervalle de temps d'une durée égale à la période 1227 qui correspond pour un macro-bloc de format 16 par 16 à 256 événements générés par l'horloge applicative. Un compteur Cpt_ApplicatifMB (décrit en relation avec la figure 4) compte les macro-blocs produit par l'application. Ce compteur Cpt_ApplicatifMB s'incrémente à la fin de chaque période 1227 et la valeur de ce compteur est enregistrée dans une table à la fin de chaque événement réseau 1221, 1222, 1223 et 1224. La partie basse 1230 illustre une séquence de transport (au niveau de la couche transport) des blocs de données (macro-blocs) encodées. L'événement réseau 1210 est représenté de manière commune à la partie basse 1230 et à la partie haute 1220 de la figure 12. Ainsi, les quatre périodes temporelles 1200 (période représentée partiellement), 1201, 1202 et 1203 correspondent aussi à quatre périodes de transport. Chaque début de bloc de données encodées est représenté par une flèche en pointillée 1218. Chaque bloc de données encodées est transmis par la couche transport pendant une sous-période de transport 1237. Une période de transport permet de transporter un nombre donné de macro-blocs. La période de transport d'un macro-bloc est appelée sous-période de transport. Un compteur Cpt_TransportMB (décrit en relation avec les figures 5, 6 et 7) compte les macro-blocs encodés qui sont transportés par la couche transport. Ce compteur Cpt_TransportMB s'incrémente à la fin de chaque sous-période de transport 1237 et la valeur de ce compteur est enregistrée dans une table à la fin de chaque période de transport 1231, 1232, et 1233. Comme décrit en relation avec la figure 4, lors d'une phase d'initialisation, le système calcule la valeur de la variable Initial_value. Dans l'exemple illustré, la valeur de la variable Initial_value est égale à 7. Le système détermine la latence initiale globale 1250 à partir de la latence initiale inhérente au système 1240, du nombre First_transportMB de blocs de données encodées à transporter pendant la (première) période de transport 1201, et du décalage nécessaire pour que le début du macro-bloc de transition soit aligné avec le début de la période de transport suivante, lors d'un changement de codage source. Après l'écoulement de cette latence initiale globale 1250, la couche transport transporte les First_transportMB blocs de données encodées pendant la période de transport 1201. Pour chaque période de transport suivante 1202 et 1203, la couche transport remplit tout(tous) le(s) paquet(s) de transport jusqu'à ce que le compteur de macro-blocs transportés Cpt_TransportMB atteigne une valeur cible de macro-bloc préalablement déterminée pour la période de transport. Cette valeur cible de macro-bloc correspond au macro-bloc seuil dont l'index est obtenu en additionnant la valeur du compteur Cpt_ApplicatifMB (enregistrée à la fin de la fenêtre d'encodage des macro-blocs) et la valeur de la variable Initial value déterminée lors de l'initialisation. Dans l'exemple illustré par la figure 12, pour la période de transport 1202, la valeur de l'index du macro-bloc seuil est égale à 20. En d'autres termes, la couche transport ne doit pas transporter le 20ème macro-bloc lors de la période de transport 1202. Dans cet exemple, le dernier macro-bloc transporté par la couche transport est le 19ème macro-bloc. Aucune correction de dérive n'est donc nécessaire. Dans l'exemple illustré par la figure 12, pour la période de transport 1203, la valeur de l'index du macro-bloc seuil est égale à 31. Dans cet exemple, il est nécessaire d'ajouter des données de bourrage en complément des blocs de données encodées compris dans la période de transport 1203. En effet, dans cet exemple le 31ème macrobloc est déjà atteint avant que tout(tous) le(s) paquet(s) de transport ne soit rempli. La couche de transport ajoute donc des données de bourrage 1260 à la fin du 30ème macrobloc jusqu'à ce que tous les paquets de transport soient remplis. Sans l'ajout de ces données de bourrage, le nombre de macro-blocs, transportés pendant la période de transport 1202, serait plus important que le nombre MB seuil (défini en relation avec la figure 4) autorisé, ce qui entraînerait une modification de la latence de bout en bout et donc pourrait entraîner après un temps donné une rupture de service. L'ajout de ces données de bourrage permet également de reporter le transport du 31ème macro-bloc à la période de transport suivante. De cette façon, on maintient l'écart entre la production et le transport des blocs de données à une valeur fixe acceptable, c'est-à-dire correspondant à la précision des autres éléments du système (gigue sur les événements réseau par exemple). La figure 13 illustre schématiquement le principe d'un mode de réalisation particulier de l'invention, à travers un exemple de correction d'une dérive entre le rythme de production des données par la couche applicative et le rythme de transport de ces données par la couche transport, dans le cas d'un changement de codage source. La figure 13 se décompose en une partie haute et une partie basse, référencées 1320 et 1330 respectivement. La partie haute 1320 illustre la génération (au niveau de la couche applicative) des blocs de données (macro-blocs) encodées par application d'un codage source sur les données applicatives brutes fournies par l'application. La partie haute 1320 comprend quatre périodes temporelles 1300 (représentée partiellement), 1301, 1302 et 1303 correspondant à quatre fenêtres d'encodage. Le début de chaque fenêtre d'encodage est aligné sur un événement réseau 1310. Dans l'exemple illustré, l'application vidéo commence à fournir des blocs de données applicatives au cours de la période 1300. Chaque début de bloc de données applicatives est représenté par une flèche en pointillée 1311. Chaque bloc de données applicatives est encodé pendant une période d'encodage 1327 Pendant les première et deuxième fenêtres d'encodage 1300 et 1301, les données applicatives brutes sont encodées (compressées) selon un premier codage source. Pendant la troisième fenêtre d'encodage 1302, les données applicatives brutes sont encodées selon le premier codage source, puis selon un second codage source. Pendant la quatrième fenêtre d'encodage 1303, les données applicatives brutes sont encodées selon le second codage source. Au début de la troisième fenêtre d'encodage 1302, une requête de changement 1312 de codage source est reçue. Le module de gestion de changement de codage source 250 détermine le macro-bloc de transition (MB transition) 1313 sur lequel le changement de codage source doit s'opérer et qui sera aligné sur un début de période de transport. La partie basse 1330 illustre une séquence de transport (au niveau de la couche transport) des blocs de données (macro-blocs) encodées. L'événement réseau 1310 est représenté de manière commune à la partie basse 1330 et à la partie haute 1320 de la figure 13. Ainsi, les quatre périodes temporelles 1300 (période représentée partiellement), 1301, 1302 et 1303 correspondent aussi à quatre périodes de transport. Chaque début de bloc de données encodées est représenté par une flèche en pointillée 1318. Chaque bloc de données encodées est transmis par la couche transport pendant une sous-période de transport 1337. Un compteur Cpt_TransportMB (décrit en relation avec les figures 5, 6 et 7) compte les macro-blocs encodés qui sont transportés par la couche transport. Ce compteur Cpt_TransportMB s'incrémente à la fin de chaque sous-période de transport 1337 et la valeur de ce compteur est enregistrée dans une table à la fin de chaque période de transport 1331, 1332, et 1333. Comme décrit en relation avec la figure 4, lors d'une phase d'initialisation, le système calcule la valeur de la variable Initial_value. Dans l'exemple illustré, la valeur de la variable Initial_value est égale à 7. Le système détermine la latence initiale globale 1350 à partir de la latence initiale inhérente au système 1340, du nombre First_transportMB de blocs de données encodées à transporter pendant la (première) période de transport 1301, et du décalage nécessaire pour que le début du macro-bloc de transition soit aligné avec le début de la période de transport suivante, lors d'un changement de codage source. Après l'écoulement de cette latence initiale globale 1350, la couche transport transporte les First_transportMB blocs de données encodées pendant la première période de transport 1301. Pour la deuxième période de transport 1302, la couche transport remplit tout(tous) le(s) paquet(s) de transport jusqu'à ce que le compteur de macro-blocs transportés Cpt_TransportMB ait atteint la valeur MB_transition (correspondant au macro-bloc de transition) déterminée suite à la réception de la requête de changement 1312 de codage source. Dans l'exemple illustré par la figure 13, la valeur MB_transition est égale à 19. En d'autres termes, le macro-bloc de transition est le 19ème macro-bloc. Dans cet exemple, lorsque le compteur Cpt_TransportMB atteint la valeur MB_transition, le système ajoute des données de bourrage 1360 à la fin du 18ème macrobloc jusqu'à ce que le 19ème macro-bloc soit aligné sur le début de la troisième période de transport 1303. Ainsi, le changement de bande passante et le changement de codage source peuvent se produire de manière synchrone, c'est-à-dire sans période de transition. Ceci permet donc de maintenir une latence de bout en bout constante dans le cadre d'un changement conjugué de bande passante et de codage source et permet également de maximiser l'utilisation de la bande passante allouée à l'application. L'ajout de ces données de bourrage permet également de maintenir l'écart entre la production et le transport des blocs de données à une valeur fixe acceptable, c'est-à- dire correspondant à la précision des autres éléments du système (gigue sur les événements réseau par exemple). REVENDICATIONS1. Procédé de gestion d'une transmission d'un flux de données depuis un dispositif émetteur (102), le dispositif émetteur recevant des blocs de données applicatives à transmettre à un dispositif récepteur (103) selon un cadencement défini par des périodes 5 de transport, les blocs de données applicatives étant encodés avant transmission par application d'un premier codage source jusqu'à traitement d'une requête de changement, caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : - déterminer (805) une dérive entre un nombre de blocs de données applicatives reçus par le dispositif émetteur et un nombre de blocs de données applicatives transmis après encodage par le dispositif émetteur ; - déterminer (806), en prenant en compte la dérive déterminée, un bloc de données applicatives de transition à partir duquel un second codage source est appliqué en réponse à ladite requête de changement ; - adapter la transmission dudit flux de telle sorte que la transmission du bloc de données de transition encodé soit alignée sur un début de période de transport. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape consistant à déterminer une dérive comprend des étapes consistant à : - identifier (804) le dernier bloc de données encodé (IndexMB) qui a été transmis pendant la période de transport qui précède le traitement de ladite requête de changement ; - déterminer la quantité (Ql) de données transmises dudit dernier bloc de données encodé identifié; et en ce que ledit bloc de données applicatives de transition est déterminé en prenant également en compte la quantité de données transmises déterminée. 25 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que le dispositif émetteur effectue une étape consistant à : - choisir (406) un décalage temporel (1350) à appliquer entre l'instant de début de réception desdits blocs de données applicatives et l'instant de début de transmission desdits blocs de données encodés, en fonction d'une période de 30 temps nécessaire à l'exécution des étapes consistant à déterminer ladite dérive et à déterminer ledit bloc de données applicatives de transition. 10 15 20 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : - déterminer un nombre de bloc(s) de données applicatives (Delta) représentant un cumul de variation de taille de blocs de données encodés à transmettre par rapport à une valeur de taille cible ; - déterminer ledit bloc de données applicatives de transition, en prenant également en compte le nombre de bloc(s) de données applicatives déterminé. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape consistant à adapter la transmission dudit flux comprend une étape consistant à ajouter, en complément du bloc de données encodé qui est transmis juste avant le bloc de données de transition encodé, des données de bourrage (1360) jusqu'à ce que le bloc de données de transition encodé soit aligné sur un début de période de transport. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que la taille des blocs de données applicatives est choisie en fonction de la précision d'une horloge en charge de définir ledit cadencement. 7. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur. 8. Moyen de stockage lisible par ordinateur, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 6. 9. Dispositif émetteur (102) comprenant des moyens pour gérer une transmission d'un flux de données, le dispositif émetteur recevant des blocs de données applicatives à transmettre à un dispositif récepteur (103) selon un cadencement défini par des périodes de transport, les blocs de données applicatives étant encodés avant transmission par application d'un premier codage source jusqu'à traitement d'une requête de changement, caractérisé en ce que le dispositif émetteur comprend les moyens suivants : - des moyens pour déterminer une dérive entre un nombre de blocs de données applicatives reçus par le dispositif émetteur et un nombre de blocs de données applicatives transmis après encodage par le dispositif émetteur ; 5- des moyens pour déterminer, en prenant en compte la dérive déterminée, un bloc de données applicatives de transition à partir duquel un second codage source est appliqué en réponse à ladite requête de changement ; - des moyens pour adapter la transmission dudit flux de telle sorte que la transmission du bloc de données de transition encodé soit alignée sur un début de période de transport.