Comparaison des performances de deux méthodes d’encodage pour un CODEC H.264

Comparaison des performances

de deux méthodes d’encodage

pour un CODEC H.264

VERGNE Aurore

2ème année Réseaux et Télécommunications

2009 - 2010

Maître de stage : Dr Yafan Zhao

Comparaison des performances de deux méthodes d’encodage pour un CODEC H.264

VERGNE Aurore 2ème année Réseaux et Télécommunications 2009-2010 1

Remerciements Je remercie tout d’abord Yafan Zhao ainsi que les membres du Center for Video Communications pour leur accueil, leur aide et leur confiance. Je tiens ensuite à remercier l’équipe pédagogique, notamment Joël Toussaint, ainsi que le personnel administratif du département Réseaux et Télécommunications pour le travail qu’ils ont accompli durant mes deux années de formation. Je tiens à adresser des remerciements particuliers à Lynsey Giroire, professeur d’anglais, pour m’avoir offert la possibilité de faire ce stage qui est, d’une part, à l’étranger et qui, d’autre part, se situe dans le domaine du codage vidéo, discipline qui n’est pas enseigné à l’Institut Universitaire de Technologie. Je la remercie également du suivi qu’elle a effectué durant celui-ci. Je remercie également Noura Guerchouch, secrétaire du département, pour l’attention qu’elle a porté la complétion et à l’envoi des dossiers de poursuite d’étude. Enfin, je remercie, Gordon Ross, réceptionniste du bâtiment de la Robert University à St Andrew Street, Ann Gardner et Malgorzata Lewandowska, secrétaires de la School of Computing, pour leur aide dans la recherche de logement et les formalités administratives.



Sommaire Remerciements………………………………………………………………………………………………………………………………...page 1 Sommaire……………………………………………………………………………………………………………………………………….. page 2 Introduction…………………………………………………………………………………………………………………………………….. page4 1. Présentation du contexte……………………………………………………………………………………………………………….. page 5 1.1. Aberdeen………………………………………………………………………………………………………………………. page 5 1.2. La Robert Gordon University…………………………………………………………………………………………….. page 6 1.2.1. La Faculty of Health and Social Care……………………………………………………………………. page 7 1.2.2. L’Aberdeen Buisiness Schoold……………………………………………………………………………. page 7 1.2.3. La Faculty of Design and Technology…………………………………………………………………… page7 1.2.4. Le Center for Video Communications…………………………………………………………………. page 7 1.3. Démarche……………………………………………………………………………………………………………………… page 9 2. Travail préliminaire : prise en main d’un CODEC………..……………………………………………………………………….. page 10 2.1. Installation de Microsoft Visual Studio……………………………………………………………………………….. page 10 2.2. Compilation du CODEC…………………………………………………………………………………………………… page 14 2.3. Prise en main de l’encodeur……………………………………………………………………………………………… page 16 2.3.1. Principes généraux d’encodage………………………………………………………………………….. page 16 2.3.2. Fichiers de configuration…………………………………………………………………………………… page 18 2.3.3. Utilisation de l’encodeur……………………………………………………………………………………. page 19 2.3.4. Étude des différents paramètres…………………………………………………………………………. page 21 2.3.4.1. Avec une trame B………………………………………………………………………………. page 21 2.3.4.1.1 Variation du nombre de trames par seconde (Frame Rate)………..... page 21 2.3.4.1.2. Variation de la compression de la trame I (QPISlice)………………….. page 22 2.3.4.1.3. Variation de la compression des trames P (QPPSlice)………………… page 22 2.3.4.1.4. Variation de la compression des trames B (QPBSlice)………………… page 23 2.3.4.2. Sans trame B…………………………………………………………………………………….. page 24 2.3.4.2.1. Variation du nombre de trames par seconde (Frame Rate)…………. page 24 2.3.4.2.2. Variation de la compression des trames I (QPISlice) et P (QPPSlice)

page 25

2.3.4.2.3. Variation du nombre de trames sautées (FrameSkip)………………… page 25 2.3.4.3. Variation du nombre de trames B (NumberBFrames)………………………………. page 26 2.3.4.3.1. Cas où le nombre de trames sautées est égal à celui des trames B.. page 26 2.3.4.3.2. Cas où le nombre de trames sautées est supérieur à celui des trames B

page 27

3. Étude de deux méthodes d’encodage……………………………………………………………………………………………….. page 28 3.1. Comparaison de deux méthodes d’encodage……………………….……………………………………………… page28 3.1.1. Présentation des deux méthodes………………………………………………………………………… page 28 3.1.2. Étude objective……………………………………………………………………………………………….. page 29 3.1.2.1. Présentation et mise en œuvre…………………………………………………………….. page 29 3.1.2.2. Résultats………………………………………………………………………………………….. page 30 3.1.3. Étude subjective………………………………………………………………………………………………. page 40 3.1.3.1. Présentation et mise en œuvre…………………………………………………………….. page40 3.1.3.2. Résultats………………………………………………………………………………………….. page 41 3.2. Étude de la relation entre qualité visuelle et MOSp………………………………………………………………. page 46 3.2.1. Définition du MOSp………………………………………………………………………………………….. page 46 3.2.2. Compilation et utilisation du nouveau CODEC………………………………………………………. page 48 3.2.3. Installation de Matlab……………………………………………………………………………………….. page 49 3.2.4. Création de la carte (map) du MOSp de chaque macrobloc……………………………………… page 54 3.2.5. Résultats…………………………………………………………………………………………………………. page 57



4. L’aboutissement de mon stage au CVC……..……………………………………………………………………………………… page 60 4.1. Résultats obtenu…………………………………………………………………………………………………………….. page 60 4.2. Difficultés rencontrées…………………………………………………………………………………………………….. page 60 4.3. Prolongements………………………………………………………………………………………………………………. page 61 Conclusion………………………………………………………………………………………………………………………………………. page 62 Bilan humain…………………………………………………………………………………………………………………………………… page 63 Questionnaire en anglais…………………………………………………………………………………………………………………… page 65 Glossaire…………………………………………………………………………………………………………………………………………. page 67 Bibliographie…………………………………………………………………………………………………………………………………… page 69



Introduction Dans le cadre de la deuxième année de Diplôme Universitaire de Technologie Réseaux et Télécommunications, il m’a été demandé de faire un stage de dix semaines. Il s’est déroulé au Center for Video Communications de la Robert Gordon University à Aberdeen, en Ecosse sous la direction du Dr Yafan Zhao. La compression de la vidéo est nécessaire afin de réduire la taille du média d’origine pour pouvoir l’envoyer sur un réseau tel qu’Internet. En effet, une séquence vidéo ayant subi peu ou pas de traitement informatique nécessite 200 kbits/s par trame ce qui conduit, pour la transmettre dans sa totalité à des débits gigantesques : généralement, pour une seconde on ne compte pas moins de 25 trames ce qui implique que le débit requis pour une seconde d’un tel type de vidéo est de 5 000 kbits/s. En plus du temps de chargement d’un média de la sorte, avoir de tel débit pose des problèmes de bande passante et, globalement, d’encombrement du réseau. Cependant, compresser un média provoque nécessairement une baisse de sa qualité. Il faut donc trouver des moyens permettant de limiter la taille du média et donc le débit qu’il requière tout en en gardant une certaine qualité. Des CODEC* tel que celui étudié dans la suite (MPEG-4 / H.264) le permettent mais ils sont loin d’atteindre une qualité visuelle et mathématique (i.e. subjective et objective1) optimale.

Le Center for Video Communications se pose ici deux questions : � le CODEC propose deux méthodes d’encodage, laquelle est objectivement et subjectivement la

meilleure ? � il y a-t-il une corrélation quelconque entre la comparaison subjective et objective ?

Ces questions ont pour but de mettre en avant des anomalies dans le code du CODEC qui pourraient provoquer une perte de qualité. Le but final, pour le Center for Video Communications, est de minimiser cette dernière. Mon sujet sera donc de répondre aux questions posées plus haut. Afin d’y répondre, j’ai organisé mon rapport de la manière suivante. Je vais, dans une première partie, présenter le contexte de ce stage. Ensuite, je vais expliquer quel fut le travail préliminaire que j’ai dû effectuer : il a consisté à la prise en main d’un CODEC. Puis je développerai mes expérimentations qui se sont déroulées en deux étapes : j’ai, tout d’abord, comparer deux méthodes d’encodage avant de m’intéresser au MOSp2 qui est un nouvel indicateur de qualité mise en place par le Center for Video Communications. Enfin, je dresserai le bilan de ce stage.

Les mots suivis * sont définis dans le glossaire page 67. 1 Ces deux méthodes de comparaison sont définies dans la partie 3.1.1. 2 Cet indicateur sera défini dans la suite de ce rapport dans la partie 3.2.1.



1. Présentation du contexte

1.1. Aberdeen Aberdeen est une ville située au nord de la Grande Bretagne, en Écosse. C’est la troisième ville de cette région en nombre d’habitants (210 000) derrière Glasgow et Édimbourg. Elle est située à l’embouchure de deux rivières : la Dee au sud et la Don au nord.

Figure 1.1.1. : Carte du Royaume-Uni

Aberdeen est bâtie principalement en granite : ce matériau a été beaucoup utilisé durant le règne la reine Victoria (époque Victorienne 1837 – 1901) et la seconde moitié du XIXème siècle. Le granite étant de couleur grise, la ville est aussi connue sous le nom de ‘‘The Grey City’’.

Figure 1.1.2. : Bâtiments en granite. À gauche, une maison sur Great Western Road et à droite une église sur Union Street

Source personnelle



De plus, Aberdeen est l’une des villes les plus riches d’Ecosse grâce à l’exploitation du pétrole offshore*. C’est d’ailleurs la capitale européenne du pétrole ‘‘Oil capital in Europe’’. En outre, la devise de la ville est ‘‘Bon accord’’ ; cette phrase était celle de reconnaissance entre écossais lors de la guerre contre les anglais.

Figure 1.1.2. : Armoiries et devise de la ville

Source : http://www.ngw.nl/int/gbr/scot/aberdee.htm

Enfin, la ville est constituée de deux universités regroupant près de 30 000 étudiants. Chacune d’entre elle en est composée d’à peu près 15 000. Ces deux universités sont la Robert Gordon University et l’University of Aberdeen. Cette dernière est la plus ancienne ; en effet, elle a été fondée en 1860 par regroupement du King’s College et du Marchial College. La Robert Gordon University est, quant à elle beaucoup plus récente. Je la présente plus en détail dans la partie suivante. L’University of Aberdeen et la Robert Gordon University sont les universités les plus au nord du Royaume-Uni.

1.2. La Robert Gordon University (RGU) La Robert Gordon University est une université moderne étant reconnue comme telle depuis 1992. En 2009, elle a été nommée ‘‘Best Modern University in the UK’’ par le Times Good University Guide. Toujours d’après le même guide, c’est la quatrième université en termes d’emplois de ces diplômés. Elle compte environ 12 800 étudiants répartis sur ces deux campus de Garthdee (en rose sur le plan) au sud et de Schoolhill (en orange) en centre-ville.

Figure 1.2.1. : Plan d’Aberdeen (sud et centre-ville)

Source : http://maps.google.co.uk



Comme la plupart des établissements scolaires au Royaume-Uni, elle a une devise en latin qui est la suivante ‘‘Omni Nunc Arte Magistra’’ qui signifie ‘‘Fait de ton mieux avec tes propres capacités’’. Elle comporte trois pôles, la Faculty of Health and Social Care, l’Aberdeen Buisiness School et la Faculty of Design and Technology.

Figure 1.2.2. : Logo de RGU

Source : http://rgu.ac.uk

1.2.1. La Faculty of Health and Social Care Située sur Garthdee, la Faculty of Health and Social Care réunit les différents départements ayant attrait aux sciences sociales et à la santé. Elle regroupe la School of Applied Social Studies spécialisée dans le social, la School of Health Sciences centralisant des disciplines telles que la médecine, la radiologie ou encore la nutrition, la School of Nursing and Midwifery qui correspond à une école d’infirmières et de sages-femmes et la School of Pharmacy and Life Sciences1 rassemblant la pharmacie et la biologie. 1.2.2. L’Aberdeen Buisiness School À l’instar de la Faculty of Health and Social Care, l’Aberdeen Buisiness School se trouve sur le campus de Garthdee. Elle est composée de l’Accounting, Finance and Economics Department étant l’un des plus grands de ce pôle et ayant pour vocation l’enseignement des finances et de l’économie, le Communications, Marketing & Media Department qui est axé sur la communication et le marketing, le Management Department qui a un des plus forts taux de réussite aux examens de Grande Bretagne et qui propose un enseignement permettant l’accès à des postes où le management est une nécessité et le Law Department dont la spécialité est le droit. 1.2.3. La Faculty of Design and Technology La Faculty of Design and Technology est à la fois sur le campus de Garthdee et de Schoolhill. Elle possède les départements suivants : la Scott Sutherland School of Architecture and Built Envirnoment et la Gray's School of Art sur Garthdee qui sont, respectivement, une école d’architecture et une d’art, la School of Computing et la School of Engineering sur Schoolhill proposant des formations en informatique pour la première et dans des domaines allant du réseau à l’électronique en passant par les sciences de l’ingénieur pour la seconde. C’est dans cette dernière que se trouve le Center for Video Communications où j’ai effectué mon stage.

1.2.4. Le Center for Video Communications Le Center for Video Communications, abrégé CVC dans la suite, est un laboratoire de recherche travaillant dans les domaines de l’imagerie et de la communication. Ses membres mènent des recherches dans les domaines suivants :

� la compression* de la vidéo grâce au codage*. � les normes de compression dont MPEG-4* et H.264*. � le codage vidéo dynamique (i.e. adaptation du taux de compression en fonction du contenu de la vidéo

[explications plus en détail dans la partie2.4]). � les codages vidéo peu complexes permettant ainsi des économies d’énergie et de temps : plus un codage est

complexe plus il nécessite de temps, de ressources matérielles et donc d’énergie. � la perception visuelle et le codage de vidéo. Le CVC cherche à répondre aux questions suivantes : comment

perçoit-on une image et quels sont les éléments qui ne doivent pas être dégradés par le codage afin que le système visuel humain* considère la vidéo comme de bonne qualité ?

� le transport de données multimédias compressées à travers un réseau. 1 Seul département de la Faculty of Heath Science est situé sur le campus de Schoolhill en centre-ville.



Figure 1.2.4.1. : Logo du CVC

Source : http://www4.rgu.ac.uk/eng/cvc/

Le CVC est organisé selon la hiérarchie suivante :

Figure 1.2.4.2. : Organigramme du CVC

Source personnelle

Le Dr Yafan Zhao est la tutrice principale de Mr James Philp qui est étudiant en 3ème année de PhD. Il travaille sur un décodeur vidéo universel pouvant être implémenté aussi bien dans des ordinateurs que dans des lecteurs DVD. Le Dr Sampath Kannangara est le superviseur principal de Ms Abharana Bhat qui a fini ses études mais mène toujours des recherches pour le CVC. Son projet est de trouver une relation entre un indicateur de qualité mathématique le MSE1 et un de qualité visuelle le MOS1 afin de développer un CODEC permettant d’avoir la meilleure qualité d’image possible. C’est à ce sujet qu’est relié le mien. En effet, je vais devoir éprouver les résultats qu’elle a déjà obtenus afin de lui permettre d’améliorer son CODEC. Pour cela, ma maître de stage va m’aiguiller quant aux expériences à mener. 1 Ces deux indicateurs sont définis dans la partie 3.2.1.

Dr Sampath Kannangara

Ms Abharana Bhat

Dr Yafan Zhao

Mr James Philp

Miss Aurore Vergne

Dr Laura Muir

Collaboration Tuteur principal Tuteur secondaire



1.3. Démarche Ma démarche se compose de trois étapes qui vont permettre de répondre aux questions posées dans l’introduction. Tout d’abord, je vais prendre en main un CODEC H.264 / MPEG-4. N’ayant aucune connaissance dans le domaine du codage vidéo, ma maître de stage, le Dr Yafan Zhao, a jugé qu’il était plus judicieux de me faire commencer par le début c'est-à-dire par la compréhension des principes généraux d’encodage (à l’aide de la lecture d’un livre) et des différents paramètres du CODEC ainsi que son fonctionnement global. En effet, celui-ci peut paraitre compliqué au premier abord car il s’utilise en lignes de commandes et est fourni sous la forme de fichiers à compiler* soit même. Cette découverte s’accompagne de la lecture d’un ouvrage expliquant les principes fondamentaux du codage MPEG-4 / H.264. Cette étape est primordiale à la bonne marche de mon sujet car elle me permet de comprendre le fonctionnement basique d’un CODEC vidéo. Ensuite, je vais comparer de manière objective et subjective les deux méthodes d’encodage proposée par le CODEC afin de déterminer laquelle est la plus performante. Cette phase est composée de deux parties : la première consiste à la comparaison des méthodes elles-mêmes ; la seconde est la vérification de la relation entre le MOSp et la qualité visuelle d’une séquence. Enfin, je répondrai aux questions posées dans l’introduction grâces aux résultats et aux observations des parties précédentes.

