ŒUVRE DU PROCEDE

La présente invention se rapporte à un procédé d'encodage d'image et un dispositif pour la mise en œuvre de ce procédé. Elle s'applique notamment au codage d'images d'un flux vidéo.

Les données vidéo font en général l'objet d'un codage source visant à les compresser afin de limiter les ressources nécessaires à leur transmission et/ou à leur stockage. Il existe de nombreux standards de codage, tels que H.264/AVC, H.265/HEVC et MPEG-2, qui peuvent être utilisés à cette fin.

On considère un flux vidéo comprenant un ensemble d'images. Dans les schémas de codage classique, les images du flux vidéo à encoder sont typiquement considérées selon une séquence d'encodage, et chacune est divisée en ensembles de pixels eux aussi traités séquentiellement, par exemple en commençant en haut à gauche et en finissant en bas à droite de chaque image.

L'encodage d'une image du flux est ainsi effectué en divisant une matrice de pixels correspondant à l'image en plusieurs ensembles, par exemple des blocs de taille fixe 16 x 16, 32 x 32 ou 64 x 64 pixels, et en encodant ces blocs de pixels selon une séquence de traitement donnée. Certains standards, comme le H.264/AVC, prévoient la possibilité de décomposer des blocs de taille 16 x 16 pixels (appelés alors macro-blocs) en sous-blocs, par exemple de taille 8 x 8 ou 4 x 4, afin d'effectuer les traitements d'encodage avec une granularité plus fine. Le standard H.265/HEVC prévoit l'utilisation de blocs de taille fixe allant jusqu'à 64 x 64 pixels, ces blocs pouvant être partitionnés jusqu'à une taille minimale de 8 x 8 pixels.

Les techniques existantes de compression vidéo peuvent être divisées en deux grandes catégories : d'une part la compression dite « Intra », dans laquelle les traitements de compression sont effectuées sur les pixels d'une unique image ou trame vidéo, et d'autre part la compression dite « Inter », dans laquelle les traitements de compression sont effectuées sur plusieurs images ou trames vidéo. Dans le mode Intra, le traitement d'un bloc (ou ensemble) de pixels comprend typiquement une prédiction des pixels du bloc effectuée à l'aide de pixels causaux (précédemment codés) présents dans l'image en cours d'encodage (dite « image courante »), auquel cas on parle de « prédiction Intra ». Dans le mode Inter, le traitement d'un bloc (ou ensemble) de pixels comprend typiquement une prédiction des pixels du bloc effectuée à l'aide de pixels issus d'une ou de plusieurs images précédemment codées, auquel cas on parle de « prédiction Inter » ou de « compensation de mouvement » (en anglais « motion compensation »).

Ces deux types de codage sont utilisés au sein de schémas de codage dits « hybrides », qui sont spécifiés dans les codées vidéo existants (MPEG2, H.264/AVC, HEVC) et sont décrits pour le codée HEVC (High Efficiency Video Coding) dans l'article intitulé « Overview of the High Efficiency Video Coding (HEVC) Standard », par Gary J. Sullivan et al., IEEE Transactions on Circuits and Systems for Video Technology, vol. 22, No. 12, Dec. 2012.

Cette exploitation des redondances spatiales et/ou temporelles permet d'éviter de transmettre ou de stocker la valeur des pixels de chaque bloc (ou ensemble) de pixels, en représentant certains au moins des blocs par un résiduel de pixels représentant la différence (ou la distance) entre des valeurs de prédiction des pixels du bloc et les valeurs réelles des pixels du bloc prédit.

L'information des résiduels de pixels est présente dans les données générées par l'encodeur après transformée (par exemple, de type transformée en cosinus discrète, ou en anglais DCT, pour Discrète Cosine Transform) et quantification afin de réduire l'entropie des données générées par l'encodeur.

Il est souhaitable de réduire autant que possible les informations additionnelles générées par la prédiction des pixels et présentes en sortie de l'encodeur afin d'augmenter l'efficacité d'un schéma de codage/compression à un niveau de distorsion donné. A l'inverse, on peut aussi chercher à réduire ces informations additionnelles pour augmenter l'efficacité d'un schéma de codage/compression à un niveau de débit de sortie de l'encodeur donné.

Un encodeur vidéo effectue typiquement un choix de mode d'encodage correspondant à une sélection de paramètres d'encodage pour un ensemble de pixels traité. Cette prise de décision peut être implémentée en optimisant une métrique de débit et distorsion, les paramètres d'encodage sélectionnés par l'encodeur étant ceux qui minimisent un critère débit-distorsion. Le choix du mode d'encodage a alors un impact sur les performances de l'encodeur, à la fois en termes de gain de débit et de qualité visuelle.

L'implémentation d'un encodeur vidéo pour lequel des performances de traitement temps réel sont recherchées peut être effectuée sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array), ou bien sous forme d'une architecture matérielle dédiée, comme par exemple un composant ASIC (Application Spécifie Integrated Circuit). Les circuits logiques programmables de type FPGA (Field-Programmable Gâte Array) sont des circuits électroniques reconfigurables par l'utilisateur. Un ASIC est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée.

Un encodeur peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).

Un des avantages de la mise en œuvre d'un encodeur vidéo temps réel sur un composant de type FPGA tient dans la possibilité de concevoir l'implémentation des algorithmes de traitement de manière à ce que certains traitements soient effectués en parallèle. Les possibilités d'implémentation avec ce type d'optimisation sont moins présentes pour des implémentations d'encodeur vidéo temps réel sur des processeurs de traitement de signal (en anglais, « Digital Signal Processor », ou DSP), qui sont des composants génériques fonctionnant avec un code logiciel linéaire qui est déroulé séquentiellement lors de l'exécution sur le processeur DSP.

Les encodeurs vidéo implémentés sur un composant dédié sont néanmoins souvent limités, notamment ceux qui effectuent des traitements en parallèle, par la bande passante disponible pour le transfert de données entre le composant et une mémoire externe dans laquelle sont stockées les données du flux vidéo à encoder. Cette limitation est usuellement surmontée grâce à la mise en œuvre d'une mémoire cache implantée sur le composant, qui bénéficie ainsi d'une bande passante beaucoup plus importante que celle d'une mémoire externe.

L'utilisation d'un cache mémoire nécessite cependant d'adapter les algorithmes d'encodage qui font intervenir la mémoire cache, de manière à tirer au mieux parti des bénéfices que procure l'utilisation d'un cache pour réduire les temps de traitement tout en améliorant la qualité de compression du flux vidéo encodé.

Suivant le type de cache utilisé, les limitations imposées à l'encodeur sont diverses. Généralement, elles se traduisent par une limitation des algorithmes d'estimation de mouvement autorisés par l'encodeur.

Il existe ainsi un besoin pour un procédé d'encodage d'image utilisant une mémoire cache amélioré en termes d'accélération des temps de traitement et de qualité de compression.

Un objet de la présente invention est de proposer un procédé d'encodage d'image utilisant une mémoire cache amélioré en termes d'accélération des temps de traitement et de qualité de compression. Un autre objet de la présente invention est de proposer un procédé d'encodage d'image utilisant une mémoire cache amélioré en termes d'accélération des temps de traitement et de qualité de compression pour une implémentation temps-réel.

Un autre objet de la présente invention est de proposer un procédé d'encodage d'image utilisant une mémoire cache amélioré pour une implémentation temps-réel.

Selon un premier aspect, il est proposé un procédé d'encodage d'une première image dans un ensemble d'images, dans lequel la première image est découpée en blocs, chaque bloc étant encodé selon un parmi une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images de l'ensemble d'images, le procédé comprenant, pour un bloc courant de la première image : définir, dans une deuxième image de l'ensemble d'images distincte de la première image et précédemment codée selon une séquence prédéfinie d'encodage des images de l'ensemble d'images, une zone de recherche unitaire de vecteurs d'estimation de mouvement ; charger les données de la zone de recherche unitaire dans une mémoire cache ; déterminer, par une recherche dans la zone de recherche unitaire chargée en mémoire cache, un vecteur d'estimation de mouvement du bloc courant, le vecteur d'estimation de mouvement pointant sur un bloc de la zone de recherche corrélé au bloc courant ; et utiliser le vecteur d'estimation de mouvement pour décider de l'encodage du bloc courant selon l'un parmi la pluralité de modes de codage ; dans lequel la zone de recherche unitaire comprend un ensemble de données de la deuxième image comprenant les données d'un bloc de la deuxième image co-localisé avec le bloc courant, et dans lequel une portion au moins de la zone de recherche unitaire a sensiblement la forme d'une portion d'ovoïde.

Le procédé proposé permet d'optimiser la forme de la zone de recherche destinée à être chargée en mémoire cache, de manière à minimiser la quantité de données chargées en mémoire cache et non utilisées par des traitements ultérieurs, comme par exemple des traitements liés à l'estimation de mouvement ou la compensation de mouvement.

Dans un mode de réalisation du procédé proposé, la zone de recherche unitaire a sensiblement une forme d'ovoïde.

L'optimisation de la zone de recherche liée à la forme d'ovoïde peut en effet être avantageusement appliquée à la totalité de la zone de recherche, et non pas seulement à une portion de celle-ci. Dans un ou plusieurs mode de réalisation du procédé proposé, la zone de recherche unitaire peut aussi être déterminée de manière qu'une portion au moins de la zone de recherche unitaire a sensiblement la forme d'une portion d'ellipsoïde.

La forme ellipsoïdale permet en effet avantageusement d'augmenter l'excursion des composantes vectorielles sans complexification d'implémentation ni utilisation de ressources supplémentaires significatives.

Ce mode de réalisation du procédé proposé présente comme avantage d'augmenter, pour un même espace mémoire, l'excursion des composantes des vecteurs de mouvement, sans perte due, le cas échéant, à la forme de configuration des blocs du groupe de blocs d'encodage destinés à être encodés en parallèle.

Dans un mode de réalisation du procédé proposé, la zone de recherche unitaire pourra être déterminée ayant une forme sensiblement ellipsoïdale.

Dans un mode de réalisation du procédé proposé, la zone de recherche unitaire pourra être déterminée avec un contour qui définit un polygone de forme sensiblement elliptique.

Le procédé proposé peut en outre avantageusement être appliqué au cas d'un groupe de blocs d'encodage destinés à être encodés en parallèle, comme par exemple un groupe de 2, 3, ou 4 blocs d'encodage.

Dans un mode de réalisation du procédé proposé, on définit ainsi une zone de recherche multiple pour une pluralité de blocs d'encodage par réunion de zones de recherche unitaires correspondant respectivement aux blocs d'encodage de la pluralité de blocs d'encodage, on charge les données de la zone de recherche multiple dans la mémoire cache, on détermine, par une recherche dans la zone de recherche multiple chargée en mémoire cache, une pluralité de vecteurs d'estimation correspondant respectivement aux blocs d'encodage de la pluralité de blocs d'encodage, et on utilise les vecteurs d'estimation déterminés pour l'encodage des blocs d'encodage de la pluralité de blocs d'encodage.

Le procédé proposé peut en outre être adapté à différentes formes de configuration des blocs du groupe de blocs d'encodage destinés à être encodés en parallèle, comme par exemple la configuration MBAFF des encodeurs de type H.264 (en anglais, « Macroblock-Adaptive Frame/field Coding »).

