HTPC, il post-processing (ffdshow)

[stealth82]

Preambolo
ffdshow è uno strumento dalle mille possibilità: configurararlo come si deve, senza una linea d'azione ben definita, potrebbe causare un notevole stress mentale. La guida si propone quindi di spiegare facilmente questo complesso argomento. Una breve carrellata:

ffdshow
ffdshow è senza dubbio il tool che più di ogni altro ha preso posto nel variegato mondo dell'HTPC. Il motivo è semplice: è in grado di "migliorare" - almeno a livello percettivo - la resa video di una sorgente video SD (Standard Definition) restituendone, in tempo reale di playback, un'immagine più dettagliata, compatta e profonda. Naturalmente questo non è il solo scopo/uso di ffdshow ma di sicuro è ciò che lo rende di così gran valore.

AviSynth
AviSynth è un free frameserver per il video editing, gestito interamente da scripts. Si posiziona ad un livello intermedio della catena: tra la sorgente video originale ed il programma ricevente (quale può essere un player, un video editor od un encoder). E' in grado di applicare un vasto range di funzioni di editing/processing (ciò che in questo caso interessa particolarmente) e, cosa più importante, è integrabile; questo lo rende uno strumento utile e potente per arricchire il pacchetto "base" ffdshow.

DScaler 4.x
Software per la cattura video e processing/scaling. Anch'esso supportato da ffdshow, è utile per aggiungere nuove funzionalità (filtri).

Premesse

1. I risultati ottenibili con il post-processing sono a volte straordinari. Tuttavia è bene ricordare che abilitare ffdshow disattiverà automaticamente la spinta accelerativa (DXVA*, e relativi benefici della tecnologia built-in) della scheda video a sostegno della riproduzione. L'interò processo graverà quindi sulle spallucce (fragili o robuste, dipende dai MHz) della CPU.
   
   * DXVA: DirectX Video Acceleration
   
   
2. Figlia della prima premessa... AviSynth era già conosciuto nell'ambiente come ottimo tool per gestire il post-processing prettamente in ambito off-line. Grazie al miglioramento di librerie e scripts - unito all'avvento di CPU sempre più potenti - sì è raggiunto l'obbiettivo di implementare on-the-fly tale gestione. La power request si mantiene tuttavia alta; CPU potenti, se non multi-core, si possono definire fondamentali.
   
   
3. I risultati ottenibili possono variare da catene a catena. A influenzarli ci sono: scheda video, decoder, output video. Infine, usando come metro di paragone gli occhi, i gusti personali influenzano la decisione finale. Non esiste, pertanto, la configurazione perfetta ma tante buone configurazioni.

[stealth82]

I downloads
Preparare l'ambiente è la cosa più facile, tuttavia prestare la giusta attenzione rimane importante.
Localizzate e scaricate (i links sono disponibili, sotto la sezione codecs, qui):

• DScaler 4.1.15
• AviSynth 2.5.7
• stealth82's v2.0 pack
• ffdshow tryout clsid sse icl10

L'installazione

1. Installate DScaler: semplicemente cliccate avanti fino alla fine.
2. Installate AviSynth: semplicemente cliccate avanti fino alla fine.
   
   Installate i plugins
   Dal gruppo AviSynth 2.5 nel menu programmi cliccate Plugin Directory; si aprirà una subfolder del percorso di installazione.
   
   
   
   Scompattate lo stealth82's v2.0 pack in tale subfolder seguendo le note a seguito riportate:
   
   CPU (single-thread / multi-thread)
   Scompattare tutti i files dell'archivio tranne MT.dll ed il subpack System32.zip.
   Scompattare, dal subpack System32.zip, il file fftw3.dll nella cartella C:\Windows\System32.
   
   CPU (multi-thread)
   Scompattare MT.dll.
   Scompattare, dal subpack System32.zip, il file avisynth.dll nella cartella C:\Windows\System32 sostituendo quello esistente (per sicurezza fare un backup).
   
   Attenzione!!
   Nel caso stiate usando Windows 7 64bit il file avisynth.dll è da scompattare nella cartella C:\Windows\SysWOW64
   
   
3. Installate ffdshow: (possibilmente in lingua inglese) prestando attenzione a spuntare le opzioni selezionate nelle seguente schermata in maniera tale da attivare il supporto per AviSynth e DScaler.
   
   

[stealth82]

Lo spazio colore
La "tavolozza colori" sulla quale viene registrata e visualizzata un'immagine è un aspetto importante e deve essere tenuto in considerazione. Non solo determina la quantità di informazioni video presenti in ogni singolo frame ma influenza il risultato. Gli spazi colore più conosciuti sono RGB16/RGB24/RGB32 e YUV/YUY2/YV12.

Il DVD - supporto comune nel nostro campo - lavora su YV12 (YUV) e, come lui, anche molti filtri ffdshow/AviSynth. Ricordare questo concetto è vitale: da esso dipendono le prestazioni della catena di post-processing e la qualità finale.

Le prestazioni saranno influenzate dallo spazio colore in ingresso così come da quello in uscita: molti filtri possono lavorare solo in YV12 ed effettueranno una conversione, laddove necessario, facendo così gravare un'ulteriore operazione sul processore. Lo stesso dicasi per l'output d'uscita: variare lo spazio colore impegnerà ulteriormente il processo di elaborazione. La qualità sarà influenzata: maggiore sarà il numero di conversioni, maggiore sarà la perdita di dati video utili; ciascuna conversione comporta inevitabilemente un degrado delle informazioni video.

