TT 2.0 Impressioni d'uso

[Neo85]

ma è meglio yv12 o yuy2? mi sa però che con ffdshow a parte l'uscita ( che può essere impostata anche a rgb32)l'ingresso sia comunque trasformato in yv12 per resize o sbaglio? quindi dovrebbe essere meglio madare direttamente sia da nvidia che da dscaler un segnale yv12....o no?

[ciuchino]

Neo85 ha scritto:
ma è meglio yv12 o yuy2? mi sa però che con ffdshow a parte l'uscita ( che può essere impostata anche a rgb32)l'ingresso sia comunque trasformato in yv12 per resize o sbaglio? quindi dovrebbe essere meglio madare direttamente sia da nvidia che da dscaler un segnale yv12....o no?

Ti sei fatto la domanda e ti sei risposto da solo .
Cosi' in teoria dovrebbe essere.

Ciao

[Michele Spinolo]

ciuchino ha scritto:
Sono tornato in overlay sistemate un po' di cose piccolo settaggio e poi mi sono divertito con un esperimento.

Questi sono due grab presi con Ffdshow ... alla fine della catena .

Ffdshow cosi' settato :

Resize 1280x720 . lanczos 4 , luma 0.7 , croma 0.3
offset luma x + 1
unsharp 15

Questo quello che e' uscito con TT2/nvidia + nvpp per la conversione in YV12 e con zoomplayer + Dscaler
settato per uscire in YV12 , questo per rendere meno pesante il resize.
Gia' una cosa strana , consumo CPU Dscaler 50% , Nvidia 68 % su P4 3Ghz.

CUT

Antonio, riesci a farmi avere per mail le immagini non compresse?
Sono piene di artefatti da compressione JPEG e non si riesce a capire se il maggior dettaglio del filtro di DScaler sia imputabile ad un algoritmo di sharpness inserito in questo.

La mia mail è michele.spinoloNOSPAM@tin.it

[ADUWIND]

Qualche banalissima premessa, doverosa:

- tutto il s.ware x HTPC, (escluso WMVHD) nasce in ambiente NTSC.
- Il formato NTSC avendo (576-480) 96 linee in meno, impegna meno le risorse dell'HTPC;
-I colori RGB NTSC sono diversi dal Pal;
- Un tritubo restituisce colori diversi da un DLP o un LCD e viceversa;
- le dimensioni dello schermo influiscono sulla visione;
- Ogni HTPC ha caratteristiche diverse dall'altro;
- Un segnale VGA, è diverso da un DVI.

E' stata fatta tutta la menata, per dirvi che i settaggi Pal, non corrispondono perfettamente a quelli NTSC e che i diversi tipi di configurazione danno risultanze diverse.

Io vi confermo che nel mio sistema le cose funzionano.
Oggi ho giocato solo con materiale Pal e queste sono le mie esperienze su TT 2.2

PentiumIV - 3,06 Gz O.C. a 3,3 - Hyper T. Attivato.
Catalyst 4.10/Ffdshow sse2 2004.07.04/Picture properties/Denoise 3d/05/1/5 HQ - Resize 816x1440 lanczos/Output RGB32/ TT 2.02/vmr9 + rgb 32/NO RECLOCK.

Nel mio sistema, Reclock introduce la perdita dell'audio nel cambio di capitolo o nell'avanzamento/riavvolgimento veloce.

Anche senza reclock, se inserisco Pause perdo l'audio....ma c'è un rimedio:
riavvio il video, apro configuration/audio/nella casella dell'uscita audio io ho selezionato di default SP/DIF, passo da SP/DIF a Stereo e poi di nuovo a SP/DIF e l'audio torna a posto.
Evidentemente con il comando pause, l'audio perde la sincronia.
Segnalerò questa cosa ad Andrew, insieme ai nominativi di due talebani di reclock.

In questa configurazione, con DVD PAL Superbit e con i miei valori di FFDSHOW la cpu è al massimo, per evitare qualche scattino disinserisco "Picture P" e inserisco "Level" che consuma un 2/3% in meno di CPU rispetto a Picture, con gamma a 1,45.
Nessuno scatto e nessuna necessità di cambio tra Picture e level con i Pal normali.

Con Video NTSC, tutto perfetto e consumo CPU circa 85% (valori di task manager x circa 2).

Test PAL superbit: Lawrence D'arabia / Pal normale 007 la morte può attendere.

