FR2934918A1 - Procede d'affichage d'une pluralite d'images sur un dispositif d'affichage video et dispositif associe. - Google Patents

Abstract

L'invention concerne un procédé d'affichage d'une pluralité d'images sur un dispositif d'affichage vidéo recevant via un réseau de communication des données représentant des images destinées à être affichées sur un écran vidéo pendant une durée d'affichage prédéfinie, caractérisé en ce que le procédé comprend successivement une étape de prévision d'un retard de disponibilité de données définissant une image dite image en retard, une étape de commande de l'affichage d'une première pluralité d'images effectuée en fonction de ladite prévision, au moins une image de la première pluralité étant affichée pendant une durée d'affichage supérieure à la durée d'affichage prédéfinie, une étape de commande de l'affichage d'une deuxième pluralité d'images comprenant l'image en retard, au moins une image de la deuxième pluralité étant affichée pendant une durée d'affichage inférieure à la durée prédéfinie.

Description

La présente invention concerne un procédé d'affichage vidéo utilisable par exemple dans un contexte de transmission multimédia numérique en direct (en temps réel - live streaming ) comme la visioconférence ou la vidéo surveillance, utilisant un réseau de communication tel que l'Internet ou un réseau local, par exemple de type IP ( Internet Protocol ).

L'invention porte également sur un dispositif d'affichage d'images qui peut être utilisé par exemple pour des applications de vidéoconférence ou de vidéosurveillance. Dans un contexte de transmission multimédia en direct, des données multimédia sont capturées par un serveur à l'aide d'une caméra et d'un microphone. Par exemple, la caméra capture une image toutes les 20 ms, dans le cas d'une vidéo à 50 images par seconde, et le microphone enregistre du son en continu. Les données sont ensuite encodées dans un format de compression numérique avant d'être transmises sur un réseau de communication de données vers un ou plusieurs récepteurs, appelés aussi clients, ayant une fonction d'affichage vidéo et de reproduction audio. Ces clients reçoivent et consomment ces données au fur et à mesure de leur réception. Notamment, le client reproduit le contenu codé par les données vidéo et les données audio au fur et à mesure qu'il les reçoit.

Les données multimédias (images, portions d'images - slices - ou portions de sons - samples -) ont dans un tel contexte de diffusion en temps réel une durée de vie utile limitée. Elles doivent impérativement être reçues et traitées par le client avant l'instant où, selon l'application et les normes d'utilisation qui lui sont applicables, on considère qu'il est indispensable que la donnée soit diffusée par le client pour les utilisateurs.

Au-delà de cette échéance, la donnée devient inutile et est en général ignorée par le client. Le rendu des informations est alors dégradé, puisqu'une partie des données n'a pas été diffusée. On ajoute que les technologies réseau actuelles sont telles qu'il se produit assez fréquemment des pertes de données entre le serveur et le client. Tant que ces pertes sont limitées, elles peuvent être d'une certaine manière et sous certaines conditions corrigées ou masquées. Quand ces pertes augmentent, la qualité du rendu, notamment le rendu vidéo s'affaiblit à des niveaux qui peuvent être considérés comme insatisfaisants dans certaines applications. Pour assurer une bonne qualité du rendu audio-vidéo, on considère donc à l'heure actuelle qu'un système de diffusion en temps réel doit simultanément remplir les quatre conditions suivantes. Tout d'abord la durée entre la capture de la donnée audio ou vidéo et son rendu doit être inférieure à 150 ms. Deuxièmement le rendu des données audio et le rendu des donnés vidéo doit être synchrone. On considère qu'un niveau de synchronisation acceptable est atteint si les données audio sont diffusées avec moins de 40 ms d'avance ou de retard sur les données vidéo.

Troisièmement, la durée entre l'affichage de deux images successives doit être régulière. On pourra à ce sujet se référer à l'article IMPACT OF JITTER AND JERKINESS ON PERCEIVED VIDEO QUALITY de Quan Huynh-Thu and Mohammed Ghanbari (Proceedings of the Second International Workshop on Video Processing and Quality Metrics for Consumer Electronics VPQM-06). Enfin, quatrièmement, le nombre de pertes de paquets sur le réseau doit être limité, et l'impact des pertes de paquets doit être contrôlé. Dans ce contexte, la demanderesse s'est intéressée aux situations où une image parvient au client avec un retard significatif par rapport au rythme d'affichage. De telles situations se produisent du fait d'un retard pris lors du codage de l'image et de son émission sur le réseau, ou lors d'un retard pris au cours de la transmission des informations sur le réseau.

Classiquement, dans un tel cas, l'image précédant l'image en retard est affichée pendant une durée supérieure à la durée moyenne, puis, quand l'image en retard est enfin disponible, celle-ci est affichée. Enfin, l'affichage des images suivant l'image en retard est précipité de manière à combler le retard pris par l'affichage. Le spectateur a donc une impression de gel de l'image puis d'accélération brusque. La qualité de la visualisation est donc fortement dégradée. L'audio et la vidéo peuvent être fortement désynchronisés, et la vidéo n'est plus rendue en direct. On connaît par le document US 6262776 "System and method for maintaining synchronization between audio and video" de Microsoft un système qui ajuste l'instant d'affichage des images pour essayer de maintenir une bonne synchronisation entre l'audio et la vidéo. Ce système peut en particulier décider de sauter une image et de passer directement à l'image suivante. Il prend également en compte les changements de vitesse de calcul du client. On connaît également par l'article "Adaptive delay and synchronization control for Wi-fi based AV conferencing", Proceedings of the First International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks (QSHINE'04) - Haining Liu and Magda El Zarki, un récepteur qui reçoit un flux audio/vidéo transmis sur un réseau sans fil Wifi et l'affiche de manière synchronisée. Le réseau considéré dans ce document introduit des délais variables en fonction des conditions, par exemple à cause d'interférence radio ou d'autres communications.

Le système adapte le rythme d'affichage en augmentant le délai d'affichage pour permettre de mieux recevoir les paquets. On comprend que cela est fait au détriment de l'interactivité. On connaît enfin par le document US 7170545 "Method and apparatus for inserting variable audio delay to minimize latency in video conferencing" de Polycom Inc., un récepteur qui reçoit un flux audio et vidéo et l'affiche après avoir analysé le contenu du flux pour déterminer s'il s'agit d'une situation de monologue ou de dialogue.

Dans le premier cas, une bonne synchronisation entre l'audio et la vidéo est souhaitée alors que dans le deuxième cas, un délai faible dans le rendu est souhaité de manière à garantir l'interactivité de l'application. Des vitesses variables sont alors utilisées pour le rendu audio.

On voit que les solutions connues ne sont pas complètement satisfaisantes, notamment pour des applications où les exigences des utilisateurs en termes de qualité du rendu et de transmission en temps réel sont importantes. L'invention de la demanderesse cherche donc à limiter l'impact visuel des durées de traitement variables dans ces contextes. Dans ce but, il est proposé un procédé d'affichage d'une pluralité d'images sur un dispositif d'affichage vidéo recevant via un réseau de communication des données représentant des images destinées à être affichées sur un écran vidéo pendant une durée d'affichage prédéfinie, le procédé comprenant successivement une étape de prévision d'un retard de disponibilité de données, par exemple des données codées ou bien des données ayant subi un décodage, et définissant une image dite image en retard, une étape de commande de l'affichage d'une première pluralité d'images effectuée en fonction de ladite prévision, au moins une image de la première pluralité étant affichée pendant une durée d'affichage supérieure à la durée d'affichage prédéfinie, et une étape de commande de l'affichage d'une deuxième pluralité d'images comprenant l'image en retard, au moins une image de la deuxième pluralité étant affichée pendant une durée d'affichage inférieure à la durée prédéfinie.

Ce procédé permet d'améliorer l'impact visuel du retard de l'image en retard, grâce à la prévision du retard et à la dépendance de la commande de l'affichage par rapport à cette prévision. On prévoie plus précisément que les données peuvent être reçues codées via le réseau de communication, et que la prévision d'un retard de disponibilité de données définissant une image comprend au moins une prévision d'un retard de réception de données codées ou un retard de décodage de données codées.