Selon un deuxième aspect, il est proposé un dispositif d'encodage d'une première image dans un ensemble d'images, comprenant : une interface d'entrée configurée pour recevoir la première image ; une unité d'encodage vidéo, couplée de manière opérationnelle à l'interface d'entrée, et configurée pour encoder la première image en utilisant le procédé proposé.

Selon un autre aspect, il est proposé un programme d'ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre des étapes du procédé proposé lors de l'exécution dudit programme par le processeur, ainsi qu'un ensemble de données représentant, par exemple par voie de compression ou d'encodage, ledit programme d'ordinateur.

Un autre aspect concerne un support de stockage non-transitoire d'un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l'exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoire et à un module d'interface entrées/sorties, conduire l'ordinateur à encoder une première image dans un ensemble d'images selon le procédé proposé.

Le procédé proposé convient particulièrement bien, bien que de façon non exclusive, pour l'encodage ou la compression d'une image d'une séquence d'images selon un schéma du type H.264/AVC (Advanced Video Coding). Mais il convient aussi pour l'encodage d'images selon tout schéma d'encodage vidéo opérant sur des images découpées en blocs dans lequel les blocs sont encodés selon une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images du flux vidéo à encoder, comme par exemple un schéma d'encodage de type H.265/HEVC.

Le procédé proposé pourra avantageusement être mis en œuvre dans les cas où le mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images de l'ensemble d'images est de type utilisant une prédiction de mouvement à partir d'images précédemment codées (type de mode de codage référencé dans certains codeurs vidéo sous l'appellation « Inter ») ou de type utilisant un vecteur prédicteur prédéterminé sélectionné à partir de blocs voisins du bloc courant précédemment codés (types de mode de codage référencés dans certains codeurs vidéo sous les appellations « Skip » et « Merge »).

D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :

- La figure 1 est un schéma illustrant un encodeur de type H.264/AVC ; - La figure 2 est un schéma illustrant l'architecture d'un codeur pour la mise en œuvre du procédé proposé ;

- Les figures 3a, 3b, et 3c sont des schémas illustrant des modes de prédiction Intra ;

- La figure 4 est un schéma illustrant une détermination de vecteur médian pour le codage en mode de prédiction Inter ;

- La figure 5 est un schéma illustrant une architecture d'encodeur utilisant un composant FPGA et une mémoire externe ;

- La figure 6a est un schéma illustrant une position fractionnaire de pixel déterminée dans le cadre d'une prédiction Inter selon un mode de réalisation ;

- Les figures 6b et 6c sont des schémas illustrant un vecteur de mouvement candidat et un ensemble de vecteurs testés dans le cadre d'une prédiction Inter selon un mode de réalisation ;

- La figure 7 est un schéma illustrant une architecture d'encodeur pour la mise en œuvre du procédé proposé ;

- Les figures 8a, 8b, 8c, 8d, 8e, et 8f sont des schémas illustrant le chargement de données en mémoire cache pour l'encodage d'une paire de blocs d'encodage ;

- La figure 9a est un schéma illustrant le chargement de données en mémoire cache pour l'encodage d'un groupe de quatre blocs d'encodage ;

- Les figures 9b et 9c sont des schémas illustrant la configuration d'un groupe de quatre blocs d'encodage à encoder en parallèle ;

- Les figures 9d et 9e sont des schémas illustrant le chargement de données en mémoire cache pour l'encodage d'un groupe de quatre blocs d'encodage ;

- La figure 10 est un diagramme illustrant le procédé proposé selon un mode de mise en œuvre ;

- Les figures 1 1 a, 1 1 b, 1 1 c, 1 1d, 1 1 e, 1 1 f, 1 1 g, 1 1 h et 1 1 i sont des schémas illustrant différentes configurations de zones de recherche selon différents modes de mise en œuvre.

Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l'homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d'autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la description.

Dans ce qui suit, on utilise indifféremment les termes « pixel » et

« échantillon » pour désigner un élément d'une image numérique.

Le procédé proposé peut être mis en œuvre par tout type d'encodeur d'image d'un ensemble d'images, comme par exemple un codée vidéo conforme aux standards H.264/AVC, H.265/HEVC, et/ou MPEG-2.

En particulier, les différents modes de réalisation décrits ci-après pour un encodeur de type H.264/AVC utilisant des macro-blocs (MB) de taille 16x16 pixels peuvent être adaptés à un encodeur de type H.265/HEVC en remplaçant les MB16x16 par des blocs de type CTB16, CTB32 et CTB64, de tailles respectives 16x16, 32x32 et 64x64, définis par la norme HEVC.

La figure 1 illustre un exemple d'architecture d'encodeur (10) de type

H.264/AVC.

Un flux F d'images à encoder (F _n ) est fourni en entrée de l'encodeur (10). Chaque image F _n (1 1 ) du flux d'entrée est découpée en macro-blocs de taille 16x16 pixels, pour être encodée selon une séquence prédéterminée d'encodage des macro-blocs, par exemple de haut en bas et de gauche à droite.

Les macro-blocs sont prédits à l'aide de pixels causaux (précédemment codés) présents dans l'image courante (prédiction « Intra »), ou bien à l'aide de pixels issus d'une ou plusieurs images précédemment codées (prédiction « Inter »). Cette exploitation des redondances spatiales et temporelles permet de représenter les unités de codage par un résiduel de pixels le plus faible possible qui est alors transmis au décodeur, éventuellement après transformée et quantification.

Chaque macro-bloc à encoder est fourni en entrée d'une unité d'estimation de mouvement (12) (« ME », pour « Motion Estimation »), qui génère des données relatives au mouvement du bloc en cours d'encodage par rapport à une ou plusieurs images précédemment encodées F' _n _ ₁ (13), communément appelées images de référence, qui sont aussi fournies en entrée de l'unité d'estimation de mouvement (12). Les données de mouvement produites par l'unité d'estimation de mouvement sont fournies à une unité de compensation de mouvement (14) (ou prédiction de type Inter) (« MC », pour « Motion Compensation »), qui reçoit en outre en entrée la ou les images de référence utilisées par l'unité d'estimation de mouvement (12). L'unité de compensation de mouvement (14) génère des données de prédiction Inter, qui sont fournies à une unité de prise de décision d'encodage (15).

Les données du bloc à encoder sont par ailleurs fournies à une unité de choix de prédiction Intra (16) qui évalue différents blocs voisins du bloc à encoder dans l'image courante dans le cadre de la prédiction Intra. L'unité de choix de prédiction Intra (16) génère en entrée d'une unité de prédiction Intra (17) des données d'un ou de plusieurs blocs voisins du bloc courant (en cours d'encodage) pour la prédiction Intra, et l'unité de prédiction Intra (17) produit en retour des données de prédiction Intra, qui sont fournies à l'unité de prise de décision d'encodage (15), qui sélectionne une prédiction de type Inter ou une prédiction de type Intra en fonction des données de prédiction reçues pour ces deux modes. L'unité de choix de prédiction Intra (16) ainsi que l'unité de prédiction Intra (17) reçoivent en entrée des données d'images encodées uF' _n .

Une détermination (18) de résiduel D _n est effectuée à partir des données de l'image courante (pour le bloc courant) F _n et les données de prédiction sélectionnées par l'unité de prise de décision d'encodage (15). Ce résiduel de pixels est ensuite traité par transformation (T) (19) et quantification (Q) (20), et les données quantifiées (X) sont encodées par encodage entropique (21 ) pour générer un flux encodé (NAL).

Une boucle de reconstruction d'images à partir des données d'encodage récupère les données quantifiées (X) pour les traiter par des opérations inverse de quantification (Q ^"1 ) (22) et de transformée (T ¹ ) (23). Une opération inverse (24) de celle de détermination de résiduel est en outre appliquée pour reconstruire des blocs déjà encodés uF' _n , et qui serviront aux unités de prédiction Intra pour fournir des données de blocs voisins du bloc en cours d'encodage. Ces données seront ensuite filtrées (25) pour la reconstruction d'images entières (26) F' _n , qui fourniront les images de référence pour les unités de prédiction Inter.

Dans l'architecture d'un encodeur illustrée par la figure 2, les images sont considérées séquentiellement et divisées en ensembles de pixels traités séquentiellement en commençant en haut à gauche et en finissant en bas à droite. Ces ensembles de pixels sont dénommés « unités de codage » dans le standard HEVC, et sont de taille maximale 64 x 64 pixels, les unités de codage de cette taille étant appelés « Large Coding Units », ou « LCU ». Ces ensembles de pixels sont prédits à l'aide de pixels causaux (précédemment codés) présents dans l'image courante (prédiction « Intra »), ou bien à l'aide de pixels issus d'une ou plusieurs images précédemment codées (prédiction « Inter »). Cette exploitation des redondances spatiales et temporelles permet de représenter les unités de codage par un résiduel de pixels le plus faible possible qui est alors transmis au décodeur, éventuellement après transformée et quantification.

En référence à la figure 2, l'encodeur 100 reçoit en entrée 109 un flux vidéo d'entrée 101 comprenant une pluralité d'images à traiter pour effectuer l'encodage du flux. L'encodeur 100 comprend un contrôleur 102, couplé de manière opérationnelle à l'interface d'entrée 109, qui pilote une unité de pré-estimation de mouvement (PRE-ME) 1 12, une unité d'estimation de mouvement (ME) 1 10 et une unité de prédiction par compensation de mouvement (MC) 104 pour les prédictions de types Inter, Merge et/ou Skip (décrites ci-dessous), ainsi qu'une unité de prédiction de mode Intra 103. Les données reçues sur l'interface d'entrée 109 sont transmises en entrée des unités de prédiction de mode Intra 103, de pré-estimation de mouvement 1 12, et du contrôleur 102. L'ensemble contrôleur 102, unité d'estimation de mouvement 1 10, unité de prédiction 104 pour les prédictions Inter, Merge et Skip, et unité de prédiction de mode Intra 103 forme une unité d'encodage 1 1 1 couplée de manière opérationnelle à l'interface d'entrée 109. L'unité d'encodage 1 1 1 est en outre couplée de manière opérationnelle à une unité de mémoire 1 13, par exemple de type RAM, par le biais du contrôleur 102 sur l'exemple illustré par la figure 2.

L'unité de prédiction de mode Intra 103 génère des données de prédiction Intra 107 qui sont fournies en entrée d'un codeur entropique 105. L'unité de préestimation de mouvement 1 12 génère, pour un bloc d'encodage, une liste de vecteurs candidats potentiels pour la décision Inter, fournie à l'unité d'estimation de mouvement 1 10. L'unité d'estimation de mouvement 1 10 et l'unité de prédiction des modes Inter/Merge/Skip 104 réalisent un affinage des vecteurs candidats potentiels puis sélectionnent un meilleur candidat. L'unité de prédiction de modes Inter/Merge/Skip 104 génère des données 106 de prédiction Inter, Merge ou Skip qui sont fournies en entrée du codeur entropique 105. Par exemple, les données fournies au décodeur pour une prédiction de type Inter peuvent comprendre un résiduel de pixels et des informations concernant un ou plusieurs vecteurs de mouvement. Ces informations relatives à un ou plusieurs vecteurs de mouvement peuvent comprendre un ou plusieurs indices identifiant un vecteur prédicteur dans une liste de vecteurs prédicteurs connue du décodeur. Les données fournies au décodeur pour une prédiction de type Skip ne comporteront typiquement pas de résiduel de pixels, et pourront aussi comprendre des informations identifiant un vecteur prédicteur dans une liste de prédicteurs connue du décodeur. La liste de vecteurs prédicteurs utilisée pour le codage de type Inter ne sera pas nécessairement identique à la liste de vecteurs prédicteurs utilisée pour le codage de type Skip. Le contrôleur 102 génère des données de contrôle 108 qui sont aussi fournies en entrée du codeur entropique 105.

Le contrôleur 102 est configuré pour piloter l'unité de prédiction de mode Intra 103 et l'unité de prédiction de modes Inter/Merge/Skip 104 afin de contrôler les données de prédiction qui sont respectivement fournies en entrée du codeur entropique 105 par l'unité de prédiction de mode Intra 103 et l'unité de prédiction de modes Inter/Merge/Skip 104. En fonction du schéma d'encodage mis en œuvre par l'encodeur 100, le contrôleur 102 peut en outre être configuré pour sélectionner parmi les différents types de mode de prédiction (mode Intra, mode Inter, mode Merge ou mode Skip en fonction des modes de codage implémentés dans l'unité d'encodage 1 1 1 ) celui pour lequel des données de prédiction seront transmises au codeur entropique 105. Ainsi, le schéma d'encodage peut comprendre une décision pour chaque bloc d'encodage traité visant à choisir le type de prédiction pour lequel des données seront transmises au codeur entropique 105. Ce choix sera typiquement mis en œuvre par le contrôleur, pour décider de l'application du mode de prédiction Inter, du mode de prédiction Intra, du mode de prédiction Merge ou du mode de prédiction Skip au bloc (ou à l'unité de codage) en cours de traitement. Cela permet de commander l'envoi au codeur entropique de données de prédiction Intra 107 ou bien de données de prédiction Inter, Merge ou Skip 106 en fonction de la décision prise par le contrôleur 102.

L'encodeur 100 peut être un ordinateur, un réseau d'ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc. En fonction du mode de réalisation, la mémoire, l'unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 102, amènent ce contrôleur 102 à effectuer ou contrôler les parties interface d'entrée 109, prédiction en mode Intra 103, prédiction en mode Inter/Merge/Skip 104, pré-estimation de mouvement 1 12, estimation de mouvement 1 10 et/ou traitement de données des exemples de mise en œuvre du procédé proposé décrits dans les présentes. Le contrôleur 102 peut être un composant implémentant un processeur ou une unité de calcul pour l'encodage d'images selon le procédé proposé et le contrôle des unités 109, 1 10, 1 12, 103, 104, 105 de l'encodeur 100.

L'encodeur 100 peut être mis en œuvre sous forme logicielle, comme décrit ci-dessus, auquel cas il prend la forme d'un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). Les SOC (System On Chip) ou systèmes sur puce sont des systèmes embarqués qui intègrent tous les composants d'un système électronique dans une puce unique.

