Encodage H.264 - CPU vs GPU : Nvidia CUDA, AMD Stream, Intel MediaSDK et x264 en test
Cartes Graphiques
Publié le Jeudi 28 Avril 2011 par Guillaume Louel
URL: /articles/828-1/encodage-h-264-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-x264-test.html
Page 1 - Introduction
Depuis quelques années, les constructeurs de cartes graphiques mettent en avant la capacité de leurs GPU à faire autre chose que du jeu. Si l'on peut relever certaines réussites dans le marché du High Performance Computing (milieux financiers, etc), côté grand public le concept du GPGPU (General Purpose computing on GPU) se cherche encore. Les standards comme OpenCL et DirectCompute tentent de faire leur trou mais l'adoption reste encore, côté grand public, relativement anecdotique.
La vidéo, évidemment ! Un usage GPGPU grand public revient cependant assez souvent dans les présentations : l'encodage de vidéos. Sur le papier, l'idée semble très bonne. Les GPU peuvent déjà être mis à contribution quand il s'agit de décoder des vidéos (par exemple des Blu-ray), ce qui se fait par le biais d'un circuit dédié, intégré au GPU. Utiliser un GPU pour encoder semble donc l'étape suivante dans la logique.
Après un départ assez limité avec la première version de Badaboom en 2008 , le transcodage est revenu sur les devant par l'intégration dans Windows 7 de la possibilité d'utiliser sa carte graphique pour transcoder automatiquement ses fichiers vers un périphérique (lecteur de vidéo portable, smartphone, à condition qu'il soit compatible et détecté par Windows 7). Et de multiples applications, gratuites ou payantes, se sont attaquées aux problèmes de transcodages de fichiers, que ce soit à destination de périphériques mobiles, de tablettes ou de consoles de jeu.
Un point commun de ces applications est qu'elles utilisent souvent des bibliothèques conçues par les constructeurs de GPU eux même. Nvidia fournit ainsi sous licence un encodeur H.264 développé sous CUDA (nvcuvenc), AMD dispose du sien utilisant la technologie Stream (AMD Media Codec package en bas de page), et même Intel s'y est mis, comme nous l'avions vu en début d'année lors du lancement des processeurs Core Sandy Bridge avec son MediaSDK (qui repose lui-même en partie sur la bibliothèque IPP).
Mais que valent en pratique ces solutions ? Tous les logiciels qui les utilisent sont ils équivalents ? Quid de la rapidité d'encodage et de la qualité ? Et comment se mesurent ces solutions d'encodage face à la référence de l'encodage H.264, le logiciel open source x264 (que nous utilisons régulièrement dans nos tests processeurs) ? Des questions brulantes auxquelles nous allons tenter de répondre dans ce dossier !
Avant d'aller plus loin nous tenons à remercier le magasin Nicolas et fils pour les prêts de matériels ainsi que Jason Garrett-Glaser (dévelopeur de x264) pour avoir répondu à nos questions sur H.264. Si vous souhaitez approfondir le sujet, voici quelques ressources que nous avons utilisées pour élaborer cet article :
- La specification de H.264
- Le livre The H.264 Advanced Video Compression Standard de Iain Richardson (dont le site propose un certain nombre de contenus intéressants et gratuits ici )
- Le blog de Jason Garrett-Glaser
Page 2 - Conteneur, codec, transcodage
Avant d'entrer dans le vif du sujet et pour comprendre ce que nous avons comparé exactement, permettez nous un petit rappel sur quelques points concernant le sujet de la vidéo.
Conteneur, codecs Ce que l'on appelle abusivement un fichier vidéo est avant tout un conteneur. Le concept est simple, il entrelace en son sein les différents contenus du fichier, à savoir la piste vidéo, la piste audio, et éventuellement les pistes de sous titre.
A gauche vue de principe, à droite l'entrelacement des pistes.
Entrelacer les contenus permet de faciliter la lecture simultanée des différentes pistes en évitant de devoir se déplacer trop souvent à l'intérieur du fichier. Les données relatives les unes aux autres (le son qui correspond à l'image par exemple) restent ainsi proches. Un point particulièrement important pour des disques vidéos (DVD, Blu-ray) ou quand il s'agit de transmettre un flux digital (par exemple via la TNT).
Il n'y a pas réellement de lien entre un conteneur et le format des pistes qu'il contient. Un fichier AVI peut contenir des pistes vidéos encodées dans de multiples formats (MPEG-1, Xvid, etc…) tout comme les pistes audio (MP3, AAC, etc…). Un utilitaire comme MediaInfo permet de savoir exactement quelles pistes composent un fichier, et dans quel format elles sont encodées. Certaines limitations techniques existent également, ce qui peut empêcher par exemple un format vidéo comme le H.264 d'être intégré (sans subterfuge) dans un fichier AVI.
Transcodage Lorsque l'on parle de solutions de transcodage, on parle donc de changer un ou plusieurs des formats présents dans le fichier original. On peut changer les formats de compression pour obtenir un fichier plus petit. Par exemple convertir un DVD (conteneur VOB, vidéo MPEG-2, audio Dolby Digital) en un fichier vidéo (AVI, XviD, MP3). Parfois on peut souhaiter garder un même format vidéo mais réduire la taille des fichiers, par exemple en convertissant un Blu-ray (.m2ts, H.264, DTS-HD) en un fichier lisible sur une tablette (.mp4, H.264, AAC) ou une console de jeux. Même si l'on ne change pas de format vidéo (H.264 de chaque côté), on peut souhaiter recompresser la vidéo, soit pour des questions de taille de fichier (les Blu-ray sont volumineux), de taille d'écran destination (réduire à 1280 par 720 au lieu de 1920 par 1080) ou de spécificité de la machine destination (un iPad par exemple ne peux pas lire tous les « niveaux » de compression H.264, d'où la notion de profil existante à l'intérieur de la norme, voir page suivante).
Pour arriver à transcoder un fichier, il y a donc un grand nombre d'étapes à gérer, et toutes ne sont pas accélérées par le GPU. Sur le schéma suivant vous pouvez voir, d'en haut à gauche à en haut à droite, le cheminement nécessaire pour transcoder un fichier vidéo :
Cliquez pour agrandir.
De tout ceci, seules deux étapes peuvent être accélérées par un GPU aujourd'hui, le décodage de la piste vidéo d'origine en un format vidéo brut (en utilisant les circuits dédiés intégrés au GPU pour ce biais, les mêmes qui servent lors de la lecture accélérée d'un DVD ou d'un Blu-ray) et l'encodage (en utilisant, soit les unités de calculs du GPU [méthode CUDA/Stream de Nvidia/AMD], soit une partie du GPU dédiée à cette tâche [méthode Intel pour Sandy Bridge/HD 3000]).
Seulement deux étapes, certes, mais ce sont de loin les plus gourmandes. Voici par exemple un découpage d'un encodage que nous avons réalisé pour nos tests (fichier extrait d'un Blu-ray vers fichier MKV 720p) :
Il s'agit ici d'un encodage très haute qualité que nous avons effectué afin de créer un fichier source (nous y reviendrons). Le temps d'encodage vidéo est donc significatif. Pour conclure sur le sujet du transcodage, notez deux points importants pour la suite de notre article :
- Le décodage et l'encodage de la vidéo sont des tâches qui s'effectuent en parallèle, image par image. L'encodage est théoriquement plus long que le décodage, mais ce n'est pas toujours vrai dans certains cas lorsque l'on parle d'accélération GPU.
- Si certains outils permettent de décomposer le temps de chaque étape, tous les logiciels que nous avons testés ne le permettent pas. Lorsque nous parlerons de temps de transcodage par la suite, il s'agira donc du temps complet incluant toutes les étapes (demux, encodage vidéo, audio, remux) et pas uniquement du temps de l'encodage vidéo !
Passons maintenant aux spécificités du H.264.
Page 3 - H.264 (1/2)
H.264 Parfois appelé AVC (souvent dans le cadre des Blu-ray) ou MPEG4 Part 10 (nomenclature ISO ), le H.264 (nomenclature ITU ) est un standard de compression vidéo souvent considéré comme le format de compression le plus avancé techniquement. Il fait suite, dans la nomenclature ISO au MPEG-1 (Video CD), MPEG 2 (utilisé sur les DVD) et au MPEG 4 Part 2 (XviD).
Il s'agit d'un standard dont la spécification est ouverte (téléchargeable ici ) mais dont l'utilisation est soumise à un certain nombre de brevets appartenant à différents grands noms de l'informatique, de l'électronique, des télécommunications ou divers instituts universitaires (Apple, Cisco, France Telecom, Fraunhofer, Microsoft, Mitsubishi, Panasonic, Philips, Sony ou Toshiba pour n'en citer que quelques uns, la liste complète des brevets est disponible ici ). Toutes ces sociétés se sont regroupées pour créer un pool de brevets gérés par le MPEG LA . Dans le cadre qui nous intéresse (utilisation personnelle et non commerciale), aucune licence n'est due pour l'utilisation du format.
Le H.264 est aujourd'hui largement répandu, que ce soit dans les Blu-ray (ou il coexiste avec un format de Microsoft, le VC-1, qui tombe lui aussi sous le coup de brevets du MPEG LA) ou pour le fait que son décodage soit accéléré dans la majorité des matériels grand publics modernes (smartphones, tablettes, consoles de jeux, etc). Il est également amplement utilisé par les sites de vidéo en ligne, ce que l'on avait pu remarquer lors de notre test de la plateforme Brazos d'AMD ou le logiciel Flash nous posait problème en matière d'accélération vidéo.
La compression vidéo en pratique Sans rentrer trop dans les détails, nous allons vous donner une vue d'ensemble de la manière dont fonctionne H.264, ce qui nous permettra par la suite d'évoquer les points qui posent problème pour les divers encodeurs que nous avons testés.
Une vidéo est une suite d'images, compressées les unes après les autres. H.264, comme beaucoup de formats avant lui, subdivise ces images en blocs de pixels (des carrés de 4x4 pixels à 16x16, on parle de macroblocks). Pour arriver au résultat final, un encodeur doit arriver à déterminer les informations nécessaires pour recréer une image (on parle de prédiction, il y'en a de deux types) puis compresser de la manière la plus efficace possible ces données (là encore, deux types de compressions distinctes).
Prédiction temporelle Derrière ce nom se cache un concept excessivement simple. La prédiction temporelle part d'un constat : les images qui se suivent dans une vidéo ont de fortes chances d'avoir un lien les unes par rapport aux autres. Que ce soit un plan fixe ou l'on voit des personnages bouger, ou un plan de caméra qui se déplace pour regarder un paysage, les images qui se suivent auront (souvent) de très nombreux liens entre elles. Partant de là, un encodeur va essayer de retrouver dans l'image de destination l'emplacement des blocs par rapport à une ou plusieurs des images précédentes. Ces mouvements peuvent d'ailleurs être minuscules, jusqu'à un quart de pixel. On parle d'estimation de mouvements (motion estimation), et il s'agit d'un traitement sur lequel on peut penser que les GPU seront excessivement efficaces. Par la suite on parlera plus simplement d'inter prédiction.
Avatar, Fox Pathé Europa
Sur cette image extraite d'une scène d'Avatar (via Elecard StreamEye ) ou la caméra se déplace de gauche à droite tout en avançant, on peut voir que les éléments de l'image qui sont à des niveaux de profondeurs différents (la liane à gauche, les fougères en bas, les fougères claires en haut et les lianes en haut) ont tous des mouvements distincts.
Prédiction spatiale Encore un nom plus compliqué qu'il n'y parait, la prédiction spatiale est là pour tenter de compresser une image par rapport à elle-même. Plutôt que de chercher des ressemblances d'une image par rapport aux précédentes, la prédiction spatiale cherche les similitudes au sein de l'image en elle-même. Un concept équivalent à la compression d'images fixes (JPEG, etc…), que l'on appellera par la suite intra prédiction.
Bien entendu, au sein d'une même image, un encodeur peut choisir de mélanger les types de prédictions. Si l'on reprend la même image que précédemment (toujours via Elecard StreamEye ) :
En bleu/jaune, les blocs inter prédits (prédiction temporelle, par rapport à une image précédente) et en orange/rouge, les blocs intra prédits (prédiction spatiale, à l'intérieur de l'image). Avatar, Fox Pathé Europa
Notez que même si un encodeur fait de son mieux pour être le plus précis possible dans ses prédictions, elles ne sont pas forcément parfaites. Dans chaque cas de prédiction ou l'on tente de trouver des ressemblances d'un bloc par rapport à un autre (qu'il soit dans la même image, intra prédiction, ou dans une autre, inter prédiction), il se peut que la destination ne ressemble pas exactement à la source. Pas un problème, il suffit simplement de sauver la différence ! Elle est par définition petite, vu qu'après tout, les blocs se ressemblent !
Compresser quoi, et comment ? Nos prédictions génèrent deux types d'informations assez distinctes. D'un côté nous avons des informations précises, comme les vecteurs de mouvements utilisés dans les prédictions. Si l'encodeur s'est extenué à obtenir une précision au quart de pixel près, ce n'est pas pour que l'on compresse ces informations avec pertes. Pour ces informations essentielles, H.264 utilise un codage sans perte (codage entropique) et deux types distincts sont disponibles, le CAVLC et le CABAC. Différence entre les deux, le second est beaucoup plus gourmand, que ce soit à encoder ou à décoder. Vous vous souvenez peut être qu'il y a quelques temps, les GeForce 8800 proposaient un décodage des flux H.264 accéléré, mais partiel. Manquait à l'appel à l'époque le décodage CABAC qui n'était pas géré par le GPU (et qui fut ajouté dans les générations suivantes). CAVLC est moins gourmand en ressources, mais aussi moins efficace (son taux de compression est moindre).
Pour les types de données qui peuvent subir une (légère) perte, comme par exemple l'image résiduelle qui correspond à la différence entre les blocs sources et destination lors d'une prédiction (voir plus haut), une compression destructive est appliquée, ce que l'on appelle la quantification (quantization).
Au final, le mélange de ces données compressées (sans perte et avec pertes) constitue notre fichier vidéo H.264.
Maintenant que les grandes lignes sont posées, voyons quelques points de détails qui auront fait la différence lors de nos tests.
Page 4 - H.264 (2/2)
B-Frames Comme nous l'avons vu, deux types de prédictions sont possibles : on peut prédire une image par rapport à une image précédente (inter prédiction) ou par rapport à elle-même (intra prédiction). En pratique dans un fichier vidéo, on retrouve différents types d'images que l'on appelle frames :
- Certaines images n'utilisent que des blocks intra prédits. L'image peut être décodée indépendamment de toute autre, on parle alors de key frame en vidéo. L'intérêt des key frames est qu'elles permettent de gérer des fonctionnalités comme d'avance ou le retour rapide. La pratique veut que l'on place une keyframe en moyenne au moins toutes les 10 secondes. Ces images entièrement intra prédites sont baptisées I-Frames.
- D'autres images peuvent mélanger des blocs intra prédits et des blocs qui font référence à des images précédentes (inter prédits). On parle alors de P-Frames. C'est le cas de l'image que nous avons utilisé sur la page précédente.
- H.264 ajoute un troisième type d'image, optionnel. Plutôt que de faire référence uniquement à des images précédentes, une B-Frame peut faire référence… à une image future ! Cela complexifie quelque peut l'encodage bien entendu, mais en étant capable de faire référence à la fois dans le passé et dans le futur, on peut limiter le nombre de blocs intra-prédits (plus gros) que l'on doit ajouter. La compression s'en améliore donc !
Sur cette image, on peut voir une B-Frame qui cumule les trois types de blocs :
En bleu, les blocs inter prédits (prédiction temporelle, par rapport à une image précédente), en orange/rouge, les blocs intra prédits (prédiction spatiale, à l'intérieur de l'image). En vert, les blocs qui viennent du futur : ils font référence à une image suivante ! Avatar, Fox Pathé Europa
On peut également résumer le tout schématiquement comme ceci :
Filtre anti blocs Un des problèmes récurrents des formats de compression par blocs concerne la jonction entre ces blocs. Si l'on tente de compresser trop fortement les blocs en cherchant des similarités approximatives, on se retrouve avec un phénomène ou l'on voit leurs délimitations apparaitre. Vous l'avez probablement vu dans une image JPEG trop compressée :
Exemples de blocs dûs à une compression trop extrême
H.264 intègre un filtre anti blocs qui peut être appliqué à chaque macroblock. C'est à l'encodeur de définir si, et comment ce filtre devra être appliqué par le décodeur. Un calcul efficace de ce paramètre peut être gourmand, et est parfois mis de côté par certains encodeurs pour gagner du temps, comme nous le verront.
Matrices de quantifications adaptatives La quantification (l'étape de compression avec pertes) dans H.264 peut être adaptée en appliquant des niveaux différents à chaque bloc. On parle de matrices de quantifications indépendantes, ou plus simplement de quantification adaptative. En clair, au lieu d'appliquer une compression uniforme aux données résiduelles (la différence entre l'image source et destination, après l'application de la prédiction), certains blocs seront privilégiés par rapport à d'autres. Cela permet de conserver plus de détails dans les zones complexes.
Profils Certaines des fonctionnalités que nous avons notées précédemment peuvent être particulièrement gourmandes, que ce soit au niveau de l'encodage ou du décodage. H.264 tentant d'être un format universel, ses auteurs ont défini de multiples « profils » d'usage qui autorisent ou non l'utilisation de certaines fonctionnalités du format. Un téléphone portable ne supportera par exemple que le profil le plus basique, tandis qu'un Blu-ray utilisera un mode plus avancé. Trois modes nous intéressent, il s'agit de ceux repris par les différents encodeurs : Baseline, Main et High. Voici un petit résumé des fonctionnalités avancées qu'ils gèrent :
En pratique on privilégiera toujours le plus haut profil possible, à concurrence des formats supportés par le périphérique destination. Si une console de jeu comme la Playstation 3 gère les trois profils, l'iPad ne gère lui officiellement que les deux premiers. Avant de transcoder, il est important de connaitre les capacités du périphérique auquel vous destinez votre fichier : le H.264, quand il s'agit de le décoder sur une machine spécifique, n'est pas si universel que l'on pourrait le croire !
Page 5 - Mesurer la qualité : PSRN, SSIM et leurs travers
Mesurer la qualité : PSRN, SSIM et leurs travers Nous avons l'habitude sur hardware.fr d'essayer d'utiliser les tests les plus objectifs possibles. Il est assez facile de déterminer un niveau de performance quand le résultat est facilement mesurable (un temps d'execution pour une tâche donnée par exemple). Dans le cadre de la vidéo, la question de l'objectivité en matière de qualité vidéo est malheureusement très… subjective. Le vrai critère objectif est la qualité visuelle de la vidéo perçue par l'œil humain. Quelque chose que, malheureusement, on ne peut pas mesurer et quantifier autrement que par des tests humains.
Au fil des années, plusieurs outils ont été développés pour tenter de comparer la qualité d'une vidéo par rapport à une autre. Le concept de base reste toujours le même, on compare, une par une, une image de la vidéo compressée à l'image de la vidéo source. On obtient ainsi une série de valeurs, pour chacune des images qui composent la vidéo.
La métrique classique utilisée pour comparer deux images est le PSNR qui tente de déterminer le niveau de distortion d'une image compressée par rapport à sa source. Surtout utilisée pour juger les formats de compression d'images fixes, le PSNR est considéré comme une mesure très indicative qui dépend grandement du format de compression choisi ou des particularités de l'encodeur. L'autre métrique utilisée est baptisée SSIM et tente de déterminer la similarité structurelle des images, avec pour but d'être un peu plus réaliste que le PSNR.
Si en pratique SSIM est un meilleur indicateur de la qualité des images, le problème reste relativement complexe tant la perception humaine de la vision est difficile à mesurer pour un algorithme. Notre œil est par exemple instinctivement attiré sur les visages. Dès lors, l'œil humain préfèrera une image dont le visage est net mais qui peut être infidèle sur le reste de l'écran (et qui aurait un PSNR bas), par rapport à une image dont la qualité est plus homogène sur toute sa surface avec un visage globalement moins net (mais un PSNR ironiquement plus haut !).
S'ajoute à cette problématique le fait que comme pour toute métrique dont l'algorithme est connu, il est très facile d'optimiser son encodeur pour l'une d'entre elle au détriment de la qualité globale de la vidéo. L'encodeur x264 illustre assez bien ce problème en proposant, au milieu de ses options qui permettent d'optimiser l'encodeur pour un film ou un anime, d'optimiser l'encodage pour obtenir les valeurs les plus hautes possibles de PSNR et de SSIM ! Voici un petit exemple de ce que cela peut donner sur une scène du film Inception, nous avons calculé les valeurs moyennes de PSNR et SSIM avec quatre optimisations différentes de x264 (aucune, Film, PSNR, SSIM). Notez pour la suite que les valeurs de PSNR s'expriment en dB (plus il est élevé et meilleur est le ratio signal/bruit), tandis que le SSIM est une valeur entre 0 et 1 qui indique la corrélation par rapport à la source, 1 indiquant une correlation parfaite.
Tenter d'optimiser pour un algorithme ne marche pas toujours en fonction de la scène. La scène choisie ici est remplie d'explosions et l'optimisation PSNR obtient les plus bas scores. La version optimisée SSIM semble donc la meilleure, elle obtient les deux meilleurs scores en SSIM et en PSNR. Vrai en image ? Voyons ce que cela donne sur une image fixe tirée de chaque vidéo :
[ No Tune ] [ Film ] [ PSNR ] [ SSIM ]
Passez la souris/cliquez sur les liens pour faire apparaitre l'image correspondante. Inception, Warner Bros
Commençons par le plus évident, sur la version PSNR, peu de choses vont. Des parties entières du visage sont floues et le dégradé sur la droite est empli de blocs. La version SSIM est elle supérieure à la version Film ? Non. Les sourcils sont plus nets sur la version Film, et le visage conserve plus de détails. Pourquoi alors un score plus bas alors que la version SSIM est légèrement plus floue ? A cause d'un dernier paramètre qui rend encore plus complexe les comparaisons PSNR et SSIM, les optimisations psycho visuelles qui tentent de conserver un maximum de détails dans les zones intéressantes. Une optimisation qui se distingue sur une image fixe mais qui se reconnait nettement une fois les images animées : la vidéo conserve tout simplement plus de détails, et ce qui peut ressembler à des artefacts sur une image fixe (pour PSNR et SSIM) apportent un bond en avant en matière de qualité, au détriment de notes plus basses.
Pour toutes ces raisons, si nous donnerons par la suite des résultats SSIM/PSNR de divers encodeurs, ces valeurs ne peuvent être considérées comme absolues !
Page 6 - Nombre de passes, GOP dynamique
En plus des spécificités du format que nous avons vus plus avant, les encodeurs peuvent être configurés avec certaines options particulières. Voici quelques explications sur leur rôle.
Une ou deux passes ? Lorsque l'on souhaite compresser une vidéo, on a généralement pour limite une taille de fichier donné que l'on ne souhaite pas dépasser, par exemple pour de contraintes liées au stockage (faire tenir la vidéo, ou n vidéos sur un DVD, ou un maximum de vidéos sur un smartphone, etc).
La méthode usuelle est de spécifier un bitrate – une quantité moyenne de données à utiliser pour une seconde d'encodage – à l'encodeur pour le guider. Les logiciels de transcodage gèrent d'ailleurs généralement la problématique à l'envers, on leur indique la taille du fichier désiré et ils calculent le bitrate à utiliser. Le bitrate sert cependant uniquement de guide et de limite à ne pas dépasser. L'encodeur va devoir choisir de lui-même les endroits ou il peut économiser, ou à l'inverse dépenser un peu plus de son « budget ».
Le problème de cette approche est qu'un encodeur ne sait pas de quoi est faite votre vidéo. Toutes les scènes qui la composent ont-elles la même complexité ? La fin de la vidéo est elle plus compressible que le début ? Difficile de le savoir sans être allé voir. C'est justement pour cela que, lorsque l'on souhaite obtenir un bon niveau de qualité, on utilise deux passes. Comme son nom l'indique, l'encodeur passe deux fois sur la vidéo et peut ainsi mieux gérer son bitrate.
Nous avons compressé deux vidéos avec des options de qualité identiques en utilisant une et deux passes pour illustrer le phénomène. Toutes les 100 images (environ 4 secondes), nous avons calculé le bitrate moyen par image qui apparait ci-dessous.
Maintenez la souris sur le graphique pour comparer l'évolution de la qualité.
Comme vous pouvez le voir en vert, en une seule passe l'encodeur est conservateur et se contraint sur toute la longueur de la vidéo à ne monter ni trop haut, ni ne descendre trop bas. En rouge, l'encodeur en deux passes à choisi de dépenser plus au début de la vidéo et moins à la fin. Si vous passez la souris sur le graphique, vous pouvez comprendre pourquoi en regardant la qualité visuelle que l'on compare ici par le SSIM. Les dernières minutes de notre vidéo sont plus fortement compressibles et atteignent un niveau de similarité avec la source très haut, plus haut que pour tout le reste de la vidéo. En utilisant une seconde passe, vous pouvez voir que la qualité reste bien plus constante tout le long de la vidéo, et c'est justement ce que l'on recherche : les sauts de qualités rendent inconfortable la visualisation de la vidéo.
Alors que le concept d'utiliser deux passes est communément admis depuis des années, les encodeurs GPU que nous avons testés se contentent tous d'une seule. C'est particulièrement dommage car implémenter une seconde passe serait un moyen très simple pour eux d'améliorer significativement la qualité.
GOP dynamique Nous l'avons vu, les encodeurs ont à leur disposition trois types d'images (I Frame, B Frame, P Frame) qu'ils peuvent utilise comme bon leur semble. Un bon encodeur va ainsi placer une keyframe (I Frame) lors d'un changement de scène par exemple. Et que font les mauvais encodeurs ? Ils utilisent une structure d'image (ce que l'on appelle GOP, Group Of Pictures)… fixe ! Rien de tel que de placer une I Frame toutes les 29 images. Exemple pratique de deux encodeurs :
Encodeur 1 : IPPPPPPPPPPPPPPPPPPPPPPPPPPPPIPPPPPPPPP
Encodeur 2 : IPPPPPPPPBBBPBBBPBBBPBBBPBBBPBBBPPPPPPI
Au rang des mauvaises idées, utiliser des GOP statiques se classe parmi les plus mauvaises. Avec des conséquences sur la qualité désastreuses !
Si l'on regarde l'évolution d'une de nos métriques de qualité, on peut déjà deviner les défauts visuels que l'on verra apparaitre :
Premier problème de cette structure en paquet de 29, la qualité saute. Chaque I Frame remet les choses en place tandis que par la suite, à chaque P Frame qui se succède, la qualité baisse ! Mais regardez ce qui se passe à l'image 48. Ici, nous avons droit à un changement de scène. L'encodeur dynamique insère une keyframe pour compenser et ramener à un bon niveau de qualité. L'encodeur statique, lui, attendra son cycle et tentera de se rattraper au fur et à mesure sur chaque P Frame qui remonte légèrement la qualité jusqu'à ce que les choses redeviennent normales à la prochaine I Frame !
En image, la différence de netteté saute littéralement aux yeux :
Maintenez la souris sur l'image pour voir l'I-Frame suivante.
Avatar, Fox Pathé Europa
Maintenant que nous avons passé en revue les écueils potentiels, passons aux tests que nous avons réalisés.
Page 7 - Scènes de tests, configuration
Scènes de tests Nous avons utilisé des fichiers vidéos extraits de trois Blu-ray. Nous avons retenus :
Avatar à l'avantage de mélanger scènes filmées et précalculées. Développé à l'origine pour être vu en 3D, les plans de caméras évitent les mouvements brusques ce que les encodeurs apprécieront. La scène mesure 9 minutes et 20 secondes.
Avatar, Fox Pathé Europa
La scène d'Inception est elle quasi épileptique. Les plans de caméras sont fixes mais remplis d'explosions. De multiples challenges intéressants pour les encodeurs sont dans cette scène. Autre challenge pour les logiciels, Inception est un Blu-ray encodé en VC1 ;
Inception, Warner Bros
Pour K-On!! nous avons encodé le premier épisode du disque. Les animes utilisent de grands aplats de couleurs qui proposent des problèmes très différent de ce que proposent les films classiques.
K-On!!, Kyoto Animation, Pony Canyon
Nous avons utilisé ces fichiers bruts, sans recompression pour nos tests d'encodage en 1080p. Pour les logiciels autres que x264, nous avons tenté de regler la qualité au maximum de ce qu'il était possible, nous reviendrons pour chaque encodeur sur ses possibilités, qui varient souvent grandement. Le bitrate choisi pour cette compression est élevé, 10 Mb/s (4.5 Go/heure), soit un peu supérieur à celui de la TNT HD (environ 7/8 Mb/s). Un bitrate élevé facilite la tâche en matière de compression. On reste cependant assez loin d'un Blu-ray puisque pour nos fichiers tests, les bitrates étaient respectivement de 24.2, 25.8 et 35.4 Mb/s. Ce scénario correspond à un ré encodage pour une console.
Nous avons également voulu tester un second scénario d'encodage avec une résolution plus faible de 720p. Afin de ne désavantager personne, nous avons réduit et recompressé nos sources 1080p au préalable afin d'obtenir de nouveaux fichiers sources en 720p. L'opération à été faite via x264 en mode slowest avec un bitrate de 25 Mb/s. Chaque logiciel peut en effet utiliser des méthodes de redimensionnement d'image très différentes qui auraient empêché toute comparaison d'images à une source. En supprimant la partie redimensionnement (qui est de toute façon négligeable en temps par rapport à l'encodage) et en partant d'une source de très haute qualité, nous réduisons au maximum les faux écarts qui pourraient exister.
Notez enfin que nous avons désactivé toutes les éventuelles options qui tentent de retoucher les couleurs pour rendre les vidéos pour vives (augmentation de la saturation, etc), que ce soit dans les logiciels et, dans le cas ou l'on décode l'image source par le GPU, dans les panneaux de contrôle des GPU. En plus d'être inutiles, elles auraient désavantagé les encodeurs dans les tests SSIM et PSNR.
Configuration de test
Nous avons utilisé la configuration suivante :
- Intel Core i7 2600K
- MSI H67MA-E45 (1155)
- 4 Go DDR3 1333 MHz Crucial
- Windows 7 64 bits
En sus, nous avons utilisé trois cartes graphiques AMD et Nvidia (équivalentes deux à deux en termes de prix) pour voir si les modèles plus puissants apportaient un bond en avant en matière de qualité, ou une réduction du temps d'encodage :
- Radeon HD 5750
- Radeon HD 6850
- Radeon HD 6970
- GeForce GTS 450
- GeForce GTX 460
- GeForce GTX 570
Pour la solution QuickSync d'Intel, nous avons testé le HD 3000 intégré au 2600K.
Un dernier mot sur la présentation des résultats. Afin de rendre les résultats lisibles, les graphiques des pages suivantes, ainsi que les comparaisons d'images nécéssitent l'utilisation d'un navigateur Web compatible HTML5. La grande majorité d'entre vous en utilisent déjà un, mais si ce n'est pas le cas, vous pouvez au choix installer un des navigateurs suivants :
- Mozilla Firefox 4
- Google Chrome 10
- Opera 11
- Apple Safari 5
- Microsoft Internet Explorer 9
Page 8 - ArcSoft Media Converter, Avatar 720p (1/4)
ArcSoft Media Converter, Avatar 720p (1/4) Développé par ArcSoft (auteurs du logiciel de lecture Blu-ray Total Media Theater), Media Converter 7 (en version 7.1.15.55, abrégé AMC dans nos graphiques) propose de transcoder au choix des sources sous la forme de fichiers vidéo ou de DVD. Le logiciel dispose de profils pour les consoles (Xbox, PS3, Wii, PSP), tablettes (iPad), Smartphones et autres périphériques dédiés à la lecture sur TV (Apple TV, WD TV, etc).
Nous avons crée manuellement deux profils pour les résolutions 720p et 1080p en maximisant les options de qualité. Le profil H.264 high n'est pas supporté, et Arcsoft semble disposer d'encodeurs custom pour les versions CUDA et Stream. La qualité est presque constante indépendamment du modèle de GeForce, avec un très léger avantage à la GeForce GTX 460. En pratique cette différence est sans intérêt, notez également que la GeForce GTX 570 (trop récente ?) n'était pas détectée par notre version de Media Converter. La qualité est strictement identique entre les différents modèles de Radeon.
Commençons par les résultats en 720p avec Avatar. Pour rappel, nos encodages 720p sont réalisés avec un débit vidéo demandé de 4 Mbit/s.
Avatar 720p 
Première surprise, utiliser une Radeon change drastiquement les options d'encodage. On repasse au profil Baseline et l'on perd B Frames et CABAC. On gagne par contre un GOP quasi dynamique dans le sens ou il utilisera une I Frame en cas de changement de scène. Les autres encodages gardent un fonctionnement plus radical, une I Frame toutes les 80 images, puis entre les deux, un groupe qui se répète : 1 P Frame suivie de 2 B Frames. Si l'on compare entre eux les scores des encodeurs d'Arcsoft, la version processeur termine significativement devant en SSIM. Le MediaSDK d'Intel semble optimisé pour le PSNR (et donc optimisé pour les benchmarks et non la qualité visuelle). Le score de la version CUDA est extrêmement bas, ce qui mérite quelques explications.
Côté temps de calcul, la version processeur pure est diaboliquement rapide, tandis que la version Radeon, malgré un profil baseline est plus de deux fois plus lente. La Radeon HD 5750 est plus rapide que ses grandes soeurs, sans raison valable.
Les valeurs moyennes de SSIM (ou de PSNR) ne veulent cependant pas dire grand-chose. A l'image de la vie en couple, c'est dans la gestion des moments difficiles que l'on peut juger de la qualité d'un encodeur. Pour pouvoir mettre un peu mieux en avant ces cas difficiles, nous avons isolés deux séries de 500 images distinctes, issues de notre extrait.
Cliquez ici pour voir le graphique PSNR de cette scène.
Notez que pour ce graphique ainsi que pour tout ceux qui suivent, nous avons du opter pour une échelle dynamique en fonction du contenu. Afin de vous aider a mieux visualiser les écarts entre les différents graphiques, une ligne orange matérialise un SSIM de 0.9. Vous pouvez également agrandir le graphique en cliquant sur l'icône en haut à droite.
Notre premier extrait de 500 images (scène 1) peut se décomposer en trois parties. D'abord de l'image 0 à 157 environ, une première scène relativement fixe à lieu. Le personnage principal est filmé dans son pod et seule sa tête bouge. Une partie très facile à compresser, et tous les encodeurs s'en tirent bien. La scène se termine par un fondu au noir (ce qui nous vaut un plateau à 1, tous les encodeurs savent correctement encoder une image totalement noire !). Jusqu'à l'image 362, une nouvelle scène prend place, plus complexe puisque la caméra se déplace dans un travelling (lent) de gauche à droite en avançant légèrement. A 363, une nouvelle scène apparait, la aussi relativement lente.
Les Radeon utilisent l'encodage le moins techniquement avancé (profil baseline), mais disposent du GOP dynamique. Résultat, si la qualité de leur encodage est quasi systématiquement derrière, la présence du GOP dynamique permet aux Radeon de supplanter le HD 3000 lors d'un changement de scène. A l'inverse, les Geforce sont complètement perdues lors du changement de scène avec une dégradation de la qualité notable. Mais beaucoup plus grave, lorsque l'image change un peu trop (et il s'agit d'une scène lente…), l'encodeur Cuda d'Arcsoft perd ses pédales entre deux I Frames (les pics vers le haut toutes les 80 images) avec une qualité qui se dégrade fortement. Pas de miracle, ces sauts de qualité sont très visibles. Afin de voir ce que cela donne en pratique, nous avons isolés une image identique pour chacun des encodages, environ une demie seconde après le changement de scène. Les images utilisées pour notre comparateur ci-dessous sont stockées au format PNG pour éviter toute déformation. Leur chargement peut prendre quelques secondes selon la vitesse de votre connexion :
 Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Si comme nous l'évoquions, l'encodage CUDA GTX 460 garde un très léger avantage sur la conservation des textures par rapport à la version GTS 450, en pratique les deux encodages sont inutilisables tant les artefacts sont présents. L'encodeur CUDA d'Arcsoft n'est tout simplement pas au niveau. La netteté départage ensuite nos autres encodeurs. La version HD 3000 reste en deçà d'un point de vue visuel, tandis que les versions AMD et encodage processeurs sont assez proches, l'encodeur d'AMD parait même légèrement supérieur lorsque l'on regarde de près les textures de peaux. En pratique ces deux images restent malheureusement un gros cran derrière l'image source avec une perte de détails importante.
