Utiliser l’IEEE ou le MMX ?
Récemment, le guide Tom’s Hardware (lien en français) publiait un test des tous nouveaux Pentium4 d’Intel. Il effectuait aussi un test utilisant FlaskMpeg et ses résultats étaient que le P4 performait particulièrement mieux que les CPU d’AMD. Quelque temps après ce test, il présentait une mise à jout à propos de ces résultats. Un lecteur suggérait alors d’utiliser le IEEE-1180 iDCT (Inverse Discrete Cosine Transform) au lieu de l’option par défaut du iDCT MMX. Tom a alors testé à nouveau mais ses résultats furent complètements différents. En raison de la supériorité des FPU (Floating Point Unit) des Athlons, les puces Intel obtenaient de bien mauvais résultats. En effet, les P4 plus rapides de 300MHz n’avaient aucune chance face à tous les Athlons du test.
Immédiatement après la parution de cet article, des rumeurs circulaient dans la communauté du ripping. Des personnes se demandaient si elles n’avaient pas eu tort d’utiliser le iDCT MMX à chaque utilisation, comme suggéré par tous les guides Flask Mpeg que je connais. Évidemment, ceci était une bonne raison d’effectuer mes propres tests dont voici les résultats.
Détails du test
Contrairement à Tom, je vais vous fournir l’ensemble des détails de mes tests pour que vous puissiez vérifiez mes résultats.
J’utilise la verson R1 de Matrix. J’ai rippé les chapitres 28 à 30 en fichiers individuels à l’aide de SmartRipper. Le chapitre 28 est l’interrogatoire de Morpheus dans l’immeuble de la police et renferme beaucoup de bruit dans les murs gris et est manifestement une scène avec peu de mouvement (low-motion). Le chapitre 29 est la bataille dans le lobby et est probablement la scène la plus connue de tout le film. Bien sûr cette scène implique beaucoup d’action et pousse le codec à ses limites. Le chapitre 30 inclut le combat sur le toit et l’explosion dans l’ascenseur – la scène la plus difficile de tout le film.
J’ai effectué les 3 tests avec les paramètres suivants :
Tous les tests ont été réalisés à l’aide de FlaskMpeg 0.594, avec le plugin AVI output 0.591 et le codec DivX 3.11alpha low-motion. La précision d’image (crispness) est à 100. L’algorithme de redimensionnement utilisé dans FlaskMpeg est le HQ bicubic et il n’y a pas de traitement audio. J’ai effectué chaque test à deux reprises, un avec l’iDCT MMX et l’autre avec l’IEEE-1180 comme référence.
Les résultats
Tout d’abord, vérifions le fichier readme de FlaskMpeg. Il indique :
“Les informations video dans les fichiers MPEG sont conservées dans le domaine fréquentiel au lieu du domaine spatial (l’image que nous voyons). De cette manière, l’image est compressée et cette compression peut être utilisée pour réduire le nombre d’informations à envoyer à travers le canal de transmission. MPEG utilise le DCT (Discrete Cosine Transform) pour traduire les informations spatiales en information fréquentielle. Pour retrouver le domaine spatial depuis un fichier MPEG vous devez appliquer l’iDCT, soit l’Inverse Discrete Cosine Transform qui inverse le DCT réalisé pendant l’encodage.
Même si le MPEG est défini (à partir d’un fichier source la sortie devrait être identique pour tous les décodeurs), le standard permet un certain degré de liberté dans le choix de l’iDCT à utiliser. De cette manière, le décodeur peut être plus aisément installé dépendant du matériel sur lequel il est utilisé. Ce que le standard exige du décodeur est que l’iDCT réponde aux normes IEEE-1180, ou en termes simples, que les erreurs dues au iDCT ne soient pas plus nombreuses que celles montrées par l’IEEE-1180.
Dans l’immédiat, FlaskMpeg possède les trois algorithmes pour effectuer l’iDCT et ils sont tous les trois conformes à l’IEEE-1180. Un basé sur le MMX, un autre basé sur les nombres entiers et un dernier utilisant les nombres à virgule flottante (floating point). Même s’ils sont tous trois conformes IEEE, celui à virgule flottante est le plus précis mais requiert les plus de cycles CPU. L’iDCT au nombres entiers devrait être suffisant pour la plupart d’entre vous sans MMX et l’iDCT MMX devrait être l’option par défaut pour tous.”
En d’autres termes : les 3 algorithmes sont conformes à l’IEEE-1180 et Flasky lui-même suggère l’iDCT MMX.
Donc tout va bien jusqu’à maintenant.
La différence de rapidité est notable : dans l’extrait à 1800kbit/s, FlaskMpeg a encodé à 6.82fps (frame per seconde, trame par seconde) sur mon P3-550 alors que le même extrait encodé selon l’iDCT de référence tombait à 2.08fps. La différence de qualité justifie t’elle le temps d’encodage supplémentaire ?
Donc lequel est lequel ? C’est la grande question. J’ai décidé de ne pas vous gâcher le plaisir. Si vous laissez votre curseur reposer sur l’image vous verrez un petit texte vous donnant la réponse. J’ai rajouté ci-dessous des images élargies de la surface dans le rectangle rouge.
Il est très difficile de dire lequel est lequel n’est ce pas ? Je dois ajouter que l’image source avait beaucoup de bruit au niveau du mur… c’est la raison pour laquelle il y a tellement de macro-blocs. Même en utilisant des débits d’encodage élevés, des blocs apparaissaient. C’est la manière selon laquelle le DivX compresse les images. J’ai aussi testé TMPG en mode deux passes et il a recréé le bruit au lieu de présenter des blocs. Je vous laisse donc décider lequel est le meilleur et passons aux prochaines captures d’écran.
Est-ce que ces images ne proviendraient pas de la même source ? Je vous assure que non. Un de ces fichiers a nécessité trois fois plus de temps que l’autre pour être encodé.
Regardons la scène de l’explosion quelques secondes plus tard :
Et la version agrandie :
Et pour être perfectionniste, une autre série de captures d’écran :
Conclusions
Vous devez donc vous demandez à ce point : que voulait donc dire tout cela ? Et bien… il est nécessaire d’expliquer mon point.
J’ai regardé ces extraits vidéo quelques fois et je n’ai pas réussi à y voir des différences marquées. Bien sûr je visionnais ces extraits sans aucun son et avec les sources de lumières de la pièce éteintes pour obtenir la meilleure impression de film. J’ai aussi étiré les films en format plein écran (1152x864) pour pouvoir y noter les erreurs plus aisément. De par mes tests précédents et mes conseils dans le choix du débit vous savez sûrement qu’en ce qui concerne la qualité, je ne fais aucun compromis. Dans le cas présent, j’ai vraiment essayé d’y voir des différences mais sans succès.
Comme vous pouvez le voir dans les captures d’écrans les différences entre l’iDCT MMX et l’IEEE-1180 de référence ne sont pas décelables. Ni dans l’extrait avec un débit de 1500Kbit/s d’où proviennent les captures d’écrans, ni dans les débits plus bas ou plus élevés.
Dans le guide de Tom’s hardware, il était écrit :
“Par contre, ceci a tendance à créer beaucoup d’artefacts dans le video MPEG-4 final parce que toutes les valeurs de pixel de l’image décodée sont des approximations. Ainsi lorsqu’une seconde transformation DCT est appliqué pour le convertir en MPEG-4, celle-ci va approximer à nouveau les résultats et produire des artefacts plutôt horribles dans certains cas.
Utiliser le décodage IEEE élimine la plupart des artefacts et produit une sortie qui rivalise avec la majorité des DVD avec un débit égal à 20% de l’original (1.5Mbps pour un DVD de 7.5Mbps tel Matrix) ”
C’est exactement ce que j’ai fait.. J’ai encodé Matrix à 1500Kbps. Et malgré cela : IL N’Y A PAS DE DIFFERENCE ! Désolé Toby mais tu as tort… Ma vue est toujours très bonne et vous pouvez croire que je peux observer des erreurs d’encodage là ou d’autres n’y verront rien. Mais dans le cas de ce test, la référence de l’algorithme IEEE n’a pas présenté d’avantage observable à la suite d’un encodage trois fois plus long.
En résumé : Vous pouvez dormir tranquille en sachant que vous n’aurez pas à ré-encoder tous vos DVD et que vous n’aurez pas non plus à acheter un Athlon 1.2GHz uniquement pour encoder vos DivX à une pauvre vitesse de 6fps.
Ce que l’article du guide Tom’s Hardware indique est uniquement ceci : AMD a un FPU de bien plus supérieur à Intel. Peut-être que cela aura un impact sur l’encodage MPEG-2 mais cela reste sans impact sur l’encodage MPEG-4. Je pense que la qualité de référence de l’iDCT provient des standards de référence du groupe de simulation logiciel MPEG. Habituellement, ces standards sont bons en termes de qualité mais sont plutôt mauvais en ce qui a rapport à la rapidité. Si un lecteur logiciel de DVD utilisait l’iDCT de référence, vous verriez plutôt des diaporamas pour les 5 prochaines années..tous les algorithmes utiles d’iDCT ont été au moins optimisés MMX- mais ceci ne veut pas forcément dire que celui employé par FlaskMpeg est mieux… il en existe certainement des meilleurs.
Considérons aussi ceci : dans l’article d’origine à propos des DivX, Tom commettait certaines erreurs grossières. Blight (www.inmatrix.com) notait la plupart d’entre elles. Parmi celles-ci on trouvait comme suggestion d’utiliser le redimensionnement par voisinage (neihbor resizing) ce qui procure un encodage particulièrement mauvais. Ceci a été corrigé depuis mais ils indique encore que pour des petits fichiers vous devriez utiliser cette méthode de filtrage. Mais croyez moi, vous ne voulez pas l’utiliser du tout, elle est vraiment affreuse. Et je ne pense pas que n’importe lequel des algorithmes de référence IEEE puisse corriger ce que ce type de filtrage a détruit.
| Traduction le 29/09/02 par Librex | Last update : 
MM/DD/YY |
Dernière mise à jour : 
29/10/02
|