Un encodeur peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).

L'image en cours de traitement est divisée en blocs d'encodage ou unités de codage (en anglais « Coding Unit », ou CU), dont la forme et la taille sont déterminées en fonction notamment de la taille de la matrice de pixels représentant l'image, par exemple en macroblocs de forme carrée de 16 x 16 pixels. On forme ainsi un ensemble de blocs pour lequel on définit une séquence de traitement (aussi appelé « parcours de traitement »). Dans le cas de blocs de forme carrée, on peut par exemple traiter les blocs de l'image courante en commençant par celui situé en haut à gauche de l'image, suivi de celui immédiatement à droite du précédent, jusqu'à arriver à la fin de la première ligne de blocs pour passer au bloc le plus à gauche dans la ligne de blocs immédiatement en-dessous de cette première ligne, pour terminer le traitement par le bloc le plus en bas et à droite de l'image.

On considère ainsi un « bloc courant » (parfois dénommé « bloc d'origine »), c'est-à-dire un bloc d'encodage en cours de traitement dans l'image courante. Le traitement du bloc courant peut comprendre le partitionnement du bloc en sous-blocs, afin de traiter le bloc avec une granularité spatiale plus fine que celle obtenue avec le bloc. Le traitement d'un bloc comprend par ailleurs la prédiction des pixels du bloc, en exploitant la corrélation spatiale (dans la même image) ou temporelle (dans une ou plusieurs autres images précédemment codées) entre les pixels. Lorsque plusieurs types de prédiction, comme par exemple une prédiction de type Intra, une prédiction de type Inter, une prédiction de type Merge et/ou une prédiction de type skip sont implémentés dans l'encodeur, la prédiction des pixels du bloc comprend typiquement la sélection d'un type de prédiction du bloc et d'informations de prédiction correspondants au type sélectionné, l'ensemble formant un jeu de paramètres d'encodage.

La prédiction du bloc de pixels traité permet de calculer un résiduel de pixels, qui correspond à l'écart entre les pixels du bloc courant et les pixels du bloc de prédiction, et est transmis dans certains cas au décodeur après transformée et quantification.

Pour coder un bloc courant, plusieurs modes de codage sont ainsi possibles et il est nécessaire d'inclure dans les données générées par l'encodage des informations de codage 106-108 signalant le choix de mode de codage qui a été effectué lors de l'encodage et selon lequel les données ont été encodées. Ces informations de codage 106-108 peuvent comprendre notamment le mode de codage (par exemple le type particulier de codage prédictif parmi les codages « Intra » et « Inter », ou parmi les codages « Intra », « Inter », « Merge » et « Skip » décrits ci-après), le partitionnement (dans le cas d'un ou plusieurs blocs partitionnés en sous-blocs), ainsi qu'une information de mouvement 106 dans le cas d'un codage prédictif de type « Inter », « Merge » ou « Skip » et un mode de prédiction Intra 107 dans le cas d'un codage prédictif de type « Intra ». Pour les modes de codage « Inter », « Skip » et « Merge », ces deux dernières informations peuvent elles aussi être prédites afin de réduire leur coût de codage, par exemple en exploitant les informations des blocs voisins du bloc courant.

Le standard HEVC utilise une structure de codage en quadtree, décrite ci- après, combinée à une sélection dynamique de taille principale de bloc. HEVC autorise un partitionnement de chaque image courante en blocs de taille allant de 64 x 64 pixels à 8 x 8 pixels. Le flux vidéo à encoder peut ainsi être parcouru avec des blocs de 64 x 64, chaque bloc de taille 64 x 64 pouvant être découpé en blocs de taille plus petite (le découpage le plus fin autorisé étant celui en 8 x 8 blocs, chacun de taille 8 x 8 pixels). L'encodeur choisit typiquement la taille des blocs utilisés selon des critères propriétaires qui ne sont pas définis par le standard.

L'encodeur vidéo peut par ailleurs utiliser une représentation de type YCbCr de l'espace colorimétrique des signaux vidéo avec un échantillonnage qui peut être de type 4:2:2 ou 4:2:0 (sous-échantillonnage des couleurs). Le signal vidéo à encoder porte une information de luminance (signal Y) et deux informations de chrominance (signaux Cb et Cr). Les échantillons de chaque composante (Y, Cb, Cr) peuvent être codés sur 8 bits, 10 bits ou plus.

En échantillonnage de type 4:2:2, une zone de taille H x L pixels (ou échantillons) de luminance est de taille H/2 x L pour chaque composante de chrominance, ce qui revient à effectuer un sous-échantillonnage des couleurs dans la direction horizontale seulement. La représentation de type 4:2:2 correspond au format de signal dit SDI (en anglais, System Deployment Image).

En échantillonnage de type 4:2:0, une zone de taille H x L pixels (ou échantillons) de luminance est de taille H/2 x L/2 pour chaque composante de chrominance, ce qui revient à effectuer un sous-échantillonnage des couleurs dans la direction horizontale et dans la direction verticale.

On décrit ci-après des exemples de modes de prédiction « Intra », « Inter », « Merge », et « skip », afin de faciliter la compréhension de la mise en œuvre du procédé proposé pour un codage vidéo utilisant ces modes de prédiction.

Comme indiqué ci-dessus, le codage prédictif en mode « Intra » inclut une prédiction des pixels d'un bloc (ou ensemble) de pixels en cours de traitement à l'aide des pixels précédemment codés de l'image courante. Il existe différents modes de codage prédictif de type « Intra », dont certains sont décrits ci-après :

Dans le mode de prédiction « Intra » dit « DC » (pour « Discrète Continuous »), on utilise les valeurs des pixels voisins du bloc courant appartenant à des blocs qui ont été précédemment codés, et on calcule une moyenne des valeurs de ces pixels voisins. Le bloc prédictif est construit en utilisant pour chaque pixel la valeur moyenne obtenue.

Par exemple, si l'on considère un bloc 200 de 8x8 pixels tel que celui illustré sur la figure 3a, on utilise les deux ensembles de 8 pixels voisins 201 , 202 du bloc voisin disposé à gauche du bloc courant et du bloc voisin disposé au- dessus du bloc courant. On calcule une valeur moyenne M des valeurs de ces 16 pixels, que l'on utilise pour remplir les valeurs des pixels du bloc prédictif 200.

Dans le mode de prédiction « Intra » dit « V » (pour « Vertical »), on utilise les valeurs des pixels voisins du bloc courant appartenant à au bloc voisin disposé au-dessus du bloc courant, lorsque ces pixels voisins ont été précédemment codés, et on recopie la valeur de chaque pixel voisin pour les pixels de la colonne correspondante dans le bloc prédictif.

Par exemple, si l'on considère un bloc 210 de 8x8 pixels tel que celui illustré sur la figure 3b, on utilise par exemple l'ensemble de 8 pixels voisins 21 1 du bloc voisin disposé à gauche du bloc courant, dans le cas où le parcours de codage des blocs est tel que ce bloc a déjà été codé. On recopie la valeur de chacun des 8 pixels voisins dans la colonne correspondante du bloc prédictif 210.

Dans le mode de prédiction « Intra » dit « H » (pour « Horizontal »), on utilise les valeurs des pixels voisins du bloc courant appartenant à au bloc voisin disposé à gauche ou à droite du bloc courant, lorsque ces pixels voisins ont été précédemment codés, et on recopie la valeur de chaque pixel voisin pour les pixels de la ligne correspondante dans le bloc prédictif.

Dans le mode de prédiction « Intra » dit « VL » (pour « Vertical-Left »), on utilise les valeurs des pixels voisins du bloc courant appartenant au bloc voisin disposé immédiatement au-dessus et au-dessus à droite du bloc courant, lorsque ces pixels voisins ont été précédemment codés, et on recopie la valeur de chaque pixel voisin pour les pixels de la colonne correspondante dans le bloc prédictif.

