FR2964235A1 - Procede de synchronisation, systeme et dispositif correspondants - Google Patents

Abstract

La présente invention concerne un procédé de synchronisation entre dispositifs (DE, DR) d'un système de distribution (100) de flux vidéo d'images. Le système comprend au moins trois dispositifs, dont un émetteur et un récepteur, dans lequel un dispositif émetteur est configuré pour recevoir, d'une source (101), un flux vidéo (DATA) présentant une fréquence image source (FlmSource), et un dispositif récepteur est configuré pour contrôler l'affichage, à une fréquence image d'affichage (FlmAff), d'un flux vidéo sur un dispositif d'affichage (104). Le procédé comporte les étapes suivantes : - obtenir (1005, 1024) une fréquence image cible (FlmCible) commune, - adapter (1158, 712), par les dispositifs, un flux vidéo source reçu d'une source, respectivement, directement ou au travers d'un dispositif émetteur, de la fréquence image source à la fréquence image cible, - ajuster, sur chaque récepteur, la fréquence image d'affichage de sorte à contrôler un affichage à ladite fréquence image cible.

Description

La présente invention concerne un procédé de synchronisation entre dispositifs d'un système de distribution de flux vidéo d'images. 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 s'applique notamment aux systèmes d'affichage vidéo haut de gamme à projections multiples. Ce sont des systèmes de projection audio vidéo constitués de plusieurs sources audio/vidéo haute définition destinées à être affichées par le biais d'un ou de plusieurs projecteurs ou écrans. Ces systèmes permettent la mise en oeuvre de systèmes d'affichage vidéo de très grandes dimensions et de très haute qualité, par exemple en plein air dans un stade pour un événement sportif ou un concert, ou bien dans un hall de conférence. Ces systèmes vidéo à projections multiples peuvent également être utilisés pour des simulateurs, afin de produire un effet d'immersion dans l'univers simulé, différents écrans entourant alors l'utilisateur de façon continue.

Dans une telle situation, les images projetées bords à bords (ou avec un léger recouvrement) sur les différents écrans doivent être parfaitement synchronisées pour garantir le réalisme. Une autre application concerne les systèmes de conférence, dans lesquels un ou plusieurs grands écrans sont utilisés pour projeter des images venant par exemple d'ordinateurs de différents participants. Les images de certaines sources peuvent par exemple être réduites et alignées sur un coté de l'image principale, ou incrustées dans celle-ci. Dans ce cas, le basculement des sources entre les images réduites et l'image principale doit se faire rapidement et sans artefacts visuels pour le confort des utilisateurs.

Pour des raisons d'esthétique, de facilité d'installation et de réarrangement du système, les communications et transferts de données entre les différents appareils constituant le système se font par l'intermédiaire d'un réseau sans fil synchrone, c'est-à-dire partageant une horloge réseau commune. En effet, ce type de réseau est bien adapté au transfert de données à débit constant, comme la vidéo ou l'audio. Le type de vidéo ciblée étant la vidéo haute définition, le réseau sans fil peut utiliser la bande de fréquence des 60 GHz afin de garantir une bande passante suffisante. Dans les systèmes de transport de vidéo, les images sont générées par les sources suivant une horloge vidéo. Cette horloge définit le rythme de l'affichage des images successives et ainsi une fréquence d'images, dite fréquence image source. Elle correspond classiquement à la valeur Vsync ("Vertical synchronisation" en anglais) représentant un signal de synchronisation verticale des images. Dans le cas où ces images sont transportées par le biais d'un réseau, des moyens de synchronisation doivent être mis en place au niveau des équipements destinataires (ou récepteurs) qui ont eux même leur propre fréquence image locale, afin de suivre l'horloge vidéo de la source. Sans ces moyens de synchronisation, les mémoires tampons de réception des appareils destinataires se videraient ou se rempliraient complètement selon que la fréquence image locale est supérieure ou inférieure à la fréquence image source, causant ainsi des artefacts visuels qui se traduisent par exemple par une interruption de la vidéo. Dans l'art antérieur, ces moyens de synchronisation peuvent être réalisés en transportant le signal d'horloge par le biais d'un câble reliant les différents appareils. Cependant, on cherche désormais à remplacer les câbles par des réseaux sans fils. De plus, la plupart des appareils grand public ne sont pas équipés pour recevoir un tel câble dédié. D'autres solutions consistent en l'utilisation de boucles à verrouillage de phase ou PLL (« Phase-Locked Loop » en terminologie anglo-saxonne), comme cela est notamment présenté dans le brevet américain US 7 499 044 (Silicon Graphics).

Ces dispositifs PLL permettent de synchroniser avec précision l'horloge de l'équipement destinataire (horloge esclave) sur celle de la source (horloge maître). La vitesse de synchronisation est paramétrable. Si elle est rapide, l'horloge esclave peut subir une forte gigue, c'est-à-dire une irrégularité temporaire, qui peut avoir des conséquences sur le traitement des données transportées. Pour limiter la gigue, la vitesse de synchronisation doit être faible, mais, dans ce cas, le délai de re-synchronisation en cas de changement d'horloge maître (par exemple en raison d'une commutation de la source) est long. De plus, le nombre de PLLs disponibles dans les composants matériels est limité, il est donc nécessaire de les utiliser avec discernement. Dans un système vidéo à projections multiples, l'affichage vidéo complet est en réalité constitué de différentes portions d'image, dont l'ensemble une fois synchronisé constitue une image vidéo parfaitement homogène. La synchronisation entre eux des différents dispositifs d'affichage (écrans ou vidéo projecteurs) constitue une exigence technique essentielle pour la mise en oeuvre de ces systèmes. Un tel système ne supporte donc pas des variations de vitesses d'affichage différentes entre deux dispositifs d'affichage.

Il est alors parfois fait appel à l'usage de sources vidéo parfaitement synchronisées. Cette synchronisation "parfaite" peut être obtenue en utilisant un équipement de synchronisation vidéo à entrées multiples (par exemple tel qu'un équipement de type « video wall controller» commercialisé par la société Barco - marque déposée) disponible sur étage.

Toutefois, un tel équipement, réservé à un usage professionnel haut de gamme, présente des inconvénients relatifs, d'une part, à son coût très onéreux, et, d'autre part, aux limitations techniques et pratiques d'un système centralisé résultant. En effet, l'ensemble des sources vidéo doit être connecté à cet équipement central, ce qui peut s'avérer incompatible avec une utilisation nécessitant un déport plus ou moins important de certaines sources vidéo interdisant le recours à des câbles, comme par exemple un ensemble de plusieurs caméras effectuant une capture étendue pour un seul affichage homogène en temps réel. Dans la même veine, il est connu, du brevet américain US 5 517 253 30 (Philips), un dispositif de synchronisation multi-sources multi-écrans basé sur l'utilisation d'équipements destinataires présentant une horloge image commune. Cette solution n'est pas satisfaisante en présence d'équipements destinataires ne partageant pas d'horloge image. En outre, la solution proposée dans ce document de l'art antérieur met en oeuvre un ajout de pixels qui s'avère être mal supporté par certains équipements destinataires. De plus, dans un système multi-sources du type précédemment évoqué, la commutation entre deux sources pose le problème supplémentaire de la synchronisation par rapport à une source de référence. En effet, chaque source suit sa propre horloge image et, lorsqu'une destination change de source d'affichage, elle doit re-synchroniser son horloge image pour suivre celle de la nouvelle source. Il en est de même lorsque, pour une même source, on commute entre deux équipements destinataires. Ce changement d'horloge de référence nécessite des traitements progressifs (et donc lents) au niveau des moyens de synchronisation de l'équipement destinataire qui sont utilisés pour suivre l'horloge de la source. Ces traitements empêchent un basculement à la fois propre et rapide entre les sources. En effet, tant que l'horloge de la destination n'est pas recalée sur celle de la source, l'affichage risque d'être perturbé : un écran noir risque d'apparaître le temps de re-synchroniser l'horloge de la destination.

Ces différents inconvénients mettent en exergue le besoin de disposer de mécanismes plus efficaces pour synchroniser des dispositifs dans un système de distribution de flux vidéo d'images, notamment pour permettre des commutations de sources ou d'équipements destinataires sans artefacts, et sans mettre en oeuvre des équipements onéreux.

La présente invention vise à remédier à au moins un des inconvénients précités en proposant notamment un procédé de synchronisation entre dispositifs d'un système de distribution de flux vidéo d'images comprenant, reliés à un réseau de communication, au moins trois dispositifs émetteurs ou récepteurs, dont un dispositif émetteur et un dispositif récepteur, un dispositif émetteur étant configuré pour recevoir, d'une source, un flux vidéo source présentant une fréquence d'images, dite fréquence image source, un dispositif récepteur étant configuré pour contrôler l'affichage, à une fréquence d'affichage, dite fréquence image d'affichage, d'un flux vidéo sur un dispositif d'affichage auquel il est relié, procédé caractérisé en ce qu'il comporte les étapes consistant à : obtenir une fréquence d'images, dite fréquence image cible, commune pour les dispositifs, adapter, par chaque dispositif de l'ensemble des dispositifs émetteurs ou de l'ensemble des dispositifs récepteurs, un flux vidéo source reçu d'une source, respectivement, directement ou au travers d'un dispositif émetteur, de la fréquence image source à la fréquence image cible, ajuster, au niveau de chaque dispositif récepteur, la fréquence image d'affichage à la fréquence image cible de sorte à contrôler un affichage à ladite fréquence image cible. Le procédé selon la présente invention permet notamment de commuter entre plusieurs dispositifs émetteurs reliés à des sources ou commuter entre plusieurs dispositifs récepteurs prévus pour l'affichage, sans entraîner d'artéfacts résultant de la mise en oeuvre d'une re-synchronisation des dispositifs comme nécessaires dans l'état de l'art. Cette faculté est obtenue par l'utilisation d'une fréquence image cible commune aux dispositifs. En outre, cette fréquence cible s'avère stable au cours du temps, comme il ressortira de la suite, eu égard aux mécanismes de détermination de celle-ci. Ainsi, lors d'une commutation, les dispositifs sont déjà configurés pour adapter un flux vidéo source à cette fréquence cible commune et les dispositifs récepteurs présentent des vitesses de traitement pour l'affichage qui sont déjà synchronisées par ajustement des fréquences images d'affichage à la même fréquence image cible. La commutation à une autre source vidéo ne requiert donc désormais plus de changement de vitesse d'horloge et donc de re-synchronisation des dispositifs.

Dans un mode de réalisation, l'étape d'obtention de la fréquence image cible comprend une étape consistant à déterminer une fréquence d'images de référence parmi les seules fréquences images sources.