En d'autres termes, selon une caractéristique, les données reçues via le réseau de communication comprennent des données codées, et la prévision d'un retard de données décodées peut inclure uniquement une prévision d'un retard de réception de données codées ou à la fois une prévision d'un retard de réception de données codées et une prévision d'un retard dans le décodage de données codées. On précise donc qu'alternativement la prévision d'un retard de données décodées peut inclure une prévision d'un retard dans le décodage de données codées reçues à temps.

Selon un premier aspect avantageux, l'affichage des images est accompagné d'une diffusion d'une bande sonore destinée à être diffusée par un haut-parleur associé au dispositif d'affichage vidéo de manière synchronisée avec l'affichage des images, et l'étape de commande de l'affichage d'une première pluralité d'images est effectuée en fonction d'un critère d'acceptabilité de désynchronisation de l'affichage des images et de la diffusion de la bande sonore pendant une durée donnée. Dans un premier cas, le critère d'acceptabilité est un critère à deux états, qui sont l'état critère vérifié et l'état critère non vérifié . Dans ce cas, l'affichage d'une première pluralité d'images est commandé si le critère d'acceptabilité est vérifié. Dans un deuxième cas, le critère d'acceptabilité peut prendre une pluralité d'états, indiquant un niveau d'acceptabilité dans une échelle discrète ou continue à plusieurs niveaux. Dans ce cas, au moins un paramètre de l'affichage d'une première pluralité d'images peut dépendre de l'état du critère d'acceptabilité. Ce paramètre peut être le nombre d'images de la pluralité ou la durée d'affichage d'au moins une image de la pluralité. Selon un mode de réalisation général, les données comprennent une image indépendante définie de manière autonome et une image complémentaire définie en fonction d'une image antérieure et la prévision d'un retard de disponibilité de données inclut une prévision d'un retard d'au moins une donnée définissant une image indépendante.

Plus précisément, il est prévu qu'une image indépendante puisse inclure au moins un bloc Intra (Intra codé), dans le cadre d'un mode de compression des données vidéo. Par ailleurs, le procédé peut comprendre une étape d'émission via le réseau à l'attention d'un serveur d'une requête d'envoi d'une image indépendante. L'étape de prévision peut d'ailleurs comprendre une étape d'émission via le réseau à l'attention d'un serveur d'une telle requête effectuée en fonction d'une information de pertinence d'émission de requête (ou simplement information de pertinence de requête) déterminée au moins sur la base d'une donnée reçue via le réseau de communication. Selon une caractéristique avantageuse, la prévision comprend une étape de détermination d'une information de pertinence de ladite émission d'une requête. On précise que la détermination d'une information de pertinence de l'émission peut inclure au moins un calcul ou une réception d'une telle information. Il est notamment prévu que l'information de pertinence puisse indiquer au moins qu'un taux d'erreur supérieur à une valeur prédéfinie a été mesuré pour une image reçue par le dispositif d'affichage vidéo via le réseau de communication. Ledit taux d'erreur peut comprendre au moins un taux d'erreur instantané ou un taux d'erreur cumulé. Dans un mode de réalisation particulier, l'affichage des images est accompagné d'une diffusion d'une bande sonore destinée à être diffusée par un haut-parleur associé au dispositif d'affichage vidéo de manière synchronisée avec l'affichage des images et la prévision inclut une évaluation d'un critère d'acceptabilité de désynchronisation de l'affichage des images et de la diffusion de la bande sonore pendant une durée donnée, l'étape de commande de l'affichage d'une première pluralité d'images étant effectuée en fonction dudit critère d'acceptabilité de désynchronisation. Dans ce contexte, on prévoit que l'information de pertinence indique au moins que le critère d'acceptabilité de désynchronisation de l'affichage des images et de la diffusion de la bande sonore pendant une durée donnée est vérifié. On précise que la vérification du critère peut être déterminée en fonction de l'application faite du dispositif d'affichage vidéo sur la base du 5 contenu des images et de la bande sonore. Avantageusement, la première pluralité d'images comporte un nombre d'images calculé au moins en fonction du critère d'acceptabilité de désynchronisation. Ensuite, selon un mode de réalisation intéressant, on a prévu que la 10 prévision comprend une étape de réception via le réseau de communication d'une information annonçant une émission prochaine d'une image indépendante. Notamment, un deuxième dispositif d'affichage vidéo reçoit via le réseau de communication les données codées et la prévision comprend une étape de réception d'une information indiquant que le deuxième dispositif 15 d'affichage vidéo a demandé un envoi d'une image indépendante. Il est ainsi possible que l'information annonçant une émission prochaine soit émise en réponse à une requête d'envoi d'une image indépendante par le deuxième dispositif d'affichage vidéo. On notera que ce dernier aspect est combiné avec l'utilisation du 20 critère d'acceptabilité de désynchronisation, et qu'alternativement, il peut être mis en oeuvre indépendamment. Selon également un mode de réalisation, une pluralité d'images indépendantes sont envoyées avec une période donnée, et ladite prévision comprend une étape de détermination d'un achèvement d'une occurrence de la 25 période. On notera que ce dernier aspect est combiné avec l'utilisation du critère d'acceptabilité de désynchronisation, et qu'alternativement, il peut être mis en oeuvre indépendamment. Selon également une caractéristique générale et optionnelle, la 30 première pluralité d'images comporte un nombre d'images calculé au moins en fonction d'un temps moyen entre l'envoi d'une image par un serveur et sa réception par le dispositif d'affichage vidéo.

Il est également possible qu'au cours de l'étape d'affichage de la première pluralité d'images, au moins deux images de la première pluralité sont affichées pendant une durée d'affichage supérieure à la durée d'affichage prédéfinie.

Selon une caractéristique, la première pluralité d'images comportant au moins une première, une deuxième et une troisième images, la première image étant affichée avant la deuxième image et la deuxième image étant affichée avant la troisième image, les première, deuxième et troisième image étant affichées pendant des durées d'affichage dites respectivement première, deuxième et troisième durées d'affichage, la première durée d'affichage est inférieure à la deuxième durée d'affichage, et la troisième durée d'affichage est également inférieure à la deuxième durée d'affichage. On a donc un phénomène de lissage du retard pris, sur au moins trois images, voire sur toutes les images de la pluralité.

Par exemple, au cours de l'étape d'affichage de la première pluralité d'images, les première, deuxième et troisième durées d'affichage sont proportionnelles à une fonction sinusoïdale appliquée à un numéro d'arrivée de l'image et de période la durée de l'étape. De manière parallèle, mais sans que les deux aspects soient nécessairement mis en oeuvre dans l'invention, il est possible qu'au cours de l'étape d'affichage de la deuxième pluralité d'images, au moins deux images de la deuxième pluralité sont affichées pendant une durée d'affichage inférieure à la durée d'affichage prédéfinie. Selon une caractéristique, la deuxième pluralité d'images comportant au moins une première, une deuxième et une troisième images, la première image étant affichée avant la deuxième image et la deuxième image étant affichée avant la troisième image, les première, deuxième et troisième image étant affichées pendant des durées d'affichage dites respectivement première, deuxième et troisième durées d'affichage, la première durée d'affichage est supérieure à la deuxième durée d'affichage, et la troisième durée d'affichage est également supérieure à la deuxième durée d'affichage.

