Pour en finir avec YV12 ou YUY2 !

» 03 Fév 2005 10:20

En attendant le test des players mpeg2 que vous attendez tous, je vous propose un petit hors d'oeuvre sur le fameux YV12 ou YUY2 :wink:

Ce test va vous permettre de constater de visu à quel point un up/downsampling de chroma mal maîtrisé peut dégrader une image.

DVD de test : Kill bill 1 (Z2)

Scène de test : 1:04:08 à 1:04:40 (ne pas tenir compte du flash back en plein milieu)

Ce qu'il faut regarder : le contour rouge du casque autour de la visière noire. Si l'info de chroma est dégradée par les traitements, on voit apparaître des effets de dégradée de "mini-blocs" plus ou moins accentués. C'est la première fois que je trouve un test aussi facile à observer sur un DVD que la majorité doit posséder...

Filtre vidéo : Dscaler 5 ou le dernier nvidia (désentrelacement weave)
ffdshow : actif mais AUCUN filtre coché

Ce qu'il faut tester :

- sortie filtre video en YUY2 & sortie ffdshow en YV12
- sortie filtre video en YV12 & sortie ffdshow en YV12
- sortie filtre video en YUY2 & sortie ffdshow en YUY2
- sortie filtre video en YV12 & sortie ffdshow en YUY2

Pour mettre un peu de suspens, je vous laisse juger par vous même quelles sont les combinaisons à éviter impérativement :wink:

et je termine par un rappel du fonctionnement du resize de ffdshow qui permet de comprendre pourquoi on peut facilement se retrouver avec un CPU à 100%.

Le resize de ffdshow traite indépendamment les infos de chroma et de luma. Ceci est possible parce que ffdshow travaille en interne soit en YV12, soit en YUY2 et que dans ces deux formats, les infos de luma et chroma sont séparée.

YUY2 a deux fois plus d'infos de chroma que YV12. Donc si ffdshow travaille en YUY2, il y a deux fois plus d'info de chroma à resizer => l'occupation CPU fait alors un joli bon en avant si on a une grosse résolution. Par contre, si ffdshow travaille en YV12, on a une charge raisonnable du CPU, même pour de grosses résolutions.

Q : Qd est-ce qu'on est en YUY2 dans ffdshow (cas défavorable pour le CPU) ?
R : si le filtre vidéo sort en YUY2 et que seul le filtre resize de ffdshow est actif

Q : Qd est-ce qu'on est en YV12 dans ffdshow (cas favorable pour le CPU) ?
R1 : si le filtre vidéo sort en YV12
R2 : s'il y a avant le resize un filtre actif du style sharpen, Blur & NR, etc. Qd ce cas, si le filtre vidéo sort en YUY2, le flux est converti en YV12 par ffdshow

Nota : le format de sortie de ffdshow YV12 ou YUY2 intervient peu sur la charge CPU.
On peut regarder la charge CPU dans le gestionnaire de tâche pour vérifier tous ces points.

Ex : mettez la sortie de Dscaler 5 en YV12. Dans ffdshow, mettez uniquement le filtre resize en 1360x1024 ou plus => tout va bien. Mettez ensuite Dscaler 5 en YUY2. J'obtiens alors un CPU à 100% sur mon P4C@3Ghz.... Ajoutez un filtre sharpen avant le resize, la charge CPU redescend de moitié...

Il suffit ensuite de croiser ça avec ce que donnent les 4 tests au dessus en terme de qualité pour conclure sur quelles sont les combinaisons intéressantes en fonction des filtres que vous utilisez.

@+
Emmanuel

» 03 Fév 2005 12:04

Conclusion ? :mdr:

» 03 Fév 2005 12:22

hé hé

Honnêtement, ça vaut le coup de faire le test parce que, pour une fois, on a quelque chose de flagrant via un test simplissime. Disons que le résultat de la combinaison "sortie filtre video en YUY2 & sortie ffdshow en YV12" bcp utilisée jusqu'à présent m'a surpris :wink:

Rq : test fait uniqt. en overlay en 1360x1024.

» 03 Fév 2005 12:27

pour completer le test juste un petit quote de ce que dit JohnAD (createur de dscaler) sur les format YUY2 et YV12

Pass decoded frames to renderer. Almost all MPEG streams encountered are encoded as 4:2:0 which means that they will be decoded internally as something superficially very similar to Microsoft's YV12 format, i.e. A big slab of luma and two quarter size slabs of chroma information. However this area is complicated by the MPEG 2 coding of chroma and the lack of control of the renderer's chroma upconversion. For any reasonably coded film material then simply passing the decoded frames the renderer as YV12 is probably the best compromise however this does not produce good results with true video material, especially sports. Most people are now aware of the "chroma bug" which effects film material and there are several known tests for it. The opposite problem of using film type chroma upsampling at all times seems to be common to all decoders using DXVA and makes these decoders a poor choice for all round TV use. The best test I have found for the second bug is watching clips of rugby matches involving teams with red shirts. When the players move they appear to leave a trail of chroma weaves behind them.
To get round the issues with interlaced material either a flag aware upconversion to YUY2 or a flag aware post-processing is required.

