Brevet FR2949036A1 — publié le 20110211

Procédé et dispositif de transmission de données entre un dispositif émetteur et un dispositif récepteur, avec gestion de troncature, produit programme d'ordinateur et moyen de stockage 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. On suppose que le dispositif émetteur comprend un encodeur fournissant des données utiles sous forme de blocs. 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. La technique de l'invention se situe au niveau de la gestion des données dans une mémoire tampon (aussi appelée � buffer �) de transmission située, au sein du dispositif émetteur, entre l'encodeur et le 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 par 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 les instants de réception des données applicatives, et l'instant de transmission associé aux propriétés synchrones ou asynchrones du canal de transmission. Pour des systèmes de distribution temps réel à faible latence, supportant par exemple des applications vidéo de type 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. Dans ce cas, les données vidéo brutes issues de l'application sont compressées par le dispositif émetteur avant transmission, en utilisant alors une technique de compression (encodage) dite par blocs de lignes, par exemple par blocs de 16 lignes. Dans la suite de la description, un bloc de lignes est aussi appelé � tuile � (ou � Tile � en anglais). Cette technique de compression permet en effet de limiter l'effet sur la faible latence exigée de bout en bout. Pour limiter la perte de qualité après reconstruction des données au niveau du dispositif récepteur restituant les données applicatives, la compression employée est alors de type VBR (� Variable Bit Rate � en anglais, ou � Débit binaire variable � en français), ce qui permet de garantir un niveau de qualité constant quel que soit le contenu brut initial. Dans ce cas, pour une même quantité brute de référence (par exemple une tuile avant encodage), la quantité de données compressées (c'est-à-dire une tuile encodée, dans l'exemple précité) est par définition variable, même si la quantité moyenne des données à l'échelle d'une trame vidéo ou d'une seconde est par défaut alignée sur la consigne de débit par défaut fixée à l'encodeur, correspondant par défaut à la valeur de la bande passante du canal de transmission. Dans ces conditions, la mémoire tampon de transmission (comprise dans le dispositif émetteur) doit être dimensionnée de manière à absorber les variations observées en sortie de l'encodeur (également compris dans le dispositif émetteur) pendant la transmission des données. En fonction du contenu initial avant compression, le débit moyen observé en sortie de l'encodeur peut cependant dépasser la consigne par défaut fixée à l'encodeur, et atteindre un seuil critique proche du dépassement de capacité de la mémoire tampon. Il est alors nécessaire de modifier la consigne de débit de l'encodeur en vue de ramener le niveau de remplissage de la mémoire tampon en dessous de ce seuil critique prédéfini. Néanmoins, compte tenu des propriétés du type de compression, l'application de la nouvelle consigne de débit n'est pas toujours effective dans un intervalle de temps escompté (correspondant à une ou plusieurs périodes tuiles), et il convient alors de procéder à la suppression des données excédant la capacité de la mémoire tampon de transmission, si l'on veut maintenir la latence de transmission des données. Lorsque l'on procède ainsi à la suppression de données encodées, les problèmes à résoudre sont de plusieurs natures : • maintien de la synchronisation du décodeur (compris dans le dispositif récepteur), indépendamment de la position des données supprimées au sein du flux encodé ; • minimisation de la perte de qualité inhérente à la reconstruction des données manquantes dans le décodeur, souvent réalisée par estimation ; • sélection des données à supprimer. Dans l'état de la technique, il existe plusieurs techniques de recouvrement des erreurs liées à la perte de données au cours de la transmission, ou liées à la suppression de données à l'émission. Selon une première approche connue, les trames vidéo issues de l'application sont tout d'abord encodées en utilisant les techniques de détection/prédiction de mouvement entre trames, tel que MPEG-2 ou H264, ce qui permet ultérieurement de bénéficier de redondance intrinsèque à l'encodage lors de la reconstruction de données manquantes, et donc de minimiser l'effort de recouvrement des erreurs. Un inconvénient de cette première approche connue est que, dans le cadre de l'utilisation d'un encodeur à faible latence, l'utilisation des techniques de détection/prédiction entre trames n'est pas envisageable, et l'absence de données devient donc un élément préjudiciable. Selon une deuxième approche connue, des méthodes d'insertion de redondance supplémentaire sont employées, telle que définies dans les standard FGS (� Fine Granularity Scaling � en anglais), ou PET (� Priority Encoding Transmission � en anglais), afin de limiter la perte de qualité après décodage. Un inconvénient de cette deuxième approche connue est que l'ajout de redondance (données supplémentaires) provoque une diminution de la bande passante utile pour les données applicatives primaires (non redondantes). Le problème étant la gestion de la troncature en cas d'un trop grand nombre de données, l'ajout de données supplémentaires n'est pas envisageable. Selon une troisième approche connue, pour maintenir la synchronisation du décodeur, les différents standards précédemment cités utilisent également une méthode d'encodage en insérant régulièrement des symboles de synchronisation (marqueurs temporels) qui permettent d'isoler spatialement à la reconstruction les parties manquantes de l'image à restituer. Un inconvénient de cette troisième approche connue est qu'elle permet de conserver la synchronisation du décodeur (et donc de la vidéo affichée) grâce aux marqueurs temporels, mais elle ne permet pas de corriger ou minimiser l'impact des données perdues. Selon une quatrième approche connue, lorsqu'un dépassement de la capacité de la mémoire tampon de transmission est observé au cours de l'encodage, les différents standards de compression cités précédemment implémentent un protocole de signalisation (appelé � Skip protocol � en anglais), qui permet de ne pas encoder une partie des données suivantes (en relation avec la quantité en excès), et permettre ainsi lors du décodage, d'isoler les données absentes à reconstituer. Cette quatrième approche connue est présentée par exemple dans le brevet US 6,937,653, qui décrit une méthode de troncature dans le cadre d'une application de transmission de données vidéo compressées utilisant un mode de transmission synchrone à débit constant. Cette solution utilise une compression par Macro-blocs, et une boucle de contre-réaction entre le taux de remplissage de la mémoire tampon de transmission et la consigne de débit fixée à l'encodeur. Lorsque le taux de remplissage de la mémoire tampon dépasse un seuil critique prédéterminé, un signal de contrôle est activé vers l'encodeur pour ne pas encoder le ou les Macro-blocs suivants. L'absence de données compressées associées aux Macro-blocs non encodés est signalée au travers d'une information de contrôle (dite � Skip �). Sur réception de cette information de contrôle, le décodeur procède alors à un traitement de correction d'erreur dans l'espace image. La quatrième approche connue présente deux inconvénients découlant du fait que le traitement visant à supprimer des données est basé uniquement sur le taux de remplissage de la mémoire tampon : • les données en excès sont supprimées ; les conséquences sur le décodage sont alors aléatoires et engendrent une diminution de la QoE (� Quality of Experience �, c'est-à-dire le perçu au niveau utilisateur) ; • la quantité de données supprimées est systématiquement associée à la quantité de données en excès de la mémoire tampon. En effet, la suppression des données est obtenue en agissant en amont de l'encodeur (sur détection d'un débordement de la mémoire tampon, le ou les Macro-blocs suivants ne sont pas encodés), ce qui implique une utilisation rigide de la bande passante qui s'en trouve non optimisée. 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, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de transmission de données entre un dispositif émetteur et un dispositif récepteur, permettant d'optimiser la gestion d'une suppression de données (c'est-à-dire la gestion d'une troncature) dans le cas où la quantité de données à transmettre excède la bande passante du canal de transmission. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique pouvant être utilisée si le dispositif émetteur comprend un encodeur à faible latence. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant de réduire les impacts sur la qualité de décodage des données dans le cadre de la gestion d'une suppression de données. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant une utilisation moins rigide de la bande passante. Un autre objectif d'au moins un mode de réalisation de l'invention est 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 transmission de données entre un dispositif émetteur et un dispositif récepteur, le dispositif émetteur comprenant un encodeur fournissant des données utiles sous forme de blocs, ledit procédé étant caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : organiser les blocs en fenêtres d'encodage, chaque fenêtre d'encodage comprenant un ensemble déterminé de bloc(s) et étant associée à une quantité cible de données ; - détecter, pour un ensemble de bloc(s) compris dans une fenêtre d'encodage donnée, un dépassement de quantité de données utiles par rapport à une quantité cible donnée associée à la fenêtre d'encodage donnée ; - déterminer une quantité en excès liée au dépassement détecté ; - choisir et enlever au moins une portion d'au moins un bloc, dit bloc(s) coupé(s), parmi ledit ensemble de bloc(s), pour obtenir un ensemble modifié, la quantité de données comprises dans la ou les portion(s) enlevée(s) du ou des bloc(s) coupé(s) étant supérieure ou égale à la quantité en excès déterminée ; - transmettre, au cours d'une période de transmission, ledit ensemble modifié ; - détecter une fenêtre d'encodage suivante nécessitant des données de bourrage pour obtenir une quantité cible associée à la fenêtre d'encodage suivante, en complément des données utiles du ou des blocs compris dans la fenêtre d'encodage suivante ; - transmettre, au cours d'une période de transmission suivante, au moins une partie de la ou les portion(s) enlevée(s), à la place d'au moins une partie des données de bourrage. Ainsi, ce mode de réalisation particulier de l'invention repose sur une approche tout à fait nouvelle et inventive consistant à gérer une suppression de données, non pas en fonction du taux de remplissage d'une mémoire tampon, mais en fonction du taux de remplissage de fenêtres d'encodage (associées chacune à une quantité cible de données). En d'autres termes, alors que la quatrième approche connue précitée propose de ne pas encoder une partie des données, en cas de détection d'un dépassement de la mémoire tampon, la présente solution repose sur une suppression de données déjà encodées, en cas de détection d'un dépassement d'une fenêtre d'encodage. Ainsi, la présente solution peut être utilisée même si le dispositif émetteur comprend un encodeur à faible latence. Dans la présente solution, pour effectuer une troncature, on distingue deux instants : un premier instant permettant de détecter un dépassement de la quantité cible associée à une fenêtre d'encodage, et un deuxième instant permettant de décider quel(s) bloc(s) doi(ven)t être coupé(s). Cette décision de troncature est aussi appelée � décision a priori� par la suite. Au contraire, dans la quatrième approche connue précitée, c'est le même instant qui est utilisé pour la détection d'un dépassement de la mémoire tampon et pour la décision de ne pas encoder (et donc supprimer avant encodage) les données qui suivent cet instant. En outre, dans la présente solution, suite à une troncature, on se base sur un troisième instant permettant de décider si au moins une partie de l'excès préalablement tronqué peut remplacer des données de bourrage dans une fenêtre d'encodage suivante. Cette décision de remplacement est aussi appelée � décision finale � par la suite. Aucun mécanisme comparable n'existe dans la quatrième approche connue précitée. Ainsi, des données tronquées d'une fenêtre d'encodage ne sont pas obligatoirement définitivement perdues, puisque dans certains cas elles sont replacées dans une fenêtre d'encodage suivante. La décision finale, portant sur le contenu de la fenêtre d'encodage suivante, permet d'annihiler (au moins en partie) l'impact de la troncature de la fenêtre d'encodage précédente en remplaçant au moins une partie des données de bourrage de la fenêtre d'encodage suivante par les données tronquées de la fenêtre d'encodage précédente. Dans la présente solution, comme l'analyse du taux de remplissage n'est effectuée qu'en fin de fenêtre d'encodage, et non pour chaque bloc, ceci limite la quantité de données à tronquer. Il y a un lissage sur tous les blocs de la fenêtre d'encodage. Ainsi, par exemple, un gros bloc qui serait coupé avec la quatrième approche connue précitée, car provoquant un dépassement de la mémoire tampon, peut ne pas provoquer de coupure avec la présente solution si ce gros bloc est compensé par un ou plusieurs petits blocs de la même fenêtre d'encodage, de sorte que le taux de remplissage de la fenêtre d'encodage reste inférieur ou égal à la quantité cible de la fenêtre d'encodage Dans la présente solution, comme le choix du ou des bloc(s) à couper n'est effectué qu'en fin de fenêtre d'encodage, ceci permet de choisir n'importe quel(s) bloc(s) parmi tous les blocs de la fenêtre d'encodage (comme détaillé par la suite, ce choix peut être effectué en tenant compte de la complexité de chacun des blocs de la fenêtre d'encodage). De façon avantageuse, le dispositif émetteur effectue des étapes consistant à : - placer à la fin de la fenêtre d'encodage donnée, ledit ou un desdits bloc(s) coupé(s) ; - placer au début de la fenêtre d'encodage suivante, au moins une partie d'au moins une portion enlevée du bloc placé à la fin de la fenêtre d'encodage donnée. Ainsi, le bloc coupé placé à la fin de la fenêtre d'encodage se recompose automatiquement, et de façon transparente, pour le dispositif récepteur. Il suffit au dispositif récepteur de réordonnancer les blocs qu'il a reçus, par exemple en s'appuyant sur un index de bloc contenu dans chaque délimiteur de bloc qui sépare deux blocs transmis successivement. Avantageusement, ladite quantité en excès est égale audit dépassement détecté. Ainsi, la totalité du dépassement détecté est traité et l'impact de la troncature (avec un ou plusieurs bloc(s) coupé(s)) est limité (voire nul) sur le résultat post-décodage. Selon une caractéristique avantageuse, ladite fenêtre d'encodage suivante est la fenêtre qui suit immédiatement ladite fenêtre d'encodage donnée. Ceci permet de limiter la latence générale du système et ainsi de préserver les ressources mémoire. En effet, si on devait permettre d'attendre plusieurs fenêtres de transmission, il faudrait prévoir une mise en attente systématique d'un temps identique à la réception avant de transmettre les données au décodeur (pour laisser le temps aux données désordonnées d'arriver). De façon avantageuse, la quantité cible donnée est définie par l'équation suivante : Q = N * P * D, avec : - Q la quantité cible donnée ; - N un nombre de blocs compris dans la fenêtre d'encodage donnée ; - P une période bloc possédant une durée prédéterminée ; - D un débit constant assuré par un canal de transmission entre le dispositif émetteur et le dispositif récepteur. Ceci permet de déterminer aisément la quantité cible associée à chaque fenêtre d'encodage. Avantageusement, sur détection du dépassement, le dispositif émetteur effectue une étape consistant à augmenter un taux de compression appliqué par l'encodeur. De cette façon, on réduit la quantité de données utiles des blocs des fenêtres d'encodage qui suivent (ce qui revient à augmenter la quantité de données de bourrage que nécessiteraient ces fenêtres d'encodage suivantes pour atteindre leurs quantités cibles associées), et on augmente donc les chances de pouvoir placer des données tronquées. Dans une application particulière, les données transmises sont des données vidéo, et en ce que chaque bloc est une tuile de données comprenant un nombre prédéterminé de lignes de données. Il est cependant évident que d'autres types de blocs peuvent être envisagés sans sortir du cadre de la présente invention. Avantageusement, l'étape consistant à choisir et enlever au moins une portion d'au moins un bloc coupé comprend des étapes consistant à : - obtenir des informations de complexité des blocs compris dans la fenêtre d'encodage donnée; - sélectionner le(s) bloc(s) coupé(s), en fonction des informations de complexité obtenues. Ainsi, on optimise le choix du ou des bloc(s) à couper, parmi tous les blocs de la fenêtre d'encodage de données. 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, transmettant des données vers un dispositif récepteur, le dispositif émetteur comprenant un encodeur fournissant des données utiles sous forme de blocs. Le dispositif émetteur comprend : - des moyens de fenêtrage, permettant d'organiser les blocs en fenêtres d'encodage, chaque fenêtre d'encodage comprenant un ensemble déterminé de bloc(s) et étant associée à une quantité cible de données ; - des moyens de gestion de la transmission, comprenant : * des moyens permettant de détecter, pour un ensemble de bloc(s) compris dans une fenêtre d'encodage donnée, un dépassement de quantité de données utiles par rapport à une quantité cible donnée associée à la fenêtre d'encodage donnée; * des moyens permettant de déterminer une quantité en excès liée au dépassement détecté ; * des moyens permettant choisir et enlever au moins une portion d'au moins un bloc, dit bloc(s) coupé(s), parmi ledit ensemble de blocs, pour obtenir un ensemble modifié, la quantité de données comprises dans la ou les portion(s) enlevée(s) du ou des bloc(s) coupé(s) étant supérieure ou égale à la quantité en excès déterminée ; * des moyens permettant de transmettre, au cours d'une période de transmission, ledit ensemble modifié ; * des moyens permettant de détecter une fenêtre d'encodage suivante nécessitant des données de bourrage pour obtenir une quantité cible associée à la fenêtre d'encodage suivante, en complément des données utiles du ou des blocs compris dans la fenêtre d'encodage suivante ; * des moyens permettant de transmettre, au cours d'une période de transmission suivante, au moins une partie de la ou les portion(s) enlevée(s), à la place d'au moins une partie des données de bourrage. 25 Avantageusement, le dispositif émetteur comprend des moyens de mise en oeuvre des étapes du procédé de transmission 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 30 la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : 10 15 20 • la figure 1 présente un exemple de système de communication entre un noeud émetteur et un noeud récepteur, qui implémente, côtés émission et réception, des mécanismes selon un mode de réalisation particulier de l'invention ; • la figure 2 décrit un mode de réalisation particulier d'une table de configuration de tuiles (après encodage), manipulée par le noeud émetteur de la figure 1 lors de la formation de fenêtres d'encodage; • la figure 3 présente un mode de réalisation particulier de l'algorithme, implémenté au sein d'un module de fenêtrage 106 (compris dans le noeud émetteur de la figure 1), pour l'agrégation de tuiles encodées en fenêtres d'encodage; • la figure 4a présente un mode de réalisation particulier de l'algorithme effectué par un module de gestion de la transmission 108 (compris dans le noeud émetteur de la figure 1), pour la gestion des données en excès ; • la figure 4b présente un mode de réalisation particulier de l'algorithme effectué par un module de gestion de la transmission 108 (compris dans le noeud émetteur de la figure 1), pour la transmission des données vers le noeud récepteur ; • la figure 5 présente un mode de réalisation particulier de l'algorithme effectué par un module de gestion de la réception 118 (compris dans le noeud récepteur de la figure 1), pour la gestion des tuiles avant décodage ; et • la figure 6 illustre, à titre pédagogique, le principe d'un mode de réalisation particulier de l'invention, à travers un exemple d'une séquence de fenêtres d'encodage 6. DESCRIPTION DÉTAILLÉE La figure 1 présente un exemple de système de communication entre deux noeuds, qui implémente, côtés émission et réception, des mécanismes selon un mode de réalisation particulier de l'invention. Il s'agit d'un système de communication vidéo temps réel entre un noeud émetteur (aussi appelé noeud producteur) 130 et un noeud récepteur (aussi appelé noeud consommateur) 131, connectés au travers d'un canal de transmission synchrone 116 à accès multiplexé suivant un mode de multiplexage du type TDMA (pour � Time Division Multiple Access � en anglais, et � accès multiple à répartition dans le temps � en français). Le noeud émetteur 130 est connecté en entrée à une application génératrice de données vidéo brutes, au travers de l'interface Video_in 102, et en sortie au canal de transmission 116, au travers de l'interface D_out 109. Le noeud émetteur 130 comprend : • un encodeur vidéo intra 101, destiné à réduire le débit applicatif par compression, à hauteur de la capacité de débit du canal de transmission synchrone 116. L'encodeur 101 effectue un traitement de compression par bloc de données, par exemple par tuile, une tuile correspondant à un nombre prédéfini de Macro-blocs générés par l'application. L'encodeur produit alors des données utiles, c'est-à-dire des Macro-blocs compressés et les fournit à un module de gestion de transmission 108 au travers de l'interface MB Data in 105 ; • un module de fenêtrage 106, destiné à organiser, sous forme de fenêtres d'encodage, l'agrégation des tuiles compressées en sortie de l'encodeur 101. L'algorithme de traitement de ce module 106 est décrit ci-dessous en relation avec la figure 3 ; • un module de gestion de la transmission 108 (ou gestionnaire d'émission), dont l'algorithme de traitement est décrit ci-dessous en relation avec la figure 4a ; le module de gestion de la transmission 108 dispose d'une voie de retour vers l'encodeur vidéo-intra 101 au travers d'une interface Ctrl 126 ; • une première unité de stockage 112 dont l'accès se fait au travers de l'interface E_Data 110, contenant la quantité de données encodées dont la transmission sur une durée correspondant à une fenêtre d'encodage est garantie ; • une seconde unité de stockage 113 dont l'accès se fait au travers de l'interface Tr_Data 111, contenant la quantité de données encodées (appelées données encodées tronquées, ou encore données en excès, par la suite) dont la transmission à l'échelle d'une fenêtre de transmission excède la quantité de données nominale d'une fenêtre de transmission après encodage ; • une troisième unité de stockage 107, dont l'accès se fait au travers l'interface MB_Cpl_out 115, contenant les paramètres de complexités des Macro-blocs au cours de leur encodage par l'encodeur 101. Le noeud récepteur 131 est connecté en sortie du canal de transmission 116, au 5 travers de l'interface D_in 117, et à une application consommatrice de données vidéo brutes, au travers de l'interface Video_out 124. Le noeud 131 comprend : • un décodeur vidéo intra 123, destiné à reconstituer les données vidéo compressées issues du module de gestion 118 ; • un module 118 de gestion de la réception (ou gestionnaire de réception) des données issues du canal de transmission 116, responsable de la réorganisation des tuiles avant décodage par le décodeur 123. L'algorithme de traitement du module 118 est décrit ci-dessous en relation avec la figure 5 ; • une unité de stockage 121, contenant la quantité de données issues du canal de transmission 116 après traitement par le module de gestion 118. Le module de fenêtrage 106 et le module de gestion de la transmission 108, compris dans le noeud émetteur 130, ainsi que le module de gestion de la réception 118, compris dans le noeud récepteur 131, 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 20 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 où d'une réalisation d'un module sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) 25 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. La figure 2 décrit un mode de réalisation particulier d'une table de configuration de tuiles (après encodage), manipulée par le noeud émetteur lors de la formation de 30 fenêtres d'encodage. Cette table est accédée en écriture par le module de fenêtrage 106 10 15 (voir figure 1), et en écriture/lecture par le module de gestion de la transmission 108 (voir figure 1). Elle est organisée de la façon suivante, pour chaque ligne correspondant à une tuile donnée encodée par l'encodeur 101 (voir figure 1) : • la première colonne 201 contient l'index de la tuile donnée ; • la deuxième colonne 202 contient la taille en octets de la tuile donnée ; • la troisième colonne 203 indique la quantité de données transmise en octets pour la tuile donnée ; • la quatrième colonne 204 indique la quantité de données en excès, par rapport à la taille de la fenêtre d'encodage associée, pour la tuile donnée ; • la cinquième colonne 205 indique le nombre de données de bourrage (� padding � en anglais), à la fin de la tuile donnée, par rapport à la frontière de la fenêtre d'encodage associée ; • la sixième colonne 206 indique la structure des données transmises, pour la tuile donnée, en fonction des paramètres des colonnes 203 à 205 ; • la septième colonne 207 indique la fenêtre d'encodage à laquelle appartient la tuile donnée. Cette septième colonne renseigne donc sur l'agrégation, en fenêtres d'encodage, opérée sur les tuiles compressées. L'exemple de la figure 2 illustre les résultats des algorithmes de traitements effectués par les modules 106 et 108 de la figure 1, pour les 10 tuiles K+6 à K+15, et pour une capacité de débit du canal de transmission égale à 100 octets en valeur nominale par tuile compressée. Ces algorithmes sont ultérieurement détaillés au travers des figures 3 et 4. Les tuiles K+6 à K+8 sont agrégées au sein de la fenêtre d'encodage N, de taille 3 (exprimée en nombre de tuiles). La capacité de transmission pour cette fenêtre d'encodage est donc de 300 octets. Compte tenu du fait que la somme des tailles des tuiles K+6 à K+8 atteint 280 octets, un bourrage de 20 octets sera effectué en fin de transmission de la fenêtre d'encodage N, c'est-à-dire en fin de tuile K+8, afin de rendre équivalentes la durée de transmission des tuiles K+6 à K+8, et la durée nominale de trois tuiles. Cela permet donc de conserver l'aspect synchrone du transport en ne commençant pas le transport de K+9 avant le moment prévu. A la fin de la transmission d'une tuile, le délimiteur de tuile est inséré, qui contient : • l'index de la tuile suivante ; • le nombre de Macro-blocs présents dans la tuile courante ; • la quantité de données de bourrage présentes en fin de tuile courante. Il est à noter que la tuile courante correspond à la tuile précédant le délimiteur alors que la tuile suivante correspond à la tuile suivant le délimiteur. Les tuiles K+9 à K+12 sont agrégées au sein de la fenêtre d'encodage N+1, de taille 4. La capacité de transmission de cette fenêtre d'encodage est donc de 400 octets. Compte tenu du fait que la somme des tailles des tuiles K+9 à K+12 atteint 440 octets, un excédent de 40 octets est identifié. On suppose que cet excédent est choisi parmi les données placées en fin de tuile K+11, au regard des informations de complexité des tuiles préalablement mémorisées dans l'unité de stockage 107. Il est à noter que l'accès à ces informations de complexité se fait au travers l'interface MB_Cpl_out 115. Cet excédent de données (aussi appelé � quantité de données tronquées �) n'est pas transmis au cours de la transmission de la fenêtre d'encodage N+1. Avantageusement, la tuile tronquée K+11 est transmise en dernière position au cours de la transmission de la fenêtre d'encodage N+1, sans délimiteur, en vue d'autoriser la transmission ultérieure de l'excédent de données (non transmis au cours de la transmission de la fenêtre d'encodage N+1), lors de la transmission de la fenêtre d'encodage N+2, en fonction des caractéristiques des tuiles encodées suivantes, associée à la formation de la fenêtre d'encodage N+2. Le délimiteur séparant la tuile K+11 (tronquée ou pas) et la tuile K+13 est transmis lors de la transmission de la fenêtre d'encodage N+2. Les informations de ce délimiteur sont mises à jour en fonction des possibilités de transmission de la partie tronquée lors de la fenêtre d'encodage N+2. La fenêtre d'encodage suivante N+2 de taille 3 est avantageusement constituée de façon à profiter de la quantité nominale correspondante au regard de la taille des tuiles K+13 à K+15, et de la quantité de données non transmise au cours de la transmission de la fenêtre d'encodage précédente N+1. Ainsi, la quantité de données tronquées (40 octets) de la tuile K+11 est transmise en début de transmission de la fenêtre d'encodage N+2, préalablement à la transmission des données de la tuile K+13, ce qui rend transparent pour le noeud récepteur 131, la segmentation des données de la tuile K+11 sur la transmission des deux fenêtres d'encodage N+1 et N+2. Pour compléter la quantité de données nominale de la fenêtre d'encodage N+2, 10 octets de bourrage sont insérés en fin de tuile K+15. Au niveau du noeud récepteur 131, les tuiles issues du canal de transmission 116 sont réordonnancées par le module 118, en fonction du contenu des délimiteurs de tuiles, avant d'être présentées au décodeur 123. La figure 3 présente un mode de réalisation particulier de l'algorithme, implémenté au sein du module de fenêtrage 106 (compris dans le noeud émetteur 130), qui permet d'agréger des tuiles encodées en fenêtres d'encodage. Après une étape d'initialisation 301, on passe à une étape 302 d'attente du prochain évènement de fin de tuile compressée (� New_tile �) 104 issu du module d'encodage 101. Durant cette attente, et dans une étape 303, la taille de la tuile en cours est analysée et les informations de complexité (� MB_Cpl_in �) 103 associées aux Macroblocs de la tuile en cours sont enregistrées dans la mémoire 107. Sur détection de l'évènement de fin de tuile compressée 104, les colonnes 201 (index de tuile) et 202 (taille en octets de la tuile après encodage) de la table de configuration présentée en figure 2 sont renseignées, au cours d'une étape 304. Puis, à l'étape 305, un test est effectué pour décider de la fermeture de la fenêtre d'encodage en cours suite à la réception de la tuile. Cette décision s'appuie par exemple sur le taux de remplissage effectif de la fenêtre d'encodage courante par rapport à la quantité de données nominale calculable au regard de la valeur actuelle de la taille de la fenêtre d'encodage, du nombre de tuiles successives de taille faible, ou du nombre de tuiles successives de taille élevée, ou encore du nombre maximal de tuiles autorisé dans une fenêtre d'encodage. Sur décision de fermeture de fenêtre d'encodage, la colonne 207 (index de fenêtre d'encodage) de la table de configuration présentée en figure 2 est renseignée pour l'ensemble des tuiles appartenant à la même fenêtre d'encodage, au cours d'une étape 306. Puis, un évènement de début de nouvelle fenêtre d'encodage (� New_window �) 114 est généré en direction du module de traitement 108, au cours de l'étape 307, avant de reboucler vers l'état d'attente 302. Dans le cas contraire (pas de décision de fermeture de fenêtre d'encodage), un retour direct vers l'état d'attente 302 est effectué. La figure 4a présente un mode de réalisation particulier de l'algorithme effectué par le module de gestion de la transmission 108 de la figure 1, compris dans le noeud émetteur 130, pour la gestion des données en excès. Après une étape d'initialisation 530, il est procédé dans une étape 307 à l'attente du prochain évènement de début de nouvelle fenêtre d'encodage (� New_window �) 114, issu du module de fenêtrage 106 (voir figure 3). En plus de l'indication de début de nouvelle fenêtre d'encodage W+1, cet événement signale la fin de la construction par le module de fenêtrage 106 d'une fenêtre d'encodage W. Puis, dans l'étape 501, un test est effectué pour vérifier si au moins une tuile appartenant à la fenêtre d'encodage précédente W-1 a été tronquée, en s'appuyant sur le contenu de la colonne 204 dans la table de configuration des tuiles présentée en figure 2. Cas n°1 : si aucune tuile appartenant à la fenêtre d'encodage précédente W-1 n'a été tronquée. Dans ce cas n°1, un test additionnel 502 compare la quantité de données réelle de la fenêtre d'encodage W avec la quantité nominale correspondante, au regard de la taille de la fenêtre d'encodage (exprimée en nombre de tuiles) et du débit du canal de transmission (par exemple 100 octets en valeur nominale par tuile compressée). Sous-cas n°1-1 : si la quantité de données nominale est supérieure ou égale à la quantité de données réelle. Dans ce sous-cas n°1-1, la différence est complétée par des données de bourrage, au cours de l'étape 513 (la quantité de données de bourrage est nulle en cas d'égalité dans le test 502). Dans ces conditions, les données de bourrage seront transmises en fin de dernière tuile lors de la transmission de la fenêtre d'encodage W. La colonne 205 du tableau de configuration des tuiles est mise à jour en conséquence pour notifier la quantité de bourrage en fin de dernière tuile lors de la transmission de la fenêtre d'encodage W. La structure des trames à transmettre 206 pour chacune des tuiles de la fenêtre d'encodage W est mise à jour. En référence à la figure 2, cette situation est illustrée pour la fenêtre d'encodage N, puisque 20 octets de bourrage sont transmis en fin de tuile K+8, dans le cas où la quantité de données nominale pour une tuile est considérée de 100 octets. Puis un retour dans l'attente de l'évènement 307 de début de nouvelle fenêtre d'encodage est opéré. Sous-cas n°1-2 : si la quantité de données nominale est inférieure à la quantité de données réelle. Dans ce sous-cas n°1-2, cela signifie que des données en excès doivent être retirées, a priori parmi au moins une tuile de la fenêtre d'encodage W. En fonction d'une politique prédéterminée de sélection des données en excès, par exemple qui consiste à choisir ces données en fin de tuile la moins complexe (par exemple de taille la plus faible), il est d'abord procédé dans l'étape 505 à la détermination et la sauvegarde des données en excès en question. La sélection des données en excès à tronquer peut s'effectuer en fonction de la quantité de données à effectivement tronquer. Par exemple, pour une quantité de données à tronquer importante, il est préférable de tronquer une faible partie d'une tuile complexe plutôt que plusieurs tuiles faiblement complexes. En effet, l'impact visuel pour l'utilisateur sera moins néfaste si une petite partie localisée de l'image est supprimée plutôt que de grandes zones. Il est également plus simple de reconstruire des portions de l'image avec peu d'erreurs (défaut visuel) à l'aide des données avoisinantes lorsque la partie supprimée est la plus petite possible. En effet, les données avoisinantes sont d'autant plus pertinentes qu'elles sont proches spatialement des données supprimées. Pour la même raison, il peut être intéressant de repartir la troncature sur différentes fins de tuiles afin de répartir les défauts sur les cotés de l'image plutôt que vers le centre. Dans le cas où plusieurs tuiles sont impactées par une troncature, il est nécessaire de choisir pour laquelle nous allons faciliter la reconstruction c'est-à-dire laquelle sera placée en dernière position lors de la transmission de cette fenêtre d'encodage. Pour choisir, on peut, par exemple, s'appuyer sur une information de quantité moyenne de données de bourrage insérée lors de la transmission des fenêtres d'encodage afin de favoriser la reconstruction de la tuile qui a une partie tronquée dont la quantité de données est inférieure à cette quantité moyenne de données de bourrage, et ainsi maximiser les chances de reconstruction transparente. Ensuite, dans l'étape 515 : • la colonne 201 de la table de configuration des tuiles est modifiée de façon à positionner la ou les tuiles tronquées à transmettre en fin de transmission de la fenêtre fenêtre de d'encodage W ; • la colonne 204 de la table de configuration des tuiles est mise à jour pour la ou les tuiles concernées, pour notifier la quantité en excès associée ; • la colonne 206 de la table de configuration des tuiles est mise à jour pour chacune des tuiles de la fenêtre d'encodage W. Ensuite, dans un mode de réalisation préféré, une étape 516 est mise en oeuvre. Dans cette étape 516, le module de gestion de la transmission 108 donne instruction, à l'aide de l'interface 126, à l'encodeur vidéo-intra 101 d'augmenter le taux de compression des données. De cette façon, on réduit la quantité de données utiles des tuiles des fenêtres d'encodage qui suivent (ce qui revient à augmenter la quantité de données de bourrage lors de la transmission des fenêtres d'encodage suivantes), et on augmente donc les chances de pouvoir placer des données tronquées. Ce taux peut ensuite être diminué à nouveau, par exemple après écoulement d'un nombre déterminé de transmission de fenêtres d'encodage. Cette opération peut alors être effectuée sous l'impulsion du module de gestion de la transmission 108 via l'interface Ctrl 216. En référence à la figure 2, cette situation est illustrée pour la fenêtre d'encodage N+1, puisque les 40 derniers octets en excès pour la tuile K+11 ont été isolés. La tuile K+11 est ainsi placée en dernière position lors de la transmission de la fenêtre d'encodage N+1. Puis un retour dans l'attente de l' évènement de début de nouvelle fenêtre d'encodage 114 (étape 307) est opéré. Cas n°2 : si au moins une tuile appartenant à la fenêtre d'encodage précédente W-1 a été tronquée. Dans ce second cas, un test additionnel 503 compare la quantité de données réelle de la fenêtre d'encodage W avec la quantité nominale correspondante, au regard de la taille de la fenêtre d'encodage (exprimée en nombre de tuiles) et du débit du canal de transmission (par exemple 100 octets en valeur nominale par tuile compressée). Sous-cas n°2-1 : si la quantité de données nominale est supérieure ou égale à la quantité de données réelle. Dans ce sous-cas n°2-1, la différence entre la quantité de données nominale et la quantité de données réelle est calculée au cours de l'étape 509. Cette différence est exprimée en quantité de données de bourrage (elle est nulle en cas d'égalité dans le test 503). Puis, un test 510 est effectué pour comparer la quantité de données de bourrage calculée et la quantité de données en excès de la fenêtre d'encodage précédente W-1 (cet excédent a été isolé au cours de l'exécution de l'étape 505 pour la fenêtre d'encodage précédente W-1). Si la quantité de données de bourrage de la fenêtre d'encodage W est supérieure ou égale à la quantité de données en excès de la fenêtre d'encodage W-1, cela signifie que la totalité des données en excès de la fenêtre d'encodage W-1 peuvent être transmises en début de transmission de la fenêtre d'encodage W, ce qui permet de compléter de façon transparente la ou les tuiles tronquées transmises lors de la transmission de la fenêtre d'encodage précédente W-1. En effet, avantageusement, si cette quantité en excès est isolée au niveau d'une tuile particulière de la fenêtre d'encodage W-1 (étape 505 pour la fenêtre d'encodage précédente W-1), puisque cette tuile tronquée est transmise en fin de transmission de la fenêtre d'encodage W-1 (étape 515 pour la fenêtre d'encodage précédente W-1), et sachant que ces données en excès seront transmises en début de transmission de la fenêtre d'encodage W, elles viendront compléter sans protocole supplémentaire la tuile tronquée avant d'insérer le délimiteur de tuile. Dans une étape 512, la quantité de données de bourrage est alors réactualisée, et dans une étape 520, les colonnes 205 et 206 de la table de configuration des tuiles sont mises à jour pour les première et dernière tuiles de la fenêtre d'encodage W : la colonne 205 de la dernière tuile de la fenêtre d'encodage W est modifiée pour tenir compte de l'actualisation de la quantité de données de bourrage ; la colonne 206 de la première tuile de la fenêtre d'encodage W est mise à jour pour indiquer dans la structure de la trame à transmettre pour cette tuile, le nombre de données à transmettre préalablement et correspondant aux données en excès précédemment isolées (dans l'étape 505 pour la fenêtre précédente W-1). En référence à la figure 2, cette situation est illustrée pour la fenêtre d'encodage N+2, puisque les 40 derniers octets en excès pour la tuile K+11 (de la fenêtre d'encodage N+1) ont été en définitif transmis au début de la transmission de la fenêtre d'encodage N+2, avant la tuile K+13, et la quantité de données de bourrage en fin de tuile K+15 (transmise lors de la transmission de la fenêtre d'encodage N+2) a été ramenée à 10 octets au lieu de 50 octets. Puis un retour dans l'attente de l'évènement de début de nouvelle fenêtre d'encodage (étape 307) est opéré. Si la quantité de données de bourrage insérée lors de la transmission de la fenêtre d'encodage W est inférieure à la quantité de données en excès de la fenêtre d'encodage W-1, cela signifie que seule une partie des données en excès peuvent être transmises en début de transmission de la fenêtre d'encodage W (on y met la suite immédiate de ce qui a pu être déjà envoyé lors de la transmission de la fenêtre d'encodage W-1), ce qui permet malgré tout de compléter partiellement et de façon transparente la ou les tuiles tronquées transmises pendant la transmission de la fenêtre d'encodage précédente W-1. Dans une étape 511, la quantité de données de bourrage est alors mise à zéro, et dans l'étape 520, les colonnes respectives 205 et 206 de la table de configuration des tuiles sont mises à jour pour les première et dernière tuiles de la fenêtre d'encodage W. Puis un retour dans l'attente de l'évènement de début de nouvelle fenêtre d'encodage (étape 307) est opéré. Sous-cas n°2-2 : si la quantité de données nominale est inférieure à la quantité de données réelle. Dans ce sous-cas n°2-2, cela signifie qu'il existe également des données en excès dans la fenêtre d'encodage W. Dans ces conditions, les données en excès de la fenêtre d'encodage W-1 sont réellement abandonnées et ne seront pas transmises : dans une étape 504, la colonne 206 de la table de configuration des tuiles est mise à jour pour la ou les tuiles tronquées transmises pendant la transmission de la fenêtre d'encodage précédente W-1. Puis, les étapes 505 et 515 précédemment décrites sont effectuées. Enfin, un retour dans l'attente de l' évènement de début de nouvelle fenêtre d'encodage (étape 307) est opéré. La transmission des trames vers le canal de transmission 116 démarre à l'issue d'une durée d'attente prédéfinie, exprimé en nombre d' évènements New_tile 104, correspondant à la taille maximale autorisée pour la transmission d'une fenêtre d'encodage (exprimée en nombre de tuiles) et représentative de la latence du traitement à l'émission. La figure 4b présente un mode de réalisation particulier de l'algorithme effectué par le module de gestion de la transmission 108 de la figure 1, compris dans le noeud émetteur 130, pour la gestion de la transmission des données sur le canal de transmission 116. Cet algorithme est exécuté en parallèle de celui décrit en relation avec la figure 4a. L'algorithme décrit en relation avec la figure 4a est en charge de préparer les données en vue de leur transmission, alors que l'algorithme de la figure 4b est en charge de la transmission elle-même. Dans une étape 800, l'algorithme est initialisé, et une étape 810 est exécutée, au cours de laquelle l'algorithme se met en attente d'un événement � Transmission _Start� représentatif de l'activation de la transmission des données sur le canal de transmission 116. Sur réception de l'événement � Transmission_Start �, la transmission des données sur le canal de transmission 116 est activée (étape 820). Les données préparées lors de l'exécution de l'algorithme décrit en relation avec la figure 4a sont alors transmises sur le canal de transmission 116 selon une cadence constante prédéfinie. La figure 5 présente un mode de réalisation particulier de l'algorithme effectué par le module de gestion de la réception 118 de la figure 1, compris dans le noeud récepteur 131, pour la gestion des tuiles avant décodage. Après une étape d'initialisation 601, le nombre prédéfini K de Macro-blocs par tuile est mémorisé, ainsi que le nombre prédéfini de tuiles à recevoir avant décodage, dans une étape 602. Puis, dans un état d'attente 603, les données reçues de l'interface 117 (figure 1) sont rangées dans l'unité de stockage 121 jusqu'à réception d'un délimiteur de tuile. Sur réception d'un délimiteur de tuile, les informations contenues dans ce délimiteur permettent de : • mémoriser et mettre à jour, dans l'unité de stockage 121, le nombre de Macro- blocs pour chacune des tuiles ; • réordonnancer le stockage des tuiles dans l'unité de stockage 121, pour garantir un décodage ordonné des tuiles ; • supprimer les données de bourrage le cas échéant. Puis un retour est systématiquement effectué vers l'état d'attente 603, et en parallèle un test 605 est effectué pour vérifier si le nombre de tuiles reçues est inférieur à la consigne Wmax. Si le nombre de tuiles reçues est inférieur à la consigne Wmax, un retour vers l'étape de test 605 est opéré. Dès que le nombre de tuiles reçues est supérieur ou égal à la consigne Wmax, le décodage est initialisé en générant, pour la tuile placée en première position dans l'unité de stockage : • dans une étape 606, un évènement de début de décodage (� Start _decode �) 120 (voir figure 1) ; • dans une étape 607, un évènement � Nb MB � 125 (voir figure 1), représentatif du nombre de Macro-blocs de la tuile. A partir de cet instant, le décodage de chaque nouvelle tuile est déclenché sur détection d'un évènement interne � Période tuile � (étape 608) représentatif de la période tuile. La figure 6 illustre, à titre pédagogique, le principe d'un mode de réalisation particulier de l'invention, à travers un exemple d'une séquence de fenêtres d'encodage. La figure 6 se décompose en une partie haute et une partie basse, référencées 720 et 730 respectivement. La partie haute 720 de la figure 6 représente le processus d'encodage des différentes tuiles (701,...,708) au cours du temps. Les tuiles encodées sont regroupées par fenêtre d'encodage : chaque fenêtre d'encodage comprend un nombre prédéterminé de tuiles encodées (dans cet exemple, le nombre de tuiles encodées par fenêtre d'encodage est de 4 ; il pourrait cependant être variable d'une fenêtre d'encodage à l'autre). La partie haute 720 représente également la comparaison entre la quantité de données contenues dans une fenêtre d'encodage et une bande passante disponible pour le transport de chaque fenêtre d'encodage sur le réseau (comparaison avec un seuil maximal Smax sur la figure 6). Il est à noter que cette comparaison n'est effectuée qu'en fin de fenêtre d'encodage et non pour chaque fin de tuile encodée, ce qui limite déjà la quantité de données à tronquer. La partie basse 730 de la figure 6 représente le processus de transport des fenêtres d'encodage, et plus précisément : i) la période de transmission des fenêtres d'encodage N (740) et N+1 (741) obtenues en tenant compte seulement de premières décisions, appelées ci-après � décisions a priori �, prises chacune à la fin d'une fenêtre d'encodage donnée; ii) la période de transmission des fenêtres d'encodage N (742) et N+1 (743) obtenues en tenant compte en outre de deuxièmes décisions, appelées ci-après � décisions finales �, prises chacune à la fin d'une fenêtre d'encodage qui suit une fenêtre d'encodage donnée, concernant une partie de tuile encodée tronquée (s'il y en a une) résultant d'une décision a priori prise à la fin de la fenêtre d'encodage donnée. Dans l'exemple de la figure 6, la ligne référencée 730a représente la transmission des fenêtres d'encodage N (740) et N+1 (741), obtenues en tenant compte de décisions a priori prises à la fin des fenêtres d'encodage N et N+1, et la ligne référencée 730b représente la transmission des fenêtres d'encodage N (742) et N+1 (743), obtenues en tenant compte des décisions a priori précitées et d'une décision finale prise à la fin de la fenêtres d'encodage N+1. Les transmissions réellement opérées pour transmettre les tuiles encodées sont illustrées au travers des périodes de transmission N et N+1 de la ligne référencée 730b (les périodes de transmission N et N+1 de la ligne référencée 730a étant présentées uniquement pour illustrer les décisions a priori). Il est à noter que dans l'exemple de la figure 6, aucune décision finale n'est vraiment à prendre à la fin de la fenêtre d'encodage N, concernant une éventuelle troncature d'une tuile encodées pendant la fenêtre d'encodage N-1, puisque la quantité de donnée produites pendant la fenêtre d'encodage N est supérieure à la bande passante allouée sur le réseau. Une quantité constante de données est transmise à chaque période réseau (notée � network cycle period �). Le processus d'encodage comprend une suite de fenêtres d'encodage (appelées ci-après � fenêtre d'encodage N �, � fenêtre d'encodage N+1 �, � fenêtre d'encodage N+2 �...). Les tuiles encodées pendant une fenêtre d'encodage donnée sont destinées à être transmises (sauf les parties tronquées, comme détaillé par la suite) pendant une période de transmission équivalente à la durée de la fenêtre d'encodage. Par exemple, les tuiles encodées pendant la fenêtre d'encodage N sont destinées à être transmises (sauf les parties tronquées) pendant la période de transmission N dont la durée est identique à la durée de la fenêtre d'encodage N. Le processus d'encodage, dans la première fenêtre d'encodage N, commence par fournir la tuile encodée 701 à la fin de la première période tuile. Ensuite, dans cette même première fenêtre d'encodage N, le processus fournit successivement les tuiles encodées 702, 703 et 704, à la fin de chaque période tuile. La fin de la période tuile de la tuile encodée 704 correspond également à la fin de la première fenêtre d'encodage N. Les quatre tuiles encodées pendant cette première fenêtre d'encodage N vont ensuite être agrégées pour être transmise au cours de la période de transmission N. A la fin de chaque fenêtre d'encodage d'un nombre prédéterminé de tuiles, le noeud émetteur prend une décision a priori, permettant, par comparaison avec le seuil Smax, d'ajuster la quantité de données produites (c'est-à-dire les tuiles encodées) pendant cette fenêtre d'encodage par rapport à la bande passante réservée pour la transmission de ces tuiles encodées pour cette fenêtre d'encodage. La bande passante réservée est prédéterminée en fonction de la quantité de données moyennes produites pour une tuile. Si la quantité de données produites durant la fenêtre d'encodage est inférieure à la bande passante allouée pour la transmission de cette fenêtre d'encodage, des données de bourrage sont ajoutés en fin de transmission des données utiles de la fenêtre d'encodage. Dans le cas inverse, des données utiles doivent être supprimées de la fenêtre d'encodage, par le noeud émetteur, avant envoi sur le canal de transmission 116. Dans l'exemple de la figure 6, on suppose que la quantité de donnée résultant de la fenêtre d'encodage N (c'est-à-dire la quantité de données obtenues après encodage des tuiles 701 à 704) est supérieure à la bande passante allouée sur le réseau sur la durée de transmission de cette fenêtre d'encodage N. Il faut donc tronquer une partie de l'information à transmettre, c'est-à-dire une partie de la fenêtre d'encodage N. Le choix de la partie à tronquer s'effectue parmi les tuiles encodées composant la fenêtre d'encodage N. Dans notre exemple, la tuile encodée 703 est tronquée afin de diminuer la quantité de données à transmettre. La tuile encodée 703 se décompose alors en deux parties : la partie non tronquée 703a et la partie tronquée 703b). Dans la séquence de transmission des tuiles encodées de la fenêtre d'encodage N (740), la partie non tronquée 703a de la tuile encodée 703 est déplacée afin de l'envoyer à la fin de la transmission de la fenêtre d'encodage N (740). Le processus d'encodage se poursuit pour une nouvelle fenêtre d'encodage : les tuiles encodées 705, 706, 707 et 708 qui en résultent sont agrégées dans la fenêtre d'encodage N+1. Comme pour la fenêtre d'encodage N précédente, une décision a priori est prise concernant la quantité de donnée pouvant être transmise lors de la transmission de la fenêtre d'encodage N+1 (comprenant les tuiles encodées 705, 706, 707 et 708). Dans l'exemple de la figure 6, on suppose que pour cette fenêtre d'encodage N+1, la quantité de données produites est inférieure à la bande passante allouée sur le réseau sur la durée de transmission de cette fenêtre d'encodage N+1. En conséquence, des données de bourrage 710 sont ajoutées à la fin de la transmission de la fenêtre d'encodage N+1 (741). La partie 730a de la figure 6 représente la transmission des fenêtres d'encodage N (740) et N+1 (741), basées chacune sur la décision a priori prise à la fin de la fenêtre d'encodage correspondante (fenêtre d'encodage N et N+1 respectivement). En outre, une décision finale est prise à la fin de chaque fenêtre d'encodage qui suit une fenêtre d'encodage donnée, concernant une partie de tuile tronquée (s'il y en a une) résultant d'une décision a priori prise à la fin de la fenêtre d'encodage donnée. Dans l'exemple de la figure 6, à la fin de la fenêtre d'encodage N+1, une décision finale est prise concernant la partie tronquée 703b de la tuile encodée 703 (cette troncature résultant de la décision a priori prise à la fin de la fenêtre d'encodage N). Cette décision finale tient compte de la quantité de données produite pendant la fenêtre d'encodage N+1, pour savoir si la partie tronquée 703b (à la fin de la fenêtre d'encodage N précédente) peut être transmise sur la durée de la transmission de la fenêtre d'encodage N+1. Dans notre exemple, à la fin de la fenêtre d'encodage N+1, la décision a priori indique au système de rajouter des données de bourrage 710 lors de la transmission de la fenêtre d'encodage N+1, de façon à ajuster la durée de transmission de la fenêtre d'encodage N+1 à la durée de la fenêtre d'encodage N+1. La décision finale prise à la fin de cette fenêtre d'encodage N+1, quand à elle, remplace une partie de ces données de bourrage 710 par la partie tronquée 703b de la tuile encodée 703. Cette partie tronquée 703b de la tuile encodée 703 est transmise au début de transmission de la fenêtre d'encodage N+1 (743). Ainsi, comme la partie non tronquée 703a de la tuile encodée 703 a été transmise en dernière position lors de la transmission de la fenêtre d'encodage N (742), la tuile encodée 703 se recompose automatiquement, et de façon transparente, pour le récepteur. Ensuite, également lors de la transmission de la fenêtre d'encodage N+1 (743), les tuiles encodées 705, 706, 707 et 708 sont transmises. Puis, une nouvelle quantité de données de bourrage 711 est calculée et transmise en fin de transmission de la fenêtre d'encodage N+1 (743). La nouvelle quantité de données de bourrage correspond à la différence entre la quantité de données de bourrage originelle 710 (calculée lors de la décision a priori prise à la fin de la période d'encodage N+1) et la partie 703b de la tuile encodée tronquée 703 (cette troncature résultant de la décision a priori prise à la fin de la fenêtre d'encodage N). La décision finale prise à la fin de la fenêtre d'encodage N+1 a donc permis d'annihiler (en totalité dans cet exemple, au moins en partie dans le cas général) l'impact de la troncature de la fenêtre d'encodage N, en remplaçant une partie des données de bourrage à insérer lors de la transmission de la fenêtre d'encodage N+1 par la partie tronquée 703b (appartenant à la tuile encodée 703) de la fenêtre d'encodage N. 15 20 25 REVENDICATIONS1. Procédé de transmission de données entre un dispositif émetteur (130) et un dispositif récepteur (131), le dispositif émetteur comprenant un encodeur (101) fournissant des données utiles sous forme de blocs (701 à 708), ledit procédé étant caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : - organiser (302 à 307) les blocs en fenêtres d'encodage, chaque fenêtre d'encodage comprenant un ensemble déterminé de bloc(s) et étant associée à une quantité cible de données ; - détecter (502), pour un ensemble de bloc(s) compris dans une fenêtre d'encodage donnée, un dépassement de quantité de données utiles par rapport à une quantité cible donnée associée à la fenêtre d'encodage donnée ; - déterminer (505) une quantité en excès liée au dépassement détecté ; - choisir et enlever (515) au moins une portion (703b) d'au moins un bloc (703), dit bloc(s) coupé(s), parmi ledit ensemble de bloc(s), pour obtenir un ensemble modifié, la quantité de données comprises dans la ou les portion(s) enlevée(s) du ou des bloc(s) coupé(s) étant supérieure ou égale à la quantité en excès déterminée ; - transmettre (820), au cours d'une période de transmission, ledit ensemble modifié ; - détecter (503, 509) une fenêtre d'encodage suivante (743) nécessitant des données de bourrage (710) pour obtenir une quantité cible associée à la fenêtre d'encodage suivante, en complément des données utiles du ou des blocs compris dans la fenêtre d'encodage suivante ; - transmettre (820), au cours d'une période de transmission suivante, au moins une partie de la ou les portion(s) enlevée(s), à la place d'au moins une partie des données de bourrage. 2. Procédé selon la revendication 1, caractérisé en ce que le dispositif émetteur effectue des étapes consistant à : - placer à la fin de la fenêtre d'encodage donnée (742), ledit ou un desdits bloc(s) 30 coupé(s) (703) ;- placer au début de la fenêtre d'encodage suivante (743), au moins une partie d'au moins une portion (703b) enlevée du bloc placé à la fin de la fenêtre d'encodage donnée. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite quantité en excès (703b) est égale audit dépassement détecté. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite fenêtre d'encodage suivante (743) est la fenêtre qui suit immédiatement ladite fenêtre d'encodage donnée (742). 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la quantité cible donnée est définie par l'équation suivante : Q = N * P * D, avec : - Q la quantité cible donnée ; - N un nombre de blocs compris dans la fenêtre d'encodage donnée ; - P une période bloc possédant une durée prédéterminée ; - D un débit constant assuré par un canal de transmission entre le dispositif émetteur et le dispositif récepteur. 10. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, sur détection du dépassement, le dispositif émetteur effectue une étape consistant à augmenter (516) un taux de compression appliqué par l'encodeur. 11. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que les données transmises sont des données vidéo, et en ce que chaque bloc est une tuile de données comprenant un nombre prédéterminé de lignes de données. 12. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'étape consistant à choisir et enlever au moins une portion d'au moins un bloc coupé comprend des étapes consistant à : - obtenir des informations de complexité des blocs compris dans la fenêtre d'encodage donnée; - sélectionner le(s) bloc(s) coupé(s), en fonction des informations de complexité obtenues. 9. 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 à 8, lorsque ledit programme est exécuté sur un ordinateur. 10 15 20 25 3010. 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 à 8. 11. Dispositif émetteur (130), transmettant des données vers un dispositif récepteur (131), le dispositif émetteur comprenant un encodeur (101) fournissant des données utiles sous forme de blocs (701 à 708), ledit dispositif émetteur étant caractérisé en ce qu'il comprend : - des moyens de fenêtrage (106), permettant d'organiser les blocs en fenêtres d'encodage, chaque fenêtre d'encodage comprenant un ensemble déterminé de bloc(s) et étant associée à une quantité cible de données ; - des moyens de gestion de la transmission (108), comprenant : * des moyens permettant de détecter, pour un ensemble de bloc(s) compris dans une fenêtre d'encodage donnée, un dépassement de quantité de données utiles par rapport à une quantité cible donnée associée à la fenêtre d'encodage donnée; * des moyens permettant de déterminer une quantité en excès liée au dépassement détecté ; * des moyens permettant choisir et enlever au moins une portion (703b) d'au moins un bloc (703), dit bloc(s) coupé(s), parmi ledit ensemble de blocs, pour obtenir un ensemble modifié, la quantité de données comprises dans la ou les portion(s) enlevée(s) du ou des bloc(s) coupé(s) étant supérieure ou égale à la quantité en excès déterminée ; * des moyens permettant de transmettre, au cours d'une période de transmission, ledit ensemble modifié ; * des moyens permettant de détecter une fenêtre d'encodage suivante (743) nécessitant des données de bourrage (710) pour obtenir une quantité cible associée à la fenêtre d'encodage suivante, en complément des données utiles du ou des blocs compris dans la fenêtre d'encodage suivante ; * des moyens permettant de transmettre, au cours d'une période de transmission suivante, au moins une partie de la ou les portion(s) enlevée(s), à la place d'au moins une partie des données de bourrage.