Figure 1.3.1. : Démarche mise en place pour résoudre mon sujet

Source personnelle

- lecture d'un livre expliquant les principes du

codage de la vidéo

- prise en main d'un CODEC

Comparaison objective et

subjective de deux méthodes

d'encodage

Vérification de la relation entre

MOSp et qualité visuelle

♦ quelle méthode est la plus performante ?

♦ il y a-t-il corrélation entre qualitié visuelle

et MOSp ?

Travail préliminaire Étude de deux méthodes d’encodage Conclusion



2. Travail préliminaire : prise en main d’un CODEC Il m’a été demandé de télécharger un CODEC permettant d’encoder une vidéo au format MEPG-4 / H.264. Je l’ai téléchargé, sur les conseils de ma maitre de stage, à l’adresse : http://iphome.hhi.de/suehring/tml/download/version 12.1. Il se présente sous la forme d’une archive zip contenant des fichiers en langage C à compiler soi-même. Je l’ai, dans un premier temps, décompressé. Puis, je l’ai compilé après avoir, au préalable, installer Microsoft Visual Studio 2008 dont l’utilisation est recommandée par la documentation du CODEC disponible à l’adresse suivante : http://iphome.hhi.de/suehring/tml/JM%20Reference%20Software%20Manual%20%28JVT-AE010%29.pdf.

2.1. Installation de Microsoft Visual Studio 2008 Microsoft Visual Studio est un IDE* regroupant plusieurs outils de développement édité par Microsoft. Il permet de gérer des projets complexes, c'est-à-dire nécessitant plus d’un fichier source écrit en un langage de programmation quelconque. Visual Studio en prend en charge une grande variété (C, C++, Visual Basic, XML, xHTML, JavaScript et CSS). Je procède à son installation sur mon ordinateur personnel. Après avoir mis le DVD, dans le lecteur, la fenêtre suivante apparait.

Figure 2.1.1. : Écran de sélection des composants à installer

La seule option actuellement possible est ‘‘Install Visual Studio 2008’’. Par conséquent, je clique sur le texte encadré en rose sur la capture. Le programme d’installation charge alors les éléments nécessaires à l’installation. De plus, une case à cocher permet ou non au programme d’envoyer des informations sur l’installation à Microsoft. Ne souhaitant pas en transmettre, je ne coche pas la case.



Figure 2.1.2. : Chargement des fichiers nécessaires à l’installation

Une fois le chargement terminé et après avoir cliqué sur ‘‘Next’’, il faut accepter la licence présente sur le produit en sélectionnant ‘‘I have read and accept the license term’’, saisir la clé et le nom d’utilisateur et cliquer, une fois de plus sur ‘‘Next’’.

Figure 2.1.3. : Écran d’acceptation de la licence et de saisi de la clé du produit

Il est désormais demandé de choisir le type d’installation voulu. Ils sont au nombre de 3 : par défaut, complète et personnalisée. Une installation par défaut installe le programme ainsi que les composants nécessaires à son bon fonctionnement, une installation complète installe le programme et tous ses composants optionnels et une installation personnalisée laisse le choix à l’utilisateur des éléments devant être installés. Certains composants tels que Microsoft SQL Server ne m’étant pas utiles c’est cette dernière que je choisis.



Figure 2.1.4. : Écran de sélection du type d’installation

Pour cela, je sélectionne ‘‘Custom’’ sur la capture précédente et clique sur ‘‘Next’’. Puis je décoche tout ce qui est en plus de Visual Studio c'est-à-dire Microsoft SQL Server, Crystal Reports Basic for Visual Studio 2008 et Crystal Reports Basic 64-bits Runtime for Visual Studio 2008.

Figure 2.1.5. : Écran de sélection des composants de Visual Studio à installer

Je clique sur ‘‘Install’’. L’installation commence alors et dure une vingtaine de minutes. Une fois qu’elle est achevée, l’écran suivant apparait.



Figure 2.1.6. : Écran indiquant la fin de l’installation

Je clique sur ‘ ‘Finish’’. Le programme étant installé, je peux le lancer en cliquant sur l’icône de lancement présent dans la rubrique ‘‘Microsoft Visual Studio’’ du menu démarrer.

Figure 2.1.7. : Visual Studio après démarrage

Le programme se lance.



2.2. Compilation du CODEC La première étape consiste à démarrer Visual Studio. Il faut ensuite ouvrir le projet que l’on veut compiler,

pour cela, il faut cliquer sur le bouton ‘‘Open’’ et sélectionner le fichier projet voulu (son extension* est .sln). Dans mon cas, il se trouve dans D:\AURORE\IUT\Stage\JM.

Figure 2.2.1. : Écran de sélection du fichier à ouvrir

Sur la capture ci-dessus, nous pouvons voir qu’il y a plusieurs fichiers .sln. Ceux-ci correspondent aux différentes versions de Visual Studio. En effet, pour des soucis de compatibilité, l’auteur du codec a choisi de l’enregistrer sous diverses versions du logiciel. D’après la documentation, pour l’utiliser avec Visual Studio 2008, il faut prendre ‘‘jm_vc9.sln’’. Ce fichier n’étant pas présent, je choisis celui correspondant à la version la plus récente avant 2008, c'est-à-dire 2005. Le fichier convenant est ‘‘jm-vc8.sln’’. Je l’ouvre. Une fois ouvert, l’arborescence du projet apparait sur la partie droite de l’écran (cadre rose sur la capture suivante).

Figure 2.2.2. : Écran de gestion du projet



Ce projet se compose de 3 programmes :

� lencod qui encode la vidéo � ldecod qui la décode � rtpdumb qui permet d’analyser les paquets RTP*

N’ayant jamais compilé ce projet précédemment, je vais devoir le compiler en totalité (i.e. les 3 programmes). Pour cela, il faut se rendre dans le menu ‘‘Buid’’ en haut et choisir ‘‘Build Solution’’.

Figure 2.2.3. : Menu permettant de compiler un projet

À noter : si l’on ne veut compiler qu’un seul programme, par exemple ‘‘ledecod’’, il suffit de le sélectionner dans la partie de droite (cf figure 2.2.2.), d’aller dans ‘‘Buid’’ puis de cliquer sur ‘ ‘Build ldedecod’’. La compilation commence alors. Une fois celle-ci terminée, le nombre de succès, d’erreurs, de mises à jour et de parties sautées apparaissent dans la partie ‘‘Output’’ située en bas de l’écran. Dans le cadre rose, on peut voir qu’il y a eu trois succès et aucune erreur. Les programmes se trouvent dans le même dossier que les fichiers d’extension .c qui le compose c'est-à-dire dans D:\AURORE\IUT\Stage\JM\bin.

Figure 2.2.4 : Log* des événements s’étant produit durant la compilation

La compilation ayant réussi, je peux désormais prendre en main le programme d’encodage (lencod.exe) en décrivant les principes généraux de codage en MPEG-4 / H.264 puis en étudiant la fonction des différents paramètres du CODEC.



2.3. Prise en main de l’encodeur Avant de modifier les paramètres d’encodage, je dois d’abord comprendre quels sont les principes généraux d’encodage dans le cas du MPEG-4 / H.264. Ils sont décrits dans le livre H.264 and MPEG-4 Video Compression – Video compression for Next-generation Multimedia de Iain E.G. Richardson dont j’ai dû lire certains chapitres (se reporter aux notes à l’annexe I).

2.3.1. Principes généraux d’encodage Dans cette partie, je vais évoquer les principes d’encodages qui seront utiles dans la suite de ce rapport. Tout d’abord, il faut savoir qu’une scène filmée est continue dans le temps et dans l’espace, par conséquent, un CODEC vidéo utilise deux types d’échantillonnages* : un temporel et un spatial. L’échantillonnage temporel consiste à prendre une série de trames issues de la vidéo à intervalles réguliers. Le spatial, quant à lui, a pour rôle d’échantillonner une série de points de l’image disposés sur une grille. Chaque échantillon décrit la luminosité et la couleur de l’image en ce point et est représenté comme un nombre.

Figure 2.3.1.1. : Échantillonnage spatio-temporel Source personnelle

L’échantillonnage spatial se fait sur une grille rectangulaire ou carrée. Plus celle-ci a de carreaux, plus il y a d’échantillons et donc meilleure est la qualité. Chaque échantillon est placé à l’intersection d’une horizontale et d’une verticale et à une forme carrée : c’est un pixel. L’échantillonnage temporel consiste à capturer des images à intervalles réguliers. Plus le nombre de trames est grand, plus le mouvement est fluide, moins il y en a, plus celui-ci est saccadé. Comme je l’ai dit ci-dessus, chaque échantillon décrit la luminosité et la couleur de l’image en ce point. Mais, il est bon de se demander quelles sont les méthodes permettant de décrire la couleur. Si l’image est monochrome*, un indicateur de luminosité suffit. Si l’image est en couleur, il y a deux méthodes :