NTSC, i soliti: Gladiator - Fifth element+ MBII, superbit.

Non ho problemi di aspect ratio, di chroma bug e simili.
Ovviamente non posso usare l'adjust video di TT, dato che lo space color RGB32 lo disabilita.

Per me, la mia configurazione è ottimale, io godo di una tridimensionalità e definizione stratosferiche, assenza di noise e colori brillanti.

Ho anche guadagnato un grigio in + !!!!

Sicuramente un 7200 su schermo 2mt digerisce vmr9+rgb32 meglio di altri proiettori.

Comunque Vi confermo che catalyst 4.10+vmr9+rgb32 è un bell'andare, non tornerete mai + all'overlay, vi apparirà "sciapo".

La mia convinzione che la validità di un S.ware x HTPC si misura su materiale NTSC/60 Hz è ulteriormente confermata.


X i due Talebani di Reclock, tali michele & ciuchino:
ho studiato, provato, auscultato, e ho dedotto che la presenza di questo programma non influisce affatto sulla qualità audio, sempre nel mio sistema.
Mentre ha gli effetti sopradescritti.

BUON HTPC A TUTTI !!!!!!

[ciuchino]

Michele Spinolo ha scritto:
Antonio, riesci a farmi avere per mail le immagini non compresse?

Michele ti rispondo qui' perche' se qualcuno vuole giocare ...
Le immagini sono cosi' come le ha grabbate Ffdshow , in pratica e' lui che ha creato il jpeg cosi' come lo vedi.
Ci sono dei settaggi di grab e quindi penso si possano migliorare.
Domani sera magari ci riprovo a farle per curiosita' meglio ... ne faccio una da 6 giga col VMR9 ed RGB32 per Aldo ... e senza reclock.

[gian de bit]

Ciao a tutti in particolare
X ciuchino e Michele:

Ho provato i filtri Dscaler e.... debbo confermare in pieno cio' che ha riportato ciuchino sopra con gli SS! Ho provaro in Overlay con uscita colore YV12 con filtri Dscaler 5.03, e debbo dire che la profondita colore aumenta visibilmente rispetto all'RGB32+cinemaster, e dando solo un paio di step di sharpness in Dscaler si arriva ad avere una profondita' maggiore di qualsiasi soluzione vista fino ad ora, (anche se non ho visto ancora gli Nvidia+TT2), l'incremento di qualita' d'immagine e di profondita' colore ihmo non e' da sottovalutare, e' veramente apprezzabile, e agendo sullo sharpness di Dscaler si ottengono ottimi risultati!

Sono pienamente daccordo con Michele, dopo varie prove fatte, che il VRM9 e' inferiore all'YV12 avendo un algoritmo meno efficiente, ma poi mi chiedo, se il PAL esce in YV12, fargli fare il passaggio da RGB32 non fa' solo danni?? Inizialmente si potrebbe essere attratti dall'"apparente" profondita colore, che e' data solo (ihmo) da un forte contrasto di partenza dell'RGB32, ma poi, essendo troppo "affogati" i neri, si deve per forza di cose andare a ritoccare i parametri di LUM e CONTR, e a quel punto escono fuori le "magagne" tipo ditering, effetto "moire" ecc... (almeno e' cio' che succedeva a me), mentre oggi con questi filtri di Dscaler non solo ottengo una profondita' colore ottima, ma anche piu' precisa nel microdettaglio e piu' nitida in generale, poi andando ad alzare dei valori di "lumi" e "contr" l'immagine ora rimane bella compatta e senza ditering, oggi con dei titoli che conosco a menadito, con questi filtri sono riuscito a levare del rumore video la' dove con altre soluzioni non ero mai riuscito a levare....
Da provare senza dubbio!

C'e' una pecca pero', che andando a smanettare si perde lo stream digitale audio verso l'ampli, e non e' sempre facile rimetterlo , a voi succede? Da cosa dipende?

Ciao
Gianni

[YGPMOLE]

...Ho notato che non sempre è sufficiente salvare e chiudere il pannello delle opzioni per rendere effettive le modifiche fatte, o quantomeno i risultati che si ottengono sono più veritieri e stabili se si chiude e riapre il lettore software.

Consiglio quindi di perdere un secondo di tempo in più per vedere come realmente sia l'influenza di un settaggio in ZP.

Un saluto. Leo!

[Michele Spinolo]

gian de bit ha scritto:

Sono pienamente daccordo con Michele, dopo varie prove fatte, che il VRM9 e' inferiore all'YV12 avendo un algoritmo meno efficiente, ma poi mi chiedo, se il PAL esce in YV12, fargli fare il passaggio da RGB32 non fa' solo danni?? Inizialmente si potrebbe essere attratti dall'"apparente" profondita colore, che e' data solo (ihmo) da un forte contrasto di partenza dell'RGB32, ma poi, essendo troppo "affogati" i neri, si deve per forza di cose andare a ritoccare i parametri di LUM e CONTR, e a quel punto escono fuori le "magagne" tipo ditering, effetto "moire" ecc... (almeno e' cio' che succedeva a me), mentre oggi con questi filtri di Dscaler non solo ottengo una profondita' colore ottima, ma anche piu' precisa nel microdettaglio e piu' nitida in generale, poi andando ad alzare dei valori di "lumi" e "contr" l'immagine ora rimane bella compatta e senza ditering, oggi con dei titoli che conosco a menadito, con questi filtri sono riuscito a levare del rumore video la' dove con altre soluzioni non ero mai riuscito a levare....
Da provare senza dubbio!

C'e' una pecca pero', che andando a smanettare si perde lo stream digitale audio verso l'ampli, e non e' sempre facile rimetterlo , a voi succede? Da cosa dipende?

Ciao
Gianni

YV12 e VRM9 non c'entrano niente uno con l'altro: il primo è uno spazio colore, il secondo una metodo di visualizzazione tramite rendering dello stream video alternativo all'overlay.
YV12 non c'entra quindi niente con l'algoritmo di resize o con l'eventuale compressione delle texture (che mi sono informato non è lossless come avevo scritto...).

Passare a RGB32 è necessario per mandare il segnale al proiettore via RGB, o quantomeno per visualizzarlo su un desktop settato a 32bit di profondità colore (se sei sotto i 32bit la conversione sarà a 24 o 16bit).
Quindi il discorso è se farlo fare in HW alla scheda video o in SW a Ffdshow.
Ffdshow lavora internamente in YV12, quindi c'è poco da fare e la conversione da qualche parte deve essere fatta.

Io non ho mai avuto problemi selezionando RGB32 come uscita in Ffdshow, mai assistito a quei viraggi, immagini buie, ecc...che sono state qui riportate, quindi non so dirti.

[Michele Spinolo]

ciuchino ha scritto:
Michele ti rispondo qui' perche' se qualcuno vuole giocare ...
Le immagini sono cosi' come le ha grabbate Ffdshow , in pratica e' lui che ha creato il jpeg cosi' come lo vedi.
Ci sono dei settaggi di grab e quindi penso si possano migliorare.
Domani sera magari ci riprovo a farle per curiosita' meglio ... ne faccio una da 6 giga col VMR9 ed RGB32 per Aldo ... e senza reclock.

Ho fatto qualche prova anche io, sempre però con i filtri nVidia e con parametri come segue:
-Denoise3D HQ chroma 0.0 luma 1.0 time 5.0
-Resize Lancsoz6 luma sharp 1.20 chorma sharp 0.0
-YV12

-Denoise3D HQ chroma 0.0 luma 1.0 time 5.0
-Resize Lancsoz4(5) luma sharp 1.20 chorma sharp 0.0
-RGB32