Buona norma, perciò, è assicurarsi sempre di far lavorare il proprio decoder video su spazio colore YV12 agevolando così il post-processing. Impostiamo, a scopo cautelativo, ffdshow in modo tale che riceva per il formato Raw video - cioè proveniente da un primo lavoro del nostro decoder - solamente YV12. Questo ci permetterà di capire se il "primo anello della catena" funziona come vogliamo noi.

Selezioniamo alla tab Codecs, alla voce Raw video il valore YV12:



L'Output, l'ultimo anello della catena - a meno di coscienti preferenze personali, è correttamente impostato in questo modo:

[stealth82]

I filtri
I filtri a disposizione di ffdshow sono facilmente consultabili ed attivabili attraverso il navigatore sinistro del programma. In partenza, ffdshow non presenta alcun filtro attivo ma abilitarli è una cosa semplice: basterà spuntare la checkbox a fianco di ciascun nome per ottenerne l'inserimento in catena.



L'ordine dei filtri
Un ulteriore coefficiente di difficoltà risiede nella possibilità di stabilire l'ordine in cui ciascun filtro applicato verrà eseguito. In generale, come vedremo, i filtri che compongono una catena rispettabile sono di tre tipi: denoiser, sharpener, resizer. Seguire una buona linea di pensiero nell'applicarli ci permetterà di evitare sprechi di sorta, impedendo che gli effetti positivi ottenuti da ciascun d'essi siano annullati da altri.

Gli ordini sono questi:

Metodo 1 (preferibile)

1. Resizer
2. Denoiser
3. Sharpener

In questo caso la priorità viene data al resizer. L'immagine così upscalata verrà processata alla nuova risoluzione dai restanti filtri. E' il metodo più dispendioso in termini di CPU ma tuttavia il più fedele. Dispendioso perchè i filtri dopo il primo lavoreranno su di un area molto maggiore rispetto alla sorgente originale aumentando di conseguenza il tempo di computazione. Fedele perchè l'immagine originale processata sulla base di una nuova risoluzione impedirà che enfatizzazioni di denoiser e sharpener subiscano successive manipolazioni.

Metodo 2 (preferibile)

1. Denoiser
2. Resizer
3. Sharpener

In questo caso è invece il denoiser a guidare la catena. Può essere un metodo altrettanto valido, sicuramente meno dispendioso in termini di CPU - perchè almeno un filtro lavora su di un area sensibilmente più piccola, ma altrettanto valido. Il pensiero cambia leggermente: si parte dal presupposto che la sorgente possa presentare rumore video e che ingrandirlo mediante resizer non sia cosa buona e giusta. Riducendolo, invece, se ne impedisce la propagazione lasciando invece al solo sharpener il compito di affilatura finale.

Metodo 3

1. Denoiser
2. Sharpener
3. Resizer

Personalmente la trovo una cattiva scelta. Le correzioni introdotte dai primi due filtri - specialmente lo sharpener - possono essere tali da falsare il risultato del resizer il quale restituirebbe, come prodotto finale, un'immagine poco compatta e soprattutto "seghettata" all'altezza delle linee di contrasto. Lo sharpener, infatti, interpola un'immagine in maniera tale da rendere più marcate le variazioni di contrasto tra pixels adiacenti; il che significa trasformare - se guardata pixel per pixel - una "morbida" linea curva in una scalettata. Applicando a posteriori il resize le scalettature prodotte verrebbero proporzionalmente enfatizzate producendo così un effetto collaterale quantificabile in una sensazione di minor continuità e morbidezza globale. Tuttavia rimane l'ultima spiaggia per chi ha a disposizione poche risorse hardware.

Ordinare i filtri è semplice: basta cliccare sulle frecce di transizione (alto / basso) presenti a fianco di ciascuna filter checkbox.
Per reimpostare l'ordine originale è sufficiente fare click su Reset order.

Approfondimento
In maniera leggermente differente si determina l'ordine dei filtri AviSynth. Come vedremo successivamente, tale sezione lavora in maniera indipendente da ffdshow, il quale semplicemente fornisce una "porta" alle istruzioni date. Il filtro AviSynth perciò, pur essendo soggetto alla catena ffdshow, determina il proprio corso mediante l'ordine in cui si susseguono le istruzioni, le quali sono rigorosamente compilate a mano. Per suddividere ciascuna istruzione è sufficiente rispettare la separazione di linea.

[stealth82]

Il denoiser
Il denoiser è preposto all'attenuazione del rumore (noise) video presente. I più diffusi sono:

• Gradual Denoise
  Il meno esoso in termini di prestazioni CPU. La qualità è tuttavia buona, ma non eccelsa.
  
  Posizione: Blur & NR, opzione Gradual Denoise.
  Valori di partenza: 40.
  
  
  
  
• denoise3d
  Discreto, alta incidenza sul frame. La qualità è di tutto rispetto, come anche il consumo CPU.
  
  Posizione: Blur & NR, opzione denoise3d.
  Valori di partenza: luma 0.50, chroma 0.50, time 5.00.
  Consigli: Se la CPU lo permette spuntare HQ per una maggiore qualità.
  
  
  
  
