FR 2924259 A1 20090529 FR 0759352 A 20071127 L'invention concerne un module de traitement de données vidéo comprenant : a) une unité de traitement vidéo, dont la configuration est programmable par des données de programmation, et qui est apte à transformer des données vidéo à traiter en données vidéo traitées, qui est elle-même dotée de : -> une entrée vidéo pour recueillir lesdites données vidéo à traiter, - > une sortie vidéo pour fournir lesdites données vidéo traitées, - > une entrée de configuration pour recueillir lesdites données de programmation, b) un bus d'entrée apte à délivrer un flux de données d'entrée comprenant 10 lesdites données vidéo à traiter, c) un bus de sortie apte à délivrer un flux de données de sortie comprenant lesdites données vidéo traitées. La figure 44 du document US5497498 décrit un tel module de traitement : voir notamment le passage situé entre la colonne 22, ligne 55 et la colonne 24, ligne 15 20 de ce document. Un inconvénient de ce module de traitement vidéo est qu'il nécessite des bus différents : pour les données vidéo d'une part (OBUS et NBUS sur la figure 44 û voir colonne 3, lignes 2-3 et 51), et pour les données de programmation d'autre part (MBUS et HBUS sur la figure 44 û voir colonne 3, lignes 7-8 et 49-50). 20 Un but de l'invention est d'offrir un module de traitement de données vidéo doté d'un bus commun pour transporter les données vidéo et les données de programmation. A cet effet, l'invention a pour objet un module de traitement précédemment cité, où ledit bus d'entrée est adapté pour intégrer audit flux de données d'entrée 25 lesdites données de programmation, et où ledit module de traitement comprend également une unité de contrôle qui est reliée audit bus d'entrée, qui est apte à séparer les données vidéo à traiter et les données de programmation dans le flux de données d'entrée délivré par ledit bus d'entrée, qui est reliée à l'entrée vidéo de ladite unité de traitement vidéo à configuration programmable pour 30 transmettre à cette unité les données vidéo à traiter après séparation dans ledit flux de données d'entrée, et qui est reliée à l'entrée de configuration de ladite unité de traitement vidéo à configuration programmable pour transmettre à cette unité les données de programmation après séparation dans ledit flux de données d'entrée. De préférence, lesdites données vidéo à traiter étant réparties en trames d'image, ledit bus d'entrée est adapté pour intégrer lesdites données de programmation dans des � temps morts �, où chaque � temps mort � est compris entre deux trames d'image successives. De préférence, l'unité de traitement vidéo à configuration programmable est un circuit, un réseau (� FPGA �) ou un contrôleur. L'unité de contrôle peut être basée sur un microprocesseur, un CPU (� Central Processing Unit � en langue anglaise), ou un circuit de type PLD (� Programmable Logic Device � en langue anglaise), CPLD (� Complex Programmable Logic Device � en langue anglaise) ou DSP (� Digital Signal Processor � en langue anglaise). Les bus qui délivrent des flux de données peuvent être du type HD-SDI (� High Definition Serial Digital Interface � en langue anglaise), tel que défini par exemple selon la norme SMPTE 292M-1998 ; ils peuvent également être du type DVI (� Digital Video Interface � en langue anglaise), ou encore du type � Fiber Channel � tel que par exemple défini par le comité technique T11 du � InterNational Committee for Information Technology Standards (INCITS) �. L'invention a également pour but un système de traitement de données vidéo comprenant une pluralité de modules de traitement selon l'invention, qui sont disposés en série et où, quelque soit le module de traitement du moment qu'il ne s'agit pas du premier de la série, le bus d'entrée dudit module de traitement correspond au bus de sortie du module de traitement précédent de la série. Grâce à ce branchement en série des modules du système, toutes les données qui sortent d'un module par son bus de sortie rentrent dans le module suivant de la série, pourvu qu'il y en ait un. De préférence, les différents modules sont alors reliés par un bus unique et commun à tous les modules. De préférence, l'unité centrale de chaque module, sauf, éventuellement, le dernier de ladite série est en outre apte à combiner dans un même flux de données les données vidéo traitées par ce module et les données de programmation des autres modules qui suivent dans ladite série, et à injecter ce flux de données combinées dans le bus de sortie dudit module. De préférence, lesdites données vidéo traitées étant réparties en trames d'image, ladite combinaison est adaptée pour intégrer lesdites données de programmation dans des � temps morts �, où chaque � temps mort � est compris entre deux trames d'image successives. En résumé, l'invention concerne notamment un module de traitement de données vidéo doté d'une unité de traitement vidéo dont la configuration est programmable. Selon l'invention, les données vidéo à traiter et les données de programmation sont acheminées à ce module via un même bus de données. Ces modules sont avantageusement chaînés en série sur un bus commun qui achemine à chaque module à la fois les données de configuration et les données vidéo à traiter. De préférence, on utilise des périodes de temps mort ou de � blanking � entre deux trames d'images transmises sur ce bus pour insérer les données de programmation. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée à titre d'exemple non limitatif, et en référence aux figures annexées sur lesquelles : - la figure 1 illustre l'architecture d'un module de traitement selon un mode de réalisation de l'invention. - la figure 2 illustre un exemple de formatage des données transportées par le 20 bus, notamment d'entrée, du module de traitement de la figure 1. - la figure 3 illustre un exemple de séquencement d'instructions de contrôle de l'unité de contrôle du module de traitement de la figure 1, dans un exemple de mise en oeuvre de ce module. - la figure 4 illustre l'architecture d'un système de traitement selon un mode de 25 réalisation de l'invention, qui comprend plusieurs modules de traitement selon la figure 1. - la figure 5 illustre les différentes étapes d'un procédé de production cinématographique. En référence à la figure 1, on va maintenant décrire un module de traitement de 30 données vidéo selon un mode de réalisation de l'invention. Ce module comprend : - une unité de traitement vidéo 4 de type FPGA (� Field Programmable Gate Array � en langue anglaise), dotée d'une entrée vidéo 12 pour recueillir des données vidéo à traiter, une sortie vidéo 13 pour fournir les données vidéo après traitement, et une entrée de configuration 9 pour recueillir des données de programmation. Cette unité de traitement vidéo 4 est apte à transformer des données vidéo à traiter en données vidéo traitées. Étant de type FPGA, cette unité de traitement vidéo 4 présente une configuration qui est programmable par des données de programmation. - un bus d'entrée 14, de type HD-SDI, apte à délivrer un flux de données d'entrée comprenant les données vidéo à traiter et, selon l'invention, les données de programmation, et un bus de sortie 15, de type HD-SDI, apte à délivrer un flux de données de sortie comprenant les données vidéo traitées. - une unité de contrôle 1, de type � PLD � ou � DSP �, qui est reliée au bus d'entrée 14, qui est apte à séparer les données vidéo à traiter et les données de programmation dans le flux de données d'entrée délivré par le bus d'entrée, qui est reliée à l'entrée vidéo 12 de l'unité de traitement vidéo 4 pour transmettre à cette unité les données vidéo à traiter après séparation dans le flux de données d'entrée, et qui est reliée à l'entrée de configuration 9 de l'unité de traitement vidéo 4 pour transmettre à cette unité les données de programmation après séparation dans le flux de données d'entrée. D'une manière connue en elle-même, l'unité de contrôle 1 est rendue apte à mettre en oeuvre un séquencement qui sera décrit ultérieurement en référence à la figure 3. Le module de traitement de données vidéo comprend également : - une première mémoire de données vidéo 3 qui est reliée de manière bidirectionnelle à l'unité de contrôle 1 par un premier bus interne de données vidéo 11, - une deuxième mémoire de données vidéo 5 qui est reliée de manière bidirectionnelle à l'unité de traitement vidéo 4 par un deuxième bus interne de données vidéo 10, - un tampon 6 qui relie l'unité de contrôle 1 à l'unité de traitement 4 pour la transmission des données de programmation, - et une mémoire de données de programmation 2 qui est reliée de manière bidirectionnelle au tampon 6. On va maintenant décrire un exemple de fonctionnement du module de traitement vidéo selon le mode de réalisation de l'invention qui vient d'être décrit. En référence à la figure 2, d'une manière connue en elle-même, les données de programmation sont insérées dans des données vidéo à traiter dans un flux de données transportées par le bus d'entrée 14, en respectant notamment les deux standards HD-SDI suivants : - SMPTE 292M-1998 : � Bit-Serial Digital Interface for High-Definition Television Systems �, qui définit l'interface série HD-SDI dans laquelle est prévu une fente (� slot �) d'insertion de données auxiliaires, qui va servir ici pour insérer les données de programmation. - SMPTE 291M-2006 : "Ancillary Data Packet and Space Formatting", qui décrit le format de ces données auxiliaires qui sont notamment ici notamment des données de programmation. Sur la figure 2, les acronymes SAV, EAV, LN et CRC ont la signification suivante : - SAV : en langue anglaise : � Start of Active Video � - EAV : en langue anglaise : � End of Active Video � - LN : en langue anglaise : "Line Number" - GRC: en langue anglaise : � Cyclic Redundancy Code �. Via l'unique bus d'entrée 14, l'unité de contrôle 1 reçoit donc un flux de données comprenant des données vidéo à traiter et des données de configuration qui sont adaptées pour configurer l'unité de traitement vidéo 4 de manière à traiter ces données vidéo conformément à un traitement donné défini à l'avance. L'unité de contrôle 1 analyse ce flux de données selon le séquencement représenté à la figure 3 : - d'une part, selon la partie gauche 16 du logigramme, l'unité de contrôle détecte, dans le flux de données, le début (� SAV �) et la fin (� EAV �) de chaque trame d'image, et écrit les données (voir sur la figure 2 : � Digital Active Lines û Active Picture �) situées entre ce début et cette fin dans la première mémoire vidéo 3, via le premier bus interne de données vidéo 11, ce qui permet de stocker dans cette mémoire l'ensemble des données d'une image. - d'autre part, selon la partie droite 17 du logigramme, dans le même flux de données, l'unité de contrôle recherche (voir la phase � Program file detection �) la présence éventuelle d'un fichier de données de programmation entre la fin (� EAV �) d'une trame et le début (� SAV �) d'une trame suivante, c'est-à-dire dans les phases dites de � blanking � ou de � temps mort � du flux de données (voir figure 2 : � Digital Line Blanking û Ancillary data �) ; en cas de détection d'un tel fichier, les données de programmation de ce fichier sont écrites dans la mémoire de programmation 2 via la connexion 8 et le tampon 6. L'unité de contrôle 1 déclenche ensuite une phase de programmation ou de re- programmation de l'unité de traitement 4 (� re-program phase �) qui passe par le transfert des données de programmation du fichier stocké dans la mémoire de programmation 2 vers l'unité de traitement 4, via le tampon 6 et l'entrée de programmation 9. L'unité de contrôle 1 initialise alors la phase de programmation de l'unité de traitement 4 sur la base des données de programmation qui viennent de lui être transférées (� End of re- program �). Puis, dès que l'unité de contrôle 1 détecte la fin de la phase de programmation de l'unité de traitement 4, elle reprend la phase de détection (voir la phase � Program file detection �) de la présence éventuelle d'un fichier de données de programmation (voir ci-dessus). Le séquencement qui vient d'être décrit en référence à la figure 3 comprend donc deux processus concurrents : l'un 16 gérant l'écriture de données vidéo dans la première mémoire vidéo 3, et l'autre 17 gérant la programmation de l'unité de traitement 4 ainsi que la lecture des données vidéo stockées dans la première mémoire vidéo 3. L'unité de contrôle 1 analyse le flux de données transmises par l'unique bus d'entrée 14 de manière à y détecter les phases de � blanking � ou de � temps mort �, et à en extraire les données de configuration pour les stocker dans la mémoire de configuration 2 ; parallèlement, les données vidéo sont stockées dans la première mémoire vidéo 3. Lorsque l'unité de contrôle 1 détecte la fin des données de configuration, elle lance alors une phase d'initialisation auprès de l'unité de traitement 4. Cette dernière télécharge alors les données de configurations stockées dans la mémoire de configuration 2. Après la phase de programmation, l'unité de contrôle 1 transfère les données vidéo qui ont été retardées dans la première mémoire vidéo 3 vers l'unité de traitement 4. L'unité de traitement 4 traite alors ces données vidéo en temps réel et les renvoie traitées à l'unité de traitement 4 via une connexion 13. L'unité de contrôle 1 transmet ensuite au bus de sortie 15 les données vidéo traitées, après formatage selon les standards HD-SDI précédemment cités. Suivant le type de traitement vidéo réalisé, l'unité de traitement 4 peut utiliser la deuxième mémoire de données vidéo 5 pour y stocker des résultats intermédiaires de traitement. Ainsi, globalement, le module de traitement selon l'invention reçoit un flux de données vidéo à traiter et de programmation mélangées via un même bus d'entrée 14 et restitue un flux de données vidéo traitées sur un bus de sortie 15. Le module de traitement est ici basé sur une unité de traitement vidéo doté d'une architecture programmable FPGA. Ce module de traitement est adapté pour analyser un flux de données, pour en extraire des données de configuration spécifique d'un traitement vidéo à appliquer, et enfin pour se programmer de manière à pouvoir appliquer ce traitement vidéo. L'ensemble de ces opérations s'effectue sans que le traitement soit interrompu sur le flux de données. Ceci est rendu possible grâce : - à l'insertion des données de configuration dans les phases de blanking 20 horizontale et verticale du flux de données. Aucune donnée vidéo n'est transmise à ce moment là dans le flux. - à l'architecture matérielle du module de traitement, qui comprend notamment une unité de contrôle 4 qui est ici associée à la fois à une première mémoire vidéo 3 et à une mémoire de programmation 2. Cette architecture et le 25 séquencement qui vient d'être décrit permettent de masquer les temps de programmation de l'unité de traitement 4. Des modules de traitement vidéo comme celui qui vient d'être décrit peuvent être avantageusement disposés en série sur un bus de données commun et unique pour former un système de traitement vidéo selon l'invention. On va 30 maintenant décrire un mode de réalisation d'un tel système de traitement vidéo en référence à la figure 4, qui comprend ici trois modules de traitement en série sur un bus commun et unique de type HD-SDI : dans l'ordre, un premier module de traitement 19, un deuxième module de traitement 20, et un troisième module de traitement 21. Chaque module de traitement 19, 20, 21 est identique au module de traitement précédemment décrit, à la différence près que l'unité centrale de chaque 5 module est en outre apte : - à combiner dans un même flux de données les données vidéo traitées par ce module et les données de programmation des autres modules, notamment des modules situés en aval dans la série, - et à injecter ce flux de données combinées dans le bus de sortie de type HD-10 SDI de ce module. Pour faire fonctionner un tel système de traitement vidéo, on prévoit alors de préférence, outre les phases précédemment décrites du séquencement de la figure 3 qui sont appliquées alors à chaque module de traitement 19, 20, 21, une phase d'initialisation du système pendant laquelle un jeton d'adresse est 15 inséré dans le flux de données transmises par le bus commun, qui est adapté pour identifier chaque module de traitement 19, 20, 21. Ainsi chacun des modules est alors en mesure d'identifier les données de configuration qui lui sont spécifiquement destinées. Le jeton d'adresse peut être constitué d'un mot de 10 bits dont la valeur initialement transmise est par exemple positionnée à 20 Ox3FF. Le premier module de traitement 19 modifie la valeur du jeton d'adresse par exemple à Ox3FE. Cette nouvelle valeur est stockée en interne et devient l'adresse du module de traitement 19. Ensuite, ce nouveau jeton est transmis au module de traitement suivant 20 qui le modifie et le stocke à son tour pour devenir par exemple Ox3FD. L'opération se répète ainsi de suite jusqu'au 25 dernier module de traitement 21. Les exemples suivants illustrent l'invention. Exemple 1 : On va maintenant décrire trois modes différents d'exploitation du système de traitement vidéo qui vient d'être décrit. Dans ces trois modes, nous supposons 30 que les données transportées par le bus commun HD-SDI du système de traitement sont formatées comme précédemment décrit en référence à la figure 2. Mode 1 : Dans ce mode, nous supposons une phase d'initialisation pendant laquelle les premières données du flux transmises par le bus commun ne comprennent pas de données vidéo mais des données de programmation définissant les traitements vidéo à appliquer aux images à traiter. Un protocole précédemment décrit, basé sur un jeton d'adresse, permet à chacun des modules de traitement du système de détecter les données de programmation qui lui sont destinées, de les enregistrer dans sa mémoire de configuration, et ensuite de lancer l'étape de programmation de son unité de traitement programmable de type FPGA (référence 4 sur la figure 1). Une fois programmées les unités de traitement des différents modules, on envoie dans le bus commun un flux de données comprenant les séquences d'images qui seront, alors traitées en temps réel par le système de traitement selon l'invention. A titre d'exemple, la taille d'un fichier de programmation de l'une des plus grosses matrices d'une unité de traitement de type FPGA, de la famille Altera (EP2S180), est de 52.4 Mbits. En utilisant la liaison � single HD-SDI � pour le bus commun, nous obtenons un temps de transfert des données de programmation de l'ordre de 20 ms. C'est l'équivalent d'un transfert de la moitié d'une image à une fréquence de 24 HZ. Mode 2 : Chaque module de traitement du système de traitement peut être programmé pour appliquer un traitement vidéo différent selon la séquence d'images à traiter. Cela suppose que, pendant la phase d'initialisation, chaque module de traitement ait st ocké dans sa mémoire de programmation les différents traitements sous forme de données de programmation spécifiques. Ensuite à chaque séquence d'images à traiter, sera avantageusement associé une metadata (correspondant à un mot de commande) apte à indiquer aux différents modules de traitement du système quel type de traitement vidéo ils doivent appliquer et selon quelles données de programmation ils doivent reconfigurer leur unité de traitement de type FPGA pour appliquer ce traitement vidéo. Les mots de commande seront par exemple transmis sur le bus commun pendant la période de � blanking �. De même, il convient que la reconfiguration des unités de traitement de type FPGA se fasse pendant cette phase de �blanking �. Ceci permet avantageusement d'éviter d'interrompre le traitement vidéo et d'assurer ainsi un traitement en temps réel. Dans ce mode, il convient que la mémoire de programmation de chaque module de traitement soit assez grande pour stocker toutes les données de programmation qui seront utilisées successivement pour programmer l'unité de traitement de ce module pendant l'ensemble de la durée du flux vidéo. Deux paramètres sont alors importants à connaître pour assurer un traitement vidéo en temps réel. D'une part le temps programmation Tprog d'une unité de traitement de type FPGA et d'autre part les durées dites de � blanking � ou � temps mort � Tmort dans le flux de données sur le bus commun. Il convient de satisfaire la relation : Tprog Deuxième solution : La deuxième solution consiste à appliquer une compression au flux de donnée transmis. Ainsi nous réduisons le débit du flux, ce qui nous permet de dégager plus de temps à la reconfiguration et d'utiliser moins de paires de liaison HD-SDI. Cette solution nécessite que chacun des modules de traitement du système soit équipé d'un circuit de décompression en entrée et d'un circuit de compression en sortie vers les autres modules de la chaîne du système de traitement. En milieu de post-production de cinéma numérique, il convient généralement que la qualité de la compression soit au moins égale à celle qui est présentée dans la spécification � DCI � (basée sur la spécification � Jpeg2000 �). A titre d'exemple, la spécification DCI impose pour l'ensemble des formats, après compression, un débit maximum de 250 Mbits/s. Dans le cas où on utiliserait une liaison simple HD-SDI (bande passante 1.5 Gbits/s), on obtient alors un temps mort nécessaire à la reconfiguration des FPGA de 19 ms dans le cas du 24 Hz et de 9.5 ms pour le 48 Hz. Les studios de post-production peuvent exiger des contraintes plus fortes que la spécification DCI en termes de qualité d'image. Cela sous-entend une compression plus faible pour garder un maximum d'information pour les traitements appliqués sur les images. Dans ce cas on peut imaginer un compromis entre la paire de liaison HD-SDI que l'on peut utiliser et le taux de compression des images. Mode 3 : Ce mode est une amélioration du mode 2 précédemment décrit. Afin de rendre la taille de la mémoire de programmation de chaque module de traitement indépendante du nombre de traitements qui seront effectués par l'unité de traitement de type FPGA de ce module, on limite la taille de la mémoire de programmation à la taille de stockage d'un seul traitement. Ce mode prévoit donc de télécharger, pendant la phase d'initialisation précédemment décrite, un seul fichier de données de programmation par module de traitement. Comme pour le mode 2, on envoie un mot de commande pendant la transmission des données de � blanking � pour lancer la configuration des unités de traitement de type FPGA de chacun des modules. La spécificité du mode 3 consiste à établir que pendant l'exécution de la première série de traitement vidéo, l'accès aux mémoires de configuration peut se faire sans perturber le fonctionnement des différentes opérations en cours. Ceci nous amène à utiliser encore une fois les temps de � blanking � pour envoyer la deuxième série de traitements vers les mémoires de programmation des modules de traitement et ensuite d'envoyer au moment souhaité les mots de commande pour lancer la reprogrammation des unités de traitement de type FPGA de chacun des modules pour exécuter la deuxième série de traitements vidéo. Exemple 2 : Cet exemple a pour but d'illustrer un exemple d'application d'un système de 25 traitement selon l'invention à un traitement vidéo dit de � post-production � pour le cinéma numérique. La figure 5 illustre différentes étapes classiques de réalisation d'une séquence de cinéma à partir de films de prise de vue (en haut à gauche) pour aboutir à l'un et/ou à l'autre des � produits � finaux suivants : DVD via une étape finale 30 dite de � DVD mastering � 24, cinéma numérique via une étape finale d'édition de fichier numérique 25 (� Digital Cinema �), ou film de projection via une étape finale d'impression de film 26 (� Film printing �). La figure 5 montre bien que l'étape dite de � post- production � 23 est comprise entre une étape de � scannerisation � 22 et l'une des étapes finales 24, 25 ou 26. Lors de l'étape de scannérisation 22, le film de prise de vue est scanné (étape 22) en un ou plusieurs fichiers de données vidéo au format DSM (� Digital Source Master �). L'étape de post-production 23 est destinée à traiter ces fichiers au format � DSM � de manière à obtenir un ou plusieurs fichiers de données vidéo traitées au format DCDM (� Digital Cinema Distribution Master �), en vue de l'une ou l'autre des étapes finales 24,25,26. Le traitement vidéo est avantageusement réalisé à l'aide d'un système de traitement selon l'invention. Ces traitements vidéo sont adaptés d'une manière connue en elle-même pour corriger, par exemple, des défauts issus des conditions d'éclairage, issus de différence de couleurs, issus de différence de Gamma etc... Dans ces fichiers de données traitées qui sont au format DCDM, sont insérées des spécifications du fichier de données, non compressées et non cryptées. La spécification � DCI � (� Digital Cinema Initiative �) décrit les étapes suivantes, notamment une étape de compression et de cryptage des données qui est effectuée avant distribution du film. Il en résulte un format de fichier de distribution dit � DCP � ( � Digital Cinema Package �). Dans le cas de la diffusion en salle de cinéma (voir étape 25 sur la figure 5), ces dernières reçoivent les films au format DCP. Ces salles sont généralement équipées d'un appareil de type � MB � (Média Block) qui est adapté pour décrypter et décompresser le format DCP afin d'extraire des données vidéo qui peuvent être adressées au projecteur numérique via, par exemple, une liaison de type � Dual � ou � Quad HD-SDI �. Pour plus d'information, on pourra se référer à la spécification � DCI � V1.0 du 20 juillet 2005. Pour le traitement vidéo de post-production à l'aide du système de traitement qui vient d'être décrit, les formats d'images utilisés sont par exemple ceux de la norme � DCI � (� Digital Cinéma Initiative �), tels que présentés au tableau 1 : Niveau du Pixels Pixels Fréquence Bits/composante Débit Conteneur Horizontaux verticaux d'images(Hz) (Gbits/s) 1 4096 2160 24 12 7.64 2 2048 1080 48 12 3.82 3 2048 1080 24 12 1.91 Tableau 1 Dans le bus unique de type HD-SDI du système de traitement (voir figure 4) selon l'invention, chaque voie supporte un débit de 1,5Gbits/s (voir standard SMPTE 292M-1998). Les traitements vidéo s'enchaînent les uns derrières les autres entre les différents modules de traitement 19, 20, 21 via un bus vidéo commun de type DUAL HD-SDI (4 :4 :4) (Voir Standard SMPTE 372M-2002), ou via un bus vidéo de type Quad HD-SDI. Les traitements s'effectuent à la volée, donc en temps réel c'est-à-dire que tous les traitements vidéo sont appliqués sans interruption du flux de données vidéo. La présente invention a été décrite en référence à un module de traitement particulier, et à un système de traitement basé sur une chaîne de tels modules. Il est évident pour l'homme du l'art qu'elle peut s'appliquer à d'autres types de module de traitement et à d'autres systèmes de traitement associant ces modules sans sortir du cadre des revendications ci-après. REVENDICATIONS 1. Module de traitement de données vidéo comprenant : a) une unité de traitement vidéo (4), dont la configuration est programmable par des données de programmation, et qui est apte à transformer des données vidéo à traiter en données vidéo traitées, qui est elle-même dotée de: - > une entrée vidéo (12) pour recueillir lesdites données vidéo à traiter, -> une sortie vidéo (13) pour fournir lesdites données vidéo traitées, -> une entrée de configuration (9) pour recueillir lesdites données de programmation, b) un bus d'entrée (14) apte à délivrer un flux de données d'entrée comprenant lesdites données vidéo à traiter, c) un bus de sortie (15) apte à délivrer un flux de données de sortie comprenant lesdites données vidéo traitées, caractérisé en ce que : - ledit bus d'entrée (14) est adapté pour intégrer audit flux de données d'entrée lesdites données de programmation ; - ledit module de traitement comprend également une unité de contrôle (1) qui est reliée audit bus d'entrée (14), qui est apte à séparer les données vidéo à traiter et les données de programmation dans le flux de données d'entrée délivré par ledit bus d'entrée, qui est reliée à l'entrée vidéo (12) de ladite unité de traitement vidéo à configuration programmable (4) pour transmettre à cette unité les données vidéo à traiter après séparation dans ledit flux de données d'entrée, et qui est reliée à l'entrée de configuration (19) de ladite unité de traitement vidéo à configuration programmable (4) pour transmettre à cette unité les données de programmation après séparation dans ledit flux de données d'entrée. 2. Module de traitement selon la revendication 1, caractérisé en ce que, lesdites données vidéo à traiter étant réparties en trames d'image, ledit bus d'entrée (14) est adapté pour intégrer lesdites données de programmation dans des � temps morts �, où chaque � temps mort � est compris entre deux trames d'image successives. 3. Système de traitement de données vidéo comprenant une pluralité de modules de traitement (16, 17, 18) selon la revendication 1 ou 2, caractérisé en ce qu'ils sont disposés en série et en ce que, quelque soit le module de traitement du moment qu'il ne s'agit pas du premier de la série, le bus d'entrée dudit module de traitement correspond au bus de sortie du module de traitement précédent de la série. 4. Système de traitement selon la revendication 3 caractérisé en ce que l'unité centrale de chaque module, sauf, éventuellement, le dernier de ladite série est en outre apte à combiner dans un même flux de données les données vidéo traitées par ce module et les données de programmation des autres modules qui suivent dans ladite série, et à injecter ce flux de données combinées dans le bus de sortie dudit module. 5. Système de traitement selon la revendication 4, caractérisé en ce que lesdites données vidéo traitées étant réparties en trames d'image, ladite combinaison est adaptée pour intégrer lesdites données de programmation dans des � temps morts �, où chaque � temps mort � est compris entre deux trames d'image successives.