HTPC, aiuto per la guida di ffdshow

Dubito che ce la faccia il proc.

avevo la stessa configurazione tua un tempo e anche se apaprentemente reggeva dopo qualche minuto audio e video andavano fuori sincrono.

per chi usa reclock.... vi e' capitato che su alcuni Mkv o Divx dia un errore all'inizio del film? uno mi pare dicesse "invalid float position..." o qualcosa del genere...

c'e' qualcosa da configurare su reclock che magari non ho fatto? io l'ho solo installato con i vari next e basta..

grazie

Citazione:

---

Originariamente scritto da enzinoxl

Chiedo scusa,
in base alla vostra esperienza (io ho un e6300 overclockato a 2500mhz, col quale non riesco ad impostare ancora quello che voglio), che processore sarebbe realmente perfetto per un esclusivo utilizzo di ffdshow ed a parità di velocità un quad è meglio di un duo?

---

...mi permetto di richiedere...

In questi giorni sto approfondendo quanto il multithread sia frainteso per il post-processing. Il punto è che il suo impiego non abbatte affatto il consumo sui picchi ma velocizza soltanto il tempo di esecuzione, facendo così terminare l'elaborazione in minor tempo. Tutto bene finchè si parla di pre-processing (ambiente offline) ma poco bene per chi tali elaborazioni le esegue on-the-fly come noi... Che significa?

A parità di clock, avere una chiamata dichiaratamente sforata su single core significa averne una anche per il multi core.
Ma allora, dove sta il vantaggio? Semplice: nell'ottimizzare quella poca percentuale di CPU non sfruttata.

Pensando al single thread non ci viene difficile capire come il tutto venga processato frame per frame. Ciascun frame, tuttavia, differisce dall'altro per composizione d'informazioni... alcuni sono "facili" da processare, altri meno. Questo si traduce in un tempo di elaborazione che varia costantemente a seconda della complessità dell'immagine. A volte la CPU si sbriga prima, altre volte meno. In single core è impossibile salvare quei cicli "risparmiati" per ridestinarli altrimenti, vengono semplicemente "droppati" in attesa che il successivo frame "salga in cattedra".

Ecco dove interviene il multi-core. Attraverso il multi-thread abbandoniamo la linearità del funzionamento per impiegare i cicli inutilizzati in un'anticipazione dell'elaborazione dei frames successivi. Ci prendiamo avanti insomma :D. Maggiori sono i core, maggiori sono i threads instanziabili...
Il fatto è che non possiamo esagerare con la chiamata sperando che il multicore faccia il miracolo. Se la CPU è impiccata su di un core per un singolo frame, non pensate che lo saranno anche gli altri per i successivi? Se non c'è alcun risparmio di cicli macchina noi cosa anticipiamo che siamo presi male? :D

P.S. Ho scritto come mi è venuta a quest'ora... anche se fatto di fretta spero si capisca qualcosa...

Citazione:

---

Originariamente scritto da enzinoxl

...mi permetto di richiedere...

---

Il più potente possibile. Con ffdshow non si arriva mai :D

Cmq sia quad core è leggermente meglio ;)

Citazione:

---

Originariamente scritto da stealth82

In questi giorni sto approfondendo quanto il multithread sia frainteso per il post-processing. Il punto è che il suo impiego non abbatte affatto il consumo sui picchi ma velocizza soltanto il tempo di esecuzione, facendo così terminare l'elaborazione in minor tempo. Tutto bene finchè si parla di pre-processing (ambiente offline) ma poco bene per chi tali elaborazioni le esegue on-the-fly come noi... Che significa?

A parità di clock, avere una chiamata dichiaratamente sforata su single core significa averne una anche per il multi core.
Ma allora, dove sta il vantaggio? Semplice: nell'ottimizzare quella poca percentuale di CPU non sfruttata.