• HQdn3d (AviSynth)
  Eccellente ma dal consumo CPU importante. Se la CPU lo permette è quasi una scelta definitiva.
  
  Posizione: AviSynth.
  Istruzione:

  hqdn3d(2)

  Consigli: Il numero tra parentesi determina il grado di incidenza del filtro.
  Un valore superiore a 5 è sconsigliato in quanto introdurrà effetti collaterali quali perdita di dettaglio.
  
  
  
  
• RemoveGrain (AviSynth)
  Nella sua semplicità si difende.
  
  Posizione: AviSynth.
  Istruzione:

  RemoveGrain(mode=2)

  Consigli: L'argomento tra parentesi (l'intero dopo mode=, in questo caso il numero 2) determina il grado di incidenza del filtro. Va da 1 a 10.
  Un valore superiore a 2 inciderà sulle prestazioni e sul dettaglio (a 2 mantiene ancora buona "coscienza").
  
  
  
  
• mergeluma + RemoveGrain (AviSynth)
  Versatile.
  
  Posizione: AviSynth.
  Istruzione:

  mergeluma(RemoveGrain(4, -1), 0.08)

  Variante:

  mergeluma(RemoveGrain(2, -1), 0.25)

  Consigli: Prendere in considerazione solamente l'ultimo parametro dell'istruzione. Va da 0.08 a 2.
  Un valore superiore a 0.75 inciderà sul dettaglio compromettendone la resa.
  Utilizzare la variante per un risultato meno aggressivo. Va da 0.25 a 0.50.
  
  

[stealth82]

Lo sharpener
Lo sharpener incrementa la nitidezza del frame enfatizzando le variazioni di contrasto tra pixels adiacenti. La sensazione è una diminuzione della morbidezza dell'immagine a favore di un effetto affilatura dei contorni, percepibile come una sensazione di "maggior dettaglio" video. I più diffusi sono:

• unsharp mask
  E' il filtro più comune. Il consumo CPU non è elevato.
  
  Posizione: Sharpen, opzione unsharp mask.
  Valori di partenza: 21.
  Consigli: Non esagerare con il valore. Gli artefatti (halos, degradazione) sono dietro l'angolo.
  Un valore superiore a 40 introdurrà inevitabilmente "sporcature".
  
  
  
  
• asharp
  Del tutto simile all'unsharp, come risultato e consumi. Il boost, a parer mio, lo ha processando materiale "animato" (cartoni, cg): molto più incisivo.
  
  Posizione: Sharpen, opzione asharp.
  Valori di partenza: high quality block filtering, threshold 1.8, strength 3.5, sharpening 0.
  Consigli: Fate attenzione, i diversi triggers, se mal bilanciati, portano presto al rovinamento dell'immagine.
  Segnalazione: by Marlenio.
  
  
  
  
• Sharpness (DScaler)
  I consumi si attestano come leggermente superiori agli sharpeners precedentemente illustrati.
  
  Posizione: Dscaler filter, libreria FLT_Sharpness.dll.
  Valori di partenza: Sharpness 128, Fast Memory Access.
  Segnalazione: by ciuchino.
  
  
  
  
• AdaptiveNoise (DScaler)
  I consumi si attestano come leggermente superiori agli sharpeners precedentemente illustrati.
  
  Posizione: Dscaler filter, libreria FLT_AdaptiveNoise.dll.
  Valori di partenza: Stability 20, Fast Memory Access, Noise Reduction 45, Spatial Smoothing (Enable), Spatial Smoothing (Percent) 140.
  Consigli: Il filtro è particolarmente indicato per il trattamento di materiale televisivo.
  
  
  
  
