FR2940736A1

FR2940736A1 - Systeme et procede de codage video

Info

Publication number: FR2940736A1
Application number: FR0859113A
Authority: FR
Inventors: Jean Pierre Morard
Original assignee: Sagem Communications SAS
Current assignee: Sagemcom Broadband SAS
Priority date: 2008-12-30
Filing date: 2008-12-30
Publication date: 2010-07-02
Anticipated expiration: 2028-12-30
Also published as: CN102318344B; US20110268191A1; US8731060B2; FR2940736B1; EP2380350A1; CN102318344A; WO2010076439A1; BRPI0923824A2

Abstract

La présente invention concerne un système et un procédé de codage vidéo. L'invention s'applique au domaine de la diffusion de données vidéo par un serveur vers un terminal client. Le système (100) de codage vidéo pour le codage d'images successives d'une séquence vidéo comporte un module (101) de réception de données d'entrées pour la réception de l'image courante (F ) à coder, des moyens (103) pour diviser l'image courante (F ) en macroblocs, un module (105) d'estimation de vecteurs de mouvement et un module (106) de compensation de mouvement. Le module (101) de réception de données reçoit en outre un vecteur de mouvement réel d'au moins une zone déplacée de l'image courante (F ), le système (100) de codage comportant des moyens (104) pour attribuer ledit vecteur de mouvement réel aux macroblocs appartenant à ladite zone déplacée et des moyens (118) pour transmettre le vecteur de mouvement réel directement au dit module (106) de compensation sans estimation des vecteurs de mouvements par le module (105) d'estimation pour les macroblocs appartenant à la zone déplacée.

Description

Système et procédé de codage vidéo

Domaine technique de l'invention La présente invention concerne un système de codage vidéo. Elle a également pour objet un procédé de codage vidéo. L'invention s'applique au domaine de la diffusion de données vidéo par un serveur vers un terminal client. Le serveur, généralement un ordinateur, est relié au terminal client, par exemple un décodeur vidéo, par un réseau, par exemple sous forme HDMI ( High Definition Multimedia Interface en anglais), WIFI ou ethernet. L'écran de l'ordinateur peut alors être affiché par le terminal client sur un écran de télévision selon un protocole de type Remote Frame Buffer , par exemple VNC ( Virtual Network Computing en anglais). Arrière-plan technologique de l'invention Dans une telle architecture, le serveur encode, c'est-à-dire compresse, ce qu'il diffuse avant de l'envoyer au terminal client. Si le serveur avait à afficher sur un écran qui lui est propre les images qu'il diffuse, il ne lui serait pas nécessaire de les compresser. Pour compresser, le serveur effectue une capture de son propre affichage, l'encode et l'envoie via le ré-seau au terminal client. Chaque image à afficher est stocké dans une mémoire tampon dite framebuffer du serveur et est généralement codée en format RGB ( Red Green Blue en anglais) qui constitue la manière la plus directe de coder les images, les trois plans correspondant aux trois couleurs élémentaires rouge, vert et bleu. L'image est ensuite généralement transformée dans un format YUV (ou luminance û chrominance). Le premier plan, appelé plan de luminance (Y) représente l'intensité lumineuse des pixels. Les deux plans suivants correspondent à la chrominance (U,V) et portent l'information de couleur. Il existe essentiellement deux formats YUV : - le format 4 :2 :0 (dit également YUV12) pour lequel les deux plans de chrominance contiennent chacun un échantillon pour quatre pixels, - le format 4 :4 :4 pour lequel les trois plans ont la même taille (i.e. il y a un échantillon de chrominance par pixel).