Par exemple, si l'on considère un bloc 220 de 8x8 pixels tel que celui illustré sur la figure 3c, on utilise par exemple l'ensemble de 8 pixels voisins 221 des deux blocs voisins disposés respectivement immédiatement au-dessus et au- dessus sur la droite du bloc courant, dans le cas où le parcours de codage des blocs est tel que ces blocs voisins, ou au moins les pixels voisins considérés, ont déjà été codés. On recopie la valeur de chacun des 8 pixels voisins dans la colonne correspondante du bloc prédictif 220 selon une direction de projection diagonale gauche comme illustré sur la figure 3c.

Le standard de codage vidéo H.264/AVC prévoit 9 modes de prédiction Intra (dont les modes de prédiction DC, H, V, VL décrits ci-dessus). Le standard de codage vidéo HEVC prévoit quant à lui un nombre plus important de 35 modes de prédiction Intra pour les échantillons de luminance, et 5 modes pour les échantillons de chrominance.

Ces standards de codage vidéo prévoient par ailleurs des cas particuliers pour effectuer une prédiction intra. Par exemple, le standard H.264/AVC autorise le découpage de blocs de 16x16 pixels en blocs plus petits, dont la taille peut aller jusqu'à 4x4 pixels, afin d'augmenter la granularité du traitement de codage prédictif.

Comme indiqué ci-dessus, l'information du mode de prédiction Intra est prédite afin de réduire son coût de codage. En effet, la transmission dans le flux encodé d'un index identifiant le mode de prédiction Intra présente un coût d'autant plus élevé que le nombre des modes de prédiction utilisables est important. Même dans le cas du codage H.264/AVC, la transmission d'un index entre 1 et 9 identifiant le mode de prédiction Intra utilisé pour chaque bloc parmi les 9 modes possibles s'avère être chère en termes de coût de codage. Le standard HEVC prévoit la détermination d'au plus trois modes Intra prédits. Si l'encodeur prend une décision d'encodage utilisant l'un de ces modes, seul une information relative à son index (parfois noté « mpm_index ») et à un indicateur indiquant que l'un des modes prédits a été choisi est transmise par l'encodeur. Autrement, l'encodeur transmet une information relative à un écart avec les modes prédits (parfois noté « rem_intra_pred_mode »).

On calcule ainsi un mode le plus probable, noté MPM (en anglais « Most Probable Mode »), qui est utilisé pour coder sur un minimum de bits le mode de prédiction Intra le plus probable. Le MPM est le résultat de la prédiction du mode de prédiction Intra utilisé pour coder le bloc courant.

Lorsque le mode Intra est sélectionné pour l'encodage du bloc courant, on pourra transmettre au décodeur typiquement un ensemble de coefficients correspondant au résiduel de pixels transformé et quantifié et le MPM.