• LimitedSharpenFaster (AviSynth)
  Filtro rivelazione. Ciò che lo rende tanto speciale è la capacità di coniugare i punti di forza dei più diffusi sharpeners (UnsharpMask(), Sharpen() e MinMaxSharpen()) senza per questo soffrire delle rispettive debolezze ("edge halos", "jaggyness").
  Si avvale di istruzioni quali RemoveGrain, LanczosResize e WarpSharp.
  
  
  Approfondimento
  I limiti fisiologici dei comuni sharpeners si presentano alquanto precocemente il che impedisce di spingersi oltre una certa soglia di "affilatura". Il LSF - mediante parametri di controllo contenitivi - è in grado di spingersi più avanti. Come? Eseguendo le seguenti operazioni di routine:
  
  
  

  1. Applica un normale sharpener (quale può essere uno dei tre elencati precedentemente)
  2. Confronta ogni singolo pixel "trattato" con quelli adiacenti - chiari e scuri - del frame originale
  3. Se rientra con un valore di gradazione intermedia accettabile viene mantenuto altrimenti, se sottoesposto/sovraesposto viene "limitato"

  
  
  Ci si rende presto conto che tale filtro non ha eguali nell'applicazione intelligente del trattamento.
  
  Posizione: AviSynth.
  Istruzione:

  LimitedSharpenFaster(ss_x=1.0, ss_y=1.0, Smode=4, strength=40, wide=false, overshoot=7)

  Consigli:
  • ss_x=, ss_y=: abbreviativo di supersampling (asse orizzontale - x, asse verticale - y), determina la qualità dell'operazione. Più alto sarà il valore, minori saranno gli artefatti (halos). Compatibilmente con la disponibilità CPU è possibile aumentare entrambi i valori - ad es. 1.1, 1.2, 1.3 - fino ad ottenere il massimo risultato con 2.0. Ad 1.0 il supersampling non opera e risulta quindi essere "spento".
    
    Default 1.5.
  • Smode=: sharpener utilizzato.
    
    1 = UnsharpMask()
    2 = Sharpen()
    3 = MinMaxSharpen() (range sharpening)
    4 = MinMaxSharpen() (nonlinear sharpening)
    
    L'ordine in cui si susseguono determina anche la progressione qualitativa del trattamento. Da 1 - più haloing - a 4 - meno haloing; maggiore sarà il valore, maggiore sarà la qualità finale. Il consumo CPU è anch'esso proporzionale.
    
    Default 3.
  • strength=: l'incidenza del filtro.
    
    Smode 1: 0-127 (simple sharpening), 128-255 (simple overdrive), 255-4096 (big overdrive).
    Smode 2: 0-100, > 100 (rimappati a 100).
    Smode 3/4: 0-100 (oltre a vostro rischio).
    
    Default 160 per Smode 1, 100 per Smode 2/3/4.
  • radius=: applicabile solo a Smode 1, determina la grandezza alla quale saranno soggetti gli halos prodotti. Maggiore sarà il valore, più evidente sarà il risultato di contrasto.
    I valori vanno da 1 a 10.
    
    Default 1.
  • wide=: determina il numero pixels campione, oggetto di confronto rispetto al pixel "trattato". Se false l'area utile è 3x3, se true 5x5. Utilizzare true solo in congiunzione con alti valori di supersampling (ss_x, ss_y) o in presenza di sorgenti molto "morbide".
    
    Default false.
  • overshoot=: parametro limitatore come descritto nel punto 3 dell'approfondimento.
    I valori vanno da 0 - rigido - a 128 - permissivo; a tale livello il LSF è completamente inutile.
    
    Default 1.
  • soft=: ammorbidisce l'effetto di affilatura. Impostato a -1 il valore verrà autocalcolato per il miglior compromesso.
    I valori vanno da 0 - affilato - a 100 - morbido.
    
    Default 0.
  
  Segnalazione: by capitano.
  
  

[stealth82]

Il resizer
Il resizer aumenta la risoluzione originale del frame e restituisce un'immagine più compatta, profonda e dettagliata. Questa operazione, detta anche upscaling, generando algoritmicamente nuove informazioni video, moltiplica le linee di scansione.

Approfondimento - l'algoritmo
Allo stato attuale sussistono diversi algoritmi applicabili a tale filtro. I più conosciuti sono: Bicubic, Bilinear, Gauss, Lanczos, Point e Spline (16, 32). Ciascuno d'essi, naturalmente, porta ad avere differenti risultati: si distinguono tanto per la morbidezza del risultato quanto per il consumo CPU.

Parlando di morbidezza del risultato la questione si fa alquanto filosifica, in maniera simile a quello che è stato l'argomento sull'ordine dei filtri. La puntualizzazione è d'obbligo: non tutti i resizer si limitano a produrre un risultato così detto neutro - il che può essere un bene e/o può essere un male. Può essere un bene poichè nel nostro ambito specifico tali resizer possono facilmente fondere la capacità di due differenti filtri - resizer/sharpener - beneficiando così di un consistente risparmio CPU. Può essere un male, invece, se si desidera ottenere la massima qualità da entrambi i processi mantenendoli a tal fine separati. Non è detto che sia vietato usare un resizer sharpener a monte di uno sharpener dedicato, tuttavia il risultato sarà un'inevitabile mescolanza di processi affini ripetuti più volte. Potrebbe anche tradursi in un maggior senso di nitidezza, lungi però dall'essere il corretto modo di operare (vedere nuovamente l'ordine dei filtri al metodo 3). Meglio lavorare sulla forza dello sharpener.

In termini di bilanciamento i migliori risultati - prestazioni/qualità - si ottengono con Spline16 per un effetto neutral e Lanczos per un effetto sharp.

Risultati comparativi

Approfondimento - la risoluzione
Ulteriore aspetto da tenere in considerazione è la risoluzione di output.

Sebbene il rapporto 1:1 sia quasi sempre scontato quando si tratta di pilotare il display o vpr che sia, non lo è poi così tanto quando si parla di upscaling. Nulla vieta, infatti, di eseguirne uno superiore alla reale risoluzione di uscita. Il beneficio? Gestire il downsize in hardware attraverso la scheda video per ottenere un nuovo risultato. La questione è tanto controversa quanto la precedente. Si tratta di capire se il guadagno in termini di qualità valga l'adottamento. Per alcuni è così, per altri un po' meno... il processo eseguito dalla scheda video sembrerebbe rendere appena poco più convincente il risultato su tecnologia CRT, viceversa, nel dominio digitale i benefici sono indistinguibili al punto tale da ridurre la cosa ad un complicato esercizio di stile.

Detto questo, se visivamente la differenza si fa sottile, a livello CPU non lo è affatto: il resize è l'unico filtro che influenza pesantemente il rendimento globale. Maggiore è la risoluzione, maggiore sarà il consumo processore - sia per il filtro in sè che per tutti i posteriori.

