Le test des décodeurs mpeg2

[Emmanuel Piat]

Voici (enfin) le test que vous attendez tous.
La mire utilisée est fournie en attaché sur ce post.

La procédure totalement gratuite d'encodage et de création du DVD de test est décrite dans le 1er post de ce topic :

http://www.homecinema-fr.com/forum/view ... t=29739262

Nota :

- Si on met l'option "Mode d'affichage" de TMPGEnc sur "Non-entrelacé" on crée un DVD 480p ou 576p. Je ne sais pas s'il existe des DVD 576p dans le commerce. Par contre, il existe des DVD NTSC en 480p .

- Si on met l'option sur "Entrelacé", on crée des DVD 480i ou 576i. Dans ces DVD, l'info de chroma est toujours stockée de manière entrelacée dans 2 fields successifs. La différence alors entre les films (souce progressive) et les vidéo (source entrelacée) est que 2 fields successifs se rapportent au même instant temporel pour un film, mais pas pour une vidéo. Pour les films, le stockage entrelacé du chroma (chroma éclaté dans les 2 fields successifs) rend très délicat son réassemblage. Pour bien comprendre ce point et les tests qui vont suivre, je vous conseille de lire le post sur la mire d'évaluation du chroma que j'ai rédigé il y a qq temps. Il est sur cette page :

http://www.homecinema-fr.com/forum/view ... c&start=40

Le document de référence en anglais est ici :

http://www.hometheaterhifi.com/volume_8 ... -2001.html

[Emmanuel Piat]

Conditions de test :

- Encodage de la mire en 576i avec l'option "Mode d'affichage" de TMPGEnc sur "Entrelacé"

- CG : Radeon Sapphire 9600SE+catalyst 4.12

- Renderer : OVERLAY (mais c'est sans importance car on s'intéresse à ce qui se passe AVANT le renderer)

- Player : ZP v4.03

- Capture : fonction Grab de ffdshow du 1 fév. 2005 (l'ouput = YV12 ou YUY2 de ffdshow n'intervient pas sur les snapshots car cette conversion au format de sorti n'a lieu qu'après la capture)

EDIT du 6 juin 2006 :
La fonction Grab de ffshow réalise une mise à l'échelle YUV vers RGB[0:255] en mappant le noir normalisé Y=16 sur 0,0,0 et le blanc normalisé Y=235 sur 255,255,255. Autrement dit, cette fonction n'affiche PAS le blacker than black [0:15] et le whiter than white [236:255]


- décodeurs testés : Dscaler 0.0.5.0 - nvidia 4.0.67.0 - windvd 6.0.6.83

Chaque décodeur mpeg2 a été testé lorqu'il génère un flux YV12 et un flux YUY2 :

- pour windvd, la clé à configurer est YV12FIRST
- pour nvidia c'est preferYV12
- pour Dscaler c'est réglable ds les options du filtre.

Les snapshots sont donnés en attaché.

[Emmanuel Piat]

Valeurs obtenues pour RGB, CMJ et W,B :
==============================

Les carrés en haut à gauche permettent de tester l'échelle de décodage en luminance et chrominance. En plus du R,G,B on trouve :

- le blanc normalisé à 235,235,235
- le noir normalisé à 16,16,16

- le "blanc" pleine échelle à 255,255,255
- le "noir" pleine échelle à 0,0,0

Nota : les valeurs obtenues dépendent
- de l'encodeur mpeg2 utilisé au départ
- du décodeur mpeg2 testé
- de la précision de la conversion YCbCr -> RGB de la fonction Grab

EDIT du 6 juin 2006 :
l'encodeur utilisé prend l'image BMP[0-255] et la compresse dans l'espace [16-235] avant de l'encoder en flux mpeg2 YUV. Par conséquent le noir 0,0,0 sur la mire BMP se retrouve à 16 sur le mpeg2, le blanc 255 à 235, le noir normalisé à une valeur strictement supérieure à 16, etc.

