Brevet FR3023113A1 — publié le 20160101

Procédé et dispositif d'optimisation de la transmission d'un flux MPEG2-TS, programme d'ordinateur et support d'enregistrement correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui de la transmission et de la diffusion de contenus numériques, notamment de données audiovisuelles. Plus précisément, l'invention concerne l'optimisation de la bande passante utile d'un flux transmis selon la norme de diffusion ISO/IEC relative aux multiplex de transport MPEG2-TS (en anglais « Motion Picture Expert Group -Transport Stream », en français « flux de transport MPEG »). 2. Art antérieur La norme MPEG2-TS est utilisée en télédiffusion pour le transport des données audiovisuelles (paquets de flux élémentaire de type PES, pour « Packetized Elementary Stream » en anglais, ou données sections (tables PMT pour « Program Map Table » en anglais ou « PAT » pour « Program Association Table » en anglais), ou encore octets de bourrage). Les données transportées sont articulées à l'aide d'informations de signalisation (SI pour « Informations sur le Système/Service » ou « Service Information » en anglais et PSI pour « Informations propres au Programme » ou « Program Specific Information » en anglais), elles-mêmes incluses dans le flux MPEG2-TS sous la forme de tables de signalisation. L'ensemble (données audiovisuelles et signalisation) est transmis par paquets de taille constante (soit cent quatre-vingt-huit octets, dont quatre octets d'en-tête, quatre octets de contrôle de l'intégrité du transport (notés CRC32) et cent quatre-vingts octets de charge utile). La transmission de données par paquets de taille constante entraine une perte de bande passante « utile »lorsque la longueur de la trame à transmettre n'est pas un multiple de la taille de paquet prédéfinie. Cette perte est donc également observée dans la transmission des tables de signalisation. Par exemple, dans le cas de la norme MPEG2-TS, une trame de taille n entraine forcément une perte de bande passante « utile » équivalente à (n modulo 180) octets. Il existe donc un besoin pour une nouvelle technique permettant de diminuer la perte de bande passante utile due à la transmission par paquets de taille constante. On s'attache plus particulièrement dans la suite de ce document à décrire une problématique existante dans le domaine des réseaux de diffusion de télévision numérique terrestre, encore appelée TNT. L'invention ne se limite bien sûr pas à ce domaine particulier d'applications, mais présente un intérêt pour toute technique de transmission ou de diffusion d'informations devant faire face à une problématique proche ou similaire, et notamment dans des réseaux de diffusion mettant en oeuvre la norme DVB-T ou la norme DVB-T2. 3. Exposé de l'invention L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé d'optimisation de la transmission d'un flux MPEG2-TS portant au moins un premier service Si. Selon l'invention, le procédé d'optimisation met en oeuvre les étapes suivantes, pour au moins un paquet TS du flux : - une étape d'insertion, dans le paquet TS, d'au moins un octet portant des données utiles, d'un deuxième service S2 distinct du premier service Si, dit octet utile supplémentaire ; - une étape de suppression d'au moins un octet de bourrage du paquet TS. Ainsi, l'invention, selon ses différents modes de réalisation, repose sur une approche nouvelle et inventive de l'optimisation de la bande passante utile d'un flux MPEG2-TS, permettant de transporter des données utiles d'un autre service dans un paquet TS portant des données d'un service donné. Pour ce faire, l'invention prévoit d'insérer, dans un paquet TS portant des données d'un service donné, un ou plusieurs octets de données utiles d'un autre service (distinct du service donné) et de supprimer, dans ce même paquet TS, un ou plusieurs octets de bourrage (OxFF), afin de respecter la taille constante définie d'un paquet TS. De ce fait, la bande passante utile est optimisée, la quantité de données utiles transmises par le même nombre de paquets étant supérieure à celle transmise selon les techniques de l'art antérieur. Le nombre d'octets de bourrage supprimés correspond bien sûr au nombre d'octets utiles supplémentaires insérés, afin de respecter la taille constante définie d'un paquet TS. En fonction du nombre d'octets de bourrage présents à la fin d'un paquet TS, le nombre d'octets utiles supplémentaires insérés est variable. Par exemple, ces données utiles supplémentaires insérées peuvent permettre de transporter des composantes de configuration d'équipements de mesure, dans un flux MPEG2-TS existant, sans augmenter le débit utile. Selon un premier mode de réalisation de l'invention, lorsque le paquet TS porte une table de signalisation, le procédé comprend une étape de formatage des données utiles du service S2 en descripteur privé, et l'étape d'insertion insère, dans la boucle des descripteurs de la table de signalisation, le ou les octets utiles supplémentaires formatés en descripteur privé. Ainsi, selon ce premier mode de réalisation de l'invention, dans lequel le paquet TS considéré porte une table de signalisation (PAT ou PMT par exemple), l'octet utile supplémentaire est inséré dans le paquet TS dans la boucle des descripteur, avant le CRC32. Pour ce faire, les données utiles à insérer sont mises en forme/formatées pour constituer un descripteur privé à insérer dans la boucle des descripteurs de la table de signalisation, ce type de descripteur étant prévu par la norme. Afin de respecter la taille constante définie d'un paquet TS, lorsqu'un octet utile supplémentaire est inséré (sous la forme d'un descripteur privé) dans la boucle des descripteurs, un octet de bourrage est supprimé à la fin du paquet TS, après le CRC32. Le deuxième service S2 transporté de cette manière, sous la forme d'octets utiles supplémentaires insérés dans un paquet TS portant des données d'un premier service Si, peut consister en un service global ou un service individuel. Dans le cas d'un service global, toutes les données supplémentaires portées par ces octets utiles supplémentaires insérés, seront agrégées, au niveau du récepteur, pour restituer les informations du service S2 commun à l'ensemble des chaînes du multiplex (ou d'un service S2 du diffuseur). Dans le cas d'un service individuel, les données supplémentaires sont liées au programme décrit par la table PMT. Selon un deuxième mode de réalisation de l'invention, lorsque le paquet TS porte une table de signalisation, les étapes d'insertion et de suppression consistent en une étape de remplacement du ou des octets de bourrage par le ou les octets utiles supplémentaires. Ainsi, selon ce deuxième mode de réalisation, dans lequel le paquet TS considéré porte une table de signalisation (PAT ou PMT par exemple), l'octet utile supplémentaire est inséré après le CRC32, directement en remplacement d'un octet de bourrage. Dans ce cas, les données supplémentaires insérées ne sont pas détectées par un récepteur classique, car elles se trouvent après le CRC32. En revanche, les données supplémentaires insérées sont détectées et reconnues par un récepteur spécifique, modifié pour vérifier s'il y a des données utiles après le CRC32. Selon une deuxième variante de ce deuxième mode de réalisation, le procédé d'optimisation comprend une étape d'ajout d'un descripteur privé, dans la boucle des descripteurs de la table de signalisation, indiquant le remplacement d'au moins un octet de bourrage par au moins un octet utile supplémentaire. Ainsi, selon une deuxième variante du deuxième mode de réalisation (dans lequel l'octet utile supplémentaire est inséré après le CRC32, directement en remplacement d'un octet de bourrage), un descripteur privé peut également être ajouté, dans la boucle des descripteurs de la table de signalisation, afin d'indiquer que des données utiles supplémentaires sont présentes après le CRC32. Ce descripteur privé ainsi ajouté est notamment utile lorsque les données utiles supplémentaires insérées après le CRC32 sont dépourvues d'entête. De même que pour la première variante, les données supplémentaires insérées peuvent en revanche être détectées et reconnues par un récepteur spécifique, modifié pour vérifier s'il y a des données utiles après le CRC32. Le descripteur est donc accessible par tous les récepteurs, mais interprétable uniquement par les récepteurs avertis/spécifiques. Par exemple, la table de signalisation est de type « PMT » (« Program Map Table ») ou « PAT » (« Program Association Table »). Selon un troisième mode de réalisation, lorsque le paquet TS porte des données utiles, de type PES (« Packetized Elementary Stream »), du service Si, les étapes d'insertion et de suppression consistent en une étape de remplacement d'au moins un octet de bourrage du champ « adaptation field » de l'en-tête du paquet TS par au moins un octet utile supplémentaire. Ainsi, selon ce troisième mode de réalisation, dans lequel le paquet TS considéré porte des paquets PES, l'octet utile supplémentaire est inséré directement en remplacement d'un octet de bourrage dans le champ « adaptation field ». Dans ce cas, il faut que la valeur du champ « adaptationjield length » soit supérieure à A, où A est la taille réelle du champ « adaptationjield » et est obtenue par le calcul suivant : A = (taille de la partie fixe du champ « adaptationjield » + « transport private_data_length » + « adaptationjield extension_length »), la partie fixe correspondant à l'ensemble des champs obligatoires du champ « adaptationjield ». Le nombre d'octets utiles supplémentaires pouvant être insérés est égal à (« adaptationjield length » - A). Selon un aspect particulier de l'invention, le procédé comprend une étape d'obtention d'un nombre maximal M d'octets utiles supplémentaires pouvant être insérés dans le paquet TS, et les étapes d'insertion et de suppressions sont réitérées n fois, avec n Plus le nombre d'octets de données supplémentaires insérés est proche du maximum, et plus l'utilisation de la bande passante utile est optimisée. Selon les premier et deuxième modes de réalisation, le nombre maximal M dépend au moins du nombre d'octets de bourrage présents dans le paquet TS. Ainsi, selon les premiers ou deuxièmes modes de réalisation décrits ci-dessus, lorsque le paquet TS porte une table de signalisation, le nombre maximal d'octets supplémentaires pouvant être insérés correspond au nombre d'octets de bourrage présents dans le paquet TS, après le CRC32. Selon le troisième mode de réalisation de l'invention, le nombre maximal M dépend d'au moins un champ appartenant au groupe comprenant : - « adaptation_field length » ; - « transport private_data_length » ; - « adaptation_field extension_length ». Ainsi, selon le troisième mode de réalisation décrit ci-dessus, lorsque le paquet TS porte des données PES, le nombre maximal d'octets supplémentaires pouvant être insérés dépend de plusieurs champs représentatifs de longueurs (« adaptation_field length », « transport private_data_length » et « adaptation_field extension_length ») et de la taille fixe du champ « adaptation_field ». L'invention concerne également un dispositif d'optimisation de la bande passante d'un flux MPEG2-TS portant au moins un premier service Si, comprenant les moyens suivants : - des moyens d'insertion, par exemple sous la forme d'un module d'insertion, dans au moins un paquet TS du flux, d'au moins un octet portant des données utiles, d'un deuxième service S2 distinct du premier service Si, dit octet utile supplémentaire ; - des moyens de suppression, par exemple sous la forme d'un module de suppression, d'au moins un octet de bourrage du paquet TS. Un tel dispositif d'optimisation est notamment adapté à mettre en oeuvre le procédé d'optimisation décrit précédemment. Un tel dispositif d'optimisation pourra bien sûr comporter les différentes caractéristiques relatives au procédé d'optimisation selon l'invention, qui peuvent être combinées ou prises isolément. Ainsi, les caractéristiques et avantages de ce dispositif d'optimisation sont les mêmes que ceux du procédé d'optimisation et ne sont pas détaillés plus amplement. L'invention concerne par ailleurs un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé d'optimisation tels que décrit précédemment lorsque ce ou ces programmes sont exécutés par un processeur. Le procédé d'optimisation selon l'invention peut donc être mis en oeuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce ou ces programmes peuvent utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention concerne enfin un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'optimisation tel que décrit précédemment. 4. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente les principales étapes d'un procédé d'optimisation de la transmission d'un flux MPEG2-TS, selon un mode de réalisation particulier de l'invention ; les figures 2a et 2b illustrent respectivement un exemple de paquet TS avant et après la mise en oeuvre du procédé d'optimisation, selon un premier mode de réalisation particulier de l'invention ; les figures 3a à 3c illustrent respectivement un exemple de paquet TS avant (figure 3a) et après (figures 3b et 3c) la mise en oeuvre du procédé d'optimisation, selon un deuxième mode de réalisation particulier de l'invention ; les figures 4a et 4b illustrent respectivement un exemple de paquet TS avant et après la mise en oeuvre du procédé d'optimisation, selon un troisième mode de réalisation particulier de l'invention ; la figure 5 illustre un exemple de paquet supplémentaire, selon un mode de réalisation particulier de l'invention ; la figure 6 illustre un exemple d'architecture simplifiée d'un dispositif d'optimisation selon un mode de réalisation de l'invention. 5. Description d'un mode de réalisation de l'invention 5.1 Principe général Le principe général de l'invention repose sur le remplacement d'octets de bourrage, dans un paquet TS d'un flux MPEG-TS portant des données d'un premier service S1, par des octets portant des données utiles d'un deuxième service S2, distinct de S1, ce qui permet d'améliorer le taux de données utiles du flux MPEG-TS. Ainsi, l'invention propose d'affecter les données de bourrage présentes dans les PID utiles (PID différents de Ox1FFF) d'un service, au transport d'un ou plusieurs services supplémentaires, augmentant ainsi la bande passante utile d'un multiplexe. Plus concrètement, la technique selon les différents modes de réalisation de l'invention, permet d'ajouter des services supplémentaires dans un multiplexe considéré comme saturé selon les techniques actuelles. Les principales étapes du procédé d'optimisation de l'invention sont illustrées en figure 1, selon un mode de réalisation particulier. On considère ainsi un ou plusieurs paquets de données d'un service S2, à transporter en utilisant la bande passante utile non utilisée pour transporter des données d'un service Si, dans un paquet TS. Un ou plusieurs octets de données du service S2, notés octets supplémentaires, sont insérés, lors d'une étape 10 d'insertion, dans le paquet TS. Selon les différents modes de réalisation décrits plus en détails ci-dessous, les octets supplémentaires sont insérés à différents endroits du paquet TS. Ensuite, une étape de suppression 11 d'un ou plusieurs octets de bourrage est mise en oeuvre, afin de conserver la taille fixe du paquet TS. Le nombre d'octets de bourrage supprimés correspond donc au nombre d'octets supplémentaires insérés. Une fois ces deux étapes mises en oeuvre, le paquet TS modifié permet de transporter non seulement des données du service Si, mais également des données d'un autre service S2. Il est à noter que le service S2 peut être un service global, c'est à dire commun à toutes les chaines d'un multiplexe, ou un service individuel. Par ailleurs, on parle de données utiles du service S2 transportées, grâce à l'invention, dans un paquet TS portant des données d'un service Si, car ces données utiles de S2 ne sont pas des données de signalisation du service Si, ni des données privées relatives au service Si. On présente maintenant, en relation avec les figures 2a et 2b, 3a à 3c, 4a et 4b, différents modes de réalisation de l'invention. 5.2 Premier mode de réalisation Selon le premier mode de réalisation, illustré en figures 2a et 2b, l'invention consiste à utiliser l'espace disponible des tables de signalisation de type PMT et PAT d'un paquet TS transportant un premier service Si, pour transporter des données supplémentaires d'un deuxième service S2. Dans ce premier mode de réalisation, les données supplémentaires sont insérées sous forme d'un descripteur privé dans la boucle des descripteurs commun de la table de signalisation, PMT ou PAT. La figure 2a illustre un exemple de paquet TS « classique » portant une table PMT. Selon cet exemple, les données utiles de PMT occupent n octets dans le paquet, après les quatre octets d'en-tête H de paquet, et avant les quatre octets de contrôle de l'intégrité du transport CRC32. Il reste donc (n mod 180) octets de bourrage (OxFF) à la fin du paquet, inutilisés et insérés à la fin du paquet pour respecter la condition de taille constante de cent quatre-vingt-huit octets d'un paquet TS. La figure 2b illustre quant à elle un exemple de paquet TS modifié selon ce mode de réalisation de l'invention, c'est à dire un paquet dans lequel un descripteur privé a été inséré, avant les octets de CRC32, pour transporter des données utiles du service S2. Pour conserver une taille de cent quatre-vingt-huit octets du paquet TS modifié, autant d'octets de bourrage que d'octets du descripteur privé sont supprimés, à la fin du paquet TS modifié. Ainsi, le nombre d'octets de bourrage correspond, dans le paquet TS modifié, à (p mod 180) octets, si l'on considère que les données utiles de PMT et le descripteur privé occupent p octets, avec p Comme déjà indiqué ci-dessus, le service supplémentaire S2 transporté peut être un service global ou individuel. Dans le cas d'un service global, toutes les données supplémentaires insérées dans un ou plusieurs paquets TS seront agrégées au niveau du récepteur pour restituer les informations d'un service commun à l'ensemble des chaînes du multiplexe (ou un service du diffuseur). Dans le cas du service individuel, les données supplémentaires seront insérées dans les paquets TS de la PMT et/ou des composantes du service auquel elles sont associées. Par exemple un service audiovisuel ayant une composante vidéo et une composante audio peut transporter un service supplémentaire via sa PMT, sa composante vidéo et/ou sa composante audio (troisième mode de réalisation décrit ci-dessous). La détermination de la bande passante disponible (c'est-à-dire le nombre d'octets non utiles transportés par un paquet TS avant l'application de la solution de l'invention) pour un service global, noté W dans l'équation ci-après, ou pour un service individuel, noté wi dans l'équation ci-après, peut être calculée selon les formules suivantes : wi = z i x (n mod 180) x 8bps et W = wibps , nbservices avec I" =100ms , = 10Hz pour une table PMT. Pour ce premier mode de réalisation, le nombre d'octets supplémentaires pouvant être insérés dépend donc du nombre d'octets de bourrage à la fin du paquet TS. Pour connaître le nombre d'octets de bourrage à la fin d'un paquet TS portant une table PAT ou PMT, l'information de taille de la section de la table transportée est utilisée. Cette information est portée par le champ « section_length » et, avec les informations également connues des champs obligatoires d'une PMT ou une PAT, le nombre d'octets de bourrage ajoutées à la fin du paquet peut être déduit. 5.3 Deuxième mode de réalisation Selon le deuxième mode de réalisation, illustré en figures 3a à 3c, l'invention consiste également à utiliser l'espace disponible des tables de signalisation de type PMT et PAT d'un paquet TS transportant un premier service Si, pour transporter des données supplémentaires d'un deuxième service S2. En revanche, dans ce deuxième mode de réalisation, les données supplémentaires sont insérées directement en remplacement des octets de bourrage, en fin de paquet TS. La figure 3a illustre, comme la figure 2a, un exemple de paquet TS « classique » portant une table PMT. Selon cet exemple, les données utiles de PMT occupent n octets dans le paquet, après les quatre octets d'en-tête H de paquet, et avant les quatre octets de contrôle de l'intégrité du transport CRC32. Il reste donc (n mod 180) octets de bourrage (OxFF) à la fin du paquet, inutilisés et insérés à la fin du paquet pour respecter la condition de taille constante de cent quatre-vingt-huit octets d'un paquet TS. La figure 3b illustre quant à elle un exemple de paquet TS modifié selon une première variante de ce mode de réalisation de l'invention, pour transporter des données utiles d'un service S2. Selon cette première variante, m octets utiles du service S2 sont insérés à la place de m octets de bourrage, après le CRC32. Il reste donc, à la fin du paquet TS modifié ((n+m) mod 180) octets de bourrage, afin de conserver la taille constante du paquet TS. Ces données insérées après le CRC32 du paquet TS modifié ne sont pas reconnues par un récepteur « classique », mais sont détectées par un récepteur adapté pour reconnaître des données utiles insérées après le CRC32. Selon une deuxième variante de ce deuxième mode de réalisation, illustrée par la figure 3c, m octets utiles du service S2 sont insérés à la place de m octets de bourrage, après le CRC32, et un descripteur privé indiquant l'insertion des octets supplémentaires après le CRC32. Ce descripteur privé est ajouté avant le CRC32, dans la boucle « program_info » de la table PMT, et il reste donc, à la fin du paquet TS modifié, ((p+m) mod 180) octets de bourrage, afin de conserver la taille constante du paquet TS, avec p le nombre d'octets comprenant les données utiles de PMT et le descripteur privé. L'Annexe, faisant partie intégrante de la présente description, présente un exemple de boucle d'insertion d'un tel descripteur privé (1), pour une table PMT, ainsi qu'un exemple de code d'insertion (2) pour un paquet de données supplémentaires, noté « rck-packet ». Pour ce deuxième mode de réalisation, le nombre d'octets supplémentaires pouvant être insérés dépend également du nombre d'octets de bourrage à la fin du paquet TS et peut être calculé, comme décrit ci-dessus pour le premier mode de réalisation, à l'aide de l'information de taille de la section de la table transportée présente le champ « section_length ». 5.4 Troisième mode de réalisation Selon un troisième mode de réalisation, illustré en figures 4a et 4b, l'invention consiste à utiliser l'espace disponible d'un paquet TS transportant des paquets PES d'un premier service Si, pour transporter des données supplémentaires d'un deuxième service S2. Dans ce cas, les octets supplémentaires sont insérés à la place des octets de bourrage présents dans le champ « adaptationjield » de l'en-tête du paquet TS. Pour que cela soit possible, il faut que la valeur du champ « adaptation_filed length » soit supérieure à la taille réelle, notée A, du champ « adaptationJield ». Par exemple, on peut écrire : A = ( A' + « transport private_data_length » + « adaptationjield extension_length »), avec A' la taille de la partie fixe du champ « adaptation_field », cette partie fixe correspondant à l'ensemble des champs obligatoires du champ « adaptationjield ». Le nombre d'octets utiles supplémentaires pouvant être insérés est égal à (adaptationjield length -A). Ainsi, selon ce troisième mode de réalisation, des données supplémentaires d'un deuxième service S2 sont transportées dans un paquet TS portant des données utiles de type PES d'un premier service Si. La figure 4a illustre un exemple de paquet TS portant une trame PES « classique », portant notamment un champ « adaptationjield » avec des données « Adf data » suivies d'octets de bourrage, ainsi que des données utiles « PES data ». La figure 4b illustre quant à elle un exemple de paquet TS portant une trame PES, modifié selon ce mode de réalisation de l'invention, pour transporter des données utiles d'un service S2. Selon ce mode de réalisation, m octets utiles du service S2 sont insérés à la place de m octets de bourrage, dans le champ « adaptationjield », avant les données utiles « PES data ». Comme pour les deux premiers modes de réalisation, la détermination de la bande passante disponible pour un service global, noté W dans l'équation ci-après, ou pour un service individuel, noté wi dans l'équation ci-après, peut être calculée selon les formules suivantes : w, =1--1 x(n mod180) x 8bps et W = wibps , nbservices 1- dépendant du débit alloué à la vidéo (ou audio) portée par les paquets PES. 5.5 Exemple de données supplémentaires Les données supplémentaires relatives à un service S2 et insérées dans un paquet TS portant des données d'un premier service Si, sont formatées selon l'exemple de paquet illustré en figure 5. Selon cet exemple, un paquet « rck », pour « Ressource kit », comprend six octets (quarante huit bits) d'information (« start », ID, « Type » (noté « T »), « size », « counter » ou encore « chck »), et q octets de charge utile, correspondant aux données supplémentaires du service S2. Le nombre q d'octets de charge utile dépend du nombre d'octets de bourrage à la fin du paquet TS, dans le cas des modes de réalisation 1 et 2 décrits ci-dessus, ou de la valeur du champ « adaptation_field length », dans le cas du troisième mode de réalisation décrit ci-dessus. 5.6 Structure d'un dispositif d'optimisation On présente désormais, en relation avec la figure 6 un exemple de structure simplifiée d'un dispositif d'optimisation, mettant en oeuvre une technique d'optimisation selon un mode de réalisation décrit ci-dessus. Cette figure 6 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser les différents modes de réalisation détaillés ci-dessus. Le dispositif d'optimisation, illustré en figure 6, comprend une mémoire RAM 60, une unité de traitement 61, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire ROM 62, mettant en oeuvre le procédé d'optimisation selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 62 sont par exemple chargées dans la mémoire RAM 60 avant d'être exécutées par le processeur de l'unité de traitement 61. L'unité de traitement 61 reçoit en entrée un paquet TS portant des données d'un service Si. Le processeur de l'unité de traitement 61 met en oeuvre les étapes du procédé d'optimisation décrit précédemment, selon les instructions du programme d'ordinateur 62, pour insérer un ou plusieurs octets supplémentaires portant des données d'un service S2, et supprimer le ou les octets de bourrage correspondants. Pour cela, le dispositif d'optimisation comprend, outre la mémoire 60, des moyens d'insertion, par exemple sous la forme d'un module d'insertion, dans au moins un paquet TS du flux, d'au moins un octet portant des données utiles, d'un deuxième service S2 distinct du premier service Si, dit octet utile supplémentaire, et des moyens de suppression, par exemple sous la forme d'un module de suppression, d'au moins un octet de bourrage du paquet TS. Ces modules sont pilotés par le processeur de l'unité de traitement 61.25 ANNEXE (1) t.dde id a ,v( lion -\ nt 1.'...wdicaloi 1 i e, en ed 2 iei tien length 12 pi oui lin_inimbei 16 reser% ed 2 version nul/ibn 5 oui ent11e,,tindiclior 1 sectionnuinher 8 Lisi...section...unnilio 8 reserved 3 P(_ 11.._P1I) 13 i t,ui -' ed 4 pro..:!:)in. inft^ length 12 streani_ 8 _t^.pe i (.r \ t.d 3 i1t,inental^ PLl 13 i esei \ e,d 4 ESini+ u2th 12 t , 32 ( liC.,..32 (2) rck-descr Tag [8] Length [8] rck-packet15 REVENDICATIONS1. Procédé d'optimisation de la transmission d'un flux MPEG2-TS portant au moins un premier service Si, caractérisé en ce que ledit procédé met en oeuvre les étapes suivantes, pour au moins un paquet TS dudit flux : - une étape d'insertion, dans ledit paquet TS, d'au moins un octet portant des données utiles, d'un deuxième service S2 distinct dudit premier service Si, dit octet utile supplémentaire ; - une étape de suppression d'au moins un octet de bourrage dudit paquet TS. 2. Procédé d'optimisation selon la revendication 1, caractérisé en ce que, lorsque ledit paquet TS porte une table de signalisation, ledit procédé comprend une étape de formatage desdites données utiles du service S2 en descripteur privé, et en ce que ladite étape d'insertion insère, dans la boucle des descripteurs de ladite table de signalisation, ledit au moins un octet utile supplémentaire formaté en descripteur privé. 3. Procédé d'optimisation selon la revendication 1, caractérisé en ce que, lorsque ledit paquet TS porte une table de signalisation, lesdites étapes d'insertion et de suppression consistent en une étape de remplacement dudit au moins un octet de bourrage par ledit au moins un octet utile supplémentaire. 4. Procédé d'optimisation selon la revendication 3, caractérisé en ce qu'il comprend une étape d'ajout d'un descripteur privé, dans la boucle des descripteurs de ladite table de signalisation, indiquant ledit remplacement d'au moins un octet de bourrage par ledit au moins un octet utile supplémentaire. 5. Procédé d'optimisation selon la revendication 3 ou la revendication 4, caractérisé en ce que ladite table de signalisation est de type « PMT » (« Program Map Table ») ou « PAT» (« Program Association Table »). 6. Procédé d'optimisation selon la revendication 1, caractérisé en ce que, lorsque ledit paquet TS porte des données utiles, de type PES (« Packetized Elementary Stream »), dudit service Si, lesdites étapes d'insertion et de suppression consistent en une étape de remplacement d'au moins un octet de bourrage du champ « adaptation field » de l'en-tête dudit paquet TS par ledit au moins un octet utile supplémentaire. 7. Procédé d'optimisation selon la revendication 1, caractérisé en ce que ledit procédé comprend une étape d'obtention d'un nombre maximal M d'octets utiles supplémentaires pouvant être insérés dans ledit paquet TS, et en ce que lesdites étapes d'insertion et de suppressions sont réitérées n fois, avec n 8. Procédé d'optimisation selon les revendications 2 ou 3 et 7, caractérisé en ce que ledit nombre maximal M dépend au moins du nombre d'octets de bourrage présents dans ledit paquetTS. 9. Procédé d'optimisation selon les revendications 6 et 7, caractérisé en ce que ledit nombre maximal dépend d'au moins un champ appartenant au groupe comprenant : - « adaptation_field length » ; - « transport private_data_length » ; - « adaptation_field extension_length ». 10. Dispositif d'optimisation de la bande passante d'un flux MPEG2-TS portant au moins un premier service Si, caractérisé en ce que ledit dispositif comprend les moyens suivants : - des moyens d'insertion, dans au moins un paquet TS dudit flux, d'au moins un octet portant des données utiles, d'un deuxième service S2 distinct dudit premier service Si, dit octet utile supplémentaire ; - des moyens de suppression d'au moins un octet de bourrage dudit paquet TS. 11. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé d'optimisation selon l'une quelconque des revendications 1 à 9, lorsque ce programme est exécuté par un processeur. 12. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'optimisation selon l'une quelconque des revendications 1 à 9.20