On a donc un phénomène de lissage de l'accélération imposée aux images, sur au moins trois images, voire sur toutes les images de la pluralité. Par exemple, au cours de l'étape d'affichage de la deuxième pluralité d'images, les première, deuxième et troisième durées d'affichage sont proportionnelles à une fonction sinusoïdale appliquée à un numéro d'arrivée de l'image et de période la durée de l'étape. Enfin, il est avantageux qu'un retard accumulé au cours de l'étape d'affichage de la première pluralité d'images soit compensé par une avance prise au cours de l'étape d'affichage de la deuxième pluralité d'images. Cela peut notamment être obtenu en utilisant des fonctions sinusoïdales symétriques pour la première pluralité d'images et pour la deuxième pluralité d'images. Eventuellement, selon une caractéristique avantageuse, l'étape de prévision d'un retard comprend une étape d'estimation d'une durée estimée du retard, et ladite durée d'affichage supérieure à la durée d'affichage prédéfinie dépend de ladite durée estimée du retard. L'invention propose également un. dispositif d'affichage vidéo comprenant des moyens de réception via un réseau de communication de données représentant des images destinées à être affichées sur un écran vidéo pendant une durée d'affichage prédéfinie, le dispositif comprenant des moyens de prévision d'un retard de données décodées définissant une image dite image en retard, des moyens de commande de l'affichage d'une première pluralité d'images, ladite commande étant effectuée en fonction de ladite prévision, au moins une image de la première pluralité étant affichée pendant une durée d'affichage supérieure à la durée d'affichage prédéfinie, et des moyens de commande de l'affichage d'une deuxième pluralité d'images comprenant l'image en retard, au moins une image de la deuxième pluralité étant affichée pendant une durée d'affichage inférieure à la durée prédéfinie. L'invention propose aussi un programme d'ordinateur comprenant une suite d'instructions aptes, lorsqu'elles sont exécutées par un microprocesseur, à mettre en oeuvre un procédé tel que présenté plus haut.

L'invention va maintenant être décrite en détails, en référence aux figures annexées, relatives à des modes de réalisation donnés à titre d'exemple. La figure 1 représente un système audiovisuel comportant un client et un serveur auquel peut s'appliquer l'invention. La figure 2 représente une architecture de dispositif récepteur à laquelle peut s'appliquer l'invention. La figure 3 et la figure 4 représentent l'ordre et la taille des images d'une séquence de transmission d'images encodées suivant un type d'encodage vidéo auquel l'invention peut s'appliquer. La figure 5 représente différents éléments d'un dispositif récepteur selon un mode de réalisation de l'invention. La figure 6 représente un aspect de la mise en oeuvre d'un procédé d'affichage selon l'art antérieur, en fonction du temps.

La figure 7 représente un autre aspect de la mise en oeuvre d'un procédé d'affichage selon l'art antérieur analogue à celui présenté en figure 6, également en fonction du temps. La figure 8 représente un algorithme utilisé au début de la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention.

La figure 9 représente un algorithme utilisé au cours de la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention, avant l'affichage de chaque image. La figure 10 présente un aspect de la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention, représenté en fonction des images successivement affichées. La figure 11 représente un autre aspect de la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention, représenté en fonction des images successivement affichées, et correspondant à la mise en oeuvre de la figure 10.

La figure 12 représente encore un autre aspect de la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention, correspondant à la mise en oeuvre des figures 10 et 11, et représenté en fonction du temps.

La figure 13 représente aussi un aspect de la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention, correspondant à la mise en oeuvre des figures 10 à 12, et représenté en fonction du temps. En référence à la figure 1, un système client-serveur auquel l'invention peut être appliquée est représenté. Un dispositif émetteur ou serveur 101 transmet des paquets de données d'un flux de données à un dispositif récepteur ou client 102 via un réseau de communication de données 100. Le réseau de communication de données 100 (WAN - Wide Area Network ou réseau étendu ; LAN - Local Area Network ou réseau local) peut être par exemple un réseau sans fil (Wifi / 802.11 a ou b ou g), un réseau Ethernet, ou le réseau Internet. Comme c'est souvent le cas, le débit disponible sur le réseau 100 est limité, par exemple par la présence de flux concurrents. Le flux de données 104 fourni par le serveur 101 comprend des informations multimédia représentant de la vidéo et de l'audio. Les flux audio et vidéo peuvent être capturés par le serveur 101 à l'aide d'une caméra 105 et d'un microphone 106. Les flux vidéo et audio sont encodés (notamment en vue de leur compression) par le serveur 101. Pour un meilleur rapport qualité sur quantité de donnés envoyées, la 20 compression de la vidéo peut être de type à compensation de mouvement, par exemple suivant le format H264 ou le format MPEG2. Pour chaque image vidéo, le serveur 101 inclut une date de capture (timestamp) dans le paquet de données de l'image. Il inclut de même une date de capture dans chaque paquet de donnée audio. Cette date est lue sur la 25 même horloge que pour les données image. Les données compressées sont découpées en paquets et transmises au client 102 par le réseau 100 en utilisant un protocole de communication, par exemple le protocole RTP (protocole de transport en temps réel ou Real-time Transport Protocol), UDP (User Datagram Protocol ou 30 protocole de datagramme utilisateur) ou DCCP (Datagram Congestion Control Protocol) ou n'importe quel autre type de protocole de communication.

Dans le cas du protocole RTP par exemple les dates de capture sont indiquées dans l'entête de chaque paquet. Le client 102 décode le flux de données 104 reçu par le réseau 100 et reproduit les images vidéo sur un dispositif d'affichage 107 et les données audio par un haut-parleur 108. On souligne que l'invention s'applique aussi à un système client-serveur où un même serveur fournit des informations à plusieurs clients. Les dates incluses dans les images vidéo et le flux audio peuvent être utilisées par le client 102 pour synchroniser le rendu vidéo et le rendu audio en faisant correspondre les dates de l'affichage vidéo et de l'émission audio. Des informations en retour 109 sont parfois communiquées du client 102 au serveur 101. Elles peuvent permettre de fournir au serveur un retour d'information sur la qualité de la transmission du flux vidéo ou les circonstances de son rendu, et permettre alors au serveur 101 de réagir en fonction de ce retour d'information de manière à améliorer la qualité de l'application. Le serveur et le client sont ici utilisés dans le cadre d'une application de transmission en temps réel. Le temps entre la prise de vue et la date de rendu doit être faible, par exemple dans une application de visioconférence, typiquement inférieur à 150 millisecondes. Il est connu que certains types de réseau introduisent des erreurs lors de la transmission. Certains paquets de données sont perdus lors de congestions du réseau dus à des débordements de mémoire d'éléments internes au réseau tels que les routeurs, ou à cause d'erreurs de transmission, comme par exemple des interférences sur un réseau sans fil. Les erreurs peuvent avoir un effet très important sur la qualité d'une vidéo encodée par compensation de mouvement. En effet une erreur sur une image se propage alors sur les images suivantes. Une manière classique de combattre les erreurs consiste pour le client 102 de transmettre des demandes de rafraichissement au serveur 101 via les informations en retour 109 diffusées à travers le réseau 100.

Sur réception d'une demande de rafraichissement le serveur encode l'image suivante sans utiliser de compensation de mouvement pour arrêter la propagation des erreurs. La figure 2 illustre un schéma de principe d'un dispositif récepteur 102 adapté pour incorporer l'invention. De préférence, le dispositif récepteur 102 comprend une unité de traitement centrale (UC, unité centrale) 201 capable d'exécuter des instructions provenant d'une ROM de programmes 203 à la mise sous tension du dispositif récepteur, et des instructions concernant une application logicielle provenant d'une mémoire principale 202 après la mise sous tension. La mémoire principale 202 est par exemple du type mémoire vive (RAM) qui fonctionne comme zone de travail de l'unité centrale 201, et la capacité de mémoire de celle-ci peut être augmentée par une RAM facultative connectée à un port d'extension (non illustré).