Le codage prédictif de type à prédiction par corrélation temporelle référencé pour certains codeurs vidéo sous l'appellation « Inter » inclut une prédiction des pixels d'un bloc (ou ensemble) de pixels en cours de traitement à l'aide de pixels issus d'une ou de plusieurs images précédemment codées (pixels qui ne sont donc pas issus de l'image courante, au contraire du mode de prédiction Intra).

Le mode de prédiction Inter utilise typiquement un ou deux ensembles de pixels respectivement situés dans une ou deux images précédemment codées afin de prédire les pixels du bloc courant. Cela dit, on peut envisager pour un mode de prédiction Inter l'utilisation de plus de deux ensembles de pixels situés respectivement dans des images précédemment codées distinctes deux-à-deux et dont le nombre est supérieur à deux. Cette technique, appelée compensation de mouvement, fait intervenir la détermination d'un ou de deux vecteurs, dits vecteurs de mouvement, qui indiquent respectivement la position de l'ensemble ou des ensembles de pixels à utiliser pour la prédiction dans l'image ou les images précédemment codées (usuellement dénommées « images de référence »). En référence à la figure 2, les vecteurs utilisés pour le mode « Inter » sont à choisir par l'encodeur 100 par le biais de l'unité de pré-estimation de mouvement 1 12, de l'unité d'estimation de mouvement 1 10 et de l'unité de prédiction des modes Inter/Merge/Skip 104. La mise en œuvre de l'estimation de mouvement au sein de l'encodeur 100 pourra donc prévoir, selon les cas, la détermination d'un seul vecteur d'estimation de mouvement, de deux vecteurs d'estimation de mouvement, voire plus, qui pointent vers des images différentes. Le ou les vecteurs d'estimation de mouvement générés en sortie de l'unité d'estimation de mouvement 1 10 seront fournis à l'unité de prédiction des modes Inter/Merge/Skip 104 pour la génération de vecteurs de prédiction Inter. Chaque vecteur de prédiction Inter pourra en effet être généré à partir d'un vecteur d'estimation de mouvement correspondant.

On décrit ci-après plus en détails l'estimation de mouvement pour un bloc courant selon des modes de réalisation.

L'estimation de mouvement peut consister à étudier le déplacement des blocs entre deux images en exploitant la corrélation temporelle entre les pixels, Pour un bloc donné dans l'image courante (le « bloc courant » ou « bloc d'origine »), l'estimation de mouvement permet de sélectionner un bloc le plus ressemblant (dénommé « bloc de référence ») dans une image précédemment codée, dite « image de référence », en représentant le mouvement de ce bloc par exemple avec un vecteur à deux dimensions (et donc deux composantes représentant par exemple respectivement un déplacement horizontal et un déplacement vertical).

Le procédé d'estimation de mouvement est non normatif et est donc susceptible de différer d'un encodeur à un autre.

Par exemple, le procédé d'estimation de mouvement pourra comprendre la recherche dans une zone plus ou moins étendue de l'image de référence, par exemple définie à partir du bloc de l'image de référence correspondant au bloc d'origine dans l'image d'origine, afin de tester la ressemblance du bloc d'origine avec un nombre plus ou moins grand de blocs candidats de l'image de référence.

La corrélation entre un bloc et son déplacement selon un vecteur d'estimation de mouvement peut être calculée à l'aide de la Somme des Différences Absolues (SAD) :

SAD =∑ _x ∑ _y \p _xy - _V ' _xy \ (1 )

où p xy est le pixel à la position (x, y)du bloc d'origine et p xy le pixel à la position (x, y) du bloc de référence. Une SAD faible sera interprétée comme une indication que les deux blocs sont très ressemblants.

Le vecteur issu de l'estimation de mouvement, correspondant au bloc de l'image de référence le plus proche du bloc d'origine parmi les blocs candidats testés dans l'image de référence, pourra servir de base à la détermination d'un vecteur de prédiction Inter. En effet, selon les implémentations, le procédé de prédiction Inter pourra inclure des optimisations visant à sélectionner un vecteur distinct du vecteur issu de l'estimation de mouvement, afin d'avoir une prédiction la moins coûteuse possible pour le mode qui est testé.

Cette optimisation peut par exemple comprendre le test d'un ou de plusieurs vecteurs autour du vecteur issu de l'estimation de mouvement susceptibles de donner un meilleur résultat en fonction de l'objectif poursuivi. Dès lors, le vecteur utilisé pour la prédiction Inter eu égard à une image de référence donnée ne sera pas nécessairement identique au vecteur issu de l'estimation de mouvement pour cette image de référence.

Lorsque le mode Inter est sélectionné pour l'encodage du bloc courant, on pourra transmettre au décodeur typiquement le résiduel de pixels (calculé pour chaque vecteur de prédiction Inter en fonction des pixels du bloc courant et des pixels du bloc vers lequel pointe le vecteur de prédiction Inter considéré) et des informations concernant le ou les vecteurs de prédiction Inter correspondant.

Cependant, le ou les vecteurs de prédiction Inter peuvent représenter un coût important dans les encodeurs vidéo. Certains encodeurs réduisent ce coût de codage en exploitant les vecteurs des blocs voisins du bloc en cours d'encodage. Cette optimisation fait intervenir une prédiction du/des vecteurs de prédiction Inter, à l'instar de la prédiction du mode de prédiction Intra dans le cas d'un codage prédictif du bloc en mode Intra.

Comme indiqué ci-dessus, les informations concernant chaque vecteur de prédiction Inter pourront ainsi être réduites en taille en transmettant, à la place des coordonnées du vecteur par exemple, un indice d'un vecteur prédicteur dans un dictionnaire connu de l'encodeur et du décodeur, et un résiduel quantifiant la distance entre le vecteur de prédiction et le vecteur prédicteur.

Par exemple, dans les codeurs de type H.264/AVC, un vecteur prédicteur médian mv _pred est utilisé pour prédire le vecteur à coder mv.

επιν ^{= mv} ~ ^mv pred (2)

Seul le résiduel e _mv est transmis dans le flux encodé, de manière à fortement réduire les coûts de codage.

Le principe utilisé dans le standard HEVC est similaire en ce qu'il prévoit la transmission d'un résiduel de vecteur e _mv , qui n'est cependant pas calculé en utilisant un vecteur prédit médian. La norme précise en fait une méthode de calcul d'un ensemble de vecteurs prédits. L'encodeur choisit ensuite un prédicteur parmi ces vecteurs prédits possibles. Il peut donc transmettre, avec le résiduel vecteur, un numéro d'indice du vecteur prédicteur retenu, afin que le décodeur puisse utiliser le même.

La technique de prédiction bidirectionnelle fait typiquement intervenir une moyenne pondérée de deux prédictions de type Inter. L'encodeur choisit un ensemble de paramètres de prédiction pour une « direction » (pour une première image de référence), puis pour une deuxième « direction » (pour une deuxième image de référence, distincte de la première image de référence). L'encodeur détermine ensuite s'il retient une seule des deux directions ou les deux, auquel cas une moyenne des deux prédictions générées est déterminée avant de calculer un résiduel de pixels correspondant, qui sera éventuellement traité par transformation et quantification.

La prédiction bidirectionnelle correspond donc dans son principe à une prédiction de type « Inter » avec deux vecteurs prédits. Il en résulte que les aspects du procédé proposé concernant la prédiction Inter sont applicables à la prédiction bidirectionnelle.

La figure 4 illustre la détermination d'un vecteur prédicteur correspondant dans l'exemple illustré au médian entre les vecteurs de blocs voisins précédemment codés. En référence à la figure 4, le bloc courant (en cours d'encodage) 241 est entouré de quatre blocs voisins 243a, 243b, 243c, 243d précédemment encodés et de trois blocs voisins 243a, 243b, 243c restant à coder.

L'exemple présenté suppose un parcours d'encodage des blocs de l'image tel que, pour chaque bloc en cours d'encodage, les blocs situés à gauche ou au- dessus du bloc courant ont déjà été encodé, de sorte que, sur la figure 4, les blocs voisins 243a, 243b, 243c, 243d précédemment encodés sont situés à gauche 243a ou au-dessus 243b, 243c, 243d du bloc courant 241 . Le vecteur prédicteur mv _pred 244 du bloc courant 241 correspond au médian entre les vecteurs respectifs 245a, 245b, 245c, 245d des blocs précédemment codés 243a, 243b, 243c ou 243a, 243b, 243d lorsque le bloc 243c n'est par exemple pas disponible (par exemple dans le cas où le bloc 243c est encodé selon un codage prédictif en mode Intra). Un mauvais vecteur prédicteur résultera en un surcoût de codage pour le bloc courant 241 . Dans un autre cas particulier où uniquement un ou deux blocs voisins sont codés en mode Inter, les standards H.264/AVC et HEVC prévoient des règles permettant d'utiliser un des vecteurs disponibles dans la mesure où le médian n'est pas calculable.

Certains codeurs utilisent, parfois dans le cadre du mode de prédiction « Inter », un mode référencé dans certains codeurs video sous l'appellation « Skip » dans lequel, comme dans le cas du mode Inter, le bloc courant est prédit à l'aide de pixels issus d'images précédemment codées (une ou deux images, voire plus en fonction de l'implémentation). Le mode Skip est d'ailleurs parfois présenté comme un sous-mode du mode Inter, du fait qu'il correspond à un mode de prédiction « Inter » sans transmission (ou génération dans le flux encodé) de vecteur de prédiction ni de résiduel de pixels.

Le mode Skip trouve à s'appliquer lorsque le résiduel de pixels est suffisamment faible pour qu'il soit considéré inutile de le transmettre dans le flux de sortie du codeur.

D'autre part, dans une optique de réduction maximale du coût de codage, le ou les vecteurs de prédiction utilisés pour ce mode ne seront typiquement pas transmis au décodeur, et seront déduits par le décodeur à partir d'une liste prédéterminée de vecteurs possibles (appelés, de même que pour le mode « Inter », « vecteurs prédicteurs »), ce qui permettra par exemple de transmettre seulement la position du vecteur prédicteur (par exemple un indice de position dans la liste des vecteurs prédicteurs) au lieu de transmettre sa valeur (comme par exemple ses coordonnées). Ainsi, par exemple, dans ce mode de codage, on sélectionne directement un vecteur prédicteur dans une liste prédéterminée connue du décodeur, la sélection du vecteur prédicteur s'effectuant à partir de blocs voisins du bloc courant qui ont été précédemment codés. Comme indiqué ci- dessus, dans les cas où les modes Skip et Inter mis en œuvre dans le codeur utilisent l'un et l'autre une liste de vecteurs prédicteurs, les listes respectives de vecteurs prédicteurs, que ce soit de par leurs tailles ou de par leurs contenus respectifs, ne seront pas nécessairement identiques.

Le standard HEVC prévoit un autre mode de codage prédictif, dit « Merge », similaire au mode Skip décrit ci-dessus à la différence près que l'on pourra transmettre un résiduel de pixels. Le mode Merge peut ainsi lui aussi correspondre à un mode de prédiction Inter, sans transmission (ou génération dans le flux encodé) de vecteur de prédiction, mais dans lequel un résiduel de pixel et généré et transmis dans le flux encodé.

Dans l'architecture matérielle d'un encodeur à base de FPGA, les images de référence sont généralement stockées dans une mémoire importante en profondeur, afin de stocker un ensemble de plusieurs images. Par exemple, le stockage de 10 images au format HD 1920x1080 pixels avec un échantillonnage de type 4:2:2 sous 8 bits requiert un espace de stockage de taille 40 Mo. Les mémoires utilisées pour ce stockage présentent en général des performances moyennes en termes de bande passante. Celle-ci est typiquement de l'ordre de 2 Go/s dans le cas d'un boîtier de mémoire vive SDRAM de type DDR3-1333. Par exemple, avec une efficacité de lecture à 70% pour des quantités importantes de données en rafale, on obtient une bande passante de 1333333333 Hz x 16 bits x 0,7, soit 1 ,7 Go/s.

La figure 5 illustre une architecture matérielle de ce type, dans laquelle un encodeur 400 implémenté sur un composant 402 de type FPGA stocke dans une mémoire RAM 401 des images de référence. Par exemple, pour l'encodage de l'image F _n d'un flux vidéo d'entrée F, l'encodeur pourra effectuer une phase d'estimation de mouvement dans le cadre d'une prédiction de type Inter, Skip ou Merge, qui nécessitera la lecture dans la mémoire RAM de stockage 401 de données de référence (notées F^). Une fois les traitements relatifs à la prédiction Inter effectués, l'encodeur pourra consigner dans la mémoire RAM 401 des données (notées F^) de l'image encodée reconstruite à partir de la décision prise, pour utilisation lors de l'encodage des images suivantes dans le flux vidéo. L'encodeur 400 pourra donc être muni d'une unité d'estimation de mouvements (ME) 403 et d'une unité de compensation de mouvement (MC) 404, l'unité d'estimation de mouvements 403 pouvant par ailleurs être configurée pour effectuer des traitements sur des données générées par une unité de pré-estimation de mouvements 405, par exemple des données 406 relatives à des vecteurs de mouvement candidats comme expliqué ci-dessus en référence à la figure 2.

La quantité de données de référence (F^) nécessaires aux fonctions de l'unité d'estimation de mouvements (ME) 403 et de l'unité de compensation de mouvement (MC) 404 de l'encodeur 400 peut s'avérer suffisamment importante pour qu'il soit envisagé d'utiliser un système de cache, notamment pour atteindre les performances requises dans le cadre d'une implémentation matérielle de traitement temps-réel.

En fonction de l'implémentation, cette quantité de données peut être significativement plus importante que la quantité de données correspondant à une image simple, du fait notamment du nombre de vecteurs candidats testés, de l'augmentation de la zone de pixels nécessaire à l'affinage des candidats (partie ME des traitements), et de l'augmentation de la zone de pixels nécessaire au calcul de la prédiction Inter (partie MC des traitements).

On considère ci-après ces trois causes de la forte augmentation des données de référence :

La zone nécessaire au calcul de la prédiction inter d'un bloc d'encodage (par exemple un macro-bloc) est égale à la taille de ce bloc augmentée de deux couronnes, dont l'une est nécessaire à l'interpolation au quart de pixel, et l'autre est nécessaire à l'excursion de l'estimation de mouvement. En effet, en fonction de l'implémentation de l'encodage vidéo, les vecteurs de mouvement peuvent être déterminés avec une précision fractionnaire du pixel, en ce qu'un vecteur de mouvement peut pointer vers un élément de pixel fractionnaire généré entre deux pixels voisins. Dans ce cas, des échantillons fractionnaires seront générés entre deux échantillons voisins, par exemple par interpolation entre ces deux échantillons. C'est le cas du standard HEVC, qui prévoit la génération d'échantillons de luminance fractionnaires en définissant un filtre interpolateur à 8 coefficients pour les positions des demi-échantillons (ou demi-pixels) et un filtre interpolateur à 7 coefficients pour les positions des quarts d'échantillon (ou quarts de pixel). Le standard HEVC permet ainsi la génération de vecteurs de mouvement avec une précision égale au quart de la distance entre deux échantillons de luminance.

L'utilisation de vecteurs de mouvement pointant sur une image de référence avec une précision sous-pixellique conduit donc à interpoler les pixels de l'image de référence originale, ce qui augmente la quantité de données correspondant à cette image. Par exemple, pour calculer une prédiction inter d'un macro-bloc de taille 16 pixel x 16 pixel, qui correspond à un vecteur de mouvement avec une précision au quart de pixel, il peut s'avérer nécessaire de disposer d'une zone de l'image de référence de taille 19 x 19 pixels : une couronne de 3 pixels est utilisée dans le calcul d'une image au demi-pixel, le calcul de l'image au quart de pixel étant réalisé en interpolant l'image au demi-pixel. Cet accroissement de la quantité de données représentant une image de référence peut ainsi résulter de l'utilisation de filtres interpolateurs pour calculer les demi-pixels (HPELs) et, éventuellement les quarts de pixels (QPELs), en fonction de la profondeur de la granularité souhaitée.

On pourra par exemple, en fonction de l'implémentation, utiliser un filtrage à 5 coefficients pour calculer un demi-pixel. Il faudra donc connaître les valeurs de 5 pixels pour mettre en œuvre le filtrage interpolateur à 5 coefficients. La figure 6a illustre ce calcul, et montre 5 pixels 601 a - 601 e d'une image de référence 600. Les pixels 601 d et 601 e appartiennent à un bloc d'encodage 602 en cours d'encodage par prédiction Inter. En utilisant un filtre d'interpolation à 5 coefficients, le calcul du demi pixel 603 entre les pixels 601 d et 601 e pourra utiliser en fonction de l'implémentation les valeurs des 5 pixels 601 a - 601 e.

Par ailleurs, comme expliqué ci-dessus, la fonction d'estimation de mouvement peut comprendre, en fonction de l'implémentation, le test d'un ensemble de vecteurs proches d'un vecteur initial, appelé vecteur candidat, et le choix parmi les vecteurs testés d'un vecteur minimisant une fonction de corrélation (souvent de type SAD ou SSD) entre le bloc de prédiction et le bloc à encoder. Dans une implémentation utilisant une unité de pré-estimation de mouvement, cette opération réalise un affinage de vecteurs candidats identifiés par la fonction de pré- estimation de mouvement.

Cet ensemble de vecteurs de test augmente la zone de référence nécessaire à la décision d'encodage pour le mode Inter. La figure 6c illustre cette augmentation en montrant un ensemble couvrant une zone de 5 x 5 pixels qui demande au final (lorsque l'on prend en compte une couronne nécessaire à l'interpolation au quart de pixel) une zone de 21 x 21 pixels.

La figure 6b montre une image de référence 605 sur laquelle est représentée le bloc 606 co-localisé dans l'image de référence 605 avec le bloc d'encodage en cours d'encodage dans l'image courante. Un vecteur candidat 608 pointe vers un pixel (demi-pixel ou quart de pixel selon la granularité choisie) de l'image de référence 605, et un ensemble 607 de vecteurs testés pointent respectivement vers des pixels (demi-pixels ou quart de pixels selon la granularité choisie) de l'image de référence 605.

La figure 6c montre l'extrémité du vecteur candidat 606, et le pixel 608 vers lequel ce vecteur 606 pointe, ainsi que deux vecteurs tests 607a et 607b et les pixels 609a et 609b vers lesquels ces vecteurs 607a et 607b pointent respectivement. En fonction de l'implémentation de la fonction d'affinage de l'estimation de mouvement, l'ensemble des pixels vers lesquels les vecteurs de test pointent respectivement (dénommés « pixels vecteurs testés » sur la figure 6c) devra être inclus dans les données de l'image de référence récupérées de la mémoire RAM pour les besoins des traitements de la prédiction Inter.

Certains standard d'encodage, comme les standards H.264/AVC et H.265/HEVC, autorisent le partitionnement d'un bloc à encoder pour découper la prédiction Inter en plusieurs zones ayant chacune un vecteur spécifique. Ceci permet une meilleure correspondance du macro-block à encoder avec l'image de référence, notamment sur des frontières d'objet ayant des mouvements différents.

Ce partitionnement augmente cependant d'autant le nombre de vecteurs candidat que l'on peut souhaiter tester dans l'encodeur pour un bloc d'encodage, et par là même la quantité de donnée nécessaire à la décision de la prédiction Inter d'un bloc d'encodage.

Cette quantité de donnée est d'autant plus importante qu'il y a de partitions.

Par exemple, le partitionnement d'un bloc de 16 pixels x 16 pixels en quatre partitions 8 pixels x 8 pixels nécessite quatre zones de 13 pixels x 13 pixels, soit une surface totale de 52 pixels x 52 pixels.

La norme H.264 permet plusieurs partitionnements d'un macro-bloc de 16 pixels x 16 pixels, jusqu'à un partitionnement en blocs de 4 pixels x 4 pixels.

On peut également prendre en compte la possibilité, prévue dans certains standards (comme les standards H.264/AVC et H.265/HEVC), de réaliser des prédictions inter bidirectionnelles qui sont une pondération de deux prédictions Inter calculées sur deux images de référence différentes, comme décrit ci-dessus.

Enfin, on peut aussi tenir compte de l'augmentation de la quantité de données nécessaires à la décision de la prédiction Inter due à l'alignement en mémoire externe qui n'est (en fonction de l'implémentation) pas toujours accessible au pixel près. Typiquement il augmente la couronne de 3 pixels (on arrive ainsi à une couronne de 8 pixels : 3 + 2 + 3).

Le tableau suivant détaille la quantité de données à lire pour réaliser la décision inter dans le cas de 4 partitionnements (16x16, 8x16, 16x8, 8x8) pour deux références (L0 et L1 ), uniquement pour la composante luminance (Y). On arrive ainsi à un ratio de x 24 en lecture par macro-bloc pour le cas H.264/AVC, comme le montre le tableau suivant (les dimensions des partitions et zones sont exprimées en nombre de pixels):

Avec ce ratio on obtient, pour un encodage 1080p60, une quantité de données qui dépasse les capacités d'un boîtier mémoire de type DDR3-1333 (1 ,7 Go/s à 70% d'efficacité). Quand on considère également la lecture de la chrominance et la nécessité d'écriture des images de référence, amplifiées par le fait que les accès « aléatoires » envisagés plus haut, dus au partitionnement des zones à charger et à leur alignement au pixel, dégrade les performances en lecture (fermeture et ouverture de page), on voit qu'il est nécessaire d'avoir un système qui minimise ces accès à la RAM externe sans dégrader la qualité de la décision.

