Avisinth LimitedSharpen in FFdshow: funziona!

[Sabatino Pizzano]

Finalmente sono riuscito a provare avisinth... cosa dire, se non STUPEFACENTE! Il mio marquee vi sta ancora ringraziando
praticamente la sensazione che ho avuto io è stata duplice: un aumento di dettaglio tale da percepire una maggiore vicinanza all'azione, e una pulizia e precisione dell'immagine come se mi allontanassi dallo schermo di un paio di metri. davvero ottimo.

Non voglio dare giudizi affrettati, ma mi aspettavo di più da avisinth

stè, controlla bene

 

[Restless Dreams]

Controllerò meglio, ma che chiamata hai fatto tu? come la mia? e resize a quanto? eppure io non vedo questa mega differenza con il vecchio unsharp...

Ieri sera ho scoperto una cosa nuova, se metto avisynth prima del resize il consumeo è chiaramente molto più basso e la cosa che mi ha lasciato stupito è che la linea nera che prima compariva ora non c'è più ho usato smode4 e il pack pluging aggiornato di stealth, qualcuno può confermare? e non mi è parso qualitativamente parlando, di notare grosse differenze tra mettere avisinth prima o dopo il resize

 

[Sabatino Pizzano]

la chiamata è la solità, smode 3 e rgb32.
nessun resize, ho impostato la risoluzione del pc a 1024*576, e cosi anche il mio processore attuale ce la fa. tanto con il crt non ho bisogno di scalare per forza.

 

[YGPMOLE]

se metto avisynth prima del resize il consumeo è chiaramente molto più basso e la cosa che mi ha lasciato stupito è che la linea nera che prima compariva ora non c'è più

Questo mi lascia un po' perplesso, visto che la riga nera dovrebbe scomparire mettendo Avisynth dopo il resize...?!??

Comunque, essendo dovuta all'abilitazione del Multithreading, sei sicuro che ci sia nella tua chiamata il parametro "MT" (ti ricordo che il "SetMTmode(2) mantiene il multithreading disattivo)?

Un saluto. Leo!

 

[Restless Dreams]

Questo mi lascia un po' perplesso, visto che la riga nera dovrebbe scomparire mettendo Avisynth dopo il resize...?!??

Comunque, essendo dovuta all'abilitazione del Multithreading, sei sicuro che ci sia nella tua chiamata il parametro "MT" (ti ricordo che il "SetMTmode(2) mantiene il multithreading disattivo)?

Un saluto. Leo!

Non ho fatto chiamate MT, ho un sempron che supporta solo istruzioni sse quindi ho fatto tenuto nei plugins solo i file sse. Cmq si è vero che si risparmia cpu mettendo avisinth prima del resize, ma qualitativamente parlando, avremo un resa video paragonabile alla soluzione di mettere avisynth dopo il resize?

La riga nera mi è parso di non averla notata, rifaccio un test approfondito in serata, cmq io stgo usando ffdshow del 29/11 e dscaler 5008 con ZP in modalità vmr9 se può essere d'aiuto e la chiamata è la solita di default messa nel post 314 di stealth con LSfaster.

Per la cronaca ieri ho straovercloccato il sempron sono arrivato al clock di 2340 mhz, e avisynth dopo il resize andava benissimo ed il sistema era cmq stabile e ben utilizzabile con consumo cpu inferiore al 90%

 

[stealth82]

la chiamata è la solità, smode 3 e rgb32.
nessun resize, ho impostato la risoluzione del pc a 1024*576, e cosi anche il mio processore attuale ce la fa. tanto con il crt non ho bisogno di scalare per forza.

Ma forzi l'RGB sia in "entrata Avisynth" spuntando la casella RGB32, sia a livello di output ffdshow (sempre spuntando solo la casella RGB32)? Il resize non è molto; altri filtri attivi?

Quello che mi preme sapere è il consumo CPU. Sto rivalutando l'RGB32 dopo questi screens (da avsforum, tenendo presente che l'RGB32 darebbe il massimo solo con il VMR9 - no overlay):

vmr9 + rgb32

vmr9 + yuv2

vmr9 + yv12

Al di là delle strane scalettature, che sembrano scomparire in rgb32, il range di colori è strabiliante.

Unico dubbio, la taratura dell'output andrebbe a farsi benedire... con l'RGB32 bisogna rialzare i valori di luminosità tornando a pieno range. Questo non sarebbe un problema in linea di principio, ma quando non usi ffdshow (tipo HD o altri media che non sfruttano ffdshow)???

 

[stealth82]

Cmq sia la trovo un po' grigia... ricordo di aver dato un'occhiata al codice del LimitedSharpen (il faster è uguale sotto questo aspetto) ed il fatto che converta sempre e cmq lo spazio colore in YV12 vanificherebbe il lavoro.

