Optimisation des performances d un encodeur suivant la norme Advanced Video Coding pour une machine vectorielle

Transcription

1 Faculté des Sciences Département d Informatique Optimisation des performances d un encodeur suivant la norme Advanced Video Coding pour une machine vectorielle Javier MARTINEZ GONZALEZ Mémoire présenté sous la direction du Prof. Philippe VAN HAM en vue de l obtention du grade de Licencié en Informatique Année académique

2 Université libre de Bruxelles Faculté des sciences Ce mémoire intitulé: Optimisation des performances d un encodeur suivant la norme Advanced Video Coding pour une machine vectorielle présenté par: Martinez Gonzalez Xavier a été évalué par un jury composé des personnes suivantes: Roggeman Yves, Van Ham Philippe, Milojevic Dragomir, Cardinal Jean, président-rapporteur directeur de recherche codirecteur membre du jury Mémoire accepté le:

3 REMERCIEMENTS Un travail de cette envergure ne s accomplit pas en un jour. Même s il est porté par le dynamisme de son auteur, il est le résultat des nombreuses influences, proches ou lointaines, qui ont accompagné un esprit avide de connaissances dans sa découverte des sciences de l informatique. Si ce travail constitue pour l auteur une première ouverture sur le monde du travail, il est aussi et surtout, l aboutissement de plusieurs années d étude. Qu il me soit donc permis de remercier les professeurs qui m ont accompagné dans ce cheminement, parfois sévèrement, souvent justement, et plus particulièrement le professeur Raymond Devillers. Je remercie également ceux qui m ont fourni tant d informations lors de l analyse des algorithmes, et tout particulièrement Alex Izvorski, concepteur d x264, pour ses longues explications sur les techniques SIMD et Xiaojie Huang, licencié de l Hong Kong Science and Technology University, pour ses éclaircicements sur la compensation du mouvement. Je tiens à remercier le professeur Flavio Fontanelli de l università degli studi di Genova pour sa pédagogie et son assistance dans la compréhension profonde des architectures machines. Ma gratitude va encore à Jorge Grazina qui dans une autre vie a bien connu les processeurs SIMD, pour ses remarques judicieuses. Je voudrais aussi témoigner de mes remerciements à Dragomir Milojevic, mon coordinateur de mémoire qui a bien voulu me fournir conseil et assistance ainsi qu au Professeur Philippe Van Ham, mon promoteur. Je remercie les professeurs Yves Roggeman et Jean Cardinal qui ont bien voulu se joindre au jury. Ma gratitude va ensuite à ma soeur Cristina, pour sa relecture attentive et ses nombreuses corrections. Je n oublie pas, pour finir, les proches qui m entourent depuis toujours, qu ils soient famille ou amis, pour leur affection et leur soutien sans faille.

4 TABLE DES MATIÈRES REMERCIEMENTS iii TABLE DES MATIÈRES iv CHAPITRE 1 :INTRODUCTION Cadre général Objectifs de ce mémoire Méthodologie Contraintes du travail Structure de ce mémoire CHAPITRE 2 :LA COMPRESSION VIDÉO Introduction Besoins Contraintes Codification Espace colorimétrique Format Vue globale d un encodeur-decodeur Modèle Temporel Compensation du mouvement Modèle Spatial Transformation

5 v Quantification Encodeur d entropie Réorganisation Codage à longueur variable Codage arithmétique CHAPITRE 3 :ADVANCED VIDEO CODING Introduction Hiérarchie des données Baseline Profile Tranche Prédiction inter Prédiction intra Trames de référence Filtres Transformation Quantification Réordonnancement Codeur d entropie Main Profile Tranches B Prédiction pondérée Video entrelacée CABAC

6 vi 3.5 Extended Profile Tranches SP et SI CHAPITRE 4 :ENVIRONNEMENT D EXÉCUTION Introduction Architecture ciblé Aperçu des microarchitectures Parallélisme des instructions Parallélisme des données Plateforme Code source Compilation Directshow CHAPITRE 5 :ESTIMATION DU MOUVEMENT Introduction Algorithmes de recherche Recherche exhaustive Méthodes multi-pas Méthodes prédictives Méthodes à critère de faible complexité Algorithmes dans le software de référence, JM Dynamic Search Range Fast Motion Estimation Simplified Fast Motion Estimation

7 vii Enhanced Predictive Zonal Search Algorithmes dans x Comparaison des performances des encodeurs-cibles Qualité des résultats Mesure des temps de calcul des algorithmes comparés Calibrage des codec Résultats CHAPITRE 6 :OPTIMISATION Introduction Approches possibles d optimisation et aboutisssement Implémentation Résultats Gain Analyse Extrapolation Remarque sur la portabilité Améliorations CHAPITRE 7 :CONCLUSION Cheminement Résultats Travaux futurs BIBLIOGRAPHIE

8 viii LISTE DES TABLEAUX LISTE DES FIGURES

9 CHAPITRE 1 INTRODUCTION 1.1 Cadre général Notre époque vit actuellement, grâce au numérique, une révolution caractérisée par l union de la télédiffusion, des télécommunications et des technologies de l information. La compression vidéo se place au coeur de cette mutation. La compression est pratiquement indissociable de la vidéo pour répondre aux limites inhérentes à la capacité de stockage et à la largeur de bande requise par les images vidéo ; qu il s agisse de la production, du stockage ou de la distribution de celles-ci. Récemment, d innombrables technologies de compression, propriétaires ou non, sont nées afin de distribuer des contenus digitaux sur des canaux de transmission à bande étroite. Soucieuses d établir des normes de compression plus efficaces, les instances internationales de normalisation ont conjugué leurs efforts pour mettre au point le système de codage nommé AVC (Advanced Video Coding). Néanmoins, bien qu excellent, ce standard requiert des capacités de calcul très élevées pour fonctionner en temps réel. Parallèlement à cela, les processeurs informatiques ont considérablement évolué. Les unités centrales de calcul se sont miniaturisées au-delà de l échelle nanométrique et l apparition du parallélisme des systèmes dans les années 60 connaît de nos jours un bond spectaculaire. La puissance de calcul des microprocesseurs universels est améliorée aujourd hui par la complexification de leur structure interne : architectures super-scalaires, techniques dites de super-pipelines, architectures SIMD, etc. Le renforcement du parallélisme dans l architecture des microprocesseurs impose donc que l on abandonne les algorithmes séquentiels au profit d une approche parallèle. Par ailleurs, un corollaire du progrès de l informatique est l augmentation croissante de sa segmentation en couches de services, couches dont les niveaux supérieurs se confrontent à l irruption des approches parallèles dans la couche inférieure. En effet, la plupart des compilateurs de langage de haut niveau actuels, soucieux avant tout de fournir du code interopérable, sous-exploitent les capacités réelles des processeurs.

10 1.2 Objectifs de ce mémoire 2 L idée de ce mémoire est née du constat que les besoins de plus en plus gourmands de la compression de données vidéo en temps réel, en général, et du processus d estimation de mouvement lors de l encodage vidéo de norme AVC, en particulier, sont mal servis par une approche séquentielle de la programmation. Nous pensons qu une solution pour optimiser l encodeur vidéo consiste peut-être à optimiser le processus de traitement de l information à l aide des unités de traitement parallèles. 1.2 Objectifs de ce mémoire Ce travail tente de répondre à deux objectifs principaux. Le premier objectif est d ordre scientifique et technique. Il consiste à analyser les différents niveaux de parallélisme d un type de processeur courant pour implémenter des solutions d optimisation de la compression vidéo et rendre possible l encodage en temps réel, en utilisant le standard AVC. Le second objectif avoue un penchant plus académique. Nous voulons démontrer qu une approche alternative moins classique de l optimisation, de type empirique, peut être avantageuse par rapport à une optimisation algorithmique pure ne tenant pas compte de l architecture d exécution. L apport in fine de ce travail est de fournir un encodeur standardisé qui soit utilisable en temps réel et qui, toutes choses étant égales par ailleurs, compresse dix fois plus vite que le système de départ uniquement par optimisation de ses étapes de compression. 1.3 Méthodologie La méthode employée pour optimiser l encodeur est essentiellement empirique. Elle consiste à analyser tous les services fournis par l architecture afin de mettre ceux-ci à disposition du programme lors de l exécution. Par ailleurs, les algorithmes de compression d image associés à la norme AVC seront étudiés en détail et comparés. Des algorithmes choisis pour leurs qualités intrinsèques seront ensuite optimisés à l aide des connaissances acquises. Ils seront enfin appliqués au problème de la compensation de mouvement dans l image, élément typiquement gourmand en puissance de calcul.

11 1.4 Contraintes du travail 3 Cette approche complète d optimisation privilégie un calculateur vectoriel dans une architecture ciblée. Elle devrait permettre l utilisation du meilleur standard de compression à l heure actuelle, la norme AVC, et permettre la vidéo en temps réel dans des conditions normales de traitement. Ce travail remet en question le concept d algorithme mathématique basé sur le principe de la machine séquentielle. Il va en cela se heurter à deux difficultés : (1) la diversité des modèles architecturaux parallèles et (2) la difficulté de programmation des machines vectorielles. 1.4 Contraintes du travail Tout naturellement, le choix du codec s est porté sur la norme AVC, adoptée par la plupart des fabricants parce qu elle surpasse tous les standards précédents en terme de qualité. Mais le software de référence pour l encodeur fournit par l UIT s est avéré peu optimal et nous avons préféré utiliser un autre code source existant, open source celui-ci. Puisqu il s agit de permettre la vidéo en temps réel, le taux d encodage imposé à l encodeur est sans surprise d au moins 25 images par seconde avec un débit de 150 Ko par seconde. S agissant d une application grand public, nous avons choisi de concentrer nos recherches autour du microprocesseur 32 bits d Intel (Pentium 4), parce que très répandu sur le marché de la micro-informatique. Ainsi, la recherche de performance de l encodeur est motivée par le respect de contraintes de temps (temps réel) et de ressources de calcul (microprocesseur). Dans ce travail, ces contraintes sont souvent abstraites pour être traduites en calculer le plus vite possible avec les ressources disponibles. Nous verrons tout au long du travail que la formalisation des contraintes matérielles est pratiquement impossible et que l approche choisie, la méthode empirique, est la plus réaliste. 1.5 Structure de ce mémoire Dans le premier chapitre de ce mémoire, nous introduisons la compression et les différents procédés de codage et de décodage de l image existants. Dans le deuxième chapitre, nous présentons la norme de codage vidéo AVC qui est la plus récente et aussi la plus efficace. Dans le troisième chapitre, nous offrons au lecteur un

12 1.5 Structure de ce mémoire 4 aperçu rapide des architectures et plateformes courantes afin de justifier le choix du microprocesseur et de présenter les contraintes environnementales présentes dans toute tentative d optimisation des algorithmes de compression. Dans le quatrième chapitre, l étude des algorithmes actuels pour l estimation du mouvement nous permet de pressentir lesquels sont les plus adaptés à nos objectifs et de choisir ceux qu il nous faudra améliorer. Dans le cinquième chapitre, enfin, nous dévoilons le cœur du travail proprement dit, soit l implémentation d algorithmes optimisés pour le traitement d images vidéo et les résultats obtenus.

13 CHAPITRE 2 LA COMPRESSION VIDÉO 2.1 Introduction Depuis l avènement des télécommunications, il est devenu aisé d accéder à l information. De nombreux média coexistent et la vidéo fait aujourd hui partie entière de notre quotidien : on peut de chez soi commander un film, télécharger les dernières nouvelles sur son téléphone portable ou faire de la vidéo conférence avec des amis à l autre bout de la planète. La maturité des équipements d aujourd hui nous permet de voir, transmettre, traiter et sauvegarder des signaux vidéo sur différentes plateformes et d interagir avec leurs contenus. Obtenir une vidéo digitale depuis la source filmée vers son lieu de distribution nécessite une longue chaîne de traitement. D un signal analogique nous sommes passés à une chaîne complète de traitement digital. Parmi les étapes importantes de ce traitement, on trouve les opérations de compression et de décompression du signal afin de minimiser la bande passante nécessaire à la distribution du signal. Cette étape porte le nom de compression vidéo. Elle peut comprimer l information avec ou sans perte. Le but de ce travail est d augmenter les prestations de la chaîne de traitement afin d obtenir la meilleure qualité possible pour une utilisation en temps réel dans un environnement (bien) particulier. Tout d abord, pour comprendre comment fonctionne la compression vidéo, nous allons passer en revue les grandes lignes de la chaîne de traitement vidéo, de son acquisition jusqu à son utilisation finale Besoins Lorsque nous regardons une séquence vidéo, nous observons une image qui change au fil du temps. Cette image est constituée de points élémentaires appelés pixels 1 ou pel. Ces pixels peuvent avoir des formes différentes (rond, point, ligne, 1 De l anglais picture element.

14 2.1 Introduction 6 Figure 2.1 Les grandes étapes lors d une acquisition vidéo. carré, etc.) et influencent la netteté de l image ; on parle de définition de l image. La résolution d une image est le nombre de pixels par image. Plus nous augmentons la résolution, plus l image devient précise et de qualité. En raison du fonctionnement de la vision humaine, la persistance rétinienne et l effet phi nous procurent un effet de mouvement fluide si nous soumettons notre vision à une scène échantillonnée à au moins vingt images par seconde [66]. La fréquence augmentant, la sensation de fluidité s accroît. Une séquence vidéo est une représentation d une scène visuelle naturelle échantillonnée temporellement et spatialement. Une scène est échantillonnée à un moment pour produire une image fixe (trame). L échantillonnage est répété à intervalles réguliers, typiquement fois par seconde. L échantillonnage est effectué à l aide d un appareil photosensible qui va acquérir la scène et produire un flux vidéo brut caractérisant la scène. Dans le cas de la vidéo digitale, les appareils photosensibles utilisées sont appellés transducteurs optoélectroniques digitaux. Les plus courants sont les CCD 2. Tout d abord, la lumière perçue est séparée en trois composantes à l aide d un filtre ou d un prisme. Ensuite, une matrice de cellules semi-conductrices quadrillant l entièreté de la fenêtre d acquisition évalue l intensité lumineuse et produit un signal électrique linéairement dépendant de l intensité perçue. Ce signal analogique est enfin converti en signal digital. Chaque cellule produit donc une composante d un pixel de l image fixe. Au final, le processus produit un flux de données égal à la résolution de chaque cellule ([1,48]bits) fois le nombre de cellules ([0.7,40] Mil- 2 De l anglais charge-couple device.

15 2.1 Introduction 7 lions). Souvent, les appareils optoélectroniques digitaux possèdent des filtres qui suppriment le bruit Gaussien (électronique) et Poissonien (lumineux). Nous devons ensuite acheminer le flux vidéo vers sa destination. Figure 2.2 Processus d acquisition d une scène vidéo à l aide d un CCD Contraintes Une vidéo contient une quantité importante de données, et malgré l augmentation de la puissance des processeurs et des capacités des périphériques de stockage, nous avons besoin de la représenter dans un format plus concis. Afin de maximiser la bande passante, des techniques de compression vidéo ont été inventées. Par compression vidéo, nous entendons le recodification des données sources, à travers une série d étapes, vers une taille de données plus compacte (= codage). Un système similaire de décompression nous permet de retrouver la vidéo originale (= décodage). Le procédé qui regroupe ces méchanismes s appelle le système codec (mot-valise construit d après les mots encodeur/decodeur). Pour un encodage sans perte d image fixe, à l heure actuelle le meilleur

16 2.2 Codification 8 standard est le JPEG-LS 3 [56]. Il nous permet d obtenir la même image de 3 à 4 fois plus compacte, la compression étant obtenue en enlevant de la redondance. Malgré le taux de compression honorable, il est nécessaire d avoir recours à des techniques avec perte. En effet, si nous considérons un film tv de 120 minutes codé en brut au format PAL, ce n est pas moins de 194,4 Giga-octets de données qui sont produites. La compression avec perte exploite la redondance subjective, c est-à-dire l élimination d éléments de l image n affectant pas ou peu la qualité perçue par le spectateur. Des taux d 1/50ème sont obtenus aujourd hui par l utilisation de codec tel que le standard MPEG-2 4. Les standards plus récents MPEG-4 et AVC se veulent plus ambitieux et permettent d obtenir des taux jusqu à deux fois meilleurs que le MPEG-2, mais leur coût en temps de calcul reste élevé. Nous verrons plus loin pourquoi nous avons choisi le standard AVC. La qualité d une vidéo compressée varie très grandement en fonction de la fréquence d entrée, de la résolution d entrée, du débit imposé en sortie et de la qualité exigée. Afin de mieux cerner le problème, nous étudierons des flux à une fréquence de 25hz. Ils garantissent un bon compromis entre taille et fluidité, et sont ceux utilisés par l industrie audiovisuelle. Nous imposerons également différentes résolutions à l entrée afin d observer les variations du débit et de la qualité en sortie. 2.2 Codification Nous avons vu qu une image est représentée par une série d éléments appelés pixels. Dans une image monochrome, un pixel prend une valeur discrète en fonction de la luminosité. En raison de la codification choisie, un pixel sera blanc, noir ou d un gris intermédiaire selon le pas de discrétisation ; on parle aussi de résolution du pixel. Dans une image couleur, nous avons besoin d au moins 3 informations par pixel pour pouvoir représenter la couleur. La méthode choisie pour représenter la luminosité (luminance ou luma) et la couleur (chromatique ou chroma) est décrite comme l espace colorimétrique. 3 Le JPEG (Joint Photographic Experts Group) est un groupe d expert associé à l organisation internationale de normalisation (ISO (International Organization for Standardization)), ils ont développé le standard JPEG-LS(LosslesS). 4 Par exemple le DVD (de l anglais Digital Versatile Disc) utilise ce standard.

17 2.2 Codification Espace colorimétrique Figure 2.3 Une image et sa représentation dans différents espaces colorimétriques. De nombreux espaces colorimétriques existent. Citons parmi eux le RGB, le CMYK, l HVS et le YUV. En RGB (rouge, vert, bleu), un pixel est représenté par trois nombres qui indiquent la proportion relative de rouge, de vert et de bleu. N importe quelle couleur est représentée par addition de ces trois couleurs dans différentes proportions ; on dit que cet espace est additif (voir Fig. 2.4(a)). Le RGB est très employé dans la capture et l affichage grâce à la facilité de séparation de la lumière en ces trois composantes. C est d ailleurs cette facilité qui a poussé l industrie à utiliser ce standard. Un autre espace beaucoup utilisé en imprimerie est le CMYK (cyan, magenta, jaune, noir). Ici l espace est soustractif (voir Fig. 2.4(b)), et la couleur perçue est celle qui n est pas absorbée par le mélange des 4 composantes. Les artistes quant à eux emploient souvent l HSV 5 (teinte, saturation, valeur) pour une raison de ressemblance à la vision humaine. La vision humaine est moins sensible aux couleurs qu à la luminosité [96]. En RGB, les trois couleurs possèdent la même importance, si bien qu il faut garder 5 De l anglais Hue, Saturation, Value.

18 2.2 Codification 10 (a) Synthèse additive (b) Synthèse soustractive Figure 2.4 Synthèse des couleurs. la même résolution pour chaque composante. Il existe des espaces qui séparent la luminosité des couleurs. Il est alors possible d augmenter la résolution de la luminance et de réduire celle de la chromatique, ce qui améliore la qualité du signal décodé. Le YUV et ses variations (aussi appelé YCbCr) représentent un pixel de couleur par une luminance Y et trois composantes chromatiques Cb, Cr et Cg. La luminance Y est un calcul pondéré des composantes rouge, verte et bleue. Y = k r R + k g G + k b B Cb = B Y Cr = R Y Cg = G Y (2.1) Où k est un coefficient pondéré. La description complète d un pixel nécessite donc 4 composantes. Heureusement, les composantes sont interdépendantes, si bien qu avec trois d entre elles nous obtenons la quatrième. Généralement seul Y, Cb et Cr sont transmis. L UIT 6 recommande l utilisation des coefficients k r = 0, 299 et k b = 0, 114. Ainsi nous obtenons la table de conversion RGB YUV : 6 Union Internationale des Télécommunications.

19 2.2 Codification 11 Y = 0.299R G B Cb = 0.564(B Y ) Cr = 0.713(R Y ) R = Y Cr G = Y 0.344Cb 0.714Cr B = Y Cb (2.2) L intérêt du YUV est double : il permet la compatibilité des vieux équipements noir et blanc avec un signal couleur et permet une meilleure utilisation de la bande passante en encodant plus d information sur la luminance au détriment de la chromatique. Différents formats d échantillonnage existent en YUV. Les plus communs sont le 4 : 2 : 0 (YV12), le 4 : 2 : 2 (YUY2) et le 4 : 4 : 4 (RGB). En mode 4 : 4 : 4 chaque composante (Y, Cb et Cr) aura la même résolution. Dès lors, chaque composante existe à chaque pixel. Le format 4 : 2 : 0 échantillonne pour quatre Y, un Cb et un Cr. Le lieu d échantillonnage sur l image varie en fonction du standard choisi. Dans la suite de ce travail nous adopterons uniquement le format YUV 4 : 2 : 0 avec une résolution de 8 bits par composante, soit une résolution moyenne de 12 bits par pixel. (a) 4 :4 :4 (RGB) (b) 4 :2 :2 (YUY2) (c) 4 :2 :1 (YV12) Figure 2.5 Trois modes d échantillonnage Y Cb. Cr Format Le standard de compression vidéo que nous étudierons (AVC) peut comprimer une grande variété de formats colorimétriques sous diverses résolutions. En pratique, le format CIF 7 est la base d une hiérarchie de formats (voir le tableau 2.1). Nous avons rajouté deux formats HDTV 8 car nous les utiliseront aussi dans le codec. Les normes PAL et NTSC définissent des vidéos en mode entrelacées à 50hz 7 De l anglais Common Intermediate Format 8 Un standard HDTV (High Definition TeleVision) pour l Europe n a pas encore été établi, néanmoins nous utilisons la dénomination courante employé par les constructeur de dalle LCD