Cette disposition permet, pour un dispositif récepteur commutant sur plusieurs émetteurs d'avoir la même adaptation a réaliser, et donc de s'affranchir également d'une resynchronisation. En variante, l'étape d'obtention de la fréquence image cible comprend une étape consistant à déterminer une fréquence d'images de référence parmi les fréquences images sources et les fréquences images d'affichage. Ainsi, on obtient en plus de la variante précédente, une homogénéité des adaptations entre dispositifs récepteurs lorsqu'un dispositif émetteur 10 commute entre ces différents dispositifs récepteurs. En particulier, la fréquence d'image de référence est la fréquence d'image la plus élevée parmi les fréquences images sources et d'affichage prises en compte. Par cette disposition, la référence est le dispositif le plus rapide. Ainsi, les autres dispositifs émetteurs voulant adapter leurs flux à cette 15 fréquence élevée devront ajouter des données (par duplication d'images par exemple). Par conséquent, cette mise en oeuvre de l'invention permet d'éviter la suppression de données utiles vidéo: les données vidéo sont donc entièrement préservées. Selon une caractéristique particulière, ladite fréquence image cible 20 est égale à la fréquence d'image de référence si cette dernière est une fréquence image source, et est strictement supérieure à la fréquence d'image de référence si cette dernière est une fréquence image d'affichage. De la sorte, tous dispositifs émetteurs sont amenés à appliquer le même type d'adaptation (duplication d'images) et tous les dispositifs récepteurs 25 à appliquer le même type d'ajustement/adaptation (retrait de lignes invisibles par exemple car la fréquence cible est supérieure à la fréquence image propre au dispositif récepteur). A noter que l'utilisation d'une fréquence image cible strictement supérieure à la fréquence image de référence (par exemple par ajout d'un 30 correctif, typiquement 0,01 Hz (i.e. image par seconde) pour un affichage final type 25, 50 ou 100 Hz), permet de pallier certaines incertitudes dans les adaptations et les latences dans le réseau.

Dans un mode de réalisation de l'invention, chaque dispositif détermine sa propre fréquence image source ou d'affichage et transmet, aux autres dispositifs, la fréquence image déterminée accompagnée d'une information renseignant le type de dispositif, émetteur ou récepteur, dont provient la fréquence image transmise. Ce travail distribué permet de s'affranchir de l'utilisation onéreuse d'un équipement centralisé. En outre, cette disposition peut être facilement mise en oeuvre avec des sources classiques, ce qui est un avantage notable en terme de coûts.

Enfin, elle assure que le calcul de la fréquence image cible, lequel peut être fonction du type de dispositif choisi comme référence, est bien effectué correctement par chaque dispositif. En particulier, la détermination d'une fréquence image propre à un dispositif est effectuée en déterminant une période d'un signal de synchronisation dudit dispositif par rapport à une horloge réseau commune du réseau de communication. Cette disposition offre une référence temporelle commune de faible complexité pour mettre en oeuvre l'invention. Selon une caractéristique particulière, l'étape d'obtention de la fréquence image cible est effectuée sur chaque dispositif ayant reçu les valeurs de période de signal de synchronisation en provenance des autres dispositifs du réseau, par détermination d'une fréquence d'images de référence en fonction desdites valeurs de période de signal de synchronisation reçues. Encore une fois, la détermination de la fréquence image de référence est faite de façon repartie, sans nécessiter d'algorithmes complexes pour élire un dispositif responsable de cette détermination. De façon générale, chaque dispositif disposant de toutes les indications nécessaires peut déterminer lui-même la fréquence image de référence et la fréquence cible Par ailleurs, il peut être prévu que: la détermination, par les dispositifs de leurs propres fréquences images source ou d'affichage, la transmission de ces fréquences aux autres dispositifs, et l'obtention, par chaque dispositif ayant reçu les fréquences des autres dispositifs, de la fréquence image cible par détermination d'une fréquence d'image de référence en fonction des fréquences images sources ou d'affichage reçues, sont effectuées périodiquement par lesdits dispositifs. Cette périodicité garantit un suivi de l'évolution des horloges propres à chaque dispositif (par exemple en fonction de la température). Ainsi, l'efficacité de l'invention peut être conservée en mettant à jour périodiquement la fréquence image de référence ou cible à l'aide de cette surveillance. Des mécanismes complexes de gestion de dérive et de compensation peuvent donc être évités. Dans un mode de réalisation de l'invention, l'adaptation du flux vidéo source comprend la duplication d'au moins une image afin que le flux vidéo atteigne ladite fréquence image cible.

Cette disposition, mettant en oeuvre une duplication d'image, permet de conserver l'intégrité des données car il n'y a pas suppression d'information. Le confort visuel (à l'affichage du flux vidéo) se trouve amélioré. En outre, la manipulation par image entière selon l'invention s'avère de mise en oeuvre plus simple, au niveau des dispositifs du réseau, qu'une manipulation par pixel ou ligne. En particulier, la duplication comprend une étape de calcul d'une dérive entre la fréquence image source et la fréquence image cible, et le nombre d'images à dupliquer est fonction de la dérive calculée pour atteindre la fréquence image cible.

Dans un mode de réalisation de l'invention, l'adaptation du flux vidéo source est effectuée par chaque dispositif récepteur recevant un flux vidéo source qui présente une fréquence image source inférieure à la fréquence image cible. Cette disposition permet un gain de bande passante sur le réseau car les images dupliquées ne sont pas transmises sur celui-ci.

En particulier, on peut prévoir que ledit dispositif récepteur détermine, à partir de la fréquence image cible et de la fréquence d'image dudit flux vidéo source reçu, les images à dupliquer dans ledit flux vidéo. Ainsi, l'émetteur n'est pas mis à contribution, ce qui est avantageux dans le cas où celui-ci est muni de faibles ressources matérielles et logicielles. En variante, ledit dispositif émetteur détermine les images à dupliquer dans ledit flux vidéo et les indique à un dispositif récepteur dudit flux vidéo source. Dans cette configuration, les traitements sont équitablement répartis entre les dispositifs émetteurs et récepteurs, tout en garantissant une utilisation raisonnable de la bande passante du réseau. En particulier, lesdites images à dupliquer sont signalées dans l'entête de paquets transportant le flux vidéo. Cela simplifie le traitement au niveau du dispositif récepteur. Dans un mode de réalisation de l'invention, l'adaptation du flux vidéo source est effectuée par chaque dispositif émetteur recevant un flux vidéo source présentant une fréquence image source inférieure à la fréquence image cible. On évite ainsi d'avoir recours à des ressources mémoires supplémentaires du côté du dispositif récepteur, prévues pour stocker les images à dupliquer. En particulier, l'adaptation du flux vidéo source par un dispositif émetteur est effectuée par lecture, à ladite fréquence image cible, d'une mémoire tampon stockant ledit flux vidéo d'une source. Comme il a pu l'être précisé précédemment, cette lecture à la fréquence image cible est rendu possible par la présence des images dupliquées dans la mémoire tampon. Dans un autre mode de réalisation de l'invention, l'ajustement de la fréquence image d'affichage d'un dispositif récepteur comporte une étape de synchronisation par asservissement du dispositif récepteur pour compenser une dérive entre la fréquence image d'affichage et la fréquence image cible.

De la sorte, les fréquences images de chaque couple émetteur/récepteur étant asservies, les mémoires tampon de réception ne seront jamais ni complètement vides ni trop pleines.

En particulier, le procédé peut comprendre: la détection, par le dispositif récepteur, d'une dérive positive représentative d'une fréquence image d'affichage plus élevée que la fréquence image cible; l'émission, par le dispositif récepteur et à destination des autres dispositifs, d'un signal d'alerte en réponse à la détection d'une dérive positive; et une mise à jour de la fréquence image cible par les dispositifs en réponse au signal d'alerte. Cette configuration permet de changer rapidement la fréquence image cible dès qu'elle n'est plus la fréquence la plus élevée. Encore une fois, grâce à la diffusion d'un signal d'alerte et à la capacité des dispositifs à déterminer eux-mêmes la fréquence image cible, ces opérations peuvent être totalement réparties, sans noeud d'étranglement constitué classiquement par un équipement central. Selon une caractéristique particulière, la mise à jour de la fréquence image cible comprend: la détermination, par les dispositifs de leurs propres fréquences images source ou d'affichage, la transmission de ces fréquences aux autres dispositifs, et l'obtention, par chaque dispositif ayant reçu les fréquences des autres dispositifs, de la fréquence image cible par détermination d'une fréquence d'image de référence en fonction des fréquences images sources ou d'affichage reçues. Selon une autre caractéristique particulière, l'adaptation du flux vidéo source comprend la duplication d'images à une fréquence de duplication afin que le flux vidéo atteigne ladite fréquence image cible, et la fréquence de duplication est mise à jour à détection du signal d'alerte. Cette disposition permet d'avoir une adaptation efficace, qui suit l'évolution de la fréquence image cible. Dans un mode de réalisation de l'invention, l'ajustement de la fréquence image d'affichage d'un dispositif récepteur recevant un flux vidéo comporte la suppression ou l'ajout d'au moins une ligne d'image dans une partie inactive d'une image du flux vidéo, de sorte à modifier artificiellement la fréquence image d'affichage au dispositif récepteur. De la sorte, il n'est pas nécessaire de modifier l'horloge pixel pilotant l'affichage. La qualité de l'affichage résultant s'en trouve améliorée.

Dans un autre mode de réalisation de l'invention, le procédé peut comprendre une étape de réajustement d'une horloge pixel (définissant une fréquence de lecture des pixels dans le flux vidéo) du dispositif récepteur lorsque une dérive négative représentative d'une fréquence image cible, régénérée par le dispositif récepteur et plus faible que la fréquence image cible, est détectée comme étant supérieure, en valeur absolue, à une valeur seuil. Corrélativement, l'invention se rapporte également à un système de distribution de flux vidéo d'images comprenant, reliés à un réseau de communication, au moins trois dispositifs émetteurs ou récepteurs, dont un dispositif émetteur et un dispositif récepteur, parmi un dispositif émetteur étant configuré pour recevoir, d'une source, un flux vidéo source présentant une fréquence d'images, dite fréquence image source, un dispositif récepteur étant configuré pour contrôler l'affichage, à une fréquence d'affichage, dite fréquence image d'affichage, d'un flux vidéo sur un dispositif d'affichage auquel il est relié, système caractérisé en ce qu'il comporte un moyen d'obtention d'une fréquence d'images, dite fréquence image cible, commune pour les dispositifs, et dans lequel chaque dispositif de l'ensemble des dispositifs émetteurs ou de l'ensemble des dispositifs récepteurs comprend des moyens d'adaptation d'un flux vidéo source reçu d'une source, respectivement, directement ou au travers d'un dispositif émetteur, de la fréquence image source à la fréquence image cible, et chaque dispositif récepteur comprend un moyen d'ajustement de sa propre fréquence image d'affichage à la fréquence image cible de sorte à contrôler un affichage à ladite fréquence image cible. Le système présente des avantages similaires à ceux du procédé exposé ci-dessus, notamment de permettre une commutation de sources (via une commutation de dispositifs émetteurs par exemple) ou de dispositifs récepteurs prévus pour piloter un affichage, sans re-synchronisation des paires de dispositifs communiquant entre eux. De façon optionnelle, le système peut comprendre des moyens se rapportant aux caractéristiques du procédé exposé précédemment. L'invention concerne également un dispositif émetteur ou récepteur d'un flux vidéo au sein d'un réseau de communication comprenant au moins trois dispositifs émetteurs ou récepteurs, dont un dispositif émetteur et un dispositif récepteur, caractérisé en ce qu'il comporte: des moyens de réception de fréquences images propres en provenance des autres dispositifs du réseau; un moyen d'obtention d'une fréquence d'images commune, dite fréquence image cible, par détermination d'une fréquence d'images de référence en fonction des fréquences images reçues et en fonction d'une fréquence image locale audit dispositif définissant une fréquence de transmission d'un flux vidéo à un dispositif aval, notamment un dispositif d'affichage des moyens configurés pour ajuster la fréquence image locale à la fréquence image cible de sorte à transmettre, à ladite fréquence image cible et à destination du dispositif aval, un flux vidéo reçu.

Ce dispositif présente des avantages similaires à ceux du procédé exposé ci-dessus, et peut comprendre, de façon optionnelle, des moyens se rapportant aux caractéristiques du procédé exposé précédemment. Notamment, le dispositif peut comprendre en outre: un moyen de détermination d'une période d'un signal de synchronisation du 25 dispositif par rapport à une horloge réseau commune de sorte à obtenir ladite fréquence image locale au dispositif, des moyens de transmission à destination des autres dispositifs du réseau, de la valeur de la période de signal de synchronisation déterminée et d'une information renseignant le type de dispositif, émetteur ou récepteur, dont 30 provient la valeur transmise. Selon une caractéristique particulière, il peut également comprendre une mémoire tampon pour stocker des données dudit flux vidéo, et être configuré pour écrire ou lire ladite mémoire tampon à ladite fréquence image cible. L'invention concerne également un moyen de stockage d'informations, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre un procédé de synchronisation conforme à l'invention lorsque ce programme est chargé et exécuté par le système informatique. L'invention concerne également un programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre un procédé de synchronisation conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur. Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre.

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 : - les Figures la, lb et le illustrent trois exemples de systèmes de communication pour des mises en oeuvre de l'invention ; - la Figure 2a 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 2b représente un dispositif de communication de type noeud émetteur disposant de deux parties émettrices 206 pour recevoir et traiter 25 deux sources; - la Figure 3 illustre des détails d'interconnexion entre modules dans la partie émetteur 206 de la Figure 2a ou 2b ; - la Figure 4a illustre un format possible de paquet vidéo ; - la Figure 4b représente l'algorithme exécuté par le module de 30 transmission de paquets vidéo 216 de la Figure 3 selon un premier mode de réalisation ; - la Figure 4c représente l'algorithme exécuté par le module de transmission de paquets vidéo 216 de la Figure 3 selon un deuxième mode de réalisation ; - la Figure 5a est une vue détaillée du module " partie d'affichage " 5 205 de la Figure 2a ; - 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 dans le premier mode de réalisation ; 10 - la Figure 5d représente l'algorithme exécuté par le module 500 de la Figure 5a dans le deuxième mode de réalisation ; - 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 15 " Vsync monitor " 530 de la Figure 5b ; - la Figure 7 illustre un algorithme de calcul de la période image source ou d'affichage par le dispositif de communication de la Figure 2a ou 2b, selon l'invention ; - les Figures 8a, 8b et 8c illustrent, sous la forme d'algorithmes, le 20 fonctionnement du module " video synchro generator " 503 de la Figure 5a ; - les Figures 9 et 10 illustrent un algorithme de détermination de paramètres de correction de flux vidéo, comprenant la détermination de la période image cible et d'une période correspondante de duplication ainsi que leur surveillance pour mise à jour, selon l'invention; et 25 - les Figures 11a et 11b illustrent le fonctionnement, selon l'invention, des opérations d'écriture et de lecture de la mémoire tampon 312 de la Figure 3. Les Figures la à 1c présentent différents contextes non illustratifs dans lesquels l'invention peut être appliquée, aux fins notamment de fournir une 30 fréquence commune, ou fréquence image cible notée ci-après FlmCible, à l'ensemble des dispositifs d'un système de distribution de flux vidéo. L'utilisation d'une telle fréquence commune permet d'éviter une re-synchronisation des dispositifs en cas de commutation, pour un dispositif récepteur, entre des dispositifs ou noeuds émetteurs reliés à des sources ou, pour un dispositif émetteur, entre des dispositifs ou noeuds récepteurs prévus pour l'affichage des flux vidéo.

La Figure la présente un premier scénario d'utilisation d'un système multi-projection sans fil 100. Le système 100 comprend notamment une source vidéo centralisée 101 pouvant fournir plusieurs sorties vidéo simultanément (PC serveur vidéo par exemple dont les deux sorties sources ne sont pas synchronisées). La source vidéo 101 est connectée à un dispositif émetteur (DE) ou noeud émetteur 102 (on désignera par la suite « noeuds émetteurs » les noeuds réseau connectés à une ou plusieurs sources) à travers une connexion vidéo numérique standard (par exemple conforme au standard HDMI). Le dispositif émetteur 102 communique avec des dispositifs récepteurs (DR) ou noeuds récepteurs 103 au moyen d'une transmission sans-fil (par exemple 60 GHz 801.15.3c). Chaque noeud récepteur 103 est connecté à un dispositif d'affichage 104 tel qu'un écran ou projecteur au moyen d'une connexion vidéo numérique standard 105 (par exemple au standard HDMI). On désignera par la suite « noeuds récepteurs » les noeuds réseau connectés à un ou plusieurs dispositifs d'affichage).

Le noeud émetteur 102 reçoit des flux vidéo ou données vidéo DATA dits "source" de la source 101. Ces flux présentent une fréquence d'images propre, dite fréquence image source (en images par seconde par exemple) et notée FlmSource. Le noeud émetteur 102 transmet ces flux vidéo par le biais d'un réseau sans fil aux noeuds récepteurs 103. Ces derniers délivrent alors les flux vidéo source reçus aux projecteurs 104 en imposant un débit pour l'affichage correspondant à une fréquence image d'affichage (FImAff, nombre d'images par seconde) contrôlée par chacun des dispositifs récepteurs (fréquence image d'affichage défini par l'horloge locale du dispositif récepteur).

Les flux vidéo source sont deux portions d'une même image. Ainsi, ils sont projetés en temps réel sous forme d'une seule grande image homogène par le système multi-projection 100.

Dans ce cas de figure, le noeud émetteur 102 considère chaque sortie source comme indépendante, et exécute, pour chacune des sorties sources (donc chaque flux vidéo source), des traitements de calculs de fréquence image source, de fréquence image de référence ou cible et de période de duplication comme décrits ci-après. A noter que dans un mode de réalisation où le noeud ou dispositif émetteur DE réalise une adaptation des flux vidéo sources pour qu'ils soient conformes à la fréquence image cible avant de les transmettre aux noeuds ou dispositifs récepteurs DR, une mémoire tampon 312 telle que décrite ci-après en référence aux Figures 11a et 11b, est prévue au niveau de ce noeud émetteur 102 pour chacune des sorties sources. Pour la suite, on notera "P" une période et "F" une fréquence correspondante: F=1/P. On passera indifféremment de l'une des valeurs à l'autre pour désigner une caractéristique d'un signal de synchronisation.

Ainsi, PlmSource et FlmSource représentent les période et fréquence image source d'un flux vidéo DATA issu d'une source 101; PImAff et FImAff, les période et fréquence image d'affichage contrôlées par un noeud récepteur pour piloter l'affichage d'un flux vidéo sur un dispositif d'affichage; PlmLocale et FlmLocale, les période et fréquence propre à un dispositif émetteur ou récepteur. A noter que PlmLocale et FlmLocale désignent respectivement PlmSource et PImAff, et FlmSource et FImAff; PlmRef et FlmRef, des période et fréquence image de référence; PlmCible et FlmCible, des période et fréquence image cible.

Dans un deuxième scénario illustré par la Figure lb, deux vidéo-projecteurs 104 affichent deux flux vidéo générés par deux caméras haute définition 101 correspondantes. La sortie de chaque caméra 101 est reliée à un noeud émetteur 102 (par exemple par le biais d'un câble HDMI) qui transmet un flux vidéo à un noeud récepteur correspondant 103 par le biais d'un réseau sans fil. Les noeuds récepteurs délivrent les flux vidéo reçus aux projecteurs 104 respectifs.

Les flux vidéo sont ensuite projetés en temps réel sous forme d'une seule grande image homogène par le système multi-projection 100. Dans ce cas de figure, chaque noeud émetteur 102 exécute des traitements de calculs de fréquence image source, de fréquence image de référence ou cible et de période de duplication comme décrits ci-après, pour la source 101 à laquelle il est rattaché. A noter que dans un mode de réalisation où les noeuds ou dispositifs émetteurs DE réalisent une adaptation du flux vidéo source reçu pour qu'il soit conforme à la fréquence image cible avant de les transmettre à un noeud ou dispositif récepteur DR, une mémoire tampon 312 telle que décrite ci-après en référence aux Figures 11a et 11b, est prévue au niveau de chaque noeud émetteur 102. La Figure 1c présente un troisième scénario d'utilisation d'un système multi-projection sans fil 100.

Dans ce scénario, deux vidéo-projecteurs 104 affichent les données provenant d'une source vidéo centralisée 101 générant plusieurs sorties vidéo simultanément (PC serveur vidéo par exemple). Ces sorties vidéos sont fournies à un premier noeud ou dispositif émetteur DE1 qui encode un premier flux vidéo DATA et le transmet par le biais du réseau sans fil à un premier noeud ou dispositif récepteur DR1. Le premier noeud ou dispositif émetteur DE1 est connecté à un second noeud ou dispositif réseau émetteur DE2, par exemple au moyen d'un lien de type Ethernet ou un bus a haut débit de type IEEE 1394. Le premier noeud ou dispositif émetteur DE1 transmet, au deuxième noeud ou dispositif émetteur DE2 par le biais de ce lien, les données correspondant à un second flux vidéo. Ce second noeud émetteur transmet ensuite le second flux vidéo par le biais du réseau sans fil à un second noeud ou dispositif récepteur DR2. Les noeuds récepteurs 103 délivrent les flux vidéo reçus aux projecteurs 104 qui les projetent en temps réel sous forme d'une seule grande image homogène.

Ce scénario permet d'introduire de la diversité de chemin réseau pour une résistance accrue aux perturbations d'un chemin, et/ou d'augmenter la bande passante du réseau si les deux couples émetteur/récepteur utilisent des fréquences radio différentes.

Dans ce cas de figure, le premier noeud ou dispositif émetteur DE1 considère chaque sortie source comme indépendante, et exécute les traitements de calculs de fréquence image source, de fréquence image de référence ou cible et de période de duplication comme décrits ci-après, pour chacune des sorties source.

A noter que dans un mode de réalisation où le premier noeud ou dispositif émetteur DE1 réalise une adaptation des flux vidéo sources pour qu'ils soient conformes à la fréquence image cible avant de les transmettre aux noeuds ou dispositifs récepteurs DR, une mémoire tampon 312 telle que décrite ci-après en référence aux Figures 11a et 11b, peut être prévue au niveau du premier noeud ou dispositif émetteur DE2 pour chacune des sorties sources. En variante, chaque noeud émetteur 102 peut exécuter ces traitements uniquement pour la sortie source qu'il retransmet à un noeud récepteur 103. Une mémoire tampon 312 dans chaque noeud émetteur peut alors être prévue pour traiter le flux vidéo dont il s'occupe.

La Figure 2a 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 aux écritures 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: une horloge réseau. 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 101, à travers un connecteur HDMI 105. 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 un module commercialisé sous la référence AD9880 par la société Analog 25 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é module "Vsync Sampler", des informations temporelles, notamment une 30 période de synchronisation verticale (Vsync) des données vidéo. Cette période est définie entre deux fronts montant successifs du signal de synchronisation verticale fourni par l'interface HDMI. Elle est représentative, pour le dispositif émetteur 102 correspondant, d'une fréquence de l'image, également dénommée "fréquence image source" FlmSource. 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 partie contrôleur de réseau 207. Le module 217, quant à lui, est chargé de l'échantillonnage des apparitions du signal de synchronisation verticale Vsync provenant du module récepteur HDMI 215, et fournit en sortie, au module 216, la dernière valeur de période PlmSource des données échantillonnées.

L'échantillonnage est plus particulièrement réalisé en générant un instant donné ("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. La période PlmSource entre deux fronts montant consécutifs peut ainsi être aisément calculée en soustrayant les deux instants correspondants à ces fronts montants. Le calcul de la période PlmSource est décrit ci-après en référence à la Figure 7 par, par exemple, la mise en oeuvre d'un compteur incrémenté à chaque front montant d'horloge réseau entre deux fronts montants du signal de synchronisation source. La valeur de la période PlmSource peut alors être transmise au module 216 afin que ce dernier l'exploite. La sous-partie d'affichage 205 comprend un module 214 de 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 toute valeur de période PlmCible (si elle est renseignée comme expliqué par la suite) qui est ensuite transmise à un module 213 de gestion de synchronisation RX. Le module 213 génère des signaux de synchronisation ou de contrôle vidéo sur la base de cette période PlmCible, et les transmet à un module transmetteur HDMI 212.

Le module 213 lit également les pixels stockés dans le module 214 suivant cette synchronisation et les transmet au module de transmission HDMI 212. Comme on le verra par la suite, un noeud récepteur dispose de toutes les informations utiles pour déterminer la fréquence ou période image cible. Ainsi, on peut se passer de l'indication de la période cible dans les paquets transmis. La sous-partie d'affichage 205 sera décrite plus en détail en référence aux Figures 5a et 5b.

Le module de transmission HDMI 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 de transmission HDMI 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. Par la mise en oeuvre de l'invention, ces signaux sont cohérents avec un affichage des données vidéo à la fréquence image cible. 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 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 met en oeuvre un pilote logiciel HDMI qui peut être obtenu à partir d'un fabricant de puces ou circuits conformes au standard HDMI. On notera qu'un dispositif ou noeud émetteur DE 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-partie d'affichage 205 n'est pas nécessaire.

De même, un dispositif ou noeud récepteur DR 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.

La Figure 2b illustre un dispositif émetteur DE qui peut traiter simultanément plusieurs flux vidéo sources, comme par exemple dans les scénarii des Figures la et 1c. Dans le présent exemple, le dispositif est "double" en ce qu'il comporte deux sous-parties sources 206, et peut donc traiter les données provenant de deux sources simultanément. Bien entendu, un plus grand nombre de sous-parties 206 et de sources peut être envisagé pour un même dispositif. Les données vidéo provenant d'une première source sont transmises au module réseau 207, via une première sous-partie source 206 (celle du haut sur la figure) comme expliqué précédemment.

Les données vidéo DATA de la deuxième source sont traitées par la deuxième sous-partie 206, puis passent par un module d'aiguillage 218. Ce module 218 permet de diriger les données vidéo soit vers le module réseau sans fil 207 (scénario de la Figure la par exemple), soit vers un module réseau filaire 219 pour transmettre les données vidéo vers un second noeud émetteur DE2, afin de dupliquer les chemins de données du réseau sans fil (meilleure robustesse aux perturbations) ou d'augmenter la bande passante total du réseau sans fil (scénario de la Figure 1c par exemple). Le module réseau filaire 219 peut être de type Ethernet haut débit ou IEEE 1394 par exemple.

Bien entendu, l'invention peut mettre en oeuvre d'autres types de hiérarchie de ces modules, par exemple à l'aide d'un module d'aiguillage 218 prenant en compte l'ensemble des flux vidéo en sortie des sous-parties 206. 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 Pixel_clk), 302 (signal de synchronisation horizontale Hsync) et 304 (signal de synchronisation verticale Vsync). Le module échantillonneur du signal Vsync 217 reçoit du module récepteur HDMI 215 le 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) générée par une horloge réseau commune du réseau de communication auquel sont connectés les différents dispositifs émetteur et récepteur.

Le module 217 génère à son tour et transmet au module 216 une information de durée 306 représentative de la période PlmSource. 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, l'information de durée 306 représentative de la période PlmSource. Le module 216 élabore alors des paquets de données vidéo 307 sur la base des informations et données précédentes et les transmet à la partie contrôleur de réseau 207. A noter que si les noeuds émetteurs indiquent, dans l'entête des paquets, la fréquence/période image cible après adaptation des données vidéo conformément à l'invention, le module 216 reçoit également des informations relatives aux fréquences images FlmLocale propres aux autres dispositifs. C'est à partir de ces fréquences propres que le noeud émetteur peut déterminer la fréquence image cible et procéder à l'adaptation des données vidéo DATA par duplication d'images, comme expliqué par la suite. Dans un mode de réalisation où les noeuds ou dispositifs émetteurs DE réalisent cette adaptation du flux vidéo source reçu pour qu'il soit conforme à la fréquence image cible avant de les transmettre à un noeud ou dispositif récepteur DR, le module 216 comprend également une mémoire tampon 312 (un dispositif émetteur peut donc contenir plusieurs mémoires tampon 312 s'il possède plusieurs sous-parties source 206).

La mémoire tampon 312 est dimensionnée pour par exemple contenir au moins deux images complètes. Selon les cas d'utilisation, cette valeur peut être ajustée. Sa gestion est décrite ci-après en référence aux Figures 11a et 11b. Elle est utilisée pour dupliquer certaines images sur la partie réseau sans fil tout en continuant de recevoir les données du module 215. Cette duplication assure l'adaptation du flux vidéo source reçu pour qu'il atteigne la fréquence image cible, c'est-à-dire un débit cible. Par exemple, en dupliquant une image toutes les 100 images, on peut passer d'une fréquence image source de 25 im/s à une fréquence image cible de 25,25 im/s.

A noter que le réseau sans fil est prévu pour avoir une bande passante utile égale ou supérieure à celle de la source 101 la plus rapide (ayant le plus gros débit) dans le système 100, de façon à ne pas constituer un goulet d'étranglement sur le chemin de données. En effet, dans le présent mode de réalisation, la mise en oeuvre de l'invention prévoit, comme décrit par la suite, que cette mémoire tampon 312 est lue au débit correspondant à la fréquence image cible sur tous les noeuds ou dispositifs émetteurs DE, afin que la transmission des images ainsi dupliquées se répartisse sur l'ensemble de la période de duplication d'image sans créer de pic de transmission sur le réseau.

En choisissant efficacement la fréquence image cible FlmCible, par exemple la fréquence la plus élevée dans l'ensemble des fréquences images sources (FlmSource) comme décrit plus loin, la mémoire tampon 312 est ainsi lue plus rapidement qu'elle n'est écrite: écriture avec le débit correspondant à la fréquence image source locale, et lecture avec le débit correspondant à la fréquence image cible, c'est-à-dire la fréquence image source la plus élevée. Ce décalage de vitesse est toutefois compensé, selon une réalisation de l'invention, par la duplication de la lecture des données correspondant aux images à dupliquer comme cela est décrit plus en détail ci-après en référence à la Figure 11 b. On décrit maintenant en référence à la Figure 7, la détermination de la valeur de la période "PlmLocale" du signal de synchronisation verticale Vsync par les modules échantillonneurs 213 et 217 des noeuds émetteur et récepteur. PlmLocale signifie PlmSource ou PImAff selon le type de dispositif (émetteur ou récepteur) pris en compte. 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.

Ces modules reçoivent l'horloge réseau du module 208, et le signal Vsync 304/508 du module 215 pour les noeuds émetteur ou du module 214 pour les noeuds récepteur. Au cours d'une première étape 900, un compteur « periode_cpt » est initialisé à 0, puis on attend un front montant du signal Vsync (étape 901).

L'arrivée d'un front montant Vsync déclenche l'attente d'un front montant de l'horloge réseau (étape 902). On se met alors en attente d'un nouveau front montant (étape 903). Si le front montant suivant n'est pas un front montant du signal Vsync (test 904 - auquel cas il s'agit d'un front montant d'horloge réseau), on incrémente le compteur « periode_cpt » (étape 905). On se remet en attente du front montant suivant en retournant à l'étape 903. Si on a observé un nouveau front montant sur le signal Vsync, on fournit la valeur du compteur « periode_cpt » comme résultat (étape 906).

Ainsi, le résultat fourni représente le nombre de fronts montant d'horloge réseau au cours duquel il y a un front montant de plus sur le signal Vsync. Ce résultat est ainsi représentatif, relativement à l'horloge réseau, de la période "PlmLocale" de synchronisation propre au dispositif considéré, c'est-à-dire de la fréquence image "FlmLocale" propre à ce dispositif, à savoir la fréquence image source FlmSource pour un dispositif émetteur et la fréquence image d'affichage FImAff pour un dispositif récepteur.

Pour obtenir un résultat plus précis, le calcul peut se faire sur plusieurs périodes du signal Vsync consécutives. La précision de la mesure dépend aussi du rapport entre les périodes du signal Vsync et de l'horloge réseau. Si la période de l'horloge réseau est trop grande par rapport à celle du signal Vsync, on peut utiliser un multiple de l'horloge réseau. On décrit maintenant en référence aux Figures 9 et 10 les mécanismes mis en oeuvre dans un mode de réalisation de l'invention pour obtenir et maintenir à jour la fréquence image cible FlmCible commune à l'ensemble des dispositifs, ainsi que la période de duplication d'images (notée Pduplication) que chaque dispositif indique ou met en oeuvre pour adapter un flux vidéo à la fréquence image cible. Les algorithmes décrivant ces mécanismes comprennent, chacun, une série d'étapes, instructions ou portions de code logiciel exécutées lors de l'exécution de l'algorithme.

Comme il ressortira de la suite, un mode de réalisation de l'invention prévoit que l'obtention mette en oeuvre une détermination, par chaque noeud du réseau (émetteur ou récepteur), d'une valeur représentative de la fréquence image "locale" FlmLocale qu'il met en oeuvre: pour un noeud émetteur 102, une fréquence image source correspondant à la fréquence des données vidéo reçues de la source 101; pour un noeud récepteur 103, une fréquence image d'affichage correspondant à la fréquence des données vidéo qu'il transmet au dispositif d'affichage 104, comme décrit précédemment en lien avec la Figure 7. Cette fréquence peut notamment être indiquée sous la forme de la période PlmLocale du signal de synchronisation verticale Vsync, par rapport à une horloge réseau commune. Chaque fréquence image "locale" FlmLocale (source ou d'affichage) ou période PlmLocale correspondante est alors transmise, par chacun des noeuds à l'ensemble des autres noeuds du réseau, accompagnée d'une information "Type" renseignant le type de dispositif, émetteur ou récepteur, dont provient la fréquence image transmise. Chaque noeud du réseau, ou éventuellement une sous-partie de ceux-ci (par exemple dans le mode de réalisation où l'ensemble des adaptations est réalisé sur les uniques noeuds récepteurs sans intervention des noeuds émetteurs après avoir émis ces fréquences images locales FlmLocale) détermine alors une fréquence image de référence "FlmRef parmi les fréquences images locales reçues, notamment en sélectionnant la fréquence d'image la plus élevée (i.e. la période PlmLocale la plus courte) parmi les fréquences images locales FlmLocale prises en compte. Cette fréquence image de référence correspond donc à un dispositif du réseau, noté par la suite dispositif ou noeud de référence DRef. Selon un premier mode de réalisation, seules les fréquences images locales FlmLocale de type fréquences images sources FlmSource (provenant des noeuds émetteurs) sont prises en compte. En variante, on peut tenir compte des fréquences images sources FlmSource et d'affichage FImAff. D'autres approches sont également possibles dans le cadre de l'invention. La fréquence image cible FlmCible peut alors se déduire de la fréquence image de référence FlmRef, et être fonction du type correspondant au dispositif de référence (déduit à partir de l'information "Type" rattachée à la période image locale retenue comme période de référence). Par exemple, la fréquence image cible FlmCible est égale à la fréquence d'image de référence FlmRef si cette dernière est une fréquence image source ("Type"=émetteur): FlmCible=FlmRef; et la fréquence image cible FlmCible est strictement supérieure à la fréquence d'image de référence FlmRef si cette dernière est une fréquence image d'affichage ("Type"=récepteur): FlmCible=FlmRef+s, où s est très faible comparé à FlmRef, notamment moins de 0,1%, par exemple s=0,01 Hz=0,01 im/s.