Les instructions concernant l'application logicielle peuvent être chargées dans la mémoire principale 202 à partir du disque dur 206 ou bien de la ROM de programmes 203 par exemple. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Une telle application logicielle, lorsqu'elle est exécutée par l'unité centrale 201, entraîne l'exécution des étapes des organigrammes montrés aux figures 8 et 9. Une interface réseau 204 permet la connexion du dispositif récepteur 102 au réseau de communication 100. L'application logicielle lorsqu'elle est exécutée par l'unité centrale est adaptée pour réagir à des messages du serveur reçues par le biais de l'interface réseau 204 et fournir au serveur 101 des informations par l'intermédiaire du réseau 100. Une interface utilisateur 205 permet le rendu des données multimédia 104 à un utilisateur. Cette interface utilisateur 205 peut aussi optionnellement recevoir une entrée d'information par celui-ci, par exemple via un clavier (non représenté). L'interface utilisateur 205 peut aussi être déportée dans un autre appareil relié par une interface haut débit transportant simultanément l'audio et la vidéo décodées (par exemple une interface de type HDMI). Un dispositif récepteur 102 mettant en oeuvre l'invention est par exemple un micro-ordinateur, une station de travail, un assistant numérique, un téléphone portable, un vidéo projecteur, un téléviseur ou un boitier relié a un téléviseur par une prise HDMI. On va maintenant en référence à la figure 3, présenter un contexte possible d'application de l'invention, portant sur l'utilisation de certains formats de vidéo numériques selon lesquels les images vidéo sont encodées en au moins deux types d'images. Selon ces formats, une image de type I (image Intra) est une image compressée indépendamment des autres images, aussi appelée image indépendante. Le flux d'information (bitstream) définissant l'image I contient donc toutes les informations utiles pour décoder l'image sur le client. C'est le cas des images 11 ou 12 dans l'exemple de la figure 3. A l'inverse, les images P (images Prédites) sont des images compressées en fonction d'une image de référence antérieure, qui peut être une image 1 ou une image P. Les images P sont donc compressées de manière beaucoup plus efficace, et le flux d'information définissant l'image P est en général nettement plus petit qu'un flux d'information définissant une image 1. C'est le cas des images P1 ou P2 sur la figure 3. Le facteur de taille entre ces deux types d'image peut par exemple être de l'ordre de 10 pour un même niveau de quantification et donc une qualité visuelle équivalente. Cela est représenté sur la figure 3, où l'axe des ordonnées présente la taille des flux de données codant pour les images. De manière générale, plus une image P est semblable à l'image de référence à laquelle elle se réfère, plus elle a une taille faible. Il faut noter que l'on peut avoir des parties (appelées blocs) d'une l'image P codée sous forme Intra. Dans ce cas la taille de l'image est intermédiaire entre la taille d'une image 1 et la taille d'une image P et augmente en fonction de la proportion de blocs de l'image qui sont codés sous forme Intra. Dans la suite lorsque nous parlerons d'image I, ce peut aussi être une image de type P avec une forte proportion de blocs codés en Intra.

Par exemple, le format de compression vidéo peut être le format H.264, MPEG-2 ou MPEG-4. Il s'agit de formats connus, basés sur l'application de Transformation en Cosinus Discrète (DCT) par blocs de séquence et sur la compensation de mouvement, suivi d'une quantification. Lors de l'utilisation d'un tel format, les images I peuvent être indispensables pour plusieurs raisons. Tout d'abord, dans certains formats elles doivent être envoyées régulièrement. C'est par exemple le cas du format MPEG2, dans lequel des images I sont envoyées toutes les 25 images. Les images I peuvent aussi dans certains systèmes être générées uniquement en cas de besoin.