20 2.3 Vue globale d un encodeur-decodeur 12 Format Résolution Luminance Bits par image (Horizontal Vertical) (YV12, 8bit) Application SQCIF Vidéo Mobile QCIF Vidéo Conférence CIF Monitoring Vidéo 4CIF TV, DVD 720i HD TV 1080i HD DVD Tableau 2.1 Résolutions d image au standard PAL. et 60hz respectivement, ce qui revient à des débits de 25 et 30 images par seconde [26]. Pour une utilisation plus pratique, un flux vidéo est encapsulé dans un conteneur (un type de fichier). Selon le conteneur choisi (avi, mp4, asf etc..), le flux est plus ou moins dépendant d une plateforme et contient des informations sur la manière dont la vidéo et l audio sont attachés entre eux, ainsi que sur les codecs utilisés. Le conteneur n impose pas le type de codec employé dans le flux. Pour des raisons pratiques, nous emploierons un conteneur avi. 2.3 Vue globale d un encodeur-decodeur Tous les codecs fonctionent selon le même principe et possèdent les mêmes étapes décisives. Une vue globale est fournie aux Figures 2.6 et 2.7. Figure 2.6 Schéma d un encodeur. L encodeur se compose de trois étages : le modèle temporel, le modèle spatial et le codeur d entropie. En entrée, nous fournissons un flux vidéo paramétré. Le

21 2.4 Modèle Temporel 13 modèle temporel exploite la redondance entre les trames voisines et construit une prédiction des trames suivantes. Les outputs du modèle temporel sont un résidu et un ensemble de vecteurs exprimant la compensation du mouvement. Ce résidu est formé par la différence entre la trame prédite et la trame successive. La trame résiduelle (inter-trame) forme l input du modèle spatial. Celui-ci utilise les propriétés de corrélation des pixels pour réduire la redondance spatiale. Les pixels sont décorrélés en transformant la trame dans un autre domaine. Cette transformation convertit une trame en coefficients. Ces coefficients sont ensuite quantifiés pour ne laisser en sortie qu une série de coefficients significatifs représentant de manière plus compacte la trame résiduelle d entrée. Les sorties du modèle temporel (les vecteurs de mouvement) et du modèle spatial (les coefficients) sont compressées par l encodeur d entropie. L encodeur d entropie utilisera la redondance statistique pour recoder les vecteurs et les coefficients de manière plus compacte. Une séquence compressée est donc constituée de vecteurs de mouvement, de coefficients de résidu et d un en-tête. Figure 2.7 Schéma d un décodeur. Le décodeur quant à lui reconstruit la vidéo à partir du flux de sortie de l encodeur. Les coefficients et les vecteurs de mouvement sont décodés par un décodeur d entropie, à la suite duquel le modèle spatial se charge de reconstruire la trame résiduelle à partir des coefficients. Ensuite à partir d une trame précédemment reconstruite, des vecteurs de mouvement et de la trame résiduelle, le décodeur obtient l image de départ. 2.4 Modèle Temporel Dans une séquence vidéo, deux images successives contiennent très probablement un grand ensemble d information semblables. Seules certaines parties de la première image vont être modifiées. Dans la figure 2.8 nous avons pris deux trames

22 2.4 Modèle Temporel 14 consécutives d une séquence vidéo. En définissant le résidu comme la différence entre nos deux trames, nous remarquons que les parties statiques (le fond de l image) ont des différences temporelles proches de 0 et qu elles interviennent peu dans le codage du résidu. Pour réduire l information du résidu, un mécanisme de compensation du mouvement à été créé. A l exception des changements de lumière, de l arrivée de nouveaux objets et des zones recouvertes par un objet en mouvement, une séquence vidéo représente un mouvement de pixel. Sur la Fig. 2.9 nous remarquons que l énergie du résidu se concentre autour de la bouche, des cheveux et du contour de la femme. L énergie résiduelle peut être réduite si arrivons à prédire la position dans la trame suivante des pixels en mouvement. Il nous suffirait d associer un vecteur à chaque pixel et d en décrire le déplacement. Ainsi, si ces vecteurs sont calculés de manière précise, nous pouvons reconstruire la prochaine trame à partir des vecteurs et du résidu. Figure 2.8 Deux trames consécutives. (a) Sans compensation de mouvement (b) Avec compensation du mouvement Figure 2.9 Résidus de la Fig. 2.8.

23 2.4 Modèle Temporel Compensation du mouvement Le but de la compensation du mouvement est de fournir une information supplémentaire afin d alléger l énergie résiduelle nécessaire à la prédiction de la trame future. Ce mécanisme est composé de l estimateur et du compensateur. L estimateur va associer des vecteurs de déplacement à la trame, quant au compensateur, il calculera le résidu. L estimation du mouvement est développée en profondeur au chapitre 5. Trois familles d estimateurs de mouvement (ME 9 ) existent : ceux basés sur les pixels, ceux basés sur les régions et ceux basés sur les blocs. Les techniques pixels fournissent un champ complet de vecteur de déplacement minimisant au mieux l énergie résiduelle, mais leur coût de calcul ainsi que la taille du champ n en font pas un outil adapté à la compression. Les techniques régions décomposent l image en objets, et effectuent des transformations sur ceux-ci. Ces techniques sont expérimentales mais seront à l avenir un solide concurrent des techniques blocs [20]. La principale difficulté reste le découpage adéquat des régions et leur encodage en forme compacte. Les techniques basées sur les blocs sont à l heure actuelle très efficaces en termes de qualité et de débit. Elles restent les techniques les plus adoptés dans les standards de compressions. Dans les techniques blocs une image est divisée en blocs rectangulaires NxM avec N,M {4, 8, 16} pixels. Chaque bloc dans la trame d origine est comparé avec des blocs de la même taille dans les trames de référence 10 dans le but de trouver le meilleur bloc qui satisfasse un critère d erreur basé sur une mesure particulière. Les coordonnées du bloc trouvé sont celles du premier pixel, soit le coin supérieur gauche. Le vecteur pointant vers le bloc trouvé est choisi comme vecteur de déplacement (MV 11 ). La différence résiduelle est calculée entre le bloc choisi et le bloc d origine par le processus de compensation de mouvement. Cette différence est codée et transmise avec les MV à l étage suivant de l encodeur. Deux critères d erreur sont couramment employés pour l estimation du mouvement : 9 De l anglais Motion Estimation 10 Trame déjà encodée, future ou antérieure par rapport à l ordre original. 11 De l anglais Motion Vector.

24 2.5 Modèle Spatial 16 la Somme du Carré des Différences (SSD) SSD(u, v) = N 1 M 1 i=0 j=0 (C i,j R i+u,j+v ) 2 (2.3) et la Somme de Différence Absolue (SAD) SAD(u, v) = N 1 M 1 i=0 j=0 C i,j R i+u,j+v (2.4) C i,j est la valeur du pixel de la trame courante et R i+u,j+v celle du bloc de référence. Les composantes du vecteur de déplacement sont (u,v). Ces deux critères offrent une bonne robustesse et restent facilement calculables [86]. SSD est un meilleur critère que SAD, mais sa complexité est plus grande. Pour un bloc de 16x16, SSD nécessite 2 8 multiplications et 2 9 additions. SAD n a besoin que de 2 9 additions. Dans ce travail, nous emploierons ces deux critères. Le vecteur de mouvement n est pas nécessairement composé d entiers. En effet, la recherche d un bloc peut se faire à un niveau plus petit que le pixel. Les valeurs subpixel peuvent être créées par une moyenne des valeurs environnantes, médiane ou d autres types d interpolations. Nous verrons à quel moment sont employées ces itérations et l impact qu elles peuvent avoir sur le MV dans la section 5.2. Une fois le bloc trouvé, le résidu est calculé et envoyé à l étage suivant, les vecteurs sont directement passés au dernier étage de l encodeur. 2.5 Modèle Spatial Le deuxième étage de l encodeur s attaque donc à la redondance spatiale. La trame résiduelle contient encore beaucoup de redondance spatiale. Si nous appliquons une transformation sur la trame, nous pouvons compacter l information sur un nombre restreint de valeurs. Ensuite, il nous faudra écarter les valeurs insignifiantes et, enfin, encoder le résultat pour réduire l ensemble.

25 2.5 Modèle Spatial Transformation Le choix d une transformée dans le cas d un codec sera dicté par ces critères : la transformée doit être inversible (le décodeur doit être capable de reconstruire les trames à partir des prédictions) ; les données dans le domaine de la transformée doivent être décorrélées (séparées en composants avec une interdépendance minimale) ; les données dans le domaine de la transformée doivent être compactes (la plus grosse partie de l énergie doit se concentrer sur un petit nombre de valeurs) ; la transformée doit être peu gourmande en calcul (requerrant peu d espace mémoire, contenant peu d opérations arithmétiques, ne dépendant pas de l epsilon machine, etc.) Beaucoup de transformées discrètes ont été proposées [13]. Les plus en vogues sont la transformée cosinus discrète (DCT 12 ) et la transformée ondelette discrète (DWT 13 ). La DCT est basée sur des blocs, la DWT sur une image entière. Bien que la DWT ait des performances supérieures à la DCT, sa demande en mémoire et sa compatibilité avec la compensation de mouvement (basé sur les blocs) n en font pas un outil adapté aux codecs d aujourd hui. DWT est la transformée utilisé dans le standard JPEG La DCT est une méthode transformant les données d une image du domaine spatial vers le domaine fréquentiel. Un bloc NxN (pour rappel, l étage précédant nous fourni des blocs de taille égale ou multiple) est transformé pour fournir des coefficients. Dans les codecs actuels, des blocs 8x8 sont choisis pour leur bonne corrélation inter-pixel et leur faible temps de calcul. L action de la DCT (et son inverse l IDCT) est un produit matriciel. La définition de la DCT à évolué au fil du temps et la dernière en date est donnée en équation 2.5 avec f le bloc original et F le bloc de coefficients transformés. F (u, v) = 2 N 1 N g(u)g(v) i=0 M 1 j=0 f(i, j) cos( 12 De l anglais Discrete Cosinus Transform. 13 De l anglais Discrete Wavelet Transform. 14 JPEG2000 est un standard de compression avec perte d images fixes. (2i + 1)uπ (2j + 1)vπ ) cos( ) (2.5) 2N 2N