Comme on le verra par la suite, l'adaptation des données vidéo DATA selon l'invention peut alors comprendre une duplication d'images dans ces données vidéo pour que ces dernières, une fois la duplication réalisée, atteignent une fréquence image égale à FlmCible. Selon diverses modes de réalisation, cette adaptation peut être menée par chaque noeud récepteur ou par chaque noeud émetteur recevant des données vidéo source qui présentent une fréquence image source inférieure à la fréquence image cible. Comme chaque noeud reçoit les fréquences images FlmLocale de tous les autres noeuds du réseau, il est capable de déterminer la fréquence image cible FlmCible et donc de décider s'il doit effectuer une telle adaptation. Dans le cas où les noeuds récepteurs mènent cette adaptation, les images à dupliquer peuvent être déterminées par eux-mêmes, ou, en variante, par les noeuds émetteurs qui les indiquent alors dans les données vidéo, par exemple dans les entêtes des paquets de données vidéo. Cette adaptation des données vidéo à la fréquence cible FlmCible permet que les communications entre différents dispositifs du réseau s'opèrent en mettant en oeuvre cette fréquence commune. Ainsi, toute commutation entre des dispositifs du réseau n'entraîne pas de resynchronisation. Enfin, pour permettre un affichage cohérent de ces données vidéo (sans coupure d'affichage ni décalage entre plusieurs portions d'une même image affichées sur plusieurs dispositifs d'affichages juxtaposés), les fréquences images d'affichage FImAff des noeuds récepteurs sont également ajustées à la fréquence image cible FlmCible. Il en résulte en effet une gestion optimale des mémoires tampon de réception du dispositif récepteur, car la lecture et l'écriture dans ces mémoires est effectuées à la même fréquence image cible FlmCible ce qui évite un vidage ou un remplissage trop important de ces mémoires (pouvant respectivement provoquer une coupure d'image et une perte d'image) Ainsi dans le cas où les noeuds émetteurs réalisent eux-mêmes l'adaptation des données vidéo DATA (ou réalise tout au moins le détermination des images à dupliquer pour procéder à cette adaptation), en référence à la Figure 9, l'étape 1000 marque le début de l'algorithme dans un quelconque noeud émetteur 102 ou récepteur 103 du réseau. Cette étape peut correspondre soit à la fin de l'initialisation du noeud dans le cas où ce dernier vient de rejoindre le réseau existant, soit à la détection d'un autre noeud venant de rejoindre le réseau.

On note « prét_pour_correction » une variable indiquant que les calculs des paramètres de fréquence commune et de période de duplication ("paramètres de correction") sont effectués pour le noeud courant. Cette variable prend la valeur « faux » au cours de l'étape 1001. A noter qu'elle gardera cette valeur tant que les paramètres ci-dessus ne seront pas déterminés pour ce noeud. A l'étape 1002, la valeur de la période PlmLocale est déterminée conformément à ce qui a été décrit ci-dessus en lien avec la Figure 7. Cette valeur est alors envoyée, à l'étape 1003, à tous les autres noeuds du réseau, par le biais d'un message contenant notamment la valeur mesurée et le type du noeud courant (émetteur ou récepteur). Une fois toutes les valeurs calculées par les autres noeuds du réseau reçues par le noeud courant (étape 1004), la fréquence image de référence FlmRef est déterminée par celui-ci (étape 1005) comme étant la fréquence FlmLocale ayant la période PlmLocale la plus courte. Tous les noeuds du réseau ayant à leur disposition les mêmes informations, ils convergeront dans la détermination de la fréquence image de référence FlmRef. Si le noeud courant est un noeud récepteur 103 (rattaché à un projecteur - test 1006), il est prêt à appliquer les corrections de la fréquence des données vidéo reçues (par duplication afin d'adapter le débit global) et passe donc à l'étape 1010 mettant la variable « prêt_pour_correction » à « vrai ». Toutefois, s'il doit déterminer lui-même les périodes de duplication, il met en oeuvre les traitements décrits ci-après pour un noeud émetteur. Sinon (noeud courant = noeud émetteur 102), la période de duplication Pduplication des images (en nombre d'images) pour atteindre la fréquence image cible FlmCible est calculée.

Dans le cas où la fréquence image de référence FlmRef correspond à une fréquence image source FlmSource (test 1007) et que le noeud courant n'est pas le noeud de référence DRef (test 1012 - noeud dont le signal Vsync est le signal de référence), la période de duplication Pduplication est égale à (étape 1009): 1/((1/PlmRef - 1/PlmLocale) * PlmLocale) où PlmRef est la période de la fréquence image de référence FlmRef, et PlmLocale est la période correspondant à la fréquence image locale FlmLocale du noeud courant. Ainsi, en dupliquant une image toutes les "Pduplication" images, le noeud source courant obtient une fréquence image égale à la fréquence image cible FlmCible, elle-même égale à la fréquence image de référence FlmRef. A noter que si le noeud courant est un noeud émetteur 102, et est le noeud de référence DRef (tests 1007 et 1012), il n'a pas de correction à apporter car le débit des données vidéo DATA est déjà adapté. Dans ce cas, Pduplication = 0 pour se différencier des autres noeuds (étape 1013). Dans le cas où la fréquence image de référence FlmRef correspond à une fréquence image d'affichage FImAff (test 1007), la période de duplication Pduplication est égale à (étape 1008): 1/((1/PlmRef - 1/PlmLocale + * PlmLocale) où E (identique pour tous les noeuds) vaut par exemple 0.01 Hz. Ainsi, en dupliquant une image toutes les "Pduplication" images, le noeud source courant obtient une fréquence image égale à la fréquence image cible FlmCible = FlmRef + E. Le noeud courant est ainsi prêt à appliquer les corrections et passe donc à l'étape 1010, au cours de laquelle la variable « prét_pour_correction » prend la valeur « vrai ». On passe ensuite à une phase de surveillance et de mise à jour de ces paramètres (Pduplication et FlmCible), représentée sur la figure par l'étape 1011. En effet, les horloges des sources 101 (définissant les fréquences images sources) et des différents noeuds (fréquences images d'affichage pour les noeuds 103) pouvant varier au cours du temps (avec la température ambiante par exemple), il peut donc se passer que le signal Vsync choisi comme référence lors de l'initialisation ne soit plus le plus rapide après un laps de temps.