Notre seconde scène comporte plusieurs déplacements assez rapide, utilisant massivement le flou de mouvement (motion blur) ce qui facilite la tâche des encodeurs. Qu'est ce que cela donne en pratique ?
Cliquez ici pour voir le graphique PSNR de cette scène.
Les encodeurs d'Arcsoft aiment le flou et se complaisent dans le motion blur. La version CUDA ne mérite pas que l'on parle d'elle, mais nos trois autres encodeurs sont au coude à coude. Les nuances infimes de SSIM sont cependant visibles, jugez plutôt sur la seconde image que nous avons extrait d'un motion blur :
 Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Si l'on prend en compte uniquement les visages, l'encodeur version AMD s'en tire plutôt bien en conservant le maximum de netteté sur eux. A l'inverse les encodeurs version CPU et version HD 3000 affichent des artefacts dans les dégradés entre les zones sombres et claires sur les visages (partie gauche du front de Jake, à droite de l'écran). Voyons si ces prestations se confirment dans des scènes un peu plus complexes !
Page 9 - ArcSoft Media Converter, Inception/K-On!! 720p (2/4)
ArcSoft Media Converter, Inception 720p Passons au film Inception, toujours en 720p ou nous avons choisi un extrait court, seulement 40 secondes mais qui comporte des scènes d'explosions particulièrement intéréssantes.
Quand l'on regarde les SSIM obtenues sur la longeur totale de la scène, l'encodeur processeur d'Arcsoft semble s'éloigner un peu plus nettement des versions Radeon/HD 3000 qui gardent une note similaire. Etant donnée la durée limitée de l'extrait, nous n'indiquerons pas les temps d'encodage.
Nous avons extrait une scène de 500 images. Durant les 400 premières, les plans d'explosions s'alternent avec des plans sur les personnages (51, 192, 352) avant que la scène se termine sur une scène beaucoup plus calme.
Cliquez ici pour voir le graphique PSNR de cette scène.
L'avantage de l'encodeur CUDA d'Arcsoft est qu'il permet très facilement de détecter les changements de scène : à chaque pic de qualité vers le bas, un changement de scène prend place ! L'encodeur Radeon est significativement en dessous de l'encodeur Intel sur les scènes d'explosions tandis que celui d'Intel est derrière sur les scènes fixes. Regardons en image comment cela se matérialise, d'abord avec une image d'explosion :
 Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
On omettra de parler de la qualité de la version CUDA pour regarder la version Radeon. Si dans les scènes peu agitées d'Avatar l'encodeur AMD avait tenu la corde, il est ici loin derrière. Et il n'y a pas vraiment de miracle, le profil baseline est significativement moins efficace que les autres en matière de compression ! Si la version CPU d'Arcsoft préserve le plus de détails, le résultat est très loin d'être glorieux.
Quid de la fin de la séquence ou la scène devient plus fixe ?
 Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Sur le fond de la scène, tous les encodeurs perdent le grain. L'encodeur Intel est le moins précis sur le visage avec la joue et le contour de l'œil particulièrement flou, c'est assez peu pardonnable sachant que c'est là que notre regard se trouve attiré en premier lieu.
Terminons avec notre dernière séquence de test en 720p.
K-On!! 720p Nous avons encodé un épisode entier (24 minutes 11 secondes) de cet anime dont l'image est relativement fixe. A 4 Mbit/sec, cela ne devrait pas être un challenge pour nos encodeurs.
Première surprise, l'encodeur Intel d'Arcsoft ne fonctionne pas ici, plantant le logiciel. Seconde surprise, l'encodeur CUDA d'Arcsoft annonce un score, certes derrière les Radeon, mais qui laisse penser que le résultat n'est pas la bouillie de pixels habituelle !
Côté temps de calcul, la version CPU continue à être extrêmement rapide, même si elle se fait devancer par les encodeurs CUDA d'Arcsoft.
Cliquez ici pour voir le graphique PSNR de cette scène.
La version GeForce peine toujours sur les changements de scènes mais le résultat semble encore tout à fait excellent. Qu'est ce que cela donne en pratique ?
 Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Ce n'est pas une erreur, la version GeForce est bel et bien celle qui conserve le plus de détails ! Tout le grain de la scène disparait en effet avec la version CPU et Radeon de l'encodage. Sachant que cette image reste fixe plusieurs secondes, c'est bel et bien un choix délibéré de la part de ces deux encodeurs que de flouter la scène, ce qui est assez regrettable ! Une tendance que nous avions déjà noté auparavant et qui montre aussi, une fois de plus, les limites de mesures comme SSIM et PSNR !
 Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Sur une scène avec moins de textures et plus d'aplats de couleurs, les différences sont minimes, on notera tout juste quelques petits artefacts assez légers. Rien de très disqualifiant.
Voyons maintenant si le passage au 1080p et à un bitrate plus elevé change les choses pour le logiciel d'Arcsoft.
Page 10 - ArcSoft Media Converter, Avatar 1080p (3/4)
ArcSoft Media Converter, Avatar 1080p Nous utilisons ici les mêmes scènes que précédemment, les sources étant les fichiers vidéo des Blu-ray.
La moyenne de SSIM de la version processeur de l'encodeur d'Arcsoft est excessivement basse. En cause, le fait que pour les encodages 1080p, cet encodeur utilise… un framerate variable ! Alors que notre source utilise un framerate constant à 23.976 images/secondes, l'encodeur d'Arcsoft crée des variations en fonction de la complexité de la scène. Et si souvent on parle de quelques millisecondes, ici les écarts sont forts (via MediaInfo) :
Original frame rate : 23.976 fps
Minimum frame rate : 8.108 fps
Maximum frame rate : 29.132 fps
Résultat, au bout d'environ 1500 images, l'encodeur applique un nombre d'images par seconde quasiment divisé par quatre sur une scène qu'il estime lente et fixe. Et les comparaisons SSIM/PSNR deviennent impossibles !
L'utilisation du VFR est une technique valable, car présente dans la specification H.264. Cependant elle est généralement réservée à des usages bien précis comme le streaming ou les caméras de surveillances. Pour encoder des films, cela ne fait pas à nos yeux sens tant la lecture de fichiers VFR peut poser problème avec certains logiciels/périphériques, encore moins en 1080p ou l'on destine le fichier à la lecture sur un téléviseur. Les encodages CUDA/Stream/Media SDK n'ont pas ce problème et utilisent un nombre d'images par seconde constant.
Côté temps d'encodage, MediaConverter semble buter sur la piste audio qui est encodée en parrallèle à la piste vidéo. Le temps est anormalement long.
Regardons tout de même l'évolution du SSIM durant les 500 premières images de la scène :
Cliquez ici pour voir le graphique PSNR de cette scène.
Durant les 500 premières images, le frame rate ne change pas pour l'encodeur CPU d'Arcsoft. Il est ici sérieusement tallonné par l'encodeur HD 3000 d'Intel. Qu'est ce que cela donne en images ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Malgré un score moyen plus haut, le résultat de la version MediaSDK n'est pas très bon, les visages et les textures de peau étant significativement moins nettes comparativement aux versions CPU et Radeon.
Cliquez ici pour voir le graphique PSNR de cette scène.
Sur cette seconde scène, la version CPU s'est déjà décalée de 7 images. De quoi rendre toutes les comparaisons fausses et les scores obtenus sur la version CPU inutiles. Pour les autres encodeurs, les résultats des versions MediaSDK et Stream semblent très bon, avec un petit avantage à MediaSDK. Vérifions sur les images :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Encore assez ironiquement, la version Radeon des encodages est de meilleure facture dans la conservation des détails, on peut le voir facilement en regardant la grille au milieu de l'écran, complètement floutée sur les autres encodages.
Page 11 - ArcSoft Media Converter, Inception/K-On!! 1080p (4/4)
ArcSoft Media Converter, Inception 1080p 
Si l'encodeur d'Arcsoft utilise encore le mode de frame rate variable, en pratique c'est comme s'il n'existait pas (via MediaInfo) :
Original frame rate : 23.976 fps
Minimum frame rate : 23.976 fps
Maximum frame rate : 23.976 fps
Voyons sur notre scène de test les prestations des différents encodeurs intégrés à ArcSoft Media Converter :
Cliquez ici pour voir le graphique PSNR de cette scène.
La version processeur semble devant que ce soit sur les scènes d'explosions ou les scènes calmes. Vérifiable en pratique ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Même si son résultat est loin d'être parfait, l'encodeur CPU propose ce qui se fait de mieux dans le lot pour la conservation des détails. La version Radeon est littéralement larguée, le profil baseline à ses limites !
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Sur des images plus fixes, on note encore une fois que l'encodage MediaSDK d'Intel perd en netteté sur le visage, c'est particulièrement visible sur le front. La texture du fond à droite perd son grain et gagne des artefacts. L'encodage Radeon est comparativement de meilleur qualité, assez proche de l'encodage CPU.
K-On !! 1080p 
L'encodage CPU d'Arcsoft utilise une fois de plus un frame rate variable (via MediaInfo) :
Frame rate mode : Variable
Frame rate : 23.976 fps
Minimum frame rate : 7.992 fps
Maximum frame rate : 47.952 fps
Il manque au final 11 images par rapport à la vidéo originale ce qui rend les scores invalides pour cet encodeur. Voyons tout de même les résultats sur la scène que nous avons isolée :
Cliquez ici pour voir le graphique PSNR de cette scène.
Les scores sont relativement elevés, mais comme nous l'avions vus en pratique sur la version 720p, cela ne veut pas dire grand-chose. Le résultat sera-t-il une fois de plus flou pour nos encodeurs ?
Côté temps d'encodage, la variabilité est énorme d'une carte à l'autre, et cette fois ci la Radeon HD est 6970 est la plus rapide.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Il y a un peu de mieux ! Une fois de plus l'encodeur CUDA d'Arcsoft a trouvé sa niche sur cette scène ou il conserve le plus de grain. L'encodeur Stream des Radeon fait dans le flou artistique tandis que les versions CPU et MediaSDK se sont légèrement améliorées, sans être parfaites.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
On comprend un peu mieux les scores un peu plus faibles de l'encodeur CUDA en regardant attentivement les lignes. Celle en haut de notre point d'intérêt disparait légèrement, ce qui vaut la différence. De petits artefacts résistent sur les aplats de couleurs, même si l'on se contenterait allègrement d'un tel résultat dans tous nos tests !
Page 12 - Cyberlink MediaEspresso, Avatar 720p (1/4)
Cyberlink MediaEspresso, Avatar 720p (1/4)
Proposé par l'éditeur de PowerDVD, Cyberlink MediaEspresso (en version 6.5.1229, abrégé CME dans nos graphiques) surfe également sur la vague du transcodage de vidéo. L'application dispose d'une interface assez amusante et animée. On retrouve en haut de l'écran l'accès à des preset établis pour les smartphones, lecteurs multimedia, consoles de jeu ou sites Internet.
Nous avons pour nos tests crées deux profils pour le 720p et le 1080p en maximisant toutes les options de qualité disponibles. Au rang des très bonnes nouvelles, l'application de Cyberlink permet d'activer l'accélération GPU au choix pour les phases de décodage, d'encodage, ou pour les deux (voir notre explication page 2).
Avatar 720p 
Les bonnes nouvelles s'arrêtent assez vite lorsque l'on regarde les caractéristiques des encodages réalisés. D'abord, seul le profil baseline est géré. Ce qui ne devrait pas aider du côté de la qualité, nous l'avons vu avec le logiciel d'Arcsoft, le profil baseline est fortement désavantagé à bitrate égal dans les scènes d'action. Ensuite il y a des bitrates surprenants. Les encodeurs CUDA et MediaSDK de Cyberlink utilisent ainsi un bitrate constant, soit exactement 4Mb pour chaque seconde. Une telle stratégie ne va pas aller dans le sens de la qualité (souvenez vous de l'intérêt des deux passes !). Ensuite, le mode « Quick » disponible lorsque l'on utilise un HD 3000 (matérialisé par un Q dans nos graphiques ci-dessous) pour l'encodage réduit le bitrate sans rien nous demander. Le GOP, enfin, est statique, et au rang des performances, c'est l'encodeur processeur une fois de plus qui est devant tous les autres ! Pour terminer, les Radeon plantent systématiquement lorsque l'on tente d'encoder avec eux notre scène via une accélération GPU. Un problème que nous avons reproduits avec l'encodeur AVIVO d'AMD qui est ici utilisé.
Côté temps d'encodages, on notera que le décodage par la carte graphique accélère les encodeurs CPU, mais ralentit les encodeurs GPU ! Les versions encode sont plus rapides que les versions Full…
Vérifions tout cela en pratique dans notre première scène d'Avatar.
Cliquez ici pour voir le graphique PSNR de cette scène.
Comme vous pouvez le voir, l'échelle de notre graphique est fortement rétrécie ! En cause, les encodeurs d'Intel en version Full qui font des pointes complètement anormales vers le bas. Traitons leur cas de suite, la raison de ces chutes est assez simple à comprendre :
On peut espérer qu'il s'agisse d'un bug, d'autant que ces artefacts n'apparaissent ni dans la version décodage pur, ni dans la version encodage pur du HD3000 ! Si vous cliquez sur ces deux encodages dans nos graphiques, l'échelle redevient normale. Comme on pouvait s'y attendre, si l'on active uniquement la partie décodage de l'accélération GPU, tous les encodeurs ont des performances globalement identiques, avec tout de même une infime variation sur les modèles GeForce par rapport au reste. Les trois encodeurs (CPU, CUDA encode, MediaSDK encode) souffrent du GOP dynamique lors du changement de scène vers l'image 363. Vérifions tout cela en images :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Nous sommes ici dans le royaume du flou, particulièrement sur l'encodeur HD 3000 lorsque l'on regarde les détails de la peau, la végétation ou tout simplement les visages. Dix images après un changement de scène, l'absence de GOP dynamique et de détection de nouvelles scènes crée des sauts de qualité insoutenables pour les yeux. La version CUDA de l'encodeur de Cyberlink n'a pas l'aspect bouillie de celui d'Arcsoft, c'est un plus !
Passons à notre seconde scène remplie de flou de mouvement.
Cliquez ici pour voir le graphique PSNR de cette scène.
Pas de pic anormal de performances vers le bas, les résultats semblent plutôt homogènes même si l'encodeur CUDA est un petit cran derrière. Vérifions en images :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Les résultats sont assez faibles en matière de netteté (et donc de conservation de détails) dans chacun des cas. On notera des artefacts au dessus de la grille particulièrement présents sur les versions GeForce/HD 3000. Voyons comment les choses évoluent dans des scènes détaillées.
Page 13 - Cyberlink MediaEspresso, Inception/K-On!! 720p (2/4)
Cyberlink MediaEspresso, Inception 720p Passons au film Inception, toujours en 720p ou nous avons choisi un extrait court, seulement 40 secondes mais qui comporte des scènes d'explosions particulièrement intéressantes.
Bonne surprise, cette fois-ci l'encodeur d'AMD n'a pas planté et nous allons pouvoir juger sa qualité. Si l'on regarde les moyennes sur la totalité de l'extrait, le classement semble être : encodeur CPU, encodeur HD 3000, encodeur Radeon, encodeur GeForce.
Voyons comment se sortent nos encodeurs des multiples changements de scènes présents dans notre extrait :
Cliquez ici pour voir le graphique PSNR de cette scène.
Parlons des pics des encodages « Full » du HD 3000, là encore pas de surprise puisque le même bug qu'Avatar touche notre scène :
Pour le reste, ce sont les morceaux d'explosion de la scène (elle alterne entre plans sur les personnages et explosions massives) qui sont à la peine particulièerment entre les images 250/350. Quel impact en image ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
On est littéralement dans le mauvais quel que soit la version. L'encodeur Radeon est particulièrement flou et perd toutes les textures, assez notablement sur la table en rotin à gauche. L'encodeur Nvidia rajoute des tâches noires sur la carte rouge tout à gauche mais conserve un peu plus de textures sur la table en rotin. Voyons sur une scène un peu plus fixe si ces encodeurs peuvent se rattraper :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
L'encodeur CUDA est un cran au dessus sur cette image avec une meilleure conservation des détails sur le visage par rapport aux autres. Le grain à droite est de toute façon systématiquement perdu.
K-On!! 720p Terminons par notre anime, théoriquement le cas le plus facile pour nos encodeurs.
L'encodeur Radeon plante, une fois de plus, lors de cet encodage.
Le décodage GPU ralentit l'encodage GPU, une fois de plus.
Cliquez ici pour voir le graphique PSNR de cette scène.
Prenons les problèmes au cas par cas. D'abord les HD 3000 continuent leur amour pour les carrés noirs :
Ensuite, l'encodage CUDA utilise un framerate variable qui décale les comparaisons d'images et les rends inutiles (via MediaInfo) :
Original frame rate : 23.976 fps
Minimum frame rate : 0.237 fps
Maximum frame rate : 23.981 fps
L'encodeur Radeon ne fonctionne pas, mais le décodeur ne fonctionne pas vraiment non plus puisque l'on à droit à ce type d'artefacts (plus prononcés ironiquement sur la 6970 !) :
Cela fait beaucoup, mais ce n'est pas tout. Systématiquement les fondus au noir présentent des dégradations violentes, quelque soit le modèle d'encodeur utilisé :
[ Source ] [ CPU ] [ CUDA ] [ Stream ]
Passez la souris/cliquez sur les liens pour faire apparaitre l'image correspondante.
Voyons tout de même en image les résultats…
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Vous pouvez voir en action les artefacts de la Radeon HD 6970 sur cette scène. Nous ne commenterons pas plus loin les résultats.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Regardez simplement les résultats obtenus suite aux « décodages » Radeon. MediaEspresso n'aime pas les anime.
Page 14 - Cyberlink MediaEspresso, Avatar 1080p (3/4)
Cyberlink MediaEspresso, Avatar 1080p Le 1080p améliorera t'il les choses pour le logiciel de Cyberlink ? Pour rappel, nous utilisons un bitrate de 10 Mbit/s sur les extraits suivants !
Même problème ici qu'en 720p pour les encodeurs GeForce et MediaSDK, le bitrate est constant lorsque l'on les utilise. L'encodeur Radeon fonctionne, et les scores de SSIM laissent penser qu'un décalage apparait.
Pour être précis les décalages sont de +3 images en mode CPU, decode, et HD 3000 encode et +1 image en mode Radeon Encode/full.
Notez que pour une fois, le décodage GPU ne ralentit pas l'encodage. Nous vous donnons des liens vers nos graphiques afin d'être complets mais les décalages d'images rendent leurs résultats farfelus :
Cliquez ici pour voir le graphique SSIM de cette scène.
Cliquez ici pour voir le graphique PSNR de cette scène.
Pour les comparaisons visuelles d'images nous avons compensé manuellement les décalages, voyons plutôt ce que cela donne !
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Les résultats sont plutôt flous au global. L'encodeur version CPU propose la meilleure netteté.
Si vous souhaitez voir les graphiques de notre scène de Motion blur malgré les décalages, cliquez ici pour le SSIM et ici pour le PSNR . Regardons plutôt le résultat en images :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
La version HD 3000 peine significativement, mais toutes les versions obtiennent un résultat mesuré. L'encodage CPU pur reste devant.
Page 15 - Cyberlink MediaEspresso, Inception/K-On!! 1080p(4/4)
Cyberlink MediaEspresso, Inception 1080p Le Blu-ray d'Inception est encodé en VC1. MediaEspresso refuse d'ouvrir les fichiers .m2ts utilisant ce codec vidéo.
K-On !! 1080p 
Domination écrasante des GeForce en version encodage sous K-On !!, vérifiable en pratique ?
Le décodage GPU ralentit de nouveau les encodages GPU…
Cliquez ici pour voir le graphique PSNR de cette scène.
Notre ami le framerate variable vient une fois de plus faire rater nos comparaisons objectives. Pour illustrer l'impact du décalage d'images, nous n'avons pas exceptionnellement compensé les différences afin de vous montrer ce que notre logiciel de comparaison d'images à relevé :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Ici les différences dues au décalage sont minimes, seules quelques fleurs qui voltigent diffèrent.
Les encodeurs GeForce et CPU sont au coude à coude sur la conservation des détails, la version Radeon fait dans le flou et la version MediaSDK a troqué son amour pour les carrés noirs par un amour pour les carrés blancs !
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Ici les résultats sont quasiment identiques. Mais peu importe car les problèmes dans les fondus que nous avions relevés en 720p sont toujours présents, les encodages sont tous inutilisables.
Résumé En ne proposant que des encodages H.264 à profil « baseline », MediaEspresso partait déjà avec un désavantage sur les logiciels concurrents. Le fait qu'il utilise des bitrates constants et des framerates variables n'aide pas non plus, tant l'inverse (frame rate constant et bitrate variable !) est conseillé lorsque l'on veut faire autre chose que du streaming de vidéo. L'absence de GOP dynamique fini de terminer le tableau en proposant des sauts de qualité incessants lors d'un changement de scène comme nous l'avions illustré précédemment, sans nommer l'encodeur responsable :
Maintenez la souris sur l'image pour voir l'I-Frame suivante.
Cyberlink MediaEspresso mode CPU, Avatar, Fox Pathé Europa
Cyberlink pourrait cependant corriger facilement la majorité de ces problèmes en configurant différemment ses encodeurs. Peut être pour une prochaine version !
Page 16 - MediaCoder, Avatar 720p (1/4)
MediaCoder, Avatar 720p (1/4)
Proposé par un développeur indépendant, MediaCoder est une sorte de trousse à outils ultime en matière de transcodage vidéo. En un package son auteur intègre une multitude d'autres logiciels d'encodages, comme entre autre les encodeurs officiels Nvidia (CUDA) et Intel (MediaSDK). En pratique MediaCoder est livré avec OpenCandy (adware) et le logiciel ouvre, à chaque démarrage, votre navigateur vers une page web remplie de pubs (en lançant le logiciel minimisé dans le systray !). Pour compléter le tout, MediaCoder est listé dans le hall of shame de ffmpeg pour violations de la licence GPL.
Pas vraiment un logiciel recommandable sur le papier mais nous nous sommes tout de même intéressés à lui car il semblait proposer deux avantages : un décodage processeur multithreadé et la possibilité de configurer les encodeurs Nvidia/Intel assez finement.
Avatar 720p 
MediaCoder permet en théorie d'activer un mode GOP dynamique pour l'encodeur GeForce ainsi que le choix entre les trois principaux profils H.264 (baseline, main, high). Le CABAC et les B-Frames sont gérées, mais le GOP dynamique est inexistant. Les résultats SSIM/PSNR sont très bas, et pour une fois le framerate variable n'est pas en cause.
La version que nous avons utilisée de MediaCoder tend a manger un nombre plus ou moins grand d'images au début de la scène. Dans le cas d'Avatar, il manque 6 images au début sur les encodages Nvidia et 4 sur les encodages Intel pour Avatar.
Côté temps d'encodage, MediaCoder est imbattable grace a l'utlisation d'un décodeur CPU multithreadé en parrallèle aux encodages GPU.
Cliquez ici pour voir le graphique PSNR de cette scène.
Les décalages d'images rendent les graphiques inutiles, passons plutôt aux comparaisons visuelles :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Les résultats ne sont pas forcément mauvais lorsque l'on compare les options d'encodages les plus élevées. Le gros des textures disparait dans les deux cas mais l'encodeur Intel persiste à être plus flou sur les visages que le reste des encodeurs testés. Sachant que cette tendance se reproduit dans trois logiciels différents, il semble que ce soit un défaut de la version utilisée du MediaSDK d'Intel.
Cliquez ici pour voir le graphique PSNR de cette scène.
Le second graphique n'a pas beaucoup plus d'intérêt à cause des décalages, regardons les images résultantes en cas de motion blur :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Sur cette scène l'encodeur Intel garde un petit avantage sur le personnage de gauche.
Page 17 - MediaCoder, Inception/K-On!! 720p (2/4)
MediaCoder, Inception 720p 
Une fois de plus notre décalage de 6 images sur la version GeForce et 4 sur la version HD 3000 reste présent.
Cliquez ici pour voir le graphique PSNR de cette scène.
Passons sur les graphiques pour comparer les images :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
En comparant les modes GeForce baseline et high, on voit rapidement ce que pourrait gagner Cyberlink à mieux configurer ses encodeurs ! L'encodeur Intel est un peu plus flou, et s'en sort mieux sur les textures complexes comme la table à gauche. A l'inverse la version GeForce tend à garder plus de détails et crée des artefacts.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Sur notre scène fixe, la différence de netteté entre les modes baseline et high dans les deux cas est elevée, prouvant une fois de plus l'intérêt d'utiliser le plus haut profil possible. L'encodeur GeForce reste un tout petit peu plus net.
K-On!! 720p 
Les décalages sont ici plus minces, seulement 1 et 2 images d'où des scores plus elevés.
MediaCoder continue à être le plus rapide des encodeurs de notre panel.
Cliquez ici pour voir le graphique PSNR de cette scène.
Il est très facile de visualiser chaque changement de scène ou chaque mouvement en regardant les pics ! Passons aux beaucoup plus utiles comparaisons d'images :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
L'encodeur CUDA aime cette scène indépendamment du logiciel utilisé, le résultat est ici propre dès le mode baseline, le mode high est très bon. La version HD 3000 est en retrait.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Les différences sont ici très minimes et on continue à voir de légers artefacts dans les applats de couleurs. Notez que les problèmes dans les fondus au noir que nous avions vus sous MediaEspresso persistent ici… mais uniquement dans les profils base :
[ Source ] [ CUDA base ] [ CUDA high ] [ MediaSDK base ] [ MediaSDK high ]
Passez la souris/cliquez sur les liens pour faire apparaitre l'image correspondante.
Page 18 - MediaCoder, Avatar 1080p (3/4)
MediaCoder, Avatar 1080p Les encodages 1080p sont réalisés avec un bitrate de 10 Mbit/s.
Bonne nouvelle, si utiliser un fichier MKV en source provoquait un décalage en 720p, utiliser un fichier m2ts en source donne un résultat correct et sans décalage ! Ouf…
Confirmation de ce que nous vous disions plus tôt, en utilisant en parallèle un décodeur processeur et un encodeur GPU, MediaCoder est extrêmement rapide.
Cliquez ici pour voir le graphique PSNR de cette scène.
De manière intriguante la qualité de l'encodeur Intel en mode base est légèrement supérieure sur le travelling que le mode high. Les résultats restent cependant très homogènes tout au long de l'extrait. Voyons en pratique la qualité après un changement de scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Sans GOP dynamique, la perte de netteté est très significative sur l'encodeur Intel, un peu moins sur l'encodeur CUDA qui sort une prestation très honnête en mode high.
Cliquez ici pour voir le graphique PSNR de cette scène.
Sur notre seconde scène les niveaux de qualité semblent une fois de plus extrêmement proches avec un avantage à l'encodeur Intel. Et en image ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Intriguant, d'abord la présence d'un carré vert sur le visage est immanquable pour les encodages Nvidia. Ils sont significativement plus nets sur le personnage de gauche, mais les dégradés sur le pod sur la partie milieu/haute tendent à laisser apparaitre eux aussi des carrés. La version Intel est plus floue, mais ne souffre pas de ces problèmes.
Page 19 - MediaCoder, Inception/K-On!! 1080p(4/4)
MediaCoder, Inception 1080p 
MediaCoder redéfinit la notion de décalage puisqu'il manque… 24 images en début de scène ! Une seconde pleine, rien que cela…
Cliquez ici pour voir le graphique PSNR de cette scène.
Les graphiques sont ici inutiles avec une seconde de décalage, on ne peut rien apprendre. Passons aux comparaisons visuelles :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
L'avantage sur la conservation des textures de l'encodeur Intel est ici particulièrement visible sur la table en rotin. A l'inverse la version Nvidia crée des nuances de couleurs qui n'existent pas dans la source et qui se traduisent en artefacts visuels animés lorsque les images se succèdent.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Si l'on oublie le grain de la scène à droite, le résultat de l'encodeur Nvidia est, une fois de plus, plus net sur le visage que son comparse Intel.
K-On !! 1080p Alors, décalage d'image ou pas ? Le suspens est intense !
Et non, cette fois-ci, nos images sont correctement alignées.
Le ralentissement du décodage GPU persiste ici ! Passons aux résultats :
Cliquez ici pour voir le graphique PSNR de cette scène.
La qualité tout le long de la scène est relativement homogène, seuls les modes baseline peinent un peu lors du fade in/fade out.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Dès que l'on sort des modes base, afficher une image fixe pendant plusieurs secondes ne pose de problème à aucun encodeur.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Sur cette seconde image les problèmes restent très réduits.
Résumé Globalement les résultats obtenus avec MediaCoder sont bons, la possibilité d'utiliser le profil H.264 high pousse un peu en avant la qualité, particulièrement pour la version CUDA de l'encodeur qui était bridée chez Arcsoft par une implémentation ratée et chez Cyberlink par un profil baseline. Malgré tout, si les résultats sont bons, il s'agit d'un avis a relativiser : ils sont bons pour des encodages GPU. Les problèmes d'images manquantes, l'abus de publicités et le côté peu convivial de l'interface sont cependant de gros moins, même si le logiciel est gratuit.
Page 20 - StaxRip/x264, Avatar 720p (1/4)
StaxRip/x264, Avatar 720p (1/4) Comme nous l'évoquions plus tôt, nous avons souhaité comparer les performances des encodeurs H.264 accélérés GPU avec ce qui existe côté processeur. Si un grand nombre de logiciels commerciaux existent, une implémentation Open Source de H.264 existe sous le nom de x264. Projet démarré par certains auteurs de VLC, x264 est une implémentation libre de H.264 comme XviD l'était en son temps pour le Mpeg 4 part 2. x264 est généralement considéré comme ce qui se fait de mieux en matière de qualité, au détriment bien sur de la rapidité d'encodage.
En soit x264 ne s'occupe que de l'encodage d'images brutes vers le format H.264. Afin de pouvoir effectuer un transcodage, il faut utiliser un frontend qui inclut les autres morceaux nécéssaires (décodeurs, encodeurs audio, etc). Nous avons retenu StaxRip , là encore un logiciel Open Source. Même s'il est un peu plus complexe de prise en main que les logiciels d'Arcsoft ou de Cyberlink, son interface reste abordable. Il a l'avantage de donner un grand contrôle au niveau de la configuration de x264, ce qui fait que nous l'avons préféré à d'autres outils comme Handbrake que l'on recommandera à ceux qui trouvent StaxRip trop austère.
Côté versions, nous avons utilisés la version 1.1.7.0 de StaxRip, à laquelle nous avons rajouté la dernière build en date au début de nos tests de x264, la r1913 .
Contrairement aux autres logiciels, x264 permet littéralement de configurer tous les paramètres d'un encodage. Pratique, même si, parfois, cela peut être un peu… intimidant :
cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=4029 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Histoire de simplifier un peu la tâche, les auteurs ont ajouté des « presets », des séries de reglages qui offrent des niveaux successivement plus élevés de qualité. Par exemple, dans le cas de notre encodage ci-dessus, il s'agit simplement du mode veryslow. 10 modes sont disponibles, allant de ultrafast à placebo, un mode affreusement lent dont les gains sont difficilement visibles par rapport à la version veryslow, d'où son nom.
Nous avons testés les neufs modes (tous sauf placebo) à la fois en mode deux passes (le mode classique et recommandé), mais aussi en mode une passe pour garder un lien avec nos autres encodeurs. Il est temps de passer aux résultats !
Avatar 720p 
Le mode ultrafast en tune film implique un profil H.264 baseline.
Comme vous le voyez sur les temps de calculs, l'ajout d'une seconde passe ne double pas réellement le temps d'encodage. Par défaut la première passe réalisée est rapide, nous avons extrait les temps de calcul de chaque passe à titre informatif :
Le mode 2p faster s'execute en temps réel sur notre Core i7.
Cliquez ici pour voir le graphique PSNR de cette scène.
Comme vous pouvez le voir le preset ultrafast détonne de tous les autres. Pas vraiment de surprise, ce dernier est le seul à utiliser le profil baseline. x264 est en effet configuré pour le résultat le plus rapide possible, en clair pour faire la course avec les encodeurs GPU. En pratique on évitera ce mode dont les résultats visuels sont pour le moins affreux comme on le verra. Notez que tous les autres modes utilisent un profil high (avec CABAC, B-Frames, GOP dynamique, etc).
Si vous comparez un même preset en version une passe et deux passes (abrégé 2p), on note de suite la meilleure uniformité en matière de qualité. Comment tout cela se traduit il en image ? Réponse !
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Si le mode ultrafast fait réellement mal aux yeux, le niveau de qualité monte rapidement. Dès le mode faster la qualité est au dessus de ce que l'on a vu de mieux précédemment. Mais de manière beaucoup plus intéréssante, la qualité des modes deux passes est significativement plus elevée, le mode 2p veryfast faisant déjà significativement mieux.
Voyons maintenant ce qui se passe dans un motion blur :
Cliquez ici pour voir le graphique PSNR de cette scène.
On rappellera tout de même que les modes d'encodages de x264 ne sont pas optimisés pour les mesures SSIM, mais pour la qualité visuelle de par leurs optimisations psychovisuelles. Malgré tout dès le mode veryfast (1 passe) la qualité est au dessus de tout ce que l'on a vu plus tôt. Et en image ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Dès le mode superfast, la préservation visuelle est plus elevée, nottamement lorsque l'on regarde la grille au milieu. Les modes 2p rajoutent significativement en netteté, une fois de plus.
Page 21 - StaxRip/x264, Inception/K-On!! 720p (2/4)
StaxRip/x264, Inception 720p 
Passons au morceau de choix, nos scènes d'explosions !
Cliquez ici pour voir le graphique PSNR de cette scène.
Là encore il est particulièrement intéressant de comparer les scènes sur les visages des personnages des scènes d'explosions. En mode une passe, on voit très nettement celles ou le resultat visuel est un peu en dessous. Alors qu'en mode deux passes, l'encodeur a reconnu la difficulté de la scène et affecté une allocation de bitrate supérieure pour ces scènes. Et visuellement, la différence est notable :
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Regardez l'aisance avec laquelle un mode comme le 2p veryfast arrive à surclasser l'encodage 1p veryslow, pourtant 3.6x plus lent ! La qualité des modes 2 passes à partir de veryfast est quasi parfaite !
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Les résultats en mode 1 passe ne sont pas excellents. Notez que même le mode 2 passes veryslow ne conserve pas le grain original de notre scène sur la droite, le bitrate ne le permet tout simplement pas.
K-On!! 720p 
Pour K-On!!, nous avons selectionné le mode « anime » proposé par x264.
Le mode 2p faster est encodé en temps réel sur notre processeur.
Cliquez ici pour voir le graphique PSNR de cette scène.
Les scores sont ici très hauts, même pour le mode ultrafast. L'avantage des deux passes semble moins net ici, en tout cas sur cette séquence. Et en images ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Dès le mode superfast la qualité est déjà excessivement proche de la source ! Le mode ultrafast est plus net que la majorité des encodages baseline GPU.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Le mode ultrafast rajoute un artefact dans l'applat bleu isolé sur l'écran. Les autres modes sont visuellement parfaits.
Page 22 - StaxRip/x264, Avatar 1080p (3/4)
StaxRip/x264, Avatar 1080p Passons au 1080p et à un bitrate de 10 Mbit/s.
Un œil aguerri notera que les modes ultrafast et superfast sont plus rapides ici en 1080p qu'en 720p ! Notre fichier source 720p disposait d'un bitrate absurdement elevé (pour la quantité de pixels) et l'encodage était ralenti… par le décodage. Le décodeur de StaxRip n'est en effet pas multithreadé.
Cliquez ici pour voir le graphique PSNR de cette scène.
Une fois de plus la supériorité des modes 2p est évidente sur le graphique, mais quid en image ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Il faut regarder de près pour voir la quantité de détails et le grain dans la peau. La supériorité des modes 2 passes, y compris le 2p veryfast est nette.
Cliquez ici pour voir le graphique PSNR de cette scène.
Sur la scène de motion blur les résultats sont excessivement proches d'un preset à l'autre. Et en image ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Dès le mode superfast les choses se passent particulièrement bien avec une préservation des détails très bonne.
Page 23 - StaxRip/x264, Inception/K-On!! 1080p(4/4)
StaxRip/x264, Inception 1080p 
Passons de suite à notre scène la plus complexe.
Cliquez ici pour voir le graphique PSNR de cette scène.
Une fois de plus la différence d'uniformité dans la qualité d'une scène à l'autre détonne entre les modes 1 passes et 2 passes. Est-ce aussi net en images ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Le mode 2p veryfast propose déjà un niveau de qualité excellent, et largement au dessus de tous les modes une passe.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Une fois de plus l'ajout de la seconde passe reste l'élément le plus important pour maximiser la qualité sur cette scène.
K-On !! 1080p 
Les temps d'encodages sont particulièrement longs ici, 1p faster s'exécute en temps réel.
Cliquez ici pour voir le graphique PSNR de cette scène.
Les scores sont une fois de plus excessivement élevés avec tous les modes. Le mode 1p superfast suffira t'il ici ?
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Dès le mode superfast 1p la qualité est excellente
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Tous les modes font un bon travail ici.
Résumé Le couple StaxRip/x264 n'est pas parfait. L'ajout d'un décodeur multithreadé améliorerait probablement la rapidité des modes d'encodages les plus lents par exemple. Mais à part pour faire une course à la médiocrité, cela n'aurait au final qu'assez peu d'intérêt. Quand on souhaite obtenir de la qualité, x264 répond présent. Et si l'on prend le temps d'ajouter une seconde passe, il surclasse littéralement toute la concurrence, y compris lorsque l'on compare un mode deux passes « rapide » tel le veryfast avec les modes une passe les plus lents.
Page 24 - Récapitulatif 720p
Récapitulatif 720p Si vous souhaitez comparer nos encodeurs les uns par rapport aux autres, nous avons regroupé leurs résultats dans les graphiques suivants.
Avatar 720p
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Inception 720p
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.K-On !! 720
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Page 25 - Récapitulatif 1080p
Récapitulatif 1080p Si vous souhaitez comparer nos encodeurs les uns par rapport aux autres, nous avons regroupé leurs résultats dans les graphiques suivants.
Avatar 1080p
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Inception 1080p
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.K-On !! 1080
Cliquez ici pour voir le graphique PSNR de cette scène.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Cliquez-ici pour afficher le comparateur d'images dans un nouvel onglet.
Page 26 - Récapitulatif temps/consomation
Récapitulatif temps/consommation A titre de rappel, voici les temps de transcodage pour chacun des encodeurs testés dans notre dossier :
Pour rappel, le temps d'encodage des encodeurs d'Arcsoft est particulièrement lent sur cette scène, probablement nous l'estimons à cause du transcodage de la piste audio qui semble poser problème au logiciel. Sur la rapidité pure, les encodages HD 3000 sont plutôt bien placés, tout comme ceux de Nvidia via MediaCoder. x264 peut être rapide, mais sa qualité en mode ultrafast n'est pas utilisable à notre gout.
Maintenez la souris sur le graphique pour voir la consommation en watts.
Nous avons calculé la consommation réelle de chaque encodage en multipliant le temps par la consommation instantanée. Le résultat est plutôt intéressant et nous appelle à quelques remarques :
- Si vous regardez les consommations instantanées, vous verrez que les cartes graphiques Nvidia ont la consommation instantanée la plus forte. Ce n'est pas une surprise, puisque les cartes du constructeur passent aux fréquences 3D lors d'un encodage (à quoi bon ?).
- Les solutions d'encodage HD 3000 sont de loin les plus efficaces et trustent la majorité des premières places. Le mode superfast de x264 n'est lui pas trop mal placé. Le mode veryfast 2 passes reste à nos yeux le meilleur compromis entre qualité, temps d'encodage et consommation électrique.
Page 27 - Conclusion
Conclusion Difficile de conclure simplement tant de tests en quelques lignes, mais pourtant une constatation s'impose : l'accélération du transcodage H.264 par les GPU n'est pas au niveau d'encodages réalisés côté processeurs.
Ce que ces solutions apportent avant tout, c'est bien souvent de la frustration. Que ce soit Nvidia, AMD ou Intel, les trois constructeurs ont misés via les encodeurs qu'ils proposent sur la rapidité au détriment de la qualité. Il est tout de même dérangeant de voir systématiquement, dans des logiciels comme MediaConverter d'Arcsoft ou MediaEspresso de Cyberlink, leurs encodeurs processeurs proposer un meilleur résultat sur le plan de la qualité que les encodeurs GPU intégrés !
Il est également extrêmement ennuyeux de constater, dans le cas des encodages GeForce et Radeon, qu'il n'y a pas de différence de rapidité entre des cartes graphiques à 100, 170 ou 330 euros. La qualité est strictement identique d'une carte à l'autre - sauf dans le cas des bugs - et les temps d'encodages ne changent pas. En aucun cas la puissance réelle en matière de GPGPU de nos cartes graphiques n'est saturée, ou pleinement utilisée.
L'utilisation des cartes graphiques se fait en prime toujours avec une aide du processeur. Lorsque l'on utilise pourtant décodages et encodages GPU, par exemple avec l'application de Cyberlink, un cœur est utilisé à 100% avec les Radeon ou le HD 3000 d'Intel, et deux avec les GeForce. Dans le cas du logiciel d'Arcsoft, on peut monter à quatre cœurs utilisés à 100%.
Autre particularité importante, les décodages assurés côté GPU sont souvent un frein aux performances des encodeurs GPU. Là encore, pas de miracle : le décodage H.264 ne se fait pas par les unités de calcul du GPU, mais par un ASIC dédié qui sert au décodage des vidéos comme les Blu-ray. Décodages qui n'ont pas besoin d'une rapidité extrême puisque la lecture d'un média se fait en temps réel. MediaCoder, malgré ses autres défauts, prouve que pour tirer la quintessence de rapidité des encodeurs GPU (sans pour autant que cela ne crée de variations entre nos cartes de différentes gammes de prix…), il est nécessaire d'utiliser un décodeur côté processeur multithreadé.
Des trois solutions utilisant le GPU pour le transcodage, il est délicat de trouver à en recommander une. Le logiciel d'Arcsoft propose l'encodeur qui, hors x264, obtient les meilleures notes tout en étant extrêmement rapide. Ses résultats sont globalement flous mais, pour des périphériques mobiles ils peuvent être considérés comme suffisants si vous n'êtes pas trop regardants. Des résultats obtenus uniquement par l'encodeur processeur de Media Converter, sa version CUDA étant littéralement cauchemardesque, sa version Radeon limitée (comme les autres) à un profil baseline qui, bien que de bonne facture, ne peux pas rivaliser avec les profils H.264 plus élevés. Et en ce qui concerne la version Intel/MediaSDK, si les scores obtenus dans nos mesures sont souvent élevés, les résultats visuels ne suivent pas avec des résultats particulièrement flous dans les zones importantes de l'image (visages, etc).
Le logiciel de Cyberlink, de son côté, se disqualifie en ne proposant que des encodages de type H.264 baseline qui ne suivent pas dans les scènes d'actions. Les multiples bugs de l'implémentation de Cyberlink de MediaSDK n'arrangent rien (carrés blancs et carrés noirs rendent les encodages inutilisables), et l'incapacité des encodeurs à insérer une I-frame lorsqu'une nouvelle scène commence crée des effets de clignotements désagréables en vidéo. La qualité des rendus Nvidia et AMD est correcte, ce qui est un progrès par rapport au logiciel d'Arcsoft pour les GeForce. Mais en pratique, l'utilisation de profils H.264 baseline reste un handicap dont il est impossible de se relever.
MediaCoder de son côté est le plus rapide, le plus configurable et le plus efficace des logiciels d'encodage GPU. Mais si l'on peut passer sur ses publicités, le fait qu'il produise des fichiers où il manque des images est tout de même ennuyeux. Il est au moins gratuit. D'un point de vue qualitatif, là encore l'encodeur Nvidia prend le dessus sur celui d'Intel qui tend un peu trop à flouter les résultats.
Le couple StaxRip/x264 gagne assez facilement sur la qualité. A nombre de passes égales, les modes faster/fast font généralement aussi bien, voir mieux que tout le reste des encodeurs présents. Mais si vous ne devez retenir qu'une seule chose de notre article, c'est bel et bien que le moyen le plus simple d'augmenter la qualité… est tout simplement d'ajouter une seconde passe aux encodages. Il est d'autant plus rageant que Nvidia, AMD et Intel pourraient simplement proposer dans leurs kits de développement cette seconde passe qui fait tant de miracles pour homogénéiser la qualité sur toute la longueur de la vidéo.
Bien entendu, cette qualité supérieure se paye par un temps d'encodage plus élevé, équivalent à du temps réel en 1080p (une heure d'encodage environ pour une heure de film pour le mode 2p veryfast sous Avatar par exemple). Descendre en qualité est possible, certains trouveront que les modes 1p faster proposent un compromis plus intéressant en divisant quasiment par deux le temps d'encodage, mais en dessous la qualité pâtit rapidement.
Si l'on tente de résumer ce qu'AMD, Nvidia et Intel proposent via ces logiciels tiers, on se doit d'effectuer quelques remarques. D'abord, l'encodeur proposé par AMD est tout sauf stable. A de maintes reprises il aura planté les logiciels qui l'utilisent, un comportement que nous avons pu produire en lançant manuellement l'interface de transcodage d'AMD (on peut y accéder par le panneau de contrôle CCC). En se limitant au profil baseline, là encore, AMD n'a aucune chance sur le plan de la qualité. C'est particulièrement dommage tant, malgré cela, la qualité est souvent de bonne facture sur les scènes fixes. Une implémentation d'un profil H.264 high pourrait être intéressante.
Nvidia propose de son côté possiblement le SDK le plus avancé et dont les résultats sont souvent les meilleurs quand il s'agit d'accélération GPU. Meilleurs, mais la qualité visuelle reste maigre, au point que les solutions purement processeurs sont souvent capables de produire un rapport qualité/temps d'encodage équivalent. Si l'on rajoute la consommation de la carte graphique, le résultat reste décevant.
L'offre d'Intel est la plus surprenante. L'encodage vidéo est géré par des unités rajoutées au GPU qui semblent accélérer une grande partie du décodage. Avec une utilisation processeur très basse, la consommation est de loin la plus faible. Au rang des problèmes, pour pouvoir en profiter il faut bien entendu disposer d'une carte mère H67 ou d'une future Z68, ce qui réduit déjà significativement les utilisateurs potentiels. Mais même si vous réunissez toutes les conditions, la qualité visuelle des encodages laisse trop franchement à désirer pour pouvoir être réellement utilisables.
Au final, les promesses marketings de transcodage GPGPU sont dommageables. Les constructeurs mettent en avant la rapidité de leurs solutions pour répondre à un problème réel : le temps, trop long pour beaucoup, nécessaire à l'encodage de vidéos par le processeur. En apportant pour seule réponse un temps d'encodage rapide, avec une qualité qui laisse significativement à désirer, le transcodage H.264 via GPGPU reste en 2011 une mauvaise réponse à un vrai problème.
Copyright © 1997-2024 HardWare.fr. Tous droits réservés.
|
