Settings ffdshow perso (core i7)

[tspascalou]

Pour la SD, j'utilise LSFMod en mode slow http://forum.doom9.org/showthread.php?t=142706 que je trouve un peu mieux que LSF mais c'est assez subjectif. Sinon je te conseillerais absolument MadVR (avec yCMS pour la correction de gamut et grayscale si besoin) plutôt que EVR CP qui est complétement dépassé à coté Par contre madVR détecte automatiquement les primaires suivant la taille de la vidéo, en cas d'upscale avant le renderer, il faut utiliser colorMatrix (http://forum.doom9.org/showthread.php?p=544082 avec un appel du style

Code: Tout sélectionner

ColorMatrix(mode="Rec.601->Rec.709",clamp=0,opt=0)

[Samsara]

La qualité de l'architecture CPU-RAM joue donc bcp sur la capacité à post-traiter la HD en temps réel.

Ce n'est pas maitrisable, à ce sujet je crois que l'archi AMD est meilleur quant à sa liaison CPU-RAM.

[Emmanuel Piat]

Je ne pense pas que ma CG ait assez de biscottos pour passer MadVR qui est gourmand niveau shaders.

EVR CP dépassé en quoi (hormis le 10 bits de MadVR) ?

[tspascalou]

non, la sortie 10 bits ne fonctionne pas pour l'instant mais en terme de

Code: Tout sélectionner

- high quality chroma upsampling
- high quality scaling (bicubic, mitchell, lanczos, spline etc)
- high quality YCbCr -> RGB conversion
- gamut & gamma correction for display calibration
- full 16bit processing queue
- final 16bit processing result is dithered down to RGB output bitdepth
- bypasses graphics card's video (damage) algorithms
- all work is done via GPU shaders
- no shortcuts, highest quality has priority over anything else

manque le swith exclusif / fenetré à la volée, les raccourcis pour la modification des primaires et du gamma dans les dernieres versions, etc.
La réaction WAF c'est

Ah ? tu as fait quoi à l'image, c'est plus joli qu'avant, t'es trop fort mon chéri

[Emmanuel Piat]

>high quality chroma upsampling
vue la faible sensibilité de l'oeil au chroma => dubitatif. AMHA, impossible de réussir un test ABX là-dessus.

>high quality scaling (bicubic, mitchell, lanczos, spline etc)
En downscaling (si on fait avant du supersampling), c'est bcp moins critique qu'on le croit : un bicubic suffit
En upsampling sur une source 720p, ok (mais on peut faire aussi bien via avisynth)

>high quality YCbCr -> RGB conversion
bin les matrices sont connues. Après faut voir au niveau profondeur de bits et dithering... Je n'utilise pas le dithering sous ffdshow, je n'ai jamais vu l'intérêt de la chose. Mes yeux sont peut être vieillissants.

>gamut & gamma correction for display calibration
gamut : ok important !

gamma : alors là il y a bcp à dire Effectivement, une modif de gamma peut engendrer d'ENORMES différence sur l'image.
Mon petit doigt me dit que 99% du rendu effectif de Madvr se joue à ce niveau-là
La correction d'une courbe de gamma est globalement une question complexe qui dépend de la salle, du CR global du diffuseur, du CR intra-image du diffuseur, de la quantité de BTB et de WTW qu'on autorise et bien sûr du gamma natif du diffuseur. Et pour compliquer le tout le sharpen qu'il faut mettre sur une image est très dépendant de la correction gamma...

Les corrections gamma que j'utilise sur mon écran LCD et sur mon projo via des shaders de mon cru sont totalement différentes car ils ont des caractéristiques différentes...

>full 16bit processing queue
A priori utile pour les post-traitements fait par le renderer AVANT conv RGB
Quels sont ces post-traitements hormis le resize ? J'aimerai des infos complémentaires

>final 16bit processing result is dithered down to RGB output bitdepth
voir ma remarque plus haut...

>bypasses graphics card's video (damage) algorithms
Très bien

>all work is done via GPU shaders
RAS

>no shortcuts, highest quality has priority over anything else
?

[/noah/]

Je ne pense pas que ma CG ait assez de biscottos pour passer MadVR qui est gourmand niveau shaders.

EVR CP dépassé en quoi (hormis le 10 bits de MadVR) ?

madVR est gourmand dès l'instant que tu utilises les shaders d'upscaling/downscaling, mais c'est tout.

Dans ton cas de figure, tu peux très bien intercaler à la sortie de ton call avisynth un resize ffdshow en bicubic à la résolution de ton diffuseur avant d'attaquer le renderer. Dans mon cas, avec un IGP (!), madVR tourne très bien. J'arrive même a upscaler des sources SD en shader madVR (softbicubic) sans problème, par contre, un simple downscaling d'un flux HD met mon IGP à plat (sauf à utiliser les unités de texturing type bilinear).

[Emmanuel Piat]

>Dans ton cas de figure, tu peux très bien intercaler à la sortie de ton call avisynth un resize ffdshow en bicubic à la résolution de ton diffuseur