L'étape 1011 vise donc à vérifier régulièrement ou périodiquement et à mettre à jour, si nécessaire, le choix du signal Vsync de référence et donc la valeur de la fréquence image cible FlmCible, ainsi que des corrections à apporter (Pduplication notamment). Cette étape 1011 est décrite maintenant plus en détail en référence à la Figure 10.

A noter que comme lors des étapes 1000 à 1010, ces surveillance et mise à jour comprennent: la détermination, par les noeuds de leurs propres fréquences images source ou d'affichage FlmLocale, la transmission de ces fréquences aux autres noeuds, et l'obtention, par chaque noeud ayant reçu les fréquences des autres noeuds, de la fréquence image cible FlmCible par détermination d'une fréquence d'image de référence FlmRef en fonction des fréquences images sources ou d'affichage reçues, Au cours de l'étape 1020, on attend soit la fin d'un délai de rafraîchissement des paramètres de correction (par exemple toutes les minutes), soit l'arrivée d'un message d'alerte « ajout de ligne » provenant d'un noeud récepteur (décrit par la suite en référence à la Figure 6b). Ce message arrive soit par le réseau sans fil soit en interne si la détection d'ajout de ligne se fait sur le noeud courant. Cette alerte est déclenchée par un noeud récepteur 103 dont les algorithmes de correction d'horloge (décrits plus loin) détectent que le signal de synchronisation Vsync qu'ils génèrent est devenu plus rapide que la fréquence image cible FlmCible. En effet, cela implique que des lignes devraient être ajoutées artificiellement dans certaines images pour maintenir la synchronisation pour l'affichage, ce qui n'est pas prévu dans cette réalisation de l'invention. Suite à l'étape 1020, on passe à l'étape 1021 similaire à l'étape 1002 pour obtenir la période PlmLocale du noeud courant. Les étapes 1022 à 1025 sont similaires aux étapes 1003 à 1006 permettant l'envoi des PlmLocale aux noeuds et la détermination de la fréquence FlmRef par les noeuds.