26 2.5 Modèle Spatial 18 où g(x) = { 1 2 si x = 0 1 sinon La série de Fourrier définit une fonction périodique comme une somme infinie de sinus. Similairement, nous voyons notre bloc comme étant une somme finie de blocs de base (voir Fig. 2.10). Les coefficients obtenus représentent le poids de chaque bloc de base dans le modèle spatial. Un bloc de base est construit à partir d une fonction cosinus. Le coefficient F(0,0) représente la composante continue, les autres sont des coefficients réels de cosinus divers. Dans un scénario typique, les coefficients basse fréquence représentent la plus grosse partie de l information d origine. Figure 2.10 Les fonctions cosinus de base. La DCT requiert une multiplication matricielle coûteuse. En pratique, une version rapide, la FDCT (Fast DCT) est employée. La complexité passe ainsi de n 2 à n log 2 n (avec n le nombre de coefficients). De nombreuses versions existent, les plus courantes se basent sur des transformées rapides de Fourrier (FFT 15 ). La FDCT est une transformée unidimensionnelle ; elle est appliquée aux lignes, puis aux colonnes, afin d obtenir la transformée bidimensionnelle. En factorisant l équation 2.5, nous savons la réécrire comme un produit Eulérien. En se basant sur la propriété où W q = 1 (avec W = e i 2π N pour N = 2 q et q N), nous réduisons fortement le temps de calcul de la DCT. La Fig nous montre où se concentre l information après une DCT. 15 De l anglais Fast Fourrier Transform.

27 2.5 Modèle Spatial 19 (a) un bloc de couleurs (b) composantes luma (c) coefficients obtenus après une DCT Figure 2.11 Numérisation et transformée d un bloc 8x Quantification Suite à la transformation qui, pour rappel, ne perd pas d information, nous obtenons une matrice avec beaucoup de coefficients proches de 0. La quantification est utilisée pour écarter les coefficients insignifiants et pour regrouper les autres par seuils. La quantification est un processus irréversible ; les données d origine ne peuvent pas être récupérées après cette étape. La quantité d information écartée est choisie en fonction d un pas de quantification (QP 16 ). Une fonction typique est montrée en Fig Le pas et la forme de cette fonction peuvent varier en fonction du temps. Les mécanismes de régulation du débit du compresseur vont jouer un grand rôle sur cette fonction [104]. Le pas de quantification influencera grandement la qualité et le débit de compression final. 16 De l anglais Quantization Parameter. Figure 2.12 Fonction de quantification.

28 2.6 Encodeur d entropie Encodeur d entropie L encodeur d entropie représente l information de manière plus compacte et sans perte. Son principe est statistique ; il va assigner des codes courts aux symboles les plus courants et de plus longs à ceux qui le sont moins. L encodeur nécessite donc deux étapes : la première assignera des probabilités aux symboles, la deuxième encodera les symboles en fonction des tables obtenues. Nous définissons l entropie (H(x)) comme le nombre moyen de bits nécessaires pour coder un symbole dans un alphabet binaire de manière minimale. Ceci est la borne inférieure du codage de symboles. Un bon encodeur se doit d approcher cette borne. H(x) = N P i log 2 P i (2.6) i=1 L équation 2.6 nous donne l entropie H(x) avec P i la probabilité du symbole i. Il y a deux types d encodeurs à longueur variable employés dans un codec, l encodeur de Huffman modifié et l encodeur arithmétique. L encodeur de Huffman offre une simplicité de calcul pour de bonnes performances, mais les codes assignés (des entiers) empêchent cet encodeur d atteindre l entropie. Le codage arithmétique, quant à lui, approche mieux cette borne en utilisant des codes réels, mais est plus gourmand. Au final, l encodeur aura en input : des vecteurs de mouvement, des coefficients de transformée quantifiés, des marqueurs de synchronisation, des en-têtes et de l information secondaire extra, non vitale pour un décodage correct Réorganisation L output du modèle spatial est une matrice creuse contenant quelques valeurs non nulles. Avant l envoi vers l encodage d entropie, les coefficients nuls sont regroupés et recodés dans un ordre plus économique en terme de place. Avec un parcours de la trame en mode zig-zag 2.13, nous allons obtenir une longue série de 0. En utilisant une méthode RLE 17, nous regroupons les De l anglais Run-Length Encoding.

29 2.6 Encodeur d entropie 21 Par exemple, le string suivant [ ] peut être ré-écrit en tuples en utilisant un code bidimensionnel : (6,1) (2,3) (0,3) (1,2) (FIN). Dans un code tridimensionnel, nous aurions supprimé le code de FIN en le répartissant sur les codes internes, le 1 sur le dernier tuple indiquant le dernier coefficient non nul dans le bloc : (6,1,0) (2,3,0) (0,3,0) (1,2,1). De 17 symboles au départ, nous passons à 9 symboles dans le cadre d un code bidimensionnel. Figure 2.13 Parcours d une trame en zig-zag Codage à longueur variable Le codage de Huffman assigne un code à chaque symbole. Ce codage s inspire fortement des arbres trie 18. Les codes de sorties prennent des valeurs de 1 à plusieurs bits. Le code à la sortie peut même être plus grand que le code à l entrée si sa probabilité est très faible. Le nombre optimal de bits pour un symbole est log 2 P, avec P la probabilité de ce symbole. Le problème du codage de Huffman est qu un nombre de bit entiers est assigné à un symbole. Si un symbole a une probabilité de 0,9, l optimum serait de le coder sur 0,15 bit, le codage de Huffman le codera sur 1 bit. Une fois les probabilités d occurrence connues, l algorithme construit une table (un arbre) de codage. La construction se fait comme suit : 1. Chaque symbole est la racine d un arbre, trier les symboles par ordre de probabilité ; 2. Rechercher les deux symboles les moins probables et former un noeud père de poids égal à leur probabilité conjugue ; 3. Trier les arbres sur leur racine ; 4. S il ne reste plus qu une racine, terminer, sinon reprendre en De l anglais retrieval., un arbre où les données sont structurées de manière ordonnée sur les feuilles.

30 2.6 Encodeur d entropie 22 La Fig nous montre un arbre construit pour 7 symboles, ainsi que les codes attribués. Avec le codage, nous obtenons une moyenne de 2,65 bits par symbole ce qui est proche de l entropie qui est de 2,62. Figure 2.14 Arbre d Huffman (extrait de [26]). Deux problèmes interviennent dans l utilisation de ce codage : 1. La table de probabilité des symboles ne peut être calculée qu après avoir encodé au deuxième étage toute la vidéo (c est une contrainte insoluble dans le cadre d un codec travaillant en temps réel) 2. Le décodeur doit obtenir une copie de la table créé par l encodeur. Pour résoudre ces problèmes, des tables pré-calculées sont incluses dans l encodeur et le décodeur dès leur conception. Elles se basent sur des distributions de symboles de vidéos génériques Codage arithmétique L idée fondamentale du codage arithmétique est d utiliser une série de symboles plutôt qu un seul et de les regrouper dans un nombre réel compris entre 0 et 1. Ceci nous permet d approcher l entropie. Plus la série de symboles est longue, plus

31 2.6 Encodeur d entropie 23 l intervalle devient petit. Illustrons ce principe par un exemple utilisant un modèle de probabilité fixe sur l alphabet A,B,C,D,E,X. Symbole Probabilité Intervalle A 0.30 [0.00, 0.30[ B 0.20 [0.30, 0.50[ C 0.20 [0.50, 0.70[ D 0.15 [0.70, 0.85[ E 0.10 [0.85, 0.95[ X 0.05 [0.95, 1.00[ Tableau 2.2 Un modèle de probabilité sur un Alphabet de 6 symboles. Figure 2.15 Encodage arithmétique de BAAEX (extrait de [55]). Soit le string BAAEX, la Fig illustre son codage arithmétique. L algorithme est basé sur l itération suivante : Inf {n} = Inf {n 1} + fréquence cumulative(symbole) T aille Sup {n} = Inf {n 1} + fréquence cumulative(symbole+1) T aille T aille {n} = Sup {n} Inf {n} (2.7) avec Inf {0} = 0 Sup {0} = 1 T aille {0} = 1

32 2.6 Encodeur d entropie 24 L information sera codée par un nombre compris dans l intervalle final. On choisit un nombre nécessitant le moins de bits possibles. Des techniques de construction à la volée de la table des probabilités sont employées par ce type de codeur. Les tables sont affinées au fur et à mesure que les symboles passent. Le décodeur utilisant le même principe, cette technique est inversible. Un raffinement du codeur peut être fait en utilisant un alphabet binaire. Après avoir examiné la théorie de la compression vidéo, et les méthodes existant pour supprimer la redondance de l image, nous allons maintenant étudier le dernier standard de compression AVC disponible.

33 CHAPITRE 3 ADVANCED VIDEO CODING 3.1 Introduction L UIT 1 et l OSI 2, deux organisations de standardisation ont uni leur forces pour développer conjointement un nouveau standard de compression vidéo 3. Le but était de produire un codec obtenant de meilleures performances que le MPEG-4 et l H.263 dans le cadre de vidéos rectangulaires. Le standard, relativement récent 4, a été nommé Advanced Video Coding (AVC) et est publié conjointement sous les labels MPEG-4 part 10 et ITU-T Recommendation H.264. Pour plus d information, consulter la biographie en [39],[69] et [82]. Tous les standards de compression définissent la syntaxe d un flux compressé et les méthodes pour le décompresser. Si bien qu une foule de logiciels de compression existent avec des implémentations différentes. Certaines nouveautés sont apparues dans AVC, comme le filtre débloquant ; pour le reste, il s agit d un raffinement des étapes déjà expliquées au chapitre 2. AVC est divisé en trois sections (profiles) définissant une série de fonctionnalités (voir figure 3.1). Nous avons le profil baseline, main et extended. Tout décodeur qui veut se conformer aux exigences du standard doit au moins savoir décoder le baseline. Nous ne décortiquerons pas le standard dans son entièreté, mais résumerons les points importants et donnerons les formules nécessaires à la compréhension de l implémentation de l estimateur de mouvement dans le code source fourni par l UIT (le JM). 1 L Union Internationale des Télécommunications. 2 L Organisme de Standardisation International. 3 Les équipes dédiées à la vidéo dans chaque organisme ont fusioné en une seule ; le Video Coding Experts Group (VCEG,ITU-T) et le Moving Picture Experts Group (MPEG,OSI/IEC) pour se rassembler sous l appellation Joint Video Team (JVT). 4 Le standard AVC a été finalisé en 2003.

34 3.1 Introduction 26 Figure 3.1 Vue générale du standard AVC (extrait de [28]).

35 3.2 Hiérarchie des données 27 Fonctions supportées Baseline Main Extended tranches SI et SP Non partitionnement des données prédiction pondéré Non tranches B Oui codage CABAC Non codage entrelacé Oui tranches I et P codage CAVLC trames de références multiples filtre déblocant ordonnancement flexible des macroblocs Oui Oui ordonnancement arbitraire des tranches Non tranches redondantes 3.2 Hiérarchie des données Tableau 3.1 AVC et ses Profiles. Une séquence vidéo est une succession de trames, dont chacune contient un numéro (POC). Ce numéro sert au réordonnancement car les processus d encodage et de décodage peuvent traiter les trames dans le désordre. Les trames encodées précédemment (trames de référence) peuvent être utilisées pour de la prédiction inter. Les trames de référence sont organisées dans une liste (ou deux) par poc. Une trame 5 est constituée d un nombre de macroblocs (des blocks de pixels), chacun d eux contenant luma (Y) et deux 8x8 chroma (Cb et Cr). Dans chaque trame, les macroblocs sont ordonnés en tranches de gauche à droite et de haut en bas. La longueur d une tranche varie de un à tous les macroblocs de la trame. Une trame peut contenir de une à plusieurs tranches de différent types (I, P, B, SP, SI). Les tranches I ne contiendront que des macroblocs I, les tranches B que des macroblocs B et I, les tranches P que des macroblocs P et I. SP et SI sont développées plus bas (cf. section 3.5.1). Chaque macrobloc dans une tranche est prédit à partir de données déjà encodées et reconstruites (Quantification inverse, IDCT) ; on garanti ainsi l utilisation de la même prédiction que le décodeur. Le codeur d entropie va recevoir la différence (le résidu) entre le bloc courant et la prédiction. Les macroblocs I sont prédits en utilisant les blocs de la tranche cou- 5 En yuv 4 :2 :0.

36 3.3 Baseline Profile 28 rante, les macroblocs P sont prédits en utilisant une à plusieurs trames antérieures, les macroblocs B quant à eux, sont prédits à partir d une ou deux trames, futures et/ou antérieures. Afin d augmenter la robustesse de la séquence, les trames sont souvent regroupées dans un ordre récurrent de modes (GOP 6 ). Figure 3.2 Hierarchie des données dans un codec (extrait de [26]). 3.3 Baseline Profile Tranche Un flux vidéo conforme au profil baseline contient des trames I et P. Une trame sera marquée par un délimiteur afin de spécifier le type de tranches permises. Pour 6 De l anglais Group Of Pictures.

37 3.3 Baseline Profile 29 des raisons de robustesse, une tranche peut être marquée comme redondante. En cas de perte de la tranche (lors du transport, par exemple) on utilisera l information des tranches voisines. Deux autres fonctions sont prévues pour diminuer la sensibilité aux erreurs : l ordonnancement flexible des macroblocs (FMO) et l ordonnancement arbitraire des tranches (ASO) Prédiction inter En mode inter, la prédiction d une trame est faite à l aide d une à plusieurs trames de référence. Les améliorations d AVC par rapport aux anciens codec comportent l utilisation de blocs de taille plus petite (4x4) et l utilisation de vecteur de déplacement précis (jusqu au huitième de pixel sur les blocs chroma). Figure 3.3 Une trames et son résidu avec la suivante. Figure 3.4 Vecteur de déplacement de la figure 3.3.

38 3.3 Baseline Profile Choix de partitionnement Lorsqu un macrobloc est traité, il est partitionné en blocs de plus petite taille. Le mode défini le choix de partitionnement du macrobloc. Une fonction de choix de partitionnement examine tout les partitionnements possibles et choisi le mode minimisant le plus la taille du résidu par rapport aux surcoût de codage des vecteurs de déplacement (MV) (voir l annexe I). Le partitionnement est fait sur le bloc luma (les deux chroma suivront le même mode que celui choisi pour le luma, mais possèderont des MV propres). Un mode skipped définit un macrobloc qui ne sera pas traité. Figure 3.5 Modes de partitionnement pour un macrobloc et ses sous-macroblocs Interpolation de pixel Le standard AVC permet des recherches très fines dans les dernières itérations de l estimateur de mouvement. Le vecteur de déplacement peut être fractionnaire, atteignant une précision du quart de pixel pour le luma, soit jusqu au huitième de pixel pour les chroma. Il faut donc interpoler le bloc de référence jusqu au huitième de pixel. Un filtre FIR 7 possède une bande passante, dans laquelle le signal passe avec peu d atténuation, ainsi qu une bande de blocage dans laquelle le signal est fortement atténué. Entre ces bandes, on trouve les bandes de transitions. L obtention d un tel filtre se fait par convolution d une fonction linéaire avec plusieurs impulsions de dirac. Les demi-pixels d un bloc luma sont interpolés en utilisant un filtre FIR à 6 entrées, les quarts de pixels sont une moyenne des demis obtenus précédemment. 7 De l anglais Finite Impulse Response.

39 3.3 Baseline Profile 31 En se basant sur la figure 3.6 et les équations 3.1 nous dérivons les valeurs des pixels. Figure 3.6 Interpolation d un bloc luma au quart de pixel. b1 = (E 5F + 20G + 20H 5I + J) s1 = (K 5L + 20M + 20N 5O + P ) b = Seuil( b1+16) 32 h1 = (A 5C + 20G + 20M 5R + T ) h = Seuil( h1+16 ) 32 j1 = aa 5bb + 20b1 + 20s1 5gg + hh j = Seuil( j1+515 ) 1024 a = G+b+1 2 d = G+h+1 2 f = b+j+1 2 e = b+h+1 2 (3.1) avec 0 si x < 0 Seuil(x) = x si 0 < x < si x > 255 En utilisant la figure 3.7 les huitièmes de pixel d un bloc chroma sont interpolés selon l équation 3.2. a = (8 d x)(8 d y )A + d x (8 d y )B + (8 d y )d y C + d x d y D (3.2)

40 3.3 Baseline Profile 32 Figure 3.7 Interpolation d un bloc chroma au huitième de pixel Vecteurs de déplacement La recherche des vecteurs de déplacement est expliquée au chapitre 5. Si un macrobloc est partitionné en 16 blocs (4x4), 24 vecteurs de déplacement (MV) vont être codés. Les MV sont souvent fortement corrélés à leurs voisins. Nous utiliserons cette propriété pour prédire le MV du bloc actuel à l aide de MV de blocs voisins déjà encodés. L encodeur d entropie recevra un vecteur différence (MVD), soit la distance euclidienne entre la prédiction (MVp) et le vecteur trouvé. Figure 3.8 Indexage des blocs voisins et prédiction médiane. Les blocs voisins sont indiqués selon la figure 3.8. Dans le cadre de voisins hétérogènes (A segmenté en 4 blocs 8 4), on sélectionne le bloc le plus proche de l origine du bloc courant, soit le coin supérieur gauche. Chaque bloc encodé possède son bloc de référence, si nous examinons un bloc en bordure de tranche ses blocs voisins peuvent avoir des blocs de référence différents. Lorsque les références sont identiques, le MVp est obtenu par calcul de la médiane des MV voisins (équation 3.3). Si seulement un de ses voisins à la même référence que lui, le MVp est alors égal à ce MV voisin. Les blocs 8 16, 16 8 et skipped sont calculés différemment.

41 3.3 Baseline Profile 33 Les blocs 8 16 auront un MVp égal à A ou C en fonction de leur position dans le macrobloc, les 16 8 un MVp égal à A ou B, les skipped un MVp égal à 0. MV p(x, y) = { Mediane(MVA (x), MV B (x), MV C (x)) Mediane(MV A (y), MV B (y), MV C (y)) (3.3) avec Mediane(x, y, z) = x + y + z min(x, min(y, z)) max(x, max(y, z)) Prédiction intra En intra, la prédiction d un bloc I est faite avec les blocs voisins précédemment encodés et reconstruits. Il y a deux méthodes de prédiction : l intra et l intra 4 4. La première contient 4 modes de prédiction et la seconde en contient neuf. Généralement, les deux méthodes et tous leurs modes sont évalués et l on sélectionne la meilleure combinaison. Figure 3.9 Pixels utilisés lors de la prédiction intra 4 4. Les modes disponibles dépendent des pixels voisins disponibles (voir 3.9). Si des pixels voisins manquent (cas du premier bloc de la trame), des valeurs par défaut sont utilisées. Dans la plupart des cas, le calcul du mode se fait par interpolation des voisins selon un angle défini en figure Pour l intra 4 4, huit directions ont été choisies. Si nous prenons le premier mode (direction verticale), les pixels {a,b,c,...,p} sont interpolés verticalement, ainsi a,e,i,m reçoivent la valeur de A. Un calcul plus complexe est utilisé en mode 7 : l angle d interpolation est de 11π 8 radians, ce qui nous donnera par exemple a = A+B et e = A+2B+C. Deux autres 2 4 modes différents sont aussi utilisés. En mode DC les pixels prennent la moyenne des valeurs de A, B, C, D, I, J, K et L. En mode PLANE, la prédiction est

42 3.3 Baseline Profile 34 Figure 3.10 Direction d interpolation pour l intra 4 4 avec numéro de mode correspondant. un dégradé oblique, calculé par moyenne des valeurs obliques (une moyenne des deux sens de la direction mode 3 ). Afin de minimiser l information, on encodera le mode choisi comme différence des modes des blocs voisins ; un codage prédictif similaire aux MVp est utilisé. (a) Vertical (b) Horizontal (c) DC (d) Plane Figure 3.11 Modes d interpolation en intra Trames de référence En mode inter, le choix des trames de références est crucial. Un processus se charge de reconstruire les trames précédemment encodées et les conserve dans un tampon (DPB). Une liste de victimes possibles est mise à jour en fonction des trames nouvellement construites. Lors de la reconstruction, le numéro de trame (poc) est ajouté à la liste et l on marque l entrée (inutilisable, court-terme, longterme, non utilisée). Un tri selon certains critères est effectué (ancienneté, numéro de trame,...). Une fenêtre sélectionne le nombre de trames à court et long terme utilisables, la taille optimale étant 5 (voir [38]). Des trames de synchronisations IDR

43 3.3 Baseline Profile 35 intra 4 4 Nom Calcul des pixels Mode { 0, 1, 3, 4, 5, 6, 7, 8 } Angle de la figure 3.10 Extrapolation à partir de l angle fourni en Fig Mode 2 DC Tout les pixels sont la moyenne de A, B, C, D, I, J, K et L intra Nom Calcul des pixels Mode 0 Vertical Extrapolation à partir des pixels supérieurs (A, B, C,...) Mode 1 Horizontal Extrapolation à partir des pixels de gauche (I, J, K,...) Mode 2 DC Moyenne des pixels supérieur et de gauche Mode 4 Plane Fonction linéaire créant un dégradé oblique Tableau 3.2 Modes disponibles de partitions en intra 16 et intra 4. (par exemple, dans le cas d une nouvelle séquence vidéo) permettent de marquer les entrées précédentes comme non utilisées Filtres Il est courant de faire du filtrage post-décompression pour améliorer l image. Un des artéfacts les plus visibles dans les techniques basées sur les blocs est l apparition de blocs dans l image décodée. De nombreux filtres débloquant atténuent le contour de ce bloc par lissage de pixels. AVC inclus un filtre débloquant lissant les trames lors de la reconstruction. Ceci permet une prédiction de meilleure qualité apportant des gains dans le bit-rate de typiquement 5 à 10 %, sans diminution de qualité. Figure 3.12 Filtrage débloquant : sans filtrage à gauche, avec filtrage à droite.

44 3.3 Baseline Profile Transformation Dans AVC, deux transformées ont été rajoutées dans le standard, variantes de la transformée discrète de Walsh-Hadamard (DWHT) ayant pour effet la simulation d une DCT à moindre coût. Après la DCT, les coefficients significatifs se retrouvent concentrés dans le coin supérieur gauche du bloc. Le premier coefficient est la composante continue du bloc. AVC transforme tous les blocs 4 4 à l aide d une DCT. En outre, une DWHT est appliquée aux quatre coefficients DC des deux blocs chroma. Les macroblocs intra 16 bénéficient aussi d une DWHT sur les 16 coefficients DC. Figure 3.13 Choix des coefficients pour la DWT. Un nouveau critère de minimisation de l erreur pour l estimateur sera alors choisi dans le cas d un bloc DC. L estimateur se basera sur la somme absolue des transformées de différence (SATD). La Somme Absolue des Transformées de Différence (SATD) D i,j = Original i,j Prédiction i,j (3.4) SAT D = D i,j 2 (3.5) i=0 j= Quantification Pour la quantification des coefficients de transformée, AVC choisi pour chaque macrobloc parmi 52 seuils. Le paramètre de quantification (QP) choisi est sauvé

45 3.4 Main Profile 37 avec le macrobloc. Lorsque l on incrémente QP de 1, le pas de quantification augmente de 12,5% Réordonnancement Dans le cas de l intra 16, après la transformation d Hadamard et la quantification, l énergie des 16 pixels DC sera concentrée sur les premiers blocs 4 4. Les blocs 4 4 en bas à droite auront généralement des zéros comme coefficients DC. Afin d augmenter les performances du codeur d entropie, on réordonne le macrobloc. Le premier bloc du macrobloc sera le bloc -1 de la figure 3.13, les blocs suivants seront créés en utilisant les coefficients restants. Par exemple, le second bloc sera construit à l aide des 15 coefficients du premier bloc et du second coefficient du second bloc, et ainsi de suite Codeur d entropie Dans le profil baseline, un codeur d entropie dynamique (CAVLC) s occupe uniquement des résidus transmis. Des tables prédéfinies sont utilisées pour le codage des autres informations comme, par exemple, les en-têtes de séquences, de trames ou des tranches, ou encore, en ce qui concerne les macroblocs : les modes de prédiction, le découpage choisi, le paramètre de quantification et les MVD. Le codeur démarre avec des tables de Huffman pré-calculées et les affine en fonction des statistiques courantes. Ainsi, un symbole peut changer de code si sa fréquence dépasse un certain seuil. 3.4 Main Profile Ce profil, plus fourni en services de qualité, est bien adapté pour la télédiffusion et le stockage haute résolution de données Tranches B Dans une tranche B, chaque bloc d un macrobloc utilisera une ou deux trames de références antérieures et/ou futures en fonction des trames disponibles dans le

46 3.4 Main Profile 38 tampon. Deux listes de références sont tenues à jour par le processus de reconstruction. La première liste trie les éléments par rapport au numéro de trame courant ; d abord elle sépare les trames antérieures des futures, place les antérieures devant les futures et place en première position la trame la plus proche. Les autres ne sont pas triées. Une opération similaire est faite sur la deuxième liste. Les victimes sont choisies par l utilisation d une table de codage de symboles Exp-Golomb ; on lui envoie le début des deux listes, elle renvoie ensuite l indice commun aux deux listes dont la distance par rapport à la trame courante est la plus courte. Des options de prédiction supplémentaires sont disponibles : les modes bi et direct. En mode bi, un bloc de référence est construit grâce aux deux listes. On effectue deux prédictions temporaires en prenant la première trame de référence dans chacune des listes. La prédiction finale est obtenue à partir de la moyenne des deux prédictions temporelles. Chacune de ces deux prédictions est codée à l aide des voisins du bloc courant, bloc ayant la même prédiction temporelle (cf. section ). En mode direct, le MV n est pas fourni. Il faut le calculer à partir des listes avec un système de voisins. Par la lecture d un flag, on pourra calculer les règles choisies pour le calcul du MV Prédiction pondérée Une série de coefficients peuvent être appliqués aux blocs de référence avant de calculer le résidu. Ceci permet un gain dans le cadre de scènes vidéo fondues. L information sera encodée dans l en-tête de la tranche Video entrelacée Une trame peut être soit encodée comme une unité, soit séparée en deux champs (fields) entrelacés pour les encoder séparément. L encodage de champs est très efficace si nous avons une trame I (cf.3.2), car, après séparation, le deuxième champ peut faire usage d une compensation de mouvement avec le premier champ comme référence. Le codage en mode champ est souvent utilisé lorsqu une séquence montre un grand déplacement horizontal. AVC supporte au niveau des macroblocs un changement à la volée entre le codage en mode trame et mode champ. Les macroblocs sont regroupés par paires dans une trame, si l on passe en mode champ, la compensation intra ou inter sera modifiée en conséquence, utilisant les lignes entrelacées pour former des blocs de références.

47 3.5 Extended Profile CABAC L efficacité du codeur d entropie peut être augmentée si l on utilise un encodeur arithmétique binaire à contexte variable (CABAC). De cette manière, on approche l entropie par l assignation de codes rationnels à des symboles fortement probables. De plus, la mise-à-jour des probabilités conditionnelles se fait uniquement par comparaison et bit shifting. En général, l encodeur CABAC permet un gain de 10 à 15% par rapport à CAVLC([76]). 3.5 Extended Profile Ce profil est bien adapté au streaming vidéo ( 8 ) Tranches SP et SI Le but des tranches SP et SI est de faciliter l accès aléatoire aux trames en phase de décompression d une vidéo. Plus précisément, si l on souhaite changer de flux entre deux vidéos, nous avons besoin d insérer des tranches I. En effet, si nous avions changé de flux entre deux trames P, la prédiction serait fausse et une dégradation de la qualité se ferait sentir au fil du temps. Le problème est qu une tranche I possède beaucoup d informations en comparaison avec une trame P. Une tranche intermédiaire et commune sera construite à l aide des deux flux et insérée dans chacun d eux pour permettre cette transition. Une autre utilité des trames SP est qu elles permettent aussi de passer d une vidéo compressée avec un débit particulier à un autre pendant le streaming. En d autres mots, elles offrent la possibilité de faire du fastforward des images vidéo en ne parcourant que les tranches SP. Les tranches SI suivent le même principe, il s agit de tranches créés en intra 4. Souvent, les trames SP et SI sont encodées dans un troisième flux distinct. Une extension d AVC nommée SVC, rajoute de l information pour obtenir une vidéo scalable, débitant des données en fonction du flux demandé. 8 Le streaming vidéo ou flux continu, est la possibilité de visionner un flux vidéo en même temps qu il est distribué par voie digitale à l utilisateur.

48 CHAPITRE 4 ENVIRONNEMENT D EXÉCUTION 4.1 Introduction Comme nous l avons dit dans l introduction, les systèmes de calcul se parallélisent depuis plusieurs années déjà (tant au niveau du traitement des instructions qu au sein même des processeurs). Ainsi les algorithmes distribués de terminaison, de synchronisation et d ordonnancement permettent un calcul réparti sur plusieurs machines distantes ; les processeurs superscalaires à cœur monolithique laissent la place aux unités à cœur multiples ; et les puces dédiées se dotent d unités d exécutions parallèles. En outre, les processeurs actuels intègrent deux types de parallélisme interne : (1) le parallélisme des instructions, où plusieurs instructions sont exécutées dans un seul cycle machine et (2) le parallélisme des données, où une instruction permet le traitement de plusieurs données. Dans la suite de ce mémoire nous avons adopté l approche suivante : d une part, analyser les différents niveaux de parallélisme d un processeur actuel (chapitre 4) et, d autre part, analyser et comparer les algorithmes existants pour l estimation de mouvement, étape de la compression typiquement gourmande en puissance de calcul lors de la compression d image (chapitre 5). Le but de cette approche est de concevoir des algorithmes optimisés pour l étape d estimation de mouvement d un flux vidéo, et par extension, de permettre le visionnage en temps réel de vidéos compressées (chapitre 6). Bien sûr, tout ceci se conçoit uniquement dans le cadre bien précis de l architecture décrite ci-dessous. 4.2 Architecture ciblé L architecture ciblée sera l Intel R X86. Pour nos besoins, nous utiliserons deux ordinateurs composés de processeurs à microarchitecture voisine, soit un Intel R Pentium R M 750, similaire au Pentium Intel R Pentium R 4 2.6C. Ces modèles de micro-processeur représentent à notre connaissance la plus grande partie du marché de la micro-informatique. Si nous suivons la taxonomie de Flynn, les deux

49 4.2 Architecture ciblé 41 processeurs sont des SISD/SIMD (single instruction, single/multiple data). Des extensions nommés MMX, SSE et SSE2 permettent l utilisation de certaines unités d exécutions en mode vectoriel. Ce choix d architecture est donc doublement justifié : il correspond à un matériel facilement disponible sur le marché et il permet l exploitation d algorithmes vectoriels 1. Plus d information peut être obtenue dans [29] et [30]. Figure 4.1 Vue d un Pentium R M et d un Pentium R Aperçu des microarchitectures Depuis les débuts d Intel R en architecture 32 bits, l accent à toujours été mis sur l interopérabilité ascendante. De nombreux choix d architecture en découlent, et l on sent encore aujourd hui le poids de l option prise pat Intel R qui à toujours privilégié la montée en fréquence dans le design de nouvelles générations, avec comme plafond la précision de gravure. Un bon exemple est la génération des micro processeurs Pentium R 4. Pour soutenir des fréquences plus hautes, Intel R a allongé ses pipelines, ce qui a augmenté de manière considérable la demande énergétique des processeurs 2. La dissipation thermique n arrivant pas à suivre, Intel R a pris un tournant décisif en matière de design de ses microprocesseurs. Aujourd hui l accent est mis sur la parallélisation et la consommation électrique comme le démontre le modèle Intel Pentium R M et tous ses successeurs. 1 Un algorithme vectoriel est un algorithme qui permet d obtenir un vecteur de sortie en n appliquant, sur un vecteur d entrée, que des opérations vectorielles. Cet algorithme peut alors être implémenté en parallèle, en se servant des opérations sur les vecteur de bits disponibles dans les processeurs, donnant lieu à des calculs très efficaces. 2 La consommation des transistors étant proportionnelle à la fréquence, aux capacités parasite et au carré de la tension.

50 4.2 Architecture ciblé Pentium R 4 Le Pentium R 4 (P4) est un processeur à jeu d instructions CISC mais à cœur d exécution RISC. Il est basé sur l architecture Netburst. Il peut décoder, exécuter et retirer jusqu a trois instructions par cycle machine. Les principales caractéristiques du modèle de P4 retenu sont : une fréquence interne de 2.6 Ghz, une pipeline de 20 étages et la longueur d une instruction qui se situe entre 8 et 108 bits. Le bus externe fonctionne à 800 mhz (4 x 200 mhz). Le noyau d exécution est séparé en deux, les nombres entiers d un côté et les nombres réels ainsi que les unités vectorielles de l autre. Le P4 intègre deux niveaux de cache. Le premier niveau (L1) est séparé en deux ; la cache instructions (trace cache, [75]) peut contenir jusqu à instructions décodées (µops), la cache données, elle, fait 8 Ko. Le deuxième niveau (L2) a une taille de 512 Ko. Figure 4.2 Architecture du Pentium R 4 (northwood).

51 4.2 Architecture ciblé Pentium R M Le Pentium R M (PM) est basé sur l architecture P6 du siècle dernier 3. Cette architecture est peu consommatrice d électricité et offre un meilleur débit en régime normal (voir ) malgré une fréquence interne plus faible que celle du P4, soit 1.86ghz. Les principales améliorations qui nous intéressent sont un bus externe à 533 mhz (4 x 133 mhz), une importante utilisation de mémoire cache (2 Mo en L2 et 64 Ko en L1), un pipeline entre dix et vingt étages 4 et une prédiction de branchement supérieure à celle utilisée dans le Pentium R 4 (voir ). Les autres améliorations concernent l économie d énergie. Figure 4.3 Architecture du Pentium R M (dothan). 3 Ce choix peut paraître étrange à première vue, mais il est guidé par la taille du die du P3 (très petite), ce qui permet une fabrication plus facile de processeur multicœur, comme le démontre le successeur du PM : l Intel R Core Duo. 4 Certaines informations concernant l architecture du PM n ont jamais été divulguées par Intel R. Elles ont été découvertes lors de nombreuses heures de recherche sur des forums spécialisés. Néanmoins, une approche prudente à été prise quant à l utilisation des informations recueillies.

52 4.2 Architecture ciblé Parallélisme des instructions L architecture choisie est du type super-scalaire et super-pipeline. Nous allons en exposer ses forces, ainsi que ses limitations. En nous basant sur certains ouvrages de référence ([34], [27] et [36]) nous allons dégager des pistes pour gagner en efficacité. Ceci nous servira pour l implémentation de notre algorithme au chapitre Cycle machine Nous expliquons brièvement les étapes de traitement sur un Pentium R 4 afin de mieux comprendre où se trouvent les goulots d étranglements. Le Pentium R M étant relativement proche, les mêmes remarques d optimisation sont valables. Nous pouvons résumer un cycle machine à l aide de la figure 4.2 : 1. (2 clocks) Le pointeur d instruction suivante est lu dans la trace cache (TC) (2 clocks) 6 L instruction est décodée en micro-opération(s) (µops). Elle(s) peut(vent) être déja disponibles dans la TC. 3. (1 clock) L unité de renommage/allocation latch jusqu a 3 µops : une lecture, une écriture et une manipulation. 4. (1 clock) L unité d allocation vérifie les ressources nécessaires et disponibles avant le renommage des registres utilisés. 5. (2 clocks) L unité de renommage renomme les registres logiques (EAX, MM0, etc.) en registres physique. 128 registres physiques sont utilisés dans l architecture netburst. Le renommage enlève les fausses dépendances, ce qui améliore le parallélisme des exécutions. 6. (1 clock) Les µops sont latchées par la station de réservation (Queue + Ordonnanceur), La queue servira au retirage des instructions dans l ordre. 7. (3 clocks) L ordonnanceur détecte dans la queue les dépendances et ressources disponibles et assigne une µop dans la queue à une unité d exécution. 5 Une comparaison d adresse a lieu dans l historique des branchements (BTB). Si l instruction fait partie d une branche déjà prédite (déjà exécuté ou lue en avance), une entrée existe et les µops se trouvent dans la TC. Si l entrée n existe pas, une adresse est mise sur le bus de la cache L2. Un délai supplémentaire sera nécessaire pour le fetch et le décodage. 6 Une remarque doit être faite sur les performances du PM ; en mode vectoriel l ALU travaille sur des vecteurs de 16 octets, mais l architecture du moteur d exécution utilise un bus de 64 bits, nécessitant deux décodages au lieu d un. Malgré les trois décodeur de l architecture P6, seul le premier gère des instructions complexes (plusieurs µops), il en découle un temps de décodage beaucoup plus long.

53 4.2 Architecture ciblé (2 clocks) L ordonnanceur envoi les µops aux unités d exécution. 9. (2 clock) Le processeur lit les registres et retire la µop de la queue. Si une instruction est terminée (dernière µ Op exécuté), le contenu est écrit en mémoire. 10. (1 clock) Les unités d exécution font leur travail. 11. (1 clock) Les flags sont calculés. 12. (1 clock) La table des prédictions de branchement (BTB) est mise à jour 13. (1 clock) Le résultat de l instruction est stocké dans la trace cache et ecrite en L2 au besoin Moteur d exécution L ordonnanceur envoie les µops aux unités d exécution au travers de ports (Figure 4.4). En fonction de la µop, l unité d exécution va prendre un certain temps à compléter la requête. Deux mesures sont utilisées pour quantifier une instruction : la latence et le débit en régime. La latence désigne le nombre de cycles d horloge nécessaires pour exécuter une instruction. Le débit désigne le nombre de cycles d horloge à attendre pour exécuter une instruction du même type. Ces deux informations ne peuvent servir à un ordonnancement optimal, au vu du caractère variable des informations (souvent une fourchette de valeurs) et par rapport à la puissance de calcul demandée (l ordonnancement est un problème NP-CO). Néanmoins, ces deux mesures peuvent servir à l optimisation de longues chaînes d instructions dépendantes. Nous dégagerons les points importants au niveau de la sélection et de l ordonnancement des instructions : Privilégier les instructions contentant peu de µops (les instructions complexes sauvent des registres mais prennent du temps à décoder) et possédant de petits temps de latence ; Veiller à utiliser des shifts/add à la place de multiplications ; Ne pas bloquer un registre pour des opérations avec des constantes, les laisser en mémoires et utiliser tous les modes d adressage ; Ne pas travailler sur des parties de registres (AX,AH,AL) ; Calculer le plus tôt possible les adresses.

54 4.2 Architecture ciblé 46 Figure 4.4 Unités d exécution et leur port associé sur un Pentium R Accès mémoire Si l accès mémoire est fait de manière efficiente, nous arrivons à obtenir des performances très proches de celles d une mémoire cache infinie [65]. Les architectures dédiées jouent sur la hiérarchie des caches, les tailles et les latences pour optimiser les accès. De bonnes règles de design sont citées dans [10]. Dans notre cas, nous sommes limités à jouer sur les moments et sur les règles d accès. En anticipant les besoins du CPU, par l utilisation d accès anticipés (prefetch) et en organisant les données par ordre d exécution, nous pouvons diminuer les pénalités qui découlent lors d un cache miss Rapatriement des données Trois mécanismes de recherche des données existent. Le premier rapporte automatiquement les données de la mémoire vive vers la L2. Il se déclenche lors d un double cache miss (séquentiel) dans la L2 avec une distance de moins de 256 octets. Une recherche aura aussi lieu pour avoir 256 octets de données disponibles par rapport à l adresse courante. Le deuxième mécanisme rapporte automatiquement des données par bloc de octets (P4 PM) à partir de l adresse courante en fonction des prédictions de branchement (voir ). Enfin, le troisième s occupe du rapatriement des données lors d un cache miss dans la L1. Les données sont rapatriées par lignes entières, soit Octets. Il peut être forcé par software. Le calcul théorique des moments de prefetch dépasse largement le cadre de ce mémoire, nous utiliserons donc un profiler décrit en pour nous aider à choisir.

55 4.2 Architecture ciblé 47 Niveau Capacité Taille des lignes Latence (clocks) Intel R observée 7 Type d écriture L1 data P4 8 Ko 64 octets 2 2 write through L2 P4 512 Ko 64 octets 7 7 write back L1 data PM 32 Ko 64 octets 3 3 write back L2 PM 2048 Ko 64 octets 5 8 write back Tableau 4.1 Performances de la mémoire cache Alignement des données Lors d une lecture de la mémoire vers un registre, des vecteurs de 4 ou 16 octets sont chargés. Les instructions permettent de charger des vecteurs de 16 octets n importe où en mémoire. Le rapatriement dans les hiérarchies se faisant par blocs de tailles différentes, si le vecteur demandé chevauche deux blocs mémoire, un nombre important de cycles supplémentaires sera nécessaire avant d obtenir l information. Nous tâcherons dès lors de faire des accès alignés, c est-à-dire multiples du vecteur que l on traitera (4 en GPR, 16 en SSE2). Nous inférons les règles suivantes : Travailler sur des adresses mémoire modulo la taille des registres, ce qui limite les surcoûts de non-alignement. Employer des prefetchs dans les fins de boucles et en tenant compte des données. Exploiter des données par bloc de 64 octets afin de maximiser l utilisation des lignes Prédiction de branchement Une unité de prédiction de branchement anticipe les instructions futures pour éviter un arrêt du pipeline, elle les décode à l avance et les place dans la trace cache. Les deux processeurs ont un système de prédiction des branchements. Seuls les irets, far calls et interruptions softwares ne sont pas prédictibles. Lorsqu une instruction de branchement est décodée, la direction de la branche est connue. S il n y a pas d entrée valide dans l historique (BTB), l algorithme en jeu utilise une règle statique : la direction négative est toujours prise. Lors du retirage de l instruction, la BTB sera mise à jour en fonction de la justesse de la prédiction. Les prédictions futures se baseront sur la BTB.

56 4.2 Architecture ciblé 48 Le Pentium R M possède en plus un détecteur de boucle et un prédicteur de branchement indirect 8. Une pile de retour a été implémentée dans le prédicteur, ce qui améliore les performances d un déroulage de boucle avec appel de fonction. Au retirage, les instructions appartenant à la même branche sont mises en série dans la cache, ce qui améliore les performances. Nous en concluons qu il faut : Utiliser la prédiction statique de retour en arrière pour ré-arranger les sauts conditionnels ; Ne pas dérouler ni recopier les fonctions d une boucle suffisamment longue et à grand nombre d itérations Parallélisme des données Depuis les années 90, les processeurs Intel R intègrent un coprocesseur arithmétique qui se charge des opérations en virgule flottante. Les unités d exécution savent travailler sur des opérandes pouvant aller jusqu à 128 bits de long. Bien souvent les données traitées sous exploitent les unités d exécution à cause de leur taille : une addition sur 8 bits mettra autant de temps que celle sur 128 bits. Afin d utiliser les unités à plein régime, de nombreuses architectures intègrent des extensions permettant un contrôle et des opérations vectorielles. La plupart des constructeurs proposent aujourd hui un jeu d extension comparable à celui d Intel R. Les techniques analysées ici, pourront facilement être réutilisées sur d autres architectures. Figure 4.5 Exécution d une instruction sur une unité vectorielle. 8 Le détecteur de boucle sauvegarde plus d information et permet une meilleure prédiction du moment de sortie de la boucle grâce à une série de compteurs. Le prédicteur traite aussi les branchements indirects ; soit les branches dont l adresse de saut est calculée pendant l exécution. En plus de l historique, des probabilités sont assignées en fonction des conditions de saut (une sorte de snapshot).

57 4.2 Architecture ciblé Extensions SIMD Les deux processeurs étudiés proposent trois extensions SIMD : MMX, SSE et SSE2. MMX donne accès en programmation à 8 registres de 64 bits (MM0, MM1,..., MM7) et supporte des opérations sur des entiers codés sur 8 (byte), 16 (word), 32 (doubleword) et 64 bits (quadword). Toute I/O se fait par adressage indirect du GPR (general purpose register). SSE rajoute 8 registres de 128 bits (XMM0,..., XMM7), la possibilité de contrôler la mémoire (prefetch, ordonnancement, etc.), ainsi que des opérations sur des réels codés sur 32 bits. Par ailleurs, des instructions supplémentaires exécutables par MMX sont rajoutées. SSE2 supporte les opérations sur des réels de 64 bits et des entiers codés sur 8 (byte), 16 (word), 32 (doubleword), 64 bits (quadword) et 128 bits (double quadword). Des instructions de conversion sont aussi rajoutées. En plus des instructions classiques (transfert, logique, décalage et comparaison), le jeu permet des opérations arithmétiques en deux modes : warp around et saturé. En mode warp around, le report est ignoré, en mode saturé, le résultat prend la valeur maximale permise par le type de données, s il y a un overflow. Figure 4.6 Types d opérandes vectorielles sur un registre XMM.

58 4.3 Plateforme Plateforme La section précédente présentait le parallélisme disponible dans l architecture. Son exploitation, évidemment, dépend du code généré. Dans cette section nous allons présenter le code source utilisé pour l implémentation du standard AVC, le choix du compilateur employé et les outils qui ont servi à l optimisation du code. Nous détaillerons aussi le cadre de travail ( framework en anglais) et l API gestionnaire du flux vidéo Code source Une implémentation d AVC est disponible sur la page web d un des membres du JVT 9, le JM [79]. Son code source est très lisible, et n as pas été conçu pour la performance. Il est écrit en C et paraît facilement portable sur n importe quelle type de micro-architecture. Le programme démarre en ligne de commande et lit un fichier de configuration. De nombreux paramètres peuvent ainsi être modifiés, tels le nombre de trames de référence, les modes de partitionnement d un macrobloc, les tranches permises, etc. Un fichier de documentation[5] permet une compréhension des structures utilisées. De nombreux projets Open Source sur un encodeur AVC existent. Parmis ceuxci nous avons choisi le projet x264 [2]. Ce projet a l avantage de proposer un traitement vectoriel de certaines fonctions. Nous appliquerons l essentiel de notre analyse à ce codec ainsi qu au codec de référence fourni par le JVT. Des comparaisons seront faites avec le codec de référence pour démontrer la validité de l approche et le meilleur candidat sera optimisé en poussant l approche vectorielle un cran plus loin. Des librairies de traitement d image sont disponibles chez Intel R sous le nom de Intel R Performance Primitives (IPP,[28]). Bien que nous n ayons pas connaissance de leur contenu (boîte noire), nous nous en servirons pour faire nos comparaisons. Accessoirement, nous avons utilisé les résultats d un testbed comparant les encodeurs commerciaux dont les principaux résultats sont décrits à la section Joint Video Team

59 4.3 Plateforme Compilation Le choix du compilateur est crucial si nous voulons un programme performant utilisant le parallélisme intra processeur. Lors d une compilation, un programme peut être optimisé en taille ou vitesse. Comme notre but est clairement la vitesse, nous avons utilisé tous les flags appropriés sur les différents compilateurs C testés. Notre choix à été guidé par : La rapidité du code obtenu (calculé en nombre de trames par seconde encodées). La possibilité d utiliser de l assembleur inline dans le code C (via NASM, TASM ou MASM). La génération de code de débogage en mode assembleur. La disponibilité d une documentation. Un interfaçage facile dans un environnement de développement(ide). Trois compilateurs ont satisfait nos critères : GCC 4.1.1, Microsoft Visual C R et Intel R C Le code généré par l Intel R se révéla le plus rapide pour le type d application concernée 10. Le compilateur Intel R supporte les librairies intrinsics qui codent les instructions assembleur en C, ce qui a pour avantage de rendre la programmation plus simple et le code plus portable. Une autre fonction intéressante du compilateur est la vectorisation automatique du code ; le compilateur est capable de dénicher le parallélisme de données dans du code en langage C et d utiliser les extensions SIMD lors de la traduction en langage machine. Le choix du compilateur influence le choix de la plateforme : nous avons utilisé le système d exploitation Microsoft Windows R sp2(winxp). Pour nous aider lors de l optimisation du code généré, un outil spécifique de simulation et d analyse a été employé (IntelVtune). Cet outil permet un échantillonnage du processeur en temps réel et fournit des statistiques sur le fonctionnement d un programme. Ceci nous a permis l identification des goulots d étranglement et l analyse des instructions au niveau assembleur d une fonction particulière. Grâce à cette analyse minutieuse, nous avons pu modifier l usage du pipeline, l ordonnancement des instructions, les accès à la cache et l usage des différentes unités d exécution par les algorithmes fps pour l Intel R, contre 6.20 pour Visual et 6.12 GCC.

60 4.3 Plateforme Directshow Directshow est l API gestionnaire du streaming multimédia sous Windows. Cet API permet le rendu et le stockage des vidéos à la demande d un programme ou d un utilisateur. Cet API fonctionne sur des graphes de filtres (voir [63]). On choisi d abord un input et un output, puis l on intercale des procédures de traitement (des filtres) sur le flux. L input et l output peuvent être un fichier, un appareil d acquisition, l entrée d un programme de visualisation, etc.. Pendant le processus d exécution, le graphe est parcouru et les fonctions de traitement sont appelées via le registre Windows. Cette API sera utilisée pour tester notre codec en conditions réelles et faire des comparaisons subjectives lors du visionnage du résultat. Figure 4.7 Vue d un Graphe de filtres dans DirectShow.

61 CHAPITRE 5 ESTIMATION DU MOUVEMENT 5.1 Introduction L estimation du mouvement (ME 1 ) est le processus d analyse permettant une compensation du mouvement. Cette analyse a seulement lieu dans l encodeur et elle influence la performance totale de ce dernier 2. Le titre de cette étape de la compression prête à confusion et ne reflète pas de manière précise son contenu. Sur les premiers codecs, l estimation du mouvement était faite par rapport à la trame précédente. Un bloc de la trame courante était comparé avec tout ceux de la trame de référence. Un vecteur de déplacement (MV) exprimait le déplacement constaté pendant que le processus de compensation reconstruisait la trame à l aide de la trame précédente, des vecteurs obtenus et des résidus (le résidu étant la différence entre le bloc courant et le bloc trouvé). Dans la norme AVC, l estimation du mouvement peut avoir d une à plusieurs trames de référence. Ces références peuvent être des trames antérieures, des trames futures 3, un mélange d antérieures et de futures ou même une somme pondérée de trames. La trame courante peut aussi servir de référence, que ce soit pour faire une recherche de bloc ou pour extrapoler le vecteur courant à l aide des vecteurs des blocs voisins déjà encodés. Dans les sections qui suivent, nous décrivons les différents algorithmes d estimation de mouvement. Une étude approfondie des algorithmes employés dans les deux softwares de références est présentée. Nous choisirons ensuite ceux pouvant être implémentés sur une machine vectorielle pour optimisation. 1 De l anglais Motion Estimation. 2 L estimation du mouvement dans AVC dépasse en moyenne les 50% du temps de calcul de l encodeur, voir le chapitre 5. 3 AVC n encode pas les trames dans l ordre temporel, une trame de référence est toujours une trame déjà encodée.

62 5.2 Algorithmes de recherche Algorithmes de recherche L objectif d un algorithme d estimation de mouvement est de trouver, au sein de la trame de référence, le bloc minimisant l énergie du résidu. Comme nous l avons vu, le critère de minimisation est exprimé en somme absolue des différences (SAD), carré de somme des différences (SSD) ou somme absolue des transformées de différence (SATD) selon le type de bloc traité (voir la section 2.4.1). De plus, cette recherche peut être faite au huitième de pixel près, ce qui demande un temps de calcul considérable. Dans AVC, le choix du bloc de référence est traité comme un problème d optimisation. Une fonction de coût lagrangienne minimise le poids du résidu par rapport au coût de codage du MV. Ceci peut amener à choisir un minimum local avec peu de déplacement, au détriment d un minimum global, avec plus de déplacement. La zone de recherche (fenêtre) dans la trame de référence varie en fonction de l algorithme employé. Habituellement cette fenêtre est centrée autour du bloc courant et a généralement une forme carrée (avec M = u = v sur la figure 5.1). Afin de mieux comprendre l évolution des algorithmes de recherche, nous allons décrire les familles d algorithmes et leurs individus les plus intéressants, c est-àdire ceux minimisant les étapes de comparaison et donnant de bons résultats en comparaison avec une recherche exhaustive. Une analyse des complexités, des performances qualitatives et des temps de calculs suivra. Figure 5.1 Fenêtre de recherche dans un algorithme d estimation du mouvement.

63 5.2 Algorithmes de recherche Recherche exhaustive Lors d une recherche exhaustive (Full Search, (FS)), tout les blocs candidats de la fenêtre courante sont examinés. C est la méthode la plus simple, donnant les meilleurs résultats, mais c est aussi la plus coûteuse en termes de calculs. Des critères d arrêt peuvent néanmoins accélérer le calcul. En effet, si un bloc possède déjà un SAD partiel plus élevé que le minimum courant, il peut être sauté. L ordre de parcours des candidats peut varier d une implémentation à une autre (de gauche à droite, spiralé autour du centre, etc.) Figure 5.2 Recherche exhaustive en balayage spiralé Méthodes multi-pas Même avec l utilisation de critères de terminaison, la recherche exhaustive est bien trop gourmande pour de nombreuses applications. Un algorithme beaucoup plus simple en terme de comparaison est le Tree-StepSearch (TSS, [43]). Cet algorithme introduit en 1981, est illustré en section 5.3. Pour une fenêtre de ±(2M + 1) de long et de large, l algorithme choisi comme origine le centre de la fenêtre. Huit autres lieux de comparaisons (points) à une distance ± M du centre sont choisis (marqués par un 1 sur la figure). Les neufs points sont comparés au bloc courant par une SSD et le meilleur devient l origine de la nouvelle itération (le point 1

64 5.2 Algorithmes de recherche 56 entouré). Le pas de sélection des voisins est divisé par deux (M = M/2 ) et huit nouvelles comparaisons ont lieu (2 sur la figure). L algorithme est fini lorsque le pas devient plus petit que l unité (le point 3 entouré sur la figure). Figure 5.3 Recherche en trois étapes (TSS). Des recherches comme celle de TSS se basent sur l hypothèse d une surface résiduelle convexe ; soit que l erreur de comparaison s accroît de manière monotone autour du minimum global. D autres algorithmes ont été développés pour être plus robustes et moins sensibles au minimum locaux que TSS. Parmis eux citons : Logaritmic Search (LS,[37]), Cross Search (CS,[25]), four-step Search (4SS,[64]), New tree-stepsearch (N3SS,[48]), Gradient Descent Search (GDS,[15]), Diamond Search (DS,[88]), Cross Diamond Search (CDS,[18]), Hexagon Search (HEXS,[112]), etc. Tous ces algorithmes proposent des solutions se basant sur différents motifs de comparaison. Ces recherches ont cependant tendance à rejeter les grands vecteurs de déplacement. Une autre approche, permettant de mieux saisir les grands déplacements, est l utilisation d une hiérarchie de fenêtres. Un algorithme comme Hierarchical Search (HS,[11]), va rechercher le déplacement d un bloc dans une pyramide de fenêtres construites par diminutions successives de la résolution. Sur la Fig. 5.6, le niveau 0 est la fenêtre entière. Le niveau 1 est obtenu par sous-échantillonnage d un facteur 2 du niveau 0 (la taille de la pyramide ainsi que la méthode d échantillonnage varie d un algorithme à un autre). Le niveau 2 est obtenu de la même manière. Une

65 5.2 Algorithmes de recherche 57 (a) (b) (c) (d) Figure 5.4 Motif diamant utilisé dans DS, avec différents déplacements du motif en fonction du meilleur résultat de l itération précédante. (a) (b) (c) Figure 5.5 Motif carré utilisé dans CS.

66 5.2 Algorithmes de recherche 58 recherche exhaustive est effectuée au niveau 2. Le vecteur de déplacement obtenu au niveau 2 est ensuite agrandi d un facteur 2. La recherche est alors effectuée au niveau 1 avec un TSS et une origine centrée sur le vecteur agrandi. L itération est propagée dans les étages inférieurs jusqu à obtenir le vecteur de déplacement du niveau 0. Figure 5.6 Structure de recherche pyramidale. Bien que diminuant très fortement le nombre de comparaisons, la famille des multi-pas ne tient pas compte des vecteurs de déplacement déjà calculés pour les blocs voisins, ni même du poids de codage du vecteur de déplacement Méthodes prédictives Le mouvement dans une scène vidéo implique généralement peu de blocs et s étale sur quelques trames. Une forte corrélation existe donc entre les blocs car leurs blocs voisins (temporellement ou spécialement) tendent à partager des vecteurs de déplacement fort semblables. En utilisant cette observation, la fenêtre de recherche peut être contrainte à une zone plus petite, centrée autour des vecteurs prédits. Un bon exemple est l algorithme Prediction Search Algorithm (PSA,[54]). Celui-ci

67 5.2 Algorithmes de recherche 59 Algorithme Nombre de comparaisons maximales M (N=3) FS (2M + 1) TSS log 2 M LS log 2 M CDS 3 + 2M HS ( 2M 2 N 1 + 1) 2 + 9(N 1) Tableau 5.1 Comparaison des Complexités de différentes méthodes Multi-pas ; avec N le nombre d étages et M = u = v. est semblable au mode direct dans AVC ; le vecteur courant est une moyenne des vecteurs voisins disponibles (en intra). Figure 5.7 Un exemple de prédictions possibles. Une approche plus raffinée comme Nearest Neighbours Search (NNS,[24]) propose un subtil mélange de multi-pas et de prédiction. Cet algorithme est illustré en 5.8. L algorithme calcule le SAD au centre de la fenêtre (marqué par un 0 sur la figure). Ensuite, l origine est centrée sur le vecteur prédit obtenu par médiane des voisins spatiaux, et un motif en diamant est appliqué autour de l origine (les points marqués 1 sur la figure). Si le centre de la fenêtre ou le centre du motif possèdent le minimum, l algorithme s arrête. Sinon, l origine est déplacée vers le point possédant le minimum courant (le point 1 entouré sur la figure). Ici l algorithme s arrête, car le centre de la troisième itération est le meilleur choix de la précédente. Cet algorithme propose d excellentes performances en comparaison avec une

68 5.2 Algorithmes de recherche 60 recherche exhaustive pour un coût de comparaison très bas. Figure 5.8 Recherche prédictive par rapport au plus proche voisin (NNS). Des approches semblables, comme le Multi-Resolution Spatio Temporal (MRST, [14]) utilisent une hiérarchie de prédictions construitent à l aide des voisins spatiaux et temporels. Dans cet algorithme, une pyramide de fenêtres est tout d abord construite comme dans HS. Ensuite, un algorithme comme NNS est employé au lieu d une recherche exhaustive. La famille des prédictifs présente deux défauts : elle a du mal à repérer les déplacements brusques et elle donne de médiocres résultats lorsque le bloc courant est dans coin supérieur gauche de la trame Méthodes à critère de faible complexité La majorité du temps de calcul des algorithmes d estimation du mouvement provient de la comparaison. Lorsque deux blocs sont comparés, une SAD ou une SSD est appliquée. De nombreux algorithmes se basent sur une recherche exhaustive, mais avec des calculs allégés du critère. Dans Partial Distortion Elimination (PDE,[97]), une approximation de la SAD est calculée par comparaison des projections des lignes et des colonnes. Cette approximation peut être résumée par :

69 5.3 Algorithmes dans le software de référence, JM 61 SAD approx = N 1 i=0 C colonne i R colonne i + avec C le bloc courant et R le bloc de référence. N 1 j=0 C ligne i R ligne i Ces algorithmes, malgré leur efficacité moindre en termes de nombre de comparaisons, sont souvent choisis pour des implémentations sur des architectures dédiées à cause de leur structure régulière. 5.3 Algorithmes dans le software de référence, JM Le JVT fournit un software de référence ou code source pour l encodeur AVC, le JM, qui en est actuellement à la version En ce qui concerne les algorithmes d estimation du mouvement, la version actuelle, en plus de la recherche exhaustive, intègre trois autres algorithmes. Ces algorithmes sont très différents et possèdent chacun leur force. Tous se basent sur un mélange des familles citées plus haut. Bien que donnant de très bons résultats en terme de qualité, le mélange de familles est souvent déconseillé à cause de la charge supplémentaire de calcul qu il génère. Nous allons maintenant passer en revue la plupart des algorithmes que l on peut rencontrer dans l encodeur JM Dynamic Search Range Le Dynamic Search Range (DSR,[101]) est un pré-traitement avant la recherche à proprement parler. Le but de cet algorithme est de calculer la taille de la fenêtre de recherche en utilisant les blocs voisins et la taille par défaut. En se référant à la Fig. 5.9, on observe que le bloc E est le bloc courant, avec comme voisins les blocs A,B,C et D. Nous associons au voisin X son vecteur de mouvement MV X (x, y). La taille de la fenêtre est définie par le déplacement par rapport au bloc courant (le déplacement horizontal est noté x, et le déplacement vertical y ). La fenêtre de recherche est donc centrée sur le bloc courant et de ± x ; ± y pixels. L algorithme de modification s écrit comme suit :

70 5.3 Algorithmes dans le software de référence, JM 62 Figure 5.9 Blocs utilisés dans une DSR. 1. Vérifier le nombre de voisins disponibles, si celui-ci est 1 terminer l algorithme et utiliser la taille de fenêtre par défaut ; 2. Si C n est pas disponible, le remplacer par D ; 3. Trouver les composantes de déplacement maximales absolues avec i {x,y} : D i = max( MV A (i), MV B (i), MV C (i) ) (5.1) Avec MV X (x, y) = (0, 0) si le bloc X n existe pas ; 4. Choisir la taille de la fenêtre entre la valeur par défaut et la valeur calculée : où i = min( i, max(2d i, k i )) (5.2) α i = MV A (i) + MV B (i) + MV C (i) (5.3). k i = i +4 8 si α i = 0 3( i +8) 16 si 0 < α i 2 i 4 sinon (5.4)

71 5.3 Algorithmes dans le software de référence, JM Fast Motion Estimation Le Fast Motion Estimation (FME,[16],[17]) va chercher dans la fenêtre un bloc minimisant l énergie résiduelle. Nous savons que de meilleurs résultats du point de vue de la minimisation du résidu sont obtenus lorsque cette recherche est faite au niveau subpixel. FME va donc employer deux algorithmes différents et un critère d arrêt : l hybrid Unsymmetrical-cross Multi-Hexagon-grid Search (UM- HexagonS) lors de la recherche sur des pixels entiers et le Center-Biased Fractional Pel Search (CBFPS) lors de la recherche sur les subpixels. Un critère d arrêt est vérifié à chaque fin d étape (voir ci-dessous). Si le résidu obtenu par transformationquantification du minimum courant est égal à zéro, l algorithme se termine. Malgré sa complexité extraordinaire, FME propose, en pratique, un temps de calcul trois fois moindre pour des résultats équivalent à FS FME :UMHexagonS L algorithme travaille sur des pixels entiers et se compose d une relativement longue série d étapes. Chacune de ses étapes utilise comme origine de recherche le résultat de l étape précédente. La Fig résume la totalité d UMHexagonS. Figure 5.10 Comparaisons effectuées par UMHexagonS.

72 5.3 Algorithmes dans le software de référence, JM 64 L algorithme est le suivant : 1 Choisir parmi quatre méthodes de prédiction du MV celle de moindre coût. Les quatre méthodes de prédiction sont : 1.1 Une médiane des MV voisins A,B,C (voir figure 5.9) sur la trame courante. 1.2 Le MV d un bloc correspondant (même position) sur une trame de référence. 1.3 Une moyenne des MV de blocs correspondants sur plusieurs trames de référence. 1.4 Le MV de la partition supérieure 4. Cette prédiction est la plus rapide, mais indisponible en mode macrobloc. 2 Rechercher à l aide d un motif en croix asymétrique (UCS) le meilleur coût. Cette méthode se base sur l observation qu une séquence vidéo présente en moyenne un plus grand déplacement horizontal que vertical. L asymétrie de la croix est un paramètre dépendant des vecteurs précédemment calculés. Le pas est généralement de 2 pixels. 3 Rechercher à l aide de deux motifs simultanés (UMHS) le meilleur coût : 3.1 Un motif carré centré de ±2 pixels permettant de cerner les petits déplacements. 3.2 Une série d Hexagones de 16 points. Les hexagones ne sont pas équirépartis afin de favoriser les déplacements horizontaux. Le premier hexagone est construit pour remplir la fenêtre, les autres sont construits par compression du premier. 4 Rechercher à l aide de deux motifs successifs (EHS, EDS) si l étape 3 a fourni un MV sur un point de l hexagone. 4.1 Un hexagone de 2 pixels est évalué. Lorsque l origine est le meilleur résultat, le motif 4.2 est utilisé. 4.2 Une croix d un pixel est évaluée et fourni le MV courant lorsque l origine est le meilleur résultat. 4 Le choix du mode de partitionnement d un macrobloc est calculé en testant tout les partitionnements possibles et en évaluant leur coût. Par exemple une ME est faite dans le premier mode (16x16), puis dans les modes suivants (16x8), (8x16), etc.

73 5.3 Algorithmes dans le software de référence, JM 65 Figure 5.11 La prédiction supérieure dans UMHexagonS FME :CBFPS A la suite de la recherche précédente, des itérations subpixel sont entreprises. Tout d abord l interpolation subpixel du bloc est effectuée avant l utilisation de CBFPS. Le niveau de précision dépend du mode et de la composante examinée ; un bloc chroma peut demander une précision au 8ème de pixel. Historiquement, un TSS était calculée sur les subpixels. La méthode a été remplacée par l utilisation d une version modifiée de NNS. Ou bien la prédiction est construite à l aide de l équation 5.1 modulo δ j (avec δ j égal à la précision subpixel). Cette prédiction est comparée à la prédiction fournie par UMHexagonS. Si UMHexagonS est meilleure, l algorithme se termine. Ou bien la prédiction devient l origine d un motif diamant d un huitième de pixel. A chaque itération le meilleur résultat devient l origine de l itération suivante. L algorithme s arrête lorsque l origine est le meilleur résultat de l itération courante.

74 5.3 Algorithmes dans le software de référence, JM 66 Figure 5.12 Comparaisons éffectuées par CBFPS Simplified Fast Motion Estimation L algorithme précédent peut être vu comme le nec plus ultra actuel en technique d estimation de mouvement. Une version allégée, le Simplified Fast Motion Estimation (SFME, [93]), est disponible dans la JM pour accélérer les calculs. D abord, le critère d arrêt de chaque étape n est plus basé sur une transforméequantifiée du résidu courant, mais sur une prédiction du résidu (plus précisément sur le critère de comparaison : le SAD, le SSD ou le SATD). En utilisant les mêmes techniques que celles de prédiction des MV (bloc voisin, bloc correspondant, bloc supérieur), la prédiction SAD du bloc courant peut être utilisée comme critère d arrêt. Dès lors si la comparaison courante dépasse le SAD seuil, l algorithme s arrête. On a SAD seuil = SAD prdit (1 + β), avec β un paramètre pré-calculé en fonction du mode du bloc courant, de la matrice de transformation, du pas de quantification et d un paramètre α, fruit d analyses statistiques sur la distribution de la norme des différence de SAD 5 ). En plus du critère d arrêt, UMHexagonS a été modifié afin de ne maintenir que la prédiction 1.4 à la première étape. L étape 3, quant à elle, n est plus effectuée. Similairement CBFPS est légèrement modifié pour tester le critère d arrêt à chaque 5 SAD predit SAD courant SAD prdit.

75 5.3 Algorithmes dans le software de référence, JM 67 itération pendant l utilisation du motif diamant Enhanced Predictive Zonal Search L Enhanced Predictive Zonal Search (EPZS,[102]) est un algorithme configurable. Comme FME, il se compose d un critère de terminaison (testé à chaque itération) et de deux parties : une traitant les pixels entiers et l autre les subpixels. Le critère est calculé à partir du poids du bloc courant. Le poids du bloc courant se calcule en multipliant le nombre de pixels par la résolution des pixels 6. Deux coefficients contrôlent le seuil d arrêt en fonction du poids du bloc courant. Ces coefficients sont des valeurs empiriques, basées sur des statistiques réalisées par le concepteur de l algorithme. La partie sur les entiers travaille en deux phases : la première phase choisit parmi cinq prédictions, celle qui offre le meilleur coût. En plus des quatre prédictions d UMHexagonS, EPZS intègre une prédiction, résultat de la moyenne des prédictions supérieures. Toutes les prédictions sont comparées, celle de moindre coût est maintenue. La seconde phase applique différents motifs autour du résultat de la phase antérieure. Les motifs sont variables en fonction de la prédiction antérieure gagnante. Comme la prédiction médiane s appuie sur une forte corrélation entre les blocs, un motif plus petit est choisi. Si la prédiction est supérieure, un losange est sélectionné. Dans les cas de prédictions temporelles, les motifs de la Fig sont choisis. La partie sur les subpixels quant à elle utilise non pas le meilleur résultat, mais les deux meilleurs résultat pour choisir le motif de recherche appliquée (voir Fig. 5.15). Il est à noter qu aucune prédiction n est utilisée en subpixel. La recherche commence donc autour du pixel et s étend avec lui. Après avoir passé en revue la liste des algorithmes existant dans le software de référence, nous abordons brièvement leur équivalent dans le codec x.264 choisi pour ses qualités de performance et d optimisation partielle du calcul vectoriel (cf. section 4.3.1). Nous comparons ensuite leurs performances respectives afin de choisir les algorithmes candidats à l optimisation. 6 EPZS supporte différents modes d échantillonnage en plus du YV12.

76 5.3 Algorithmes dans le software de référence, JM 68 Figure 5.13 Comparaisons effectuées par EPZS sur les pixels entiers. tempo- (a) Prédiction relle (b) Prédiction multiréférences Figure 5.14 Motif sélectionné en fonction de la prédiction gagnante lors d une recherche EPZS sur les pixels.

77 5.4 Algorithmes dans x (a) L origine est le second point (b) (c) Figure 5.15 Etapes possibles lors d une recherche subpixel avec EPZS. La stratégie de recherche varie en fonction du premier et du second meilleur point. 5.4 Algorithmes dans x264 L implémentation actuelle de x264 bénéficie de trois algorithmes d estimation du mouvement : FS, xfme et xepzs. Nous avons noté les algorithmes déja mentionnés d un préfixe x car il s agit en réalité de très légères variantes des algorithmes déjà implémentés dans JM (cf. sections précédentes). xfme et xepzs utilisent le même critère de terminaison que SFME, c est-à-dire une prédiction du résidu. EPZS étant hautement configurable, trois motifs de représentation existent : un diamant d un pixel de rayon, un hexagone de deux pixels et un hexagone asymétrique. 5.5 Comparaison des performances des encodeurs-cibles Nous pouvons maintenant tester et comparer les algorithmes d estimation du mouvement avec les codec JM et x264. Le but de cette action est de garder parmi ces deux codecs les algorithmes d estimation de mouvement proposant le meilleur compromis qualité/rapidité pour choisir ensuite les plus aptes à être optimisés. Dans cette section, une description des mesures précède les résultats obtenus, qui sont en partie présentés dans cette section et dans la section suivante 6.

78 5.5 Comparaison des performances des encodeurs-cibles Qualité des résultats Afin de comparer la qualité des séquences vidéos obtenues, une mesure objective doit être choisie. Le choix de cette mesure est difficile en raison du caractère subjectif du critère qualité. En effet, deux personnes ne s attarderont pas sur les mêmes détails, si bien que la même vidéo peut recevoir deux avis différents. De nombreuses mesures, aussi bien subjectives qu objectives, ont vu le jour. La méthode donnant généralement les meilleurs résultats consiste à choisir un panel de personnes à qui l on propose de visionner la séquence en double aveugle et d évaluer sa qualité. Bien évidement, le coût et le temps nécessaires pour appliquer cette méthode n en font pas un outil adapté à nos besoins. De nombreuses mesures objectives sont apparues pour tenter de mesurer le critère qualité. La plus répandue est le Peak Signal to Noise Ratio (PSNR). Ce rapport signal/bruit est mesuré sur une échelle logarithmique et dépend de la moyenne du SSD ; autrement dit, de l erreur quadratique moyenne. Plus ce rapport est élevé, plus l image est de qualité. Il faut noter qu une comparaison PSNR de deux images doit être traitée avec précaution car une image possèdant un PSNR bas 5.16(b) peut néanmoins proposer une meilleure qualité visible à l œuil nu, qu une image avec un meilleur PSNR 5.16(c). SSD = N 1 M 1 i=0 j=0 P SNR db = 10 log 10 (2 n 1) 2 (C i,j R i,j ) 2 (5.5) SSD N M (5.6) Equation du PSNR pour une image NxM, avec C l image courante, R l image comparée et n le nombre de bits par composante ; soit 8 bits dans le cas illustré Mesure des temps de calcul des algorithmes comparés Si l on souhaite évaluer un algorithme, la meilleure chose à faire est de regarder son temps d éxécution. Un temps de calcul basé sur une complexité algorithmique théorique et sur les paramètres d évaluation de la puissance de calcul ne peut conduire qu à une approximation très grossière du temps de calcul. Dès lors, la seule mesure pertinente de l efficacité d un programme exécuté sur une machine est le temps de calcul effectif.

79 5.5 Comparaison des performances des encodeurs-cibles 71 (a) Original (b) image à db, l arrière plan flou (c) image floue à db Figure 5.16 Des exemples de PSNR Afin de réaliser une mesure du temps de calcul effectif qui soit correcte, nous utilisons le profiler Intel R VTUNE qui nous indique le temps d exécution d une application. Ce temps est calculé par échantillonage du processeur en mode DE- BUG (sans nuire à l exécution courante). Lorsqu une application est exécutée, son adresse mémoire est connue, ainsi que ses processus-fils. Dès lors, en menant un échantillonage régulier et de courte période, on parvient à reconstituer statistiquement le temps d exécution d une application. Ce temps machine est bien meilleur qu un temps OS qui ne fait que regarder le temps global d exécution (c est-à-dire la période comprise entre le moment du chargement et le moment de fin du processus racine) ; sans tenir compte des préemptions ni des temps d interruption. Grâce à ce type de mesure statistique, un code source peut être évalué très précisément et nous nous en servirons pour montrer les gains obtenus dans l optimisation du code au chapitre suivant. Petite précision, une application étant vue par l OS comme un arbre de processus, nous avons configuré l ordonnanceur de processus de l OS de manière à attribuer la plus grande priorité à notre processus. Cette manipulation vise à diminuer le risque de préemption lors de nos tests, qui provoquerait une diminution des performances individuelles, et donc du temps réel d exécution des algorithmes Calibrage des codec La première étape est un calibrage des codec. Par défaut, les deux encodeurs possèdent une foule de paramètres différents utilisables pour l encodage. Afin de nous autoriser une comparaison des algorithmes, nous avons choisi d exiger les

80 5.5 Comparaison des performances des encodeurs-cibles 72 mêmes performances qualitatives de chacun d eux. Un débit de 150 Ko/s a été imposé en sortie des encodeurs par ajustage des paramètres de quantification (QP). Pour mieux comparer la performance des algorithmes, cinq trames de référence ont été imposées pour l étape de compensation du mouvement (théorie en section 2.4. Ce paramètre n est nullement utilisable pour du temps réel, mais il accentue les différences entre les algorithmes. Enfin, un paramétrage minutieux des algorithmes à été opéré, selon les consignes de leur créateurs (voir annexe IV). Figure 5.17 Calibrage des codec avec une recherche exhaustive. (a) Original (b) x264 à 40,05 db (c) JM à 37,41 db Figure 5.18 Trame 251 de la figure 5.17 proposant le plus grand PSNR en régime d exécution Résultats Les temps d exécution des différents algorithmes ont été comparés et les deux meilleurs algorithmes ont été choisis : soit EPZS et SFME. Les tests complets sont disponibles en Annexe III. La première constatation est la très nette différence de temps d exécution entre les deux codec (cf. Fig. 5.19). En effet, pour une très faible distorsion PSNR, l encodage avec une recherche exhaustive de 400 trames QCIF se fait en 271,59 secondes

81 5.5 Comparaison des performances des encodeurs-cibles 73 (1,47 trames par seconde) sur JM, contre 55,32 secondes sur x264 (7 trames par seconde). Soit presque cinq fois plus rapidement. Les autres algorithmes creusent l écart jusqu à un facteur dix. Pour des raisons d implémentation, seule la recherche exhaustive peut nous servir comme repère de comparaison. Effectivement, la simplicité algorithmique de la recherche exhaustive en dit long sur la qualité du codage des deux codec. Les chiffres reflètent d ailleurs bien le caractère lent de JM, caractère qui nous a poussé dès le départ de nos recherches à trouver un codec plus performant (il ne faut pas oublier que le JM est un codec écrit pour la compréhension du standard, et non la performance). Figure 5.19 Temps d exécution des algorithmes des deux codec sur une séquence à PSNR égal. La deuxième constatation est qu au-delà du format QCIF (176x144) imposé en entrée, aucun codec ni algorithme n arrive à nous fournir un encodage suffisament rapide d au moins 25 trames par seconde, exigence principale d une compression en temps réel. Nous avons diminué le nombre de trames de référence jusqu au minimum possible selon un niveau de qualité imposé, ainsi que le seuil de terminaison des algorithmes. La troisième constatation est que, malgré une augmentation certaine de la rapidité, aucune combinaison n a su satisfaire à la fois notre exigence de débit et notre exigence de vitesse d encodage. La seule manière d augmenter les performances était de désactiver l estimation du mouvement par l imposition d un critère de ter-

82 5.5 Comparaison des performances des encodeurs-cibles 74 minaison extrêmement laxiste. Bien sûr, cette approche revient à mettre tout le poids du débit imposé sur l étape de quantification, ce qui revient à obtenir une qualité très médiocre, équivalente au standard de compression MPEG-1. Figure 5.20 Vitesse d encodage des deux codec sur une séquence Un débit en sortie moitié moindre est imposé à x264. La quatrième constatation est l observation que l on peut faire de la grande quantité de temps consommé par l étape d estimation du mouvement par rapport au temps global d encodage. En effet, nous pouvons observer ici la règle du qui spécifie que 10% du code requiert 90% du temps d exécution. Cette durée conséquente justifie, à elle seule, la nécéssité d optimiser cette étape en priorité. La cinquième constatation est le meilleur critère de terminaison utilisé par le codec x264. Celle-ci découle de l analyse profonde des comportements des différents algorithmes lors de l encodage. Un examen minutieux des graphiques PSNR et du temps d encodage de chaque trame (non illustré), nous fournit l observation suivante : l estimation de mouvement est meilleure si le critère est plus laxiste, donc plus variable, et si elle est basée sur la prédiction du résidu. Effectivement, les autres critères de terminaison tels le poids du bloc, ou le calcul des coefficients après quantification, induisent trop de branchements ; et par conséquent, trop de tests conditionnels au sein de l algorithme pour un gain de qualité dérisoire. Forts de ces résultats, nous pouvons maintenant procéder à l optimisation algo-

83 5.5 Comparaison des performances des encodeurs-cibles 75 codec Algorithme Format Temps global (s) Temps ME (s) % FS QCIF 271,59 258, QCIF 103,25 90, EPZS JM CIF FME QCIF 98,84 85, SFME QCIF 74,42 60, CIF FS QCIF 55,32 49,00 89 CIF 247,93 232,99 94 x264 EPZS : Dia QCIF 12,57 4,47 36 CIF 35,79 13,79 39 EPZS : Hex QCIF 13,97 5,02 36 CIF 40,48 18,33 45 SFME QCIF 22,50 14,53 64 CIF 80,42 57,32 71 Tableau 5.2 Temps d exécution des algorithmes d estimation de mouvement. rithmique proprement dite. Nous avons testé et comparé les performances des deux encodeurs de référence. Le codec x264 a clairement démontré sa supériorité dans différents aspects. Nous allons donc isoler les deux meilleurs algorithmes dans ce codec et les optimiser au maximum pour l étape d estimation de mouvement. Figure 5.21 PSNR des deux algorithmes proposant le plus grand moyen sur la séquence QCIF.

84 CHAPITRE 6 OPTIMISATION 6.1 Introduction Au chapitre précédent nous avons vu pourquoi le temps d encodage d une scène vidéo dépend très fortement des étapes de compensation du mouvement, et tout particulièrement de l estimation du mouvement. Des tests de performance divers ont été réalisés afin de comparer les algorithmes entre eux et détecter les meilleurs candidats à l optimisation. Malgré leurs insuffisances pour permettre un encodage en temps réel de grands formats d image vidéo, les algorithmes EPZS et SFME étaient les meilleurs candidats pour obtenir une accélération du temps de calcul s ils étaient correctement optimisés. Ce chapitre rappelle d abord la méthodologie adoptée tout au long de nos recherches. Ensuite, elle décrit les optimisations effectuées sur ces deux algorithmes ainsi que les résultats obtenus. 6.2 Approches possibles d optimisation et aboutisssement Pour bien optimiser un programme informatique, il faut avoir une vue d ensemble des agents intervenants et maintenir à l esprit les objectifs à atteindre. Dans ce travail, nous avons à faire à un processus d encodage s exécutant sur une architecture universelle 32 bits ciblée, avec un système d exploitation standard et travaillant sur un flux de données avec des contraintes d échéance en temps réel (25 trames par seconde). Malgré les choix architecturaux opérés et malgré l imposition d une vitesse d encodage à un débit minimum précis en sortie, nous pouvons encore jouer sur de nombreux facteurs afin d augmenter la vitesse totale de traitement. Petit rappel sur notre approche de départ. Lors de nos recherches sur l accélération des étapes de compression, nous avons dégagé les différents moyens qui peuvent être mis en oeuvre pour optimiser un programme lors de son exécution : le premier consiste uniquement en l amélioration des algorithmes utilisés, le second consiste en l amélioration de l implémentation proprement dite. La première approche requiert une analyse approfondie du problème. En effet, pour pouvoir remplacer un algorithme par un autre, plus efficace, il faut tout

85 6.2 Approches possibles d optimisation et aboutisssement 77 d abord définir le problème en détail, ce que nous avons fait aux chapitres 2,3 et 5. A la suite des tests effectués sur les algorithmes dans la phase d estimation du mouvement, et forts des résultats d exécution obtenus (cf. chapitre précédent), nous avons décidé de ne pas remplacer les algorithmes existants. Ce choix s explique par le fait que le facteur d accélération qui serait demandé à un nouvel algorithme ne serait pas réaliste. La seconde approche nous a paru beaucoup plus intéressante, car trois niveaux d actions s offrent à nous. Nous pouvons ainsi modifier l implémentation au niveau du code source, au niveau de la compilation et au niveau de l exécution. Suite à l étude complète de l environnement d exécution que nous avons effectuée (cf. chapitre 4), nous savons que ces trois niveaux sont fortement liés, et que l utilisation du parallélisme intra-processeur requiert des techniques précises. A l issue de ce constat, nous avions donc d abord décidé d appliquer cette approche au code source du software de référence de l UIT, code source écrit en C. Malheureusement, après de nombreuses adaptations des différentes techniques de vectorisation sur le code, l analyse des résultas obtenus nous a fait rapidement conclure que le codec JM était inapproprié pour servir nos exigences. Ce n était pas le parallélisme des instructions qui posait problème, mais l impossibilité d utiliser le parallélisme des données. Pour rappel, l accès au jeu d instructions spécialisés se fait soit par l utilisation du langage assembleur, soit par l utilisation de librairies spécialisés, soit encore par un traitement automatique lors de la compilation, traitement dit de vectorisation. Les deux dernières techniques, bien que facilement adaptables, ne se sont pas montrées convainquantes. Quant à la première, son utilisation aurait demandé une réécriture complete du codec. la raison est que l écriture inline dans le code source ne nous offrait pas assez de contrôle, et l adaptation de fonctions externes s est montrée chaotique à cause de l utilisation de nombreuses macros dans le code source. Lors de nos recherches d adaptation des fonctions assembleur, nous avons fait l heureuse découverte de x264, un codec open source, conforme à la norme AVC et proposant déja une utilisation partielle du parallélisme. Ce codec est orienté vers la performance, et de nombreuses optimisations sont déja présentes dans le code en C. A partir de là, nous avons décidé de privilégier uniquement une optimisation de ce codec en renforçant le parallélisme intra-processeur. Les sections qui suivent décrivent la phase finale d optimisation du codec x264 en vue de son utilisation en conditions particulières (compression en temps réel

86 6.3 Implémentation 78 pour bande de diffusion étroite). Nous abordons les techniques SIMD déja présentes (optimisation à l aide de l extension MMX) et la traduction que nous avons choisie pour qu elles s adaptent à une autre extension importante de notre architecture, l extension SSE Implémentation La première remarque à faire est l important travail d optimisation déja présent dans x264. En effet, contrairement au codec JM, x264 intègre déja toutes les notions de parallélisation des instructions. Les dépendances de flux, du type consommateurproducteur ou producteur-consommateur sont quasi-inexistantes sur les fonctions que ce codec emploie. Après avoir activé les extensions SIMD de x264 1, nous avons eu la satisfaction d obtenir un gain de performance à la hauteur de nos attentes. En effet, les temps d exécution sont jusqu à quatre fois moindres comparé à une version de x264 sans extensions 2. Mais ces gains ne suffisent pas à permettre la compression des images vidéo en temps réel. Heureusement pour nous, indépendamment de l utilisation partielle des extensions SIMD, x264 était encore perfectible. Puisque le codec x264 est orienté multi-plateformes, il a le souci d être compatible avec un maximum d architectures. Dès lors un grand nombre d optimisations vectorielles existent. Malheureusement certaines optimisations déja implémentées en AltiVec 3, par exemple, ne le sont pas en SSE2, ou encore d autres parties déjà écrites en MMX, ne tirent pas complètement parti de la puissance disponible grâce à SSE2. Dans la phase d estimation du mouvement, le calcul le plus gourmand reste celui du critère de comparaison, soit le SAD, le SSD ou le SATD 4. La première constatation que l on peut faire dans une architecture Intel est l implémentation d une unité spécialisée pour le traitement des sommes absolues de différences. En 1 Pour une description détaillée des extensions de l architecture SIMD, se reporter au chapitre Afin de garantir l intégrité de notre démarche, nous avons d abord désactivé les extensions SIMD lors de la comparaison des codecs (cf. chapitre précédent) afin de dégager le facteur d accélération réel résultant d une optimisation algorithmique pure. 3 Nom commercial pour un ensemble de fonctions SIMD en virgule flottante sur certaines plateformes d IBM, de Motorola, etc. 4 Pour une description détaillée des critères de comparaison, se reporter à la section

87 6.3 Implémentation 79 effet, l instruction psadbw, disponible sur SSE2, permet 16 soustractions de 8 bits et 15 additions en seulement quatre cycles-machine avec possibilité de pipeliner la même instruction tout les deux cycles. Cette instruction permet un gain de temps considérable face à une calcul classique à l aide des GPR. Une instruction similaire était déja présente sur MMX, mais avec évidement des opérandes de 64 bits et non de 128 bits de long. La fonction de base MMX de calcul des SAD dans x264 est très linéaire et s appuie fortement sur l instruction psadbw ; le reste de la fonction de calcul s occupe des transferts des données 5, des additions partielles et de la gestion de leur nombre en fonction de la dimension du bloc. Le problème principal de cette fonction MMX est son temps de latence. Nous avons estimé ce temps à 40% du temps total d exécution de la fonction. Elle ne fait pas grand chose par appel, et elle est appellée un grand nombre de fois. Pour pallier cette latence, deux fonctions MMX ont été rajoutées par les développeurs 6 d x264. Basiquement, les fonctions calculent 3 ou 4 SAD en parallèle. Similairement, nous avons tenté de les appliquer aux extensions SSE2. Le portage de ces deux fonctions a demandé beaucoup de temps, mais le gain obtenu méritait l effort exigé. La principale difficulté a été le manque de registres disponibles pour combler la pression que nous imposions au pipeline. En effet, sur les 8 registres de 128 bits disponibles, 2 doivent rester vacants pour pouvoir exécuter le mouvement de données. En outre, lorsque nous lançons une opération MMX ou SSE, une des opérandes est généralement détruite (contrairement à l approche d AltiVec, par exemple), ce qui implique qu un registre supplémentaire doit être utilisé pour la sauvegarde temporaire. Une autre modification notable est celle faite sur le calcul du critère de terminaison. Comme nous l avons déja mentionné, la version EPZS de x264 se veut légérement différente de celle de JM. Le critère de terminaison s appuie sur une version modifiée du critère de SFME, soit sur une prédiction du résidu. Cette prédiction, est vraie dans généralement 80% du temps, comme nous l a démontré une analyse à l aide de IntelVTUNE. Cet impact est important dans l ordonnancement des instructions de prédiction. En effet, pendant la comparaison du bloc courant avec le bloc prédit, le critère de terminaison est vérifié. Si la résultante du critère se trouve sous le seuil de prédiction, l algorithme passe (saute) à la prochaine analyse 5 Malgré nos efforts à l aide de préfetchs, aucune amélioration ne s est faite sentir sur ces transferts. 6 Pour rappel, il s agit d un projet Open Source.

88 6.4 Résultats 80 de partitionnement pour le macrobloc courant. Etant donné que la probabilité de saut est grande, nous avons parallélisé les calculs des prédictions des blocs successifs au détriment d un remplissage complet du pipeline en calculs SAD du bloc courant Résultats Avant de présenter les résultas finaux obtenus suite à l optimisation effectuée sur x264, une remarque préliminaire sur ceux-ci doit être faite. Sur le codec x264, lors du calcul d une SATD, par exemple, une fonction spécialisée écrite en assembleur est appellée. En fonction des extensions disponibles sur l architecture d exécution, des versions différentes sont exécutées. Cette opération de sélection de la bonne fonction est obtenue à l aide d un pointeur sur une matrice d addresses de routines de calcul. Le calcul du pointeur est une opération faite lors de l exécution du programme par comparaison de flags caractéristiques dans un registre particulier, flags spécifiant le type d architecture courante et les extensions SIMD disponibles (à savoir les extensions MMX, SSE et SSE2 chez Intel). Pour nous simplifier la vie lors des étapes de test, qui sont très fastidieuses lors d un benchmarking d instructions vectorielles, nous avons délibérément désactivé le test du flag SSE. Ainsi nos fonctions n étaient plus exécutées et nous pouvions regarder le gain obtenu en les comparant aux versions MMX. Le corollaire est que d autres fonctions spécialisées disponibles dans x264 8 se sont vues désactivées, comme le calcul du SSD 9. Par conséquent, le facteur de gain global qui est décrit ci-après ne reflète pas précisément le gain de performances obtenu par notre implémentation Gain Cette section résume les gains obtenus sur le codec x264 optimisé, à l aide d un graphe de résultats. Nous avons regroupé sous l appellation x264 SIMD les améliorations MMX, et sous l appellation x264 SIMD optimisé, toutes les améliorations obtenues grâce à SSE2. Nous estimons notre part de contribution à 7 Malheureusement, IntelVTUNE ne nous permet pas de valider ce gain. 8 Ces fonctions sont écrites en assembleur et utilisent des instructions SSE2. 9 Pour rappel, SSD est un calcul fait lors d une recherche sur un bloc chroma.

89 6.5 Analyse 81 cette considérable amélioration des performances du codec à environ 80% de ce chiffre 10. Cette performance est analysée dans la section suivante. Figure 6.1 Amélioration obtenue avec l algorithme d encodage EPZS en fonction des formats différents : QCIF :5, CIF :5, 4CIF :1 et HD : Analyse A la suite des résultats obtenus, force est de constater que l optimisation réalisée bénéficie à tous les algorithmes (cf. graphe de comparaison de la vitesse des algorithmes d encodage 6.2). Cette constatation était prévisible car la partie la plus gourmande des algorithmes d estimation du mouvement est leur partie commune, à savoir le calcul des critères de comparaison. La seconde remarque que nous pouvons faire est qu au-delà du format 4CIF, le gain de SSE2 est imperceptible. En effet, lors d un encodage en temps réel au format HD720p pour une recherche EPZS, l encodeur va traiter 230 Mo de données 10 Sur base des tests.

90 6.5 Analyse 82 Figure 6.2 Comparaison de la vitesse d encodage des différents algorithmes. en 12 secondes, ce qui revient à un débit de moyen de 19 Mo/s transitant par le microprocesseur. Le goulot d étranglement passe alors sur le bus externe 11. La troisième constatation concerne les performances inattendues de l algorithme SFME dans les plus hautes résolutions. L action conjuguée du transfert d I/O, ainsi que le nombre de branchements importants lors du calcul des prédictions de son concurrent EPZS pénalisent ce dernier et laissent SMFE venir le ratrapper Extrapolation Puisque l on est parvenu à améliorer d un facteur 4 la vitesse de l encodeur en optimisant l étape la plus gourmande de la compression 12, il est raisonnable de penser que l on pourrait améliorer de 2 fois l ensemble du codec x264 si l on s attardait sur d autres fonctions (par exemple l encodeur d entropie, la DCT, etc.). Ce facteur n est pas négligeable. Grâce à nos résultats, nous pouvons déduire que les tecniques de vectorisation sur des architectures dédiées permettraient un encodage en temps réel de haute 11 Des débits d I/O supérieures peuvent être supportés par le bus. Dans le cadre d une écriture DMA, par exemple, le taux de transfert moyen avoisine les 55Mo/s. 12 Par rapport à l encodeur purement en C.

91 6.5 Analyse 83 Figure 6.3 Gains des différents algorithmes en comparaison avec leur version de base en C. qualité. Par exemple, une première puce s occuperait de comprimer le flux brut HDTV 13 dans un format plus compact et une deuxième puce d architecture à plusieurs unités de traitement parallèles, même peu rapides, effecturait des Somme Absolues de Différence (SAD) en mode vectoriel Remarque sur la portabilité Toute approche d optimisation manuelle porte avec elle ses limites. Une telle approche est en effet laborieuse et grande consommmatrice de temps. Notre expérience, et d autres publications que l on trouve sur le sujet, le confirment. De plus, un tel code, optimisé pour une architecture spécifique n est pas portable. Ceci est en partie dû au fait que les registres multimédias ont des longueurs, des styles de programmation et des exigences d alignement différents et qu ils supportent, en sus, des instructions différentes. 13 De l anglais High Definition Television. La qualité HDTV (haute définition) exige des débits bruts de traitement d i/o d au moins 20 à 30 Mo/s.

92 6.5 Analyse 84 Figure 6.4 Vitesse d encodage en fonction de la qualité Améliorations Pour finir, nous avons regroupé une liste des améliorations possibles qui ne nous ont pas paru essentielles pour valider notre approche d optimisation, mais qui représentent des bonnes pratiques en matière d amélioration d algorithmes ou parfois même qui vont un pas plus loin dans l approche vectorielle. Ainsi, on pourrait notamment : ne plus utiliser un array de fonctions, impliquant des calculs d adresses inutiles ; utiliser des calculs approximatifs des SAD ; utiliser une machine vectorielle avec moins de limitations de registres (Pentium D, AltiVec, etc.) ;paralléliser avec SSE2 et des ALU classiques, et non seulement SSE2 ; utiliser encore mieux la ressource mémoire ; procéder à une optimisation machine encore plus fine ; etc. On pourrait encore espérer un gain supplémentaire de 20 à 30 % sur l étape d estimation de mouvement par une écriture plus que laborieuse de tous les algorithmes. Tout est possible...mais est-ce bien réaliste?

93 6.5 Analyse 85 Figure 6.5 Amélioration obtenue depuis la JM. Comme nous l avons dit en introduction, en remettant en question le concept d algorithme mathématique basé sur le principe de la machine séquentielle, ce type de travail allait se confronter à deux difficultés majeures : la diversité des modèles architecturaux parallèles qui présupose toujours un compromis entre la performance et la portabilité du code, mais également la difficulté de programmation des machines vectorielles. Nous savons maintenant qu il n existe pas d algorithme universel qui serait optimal quel que soit le problème. Pour optimiser des algorithmes comme ceux impliqués dans la compression, il faudrait plutôt améliorer la conception des compilateurs eux-mêmes qui génèrent actuellement un code peu compatible avec les architectures vectorielles. Des compilateurs évolués dont les programmes exploiteraient toute la potentialité de performance des micro-processeurs parallèles.

94 CHAPITRE 7 CONCLUSION 7.1 Cheminement Nous avons tout d abord exposé un résumé de la théorie de la compression d image vidéo et détaillé les couches d un encodeur. Ensuite, nous avons présenté la norme de compression AVC et ses principales caractéristiques. Nous avons introduit l environnement d exécution en justifiant le choix du processeur Intel x86, architecture de type superscalaire et superpipeline. En analysant les mécanismes de parallélisme offerts par l architecture x86, nous avons pu dériver les caractéristiques d un algorithme optimal. Nous avons, notamment, veillé à identifier les goulots d étranglement pour les supprimer. Nous avons aussi dégagé des principes de développement pour optimiser le code. Le pendant de l architecture d exécution est la plateforme d exécution qui englobe notamment le codec (et ses algorithmes de compression) et le compilateur. Le choix de ce dernier était primordial car déterminant pour les performances du code source. Après une analyse minutieuse des besoins, nous avons opté pour le compilateur Intel R C Le chapitre sur l estimation du mouvement décrit une des étapes majeures de l encodage et les algorithmes de recherche qui y sont associés. Nous avons d abord étudié tous les algorithmes employés dans chacun des encodeurs de référence, JM et x264. Ce n est qu après les avoir décrits en détail que l on peut les analyser et les tester. Pour ce faire, nous avons appliqué une méthode statistique de comparaison des performances. L examen attentif du codec JM fournit par l UIT, a débouché sur la constatation que ce codec ne convenait pas pour une compression en temps réel dans l environnement choisi. Le codec JM n est pas conçu pour une machine vectorielle, il sous-exploite les capacités de calcul du processeur. Il s agissait donc de convertir son code d origine pour mieux solliciter le parallélisme de l architecture. Cette solution très laborieuse s est avérée inutile puisque d autres encodeurs existent sur le marché offrant des performances supérieures.

95 7.2 Résultats 87 Finalement, nous avons donc choisi le codec open source x264 (écrit en langage C) qui, après comparaison avec JM, s est révélé meilleur. Non seulement il adopte une approche de qualité, tournée vers la performance ; mais il propose aussi, en assembleur, une utilisation partielle du parallélisme de bas niveau. Dans ce même chapitre, après cette comparaison, nous avons élu les algorithmes candidats à l optimisation : les algorithmes EPZD et SFME. Ces deux algorithmes étaient les plus propices à une réelle amélioration des performances du code source pour la phase d estimation de mouvement ; et par voie de conséquence, les plus aptes à accélérer le processus global d un encodage en temps réel à 25 images (trames) par seconde. Le sixième et dernier chapitre reflète la mise en pratique des connaissances et déductions accumulées lors des chapitres précédents. Une des lignes directrices de nos recherches a été la quête d optimisation des deux algorithmes EPZD et SFME. Ces deux algorithmes ont été optimisés à l aide d un outil spécifique de simulation et d analyse, IntelVTUNE R. Sur base de l échantillonnage du processeur, nous avons identifié les goulots d étranglement et procédé à l analyse des instructions en assembleur. Nous avons accéléré le processus d encodage à l aide de la nouvelle génération d extensions SSE2 fournies avec l architecture Intel 32 bits. Grâce à un examen minutieux du code, nous avons pu modifier l usage du pipeline, l ordonnancement des instructions, les accès à la mémoire cache et l usage des différentes unités d exécution par les algorithmes. L optimisation itérative dont ils ont fait l objet a également bénéficié aux autres algorithmes présents dans le codec x264. De ce fait, nous avons poussé dans ses derniers retranchements une méthode esquissée par le codec x264, à savoir utiliser les extensions vectorielles du micro-processeur pour augmenter le parallélisme. 7.2 Résultats Nous sommes donc parvenus au terme de ce travail à respecter les contraintes que nous nous étions imposées avec un temps d exécution du codec x264 quatre fois plus rapide que sa version basique, et quinze fois plus rapide si nous le comparons à JM. Nous avons au final doublé la vitesse d exécution de l encodeur x264. Ce gain nous a permis de réaliser de l encodage en temps réel (plus de 25 images par seconde), d un format supérieur au précédent. Nous pouvons ainsi conclure que

96 7.3 Travaux futurs 88 nous avons satisfait à notre premier objectif scientifique d optimisation d un encodeur pour une machine vectorielle. Nous pouvons également constater que la méthode proposée a démontré ses avantages car la comparaison des performances d un même codec avec, et sans utilisation de l architecture vectorielle, a clairement montré l inclusion des techniques parallèles comme étant un élément favorable. Notre deuxième objectif est donc bien rempli et indique que la programmation n est pas un art figé et qu elle se doit d évoluer de concert avec l architecture des systèmes. En conclusion, nous avons généré des optimisations à tous les niveaux de la chaîne de développement, depuis le langage de programmation jusqu à l exécution en passant par les étapes de compilation. Le but de toutes ces optimisations étant de permettre le traitement d un flux vidéo qualitatif en temps réel avec la dernière génération de micro-processeurs d Intel tout en respectant la norme AVC. Ce qui nous est enfin permis. 7.3 Travaux futurs Cependant, malgré une performance très intéressante, tout n est pas fini. Il s offre à nous d autres perspectives d amélioration qui n ont été abordées que sommairement et qui sortent du cadre de ce travail. Il y a, par exemple, d autres étapes de la codification d images vidéo qui peuvent être optimisées en dehors de l estimation de mouvement. L optimisation manuelle est toujours nécessaire, sans s opposer à l optimisation algorithmique mathématique, car elle comble les limites des compilateurs actuels (même les plus évolués). Les optimisations algorithmiques parallèles opérées dans ce travail, par exemple, ont fait leurs preuves, bien qu elles s avèrent parfois laborieuses. Néanmoins, nous pensons qu au lieu d utiliser de l assembleur (langage de bas niveau, peu maniable) pour optimiser les algorithmes de compression, il faudrait améliorer la conception des compilateurs eux-mêmes qui génèrent actuellement un code n exploitant pas assez les potentialités des architectures vectorielles. En conclusion, la compression en temps réel sur une architecture universelle (ou grand public) s accommode mal d un code source hautement portable. La prochaine génération de compilateurs, pour être à la pointe de la technologie, se doit d adapter sa logique aux architectures vectorielles. C est même une condition

97 7.3 Travaux futurs 89 sine qua non pour que le grand public ait accès aux applications multimédia en temps réel avec une qualité et un débit dignes de ce nom.

98 BIBLIOGRAPHIE [1] Forum d outils de compression vidéo. URL [2] Le codec open source x264. URL [3] Le site Compression.ru. URL [4] Le site DOOM9.net. URL [5] Système de documentation DOXYGEN. URL ~dimitri/doxygen/. [6] A 27 mw 1.1 mm2 Motion Estimator for Picture-Rate Up-converter, [7] Maneesh Agrawala, Andrew C. Beers et Navin Chaddha. Model-based motion estimation for synthetic animations. ACM Multimedia, 59: , [8] John G. Allen et Jesse S. Jin. Enhancing screen teleconferencing with streaming simd extensions. Dans VIP 01 : Proceedings of the Pan-Sydney area workshop on Visual information processing, pages , Darlinghurst, Australia, Australia, Australian Computer Society, Inc. ISBN [9] andrew gibson. the h.264 video compression standart. Mémoire de maîtrise, Queen s University, [10] Abu Asaduzzaman et Imad Mahgoub. Cache modeling and optimization for portable devices running mpeg-4 video decoder. Multimedia Tools Appl., 28 (1): , ISSN [11] M. Bierling. Displacement estimation by hierarchical block matching. SPIE Visual Communications and Image Processing, 1001: , [12] Aart J. C. Bik, Milind Girkar, Paul M. Grey et Xinmin Tian. Automatic intraregister vectorization for the intel R architecture. Int. J. Parallel Program., 30(2):65 98, ISSN [13] Alan C. Bovik, Jerry D. Gibson et Al Bovik. Handbook of Image and Video Processing. Academic Press, Inc., Orlando, FL, USA, ISBN

99 91 [14] J. Chalidabhongse et C.-C.J. Kuo. Fast motion vector estimation using multiresolution-spatio-temporal correlations. IEEE Trans. Circuits Syst. Video Technol., 7: , [15] O.T.-C. Chen. Motion estimation using a one-dimensional gradient descent search. IEEE Transactions on Circuits and Systems for Video Technology, 10: , [16] Zhibo Chen, Peng Zhou et Yun He. Fast integer pel and fractional pel motion estimation in for jvt. Rapport technique, Joint Video Team (JVT) of ISO/IEC MPEG & ITU-T VCEG, [17] Zhibo Chen, Peng Zhou et Yun He. Fast motion estimation for jvt. Rapport technique, JVT-G016, [18] C.-H. Cheung et L.-M. Po. A novel cross-diamond search algorithm for fast block motion estimation. IEEE Trans. Circuits Syst. Video Technol, 12: , [19] Kwang-Pyo Choi, Inchoon Choi, Byeungwoo Jeon et Keun-Young Lee. An efficient traffic smoothing method for mpeg-4 part-10 avc/h.264 bitstream over wireless network. Dans PCM (2), pages , [20] G. de Haan. Progress in motion estimation for consumer video format conversion. Philips Research Laboratories, [21] Chunjiang Duanmu. New motion estimation techniques and their simd implementations for video coding. Thèse de doctorat, Montreal, P.Q., Canada, Canada, [22] Alexandre E. Eichenberger, Peng Wu et Kevin O Brien. Vectorization for simd architectures with alignment constraints. Dans PLDI 04 : Proceedings of the ACM SIGPLAN 2004 conference on Programming language design and implementation, pages 82 93, New York, NY, USA, ACM Press. ISBN [23] Franz Franchetti, Yevgen Voronenko et Markus P&#252 ;schel. Formal loop merging for signal transforms. ACM Press, New York, NY, USA, ISBN [24] M. Gallant, G. Côté et F. Kossentini. An efficient computation-constrained block-based motion estimation algorithm for lowbit rate video coding. IEEE Trans. Image Processing, 8, 1999.

100 92 [25] M. Ghanbari. The cross-search algorithm for motion estimation. IEEE Transactions on Communication, 38: , [26] Mohammed Ghanbari. Standard Codecs : Image Compression to Advanced Video Coding. Institution Electrical Engineers, [27] Randall Hyde. The Art of Assembly Language. No Starch Press, San Francisco, CA, USA, ISBN [28] La librairie Intel Performance Primitives. Intel. URL com/cd/software/products/asmo-na/eng/perflib/ipp/index.htm. [29] Intel. Intel R Architecture Optimization Reference Manual. Intel corporation, [30] Intel. Volume 1 Basic Architecture. Intel corporation, [31] Intel. Volume 2A Instruction Set Reference, A-M. Intel corporation, [32] Intel. Volume 2B Instruction Set Reference, N-Z. Intel corporation, [33] Intel. Volume 3 System Programming Guide. Intel corporation, DeveloperŠs Manual. Intel corpo- [34] Intel. IA-32 Intel R Architecture Software ration, [35] Ali R. Iranpour et Krzysztof Kuchcinski. Evaluation of simd architecture enhancement in embedded processors for mpeg-4. Euromicro Symposium on Digital System Design, DSD 04: , [36] Kip R. Irvine. Assembly Language for Intel-Based Computers. Prentice Hall Professional Technical Reference, ISBN [37] J. Jain et A. Jain. Displacement measurement and its application in interframe image coding. EEE Trans. Commun., 29: , [38] A. Joch, F. Kossentin et P. Nasiopoulos. A performance analysis of the itu-t draft h.26l video coding standard. Dans Proceedings of 12th international Packet video workshop, Avril [39] JVT. Advanced video coding for generic audiovisual services. Rapport technique, ISO/IEC and ITU-T Rec. H.264, 2003.

101 93 [40] C. S. Kannangara, I. E. G. Richardson, M. Bystrom, J. Solera, Y. Zhao, A. MacLennan et R. Cooney. Low complexity skip prediction for h.264 through lagrangian cost estimation. page 20,. [41] C.S. Kannangara et I.E.G. Richardson. Computational control of an h.264 encoder through lagrangian cost function estimation. page 4. [42] C.S. Kannangara, I.E.G. Richardson, M. Bystrom, J. Solera, Y.Zhao, A. Maclennan et R. Cooney. Complexity reduction of h.264 using lagrange optimization methods.. [43] T. Koga, K. Iinuma, A. Hirano, Y. Iijima et T. Ishiguro. Motion-compensated interframe coding for video conferencing. Dans IEEE NTC, volume G5.3.1, pages IEEE, [44] Chung-Ming Kuo, Cheng-Ping Chao et Chaur-Heh Hsieh. A new motion estimation algorithm for video coding using adaptive kalman filter. Real- Time Imaging, 8(5): , ISSN [45] Soon-Kak Kwon, A. Tamhankar et K.R. Rao. Overview of h.264 / mpeg-4 part 10. JVCIR, 17, [46] Bo Li, Wei Li et YaMing Tu. A fast block-matching algorithm using smooth motion vector field adaptive search technique. J. Comput. Sci. Technol., 18 (1):14 21, ISSN [47] Lei Li et Krishnendu Chakrabarty. On using exponential-golomb codes and subexponential codes for system-on-a-chip test data compression. J. Electron. Test., 20(6): , ISSN [48] Reoxiang Li, Bing Zeng et M.L. Liou. A new three-step search algorithm for block motion estimation. Circuits and Systems for Video Technology, IEEE Transactions on, 4( ): , [49] Tiejun Li, Sikun Li et Chengdong Shen. A novel configurable motion estimation architecture for high-efficiency mpeg-4/h.264 encoding. Dans ASP-DAC 05 : Proceedings of the 2005 conference on Asia South Pacific design automation, pages , New York, NY, USA, ACM Press. ISBN [50] Keng-Pang Lim, Gary Sullivan et Thomas Wiegand. Text description of joint model reference encoding methods and decoding concealment methods.

102 94 Rapport technique, Joint Video Team (JVT) of ISO/IEC MPEG and ITU-T VCEG, [51] Hung-Chih Lin, Yu-Jen Wang, Kai-Ting Cheng, Shang-Yu Yeh, Wei-Nien Chen, Chia-Yang Tsai, Tian-Sheuan Chang et Hsueh-Ming Hang. Algorithms and dsp implementation of h.264/avc. Dans ASP-DAC 06 : Proceedings of the 2006 conference on Asia South Pacific design automation, pages , New York, NY, USA, ACM Press. ISBN [52] L. K. Liu et E. Feig. A block-based gradient descent search algorithm for block motion estimation in video coding. IEEE Trans. Circuits & Syst. for Video Technol., 6:1 6, [53] S. Lopez, G. M. Callico, J. F. Lopez et R. Sarmiento. A high quality/low computational cost technique for block matching motion estimation. Design, Automation and Test in Europe, Proceedings, 3:2 7, [54] L. Luo, C. Zou, X. Gao et Z. He. A new prediction search algorithm for block motion estimation in video coding. IEEE Trans. Consumer Electron., 43:56 61, [55] Nicolas Mainil. Implémentation efficace de l encodeur de l entropie pour codec h.264/avc sur microprocesseur pentium 4. Mémoire de maîtrise, Université Libre de Bruxelles, [56] Hong Man, Alen Docef et Faouzi Kossentini. Performance analysis of the jpeg 2000 image coding standard. Multimedia Tools Appl., 26(1):27 57, ISSN [57] Ziqing Mao, Rong Yan, Ling Shao et Dong Xie. An error resilience scheme for packet loss recover of h.264 video. Dans PCM, pages , [58] Dragomir Milojevic. Implémentation des filtres non-linéaires de rang sur des architectures universelles et reconfigurables. Thèse de doctorat, Université Libre de Bruxelles Faculté de Sciences appliquées, [59] Chun-Hui Mo et Christof Koch. Modeling reverse-phi motion-selective neurons in cortex : double synaptic-veto mechanism. Neural Comput., 15(4): , ISSN [60] King N. Ngan, Thomas Meier et Douglas Chai. Advanced Video Coding : Principles and Techniques. Elsevier Science Inc., New York, NY, USA, ISBN X.

103 95 [61] S. Olivieri, L. Alban et G. de Haan. a low complexity recursive motion estimation algorithm for h.263 video coding. page 6, [62] N. C. Paver, M. H. Khan et B. C. Aldrich. Optimizing mobile multimedia using simd techniques. Multimedia Tools Appl., 28(1): , ISSN [63] Mark D. Pesce. Programming Microsoft DirectShow for Digital Video and Television. Microsoft, [64] L. Po et W. Ma. A novel four-step search algorithm for fast block motion estimation. IEEE Trans. Circuits Syst. Video Technol, 6: , URL citeseer.ist.psu.edu/po96novel.html. [65] S. Przybylski, M. Horowitz et J. Hennessy. Characteristics of performanceoptimal multi-level cache hierarchies. Dans ISCA 89 : Proceedings of the 16th annual international symposium on Computer architecture, pages , New York, NY, USA, ACM Press. ISBN [66] Rajesh P. N. Rao, David M. Eagleman et Terrence J. Sejnowski. Optimal Smoothing in Visual Motion Perception, volume 13, 6. MIT Press, Cambridge, MA, USA, [67] Iain Richardson et Yafan Zhao. Video encoder complexity reduction by estimating skip mode distortion.. [68] Iain E. G. Richardson. Video codec design. Wiley, [69] Iain E. G. Richardson. H.264 and MPEG-4 Video Compression, Video Coding for Next Generation Multimedia. John Wiley & Sons, [70] Iain E G Richardson et Yafan Zhao. Adaptive algorithms for variablecomplexity video coding.. [71] Iain E G Richardson et Yafan Zhao. Video codec complexity management.. [72] Iain Edward Garden Richardson. Video Coding for Reliable Communications. Thèse de doctorat, The Robert Gordon University, [73] Iain E.G. Richardson et Yafan Zhao. Adaptive management of video encoder complexity. Real-Time Imaging, Volume 8, Issue 4: , August 2002.

104 96 [74] Juan Carlos Rojas et Miriam Leeser. Programming portable optimized multimedia applications. pages , [75] Eric Rotenberg, Steve Bennett et James E. Smith. Trace cache : a low latency approach to high bandwidth instruction fetching. Dans MICRO 29 : Proceedings of the 29th annual ACM/IEEE international symposium on Microarchitecture, pages 24 35, Washington, DC, USA, IEEE Computer Society. ISBN [76] Ralf Schäfer, Thomas Wiegand et Heiko Schwarz. The emerging h.264/avc standard. Heinrich Hertz Institute, Berlin, Germany, [77] Dale Schouten, Xinmin Tian, Aart Bik et Milind Girkar. Inside the intel compiler. Linux J., 2003(106):4, ISSN [78] Tse-Tsung Shih, Chia-Lin Yang et Yi-Shin Tung. Workload characterization of the h.264/avc decoder. Dans 5. th. IEEE Pacific-Rim Conf. Multimedia, pages , [79] Karsten Sühring. Le codec JM de référence. URL suehring/tml/index.htm. [80] Johan Skoglund et Michael Felsberg. Fast image processing using sse2. Dans Proceedings of the SSBA Symposium on Image Analysis, Malmö, March [81] Greg Stitt, Frank Vahid, Gordon McGregor et Brian Einloth. Hardware/software partitioning of software binaries : A case study of h.264 decode. [82] Gary J. Sullivan, Pankaj Topiwala et Ajay Luthra. The h.264/avc advanced video coding standard : Overview and introduction to the fidelity range extensions. IEEE Trans. Circuits Syst. Video Technol., 13: , [83] Min Tan, Janet M. Siegel et Howard Jay Siegel. Parallel implementations of block-based motion vector estimation for video compression on four parallel processing systems. Int. J. Parallel Program., 27(3): , ISSN [84] Andrew Tanenbaum, Jean-Alain Hernandez et René Joly. Architecture de l ordinateur. DUNOD, [85] Stewart Taylor. Intel Integrated performance primitives. Intel Press, 2004.

105 97 [86] Tuukka Toivonen. Number theoretic transform -based block motion estimation. Thèse de doctorat, Department of Electrical Engineering, University of Oulu, Oulu, Finland, [87] Tuukka Toivonen et Janne Heikkilä. Fast full search block motion estimation for h.264/avc with multilevel successive elimination algorithm. Machine Vision Group. [88] A. Tourapis, G. Shen, M. Liou, O. Au et I. Ahmad. A new predictive diamond search algorithm for block based motion estimation. Dans Visual Comm. and Image Proc (VCIP-2000), URL citeseer.ist.psu.edu/ tourapis00new.html. [89] Alexis M. Tourapis, Oscar C. Au et Ming L. Liou. Fast motion estimation using circular zonal search. [90] Alexis M. Tourapis, Oscar C. Au et Ming L. Liou. Predictive motion vector field adaptive search technique. Dans Visual Comm. and Image Proc., [91] Alexis Michael Tourapis. Enhanced predictive zonal search for single and multiple frame motion estimation. URL citeseer.ist.psu.edu/ tourapis02enhanced.html. [92] Alexis Michael Tourapis et Oscar C. Au. Fast motion estimation using modified circular zonal search URL citeseer.ist.psu.edu/article/ tourapis99fast.html. [93] Alexis Michael Tourapis, Hye-Yeon Cheong et Pankaj Topiwala. Fast me in the jm reference software. Rapport technique, JVT-P026, JVT-P026. [94] Deepak Turaga et Mohamed Alkanhal. Search algorithms for block-matching in motion estimation. page 10, [95] Dmitriy Vatolin. Mpeg-4 avc/h.264 video codec comparison. Rapport technique, CS MSU Graphics&Media Lab, URL compression.ru/video/. [96] N. Wade et M. Swanston. Visual Perception : An Introduction. Psychology Press, [97] H. S. Wang et R. M. Mersereau. Fast algorithms for the estimation of motion vectors. IEEE Trans. Image Process, 8: , 1999.

106 98 [98] Thomas Wiegand et Gary Sullivan. Itu-t recommendation international standard of joint video specification (itu-t rec. h.264 iso/iec avc) [99] Thomas Wiegand, Gary J. Sullivan, Gisle Bjntegaard et Ajay Luthra. Overview of the h.264/avc video coding standard. IEEE Trans. Circuits Syst. Video Techn., 13(7): , [100] Jun Xin, Anthony Vetro et Huifang Sun. Converting dct coefficients to h.264/avc transform coefficients. Dans PCM(2), pages , [101] Xiaozhong Xu et Yun He. Modification of dynamic search range for jvt. Rapport technique, JVT-Q088, [102] Xiaoquan Yi, Jun Zhang, Nam Ling et Weijia Shang. Improved and simplified fast motion estimation for jm. Rapport technique, JVT-P021, [103] Hui Zhang. Fast intra-prediction mode selection for h.264. [104] Peng Zhang, Qingming Huang et Wen Gao. Key techniques of bit rate reduction for h.264 streams. Dans PCM (2), pages , [105] Y. Zhao et I. Richardson. Computational complexity management of motion estimation in video encoders. Dans DCC 02 : Proceedings of the Data Compression Conference (DCC 02), page 483, Washington, DC, USA, IEEE Computer Society. [106] Yafan Zhao. Complexity Management for Video Encoders. Thèse de doctorat, the Robert Gordon University, [107] Yafan Zhao et Iain E G Richardson. Computational complexity management of motion estimation in video encoders. [108] Yafan Zhao et Iain E.G. Richardson. Macroblock classification for complexity management of video encoders. page 11, [109] Lizhi Zheng, John Cosmas et Takebumi Itagaki. Real time h.263 video encoder using mercury multiprocessor workstation. [110] Y. Zhong, I. Richardson, A. Miller et Y. Zhao. Perceptual quality of h.264/avc deblocking filter. The Robert Gordon University,. [111] Ying Zhong, Iain Richardson, Arash Sahraie et Peter McGeorge. Influence of task and scene content on subjective video quality..

107 99 [112] C. Zhu, X. Lin et L.-P. Chau. Hexagon-based search pattern for fast block motion estimation. IEEE Trans. Circuits Syst. Video Technol, 12: , [113] S. Zhu et K.-K. Ma. A new diamond search algorithm for fast block matching motion estimation. IEEE Trans. Image Process., 9: , 2000.

108 LISTE DES TABLEAUX 2.1 Résolutions d image au standard PAL Un modèle de probabilité sur un Alphabet de 6 symboles AVC et ses Profiles Modes disponibles de partitions en intra 16 et intra Performances de la mémoire cache Comparaison des Complexités de différentes méthodes Multi-pas ; avec N le nombre d étages et M = u = v Temps d exécution des algorithmes d estimation de mouvement I.1 Choix de MODE en fonction du type de tranche ix IV.1 QP x.264 QP JM xiii

109 LISTE DES FIGURES 2.1 Les grandes étapes lors d une acquisition vidéo Processus d acquisition d une scène vidéo à l aide d un CCD Une image et sa représentation dans différents espaces colorimétriques Synthèse des couleurs Trois modes d échantillonnage Y Cb. Cr Schéma d un encodeur Schéma d un décodeur Deux trames consécutives Résidus de la Fig Les fonctions cosinus de base Numérisation et transformée d un bloc 8x Fonction de quantification Parcours d une trame en zig-zag Arbre d Huffman (extrait de [26]) Encodage arithmétique de BAAEX (extrait de [55]) Diagramme d AVC Hierarchie des données dans un codec (extrait de [26]) Une trames et son résidu avec la suivante Vecteur de déplacement de la figure Modes de partitionnement pour un macrobloc et ses sous-macroblocs Interpolation d un bloc luma au quart de pixel

110 Interpolation d un bloc chroma au huitième de pixel Indexage des blocs voisins et prédiction médiane Pixels utilisés lors de la prédiction intra Direction d interpolation pour l intra 4 4 avec numéro de mode correspondant Modes d interpolation en intra Filtrage débloquant : sans filtrage à gauche, avec filtrage à droite Choix des coefficients pour la DWT Vue d un Pentium R M et d un Pentium R Architecture du Pentium R 4 (northwood) Architecture du Pentium R M (dothan) Unités d exécution et leur port associé sur un Pentium R Exécution d une instruction sur une unité vectorielle Types d opérandes vectorielles sur un registre XMM Vue d un Graphe de filtres dans DirectShow Fenêtre de recherche dans un algorithme d estimation du mouvement Recherche exhaustive en balayage spiralé Recherche en trois étapes (TSS) Motif diamant utilisé dans DS, avec différents déplacements du motif en fonction du meilleur résultat de l itération précédante Motif carré utilisé dans CS Structure de recherche pyramidale Un exemple de prédictions possibles

111 Recherche prédictive par rapport au plus proche voisin (NNS) Blocs utilisés dans une DSR Comparaisons effectuées par UMHexagonS La prédiction supérieure dans UMHexagonS Comparaisons éffectuées par CBFPS Comparaisons effectuées par EPZS sur les pixels entiers Motif sélectionné en fonction de la prédiction gagnante lors d une recherche EPZS sur les pixels Etapes possibles lors d une recherche subpixel avec EPZS. La stratégie de recherche varie en fonction du premier et du second meilleur point Des exemples de PSNR Calibrage des codec avec une recherche exhaustive Trame 251 de la figure 5.17 proposant le plus grand PSNR en régime d exécution Temps d exécution des algorithmes des deux codec sur une séquence à PSNR égal Vitesse d encodage des deux codec sur une séquence Un débit en sortie moitié moindre est imposé à x PSNR des deux algorithmes proposant le plus grand moyen sur la séquence QCIF Amélioration obtenue avec l algorithme d encodage EPZS en fonction des formats différents : QCIF :5, CIF :5, 4CIF :1 et HD : Comparaison de la vitesse d encodage des différents algorithmes Gains des différents algorithmes en comparaison avec leur version de base en C Vitesse d encodage en fonction de la qualité

112 Amélioration obtenue depuis la JM

113 Annexe I Coût de partitionnement d un macroblock Le coût Lagrangien J à minimiser lors du calcul du partitionnement d un macroblock est : J(s, c, MODE QP, λ mode ) = Diff(s, c, MODE QP ) + λ mode Debit(s, c, MODE QP )(I.1) avec QP le paramètre de quantification (voir 3.3.7), MODE le type de partitionnement sélectionné, s le macroblock courant et c le macroblock reconstruit. MODE est choisi parmi un ensembles de modes en fonction du type de tranche : Tranche Modes Possibles I INTRA 4 4, INTRA P INTRA 4 4, INTRA 16 16, SKIP, 16 16, 16 8, 8 16, 8 8 B INTRA 4 4, INTRA 16 16, DIRECT, 16 16, 16 8, 8 16, 8 8 Tableau I.1 Choix de MODE en fonction du type de tranche Diff(s, c, MODE Q) est calculé avec SSD, SAD ou SATD(voir 3.3.6). λ mode = { 0, 85 2 (Q 12)/3 si type = I,P max ( 2, min (4, Q 12 6 ) ) λ I,P si type = B Pour une différence calculée avec SAD ou SATD on utilise dans J λ mode,type à la place de λ mode,type. Debit(s, c, MODE Q) étant le nombre de bit nécéssaires pour coder le block dans le mode choisi. Le calcul comprends les en-têtes de macroblock, le vecteur de déplacement, le block de référence, les transformées des coefficients Y,U et V et le résidu. Une évaluation est obtenue par une fonction de hashage dans une table d Exp-Golomb.

114 Annexe II Résultat des tests

115 Annexe II Résultats des Tests Séquenc e Encodeur PSNR Extra graphe Nom de la séquence Format Nom Q ME utilisé Nombre de Trames fréquence Temps PM (s) Foreman QCIF: 5 x FS: esa ,38 7,79 33,61 40,88 41,87 all 7,00 Foreman QCIF x EPZS: Dia ,27 35,49 33,50 all 7,00 Foreman QCIF x EPZS: Hex ,47 32,08 33,70 all 7,00 Foreman QCIF x SFME:umh ,03 19,02 33,68 all 7,00 Foreman QCIF x FS: esa ,20 7,38 35,10 38,80 39,80 all 7,00 Foreman QCIF x EPZS: Dia ,88 33,68 35,15 38,80 39,80 all 7,00 Foreman QCIF x EPZS: Hex ,30 30,08 35,07 38,82 39,83 all 7,00 Foreman QCIF x SFME:umh ,69 18,44 35,10 38,80 39,80 all 7,00 Foreman QCIF x x.264 FS ,33 49,00 7,23 36,61 39,54 40,82 all 7,00 Foreman QCIF x EPZS: Dia ,58 4,47 31,80 36,50 39,50 40,80 all 7,00 Foreman QCIF x EPZS: Hex ,97 5,02 28,63 36,60 39,51 40,82 all 7,00 Foreman QCIF x x.264 SFME ,51 14,51 17,77 36,60 39,50 40,80 all 7,00 Foreman QCIF JM 26 JM FS ,59 258,84 1,47 36,75 Foreman QCIF JM 26 JM EPZS ,25 90,25 3,87 36,75 Foreman QCIF JM 26 JM FME ,84 85,99 4,05 37,18 Foreman QCIF JM 26 JM SFME ,42 60,41 5,37 37,14 Foreman QCIF MMX 24 x.264 FS ,90 16,74 all 7,00 2,31 Foreman QCIF MMX EPZS: Dia ,22 55,38 all 7,00 1,74 Foreman QCIF MMX 2464 EPZS: Hex ,31 54,70 all 7,00 1,91 Foreman QCIF MMX 24 x.264 SFME ,13 43,82 all 7,00 2,47 Foreman QCIF SSE2 24 x.264 FS ,23 23,21 all 7,00 3,21 76,26 Foreman QCIF SSE EPZS: Dia ,25 76,26 all 7,00 2,40 95,33 Foreman QCIF SSE EPZS: Hex ,23 76,41 all 7,00 2,67 285,98 Foreman QCIF SSE2 24 x.264 SFME ,44 62,13 all 7,00 3,50 428,96 Temps ME(s) fps Y Cb Cr analyse subpel sa(t)d SpeedUp vs C 5HQ,HQ,M Q,LQ Mobile CIF: 5 x x.264 FS ,93 232,99 1,21 33,29 all 7,00 Mobile CIF x EPZS: Dia ,80 13,79 8,38 32,46 all 7,00 Mobile CIF x EPZS: Hex ,49 18,33 7,41 33,06 all 7,00 Page 1 de 3

116 Annexe II Résultats des Tests Mobile CIF x x.264 SFME ,43 57,32 3,73 32,47 all 7,00 Mobile CIF JM 26 JM FS all 7,00 Mobile CIF JM 26 JM EPZS ,00 258,00 1,03 35,55 all 7,00 Mobile CIF JM 26 JM FME all 7,00 Mobile CIF JM 26 JM SFME ,00 207,00 1,24 35,53 all 7,00 Mobile CIF MMX 24 x.264 FS ,63 2,31 1,91 Mobile CIF MMX EPZS: Dia ,34 13,43 1,60 Mobile CIF MMX 2464 EPZS: Hex ,79 13,16 1,78 Mobile CIF MMX 24 x.264 SFME ,46 10,93 2,93 Mobile CIF SSE2 24 x.264 FS ,66 4,64 all 7,00 3,83 Mobile CIF SSE EPZS: Dia ,31 19,59 all 7,00 2,34 Mobile CIF SSE EPZS: Hex ,13 19,83 all 7,00 2,68 Mobile CIF SSE2 24 x.264 SFME ,79 14,43 all 7,00 3,87 Mobile CIF SSE2 24 x.264 FS all 7,00 Mobile CIF SSE EPZS: Dia ,26 24,46 all 7,00 Mobile CIF SSE EPZS: Hex all 7,00 Mobile CIF SSE2 24 x.264 SFME ,54 19,30 all 7,00 19,59 Mobile CIF SSE EPZS: Dia ,72 44,65 P4 5,00 x3 24,46 Mobile CIF SSE EPZS: Dia ,64 64,70 P8 4,00 x3 44,65 Mobile CIF SSE EPZS: Dia ,40 88,11 I8 3,00 x4 94,58 Mobile CIF SSE EPZS: Dia ,17 94,58 none 1,00 x4 Plane 4CIF: 1 x264 FS: esa ,87 2,17 47,59 P4 5,00 Plane 4CIF x264 EPZS: Dia ,17 6,04 47,59 P4 5,00 Plane 4CIF x264 EPZS: Hex ,30 5,47 P4 5,00 Plane 4CIF x264 SFME:umh ,56 4,27 47,48 P4 5,00 Plane 4CIF MMX FS: esa ,43 4,04 1,86 Plane 4CIF MMX EPZS: Dia ,10 8,23 1,36 Plane 4CIF MMX EPZS: Hex ,00 Plane 4CIF MMX SFME:umh ,23 8,94 2,09 Plane 4CIF SSE2 FS: esa ,92 5,95 P4 1,00 2,74 Plane 4CIF SSE2 EPZS: Dia ,42 12,16 P4 1,00 2,01 Plane 4CIF SSE2 EPZS: Hex P4 1,00 0,00 Plane 4CIF SSE2 SFME:umh ,55 13,78 P4 1,00 3,23 9,73 Plane 4CIF SSE2 EPZS: Dia ,63 23,52 1,00 x3 12,16 Plane 4CIF SSE2 EPZS: Dia ,40 28,55 none 1,00 x3 28,55 Page 2 de 3

117 Annexe II Résultats des Tests Plane 4CIF SSE2 SFME:umh ,56 28,13 1,00 x3 42,83 Plane 4CIF SSE2 SFME:umh ,42 31,52 none 1,00 x4 Plane 4CIF SSE2 FS: esa ,09 8,23 none 1,00 x4 Girl HD: 1 x264 FS: esa ,73 0,88 46,17 Girl HD x264 EPZS: Dia ,86 1,76 46,16 Girl HD x264 EPZS: Hex ,18 1,46 46,17 Girl HD x264 SFME:umh ,47 1,52 46,17 Girl HD MMX FS: esa ,44 1,99 2,26 Girl HD MMX EPZS: Dia ,85 4,26 2,42 Girl HD MMX EPZS: Hex ,00 Girl HD MMX SFME:umh ,23 3,46 2,28 Girl HD SSE2 FS: esa ,06 2,07 x3 2,35 Girl HD SSE2 EPZS: Dia ,75 4,27 hd ki trashx3 2,43 Girl HD SSE2 EPZS: Hex x3 0,00 1,14 Girl HD SSE2 SFME:umh ,98 5,12 x3 3,37 1,42 Girl HD SSE2 EPZS: Dia ,62 14,97 x4 4,27 Girl HD SSE2 SFME:umh ,06 11,55 x4 14,97 Tomson HDVD x264 FS: esa ,28 3,55 42,00! Pas divisibla par 16 Tomson HDVD x264 EPZS: Dia Tomson HDVD x264 EPZS: Hex Tomson HDVD x264 SFME:umh Tomson HDVD MMX FS: esa Tomson HDVD MMX EPZS: Dia Tomson HDVD MMX EPZS: Hex Tomson HDVD MMX SFME:umh Tomson HDVD SSE2 FS: esa ,28 3,55 Tomson HDVD SSE2 EPZS: Dia ,28 3,55 Tomson HDVD SSE2 EPZS: Hex ,28 3,55 Tomson HDVD SSE2 SFME:umh ,28 3,55 Page 3 de 3

118 Annexe III Code Source Le code source, ainsi que tout les outils qui ont servi à ce mémoire sont disponibles dans un CD-ROM la bibliothèque du Département d Informatique de l ULB. Le codec x264 est aussi disponible sur le site http ://developers.videolan.org/x264.html.

119 Annexe IV Paramètres des encodeurs lors des tests Les paramètres visés : Débit: 150Kbps foreman QCIF@30fps psnr: 37 mobile CIF@30fps psnr: 35 plane 4CIF@24fps psnr: 32 girl HD720p@24fps psnr: 32 tomson HD1080p@15fps psnr: 32 Les paramètres modifié d x.264 : crf 24 analyse all subme 7 no-cabac progress ref 5 8x8dct Les paramètres modifié de JM 10.2 : ProfileIDC = 66 LevelIDC = 40 NumberReferenceFrames = 5 IntraPeriod = 0 EnableOpenGOP = 0 IDRIntraEnable = 0 QPISlice = 26 QPPSlice = 26 UseHadamard = 1 RestrictSearchRange = 2 PicOrderCntType = 1 YUVFormat = 1 EPZSDualRefinement = 3 EPZSFixedPredictors = 2 EPZSTemporal = 1 EPZSSpatialMem = 1 EPZSMinThresScale = 0 EPZSMedThresScale = 1 EPZSMaxThresScale = 1 Lors des paramétrages des codecs JM et X.264, nous avons joué sur les débits par modification de QP. Le tableau suivant indique les équivalences x.264 JM, en terme de débits ; avec P SNR l amplitude maximale constatée entre les codecs

120 xiii Format QP x.264 QP JM 10.2 δp SNR (Db) SQCIF ,1 QCIF ,54 CIF ,8 4CIF ,3 720i50 24 NA NA 1080i50 24 NA NA Tableau IV.1 QP x.264 QP JM