Donc avec l'encodeur utilisé ici il est strictement IMPOSSIBLE de mettre des infos dans la zone [0-15] (blacker than black) et [236-255] (whiter than white)


- Décodeurs mpeg2 configurés pour sortir en YUY2 :

Windvd :
R=254,0,0 | G=1,254,0 | B=0,0,255 | C=0,254,255 | M=253,0,254 | J=253,254,0 | W=254,254,254 | B = 0,0,0
nvidia :
R=254,0,0 | G=0|1,254,0 | B=0,0,255 | C=0,254,255 | M=252|253,0|1,254 | J=253,254,0 | W=254,254,254 | B = 0,0,0
Dscaler :
R=254,0,0 | G=1,254,0 | B=0,0,255 | C=0,254,255 | M=253,0,254 | J=253,254,0 | W=254,254,254 | B = 0,0,0

Tous les décodeurs fournissent la pleine échelle 0-255 à ffdshow (avec les zones 0:15 et 236:255 totalement vide d'info sur cette mire encodée en mpeg2, cf. edit du 6 juin 2006),

Donc, il n'y a pas de blacker than black (0-15) et de Whiter than white (236-255) présent sur cette mire.

Après grab : le noir à Y=16 (initialement à 0,0,0 sur le BMP) se retrouve à 0,0,0.
etc.

Nota : Ne pas oublier qu'une fois les traitements de ffdshow terminés, les réglages du renderer "overlay" permettent de positionner le black (16) et le white (235) à la valeur qu'on veut. Par exemple, sur les ATI, avec ZoomPlayer, brightness=750 positionne le black Y=16 à 0 et contrast=10000 positionne "environ" le white Y=235 à 255 (quasi perte du BTB et du WTW).

Cette mise à l'échelle ainsi que la conversion YCbCr -> RGB pour les RAMDAC est faite avec une très grande précision de calcul (de mémoire, sur les ATI les calculs sont en 36 bits, soit 12 bits par canal, les DAC étant 10 bits).

- Décodeurs mpeg2 configurés pour sortir en YV12 :

Windvd :
R=253,0,0 | G=1,252,0 | B=0,0,254 | C=0,253,253 | M=252,0,253 | J=251,252,0 | W=252,252,252 | B=0,0,0
nvidia :
R=253,0,0 | G=0,252,0 | B=0,0,254 | C=0,253,253 | M=252,0,253 | J=251,252,0 | W=252,252,252 | B=0,0,0
Dscaler :
R=253,0,0 | G=0,252,0 | B=0,0,254 | C=0,253,253 | M=252,0,253 | J=251,252,0 | W=252,252,252 | B=0,0,0

Le blanc "recule" un peu et sa valeur n'est pas très cohérente avec celle de R,G,B. Difficile d'en tirer une conclusion, c'est peut-être la fonction grab qui est mal implémentée dans ce cas...

[Emmanuel Piat]

Règle ds le coin en haut à gauche :
=========================

Elle est juste là pour s'assurer qu'on est pas en désentrelacement bob (dans ce cas, il y a une perte de réso verticale qui "floute" la règle). Ici tous les décodeurs ont été forcés en weave (et tous choisissent bob si on les mets en mode "automatic"...).

Demi-cercle avec tâche noire :
======================

- Un coup de zoom permet de voir que le résultat est bien meilleur en YUY2 qu'en YV12.
L'upsampling du chroma de 4:2:0 à 4:2:2 par le décodeur permet de se rapprocher de la mire originale (qui a été convertie en 4:2:0 pdt l'encodage). L'arc de cercle rouge sur fond jaune est aussi mieux rendu en YUY2.

Diagonale du triangle :
=================