C'est une bonne idée, je vais essayer mais j'ai peur d'être juste niv. CPU

[/noah/]

Essaye également les différents shaders dispo sous madVR, si tu passes le bicubic en EVR, tu dois pouvoir le passer sous madVR ?

[kbil69]

Au fait Emmanuel, tu en es où de ta salle ?

[kbil69]

PS: je bascule tous les sujets dans le topic de MadVR

viewtopic.php?f=1196&t=29966764

[Emmanuel Piat]

Au fait Emmanuel, tu en es où de ta salle ?

Guère d'évolution. Ca marche très très fort. L'acoustique est extraordinaire. Je poursuis lentement mais surement ma réflexion sur la partie grave.

J'ai testé madVR ce WE. Aucun problème particulier à signaler, ça marche très bien en downscaling même sur ma petite ATI 4650.

Fluidité identique à l'EVR CP (c'est à dire parfaite ds les 2 cas).
Rendu colorimétrique strictement identique à la sortie RGB de ffdshow.
En test d'aliasing en supersampling, je trouve que le downsampling fait par MPC-HC (bicubic 0.60) en EVR CP est un poil plus propre que celui de madVR avec un setting équivalent.

La conclu, c'est que si on sort en RGB de ffdshow, madVR n'apporte absolument rien par rapport à l'EVR CP. MadVR n'a d'intérêt que si on ne post-processe pas la vidéo (pas d'utilisation de ffdshow) et que le décodeur sort en YV12 ou si on sort de ffdshow en YV12 ou en YUY2. Là il est absolument indispensable vu que les drivers des CG se plantent souvent lamentablement dans la conv YCbCr vers RGB selon les sources SD, HD et les rec BT.601 et 709.
Si on sort de ffdshow en RGB, vu qu'on maitrise toute la chaine de conv, il n'y a plus le moindre problème et madVR n'est pas utile. Mais il faut alors faire des settings automatiques ds ffdshow en fct de la source.

Le gros défaut de MadVR c'est qu'on ne peut plus mettre dans la boucle ses propres pixels shaders, et ça pour moi, c'est rédhibitoire, notamment pour faire une correction non linéaire du niveau des noirs (expander vidéo) qui est généralement nécessaire si on veut traiter correctement le BTB et les 1er niveaux de noirs sur des projos à CR élevé... Je vous ai fait ce WE un petit prog. matlab pour vous aider dans le paramétrage de l'expander vidéo paramétrique que j'ai écris en pixel-shader. Il faut simplement que je traduise maintenant le tout en code Scilab (gratuit) pour que tout le monde puisse l'utiliser...

[/noah/]

Dans mon cas, j'utilise madVR simplement parce qu'EVR CP produit beaucoup de tearing. Et également madVR a implémenté un mode direct3d intelligent (nettement mieux foutu que le d3d EVR). Pour le moment j'ai l'impression qu'il a encore un petit bug (remonté à madshi), mais c'est bien foutu.

Par contre, c'est curieux car j'ai l'impression que tu peux toujours sélectionner des shaders mais avant resize (ctrl+alt+p), du moins c'est accessible en clic doit mpc en lecture. A vérifier si cela marche ou non.

[/noah/]

sinon ton expander sert à quoi ? Déboucher les noirs ? Ca pourrait permettre sur les projos avec un noir un peu gris de jouer sur la luminosité sans pour autant perdre tous les détails ?

[Emmanuel Piat]

L'expander peut effectivement déboucher les noirs. Il permet en fait de contrôler le contraste relatif entre chaque niveau de gris (le saut de chaque "marche" de gris en qq sorte).

Ca peut effectivement servir à booster le contraste apparent dans les noirs pour les projos ayant un niv. de noir un peu élevé ET une bonne luminosité (because, il n'y pas de miracle sur cette bonne veille planète : si tu expandes au début, il faut compresser ensuite (sinon tu perds des niveaux en bout d'échelle). Donc il faut bien choisir la zone de compression qui va rendre l'image plus "plate" ds cette zone. L'idéal serait peut être de la mettre tout au bout vers les blanc. Mon expander qui est assez basique ne le permet pas : la compression suit immédiatement l'expansion mais elle se fait de manière diluée sur toute l'échelle avec une décroissance log. Ca marche très bien avec un diffuseur lumineux.

[Emmanuel Piat]

>parce qu'EVR CP produit beaucoup de tearing.

bien dire ds les options de MPC qu'il faut attendre le GPU (sinon tearing garanti).

En cas de désynchro source / diffuseur, ça peut néanmoins être insuffisant. Personnellement, j'ai la chance d'avoir des diffuseurs (moniteurs / projo) qui bouffent n'importe quelle synchro sans sourciller. Donc si j'ai une source en xxx fps, je mets la fréq de la CG sur un multiple de xxx via powerstrip et tout roule au niv. du diffuseur. S'il reste du tearing, il suffit d'ajuster l'offset de synchro via MPC-HC et une fois qu'on a le bon offset tout le tearing dégage.

Bref, pour faire bref, le tearing je ne connais pas chez moi