Si le noeud courant est un noeud récepteur 103 (rattaché à un projecteur), une variable notée « alerte_ack » prend la valeur 0 à l'étape 1029.

Cette variable est utilisée par le noeud récepteur qui a éventuellement détecté et signalé une alerte « ajout de ligne » pour confirmer la prise en compte de l'alerte (voir Figure 6b). On reboucle ensuite sur l'étape 1020.

Si le noeud courant est un noeud émetteur 102, la période de duplication des images Pduplication (en nombre d'images) est mise à jour lors des étapes 1026 à 1030, de façon similaire aux étapes 1007 à 1013. On reboucle ensuite sur l'étape 1020. La Figure 4a illustre un format possible de paquets de données vidéo transmis d'un noeud émetteur 102 à un noeud récepteur 103. 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 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 (notamment une balise binaire prédéfinie, "start of image flag" en terminologie anglo-saxonne). Cette balise est renseignée 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 optionnel 403 d'indication de la période rythmant les images transmises par le noeud courant (PlmCible ou PlmSource selon le mode de réalisation). Ce champ est renseigné par le module 216 lors de la construction du premier paquet d'une image. A noter que ce champ est optionnel dans le cas où le noeud émetteur réalise l'adaptation des données vidéo ou détermine et indique tout au moins les images à dupliquer. En effet, dans ce cas, le dispositif récepteur peut connaître la valeur de la période image cible permettant la lecture des données vidéo après adaptation, cette connaissance résultant des calculs décrits précédemment à l'aide des fréquences FlmSource et FImAff reçues des autres noeuds.

Dans le cas où le noeud émetteur ne réalise aucune opération (adaptation ou détermination des images à dupliquer) sur les données vidéo, ce champ 403 permet d'indiquer au noeud récepteur la fréquence image source, de telle sorte qu'il puisse procéder à l'adaptation (notamment calculer la période de duplication qui dépend de la période image source). 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 ligne de l'image transmise qui correspond aux premières données 406 dans la charge utile 401. 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 ligne de l'image transmise qui correspond aux dernières données 407 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 ou données vidéo DATA qui vont de la première ligne représentée sur la 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). A noter que ces lignes du flux vidéo comprennent des informations sur des pixels à afficher par un dispositif d'affichage. Dans un mode de réalisation particulier décrit plus après (notamment en lien avec les Figures 4c et 5d), dans lequel l'adaptation des données vidéo DATA pour qu'elles atteignent la fréquence image cible FlmCible est réalisée sur les noeuds récepteurs, le paquet de données peut comprendre un champ supplémentaire 408, noté "duplicate_req_bit", indiquant si une image (correspondant aux données utiles 401) est à dupliquer (champ valant "1", sinon champ valant "0"). Ce champ permet d'indiquer, par un noeud émetteur à un noeud récepteur, quelles sont les images à dupliquer pour réaliser l'adaptation mise en oeuvre dans l'invention. Ce champ est défini par le module 216 lors de l'élaboration du premier paquet correspondant à une image.

Le champ optionnel 403 peut indiquer la période image cible. 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 102, tel que l'un de ceux représentés sur les Figures la à 1c.

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. Ce module de transmission 216 utilise les données vidéo lues dans la mémoire tampon 312. La gestion de cette mémoire est décrite ci-après en référence aux Figures 11a et 11b, montrant notamment que, dans un mode de réalisation de l'invention, c'est ce module 216 qui définit la période de lecture des données vidéo en vue d'une transmission, laquelle période prend la valeur de la période image cible PlmCible selon l'invention.

L'algorithme comprend un état initial 407 dans lequel on attend que les paramètres de correction de la Figure 9 soient calculés (i.e. que la variable « prêt_pour_correction » soit égale à « vrai »). Dans une étape non représentée exécutée après chaque démarrage du système, on attend qu'une image complète soit stockée dans la mémoire tampon 312, afin d'assurer qu'il y a assez de données dans la mémoire tampon 312 pour supporter le débit de lecture correspondant à la période ou fréquence image cible PlmCible/FlmCible. Alors, à l'étape 410, on attend le début d'une image. Le début d'une image peut être détecté par la présence d'un bit « debut_image_bit » (décrit ci- après en référence à la Figure 11a) et valant 1. Lorsque le début d'une nouvelle image est détecté l'étape 410 est suivie d'une étape 411 au cours de laquelle une information sur la durée PlmCible est récupérée comme décrit précédemment. Au cours de l'étape suivante 412, l'entête 400 (Figure 4a) du paquet vidéo incluant (dans le champ optionnel 403) la période image cible PlmCible récupérée 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 lues dans la mémoire 312. Le nombre de lignes vidéo par paquet résulte de la vitesse de lecture de la mémoire tampon 312 par le module 216, c'est-à-dire est fonction de la fréquence image cible FlmCible. 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, l'indication optionnelle de la période PlmCible n'est pas nécessaire car le premier paquet pour la même image indique déjà cette valeur pour l'ensemble de l'image, et le noeud récepteur est capable de la connaître par ses propres moyens.

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 410 d'une nouvelle image, étape déjà décrite. Les Figures 11a et 11b illustrent une gestion de la mémoire tampon 312. Cette gestion est utile dans le mode de réalisation où les noeuds émetteurs 102 réalisent eux-mêmes l'adaptation des données vidéo DATA par duplication d'images pour qu'elles atteignent la fréquence cible FlmCible. Ces algorithmes comprennent, chacun, une série d'étapes, instructions ou portions de code logiciel exécutées lors de l'exécution de l'algorithme. Plus précisément, la Figure 11a illustre un algorithme de gestion d'un pointeur d'écriture dans la mémoire tampon 312 du module de transmission des paquets vidéo 216, au niveau des noeuds émetteurs 102. Les données vidéo DATA reçues de la source 101 à laquelle est relié le noeud émetteur courant sont mémorisées, dans cette mémoire 312, sous forme d'entrées E. Selon une mise en oeuvre, chaque entrée E de la mémoire tampon 312 comporte trois champs. Le premier champ El contient les données vidéo; le second champ E2 comprend la variable « debut_image_bit » contenant un bit valant 1 si les données vidéo de l'entrée sont les premières d'une nouvelle image (0 sinon); et le dernier champ E3 contient la valeur de la période de l'image PlmLocale venant de se terminer (valeur fournie par le module 217 - voir référence 306 sur la Figure 3) si le champ « debut_image_bit » vaut 1. La taille des données fournies à la mémoire tampon à chaque coup d'horloge d'écriture comme décrit ci-après est calculée pour que les premières données d'une image soient alignées avec une entrée E dans la mémoire. Au cours de l'étape 1100, le pointeur d'écriture, noté "ptr_ecriture" est initialisé a O. On attend alors un front de l'horloge d'écriture lors de l'étape 1101.

A l'étape 1102, les données vidéo DATA reçues de la source 101 correspondant au front de l'horloge d'écriture sont écrites en mémoire à l'adresse désignée par le pointeur ptr_ecriture. A ce stade, la variable « debut_image_bit » prend la valeur O. Si les données du front d'horloge d'écriture correspondent au début d'une nouvelle image (test 1103), le champ « debut_image_bit » est mis à 1 à l'étape 1104, et la valeur 306 de la période de l'image venant de se terminer est écrite dans le champ correspondant, à l'étape 1105. A noter que le début d'une nouvelle image peut être détecté à l'aide des signaux de synchronisation: lorsque le signal Hsync indique une nouvelle ligne et que le signal Vsync indique une nouvelle image.

S'il s'agit du début de la première image, une valeur par défaut calculée comme valeur nominale est utilisée. Voir notamment la valeur attribuée au registre 516 lors de l'étape 600 de la Figure 6a. Le pointeur d'écriture est ensuite incrémenté modulo le nombre d'entrées dans la mémoire au cours de l'étape 1106. Cette mémoire étant utilisée de façon circulaire, on vérifie au cours de l'étape 1107 que le pointeur d'écriture n'a pas rattrapé le pointeur de lecture. On peut ensuite revenir à l'étape 1101. La Figure 1l b illustre la gestion de la lecture dans la mémoire tampon 312, notamment lors des lectures de la Figure 4b. Il s'agit notamment d'un algorithme de gestion du pointeur de lecture dans la mémoire tampon 312 du module de transmission des paquets vidéo 216 dans les noeuds émetteurs. Au cours de l'étape 1150, un pointeur de lecture, noté « ptr_Iecture », à vocation à donner l'adresse des prochaines données à lire est initialisé à 0.

De même, un compteur d'image, noté « cpt_image », indiquant le nombre d'images envoyées sur le réseau depuis la dernière duplication d'image est initialisé à 0. Enfin, un pointeur « ptr_im_à_dupliquer » indiquant l'adresse du début de la prochaine image à dupliquer est initialisé à 0.

On vérifie ensuite que des données sont disponibles dans la mémoire tampon 312, lors de l'étape 1161, en vérifiant que le pointeur de lecteur n'a pas déjà rejoint le pointeur d'écriture.

Les données situées à l'adresse indiquée par ptr_lecture sont alors lues (étape 1153) à l'arrivée d'un nouveau front montant de l'horloge de lecture (étape 1152). A noter qu'en cas d'adaptation par le noeud émetteur, la période indiquée dans le champ E3 lu est remplacée par la période image cible PlmCible lors de la formation des paquets (si le champ optionnel 403 doit être renseigné). Si le bit « debut_image_bit » vaut 0 ou si le noeud courant est le noeud de référence (i.e. Pduplication=0, pas de duplication d'image à faire) (test 1154), le pointeur de lecture ptr_lecture est incrémenté (étape 1159) avant de revenir à l'étape 1161 pour traiter les données suivantes. Si le bit « debut_image_bit » vaut 1, le compteur d'images transmises est incrémenté (étape 1155) puis comparé à la valeur « Pduplication + 1» calculée précédemment (+1 car le compteur compte aussi l'image insérée) (étape 1156).

Si les valeurs sont différentes, on met à jour le pointeur ptr_im_à_dupliquer à la valeur du pointeur courant de lecture (étape 1160). Cela permet de mémoriser, pour duplication d'une image, la dernière image en cours de traitement. En effet, on cherche à toujours dupliquer la dernière image transmisse pour ne pas créer d'artefact visuel.

Puis le pointeur de lecture ptr_lecture est incrémenté (étape 1159) avant de revenir à l'étape 1161 pour traiter les données suivantes. Enfin, si « cpt_image » est égal à « Pduplication +1 », on doit dupliquer la dernière image transmise. Pour se faire, on réinitialise le compteur « cpt_image » à 0 (étape 1157 en vue de la détermination d'une image suivante à dupliquer), puis le pointeur « ptr_lecture » prend (étape 1158) la valeur de « ptr_im_à_dupliquer » (telle que mémorisée à la dernière étape 1160), correspondant au début de l'image précédemment transmise. Ainsi, on procède à nouveau à la lecture de l'image située à « ptr_im_à_dupliquer ». Suite à l'étape, on peut revenir à l'étape 1161 pour traiter les 30 données suivantes. Les différents exemples ci-dessus montrent comment un noeud émetteur 102 peut déterminer une fréquence image cible commune à l'ensemble des dispositifs du réseau et à adapter, par duplication d'images, un flux vidéo source pour que ce dernier atteigne cette fréquence image cible. Dans un mode de réalisation particulier évoqué précédemment, cette adaptation est réalisée au niveau d'un noeud récepteur 103 permettant de réduire l'utilisation de la bande passante (car les images dupliquées ne sont pas envoyées en double sur le réseau). La mémoire tampon 312 n'est alors plus nécessaire au niveau des noeuds émetteurs 102. La Figure 4c illustre l'adaptation de l'algorithme de la Figure 4b, à ce mode de réalisation particulier. Les étapes 410 à 416 demeurent sensiblement inchangées. Toutefois, l'étape d'initialisation 409 prévoit l'initialisation d'un compteur « cpt_image » à 0. Cet algorithme comprend également une série d'étapes, instructions ou portions de code logiciel exécutées lors de l'exécution de l'algorithme. Après l'étape 411 d'obtention de la période PlmCible, on teste la valeur du compteur cpt_image lors d'un test 417. Si elle est différente de la variable Pduplication (telle que décrite et calculée précédemment en référence aux Figures 9 et 10), on construit (étape 412) un entête 400 de paquet vidéo incluant, de façon optionnelle, la valeur de la période PlmCible obtenue à l'étape 411. Cet entête contient aussi un champ "duplicate_req_bit" prenant la valeur « 0 » et indiquant au noeud récepteur que l'image en cours n'a pas à être dupliquée à la réception. Le compteur cpt_image est ensuite incrémenté (étape 418), puis on poursuit à l'étape 413, qui se déroule conformément à la description faite précédemment. Si la valeur du compteur cpt_image elle est égale à la variable Pduplication (l'image courante est donc à dupliquer), le cpt_image est réinitialisé a 0 (étape 419) et l'on construit un entête de paquet vidéo incluant la valeur de la période PlmCible obtenue à l'étape 411. Cet entête contient aussi un champ "duplicate_req_bit" prenant la valeur « 1 », et indiquant au noeud récepteur que l'image en cours devra être dupliquée à la réception. On poursuit ensuite par l'étape 413, qui se déroule conformément à la description faite précédemment. Ainsi, grâce au champ "duplicate_req_bit", le noeud récepteur est capable d'adapter les données vidéo, par duplication d'images, pour atteindre la fréquence cible FlmCible déterminée. On décrit maintenant la partie d'affichage 205 pour un noeud récepteur 103. 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 un dispositif ou noeud récepteur 103 afin d'extraire la vidéo envoyée par un 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, type HDMI). 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. En variante, ces données de synchronisation (en particulier FlmCible) peuvent être déterminées localement à partir des FlmSource et FImAff reçues. On évite ainsi d'utiliser le champ 403. 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 extraites dans un moyen de stockage " FIFO vidéo " 501, de type FIFO. 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 cible FlmCible).

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 cible (c'est-à-dire correspondant à FlmCible) 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 (représentatif donc de la fréquence image cible FlmCible) 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 pour l'affichage FImAff) 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, ...). Ce sont ces signaux qui sont utilisés au niveau de l'interface HDMI 212 pour contrôler la synchronisation de l'affichage. 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 (présentant la fréquence image d'affichage FImAff) et le signal de synchronisation verticale des données vidéo reçues, reconstitué progressivement et représenté par le signal " peer_vsync " 507. 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 la commande " remove_line " 510 (pour supprimer une ligne inactive d'image) à destination du module de génération de synchronisation vidéo 503 ou déclenche une alerte "ajout de ligne" transmise sur le réseau à destination des autres noeuds du réseau. L'utilisation et le traitement de cette alerte ont été décrits précédemment en lien avec la Figure 10. Sur réception de l'acquittement de la commande "remove_line" ("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 de la commande " remove_line " 510. La ou les lignes 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 " d'une image. 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. 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 tel que fourni par le module " Vsync_regen " 504, de signaux " Hsync " 512 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.

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, puis 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. 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 " pixel clock " 514. D'autres mises en oeuvre à 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 "video 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 des données vidéo reçues par le dispositif ou noeud récepteur 103 à partir de la fréquence/période image cible. Cette dernière est soit récupérée dans les entêtes des paquets reçus (extraite des entêtes dans le dispositif ou noeud récepteur 103 par le module " RX from network " 500, puis envoyée au module " Vsync regen " 504), soit déterminée localement à partir des fréquence images sources et d'affichage reçues des autres noeuds du réseau. La valeur PlmCible récupérée est exploitée par un module " Vsync monitor " 530 tel que décrit plus loin en référence aux Figures 8a, 8b et 8c. Le module " Vsync monitor " 530 observe la période du signal de synchronisation verticale cible PlmCible et contrôle la durée nominale du signal régénéré " peer_vsync " 507 en changeant la valeur d'un registre " nominal Vsync " 516 selon l'évolution de cette période PlmCible.

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 " 522 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 module de temps réseau (" network time ") 519 génère une information temporelle 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 une information temporelle ("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 Figure 5a (dispositif ou noeud récepteur 103), notamment pour fournir, au module 530 du module 504, l'indication de période image cible lorsqu'elle est renseignée dans les paquets reçus (champ 403). 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 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). 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, la valeur contenue dans le champ 403 (PlmCible courante) est extraite de l'entête 401 du paquet et l'étape suivante 703 est exécutée. Au cours de cette étape, la valeur extraite PlmCible est transmise au module "Vsync monitor" 530 de la Figure 5b et l'étape suivante 704 est 25 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. Au cours de cette étape, un test est pratiqué afin de déterminer si la 30 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 102.