- Avec la plupart des décodeurs, la diagonale du triangle fait apparaître légèrement moins d'artefacts chromatiques en YUY2 qu'en YV12 (il faut zoomer pour s'en rendre compte).

Red chroma bug :
=============

Si on zoome sur le cercle et le triangle, aucun des décodeurs n'a le red chroma bug sauf Dscaler et windvd en YUY2. Ces players ne gèrent donc pas les trames dont la structure du chroma est entrelacée. Le red chroma bug est bcp plus prononcé sur Dscaler que windvd (effet de peigne produisant des lignes horizontales fantômes).


Lignes rouges horizontales :
====================

Via un zoom, ce test permet de visionner en détail tous les effets de "ghosting" dûs à la manière dont le décodeur décode l'info de chroma. On peut aussi regarder les traits R,G,B au centre de l'écran pour se faire une idée des dégats. Les pires résultats sont évidemment obtenus lorsque le décodeur ne tient pas compte de la structure entrelacée du chroma et suppose qu'elle est stockée en progressif, ce qui engendre le red chroma bug.

Si on visualise simultanément en zoomant dans PSP les 4 candidats qui n'ont pas le red chroma bug :

- Dscaler YV12
- Windvd YV12
- nvidia YV12
- nvidia YUY2

Les 3 premiers ne sont pas départageables à l'oeil. Seul nvidia YUY2 avec son upsampling de chroma en 4:2:2 a un rendu différent qu'on pourrait préférer.

Lorqu'on soustrait les images sous PSP des 3 premiers pour voir les écarts (via histogramme), les pixels sont tous identiques mise à part un nombre compris entre 100 et 200 (sur 720x576) dont la différence sur chaque canal RGB est inférieure à 2. Autant dire que ceux qui voient une différence ont un oeil bionique . On retrouve là tous les méfaits du subjectif qui fait dire n'importe quoi.

Nota : à cause de la structure entrelacée du chroma en 4:2:0, il est illusoire de penser comme je l'ai vu sur AVS qu'on peut compenser les artefacts de chroma en décalant l'info de chroma par rapport au luma (filtre Dscaler dans ffdshow) car selon la position du pixel, les artefacts de chroma n'apparaissent pas au même endroit. Par exemple, si dans la mire, je décale d'un pixel à droite, à gauche, en haut ou en bas les carrés R,G,B, les artefacts apparaitront sur d'autres bords... Le combat est donc perdu d'avance.

[Emmanuel Piat]

Conclusion :
=========

Pour les DVD pour lequels les films (source progressive) ont un chroma stocké dans une structure entrelacée (cas des DVD PAL), deux players sont à bannir :

- Dscaler YUY2
- Windvd YUY2

Dscaler YV12, Windvd YV12, nvidia YV12 ont des comportements identiques et le mieux sera de privilégier celui qui a l'occupation CPU la plus légère (je n'ai pas testé, mais je pense que c'est windvd).

nvidia YUY2 est le seul player YUY2 (ie upsampling du chroma en 4:2:2) qui décode et upsample correctement le chroma. Je le dis depuis sa sortie car c'est la première chose que j'ai testé... Reste à savoir si cela a un intérêt quelconque. Qd on voit la tâche noire dans le demi-cercle, j'aurait tendance à dire oui si on utilise pas de post-traitements. La réponse pourrait aussi être oui si on utilise uniquement le resize dans ffdshow (les autres filtres imposent de repasser en YV12) mais cette question reste ouverte (et difficile) ...

Je précise que ces résultats ne sont valables que dans les conditions de tests que j'ai cité. Je me suis amusé à lancer la mire dans windvd6, j'ai des résultats différents en 576i avec weave... (c'est encore plus mauvais...). Par contre, si on active le DNM sur la mire, tout s'arrange car le DNM doit correctement traiter l'info de chroma dans son algorithme...

[Emmanuel Piat]

Conditions de test :

- Encodage de la mire en 576p avec l'option "Mode d'affichage" de TMPGEnc sur "Non-entrelacé"

- reste identique.

Lorsque le chroma est stocké en progressif (cas de certains DVD NTSC qui sont des 480p), tous les players ont un comportement identique en YV12 et un comportements identique en YUY2 (cf. captures). A l'oeil, il est rigoureusement impossible de les départager et lorqu'on soustrait les images sous PSP, n'en déplaise à ceux qui ont un oeil bionique sur AVS, on a le même résultat que précédemment (le nombre de pixels différents est même encore plus faible lorsqu'on compare les mêmes couples de décodeurs).

Dans ce cas, on préviligiera à nouveau le décodeur qui charge le moins le CPU et là encore il faut trancher entre YV12 et YUY2. Sur les snapshots, le YV12 semble plus net du fait de la structure de chroma différente... Mais là encore, la question est ouverte et dépend sans doute de ce qu'on va mettre en aval du décodeur...

[Emmanuel Piat]

On peut ajouter que pour les DVD NTSC, pour le moment nvidia a une longueur d'avance grâce au inverse 3:2 pulldown (nvidia video post processor) qui permet de supprimer le judder inhérent aux DVD Z1 mal flaggés. Par exemple, sur I-robot Z1, si vous regardez le mouvement des ascenseurs en arrière plan à xx:xx:xx (j'ai oublié de prendre les valeurs ), ces derniers n'ont un mouvement parfaitement fluide que si on utilise le inverse 3:2 pulldown...