Approfondimento - il bug dei DVD menus e degli aspect-ratios
Problema di vecchia data è sempre stato quello di avere a che fare con la "corruzione" dei DVD menus. Bug impossibile da riscontrare usando la tastiera, fastidioso ed irritante usando invece il mouse. Per chi ha sperimentato il fenomeno il risultato si traduceva in un disallineamento tra la posizione di click del mouse e le rispettive voci dei menus. Non solo questo ma anche problemi legati all'aspect-ratio, black screens etc., erano luogo comune.
Come venirne a capo? Difficile: per molto tempo è rimasto un problema insoluto.

Le cose poi sono finalmente cambiate con l'avvento del resize dinamico (calcolo su di un unico asse). Sperimentando resize fissi, infatti, non si poteva gestire correttamente lo strano rapporto che contraddistingue i DVD: la famosa risoluzione di 720x576. Strana davvero perchè anche un DVD 16:9 è dotato del medesimo formato. Di conseguenza, applicando un resize arbitrario la non proporzionale risoluzione applicata ai DVD menus causava il difetto di navigazione. Causava anche problemi nella gestione degli aspect-ratio stessi, come detto, che non venivano più rispettati e dovevano quindi essere corretti manualmente.

Per concludere nulla vieta di continuare ad usare un resize fisso, ma l'unico modo per evitare le problematiche esposte risiede nell'applicare il resize in maniera dinamica.

Approfondimento - l'esecutore materiale
ffdshow e AviSynth offrono quasi specularmente un vasto ventaglio di opzioni legate al resize. A volte alcune di queste differiscono tra loro, così come il consumo CPU - quest'ultimo leggermente a favore di ffdshow - ma sostanzialmente le carte a disposizione si assomigliano. Avanzando un'opinione, a seguito anche di qualche esperienza maturata sul campo, direi cmq che la miglior qualità finale sia a favore di AviSynth. Non chiedetemi il perchè - sebbene a parità di algoritmo il risultato non dovrebbe cambiare - ma è così. Si parla cmq di difetti di visualizzazione in determinate circostanze e a determinate risoluzioni.

Per concludere l'equazione è: ffdshow = -qualità = -consumo, AviSynth = +qualità = +consumo.

[stealth82]

• ffdshow
  Il resize ffdshow si compone principalmente di due finestre di opzioni: la prima dedicata alla risoluzione, la seconda dedicata all'algoritmo.
  
  Posizione: Resize & aspect.
  Valori di partenza: specify horizontal and vertical size, new size 1280 x 720, resize if x < 1280 or y < 720, no aspect ratio correction.
  Variante (fixed):
  
  
  Variante (dynamic):
  
  
  Variante (Spline):
  
  
  Variante (Lanczos):
  
  
  Consigli:
  
  • Resize if: Per evitare resizes indesiderati è sempre consigliato specificare una condizione che verifichi la risoluzione del materiale prima di applicare il filtro. Generalmente si imposta una condizione in pixel - sia per l'asse X e/o per l'asse Y - che risulti appena inferiore alla risoluzione finale.
  • Resize settings: generalmente applicato per Luma e Chroma (Lock), l'algoritmo di resize fornisce alcune opzioni sulle quali operare. Generalmente queste opzioni applicano un fattore di sharpening. Farne uso o meno è solo questione di necessità imposta. Se la CPU non è in grado di svolgere uno sharpener dedicato questa potrebbe essere l'unica alternativa.
    
    Come descritto in precedenza, il metodo Lanczos è generalmente il più adatto allo scopo. Proporzionalmente al consumo CPU, è possibile inoltre intervenire sui taps - 4 è il valore migliore per l'upsampling - ed enfatizzare ulteriormente lo sharpening.
  
  
  
• AviSynth
  In AviSynth il tutto è racchiuso nella "solita" casella di istruzioni il che richiederà, in alcuni casi, maggiore uso dello script.
  
  Posizione: Resize & aspect.
  Variante (Spline16 fixed):
  

  Spline16Resize(1280, 720)

  Variante (Spline16 dynamic):
  

  ffdshow_setDAR(ffdshow_dar_x, ffdshow_dar_y)
  DisposeAxis(1280, 720, ffdshow_dar_x, ffdshow_dar_y)
  Spline16Resize(da_w, da_h)

  Variante (Lanczos fixed):
  

  LanczosResize(1280, 720)

  Variante (Lanczos dynamic):
  

  ffdshow_setDAR(ffdshow_dar_x, ffdshow_dar_y)
  DisposeAxis(1280, 720, ffdshow_dar_x, ffdshow_dar_y)
  LanczosResize(da_w, da_h)

  Variante (algoritmi):
  

  BicubicResize(int width, int height)
  BilinearResize(int width, int height)
  GaussResize(int width, int height, float p)
  LanczosResize(int width, int height, int taps)
  PointResize(int width, int height)
  Spline16Resize(int width, int height)
  Spline36Resize(int width, int height)

  Consigli:
  
  • ffdshow_setDAR: funzione necessaria per conservare l'originale formato dell'immagine. Poichè AviSynth non contempla il concetto di aspect-ratio in sè, tale funzione - nativa di ffdshow - semplicemente lo ristabilisce. La funzione può essere invocata immediatamente, anche a monte del resize.
  • DisposeAxis: funzione adibita al calcolo dinamico di larghezza e altezza dell'immagine. La prima e la seconda variabile specificano larghezza e altezza massima per ciascun asse, la terza e la quarta il controllo dell'aspect-ratio (sempre larghezza e altezza). I valori restituiti - che si traducono in due variabili globali, da_w per larghezza e da_h per altezza - sono il risultato di un perfetto calcolo dinamico di entrambe le dimensioni; nessuna limitazione assi fissi ma massima dimensione d'output nel pieno rispetto del formato.
  • GaussResize: per l'algoritmo Gauss è possibile intervenire sul livello di incisività del resize: da 1 - veramente morbido - a 100 - veramente affilato.
    
    Default 30.
  • LanczosResize: come per ffdshow anche per la chiamata Lanczos di AviSynth è possibile intervenire sui taps. Basta specificarli come terzo parametro della chiamata. Es.:
    

    LanczosResize(da_w, da_h)

    La semplice chiamata LanczosResize corrisponderà ad una chiamata avente taps=3.
  
  
  