L'unité CPU 201 du dispositif ou noeud émetteur 102 transmet cette information au dispositif ou noeud récepteur 103, 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 (de la même image) 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. Cet algorithme s'applique notamment lorsque l'adaptation des données vidéo DATA, par duplication d'images, est réalisée au niveau des noeuds émetteurs 102. Dans le cas particulier où cette adaptation est réalisée sur les noeuds récepteurs (comme discuté précédemment en lien avec la Figure 4c), ces derniers doivent tenir compte des éventuelles indications de duplication d'images qui ont été insérées par les noeuds émetteurs dans l'entête des paquets (voir le champ 408 comprenant la variable "duplicate_req_bit"), comme décrit maintenant en référence à la Figure 5d. L'algorithme de cette figure comprend une série d'étapes, instructions ou portions de code logiciel exécutées lors de l'exécution de l'algorithme. Sur cette figure, les étapes 700 à 706 sont similaires à celles de la Figure 5c.

Suite aux étapes 700 à 703, une étape 707 est prévue au cours de laquelle la valeur de la variable « duplicate_req_bit » est extraite de l'entête du paquet reçu. Les données vidéo (lignes vidéo) sont ensuite stockées dans le 5 moyen de stockage 501 au cours de l'étape 704. On teste (étape 708) alors si la variable "duplicate_req_bit" vaut « 1 ». Si tel est le cas, l'image en cours de réception doit être dupliquée. Pour ce faire, les données vidéo de cette image sont donc parallèlement stockées dans un second moyen de stockage, de type mémoire temporaire (étape 709). 10 Suite à l'étape 709 ou en cas de variable "duplicate_req_bit" valant « 0 », on passe au test 705 décrit précédemment. L'étape 706 est exécutée si le paquet reçu ne correspond pas à la fin de l'image courante. Après réception du dernier paquet correspondant à l'image en cours (test 705) et si "duplicate_req_bit" vaut « 1 » (test 710), la valeur de la période 15 (ou durée) de l'image venant de se terminer, c'est-à-dire PlmCible, est retransmise au module 530 (étape 711). Les données vidéo correspondant à l'image venant de se terminer sont alors retransmises depuis le second moyen de stockage vers le moyen de stockage 501, au cours de l'étape 712. Cette étape assure la duplication 20 effective de l'image au sein des données vidéo. Si l'image n'est pas à dupliquer ou suite à l'étape 712, on retourne à l'étape 700 pour continuer le traitement des paquets vidéo suivants. Comme illustré ici, l'indication de dupliquer des images renseignée par le noeud émetteur 102 à l'attention du noeud récepteur 103 est intégrée 25 dans l'entête des paquets de transport vidéo. Toutefois, en variante, cette indication peut être transmise en parallèle des paquets de transport vidéo (sous forme de paquets de requête d'insertion d'image), sur le même réseau de communication ou via des liens spécifiques. 30 Egalement, bien que dans le présent exemple, les images à dupliquer sont déterminées par le noeud émetteur 102, cette détermination peut être réalisée en variante par le noeud récepteur 103. Dans ce cas, le noeud émetteur 102 ne participe aux traitements selon l'invention que pour transmettre sa fréquence image source FlmLocale (ou PlmLocale correspondante) telle que décrit plus haut. En outre, le noeud récepteur détermine lui-même la fréquence image cible.