clp.isYV12() ? clp : clp.converttoyv12()

Cioè, quello che voglio dire è che sarebbe meglio uscire da TT in RGB32 (a proposito sarebbe bello farlo da programma piuttosto che cambiare le chiavi di registro, se si potesse mettere RGB32 ovviamente ), evitando le buche più dure (ergo la conversione), e lavorando solo in questo spazio colore... infatti, da quello che leggevo sul thread dove ho pescato le foto, la conversione del vmr9 in RGB32 non è il massimo (cioè dovrebbe essere già rgb32 quando elaborata e non convertita alla fine della catena di elaborazione).

Allora sì che mi comprerei una CPU MT se bastasse

 

[ciuchino]

Allora sì che mi comprerei una CPU MT se bastasse

YV12 e' lo spazio colore che piu' si avvicina al DVD quindi se Nvidia uscisse in RGB32 la conversione l'avresti comunque.
Inoltre il dispendio di risorse elaborando un RGB32 sarebbe enorme.
Da valutare invece la conversione finale prima di passare il tutto alla scheda video.
Da mettere sul piatto della bilancia come al solito vantaggi e svantaggi.

Con ATI la cosa funziona anche in Overlay.

Ciao
Antonio

 

[stealth82]

YV12 e' lo spazio colore che piu' si avvicina al DVD quindi se Nvidia uscisse in RGB32 la conversione l'avresti comunque.

E qui non ci piove, ma se ben ricordo, l'impatto CPU che implicava la conversione YUV2 (il vecchio spazio TT) > YV12, in ffdshow era ben superiore a quanto poi è stato uscire direttamente in YV12, o sbaglio?

Magari fosse eseguito in hardware

Inoltre il dispendio di risorse elaborando un RGB32 sarebbe enorme.

Tentar non nuoce: serriamo qui, molliamo là

Da valutare invece la conversione finale prima di passare il tutto alla scheda video.

Ora, non ho provato la differenza ma stando alle dichiarazioni dell'autore degli ss in alto le frasi che ho evidenziato in grassetto mi disturbano

The best possible RGB conversion would be using software RGB conversion + vmr9, but it's slow .
e.g. ffdshow and kmplayer can output RGB32 (0-255)

Overlay is hardware dependent. For me, overlay+RGB is bad, overlay+yuv is good.
vmr9 is just bad in rgb conversion, no wonder yv12 is disabled in mplayerc vmr9 renderless.

 

[Sabatino Pizzano]

Ma forzi l'RGB sia in "entrata Avisynth" spuntando la casella RGB32, sia a livello di output ffdshow (sempre spuntando solo la casella RGB32)? Il resize non è molto; altri filtri attivi?