» 03 Fév 2005 15:46

pour ceux qui ne peuvent pas faire le test ( pas de pc en cemoment ), Quel est le meilleur choix ?
merci

» 03 Fév 2005 17:53

t'as commencé tôt ce matin, moi j'ai pas le kill bill vol 1, mais je dis que le mieux c'est de rentrer en yv12 dans ffdshow et de sortir également en yv12.
Parceque bien entendu on va utiliser du denoise et du rezise, du moins dans mon cas.
Par contre le comparo filtre de décodage, je l'attends de pied ferme.

» 03 Fév 2005 18:34

Emmanuel Piat a écrit:Ex : mettez la sortie de Dscaler 5 en YV12. Dans ffdshow, mettez uniquement le filtre resize en 1360x1024 ou plus => tout va bien. Mettez ensuite Dscaler 5 en YUY2. J'obtiens alors un CPU à 100% sur mon P4C@3Ghz.... Ajoutez un filtre sharpen avant le resize, la charge CPU redescend de moitié...

j'ai la meme chose a la maison (resize+sharp+denoise 3d), d'ou vient cette montée/baisse d'occupation processeur avec le resize seul ? (note qu'en yv12/yv12 l'occupation est la meme avec les trois parametres cochés)

(j'ai testé en vrm9...mais pas assez longtemps pour pouvoir parler de qualité, surtout sur le moniteur).

ps : en passant, le hardcode for pal de dscaller a l'air de ne servir à rien chez moi, qui peut me rappeller quelle est son utilité exacte ?

» 03 Fév 2005 18:48

>j'ai la meme chose a la maison (resize+sharp+denoise 3d), d'ou vient cette montée/baisse d'occupation processeur avec le resize seul ?

la réponse est dans ce que j'ai écrit. Si tu entre en YUY2 avec juste le filtre resize, tu auras forcément une occupation CPU bien supérieure car bcp plus d'info de chroma à upsampler. Si tu entre en YV12 avec juste le filtre resize, pas de pb.

>c'est de rentrer en yv12 dans ffdshow et de sortir également en yv12.

C'est un des modes qui marche bien mais ce n'est pas le seul :wink:

. Par contre, j'ai un mal de chien à avoir une config parfaitement fluide avec Dcaler5 ou Nvidia configuré en YV12. J'ai parfois des micro saccades sur les travelling difficiles... Alors que les autres config qui marchent aussi sont fluides chez moi.

@+
Emmanuel

» 03 Fév 2005 19:16

je ne sais pas de quelle build de ffdshow vous vous servez, mais ce qui est sure c'est qu'avec la build d'andy et son optimisation SSE2, seul le code YV12 a ete retouche ce qui aggrave encore la difference de consommation CPU entre YUY2 et YV12.

» 03 Fév 2005 19:48

Donc les filtres ffdshow s appliquent avant le resize? on n aurait pas une meilleur qualité s ils sont plutot apres?

Avi

» 03 Fév 2005 19:53

Alien 1 en zone 1, juste l'intro ( traveling de la mort soit dit en passant )

testé à l'instant en DSCALER => YUY2 => FFDSHOW ( SHARP + DENOISE 3D + RESIZE + LANCZOS 4 + LUMA 1 ) => YV12.

10% d'augment CPU... environ.

YV12 => YV12 quelques saccades,
YUY2 => YV12, plus aucunes saccades.

D'un point de vue qualité, j'vois pas la moindre différence. Mais y'en a t il une vraiment ?

A+

» 03 Fév 2005 21:35

En fin de chaine il ne faut pas oublier non plus la conversion YV12 vers RGB 8 bits dans le renderer video

» 03 Fév 2005 22:11

DTSman a écrit:En fin de chaine il ne faut pas oublier non plus la conversion YV12 vers RGB 8 bits dans le renderer video

Peux-tu me dire où cela se configure dans ZP, STP ?
Dans bsplayer, est-ce dans options\préférences\video\rendu video ?

Succintement, quel est l'intérêt ?

Merci

Olivier

» 03 Fév 2005 22:21

alors yuyv vers yv12, il y aurait moins de saccade, mais qu'en pense notre ami qui lance des post qui vont faire 40 pages à 9h20 du matin, serait ce également une solution qui marche bien.
A y etre je rajouterais quand même puisque qu'on parle d'occupation cpu, les mêmes tests avec avisynth vu qu'on s'est un peu échauffé là sur l'autre post, je reve du limitedSharpen2.

» 03 Fév 2005 23:48

Honnêtement, ya pas de difference chez moi entre yv12 et yuy12!