Brevet FR2937820A1 — publié le 20100430

La présente invention concerne un procédé d'adaptation de débit dans un appareil de génération d'un flux de données vidéo et plus particulièrement dans un encapsulateur IP de flux. Ce flux pouvant être, par exemple à la norme DVB-H (Digital Video Broadcasting û Handheld en anglais) défini dans le document "ETSI EN 302 304, DVB-H - Transmission System for Handheld Terminals". Un système de génération de flux DVB-H est illustré Fig. 1. Sur cette figure on voit un ensemble d'encodeurs 1.1, 1.2 et 1.3. Ces encodeurs sont chargés d'encoder des services, généralement de la vidéo. Chaque encodeur encode un service et envoie ce service encodé sous la forme d'un flux de paquets IP (Internet Protocol en anglais). L'encapsulateur IP 1.4, ou IPE (IP Encapsulator en anglais) reçoit tous ces flux et est chargé d'en faire un flux DVB-H conformé en salves (burst en anglais). Ce flux de sortie 1.5 contient l'ensemble des flux d'entrée sous la forme de sections MPE (Multi Protocol Encapsulation en anglais défini par la norme EN 301 192). Pour constituer ce flux de sortie, il est nécessaire de générer des sections dites FEC (Forward Error Correction en anglais) contenant des données de redondance servant à corriger des erreurs de transmission. Le flux de sortie est affecté d'un débit maximum. Généralement, on cherche à optimiser l'utilisation de ce débit maximum disponible en multiplexant le maximum de services possibles. L'encapsulateur IP est capable de générer un flux ayant un débit inférieur ou égal à ce débit maximum théorique. Lorsque le débit utile est inférieur, des données de bourrage sont introduites dans le flux généré 1.5. Les encodeurs 1.1, 1.2 et 1.3 peuvent fonctionner selon deux modes de compression différents. Ils peuvent fonctionner en mode CBR (Constant Bit Rate en anglais) c'est-à-dire qu'ils compressent le service à débit constant. Ils peuvent également fonctionner en mode VBR (Variable Bit Rate en anglais) c'est-à-dire que dans ce mode le débit instantané de compression varie dans le temps en fonction de la complexité instantanée de l'information à compresser, le débit moyen à observer étant fixé. Des solutions permettant de contrôler un ensemble d'encodeurs fonctionnant en mode VBR pour produire un ensemble de flux dont la somme des débits est constante existent et ne seront pas décrites ici. Donc, que l'on utilise des encodeurs en mode CBR ou VBR, on maîtrise le débit total de l'ensemble des flux issus de ces encodeurs. C'est ce débit que l'on cherche à fixer au plus prêt du débit permettant d'obtenir en sortie de l'encapsulateur le débit maximum théorique. La transmission des flux entre les encodeurs (1.1, 1.2, 1.3) et l'IPE (1.4) peut se faire à l'aide de divers liens. On peut citer les liens ASI (Asynchronous Serial Interface en anglais) encore très utilisés. Ces liens ont l'avantage de transmettre les données à un débit garanti. Il est de plus en plus courant d'utiliser pour ces transmissions des liens IP (Internet Protocol en anglais défini par la RFC 791) qui offrent l'avantage d'être très répandus et donc d'utiliser des appareils et des matériaux bon marché. D'autre part, ces liens IP permettent des connexions sur de grandes distances en empruntant des réseaux existants comme Internet. Grâce à l'utilisation de ces liens, il est possible de répartir les encodeurs et l'IPE géographiquement de manière souple. Par contre, l'inconvénient des transmissions sur réseaux IP est l'introduction de gigue de transmission (jitter en anglais). Cette gigue se traduit par une distribution aléatoire du débit instantané de transmission autour d'une valeur moyenne. Elle a pour résultat dans le système de transmission décrit que le débit instantané des données arrivant en entrée de l'IPE subit des variations aléatoires dues à la transmission sur réseau IP. Ces variations aléatoires, d'autant plus que le débit des flux des services est calculé comme très proche du débit maximum théorique, amènent ce débit instantané à présenter des pics pouvant être supérieurs à ce débit maximum théorique. Ces pics sont difficiles à traiter, car on ne peut pas se permettre ni de perdre des données ni de retarder l'émission des paquets du fait des informations temporelles de rendu contenues dans ces paquets. L'invention vise à résoudre ce problème en proposant un procédé d'adaptation du débit d'entrée de l'IPE. Ce procédé est basé sur un calcul prédictif du débit effectif de sortie de l'IPE en fonction des données reçues et sur un jeu sur les tampons utilisés pour le calcul des codes correcteurs d'erreurs au sein de l'IPE. Elle offre l'avantage de ne pas introduire de latence supplémentaire dans le fonctionnement de l'IPE et de ne pas nécessiter de modifier les informations temporelles de rendu des paquets. L'invention concerne un procédé d'adaptation de débit dans un appareil de génération d'un flux de données vidéo comprenant une pluralité d'entrées, chacune de ces entrées permettant la réception d'un flux de données composé de paquets IP, chacun de ces flux étant traité par un module de calcul de codes correcteurs composé d'au moins un tampon de réception, d'un tampon de calcul et d'un tampon de sortie fonctionnant en parallèle, une période étant définie, qui comprend lors de la réception d'un nouveau paquet de données sur une des entrées une étape de calcul de la taille des données de sortie qui seront générées par l'ensemble des paquets de données reçus lors de la période courante ; une étape de comparaison de cette taille calculée avec un seuil et lorsque cette taille calculée est supérieure au seuil, une étape visant à intégrer le dernier paquet reçu qui provoque le dépassement du seuil et les paquets suivants dans les données reçues à la période suivante. Selon un mode particulier de réalisation de l'invention, l'étape visant à intégrer le dernier paquet reçu qui provoque le dépassement du seuil et les paquets suivants dans les données reçues à la période suivante consiste en une bascule des tampons de réception de tous les modules de calcul de codes correcteurs sur un tampon de réserve disponible au sein de chaque module qui devient alors le tampon de réception. Selon un mode particulier de réalisation de l'invention, le calcul de la taille des données de sortie générées par l'ensemble des paquets de données reçus lors de la période courante comprend une étape de calcul du nombre de paquets FEC correspondant à ces paquets reçus et leur taille ; une étape de calcul de la taille des en-têtes MPE correspondant aux paquets de données reçus et aux paquets FEC et une étape de calcul de la taille des en-têtes des paquets TS qui seraient générés pour la transmission de ces sections données et FEC. Selon un mode particulier de réalisation de l'invention, lors de l'étape de calcul de la taille des données de sortie, on maintient pour chaque service le nombre de paquets reçus et la somme des tailles de ces paquets reçus pour la période, le calcul comprenant alors une étape où l'on calcule la contribution du service auquel appartient le paquet reçu, avec et sans ce paquet reçu ; une étape de mise à jour des données mémorisées pour ce service compte tenu de ce paquet reçu et une étape où l'on ajoute à la taille totale des données générées la différence entre les deux calculs. Selon un mode particulier de réalisation de l'invention, lors de l'étape de calcul de la taille des données de sortie, on calcule le débit généré par la taille des données calculées, et où l'étape de comparaison consiste à comparer ce débit à un seuil correspondant au débit maximum théorique. Selon un mode particulier de réalisation de l'invention, lors de l'étape de calcul de la taille des données de sortie, on compare cette taille avec celle engendrée par le débit maximum théorique sur la période. Selon un mode particulier de réalisation de l'invention, on établit le seuil en nombre de paquets TS par période et dans ce cas on exprime la taille calculée en nombre de paquets TS générés par l'ensemble des paquets IP reçus. L'invention concerne également un appareil de génération d'un flux de données vidéo comprenant une pluralité d'entrées, chacune de ces entrées permettant la réception d'un flux de données composé de paquets IP ; une pluralité correspondante de modules de calcul de codes correcteurs pour traiter ces flux, chaque module étant composé d'au moins un tampon de réception, d'un tampon de calcul et d'un tampon de sortie fonctionnant en parallèle et, une période étant définie, caractérisé en ce qu'il comprend en outre des moyens pour, lors de la réception d'un nouveau paquet de données sur une des entrées, calculer la taille des données de sortie qui seront générées par l'ensemble des paquets de données reçus lors de la période courante ; comparer cette taille calculée avec un seuil et lorsque cette taille calculée est supérieure au seuil, intégrer le dernier paquet reçu qui provoque le dépassement du seuil et les paquets suivants dans les données reçues à la période suivante. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : La Fig. 1 illustre l'architecture d'un système de génération de flux DVB-H ; La Fig. 2 illustre un exemple de réalisation d'un IPE ; La Fig. 3 illustre les tampons utilisés dans un exemple de réalisation de l'invention ; La Fig. 4 illustre l'organigramme du procédé selon un exemple de réalisation de 25 l'invention. La Fig. 2 illustre l'architecture typique d'un IPE 1.4. Cet appareil dispose d'une pluralité d'entrées. Chacune de ces entrées permet la réception d'un flux de données en provenance d'un encodeur. Typiquement chacun de ces flux correspond à un service. Ces données sont reçues sous la forme de paquets de données IP et traités par 30 des modules de calcul de codes correcteurs d'erreurs 2.1, 2.2 et 2.3. Ces modules sont chargés du calcul des codes correcteurs ou FEC. Ce mécanisme de calcul est décrit dans le document ETSI EN 301 192 � Digital Video Broadcasting (DVB) ; DVB specification for data broadcasting � au chapitre 9. I1 consiste à ranger les paquets IP dans une table, verticalement à la suite les uns des autres. Ensuite, des informations de correction d'erreurs sont calculées sur les lignes de la table pour créer des colonnes supplémentaires. Ces informations de correction d'erreurs sont alors encapsulées, de même que les paquets IP de la table, dans des sections dites MPE. Ces sections MPEFEC sont transmises dans le flux en sus des sections de données, elles serviront au récepteur pour corriger d'éventuelles erreurs de transmission dans les sections de données. Les sections, données et FEC, calculées par chaque module de calcul des codes correcteurs sont alors multiplexées par le module de multiplexage 2.4 puis découpées et encapsulées dans des paquets de transports appelés paquets TS (Transport Stream en anglais) pour générer le flux de sortie. Le fonctionnement du module de calcul de codes correcteurs est basé sur l'utilisation de trois tampons (buffer en anglais). Un premier tampon de réception sert à stocker les données. Un second tampon de calcul sert au calcul des codes correcteurs et des en-têtes de section MPE. Le troisième tampon de sortie est un tampon où sont lues les données calculées. Ces tampons fonctionnent en parallèle. Pour ce faire, on définit une période temporelle. Cette période est définie par rapport au débit du flux. Il faut qu'elle soit suffisamment petite pour éviter qu'un tampon de réception puisse déborder. Elle est valable pour l'ensemble des modules de calcul des codes correcteurs de l'IPE. Donc sur le temps que dure cette période, le premier tampon est rempli par les données reçues, les données contenues dans le second sont soumises au calcul des informations de correction FEC, tandis que les données du troisième sont consommées par le module de multiplexage 2.4. A la fin de la période, on effectue une rotation de tampon. Le tampon dont les données ont été consommées devient le nouveau tampon de réception pour de nouvelles données. Le tampon, dont les données ont été soumises au calcul de FEC et sont donc prêtes à la consommation, devient le nouveau tampon de sortie. Le tampon de réception devient le tampon de calcul. On voit donc que pendant chaque période on reçoit les données de la période courante, on calcule les informations FEC et MPE des données reçues lors de la période précédente et on multiplexe les données reçues lors de la période encore précédente. Les données sont donc traitées par les modules de calcul de codes correcteurs en temps réel avec une latence de deux périodes. En l'absence de fluctuations des débits d'entrées, les encodeurs sont contrôlés de telle sorte que l'on a en permanence une quantité de données dans les tampons de sortie qui, cumulée, reste inférieure à la quantité de données pouvant être émise par le flux de sortie, au débit de ce flux, pendant la période. Du fait des fluctuations dues à la transmission des flux entrants sur IP, on peut avoir des pics de données et des périodes où l'on se retrouve avec trop de paquets à émettre dans les tampons de sortie. Le procédé d'adaptation de débit proposé est basé sur l'utilisation de tampons de réserve telle qu'illustrée Fig. 3. Sur cette figure, chaque module de calcul de codes correcteurs 3.1 contient les trois tampons déjà décrits 3.2, 3.3 et 3.4. Il comporte en outre un nombre N au moins égal à 1 de tampons de réserve 3.5, 3.6 et 3.7. Ces tampons vont servir à un basculement anticipé du tampon de réception RX en cas de pic de données reçues. L'organigramme d'un exemple de réalisation du procédé est décrit Fig. 4. Le procédé décrit est celui qui s'applique de manière générale pour l'ensemble des modules de calcul de codes correcteurs. En début de période, lors d'une étape 4.1, les tampons devant être utilisés sont initialisés au sein de chaque module. On initialise également à zéro un compteur qui servira à comptabiliser la taille de données de sortie pour la période, c'est-à-dire la taille des données qui seront générées à partir des données reçues dans la période, il s'agit d'un calcul prédictif. Lors d'une étape 4.2, un nouveau paquet de données est reçu sur l'une des entrées de l'IPE. Ce paquet de données est dirigé sur l'un des modules de calcul de codes correcteurs en fonction du service auquel il appartient. Lors d'une étape 4.3, on calcule la taille des données qui seront générées à partir de l'ensemble des données reçues lors de la période. Cette taille des données est calculée à partir des paquets reçus contenus dans chaque tampon de réception. On calcule le nombre de paquets FEC correspondant à ces paquets reçus et leur taille. Pour cela, on considère le calcul tel qu'il aurait lieu si la période était terminée et que les tables de calcul des FEC étaient figées dans l'état courant. On calcule également la taille des en-têtes MPE correspondant aux paquets de données reçus et aux paquets FEC. Enfin, on ajoute la taille des en-têtes des paquets TS qui seraient générés pour la transmission de ces sections données et FEC. On obtient ainsi la taille totale des données qui seraient à émettre à partir des données reçues lors de la période courante si celle-ci se terminait après la réception du dernier paquet et ceci pour l'ensemble des services et donc l'ensemble des modules de calcul de codes correcteurs présents dans l'IPE. Alternativement, pour l'étape de calcul 4.3, on maintient pour chaque service sa contribution au total des données générées pour la période. On mémorise en particulier pour chaque service le nombre de paquets reçus et la taille des données correspondante, c'est-à-dire la somme des tailles de chacun des paquets reçus. On calcule alors la contribution du service sans le paquet reçu et avec le paquet reçu. Ce calcul se fait à l'aide des données mémorisées en y incorporant ou pas les données du paquet reçu. On met ensuite à jour les données mémorisées pour le service. On met à jour également la taille des données de sortie en ajoutant la différence entre les deux calculs, avec et sans le paquet reçu. Ceci évite de devoir recalculer la contribution de chaque service à chaque paquet reçu tout en minimisant la quantité de données à mémoriser. Lors d'une étape 4.4, on teste si la taille calculée de ces données dépasse le seuil constitué par la quantité de données pouvant être émises dans le flux de données de sortie pendant la période au débit maximum théorique de ce flux de sortie. Deux façons de faire ce test peuvent ici être envisagées. On peut d'une part calculer le débit généré par la taille des données calculées. Dans ce cas, le test consiste à comparer ce débit à un seuil correspondant au débit maximum théorique. On peut aussi calculer la taille des données de sortie et la comparer avec celle engendrée par le débit maximum théorique sur la période. Alternativement, on peut aussi établir le seuil en nombre de paquets TS par période et dans ce cas on exprime la taille calculée en nombre de paquets TS générés par l'ensemble des paquets IP reçus. Si ce seuil n'est pas dépassé, on n'a pas encore excédé le débit maximum, on teste alors si la période courante est terminée lors d'une étape 4.6. Si la période n'est pas terminée, on se met en attente du prochain paquet qui sera traité de nouveau par l'étape 4.2. Si la période courante est terminée, on passe sur une étape 4.7 de rotation des tampons. C'est l'opération qui organise la rotation des trois tampons au sein de chaque module. Le tampon de réception devient le tampon de travail, le tampon de travail devient le tampon de sortie et le tampon de sortie devient le tampon de réception. Dans le cas d'un dépassement de seuil lors de l'étape 4.4, on organise une bascule anticipée du tampon de réception lors d'une étape 4.5. Pour cela, le tampon de sortie n'étant pas encore disponible pour servir de nouveau tampon de réception, on utilise un tampon de réserve, 3.5, 3.6 ou 3.7, pour servir de nouveau tampon de réception. Cette bascule est faite pour l'ensemble des modules de manière synchronisée. Le dernier paquet reçu qui a provoqué le dépassement de seuil est alors stocké dans ce nouveau tampon de réception au sein du module correspondant au service auquel il appartient. La réception peut alors continuer comme précédemment en se branchant sur l'étape 4.6 de test de fin de période. Fonctionnellement, cela revient à effectuer une étape visant à intégrer le dernier paquet reçu qui provoque le dépassement du seuil et les paquets suivants dans les données reçues à la période suivante. D'autres moyens pourraient être mis en oeuvre pour arriver à ce résultat. On pourrait, par exemple, intégrer une marque dans les tampons de réception lors de la réception du paquet qui provoque le dépassement et, lors de l'étape de rotation recopier les données à partir de cette marque dans le nouveau tampon de réception et ne pas tenir compte dans le calcul des données au-delà de cette marque. De cette manière, on voit que l'on s'assure que l'ensemble des tampons de réception correspondant à une période donnée contient toujours des données générant un débit de sortie inférieur au débit maximum théorique. Cette bascule anticipée revient à transférer les dernières données reçues lors d'une période donnée parmi les données reçues à la période suivante. On ne perd donc pas de données et l'on respecte les informations temporelles contenues dans les paquets. Il faut noter que lors de la rotation de tampons suivante, donc en fin de la période, les opérations sont légèrement modifiées. Si le tampon de réception, le tampon initial pas le tampon de réserve, devient bien le tampon de calcul et le tampon de calcul devient bien le tampon de sortie, ce n'est plus le tampon de sortie qui devient le tampon de réception, mais le tampon de réserve sur lequel on a déjà basculé en réception. Les données reçues lors de la nouvelle période vont donc venir s'ajouter aux données excédentaires reçues lors de la période précédente. Le tampon de sortie prend alors la place du tampon de réserve. Le fait de prévoir plusieurs tampons de réserve permet de pouvoir faire face à un pic de réception de données important où un deuxième débordement arriverait au 25 cours d'une même période. On voit que cette bascule anticipée peut se renouveler sur plusieurs périodes consécutives. Toutefois, une dérive qui verrait le débit global de réception durablement supérieur au débit de sortie n'est pas possible. Le débit de sortie des encodeurs étant contrôlé de manière à rester au-dessous du débit maximum théorique, 30 les débordements ne peuvent résulter que d'une fluctuation passagère qui sera suivie par une baisse du débit d'entrée. En moyenne celui-ci reste au-dessous du débit maximum théorique. REVENDICATIONS1/ Procédé d'adaptation de débit dans un appareil (1.4) de génération d'un flux de données vidéo comprenant une pluralité d'entrées, chacune de ces entrées permettant la réception d'un flux de données composé de paquets IP, chacun de ces flux étant traité par un module (2.1, 2.2 et 2.3) de calcul de codes correcteurs composé d'au moins un tampon de réception (3.2), d'un tampon de calcul (3.3) et d'un tampon de sortie (3.4) fonctionnant en parallèle, une période étant définie, caractérisé en ce qu'il comprend lors de la réception d'un nouveau paquet de données sur une des entrées : - une étape (4.3) de calcul de la taille des données de sortie qui seront générées par l'ensemble des paquets de données reçus lors de la période courante ; - une étape (4.4) de comparaison de cette taille calculée avec un seuil ; - lorsque cette taille calculée est supérieure au seuil, une étape (4.5) visant à intégrer le dernier paquet reçu qui provoque le dépassement du seuil et les paquets suivants dans les données reçues à la période suivante. 2/ Procédé selon la revendication 1, caractérisé en ce que l'étape (4.5) visant à intégrer le dernier paquet reçu qui provoque le dépassement du seuil et les paquets suivants dans les données reçues à la période suivante consiste en une bascule des tampons de réception de tous les modules de calcul de codes correcteurs sur un tampon de réserve disponible au sein de chaque module qui devient alors le tampon de réception. 3/ Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que le calcul de la taille des données de sortie générées par l'ensemble des paquets de données reçus lors de la période courante comprend : - une étape de calcul du nombre de paquets FEC correspondant à ces paquets reçus et leur taille ; - une étape de calcul de la taille des en-têtes MPE correspondant aux paquets de données reçus et aux paquets FEC ; - une étape de calcul de la taille des en-têtes des paquets TS qui seraient générés pour la transmission de ces sections données et FEC.4/ Procédé selon l'une des revendications 1 à 3, caractérisé en ce que lors de l'étape de calcul de la taille des données de sortie, on maintient pour chaque service le nombre de paquets reçus et la somme des tailles de ces paquets reçus pour la période, le calcul comprenant alors les étapes suivantes : - une étape où l'on calcule la contribution du service auquel appartient le paquet reçu, avec et sans ce paquet reçu ; - une étape de mise à jour des données mémorisées pour ce service compte tenu de ce paquet reçu ; - une étape où l'on ajoute à la taille totale des données générées la différence entre les deux calculs. 5/ Procédé selon l'une des revendications 1 à 4, caractérisé en ce que lors de l'étape de calcul de la taille des données de sortie, on calcule le débit généré par la taille des données calculées, et où l'étape de comparaison consiste à comparer ce débit à un seuil correspondant au débit maximum théorique. 6/ Procédé selon l'une des revendications 1 à 4, caractérisé en ce que lors de l'étape de calcul de la taille des données de sortie, on compare cette taille avec celle engendrée par le débit maximum théorique sur la période. 7/ Procédé selon l'une des revendications 1 à 4, caractérisé en ce que on établit le seuil en nombre de paquets TS par période et dans ce cas on exprime la taille calculée en nombre de paquets TS générés par l'ensemble des paquets IP reçus. 25 8/ Appareil (1.4) de génération d'un flux de données vidéo comprenant : - une pluralité d'entrées, chacune de ces entrées permettant la réception d'un flux de données composé de paquets IP ; - une pluralité correspondante de modules (2.1, 2.2 et 2.3) de calcul de codes correcteurs pour traiter ces flux, chaque module étant composé d'au moins un tampon 30 de réception (3.2), d'un tampon de calcul (3.3) et d'un tampon de sortie (3.4) fonctionnant en parallèle ; et, une période étant définie, caractérisé en ce qu'il comprend en outre des moyens pour, lors de la réception d'un nouveau paquet de données sur une des entrées :20- calculer la taille des données de sortie qui seront générées par l'ensemble des paquets de données reçus lors de la période courante ; - comparer cette taille calculée avec un seuil ; - lorsque cette taille calculée est supérieure au seuil, intégrer le dernier paquet 5 reçu qui provoque le dépassement du seuil et les paquets suivants dans les données reçues à la période suivante.