L'utilisation d'une mémoire cache, c'est-à-dire d'un espace mémoire, souvent interne au composant, par exemple ASIC ou FPGA, sur lequel est implémenté l'encodeur vidéo, ayant une bande passante en lecture beaucoup plus efficace que celle d'une mémoire externe, permet de pallier à ce problème de limitation de bande passante d'une mémoire externe.

Par exemple, on peut implémenter une mémoire cache au sein d'un composant FPGA de type Stratix-lll d'Altera (EP3SL340) en utilisant 32 mémoires internes de type M144K pouvant chacune contenir 2048 mots de 72 bits. En utilisant pour la sortie de ce cache un bus de 16 x 8 pixels à 133 MHz, on obtient une bande passante de l'ordre de 16 Go/s, c'est-à-dire une amélioration d'un facteur égal à 9 par rapport à une mémoire externe telle que celle décrite ci-dessus.

La figure 7 montre une mise en œuvre de l'encodeur implémenté sur un composant FPGA illustré par la figure 4 en utilisant une mémoire cache au sein de l'unité de décision de prédiction Inter. Un encodeur 700 est implémenté sur un composant 702 de type FPGA, et stocke dans une mémoire RAM 701 externe au composant FPGA 702 des images de référence F'. Pour l'encodage d'une image F _n d'un flux vidéo d'entrée F, l'encodeur 700 pourra effectuer une phase d'estimation de mouvement dans le cadre d'une prédiction de type Inter, Skip ou Merge, et lire pour ce faire dans une mémoire cache 707 implémentée sur le composant FPGA 702 (et non pas dans la mémoire RAM de stockage 701 comme dans l'architecture illustrée sur la figure 4) des données de référence (notées F^). Une fois les traitements relatifs à la prédiction Inter effectués, l'encodeur 700 pourra consigner dans la mémoire RAM externe 701 des données (notées F^) de l'image encodée reconstruite à partir de la décision prise, pour utilisation lors de l'encodage des images suivantes dans le flux vidéo. L'encodeur 700 pourra donc être muni d'une unité d'estimation de mouvements (ME) 703 et d'une unité de compensation de mouvement (MC) 704, configurées pour lire des données de référence dans une mémoire cache locale 707 plutôt que dans une mémoire externe 701 . L'unité d'estimation de mouvements 703 pourra par ailleurs être configurée pour effectuer des traitements sur des données générées par une unité de pré-estimation de mouvements 705, par exemple des données 706 relatives à des vecteurs de mouvement candidats comme expliqué ci-dessus en référence à la figure 2.

Dans un ou plusieurs modes de réalisation, le type de cache et son efficacité, ainsi que sa complexité de mise en œuvre, seront de préférence choisis en fonction de la cohérence des différentes zones nécessaires aux traitements d'estimation de mouvement et de compensation de mouvement.

Différents types de cache peuvent en effet être envisagés. Dans les caches de type « Hit-Miss », les données recherchées seront obtenues rapidement si elles se trouvent déjà dans le cache (cas de « hit »), ou bien devront être recherchées dans la mémoire externe puis stockées dans le cache (cas d'un « miss »). Le temps de latence pour l'obtention des données sera donc variable selon que les données recherchées se trouvent déjà dans le cache ou non.

Dans les caches dits « systématiques », les données nécessaires au traitement d'encodage d'un bloc seront préchargées dans le cache pour le macrobloc en cours de traitement. En particulier, une zone autour du bloc co- localisé dans l'image de référence au bloc en cours d'encodage pourra être préchargée dans le cache.

Dans l'exemple d'un encodeur vidéo implémenté sur un composant FPGA de manière à effectuer en parallèle l'encodage de plusieurs blocs, l'utilisation d'un cache systématique pourra être préférée à celle d'un cache Hit-Miss, du fait que le cache systématique permet d'obtenir un temps de latence pour l'obtention des données quasiment invariable pendant les traitements d'encodage de plusieurs blocs en parallèle.

Dans un ou plusieurs modes de réalisation, on considérera donc une zone de recherche bornée, destinée à être pré-chargée dans un cache, définie suivant le parcours d'encodage des blocs à encoder.

Deux facteurs pourront être pris en compte pour définir la quantité de données à pré-charger en mémoire cache : d'une part, la hauteur de la zone de recherche, qui sera liée à la composante verticale maximale autorisée pour les vecteurs de ME et de MC, et d'autre part, le nombre de blocs à traiter simultanément, c'est-à-dire en parallèle.

Les figures 8a et 8b illustrent ces deux facteurs et montrent le cas de deux blocs encodés en parallèle à des instants ΤΊ et T ₂ d'encodage distincts et pour lesquels il est nécessaire de charger préalablement à leur traitement en mémoire cache une zone de recherche couvrant les données nécessaires au traitement des deux blocs.

La figure 8a montre la zone de recherche 801 de données d'une image de référence 800 qu'il est possible de pré-charger en mémoire cache au regard de la taille de celle-ci pour les deux blocs 802 et 803 correspondant à deux blocs de l'image courante à encoder en parallèle, et la figure 8b montre la zone de recherche 804 de données de l'image de référence 800 à pré-charger en mémoire cache pour les deux blocs 805 et 806 correspondant à deux blocs de l'image courante à encoder en parallèle après les deux blocs 802 et 803 (dans l'hypothèse d'un parcours d'encodage de blocs allant de gauche à droite et de haut en bas, comme indiqué par la flèche noire sur les figures 8a et 8b). Les zones de recherche 801 et 804 à charger en mémoire cache sont définies autour de blocs de l'image de référence co-localisés avec les blocs à encoder en parallèle.

Lorsque la taille des blocs d'encodage est fixe, comme c'est le cas des macro-blocs du standard d'encodage vidéo H.264, les données de l'image de référence pourront être regroupées en lignes virtuelles, de hauteur celle d'un bloc, comme illustré sur les figures 8a à 8f qui montrent une image de référence 800 comprenant 8 lignes virtuelles. Bien entendu, en fonction du mode de réalisation et notamment de la taille des images à encoder ainsi que des différentes tailles possibles des blocs à encoder, les lignes virtuelles pourront avoir des hauteurs différentes, et les images à encoder un nombre de lignes virtuelles différent de celui illustré par les figures 8a à 8f, qui montrent un exemple de mise en œuvre du procédé proposé.

Les figures 8c - 8f illustrent le chargement en mémoire cache de données d'une image de référence 800 pour différentes paires de blocs encodés en parallèle.

La figure 8c montre deux blocs 807 et 808 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés dans la partie supérieure de l'image courante (première et deuxième lignes vituelles). La taille de la zone de recherche 809 à charger en mémoire cache est telle que l'encodage de deux lignes virtuelles de l'image courante conduit au chargement en mémoire cache de 4 lignes virtuelles de l'image de référence.

La figure 8d illustre le chargement en mémoire cache de 6 lignes virtuelles pour l'encodage de deux blocs 810 et 81 1 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés sur les troisième et quatrième lignes virtuelles de l'image courante.

La figure 8e illustre le chargement en mémoire cache de 6 lignes virtuelles pour l'encodage de deux blocs 812 et 813 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés sur les cinquième et sixième lignes virtuelles de l'image courante.

La figure 8f illustre le chargement en mémoire cache de 4 lignes virtuelles pour l'encodage de deux blocs 814 et 815 co-localisés dans l'image de référence 800 avec des blocs à encoder en parallèle situés sur les septième et huitième lignes virtuelles de l'image courante.

Ainsi, la quantité de données chargées en mémoire cache pour l'encodage de l'ensemble des blocs d'une image courante, l'encodage étant effectué en parallèle pour des ensembles de deux blocs, correspondra à 20 fois la largeur d'une image de référence de hauteur égale à 8 lignes virtuelles, la hauteur d'une ligne virtuelle correspondant à celle d'un bloc à encoder, comme le montre la formule suivante :

Largeur_Image_Référence x (4 + 6 + 6 + 4) = 20 x Largeur_Image_Référence La taille de l'image de référence considérée dans les exemples illustrés sur les figures 8a à 8f étant de Largeur_Image_Référence x 8, l'encodage des blocs d'une image courante conduit à lire 2,5 fois les données de l'image de référence.

Le tableau suivant présente le cas de l'encodage d'une image 1080p60, avec une zone de recherche correspondant à une excursion verticale de 96 pixels (soit 6 blocs d'encodage de taille 16x16 pixels), l'encodage étant effectué avec un traitement en parallèle de 4 blocs d'encodage :

Le tableau utilise les acronymes et notations suivants : MB : Macrobloc, ZR : Zone de recherche, // : parallèle, et Y : position verticale (exprimée en nombre de MB).

On constate que l'image de référence est lue 3,76 fois. Si on prend en compte deux références, pour les prédictions bidirectionnelles, on arrive à une quantité de données équivalente à 7,5 images, soit un gain de 3,6 par rapport aux 27 images du tableau de la Figure 1 1 . Ces 7,5 images représentent 0.88 Go/s pour un frame rate de 60 images par seconde, en ne considérant que la luminance, et un débit de 1 .76 Go/s en considérant aussi la chrominance.

Il y a donc un gain certain en bande passante par rapport à un accès direct et « aléatoire » à une mémoire externe, avec comme contrainte une limitation des composantes vectorielles du mouvement codé.

Le procédé proposé décrit ci-après permet de réduire l'impact de cette limitation sans complication d'implémentation ni ressource supplémentaire.

La zone de recherche habituellement utilisée dans les implémentations d'encodeur utilisant une mémoire cache dans laquelle sont pré-chargées les données d'une zone de recherche de vecteurs d'estimation de mouvement est une zone de forme carrée ou plus généralement rectangulaire, pour mieux refléter l'aspect ratio de l'image de référence.

Par exemple, avec 32 mémoires de type M144K (ce qui correspond à 66% des mémoires M144K d'un composant Stratix-3 EP3SL340 d'Altera), utilisées en 16k x 8 bits, c'est-à-dire pour stocker 2 ¹⁴ mots (2 ¹⁴ = 16384), chacun de taille 8 bits, on dispose de 512k x 8 bits = 512k pixels (avec un échantillonnage de la luminance et de la chrominance de type 4:2:2), soit 2 ¹⁹ pixels, ce qui correspond à 1024 blocs d'encodage de taille 16x16 pixels (512k pixels / (16 x 16 x 2) = 1024 blocs 16 x 16 Y-UV, pour un bloc d'encodage comprenant les composantes Y et UV, soit 16x16 Y + 8x16 U + 8x16 V en échantillonnage 4:2:2). Pour une implémentation effectuant en parallèle l'encodage de 4 blocs d'encodage et une excursion verticale des vecteurs de 6 blocs d'encodage, on obtient une zone de recherche de 64 MB x 16 MB pour une unique image de référence, et de 32 MB x 16 MB pour deux images de référence dans le cas d'une prédiction bidirectionnelle, la taille de la zone de recherche étant définie en macro-blocs (MB), par exemple de taille 16x16 pixels pour la composante Y de luminance, la taille des composantes chrominance U et V dépendant de l'échantillonnage de ces composantes.

En référence à la figure 9a, en considérant qu'il faut une colonne de blocs d'encodage pré-chargés pour ne pas bloquer le flot de traitement aval, on obtient pour l'exemple décrit ci-dessus une excursion des composantes vectorielles (sans tenir compte des réductions dues aux couronnes décrites plus haut) de 15 MB x 6 MB, soit +/- 240 pixels x +/- 96 pixels. En effet, pour traiter en parallèle les blocs 901 , 902, 903 et 904, il est souhaitable de disposer de la zone de recherche non grisée sur la figure 9a. Si l'algorithme d'encodage attend la fin du traitement de ces quatre blocs pour libérer la colonne à l'extrémité gauche de la zone de recherche, et charger la colonne 905 pour passer au traitement des quatre blocs de droite adjacents aux quatre blocs en cours d'encodage, le chargement de la colonne 905 générera un temps mort dans les traitements. Dans un ou plusieurs modes de réalisation, on pourra pré-charger la colonne 905 afin d'éviter cette rupture de traitement.

La figure 9a montre une zone de recherche 900 destinée à être chargée dans une mémoire cache, de forme rectangulaire et définie autour de quatre blocs 901 - 904 correspondant dans une image de référence aux blocs co-localisés avec quatre blocs d'une image courante en cours d'encodage en parallèle. L'excursion horizontale des composantes des vecteurs de mouvement correspond, avec les paramètres décrits ci-dessus et correspondant à un mode de réalisation particulier, à un espace mémoire cache de 15 MB, ou à 15 blocs de largeur, tandis que l'excursion verticale des composantes des vecteurs de mouvement correspond, avec les paramètres décrits ci-dessus, à un espace mémoire cache de 6 MB, ou à 6 blocs de hauteur ( soit 6 x 16 = 96 pixels). Une colonne de blocs d'encodage supplémentaire 905 peut en outre être pré-chargée afin de ne pas bloquer le flot de traitement aval comme indiqué ci-dessus.

La zone de recherche 900 occupe un espace mémoire de 32 x 16 MB, soit

512 MB, qui correspond à l'espace mémoire disponible pour une implémentation de la mémoire cache utilisant 32 mémoires de type M144K du composant Stratix-3 EP3SL340 d'Altera (comme indiqué ci-dessus) et mettant en œuvre le chargement en mémoire cache de deux zones de recherche correspondant respectivement à deux images de référence pour une prédiction à corrélation temporelle de type bidirectionnelle (par exemple une prédiction Inter bidirectionnelle).

L'adressage de cette mémoire est peu complexe puisqu'il suffit d'ajouter un offset sur la position x du bloc souhaité, offset en fonction du « ruban » en cours de traitement (le « ruban » correspondant à l'ensemble des lignes auxquelles appartiennent les blocs en cours de traitement), de prendre les 5 bits LSB de ce résultat et de les combiner au 4 bits LSB de la position y du bloc demandé, pour obtenir une adresse sur 9 bits (512 MB).

La configuration des blocs d'encodage en cours d'encodage en parallèle illustrée sur la figure 9a par le groupe de quatre blocs 901 - 904 de l'image de référence respectivement co-localisés avec des blocs d'encodage de l'image courante, peut être avantageusement remplacée par une configuration dite « en escalier », et illustrée sur la figure 9b, afin de tenir compte de dépendances d'encodage pour chacun des blocs en cours d'encodage.

En effet, comme indiqué ci-dessus, la prédiction d'un bloc selon le mode de prédiction Intra ou le mode de prédiction Inter peut faire intervenir des blocs voisins dans l'image courante du bloc d'encodage qui ont déjà été encodés. Pour la prédiction Inter, on pourra, en fonction du mode de réalisation, chercher à prédire le vecteur d'estimation de mouvement en utilisant les vecteurs déterminés pour les blocs voisins, le cas échéant, du fait qu'ils sont déjà encodés. Pour la prédiction Intra, on pourra, en fonction du mode de réalisation, prédire les pixels du bloc en cours d'encodage (bloc courant) en fonction des pixels d'un ou de plusieurs blocs voisins. La définition de ces blocs voisins pourra donc dépendre du parcours d'encodage choisi pour les blocs de l'image.

La configuration en escalier illustrée sur les figures 9b, 9c et 9d est fournie à titre d'exemple de configuration d'une pluralité de blocs destinés à être encodés en parallèle (ou de blocs correspondants respectivement co-localisés dans une image de référence), et positionnés les uns par rapport aux autres de manière à ce qu'aucun des blocs de la configuration ne corresponde à un bloc voisin d'un autre bloc de la configuration utilisable pour l'encodage de cet autre bloc, en fonction du parcours d'encodage choisi pour les blocs de l'image en cours d'encodage. D'autres configurations en escalier peuvent bien entendu être utilisées pour la mise en œuvre du procédé proposé.

La figure 9c illustre un bloc d'encodage 906 en cours d'encodage (bloc courant) avec quatre blocs voisins 907 - 910 situés au voisinage immédiat du bloc courant 906. Les quatre blocs voisins sont définis en fonction du parcours d'encodage des blocs de l'image 91 1 en cours d'encodage, qui dans l'exemple illustré évolue de gauche à droite et de haut en bas. Dans cet exemple de configuration, le bloc 912, situé immédiatement en-dessous et à gauche du bloc voisin 910 situé immédiatement à gauche du bloc courant 906, est un bloc qui peut être encodé en parallèle avec le bloc courant 906.

L'utilisation d'une configuration d'un groupe de blocs à encoder en parallèle de type en escalier telle que celle illustrée sur le figures 9b et 9c entraîne une réduction de l'excursion des composantes vectorielles dans la zone de recherche correspondante à pré-charger en mémoire cache.

Par exemple, comme illustré sur la figure 9d, la zone de recherche 900 illustrée sur la figure 9a (excursion horizontale de 15 MB et excursion verticale de 6 MB) se trouve réduite à une excursion horizontale de 12 MB du fait du passage d'une configuration verticale des blocs à encoder en parallèle à une configuration de type en escalier, configuration reflétée sur celle de blocs correspondants 901 - 904 respectivement co-localisés dans une image de référence.

De plus, en fonction du mode de réalisation, la gestion des bords d'image peut être effectuée par duplication des données ou bien par l'utilisation d'une logique dédiée. La duplication des données présente l'avantage d'éviter le coût d'implémentation d'une logique dédiée à la gestion des bords de l'image à encoder.

La duplication des données pour la gestion des bords d'image peut conduire par exemple à la définition d'une zone de recherche telle que celle illustrée sur la figure 9e.

La figure 9e montre une zone de recherche 915 de forme rectangulaire destinée à être pré-chargée dans une mémoire cache afin d'accélérer les traitements liés à une prédiction par corrélation temporelle de quatre blocs à encoder en parallèle positionnés selon une configuration en escalier. Cette configuration en escalier se retrouve sur les quatre blocs correspondants 901 - 904 respectivement co-localisés dans une image de référence illustrés sur la figure 9e. Une ligne de blocs 913 et une colonne de blocs 914 sont en outre recopiés en mémoire cache pour la gestion des bords de l'image de référence. L'excursion des composantes vectorielles du mouvement codé est limitée à +/- 160 pixels pour la composante horizontale, ce qui correspond à une occupation mémoire cache de 2 x 10 MB, et à +/- 96 pixels pour la composante verticale, ce qui correspond à une occupation mémoire cache de 2 x 6 MB.

La zone de recherche 915 inclut en outre deux colonnes de blocs préchargées 916a - 916b afin de ne pas bloquer le flot de traitement aval.

Au total, la zone de recherche 915 illustrée sur la figure 9e utilise 17 x 30

MB, c'est-à-dire 510 MB, sur les 512 MB disponibles dans une implémentation de la mémoire cache utilisant 32 mémoires de type M144K du composant Stratix-3 EP3SL340 d'Altera (comme indiqué ci-dessus) et mettant en œuvre le chargement en mémoire cache de deux zones de recherche correspondant respectivement à deux images de référence pour une prédiction à corrélation temporelle de type bidirectionnelle (par exemple une prédiction Inter bidirectionnelle).

Les inventeurs du procédé proposé ont remarqué que les données des ensembles de blocs 917 et 918 respectivement situés dans les parties inférieure droite et supérieure gauche de la zone de recherche 915, n'étaient pas utilisées par les traitements liés à l'estimation de mouvement ou la compensation de mouvement. Le procédé proposé permet de remédier à cet inconvénient en optimisant la forme de la zone de recherche destinée à être chargée en mémoire cache, de manière à minimiser la quantité de données chargées en mémoire cache et non utilisées par les traitements ultérieurs liés à l'estimation de mouvement ou la compensation de mouvement.

De plus, le procédé proposé permet avantageusement d'augmenter l'excursion des composantes vectorielles sans complexification d'implémentation ni utilisation de ressources supplémentaires significatives.

La figure 10 est un diagramme illustrant le procédé proposé selon un mode de réalisation.

On envisage une première image d'un ensemble d'images d'une séquence vidéo.

Cette première image est découpée en blocs sur lesquels les traitements d'encodage de l'image sont appliqués. Chaque bloc est ainsi encodé, selon un parmi une pluralité de modes de codage comprenant au moins un mode de codage de type à prédiction par corrélation temporelle utilisant une pluralité d'images de l'ensemble d'images, comme par exemple les prédictions de type Inter, Merge, et Skip décrits ci-dessus.

Pour un bloc courant (en cours d'encodage) de la première image (1001 ), on définit (1002) une zone de recherche dans une image de référence pour la recherche de vecteurs d'estimation de mouvement du bloc courant, dont au moins une portion a sensiblement la forme d'une portion d'ovoïde. L'image de référence utilisée est choisie distincte de l'image en cours d'encodage (première image), et a été précédemment encodée selon une séquence d'encodage des images de l'ensemble d'images.

La zone de recherche ainsi définie est unitaire en ce sens qu'elle est définie pour un bloc d'encodage en cours d'encodage.

Les données de la zone de recherche sont ensuite chargées (1003) dans une mémoire cache, puis un vecteur d'estimation de mouvement pointant sur un bloc de la zone de recherche corrélé au bloc courant est déterminé (1004) en effectuant une recherche dans la zone de recherche chargée en mémoire cache.

Une décision d'encodage du bloc courant selon l'un des modes de codage est ensuite prise (1005) en utilisant le vecteur d'estimation de mouvement.

Le procédé proposé utilise ainsi une zone de recherche qui n'est pas définie avec une forme rectangulaire ou carrée.

La zone de recherche carrée, et son équivalent rectangulaire pour suivre l'aspect ratio de l'image, correspond à l'utilisation de la norme vectorielle infinie pour la délimitation d'une zone de recherche. Par norme vectorielle infinie, on entend une norme vectorielle définie par la relation suivante : || _∞ = max(v _x , v _y ), où v _x et v _y sont deux composantes du vecteur v, de norme infinie || _∞ .

L'utilisation d'une forme ovoïde permet entre autres d'éviter le chargement en mémoire cache de données qui ne sont pas utilisées par l'algorithme de recherche de vecteurs de mouvement dans la zone de recherche.

Dans un ou plusieurs modes de réalisation, on définit une zone de recherche dont une portion a sensiblement la forme d'une portion d'ellipsoïde.

En effet, si l'on utilise, pour la délimitation d'une zone de recherche, une norme vectorielle quadratique définie par la relation suivante : \\v\\ ₂ = v _x ² + v _y ² , où v _x et v _y sont deux composantes du vecteur v, de norme quadratique \\v\\ ₂ , on obtient une zone de recherche ayant une forme circulaire. L'équivalent de cette forme circulaire pour suivre l'aspect ratio de l'image est une forme ellipsoïdale, comme illustré sur la figure 1 1 a.

Dans un ou plusieurs modes de réalisation, la zone de recherche peut avoir dans sa totalité une forme d'ovoïde, ou bien, dans un mode particulier de réalisation, une forme d'ellipsoïde. Dans ce dernier cas, le contour de la zone de recherche définit un polygone de forme sensiblement elliptique.

Par ailleurs, dans un ou plusieurs modes de réalisation, la forme de la zone de recherche unitaire est prédéterminée. En effet, une ou plusieurs formes de zone de recherche unitaire peuvent être préenregistrées. Par exemple, des données de définition de forme (ovoïde, ellipsoïde, ou autre) peuvent être chargées d'une mémoire pour définir la zone de recherche unitaire. Une fois chargée, cette forme de zone est prédéterminée pour toute(s) image(s) d'une séquence à coder.

Dans un mode de réalisation, ces données de définition de forme peuvent définir une courbe correspondant à une portion ou à la totalité de la zone de recherche.

Par exemple, dans le cas d'une zone de recherche de forme sensiblement ellipsoïdale, l'ellipse peut être définie sur un quart d'espace, comme illustré sur la figure 1 1 b, à partir de données de définition de forme chargées en mémoire.

Dans un mode de réalisation, la zone de recherche (1 101 ) peut ensuite être définie pour un bloc (1 102) co-localisé dans l'image de référence choisie avec le bloc courant en cours d'encodage en appliquant la forme définie pour un quadrant sur les quatre quadrants, comme illustré sur la figure 1 1 c.

Les figures 1 1 d, 1 1 e et 1 1 f montrent d'autres exemples de zone de recherche (1 104) et (1 105) définie à partir d'une portion d'ovoïde (1 103) utilisée pour la définition de la zone de recherche sur un quart d'espace.

Dans un ou plusieurs modes de réalisation dans lesquels l'implémentation de l'encodeur prévoit l'encodage en parallèle d'une pluralité de blocs d'encodage, on définit une zone de recherche multiple réunissant les zones de recherche unitaires respectivement définissables pour chaque bloc d'encodage encodé en parallèle.

La figure 1 1 g montre une zone de recherche multiple (1 106) réunissant les zones de recherche unitaires correspondant respectivement à quatre blocs (1 107 - 1 1 10) respectivement co-localisés dans une image de référence avec quatre blocs d'encodage en cours d'encodage disposés dans une configuration en escalier telle que décrite ci-dessus. Dans cet exemple, la zone de recherche multiple est définie à partir d'une définition de zone de recherche unitaire ayant une forme ellipsoïdale de type celle illustrée par la fig. 1 1 c.

En fonction du parcours d'encodage choisi, le chargement en mémoire cache d'une zone de recherche pour un nouveau bloc d'encodage à encoder peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (noté delta x ou à _x ^charg (y)) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche, déterminées sur la base de la forme de la zone de recherche à charger en mémoire cache.

De même, dans le cas d'une zone de recherche multiple, le chargement en mémoire cache de la zone de recherche multiple pour un nouvel ensemble de quatre blocs d'encodage à encoder peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (noté delta x ou à _x ^charg (y)) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche, déterminées sur la base de la forme de la zone de recherche à charger en mémoire cache et en fonction du parcours d'encodage des blocs de l'image courante.

La figure 1 1 h illustre un jeu de valeurs de décalage à _x ^charg (y) pour la zone de recherche multiple illustrée sur la figure 1 1 g. Dans cet exemple, les valeurs x ^charg (y) correspondent respectivement aux 16 valeurs de coordonnée dans le sens vertical possibles. Dans l'exemple illustré sur la figure 1 1 h, les valeurs de décalage A _x ^charg (y) sont déterminées par rapport à la position d'un (1 1 10) des quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, choisi comme bloc de référence. Bien entendu, dans un ou plusieurs modes de réalisation, un autre parmi les quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, ou bien un autre bloc de la zone de recherche multiple 1 106 pourrait être utilisé comme bloc de référence. On peut par exemple utiliser comme bloc de référence celui des quatre blocs (1 107 - 1 1 10) qui conduit à des valeurs de décalage A _x ^char3 (y) les plus faibles, afin de minimiser l'espace mémoire requis pour leur stockage.

Dans un mode de réalisation, les valeurs de décalage A _x ^char3 (y) peuvent être consignées dans une mémoire, par exemple de type ROM, ce qui ne dégrade pas significativement les performances d'accès du contrôleur DDR3, par rapport aux accès aléatoires d'un système sans cache, car les requêtes de lecture en mémoire concernent des blocs entiers (par exemple 512 octets, alignés à la taille d'un macro-block dans le cas d'un encodeur de type H.264/AVC). En effet, dans un mode de réalisation dans lequel chaque couple (x, A _x ^char3 y)) correspond à un macrobloc de taille 16x16 (512 octets avec un échantillonnage de type 4:2:2-8 bits), soit à 32 mots alignés en DDR3, l'accès à des MB 16x16 entiers (correspondant à 32 adresses contiguës) est plus efficace que des accès à des adresses aléatoires.

En référence à l'exemple de réalisation illustré par la figure 1 1 h, les valeurs de A _x ^char3 (y) pour chaque position verticale y, allant par exemple de 0 à 15, sont regroupées dans le tableau ci-dessous (les valeurs de A _x ^char3 (y) étant des entiers naturels) :

y ^ara iy)

0 0

1 +3

2 +7

3 +10

4 +12

5 +13

6 +14

7 +14

8 +14

9 +14

10 +14

1 1 +13 12 +12

13 +1 1

14 +9

15 +6

De même, la libération de la zone de mémoire cache pour un bloc dont l'encodage est terminé peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (notées deltajib x ou A" ^fc ( )) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche mise à jour en mémoire cache, déterminées sur la base de la forme de la zone de recherche chargée en mémoire cache et en fonction du parcours d'encodage choisi.

Dans le cas d'une zone de recherche multiple, la libération de la zone de mémoire cache pour un ensemble de quatre blocs d'encodage dont l'encodage est terminé peut, dans un ou plusieurs modes de réalisation, être défini par une série de valeurs de décalage dans le sens horizontal (notées deltajib x ou à^ Çy)) correspondant respectivement à chacune des valeurs possibles de coordonnée verticale des blocs de la zone de recherche, déterminées sur la base de la forme de la zone de recherche chargée en mémoire cache et en fonction du parcours d'encodage des blocs de l'image courante.

La figure 1 1 i illustre un jeu de valeurs de décalage à^ Çy) pour la zone de recherche multiple illustrée sur la figure 1 1 g. Dans cet exemple, les valeurs de décalage à^ Çy) correspondent respectivement aux 16 valeurs de coordonnée dans le sens vertical possibles. Dans l'exemple illustré sur la figure 1 1 i, les valeurs de décalage Δ^ ³ (y) sont déterminées par rapport à la position d'un (1 107) des quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, choisi comme bloc de référence. Bien entendu, dans un ou plusieurs modes de réalisation, un autre parmi les quatre blocs (1 107 - 1 1 10) co-localisés avec les blocs en cours d'encodage en parallèle, ou bien un autre bloc de la zone de recherche multiple 1 106 pourrait être utilisé comme bloc de référence. On peut par exemple utiliser comme bloc de référence celui des quatre blocs (1 107 - 1 1 10) qui conduit à des valeurs de décalage à^ Çy) les plus faibles, afin de minimiser l'espace mémoire requis pour leur stockage.