Linko i file delle foto perchè sono PNG a risoluzione piena e quindi "pesantucci" (1Mb l'uno):

1° scena

http://michelespinolo.altervista.org...2_lancsoz5.png

http://michelespinolo.altervista.org...lancsoz6_2.png

2° scena

http://michelespinolo.altervista.org...2_lancsoz4.png

http://michelespinolo.altervista.org...2_lancsoz6.png

in conclusione IMHO non ci sono differenze fra RGB32 e YV12, mentre qualcosa fra Lancsoz4 e 6 può essere visto.
I frame non sono esattamente gli stessi, ma confronti si possono lo stesso fare.
Da notare nella prima scena gli artefatti nel contorno degli edifici, che a questo punto penso siano dovuti alla compressione Mpeg2.

Il chroma blocking lamentato su AVSF non l'ho notato per nulla, ne in RGB32 ne in YV12.

P.S. Non so perchè se cliccate sulle immagini non le apre, click col destro sul link e scegliete "salva con nome"

[gian de bit]

Michele Spinolo ha scritto:
YV12 e VRM9 non c'entrano niente uno con l'altro: il primo è uno spazio colore, il secondo una metodo di visualizzazione tramite rendering dello stream video alternativo all'overlay.
YV12 non c'entra quindi niente con l'algoritmo di resize o con l'eventuale compressione delle texture (che mi sono informato non è lossless come avevo scritto...).

Passare a RGB32 è necessario per mandare il segnale al proiettore via RGB, o quantomeno per visualizzarlo su un desktop settato a 32bit di profondità colore (se sei sotto i 32bit la conversione sarà a 24 o 16bit).
Quindi il discorso è se farlo fare in HW alla scheda video o in SW a Ffdshow.
Ffdshow lavora internamente in YV12, quindi c'è poco da fare e la conversione da qualche parte deve essere fatta.

Michele grazie, per la correzione, mi sto' rileggendo ora, e mi rendo conto che scrivendo ho mischiato i concetti tra spazio colore e trattamento video, (sara' stata pure l'ora in cui ho postato: 03.00 ), comunque mi sono ingarbugliato solo per dire che alla fine dei conti questi filtri Dscaler in Overlay e YV12, vanno meglio dell' RGB32 in VRM9 .
Unico difetto e' che smanettandoci, si perde lo stream audio digitale sull'ampli, che diventa DPLogic
Chi li ha provati potra' constatare che c'e' piu' dettaglio e piu' pulizia generale, nonche' piu' profondita'.

PS: per postare alle 03.00 qualcosa di buono devo aver trovato casini scritti a parte...

Ciao
Gianni

[ADUWIND]

Michele Spinolo ha scritto:
Ho fatto qualche prova anche io, sempre però con i filtri nVidia e con parametri come segue:
-Denoise3D HQ chroma 0.0 luma 1.0 time 5.0
-Resize Lancsoz6 luma sharp 1.20 chorma sharp 0.0
-YV12

-Denoise3D HQ chroma 0.0 luma 1.0 time 5.0
-Resize Lancsoz4(5) luma sharp 1.20 chorma sharp 0.0
-RGB32

Linko i file delle foto perchè sono PNG a risoluzione piena e quindi "pesantucci" (1Mb l'uno):

1° scena

http://michelespinolo.altervista.org...2_lancsoz5.png

http://michelespinolo.altervista.org...lancsoz6_2.png

2° scena

http://michelespinolo.altervista.org...2_lancsoz4.png

http://michelespinolo.altervista.org...2_lancsoz6.png

in conclusione IMHO non ci sono differenze fra RGB32 e YV12, mentre qualcosa fra Lancsoz4 e 6 può essere visto.
I frame non sono esattamente gli stessi, ma confronti si possono lo stesso fare.
Da notare nella prima scena gli artefatti nel contorno degli edifici, che a questo punto penso siano dovuti alla compressione Mpeg2.

Il chroma blocking lamentato su AVSF non l'ho notato per nulla, ne in RGB32 ne in YV12.

P.S. Non so perchè se cliccate sulle immagini non le apre, click col destro sul link e scegliete "salva con nome"

Ciao Michele,
alcune domande:
1) versione di ffdshow ?
2) scheda grafica ?
3) cpu

Grazie,

Aldo

[kaisersoze]

ed anche:

Overlay o VMR9?

Grazie: ottimo lavoro!

[Michele Spinolo]

gian de bit ha scritto:

PS: per postare alle 03.00 qualcosa di buono devo aver trovato casini scritti a parte...

Ciao
Gianni

IMHO è già molto aver trovato le lettere sulla tastiera!

[Michele Spinolo]

ADUWIND ha scritto:
Ciao Michele,
alcune domande:
1) versione di ffdshow ?
2) scheda grafica ?
3) cpu

Grazie,

Aldo

Giusto! Mancavano le condizioni al contorno!

allora:
-WinXP SP1 senza ulteriori patch
-Radeon 9600Pro Cat4.10
-TT2.02
-Ffdshow ultima versione MMX2 di Andy
-Barton 2500+@3200+
-Reclock
-Overlay

[ciuchino]

Ottimo Michele .
Sarebbe interessante capire se il grab comprende anche l'ultimo colorspace impostato in Ffdshow.
Sicuramente non il renderer video , che viene dopo Ffdshow , per cui non cambia niente tra overlay o VMR9.

Almeno hai usato il grab di Ffdshow ?

Ciao