allora, ho selezionato RGB32 da zoom player e da fddshow. Se lo vado a selezionare pure da avisinth mi da errore dicendo che non può convertire. Abilitando OSD di Fddshow effettivamente come spazio colore mi indica RGB32. Riguardo al consumo CPU non mi pronuncio perchè attualmente sto con una configurazione molto approssimativa (in attesa che arrivi la nuova mobo e la x1600 che vanno a sostituire rispettivamente l'epox che ho bruciato e la 6600).

ps. nessun altro filtro utilizzato. Attualmente ho un barton 3000+ montato su una mobo a 266mhz, per cui molto castrato che va più lento del vecchio xp 2200+ e il consumo cpu sta sul 60/70%.

 

[ciuchino]

E qui non ci piove, ma se ben ricordo, l'impatto CPU che implicava la conversione YUV2 (il vecchio spazio TT) > YV12, in ffdshow era ben superiore a quanto poi è stato uscire direttamente in YV12, o sbaglio?

Nvidia puo' uscire in spazio colore YUY2 o YV12 tramite settaggio registro.
TT forza l'uscita YV12 , il grosso vantaggio c'e' se usi il resize di Ffdshow come primo filtro perche' e' ottimizzato per quello spazio colore.
Altre cose non ne ho provate non notando differenze tra l'uso di YUY2 e YV12.
In DXVA esci in NV12 o sottospeci , in altri casi te ne ritrovi un altro con Elecard per esempio.

Per il resto che vuoi che ti dica , ho usato l'RGB32 per parecchio tempo e come al solito c'era chi ne parlava bene e chi ne parlava male.
Attualmente nel mio caso le differenze si sono assottigliate ed uso la catena YV12 in/out.
Ma non si sa' mai ...

Ciao

 

[Mike5]

Con ATI la cosa funziona anche in Overlay.

Cioè vuoi dire che con le schede ATI, a differenza di quelle nVidia, si può uscire in RGB32 anche in Overlay ?

Nvidia puo' uscire in spazio colore YUY2 o YV12 tramite settaggio registro.

Smanettando con ffdshow e vari decoder ho scoperto che se si setta Raw video a "all supported" oppure "all YUV", il decoder nVidia puro (no TT) esce in YUY2; se invece si setta a "YV12", nVidia esce in YV12 senza bisogno di settare registri. E' una soluzione alternativa che permette di non toccare i registri (usando ffdshow).

Michele

 

[Sabatino Pizzano]

Cioè vuoi dire che con le schede ATI, a differenza di quelle nVidia, si può uscire in RGB32 anche in Overlay ?

io lo uso con la 9200

 

[Mike5]

io lo uso con la 9200

In effetti poi ho visto che Ciuchino lo aveva già detto in altri thread.

D'altronde ho anche riflettuto che l'overlay è una funzionalità hardware della scheda video e quindi ogni produttore lo fa (entro certi limiti) come lo vuole.

Michele

 

[Mike5]

io lo uso con la 9200

In effetti poi ho visto che Ciuchino lo aveva già detto in altri thread.

D'altronde ho anche riflettuto che l'overlay è una funzionalità hardware della scheda video e quindi ogni produttore lo fa (entro certi limiti) come lo vuole.

Michele

 

[Mike5]

Mi sono beccato un errore di memory overflow da parte del server di AVMagazine ed il messaggio è uscito 2 volte.

 

[stealth82]

Ho trovato il corrispettivo wikipedia per le funzioni di Avisynth: non è completissimo - ovvero non tutte le funzioni sono documentate - ma sicuramente da tenere d'occhio per ricordare cose utili, una su tutti il LimitedSharpen. Se non altro è un complemento dell'altro help.

Provate qui: http://www.avisynth.org/mediawiki/wiki/LimitedSharpen. C'è tutta la documentazione con il dettaglio delle varie opzioni.

Da come è descritta la funzione smode molto probabilmente treno ha ragione (non si sta mai fermi un attimo )

Smode int (1-4, default 3)
Sharpen mode:

* 1 : UnsharpMask
* 2 : Sharpen
* 3 : Magic.
* 4 : Deep magic.

Magia profonda... ghhaaa (ci vorrebbe la faccia trasognata di homer )

 

[stealth82]

Per il resto che vuoi che ti dica , ho usato l'RGB32 per parecchio tempo e come al solito c'era chi ne parlava bene e chi ne parlava male.
Attualmente nel mio caso le differenze si sono assottigliate ed uso la catena YV12 in/out.
Ma non si sa' mai ...

Nelle tue peregrinazioni hai mai provato questo ciuchino (vedi s.s. sotto)... o hai sempre testato l'RGB32 liscio. No perchè sembrerebbe un grande affare, a quanto sto leggendo . Se sì, reimposta lo 0-255 (io direi proprio di sì)? Inoltre, se magna lo stesso la CPU?

Probabilmente richiede anche qualche altra spunta nella sezione RGB

L'ho buttata lì perchè non ho la possibilità di provarla SUBITO da me

 

[Restless Dreams]

Ho trovato il corrispettivo wikipedia per le funzioni di Avisynth: non è completissimo - ovvero non tutte le funzioni sono documentate - ma sicuramente da tenere d'occhio per ricordare cose utili, una su tutti il LimitedSharpen. Se non altro è un complemento dell'altro help.

Provate qui: http://www.avisynth.org/mediawiki/wiki/LimitedSharpen. C'è tutta la documentazione con il dettaglio delle varie opzioni.

Da come è descritta la funzione smode molto probabilmente treno ha ragione (non si sta mai fermi un attimo )

​

Magia profonda... ghhaaa (ci vorrebbe la faccia trasognata di homer )

Eppure ragazzi a me sembra che la modalità smode4 consumi meno della 3, ma si tratta davvero di pochissimo! riguardo a quale si vede meglio? forse la 3... o la 4?
Grazie stealth per la gradita info

 

[stealth82]

Eppure ragazzi a me sembra che la modalità smode4 consumi meno della 3, ma si tratta davvero di pochissimo! riguardo a quale si vede meglio? forse la 3... o la 4?

Ho una bella rispostina - - direttamente dalla viva tastiera di Didée...

Posterization and aliasing is likely to happen with ultra-high values for "strength", or generally when "strength" is set too high for the chosen supersampling factor. If you're using no supersampling (ss_x=1.0 & ss_y=1.0), then aliasing will show up with much lower strength settings already. When no supersampling is used, Smode=4 might be better suited than the others, because of its non-linear response.
The "soft" parameter will help on all Smodes to prevent or reduce the introduction of aliasing and posterization.

Smode3 con supersampling (cioè ss_x e ss_y maggiori di 1.0) altrimenti è forse meglio lo Smode4. Questa sera ubbidisco (io non ce l'ho il SS )