J'ai également fait qq snapshots pour voir comment le nvidia video post processor dégrade l'image.

Si le DVD est un 480i, la dégration est légère (le chroma "bave" un peu plus). Si le DVD est un 480p, la dégration est beaucoup plus marquée (un peu comme si on passait d'un DVD progressif à un DVD entrelacé). Donc si le DVD est correctement flaggé, je conseille d'enlever le post processor.

Voilà. J'espère que ces tests et leurs conclusions où toute subjectivité a été bannie vous auront plu.

[Bardamu voyage]

Bravo pour ce test détaillé et empreint de professionnalisme.

[Emmanuel Piat]

Merci

Tests à venir :
===========

- Test des algos de resize (via les lettre et les traits blancs et noirs au centre de la mire + tracé de courbes avec matlab).

- Voir comment influe le renderer VMR9. Comme je n'utilise pas le VMR9, si une bonne âme voulait le faire, ça m'arrangerait bien car je ne suis pas très motivé (BangoO sur cineson ?)

- voir comment influe le renderer OVERLAY, ce qui impose de pouvoir faire une capture de l'overlay. Est-ce que c'est maintenant possible sur ATI ? idem sur Nvidia ?

Tests auxquels il faut réfléchir :
======================

- test de la profondeur de couleur du renderer via l'ellipse en dégradé et la portion marron sur la mire.

- impact du choix de l'output YV12 ou YUY2 dans ffdshow. Si on est en VMR9, il sera facile de s'en rendre compte en faisant une capture de l'écran. Si on est en overlay, c'est plus délicat, car il faudrait pouvoir capturer la mire dans l'overlay...

[bunyete]

Très intéressant, merci!

N'aurait-il pas fallu appliquer un filtre passe-bas à la mire ?

Je pense notamment à l'impact que cela pourrait avoir sur les tests des algos de resize.

[Emmanuel Piat]

Au contraire, il faut impérativement laisser les hautes fréquences pour voir comment le resize les traite (il va les adoucir car tout resize est un filtre passe bas. Si on ajoute du sharpen, on va en plus booster le contraste au niveau de la transition => ça va faire une bosse positive et une négative. Ca se voit parfaitement à l'oeil nu sur la mire au niveau de la transition blanc-noir. Mais sans les courbes, s'est un peu difficile à expliquer...).

[bunyete]

Si j'ai bien compris, tu dis qu'il faut introduire des hautes fréquences dans la mire car beaucoup de gens introduisent des hautes fréquences avant le resize en appliquant un filtre sharpen (corrige-moi si j'ai mal compris).

Dans ce cas, je pense qu'il serait judicieux d'avoir 2 tests (car l'algo de base du resize repose quand même sur l'hypothèse que l'image d'origine provient d'un échantillonnage, donc est filtrée): un test pour les "puristes" qui ne font que du resize et n'introduisent pas de hautes fréquences avant le resize (par ex ceux qui font denoise + resize + sharpen du resize). Et un test pour ceux qui introduisent des HF (sharpen avant resize).

Par ailleurs, ne penses-tu pas que les HF introduites dans la mire ne sont pas représentatives des HF introduites par les sharpen?

[Emmanuel Piat]

>Si j'ai bien compris, tu dis qu'il faut introduire des hautes fréquences dans la mire car beaucoup de gens introduisent des hautes fréquences avant le resize en appliquant un filtre sharpen (corrige-moi si j'ai mal compris).


Non ce n'est pas vraiment ça. Qd tu testes la réponse d'un filtre, tu le fais toujours sur des signaux particuliers : impulsion, échelon. Ici je propose de le faire sur un échelon, c'est tout il ne faut pas chercher plus loin. Cela va permettre de voir comment une transition brutale est filtrée par le resize. Plus le resize sera bon, et plus la pente obtenue sera raide.

Concernant les hautes fréquences présentes dans un DVD, leur max dépend évidemment de l'échantillonnage spatial du DVD (théorème de shanon) et des filtrages ajoutés par les gars qui produisent le master numérique.

Généralement, il y a pas mal de filtrage vertical pour éviter les phénomènes de "flickering" des lignes horizontales si on visionne le DVD sur une TV 50Hz. Je ne connais pas les raisons du filtrage horizontal (réduction des artefacts temporels sur une TV ?). Quoi qu'il en soit, ces filtrages sont une véritable plaie pour nous car ils dégradent énormément le piqué de l'image lorsqu'on sort en progressif. Les 576 lignes du PAL sont des fois un voeux pieux et c'est encore pire en NTSC car les DVD Z1 NTSC sont généralement très filtrés et donc peu piqués (voir par exemple le seigneur des anneaux qui est une catastrophe en Z1).

Il y a néanmoins des exceptions. Les DVD NTSC de la sphère asiatique sont généralement très peu filtré (ils sont souvent meilleurs que nos PAL !). Les DVD PAL sont également beaucoup moins filtrés depuis environ un an (en tout cas, j'ai vu une évolution sensible chez pas mal d'éditeurs).

@+
Emmanuel

[bunyete]

Ok, merci pour ces précisions.

>Qd tu testes la réponse d'un filtre, tu le fais toujours sur des signaux particuliers : impulsion, échelon. Ici je propose de le faire sur un échelon, c'est tout il ne faut pas chercher plus loin. Cela va permettre de voir comment une transition brutale est filtrée par le resize. Plus le resize sera bon, et plus la pente obtenue sera raide.

Cela devient donc le centre du débat :C)
Je pense que pour un resize, on ne cherche pas à connaître la réponse impulsionnelle ou la réponse à un échelon. D'ailleurs, SI les resizes sont implémentés 'sans erreur', on les connaît (mais ta démarche a certainement l'intérêt de vérifier les implems). Selon toi, le bon critère est: "Plus le resize sera bon, et plus la pente obtenue sera raide". Je pense que le bon critère serait plutôt la différence entre l'image de départ et un rééchantillonnage de l'image upscalée. Evidemment, le critère que je propose n'est pas évident à mettre en oeuvre car il faudrait en théorie pouvoir rééchantillonner comme la source l'a fait... De plus, à la lumière de tes remarques sur les filtres appliqués en production, on est effectivement très gêné par la variabilité de ces filtres. J'ai l'impression néanmoins que le critère que tu envisages aura tendance à favoriser les resizes qui traitent le mieux les sous-titres (n'est-ce pas là qu'on a les plus fortes transitions?).

[Emmanuel Piat]

>J'ai l'impression néanmoins que le critère que tu envisages aura tendance à favoriser les resizes qui traitent le mieux les sous-titres (n'est-ce pas là qu'on a les plus fortes transitions?).

C'est la moindre des choses si le resize est bon . Un bon resize doit correctement se comporter avec toutes les fréquences (de la min à la max) présentent dans l'image d'origine. Sinon, tu as raisons, on a les plus fortes transitions sur les sous-titres de par leur nature "artificielle".