FR 2964234 A1 20120302 FR 1003492 A 20100831 La présente invention concerne un procédé de synchronisation de contrôle du rythme d'affichage d'un signal vidéo entre un dispositif émetteur et un dispositif récepteur. De manière générale, la présente invention concerne le domaine des Technologies de l'Information et de la Communication. La présente invention se rapporte plus particulièrement à un système vidéo sans-fil. Ce type de système remplace les câblages traditionnels entre des sources vidéo et des récepteurs vidéo. Un émetteur vidéo transmet un flux vidéo à travers une interface sans-fil vers des récepteurs vidéo. Les systèmes de transport de flux vidéo dans des réseaux doivent résoudre le problème de la synchronisation de lecture vidéo en temps réel. D'un côté, le flux vidéo est généré en se basant sur une première horloge vidéo du dispositif source vidéo, et de l'autre côté, le flux vidéo est lu en se basant sur une seconde horloge vidéo du récepteur. Si les deux horloges ne fonctionnent pas précisément à la même vitesse, cela signifie que les récepteurs vidéo joueront le flux vidéo trop rapidement ou trop lentement. Si le récepteur joue trop rapidement le flux vidéo, il n'aura plus assez de vidéo et la lecture sera interrompue. Si, en revanche, le récepteur joue trop lentement le flux vidéo, il n'aura plus assez d'espace en mémoire tampon pour la réception des paquets vidéo et perdra ainsi des données vidéo. On connaît deux types de solutions pour résoudre le problème des différences dans les vitesses d'écriture et de lecture des données vidéo. Le premier type de solution est basé sur la modification de quantité d'images lues. Dans le cas où le récepteur est plus rapide que la source vidéo, le récepteur va sporadiquement dupliquer une image afin d'augmenter le nombre d'images constituant le flux vidéo reconstitué. Dans le cas inverse où le noeud récepteur est plus lent que la source vidéo, le noeud récepteur va sporadiquement supprimer une image afin de diminuer le nombre d'images constituant le flux vidéo reconstitué. Le principal avantage de cette solution est qu'elle ne modifie aucun des signaux de synchronisation de la vidéo. En effet, l'adaptation de la fréquence image du noeud récepteur par rapport à la fréquence image de la source vidéo est réalisée uniquement en jouant sur la quantité d'images. Le noeud récepteur génère donc ses propres signaux de synchronisation vidéo à partir de son oscillateur local, ce qui est une garantie de la stabilité et de la bonne qualité de ses signaux de synchronisation vidéo. L'inconvénient majeur de cette solution est la suppression d'images vidéo. En effet, cela a pour résultat de dégrader la qualité de restitution du flux vidéo. Le second type de solution est basé sur l'utilisation de boucles à verrouillage de phase ou PLL ("Phase-Locked Loop " en terminologie anglo-saxonne). Une boucle à verrouillage de phase ou PLL a pour fonction de générer un premier signal (signal résultant) d'horloge synchrone à un second signal (signal de référence) d'horloge. Le signal d'horloge résultant a une fréquence multiple ou qui est une fraction du signal d'horloge de référence. Le signal d'horloge résultant est réinjecté dans la PLL afin de permettre une comparaison constante avec le signal de référence dans le but de garantir que le signal d'horloge résultant est toujours synchrone du signal d'horloge de référence et ceci malgré les variations que peut avoir le signal d'horloge de référence. Suivant les implémentations de la PLL, une amplitude et une fréquence de variation donnée est tolérée sur le signal d'horloge de référence. Quand cette tolérance est dépassée, la PLL " décroche " et le signal résultant est stoppé. L'utilisation d'une PLL pour le besoin de l'harmonisation des rythmes d'image d'une source vidéo et d'un noeud récepteur fonctionne comme décrit ci-dessous. Le récepteur reconstitue dans un premier temps une référence temporelle du rythme d'image de la source. II existe trois références temporelles équivalentes respectivement l'horloge pixel (un cycle par pixel), la synchronisation horizontale (un cycle par ligne) et enfin la synchronisation verticale (un cycle par image). Lorsque la source et le récepteur sont séparés par un réseau de communication, l'état de l'art privilégie le transport de références temporelles liées soit à la synchronisation horizontale, soit à la synchronisation verticale, car elles sont moins fréquentes et donc plus aisées à reconstituer sans introduire trop d'erreurs. Ainsi, le récepteur utilise par exemple le signal de synchronisation horizontale de la source vidéo tel que reconstitué par le noeud récepteur comme signal d'horloge de référence de la PLL. Le noeud récepteur fournit comme facteur de division de la PLL le nombre de pixels par ligne pour avoir comme signal d'horloge résultant un signal d'horloge pixel synchrone du signal de synchronisation horizontale de la source vidéo. Ensuite, à partir d'un compteur synchrone de l'horloge pixel ainsi obtenue, il génère un signal de synchronisation horizontale synchrone de l'horloge pixel en fonction d'un nombre prédéterminé de pixels par ligne. De même, à partir d'un compteur synchrone du signal de synchronisation horizontale ainsi obtenu, il génère un signal de synchronisation verticale synchrone du signal de synchronisation horizontale en fonction d'un nombre désiré de lignes par image. De même, on insère des périodes dites invisibles de l'image (" horizontal blanking " et " vertical blanking " en terminologie anglo-saxonne), utilisées pour l'insertion de données supplémentaires de contrôle ou pour permettre la prise en compte des informations de synchronisation en anticipation des périodes actives des données image et, ainsi, autoriser un temps de traitement préalable au traitement des données images. A l'inverse de la première solution, la solution des PLLs ne permet pas l'usage de signaux de synchronisation vidéo générés par le noeud récepteur. Au contraire les signaux de synchronisation vidéo sont générés à partir des PLLs et vont varier au gré des variations du signal vidéo source tel que reconstitué par le noeud source. Cependant, ce système assure que tous les signaux de synchronisation vidéo résultants (horloge pixel, synchronisation horizontale, synchronisation verticale) varieront de manière complètement synchrone car les signaux de synchronisation horizontale et de synchronisation verticale sont directement obtenus par une multiplication de l'horloge pixel. Il n'y donc pas de risque de décrochage de l'affichage due à la qualité des signaux de synchronisation vidéo. De plus, cette solution ne présente pas les inconvénients de la première solution dans la mesure où elle respecte strictement l'intégrité des données vidéo (pas de suppression d'images). En revanche, cette solution repose sur le fait que le signal de synchronisation de référence reconstitué par le récepteur soit d'une certaine stabilité. En effet, il a été vu ci-dessus que les PLLs sont sensibles aux variations (gigue ou "jitter " en anglais) du signal d'horloge de référence. Si le signal de référence varie trop (par exemple, dans le cas d'un basculement de source vidéo), les PLLs ne sont plus en mesure de fournir un signal d'horloge résultant. Les PLLs capables d'accepter des signaux d'horloge de référence fortement perturbés sont très complexes et très coûteuses à mettre en oeuvre. Par ailleurs, les protocoles permettant une reconstitution peu perturbée du signal de synchronisation de la source vidéo par le récepteur sont tout aussi complexes et coûteux à mettre en oeuvre. II est également connu, par le brevet américain US 5 517 253, un procédé de synchronisation des rythmes de lecture d'image d'un dispositif de réception sur le rythme d'image d'une source vidéo. Le procédé décrit dans ce document de l'état de la technique est basé sur l'ajout et la suppression de pixels dans la partie invisible des lignes. Bien qu'elle ne nécessite pas de PLL et bien qu'elle respecte l'intégrité des données, la solution décrite dans ce document de l'état de la technique implique toutefois l'altération des deux signaux de synchronisation horizontale et verticale. Un but de la présente invention est de fournir une solution pour la synchronisation du rythme de lecture de la vidéo par un récepteur sur le rythme de la source vidéo telle que l'intégrité des données vidéo soit préservée (pas de suppression d'images). Un autre but de la présente invention est de fournir une solution pour la synchronisation du rythme de lecture de la vidéo par un récepteur sur le rythme de la source vidéo telle que la qualité des signaux de synchronisation de la vidéo soit la plus stable possible, c'est-à-dire que les corrections effectuées sur les signaux de synchronisation soient les plus " faibles " possible. Un autre but de la présente invention est de fournir une solution pour la synchronisation du rythme de lecture de la vidéo par un récepteur sur le rythme de la source vidéo telle que le coût de la mise en oeuvre de la solution soit raisonnable (pas d'utilisation de PLL). La présente invention vise à atteindre au moins l'un des buts précités en proposant un procédé de contrôle du rythme d'affichage d'un signal vidéo issu d'une source vidéo, transmis par un dispositif émetteur (DE) vers un dispositif récepteur (DR) et destiné à être affiché sur un dispositif d'affichage, le signal vidéo comprenant des images, chaque image contenant des lignes actives incluant des informations sur des pixels à afficher par le dispositif d'affichage et des lignes inactives n'incluant pas d'informations sur des pixels à afficher par le dispositif d'affichage, caractérisé en ce que le rythme d'affichage est contrôlé par au moins un premier signal de contrôle (SV1) synchronisé au rythme image de la source vidéo , le procédé comportant les étapes suivantes - calcul d'une dérive entre le premier signal de contrôle (SV1) et un signal (SVL) synchronisé au rythme image au niveau du dispositif récepteur ; - en fonction de la dérive calculée, adaptation du nombre de lignes inactives dans une image du signal vidéo au niveau du dispositif récepteur. La détermination d'une éventuelle dérive (une telle dérive traduit une non synchronisation entre les rythmes image ou cadences définies respectivement par la source vidéo et par le dispositif récepteur) permet de décider si une correction de la dérive doit être appliquée pour recaler les signaux SV1 et SVL l'un par rapport à l'autre. On notera que le rythme image correspond à un nombre d'image par seconde, c'est-à-dire à un certain débit de données. Le rythme image peut également être défini par la fréquence d'une horloge dont le front montant est calé sur le début de chaque image. Le signal SVL est par exemple recalé sur le premier signal de contrôle SV1. Le rythme d'arrivée du signal ou flux vidéo sert ainsi de référence. On notera que le signal local au dispositif récepteur basé sur une horloge locale) pour la détermination d'une dérive peut être un signal de synchronisation de l'affichage d'images du signal vidéo. Le premier signal de contrôle SV1 est par exemple un signal de synchronisation verticale régénéré par le dispositif récepteur. On notera que l'adaptation du nombre de lignes inactives d'une image a pour effet de moduler la vitesse de lecture des données vidéo (pixels) de l'image. Le rythme de lecture des données vidéo du signal vidéo par le dispositif récepteur est ainsi asservi au rythme de génération des données vidéo par la source vidéo grâce à l'adaptation (ajout et de la suppression) du nombre de lignes inactives dans une image à afficher. Le contrôle proposé par l'invention respecte strictement l'intégrité des données vidéo (pixels à afficher) car les lignes inactives ajoutées et supprimées le sont dans la partie non visible de l'image. Dans un exemple de réalisation, les signaux de contrôle comprennent un signal d"horloge pixel et un signal de synchronisation horizontale (SHL), ainsi qu'un signal de synchronisation verticale (SV1). Les signaux de contrôle du signal vidéo sont le plus stable possible. En effet, l'horloge pixel est totalement stable car générée localement au dispositif récepteur sans modulation. Le signal de synchronisation horizontale est totalement stable car généré localement sans modulation. Seul le signal de synchronisation verticale est asservi progressivement (asservissement doux) au rythme du signal de synchronisation verticale de la source vidéo. Le coût de la mise en oeuvre du contrôle selon l'invention est raisonnable car, d'une part, il n'y a pas de PLL de mise en oeuvre pour la correction de dérive par cette solution. Et, d'autre part, la régénération du signal de synchronisation verticale de la source vidéo par le dispositif récepteur ne nécessite pas une stabilité aussi grande que celle imposée par une PLL. En effet, le signal de synchronisation verticale reconstitué sert à détecter un déphasage de plus ou moins une ligne avec par exemple le signal de synchronisation verticale locale. Cette comparaison peut être réalisée raisonnablement avec une précision de quelques pixels. On notera que le dispositif émetteur peut être inclus ou non dans la source vidéo. S'il ne fait pas partie de la source le dispositif émetteur peut être associé à la source, par exemple en étant connecté à cette dernière. Selon une caractéristique, le rythme d'affichage est contrôlé également par au moins un deuxième signal de contrôle synchronisé au rythme image du dispositif récepteur. Ainsi, le rythme d'affichage du signal vidéo est contrôlé en combinant au moins un signal de contrôle local au dispositif récepteur et un signal de contrôle (SV1) qui suit le rythme des données vidéo de la source vidéo (ex : rythme imposé par une horloge de la source vidéo). On notera que le deuxième signal de contrôle est par exemple un signal de synchronisation horizontale et qu'un troisième signal de contrôle est par exemple un signal d'horloge pixel. Selon une caractéristique, le procédé comporte une étape de suppression d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en avance de phase par rapport à la source vidéo. Selon une caractéristique, le procédé comporte une étape d'ajout d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en retard de phase par rapport à la source vidéo. Qu'il y ait une avance de phase ou un retard de phase entre les signaux composés la compensation est effectuée sur les lignes inactives d'une image et donc sans altérer les signaux de synchronisation. Selon une caractéristique, le procédé comporte en outre une étape de réajustement, par le dispositif récepteur, du front montant du premier signal de contrôle (SV1) pour qu'il se réaligne sur un début de ligne lorsque la correction de la dérive calculée ne se traduit pas par un nombre entier de ligne(s) inactive(s). On cale ainsi le premier signal de contrôle sur un début de ligne lorsque, après suppression ou ajout d'une ligne, une dérive subsiste entre les signaux. Selon une caractéristique, le procédé comporte une étape de génération du premier signal de contrôle (SV1) par le dispositif récepteur. Selon une caractéristique, le calcul d'une dérive est effectué de manière régulière. Le dispositif récepteur peut en effet surveiller régulièrement au cours du temps l'éventuelle dérive entre les signaux. L'invention a également pour objet un dispositif de contrôle du rythme d'affichage d'un signal vidéo issu d'une source vidéo, transmis par un dispositif émetteur (DE) et destiné à être affiché sur un dispositif d'affichage, le signal vidéo comprenant des images, chaque image contenant des lignes actives incluant des informations sur des pixels à afficher par le dispositif d'affichage et des lignes inactives n'incluant pas d'informations sur des pixels à afficher par le dispositif d'affichage, caractérisé en ce que le rythme d'affichage est contrôlé par au moins un premier signal de contrôle (SV1) synchronisé au rythme image de la source vidéo, le dispositif de contrôle comportant : - des moyens de calcul d'une dérive entre le premier signal de contrôle (SV1) et un signal (SVL) synchronisé au rythme image du dispositif récepteur, - des moyens d'adaptation, en fonction de la dérive calculée, du nombre de lignes inactives dans une image du signal vidéo. Selon d'autres caractéristiques du dispositif : - le rythme d'affichage est contrôlé également par au moins un deuxième signal de contrôle synchronisé au rythme image du dispositif récepteur. - le rythme d'affichage est contrôlé par le deuxième signal de contrôle qui est un signal de synchronisation horizontale (SHL) et par un troisième signal de contrôle qui est un signal d'horloge pixel. - il comporte des moyens de suppression d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en avance de phase par rapport à la source vidéo. - il comporte des moyens d'ajout d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en retard de phase par rapport à la source vidéo. - il comporte en outre des moyens de réajustement du front montant du premier signal de contrôle (SV1) pour qu'il se réaligne sur un début de ligne lorsque la correction de la dérive calculée ne se traduit pas par un nombre entier de ligne(s) inactive(s). - il comporte des moyens de génération du premier signal de contrôle (SV1). - le premier signal de contrôle est un signal de synchronisation verticale. - le calcul d'une dérive est effectué de manière régulière. L'invention a également pour objet un système de communication comprenant une source vidéo, un dispositif émetteur (DE), un dispositif récepteur (DR), un dispositif d'affichage et un dispositif de contrôle du rythme d'affichage d'un signal vidéo issu de la source vidéo, transmis par le dispositif émetteur (DE) vers le dispositif récepteur (DR) et destiné à être affiché sur un dispositif d'affichage, le signal vidéo comprenant des images, chaque image contenant des lignes actives incluant des informations sur des pixels à afficher par le dispositif d'affichage et des lignes inactives n'incluant pas d'informations sur des pixels à afficher par le dispositif d'affichage, caractérisé en ce que le rythme d'affichage est contrôlé par au moins un premier signal de contrôle (SV1) synchronisé au rythme image de la source vidéo, le dispositif de contrôle comportant : - des moyens de calcul d'une dérive entre le premier signal de contrôle (SV1) et un signal (SVL) synchronisé au rythme image du dispositif récepteur, - des moyens d'adaptation, en fonction de la dérive calculée, du nombre de lignes inactives dans une image du signal vidéo. La présente invention se rapporte également à un programme d'ordinateur chargeable dans un système informatique, ledit programme comprenant des instructions permettant la mise en oeuvre du procédé tel que brièvement exposé ci-dessus, lorsque ce programme est chargé et exécuté par un système informatique. On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux dessins annexés sur lesquels : - la Figure 1 illustre un exemple de système de communication selon l'invention ; - la Figure 2 représente un dispositif de communication générique capable d'être utilisé comme noeud émetteur 102 (DE) ou comme noeud récepteur 103 (DR) ; - la Figure 3 illustre des détails d'interconnexion entre modules dans la partie émetteur 206 de la Figure 2 ; - la Figure 4a illustre un format possible de paquet vidéo ; - la Figure 4b représente l'algorithme exécuté par le module de transmission de paquets vidéo 216 de la Figure 3 ; - la Figure 5a est une vue détaillée du module " partie d'affichage " 205 de la Figure 2 ; - la Figure 5b est une vue détaillée du module "Vsync regen " 504 de la Figure 5a ; - la Figure 5c représente l'algorithme exécuté par le module 500 de la Figure 5a ; - la Figure 6a illustre l'algorithme mis en oeuvre par le module de gestion de dérive 506 de la Figure 5a ; - la Figure 6b représente l'algorithme exécuté par le module " Vsync monitor " 530 de la Figure 5b ; - les Figures 7a et 7b illustrent des signaux digitaux permettant de contrôler le rythme d'affichage d'un flux vidéo ; et - les Figures 8a, 8b et 8c illustrent sous la forme d'algorithmes le fonctionnement du module " video synchro generator " 503 de la Figure 5a. La Figure 1 illustre un exemple de système de communication sans-fil de flux vidéo. Le système vidéo comprend notamment une source vidéo 101. Cette source vidéo 101 peut par exemple être un lecteur Blu-Ray, un décodeur numérique (" set top box en terminologie anglo-saxonne) ou un disque dur multimédia. La source vidéo génère un flux vidéo à un rythme image ou débit d'image par seconde donné. La source vidéo 101 est connectée à un dispositif émetteur (DE) ou noeud émetteur 102 à travers une connexion vidéo numérique standard (par exemple conforme au standard HDMI). On notera que la source et le dispositif émetteur peuvent alternativement faire partie du même appareil de communication. Le dispositif émetteur 102 communique avec un dispositif récepteur (DR) ou noeud récepteur 103 au moyen d'une transmission sans-fil (par exemple 60 GHz 801.15.3c). Le noeud récepteur 103 est connecté à un dispositif d'affichage 104 tel qu'un écran au moyen d'une connexion vidéo numérique standard 105 (par exemple au standard HDMI). La Figure 2 décrit un dispositif de communication ou noeud générique capable d'être utilisé comme noeud émetteur 102 ou comme noeud récepteur 103. Le noeud générique est constitué d'une partie contrôleur vidéo 204 et d'une partie contrôleur de réseau 207. La partie contrôleur de réseau 207 est en charge de mettre en oeuvre les communications sans-fil des données vidéo et des données de contrôle. La partie contrôleur 204 comprend une sous-partie d'affichage 205 et une sous-partie source 206. La sous-partie d'affichage 205 est en charge de jouer la vidéo reçue (sous la forme d'un flux vidéo) du contrôleur de réseau 207 sur un dispositif d'affichage vidéo tel que le dispositif d'affichage 104. La sous-partie source 206, quant à elle, est chargée de capturer un flux vidéo issu d'un dispositif source de vidéo tel que la source 101 et de l'envoyer au noeud récepteur tel que le noeud 103 à travers la partie contrôleur de réseau 207. Les deux parties 204 et 207 sont contrôlées par un système CPU composé d'une unité de traitement de données (CPU) 201, d'une mémoire vive (RAM) 202 et d'une mémoire morte (ROM) 203. La partie contrôleur de réseau 207 est un sous-système de communication à 60 GHz standard, mettant en oeuvre soit le standard IEEE 802.15.3 soit le standard WirelessHD. Il est composé d'un module MAC 208, d'un module PHY 209, d'un module d'antenne de transmission 210, et d'un module d'antenne de réception 211. Pour la description détaillée de ces modules, le lecteur peut se référer soit au standard IEEE (standard 802.15.3 modification c) soit auprès du consortium WirelessHD. Le contrôleur de réseau 207 fait également fonctionner un protocole de réseau qui garantit que tous les noeuds du réseau ont accès à une seule référence temporelle. Par exemple, le contrôleur de réseau peut mettre en oeuvre le protocole IEEE 1588. La sous-partie source 206 de la partie contrôleur vidéo 204 comprend un module récepteur HDMI 215 capable de recevoir un flux vidéo au format HDMI d'une source vidéo, à travers un connecteur HDMI. Ce module récepteur HDMI 215 fournit en sortie des données d'images ou pixels sur un bus, ainsi que plusieurs signaux de synchronisation ou de contrôle vidéo. Par exemple, trois signaux de synchronisation vidéo, à savoir un signal d'horloge pixel, un signal de synchronisation horizontale et un signal de synchronisation verticale, sont transmis à deux modules 216, 217. On notera que le module récepteur HDMI 215 peut par exemple être 10 un module commercialisé sous la référence AD9880 par la société Analog Device. Le module 216 est un module de transmission de paquets vidéo qui reçoit du module récepteur 215 des données vidéo. Le module 216 reçoit également de la part du module 217, appelé 15 module "Vsync Sampler", des informations temporelles, appelées horodatages ou étiquettes temporelles (connues en terminologie anglo-saxonne sous le terme "time stamp"). Le module 216 élabore des paquets de données vidéo comme il sera décrit de façon plus détaillée en référence à la Figure 3 et les transmet à la 20 partie contrôleur de réseau 207. Le module 217, quant à lui, est chargé de l'échantillonnage des apparitions du signal de synchronisation verticale provenant du module récepteur HDMI 215. L'échantillonnage est plus particulièrement réalisé en générant un 25 horodatage ("time stamp") par rapport à un temps réseau servant de référence, tel qu'il est reçu par la partie contrôleur de réseau 207. L'horodatage ainsi généré est transmis au module 216 afin d'être inséré dans l'en-tête d'un paquet. La sous-partie d'affichage 205 comprend un module 214 de 30 réception de paquets vidéo qui reçoit des paquets de la partie contrôleur de réseau 207. Le module 214 extrait des paquets reçus les données d'image ou pixels contenus dans ces derniers afin de les stocker et extrait l'horodatage (time stamp) qui est ensuite transmis à un module 213 de gestion de synchronisation RX. Le module 213 génère des signaux de synchronisation ou de contrôle vidéo et les transmet à un module transmetteur HDMI 212. Le module 213 lit également les pixels stockés dans le module 214 et les transmet au module 212. Cette sous-partie d'affichage 205 sera décrite plus en détail en référence aux Figures 5a et 5b. Le module 212 met en oeuvre un contrôleur TX HDMI en vue du contrôle de l'affichage des données sur le dispositif d'affichage 104. Plus particulièrement, le module 212 reçoit en entrée les pixels véhiculés par un bus ainsi que les trois signaux de synchronisation ou de contrôle vidéo, à savoir respectivement un signal d'horloge pixel, un signal de synchronisation horizontale et un signal de synchronisation verticale. Le module 212 pilote en sortie un connecteur HDMI. On notera que le module transmetteur HDMI est par exemple commercialisé par la société Analog Device sous la référence de circuit 20 AD9889B. Les modules récepteur 215 et transmetteur 212 sont contrôlés et initialisés par l'unité CPU 201 par l'intermédiaire d'un bus I2C non représenté par souci de clarté. Par ailleurs, l'unité CPU implémente un pilote logiciel HDMI qui peut 25 être obtenu à partir du fabricant de puces ou circuits conformes au standard HDMI. On notera qu'un dispositif ou noeud émetteur dispose de la partie contrôleur vidéo 204 qui inclut la sous-partie source 206. Toutefois, pour la fonction de dispositif ou noeud émetteur, la sous- 30 partie d'affichage 205 n'est pas nécessaire. De même, un dispositif ou noeud récepteur dispose d'une partie contrôleur vidéo 204 incluant la sous-partie d'affichage 205 sans toutefois nécessairement inclure la sous-partie source 206 qui n'est pas nécessaire pour cette fonctionnalité du noeud. Comme indiqué plus haut, la Figure 3 illustre de façon plus détaillée les interconnections entre les différents modules de la sous-partie source 206 de la Figure 2. Le module de réception HDMI 215 reçoit en provenance d'un connecteur HDMI non représenté sur la Figure 3, un flux de données vidéo HDMI 308 et fournit en sortie les différents types de données reçues. Plus particulièrement, le module 215 fournit un bus 300 de données d'image ou pixels ainsi qu'un signal de contrôle "de" 311 appelé "Data Enable" et des signaux de contrôle de synchronisation vidéo 301 (signal d'horloge pixel), 302 (signal de synchronisation horizontale) et 304 (signal de synchronisation verticale). Le module échantillonneur 217 reçoit du module récepteur HDMI 215 un signal 304 appelé "Vsync" et reçoit de la partie contrôleur réseau 207 une référence temporelle de réseau 305 ("network time" en terminologie anglo-saxonne). Le module 217 génère à son tour et transmet au module 216 des horodatages 306 ("time stamps"). Le module de transmission de paquets vidéo 216 reçoit du module récepteur HDMI 215 les différentes données précitées 300, 311, 301, 302 et 304 et du module 217 les horodatages 306. Le module 216 élabore ainsi des paquets de données vidéo 307 sur la base des informations et données précédentes et les transmet à la partie 25 contrôleur de réseau 207. La Figure 4a illustre un format possible de paquets de données vidéo. La structure du paquet vidéo représenté comprend un entête 400 et une partie contenant des données utiles appelée charge utile 401 (connue en 30 terminologie anglo-saxonne sous le terme de "payload"). L'entête 400 comprend plusieurs champ parmi lesquels un champ 402 d'indication de début d'image ("start of image flag" en terminologie anglo-saxonne). Cette balise est définie par le module 216 des Figures 2 et 3 lorsque ce dernier construit le premier paquet d'une image. L'entête 400 comprend également un champ 403 d'horodatage (connu en terminologie anglo-saxonne sous le terme "time stamp field") qui est défini par le module 216 lors de la construction du premier paquet d'une image. L'entête 400 comprend également un champ 404 de numéro de première ligne. Ce champ 404 contient le numéro de la première ligne d'une image dans la charge utile 401. On notera que chaque paquet peut transporter plusieurs lignes d'une même image. Ce champ est défini par le module 216 lors de l'élaboration de la charge utile 401. L'entête 400 comprend également un champ 405 d'indication de numéro de dernière ligne. Ce champ contient le numéro de la dernière ligne dans la charge utile 401. Ce champ est défini par le module 216 lors de l'élaboration de la charge utile 401. La charge utile 401 contient les lignes du flux vidéo qui vont de la première ligne représentée sur al Figure 4a par la référence 406 (indiquée par le champ 404) à la dernière ligne représentée par la référence 407 (indiquée par le champ 405). Comme on le verra par la suite, ces lignes du flux vidéo comprennent des informations sur des pixels à afficher par un dispositif d'affichage. La Figure 4b est un algorithme exécuté par le module de transmission de paquets vidéo 216 des Figures 2 et 3 dans un dispositif ou noeud émetteur, tel que celui référencé 102 sur la Figure 1. Cet algorithme comprend une succession d'étapes ou d'instructions (portions de code logiciel) qui sont exécutées par le module 216 en cas d'émission de données vers un dispositif ou noeud récepteur, tel que celui référencé 103 sur la Figure 1. L'algorithme comprend une première étape 410 d'attente du début d'une image. Le début d'une image intervient lorsque le module de réception HDMI 215 des Figures 2 et 3 fournit le signal de synchronisation de contrôle vertical Vsync. Lorsque le début d'une nouvelle image est détectée l'étape 410 est suivie d'une étape 411 au cours de laquelle un horodatage ("time stamp") 306 est fourni par le module échantillonneur 217. L' horodatage 306 représente l'instant d'apparition du signal "Vsync" tel que détecté à l'étape 410. Cet instant est défini par rapport à un temps de référence réseau fourni par la partie contrôleur de réseau 207. Au cours de l'étape suivante 412, l'entête 400 (Figure 4a) du paquet vidéo incluant l'horodatage 306 obtenu à l'étape 411 est construit. Au cours de l'étape suivante 413, la charge utile 401 du paquet vidéo est construite en concaténant plusieurs lignes de flux vidéo (par exemple 16 lignes) qui constituent, par exemple, des lignes actives au sens où ces lignes incluent des informations sur des pixels à afficher par un dispositif d'affichage. Au cours de l'étape suivante 414, le paquet de données vidéo ainsi construit est transmis à la partie contrôleur réseau 207 de la Figure 2. L'étape suivante 415 de la Figure 4b est un test permettant de déterminer si la fin de l'image concernée dans le flux vidéo est atteinte ou non. On considère que la fin de l'image est atteinte lorsque toutes les lignes de l'image ont été envoyées. On notera que le nombre de lignes par image dépend du format vidéo utilisé. Les informations sur le format vidéo utilisé sont fournies par le module récepteur HDMI 215 des Figures 2 et 3 à l'unité de traitement CPU 201. Cette unité 201 fournit ensuite au module transmetteur de paquets vidéo 216 les informations sur le nombre de lignes par image du flux vidéo. Dans le cas où la fin de l'image concernée n'a pas été atteinte (nombre de lignes de l'image non atteint), l'étape 415 est suivie d'une étape 416. Au cours de cette étape, un entête de paquets de données vidéo est construit. Cet entête est destiné à un paquet vidéo qui ne contient pas le début de l'image. Dans cet entête de paquet, le champ « horodatage » 403 n'est pas renseigné L'étape 416 est suivie de l'étape 413 déjà décrite au cours de laquelle la charge utile d'un paquet est construite. Dans le cas où la fin de l'image a été atteinte (test de l'étape 415), l'étape 415 est suivie de l'étape d'attente d'image 410 déjà décrite. La Figure 5a représente de façon détaillée la sous-partie d'affichage 205. La sous-partie d'affichage 205 est utilisée par le dispositif ou noeud récepteur 103 afin d'extraire la vidéo envoyée par le dispositif ou noeud émetteur 102 et d'afficher cette vidéo extraite sur le dispositif d'affichage 104. La sous-partie d'affichage 205 comprend le module 214 en charge de la réception des paquets vidéo et le module 213 en charge de générer les signaux de synchronisation ou de contrôle vidéo ainsi que le flux de pixels associé. Les paquets et signaux sont ensuite transmis au module d'interface vidéo 212 (module de transmission). Le module 214 comprend un module de réception du réseau (" Rx from network ") 500 qui est en charge de récupérer les données de synchronisation telles que présentes dans les entêtes 400 des paquets (Figure 4a) et d'envoyer ces données de synchronisation à un module "Vsync regen " 504 du module 213. Le module 500 doit aussi extraire les données vidéo telles que présentes dans la partie utile 401 des paquets et stocker ces données vidéo ainsi extraites dans un moyen de stockage " FIFO vidéo " 501. L'algorithme détaillé du fonctionnement du module 500 sera décrit en référence à la Figure 5c. Le module 213 comprend le module " Vsync regen" 504 déjà mentionné dont la fonction est de régénérer progressivement un signal, nommé peer-vsync " 507 (signal de contrôle synchronisé au rythme image de la source vidéo, noté aussi SV1), représentatif du signal de synchronisation verticale de la source 101. La reconstitution du signal de synchronisation verticale se fait à partir des informations de synchronisation reçues du module 500. Le module "Vsync regen " 504 a une capacité limitée à une régénération qualifiée de " douce " (par exemple pas plus de 10 pixels toutes les 3 images). Si la différence entre le signal de synchronisation verticale de la source 101 et le signal de synchronisation régénéré " peer_vsync " 507 est supérieur à la capacité de synchronisation " douce " du module " Vsync Regen " 504, alors la fréquence du signal d'horloge pixel local 514 est changée dans le module 515 qui la génère. Les détails de réalisation du module " Vsync regen " 504 sont représentés sur les Figures 5b et 6b. Le signal " peer_vsync " 507 (signal de contrôle SV1) est fourni par le module 504 en entrée d'un module de détection de différence de phase ("phase detector ") 505. L'autre entrée du détecteur 505 reçoit un signal "Vsync" 508 (signal de synchronisation verticale aussi noté SVL) fourni par un module (" video synchro generator ") 503. Le module de génération de synchronisation vidéo 503 génère les signaux de synchronisation vidéo en fonction du signal d'horloge pixel local 514 et de paramètres représentatifs du format vidéo souhaité (nombre de pixels par ligne, nombre de lignes par image, durée des signaux de synchronisation verticale et horizontale, ...). Le fonctionnement de ce module ainsi que le détail des paramètres du format vidéo sont illustrés sur les Figures 8a, 8b et 8c. Les paramètres de format vidéo sont stockés par l'unité CPU 201 dans une mémoire RAM 502. Le démarrage du module " video synchro generator " 503 est synchronisé sur le premier front montant du signal régénéré " peer_vsync " 507. Le module de détection 505 calcule la différence de phase entre le signal de synchronisation verticale du dispositif ou noeud récepteur 103, " Vsync " 508 (signal SVL synchronisé au rythme image du dispositif récepteur) et le signal de synchronisation verticale de la source vidéo 101, reconstitué progressivement et représenté par le signal " peer_vsync " 507 (SV1). La mise en oeuvre d'un module de détection de différence de phase est bien connue de l'homme du métier et ne sera donc pas décrite plus avant ici. Un module de gestion de dérive (" drift manager ") 506 reçoit les informations de différence de phase fournies par le module 505 et, en fonction de la nature de la différence ou dérive constatée (positive, négative) et de l'importance de la différence ou dérive constatée (moins d'une ligne, plus d'une ligne), le module 506 actionne les commandes " add_line " 509 ou " remove line " 510 à destination du module de génération de synchronisation vidéo 503. Sur réception de l'acquittement d'une des deux commandes ("ack_change" 511) par le module 503, le module 506 envoie au module 504 une commande " realign " 525 pour réaligner le signal " peer vsync " 507 sur le début de ligne. Le détail du module de gestion de dérive 506 est illustré à la Figure 6a. Le module " video synchro generator " 503 agit sur la durée de la période de masquage vertical (" vertical_blanking " en terminologie anglo-saxonne) de l'image sur réception des commandes " add_line " 509 ou " remove_line " 510. La ou les lignes ajoutées ou supprimées en début d'image à afficher dépendent, pour leur nombre, de la grandeur de la différence ou dérive calculée précédemment. Ces lignes sont " invisibles " à l'affichage et sont qualifiées de lignes inactives en ce sens qu'elles ne contiennent pas d'informations sur des pixels d'image à afficher. L'action du module 503 se situe au niveau de la période dite " Back porch lines " 913 des Figures 7a et 7b. Sur réception d'une commande " remove_line " 510 le module 503 raccourcit la durée de la période " Back porch lines " 913 d'une ligne. Sur réception d'une commande " add line " 509, le module 503 rallonge la durée de la période " Back porch lines " 913 d'une ligne. Une fois la commande exécutée, le module 503 envoie au module 506 le signal d'acquittement " ack change " 511 déjà mentionné. Le module 212 transmet le flux vidéo vers le dispositif d'affichage 104 à partir du signal " peer_vsync " 507 (SV1) tel que fourni par le module " Vsyncregen " 504, de signaux " Hsync " 512 (SHL) et " de " 513 tels que fournis par le module 503, du signal d'horloge pixel local " pixel_clock " 514 et d'un bus de pixels extrait du moyen de stockage 501. Le moyen de stockage 501 est lu au rythme du signal " de " 513 qui définit les instants correspondant aux pixels " actifs " dans les lignes actives de l'image à afficher (voir Figures 7a et 7b). Le module 515 de génération du signal d'horloge pixel local 514 (ce signal cadence/rythme la durée d'affichage des pixels) est par exemple composé d'un oscillateur à quartz générant une fréquence de 24 MHz, d'une PLL avec un ratio de 116/100, générant ainsi une horloge à 27,84 MHz, puis d'un multiplieur permettant d'atteindre la fréquence pixel telle que définie par le format vidéo utilisé (information contenue dans la mémoire RAM 502). Deux autres ratio pouvant être utilisés en plus du 116/100, à savoir le 117/100 et le 115/100 au cas où la capacité de synchronisation " douce " du module "Vsync regen " 504 est trop limitée. L'invention est avantageusement mise en oeuvre dans le dispositif ou noeud récepteur 103 puisque le module 213 est complètement synchrone ("full synchronous" en anglais). En effet, ce module ne dépend que d'un seul signal d'horloge, à savoir le signal d'horloge pixel " pixelclock " 514. D'autres implémentations à base de PLL dépendraient d'au moins deux signaux d'horloge : une horloge pixel locale telle que l'horloge 514 et une horloge résultant de la PLL. L'horloge pixel locale 514 peut être générée à partir d'une PLL dans le module 515, mais le signal d'horloge pixel 514 reste la seule source d'horloge pour tous les autres modules. De plus, cette mise en oeuvre garantit une modulation douce de la phase du signal de synchronisation verticale " peer_vsync " 507 par le module " Vsync Regen " 504, évitant ainsi une correction brutale de la synchronisation. Par ailleurs, cette mise en oeuvre respecte complètement l'intégrité des données vidéo puisque le module " vidéo synchro generator " 503 ne supprime que des lignes non actives dans les images à afficher. En outre, cette mise en oeuvre n'altère pas le signal de synchronisation horizontale Hsync 512 dans la mesure où le module " video synchro generator " 503 ne modifie pas la durée des lignes actives et non actives mais seulement leur nombre dans une image. La Figure 5b représente de façon plus détaillée le module "Vsync regen " 504. Ce module régénère le signal de synchronisation verticale (SV1) de la source 101 dans le dispositif ou noeud récepteur 103 à partir des informations de synchronisation (horodatages). Ces informations de synchronisation sont insérées dans les entêtes de paquet par le dispositif ou noeud émetteur 102 (étape 412 de la Figure 4b), ensuite ces informations de synchronisation sont extraites des entêtes dans le dispositif ou noeud récepteur 103 par le module " RX from network " 500, puis envoyées au module " Vsync regen " 504. Les informations de synchronisation sont exploitées par un module " Vsync monitor" 530 tel que décrit plus loin en référence à la Figure 6e. Le module " Vsync monitor " 530 observe la période du signal de synchronisation verticale de la source 101 et module la durée nominale du signal régénéré " peer_vsync " 507 (SV1) en changeant la valeur d'un registre " nominal Vsync " 516. On notera que le signal SV1 généré au dispositif récepteur est modifié pixel par pixel en fonction de la dérive du dispositif récepteur par rapport à la source vidéo. Un compteur 517 alimenté par le signal d'horloge pixel 514 est comparé au registre " nominal vsync " 516 par un comparateur 518. A chaque fois que le compteur atteint la valeur nominale de la période de synchronisation verticale, le comparateur 518 génère une impulsion vers un module " Vsync niveau haut " 522 et vers la commande de remise à zéro du compteur 517. Le module " Vsync niveau haut " maintient le signal " peer_vsync " 507 à l'état haut pendant une durée définie par le format vidéo utilisé. Cette information est contenue dans la mémoire RAM 502. Un exemple de ces paramètres sera fourni ultérieurement en référence à la Figure 7b. Un module de temps réseau (" network time ") 519 génère une information temporelle d'horodatage en lien avec l'horloge du réseau et telle que fournie par la partie contrôleur réseau 207. A chaque front montant du signal " peer_vsync " 507, le module 519 génère un horodatage ("time stamp") et l'envoie au module " Vsync monitor " 530. Le registre " nominal Vsync " 516 peut aussi recevoir une commande de réalignement realign ") 525 envoyée par le module de gestion de dérive 506 (Figure 5a). Cette commande comprend un temps de cycle et un signe + ou -. Sur réception d'un signe -, le registre "nominal Vsync " 516 augmente sa valeur en y ajoutant la différence entre sa propre valeur et le temps de cycle inclus dans la commande. Sur réception d'un signe +, le registre " nominal vsync " 516 diminue sa valeur en y retranchant la différence entre sa propre valeur et le temps de cycle inclus dans la commande. La Figure 5c illustre un algorithme exécuté par le module 500 de la 10 Figure 5a (dispositif ou noeud récepteur 103). Cet algorithme comporte une succession d'étapes, instructions ou portions de code logiciel qui sont exécutés lors de l'exécution de l'algorithme. L'algorithme comprend une première étape 700 d'attente de réception d'un paquet de données vidéo de la partie contrôleur réseau 207 de 15 la Figure 2. Dès qu'un paquet est reçu l'étape suivante 701 est exécutée. Au cours de cette étape, un test est pratiqué afin de déterminer si l'entête du paquet contient une balise indiquant un début d'image ("flag" 402 de la Figure 4a). 20 En cas de réponse négative, l'étape 700 est de nouveau exécutée. Dans le cas contraire (début d'image), une étape suivante 702 est exécutée. Au cours de cette étape, un horodatage ("time stamp") est extraite de l'entête du paquet et l'étape suivante 703 est exécutée. 25 Au cours de cette étape, l'horodatage extrait est transmis au module "Vsync monitor" 530 de la Figure 5b et l'étape suivante 704 est exécutée. Au cours de cette étape, les lignes actives du flux vidéo de la partie utile 401 du paquet de la Figure 4a sont stockées dans le moyen de stockage 501 de la Figure 5a et l'étape suivante 705 est exécutée. 30 Au cours de cette étape, un test est pratiqué afin de déterminer si la fin d'une image est atteinte. La fin d'une image est atteinte lorsque toutes les lignes de l'image ont été stockées. Comme déjà indiqué plus haut, le nombre de lignes par image dépend du format vidéo utilisé et cette information est envoyée par le module récepteur HDMI 215 de la Figure 2 à l'unité de traitement CPU 201 du dispositif ou noeud émetteur. L'unité CPU 201 du dispositif ou noeud émetteur transmet cette information au dispositif ou noeud récepteur, plus particulièrement à l'unité CPU 201 de ce dernier, par l'intermédiaire de données de contrôle de la partie contrôleur de réseau 207. L'unité CPU 201 du dispositif ou noeud récepteur envoie une information sur le nombre de lignes par image de la vidéo ou module 500 de la Figure 5a. Dans l'hypothèse où la fin d'une image n'est pas atteinte, l'étape 705 est suivie d'une étape 706 d'attente d'un prochain paquet vidéo provenant de la partie contrôleur de réseau 207. En cas de réception de paquet, l'étape 706 est suivie de l'étape 704 déjà décrite. Dans l'hypothèse où la fin d'une image est atteinte, l'étape 705 est alors suivie de l'étape 700 déjà décrite plus haut. La Figure 6a illustre un algorithme exécuté par le module "Vsync monitor" 530 de la Figure 5b (dispositif ou noeud récepteur 103). Cet algorithme comprend une série d'étapes, instructions ou portions de code logiciel exécutées lors de l'exécution de l'algorithme. Cet algorithme comprend une première étape 600 au cours de laquelle le registre 516 est chargé avec une valeur ("nominal Vsync") représentative de la fréquence image visée et qui est représentative de la fréquence du signal d'horloge pixel local 514 (cela signifie que la valeur nominale ainsi chargée est égale au nombre de pixels par image, incluant les périodes de masquage ou "blanking periods"). Cette valeur est fixée par l'unité CPU 201 et stockée dans la mémoire RAM 502. A titre d'exemple, pour un format vidéo de 1080p utilisant une fréquence de 60Hz, la valeur nominale du registre 516 est fixée à 2 475 000, correspondant à 1125 (lignes par image) x 2200 (pixels par ligne). Au cours de l'étape suivante 601, un horodatage ("time stamp") est 5 attendu du module 500 de la Figure 5a. Dès réception de cet horodatage, l'étape 601 est suivie de l'étape 602. Au cours de cette étape, le compteur 517 de la Figure 5b démarre. Le compteur 507 est synchronisé avec le début d'une image. Au 10 cours de cette étape, les variables "remote V1" et "local V1" sont respectivement fixées aux valeurs précédentes (instant t-1) d'horodatage ("time stamp") et de temps réseau. L'étape 602 est ensuite suivie d'une étape 604 d'attente de l'occurrence de l'horodatage suivant en provenance du module 500 et de 15 l'occurrence d'un horodatage local déclenchée par le signal "peer_vsync" 507. Lorsque ce signal 507 monte, la valeur de l'horodatage de référence prend la valeur du temps réseau 519. Le temps réseau 519 est piloté par la partie contrôleur de réseau 207. 20 L'étape 604 est ensuite suivie d'une étape 605 de test afin de déterminer si le signal "Remote Vsync" de la source vidéo est plus lent que le signal "peer_vsync" 507. Les informations représentatives du signal "Remote Vsync" sont obtenues à partir des horodatages présents dans les entêtes des paquets. Elles permettent de déterminer la période du signal à partir de la 25 différence entre deux horodatages extraits de paquets reçus et qui représentent respectivement l'instant d'apparition de deux fronts montants consécutifs dudit signal. Afin de réaliser ce test, on compare les valeurs [remote time stampremote V1] et [local time stamp-local V1] où les variables "remote time stamp" 30 et "local time stamp" ont pour valeurs respectives les valeurs courantes (instant t) d'horodatage et de temps réseau. Si la première valeur est supérieure à la seconde valeur, alors le signal "Remote Vsync" est plus lent et l'étape 609 est exécutée. Dans le cas contraire, l'étape 605 est suivie de l'étape 607. Au cours de l'étape 609, un test est pratiqué afin de déterminer si la correction de synchronisation peut être appliquée de façon douce. Comme décrit précédemment, la capacité de correction du module est limitée à un nombre prédéterminé K de pixels tous les N cycles. Ainsi, si la dernière correction est survenue avant que N cycles (par exemple trois cycles) se soient écoulés, l'étape 609 est alors suivie de l'étape 604 déjà décrite et aucune correction n'est appliquée. Si la quantité ou l'importance de la correction ([remote time stampremote V1] - [local time stamp-local V1]) est plus grande que le nombre de pixels K (par exemple dix coups d'horloge pixels), alors un signal de changement du "local pixels clock ratio" est envoyé du module 504 au module 515 ("coarse_correction" 523 sur la Figure 5a). Ainsi, la vitesse de l'horloge pixel générée par le module 515 sera modifiée pour être plus proche du rythme de la source vidéo. Dans le cas précité la capacité de correction de K pixels par N cycles est dépassée et la correction demandée est considérée comme "brutale" L'étape 609 est ensuite suivie de l'étape 604 déjà décrite et aucune correction n'est appliquée. Dans le cas contraire, l'étape 609 est suivie de l'étape 606. Au cours de l'étape 606, le signal "peer_Vsync" 507 est ralenti d'un nombre de coups d'horloge (du signal d'horloge pixel local 514) tel que déterminé à l'étape 609. Plus particulièrement, le signal 507 est ralenti en activant de façon correspondante la commande de décrémentation 520 du registre 516 (Figure 5b). Ensuite, les variables "remote V1" et "local V1" prennent respectivement pour valeurs les nouvelles valeurs de "remote time stamp" et "local time stamp". L'étape 606 est ensuite suivie de l'étape 604 déjà décrite en vue d'attendre de nouvelles informations temporelles d'horodatage ("time stamps"). De retour à l'étape 605, en cas de test négatif, cette étape est suivie de l'étape 607. Au cours de cette étape, un test est pratiqué afin de savoir si le signal "Remote Vsync" est plus rapide que le signal "peer_vsync" 507. Pour la mise en oeuvre de ce test, on procède à la comparaison entre les valeurs [remote time stamp-remote V1] et [local time stamp-local V1]. Si la première valeur est inférieure à la seconde valeur, alors le signal "Remote Vsync" est plus rapide et l'étape 607 est suivie de l'étape de test 610. Dans le cas contraire, les variables "remote V1" et "local V1" prennent respectivement pour valeurs les nouvelles valeurs de "remote time stamp" et "local time stamp". L'étape 607 est ensuite suivie de l'étape 604 déjà décrite ci-dessus. De retour à l'étape 610, un test est pratiqué afin de déterminer si la correction de synchronisation peut être appliquée de façon douce (c'est-à-dire non brutale). Comme déjà décrit, la capacité de correction de ce module est limitée à un nombre K de pixels tous les N cycles. Ainsi, si la dernière correction est intervenue avant que N cycles (par exemple trois cycles) se soient écoulés, alors l'étape 610 est suivie de l'étape 604 déjà décrite et aucune correction n'est appliquée. Si la quantité ou l'importance de la correction ([local time stamp-local V1]-[remote time stamp-remote V1]) est supérieure au nombre K (par exemple dix coups d'horloge pixels), alors un signal de changement du "local pixels clock ratio" est envoyé par le module 504 au module 515 de la Figure 5a ("coarse_correction" 523) et l'étape 610 est alors suivie de l'étape 604 déjà décrite sans qu'aucune correction n'ait été appliquée. Dans le cas contraire, l'étape 610 est suivie d'une étape 608 au cours de laquelle le signal "peer_vsync" est accéléré d'un nombre de coups d'horloge pixel local 514 tel que défini à l'étape 609. L'accélération du signal est obtenue plus particulièrement en activant de façon correspondante la commande d'incrémentation 521 du registre nominal 516 de la Figure 5b. Ensuite, les variables "remote V1" et "local VI" prennent respectivement les valeurs de "remote time stamp" et "local time stamp". L'étape 608 est alors suivie de l'étape 604 déjà décrite en vue d'attendre de nouvelles informations temporelles d'horodatage (time stamps). La Figure 6b décrit un algorithme mis en oeuvre par le module de gestion de dérive 506 de la Figure 5a. Ce module est mis en oeuvre par le dispositif ou noeud récepteur 103 pour commander l'ajout et la suppression de lignes inactives par le module "video synchro generator " 503 de la figure 5a. L'adaptation du nombre de lignes inactives dans une image est réalisée en fonction du déphasage (ou dérive) déterminé par le module de détection 505 sur les signaux "Vsync " 508 et " peer_vsync " 507. Le signal "Vsync " 508 est généré par le module " video synchro generator " 503 et est donc représentatif de la fréquence image fournie au dispositif d'affichage 104. Le signal " peer_vsync " 507 est généré par le module " Vsync regen " 504 à partir des informations représentatives de la fréquence image de la source 101. Lors de l'étape initiale 620 de l'algorithme, le module se met en attente d'une détection de différence de phase (ou dérive) calculée par le module " phase detector " 505. Puis, lorsque qu'une différence de phase a été détectée, le module 506 passe à l'étape suivante 621. Lors de l'étape 621 le module 506 détermine via un test le sens du déphasage qui a été déterminé par le module " phase detector " 505. Si le signal " peer_vsync " 507 est en avance de phase par rapport au signal " Vsync " 508, alors le module passe à l'étape 622, sinon le signal " Vsync " 508 est en avance de phase par rapport au signal " peer_vsync " 507 et le module passe à l'étape 627. Lors de l'étape 622, le module 506 détermine par un test si la différence de phase (ou dérive) a atteint ou dépassé la valeur d'une ligne. La valeur d'une ligne est fournie par l'unité CPU ou obtenue à partir de la mémoire RAM 502. Par exemple, pour un format vidéo de 1080p la valeur d'une ligne correspond à 2200 fronts d'horloge pixel 514. Ainsi, si la différence de phase est égale ou supérieure à la valeur d'une ligne, alors le module 506 passe à l'étape 623, sinon il reboucle à l'étape 620 déjà décrite. Lors de l'étape 623, le module 506 active la commande " remove_line " 510 afin de réduire la période du signal "Vsync " 508 (SVL) qui est en retard de phase par rapport au signal " peer_vsync " 507 (SV1). L'exemple de la Figure 7a illustre ce cas. Le module 506 passe ensuite à l'étape 624. Lors de l'étape 624, le module 506 se met en attente du signal d'acquittement " ack_change " 511 qui sera envoyé par le module " video synchro generator " 503 dès la prise en compte de la commande passée. Une fois le signal d'acquittement reçu, le module 506 passe à l'étape 625. Lors de l'étape 625, le module 506 relâche les commandes passées, puis envoie une commande " realign " 525 pour réaligner le signal " peer_vsync " 507 sur le début de ligne. La valeur du réalignement est par exemple égale à la différence du temps de cycle entre le signal " Vsync " 508 et le signal " peer_vsync " 507. Le temps de cycle du signal " Vsync " 508 est contenu dans la mémoire RAM 502 et le temps de cycle du signal " peer_vsync " est connu du module "Vsync regen " 504. Si la commande acquittée est " add_line " 509 (Figure 5a) alors la commande de réalignement comprend l'indication - et le temps de cycle du signal " Vsync " 508 contenu dans la mémoire RAM 502. Si la commande acquittée est " remove_line " 510 (Figure 5a), alors la commande de réalignement comprend l'indication + et le temps de cycle du signal " Vsync " 508 contenu dans la mémoire RAM 502. Ensuite, le module 506 reboucle sur l'étape initiale 620 déjà décrite. De retour à l'étape 627, le module 506 teste si la différence de phase a atteint ou dépassé la valeur d'une ligne telle que définie ci-dessus. Ainsi, si la différence de phase est égale ou supérieure à la valeur d'une ligne, alors le module passe à l'étape 628, sinon il reboucle à l'étape 620 déjà décrite. Lors de l'étape 628 le module active la commande " add_line " 509 afin d'augmenter la période du signal " Vsync " 508 (SVL) qui est en avance de phase par rapport au signal " peer_vsync " 507 (SV1). Le module 506 passe ensuite à l'étape 624 déjà décrite. La Figure 7a illustre sous la forme de chronogrammes différents signaux utilisés pour la synchronisation d'un flux vidéo et, plus particulièrement, pour contrôler le rythme d'affichage des images du flux vidéo sur un dispositif d'affichage tel que le dispositif 104 de la Figure 1. Plus particulièrement, on a représenté les signaux "de" (data_enable) 513 de la Figure 5a, "Hsync" (SHL) 512 (signal de synchronisation horizontale) de la Figure 5a, "Vsync" (SVL) 508 (signal de synchronisation verticale) et "peer_vsync" (SV1) 507 (signal régénéré) de la Figure 5a. Les signaux "de", "Hsync" et "Vsync" sont des signaux rythmés sur l'horloge locale du dispositif ou noeud récepteur, tandis que le signal "peer_vsync" est rythmé sur l'horloge de la source vidéo ou du dispositif ou noeud émetteur si source et dispositif émetteur sont confondus. La combinaison d'un signal de contrôle (SV1) synchronisé sur la source vidéo avec un ou plusieurs signaux synchronisés sur le dispositif ou noeud récepteur permet de contrôler le rythme d'affichage de la vidéo et donc d'apporter des corrections en vue de l'affichage de manière particulièrement douce. Les signaux "Hsync", "Vsync" et "peer_vsync" sont représentés chacun par une succession d'impulsions qui sont en fait des créneaux tels que représentés sur la Figure 7b qui sera décrite ci-après. Le signal "Vsync" rythme l'affichage des images tandis que le signal "Hsync" rythme l'affichage des lignes à l'intérieur d'une image. Le signal "de", quant à lui, rythme l'affichage des pixels sur une ligne active en combinaison avec le signal d'horloge pixel local 514 non représenté sur la Figure 7a par souci de clarté. Comme cela apparaît sur la Figure 7a un écart ou dérive intervient 30 entre les signaux "peer_vsync" (SV1) et "Vsync" (SVL) et est calculé par le module 505 de la Figure 5a. Les écarts ou dérives successifs détectés sont représentés par les références 800, 801 et 802 sur la Figure 7a. Si l'on suppose qu'une image à afficher contient un nombre K de lignes (incluant les lignes actives et inactives) le flux arrivant constitué de ces K lignes est rythmé par le signal "peer_vsync" qui est synchronisé avec l'horloge de la source vidéo. Tant que la dérive entre les signaux "peer_vsync" et "Vsync" reste inférieure à une ligne (dérives 800 et 801 sur la Figure 7a), l'affichage de ces K lignes peut être effectué suivant le rythme d'affichage fourni par l'horloge locale du dispositif ou noeud récepteur sans qu'une correction n'intervienne. Toutefois, lorsque la dérive constatée (ex : dérive 802) est supérieure à une ligne, l'invention prévoit de mettre en place une correction afin que l'horloge locale du dispositif ou noeud récepteur et tous les signaux utiles qui en sont issus se synchronisent sur le signal "peer_vsync" et donc sur l'horloge de la source vidéo. En effet, avec une telle dérive si aucune correction n'est apportée alors les K lignes de l'image ne pourront pas être affichées sur une seule image et vont "déborder" sur l'image suivante, créant ainsi des perturbations visuelles inacceptables. Comme représenté sur la Figure 7a suite à la dérive 802 détectée une correction est apportée pour l'affichage de l'image suivante, permettant ainsi d'obtenir une synchronisation entre les signaux "peer_vsync" et "Vsync" ainsi que représenté par la référence 803. Dans l'exemple représenté, la correction apportée est adaptée à la dérive qui a été relevée et consiste à supprimer une ligne inactive parmi les (K-M) lignes inactives des K lignes de l'image qui est à afficher M représentant le nombre de lignes actives). Le nombre de lignes inactives à supprimer d'une image (ou à ajouter selon le signe du déphasage entre les signaux "peer_vsync" et "Vsync") dépend de l'amplitude de la dérive qui a été déterminée. On a représenté sur la Figure 7b à plus grande échelle les signaux "de", "Hsync" et "Vsync". - La Figure 7b est divisée en deux parties : une première partie supérieure 900 représente le diagramme temporel d'une ligne de vidéo et une deuxième partie inférieure 901 représente le diagramme temporel d'une image. Sur la première partie 900 une nouvelle ligne commence par un front montant du signal "Hsync" 512 (SHL). En amont de ce front montant se trouve la période " Front porch pixels " 905. En aval du front descendant se trouve la période "Back porch pixels " 906. L'ensemble comprenant la période " Front porch pixels " 905, la période couvrant l'état haut 909 du signal "Hsync", et la période " Back porch pixels " 906 forme la période 908 dite " horizontal_blanking " (masquage horizontal) pendant laquelle les pixels de la ligne sont invisibles (inactifs), c'est-à-dire qu'ils ne sont pas à afficher. La partie inactive de la ligne est signalée par un état bas du signal "de" (data_enable) 513. La période située entre la période " Back porch pixels " 906 et la prochaine période " Front porch pixels " 905 définit la partie active 907 de la ligne. Pendant la partie active 907 de la ligne les pixels à afficher sont pris en compte et affichés. La partie active de la ligne est signalée par un état haut du signal "de" 513. C'est le signal d'horloge pixel qui rythme le nombre de coups d'horloge à partir duquel le premier pixel d'une ligne doit être affiché. Le signal d'horloge pixel n'est pas représenté sur ce diagramme par souci de clarté. Quand le signal "de" 513 est à l'état haut il faut fournir un pixel à chaque front montant du signal d'horloge pixel. Par exemple pour le format vidéo utilisé1080p60 tel que défini par la norme CEA-861-D, la période " Front porch pixels " a une durée équivalente à 88 pixels, le niveau haut du signal "Hsync" a une durée équivalente à 44 pixels, la période " Back porch pixels " a une durée équivalente à 906 pixels et la partie active de la ligne comporte 1920 pixels. Sur la deuxième partie inférieure 901 de la Figure 7b, une nouvelle image commence par un front montant du signal "Vsync " 508 (SVL). En amont du front montant du signal "Vsync" se trouve la période " Front porch lines " 911. En aval du front descendant du signal "Vsync" se trouve la période " Back porch lines " 913. L'ensemble comprenant la période " Front porch lines ", la période couvrant l'état haut 912 du signal "Vsync" et la période " Back porch Unes " 913 forme la période 910 dite " vertical_blanking " (masquage vertical). Pendant la période " vertical_blanking " 910 les lignes sont invisibles (inactives), c'est-à-dire qu'elles ne sont pas affichées. Le signal "de" 513 est d'ailleurs à l'état bas pendant toute la période " vertical_blanking " 910. Par contre, le signal "Hsync" 512 continue à indiquer les frontières de lignes même si elles sont inactives pendant la période " vertical_blanking " 910. Au-delà de la période " vertical_blanking " 910, les lignes sont dites actives (période référencée 914) et donc contiennent des pixels à afficher (ex : M lignes actives sur la Figure 7a). De façon générale, en fonction de la dérive, la période " Back porch lines " 913 peut être augmentée d'une ou de plusieurs lignes à l'intérieur d'une image pour ralentir en moyenne la fréquence image (pendant l'affichage d'une image le temps d'affichage s'est trouvé allongé d'une ou de plusieurs lignes). Inversement, selon la dérive, la période " Back porch lines " 913 peut être réduite d'une ou de plusieurs lignes dans une image pour accélérer en moyenne la fréquence image (pendant l'affichage d'une image le temps d'affichage s'est trouvé raccourci d'une ou de plusieurs ligne). Dans l'exemple de la Figure 7a, la période 913 a été raccourcie (période raccourcie notée 913') par suppression d'une ligne inactive de l'image. Sous le signal Hsync les périodes 911 et 912+913 ont été représentées avec des accolades et la période 906 précédant l'apparition d'un front montant du signal "de" 513 a également été indiquée. Par ailleurs, la correction apportée (période modifiée 913') pour modifier le rythme d'affichage d'une image a été représentée après le front montant déclenchant une nouvelle image. Cette nouvelle image ne contient ainsi que K-1 lignes comptées suivant l'horloge locale du dispositif ou noeud récepteur au lieu de K images (le nombre de M lignes actives à afficher n'a pas varié). Des modes de réalisation alternatifs pourraient agir sur la période " Front porch lines " 911 ou bien sur la durée de l'état haut 912 du signal "Vsync" 508. Le mode de réalisation décrit ici est toutefois le plus avantageux. En effet, la période " Back porch lines " 913 est la plus longue, donc en la réduisant d'une ligne on obtient le plus petit ratio de changement, ce qui s'avère moins perturbant pour le dispositif d'affichage 104 de la Figure 1. Par ailleurs, changer la durée de l'état haut 912 du signal "Vsync" ajouterait un autre risque de perturbation du dispositif d'affichage 104. Les ordres de grandeur sont par exemple indiqués comme suit, pour le format 1080p60 tel que défini par la norme CEA-861-D : la période " Front porch lines " 911 a une durée équivalente à 5 lignes, le niveau haut 912 du signal "Hsync" a une durée équivalente à 5 lignes, la période " Back porch lines " 913 a une durée équivalente à 36 lignes et le nombre M de lignes actives 914 est égal à 1080 lignes. On notera que les signaux représentés sur les figures 7a et 7b portent des références différentes de ceux illustrés sur la Figure 3 (301, 302, 304 et 311) mais il s'agit des mêmes signaux. Les Figures 8a, 8b et 8c illustrent le fonctionnement du module "video synchro generator" 503 de la Figure 5a. Le module " video synchro generator " 503 met en oeuvre trois algorithmes en parallèle respectivement représentés sur les Figures 8a, 8b et 8c. Un premier algorithme illustré sur la Figure 8a a pour but de générer le signal " Hsync " 512 (SHL) et un signal interne de masquage horizontal (" horizontal_blanking "), référencé 908 sur la Figure 7b, pris en compte par l'algorithme de la Figure 8c pour la génération du signal " de " 513. Lors de l'étape initiale 640 de l'algorithme le module 503 se met en attente d'un front montant du signal " peer_vsync " 507 afin de synchroniser son démarrage sur ce signal. Lors de cette étape le signal "Hsync " 512 est maintenu à l'état bas et le signal " horizontal_blanking " est maintenu à un état haut. Sur détection d'un front montant du signal " peer_vsync " 507 le module 503 passe à l'étape suivante 641. Lors de l'étape 641 le module 503 entre en phase de synchronisation horizontale. Lors de cette étape le signal " Hsync " 512 est maintenu à l'état haut 909 sur la Figure 7b (première partie 900) et le signal " horizontal_blanking " est maintenu à un état haut. La durée de cet état est fonction du format d'image contenu dans la mémoire RAM 502 et qui est, par exemple de 44 fronts du signal d'horloge pixel 514 pour un format vidéo 1080p60. A la fin de cette période le module 503 passe à l'étape suivante 642. Lors de l'étape 642 le module 503 entre dans la période de " Back porch pixels " 906 sur la Figure 7b (première partie). Lors de cette étape le signal " Hsync " 512 est maintenu à l'état bas et le signal " horizontal_blanking " est maintenu à un état haut. La durée de cet état est fonction du format d'image tel que stocké dans la mémoire RAM 502. Cette durée est par exemple de 148 fronts du signal d'horloge pixel 514 pour un format vidéo 1080p60. A la fin de cette période le module 503 passe à l'étape suivante 643. Lors de l'étape 643 le module 503 entre en phase d'affichage des pixels "actifs" d'une ligne active d'une image (phase référencée 907 sur la Figure 7b). Lors de cette étape le signal " Hsync " 512 est maintenu à l'état bas de même que le signal " horizontal_blanking ". La durée de cet état est fonction du format d'image tel que stocké dans la mémoire RAM 502. Cette durée est par exemple de 1920 fronts du signal d'horloge pixel 514 pour un format vidéo 1080p60. A la fin de cette période le module 503 passe à l'étape suivante 644. Lors de l'étape 644 le module 503 entre dans la période de " Front porch pixels " (période 905 sur la Figure 7b). Lors de cette étape le signal " Hsync " 512 est maintenu à l'état bas et le signal " horizontal_blanking " est maintenu à un état haut. La durée de cette période ou état est fonction du format d'image tel que stocké dans la mémoire RAM 502. Cette durée est par exemple de 88 fronts du signal d'horloge pixel 514 pour un format vidéo 1080p60. A la fin de cette période le module 503 repasse à l'étape déjà décrite 641. Les étapes 641, 642 et 644 correspondent à la période " horizontal_blanking " 908 de la Figure 7b durant laquelle les pixels sont "inactifs" (pas d'affichage de pixels). L'étape 643 correspond à la période 907 de la Figure 7b où les pixels d'une ligne sont "actifs", c'est-à-dire que l'on procède à leur affichage au rythme de l'horloge pixel locale. Un deuxième algorithme illustré à la Figure 8b a pour but de générer le signal " Vsync " 508 (SLV) des Figures 5a et 7a et un signal interne de masquage vertical (" vertical_blanking "), référencé 910 sur la Figure 7b, pris en compte par l'algorithme de la Figure 8c pour la génération du signal " de " 513. Cet algorithme est en outre en charge de la gestion des commandes " add_line " 509 et " remove_line " 510 de la Figure 5a. Lors de l'étape initiale 650 de l'algorithme le module 503 se met en attente d'un front montant du signal " peer_vsync " 507 afin de synchroniser son démarrage sur ce signal. Lors de cette étape le signal "Vsync " 508 (SVL) est maintenu à l'état bas et le signal " vertical_blanking " 910 est maintenu à un état haut. Sur détection d'un front montant du signal " peer vsync " 507 le module 503 passe à l'étape suivante 651. Lors de l'étape 651 le module 503 entre dans une période ou phase de synchronisation verticale (référencée 912 sur la Figure 7b). Lors de cette étape le signal "Vsync " 508 est maintenu à l'état haut, de même que le signal " vertical_blanking ". La durée de cet état est fonction du format d'image tel que connu de la mémoire RAM 502. Cette durée est par exemple de 5 lignes pour un format vidéo 1080p60. A la fin de cette période le module 503 passe à l'étape suivante 652. Lors de l'étape 652 le module réalise un test afin de déterminer s'il a reçu une commande " add_line " 509 ou " remove_line " 510 du gestionnaire de dérive 506 (Fig. 5a). S'il a reçu une des deux commandes, il passe à l'étape suivante 653. Sinon, il passe à l'étape suivante 655. Lors de l'étape 653 le module 503 modifie la durée de la période " Back porch lines " (période 913 sur les Figures 7a et 7b) à venir. Cette nouvelle durée est fonction de la commande reçue et est adaptée à la dérive entre les signaux "Vsync" (SVL) et "peer-vsync" (SV1). La durée de la période "Back porch lines " 913 est fonction du format d'image contenu dans la mémoire RAM 502 et est, par exemple, de 36 lignes pour un format 1080p60. Si la commande reçue est " add_line " 509, alors la durée de la période " Back porch lines " est incrémentée d'une unité (37 lignes par exemple). Si la commande reçue est " remove_line " 510, alors la durée de la période " Back porch lines " est décrémentée d'une unité comme dans l'exemple de la Figure 7a (35 lignes par exemple). La durée modifiée notée 913' a été représentée sur la Figure 7a. Ces nouvelles valeurs ne sont pas stockées dans la mémoire RAM 502.. Le module 503 passe ensuite à l'étape 654. Lors de l'étape 654 le module 503 envoie un signal d'acquittement " ack change " au module de gestion de dérive 506. Le module 503 passe ensuite à l'étape 655. Lors de l'étape 655 le module 503 entre dans la période de " Back porch lines " (913 sur les Figures 7a et 7b). Lors de cette étape le signal "Vsync " 508 est maintenu à l'état bas et le signal " vertical_blanking " 910 est maintenu à un état haut. Si la transition vers cet état vient directement de l'étape 652, alors la durée de cet état est fonction du format d'image connu de la mémoire RAM 502. La durée est par exemple de 36 lignes pour un format 1080p60. Si la transition vers cet état vient des étapes 653 et 654 alors la durée de cet état est fonction du calcul effectué à l'étape 653 et est, par exemple de 35 ou 37 lignes. A la fin de cette période le module 503 passe à l'étape suivante 656. Lors de l'étape 656 le module 503 entre dans une phase ou période d'affichage de lignes actives (914 sur la Figure 7b). Lors de cette étape le signal "Vsync " 508 est maintenu à l'état bas de même que le signal vertical_blanking ". La durée de cet état est fonction du format d'image connu de la mémoire RAM 502. Cette durée est par exemple de 1080 lignes pour un format 1080p60. A la fin de cette période le module 503 passe à l'étape suivante 657. Lors de l'étape 657 le module 503 entre dans une période de " Front porch lines " (911 sur les Figures 7a et 7b). Lors de cette étape le signal " Vsync " 508 est maintenu à l'état bas et le signal " vertical_blanking " est maintenu à un état haut. La durée de cet état est fonction du format d'image connu de la mémoire RAM 502. Cette durée est par exemple de 5 lignes pour un format vidéo 1080p60. A la fin de cette période le module 503 repasse à l'étape 651 déjà décrite. Les étapes 651, 655 et 657 correspondent à la période vertical_blanking " 910 de la Figure 7b durant laquelle les lignes sont inactives (pas d'affichage de lignes). L'étape 656 correspond à la période " Active lines " 914 durant laquelle les lignes sont actives, c'est-à-dire que l'on procède à leur affichage. Un troisième algorithme illustré à la Figure 8c a pour but de générer le signal " de " 513. Cet algorithme est constitué d'une seule étape 660 exécutée en permanence et qui positionne le signal " de " 513 des Figures 5a, 7a et 7b à l'état haut quand les deux signaux " horizontal_blanking " et " vertical_blanking " sont eux même à l'état haut. Sinon, si l'un des deux signaux " horizontal_blanking " ou " vertical_blanking " est positionné à l'état bas, alors le signal " de " 513 est lui aussi positionné à l'état bas. REVENDICATIONS, 1. Procédé de contrôle du rythme d'affichage d'un signal vidéo issu d'une source vidéo, transmis par un dispositif émetteur (DE) vers un dispositif récepteur (DR) et destiné à être affiché sur un dispositif d'affichage, le signal vidéo comprenant des images, chaque image contenant des lignes actives incluant des informations sur des pixels à afficher par le dispositif d'affichage et des lignes inactives n'incluant pas d'informations sur des pixels à afficher par le dispositif d'affichage, caractérisé en ce que le rythme d'affichage est contrôlé par au moins un premier signal de contrôle (SV1) synchronisé au rythme image de la source vidéo , le procédé comportant les étapes suivantes : - calcul d'une dérive entre le premier signal de contrôle (SV1) et un signal synchronisé au rythme image du dispositif récepteur ; - en fonction de la dérive calculée, adaptation du nombre de lignes inactives dans une image du signal vidéo au niveau du dispositif récepteur. 2. Procédé selon la revendication 1, caractérisé en ce que le rythme d'affichage est contrôlé également par au moins un deuxième signal de contrôle synchronisé au rythme image du dispositif récepteur. 3. Procédé selon la revendication 2, caractérisé en ce que le rythme d'affichage est contrôlé par le deuxième signal de contrôle qui est un signal de synchronisation horizontale (SHL) et par un troisième signal de contrôle qui est un signal d'horloge pixel. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il comporte une étape de suppression d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en avance de phase par rapport à la source vidéo. 5. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il comporte une étape d'ajout d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en retard de phase par rapport à la source vidéo. 6. Procédé selon la revendication 4 ou 5, caractérisé en ce qu'il comporte en outre une étape de réajustement, par le dispositif récepteur, dufront montant du premier signal de contrôle (SV1) pour qu'il se réaligne sur un début de ligne lorsque la correction de la dérive calculée ne se traduit pas par un nombre entier de ligne(s) inactive(s). 7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce 5 qu'il comporte une étape de génération du premier signal de contrôle (SV1) par le dispositif récepteur. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que le premier signal de contrôle est un signal de synchronisation verticale. 9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce 10 que le calcul d'une dérive est effectué de manière régulière. 10. Dispositif de contrôle du rythme d'affichage d'un signal vidéo issu d'une source vidéo et transmis par un dispositif émetteur (DE) et destiné à être affiché sur un dispositif d'affichage, le signal vidéo comprenant des images, chaque image contenant des lignes actives incluant des informations sur des 15 pixels à afficher par le dispositif d'affichage et des lignes inactives n'incluant pas d'informations sur des pixels à afficher par le dispositif d'affichage, caractérisé en ce que le rythme d'affichage est contrôlé par au moins un premier signal de contrôle (SV1) synchronisé au rythme image de la source vidéo, le dispositif de contrôle comportant : 20 - des moyens de calcul d'une dérive entre le premier signal de contrôle (SV1) et un signal (SVL) synchronisé au rythme image du dispositif récepteur, - des moyens d'adaptation, en fonction de la dérive calculée, du nombre de lignes inactives dans une image du signal vidéo. 25 11. Dispositif selon la revendication 10, caractérisé en ce que le rythme d'affichage est contrôlé également par au moins un deuxième signal de contrôle synchronisé au rythme image du dispositif récepteur. 12. Dispositif selon la revendication 11, caractérisé en ce que le rythme d'affichage est contrôlé par le deuxième signal de contrôle qui est un 30 signal de synchronisation horizontale (SHL) et par un troisième signal de contrôle qui est un signal d'horloge pixel. 13. Dispositif selon l'une des revendications 10 à 12, caractérisé en ce qu'il comporte des moyens de suppression d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en avance de phase par rapport à la source vidéo. 14. Dispositif selon l'une des revendications 10 à 12, caractérisé en ce qu'il comporte des moyens d'ajout d'au moins une ligne inactive dans l'image du signal vidéo à afficher lorsque la dérive calculée traduit le fait que le dispositif récepteur est en retard de phase par rapport à la source vidéo. 15. Dispositif selon la revendication 13 ou 14, caractérisé en ce qu'il comporte en outre des moyens de réajustement du front montant du premier signal de contrôle (SV1) pour qu'il se réaligne sur un début de ligne lorsque la correction de la dérive calculée ne se traduit pas par un nombre entier de ligne(s) inactive(s). 16. Dispositif selon l'une des revendications 10 à 15, caractérisé en ce qu'il comporte des moyens de génération du premier signal de contrôle (SV1). 17. Dispositif selon l'une des revendications 10 à 16, caractérisé en ce que le premier signal de contrôle est un signal de synchronisation verticale. 18. Dispositif selon l'une des revendications 10 à 17, caractérisé en ce que le calcul d'une dérive est effectué de manière régulière. 19. Système de communication comprenant une source vidéo, un dispositif émetteur (DE), un dispositif récepteur (DR), un dispositif d'affichage et un dispositif de contrôle du rythme d'affichage d'un signal vidéo issu de la source vidéo, transmis par le dispositif émetteur (DE) vers le dispositif récepteur (DR) et destiné à être affiché sur un dispositif d'affichage, le signal vidéo comprenant des images, chaque image contenant des lignes actives incluant des informations sur des pixels à afficher par le dispositif d'affichage et des lignes inactives n'incluant pas d'informations sur des pixels à afficher par le dispositif d'affichage, caractérisé en ce que le rythme d'affichage est contrôlé par au moins un premier signal de contrôle (SV1) synchronisé au rythme image de la source vidéo, le dispositif de contrôle comportant :- des moyens de calcul d'une dérive entre le premier signal de contrôle (SV1) et un signal (SVL) synchronisé au rythme image du dispositif récepteur, - des moyens d'adaptation, en fonction de la dérive calculée, du 5 nombre de lignes inactives dans une image du signal vidéo. 20. Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé de contrôle selon l'une des revendications 1 à 9, lorsque ce programme est chargé et exécuté par un système informatique. 10