Pensando al single thread non ci viene difficile capire come il tutto venga processato frame per frame. Ciascun frame, tuttavia, differisce dall'altro per composizione d'informazioni... alcuni sono "facili" da processare, altri meno. Questo si traduce in un tempo di elaborazione che varia costantemente a seconda della complessità dell'immagine. A volte la CPU si sbriga prima, altre volte meno. In single core è impossibile salvare quei cicli "risparmiati" per ridestinarli altrimenti, vengono semplicemente "droppati" in attesa che il successivo frame "salga in cattedra".

Ecco dove interviene il multi-core. Attraverso il multi-thread abbandoniamo la linearità del funzionamento per impiegare i cicli inutilizzati in un'anticipazione dell'elaborazione dei frames successivi. Ci prendiamo avanti insomma :D. Maggiori sono i core, maggiori sono i threads instanziabili...
Il fatto è che non possiamo esagerare con la chiamata sperando che il multicore faccia il miracolo. Se la CPU è impiccata su di un core per un singolo frame, non pensate che lo saranno anche gli altri per i successivi? Se non c'è alcun risparmio di cicli macchina noi cosa anticipiamo che siamo presi male? :D

P.S. Ho scritto come mi è venuta a quest'ora... anche se fatto di fretta spero si capisca qualcosa...

---

Interessante. Tra l'altro, effettivamente, con l'utilizzo dell'istruzione MT aumenta l'uso della seconda cpu, quindi questa viene comunque sfruttata. Ergo lo scopo del MT è raggiunto.

Comunque, molto più interessante:

Citazione:

---

Originariamente scritto da stealth82

Spero di farcela e di non essere sotterrato prima :D

Un'altra novità a cui vi introdurrò è un denoiser Avisynth totalmente a carico della GPU. Avete capito bene: finalmente la scheda video farà qualcosa e, di conseguenza, ci sarà più potenza CPU da ripartire per qualcos'altro.

Le schede video supportate partono da: NVIDIA GeForce series 5 in poi, Ati Radeon 9500 in poi. Insomma una che supporti DirectX9.

NVIDIA è più beneficiata, più che altro per il controllo prestazioni che si può implementare attraverso NVPerfHUD; una sorta di Task Manager del processore.

E' in grado pure di fare un po' di sharpening ma mi sembra di capire che non sia ai livelli di LSF. Da verificare è anche la comparativa con il famoso hqn3d.

Che vi sembra? Interessante?

---

Se ne sa più nulla? :D

Domanda: perché se uso lo script per SeeSaw postato da f_carone mi appare questo errore:
http://xs123.xs.to/xs123/08053/grab000020335.jpg

??
Lo script di f_carone:

Citazione:

---

Originariamente scritto da f_carone

Non vorrei essere OT ma con questa:
MT("SeeSaw(Sstr=2.9, Szp=1, Slimit=50, Sdamplo=6)",5)

al posto di LSF:
MT("LimitedSharpenFaster(ss_x=1.0, ss_y=1.0, Smode=4, strength=90, wide=false, overshoot=0, soft=10)",5)

ottengo una sorta di effetto tridimensionale sull'immagine, da valutare con piu calma, ...ma quanto pesa? Ci vorrebbe un quadcore.

ciao,
fil

---

Sono sicuro che SeeSaw è nella cartella plugins. Quindi, perché me lo da come mancante?:confused:

Non uso seesaw da parecchio tempo ma mi ricordo che oltre allo "script" bisognava installare altri plugins perchè funzionasse....vado a memoria...mi ricordo ad esempio soothe


ciao sebi

Citazione:

---

Originariamente scritto da kache

Se ne sa più nulla? :D

---

Ehm, mi ritrovo con il tempo che mi ritrovo. Al momento la guida sta procedendo frase per frase alla velocità di giorno per giorno, in pratica una frase al giorno :D

Spero di riuscire a cambiare questo trend. Portate pazienza.

Citazione:

---

Originariamente scritto da kache

Domanda: perchè se uso lo script per SeeSaw...

---

Di SeeSaw non mi interesso affatto visto che altro non è che un denoiser + sharpener. Io le cose le faccio separate :D

Citazione:

---

Originariamente scritto da stealth82