[stealth82]

La famiglia YCbCr
Uno degli aspetti più complessi che caratterizzano il mondo della rappresentazione video sono gli spazi colore - come si è accennato nel post dedicato a tale argomento - ma, naturalmente, poche parole non sono in grado di spiegare la straordinaria, seppur ordinata, "confusione" che vi regna. Ciò nonostante è un aspetto obbligatorio da considerare soprattutto in funzione del post-processing applicato. Così estendiamo, nella specifica necessità, il significato di YCbCr.

Il termine YCbCr o (Y'CbCr) indica una famiglia di spazi colore usata nei sistemi video e di fotografia digitale. Y' è il componente di luma mentre Cb e Cr indicano i componenti di crominanza e, nella maggior parte dei casi quando ci riferisce a segnali di tipo video o in forma digitale, "YUV" può ugualmente significare "Y'CbCr". Lo Y'CbCr non è uno spazio colore assoluto. È un modo di codificare l'informazione RGB, e i colori realmente visualizzati dipendono dai coloranti usati dal mezzo di visualizzazione.
I segnali Y'CbCr, prima di essere processati per ottenere un segnale in forma digitale, sono chiamati YPbPr, e sono creati dai corrispondenti primari RGB corretti in gamma usando due costanti Kb e Kr. Complicando dunque le cose, ad oggi coesistono due standard applicabili allo Y'CbCr che riporto di seguito:

• ITU-R BT.601: per la rappresentazione digitale del formato standard-definition (SD), SDTV e DVD.
  

  Kb = 0.114
  Kr = 0.299

• ITU-R BT.709: per la rappresentazione digitale del formato high-definition (HD), HDTV, HD-DVD e Blu-ray.
  

  Kb = 0.0722
  Kr = 0.2126

Non solo questo ma anche le definizioni per i primari R', G' e B' sono diverse, per cui una vera conversione da un tipo all'altro di YCbCr non è solo una questione matematica. In effetti, quando lo spazio colore YCbCr è usato correttamente, i valori Kb e Kr sono derivati dalle specifiche precise dei primari RGB.
Concludendo, due differenti modi di rappresentare l'immagine portano a due differenti risultati cromatici.

In che modo tale argomento ha qualcosa da spartire con il post-processing? Questi profili non vengono automaticamente applicati secondo i casi?

Da che spartire c'è eccome! Il resize, infatti, impedisce una corretta applicazione di tali profili: qualunque sorgente SD - naturalmente candidata alla rappresentazione mediante BT.601 - "upscalata" fino alla 720a linee verticale o più, verrà inevitabilmente rappresentata mediante il profilo BT.709, falsando di conseguenza il risultato. Tale comportamento da parte del sistema non è chiaro, si suppone sia un tentativo di interpretazione arbitraria del materiale il quale, possedendo una caratteristica importante propria dell'alta definizione (720p), richiede necessariamente l'applicazione del profilo BT.709. Traduzione per immagini?

Comparazione
A sinistra, la normale sorgente in BT.601.
A destra, la stessa sorgente "upscalata" ma rappresentata - nostro malgrado - in BT.709.

La differenza è netta ed il problema imprescindibile! Qualunque resize adottiamo, lato ffdshow o lato AviSynth, il risultato non cambia. L'unico modo di ovviare al problema è risolverlo! Vediamo perciò i due modi - o meglio uno, credo sarà chiaro il perchè - mediante i quali è possibile gestire la situazione.

• ffdshow
  La gestione del problema attraverso il solo ffdshow è piuttosto macchinosa. In breve l'unica possibilità è convertire lo spazio colore in RGB in fase di post-processing.
  
  Posizione: Output, RGB Conversion.
  Valori (Output): RGB32, RGB24, RGB16, RGB15, High Quality YV12 to RGB Conversion.
  Valori (RGB Conversion): ITU-R BT.601.
  Consigli: l'unico modo per invocare la conversione è negare l'output per i normali spazi colore YUV. Tale conversione impiegherà inevitabilmente cicli CPU; il peggior modo di sprecarli ma il passaggio è obbligato. La cosa peggiore è che, allo stato attuale, presenta difetti non trascurabili uniti ad una riscontrata incapacità di conversione con determinate sorgenti.
  
  
  
  
  
  
• ColorMatrix (AviSynth)
  Da considerarsi l'unica vera alternativa volta ad ovviare il problema, corregge i colori dell'immagine applicando uno specifico profilo di conversione.
  
  Posizione: AviSynth.
  Istruzione:

  ColorMatrix(mode="Rec.601->Rec.709")

  Consigli: la funzione può essere invocata immediatamente, anche a monte del resize.
  
  
  
  • hints=: parametro per il discovery automatico del profilo più idoneo.
    

    ColorMatrix(hints=true)

  • mode=: esclude automaticamente hints per il forcing del profilo.
  
  Segnalazione: by Neo85.
  
  

Fixing
Il fix dell'immagine mediante ColorMatrix

[stealth82]

UNDER REVISION

[stealth82]

Con l'avvento di CPU sempre più potenti - in termini di MHz - abbiamo conseguentemente visto nascere nuove tecnologie e soluzioni costruttive ad esse abbinate. Su tutte le estensioni a 64bit ed il multithreading (AMD Dual Core e Intel Hyper Threading e Dual Core).

Senz'altro vorremmo che queste due tecnologie fossere sfruttate al pieno delle loro possibilità; tuttavia, nella realtà, dobbiamo fare i conti con i "limiti" di sviluppo delle applicazioni che dovrebbero supportarle (è una mia speranza) e invece ancora non lo fanno; nel nostro caso ffdshow. Senza dubbio ne beneficeremmo alquanto, visto i "carichi" in gioco!

Parlare di questo sembrerebbe ancora presto ( ). Tuttavia, per Avisynth (guardacaso a supporto di ffdshow con filtri "importanti") - almeno sul lato multithreading - qualcosa da dire c'è.

Piccolo approfondimento
Il concetto di multithreading, per spiegarlo in poche parole, si basa su di un metodo di lavoro detto parallelo (seriale è l'opposto); svolgere più tasks contemporaneamente piuttosto che singolarmente (accodando i successivi). Per questo motivo tale tecnologia permette un incremento prestazionale ampiamente superiore a quello ottenibile con il semplice incremento di velocità di clock (i famosi MHz).

Tramite la funzione MT di Avisynth saremo in grado di trarre "reale" beneficio da questa nuova tecnologia. Infatti, se avete potuto notare, per alcuni dei filtri Avisynth illustrati precedentemente è stata indicata la possibilità di supporto multithreading. Ad implementarlo vi sono due metodi; a volte sarà utile impiegarli contemporaneamente (maggiori prestazioni):

• MT
  Inserite la funzione MT() racchiudendo la vostra corrente istruzione tra due doppi apici. Es:
  
  

  MT("hqdn3d(2)")

  Potete inoltre utilizzare la medesima istanza per includere più istruzioni, se è il vostro caso, dividendole con un "a capo" (vedete il post "i filtri, l'ordine") in questo modo:
  
  

  MT("hqdn3d(2)
  LimitedSharpenFaster(ss_x=1.0, ss_y=1.0, Smode=4, strength=40, overshoot=7)")

  
  
  Piccolo approfondimento
  Come applica il multithreading questa funzione? Ebbene, in poche parole, suddivide l'immagine in più parti permettendo di parallelizzare un processo altrimenti seriale. Tutte queste parti, infatti, vengono poi contemporaneamente processate, ed infine ricomposte, a formare nuovamente il frame completo.
• SetMTMode
  Inserite sempre questa istruzione come prima all'interno della textarea poichè essa determinerà il principale comportamento delle successive chiamate:
  
  

  SetMTMode(2, 0)

  In questa situazione le istruzioni successive usufruiranno della divisione di carico in base ai threads disponibili - dati dal secondo core, fisico o logico che sia. Nel dettaglio, la prima chiamata richiede due parametri ben distinti, le eventuali successive una:
  
  
  
  • Mode: determina la modalità di esecuzione del multithreading. Di seguito i possibili valori:
    
    1 = Il metodo più veloce ma funziona con pochi filtri.
    2 = Funzionante con la maggior parte dei filtri ma usa più memoria.
    3 = Funzionante con filtri non compatibili con mode 2 anche se risulta più lento.
    4 = Combinazione di mode 2 e mode 3 con supporto per ancora più filtri ma il doppio più lento ed usa più memoria.
    5 = Funzionante con la totalità dei filtri di tipo "linear frameserving"; in parole povere il multithreading risulta disabilitato; utile per ripristinare una sorta di "compatibility mode".
    6 = Versione modificata del metodo 5 ma leggermente più performante.
    
    Se doveste notare delle incompatibilità con i filtri utilizzati - in manifestazione di bugs, artefatti o simili - in modalità multithread default, (valore 2) alzate progressivamente il valore (fino a 5 o 6) alla ricerca della "safe working zone".
  • Threads: il numero di threads impiegabili per le operazioni multithreading. E' impostabile solamente con la prima chiamata - in assoluto - del metodo SetMTMode(). Mantenete il parametro sempre a valore 0 poichè, in questo modo, il filtro rileverà automaticamente il numero di "processori" disponibili.
  
  
  
  
  Come detto, potrebbero essere utilizzati dei filtri non troppo "avvezzi" al multithreading, vuoi per mancanza di supporto, vuoi per vera è propria inapplicabilità. Di seguito un esempio di ciò che potrebbe essere la gestione di una configurazione mista:
  
  
  
  
  Piccolo approfondimento
  SetMTMode() comincerà ad essere parte integrante di Avisynth dalla release 2.6. Risulta essere già disponibile in questa, la 2.5.6a, solamente grazie alla sostituzione della libreria avisynth.dll presente nella cartella system32 di Windows.

Note finali
Non fidatevi alla lettera degli esempi fatti. Purtroppo, non possedendo personalmente un processore multithreading, non sono in grado di comprovare o "affinare" quanto esposto; a maggior ragione in relazione a quanto sto per dirvi. In fase di premessa ho infatti dichiarato come fosse possibile utilizzare i due metodi - MT() e SetMTMode() - contemporaneamente. Il consiglio è provare tutte le possibili combinazioni: MT() singolarmente, SetMTMode() singolarmente ed infine MT() e SetMTMode() contemporaneamente (non lo dico io, lo dice l'autore). I consumi CPU potrebbero realmente differenziarsi!

[stealth82]

Sebbene il deinterlacing abbia ruolo marginale nel concetto di post-processing, a seguito dell'inibizione della DXVA - effetto collaterale, come abbiamo già detto, di questa scelta - i risultati ottenibili dall'accoppiata HW/SW in questo campo e in queste condizioni a volte si riducono al limite del "deplorevole". Fortunatamente - dicendo a volte - non è problema di tutti i giorni: vuoi per il materiale (correttamente "flaggato"), vuoi per buona prestazione del decoder (a monte). Tuttavia, se vi trovaste in questa spiacevole situazione potrete avvalervi di ffdshow, quale - ancora una volta - valido alleato, tramite il filtro di deinterlacing.

Tra i vari metodi ne spicca uno in particolare:

Abilitate il filtro Deinterlacing e selezionate, dal menu a tendina Method, il metodo 5-tap lowpass.
Il consiglio è sempre quello di anteporre, come primo, questo filtro rispetto alla restante catena; dopotutto meglio lavorare su un'immagine correttamente ricostruita, no?
Il consumo CPU non è elevato.



Sebbene - abbiamo detto - il deinterlacer possa essere un valido alleato, la filosofia, quasi controcorrente, è quella di non interpolare eccessivamente l'immagine. Se il risultato raggiunto senza l'uso di questo filtro è soddisfacente, pari al risultato con, non abilitatelo inutilmente.

[stealth82]

Ad una tale abbondanza di filtri sarebbe certamente gradita una certa flessibilità nel poterli applicare a seconda della situazione, per esempio a seconda del materiale o del player avviato. Anche se non esaustiva, grazie ad una particolare sezione di ffdshow potremo fare anche questo.

Tramite la voce Images setting è infatti possibile caricare un'intera, differente, catena ffdshow in maniera sostanzialmente trasparente (in base a criteri definiti). Come? Per fare un'applicazione pratica, prenderemo in esame la mia realtà.

Personalmente ho avuto la necessità di configurare ffdshow per tre tipi di applicazione (potrebbero essere anche quattro) diverse: per materiale eseguito - se PAL o NTSC - o per player utilizzato - se TT o ZP. Così, dalla tab Image settings, tramite il pulsante New, oltre al default, ho creato i seguenti nuovi profili: NTSC e Zoom Player. Per ognuno di questi ho poi specificato le condizioni di esecuzione (autoload; ovvero in quale occasione ognuno di questi dovrebbe realmente attivarsi). Tramite il pulsante Preset autoload conditions...:

default
Mantenendo il profilo a default (grassetto; doppio click su di esso) non è necessario specificare alcuna condizione: semplicemente entrerà in azione nel qual caso le condizioni date dagli altri profili non dovessero essere soddisfatte.

NTSC
Ciò che contraddistingue il materiale NTSC dal PAL è la risoluzione: 720x480 per l'NTSC e 720x576 per il PAL. Ho così sfruttato questa differenza per caricare il profilo all'occasione. Il motivo che mi ha spinto a voler creare un profilo ffdshow dedicato a questo scopo è presto detto: l'NTSC essendo inferiore di risoluzione e minore in fps - rispetto al collega PAL - mi permette di spremere maggiormente la CPU (consuma meno) incrementando quindi "l'impegno" dei filtri utilizzati.



Zoom Player
In questo caso la scelta di autoload è ricaduta sull'eseguibile associato al player: zplayer.exe. Il motivo che mi ha spinto a dover creare un profilo ffdshow dedicato a questo scopo è stato - a parità di filtri - il maggior consumo di CPU. Ho così dovuto "limare" la mia configurazione.



Ultimo aspetto, per permettere il funzionamento della feature, è stato lo spuntare la voce Automatic preset loading sottostante il pulsante di richiamo delle varie condition (Preset autoload conditions...).

La gestione
Gestire i profili è molto semplice: presente in ogni filtro, tramite il menu a tendina posto in alto, è possibile richiamare ciascun "banco" creato. Questa selezione ha la funzione di switch. Questo switch ricaricherà, ogni volta, la singola configurazione rispettando l'ordine dei filtri, le istruzioni utilizzate e ogni altra personalizzazione (all'infuori della tab Codecs che ha valenza universale).

[stealth82]

L'approfondimento è terminato.

Se qualcosa non vi fosse chiaro esprimete i vostri dubbi qui: http://www.avmagazine.it/forum/showthread.php?t=50025

[BigBlack]

Ma questa guida è ancora valida? :P Visto che ha 2 anni? Ed è applicabile a qualsiasi player tra cui anche XBMC? Grazie