L'encodage effectué par le serveur est un encodage du type spatio-temporel tel que H264. La norme H264 est une norme de codage vidéo dé- veloppée conjointement par le VCEG ( Vidéo Coding Experts Group ) et le MPEG ( Moving Pictures Experts Group ). Cette norme permet d'encoder des flux vidéo avec un débit inférieur à deux fois moins que celui obtenu par la norme MPEG2 pour la même qualité. Un encodage spatio-temporel n'encode intégralement qu'une partie des images à transmettre afin de reconstituer une vidéo. On retrouve dans la norme H264 les types d'image connus et définis dans la norme MPEG2, à savoir : - les images I (Intra) dont le codage ne dépend d'aucune autre image, - les images P (Prédictives) dont le codage dépend d'images reçues précédemment, - les images B (Bi-prédictives) qui dépendent d'images reçues précédemment et/ou postérieurement. Toutefois, la mise en oeuvre d'une telle solution d'encodage pose un certain nombre de difficultés lorsqu'il s'agit de déporter en temps réel l'affichage du serveur sur le terminal client. Ainsi, un tel mode de codage est très couteux en temps et en moyens de calculs. Pour économiser de la bande passante, les données doivent être compressées le plus possible. Cette compression importante impose une grande complexité dans l'encodage. Ainsi, le serveur doit non seulement effectuer une compression d'image mais doit effectuer de nombreux calculs pour déterminer les adresses et les données à encoder. Cette surconsommation d'énergie rend délicate la mise en oeuvre d'autres applications fonctionnant sur le même serveur. Description générale de l'invention Dans ce contexte, la présente invention vise à fournir un système de codage vidéo spatio-temporel permettant de réduire l'effort d'encodage en vue d'une utilisation suivant un protocole client serveur en temps réel tout en laissant suffisamment de ressources sur le serveur en charge de l'encodage pour faire tourner d'autres applications.

A cette fin, l'invention propose un système de codage vidéo pour le codage d'images successives d'une séquence vidéo, le codage d'au moins une image courante étant opéré relativement à au moins une image précé- dente et/ou postérieure de ladite séquence vidéo, ledit système de codage comportant : - un module de réception de données d'entrées pour la réception de ladite image courante à coder, - des moyens pour diviser ladite image courante en macroblocs, - un module d'estimation de vecteurs de mouvement en fonction des macroblocs de ladite image courante et de ladite au moins une image précédente et/ou postérieure, - un module de compensation de mouvement recevant des vecteurs de mouvement et fournissant au moins une zone prédite, ledit système de codage étant caractérisé en ce que ledit module de réception de données reçoit en outre un vecteur de mouvement réel d'au moins une zone déplacée de ladite image courante, ledit système de codage comportant : - des moyens pour attribuer ledit vecteur de mouvement réel aux macroblocs appartenant à ladite zone déplacée ; - des moyens pour transmettre ledit vecteur de mouvement réel directement au dit module de compensation sans estimation des vecteurs de mouvements par ledit module d'estimation pour lesdits macroblocs appartenant à ladite zone déplacée. On désigne par le terme macrobloc, une région élémentaire rectangulaire de l'image ayant une taille comprise entre 4x4 et 16x16 pixels (en passant par 8x16, 8x8,...). Chaque macrobloc est lui-même constitué de blocs de luminance et de blocs de chrominance.

L'estimation de mouvement dans le cadre d'un codage spatio-temporel est une opération qui nécessite une puissance de calcul très importante. Le système selon l'invention permet de s'affranchir d'une partie de cette estimation en utilisant avantageusement la fourniture d'un vecteur de mouvement déjà existant.

Grâce à l'invention, la fourniture du vecteur de mouvement relatif à une zone (typiquement un rectangle à l'intérieur d'une image ou frame en anglais) ayant subi un déplacement permet de ne pas calculer les vecteurs de mouvement pour les macroblocs qui se trouvent dans une telle zone déplacée. Le vecteur de mouvement réel est directement injecté sur l'entrée du module de compensation. Ainsi, l'effort d'encodage est notablement réduit par rapport à un en-codage spatio-temporel classique.