Les images I sont notamment utiles lors d'un changement important du contenu des images de la vidéo, par exemple un changement de scène, qui dans le cadre d'une vidéosurveillance peut être un changement de caméra (dans un système à plusieurs caméras) ou un changement important de position de la caméra. La nouvelle image n'a pas de ressemblance avec les images précédentes et donc la compression par compensation de mouvement n'est pas utile ou efficace. Dans ce cas, l'envoi d'une image I permet une bonne qualité d'image. Les images I servent également à réinitialiser le décodage quand il est constaté qu'un nombre trop élevé de pertes de paquets sur le réseau est atteint. En effet, une image P étant codées sur la base d'une image antérieure, si celle-ci comporte des erreurs, celles-ci sont susceptibles de se propager, voire de croître à un niveau inacceptable. Dans ce cas le dispositif récepteur peut effectuer une demande de rafraichissement pour que le serveur envoie une image I (ou une image P avec une forte proportion de blocs Intra) et donc ainsi stoppe la propagation d'erreurs. Un autre cas d'utilisation d'une image I est le début de séquence ou une réinitialisation du transfert d'information lors de la connexion d'un nouveau client à un serveur transmettant un même flux à plusieurs clients. Dans ce dernier cas, une image I doit être générée pour permettre au nouveau client de commencer à décoder le flux vidéo. On précise que certains formats prévoient également des images de type B, se référant à deux images de référence, mais les images de type B ne sont en général pas utilisées pour des applications de vidéo en temps réel. Enfin, un GOP (Group Of Picture ou groupe d'image) est une suite d'images commençant par une image I qui ne fait aucune référence à une image dans un GOP précédent.

En référence à la figure 4 on a représenté schématiquement la progression des flux d'information codant pour des images compressées sur le réseau. Après compression, les flux d'information codant des images de la vidéo sont découpés en paquets pour être envoyés sur le réseau. La taille d'un paquet est adaptée pour être transmise sur le réseau. Elle est classiquement de taille inférieure à 1500 octets. Normalement cette contrainte est prise en compte par l'encodeur qui crée des unités d'information décodables indépendamment les unes des autres et représentant chacune une partie de l'image.

Le débit fourni par le réseau étant limité, le temps d'envoi-réception d'une image est proportionnel à son nombre de paquets et donc à la quantité d'information de l'image. Pour une qualité optimum, le serveur utilise le maximum de débit disponible pour envoyer des images P et de temps en temps des images I (par exemple à temps régulier ou lors d'une demande de rafraichissement). Il apparaît que dans le cas d'une transmission sur un réseau avec un débit limité, la taille importante de l'image I va induire une durée de transmission plus importante que celle des images P. A la durée de transmission s'ajoute dans certains cas la durée de 30 traitement de l'image, qui peut inclure le temps de décodage de l'image par le client ou le temps de codage de l'image par le serveur.

Cette durée de transmission et de traitement peut être du même ordre ou même supérieure au retard accepté pour l'application. Dans ce cas, si aucune mesure n'est prise, le client affiche l'image P précédant l'image I pendant plus longtemps que la durée normale, puis il affiche l'image I et les images P suivant l'image I pendant des durées d'affichage plus courtes que la durée normale, de manière à rattraper le retard pris et resynchroniser la vidéo et le son. Par exemple, dans le cas d'une vidéo à 25 images par seconde, une image doit être capturée et affichée toutes les 40 ms. Sur un serveur pouvant fournir un débit de 512 kbit.s-' la taille maximum des images P est de 512 divisé par 25 = 20 kbit. Lors de l'envoi d'une image I dont la taille est par exemple 5 fois supérieure à celle d'une image P, le nombre de paquets à envoyer est multiplié par 5, soit une quantité d'informations jusqu'à 100 kbit. Si le débit du réseau est utilisé au maximum, ce qui est souvent le cas, le temps d'envoi de cette image est aussi jusqu'à cinq fois plus élevé, soit jusqu'à 200ms. Cela dépasse la contrainte d'échange point à point souhaitée dans le contexte d'application en temps réel, qui comme on l'a vu en introduction doit être inférieur à 150 ms. Pour compenser la taille de l'image I et donc le temps pris pour l'envoyer, il est nécessaire d'encoder plus fortement les images P suivantes. Ceci est représenté sur les figures 3 et 4 par une taille des images P1, P2, P3 plus petites que les images P4, P5. Le temps de transmission d'une image I peut être évalué en utilisant la taille moyenne des dernières images I reçues et le débit disponible du réseau. La figure 5 présente les principaux modules d'un dispositif d'affichage vidéo 102 pouvant utiliser l'invention. Une première mémoire tampon 605 réceptionne les paquets d'information en provenance du réseau 100. Ces paquets sont ensuite utilisés en parallèle par les chaînes de traitement audio (partie inférieure de la figure) et vidéo (partie supérieure de la figure).

Le décodeur audio 610 décode les paquets audio encodés et stocke les données audio décodées dans une autre mémoire tampon 615 dont le contenu est enduite consommé progressivement par le module de reproduction audio 620 commandant un haut-parleur.

Le décodeur vidéo 630 décode quant à lui les paquets d'informations rassemblés pour recréer le flux d'information des images vidéo encodées pour générer des images décodées qui sont stockées dans une mémoire tampon 640 dont le contenu est consommé par le module de reproduction vidéo 645. Le décodeur vidéo 630 et le module de reproduction vidéo 645 sont cadencés par un synchroniseur 650. Le module de reproduction audio 620 fournit au synchroniseur 650 des informations temporelles relatives à la bande sonore. Ces informations sont d'une part la date enregistrée dans la bande sonore lors de son codage par le serveur et d'autre part, l'instant où le son est effectivement reproduit par le module de reproduction audio. Ces informations vont servir pour la synchronisation des images avec la bande sonore. Dans le cadre du mode de réalisation présenté figure 5, le réseau 100 est tel que des données sont perdues entre le serveur 101 et le client 102. Le dispositif d'affichage vidéo 102 comporte quant à lui un module de détection d'erreur 635. Chaque image est codée par plusieurs paquets d'informations transmis via le réseau. La perte de paquets de la partie vidéo créée donc des erreurs dans les images décodées. Quand une image comportant des erreurs sert de référence à une autre image codée par rapport à elle (que cette image de référence soit une image I ou une image P), les erreurs sont propagées dans les images P décodées suivant l'image de référence. Le décodeur vidéo 630 intègre ici des algorithmes de correction d'erreur qui essayent de corriger les erreurs liées par exemple aux problèmes de transmission. Des algorithmes connus peuvent par exemple utiliser des interpolations spatiales ou temporelles. Ces corrections d'erreur permettent d'atténuer l'effet des erreurs mais ne sont pas toujours totalement efficaces. Par exemple dans le cas de scène avec des mouvements importants et non continus les interpolations temporelles sont peu efficaces. Pour déterminer au mieux les actions à entreprendre face à la présence d'erreur, le module de détection d'erreur 635 évalue le taux d'erreur de l'image décodée en fonction du nombre de paquets perdus dans l'image courante, du taux d'erreur de l'image précédente dans le cas d'une image P et de l'efficacité de la correction d'erreur. Comme un paquet représente une partie de l'image, on définit le taux d'erreur d'une image comme le rapport du nombre de paquets perdus sur le 10 nombre de paquets envoyés pour l'image : Taux, = Nb _ Paquets _ Perdus, Nb _ Paquets _ Envoyés, Comme l'erreur de l'image de référence se propage à l'image P codée en fonction de l'image de référence, le taux d'erreur d'une image P est composé de son propre taux d'erreur additionné du taux d'erreur de son image 15 de référence, suivant la formule : Tauxp Yef = TauxYef +Tauxp Si le décodeur utilise un algorithme de correction d'erreur, le taux d'erreur propre de l'image P sera multiplié par un facteur d'amélioration A entre [0,1]. Si la correction d'erreur a corrigé toutes les erreurs, alors A = 0. Si au 20 contraire l'algorithme de correction d'erreur n'a pas pu faire de correction, alors A = 1. On obtient donc le taux d'erreur corrigé : Taux, ref =Tauxref +Ap *Tauxp Dans le mode de réalisation présenté, le client 102 est en mesure de faire des demandes au serveur 101 (comme représenté en figure 1, référence 25 109). Il est notamment en mesure d'envoyer à destination du serveur une requête d'envoi d'une image I, en vu d'utiliser cette image I pour réinitialiser l'affichage et se débarrasser des erreurs qui ont pu être accumulées du fait de la succession d'images P. Une telle requête est appelée demande de rafraichissement . 30 Le taux d'erreur est utilisé par un module d'évaluation de la pertinence d'une demande de rafraichissement 636, décidant en fonction des informations qui lui sont communiqués s'il est ou non approprié de demander au serveur d'effectuer un rafraichissement des données. Ce module 636 utilise notamment le taux d'erreur qui lui est communiqué pour chaque image par le module de détection d'erreur 635, ainsi que des informations sur les contenus audio et vidéo et les caractéristiques générales ou instantanées du fonctionnement du réseau 100, notamment le débit disponible, et le temps mis par les informations pour arriver du serveur au client. Le synchroniseur 650 calcule l'instant d'affichage souhaité des images disponibles en tenant compte de l'instant de reproduction de l'échantillon audio le plus proche. L'instant d'affichage souhaité de l'image est calculé pour faire correspondre les temps de rendu audio et vidéo. Comme indiqué en introduction, pour que la qualité du rendu audio-visuel soit satisfaisante, il faut avoir un affichage régulier des images et un décalage entre le son et les images ne dépassant pas 40 ms. Cela n'est néanmoins pas toujours possible. En effet si une image a un temps de transmission important, le décodeur doit attendre de recevoir toute l'image avant de la décoder. L'image est ensuite affichée quand le décodage est fini. On précise que la fin de réception des paquets d'une image est caractérisée soit par la réception du dernier paquet (dans le cas de transport de données codées au format MPEG4 sur RTP ce dernier paquet a un bit spécifique positionné dans son entête) soit par la réception d'un paquet avec une date différente (disponible par exemple dans l'entête des paquets d'information dans le format RTP). Comme évoqué précédemment en référence à la figure 4 une image I provoque un délai de transmission important qui peut provoquer une irrégularité dans l'affichage des images et une désynchronisation de l'audio et la vidéo. Cela est représenté en figure 6 qui présente les temps de reproduction des images (trait gras) et du son (trait fin) dans une situation classique, où l'invention n'est pas mise en oeuvre.

Dans cet exemple portant sur une vidéo rythmée à 25 images par secondes, le temps d'affichage moyen d'une image est de 1/25 seconde soit 40 ms. Pendant la phase 1, avant la réception d'une image I, les images sont affichées de manière régulière et synchrone avec la bande sonore. Pendant la phase 2, pendant la réception de l'image I le traitement de celle-ci prend plus de temps et l'affichage vidéo est gelé pendant ce traitement, alors que la reproduction audio continue. Pendant la phase 3, une série d'images P de petites tailles arrive de manière rapide et le synchroniseur procède à une resynchronisation. Ceci produit une accélération de l'affichage sur l'écran vidéo. Enfin, pendant la phase 4, les images sont de nouveau affichées régulièrement et de manière synchrone avec la bande sonore. Au cours de ce scénario, le changement d'étape a produit un changement brusque du rythme d'affichage, désagréable pour le spectateur. Egalement, le son et l'affichage ont été désynchronisés pendant les phases 2 et 3. La figure 7 représente quant à elle l'évolution de la quantité d'informations vidéo présente dans la mémoire tampon 605, pendant la même séquence que représentée dans la partie haute de la figure. Avant la réception de l'image I, pendant la phase 1, la mémoire tampon est utilisée à un rythme régulier : elle se remplit pendant la réception de chaque image avec une vitesse dépendant du débit instantané du réseau, et se vide quelques temps après, quand l'image reçue doit être décodée puis affichée. D'une image sur l'autre, la taille de l'ensemble des informations stockées peut varier, dans la mesure où toutes les images P n'ont pas toute la même taille, mais cette taille reste limitée. Généralement, la mémoire tampon se retrouve complètement vide au moment du début de décodage d'une image, l'image suivante commençant à ce moment là ou juste après à être chargée dans la mémoire tampon. Il est également possible que l'image suivante ait déjà commencé à se charger dans la mémoire tampon à cet instant, de telle sorte que la mémoire tampon n'est pas complètement vidée au moment de l'affichage. Au cours de la réception de l'image I, pendant la phase 2, la taille du total des informations stockées augmente progressivement jusqu'à une valeur élevée correspondant à la quantité d'information nécessaire pour coder l'image 1. Le débit du réseau restant limité, la réception de ces informations prend du temps avant que le décodage de cette image et son affichage soient possibles. La chaîne vidéo est stoppée jusqu'à la fin de réception de l'image. Au cours de la phase 3, des images P de petites tailles envoyées par le serveur à la suite de l'émission de l'image I sont reçues par le client. Ces images sont reçues et décodées rapidement et permettent une accélération de la chaîne vidéo, et une resynchronisation de l'image et du son. Enfin, pendant la phase 4, la mémoire tampon est de nouveau utilisée à rythme régulier, correspondant à la phase 1.

La mise en oeuvre de l'invention, dont un mode de réalisation est décrit en détails en référence aux figures suivantes, permet d'anticiper la réception de l'image I en adaptant à l'avance le rythme d'affichage des images et en évitant ainsi un gel de la vidéo provoqué par le temps de traitement d'une image trop importante La figure 8 représente l'algorithme du module d'évaluation 636 qui décide si une image I doit être demandée ou non. Le module d'évaluation 636 reçoit en entrée le taux d'erreur calculé par le module de détection d'erreur 635, calcul effectué au cours d'une étape de calcul d'évaluation d'erreur 800.

Un premier test 801 compare ce taux d'erreur à une première valeur dite valeur faible, ici 5%. Si le taux d'erreur est inférieur à cette valeur, il est considéré qu'une demande de rafraichissement n'est pas nécessaire, et aucune action particulière n'est mise en oeuvre par le module 636. Si le taux d'erreur est par contre supérieur à cette première valeur, 30 un deuxième test 805 est mené, de manière à comparer ce taux à une deuxième valeur, dite valeur élevée, et qui est ici égale à 30%.

Si le taux d'erreur est également supérieur à cette valeur, une requête en rafraichissement est envoyée par le client au serveur via le réseau. Cette requête en rafraichissement vise à obtenir l'envoi par le serveur d'une image I, qui permettra de supprimer les erreurs accumulées dans les images P.

L'étape 810 représente l'envoi d'une demande de rafraichissement, ainsi que la prédiction de l'arrivée d'une image I. Si au cours du test 805, il est constaté que le taux d'erreur est inférieur à la valeur élevée, un test 815 est mené. Ce test 815 est mis en oeuvre sur la base du contenu des images 10 vidéo et de la bande sonore associée. L'impact d'une éventuelle désynchronisation de longue durée entre la reproduction des données audio et des données vidéo sur la qualité pour le spectateur de la reproduction audio-visuelle dans le contexte d'application est évalué. 15 Pour cela les contenus audio et vidéo sont analysés. L'intensité audio est tout d'abord mesurée. Si le niveau sonore est inférieur à 2dB, on considère que le son est peu audible. On estime alors qu'une désynchronisation longue est possible. Les visages des personnes audibles dans le flux audio sont 20 recherchés sur les images. On utilise pour cela des algorithmes connus de détection de visage et de contour des lèvres. On pourra à ce sujet se référer à l'article Face Detection: A Survey , de Erik Hjelmas dans Computer Vision and Image Understanding 83, 236û274 (2001). Si les personnes audibles sont en dehors du champ de la caméra, 25 une désynchronisation de longue durée est considérée comme possible. Une demande de rafraichissement est alors envoyée du client vers le serveur, selon la mise en oeuvre de l'étape 810. L'arrivée d'une image I est de ce fait également prédite. Si l'analyse des contenus audio et vidéo menée à l'étape 815 montre 30 qu'une désynchronisation de longue durée n'est pas souhaitable, une étape 820 est menée, pour déterminer si une désynchronisation de courte durée entre l'audio et la vidéo est souhaitable.

Si par exemple les images vidéo montrent des mouvements importants (ce qui peut être détecté par exemple par la présence de vecteurs mouvements importants), on estime à l'étape 820 qu'une désynchronisation de courte durée n'est pas non plus souhaitable.

Si les images montrent peu de mouvements, on considère au contraire à l'étape 820 qu'un changement de rythme d'affichage sur une durée courte peut être éventuellement mené. Dans ce cas, un test 830 est mené pour savoir si le taux d'erreur est supérieur à une valeur dite valeur moyenne, ici une valeur de 20%.

Si c'est le cas, la décision d'émettre une requête de rafraichissement en direction du serveur est prise selon l'étape 810. Sinon, aucune mesure particulière n'est prise par le client pour corriger l'affichage. Il faut noter que dans ce cas la durée de la désynchronisation entre l'audio et la vidéo doit être courte. Cette information est mémorisée pour mettre en place les calculs de courbe de retard d'images qui seront présentés plus loin. L'étape 810 de prédiction d'une image I comprend une évaluation du nombre d'images, noté N, restant à recevoir via le réseau avant la réception de l'image I.

La valeur de N peut être estimée en fonction du temps moyen entre l'envoi de la demande et la réception de l'image I, calculé sur les précédentes mises en oeuvre du procédé. La valeur de N peut aussi être imposée par le client au serveur en fonction des évaluations effectuées aux étapes 815 et 820, sous réserve que le débit du réseau soit suffisant. Par défaut, une durée de synchronisation longue avec une valeur de N égale par exemple à 10 images est demandée par le client au serveur. Dans le cas où la synchronisation courte est préférable une valeur de N faible, par exemple 4, est choisie.

L'information selon laquelle une image I est attendue est alors transmise au synchroniseur 650 avec la valeur N représentative du nombre d'images à recevoir avant l'image I.

En référence à la figure 9, on a représenté le fonctionnement du synchroniseur 650, qui exécute un algorithme de calcul de synchronisation chaque fois qu'une nouvelle image est disponible ou qu'une image vient d'être affichée.

Cet algorithme permet de calculer le retard At qui doit être ajouté à la date d'affichage de la prochaine image à afficher. Son fonctionnement est décomposé en trois modes représentés par les trois branches se séparant au noeud 901.

Le premier mode est le mode Normal (partie gauche de la figure).

Ce mode est le mode par défaut. Pour chaque image, un test 905 est effectué pour savoir si une image I est prédite. Ce test utilise une des méthodes décrite en référence à la figure 8. Si aucune image I n'est prédite, aucun retard At n'est ajouté (référence 920), le retard cumulé est nul et la vidéo est affichée au rythme normal. Le synchronisateur revient au test 901.

Si une image I est prédite, l'algorithme passe en mode anticipation et une courbe de retard est calculée lors d'une étape 925 à partir du nombre N défini précédemment.

Cette courbe de retard prend en compte le retard cumulé minimal à ajouter pour anticiper l'arrivée de l'image I, ainsi que le retard cumulé courant.

Cette courbe représente le retard à ajouter, sur un nombre N d'images, au temps d'affichage de chaque image pour avoir le minimum de retard cumulé R permettant l'anticipation de la réception d'une image de type I.

Une première solution consiste à ajouter un retard constant sur les N images précédant l'image de type I pour avoir un retard suffisant pour anticiper l'arrivée de l'image I :

1 .fN (i) =- N , i étant le numéro d'image dans l'intervalle [0, N-1].

Cette solution est mise en oeuvre dans les cas où le nombre d'image N avant l'arrivée de l'image I est faible (par exemple inférieur à 4).

Le retard total est uniformément réparti sur toutes les images. Cela minimise l'effet du changement de rythme.

Une deuxième solution est utilisée quand le nombre d'image N avant l'arrivée de l'image I est supérieur à 4. Elle utilise la formule suivante qui permet de lisser les accélérations : 2 26 1+sin[ON(i)] 6 étant échantillonné sur l'intervalle ON(i)=ù+2z* a avec la formule 2 N-1 3 Pour finir, quelle que soit la solution adoptée pour la répartition des retards, on normalise la courbe pour que la somme des échantillons soit égale à un coefficient A : gA,N,10(I) = A* fN(I I°) , le numéro de l'image de type I étant IN, lo i=o ° N (Z) étant le numéro de l'image de début de prédiction et I le numéro de chaque image dans la séquence allant de l'image lo à l'image IN.

Pour minimiser le retard accumulé et avoir le traitement de l'image de type I le plus rapide possible, le coefficient A est choisi égal à R, le retard cumulé minimum pour anticiper l'image de type I, que l'on choisit égal au temps de traitement moyen d'une image de type I (C,) duquel on retranche le temps de traitement moyen d'une image P (Cp) et le retard cumulé à l'instant lo (Ro).

R=CIù Cp ùR° Au cours de l'étape 945 de calcul du retard, on utilise la dernière courbe de retard calculée.

Le synchroniseur 650 utilise la fonction gA N 10 (I) pour calculer l'incrément de retard à appliquer aux images 4t(I) g",10(l)

La courbe des retards ainsi calculés est illustrée en figure 10 repère 1020. On voit que cette formule permet un lissage du retard ajouté et évite un brusque changement de rythme.

Les images de la vidéo étant alors affichées sur l'écran durant un temps d'affichage égal à Di = 1 Rythme , la date d'affichage d'une image i+1 me étant alors égal à ti+1 = ti + Di, avec ti la date d'affichage de l'image i.

La courbe de retard et le numéro de l'image courante sont mémorisés.

Le retard cumulé est aussi mis à jour, au cours d'une étape 950 pour connaître à chaque image le retard cumulé que l'on a introduit dans la vidéo.

Les retards s'ajoutent sur plusieurs images pour obtenir un retard N-1 cumulé R. R = E Ati i=o

Après la mise à jour du retard cumulé, le synchronisateur passe au test 901, et si l'algorithme se trouve toujours dans le mode anticipation , il passe alors au test 915 pour savoir si une image I a été reçue.

Si ce n'est pas le cas, le synchronisateur reste en mode anticipation et la courbe de retard courante est appliquée au cours d'une nouvelle occurrence de l'étape 945.

Dans le cas au contraire où une image I a été reçue, on passe à l'étape 940 pour calculer une nouvelle courbe de retard pour permettre la resynchronisation en fonction du retard cumulé courant.

La même méthode est utilisée pour cette étape de resynchronisation que pour l'étape d'anticipation, à l'exception du fait que le coefficient de normalisation A est calculé pour compenser le retard cumulé R :

A=- R Cette valeur permet de supprimer tout le retard cumulé pour revenir à la synchronisation avec la bande sonore.

Dans le cas de l'utilisation d'une courbe sinusoïdale de même période que celle utilisée lors de l'étape d'anticipation, on obtient la courbe de retard 1025 représentée en figure 10. lI est à noter qu'une courbe sinusoïdale de période différente pourrait être utilisée, ou même une courbe non sinusoïdale, de telle sorte que la courbe des incréments de retard ne soit pas symétriques par rapport à l'image I.

Par défaut le nombre N' d'images utilisées pour resynchroniser peut être calculé en fonction de R pour ne pas trop accélérer la vidéo pendant la resynchronisation.

On peut aussi utiliser une durée N' pour tenir compte de l'impact en qualité de la désynchronisation audio vidéo en utilisant les résultats des étapes d'analyse du contenu audio et vidéo 815 et 820 ou en refaisant ces calculs si nécessaire (dans le cas où le module 636 n'est pas actif) La courbe de resynchronisation 1025 est donc la suivante At(I) = gx N, IN (I ) Le mode du synchronisateur est ensuite mis à resynchronisation (repère 940). Après une occurrence des étapes 945 et 950, où une valeur de retard At est appliquée et où le retard cumulé est mis à jour, le synchronisateur reprend l'étape 901, et s'oriente vers la branche centrale de l'algorithme représenté en figure 8. Le synchronisateur effectue le test 910 pour vérifier si une nouvelle image est prédite alors que la resynchronisation n'est pas finie. Si c'est le cas une nouvelle courbe de retard est calculée à l'étape 925 suivant l'algorithme présenté précédemment. Si le test 910 est négatif, le test 935 qui vérifie si le retard cumulé est nul permet de savoir si la resynchronisation est finie. Si c'est le cas, à l'étape 930 le synchronisateur est commuté en mode normal , et il reprend l'étape 901.

Si le test 935 est négatif, l'algorithme reste en mode resynchronisation et la dernière courbe de retard mémorisée est appliquée à l'étape 945. Les figures 11, 12 et 13 représentent une mise en oeuvre du procédé selon l'invention, en utilisant le calcul d'incrément de retard tel que présenté en relation avec la figure 10. La figure 11 montre l'évolution du retard cumulé tel que mémorisé à chaque occurrence de l'étape 950. Celui-ci débute à la valeur 0, puis augmente progressivement (référence 1010) pendant la phase d'anticipation débutant avec l'affichage d'une image numérotée 0 et s'achevant avec l'affichage d'une image I numérotée N, jusqu'à une valeur de retard cumulé suffisante pour que le retard de l'image 1 n'apporte pas d'à-coup dans l'affichage.

Le retard cumulé diminue ensuite progressivement (référence 1015) jusqu'à une valeur de retard cumulé égale à la valeur 0 pendant la phase de resynchronisation qui débute avec l'affichage de l'image I numérotée N, et qui s'achève avec l'affichage d'une image numérotée N+N'.

La figure 12 présente les temps de reproduction des images (trait gras) et du son (trait fin) dans une situation où l'invention est mise en oeuvre avec le retard cumulé représenté en figure 11. Pendant la phase 1, avant la réception de l'image I, les images sont affichées de manière synchrone à un rythme constant.

Pendant la phase 2, une image I est prévue, un retard est ajouté progressivement de manière souple jusqu'au traitement de l'image I. L'affichage se désynchronise de la bande sonore et le rythme évolue doucement. Le retard cumulé ajouté doit être identique au retard que provoquera l'image I.

Pendant la phase 3, le synchronisateur met en place une resynchronisation : le retard ajouté est progressivement retiré de manière souple sur un certain nombre d'image. L'affichage se resynchronise avec la bande sonore et le rythme évolue doucement. Enfin, pendant la phase 4, une fois que la resynchronisation est 20 achevée, les images sont affichées de manière synchrone. Le rythme est de nouveau constant. On observe que grâce à l'invention, le rythme évolue de manière souple au cours du temps et ne gène pas la visualisation de la vidéo. En référence à la figure 13, la mémoire tampon 605 est utilisée de la 25 manière suivante. Avant la réception de l'image I, pendant la phase 1, la mémoire tampon est utilisée à un rythme régulier. Elle est remplie par les images arrivant, et elle se vide régulièrement, la durée d'arrivée d'une image étant du même ordre de grandeur que la durée d'affichage de l'image la précédant. 30 Une image I est alors prévue, suivant l'étape 810 représentée en figure 8. L'utilisation de la mémoire tampon se désynchronise et reste continue, la durée d'arrivée d'une image étant alors plus courte que la durée d'affichage de l'image la précédant. Le niveau moyen d'occupation de la mémoire tampon augmente alors, pendant la phase 2, jusqu'à une valeur équivalent à la taille d'une image I. Puis, le dispositif procède à l'affichage de l'image I, au moment duquel la mémoire tampon se vide totalement.

Au cours d'une phase 3 de resynchronisation, la valeur moyenne de l'occupation de la mémoire tampon augmente pendant une première partie 3a de la phase 3, puis diminue pendant une deuxième partie 3b de la phase 3. Pendant la partie 3a, des images P de petites tailles sont reçues rapidement les unes derrière les autres, alors que pendant la partie 3b, des images P de tailles moyennes sont reçues. Au cours de la phase 4, après la resynchronisation, la mémoire tampon est utilisée à nouveau à un rythme régulier. Le buffer est utilisé de manière continue au cours du temps. Le synchroniseur 650 transmet au décodeur vidéo 630 l'instant de décodage souhaité, ce qui a pour conséquence de moduler le temps d'attente des paquets dans la mémoire tampon 605. Cet algorithme a par ailleurs l'avantage d'ainsi tenir compte des éventuels paquets d'information parvenant à la mémoire tampon 605 avec un léger retard.20

Claims (23)

1. REVENDICATIONS1. Procédé d'affichage d'une pluralité d'images sur un dispositif d'affichage vidéo recevant via un réseau de communication des données représentant des images destinées à être affichées sur un écran vidéo pendant une durée d'affichage prédéfinie, caractérisé en ce que le procédé comprend successivement une étape de prévision d'un retard de disponibilité de données 10 définissant une image dite image en retard, une étape de commande de l'affichage d'une première pluralité d'images effectuée en fonction de ladite prévision, au moins une image de la première pluralité étant affichée pendant une durée d'affichage supérieure à la durée d'affichage prédéfinie, 15 une étape de commande de l'affichage d'une deuxième pluralité d'images comprenant l'image en retard, au moins une image de la deuxième pluralité étant affichée pendant une durée d'affichage inférieure à la durée prédéfinie. 20
2. 2. Procédé selon la revendication 1, caractérisé en ce que les données sont reçues codées via le réseau de communication, et en ce que la prévision d'un retard de disponibilité de données définissant une image comprend au moins une prévision d'un retard de réception de données codées ou un retard de décodage de données codées. 25
3. 3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que l'affichage des images est accompagné d'une diffusion d'une bande sonore destinée à être diffusée par un haut-parleur associé au dispositif d'affichage vidéo de manière synchronisée avec l'affichage des images, et en 30 ce que l'étape de commande de l'affichage d'une première pluralité d'images est effectuée en fonction d'un critère d'acceptabilité de désynchronisation de l'affichage des images et de la diffusion de la bande sonore pendant une durée donnée.
4. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que les données comprennent une image indépendante définie de manière autonome et une image complémentaire définie en fonction d'une image antérieure et la prévision d'un retard de disponibilité de données inclut une prévision d'un retard d'au moins une donnée définissant une image indépendante.
5. 5. Procédé selon la revendication 4, caractérisé en ce qu'une image indépendante inclut au moins un bloc Intra.
6. 6. Procédé selon la revendication 4 ou la revendication 5, caractérisé en ce que l'étape de prévision comprend une étape d'émission via le réseau à l'attention d'un serveur d'une requête d'envoi d'une image indépendante effectuée en fonction d'une information de pertinence de requête déterminée au moins sur la base d'une donnée reçue via le réseau de communication.
7. 7. Procédé selon la revendication 6, caractérisé en ce que l'information de pertinence de requête indique au moins qu'un taux d'erreur supérieur à une valeur prédéfinie a été mesuré pour une image reçue par le dispositif d'affichage vidéo via le réseau de communication.
8. 8. Procédé selon la revendication 7, caractérisé en ce que ledit taux d'erreur comprend au moins un taux d'erreur instantané ou un taux d'erreur cumulé.
9. 9. Procédé selon l'une des revendications 6 à 8, caractérisé en ce que l'affichage des images étant accompagné d'une diffusion d'une bande sonore destinée à être diffusée par un haut-parleur associé au dispositif d'affichage vidéo de manière synchronisée avec l'affichage des images, et la prévision incluant une évaluation d'un critère d'acceptabilité de désynchronisation de l'affichage des images et de la diffusion de la bande sonore pendant une durée donnée, l'étape de commande de l'affichage d'une première pluralité d'images étant effectuée en fonction dudit critère d'acceptabilité de désynchronisation, l'information de pertinence indique au moins que ledit critère d'acceptabilité de désynchronisation est vérifié.
10. 10. Procédé selon l'une des revendications 4 à 9, caractérisé en ce que la prévision comprend une étape de réception via le réseau de communication d'une information annonçant une émission prochaine d'une image indépendante.
11. 11. Procédé selon la revendication 10 caractérisé en ce que ladite information annonçant une émission prochaine d'une image indépendante est émise en réponse à une requête d'envoi d'une image indépendante par un deuxième dispositif d'affichage vidéo recevant via le réseau de communication lesdites données représentant des images.
12. 12. Procédé selon l'une des revendications 4 à 11, caractérisé en ce qu'une pluralité d'images indépendantes sont envoyées avec une période donnée, et ladite prévision comprend une étape de détermination d'un achèvement d'une occurrence de la période.
13. 13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce que la première pluralité d'images comporte un nombre d'images calculé au moins en fonction d'un temps moyen entre l'envoi d'une image par un serveur et sa réception par le dispositif d'affichage vidéo.
14. 14. Procédé selon l'une des revendications 1 à 13, caractérisé en ce qu'au cours de l'étape d'affichage de la première pluralité d'images, au moins deux images de la première pluralité sont affichées pendant une durée d'affichage supérieure à la durée d'affichage prédéfinie.
15. 15. Procédé selon la revendication 14, caractérisé en ce que la première pluralité d'images comportant au moins une première, une deuxième et une troisième images, la première image étant affichée avant la deuxième image et la deuxième image étant affichée avant la troisième image, les première, deuxième et troisième image étant affichées pendant des durées d'affichage dites respectivement première, deuxième et troisième durées d'affichage, la première durée d'affichage est inférieure à la deuxième durée d'affichage, et la troisième durée d'affichage est également inférieure à la deuxième durée d'affichage.
16. 16. Procédé selon la revendication 15, caractérisé en ce qu'au cours de l'étape d'affichage de la première pluralité d'images, les première, deuxième et troisième durées d'affichage sont proportionnelles à une fonction sinusoïdale appliquée à un numéro d'arrivée de l'image et de période la durée de l'étape.
17. 17. Procédé selon l'une des revendications 1 à 16, caractérisé en ce qu'au cours de l'étape d'affichage de la deuxième pluralité d'images, au moins deux images de la deuxième pluralité sont affichées pendant une durée d'affichage inférieure à la durée d'affichage prédéfinie.
18. 18. Procédé selon la revendication 17, caractérisé en ce que la deuxième pluralité d'images comportant au moins une première, une deuxième et une troisième images, la première image étant affichée avant la deuxième image et la deuxième image étant affichée avant la troisième image, les première, deuxième et troisième image étant affichées pendant des durées d'affichage dites respectivement première, deuxième et troisième durées d'affichage, la première durée d'affichage est supérieure à la deuxième durée d'affichage, et la troisième durée d'affichage est également supérieure à la deuxième durée d'affichage.
19. 19. Procédé selon la revendication 18, caractérisé en ce qu'au cours de l'étape d'affichage de la deuxième pluralité d'images, les première, deuxième et troisième durées d'affichage sont proportionnelles à une fonction sinusoïdale appliquée à un numéro d'arrivée de l'image et de période la durée de l'étape.
20. 20. Procédé selon l'une des revendications 1 à 19, caractérisé en ce qu'un retard accumulé au cours de l'étape d'affichage de la première pluralité d'images est compensé par une avance prise au cours de l'étape d'affichage de la deuxième pluralité d'images.
21. 21. Procédé selon l'une des revendications 1 à 20, caractérisé en ce que l'étape de prévision d'un retard comprend une étape d'estimation d'une durée estimée du retard, et ladite durée d'affichage supérieure à la durée d'affichage prédéfinie dépend de ladite durée estimée du retard.
22. 22. Dispositif d'affichage vidéo comprenant des moyens de réception via un réseau de communication de données représentant des images destinées à être affichées sur un écran vidéo pendant une durée d'affichage prédéfinie, caractérisé en ce que le dispositif comprend des moyens de prévision d'un retard de données définissant une image dite image en retard, des moyens de commande de l'affichage d'une première pluralité d'images, ladite commande étant effectuée en fonction de ladite prévision, au moins une image de la première pluralité étant affichée pendant une durée d'affichage supérieure à la durée d'affichage prédéfinie, des moyens de commande de l'affichage d'une deuxième pluralité d'images comprenant l'image en retard, au moins une image de la deuxième pluralité étant affichée pendant une durée d'affichage inférieure à la durée prédéfinie.
23. 23. Programme d'ordinateur comprenant une suite d'instructions aptes, lorsqu'elles sont exécutées par un microprocesseur, à mettre en oeuvre un procédé selon l'une des revendications 1 à 21.5