Brevet FR2984060A1 — publié le 20130614

- 1 - Procédé et dispositif de restitution locale d'une vidéo Domaine de l'invention L'invention se situe dans le domaine des réseaux de télécommunication. Elle concerne un dispositif et un procédé de restitution locale d'une vidéo lors d'une communication visiophonique. Art antérieur Un service de visiophonie permet à deux utilisateurs de communiquer entre eux par une communication multimédia audio et vidéo. Pour la composante vidéo de la communication, le terminal d'un utilisateur émetteur acquiert une vidéo représentant l'utilisateur et code les données de la vidéo afin de compresser la quantité d'information de la vidéo et d'obtenir un flux de données codées. Le flux de données est ensuite transmis à un utilisateur destinataire via un réseau de télécommunications. L'utilisateur destinataire reçoit sur son terminal le flux de données codées permettant de reconstruire la vidéo représentant l'utilisateur émetteur. Le terminal de l'utilisateur destinataire décode le flux de données reçu et reconstruit la vidéo qui est ensuite affichée sur l'écran de son terminal. Lors de la transmission du flux de données, le flux de données peut subir des dégradations, par exemple des pertes de paquets de données, dues à une mauvaise qualité de service du réseau de télécommunications, ou à des délais de transmission trop importants ou bien encore à la gigue (jitter en anglais, correspondant à des fluctuations du signal) liée à la transmission d'autres flux de données en parallèle sur le réseau. La vidéo affichée sur le terminal du destinataire peut alors avoir une qualité dégradée. Par exemple, la vidéo affichée peut présenter des gels d'images ou de portions d'images, des blocs d'images mal ou non reconstruits, des effets de blocs dans les images. La dégradation subie par une vidéo peut ne pas être symétrique et l'utilisateur émetteur peut recevoir et afficher une vidéo de l'utilisateur destinataire de bonne qualité alors que la vidéo de l'utilisateur émetteur est de mauvaise qualité. Ce problème peut par exemple être due aux débits asymétriques des réseaux d'accès, par exemple pour une connexion ADSL, ou bien au fait que le réseau est plus chargé dans un sens que dans l'autre. L'utilisateur émetteur ne peut pas connaître, ni juger de la qualité de la vidéo qui le représente et qui est affichée à l'utilisateur destinataire. Pour cette raison, les utilisateurs n'adhèrent pas facilement à l'utilisation d'un service de visiophonie car par ces services, ils ne peuvent pas maîtriser l'image qu'ils renvoient à un utilisateur destinataire. Inconvénient de l'art antérieur Une solution proposée dans les services de visiophonie existants est l'affichage de la vidéo de l'émetteur acquise localement, sur l'écran du terminal de l'utilisateur émetteur. L'utilisateur - 2 - émetteur peut alors visualiser simultanément la vidéo qu'il reçoit de l'utilisateur destinataire et la vidéo qu'il envoie à l'utilisateur destinataire. Cependant, cette solution ne permet d'afficher que la vidéo de l'utilisateur émetteur acquise localement, cette vidéo correspond à la vidéo non codée de l'utilisateur émetteur et elle est alors d'excellente qualité. La vidéo affichée ne correspond pas à la vidéo de l'utilisateur émetteur que reçoit et affiche l'utilisateur destinataire. Exposé de l'invention Un des buts de l'invention est d'apporter des améliorations par rapport à l'état de la technique. Elle propose à cet effet un procédé de restitution locale d'une vidéo transmise sous la forme d'un flux de données codées par un réseau de communication et affichée à un destinataire. Le procédé comprend une étape de duplication du flux de données codées, une étape de réception d'au moins une information de qualité relative à la transmission du flux de données codées au destinataire, une étape d'application au flux de données dupliqué d'un traitement déterminé en fonction de la au moins une information de qualité reçue, résultant en un flux de données modifié, et une étape d'affichage d'une vidéo reconstruite à partir du décodage du flux de données modifié. L'utilisateur émetteur de la vidéo peut ainsi visualiser une version de la vidéo qu'il a émise dont la qualité est proche de la qualité de la vidéo visualisée par le destinataire. En effet, la vidéo restituée localement à l'utilisateur émetteur présente des défauts de qualité similaires à ceux de la vidéo transmise et en rapport avec la qualité de la transmission de cette vidéo. L'utilisateur peut ainsi avoir un retour sur la qualité de la vidéo qu'il a émise et que le destinataire visualise. La vidéo émise peut correspondre à une vidéo représentant l'utilisateur, le procédé permet alors à l'utilisateur de contrôler son image. La vidéo émise peut aussi correspondre à une vidéo représentant une scène de l'environnement de l'utilisateur. Avantageusement, le procédé selon l'invention est mis en oeuvre au cours d'une communication audio et vidéo entre au moins un émetteur et le destinataire. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux caractéristiques du procédé défini ci-dessus. Selon un mode particulier de réalisation de l'invention, la au moins une information de qualité est transmise selon le protocole de transport RTCP (Real-Time Control Protocol en anglais). Ainsi, l'invention bénéficie des mécanismes connus de diffusion de rapports relatifs à la qualité de la transmission de données sur une liaison de communication. Le terminal de l'utilisateur a ainsi accès aisément à une information de qualité relative à la qualité de la transmission. De manière avantageuse, selon ce mode particulier de réalisation de l'invention, il n'est pas nécessaire de modifier les protocoles de transport des flux médias d'un échange de données, ni d'ajouter un protocole de communication supplémentaire. Selon un autre mode particulier de réalisation de l'invention, le procédé de restitution comprend une étape d'activation préalable à l'affichage de la vidéo reconstruite à partir du décodage du flux de données modifié. L'utilisateur peut ainsi basculer entre l'affichage local de la vidéo émise non - 3 - codée, ne présentant donc pas de défauts dus au codage ou à la transmission, et l'affichage local de la vidéo dégradée. Selon un autre mode particulier de réalisation de l'invention, le procédé peut être mis en oeuvre au cours d'une communication vidéo entre un émetteur et le destinataire. Le procédé comprend en outre une étape d'adaptation d'au moins un paramètre relatif à la communication vidéo. Avantageusement, l'étape d'adaptation peut être mise en oeuvre à l'initiative de l'utilisateur émettant la vidéo vers le destinataire. L'utilisateur émetteur peut ainsi modifier les paramètres de son terminal ou de sa connexion au réseau par exemple s'il juge que la qualité de la vidéo transmise n'est pas acceptable et souhaite l'améliorer. L'invention concerne aussi un dispositif de restitution locale d'une vidéo transmise sous la forme d'un flux de données codées par un réseau de communication et affichée à un destinataire. Le dispositif comprend des moyens de duplication du flux de données codées, des moyens de réception d'au moins une information de qualité relative à la transmission du flux de données codées au destinataire, des moyens d'application au flux de données dupliqué d'un traitement déterminé en fonction de la au moins une information de qualité reçue, résultant en un flux de données modifié et des moyens d'affichage d'une vidéo reconstruite à partir du décodage du flux de données modifié. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux caractéristiques du dispositif défini ci-dessus. Selon un mode particulier de réalisation de l'invention, le dispositif comprend des moyens d'activation de l'affichage de la vidéo reconstruite à partir du décodage du flux de données modifié. Selon un autre mode particulier de réalisation de l'invention, le dispositif comprend des moyens d'adaptation d'au moins un paramètre relatif à une communication vidéo mise en oeuvre entre un émetteur et le destinataire. Les moyens d'adaptation sont activés à l'initiative de l'émetteur. L'invention concerne également un terminal comprenant un dispositif selon l'un quelconque des modes de réalisation de l'invention cités ci-dessus. L'invention concerne aussi un programme d'ordinateur comportant des instructions pour l'exécution du procédé de restitution selon l'un quelconque des modes de réalisation de l'invention cités ci-dessus, lorsque le programme est exécuté par un processeur. L'invention concerne aussi un support d'enregistrement lisible par un processeur sur lequel est enregistré un programme comportant des instructions pour l'exécution du procédé selon l'un quelconque des modes particuliers de réalisation cités ci-dessus. Le dispositif, le terminal, le programme et le support d'informations présentent des avantages analogues à ceux du procédé selon l'invention décrits ci-dessus. - 4 - Liste des figures D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels: la figure 1 illustre un exemple d'environnement de mise en oeuvre du procédé selon un mode particulier de réalisation de l'invention, la figure 2 illustre les étapes du procédé selon un mode particulier de réalisation de l'invention, la figure 3 illustre l'architecture d'un dispositif mettant en oeuvre le procédé selon un mode particulier de réalisation de l'invention. Description d'un mode particulier de réalisation de l'invention La figure 1 illustre un exemple d'environnement de mise en oeuvre du procédé selon un mode particulier de réalisation de l'invention. L'environnement comprend un réseau de communication 10, correspondant par exemple à un réseau IP (pour Internet Protocol en anglais) ou un réseau de télécommunications mobile de type GSM, EDGE, 3G, 3G+... Le réseau de communication 10 représenté peut correspondre à un groupe de réseaux de communication d'opérateurs différents interconnectés entre eux permettant d'échanger des données et d'établir des communications entre des terminaux connectés au réseau de communication 10 par l'intermédiaire de points d'accès (non représenté) au réseau de communication. Un utilisateur UA d'un terminal 11 connecté au réseau 10 établit une communication en visiophonie, c'est-à-dire une communication audio et vidéo, avec un utilisateur UB d'un terminal 12 également connecté au réseau 10. L'écran 111 du terminal 11 affiche alors à l'utilisateur UA dans un cadran 112 la vidéo reçue de l'utilisateur UB. La vidéo acquise localement de l'utilisateur UA s'affiche également sur l'écran 111 dans un cadran 113. Grâce au procédé de restitution locale tel que décrit dans l'invention, la vidéo locale affichée dans le cadran 113 correspond à la vidéo de l'utilisateur UA acquise localement qui a été codée et dont le flux de données codé a subi un traitement en fonction de la qualité de transmission sur le réseau, puis décodé afin de reconstruire une vidéo de l'utilisateur UA présentant des défauts similaires à ceux de la vidéo de l'utilisateur UA affichée sur l'écran 121 du terminal 12 de l'utilisateur UB. De la même manière, l'écran 121 du terminal 12 affiche alors à l'utilisateur UB dans un cadran 122 la vidéo reçue de l'utilisateur UA. La vidéo acquise localement de l'utilisateur UB et dégradée selon le procédé tel que décrit en référence avec la figure 2, s'affiche également sur l'écran 121 dans un cadran 123. Le procédé de restitution locale décrit à la figure 2 peut être mis en oeuvre par les deux terminaux impliqués dans la communication ou par un seul des terminaux. Si par exemple, seul le terminal 11 met en oeuvre le procédé de restitution locale, le terminal 12 affichera dans le cadran 123 de l'écran 121, la vidéo acquise localement de l'utilisateur UB n'ayant subie aucune dégradation. - 5 - La figure 2 illustre les étapes du procédé de restitution locale selon un mode particulier de réalisation de l'invention. Lors d'une étape 200, une communication visiophonique est établie (E COM) entre deux terminaux, par exemple entre le terminal 11 et le terminal 12, de manière connue à l'aide par exemple du protocole SIP (pour Session Initiation Protocol en anglais) utilisé pour des communications sur réseaux IMS (pour IP Multimedia Subsystem en anglais). Le protocole SIP transporte des informations de description de protocole SDP (pour Session Description Protocol en anglais) permettant aux terminaux d'échanger des informations concernant les codecs supportés par chaque terminal et relatifs aux médias (audio, vidéo, texte, ...) supportés par chaque terminal. Par exemple, ces codecs peuvent correspondre aux normes G711, G722, G729 pour l'audio, H261, H263 ou H264 pour la vidéo, T140 pour le texte temps réel. Le protocole SIP permet aussi aux terminaux d'échanger les adresses IP,t numéros de port et protocole de transport de communication sur lesquels les terminaux veulent recevoir les flux média de la communication. Après l'établissement de la communication, les terminaux échangent de manière connue des données audio sous la forme d'un flux de données audio codé et vidéo sous la forme d'un flux de données vidéo codé. Le terminal 11 acquiert (E ACQ) lors d'une étape 201 un flux vidéo représentant l'utilisateur UA du terminal. Le flux vidéo est ensuite codé (E COD) lors d'une étape 202, par exemple à l'aide d'un codeur H.264 intégré dans le terminal 11. Le codeur fournit en sortie un flux de données codées qui est transmis (E TRANS) au terminal destinataire 12 selon un protocole connu de communication, par exemple le protocole RTP (pour Real-time Transport Protocol en anglais), lors d'une étape 203. Le protocole RTP encapsule les données codées dans des paquets de données qui sont ensuite encapsulés dans des datagrammes UDP (User Data Protocol en anglais) transportés par le protocole IP. Lors d'une étape 204, le terminal 11 reçoit (E RVID) un flux de données codées en provenance du terminal 12. Le terminal 11 extrait les données codées correspondant à des données vidéo du flux reçu et décode (E DECOD) le flux de données vidéo codées extrait lors d'une étape 205 afin de reconstruire la vidéo représentant l'utilisateur UB du terminal 12. La vidéo reconstruite est ensuite affichée (E AFF DST) sur l'écran du terminal 11 lors d'une étape 206. Le terminal 11 émet et reçoit également périodiquement des paquets de contrôle relatifs aux flux de données audio et vidéo codés reçus et émis. Ces paquets de contrôle sont par exemple envoyés selon le protocole RTCP (Real-Time Control Protocol en anglais) et correspondent à des paquets de type SR (Send Report en anglais) et RR (Receive Report en anglais). Ce protocole est décrit plus en détail dans le document RFC 1889 (« RTP : a Transport Protocol for Real-Time Applications », janvier 1996), publié par le groupe de travail de transport audio-vidéo de l'IETF (pour Internet Engineering Task Force en anglais). De manière connue, à partir de ces paquets RTCP, les terminaux peuvent connaître le taux de pertes de paquets de données RTP lors de la transmission entre le terminal émetteur et le terminal - 6 - récepteur, le délai de transmission et la gigue du réseau. A partir de ces informations, lorsque la qualité de la transmission est trop mauvaise, les terminaux peuvent par exemple décider d'augmenter le taux de compression des données vidéo ou de renégocier un codec vidéo. De manière symétrique, les étapes 200 à 206 sont mises en oeuvre au niveau du terminal 12 de l'utilisateur UB afin d'afficher sur l'écran du terminal 12 la vidéo reconstruite représentant l'utilisateur UA. En parallèle, lors d'une étape 207, le terminal 11 duplique le flux de données codées issu du codeur à l'étape 202 et le stocke provisoirement dans une mémoire vive. Lors d'une étape 208, le terminal 11 reçoit (E REC) en provenance du terminal 12 des paquets RTCP. Ces paquets RTCP reçus permettent au terminal d'avoir une information de qualité relative à la transmission des données. Les paquets RTCP contiennent des informations relatives à la qualité de service concernant la réception de chaque source média (audio, vidéo, texte, ...) que le terminal 12 a reçu depuis le dernier paquet RTCP de type SR ou RR envoyé. Le terminal 11 extrait des paquets RTCP les informations de qualité de service relatives aux paquets de données qu'il a émis à l'étape 203. Ces informations sont les suivantes : le champ SSRC (pour Synchronisation SouRCe en anglais) correspondant à la source pour laquelle le paquet est émis, le taux de paquets perdus depuis le précédent paquet SR envoyé, le nombre cumulé de paquets perdus depuis le début de la réception de paquets de données, le plus grand numéro de séquence reçu d'un paquet RTP, la gigue, correspondant à la variation du délai entre des paquets média. Il s'agit d'une estimation de la variance de l'intervalle de réception entre deux paquets, calculé en comparant l'instant de réception obtenue par l'horloge locale et le marqueur temporel du paquet RTP, le dernier marqueur temporel d'un paquet SR reçu, noté LSR pour Last Sender Report en anglais, le délai entre la réception du dernier paquet SR reçu et l'envoi du présent paquet SR, noté DLSR pour Delay Last Sender Report en anglais. En soustrayant à l'instant de réception de ce présent paquet SR, le dernier marqueur temporel LSR indiqué ci-dessus et le délai DLSR indiqué ci-dessus, le récepteur du présent paquet SR peut ainsi calculer le temps d'aller-retour d'un paquet SR. A partir des informations décrites ci-dessus, en 209, le terminal 11 peut appliquer (E APP) au flux de données dupliqué des perturbations réseau similaires à celles subies par le flux de données vidéo codé transmis au terminal 12 lors de l'étape 203. Le flux de données dupliqué stocké peut par exemple subir des pertes de paquets de données, le taux de pertes appliqué correspondant au taux de pertes de paquets indiqué dans un paquet RTCP SR récemment reçu. Par exemple, si le taux de pertes de paquets est de 0.5%, un paquet sur 200 paquets va être supprimé. Certains paquets de données du flux dupliqué peuvent aussi subir du délai et/ou de la gigue. Par exemple, si le délai de bout en bout est de 300 millisecondes - 7 - et la gigue de 10 millisecondes, les paquets de données du flux dupliqué sont stockés pendant 300 millisecondes en moyenne et envoyés au décodeur vidéo après un temps de 290 millisecondes pour certains paquets et de 310 millisecondes pour d'autres paquets. Le temps de réception d'un paquet RTCP SR correspondant à l'émission ou la réception de paquets de données vidéo pouvant être de l'ordre de 5 à 30 secondes par rapport à l'émission ou la réception des paquets de données vidéo correspondants, les paramètres de dégradations appliqués au flux de données dupliqué ne correspondront pas forcément aux valeurs des paramètres relatives à la transmission de ces mêmes paquets. Cependant, la dégradation apportée par le réseau étant relativement stable, les informations extraites des paquets RTCP permettent d'émuler dans le terminal 11 une qualité de la transmission de la communication proche de la qualité réelle de transmission. Lors d'une étape 210, le terminal 11 effectue alors le décodage (E DEC D) des paquets de données du flux dupliqué modifié par les dégradations appliquées en 209 afin de reconstruire une vidéo locale dégradée. En 212, le terminal 11 affiche (E AFF LOC) la vidéo locale dégradée par exemple dans le cadran 113 de l'écran 111 du terminal. Selon un mode particulier de réalisation de l'invention, l'utilisateur UA peut activer (E ACT) l'affichage de la vidéo locale dégradée lors d'une étape 211 à l'aide par exemple d'un bouton On/Off dédié sur son terminal ou un bouton affiché sur l'interface graphique de l'application de visiophonie. Ainsi, l'utilisateur UA peut choisir d'activer ou désactiver l'affichage de la vidéo locale dégradée. L'utilisateur UA peut ainsi basculer sur l'affichage de la vidéo locale originale non dégradée s'il le souhaite. Selon un autre mode particulier de réalisation de l'invention, suite à la visualisation de la vidéo dégradée en 212, l'utilisateur UA peut demander une adaptation (E ADAPT) d'un paramètre de la communication par le terminal 11 lors d'une étape 213. Par exemple, l'utilisateur UA peut activer un changement de réseau en cours de communication afin de basculer sur un réseau de communication possédant une meilleure qualité de service. L'utilisateur peut aussi par exemple demander l'adaptation de la taille de la vidéo acquise par son terminal 11, le terminal 11 peut par exemple diminuer ou augmenter la taille des images de la vidéo acquise. Par exemple, le terminal peut adapter le format d'acquisition passant de la Haute Définition à la définition standard ou l'inverse. La figure 3 illustre l'architecture d'un dispositif 30 mettant en oeuvre le procédé de restitution locale selon un mode particulier de réalisation de l'invention. Le dispositif comprend un espace de stockage 34, par exemple une mémoire (MEM), une unité de traitement 33, équipée par exemple d'un microprocesseur (PROC), et pilotée par le programme d'ordinateur (PG) 35, mettant en oeuvre le procédé de restitution locale tel que décrit dans l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 35 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 33. Le - 8 - microprocesseur de l'unité de traitement 33 met en oeuvre les étapes du procédé de restitution locale d'une vidéo transmise sous la forme d'un flux de données codées par un réseau de communication et affichée à un destinataire selon l'invention décrit précédemment et notamment les étapes de duplication du flux de données codées, de réception d'au moins une information de qualité relative à la transmission du flux de données codées au destinataire, d'application au flux de données dupliqué d'un traitement déterminé en fonction de la au moins une information de qualité reçue, résultant en un flux de données modifié, et d'affichage d'une vidéo reconstruite à partir du décodage du flux de données modifié, selon les instructions du programme d'ordinateur 35. Pour cela, le dispositif comprend, outre la mémoire 34, des moyens de communication 31 (COM) permettant au dispositif de se connecter à un réseau de télécommunication et d'échanger des données avec d'autres dispositifs par l'intermédiaire du réseau de télécommunications. Ces moyens de communication peuvent par exemple être une interface réseau. Le dispositif comprend également des moyens de codage et de décodage 38 (DEC) d'un flux vidéo permettant de compresser une vidéo acquise localement et/ou décoder des paquets de données codées reçus depuis un terminal distant ou depuis un module d'émulation réseau 32 intégré au dispositif 30. Le dispositif comprend aussi un module d'émulation réseau 32 (MOD RTCP) permettant d'appliquer des perturbations réseau à un flux de données codé afin de simuler la transmission sur le réseau du flux de données codé. Le dispositif comprend des moyens d'affichage 36 (AFF) tels que par exemple un écran d'affichage permettant d'afficher la vidéo reconstruite à partir du flux de données vidéo décodé reçu depuis un terminal distant et/ou d'afficher la vidéo reconstruite à partir du flux de données vidéo ayant subi des perturbations réseau et décodé. Le dispositif comprend des moyens d'interaction utilisateur 37 (I/O) tels que par exemple un clavier ou un écran tactile permettant à un utilisateur par exemple de composer un numéro, de lancer une application de visiophonie et/ou d'activer l'affichage de la vidéo au cours de la communication. Le dispositif comprend également des moyens d'acquisition 41 (ACQ) d'une vidéo locale, par exemple une caméra, des moyens d'acquisition sonore 39 (MIC) tels que par exemple un microphone et des moyens de restitution sonore 40 (HP) tels que par exemple des haut-parleurs. Selon un mode particulier de réalisation de l'invention, le dispositif comprend aussi des moyens d'adaptation 42 (ADA) d'au moins un paramètre relatif à la communication. Ces moyens peuvent par exemple être mis en oeuvre par un module de commande des interfaces de connexions à un ou plusieurs réseaux de télécommunications ou des moyens d'acquisition vidéo du dispositif. Ces moyens peuvent aussi être mis en oeuvre sous la forme d'un programme d'ordinateur commandant par exemple les moyens de communication et/ou les moyens d'acquisition vidéo. Selon un mode particulier de réalisation de l'invention, le dispositif 30 est intégré dans un terminal téléphonique, par exemple un terminal mobile ou fixe possédant des moyens de visiophonie. - 9 - Selon un autre mode particulier de réalisation de l'invention, le dispositif est intégré dans un terminal de type ordinateur personnel, une TV connectée à un réseau de télécommunication, une borne interactive. REVENDICATIONS1. Procédé de restitution locale d'une vidéo transmise sous la forme d'un flux de données codées par un réseau de communication et affichée à un destinataire, caractérisé en ce qu'il comprend : une étape de duplication (207) du flux de données codées, une étape de réception (208) d'au moins une information de qualité relative à la transmission du flux de données codées au destinataire, une étape d'application (209) au flux de données dupliqué d'un traitement déterminé en fonction de la au moins une information de qualité reçue, résultant en un flux de données modifié, une étape d'affichage (212) d'une vidéo reconstruite à partir du décodage du flux de données modifié. 2. Procédé de restitution selon la revendication 1 caractérisé en ce que la au moins une information de qualité est transmise selon le protocole de transport RTCP. 3. Procédé de restitution selon la revendication 1 caractérisé en ce qu'il comprend une étape préalable d'activation (211) de l'affichage de la vidéo reconstruite à partir du décodage du flux de données modifié. 4. Procédé de restitution selon la revendication 1, le procédé étant mis en oeuvre au cours d'une communication vidéo 200 entre au moins un émetteur et le destinataire, le procédé est caractérisé en qu'il comprend en outre une étape d'adaptation (213) d'au moins un paramètre relatif à la communication. 5. Dispositif de restitution locale d'une vidéo transmise sous la forme d'un flux de données codées par un réseau de communication et affichée à un destinataire, caractérisé en ce qu'il comprend : des moyens de duplication (34, 35) du flux de données codées, des moyens de réception (31) d'au moins une information de qualité relative à la transmission du flux de données codées au destinataire, des moyens d'application (32) au flux de données dupliqué d'un traitement déterminé en fonction de la au moins une information de qualité reçue, résultant en un flux de données modifié, des moyens d'affichage (36) d'une vidéo reconstruite à partir du décodage du flux de données modifié.. Dispositif de restitution selon la revendication 5 caractérisé en ce qu'il comprend des moyens d'activation de l'affichage de la vidéo reconstruite à partir du décodage du flux de données modifié. 7. Dispositif de restitution selon la revendication 5 caractérisé en ce qu'il comprend des moyens d'adaptation d'au moins un paramètre relatif à une communication vidéo entre au moins un émetteur et le destinataire. 8. Terminal comprenant un dispositif selon l'une quelconque des revendications 5 à 7. 9. Programme d'ordinateur comportant des instructions pour l'exécution du procédé de restitution selon l'une quelconque des revendications 1 à 4, lorsque le programme est exécuté par un processeur.15