Le système de codage trouve une application particulièrement intéressante dans le cas où l'initiation du déplacement de la zone est réalisée au niveau d'un terminal client relié à un serveur via un protocole VNC, le rendu du déplacement étant affiché sur l'écran du terminal. Le codage par le système selon l'invention est effectué au niveau du serveur et le vecteur réel de la zone déplacée est fourni par une interface de programmation de l'environnement graphique du serveur. Outre l'effort d'encodage réduit, on notera que, grâce à l'invention, le rendu sera meilleur puisqu'on travaille, au moins en partie, avec des vecteurs de mouvement réels et non estimés.

Typiquement, on peut obtenir un tel vecteur de mouvement réel pour une zone subissant un déplacement dans le cadre d'application telle que : - un défilement (ou scrolling en anglais) horizontal ou vertical de la zone déplacée avec une application du type navigateur ; - déplacement d'une fenêtre graphique du système d'exploitation du serveur; - transition d'un transparent à un autre transparent dans le cas d'un diaporama ( slideshow en anglais); - animation du type flash ou silverlight. Le système selon l'invention peut également présenter une ou plu- sieurs des caractéristiques ci-dessous, considérées individuellement ou se- lon toutes les combinaisons techniquement possibles : - le système selon l'invention comporte des moyens pour transmettre uniquement les macroblocs n'appartenant pas à ladite zone déplacée vers ledit module d'estimation de vecteurs de mouvement; - un soustracteur pour effectuer la différence entre les pixels de l'image courante et la zone prédite et fournissant une erreur résiduelle correspondant à cette différence ; - un module de transformée fréquentielle appliquant une transformée fréquentielle sur chaque macrobloc traité par ledit module d'estimation ainsi que sur ladite erreur résiduelle ; - un module de quantification des données issues dudit module de transformée fréquentielle ; - un codeur entropique pour le codage des données issues dudit module de quantification. La présente invention a également pour objet un procédé de codage vidéo pour le codage d'images successives d'une séquence vidéo, le co- dage d'au moins une image courante étant opéré relativement à au moins une image précédente et/ou postérieure de ladite séquence vidéo, ledit pro- cédé comportant les étapes suivantes : - réception de ladite image courante à coder et d'un vecteur de mouvement réel d'au moins une zone déplacée de ladite image courante, - division de ladite image courante en macroblocs, - attribution dudit vecteur de mouvement réel aux macroblocs appartenant à ladite zone déplacée, - estimation de vecteurs de mouvement en fonction des macroblocs de ladite image courante et de ladite au moins une image précédente et/ou postérieure, ladite estimation se faisant uniquement à partir des macroblocs n'appartenant pas à ladite zone déplacée, ladite image courante à coder étant transmise d'un serveur vers un terminal client, le codage étant effectué au niveau du serveur et ledit vecteur réel d'au moins une zone déplacée de ladite image courante étant fourni par une interface de programmation de l'environnement graphique dudit serveur. Le procédé selon l'invention peut également présenter une ou plu-sieurs des caractéristiques ci-dessous, considérées individuellement ou selon toutes les combinaisons techniquement possibles : - ledit codage vidéo est un codage spatio-temporel H264 - l'écran dudit serveur est affiché par ledit terminal client sur un écran selon un protocole RFB Remote Frame Buffer tel que le protocole VNC Virtual Network Computing , - ledit vecteur de mouvement réel de ladite zone déplacée est déterminé dans les cas suivants : o défilement horizontal ou vertical de ladite zone déplacée avec une application du type navigateur ; o déplacement d'une fenêtre graphique du système d'exploitation dudit serveur ; o transition d'un transparent à un autre transparent dans le cas d'un diaporama ; o animation du type flash. - ledit terminal client est un décodeur vidéo ; - ladite image courante ainsi que ledit vecteur de mouvement réel sont initialement codées dans un format RGB puis subissent une transformation dans un format YUV. - ledit vecteur de mouvement réel est un vecteur à deux ou trois di- mensions. Brève description des figures D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence à la figure 1 annexée qui est une représenta- tion schématique simplifiée d'un système de codage selon l'invention pour la mise en oeuvre du procédé de codage selon l'invention. Description des formes de réalisation préférées de l'invention La figure 1 représente un système de codage 100 selon l'invention. Le système de codage 100 comporte : - un module 101 de réception de données d'entrées, - un module 102 de traitement des données d'entrées, - un module 105 d'estimation de mouvement (également appelé par la suite module d'estimation de vecteurs de mouvement), - un module 106 de compensation de mouvement, - un soustracteur 109 et un additionneur 110, - un module de transformée fréquentielle 112 et un module de transformée fréquentielle inverse 115, - un module de quantification 113 et un module de quantification in-verse 114, - un filtre 116, - une mémoire tampon 111, - un module de reordonnancement 108, - un codeur entropique 120. L'invention s'applique au domaine de la diffusion de données vidéo par un serveur vers un terminal client. Le serveur, généralement un ordinateur, est relié au terminal client, par exemple un décodeur vidéo, par un ré- seau, par exemple sous forme HDMI ( High Definition Multimedia Inter-face en anglais), WIFI ou ethernet. L'écran de l'ordinateur peut alors être affiché par le terminal client sur un écran de télévision selon un protocole de type Remote Frame Buffer , par exemple VNC ( Virtual Network Computing en anglais). Le serveur encode ce qu'il diffuse avant de l'envoyer au terminal client. L'encodage effectué par le serveur est un encodage du type spatio-temporel tel que H264 : c'est donc le serveur qui intègre le système de codage 100 selon l'invention. Le module de réception 101 reçoit en entrée une image prédictive Fn. Fn correspond à l'image courante de l'écran du serveur dans sa totalité. On notera que l'invention concerne uniquement le codage des images prédictives, le codage intra-prédictif des images I continuant à se faire selon des techniques connus. Ainsi, pour rendre le schéma plus clair, les moyens nécessaires au codage intra-prédictif ont été volontairement omis. L'image Fn se présente généralement dans un format YUV12 après avoir subi une transformation RGB û YUV. Le module de réception 101 reçoit également en entrée des informations sur les zones ayant subi un déplacement (dites aussi zone déplacées dans la suite de la description) dans l'image Fn. La zone déplacée est une zone rectangulaire généralement représentée par un quadruplet (x, y, I, h) : x et y représentent respectivement l'abscisse et l'ordonnée du point en haut à gauche de la zone, I représente la largeur du rectangle et h est la hauteur dudit rectangle. L'information reçue par le serveur concernant chaque zone déplacée est constituée par le vecteur de mouvement réel m = (mx, my)T de cette zone déplacée, mx et my étant les composantes horizontale et verticale du vecteur de mouvement réel et T désignant l'opérateur transposition. Typiquement, ce vecteur réel peut être obtenues par le serveur via les inter-faces de programmation de son environnement graphique, dites aussi API (Application Programming Interface) pour interface utilisateur graphique (ou GUI Graphical User Interface ) de l'application logicielle fonctionnant sur le serveur et utilisée par le terminal client ou du système d'exploitation (ou operating system en anglais) du serveur, WindowsTM par exemple. Ce vecteur de mouvement réel est connu de l'application logicielle puisque cette dernière est a l'initiative du déplacement de la zone suite a un événement (typiquement un événement engendré par un clic ou un mouvement souris ou une frappe clavier) de l'utilisateur final via le terminal client. Cependant afin d'avoir l'échelle de ce vecteur pour le calculer en nombre de pixels, il peut s'avérer nécessaire d'accéder aux API des cou- ches logicielles plus basses. C'est donc préférablement dans la couche du système d'exploitation (WindowsTM) que le système 100 s'appuiera pour récupérer le vecteur réel afin d'implémenter cet accélérateur logiciel d'encodage, indépendamment des applications qui en bénéficieront. A titre d'exemple, on peut ainsi faire appel à une fonction JavaScript du type win- dows.scrollby(x-coord, y-coord) de DOM Windows qui sera appelée lors de l'enclenchement sur le terminal client d'une touche flèche vers la bas : la fonction peut fournir le module du vecteur de mouvement : m = V(mx2 + my2 , la direction du vecteur étant verticale vers le bas. La taille du rectangle peut également être obtenue par des fonctions du type windows.innerHeight et windows.innerWidth . En tout état de cause, le serveur peut obtenir des valeurs caractérisant le vecteur de mouvement réel de la zone déplacée par l'utilisateur via le terminal client. Typiquement, on peut par exemple obtenir un tel vecteur de mauve- ment réel pour une zone subissant un déplacement dans le cadre d'application telle que : - un défilement (ou scrolling en anglais) horizontal ou vertical de la zone déplacée avec une application du type navigateur ou browser en anglais; - un déplacement d'une fenêtre graphique du système d'exploitation du serveur; - une transition d'un transparent à un autre transparent dans le cas d'un diaporama ( slideshow en anglais); - une animation du type flash ou silverlight. Le vecteur de mouvement m = (mx, my)T codé en format RGB est également transformé en format YUV12. Le module 102 de traitement des données d'entrée comporte : - des moyens 103 pour diviser l'image courante Fn en macroblocs, - des moyens 104 pour attribuer le vecteur de mouvement réel V aux macroblocs appartenant à la zone déplacée, - des moyens 118 pour transmettre le vecteur de mouvement réel di- rectement au module 106 de compensation sans estimation des vec- teurs de mouvements par le module 105 d'estimation, pour les ma- croblocs appartenant à la zone déplacée, - des moyens 119 pour transmettre uniquement les macroblocs n'appartenant pas à la zone déplacée vers le module 105 d'estimation de mouvement. On économise de la sorte toute une partie de calcul des vecteurs de mouvement pour les macroblocs auxquels le module 104 a déjà attribué un vecteur de mouvement réel de par leur appartenance à une zone déplacée.

Ainsi, chaque image courante Fn à encoder est divisée par les moyens 103 en macroblocs correspondant à une région élémentaire rectangulaire de l'image ayant une taille variable comprise entre 4x4 et 16x16 pixels (en passant par 8x16, 8x8,...). Les moyens 104 connaissant les zones déplacées de l'image Fn ainsi que leurs vecteurs de mouvement réels permettent d'attribuer aux macro- blocs appartenant à une zone déplacée un même vecteur de mouvement réel. Dès lors, les moyens 119 vont orienter uniquement les macroblocs non touchés par une zone déplacée vers le module d'estimation de mouvement 105, les vecteurs de mouvement réels des autres macroblocs étant transmis directement au module de compensation de mouvement 106 via les moyens 118. La fonction du module 105 d'estimation de mouvement est de retrou- ver un macrobloc de l'image courante Fn dans au moins une image Fn_1 précédente de l'écran du serveur dans sa totalité (il pourrait également s'agir d'une image postérieure dans le cas d'une image B et même d'une pluralité d'images antérieures et/ou postérieures). Lorsque l'on trouve une partie d'une image précédente qui ressemble (selon des critères de moindres car- rés par exemple) au macrobloc, on en déduit un vecteur de mouvement qui correspond à la différence entre la position de la région sélectionnée et celle du macrobloc. Les vecteurs de mouvement qui ont été retenus par le module d'estimation (en plus des vecteurs de mouvement réels transmis par les moyens 118) sont transmis vers le module 106 de compensation de mouvement. On obtient alors une erreur de prédiction due au fait qu la région retenue dans l'image passée n'est pas exactement égale au macrobloc analysé. On obtient en sortie du module de compensation de mouvement 106 une image prédite P.

Le soustracteur 109 calcule ensuite une erreur résiduelle Dn entre les pixels de Fn et l'image prédite P. On applique une transformée fréquentielle (du type transformée en cosinus discrète DCT Discrete Cosine Transform ou transformée d'Hadamard) via le module de transformée fréquentielle 112 sur chaque macrobloc ayant subi une estimation de mouvement ainsi que sur l'erreur résiduelle Dn. Cette transformée permet d'avoir une représentation fréquentielle des zones modifiées. Les données issues du module de transformée fréquentielle 112 sont ensuite quantifiées (i.e. codées sur un nombre limité de bits) par le module de quantification 113 pour fournir des paramètres transformés et quantifiés X. La fonction du module de quantification 113 est de définir des pas de quantification différents selon que certaines composantes seront jugées ou non significatives visuellement ; ces pas de quantification sont définis dans une table de pas de quantification. Le module 114 de quantification inverse récupère les paramètres transformés et quantifiés X qui traversent ensuite le module 115 de trans- formée fréquentielle inverse qui opère une transformée fréquentielle inverse pour récupérer une version quantifiée D'n de l'erreur résiduelle Dn ; cette version quantifiée D'n est alors ajoutée aux macroblocs de la zone prédite P par l'additionneur 110 ; l'image en sortie de l'additionneur 110 est alors traitée par le filtre de déblocage pour fournir une image reconstruite F'n correspon- dant à un ensemble de zones reconstruites ayant la même position, la même largeur et la même hauteur que les zones modifiées. F'n est utilisée en interne par le décodeur 100 pour estimer la qualité de l'encodage. Les résultats quantifiés X issus du module de quantification 113 sont alors réordonnés par le module de reordonnancement 108 pour grouper en- semble les coefficients non nuls de façon à permettre une représentation efficace des autres coefficients ayant une valeur nulle. Les données subissent alors une dernière phase de compression de codage entropique via le codeur entropique 120. La fonction du codeur en-tropique est de réencoder différemment les données afin de diminuer le nombre de bits nécessaires à leur encodage en s'approchant le plus possible du minimum de bits théoriques (qui est fixé par l'entropie). Le codeur entropique 120 construit un flux de sortie 4 dans un format NAL ( Network Abstraction Layer en anglais) définie pour permettre l'usage de la même syntaxe vidéo dans de nombreux environnements ré- seau. On notera que les moyens et modules décrits ci-dessus peuvent être soit logiciels soit réalisés avec des circuits électroniques spécifiques. Bien entendu, l'invention n'est pas limitée au mode de réalisation qui vient d'être décrit.

Notamment, l'invention a été plus particulièrement décrite dans le cadre du codage H264 mais elle s'applique à tout type de codage spatio-temporel : c'est par exemple le cas du codage MPEG2 ou du codage VC1 (norme de compression vidéo du SMPTE Society of Motion Picture and Television Engineers ). On notera en outre que le vecteur de mouvement a été décrit comme un vecteur à deux dimensions mais il est également possible d'utiliser un vecteur de mouvement à trois dimensions, par exemple dans le cas d'une interface graphique telle qu'AeroTM qui est l'interface graphique de Windows VistaTM permettant d'afficher des effets en 3D. Enfin, on pourra remplacer tout moyen par un moyen équivalent

Claims

REVENDICATIONS1. Système (100) de codage vidéo pour le codage d'images successives d'une séquence vidéo, le codage d'au moins une image courante (Fn) étant opéré relativement à au moins une image précédente et/ou postérieure (Fn_1) de ladite séquence vidéo, ledit système (100) de codage comportant : - un module (101) de réception de données d'entrées pour la réception de ladite image courante (Fn) à coder, - des moyens (103) pour diviser ladite image courante (Fn) en macro- blocs, - un module (105) d'estimation de vecteurs de mouvement en fonction des macroblocs de ladite image courante (Fn) et de ladite au moins une image précédente et/ou postérieure (Fn_1), - un module (106) de compensation de mouvement recevant des vec- teurs de mouvement et fournissant au moins une zone prédite (P), ledit système (100) de codage étant caractérisé en ce que ledit module (101) de réception de données reçoit en outre un vecteur de mouvement réel d'au moins une zone déplacée de ladite image courante (Fn), ledit système (100) de codage comportant : - des moyens (104) pour attribuer ledit vecteur de mouvement réel aux macroblocs appartenant à ladite zone déplacée ; - des moyens (118) pour transmettre ledit vecteur de mouvement réel directement au dit module (106) de compensation sans estimation des vecteurs de mouvements par ledit module (105) d'estimation pour lesdits macroblocs appartenant à ladite zone déplacée.
2. Système (100) de codage vidéo selon la revendication précédente caractérisé en ce qu'il comporte des moyens (119) pour transmettre uniquement les macroblocs n'appartenant pas à ladite zone déplacée vers ledit module (105) d'estimation de vecteurs de mouvement.
3. Système (100) de codage vidéo selon l'une des revendications précédentes caractérisé en ce qu'il comporte :- un soustracteur (109) pour effectuer la différence entre les pixels de l'image courante (Fn) et la zone prédite et fournissant une erreur résiduelle (Dn) correspondant à cette différence, - un module (112) de transformée fréquentielle appliquant une trans- formée fréquentielle sur chaque macrobloc traité par ledit module (105) d'estimation ainsi que sur ladite erreur résiduelle (Dn), - un module (113) de quantification des données issues dudit module (112) de transformée fréquentielle, - un codeur entropique (120) pour le codage des données issues dudit module (113) de quantification.
4. Procédé de codage vidéo pour le codage d'images successives d'une séquence vidéo, le codage d'au moins une image courante (Fn) étant opéré relativement à au moins une image précédente et/ou postérieure (Fn_1) de ladite séquence vidéo, ledit procédé comportant les étapes suivantes : - réception de ladite image courante (Fn) à coder et d'un vecteur de mouvement réel d'au moins une zone déplacée de ladite image cou- rante (Fn), - division de ladite image courante en macroblocs, - attribution dudit vecteur de mouvement réel aux macroblocs apparte- nant à ladite zone déplacée, - estimation de vecteurs de mouvement en fonction des macroblocs de ladite image courante et de ladite au moins une image précédente et/ou postérieure, ladite estimation se faisant uniquement à partir des macroblocs n'appartenant pas à ladite zone déplacée, ladite image courante à coder étant transmise d'un serveur vers un terminal client, le codage étant effectué au niveau du serveur et ledit vecteur réel d'au moins une zone déplacée de ladite image courante étant fourni par une interface de programmation de l'environnement graphique dudit serveur.
5. Procédé selon la revendication précédente caractérisé en ce que l'écran dudit serveur est affiché par ledit terminal client sur un écran selon un protocole RFB Remote Frame Buffer tel que le protocole VNC Virtual Network Computing .
6. Procédé selon l'une des revendications 4 ou 5 caractérisé en ce que ledit codage vidéo est un codage spatio-temporel H264
7. Procédé selon l'une des revendications 4 à 6 caractérisé en ce que ledit vecteur de mouvement réel de ladite zone déplacée est déterminé dans les cas suivants : - défilement horizontal ou vertical de ladite zone déplacée avec une application du type navigateur ; - déplacement d'une fenêtre graphique du système d'exploitation dudit serveur; - transition d'un transparent à un autre transparent dans le cas d'un diaporama ; - animation du type flash.
8. Procédé selon l'une des revendications 4 à 7 caractérisé en ce que ledit terminal client est un décodeur vidéo.
9. Procédé selon l'une des revendications 4 à 8 caractérisé en ce que ladite image courante ainsi que ledit vecteur de mouvement réel sont initialement codées dans un format RGB puis subissent une transformation dans un format YUV.
10. Procédé selon l'une des revendications 4 à 9 caractérisé en ce que ledit vecteur de mouvement réel est un vecteur à deux ou trois dimen- sions.