De même que pour les valeurs de décalage de chargement, dans un mode de réalisation, les valeurs de décalage de libération àx ^b (y) peuvent être consignées dans une mémoire, par exemple de type ROM.

En référence à l'exemple de réalisation illustré par la figure 1 1 i, les valeurs de décalage de libération A^ (y) pour chaque position verticale y, allant par exemple de 0 à 15, sont regroupées dans le tableau ci-dessous (les valeurs de à^ ^{l b} (y) étant des entiers relatifs) :

L'invention permet ainsi d'obtenir, par rapport à un cache systématique rectangulaire, un gain en efficacité de codage, du fait que, pour un même espace mémoire interne au FPGA, on autorise une excursion des vecteurs plus importante. Cette amélioration de l'excursion des composantes des vecteurs de mouvement est due, d'une part, au gain de l'espace mémoire chargé inutilement avec un cache rectangulaire, comme illustré par les portions d'espace mémoire 917 et 918 sur la Figure 9e, et d'autre part, à la zone de recherche de forme ovoïdale qui permet des vecteurs plus grands dans les directions horizontales et verticales, et moins grands dans les directions diagonales, grâce à l'utilisation dans certains modes de réalisation de la norme quadratique \\v\\ ₂ à la place de la norme infinie.

En fonction du mode de réalisation choisi, certains actes, actions, événements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou événements sont effectués ou se produisent concurremment et non pas successivement.

Bien que décrits à travers un certain nombre d'exemples de réalisation détaillés, le procédé d'encodage proposé et l'équipement pour la mise en œuvre du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l'homme de l'art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l'invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l'ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques font partie de la portée de l'invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n'incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.