In questi giorni sto approfondendo quanto il multithread sia frainteso per il post-processing. ..... In single core è impossibile salvare quei cicli "risparmiati" per ridestinarli altrimenti, vengono semplicemente "droppati" in attesa che il successivo frame "salga in cattedra".......Se la CPU è impiccata su di un core per un singolo frame, non pensate che lo saranno anche gli altri per i successivi? Se non c'è alcun risparmio di cicli macchina noi cosa anticipiamo che siamo presi male?

---

Molto interessante... In soldoni, la frequenza conta molto di più... Sempre a parità di frequenza posso anche passare da un single core ad un duo, dove dovrei agevolarmi almeno un pò della possibilità del risparmio di alcuni cicli, ma la differenza tra un duo ed un quad non sarà enormemente sensibile perchè se il post processing, avendo ipotizziamo un flusso video con una serie di frame molto pesanti da elaborare, sta impiccando due core, ne impiccherà comunque anche quattro...

Ho detto fesserie, stealth82?

Citazione:

---

Originariamente scritto da kache

Sono sicuro che SeeSaw è nella cartella plugins. Quindi, perché me lo da come mancante?:confused:

---

qui trovi tutti i plugin che ti servono per il SeeSaw (in fondo alla pagina)
http://www.avsforum.com/avs-vb/showthread.php?t=719041

ciao

Citazione:

---

Originariamente scritto da enzinoxl

Ho detto fesserie, stealth82?

---

No, come dici tu - in soldoni, è proprio così.

Grazie infinite, il tuo aiuto è sempre prezioso, sono più che soddisfatto. Colgo l'occasione, dato che non l'ho mai fatto prima, di dirti quanto sei stato fenomenale con la tua guida. Ho scoperto ed iniziato ad usare il post processing proprio con te e, per me, è stato come quando gli uomini primitivi hanno scoperto il fuoco. Non riesco a vedere più nessun filmato o dvd, se non uso ffdshow. Grazie davvero.

Citazione:

---

Originariamente scritto da mamach

Di recente sono stato costretto a formattare il mio HTPC e con l'occasione ho installato XP Pro al posto di MCE2005.
Ora però non riesco più a configurare ffdshow a mio piacimento (su MCE2005 mai nessun problema in questo senso).
Il problema è questo:
se imposto raw video su all supported o all YUV, ffdshow si infila dappertutto come postprocessor (codec nvidia Pure video) dai DVD (e mi sta bene) alla TV ai video (e mi sta meno bene).
Eppure i settaggi sono sempre gli stessi, i merit pure e su Mediaportal non ho configurato nessun tipo di postprocessor.
Se setto invece raw video su disabled, ffdshow parte solo quando è chiamato.
Però non mi sembra un comportamento corretto.

Un'altro problema che su MCE2005 non avevo è che se non disabilito su ffdshow mpgeg2, ho problemi di deinterlacciamento)
EDIT: in quest'ultimo caso il problema è dato dal fatto che ffdshow parte direttamente come codec (anche se su Mediaportal ho impostato Nvidia).

Dove sbaglio??

ciao

---

nessuno sa dirmi perchè ffdshow su XP Pro funziona all'incontrario di come funzionava su MCE2005? (almeno a me:D )
ciao

Come sapete, utilizzando Avisynth bisogna inserire la Avisynth.ddl all'interno della cartella Windows/System32: volevo segnalare un'anomalia che questa operazione comporta e che, inizialmente, fu scambiata per un problema della versione 2.6 di TheaterTek.

La versione 2.5.7.0 - contenuta nei plugin dello Stealth pack - fa sì che, riducendo TheaterTek a finestra quando si è in modalità "WRM9 Exclusive", non si riesca a riprendere la visualizzazione, ottenendo la segnalazione di errore "TheaterTek non è in grado di ricostruire il filter graph".

Il problema può essere superato o rinunciando alla "visualizzazione Full screen exclusive" (in questo modo la riduzione a finestra non manda in crash TheaterTek), oppure inserendo la versione 2.5.6.0 della Avisynth.ddl, che funziona regolarmente anche con le versioni più aggiornate del programma stesso (testata con Avisynth 2.5.7 e 2.5.8Alpha).