� le RGB (Red, Green, Blue) ou RVB (Rouge, Vert, Bleu) en français code chaque échantillon et donc chaque pixel, à l’aide de trois nombres : le premier indique la quantité de rouge, le second celle de bleu et le dernier, celle de vert. Avec ce procédé, il faut capturer chaque composante séparément. À une distance normale (c'est-à-dire 50 cm ou plus), la réunion de ces trois couleurs permet de voir la couleur d’origine de l’image.

Figure 2.3.1.2. : Décomposition RVB

Source personnelle

Cependant, avec cette méthode, les couleurs ont toutes la même luminosité ce qui peut poser des problèmes au niveau du contraste.

Échantillonnage temporel

Échantillonnage spatial

250 141 61



� le YCbCr est un moyen efficace pour représenter les couleurs et la luminosité. Cette dernière à une

meilleure résolution que les couleurs. En effet, le système visuel humain est plus sensible à la luminance qu’à la chrominance. Il est donc nécessaire de la privilégier par rapport aux couleurs c’est pour cette raison que je comparerai le rapport signal de la luminosité et non ceux des couleurs dans la suite de ce rapport (se reporter à l’annexe I partie 2.4.2. pour les calculs). Il existe plusieurs formats d’échantillonnage pour le YCbCr. Le premier d’entre est le 4:4:4 : les trois composantes ont la même résolution verticale et horizontale : il y a 4 luminances pour 4 composantes bleues et 4 rouges. Ce format est fidèle à l’original sur le plan de la chrominance*. Le second est le 4:2:2 : la chrominance a la même résolution verticale que la luminance* et une demi-résolution horizontale (pour 4 luminances, il y a 2 composantes bleues et 2 rouges). Il est utilisé pour la reproduction haute qualité des couleurs. Le troisième format est le 4:2:0 : les composantes représentant les couleurs ont une demi-résolution verticale et horizontale de celle de luminosité. Il est utilisé pour les conférences vidéo, la télévision numérique et les DVD. Les deux derniers formats correspondent à une compression de l’image car toutes les composantes n’ont pas la même résolution.

Figure 2.3.1.3. : 4:4:4, 4:2:2 et 4:2:0 Source personnelle

En plus de la compression apportée par les formats décrits ci-dessus, l’encodeur cherche à supprimer la redondance spatiale et / ou temporelle c'est-à-dire les éléments de l’image se répétant sur plusieurs images successives ou sur une partie de celle-ci. En effet, si des images ont été capturées autour du même instant, il y a de fortes chances qu’il y ait une forte corrélation temporelle (c’est d’autant plus vrai si la fréquence d’échantillonnage est élevée). De plus, des pixels adjacents ont souvent une valeur RVB ou YCrCb voisine. Pour permettre cette suppression, il existe des méthodes telles que la compensation de mouvement. Celle-ci peut être de deux types : la compensation de mouvement faite à partir de la trame précédente et l’estimation de mouvement. La première fait la différence entre la trame prédite et l’actuelle. La seconde, quant à elle, estime la trajectoire de chaque pixel en fonction du type de mouvement (caméra ou objet) (se reporter à l’annexe I partie 3.3.2. et suivantes). Enfin, il faut savoir que dans une séquence à encoder, il y a 3 types de trames :

� la trame I est la première d’une séquence. Elle est donc unique et est précédée d’un entête dont la taille est paramétrable.

� les trames P suivent la I. Pour en encoder une, il faut avoir codé celle qui la précède.

Figure 2.3.1.4. : Encodage d’une trame P

Source personnelle

� les trames B sont ajoutées lors de l’encodage. Elles ne sont donc pas présentent dans la séquence

originale. La plupart des encodeurs permettent de choisir la fréquence à laquelle on les crée. Pour encoder une trame B, il est nécessaire d’avoir encodé la trame qui la précède et celle qui la suit.

Figure 2.3.1.5. : Encodage d’une trame B

Source personnelle

Après avoir défini les principes généraux d’encodage, je peux me pencher sur le fichier de configuration de l’encodeur (lencod.exe).

P

B



2.3.2. Fichiers de configuration Le fichier de configuration de l’encodeur (lencod.exe) se trouve dans D:\AURORE\Stage\JM\bin et a comme extension .cfg. Il est possible de l’ouvrir avec un simple éditeur de texte, le Bloc-Notes de Windows par exemple. Il se présente sous la forme ‘‘NomDuParamètre = Valeur #Commentaire ’’. Le nombre de paramètres qu’il contient est très grand. Par conséquent, je ne vais pas tous les commenter (ils le sont tous dans la documentation) mais expliquer les plus importants. InputFile = "foreman.qcif" #Séquence à encoder. Les formats supportés sont cif*, qcif* et yuv*. InputHeaderLength = 0 #Taille de l’entête du fichier de sortie. S’il en a une, le nombre de bits total de la séquence encodée est plus grand. La valeur par défaut est 0. StartFrame = 0 #Première trame à encoder, on peut, par exemple, commencer l’encodage à la trame 5. FramesToBeEncoded = 50 #Nombre de trames total à encoder. FrameRate = 30.0 #Nombre de trames par secondes (doit être compris entre 0,1 et 100,0). La valeur pat défaut est 30,0. SourceWidth = 176 #Largeur des images de la séquence source, ce doit être un multiple de 16. La valeur par défaut est 176. SourceHeight = 144 #Hauteur des images de la séquence source ce doit être un multiple de 32. La valeur par défaut est 144. ReconFile = "D:\AURORE\IUT\Stage\Test\foremanRC10_r ec.yuv" #Emplacement du fichier servant à reconstruire la vidéo. OutputFile = "D:\AURORE\IUT\Stage\Test\foremanRC10. 264" #Emplacement de la séquence de sortie obligatoirement au format .264*. C’est le programme servant à décoder qui reconstruit le fichier au format cif/qcif à l’aide de ce fichier et du ‘‘ReconFile’’. ProfileIDC = 100 #Permet de choisir entre les modes de compensation ou prédiction de mouvement (cf partie précédente). Cette valeur est également en corrélation avec le format YUV que l’on veut. La valeur par défaut est 88. Les valeurs possibles sont définies dans la documentation. 100 correspond à ‘‘High’’ ce qui permet d’avoir une prédiction de l’image suivante élevée et donc précise. QPISlice = 28 #Paramètre d’encodage de la trame I (doit être entre 0 et 51). Il s’apparente à un taux de compression. Dans la suite je le nommerai aussi paramètre de qualité. QPPSlice = 28 #Paramètre d’encodage des trames P (doit être entre 0 et 51). Il s’apparente à un taux de compression. Dans la suite je le nommerai aussi paramètre de qualité. FrameSkip = 1 #Nombre de trames sautées lors de l’encodage (s’il est à 1 ou plus, cela permet de créer des trames B) NumberBFrames = 1 #Nombre de trames B. Ce paramètre doit être inférieur ou égal au précédent. QPBSlice = 30 #Paramètre d’encodage des trames B (doit être entre 0 et 51). Il s’apparente à un taux de compression. Dans la suite je le nommerai aussi paramètre de qualité. RateControlEnable = 0 #Activer (1) le ‘‘Rate Control’’ permet d’encoder les trames avec un QP différent en fonction du débit voulu. Par défaut, ce paramètre est désactivé sa valeur est 0. Bitrate = 100000 #Débit souhaité en bits/s. Ce paramètre est utilisé par le ‘‘RateControl’’ InitialQP = 0 #QP de la trame I si l’on fait du ‘‘RateControl’’. Si ce paramètre est à 0 (valeur par défaut), l’encodeur choisi le meilleur QP en fonction du débit voulu. BasicUnit = 99 # Définit l’unité de base pour l’encodage. S’il est à 99, un macrobloc* correspond à une unité de base. Par conséquent, le QP change pour chaque macrobloc. L’encodeur se charge de faire la moyenne des QP de chaque macrobloc pour avoir celui de la trame. Exemple : si BasicUnit = 11 ; chaque groupe, pouvant avoir un QP différent, est composé de 11 macroblocs. ChannelType = 0 #Type de canal de transmission. Si le canal varie au cours du temps, ce paramètre doit être à 1 et à 0 s’il est constant. YUVFormat = 1 #Type de format YUV. 1 correspond au format 4:2:0 qui est celui par défaut. Les valeurs possibles et le format YUV correspondant sont définis dans la documentation. Je peux désormais modifier les paramètres cités ci-dessus afin de mieux comprendre leur fonction en étudiant leur effet sur la vidéo.



2.3.3. Utilisation de l’encodeur L’encodeur s’utilise en ligne de commandes. Pour ouvrir une console, il faut aller dans Démarrer/Tous les programmes/Accessoires/Exécuter. Puis il faut taper ‘‘cmd’’.

Figure 2.3.3.1. : La console lors de son ouverture

Il faut ensuite se placer dans le dossier où se trouve le programme (D:\AURORE\Stage\JM\bin). Comme on peut le voir sur la capture ci-dessus, on se trouve dans C:\Users\Erra ce qui correspond à mon répertoire personnel. Or, le programme se trouve sur la deuxième partition de mon disque dur il faut donc s’y rendre. Pour cela, je saisis : d: Il faut ensuite que je me place dans le bon répertoire : cd AURORE/IUT/Stage/JM/bin (Windows interprète le slash (/) comme un anti-slash (\) qui est le séparateur de ce système d’exploitation).

Figure 2.3.3.2. : La console une fois dans le bon répertoire

On est donc dans le bon répertoire. Pour exécuter le programme, il faut utiliser la commande suivante : lencod.exe [ –d fichier_conf.cfg] La partie entre crochets est optionnelle. Si on ne définit pas le fichier de configuration à utiliser, c’est celui par défaut (encoder.cfg) dont on se sert. L’encodage commence. Des lignes nous rappelant le fichier de configuration utilisé, les séquences d’entrée et de sortie, le format YUV ainsi que le nombre de trames à encoder apparaissent.

Figure 2.3.3.3. : Les premières lignes de log

Fichier de configuration utilisé

Séquences d’entrée et de sortie

Format YUV

Nombre de trames I et P à encoder / nombre de trames B à encoder



Ensuite, les valeurs correspondantes à chaque trame encodée apparaissent une à une dans la console.

Figure 2.3.3.4. : Les différentes valeurs pour chaque trame

Il y a deux trames ‘‘0000’’ : la première (NVB) est une entête, la seconde est la première trame de la séquence (c’est la trame I). De plus, l’encodeur encode la trame 0 puis la 2 car il y a une trame sautée et une trame B. Or, pour coder une trame B, il faut avoir codée celle qui la précède (la 0 dans ce cas) et celle qui la suit (la 2) (cf 2.3.1 Principes généraux d’encodage). À côté du numéro de la trame, on trouve, entre parenthèses, le type de celle-ci. Les différentes colonnes correspondant au nombre de bits sur lequel la trame est codée (en rose), le taux de compression de la trame (en orange), le rapport signal sur bruit (SNR) par rapport aux différentes composantes de la trame (Y correspond à la luminance, U et V au couleurs) (en violet), le temps mis pour coder la trame (en marron), le temps de l’estimation de mouvement (en vert), le type d’encodage de l’image (en bleu) et l’indicateur de référence pour l’image (en rouge). Une fois l’encodage terminé, on obtient des informations générales sur celui-ci.

Figure 2.3.3.5. : Les différentes valeurs moyennes de cet encodage

Nombre total de trames encodées (nombre de trames B)

Temps total d’encodage (nombre de trames encodées par seconde)

Temps total de calcul de l’estimation de mouvement

Débit

Forme de la séquence et rappel des QP pour chaque type de trame

Nombre total de bits (bits utilisés pour les trames I, P, B et l’entête)

Moyenne du SNR de chaque trame pour chaque composante

À noter : on peut sauvegarder ce qui apparait dans la console dans un fichier. Il suffit d’utiliser la commande suivante : lencod.exe [–d fichier_conf.cfg] > fichier_log.txt

Fréquence pour l’encodage. Cette valeur est égale au FrameRate (nombre de trame par seconde) sauf s’il y a des trames B ce qui est le cas ici.



2.3.4. Étude de quelques paramètres Tous les tests ont été faits avec le format YUV par défaut c'est-à-dire 4:2:0. 2.3.4.1. Avec une trame B Je teste les différents paramètres en ayant une trame B car c’est la configuration par défaut. Les captures d’écran pour toutes les expérimentations à suivre se trouvent dans l’annexe II. 2.3.4.1.1. Variation du nombre de trames par seconde (FrameRate) Je commence par étudier l’effet du nombre de trames par seconde. Pour cela, je modifie le paramètre ‘‘FrameRate’’. Je compare le résultat de l’encodage pour deux valeurs : 30 et 10. J’obtiens les valeurs suivantes.

Nombre de trames par seconde 30 10 Nombre de trames à encoder 10 10 Nombre de trames B ajoutées 9 9

Nombre de trames encodées au total 19 19 Fréquence pour l’encodage 15 5

Débit (kbits/s) 138,25 46,08 Nombre de bits total 87 560 87 560

La fréquence pour l’encodage correspond, dans chaque cas à la moitié du nombre de trames par seconde. En effet, il y a une trame B ajoutée entre chaque trame P. Par conséquent, une trame sur deux doit être créée par l’encodeur ce qui provoque une diminution de la fréquence lors de l’encodage. De plus, le débit pour un ‘‘FrameRate’’ de 30 est plus grand que pour un de 10 : dans un cas, une séquence d’une seconde comportera 30 images alors que dans l’autre, il n’y en aura que 10. Il faut donc avoir un débit plus important pour faire passer 30 images par seconde que pour en faire passer 10. Enfin, le nombre total de bits sur lequel la séquence est codée ne diffère pas. Cela s’explique par le fait que le nombre de trames à encoder est le même dans les deux cas : il y a 1 trame I, 9 trames P et B. Pour conclure sur cette expérience, je peux dire que le nombre de trames par seconde influe sur le débit et sur la fréquence d’encodage des trames : plus il est grand, plus le débit est important tout comme la fréquence pour l’encodage. Cependant, il n’a aucune influence sur le nombre de bits utilisés pour coder la séquence. Je vais maintenant m’intéresser à la variation de la qualité et donc du taux de compression de chaque type de trames en commençant par la trame I.



2.3.4.1.2. Variation de la compression de la trame I (QPISlice) Le paramètre correspondant à la qualité de la trame I est ‘‘QPISlice’’. Les valeurs qu’il peut prendre doivent être comprises entre 0 et 51 Je compare les résultats pour 3 valeurs : celle par défaut, 28, la maximale, 51, et la minimale 0. J’obtiens le tableau suivant.

QPISlice = 0 QPISlice = 28 QPISlice = 51 Nombre de bits sur lequel est codée la trame I 193 256 20 704 1 752

SNR Y 75,937 dB 37,455 dB 23,35 dB Débit (kbits/s) 136,15 46,08 44,26

Nombre de bits total 258 680 87 560 84 088 Le nombre de bits sur lequel la trame I est encodée varie énormément en fonction du ‘‘QPISlice’’. Si ce paramètre est à 0, cela correspond à une compression entropique* que l’on nomme CABAC*; le nombre de bits sur lequel est codé la trame est donc important et, de fait, le nombre de bits total l’est aussi, tout comme le débit. Inversement, si le ‘‘QPISlice’’ est grand, on a une forte compression d’où la diminution du nombre de bits (au total ou pour la trame I) et du débit. Pour ce qui est du rapport signal sur bruit de la composante de la luminosité (SRN Y), plus la compression augmente (c'est-à-dire plus ‘‘QPISlice’’ est grand), plus il se détériore : il devient plus petit et, par conséquent, la qualité objective de l’image1 est moindre. Je vais désormais faire la même expérience pour les trames P et B. 2.3.4.1.3. Variation de la compression des trames P (QPPSlice) Le paramètre réglant à la qualité des trames P est ‘‘QPPSlice’’. Il admet le même intervalle de valeurs que le ‘‘QPISclice’’. Je vais, là aussi, comparer les résultats pour trois valeurs : les mêmes que pour la partie précédente. Avec les paramètres par défaut, c'est-à-dire une trame B et une trame sautée (NumberBFrames = FrameSkip = 1), une trame sur deux est une B.

Figure 2.3.4.1.3.1. : Succession des différentes trames pour les paramètres par défaut et ordre d’encodage (se référer à la figure 2.3.4.)

Source personnelle

QPPSlice = 0 QPPSlice = 28 QPPSlice = 51 Intervalle sur lequel sont

codées les trames P Moyenne

120 560 - 159 352

129 126

4 992 – 7 792

6 359

256 – 624

439 Intervalle SNR Y

Moyenne 65,241 dB - 71,563 dB

70,580 dB 36,857 dB – 37,035 dB

36,931 dB 24,624 dB - 28,173 dB

25,785 dB Débit (kbits/s) 627,16 46,08 43,25

Nombre de bits total 1 191 608 87 560 82 168 Nombre de bits pour les

trames P 1 162 136 57 232 3 952

Tout comme pour la trame I, le nombre de bits sur lequel sont codés les P varie beaucoup en fonction du QP : plus celui-ci est grand, plus le nombre de bits est faible et inversement. Pour le rapport signal sur bruit de la luminance, celui-ci se détériore lorsque la compression augmente. De fait, plus la compression augmente, plus la qualité objective de l’image diminue. Ces observations sont conformes à celles faites pour la trame I. Je vais m’intéresser, dès lors, aux trames B. 1 La qualité objective sera définie dans la suite de ce rapport (partie 3.1.2.).

1 3

2 4

B B I P P Vidéo



2.3.4.1.4. Variation de la compression des trames B (QPBSlice) Le paramètre permettant de choisir la qualité des trames B se nomme ‘‘QPBSlice’’. Je compare, encore une fois, les résultats pour les 3 mêmes valeurs c'est-à-dire, la valeur par défaut (30), la maximale (51) et la minimale (0).

QPBSblice = 0 QPBSlice = 30 QPBSblice = 51 Intervalle sur lequel sont

codées les trames B Moyenne

144 184 - 158 408

153 483

832 - 1 792

938

96

96 Intervalle SNR Y

Moyenne 64,734 dB – 72,468 dB

71,243 dB 36,070 dB – 36,534 dB

36,257 dB 28,951 dB – 34,090 dB

32,169 dB Débit 768,14 kbits/s 46,08 kbits/s 41,57 kbits/s


trames B 1 381 352 9 448 864

Là encore, le nombre de bits sur lequel sont codées les trames B varie énormément en fonction du paramètre de qualité : plus le QP est grand, plus la compression l’est aussi, moins le nombre de bits utilisés par la trame est important. Les observations faites précédemment quant au SNR sont encore une fois valables c'est-à-dire, plus le taux de compression et, de fait le QP, est élevé, plus le signal sur bruit est petit et donc moindre est qualité objective de l’image. Des trois expériences précédentes, je peux déduire que ‘‘QPISlice’’, ‘‘QPPSlice’’ et ‘‘QPBSlice’’ influent, de la même façon, sur les trames dont ils modifient la qualité. Ayant la même fonction, ces trois paramètres seront regroupés, dans la suite du présent rapport, sous le terme QP. Lorsque celui-ci est grand, il y a une forte compression ; la trame codée utilise donc peu de bits ; le SNR Y est petit ce qui implique une mauvaise qualité objective de l’image. S’il est petit, la compression est faible, le nombre de bits est plus important tout comme le ratio signal sur bruit de la luminance ce qui signifie que l’image est, objectivement, de meilleure qualité. Cependant, il est possible de voir la dégradation de la vidéo de manière subjective1 comme le montre la figure suivante : plus le QP est élevé, moins l’image est nette. La séquence 1 n’a pas de compression, elle sert de référence. Sur séquence 2, le visage de la fillette est flou mais reste reconnaissable ce qui n’est plus le cas sur la 3. Cette dernière est composée de gros blocs de pixels ce qui la rend grossière et donc floue : il n’est plus possible de distinguer clairement les contours des visages.

Figure 2.3.4.1.4.1. : Exemple de vidéo compressée. De gauche à droite QP=0, QP= 28 et QP=51.

Source personnelle

Je réitère les même expériences sans trame B cette fois-ci. 1 La qualité subjective sera définie dans la suite de ce rapport (partie 3.1.3.).

1 2 3



2.3.4.2. Sans trame B Je vais, dans un premier temps, faire varier le nombre de trames par secondes (‘‘FrameRate’’), puis je vais modifier le paramètre de qualité des trames I et P (‘‘QPISlice’’ et ‘‘QPPSlice’’) et, enfin, je vais tenter de comprendre l’influence des trames sautées (‘‘FrameSkip’’). Les captures d’écran pour toutes les expérimentations à suivre se trouvent dans l’annexe II. 2.3.4.2.1. Variation du nombre de trames par seconde(FrameRate) Le paramètre à modifier est ‘‘FrameRate’’. Je vais comparer le débit ainsi que le nombre de bit total pour les mêmes valeurs que précédemment c'est-à-dire 10 et 30 trames par seconde.

Frame Rate / Nombre de trames par seconde 30 10

Avec 1 trame B

Fréquence pour l’encodage 15 5 Nombre de trames à encoder (‘‘FramesToBeEncoded’’) 10 10

Nombre de trames B ajoutées 9 9 Nombre de trames encodées au total 19 19

Débit (kbits/s) 138,25 46,08 Nombre de bits total 87 560 87 560

Sans trame B

Fréquence pour l’encodage 30 10 Nombre de trames à encoder (‘‘FramesToBeEncoded’’) 10 10

Débit (kbit/s) 168,31 56,10 Nombre bits total 56 104 56 104

Je remarque que la fréquence pour l’encodage est égale au nombre de trames par seconde. En effet, il n’y a plus de trame à créer une fois sur deux ce qui réduit le temps de calcul de l’encodeur et évite donc une diminution de la fréquence lors de l’encodage. De plus, le débit, sans trames B, est plus important de 30 kbit/s pour un nombre de trames par seconde de 30 et de 10 kits/s pour un nombre d’images par seconde de 10. Je peux donc en déduire que l’ajout de trames B permet de faire diminuer le débit de la vidéo : c’est, de fait, une sorte de compression. Cependant, le nombre de bits total avec une trame B est plus grand que sans. Cela s’explique par le fait, que, dans le cas où il y a une B, on ajoute des trames et donc des bits. Je vais désormais m’intéresser aux QP de la trame I et des trames P.



2.3.4.2.2. Variation de la compression des trames I (QPISlice) et P (QPPSlice) Les paramètres à modifier pour changer la qualité des trames I et P sont respectivement ‘‘QPISlice’’ et ‘‘QPPSlice’’. Je fais trois tests avec les mêmes valeurs que dans les parties 2.3.4.1.2, 2.3.4.1.3 et 2.3.4.1.4 (0, 28 et 51).

QPISlice = 0 QPISlice = 28 QPISlice = 51

Avec 1 trame B

Nombre de bits sur lequel est codée la trame I 193 256 20 704 1 752 SNR Y 75,937 dB 37,455 dB 23,35 dB

Débit (kbits/s) 136,15 46,08 44,26 Nombre de bits total 258 680 87 560 84 088

Sans trame B

Nombre de bits pour la trame I 192 984 20 520 1 720 SNR Y 75,180 dB 37,429 dB 23,268 dB Débit 226,90 kbits/s 56,10 kbits/s 52,88 kbits/d

Nombre de bits total 226 904 56 104 52 880

QPPSlice = 0 QPPSlice = 28 QPPSlice = 51

Avec 1 trame B

Intervalle sur lequel sont codées les trames P

Moyenne

120 560 - 159 352

129 126

4 992 – 7 792

6 359

256 – 624


Moyenne 65,241 dB - 71,563 dB

70,580 dB 36,857 dB – 37,035 dB

36,931 dB 24,624 dB - 28,173 dB

25,785 dB Débit (kbits/s) 627,16 46,08 43,25


trames P 1 162 136 57 232 3 952

Sans trame B

Intervalle sur lequel sont codées les trames P

Moyenne

106 554 - 151 824

115 953

2 960 - 4 432

3 934

120 - 312


Moyenne 65,276 dB – 70,677 dB

69,792 dB 36,788 dB - 36,930 dB

36,854 dB 24,258 dB – 29,738 dB

26,108 dB Débit (kbits/s) 1 064,28 56,10 22,60

Nombre de bits total 1064,28 kbits/s 56 104 22 600 Nombre de bits pour les

trames P 1 043 584 35 408 1 904

Les observations faites dans la partie précédente sont encore vraies ici : plus le QP est grand, plus la compression des trames est grande et donc, moins elles prennent de bits. De plus, le SNR diminue en fonction du QP : plus ce dernier est grand, plus le rapport signal sur bruit est petit et donc plus l’image est de mauvaise qualité objective. Je peux donc en déduire que le QP a la même fonction qu’il y est ou non, des trames B. Je vais maintenant m’intéresser au paramètre qui permet de définir le nombre de trames que l’on saute lors de l’encodage. 2.3.4.2.3. Variation du nombre de trames sautées (FrameSkip) Le paramètre permettant de sauter des trames lors de l’encodage est ‘‘FrameSkip’’. Sauter des trames signifie ne pas encoder toutes les encoder. Par exemple, si on en en saute 1, l’encodeur va coder la 0, la 2 puis la 4 et ainsi de suite. De plus, pour un même nombre de trames à encoder, plus le nombre de trames sautées est important, plus on est loin dans la vidéo. Je m’explique. Si on encode 5 trames sans en sauter, on aura les trames suivantes 0, 1, 2, 3 et 4 ; si en en saute une, 0, 2, 4, 6 et 8 ; si en saute deux 0, 3, 6, 9 et 12. Je me suis posée la question de savoir quelle est l’influence du saut de trames sur la fréquence d’encodage et sur le débit. Pour cela, j’ai encodé 3 fois la même séquence avec 0, 1 et 4 trames sautées.



Figure 2.3.4.2.3.1. : Exemple d’encodage avec 0, 1 et 4 trames sautées. Source personnelle

0 trame sautée 1 trame sautée 4 trames sautées QPISlice = QPPSlice= 28 ; QPBSlice = 30

Fréquence pour l’encodage 10 5 2 Débit 56,10 kbits/s 37,50 kbits/s 18,19 kbits/s

Lorsque le nombre de trames sautées augmente, j’observe une diminution de la fréquence pour l’encodage par deux lorsqu’il y a une trame sautée et par cinq quand il y en a quatre. Le débit est également moins élevé. Cela peut s’expliquer par le fait que l’encodeur doit calculer le nombre de trames à sauter. Après m’être intéressée à l’impact des différents paramètres en présence ou non de trames B. Je vais me pencher sur la variation du nombre de celles-ci afin de voir l’impact sur le débit et la fréquence pour l’encodage. 2.3.4.3. Variation du nombre de trames B Dans cette partie, je vais étudier deux cas : dans le premier le nombre de B est égal au nombre de trames sautées (NumberBFrame = FrameSkip). Dans le second, le nombre de trames sautées est supérieur à celui des B (NumberBFrame < FrameSkip). Les captures d’écrans pour toutes les expérimentations qui suivent se trouvent à l’annexe II. À noter : le nombre de trames B ne peut pas être plus grand que celui de trames sautées. En effet, pour créer une trame B, il faut laisser une trame vide entre deux trames P ou entre une trame I et une P. (se reporter à la figure 2.3.4.1.3.1). 2.3.4.3.1. Cas où le nombre de trames sautées est égal à celui des trames B Dans cette étude, les paramètres ‘‘NumberBFrame’’ et ‘‘FrameSkip’’ sont égaux. Je vais mener la même expérience pour quatre valeurs. Lorsqu’il y a une trame B l’encodage se passe de la même manière qu’à la figure 2.3.4.1.3.1. Quand il y a 2 trames B, l’encodage se fait comme expliqué sur la figure suivante.

Figure 2.3.4.3.1.1. : Ordre d’encodage quand il y a 2 trames B Source personnelle

Pour pouvoir comparer les résultats, il faut que le nombre total de trames codées soit identique. Par conséquent, le nombre de trames à encoder va changer en fonction de celui des B. Je répète cette expérience pour 0, 1, 2, 3, 4 et 5 trames B. Le paramètre de compression de celles-ci (‘‘QPBSlice’’) est laissé à sa valeur par défaut c'est-à-dire 30.

1 3 0 2 4 Vidéo

6 8 Vidéo

2 4 0

3

Vidéo B B P

4

5

6

2

I B B P

1



Nombre de trames B 0 1 2 3 4 5 Nombre de trame à encoder 61 31 21 16 13 11

Nombre total de trames B 0 30 40 45 48 50 Nombre total de trames

Forme de la séquence 61

IPPPP 61

IBPBP 61

IBBPBBP 61

IBBBPBBBP 61

IBBBBPBBBBP

61 IBBBBBPBBBBBP

Fréquence pour l’encodage 10 5 3 3 2 2 Débit (kbits/s) 39,75 34,54 32,85 33,08 33,18 34,44

Nombre de bits total 242 504 210 704 200 400 201 800 202 368 210 080 Nombre de bits pour les trames B 0 25 384 48 720 69 056 84 480 105 296

Je remarque que le débit diminue lorsque le nombre de trames B est égal à 1 ou 2. Au-delà, il ré-augmente. Le nombre bits total varie de la même façon : s’il y a plus de deux trames B, le nombre de bits nécessaire à celle-ci est grand si bien qu’il suffit, à lui seul, à faire augmenter le débit. La fréquence pour l’encodage, diminue lorsque le nombre de trames B devient grand. L’explication de ce phénomène est la même que précédemment : l’encodeur a besoin d’un temps de calcul plus long lorsqu’il y a plus de trames B. Je vais maintenant m’intéresser au cas où il y a plus de trames sautées que de trames B. 2.3.4.3.2. Cas où le nombre de trames sautées est supérieur à celui des trames B Pour les expérimentations qui vont suivre, ‘‘NumberBFrames’’ est plus petit que ‘‘FrameSkip’’. Il y a donc plus de trames sautées que de B.

Dans le cas où il y a deux trames sautées et une B, l’encodage se passe comme décrit sur la figure suivante.

Figure 2.3.4.3.2.1. : Ordre d’encodage quand il y a 1 trame B et 2 trames sautées

Source personnelle

S’il y a trois trames sautées pour une B, l’encodage se déroule comme suit.

Figure 2.3.4.3.2.2. : Ordre d’encodage quand il y a 1 trame B et 3 trames sautées

Source personnelle

Je remarque que si l’on saute 3 trames, l’encodeur code une fois sur deux une trame B. Je fais 3 encodages afin de pouvoir voir quelle est l’influence du nombre de trames sautées sur le débit et la fréquence pour l’encodage.

1 trame B

1 trame sautée 1 trame B

2 trames sautées 1 trame B

3 trames sautées Fréquence pour l’encodage 5 3 3

Débit 46,08 kbits/s 33,92 kbits/s 27,80 kbits/s

La fréquence pour l’encodage et le débit diminuent lorsque le nombre de trames sautées augmente. Le même résultat a été observé dans la partie 2.3.4.2.3. Après avoir pris en main le CODEC, je vais pouvoir étudier les deux méthodes d’encodage qu’il propose en les comparant de manière objective et subjective. Je vais ensuite m’intéresser à la relation entre ces deux méthodes en cherchant à savoir s’il existe une relation entre elle. Pour cela, je vais me baser sur le MOSp.

1

2

3

4

5

6

I B B P P P B Vidéo

Vidéo I B P

1 3

4 2

P B



3. Étude de deux méthodes d’encodage Cette partie présente les expérimentations visant à permettre au CVC d’améliorer le CODEC. Dans un premier temps, j’ai étudié les deux méthodes d’encodage qu’il propose. Dans un second, j’ai mis en place des expérimentations permettant de mettre en avant la relation entre qualité subjective et objective d’une vidéo.

3.1. Comparaison de deux méthodes d’encodage Dans cette partie, je vais étudier les deux méthodes d’encodage proposées par le CODEC (le même que dans la partie 2). Dans un premier temps, je les présenterai. Ensuite, je les comparerai selon deux techniques, l’une qualifiée d’objective et l’autre de subjective.

3.1.1. Présentation des deux méthodes Les deux méthodes que j’ai dû comparer sont les suivantes. La première consiste à fixer la qualité des différentes images (I, P et B) grâce aux paramètres ‘‘QPISlice’’, ‘‘QPPSlice’’ et ‘‘QPBSlice’’. Dans les expérimentations que j’ai mené, je n’ai pas mis de trames B, ‘‘QPBSlice’’ est donc inutile. De plus, pour pouvoir comparer, il faut que toutes les images, qu’elles soient I ou P, aient la même qualité. Par conséquent, ‘‘QPISlice’’ et ‘‘QPPSlice’’ ont la même valeur. Ils seront, comme précédemment, regroupés sous le sigle ‘‘QP’’. Cette méthode est appelée méthode du QP fixe. La seconde consiste à fixer le débit de la vidéo que l’on veut. L’encodeur, afin d’atteindre ce dernier, va modifier la qualité et donc le QP de chaque image : si le débit actuel est trop important par rapport à celui que l’on veut, le QP augmente ce qui permet d’avoir une compression plus forte et, par conséquent, de faire diminuer le débit. Le mécanisme inverse s’applique lorsque le débit actuel est trop faible. L’encodeur effectue donc un contrôle du débit. Cette méthode est appelée méthode du Rate Contol (RC). Afin de l’activer, il faut mettre le paramètre ‘‘RateControlEnable’’1 à 1. De plus, ‘‘Bitrate’’1 prend la valeur en bits par seconde, du débit que l’on veut atteindre. ‘‘InitialQP’’1 qui permet de définir le QP de la trame I est mis à 0. Enfin, ‘‘BasicUnit’’1 est, par défaut, à 11. La présentation des deux méthodes étant terminées, je vais pouvoir les mettre en œuvre et les comparer. 1 Ces paramètres ont été définis dans la partie 2.3.2.



3.1.2. Étude objective 3.1.2.1. Présentation et mise en œuvre L’étude objective de la qualité d’une vidéo se fait grâce à des outils mathématiques tels que le débit et le PSNR* Y. Plus ce dernier est élevé, meilleure est la qualité de la vidéo. Je vais comparer 5 séquences au format qcif de cette manière. La première, ‘‘foreman.qcif’’, montre un ouvrier qui parle puis la caméra bouge afin de filmer le chantier. Cette vidéo a un mouvement modéré. La deuxième, ‘‘mother_and_daughter.qcif’’, présente une mère et sa fille sur un fond uni qui parlent. Cette vidéo n’a pas beaucoup de mouvement. Sur la troisième, ‘‘coastguard.qcif’’, on suit de la caméra un bateau de garde côte. La quatrième, ‘‘stefan.qcif’’, est tiré d’un match de tennis. La dernière, ‘‘table.qcif’, quant à elle, présente un match de tennis de table : au début, on voit juste les rebonds de la balle sur la raquette puis la caméra dé-zoome afin de filmer le premier joueur ; dans la suite son angle varie pour filmer tour à tour, chacun des pongistes. Ces trois séquences ont beaucoup de mouvement.

Figure 3.1.2.1.1. : Aperçu des séquences à encoder (1ère image)

Je vais encoder chaque vidéo avec la méthode du QP fixé. Les séquences ainsi codées auront un débit quelconque que je vais utiliser pour la seconde, celle du Rate Control. Le but de cette étude est de voir la différence au niveau du débit et du PSNR Y en fonction de la méthode utilisée et de comprendre la corrélation entre la quantité de mouvement dans une vidéo et le débit qu’elle nécessite pour une qualité donnée.



3.1.2.2. Résultats Je commence par encoder la séquence ‘‘foreman.qcif’’. Il m’a été demandé, uniquement pour cette séquence, de faire la comparaison des deux méthodes pour plusieurs frame rate (nombre de trames par seconde).

Séquence 1 : foreman.qcif

Méthode du QP fixé

QP 0 10 20 24 28 32 36 40 42 48 51 Frame Rate 30

PSNR Y 70,73 51,64 43,09 39,90 37,01 34,09 31,35 28,53 27,31 23,35 21,67 Bitrate (1) 3456,82 1512,90 412,58 239,18 140,57 83,53 51,58 32,09 25,08 11,73 8,50

Frame Rate 20 PSNR Y 70,73 51,64 43,09 39,90 37,01 34,09 31,35 28,53 27,31 23,35 21,67

Bitrate (2) 2304,55 1008,6 275,05 159,46 93,72 55,69 34,39 21,40 16,72 7,82 5,66 Frame Rate 15

PSNR Y 70,73 51,64 43,09 39,90 37,01 34,09 31,35 28,53 27,31 23,35 21,67 Bitrate (3) 1728,41 756,45 206,29 119,59 70,29 41,77 29,79 16,05 12,54 5,87 4,25

Méthode du Rate Control

Frame Rate 30 Target bitrate = bitrate (1) 3456,82 1512,90 412,58 239,18 140,57 83,53 51,58 32,09 25,08 11,73 8,50

PSNR Y 65,94 51,33 43,10 40,03 37,19 34,44 31,64 28,86 27,64 24,28 23,27 Bitrate 3162,49 1501,30 412,09 239,01 140,54 86,91 51,68 32,22 25,30 13,28 10,96


PSNR Y 65,94 51,33 43,10 40,03 37,19 34,44 31,64 28,86 27,64 24,28 23,27 Bitrate 2108,33 1000,87 274,73 159,34 93,69 55,74 34,44 21,47 16,87 8,85 7,24


PSNR Y 65,94 51,33 43,10 40,03 37,19 34,44 31,64 28,86 27,64 24,28 23,27 Bitrate 1581,25 750,65 206,04 119,51 70,27 41,81 29,83 16,10 12,65 6,62 5,34

Les colonnes en italique ne sont pas représentées sur le graphique pour des raisons d’échelle. La méthode du QP fixé donne, pour un même QP et pour un nombre de trames par seconde différent, un même PSNR Y (en rose dans le tableau). Ce résultat est celui attendu. En effet, la qualité d’une trame n’est pas définie par son frame rate mais par son QP. Par conséquent, le rapport signal sur bruit de la luminosité n’est pas influencé par le nombre de trames par seconde. Cependant, ce dernier a une action sur le débit : pour un même QP, plus il est faible, plus le débit diminue. Enfin, si le nombre de trames par seconde est divisé par deux, le débit de la vidéo l’est aussi. La méthode du Rate Control ne permet pas d’avoir exactement le débit voulu. Il y a un léger décalage dû aux variations du QP. Je remarque que pour des débits très faibles ou très élevés la variation est plus grande (cellules encadrées en violet dans le tableau). Tout comme pour la méthode précédente, les PSNR Y sont identiques pour les différents frame rate : par exemple, pour le débit le plus élevé de la séquence à 30 images/sec, le PSNR Y est de 65,94 dB ce qui correspond aussi à celui du débit le plus élevé de la séquence à 20 images/sec et à 15 images/sec (en orange dans le tableau). Là encore, lorsque le nombre d’images par seconde est divisé par deux, le débit l’est aussi. Globalement, les résultats des deux méthodes sont très proches bien que celle du Rate Control semble plus performante (se reporter au graphique à la page suivante).



Figure 3.1.2.2.1. : PNR Y en fonction du débit pour la séquence ‘‘foreman.qcif’’ Je refais l’expérience pour la séquence ‘‘mother_and_daughter.qcif’’

21

26

31

36

41

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 400 420

PS

NR

(dB

)

Bitrate (kbits/s)

Frame Rate = 15 - QPFrame Rate = 20 - QPFrame Rate = 30 - QPFrame Rate = 15 - RCFrame Rate = 20 - RCFrame Rate = 30 - RC



Séquence 2 : mother_and_daughter.qcif


QP 0 10 14 16 20 24 28 32 36 40 42 48 51 PSNR Y 70,31 51,33 48,23 46,82 43,63 40,53 37,55 34,71 32,20 30,06 28,93 25,41 24,18

Bitrate (1) 3000,13 943,26 441,76 325,99 167,99 91,19 49,80 27,22 15,25 8,79 6,98 4,06 3,62


Target bitrate = bitrate (1) 3000,13 943,26 441,76 325,99 167,99 91,19 49,80 27,22 15,25 8,79 6,98 4,06 3,62 PSNR Y 57,64 50,29 46,18 44,72 41,98 40,69 37,59 34,74 31,65 29,99 29,17 26,86 26,89 Bitrate 2121,92 943,62 441,91 326,17 168,11 91,19 49,84 27,30 15,60 9,19 7,36 4,70 4,62

Les colonnes en italique ne sont pas représentées sur le graphique pour des raisons d’échelle.

Figure 3.1.2.2.3. et figure 3.1.2.2.4. : PNR Y en fonction du débit pour la séquence ‘‘mother_and_daughter.qcif’’

La zone bleue de la courbe correspond aux points pour un QP de 14 et 16. Ils ont été ajoutés afin de l’affiner. Pour des débits supérieurs à 100 kbits/s, on peut voir qu’il y a environ 2 dB d’écart entre les deux courbes. Ce résultat n’est pas correct. En effet, les deux méthodes sont supposées donner des résultats proches pour ce type de vidéo (i.e des vidéos n’ayant pas beaucoup de mouvements). Afin de corriger ce problème, il faut modifier le fichier de configuration et, plus particulièrement, les paramètres ‘‘BasicUnit’’ et ‘‘InitialQP’’.

20

25

30

35

40

45

50

55

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950

PS

NR

(dB

)

Bitrate (kbits/s)

QPRC

24

26

28

30

32

34

36

38

40

42

0 15 30 45 60 75 90

QP

RC

2 dB



‘‘BasicUnit’’ a pour valeur 11 ce qui implique que l’encodeur fait la moyenne du QP de tous les groupes composés de 11 macroblocs pour avoir le QP de la trame. Dans ce cas de cette vidéo, cela ne fonctionne pas : il y a de fortes différences entre les QP utilisés au niveau des visages et de l’arrière-plan. Ce dernier à un QP très élevé ce qui fait augmenter la moyenne et donc le QP de la trame diminuant ainsi sa qualité. De plus, ‘‘InitalQP’’ est laissé à 0 : l’encodeur doit alors sélectionner la meilleure valeur pour celui-ci. Ici, l’algorithme qui doit le choisir fonctionne mal pour cette vidéo (on ne sait d’ailleurs par pourquoi) et prend un QP trop faible. Afin d’atteindre le débit voulu, l’encodeur l’augmente peu à peu détériorant, de fait, la qualité de la trame et provoquant une forte diminution du SNR Y ce qui explique la différence de 2 dB. Exemple pour le point correspond au QP de 16 avec BasicUnit = 11 et InitialQP = 0. --------------------------------------------------- ---------------------------- Frame Bit/pic QP SnrY SnrU SnrV Ti me(ms) MET(ms) Frm/Fld Ref --------------------------------------------------- ---------------------------- 0000(IDR) 77536 10 52.443 51.941 51.926 616 0 FRM 1 0001(P) 23496 10 50.658 50.644 50.693 2058 1132 FRM 1 0002(P) 40024 7 52.632 52.387 52.568 3133 2129 FRM 1 0003(P) 39352 7 53.169 52.243 52.695 4153 3137 FRM 1 0004(P) 35280 8 52.531 51.946 52.240 5020 4062 FRM 1 0005(P) 29032 9 51.905 51.335 51.596 5961 5052 FRM 1 0006(P) 23984 9 51.109 50.708 51.177 5947 5061 FRM 1 0007(P) 24648 9 51.199 50.957 51.296 6002 5093 FRM 1 0008(P) 31368 8 52.282 51.604 51.837 6111 5167 FRM 1 0009(P) 31936 9 51.927 51.404 51.646 6657 5653 FRM 1 0010(P) 23736 10 50.904 50.918 51.187 6042 5150 FRM 1 […] 0182(P) 6360 18 46.072 47.460 48.270 7369 6494 FRM 1 0183(P) 8624 17 46.470 47.668 47.991 7157 6320 FRM 1 0184(P) 7280 18 45.812 47.502 48.015 7459 6538 FRM 1 0185(P) 6480 19 45.222 47.266 47.673 7753 6841 FRM 1 0186(P) 5568 20 44.610 46.919 47.507 6995 6225 FRM 1 0187(P) 4696 21 43.949 46.634 47.165 7227 6459 FRM 1 0188(P) 5216 22 43.335 46.448 46.948 6680 5985 FRM 1 0189(P) 3112 24 41.751 45.876 46.396 5809 5224 FRM 1 0190(P) 4392 25 41.303 45.391 45.913 5782 5215 FRM 1 0191(P) 3720 26 40.661 44.910 45.325 5734 5183 FRM 1 0192(P) 2304 28 39.509 44.872 45.000 5889 5302 FRM 1 0193(P) 1600 30 38.542 44.301 44.546 5810 5266 FRM 1 0194(P) 1896 30 38.091 44.114 44.433 5702 5189 FRM 1 0195(P) 816 31 36.966 43.594 43.986 5644 5150 FRM 1 0196(P) 1080 33 36.651 43.555 43.948 5623 5138 FRM 1 0197(P) 552 35 35.594 43.069 43.564 5666 5190 FRM 1 0198(P) 824 35 35.350 43.082 43.633 5678 5189 FRM 1 0199(P) 2944 32 37.315 43.385 43.473 5664 5149 FRM 1

Figure 3.1.2.2.5. : QP et SNRY en fonction du numéro de la trame (BasicUnit=11)

5

10

15

20

25

30

35

40

45

50

55

0 20 40 60 80 100 120 140 160 180

Numéro de la trame

QP

SNR Y



On retrouve, sur l’extrait de fichier log ainsi que sur la figure 3.1.2.2.5. les observations faites précédemment. Je vais maintenant comparer avec le cas où BasicUnit=99 et InitialQp=16. --------------------------------------------------- ---------------------------- Frame Bit/pic QP SnrY SnrU SnrV Ti me(ms) MET(ms) Frm/Fld Ref --------------------------------------------------- ---------------------------- 0000(IDR) 48520 16 47.672 48.265 48.662 499 0 FRM 1 0001(P) 4744 16 46.456 46.946 47.572 1717 1020 FRM 1 0002(P) 10800 14 47.378 47.998 48.592 2842 2066 FRM 1 0003(P) 7264 14 47.444 48.036 48.396 3784 3048 FRM 1 0004(P) 16312 12 48.941 49.083 49.508 4800 4003 FRM 1 0005(P) 5488 14 47.889 48.015 48.697 5831 5123 FRM 1 0006(P) 15464 12 49.009 49.059 49.488 5875 5066 FRM 1 0007(P) 8776 13 48.415 48.554 49.225 5896 5119 FRM 1 0008(P) 7792 13 48.553 48.707 49.333 5901 5122 FRM 1 0009(P) 14992 12 49.379 49.259 49.538 6005 5170 FRM 1 0010(P) 8760 13 48.617 48.577 49.407 5803 5046 FRM 1 […] 0182(P) 11968 15 47.832 47.858 48.701 5940 5190 FRM 1 0183(P) 12144 15 47.906 48.054 48.413 5874 5150 FRM 1 0184(P) 13216 15 47.986 47.969 48.703 5949 5203 FRM 1 0185(P) 10544 16 47.247 47.652 48.175 5827 5114 FRM 1 0186(P) 12024 16 47.350 47.849 48.441 5936 5217 FRM 1 0187(P) 12328 16 47.391 47.528 48.084 5837 5110 FRM 1 0188(P) 11032 17 46.758 47.559 48.002 5891 5182 FRM 1 0189(P) 10304 18 46.045 47.239 47.807 5886 5217 FRM 1 0190(P) 7752 20 44.874 46.652 47.090 5924 5268 FRM 1 0191(P) 11784 19 45.536 46.747 47.033 5950 5246 FRM 1 0192(P) 7312 20 44.612 46.466 46.880 5933 5275 FRM 1 0193(P) 12032 18 45.740 46.820 47.193 5937 5237 FRM 1 0194(P) 10168 18 45.728 46.988 47.325 5969 5280 FRM 1 0195(P) 9568 18 45.702 46.979 47.395 5890 5207 FRM 1 0196(P) 15160 16 47.037 47.488 47.957 5894 5177 FRM 1 0197(P) 8136 18 46.075 47.124 47.510 5867 5190 FRM 1 0198(P) 11280 17 46.420 47.294 47.660 5971 5232 FRM 1 0199(P) 7312 18 45.868 47.050 47.428 6098 5390 FRM 1

Figure 3.1.2.2.6. : QP et SNRY en fonction du numéro de la trame (BasicUnit=99)

J’observe que le QP et, donc, le SNR Y subissent moins de variations. Par conséquent, le PSNR Y est de 46,98 dB au lieu de 44,72.

5

10

15

20

25

30

35

40

45

50

55

0 20 40 60 80 100 120 140 160 180Numéro de la trame

QP

SNR Y



Je ré-encode la séquence en modifiant ces paramètres (i.e. ‘‘BasicUnit’’ et ‘‘InitialQP’’). J’obtiens les résultats suivants :


BasicUnit=11 InitialQP=0 Target bitrate = bitrate (1) 3000,13 943,26 441,76 325,99 167,99 91,19 49,80 27,22 15,25 8,79 6,98 4,06 3,62

PSNR Y 57,64 50,29 46,18 44,72 41,98 40,69 37,59 34,74 31,65 29,99 29,17 26,86 26,89 Bitrate 2121,92 943,62 441,91 326,17 168,11 91,19 49,84 27,30 15,60 9,19 7,36 4,70 4,62

BasicUnit=99 InitialQP=X PSNR Y 2 58,02 51,38 48,33 46,98 43,86 41,01 38,00 34,77 31,89 30,01 29,22 26,9 26,95

Bitrate 2201,75 943,11 442,06 325,64 167,87 91,19 49,82 27,28 15,39 8,99 7,03 4,50 3,99 Les colonnes en italique ne sont pas représentées sur le graphique pour des raisons d’échelle.

Figure 3.1.2.2.7. : PNR Y en fonction du débit pour la séquence ‘‘mother_and_daughter.qcif’’ après ré-encodage avec BasicUnit=99 et InitialQP=16

Je remarque que la méthode du RC est meilleure que celle du QP. Cependant, je note, encore une fois, que les résultats sont très proches. Je refais l’expérience avec la séquence ‘‘coastguard.qcif’’.

20

25

30

35

40

45

50

55

0 50 100 150 200 250 300 350 400 450 500 550 600 650 700 750 800 850 900 950

PS

NR

(dB

)

Bitrate (kbits/s)

QP

RC avec BasicUnit=11 et sans InitalQP

RC avec BasicUnit=99 et un InitialQP



Séquence 3 : coastguard.qcif


QP 0 10 20 24 28 32 36 40 42 48 51 PSNR Y 71,98 51,79 42,07 38,36 34,92 31,58 28,85 26,40 25,29 22,43 21,10

Bitrate (1) 4077,54 2069,37 756,95 438,23 227,22 100,05 45,60 22,53 16,18 7,47 5,44


Target bitrate = bitrate (1) 4077,54 2069,37 756,95 438,23 227,22 100,05 45,60 22,53 16,18 7,47 5,44 PSNR Y 70,44 51,51 41,95 38,31 34,91 31,57 28,80 26,35 25,17 22,18 21,69 Bitrate 3984,53 2064,67 757,06 438,07 227,41 100,18 45,77 22,61 16,23 8,18 7,35

La colonne en italique n’est pas représentée sur le graphique pour des raisons d’échelle.

Figure 3.1.2.2.2. : PNR Y en fonction du débit pour la séquence ‘‘coastguard.qcif’’

La méthode du QP est plus performante que celle du Rate Control quel que soit le débit. Cependant, les résultats des deux méthodes sont, là aussi, très proches. Je fais de même avec la séquence ‘‘stefan.qcif’’.

21

26

31

36

41

46

51

0 500 1000 1500 2000

PS

NR

(dB

)

Bitrate (kbits/s)

QP

RC



Séquence 4 : stefan.qcif


QP 0 10 20 24 28 32 36 40 42 48 51 PSNR Y 72,03 51,84 42,85 39,06 35,34 31,50 28,10 25,02 23,57 19,81 18,48

Bitrate (1) 4990,88 2667,23 1047,00 648,37 376,76 194,49 102,60 56,30 41,33 14,97 7,71




Figure 3.1.2.2.8. : PNR Y en fonction du débit pour la séquence ‘‘stefan.qcif’’

Dans ce cas, la méthode du QP est plus performante que celle du RC. J’observe, là encore, que les résultats sont très proches. Je réitère, une dernière fois, cette expérimentation avec la séquence ‘‘table.qcif’’.

15

20

25

30

35

40

45

50

55

0 500 1000 1500 2000 2500 3000

PS

NR

(dB

)

Bitrate (kbits/s)

QP

RC



Séquence 5 : table.qcif


QP 0 10 20 24 28 32 36 40 42 48 51 PSNR Y 70,44 50,93 42,31 39,08 36,23 33,46 30,82 28,37 27,15 23,37 21,49

Bitrate (1) 3458,27 1459,64 440,17 263,49 151,03 82,67 47,03 29,17 23,51 12,00 8,31




Figure 3.1.2.2.9. et figure 3.1.2.2.10. : PNR Y en fonction du débit pour la séquence ‘‘table.qcif’’

Je remarque que la méthode du QP est plus adéquate pour des faibles débits (de 8 à 90 kbit/s). Pour des plus élevés, c’est celle du Rate Control qui est plus efficace. Cependant, ce qui m’intéresse ici, est de voir quelle est la méthode qui permet d’avoir la meilleure qualité pour des débits faibles. Par conséquent, je peux dire que c’est celle du QP fixé.

20

25

30

35

40

45

50

55

0 500 1000 1500

PS

NR

(dB

)

Bitrate (kbits/s)

QPRC

21

23

25

27

29

31

33

35

8 20 32 44 56 68 80 92

QPRC



Je vais désormais faire un récapitulatif des résultats observés afin de pouvoir conclure. Tour d’abord, j’ai constaté que le PSN Y (ou le SNR Y de chaque trame) n’est pas influencé par nombre de trames par seconde (cf ‘‘foreman.qcif’’). Ce dernier agit sur débit : si le frame rate est divisé par deux, le débit l’est aussi.

Ensuite, j’ai remarqué qu’il n’y a pas une méthode d’encodage plus performante que l’autre. En effet, si l’une fonctionne bien pour une vidéo, ce ne sera peut-être pas le cas pour une autre. De plus, je constate que les vidéos ayant peu de mouvement ont une meilleure qualité objective pour la méthode du Rate Control alors que celles en ayant beaucoup en ont une meilleure pour celle du QP fixe. Le tableau ci-dessous récapitule quelle méthode fonctionne mieux pour quelle séquence (‘‘X’’ dans le tableau).

foreman mother and daughter coastgauard stefan table Méthode du QP fixe X X X Méthode du Rate Control X X

Enfin, j’ai observé qu’à un taux de compression, un frame rate et un nombre de trames identiques, les 5 vidéos ne requièrent pas le même débit. Comment cela peut-il s'expliquer ? Il faut se pencher sur le contenu de la vidéo et notamment sur l'intensité du mouvement dans celle-ci. Dans le cas d'une vidéo ayant peu de mouvement (‘‘mother_and_daughter.qcif’’, par exemple) deux trames successives se ressemblent beaucoup, il n'y a donc pas beaucoup de différence. Or, ce qui est encodé est la différence entre deux trames successives (cf annexe I). Par conséquent, il y a peu de choses à encoder ce qui permet d'utiliser moins de bits et donc d'avoir un débit plus faible. Si la vidéo contient beaucoup de mouvements rapides (‘‘stefan.qcif’’, par exemple), la différence entre deux trames est grande, il faut donc utiliser un nombre de bits important et donc avoir un débit plus élevé. C'est pourquoi, pour avoir une qualité identique c'est-à-dire un même PSNR Y de, par exemple, 45 dB entre ‘‘mother_and_daugher.qcif’’ et ‘‘stefan.qcif’’, la première nécessitera un débit d'environ 200 kbits/s alors que la seconde aura besoin d'environ 1500 kbits/s. Pour avoir une qualité égale entre les deux séquences, ‘‘mother_and_daughter.qcif’’ pourra être plus compressée que ‘‘stefan.qcif’’.

Figure 3.1.2.2.11. : PNR Y en fonction du débit pour les 5 séquences encodées précédement

Après avoir comparé objectivement les vidéos, je vais le faire de manière subjective.

15

25

35

45

55

65

75

0 1000 2000 3000 4000 5000

PS

NR

Y (d

B)

Bitrate (kbits/s)

Méthode 1 (QP) : ForemanMéthode 2 (RC) : ForemanMéthode 1 (QP) : Mother and DaughterMéthode 2 (RC) : Mother and DaughterMéthode 1 (QP) : StefanMéthode 2 (RC) : StefanMéthode 1 (QP) : TableMéthode 2 (RC) : TableMéthode 1 (QP) : Coast GuardMéthode 2 (RC) : Coast Guard



3.1.3. Étude subjective 3.1.3.1. Présentation et mise en œuvre L’étude subjective ne nécessite pas d’outils mathématiques : elle consiste juste en une comparaison des différentes séquences à l’œil. Il existe différentes méthodes afin de définir la qualité subjective de l’image. Elles sont décrites dans les recommandations IUT-R BT.500-11 et ITU-T P.910. Je vais tacher de les décrire brièvement ici :

� Double Stimulus Continuous Quality Scale (DSCQS). Il y a deux vidéos : l’une sert de référence et l’autre de test. Celles-ci sont présentées deux fois aux observateurs, dans un ordre aléatoire. Ils ne savent pas laquelle est la référence et laquelle est le test. Ils notent chacune d’elle en entourant sa qualité sur une échelle à cinq paliers allant de ‘‘mauvais’’ à ‘‘excellent’’. Ensuite la différence de note entre chaque paire est calculée. Cette méthode est utilisée lorsque la qualité entre les deux séquences est proche. Elle est aussi appelée DCR pour Degradation Category Rating.

� Double Stimulus Impairement Scale (DSIS). Contrairement à la méthode précédente, la vidéo de référence est vue une seule et unique fois avant le test. Les observateurs notent la dégradation entre la référence et le test sur une échelle à cinq paliers allant d’‘‘imperceptible’’ à ‘‘très ennuyeux’’. Cette méthode est très employée dans le cas où il y a une perte de qualité importante due, notamment, aux erreurs de transmission.

� Absolute Category Rating (ACR). Les observateurs voient uniquement la vidéo à tester et notent la qualité générale de celle-ci. L’échelle, comme dans le cas du DSCSQ, comporte cinq paliers allant de ‘‘mauvais’’ à ‘‘excellent’’. ACR est plus efficace que les deux méthodes présentées ci-dessus car elle nécessite moins de temps : la référence n’étant jamais montrée.

� Pair Comparaison (PC). Les séquences sont mises par paires de toutes les manières possibles. Les observateurs disent quelle vidéo à la meilleure qualité pour chaque paire.

Dans chaque cas, un minimum de 15 observateurs est requis. La moyenne des notes données par ces derniers sert à calculer le MOS1 (Mean Opinon Score). Dans mon cas (mais aussi pour des questions de temps et de nombre d’observateurs), je ne vais pas calculer de MOS. Je vais procéder à une comparaison par paire (PC) afin de mettre en avant les différences, trame par trame, entre deux vidéos ayant le même débit. Pour savoir quelle vidéo encodée avec la méthode du QP fixe doit être associée avec celle encodée grâce à la méthode du Rate Control, je me réfère aux tableaux recensant les résultats pour chacune d’entre elle. (cf pages précédentes). Afin de lire les séquences .yuv, j’utilise un lecteur libre appelé Avarex YUV Player disponible à l’adresse

http://www.softpedia.com/get/Multimedia/Video/Video-Players/Avarex-YUV-Player.shtml. Celui-ci ne nécessite pas d’installation car c’est une application portable. 1 le MOS est défini à la partie 3.2.1.1.



Je vais désormais présenter les différentes dégradations que peut subir une image :

� Le flou

Figure 3.1.3.1.1. : Flou

� Les blocs de pixels qui correspondent à une zone floue dans laquelle on ne parvient plus à voir les détails ou les contours

Figure 3.1.3.1.2. : Bloc de pixel

� Les distorsions qui sont une déformation de la forme de l’objet.

Figure 3.1.3.1.3. : Distorsion

Après avoir présenté les méthodes de comparaison de séquences vidéos et les différentes dégradations que peut subir une image, je vais comparer chaque vidéo pour débits / QP différents. 3.1.3.2. Résultats Je regroupe mes observations dans les tableaux aux pages suivantes.

Image nette Image floue


VERGNE Aurore 2ème année Réseaux et Télécommunications 2009-2010

42

Frame Rate

30 20 15

Séquence Débit

approximatif QP RC

Débit approximatif

QP RC Débit

approximatif QP RC

foreman

140 Pas de différences. 159 Pas de différences. 119 Pas de différences. 83 Le visage est

flou au début jusqu’à la trame 90.

Le visage est flou et il y a des distorsions à partir de la trame 90. Il y en a beaucoup plus à partir de la trame 140. Il y a des blocs de pixels.

93 Le visage est flou et il y a des petits blocs de pixels. Ils sont plus gros lorsque la caméra bouge.

70 Le visage est flou et il y a des petits blocs de pixels lors des mouvements et beaucoup plus de distorsions à partir de la trame 140.

51 Le visage est flou. Il y a des blocs de pixels. L’image est très floue avec beaucoup de blocs et de distorsions lors de mouvements de caméra (autour de la trame 180).

55 Le visage est flou au début et il y a de petites distorsions (trame 40). À partir de la trame 60, plus de différences.

Le visage est flou et il y a des blocs de pixels à partir de la trame 70. Il y a beaucoup plus de distorsions à partir de la trame 140. L’image est très floue avec beaucoup de blocs et de distorsions lors de mouvements de caméra.

41 Le visage est flou au début et il y a de petites distorsions (trame 20).

Le visage est flou et il y a des blocs de pixels à partir de la trame 80. L’image est globalement très floue avec beaucoup de blocs et de distorsions lors de mouvements de caméra ou de mouvements rapides du visage. Les distorsions sont plus nombreuses à partir de la trame 140.



43

Frame Rate 30

Séquence Débit

approximatif QP RC

mother_and_daughter

91 Pas de différences. 49 Il y a des blocs de pixels quand la mère touche les cheveux de la

fille (trame 83). Les visages sont flous. Il y a moins de flou à partir de la trame 6 mais ils restent plus flous que pour QP.

Hormis quelques petits détails, les vidéos sont quasiment identiques. 27 Le visage de la fillette est flou. Les visages sont flous. Il y a moins de flou à partir de la trame 12

mais ils restent plus flous que pour QP. Il y a des distorsions et des blocs de pixels quand la mère bouge la main vers la trame 153. Idem vers la trame 165. À partir de la trame 150, les visages sont identiques à QP. Il y a des blocs de pixels et des distorsions au niveau du visage de la mère à partir de la trame 191.

coastguard

227 Pas de différences. 100 Au niveau de l’eau et le l’arrière-plan (le gazon), il y a des blocs de

pixels au début de la vidéo (jusqu’à la trame 23). Il y a des blocs de pixels au niveau du drapeau du bateau. L’arrière du bateau blanc est flou et il y a des distorsions. La vidéo est floue lorsque la caméra bouge.

Exceptées ces petites différences, les vidéos sont relativement les mêmes. 45 Il y a des blocs de pixels au niveau de l’eau et du gazon jusqu’à la

trame 37. Globalement, la vidéo est plus floue mais avec moins de blocs et de distorsions.

Lorsque l’angle de la caméra change, il y a des blocs de pixels et des distorsions au niveau de l’arrière-plan (autour de la trame 70). Il y a des blocs de pixels dans l’eau à l’arrière du gros bateau blanc. Des distorsions apparaissent au niveau du drapeau vers la trame 78 et à l’avant du bateau autour de la trame 80. Globalement, la vidéo est moins floue mais avec plus de blocs et de distorsions.

stefan

194 Pas de différences 102 L’image est floue jusqu’à la trame 5. Il y a des blocs de pixels et des distorsions des trames 6 à 8.

Il y a des blocs de pixels lors des mouvements ainsi que des distorsions (par exemple autour des trames 12, 86 ou 126).

56 L’image est floue surtout autour des jambes. Globalement, la vidéo est plus floue mais avec moins de blocs et de distorsions.

Il y a des blocs de pixels et des distorsions lors des mouvements (par exemple autour des trames 5 ou 111). Globalement, la vidéo est moins floue mais avec plus de blocs et de distorsions. L’arrière-plan est flou et il y a des blocs de pixels.

Les vidéos sont relativement similaires après la trame 60.



44

Frame Rate 30

Séquence Débit

approximatif QP RC

table

151 Pas de différences 82 Jusqu’à la trame 53, l’arrière-plan est plus flou mais il y a moins

de distorsions au niveau des mains. Il y a quelques blocs de pixels vers les jambes autour de la trame 170 et vers la raquette autour de la 180 et de 200.

Il y a des distorsions au niveau des mains autour de la trame 45. Il y a des blocs de pixels au niveau des mains à la trame 51, au niveau des bras à la 54 et vers la raquette à la 76. Le pongiste est flou autour de la trame 70. Le second pongiste est flou ainsi que le filet et l’arrière-plan et il y a des blocs de pixels (trame 131). La table est floue et contient des blocs de pixels (trame 181).

47 Jusqu’à la trame 43, l’arrière-plan est plus flou mais il y a moins de distorsions au niveau des mains.

Il y a des blocs de pixels et des distorsions au niveau des mains (trame 45 et suivantes). A la trame 70, de grosses distorsions apparaissent au niveau de la main qui lance la balle. Elles se poursuivent jusqu’à la 80. Plus généralement, les distorsions et les gros blocs de pixels sont importants jusqu’à la trame 115 ; dans la suite de la séquence, ils sont plus petits. Autour de la trame 140, la séquence est floue. Globalement, la qualité de la vidéo semble moindre.

Je constate que la méthode du RC donne un rendu visuel de moins bonne qualité que celle du QP fixé. En effet, la variation du QP de chaque trame entraine des différences telles que des blocs de pixels ou des distorsions. Lors d’une étude mathématique, je ne prends pas en compte ces dégradations : je ne me préoccupe que du PSNR Y et du débit. Lorsque le QP est plus faible, le SNR Y de la trame l’est aussi et inversement. Ces variations ne se compensant pas tout à fait, on obtient, dans la plupart des cas un PSNR Y plus élevé ce qui permet de conclure que la vidéo est de meilleure qualité subjective. Visuellement, ce n’est pas le cas. Par conséquent, je peux dire que la méthode du QP, bien qu’elle soit mathématiquement moins bonne donne visuellement de meilleurs résultats (lorsque l’on fait de la comparaison de vidéo, c’est toujours celle faite par l’œil humain qui est considérée comme la meilleure). La perte de qualité remarquée visuellement est cependant visible mathématiquement lorsque l’on fait le graphique du SNR Y en fonction du numéro de la trame.


VERGNE Aurore 2ème année Réseaux et Télécommunications

2009-2010 45

Figure 3.1.3.2.1. : SNR Y en fonction du numéro de la trame pour la séquence ‘‘table.qcif’’ pour un débit autour de 47 kbits/s

Sur le graphique ci-dessus, je retrouve les observations faites dans le tableau c'est-à-dire une première baisse de la qualité de la vidéo encodée avec la méthode du RC des trames 45 à 115 (rectangle orange) (distorsions, blocs de pixels et flou) et une seconde (en rose) autour de la trame 140 (flou). Je note également que la vidéo encodée avec la méthode du RC a une meilleure qualité visuelle au début de la séquence (encadré vert). Afin de ne pas me répéter, je ne mets pas les graphiques correspondant à chaque comparaison (pour les débits les plus faibles uniquement) : ils sont disponibles à l’annexe III. Leur commentaire, quant à lui, se trouve dans les tableaux aux pages précédentes. J’ai, dans cette partie, comparé deux méthodes d’encodage. Celle du QP semble visuellement meilleure que celle du RC. Le CVC a récemment développé un nouvel outil permettant de faire une relation entre qualité objective et subjective. C’est pour vérifier cette corrélation qu’il m’a été ensuite demandé d’encoder les mêmes séquences avec un autre CODEC donnant la valeur de cet indicateur pour chaque macrobloc. C’est ce que je fais dans la partie suivante

26

28

30

32

34

0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200

table.qcif (débit autour de 47 kbits/s)

QP

RC



2009-2010 46

3.2. Étude de la relation entre qualité visuelle et MOSp

3.2.1 Définition du MOSp Le MOSp ne peut être défini qu’à partir du MOS et du MSE c’est pourquoi je vais d’abord définir c’est deux indicateurs. MOS est un acronyme signifiant Mean Opinon Score. Il permet de définir la qualité subjective d’une vidéo. Afin de le définir, il existe plusieurs procédures de tests définis dans la partie 3.1.3.1. Elles nécessitent toutes de faire appel à un panel de personnes. Le MOS est la moyenne des notes données par le panel. Elles s’étendent sur un intervalle de 0 (mauvais) à 5 (excellent). Pour des questions de commodité, le MOS est souvent ramené sur une échelle plus petite allant de 0 (mauvais) à 1 (excellent). MSE est l’abréviation de Mean Square Error. C’est un outil mathématique permettant de définir la qualité objective de la vidéo. Il est calculé en faisant la moyenne du carré de la différence entre la valeur de la luminosité de chaque pixel entre la séquence d’origine et celle que l’on a encodée.

MSE = �

�.�.�.∑ ∑ ∑ ��, �, � � ��, �, ��

��

�� ²

avec : - I la séquence originale - Ic la séquence encodée - M la largueur de la trame - N la hauteur de la trame - T le nombre de trame par séquence

Des expérimentations, menées par les membres du CVC, ont permis de trouver une relation entre MOS et MSE. Elles consistent à encoder diverses séquences pour les QP = {6, 26, 34, 36, 38, 40, 45, 45} et à les faire évaluer par un panel afin de connaitre leurs MOS respectifs. La dernière étape consiste à faire un graphique ayant en ordonnée le MOS de chaque séquence pour chacun des QP et en abscisse le MSE de chaque séquence pour chacun des QP. Ce dernier est donné par le CODEC Le graphique suivant est obtenu :

Figure 3.2.1.1. : MOS en fonction du MSE

Source : A novel perceptual quality metric for video compression, A.Bhat, I. Richardson et S.Kannangara



2009-2010 47

Les membres du CVC ont constaté que les courbes sont linéaires pour un MOS supérieur à 0,1 : au-delà de cette valeur, la qualité de la vidéo est tellement mauvaise qu’elle peut être assimilée à 0. Par conséquent, le MOS peut être assimilé à une droite dont on peut connaitre l’équation. Il est donc possible de prédire le MOS d’où la notion de MOSp ‘‘p’’ signifiant ‘‘predictiv’’ ou, en français, ‘‘estimé’’

Figure 3.2.1.2. : MOS ‘’linéarisé’’ en fonction du MSE

Source : A novel perceptual quality metric for video compression, A.Bhat, I. Richardson et S.Kannangara Par conséquent, le MOSp peut être calculé grâce à une équation de droite qui est la suivante :

mosp = 1 – ks.(MSE) avec : ks une constante dépendant du mouvement de la séquence et de la quantité de texture

ks est calculé grâce à l’estimation de mouvement et de texture au sein de chaque macrobloc. Cette estimation est faite par le CODEC à l’aide de formules particulièrement complexes. Je ne les détaillerai pas dans ce rapport car cela n’apporterai pas grand-chose au sujet.



2009-2010 48

3.2.2. Compilation et utilisation du CODEC

La compilation et l’utilisation du CODEC se déroulent de la même manière que précédemment, je ne détaillerai donc pas.

Ce CODEC est basé sur celui étudié précédemment. En effet, un membre du CVC l’a modifié afin qu’il donne des valeurs telles que le MOSp ou le MSE. Par conséquent, il y a des paramètres en plus de ceux décrits dans le fichier de configuration : MOSYFile = "mbmosp.log" #Emplacement du fichier stockant la valeur du MOSp de chaque macrobloc pour une trame donnée (‘‘Frameformosp’’). Il est composé de trois colonnes : la première correspond au numéro de la trame, la seconde à celui du macrobloc et la dernière au MOSp. Exemple : 157 0 0.764015 157 1 0.556164 157 2 0.097607 157 3 0.880771 157 4 0.763209 157 5 0.672024 157 6 0.535319 157 7 0.599031 157 8 0.747061 157 9 0.764907 [...] 157 95 0.575323 157 96 0.439069 157 97 0.313856 157 98 0.637731 MSEYFile = "msey.log" #Emplacement du fichier contenant la valeur du MSE pour la composante Y de la séquence. Il est composé d’une seule ligne. Exemple : Sequence MSE: 25.800414 MSEYCbCrFile = "mseycbcr.log" #Emplacement du fichier dans lequel se trouve la valeur du MSE pour les composantes colorées (Cb et Cr) de la séquence. Il est vide (l’écriture dans celui-ci n’est pas activée). Frameformosp = 1 #Numéro de la trame dont on veut enregistrer le MOSp de chaque macrobloc. En plus des ajouts précédents deux autres lignes apparaissent dans le terminal (ou le fichier si on a redirigé la sortie standard*) : ‘‘Average New MOSp’’ qui indique la valeur moyenne du MOSp pour la séquence et ‘‘Average New MSEy’’ dont la valeur est la même que celle contenu dans ‘‘MSEYFile’’. Grâce aux informations fournies par ce CODEC, il m’a été demandé de faire une carte du MOSp de chaque macrobloc avec un logiciel appelé MatLab. Je procède donc à son installation sur mon ordinateur personnel.



2009-2010 49

3.2.3. Installation de Matlab R2009b Matlab est à la fois un environnement de programmation et un langage développé par la société américaine MathWorks. Il est utilisé dans les domaines de l’éducation, de la recherche et de l’industrie pour le calcul numérique. Il permet également de faire des graphiques complexes tels que celui que l’on me demande de faire. Une fois le DVD mis dans le lecteur, la fenêtre suivante s’affiche.

Figure 3.2.3.1. : Écran de choix du type d’installation

Je choisis d’installer le logiciel manuellement c'est-à-dire sans utiliser Internet. En effet, l’installation derrière un proxy* a tendance à boguer. De plus, le CVC a déjà activé le programme et a donc la possibilité de me donner les fichiers nécessaires à l’activation. Une fois la case ‘‘Install manually without using the Internet’’ cochée, je clique sur ‘‘Next’’. J’accepte le contrat de licence et saisi la clé fournie avec le DVD.

Figure 3.2.3.2. : Écran d’acceptation du contrat de licence



2009-2010 50

Figure 3.2.3.3. : Écran de saisi de la clé

Il m’est ensuite demandé si je veux créer un compte. N’ayant pas de compte, j’ai dû en créer un (les membres du CVC ont perdu leurs identifiants). Pour cela, j’ai coché la case ‘‘I need to create a MathWorks account’’ et cliqué sur ‘‘Next’’.

Figure 3.2.3.4. : Demande de création de compte



2009-2010 51

Ensuite, le type d’installation (typique ou personnalisée) est demandé. Ne sachant pas vraiment quels sont les outils qui sont susceptibles de me servir, je choisis une installation typique en sélectionnant ‘‘Typical’’.

Figure 3.2.3.5. : Sélection du type d’installation

Le répertoire d’installation est alors affiché. Celui par défaut (C:\Program Files\MATLAB\R2009b) ne me convenant pas, je le modifie en C:\Program Files\MATLAB.

Figure 3.2.3.6. : Choix du dossier d’installation

Les composants qui vont être installés sont listés et, une fois que j’ai cliqué sur ‘‘Next’’, l’installation commence et dure environ 20 minutes.



2009-2010 52

Figure 3.2.3.3.7. : Liste des composants qui vont être installés et début de l’installation

Une fois l’installation terminée, il faut que j’active Matlab. Pour cela, je coche la case ‘‘Activate Matlab’’ et je clique sur ‘‘Next’’.

Figure 3.2.3.8. : Écran de demande d’activation du programme

Tout comme pour l’installation, le type d’activation est demandé. Ayant déjà les fichiers d’activation, je choisi l’option sans Internet ‘‘Activate manually without the Internet’’.

Figure 3.2.3.9. : Sélection du type d’activation



2009-2010 53

Je sélectionne alors le fichier servant à l’installation en cliquant sur ‘‘Browse’’.

Figure 3.2.3.10. : Activation du logiciel

L’activation se passe sans anicroche. Je peux donc lancer MatLab grâce au raccourci présent dans le menu Démarrer. L’application se lance.

Figure 3.2.3.11. : MatLab après démarrage



2009-2010 54

3.2.4 Création de la carte (map) du MOSp de chaque macrobloc MatLab étant fonctionnel, je peux désormais créer le graphique (appelé map) représentant la valeur de chaque macrobloc par un carré de couleur. Le résultat est représenté à la figure suivante :

Figure 3.2.4.1. : Exemple de map avec ‘‘shading flat’’ et ‘‘colorbar’’

Afin d’obtenir le résultat voulu, il faut écrire une suite de commandes en langage MatLab dans la partie ‘‘Command Window’’ (en rose sur la figure 3.2.3.11. à la page précédente). La première étape est de stocker, dans une matrice, le contenu du fichier, mosp_SéquenceMéthEncoVal.log archivant la valeur de chaque macrobloc pour une trame donnée. Sa composition est décrite dans la partie 3.2.2. Pour cela, je saisis :

A = [ contenu du fichier mosp_SéquenceMéthEncoVal.log ]; La seconde étape est de dire au programme quelle colonne correspond au MOSp (il s’agit de la troisième). J’utilise la commande suivante :

mosp = A(:,3); ‘‘A’’ est la matrice créée précédemment, ‘‘:’’ sert à signaler qu’il faut prendre toutes les lignes de la matrice et ‘‘3’’ indique le numéro de la colonne correspondant au MOSp. ‘‘mosp’’ est actuellement représenté sur 99 lignes et 1 colonne ; cela ne correspond pas au résultat attendu (cf figure 3.2.4.1.). Il faut donc mettre en forme les valeurs. Il y a 99 macroblocs de 16 pixels de côté. Une séquence au format .qcif mesure 176 pixels de large pour 144 de haut. Pour savoir le nombre de macroblocs à placer par ligne et par colonne, il faut faire les calculs suivants :

nombre de macroblocs en largeur = ��

�� = 11 nombre de macrobloc en hauteur =

��

�� = 9

Pour trier les valeurs comme je le souhaite, il faut utiliser le script de la page suivante :



2009-2010 55

j=1; J’initialise à j à 1 ; il sert à compter les lignes. for (i=1:11:89) Je fais une boucle dont le but est de mettre en ligne 11 MOSp.

Le premier macrobloc de la première ligne est le 1, celui de la seconde est le 12 et ainsi de suite.

Il faut donc créer une variable dont la plus petite valeur sera 1, la plus grande 89 et l’incrémenter de 11 à chaque fois.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

mosp_map(j,:)=A(i:i+10,3); Je crée une variable mosp_map qui a ‘‘j’’ lignes de 11 MOSp et toutes les colonnes (‘‘:’’) que l’on a créé c'est-à-dire 11. Elle prend les valeurs de la matrice ‘‘A’’ mise en forme ; c'est-à-dire en ligne, toutes les valeurs de ‘‘i’’ à ‘‘i+10’’ et en colonne, la troisième c'est-à-dire celle du MOSp.

j=j+1; ‘‘j’’ est incrémenter afin de faire une nouvelle ligne. end Je termine la boucle for. En d’autre termes, ‘‘i’’ se charge du placement horizontal des MOSp et ‘‘j’’ du vertical.

1 2 3 4 5 6 7 8 9

10 11 12 13 14 15 16 …

Figure 3.2.4.2. : Fonctionnement du script créé sous MatLab

1 2 3 4 5 6 7 8 9 10 11 i

j

j+1

i+1 i+2 i+3

12 13 14 15 16 …



2009-2010 56

Enfin, il faut créer le graphique à proprement parler. Pour cela, j’emploie la fonction :

figure, pcolor(mosp_map); shading flat; axis ij; co lorbar ‘‘figure, pcolor(mosp_map)’’ permet de faire une map (i.e. des carrés colorés en fonction de leur valeur). Le paramètre entre parenthèse correspond à celui que l’on veut représenter. ‘‘shading flat’’ supprime la bordure noire entre chaque carré. ‘‘axis ij’’ correspond à l’abscisse et à l’ordonnée du graphique (ici, ‘‘i’’ représente les macroblocs on le met donc en abscisse et ‘‘j’’ le nombre de ligne, on le met en ordonnée car je veux un carré de 11 par 9). Enfin, ‘‘colorbar’’ affiche une barre à droite de la figure ; elle indique la légende. J’obtiens le résultat présenté à la figure 3.2.4.1. Si je choisis de ne pas mettre les paramètres ‘‘shading flat’’ et ‘‘colorbar’’, la map est la suivante :

Figure 3.2.4.3. : Exemple de map sans ‘‘shading flat’’ et ‘‘colorbar’’

Le script complet (i.e. tel qu’il est entré sous MatLab est disponible à l’annexe IV). À noter : pour toutes les cartes de MOSp présentes dans ce rapport, plus la couleur du macrobloc est rouge foncée, plus le MOSp est élevé et donc meilleure est la qualité visuelle et inversement lorsque la couleur est bleue foncée (cf figure 3.2.4.1.). Maintenant que je sais créer une carte de MOSp avec MatLab, je peux passer aux expérimentations et à l’analyse des résultats obtenus.



2009-2010 57

3.2.5. Résultats Dans cette partie, je présente les résultats de mes expériences. Il m’a été demandé de comparer la carte de MOSp de deux trames l’une provenant d’une séquence encodée avec la méthode QP et l’autre venant de la même séquence encodée avec la méthode RC. Ces trames doivent avoir une différence de qualité subjective particulièrement visible et les deux vidéos doivent avoir le même débit (se reporter aux tableaux de la partie 3.1.3.2.). J’ai fait ces tests pour une trame de chacune des séquences encodées précédemment (cf. partie 3.1.). Je ne développerai ici que les résultats marquant c'est-à-dire ceux dont la qualité visuelle est significativement différente. En effet, sur certaines séquences, la différence de qualité, bien qu’elle soit relativement grande, est difficile à voir ; il peut s’agir de macroblocs de la mauvaise couleur dans une zone l’image, de flou ou de légères distorsions. Ces dégradations sont extrêmement ardues à rendre sur le papier car l’impression ne peut pas être parfaite. C’est pour cette raison que je ne ferai figurer ici que les trames en ayant des particulièrement visibles (les autres sont à l’annexe IV). La séquence ‘‘foreman.qcif’’ présente une différence de qualité relativement grande entre les deux méthodes d’encodage (i.e. QP et RC) j’ai comparé la trame 157 pour un frame rate de 30.

Débit d’environ 51 kbits/s Méthode QP Méthode RC

Tout d’abord, je rappelle que plus la couleur du macrobloc (i.e. le carré) est rouge foncée, plus le MOSp est élevée et donc, plus la qualité visuelle est grande ; plus le carré est bleu foncé, plus le MOSp est faible et, de fait, la qualité visuelle est mauvaise. Je remarque que la méthode du QP donne de meilleurs résultats que la méthode du RC (la carte pour le QP est globalement plus orangée que celle pour le RC). De plus, les régions ayant une bonne qualité visuelle ont un fort MOSp ; je fais la même constatation pour le cas inverse.



2009-2010 58

‘‘mother_and_daughter.qcif’’ présente elle aussi une différence de qualité à la trame 193.

Débit d’environ 27 kbits/s QP RC

Dans le cas du QP, je remarque deux zones où le MOSp est fort (en trait continu) et une où il est faible (en pointillés). Je les retrouve sur la capture d’écran de la trame. De plus, pour le RC, l’aire où le MOSp est grand est plus vaste c’est aussi le cas de celle où il est plus petit. La surface où le MOSp est peu important étant plus grande et au niveau des visages (plus particulièrement de celui de la mère), la qualité visuelle de l’image apparait clairement comme moins bonne.



2009-2010 59

La dernière séquence qui retiendra mon attention ici est ‘‘table.qcif’’. L’une des trames présentant le plus de différence est la 75.

Débit d’environ 47 kbits/s QP RC

Je remarque ici qu’entre la trame encodée avec la méthode du QP et celle codée avec la méthode du RC, il y a une baisse de qualité significative : il y a une augmentation du nombre de carré bleu et donc une baisse du MOSp pour ces macroblocs. Les observations faites ci-dessus se retrouvent lorsque l’on compare subjectivement les deux trames. Les constations faites aux pages précédentes montrent bien qu’il y a une relation entre le MOSp et la qualité visuelle de la vidéo. Par conséquent, et grâce aux remarques faites précédemment, le CVC va pouvoir améliorer ce CODEC en faisant en sorte que la qualité entre chaque macrobloc reste constante. Pour cela, leur projet et des réduire les données allouées aux zones où le MOSp est grand pour en donner aux secteurs où ce dernier est plus faible. Il s’agit donc de faire une sorte de moyenne. Après avoir réalisé les tâches qui m’ont été demandé, je peux dresser un bilan de mon stage.



2009-2010 60

4. L’aboutissement de mon stage au CVC Dans cette partie, je vais effectuer un bilan des tâches effectuées pendant mon stage. Je vais d’abord évoquer les résultats obtenus puis les difficultés que j’ai rencontrées et enfin j’évoquerai les prolongements possibles.

4.1. Résultats obtenus L’objectif final de ce projet était de permettre au CVC de se rendre compte de la corrélation entre qualité visuelle et MOSp Pour répondre à ce besoin, j’ai d’abord du comprendre les principes généraux d’encodage en MPEG-4 / H.264. J’ai ensuite étudié les deux méthodes d’encodage proposées par le CODEC. Ces méthodes sont celle du QP fixe et du Rate Control. J’ai, par la suite, comparé objectivement (grâce au PSNR Y) et subjectivement les séquences encodées ce qui m’a permis de faire la carte des MOSp de chaque macroblocs pour deux trames (chacune provenant d’une vidéo encodée avec une méthode différente). Ces dernières ont révélé qu’aucune des deux méthodes n’encode, de manière uniforme, tous les macroblocs et donc qu’il y a, en plus des différences de qualité entre chaque méthode, des baisses de qualité au sein d’une même trame. Par conséquent, je peux donc dire que mon objectif est atteint car le CVC a désormais une preuve de ce qu’il supposait. Ce stage m’a permis d’acquérir des compétences techniques telles que la connaissance des principes d’encodage (estimation / compensation de mouvement) ainsi que le fonctionnement d’un CODEC MPEG-4 / H.264. J’ai également appris les bases pour l’utilisation de Visual Studio ainsi que celle du langage éponyme. La réussite de ma mission ne s’est pas faite sans difficultés. Je les évoque dans la partie suivante.

4.2. Difficultés rencontrées

La première difficulté a été l’adaptation à des méthodes de travail qui m’étaient inconnues : dans les pays anglo-saxons en général, une place très importante est laissée à l’autonomie que ce soit au niveau de la gestion de son travail, de sa réalisation ou de l'organisation de ses horaires de travail. De plus, j’ai été surprise par la fait que ma maître de stage soit étonnée que je réalise ce que l’on me demande rapidement et correctement. Enfin, j’ai dû faire avec les absences et le manque de temps de cette dernière (il m’est arrivée d’avoir terminé mon travail et devoir attendre une semaine avant qu’elle n’ait le temps de m’expliquer la suite du projet).

Sur le plan technique mes difficultés ont été principalement liées à la méconnaissance du codage vidéo. Il a fallu que j’assimile en très peu de temps des principes pouvant être complexes (compensation / estimation de mouvement) ainsi qu’un vocabulaire spécifique au domaine et dont le sens n’est pas toujours très évident. Une autre difficulté a été de comprendre les messages d’erreur du CODEC lorsqu’un ou plusieurs paramètres ne sont pas corrects. Ceux-ci ne sont pas très clairs et n’indiquent pas réellement quel est le problème. Lors d’une expérimentation où je cherche à comprendre l’influence du format YUV sur le débit, j’ai voulu le modifier (pour cela il faut modifier ‘‘YUVFormat’’ et ‘‘ProfileIDC’’1 dans le fichier de configuration). Une fois les modifications effectuées, j’ai obtenu l’erreur suivante :

Figure 4.2.1. : Erreur du CODEC

Comme le montre la capture d’écran, le CODEC indique que ‘‘Transform8x8Mode’’ doit être utilisé pour des ‘‘ProfileIDC’’ allant de 100 à 144. Or le profil que je veux utiliser est le 88 et aucun paramètre ne permet de régler ‘‘Transform8x8Mode’’. Malgré mes recherches, je n’ai pas trouvé de réponse, je me suis donc tournée vers ma maître de stage qui elle non plus n’avait aucune idée du pourquoi de cette erreur. Je n’ai pas donc pas pu mener à bien ces tests (i.e l’influence du format YUV sur le débit). J’ai aussi dû me familiariser avec Microsoft Visual Studio qui n’est pas reconnu pour être un logiciel très simple d’utilisation ni très intuitif. 1 Ces paramètres sont définis dans la partie 2.3.2.



2009-2010 61

Enfin, j’ai dû utiliser MatLab et créer un script dans le langage du même nom. La documentation sur ce dernier est soit peut explicite, soit payante, il a donc fallu que je me tourne vers les membres du CVC. Grâce à quelques explications d’A.Bhat j’ai su comment réaliser la map de MOSp.

4.3. Prolongement Les prolongements possibles sont l’amélioration du CODEC notamment par l’implémentation d’un mécanisme permettant d’équilibrer les données allouées à chaque macrobloc afin d’avoir une qualité visuelle identique au sein d’une même trame. Ce projet est très ambitieux et va probablement être mené par le CVC dès l’année prochaine. En effet, l’implémentation et la validation d’un tel algorithme nécessite énormément de temps et de recherches.



2009-2010 62

Conclusion Afin d’obtenir mon Diplôme Universitaire de Technologie, il m’a été demandée d’effectuer un stage de dix semaines au Center for Video Communications de la Robert Gordon University à Aberdeen, en Ecosse. Ce centre mène des recherches sur la compression de la vidéo. Leur but est de trouver un moyen de la compresser en gardant la meilleure qualité possible. Ma mission a été de mettre en avant la différence de qualité entre deux trames encodées avec des méthodes différentes mais aussi de vérifier ou non si l’indicateur créé par le CVC à une bonne relation avec la qualité visuelle. N’ayant pas de connaissance dans le domaine de la compression vidéo, il m’a été demandé de faire un travail préliminaire me permettant de prendre en main le CODEC c'est-à-dire de comprendre le rôle de ces différents paramètres mais aussi de savoir correctement l’utiliser. Puis, j’ai débuté les expérimentations à proprement parlé en commençant pas comparer les deux méthodes d’encodage proposées par le CODEC (méthode QP et méthode RC). Il est alors apparu qu’aucune n’était plus performante que l’autre du point de vu mathématique en tout cas. Cependant, lors de la comparaison subjective de celle-ci, celle du QP a semblé clairement meilleure. En effet, dans ce cas toutes les trames ont la même qualité ce qui n’est pas le cas avec l’autre. De plus dans le cas du RC, la trame a des zones où la qualité est nettement moins bonne. Celles-ci peuvent être normalement mises en avant grâce au MOSp qui est un indicateur ayant pour but de faire un lien entre la comparaison objective et subjective. C’est cette supposition, qui s’est avérée vraie, que j’ai démontré dans cette partie. Enfin, j’ai dressé un bilan de ce stage dont j’ai rempli la mission. Cependant des prolongements sont possibles tels que l’amélioration du CODEC. C’est d’ailleurs l’un des projets du CVC



2009-2010 63

Bilan humain Dans cette partie, je vais faire un bilan humain de ce stage. Tout d’abord, je vais présenter les difficultés auxquelles j’ai été confrontées. Puis je parlerai des apports de ce stage et de son contexte sur le plan humain.

� Difficultés Tout d’abord, l’arrivée à Aberdeen n’a pas été une partie de plaisir ! Le logement de l’université (i.e. les Riverside Cabins) propose un confort extrêmement limité : le chauffage ne remplit pas son rôle, la propreté laisse à désirer, une odeur de plastique brûlé règne dans les chambres, dans la cuisine, les mouches vivent dans le micro-onde / four, des piles d’assiettes sales gisent dans l’évier, la plaque de cuisine est recouverte de dépôts d’aliments calcinés et, là aussi, on sent une odeur nauséabonde.

Photographie de la ‘‘cuisine’’

Source personnelle

Les Riverside Cabins sont une honte pour le personnel de RGU qui, quand on leur en parle, fronce les sourcils d’un air de profonde compassion. Après avoir passé une nuit ici (la température n’excédait pas 8°C), Rémi Voirin (i.e. l’autre stagiaire de Clermont-Ferrand) et moi avons décidé de partir à la recherche d’un appartement convenable ce qui ne fut pas une tâche facile en ce week-end Pascal. Après plusieurs échecs, nous avons trouvé, par le biais d’un site permettant aux propriétaires de mettre en ligne des annonces pour louer leur appartement sans passer par une agence, notre logement. Cependant, les difficultés ne s’arrêtèrent pas là.

Étant venu en voiture, il a fallu obtenir un permis de parking car celui-ci est payant dans notre rue et sur environ 1 mile aux alentours. Nous nous sommes donc rendus à ‘‘The Point’’, le service de la mairie les délivrant. Une fois sur place, on nous annonça que les baux privés ne sont pas des justificatifs et qu’il nous faut une facture de la compagnie d’électricité ou une lettre de l’université. Ma maître de stage n’ayant pas le temps de m’en faire une avant la semaine suivante, Rémi a demandé au secrétariat de la School of Computing de lui en délivrer une. Nous avons donc obtenu, pour £22 / 3 mois, notre permis de stationnement.

Enfin, la dernière difficulté rencontrée a encore un lien avec la mairie de la ville. Lorsque l’on vit à Aberdeen, une taxe (la ‘‘Council Tax’’) est demandée afin de payer l’eau et les services de la ville. Étant étudiants, nous n’avons normalement pas à la payer. Un mois et demi après nous être enregistrés à la mairie, nous recevons une facture nous réclamant la modique somme de £1080 de ‘‘Council Tax’’. Nous nous rendons sur place afin d’éclaircir cette histoire. En effet, nous n’apparaissons pas dans les listes d’étudiants d’Aberdeen fournies en début d’année à la mairie. Nous avons donc du prouver que nous étions bien étudiants (une lettre de RGU a suffi). Malgré la différence de langue qui, pour des démarches administratives requièrent un vocabulaire bien particulier, et la difficulté de trouver un appartement pour moins de 6 mois (durée légale minimale pour un bail en Ecosse), nous avons surmonté ces difficultés et, de fait, pu profiter pleinement de notre stage mais aussi pu découvrir Aberdeen, l’Aberdeenshire et même les Îles Shetland.



2009-2010 64

� Apports du stage et du contexte

Ce stage s’est déroulé à l’étranger, dans un pays anglophone ce qui m’a permis d’améliorer mon anglais tant

au niveau de la compréhension (écrite et orale) qu’au niveau de l’expression (écrite et orale). De plus, le mode de travail est totalement différent de ce que l’on peut trouver en France. Par exemple, une grande autonomie est offerte aux étudiants qui doivent, la plupart du temps, se débrouiller par eux-mêmes pour acquérir des compétences en faisant des recherches et / ou des formations du type du CCNA Cisco. Par conséquent, les étudiants jouissent d’une grande liberté quant à l’organisation et la répartition de leur travail. En outre, une grande flexibilité est offerte au niveau des horaires qui sont d’ailleurs (sur le papier) plus légers qu’en France. Cet aspect m’a permis de gagner en autonomie et en organisation au niveau de mon travail. Aussi la relation étudiant / professeur semble plus ouverte ce qui, à mon avis, permet d’instaurer une sorte de confiance mutuelle qui permet une meilleure ambiance. Globalement, les gens semblent beaucoup plus accueillants qu’en France ce qui offre de plus grandes facilités pour s’intégrer dans une équipe de travail déjà formée depuis de longs mois. J’ai d’ailleurs eu la sensation de bien m’être intégrée au sein du CVC. Le bilan général de ce stage est très positif. Il m’a conforté dans le choix de poursuivre mes études et, pourquoi pas, à l’étranger et m’a aussi permis d’améliorer mes compétences humaines telles que l’adaptabilité, la communication et l’organisation.



2009-2010 65

Questionnaire en anglais

INTERNSHIP TITLE: Comparaison des performances de deux méthodes d’encodage pour un CODEC H.264 START DATE: Wednesday, April 7th END DATE: Friday, June 11th INTERNSHIP SUPERVISOR: Dr Yafan Zhao

Question One: Where did you do your internship?

I did my internship at the Centre for Video Communications in the School of Engineering, The Robert Gordon University in Aberdeen. This city is the third most populous in Scotland and it is known as ‘‘The Oil Capital of Europe’’ or as ‘‘The Grey City’’ because of the offshore oil and the granite buildings. The motto of the city is the French words ‘‘Bon Accord’’. This motto was used as a sign of recognition between Scottish during the war with England. Question Two: Who did you work with/ for?

I worked mostly alone but, once a week, my supervisor had a look at my work, answered to my questions and explained to me what I had to do next. When she was not available or not in the CVC lab, A. Bhat helped me. For example, she explained to me some parameters of the CODEC and how MatLab works. Question Three: What were you asked to do?

I had to compare the performances of two coding methods for a MPEG-4 / H.264 CODEC. The final aim is to indicate to the CVC members if there is any way to improve the CODEC performance. In order to achieve this goal, my work was divided in three parts describes in question four. Question Four: Explain in stages what you did. First of all, I did preliminary work to study the various parameters of the CODEC in order to understand how the output sequence is influenced. For example, the parameters called ‘‘QPISlice’’, ‘‘QPPSlice’’ and ‘‘QPBSlice’’ (usually called QP) define the quality of the frame I (the first one of a sequence), P and B (the other frames of the sequence). I observe that the higher the QP, the worse is the picture quality. This work took about one month because I had to test a lot of parameters and because the encoder needs about thirty minutes to code a video. These results are presented in the second part of this report. After that, I had to compare two coding methods proposed by the CODEC. The first one is called fixed QP (the QP value is chosen and it never changes during the coding). The second is called Rate Control. In this method, the QP is not fixed. Instead, I chose a target bitrate and the CODEC tries to achieve it by changing the QP for each frame. Once the sequences are coded with the two methods, I did a graph in order to compare objectively using PSNR Y and bitrate which one is the best. It appears that neither of them are better: it depends on the motion in the sequence. Then I compared those two methods subjectively (i.e. I watched the two sequences coded with each method and I wrote the difference in quality in tables). This time it appears that the QP method is better than RC method. In this one there are significant differences of the quality in the same frame that is why the quality seems worse. The last step consists of comparing a video frame encoded with fixed QP and with Rate Control. The comparison was made using an objective video quality measure called MOSp. This frame had to have big visual differences. Once that was done, I did a map of MOSp with software called MatLab. I noticed that the areas with a worse visual quality had a lower MOSp. So, I can say that MOSp which is calculated mathematically has a very high correlation with the visual quality.



2009-2010 66

Question Five: Did you have any problems? I did not have big problems. But I found that the CODEC would often give error messages which were not clearly explained: they didn’t really explain which parameters are wrong and why. A few times I asked my supervisor because I didn’t find the answer by myself and she had no idea at all about the wrong things in the CODEC. So, it was a little annoying and I wasn’t able to finish my experiments, for example, about the influence of the YUV format on the bitrate. Another problem is the lack of documentation about MatLab and its programing language: much of the documentation is paying and, if it’s not the case, it’s really incomplete. Question Six: Was your work successful? In my opinion, my work was successful because I’ve done all the tasks I had to do. Question Seven: How could your work be continued by another student? First of all my work is completely done. The final aim was to show to the CVC what are the things which can be improved in the CODEC. That was presented by the MOSp map. Now, the CVC will work on it to do a kind of average between macroblocks with a high MOSp and the one with a low MOSp in order to not have any more a big drop of the quality in certain areas of the picture. I think the improvement of the CODEC can’t be done by another IUT student. I explain. Video coding is based on complicated concepts which need time to understand it well. Moreover, the CODEC contains a lot of C files which is possible to modify to improve it. Ten weeks is not enough to understand video coding concepts, how the CODEC C files work together and how modify them to do the average between high MOSp macroblock and low MOSp macroblock. That’s why my work will be used by the CVC. Question Eight: What technical skills did you gain from doing this internship? In the first place, I gained skills about video coding: I understood how a MPEG-4 / H.264 CODEC works, what are the mechanisms to code a sequence (motion estimation, motion compensation, …) and what are the coding methods (fixed QP, RC). I learnt also what the CODEC parameters mean and what are their functions. Moreover I gained programming skills: I discovered the basics of Microsoft Visual Studio and MatLab programming language (‘‘for’’ loop, table and figure). Question Nine: What other skills did you obtain? In addition to the technical skills listed in the previous question, I gained people skills. The first one is a better knowledge of written and spoken English. This one is due to the context of my internship. I discovered also a new way of work: in anglo-saxon countries a larger place is let to the autonomy and the schedule is more flexible. So, I was able to organize my work and my schedule as I wanted. It’s really different that I always known. Then I’m more resourceful with, for example, administrative papers. Overall, I keep a very good impression about this internship as well as human and technical. It was a great and unique experience. Question Ten: Was the internship linked to your future studies or your future career? I think this internship doesn’t really have a link with my future studies or career despite it was really interesting. In fact, I’d like to work in networking: I hope to do a degree in this domain; for example, RSFS or ASUR and then a Masters degree in a foreign country. However I’m sure this internship was a very good opportunity to improve my CV (and my English as well) because it took place in a foreign country. I’m very happy about the last ten weeks.



2009-2010 67

Glossaire .264 Vidéo encodée avec un CODEC H.264. C’est le format de sortie du CODEC utilisé dans

ce rapport. .cif CIF est une abréviation pour Common Intermediate Format. C’est un format utilisé

pour normaliser la résolution horizontale et verticale en pixel des séquences vidéo au format YCrCb. Les vidéos en se formant ont une résolution de 352*228 pixels, un nombre d’images par seconde de 29,97 et les couleurs sont encodées au format YUV 4:2:0. De plus, une trame contient 22*18 macroblocs

.qcif QCIF est l’abréviation de Quarter Common Intermediate Format. Les caractéristiques d’une vidéo de ce format sont les mêmes que pour le cif excepté qu’elle a une résolution quatre fois moins grande (176*144). Le nombre de macroblocs est lui aussi divisé par 4 (11*9).

.yuv Vidéo encodée au format YUV. C’est le format de sortie du CODEC utilisé dans ce rapport. Cette séquence, couplée à celle au format .264 sert à recréer celle d’origine grâce au décodeur ou à lire celle encodée.

CABAC Context-based Adaptive Binary Arithmetic Coding est une forme de codage entropique utilisée dans le MPEG-4 / H.264. Il permet une meilleure compression que les autres algorithmes de compression ce qui est un des principaux avantages du MPEG-4 / H.264. Cependant, il nécessite une grande quantité de traitements pour être décodé.

Chrominance désigne la couleur. Généralement cette dernière est décomposée en 3 composantes (= en 3 chrominaces) rouge, verte et bleue (RVB).

Codage Fait de passer d’une représentation de données à une autre. Par exemple, on passe de lettres formant un mot à une représentation en binaire de celui-ci.

CODEC COdeur / DECodeur. Il existe différents types de codeur/décodeur ne compressant pas tous les données de la même manière et donc donnant rendu ayant différente qualité. Il y en a pour le son et pour la vidéo.

Compiler Fait de transformer des fichiers écrits dans un langage de programmation compréhensible par l’homme en un programme exécutable (= dans un langage compréhensible par la machine).

Compression Technique permettant de réduire la taille de données numériques afin de faciliter leur stockage ou leur envoi sur un réseau.

Compression entropique Compressions sans perte. Le code de Huffman est une forme de compression entropique.

Échantillonnage Fait de transformer un signal analogique en un numérique. Dans le cas d’une image, on utilise deux types d’échantillonnage : le spatial et le temporel.

Extension Partie du nom du fichier située après le ‘‘.’’ définissant son type. Par exemple, un fichier .txt est un fichier texte, un .xlx est un fichier excel et ainsi de suite. Généralement les utilisateurs lamba ne les affichent pas (i.e. sous Windows, notamment, elles sont masquées par défaut).

H.264 Norme de codage vidéo dont le but est de réduire les temps de codage et décodage mais aussi de permettre une meilleure adaptation au protocole utilisé pour transporter le flux vidéo.

IDE Un Integrated Development Environment est programme regroupant un ensemble d'outils (éditeur de texte, compilateur, débogueur,...) pour le développement de logiciels. Exemple d'IDE : Eclipse (développement en Java), Microsotf Visual Studio, ...

Log Fichier stockant tous les événements qui se sont produits lors d’une action quelconque. Luminance Intensité lumineuse. Dans ce rapport, la luminance est la luminosité d’un pixel. Macrobloc Unité de base utilisée dans le codage de la vidéo. C’est un bloc de pixels de 16*16. Monochrome Désigne l’utilisation d’une seule couleur dont on fait varier la luminosité pour faire des

nuances. Le ‘‘noir et blanc’’ est le plus célèbre monochrome : la couleur utilisée est le noir dont on fait varier la luminosité pour obtenir des nuances de gris allant jusqu’au blanc.



2009-2010 68

MPEG-4 Norme de codage des séquences audio-visuelles dans le cas d’applications multimédias

(téléchargement, streaming, vidéo et radio mobile, jeux vidéo, télévision, support haute définition).

Pétrole offshore Pétrole se trouvant dans un gisement en haute mer. On l’exploite grâce à des plateformes pétrolières.

Proxy Serveur servant à relayer les requêtes entre un poste client et un autre serveur. Il est couramment utilisé dans les collectivités notamment pour réguler l’accès à Internet.

PSNR Le Peak Signal to Noise Ratio est un indicateur de qualité objectif de la vidéo. Son unité est le décibel (dB). Il est calculé grâce à la formule suivante :

PSNR =10.log��²

��

avec m la valeur maximale que peut prendre un pixel (s’il est codé sur 8 bit, la valeur maximale est de 255).

RTP Real Time transfert Protocol est un protocole de communication Sortie standard Dans le cas d’un terminal Unix ou d’une console Windows, la sortie standard est

l’endroit où sont affichés les résultats de commande. Par défaut, celle-ci est l’écran mais il est possible de la rediriger dans un fichier par exemple.

Système visuel humain Ensemble des organes permettant la perception visuelle. Il regroupe les organes suivants : l'œil et plus particulièrement la rétine les nerfs optiques le chiasma optique le tractus optique le corps genouillé latéral les radiations optiques le cortex visuel



2009-2010 69

Bibliographie

Ouvrages : Iain E.G. Richardson, H.264 and MPEG-4 Video Compression – Video compression for Next-generation Multimedia, John Wiley & Sons Ltd, 2003 Stefan Winkler, Digital Video Quality Vision Models and Metrics, John Wiley & Sons Ldt, 2005

Publications : Abharana Bhat, Iain Richardson and Sampath Kannangara, A Novel Perceptual Quality Metric for Video Compression, Picture Coding Symposium 2009, California, Illinois, USA, mai 2009 disponible aussi à l’adresse suivante : http://www4.rgu.ac.uk/files/PCS_46.pdf International Telecommunication Uninon section Telecommunication, Recommendation P.910 - Subjective video quality assessment methods for multimedia applications, 2009 disponible aussi à l’adresse suivante : http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-P.910-200804-I!!PDF-E&type=items International Telecommunication Uninon section Radiocommunication, Recommendation BT. 500-11 - Methodology for the subjective assessment of the quality of television pictures, 2002 disponible aussi à l’adresse suivante : http://www.dii.unisi.it/~menegaz/DoctoralSchool2004/papers/ITU-R_BT.500-11.pdf

Sites web : CODEC : Site où est publié le CODEC : http://iphome.hhi.de/suehring/tml/download/version 12.1

Documentation : http://iphome.hhi.de/suehring/tml/JM%20Reference%20Software%20Manual%20%28JVT-AE010%29.pdf Lecteur YUV :

http://www.softpedia.com/get/Multimedia/Video/Video-Players/Avarex-YUV-Player.shtml Projet de James Philip :

http://www.openvideocoding.org Renseignements généraux :

http://www.en.wikipedia.org

http://www.fr.wikiperdia.fr http://www.aberdeencity.gov.uk http://www.rgu.ac.uk

La compression de la vidéo est de plus

en plus utilisée dans le cas de transferts

sur un réseau quelconque de vidéos

(streaming, téléchargement, …). Elle a

pour but de réduire le débit nécessaire à

celle-ci et, de fait la bande passante.

Cependant, compresser une vidéo

implique, nécessairement une perte de

qualité objective et subjective qui

peut s’avérer gênante.

Le Center for Video Communications a

pour projet de limiter au maximum

cette perte mais aussi d’établir une

relation, à l’aide du MOSp, entre ces

deux types de qualité.

Pour cela, il m’a été demandé de

comparer deux méthodes d’encodage

d’un CODEC MPEG-4 / H.264 afin de

déterminer objectivement et

subjectivement quelle est la meilleure. Par

la suite, j’ai dû vérifier la relation entre

ces deux modes de comparaison afin de

voir si le MOSp est viable.

Les réponses à ces interrogations se

trouvent dans le présent rapport.

Documents

Comparaison des performances de deux méthodes d’encodage pour un CODEC H.264