En effet, dans ce cas, chaque noeud du réseau partageant entre eux leurs valeurs de période PlmLocale, ils ont tous, en leur possession, l'ensemble des éléments nécessaires au calcul des paramètres de correction, à savoir la fréquence (ou période) image cible FlmCible et la période de duplication Pduplication correspondant à une source.

Les noeuds récepteurs 103 peuvent donc mettre en oeuvre et gérer, par eux même, la valeur du compteur "cpt_image" tel que décrit précédemment (pour le compte des noeuds émetteurs). Les noeuds émetteurs n'ont alors plus besoin d'émettre de requête de duplication d'image. Par ailleurs, la valeur de la variable « Pduplication » est mise à jour, par le noeud récepteur, lors de la surveillance de la Figure 10 ou lors d'une commutation avec un autre noeud émetteur (car dans ce cas le récepteur reçoit un autre flux avec une autre fréquence image source). 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 initialement chargé avec une valeur nominale par défaut représentative de la fréquence image cible exprimée selon le 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 1080 pixels utilisant une fréquence de 60Hz, la valeur nominale du registre 516 est fixée à 2 475 000, correspondant à 2200 (pixels par ligne ) x 1125 (lignes par image).

Au cours de l'étape suivante 601, une information relative à la période image cible des données vidéo reçues est attendue du module 500 de la Figure 5a. Comme indiqué précédemment, il s'agit de la période PlmCible soit renseignée dans l'entête du premier paquet de données de l'image courante, soit déterminée par le noeud récepteur lui-même. Dès réception de cette information PlmCible, l'étape 601 est suivie de l'étape 602. Au cours de cette étape, le compteur 517 de la Figure 5b démarre, incrémenté au rythme 514 de l'horloge pixel 515.

Le compteur 507 est ainsi synchronisé avec le début d'une image. Au cours de cette étape, une variable notée "local V1" est fixée à la valeur de temps réseau (horloge réseau). L'étape 602 est ensuite suivie d'une étape 604 d'attente de l'occurrence d'une information temporelle locale déclenchée par le signal "peer_vsync" 507. En pratique, lorsque ce signal 507 monte (front montant), la valeur de l'information temporelle locale prend la valeur du temps réseau 519. Le temps réseau 519 est piloté par la partie contrôleur de réseau 207. L'étape 604 est ensuite suivie d'une étape 605 de test afin de déterminer si le signal de synchronisation verticale Vsync correspondant à la fréquence image cible FlmCible est plus lent que le signal "peer_vsync" 507. Il s'agit d'une simple comparaison de période de signal. Afin de réaliser ce test, on compare la période PlmCible obtenue avec [valeur de l'information temporelle locale - local V1].

Si la première valeur (PlmCible) est (strictement) supérieure à la seconde valeur, alors le signal Vsync rythmant les données vidéo reçues est plus lent et l'étape 609 est exécutée pour réduire la vitesse du signal "peer_vsync" 507. 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.

La capacité de correction du module peut par exemple être limitée à un nombre K prédéterminé 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 sur le signal "peer_vsync" 507 n'est appliquée. En revanche si la quantité ou l'importance de la correction (PlmCible - [valeur de l'information temporelle locale - local VI]) est (en valeur absolue) 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) pour modifier l'horloge pixel 514. Ainsi, la vitesse de l'horloge pixel générée par le module 515 sera modifiée pour être plus proche de la fréquence image cible FlmCible. 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". Nonobstant cet ajustement de l'horloge pixel, 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 une commande de décrémentation 520 du registre 516 (Figure 5b). Ensuite, la variable "local V1" est mise à jour pour prendre la valeur de l'information temporelle locale courante. L'étape 606 est ensuite suivie de l'étape 604 déjà décrite en vue d'attendre une nouvelle information temporelle locale déclenchée par le signal "peer_vsync" 507 et une nouvelle période PlmCible obtenue par un nouveau premier paquet d'image reçu ou déterminée par le noeud récepteur pour une nouvelle image.

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 de synchronisation verticale Vsync correspondant à PlmCible courant est plus rapide que le signal "peer_vsync" 507. Pour la mise en oeuvre de ce test, on procède à la comparaison entre la période PlmCible obtenue et [valeur de l'information temporelle locale - local V1]. Si la première valeur (PlmCible) est (strictement) inférieure à la seconde valeur, alors le signal Vsync est plus rapide et l'étape 607 est suivie de l'étape de test 610. Dans le cas contraire, la variable local V1 est mise à jour pour prendre la valeur de l'information temporelle locale courante. 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 (PlmCible - [valeur de l'information temporelle locale - local VI]) est (en valeur absolue) 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 ne soit 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 une commande d'incrémentation 521 du registre nominal 516 de la Figure 5b. Ensuite, la variable local V1 est mise à jour pour prendre la valeur de l'information temporelle locale courante. L'étape 608 est alors suivie de l'étape 604 déjà décrite en vue d'attendre une nouvelle période PlmCible obtenue par un nouveau premier paquet d'image reçu (ou déterminée par le noeud récepteur). Grâce à ces mécanismes mis en oeuvre dans le module 530, le signal "peer_vsync" 507 est synchronisé sur la fréquence/période image cible définie par les données vidéo. La Figure 6b décrit un algorithme mis en oeuvre par le module de gestion de dérive 506 de la Figure 5a pour suivre une dérive entre ce signal "peer_vsync" 507 et le signal de synchronisation pour l'affichage (c'est-à-dire correspondant à FImAff) propre au générateur de synchronisation vidéo 503. Ce module est mis en oeuvre par le dispositif ou noeud récepteur 103 pour commander 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 d'affichage FImAff 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 cible, comme exposé précédemment. 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 1080 pixels, 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 image d'affichage PImAff du signal " Vsync " 508 qui est en retard de phase par rapport au signal " peer_vsync " 507 correspondant à la période image cible PlmCible. 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 " 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 déclenche l'envoi d'un message d'alerte « ajout de ligne » à tous les autres noeuds du réseau. En effet, on ne peut se trouver dans ce cas que si le signal "Vsync" 508 généré par le noeud récepteur courant 103 est devenu plus rapide que le signal de synchronisation cible rythmant les données vidéo reçues. Cela signifie que le noeud récepteur a une fréquence image d'affichage plus élevée que la fréquence image de référence (par définition la plus élevée des FlmLocale). Le message d'alerte permet ainsi de mettre à jour la fréquence image cible dans chacun des noeuds du réseau. Le module passe alors à l'étape 628 où la variable « alert_ack » prend la valeur 0, puis on attend à l'étape 629 que cette variable soit remise à 1 par le CPU, indiquant la prise en compte de l'alerte et la mise a jour des paramètres de correction sur le réseau. On reboucle ensuite à l'étape 620. Les Figures 8a, 8b et 8c illustrent le fonctionnement du module "video synchro generator" 503 de la Figure 5a qui met en oeuvre trois algorithmes en parallèle. Ces algorithmes comprennent, chacun, une série d'étapes, instructions ou portions de code logiciel exécutées lors de l'exécution de l'algorithme. Un premier algorithme illustré sur la Figure 8a a pour but de générer le signal "Hsync " 512 et un signal interne de masquage horizontal (" horizontal_blanking ") 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 à un état haut 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 1080p à 60 Hz. 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 ". Lors de cette étape le signal "Hsync " 512 est maintenu à un é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 1080p à 60 Hz. 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. Lors de cette étape le signal " Hsync " 512 est maintenu à un é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 1080p à 60 Hz. 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 ". Lors de cette étape le signal " Hsync " 512 est maintenu à un é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 1080p à 60 Hz. 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 " durant laquelle les pixels sont "inactifs" (pas d'affichage de pixels). L'étape 643 correspond à la période 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, c'est-à-dire à la fréquence image d'affichage FImAff normalement égale à FlmCible grâce aux moyens décrits précédemment. Un deuxième algorithme illustré à la Figure 8b a pour but de générer le signal " Vsync " 508 de la Figure 5a et un signal interne de masquage vertical (" vertical_blanking ") 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 de la commande " 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 est maintenu à un état bas et le signal " vertical_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 651.

Lors de l'étape 651, le module 503 entre dans une période ou phase de synchronisation verticale. Lors de cette étape, le signal " Vsync " 508 est maintenu à un é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 1080p à 60 Hz. 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 " remove_line " 510 du gestionnaire de dérive 506 (Figure 5a). S'il a reçu une telle commande, 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 " à venir. Cette nouvelle durée est fonction de la commande reçue et est adaptée à la dérive entre les signaux "Vsync" et "peer_vsync". La durée de la période " Back porch lines " est fonction du format d'image contenu dans la mémoire RAM 502 et est, par exemple, de 36 lignes pour un format 1080p à 60 Hz. A réception d'une commande " remove_line " 510, la durée de la période " Back porch lines " est décrémentée d'une unité pour passer à 35 lignes par exemple. Cette nouvelle valeur n'est pas stockée 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 30 " 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 ". Lors de cette étape, le signal "Vsync " 508 est maintenu à un é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 1080p à 60 Hz. 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 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. Lors de cette étape, le signal " Vsync " 508 est maintenu à un é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 1080p à 60 Hz. 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 ". Lors de cette étape, le signal " Vsync " 508 est maintenu à un é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 1080p à 60 Hz. 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 " durant laquelle les lignes sont inactives (pas d'affichage de lignes). L'étape 656 correspond à la période " Active lines " 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 de la Figure 5a, à 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.

Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. Par exemple, bien que la synchronisation selon l'invention soit basée sur le signal de synchronisation verticale Vsync, elle peut être menée sur un autre signal de synchronisation ou même sans se baser sur les signaux de synchronisation fournis par les sources. Par ailleurs, les mécanismes ci-dessus envisagent la génération d'une alerte "ajout de ligne" si le signal Vsync 508 du dispositif ou noeud récepteur 103 est en retard (plus lent) que le signal des données reçues représenté par "peer_vsync" 507. Cette alerte tient au fait que l'on souhaite que la fréquence image cible FlmCible soit la plus élevée des fréquences images FlmLocale propres aux noeuds 102, 103 du réseau. Toutefois, dans le cas où l'on envisage que la fréquence image cible FlmCible est la plus élevée des fréquences images sources uniquement FlmSource, la fréquence image d'affichage d'un noeud récepteur 103 (correspondant à Vsync 508) peut être plus élevée que la fréquence cible FlmCible (correspondant à "peer_vsync" 507). Dans ce cas, le module générateur de synchronisation vidéo 503 peut mettre en oeuvre des commandes d'ajout de ligne (auquel cas, il n'y a pas d'alerte "ajout de ligne" émise) afin de compenser une dérive positive du signal de synchronisation de l'affichage. Les mécanismes d'ajout sont sensiblement symétriques aux mécanismes de retrait de ligne ("remove line").

Claims (29)

1. REVENDICATIONS1. Procédé de synchronisation entre dispositifs (102, 103, DE, DR) d'un système de distribution (100) de flux vidéo d'images comprenant, reliés à un réseau de communication, au moins trois dispositifs émetteurs (102, DE) ou récepteurs (103, DR), dont un dispositif émetteur et un dispositif récepteur, un dispositif émetteur (DE) étant configuré pour recevoir, d'une source (101), un flux vidéo source (DATA) présentant une fréquence d'images, dite fréquence image source (FlmSource, 306), un dispositif récepteur (DR) étant configuré pour contrôler l'affichage, à une fréquence d'affichage, dite fréquence image d'affichage (FImAff), d'un flux vidéo sur un dispositif d'affichage (104) auquel il est relié, procédé caractérisé en ce qu'il comporte les étapes consistant à : obtenir (1005, 1024) une fréquence d'images, dite fréquence image cible (FlmCible), commune pour les dispositifs, adapter (1158, 712), par chaque dispositif de l'ensemble des dispositifs émetteurs (DE) ou de l'ensemble des dispositifs récepteurs (DR), un flux vidéo source reçu d'une source, respectivement, directement ou au travers d'un dispositif émetteur, de la fréquence image source (FlmSource) à la fréquence image cible (FlmCible), ajuster, au niveau de chaque dispositif récepteur (DR), la fréquence image d'affichage (FImAff) à la fréquence image cible (FlmCible) de sorte à contrôler un affichage à ladite fréquence image cible.
2. 2. Procédé de synchronisation selon la revendication 1, dans lequel l'étape d'obtention de la fréquence image cible (FlmCible) comprend une étape consistant à déterminer une fréquence d'images de référence (FlmRef) parmi les seules fréquences images sources (FlmSource).
3. 3. Procédé de synchronisation selon la revendication 1, dans lequel l'étape d'obtention de la fréquence image cible (FlmCible) comprend une étape consistant à déterminer une fréquence d'images de référence (FlmRef) parmi les fréquences images sources et les fréquences images d'affichage (FlmSource, FImAff).
4. 4. Procédé de synchronisation selon la revendication 2 ou 3, dans lequel la fréquence d'image de référence (FlmRef) est la fréquence d'image la plus élevée parmi les fréquences images sources et d'affichage (FlmSource, FImAff) prises en compte.
5. 5. Procédé de synchronisation selon la revendication 4, dans lequel ladite fréquence image cible (FlmCible) est égale à la fréquence d'image de référence (FlmRef) si cette dernière est une fréquence image source, et est strictement supérieure à la fréquence d'image de référence (FlmRef) si cette dernière est une fréquence image d'affichage.
6. 6. Procédé de synchronisation selon l'une des revendications précédentes, dans lequel chaque dispositif (DE, DR) détermine (905, 1002, 1021) sa propre fréquence image source ou d'affichage (FlmSource, FImAff) et transmet (1003, 1033), aux autres dispositifs, la fréquence image déterminée accompagnée d'une information renseignant le type de dispositif, émetteur ou récepteur, dont provient la fréquence image transmise.
7. 7. Procédé selon la revendication précédente, dans lequel la détermination d'une fréquence image propre à un dispositif est effectuée en déterminant (905) une période d'un signal de synchronisation dudit dispositif par rapport à une horloge réseau (519) commune du réseau de communication.
8. 8. Procédé selon la revendication précédente, caractérisé en ce que l'étape d'obtention de la fréquence image cible (FlmCible) est effectuée sur chaque dispositif ayant reçu les valeurs de période de signal de synchronisation en provenance des autres dispositifs du réseau, par détermination d'une fréquence d'images de référence (FlmRef) en fonction desdites valeurs de période de signal de synchronisation reçues.
9. 9. Procédé de synchronisation selon l'une des revendications 6 à 8, dans lequel: la détermination (905, 1022), par les dispositifs (DE, DR) de leurs propres fréquences images source ou d'affichage (FlmSource, FImAff), la transmission (1022) de ces fréquences aux autres dispositifs, et l'obtention (1024), par chaque dispositif ayant reçu les fréquences des autres dispositifs, de la fréquence image cible (FlmCible) par détermination d'une fréquence d'image de référence (FlmRef) en fonction des fréquences images sources ou d'affichage reçues, sont effectuées périodiquement par lesdits dispositifs.
10. 10. Procédé de synchronisation selon l'une des revendications précédentes, dans lequel l'adaptation du flux vidéo source comprend la duplication (1158, 712) d'au moins une image afin que le flux vidéo atteigne ladite fréquence image cible.
11. 11. Procédé de synchronisation selon la revendication précédente, dans lequel la duplication comprend une étape de calcul d'une dérive entre la fréquence image source et la fréquence image cible, et dans lequel le nombre d'images à dupliquer est fonction de la dérive calculée pour atteindre la fréquence image cible.
12. 12. Procédé de synchronisation selon l'une des revendications 1 à 11, dans lequel l'adaptation du flux vidéo source est effectuée par chaque dispositif récepteur (DR) recevant un flux vidéo source qui présente une fréquence image source (FlmSource) inférieure à la fréquence image cible (FlmCible).
13. 13. Procédé de synchronisation selon les revendications 10 et 12 prises en combinaison, dans lequel ledit dispositif récepteur (DR) détermine, à partir de la fréquence image cible (FlmCible) et de la fréquence d'image (FlmSource) dudit flux vidéo source reçu, les images à dupliquer dans ledit flux vidéo.
14. 14. Procédé de synchronisation selon les revendications 10 et 12 prises en combinaison, dans lequel ledit dispositif émetteur (DE) détermine (420) les images à dupliquer dans ledit flux vidéo et les indique à un dispositif récepteur (DR) dudit flux vidéo source.
15. 15. Procédé de synchronisation selon la revendication précédente, dans lequel lesdites images à dupliquer sont signalées dans l'entête (400) de paquets transportant le flux vidéo.
16. 16. Procédé de synchronisation selon l'une des revendications 1 à 11, dans lequel l'adaptation du flux vidéo source est effectuée (1158) par chaque dispositif émetteur (DE) recevant un flux vidéo source présentant une fréquence image source (FlmSource) inférieure à la fréquence image cible (FlmCible).
17. 17. Procédé de synchronisation selon la revendication précédente, dans lequel l'adaptation du flux vidéo source par un dispositif émetteur (DE) est effectuée par lecture, à ladite fréquence image cible, d'une mémoire tampon (312) stockant ledit flux vidéo d'une source.
18. 18. Procédé de synchronisation selon l'une des revendications précédentes, dans lequel l'ajustement de la fréquence image d'affichage (FImAff) d'un dispositif récepteur (DR) comporte une étape de synchronisation par asservissement du dispositif récepteur pour compenser une dérive entre la fréquence image d'affichage et la fréquence image cible.
19. 19. Procédé de synchronisation selon la revendication 18, comprenant: la détection (621), par le dispositif récepteur (DR), d'une dérive positive représentative d'une fréquence image d'affichage plus élevée que la fréquence image cible; l'émission (627), par le dispositif récepteur et à destination des autres dispositifs (DE, DR), d'un signal d'alerte en réponse à la détection d'une dérive positive; et une mise à jour (1011, 1024) de la fréquence image cible par les dispositifs en réponse au signal d'alerte.
20. 20. Procédé de synchronisation selon la revendication précédente, dans lequel la mise à jour (1011) de la fréquence image cible comprend: la détermination (1021), par les dispositifs de leurs propres fréquences images source ou d'affichage (FlmLocale), la transmission (1022) de ces fréquences aux autres dispositifs, et l'obtention (1024), par chaque dispositif ayant reçu les fréquences des autres dispositifs, de la fréquence image cible (FlmCible) par détermination d'une fréquence d'image de référence (FlmRef) en fonction des fréquences images sources (FlmSource) ou d'affichage (FImAff) reçues.
21. 21. Procédé de synchronisation selon la revendication 19 ou 20, dans lequel l'adaptation du flux vidéo source comprend la duplication d'images à une fréquence de duplication (Pduplication) afin que le flux vidéo atteigne ladite fréquence image cible, et la fréquence de duplication est mise à jour à détection du signal d'alerte.
22. 22. Procédé selon la revendication 18, dans lequel l'ajustement de la fréquence image d'affichage d'un dispositif récepteur recevant un flux vidéo comporte la suppression ou l'ajout d'au moins une ligne d'image dans une partie inactive d'une image du flux vidéo, de sorte à modifier artificiellement la fréquence image d'affichage au dispositif récepteur.
23. 23. Procédé selon l'une des revendications 18 à 22, comprenant une étape de réajustement d'une horloge pixel (514) du dispositif récepteur lorsque une dérive négative représentative d'une fréquence image cible (peer_vsync), régénérée par le dispositif récepteur et plus faible que la fréquence image cible (FlmCible), est détectée comme étant supérieure, en valeur absolue, à une valeur seuil.
24. 24. Système de distribution (100) de flux vidéo d'images comprenant, reliés à un réseau de communication, au moins trois dispositifs émetteurs (102; DE) ou récepteurs (103, DR), dont un dispositif émetteur et un dispositif récepteur, parmi un dispositif émetteur (DE) étant configuré pour recevoir, d'une source (101), un flux vidéo source (DATA) présentant une fréquence d'images ,dite 20 fréquence image source (FlmSource), un dispositif récepteur (DR) étant configuré pour contrôler l'affichage, à une fréquence d'affichage, dite fréquence image d'affichage (FImAff), d'un flux vidéo sur un dispositif d'affichage (104) auquel il est relié, système caractérisé en ce qu'il comporte un moyen d'obtention d'une 25 fréquence d'images, dite fréquence image cible (FlmCible), commune pour les dispositifs, et dans lequel chaque dispositif de l'ensemble des dispositifs émetteurs ou de l'ensemble des dispositifs récepteurs comprend des moyens d'adaptation d'un 30 flux vidéo source reçu d'une source, respectivement, directement ou au travers d'un dispositif émetteur, de la fréquence image source à la fréquence image cible,et chaque dispositif récepteur comprend un moyen d'ajustement de sa propre fréquence image d'affichage à la fréquence image cible de sorte à contrôler un affichage à ladite fréquence image cible.
25. 25. Dispositif émetteur (DE) ou récepteur (DR) d'un flux vidéo au sein 5 d'un réseau de communication comprenant au moins trois dispositifs émetteurs ou récepteurs, dont un dispositif émetteur et un dispositif récepteur, caractérisé en ce qu'il comporte: des moyens de réception de fréquences images propres (FlmLocale) en provenance des autres dispositifs du réseau; 10 un moyen d'obtention d'une fréquence d'images commune, dite fréquence image cible (FlmCible), par détermination d'une fréquence d'images de référence (FlmRef) en fonction des fréquences images reçues et en fonction d'une fréquence image locale audit dispositif définissant une fréquence de transmission d'un flux vidéo à un dispositif aval (104), 15 des moyens configurés pour ajuster la fréquence image locale à la fréquence image cible de sorte à transmettre, à ladite fréquence image cible et à destination du dispositif aval, un flux vidéo reçu.
26. 26. Dispositif (DE, DR) selon la revendication 25, comprenant en outre: 20 un moyen de détermination d'une période d'un signal de synchronisation du dispositif par rapport à une horloge réseau (519) commune de sorte à obtenir ladite fréquence image locale au dispositif, des moyens de transmission à destination des autres dispositifs du réseau, de la valeur de la période de signal de synchronisation déterminée et d'une 25 information renseignant le type de dispositif, émetteur ou récepteur, dont provient la valeur transmise.
27. 27. Dispositif (DE, DR) selon la revendication 25 ou 26, comprenant une mémoire tampon (312, 501) pour stocker des données dudit flux vidéo, et configuré pour écrire ou lire ladite mémoire tampon à ladite fréquence image 30 cible.
28. 28. Moyen de stockage d'informations, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé conforme à l'une quelconque des revendications 1 à 23, lorsque le programme est chargé et exécuté par le système informatique.
29. 29. Produit programme d'ordinateur chargeable dans un système informatique, ledit programme comprenant des instructions permettant la mise en oeuvre du procédé de synchronisation selon l'une des revendications 1 à 23, lorsque ce programme est chargé et exécuté par un système informatique.