La compressione Mpeg4 e

la configurazione del codec Xvid

(l'evoluzione dell'originale progetto divX nel mondo OpenSource)

(Versione 3)

Questa pagina è stata pubblicata da Andrea Panisson su http://digilander.libero.it/andypanix. Ultimo aggiornamento: 13/07/2003.
(Rimuovi "NOSPM_" dall'indirizzo email per contattarmi)
N.B. guida basata sulla versione del codec Koepi's Xvid del 24/06/03
(nel caso abbiate problemi a reperire sul sito dell'autore la versione indicata qui sopra,
ne ho messo a disposizione una copia in locale a questo indirizzo)

Per stampare correttamente questa guida vi consiglio l'utilizzo dell'ultima versione di Mozilla

P.S. dato che fino a prova contraria sono anch'io un essere umano, come tale non sono immune agli errori, quindi se dovessi aver commesso qualche imprecisione o scritto qualche "castroneria", vi sarei immensamente grato per tutte le eventuali segnalazioni nonché per tutti i suggerimenti, che in bene od in male saranno comunque bene accetti ;-)

INDICE

Introduzione


PARTE I - un po' di teoria
PARTE II - Alcune cose di cui tener conto
PARTE III - La configurazione del codec Xvid

Encoding Options
Decoder Options
Load Defaults

Modalità "1 Pass..." e "2 Pass - 1st pass": impostazioni per la codifica ad 1 solo passaggio ed impostazioni dei settaggi per il primo passaggio nella codifica a due passaggi
  • Scheda "Global": Motion search precision, Quantization type, FourCC used, VHQ Mode, Maximum e Minimum I-frame interval, Enable lumi masking, Enable grayscale, Enable interlacing, Use croma motion, Quarterpel, Global Motion Compensation (GMC), Maximum B-frames, B-frame quantizer ratio (%), B-frame quantizer offset, B-frame threshold, Packed bitstream, DX50 B-VOP compatibility, Print debug info on each frame.
  • Scheda "Quantization": Min / Max I-frame quantizer, Min / Max P-frame quantizer, Min / Max B-frame quantizer, Edit Quantizer Matrix
  • Scheda "Two Pass": Discard first pass, Hinted ME, 1st pass stats.
  • Scheda "Alt. (Alternative) Curve": Max bitrate (Kilobit/s), Max overflow improvement % - Max overflow degradation %
  • Scheda "Credits": Credits at start of movie, Credits at end of movie, Encode credits in greyscale, Credits rate reduction (Desired % rate, I-frame quantizer / P-frame quantizer, Starting size / Ending size (kBytes)).
  • Scheda "Debug": Performance optimizations, Chroma Optimizer, Use trellis R-D quantisation, Frame drop ratio, Reaction Delay Factor, Average period, Smoother
Modalità "2 Pass - 2nd pass...": impostazioni del codec per il secondo passaggio
  • Scheda "Global": Quantization type.
  • Scheda "Quantization": Min / Max I-frame quantizer, Min / Max P-frame quantizer
  • Scheda "Two Pass": Two pass tuning, I-frame boost %, Discard first pass, Dummy 2nd pass, Below i-frame distance..., I-frame bitrate reduction %, Curve compression, High / Low bitrate scenes %, Bitrate payback delay (frames), Payback with bias, Payback proportionally.
  • Scheda "Alt. (Alternative) Curve": Use Alternative curve system, Curve agression, High distance from average %, Low distance from average %, Enable automatic minimum relative quality, Strenght %, Minimum relative quality %, Enable automatic bonus bias calculation, Manually set bonus bias, Max bitrate (Kilobit/s), Max overflow improvement %, Max overflow degradation %.
Appendice A - I difetti dovuti ad una cattiva compressione video
Appendice B - Undersize (video sottodimensionato) ed altri problemi sulle dimensioni del video
Appendice C - PNSR
Appendice D - Rate-Distortion
Appendice E - Schema dei parametri di conversione consigliati

Fonti

Introduzione

Questo articolo si prefigge un obbiettivo piuttosto impegnativo: spiegare nel modo più semplice possibile la funzione e l'utilizzo dei diversi parametri presenti nelle finestre di configurazione del codec Xvid (www.xvid.org). Che cos'è il codec Xvid? L'Xvid è al pari del Divx un codec di compressione Mpeg4, ovvero, un software che vi consente di comprimere un video in formato mpeg4 e allo stesso tempo di visualizzare i video così compressi. Per quel che riguarda la visualizzazione di un video compresso con il codec Xvid, (ma anche con il più noto DivX), vi consiglio di far riferimento alla guida al postprocessing.

E' necessario premettere, per tutti coloro che sono alle prime armi, che per comprimere un qualunque video in formato Mpeg4, non è sufficiente scaricare ed installare il codec Xvid, ma è necessario anche un altro programma che faccia da "tramite" (interfaccia)  tra il video stesso da comprimere ed il codec installato. Per un esempio pratico, ad esempio per la conversione da DVD, si veda la guida a Vidomi, oppure più in generale, la guida a Virtualdub.
Sottolineo nuovamente quindi che questa guida non spiega come effettivamente convertire un video in mpeg4 utilizzando il codec Xvid, ma ne illustra esclusivamente i vari parametri di configurazione disponibili e tenta di spiegare come utilizzarli. Ripeto, se si desidera un esempio pratico per l'utilizzo dell'Xvid, è necessario fare riferimento alle guide sopracitate.

Ma torniamo all'Xvid. Prima ho citato il Divx e non a caso, dato che l'Xvid nasce in pratica come alternativa OpenSource del Divx (opensource, ovvero con il codice sorgente liberamente scaricabile e modificabile). In sintesi, l'Xvid (che se non l'avevate già notato è divX scritto al contrario) è un'ottima alternativa completamente gratuita al codec Divx nella versione Pro, paragonabile a questo in termini di qualità ottenibile (ma qualcuno sostiene che la qualità sia anche superiore) ed in termini di velocità (ovviamente a parità di funzioni utilizzate).
 
Perché usare l'Xvid al posto del più noto e diffuso DivX?

La risposta è che l'Xvid è gratuito, il DivX Pro no, a meno di utilizzare la versione con banner pubblicitario (cosa che può infastidire non poco), mentre la versione basic del DivX non offre le stesse funzionalità della versione Pro e le sue prestazioni sono inferiori a quelle dell'Xvid. Il numero di funzioni supportate dall'Xvid sono superiori rispetto a quelle del DivX Pro; trovate una tabella aggiornata con il confronto delle caratteristiche supportate dai più diffusi codec Mpeg4 al seguente indirizzo: http://www.mplayerhq.hu/%7Emichael/codec-features.html; una rapida occhiata in "Mpeg4 Encoder features" basta per rendersi conto delle differenze tra i vari encoder, in particolare tra il DivX e l'Xvid. Ora, un numero superiore di funzioni supportate non necessariamente significa una qualità superiore nel risultato, tuttavia vi è comunque una buona probabilità che alcune funzioni possano fare la differenza... Infine, ma questa forse è più una scelta di ragione "filosofica", l'Xvid è un progetto opensource rilasciato con licenza GPL (quindi con tutte le conseguenze pratiche che questo comporta), il DivX no.

Dove scaricare il codec Xvid

In rete potete reperire diverse versioni del codec, tuttavia, per evitare brutte sorprese vi consiglio di andare quasi sul sicuro e di utilizzare la versione del codec che consiglio in questa guida (vedi qui); quel "quasi" è necessario in quanto la versione consigliata è una versione non ufficiale. Credo che sia necessaria qualche spiegazione. Esiste una sola versione ufficiale e stabile, priva di difetti od errori (bugs), basata sui codici sorgente rilasciati da xvid.org e che potete trovare  sul sito di Koepi al seguente indirizzo, http://roeder.goe.net/~koepi/xvid.shtml marchiata come "stable release". Esistono poi diverse altre versioni, cosiddette "unstable" o "alpha" o "beta" (o quello che volete ma non "stable"), che contengono delle opzioni avanzate di configurazione e delle funzioni che non sono state inserite nella versione stabile, in quanto ritenute "a rischio", ovvero non prive di difetti o possibili bug. Il perché usare una di queste versioni è presto detto: alcune opzioni avanzate (esempio i B-Frames) consentono di ottenere un livello di compressione con una qualità non raggiungibile con la versione ufficiale. Il vantaggio è la possibilità di risparmiare qualche CD o qualche centinaia di MB, il rischio è quello che il nostro video presenti alcuni difetti in fase di visualizzazione, cosa che non dovrebbe (e qui il condizionale è d'obbligo) verificarsi seguendo le indicazioni di questo articolo, o peggio ancora che il video sia non utilizzabile con una versione successiva del codec (cosa che semplicemente potete risolvere inserendo la versione con cui il video è stato compresso all'interno del CD in cui avrete salvato il video). Ecco dove scaricare le versioni "non ufficiali": versione di Koepi, http://roeder.goe.net/~koepi/, versione di Nic http://nic.dnsalias.com/ ed infine la versione di Umaniac http://umaniac.leffe.dnsalias.com (sono tutte versioni tra loro leggermente differenti, in quanto contengono delle piccole modifiche al codice sorgente che i loro autori hanno preferito includere od escludere  al momento della compilazione). I codici sorgenti ufficiali da compilare li trovate, invece, sulla homepage del progetto: http://www.xvid.org/;

Questa guida.

Come è strutturata questa guida? Per una buona comprensione del funzionamento dei singoli parametri, ho ritenuto indispensabile fornire anche una breve introduzione alla compressione video (in particolare alla compressione MPEG) in cui mi sono occupato nella PARTE I di questo articolo. Comunque, chi fosse semplicemente interessato alla configurazione dei parametri del codec, può tranquillamente saltare alla PARTE II o fare riferimento direttamente alle tabelle riassuntive.

Ringraziamenti

Vorrei ringraziare tutti coloro che hanno reso possibile la stesura di questa guida, mettendo a disposizione di tutti la loro conoscenza e la loro esperienza. Un ringraziamento particolare a due guru del codec Xvid, Koepi (http://roeder.goe.net/~koepi/) e Nic (http://nic.dnsalias.com/), senza i quali questo mio lavoro non avrebbe ragione d'esistere. Un doveroso ringraziamento anche a doom9 ed al suo eccezionale sforzo e contributo nel diffondere il piacere per il video digitale. Vorrei poi ringraziare tutti coloro che con i loro post sul forum di doom9 (http://forum.doom9.org/) hanno fornito informazioni ed indicazioni utili (se non indispensabili) alla creazione di questo articolo; un ringraziamento speciale a "Iago", ed alla sua guida, che mi ha fornito la prima idea su come scrivere queste pagine, nonché un doveroso grazie alla pazienza mostrata da Nic e da Koepi. Un ringraziamento particolare inoltre allo straordinario lavoro svolto da Benny nel suo sito, senza il quale non sarei mai stato in grado di capire molte delle funzioni del codec mpeg4 Xvid. Per una lista completa dei siti in cui ho cercato le informazioni per scrivere questo articolo, vi rimando comunque alle "Fonti".

Scrivere questa guida ha richiesto uno sforzo non indifferente da parte mia; per alcuni parametri ho effettivamente faticato non poco per reperire anche una seppur minima documentazione, quindi potrebbero non essere spiegati sufficientemente bene e/o le spiegazioni potrebbero contenere qualche errore. Nel caso vi siano imperfezioni, omissioni, errori, sviste, clamorose gaffes etc etc etc, segnalatemele senza indugi. A farla breve, ogni suggerimento o consiglio è ben accetto.

Questa guida è basata su di una particolare versione del codec Xvid (vedi qui quale). Nel caso non riusciate più a reperirla in rete, potete scaricarla a questo indirizzo. Potrebbero essere disponibili anche versioni successive, tuttavia la versione che viene usata in questo articolo dovrebbe essere sufficientemente stabile da garantire un risultato di buona qualità. Prestate attenzione inoltre che alcune versioni del codec potrebbero contenere degli errori (bug) che possono portare ad un pessimo risultato finale oppure avere problemi di funzionamento con il decoder video ("Broken B-Frame...", "...B-frame decoder Lag" etc...). In proposito, mi preme sottolineare nuovamente che le versioni che trovate nei siti di Nic e di Koepi sono generalmente versioni BETA se non indicato diversamente (tipo "Stable release" etc...) e quindi non è detto siano prive di errori. Sono disponibili in linea solo per essere testate e non lamentatevi troppo se non funzionano, al più provate a segnalare il problema nel forum di Doom9 (magari avete scoperto un bug...)

NOTA BENE: PostProcessing - fate riferimento alla "Guida introduttiva al postprocessing" per maggiori informazioni sul postprocessing ovvero sulla decodifica e sull'applicazione di eventuali filtri per migliorare la qualità dei video compressi con il codec Xvid e per la risoluzione di eventuali problemi in fase di decodifica (ovvero durante la visione di un film).

PARTE I - un po' di teoria

Prima di addentrarmi nella configurazione del codec, onde evitare di appesantire e rendere troppo dispersiva la parte della guida che ne descrive in dettaglio le impostazione, tenterò di fornire tutte le nozioni teoriche di base che dovrebbero consentirvi di comprendere al meglio il suo funzionamento.

Un'introduzione alla compressione video

Ora addentriamoci un pò di più nei meandri della compressione video; in particolare tenterò di spiegare a grandi linee (tanto per avere un'idea) e nel modo più semplice possibile, come funziona l'encoder video, cosa che se non è proprio indispensabile per fare dei buoni mpeg4, potrebbe comunque essere molto utile.
Vediamo anzitutto di dare una definizione: un un CoDec video (Co-Dec = parola composta di Coder e Decoder) è un programma (software) composto di un due parti: un enCoder il cui scopo è comprimere una sequenza di immagini (video) per archiviarla in un file ed un Decoder necessario per decomprimere la sequenza e poterla nuovamente visualizzare. A grandi linee ecco come funziona il procedimento:


Video originale
(non compresso)		 EnCOder

Codifica, compressione del video		 File compresso sul disco fisso
(il nostro file .avi, .mpeg ecc. ecc, per intenderci)
DECoder


Decodifica, decompressione del video, vengono effettuati alcuni procedimenti inversi rispetto alla fase di codifica, onde "ricostruire" il video.

Video decompresso che "scorre" sul monitor o sulla TV

In questo articolo mi occuperò solo della procedura di compressione del video, ovvero del lavoro effettuato dall'encoder; la procedura di decodifica da parte del decoder viene brevemente accennata nell'articolo sul postprocessing.

Le tecniche di compressione video (ma questo vale per gli algoritmi di compressione in generale) possono essere suddivise in due grandi categorie: le tecniche cosiddette"loseless", nei quali la compressione è un processo perfettamente reversibile che avviene senza perdita di informazione e dove video originale e video decompresso sono identici in tutti i dettagli, e le tecniche "lossy" o tecniche di compressione non reversibile, nelle quali video compresso e decompresso non sono più identici in quanto al momento della compressione sono state volutamente eliminate alcune informazioni ritenute "sacrificabili". Le tecniche "lossy" sono le più diffuse per la compressione del multimediale, ed infatti appartengono a questa categoria le codifiche MPEG (1, 2 e 4), il Divx, l'Xvid, l'mp3, il Vorbis ecc...; invece generalmente le tecniche di compressione loseless sono poco efficaci nel caso del multimediale e vengono infatti ampiamente utilizzate nella compressione dei documenti (zip, rar, etc...); un esempio di codec video di loseless è l'ottimo Huffyuv (gratuito).

Prima di procedere analizzando in dettaglio cosa avviene durante la compressione video, ovvero cosa fa effettivamente un encoder video, definiamo anzitutto il concetto di frequenze video. Come nell'audio, anche nel video si può parlare di alte e basse frequenze (video): “…nel video le basse frequenze corrispondono ai colori uniformi (un cielo sereno senza nubi, il colore di una automobile) mentre le alte frequenze corrispondono alle immagini frastagliate tipo le foglie di un albero visto da lontano, i quadrettini minuti di una giacca, o i caratteri minuti della pagina di un giornale...” (5). Detto questo, proseguiamo.

Un video è costituito da una serie di immagini che si susseguono in rapida sequenza. Quindi quando si comprime un flusso video si stanno sostanzialmente comprimendo delle immagini. E' possibile farsi un'idea su come viene trattato un flusso video, osservando la figura seguente (non preoccupatevi se compaiono termini di cui ignorate il significato, in quanto verranno illustrati in seguito):



Si tratta sostanzialmente di individuare delle caratteristiche nelle immagini e nel video che possano essere sfruttate ai fini della compressione.

Come è possibile comprimere un video?

Tecniche relative al modo di memorizzazione
E' possibile comprimere un video riducendo la precisione con cui vengono memorizzate le informazioni: un esempio tipico di questo tipo di compressione, nel caso di un flusso video digitale, è il passaggio dallo spazio di colore RGB a tutta una serie di spazi di colore denominati YUV; si ha una reale perdita di informazione, che risulta tuttavia difficilmente notabile per l'inferiore sensibilità al colore dell'occhio umano.

Tecniche che sfruttano alcune caratteristiche intrinseche del video stesso, in combinazione con le caratteristiche del sistema visivo umano.
E' possibile comprimere un segnale video:
  • Rimuovendo la ridondanza (ripetitività) statistica contenuta in un video e mantenendo solo le nuove informazioni, ovvero quelle effettivamente utili; si cerca una rappresentazione "meno correlata" delle immagini, eliminando le "ripetizioni":
    • si può dimostrare che pixels adiacenti, vicini, all'interno di una stessa immagine, presentano caratteristiche molto simili per quel che riguarda il colore e la luminosità (cosa del resto piuttosto intuitiva: se considero una porzione azzurra di cielo, con buona probabilità pixel vicini avranno lo stesso colore); la codifica intra-frames si occupa di rimuovere questa ripetitività o ridondanza spaziale all'interno dello stesso fotogramma;
    • esiste inoltre una netta correlazione non solo tra i pixel dello stesso fotogramma, ma anche tra i pixels di fotogrammi adiacenti: un fotogramma ed i due vicini (il successivo ed il precedente) spesso risultano pressoché identici (fanno eccezione le situazioni in cui si hanno cambi di scena); questa correlazione, ridondanza temporale tra fotogrammi vicini che ne sfrutta le loro minime differenze, viene trattata  dalla codifica inter-frames.
  • Sfruttando alcune peculiarità del sistema visivo umano: la scarsa sensibilità dell'occhio alle alte frequenze video soprattutto se si tratta di immagini in movimento.  E' possibile "tagliare", buttar via, alcune delle informazioni sulle alte frequenze di un'immagine senza per questo portare ad un visibile deterioramento dell'immagine stessa. Per come è strutturato, il sistema visivo umano non è in grado di percepire le variazioni nei dettagli di figure molto frastagliate; è molto difficile rendersi conto di una perdita di dettaglio nelle fronde di alcuni alberi in movimento; molto più semplice invece notare anche la più piccola variazione di colore o luminosità nell'azzurro di un cielo limpido e sereno sullo sfondo di un video (DCT e quantizzazione).

Scendiamo un pò di più nel dettaglio, ed analizziamo i singoli passaggi. La prima fase è una conversione dello spazio di colore, e già qui si ha la prima perdita totale di informazioni, in quanto si passa da 24 bit per pixel (bpp) del formato RGB ai soli 12 bpp del formato YV12; si ha in pratica un dimezzamento delle dimensioni del video, con perdita irreversibile di informazioni ma degrado qualitativo praticamente nullo (non percettibile), data la ridotta sensibilità alle variazioni di colore del sistema visivo umano.



 1) Conversione dello spazio di colore: da RGB a YUV 4:1:1
Y=0,299 R + 0,587 G + 0,114 B
Cb = (B – Y) / 2,03
Cr = (R – Y) / 1,60

(R, G, B)
(24 bit / pixel)
 =

(Rosso, Red)
(8 bit / pixel)
+

(Verde, Green)
(8 bit / pixel)
+

(Blu)
(8 bit / pixel)
 RGB: le informazioni di ogni pixel sono date da una coordinata spaziale del tipo (numero, numero, numero) = (Red, Green, Blu) dove "numero" è un valore da 0 a 255 valore che è rappresentabile in binario (il linguaggio del computer formato da 0 ed 1) con 8 bit (il più grande numero decimale rappresentabile con n bit si ottiene con la formula: 2n-1, ovvero 28-1 = 256-1 = 255). Questo significa che in formato colore RGB servono 24 bit per ogni pixel ovvero 3 bytes (1 byte = 8 bit). Per la cronaca nero = (0,0,0), bianco = (255,255,255); tutte le tonalità di grigio sono rappresentate da valori del tipo (x,x,x), ovvero terne dello stesso numero.

YUV 4:1:1
YV12
(12 bit / pixel)
=

Luma (Y)
(8 bit / pixel)
+

Chroma Blu (Cb)
(2 bit / pixel)
+

Chroma Red (Cr)
(2 bit / pixel)
 YV12: per “risparmiare” bit, per il video si utilizza il formato colore YUV 4:1:1 noto anche come YV12. Si risparmia in quanto bastano soli 12 bit per ogni pixel. Come? Per ogni singolo pixel si mantengono tutte le informazioni per la luminosità (il bianco ed il nero in un certo senso), mentre si approssima come uguale il colore di un cubetto di quattro pixel (2x2). E’ come se si usasse una risoluzione dimezzata per il colore (invece di memorizzare i dati di ciascun pixel, si memorizzano solo quelli di 4 pixels adiacenti, supponendo siano tutti dello stesso colore, usando il valore medio del colore). La qualità complessiva non ne risulta compromessa (basti pensare ai video DVD), in quanto l’occhio non è così sensibile alle variazioni di colore quanto lo è alle variazioni di luminosità, soprattutto in immagini in movimento. I formati YUV vengono detti "luminance / chrominance colour image format", per distinguerli da quelli basati sulle componenti di colore quali l'RGB.






2)Blocking: l’immagine viene suddivisa in macroblocchi di 16x16 pixels

L'immagine originale viene suddivisa in macroblocchi di 16x16 pixels; di qui la necessità che il video da comprimere sia un multiplo di 16 nelle dimensioni verticali ed orizzontali (altezza e larghezza). (Il codec Xvid consente di comprimere flussi video con risoluzioni anche multiple di 8 , di 4 e probabilmente di 2, tuttavia in queste situazioni la suddivisione in macroblocchi non è ottimizzata, e potrebbero richiedere un bitrate più elevato od addirittura presentare degli artefatti video durante la decompressione, a causa di una motion estimation effettuata su macroblocchi non standard)

Nello spazio di colore YV12 all’interno di ciascun macroblocco 16x16, si possono distinguere 4 blocchi di 8x8 pixels per quel che riguarda la luminosità (luma) ed 1 solo blocco di 8x8 valori (ogni valore rappresenta 4 pixel) per ogni componente del colore Chroma-Blu e Chroma-Red (dato che la risoluzione per il colore viene dimezzata), per un totale 6 blocchi di 8x8 pixels.

Ingrandimento di uno dei macroblocchi 16x16 in cui è stata suddivisa l'immagine e simulazione (nel senso che le componenti Cb e Cr non corrispondono alla realtà) della decomposizione del macroblocco selezionato nelle componenti dello spazio di colore YV12


Y, Luminanza:
risoluzione invariata, 16x16 pixels, ovvero 4 blocchi di 8x8
Cr, Crominanza Rosso:
risoluzione dimezzata, il macroblocco 16x16 è approssimato con un blocco di 8x8 pixel

Cb,  Crominanza Blu:
risoluzione dimezzata, il macroblocco 16x16 è approssimato con un blocco di 8x8 pixel


L'encoder a questo punto decide quali fotogrammi devono essere trattati come I-Frames e quali invece saranno trattati come P o B-frames. Sugli I-Frames viene direttamente applicata la DCT (vengono compressi come vere e proprie immagini in formato JPEG), mentre sugli altri fotogrammi vengono effettuate delle procedure di "modellizzazione del moto".



 Intra-Frames
(I-Frames)

Delta-Frames o Inter-Frames (P e B-Frames)
Sugli I-frames non viene effettuata nessuna modellizzazione del moto



 3) Modellizzazione del moto: Motion Estimation e Motion Compensation, Inter-Frames Prediction
La procedura è piuttosto complessa ed è difficile sintetizzare il tutto in poche righe. Tenterò di illustrarvi solo i concetti di base in modo tale che vi facciate per lo meno un'idea generale. Ripeto: le cose in realtà non sono così semplici. In questa fase viene sfruttata la ridondanza temporale dei fotogrammi del video, ovvero il fatto che fotogrammi adiacenti (successivi) risultano tra loro molto simili. Per citare l'esperto ;) "se un pixel in un certo frame ha un certo colore, lo stesso pixel o quelli vicini, nei fotogrammi successivi o precedenti con buona probabilità avranno un colore simile"(5). In pratica ora vengono costruiti i P-frames ed i B-frames. Come? Con due procedure:

1) Motion Estimation (ME): per ciascun macroblocco 16x16 o blocco 8x8 (a seconda della precisione sulla ricerca del moto, la ricerca viene effettuata sui macroblocchi 16x16 o sui blocchi 8x8; di seguito utilizzerò sempre il termine blocco, restando sottinteso che potrebbe anche trattarsi di un macroblocco) viene effettuata una stima del movimento; in pratica l'encoder tenta di individuare tra i fotogrammi adiacenti (nel solo fotogramma precedente per i P-Frames, nel precedente e nel successivo per i B-Frames) il blocco più simile (se non uguale). Dopodichè viene associato al blocco su cui è stata effettuata l'analisi, un vettore di moto, cioè una coppia di numeri tipo (x,y) = (-1,4) che individuano sul piano ipotetico rappresentato dal fotogramma, il vettore di spostamento, sostanzialmente una freccia che mi indica direzione, verso e entità dello spostamento del blocco passando dal fotogramma 1 al fotogramma 2. Tale vettore deve essere necessariamente associato ad ogni blocco su cui viene effettuata la ME, e viene utilizzato in fase di decodifica per ricostruire l'immagine originale. Si noti inoltre che la ricerca per il blocco di riferimento viene generalmente effettuata in un intorno limitato del blocco di partenza (area in grigio nella figura in basso) in quanto se la ricerca fosse effettuata su tutto il fotogramma, i tempi per la codifica potrebbero allungarsi in modo non accettabile; l'efficenza del metodo è assicurata dal principio della rindondanza spaziale: la probabilità di trovare un blocco simile man mano che ci si allontana dal blocco di partenza, diminuisce in modo esponenziale con l'aumentare della distanza.

     


2) Motion Compensation (MC): viene creato il blocco differenza, in pratica viene sostituito il blocco originale su cui è stata effettuata la ricerca, con il risultato che si ottiene sottraendo dal blocco molto simile trovato del fotogramma 1 (reference frame) il blocco in questione nel fotogramma 2. Se tutto ha funzionato a dovere, ovvero l'encoder non ha commesso errori nella ricerca del blocco di riferimento (nel fotogramma 1), si ottiene un netto vantaggio consistente nel fatto che il nuovo blocco "differenza" sarà costituito da un numero decisamente inferiore di dati (nella matrice del blocco saranno presenti molti zeri (colore nero)). Le uniche informazioni aggiuntive da considerare saranno quelle relative al vettore di moto (una coppia di numeri).






4)DCT, Discrete Cosine Transform
Torniamo ai macroblocchi di 16x16 pixels, che, per la conversione nel formato colore YUV 4:1:1 (YV12), corrispondono a 6 blocchi di 8x8 pixel, numeri o coefficienti che dir si voglia (4 per la luminosità e 2 per il colore). Ognuno di questi blocchi 8x8 può essere descritto da una matrice di 8x8 valori numerici, ovvero un quadrato di 8x8 = 64 numeri da 0 a 255, che, a seconda del blocco in questione, descrivono luminosità (Y) di ciascun pixel o colore (Cb e Cr) di ciascun gruppo di 4 (2x2) pixels. Generalmente queste singole matrici risultano composte tutte da valori non nulli (a meno che non si tratti di immagini totalmente nere). Una funzione matematica, la DCT (Discrete Cosine Transform), viene applicata alle singole matrici 8x8; questa funzione trasforma le matrici dei valori Y, Cr e Cb, nelle matrici 8x8 contenenti i valori delle frequenze video. Ovvero si ottengono nuovi quadrati 8x8 sempre di 64 numeri o coefficienti che dir si voglia, con la differenza che ora i singoli coefficienti non rappresentano più, ad esempio, la luminosità dei 64 pixels del nostro blocchetto, ma la distribuzione delle frequenze video sempre dello stesso blocchetto. Ogni coefficiente rappresenta una determinata frequenza video: le basse frequenze (colori uniformi) sono rappresentate dai coefficienti in alto a sx della matrice, le alte frequenze (colori frastagliati) nell'angolo in basso a dx. Generalmente, ad una risoluzione di 8x8 pixel, si ha una certa uniformità nella distribuzione del colore, ovvero pixel adiacenti risultano piuttosto simili se non uguali (la cosa è piuttosto intuitiva, in quanto si pensi a quanto piccolo sia un blocchetto di 8x8 pixels rispetto ad esempio alla risoluzione tipica dei DVD di 720x576 pixels). Per questo motivo, nella stragrande maggioranza dei casi la matrice dei coefficienti DCT avrà valori significativi (diversi da 0) concentrati nell'angolo in alto a sinistra, ovvero nel campo delle basse frequenza. In particolare il valore in posizione (1,1) (il primo coefficiente in alto a sinistra) descrive il valore medio di tutto il blocco 8x8 ed è il coefficiente più importante. L'operazione è del tutto reversibile; nessuna informazioni fin qui viene persa e dalla matrice 8x8 DCT è comunque possibile ritornare alla matrice originale 8x8 tramite l'operazione inversa iDCT (inverse DCT).

Uno dei blocchi 8x8 dell'immagine originale

Rappresentazione grafica della matrice contenente i valori originali del blocchetto 8x8: i valori, nella maggior parte dei casi, sono piuttosto simili a causa della uniformità spaziale delle distribuzioni di colore che caratterizzano le immagini a scale relativamente piccole (8x8 pixels)


Rappresentazione grafica della matrice dei coefficienti DCT: solo pochi coefficienti presentano valori significativi. L'energia è stata concentrata soprattuto nel campo delle basse frequenze.





5) Quantizzazione
Fino a questo punto tutte le operazioni effettuate dall'encoder sono perfettamente reversibili; nessuna informazione è stata persa ed è possibile ritornare ai fotogrammi originali effettuando le operazioni nella direzione inversa. Per ottenere un ulteriore risparmio di bit, a questo punto non rimane che scartare alcune informazioni “poco significative”, poco importanti. Per quanto detto in precedenza, data la relativa insensibilità del nostro occhio alle alte frequenze video, potremmo scartare alcune delle informazioni relative alle alte frequenze senza per questo percepire un qualche degrado qualitativo. A tal fine, ogni coefficiente della matrice 8x8 DCT viene diviso per un numero intero (divisore) ed il resto della divisione viene scartato. In tal modo tutti i coefficienti più piccoli del divisore vengono approssimati a 0, ovvero vengono scartati (perdita di informazioni). I 64 divisori con cui dividere ognuno dei 64 coefficiente della matrice 8x8 DCT si trovano nella matrice di quantizzazione (che è appunto una matrice di 8x8 = 64 numeri interi), matrice che è possibile scegliere in fase codifica. Vengono utilizzate due differenti matrici di quantizzazione: una per gli Intra-Frames (I-Frames) ed una per gli Inter o Delta-Frames (P e B-Frames). Quello che avviene durante la fase di quantizzazione, può essere intuito osservando le seguenti immagini (i pallini nelle singole celle rappresentano i coefficienti e, maggiore il diametro del pallino, maggiore è il coefficiente in valore assoluto; lo zero è rappresentato da una cella vuota. Si noti che i coefficienti DCT possono assumere anche valori negativi):

Matrice dei coefficienti DCT(x,y)
        
Matrice di quantizzazione Q, Intra o Inter-Frames
(Coefficienti Q(x,y))
Matrice dei coefficienti DCT(x,y)Quantizzati

Il netto vantaggio è ora quello di avere una matrice DCT con un elevato numero di coefficienti nulli; in molti casi restano da 1 a 3 coefficienti diversi da zero, raggruppati nell'angolo superiore sinistro della matrice. Si noti come i coefficienti di quantizzazione per le alte frequenze (in basso a destra) siano nettamente superiori rispetto a quelli per le basse frequenze: il coefficiente DCT in alto a sinistra (quello più importante, che descrive il valore medio dell'intero blocco) dovrà essere approssimato (quantizzato) di meno, ed infatti risulta avere il minor coefficiente di quantizzazione. Durante la fase di decodifica, il decoder moltiplicherà ogni coefficienti DCT quantizzato per il rispettivo valore della matrice di quantizzazione, e ricostruirà la relativa matrice dei coefficienti DCT, che ovviamente non potrà essere equivalente all'originale, ma ne sarà una sua approssimazione; tuttavia, sebbene molti dei 64 coefficienti della matrice DCT originale siano stati "persi", se la compressione (quantizzazione) non è stata troppo elevata (ovvero coefficienti della matrice di quantizzazione troppo elevati) difficilmente si è in grado di notare la differenza tra l'immagine originale (non compressa) e quella (de)compressa, questo poiché le informazioni (quelle più importanti) dell'immagine originale sono state in gran parte concentrate in alcuni dei coefficienti DCT (quelli delle basse frequenze). Qui sotto è illustrato il procedimento che avviene in fase di decodifica; come si può notare la matrice dei coefficienti DCT non risulta uguale a quella di partenza:

Matrice dei coefficienti DCT(x,y)Quantizzati

Durante la decodifica, moltiplicando la matrice quantizzata dei coefficienti DCT per la matrice di quantizzazione Q utilizzata dall'encoder, si ottiene una approssimazione della matrice dei coefficienti DCT originale di partenza. Tale matrice DCT "ricostruita" viene quindi utilizzata dal decoder per ricostruire l'immagine originale, tramite la trasformata inversa del coseno (iDCT).
Matrice dei coefficienti DCT(x,y) "ricostruita"


La parte restante della procedura di encoding è forse quella che ci può interessare di meno ai fini della comprensione del meccanismo alla base della compressione video, in quanto si tratta di tecniche atte alla memorizzazione (e compressione) delle informazioni fin qui raccolte. Si tratta di tecniche di compressione “loseless”, ovvero che avvengono senza perdita di dati. La perdita di dati, informazioni, è già avvenuta durante la quantizzazione della matrice DCT, ed è per questo che la compressione video è considerata di tipo "non loseless" ovvero con perdita di informazioni. Ne darò solo un breve cenno, rimanendo molto sul generale.




 6) Zig-Zag Scanning (Scansione a Zig-Zag)
I coefficienti delle matrici DCT quantizzate vengono memorizzati e salvati in array (sono delle matrici lineari) con dei metodi detti Scansione a Zig-Zag. Per le caratteristiche delle matrici DCT (tutti i coefficienti non nulli risultano per lo più concentrati nell’angolo in altro a sinistra nella matrice), i numeri diversi dallo 0, tendono ad essere raggruppati tutti assieme. Il risultato: una lunga sequenza di zeri, intervallata da alcuni coefficienti non nulli:





7)Run-Level encoding (RLE) e Variable-Lenght coding (VLC)
Il procedimento fin qui descritto è servito per trasformare i dati in una forma trattabile da una serie di algoritmi matematici descritti generalmente come Entropy Encoding che, sfruttando la distribuzione casuale dei dati, tentano di rimuovere una certa rindondanza statistica naturalmente presente, ad esempio memorizzando i valori più comuni con dei codici brevi, mentre quelli meno comuni con dei codici più complessi. Tra le tecniche di questo tipo rientrano:
  • codifica Run-Lenght: utilizzata quando i dati presentano ripetizioni consecutive di alcuni simboli
  • codifica di Huffman: rappresenta simboli a probabilità di occorrenza decrescente mediante una codifica a lunghezza crescente
  • codifica DPCM (Difference Pulse Code Modulation): rappresenta i simboli originali come differenza tra il simbolo corrente ed una predizione dei simboli precedenti
  • codifica LZW: utilizza una tabella per rappresentare sequenze ricorrenti di simboli
  • codifica aritmetica: rappresenta gruppi di simboli, in base alla probabilità di ricorrenza degli stessi, mediante una rappresentazione in virgola mobile.
Vediamo qui di seguito un esempio di applicazione della prima di queste tecniche (Run-Lenght).

----------------------------------------------------

Al termine della procedura di scansione a Zig-Zag, ci troviamo in presenza di una sequenza di numeri del tipo:

Sequenza originale: 90, 5, 10, 2, 10, 1, 0, 0, -2, -4, 3, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 1, -2, ...

Utilizzando la Run-Level encoding, sequenze consecutive di simboli identici vengono combinati assieme e vengono rappresentati da un singolo simbolo o codice. Ad esempio è possibile rappresentare la serie di numeri qui sopra rappresentata come una coppia di coefficienti (run, level) dove run = numero di zero precedenti il valore "level", con "level" corrispondente ad ogni valore diverso da zero che è presente nella nostra sequenza; utilizzando l'esempio di sopra, applicando una codifica Run-Level come quella descritta (in cui tutte le sequenze di 0 consecutive sono rappresentate con il numero degli zeri che precedono il coefficiente non nullo), si otterrebbe la sequenza seguente:

Sequenza Run-Leve: (0, 90)(0, 5)(0, 10)(0, 2)(0, 10)(0, 1)(2, -2)(0, -4)(0, 3)(4, 3)(5, 1)(0, -2) ...

A questo punto è possibile applicare tecniche di compressione Entropy Encoding o Variable-Lenght Coding, dove le sequenze od i gruppi di dati che si presentano più frequentemente vengono rappresentati con un codice breve, mentre vengono assegnati codici più lunghi a quelle sequenze che si presentano piuttosto di rado. La conseguenza di questa nuova rappresentazione dei dati è che mediamente occorrono un numero inferiore di bit per la memorizzazione dello stesso simbolo rispetto alla quando i dati si presentavano nella forma di partenza. Esempi tipici di algoritmi che vengono applicati nella codifica a codice a lunghezza variabile, sono il cosiddetto albero di Huffman (che porta ad un rapporto di compressione tipicamente 1.5:1), le codifiche aritmetiche e le codifiche sostituzionali come ad esempio l'algoritmo LZW usato nella compressione delle immagini GIF e che in una forma modificata, combinata con la codifica di Huffman, è presente nei famosi formati di compressione gzip, pkzip e png. Ribadisco che tutte queste tecniche sono di tipo loseless, ovvero non comportano nessuna perdita dei dati di partenza.


-----------------------------------------------

Motion Estimation e Compensation in pratica

Ed infine, per chiarire un pò le idee, un po di "Motion Estimation" applicata. Osservate le seguenti immagini: si tratta di una sequenza video di un'auto che si sposta da sinistra a destra. A sinistra abbiamo il fotogramma A, a destra il fotogramma successivo B:

Fotogramma A
 Fotogramma B (successivo)

Il fotogramma seguente mostra la differenza tra le due immagini, differenza calcolata pixel a pixel senza l'utilizzo di nessuna tecnica di compensazione del moto; è in bianco e nero, in quanto si tratta della sola componente della luminanza (Y).

L'immagine differenza tra i due fotogrammi A e B, senza Motion Compensation

Osservate ora le due immagini seguenti: l'immagine di sinistra mostra il fotogramma A con tracciati i vettori di moto; ogni vettore (linea) indica la direzione in cui si sposta il macroblocco corrente nel fotogramma B successivo (direzione individuata mediante motion estimation). L'immagine di destra è stata invece ottenuta effettuando la differenza tra i due fotogrammi A e B, utilizzando, al posto del fotogramma A, il fotogramma A su cui è stata effettuata la stima di moto. Quello che è importante osservare è che l'immagine di sinistra contiene un numero di dettagli (informazioni) notevolmente inferiore rispetto all'immagine qui sopra mostrata (ottenuta dalla differenza senza ME) e richiede quindi un numero inferiore di bit per essere codificata.
Fotogramma A con tracciati i vettori di moto
 L'immagine differenza tra i due fotogrammi A e B, con Motion Compensation

La sequenza di immagini qui sopra è stata prodotta con il programma VCdemo, Image Compression Learning Tool, liberamente scaricabile al seguente indirizzo: http://www-ict.its.tudelft.nl/~inald/vcdemo, un software estremamente illuminante per tutti coloro che vogliano capire i principi alla base della compressione video tramite qualche divertente esperimento.

Chi desiderasse approfondire l'argomento, trova alcuni link ad indirizzi web molto interessanti nelle fonti alla fine di questo articolo.

NOTA BENE: tenete sempre a mente che ogni fotogramma (immagine) di cui è composto il video viene suddiviso in macroblocchi di 16x16 pixels (o blocchi di 8x8), ed è lavorando su questi blocchi che il video viene compresso. Quando catturate, ridimensionate o comprimente un video, assicuratevi sempre che il numero di pixels verticali ed orizzontali del vostro video, le dimensioni del vostro video, siano un multiplo intero di 16, ovvero siano divisibili per 16 (senza resto!), pena una compressione non ottimale od un possibile errore in fase di codifica.

Un piccolo commento riguardo alla nota di qui sopra. Utilizzare una risoluzione non multipla di 16, quanto piuttosto multipla di 4 o di 8 potrebbe comunque funzionare, tuttavia si rischia di andare incontro ad alcuni problemi, sotto forma di artefatti video in fase di codifica. Questo è piuttosto logico se si pensa al fatto che ci si troverebbe in presenza di un macroblocco di dimensioni non  standard. Ad esempio, utilizzando una risoluzione di 640x360 pixel  (640 è multiplo di 16, mentre 360 è multiplo di 8), avremmo una linea orizzontale di "macroblocchi" di 16x8 pixel, cosa che potrebbe recare qualche fastidio durante la compensazione del moto. Il problema si potrebbe inoltre complicare nel caso di video interlacciato. L'argomento è stato comunque trattato più in dettaglio da Benedetto in un suo articolo, quindi vi rimando alle sue pagine per ulteriori dettagli (http://www.benis.it/dvd/dig_vid.htm)

-----------------------------------------------

Tipi di fotogrammi: un approfondimento sulla compressione dei singoli fotogrammi

Veniamo ora ad analizzare più in dettaglio gli I, P, B-Frames ovvero (tradotto) fotogrammi-I, P, B che non sono altro che differenti metodi in cui il codec Xvid o DivX (quest'ultimo solo nella versione Professional per quel che riguarda i B-Frames) comprime i fotogrammi, che appunto a seconda del metodo di compressione applicato, predono poi i rispettivi nomi. In sintesi, un film compresso in mpeg4 (ma questo vale anche per gli Mpeg1 e2) sarà costituito da una sequenza di fotogrammi di diverso tipo, generalmente qualcosa come IPBBBPBBBPIBBBP eccetera.

Intra-Frames

I-Frames: i fotogrammi di tipo I, chiamati anche Intra-Frames o Key-Frames (fotogrammi chiave), sono fotogrammi che vengono codificati utilizzando le informazioni contenute nel fotogramma stesso e non contengono nessun riferimento od informazione sui fotogrammi adiacenti; in pratica sono compressi alla stregua di un'immagine singola, allo stesso modo di quando un'immagine viene salvata in formato JPEG. Nessun tipo di compressione temporale (ovvero compressione che tiene conto anche dei fotogrammi successivi e/o precedenti) viene applicata a questi fotogrammi. E' ovvio quindi che se tutti i fotogrammi del film fossero di questo tipo, i nostri film occuperebbero decisamente molto spazio (25 immagini per ogni secondo di film, per 90 minuti di film... fate un pò voi). In genere i fotogrammi chiave vengono inseriti dal codec ogniqualvolta vi sia un repentino cambiamento tra due immagini successive. Quando ad esempio un fotogramma è completamente diverso dal precedente, l'encoder probabilmente codificherà tale immagine come fotogramma di tipo I o chiave. Se inoltre viene specificato un intervallo massimo tra un fotogramma chiave ed il successivo (come in Maximum I-Frame Interval) il codec dovrà necessariamente inserire un fotogramma chiave anche se non strettamente necessario. Questo risulta utile in quanto quando ci si sposta all'interno di un file video mentre lo si sta guardando, alla ricerca di una particolare scena, è possibile solo spostarsi tra un fotogramma chiave ed il successivo. Fotogrammi chiave troppo distanziati renderebbero la ricerca piuttosto complicata ed è per questo che in genere si utilizza un valore massimo per la distanza tra un key frame ed il successivo corrispondente a circa 10-12 secondi di film (250, 300 fotogrammi nel caso di un film PAL). Per altre informazioni, vi rimando al seguente articolo di Benny, http://www.benis.it/dvd/agg2.htm.

Delta-Frames o Inter-Frames

P-Frames: il fotogramma P, (Predicted frames) viene codificato utilizzando informazioni acquisite in base al fotogramma che lo precede, sia questo di tipo I o di tipo P.  Ogni macroblocco di 16x16 pixels di un P-Frame può essere codificato sia in modo indipendente (come nel caso dell'I-Frame) sia può essere compensato, bilanciato utilizzando informazioni del fotogramma precedente. Utilizzando le somiglianze tra fotogrammi successivi i fotogrammi P risultano essere più piccoli dei corrispondenti I-Frames. (1) Spesso in una sequenza video, un gruppo o serie di fotogrammi risultano tra loro molto simili. Considerate ad esempio il caso limite del conduttore di un telegiornale che parla seduto alla scrivania. Per la gran parte del tempo, lo sfondo rimarrà praticamente invariato. Prendendo in considerazione che  per ogni secondo di video si susseguono 25 fotogrammi,  risulterebbe molto più utile poter memorizzare non i singoli fotogrammi in modo indipendente, quanto piuttosto  memorizzare e quindi successivamente comprimere esclusivamente le minime differenze tra di loro. A questo scopo vengono utilizzati i fotogrammi di tipo P, che consentono di eliminare le informazioni ridondanti e ripetitive: un fotogramma di tipo P contiene le informazioni della posizione (X',Y') nel fotogramma corrente in cui si è spostato un blocco che aveva coordinate (X,Y) in quello precedente (Motion Estimation / Compensation). Ripeto, in tal modo, al posto di mantenere l'informazione spaziale (tipo JPEG) del singolo fotogramma, vengono memorizzate le sole informazioni sulla variazione di posizione (ad ogni blocco viene associato il suo vettore di moto che consente di ricostruire l'immagine originale), informazioni che a conti fatti richiedono molti meno bit rispetto alla memorizzazione dell'immagine completa. Lo svantaggio dell'utilizzo di questo tipo di fotogrammi si ha in fase di decodifica; è infatti necessario "ricostruire" ciascun fotogramma P prima di poterlo visualizzare,  e per far questo si deve sempre partire dal fotogramma P seguente all'ultimo fotogramma chiave; ovvero per visualizzare ad esempio il quarto fotogramma P di una sequenza tipo IPPPPPPP è necessario comunque ricostruire anche i 3 fotogramma P precedenti.

Un discorso piuttosto approfondito meritano i B-Frames che introducono la codifica bidirezionale.

B-frames / Bi-directional encoding: per i fotogrammi di tipo B la ricerca del moto (motion estimation / compensation) è effettuata non solo sul fotogramma precedente (come nel caso di P-Frames) ma anche sul fotogramma successivo. La codifica ed anche la decodifica risultano quindi decisamente più complesse. Sostanzialmente i fotogrammi B sono di tipo "Bidirezionale", nel senso che fanno riferimento sia a ciò che li precede, sia a quello che segue. Inserire in un fotogramma informazioni che si riferiscono ad un fotogramma successivo è  possibile solo alterando l'ordine in cui i fotogrammi vengono archiviati all'interno del file video compresso. Questo è effettivamente quello che fa l'encoder (e di cui tiene conto il decoder in fase di decodifica). Facciamo un esempio. Supponiamo di avere 4 fotogrammi da comprimere. Il primo di questi sarà necessariamente un fotogramma chiave (I-Frame), mentre vogliamo che i successivi due siano B-Frames (che generalmente hanno una dimensione di 1/4 del P-Frame corrispondente); l'ultimo deve essere necessariamente un P-frame, in quanto i fotogrammi B necessitano dopo di loro di qualcosa da cui essere derivati. In sequenza avremmo:

n° fotogramma
 1
 2
 3
 4
tipo di fotogramma: I
 B
 B
 P

tuttavia i fotogrammi verranno archiviati all'interno del filmato in questo modo:

n° fotogramma
 1
 4
 2
 3
tipo di fotogramma: I
 P
 B
 B

Dopo aver codificato l'I-Frame, l'encoder salta avanti di due fotogrammi e codifica quello che è destinato ad essere il fotogramma P (ovvero il quarto) e lo codifica come se seguisse immediatamente l'I-frame:

n° fotogramma
 1
 4
tipo di fotogramma: I
 P

Questo processo genererà un P-frame di dimensioni superiori a quello che si avrebbe codificando come P-frame il 2° fotogramma, in quanto generalmente vi saranno più cambiamenti (ovvero differenze) tra il 1° fotogramma ed il 4° che non tra il 1° ed il 2°. Tuttavia, l'utilizzo dei due B-frame porterà complessivamente ad una riduzione del numero di informazioni (dimensioni) necessarie alla codifica (come ho già detto un B-frame occupa 1/4 delle dimensioni di un P-frame). Ora abbiamo un fotogramma I ed uno P compressi. Fatto questo, l'encoder ritorna al 2° fotogramma (che è destinato ad essere il nostro primo B-Frame) e facendo riferimento sia al fotogramma I che a quello P per la stima e ricerca del movimento, analizza le eventuali somiglianze e procede alla codifica del B-Frame:

n° fotogramma
 1
 4
 2
tipo di fotogramma: I
 P
 B

L'encoder prende quindi il 3° fotogramma e confrontandolo sempre con l'I-frame ed il P-frame iniziale genera il secondo B-frame:

n° fotogramma
 1
 4
 2
 3
tipo di fotogramma: I
 P
 B
 B

I B-frame non possono comunque mai fare riferimento uno all'altro, ovvero è sempre necessario avere un I-frame e un P-frame tra più B-frames consecutivi.
Questa procedura porta a complicare ulteriormente la fase di decodifica in quanto ora non solo è necessario rigenerare i fotogrammi in base alle informazioni codificate, ma i fotogrammi stessi risultano non essere più archiviati con il corretto ordine. Traduzione libera di un intervento di "rui" del 18th February 2002 nel forum di Doom9. (1)

In sintesi, l'utilizzo di queste tecniche permette di ridurre la quantità di bit necessari per la codifica dell'informazione trasmettendo (codificando) le differenze tra fotogrammi, piuttosto che archiviando i fotogrammi stessi. Alla luce di quanto detto finora, si comprende meglio il motivo per cui sequenze video con scene in rapido movimento o con un'elevata dinamica siano più impegnative da codificare e richiedano un bit-rate (o equivalentemente un numero di bit) più elevato: essendo maggiori le differenze tra i fotogrammi adiacenti, maggiori sono le informazioni che devono essere memorizzate e conservate. Al contrario, scene statiche con movimenti lenti o pochi cambi di scena, presentano minime differenze tra fotogrammi adiacenti, minime differenze che si traducono con un numero decisamente inferiore di informazioni da mantenere e trasmettere ovvero con un basso bit-rate.

"Quantificare" la compressione: il 'Quantizer'

Un ottimo articolo scritto da Benny sulla configurazione del codec DivX 4.12, spiega ottimamente la funzione del Quantizer o fattore di quantizzazione. Come si evince dall'articolo, il fattore di quantizzazione, che deriva direttamente dall'Mpeg1 e 2, dove generalmente viene chiamato Q, istruisce il codec sul  livello di compressione da applicare ai singoli fotogrammi. In sintesi, il fattore di quantizzazione può essere inteso come l'entità della compressione da applicare al singolo fotogramma. Più elevato è il Quantizer, più elevata è la compressione e minore è lo spazio occupato dal singolo fotogramma, ma peggiore è la qualità del fotogramma. Si possono avere valori compresi tra 1 (compressione nulla, massima qualità) e 31 (compressione massima, qualità estremamente scadente, sostanzialmente inutilizzabile). Generalmente i quantizer prendono valori tra 2 e 16, utilizzando valori superiori solo ove si voglia effettivamente risparmiare spazio trascurando la qualità (vedi ad esempio per la codifica dei titoli di coda); con valori compresi tra 2 e 4 si ottiene un'ottima qualità, con artefatti dovuti alla compressione praticamente invisibili ad occhio nudo, se non ingrandendo con uno zoom il filmato. Nel codec sarà necessario inserire un range massimo e minimo per i valori di quantizzazione. Sarà l'encoder in fase di codifica ad utilizzare un determinato valore del fattore di compressione (sempre e comunque all'interno dell'intervallo scelto), adattandosi in base allo spazio (bit-rate) disponibile. In situazioni in cui vi sarà abbondanza di bit-rate disponibile, saranno preferiti valori bassi di compressione; nel caso invece vi fosse mancanza di spazio, l'encoder preferirà aumentare la compressione dei fotogrammi. Utilizzando un valore uguale per il minimo e per il massimo si ottiene una cosiddetta codifica a qualità costante, ovvero ad ogni fotogramma è applicata la stessa compressione. (5)

PARTE II - Alcune cose di cui tener conto

La scelta del metodo di compressione

In genere si possono presentare due diverse situazioni quando andiamo a comprimere un video, sia esso un film in DVD, un documentario registrato dalla TV od il filmino delle nostre vacanze.

1) Non ci interessa lo spazio occupato dal video e miriamo solo alla qualità.

2) Siamo in presenza di uno spazio limitato, non vogliamo rinunciare alla qualità: cerchiamo il miglior compromesso tra spazio occupato e qualità del video.
Una situazione del genere potrebbe verificarsi ad esempio se desideriamo mantenere tutti i nostri video digitali su di un disco fisso dedicato (dischi di 120GB sono oggi piuttosto economici). In alternativa, data la rapida diffusione ed il costante ribasso dei prezzi, molte persone oggi dispongono di un masterizzatore DVD; i  4,7GB di un supporto DVD, sono quasi sicuramente più che sufficienti per un normale video di 3 ore in Mpeg4 ad elevata risoluzione (es. 720x576) e magari anche con audio multicanale, ed anche in questo caso non ci si preoccuperà dello spazio disponibile od occupato dal video, quanto piuttosto l'unica preoccupazione sarà ottenere la massima qualità possibile.

In casi di questo tipo, il modo migliore per comprimere il video è utilizzare un bit-rate costante estremamente elevato, oppure impostare un livello di qualità e/o compressione costante (es. quality = 98% o quantizer = 2). Sono situazioni relativamente semplici da affrontare e la codifica video risulta inoltre piuttosto rapida, in quanto basta un solo passaggio per la compressione del video.
Qui le cose si complicano un po', perché ora quello che ci interessa non è più la sola qualità video, ma anche lo spazio occupato dal video, vuoi ad esempio perché vogliamo sfruttare al massimo il nostro supporto DVD+/-R inserendovi più di un film, vuoi perché ad esempio stiamo usando dei supporti CD-R (scelta tutt'altro che rara, data la loro elevata economicità) per conservare i nostri video.


Il metodo di compressione più indicato in queste situazioni è il metodo a bit-rate variabile in due passaggi, ed è proprio quello che assicura la massima qualità sfruttando al meglio lo spazio disponibile. In sintesi con questo metodo si risparmia bit-rate nelle scene più semplici per utilizzarlo in quelle più complesse, che risultano avere quindi un qualità migliore rispetto alla codifica con un solo passaggio ed a bit-rate costante (per il quale invece viene riservato lo stesso bit-rate video indipendentemente dal tipo di scena).

Andiamo ora ad analizzare più in dettaglio la problematica sollevata dalla seconda situazione vista più sopra.

Questioni di spazio

Una delle prime domande che possono venirci in mente è "in quanti CD metto il mio video?", ovvero, "quant'è il numero minimo di CD in cui posso comprimere il mio video con la certezza di ottenere una buona qualità?", oppure in alternativa, "quanti megabytes (MB) o Gigabytes (GB) devo dedicare al mio video per essere sicuro di ottenere una buona qualità?".



Per rispondere a questa domanda, è necessario prima chiarire un concetto importante.

Il bit-rate: il bitrate (o bit-rate) è una velocità (lo dice la parola stessa, bit-rate = velocità dei bit), ovvero la quantità di bit che vengono trasmessi in ogni secondo; l'unità di misura del bitrate sono i bit al secondo (bps), o generalmente i kilobit per secondo (kbps) e tutti i loro multipli (megabit, gigabit, petabit ecc...); per codificare una singola immagine o fotogramma sono necessari un determinato numero di bit, e poiché nel caso di un flusso video si ha un determinato numero di fotogrammi ogni secondo, ecco che si passa dai bit (o Kilobit) al bitrate.  L'immagine seguente aiuta a chiarire il concetto:



Ovviamente, più alto il bitrate, mantenendo constante il numero di fotogrammi che scorrono ogni secondo, più alta è la quantità di bit riservata ad ogni fotogramma. Più elevato è il numero di bit disponibili per ogni singolo fotogramma, maggiore sarà il numero di informazioni che possono essere memorizzate e maggiore sarà quindi la qualità del singolo fotogramma (vi siete persi? ;). Sicuramente avrete già sentito parlare di bitrate se siete soliti comprimere i vostri CD-Audio in formato MP3. Più o meno tutti sanno che una volta compressi in MP3, in un CD-R potranno essere inseriti diversi album musicali. Se ci si accontenta di una qualità almeno accettabile generalmente si creano  mp3 a 128 kbps (chilo bit per secondo, dove 1bit = 1/8 byte = 1/(8*1024) kbyte ovvero 1 kbyte = 1024*8 bit), ma se si desidera una qualità superiore in genere sceglierò almeno 196 kbps. Nel primo caso potrò mettere circa 10 interi album in nel mio CD mp3, nel secondo caso probabilmente solo 7 o forse 8. Una situazione di questo tipo ricade comunque nel primo caso di quelli più sopra analizzati, ovvero non interessa minimamente lo spazio occupato dalla singola canzone, e difficilmente ci si porrà un problema del tipo "qual'è la qualità massima (in termini di kbps) che posso usare per far stare esattamente tutti i miei 10 CD Audio in 700MB (ovvero 1CD da 80 minuti) avanzando al più 1 o 2 MB?"

Al pari della compressione audio, quando si effettua la compressione di un video la quantità di dati necessari per memorizzare le informazioni (ovvero il numero di bit necessari) dipende molto dal tipo di video che si sta comprimendo. Per chiarire questo concetto, torniamo alla compressione di un file audio. Supponiamo di avere due file audio della stessa lunghezza, diciamo 5 minuti. Supponiamo che uno sia la registrazione di un dialogo tra due persone, effettuato in una stanza molto silenziosa; necessariamente in questo file saranno presenti delle pause, dei silenzi, che richiederanno un numero molto basso se non nullo di bit per essere codificati. L'altro file, sia invece la registrazione di un concerto di una famosa orchestra sinfonica; 40 e più strumenti che riempiono di una melodiosa armonia la sala da concerto. Inutile dire quanto più complesso sia da comprimere questo secondo file; ovviamente sarà necessaria una quantità molto superiore di bit per la compressione del concerto. Potrebbe quindi bastare un solo megabyte per il primo file (quello dei dialoghi), per ottenere una qualità più che buona, ma potrebbero esserne necessari 3 per il concerto dell'orchestra sinfonica.
Lo stesso concetto può essere applicato al video, ma se nel caso dell'esempio, risultava piuttosto ovvia la differente complessità dei due file audio, ed era quindi possibile azzardare a priori una previsione sul bitrate medio necessario per la codifica con qualità accettabile, non altrettanto semplice è prevedere a priori la complessità di un video.
Alla luce di quanto visto nella Parte I (introduzione alla compressione video), i più attenti potrebbero interpretare l'eventuale presenza di lunghe sequenze video statiche (pochi movimenti con sfondi fissi) e/o di sequenze video molto scure, alla stregua dei silenzi nell'equivalente audio dell'esempio di sopra, e quindi potrebbero essere in grado (se dotati di una certa esperienza) di prevedere a priori un bitrate medio necessario ad una ottimale codifica del video in questione o piuttosto essere in grado di intuire se sarà sufficiente un solo CD per contenere tutto il filmato con una qualità più che accettabile, o più di uno.

Ma è possibile sapere a priori con certezza quanti MB (od eventualmente quanti CD) ci garantiscono una elevata qualità di codifica?

Quali dimensioni per il video?

Facendo qualche prova (ovvero provando a comprimere più volte il video ed a dimensioni diverse) potremmo conoscere le dimensioni minime che ci garantiscano la qualità voluta. Tuttavia la compressione di un video è un'operazione piuttosto laboriosa e richiede diverso tempo. Quindi questa soluzione appare piuttosto improbabile.

Se non interessa sprecare CD, o non vi scoccia dividere il film in più supporti anche se non strettamente necessario, il problema sostanzialmente non si pone.

Prendiamo un video in formato 16:9, di risoluzione 640x352 pixel (punti). Se seguirete la seguente tabella, avrete un risultato garantito nel 100% dei casi:

Durata del film (video di 640x352 pixel)
 Numero di CD
(da 700MB)
Inferiore a 1h 00m 1
tra 1h 00m e 2h 00m 2
tra 2h 00m e 3h00m 3

Sostanzialmente 1 ora di video per CD, ovvero, tolto lo spazio occupato dall'audio, riservando qualcosa come 500-600 MB (MegaBytes) per ogni ora di video, avente risoluzione orizzontale di 640 pixel ed verticale di 352 pixel, andrete sul sicuro. Ovviamente aumentando la risoluzione aumenteranno i MB necessari ma direi che fino a risoluzioni di 720x384 pixel o simili non dovreste avere problemi seguendo la tabella di sopra. Sebbene 1 ora di video per CD non si possa certo definire una situazione di basso bitrate è comunque questo un caso in cui utilizzare un metodo di compressione in due passaggi, per lo meno per essere sicuri di utilizzare tutto lo spazio disponibile. Il metodo in due passaggio è infatti l'unico che consente di impostare a priori e con precisione la dimensione del file video.

Le cose si complicano se invece siete decisamente tirchi e/o pigri e non volete sprecare un CD in più di quelli effettivamente necessari per ottenere una buona qualità (come il sottoscritto ad esempio ;).

Il rapporto bit per pixel (bit / pixel, bpp)

Un metodo potrebbe essere quello di fare un pò di conti e vedere il numero di bit che mediamente vengono assegnati a ciascun pixel del nostro video (!). La cosa sembra complicata, ma prestate un pò di attenzione e vedrete che in realtà tanto difficile non è. Ciò che è però necessario sapere a priori è quanti bit/pixel (bpp) siano necessari per poter avere un video di qualità accettabile.
Supponiamo che mediamente siano sufficienti 0,25 bit/pixel (bpp) per avere una qualità accettabile (comprimendo il video in Mpeg4). In tal modo è possibile calcolare il numero minimo di MB (Megabytes) da assegnare al video, ovvero il numero di megabyte sotto il quale non dovremmo andare per garantire un risultato di qualità. Per fare il conto sostanzialmente basta sapere la risoluzione del video (il n° di pixel orizzontali ed il n° di pixel verticali) e la sua durata e tenere conto che in ogni secondo di video vi sono 25 fotogrammi (se il video è in formato PAL come del resto sono tutti i video prodotti e venduti in Italia ed in UE).

Prendiamo ad esempio un video di 640x352 pixel, della durata di 90 minuti (= 90 x 60 = 5400 secondi). Il conto è presto fatto:



PF = Numero di pixel per ogni fotogramma
ROriz = Risoluzione orizzontale in pixel
RVert = Risoluzione verticale in pixel

Risulta:



FTOT = Numero totale di fotogrammi
TSec = Durata in secondi del video
FSec = Fotogrammi al secondo

Sapendo che ogni pixel necessita di almeno 0,25 bit, ovvero:



calcoliamo:



BF = Numero di bit necessari per 1 fotogramma
PF = Numero di pixel per ogni fotogramma

da cui:



BTOT  = Numero di bit necessari per l'intero film
BF  = Numero di bit necessari per 1 fotogramma
FTOT  = Numero totale di fotogrammi

tenuto conto che:



ovvero



si ha:



Quindi per garantire la riuscita di un video di qualità nel nostro caso (video di 640x352 pixel, della durata di 90 minuti), potrebbero bastare poco più di 900MB. Questo sempre se il valore di 0,25 bpp fosse corretto e fosse costante, ovvero se non dipendesse dal film. Ma purtroppo così non è: il rapporto bit per pixel come indice di qualità, dipende dal video che si sta prendendo in esame (come del resto era logico aspettarsi). In effetti, sebbene con una certa approssimazione questo discorso possa valere per un gran numero di video o film, vi sono dei casi in cui questo metodo non funziona. Generalmente un valore di 0,25 potrebbe essere sufficiente, ma in certi casi potrebbe non esserlo, ed in altri potrebbe essere troppo elevato (uno spreco di bit in soldoni). Alcuni programmi, calcolano questo valore partendo dalla dimensione in MB che viene assegnata al video (basta effettuare il procedimento di sopra alla rovescia) e lo usano come valore indicativo della possibile qualità del video dopo la compressione:






Indicativamente valori inferiori a 0,20 bpp potrebbero non essere sufficienti per una qualità accettabile, mentre valori superiori a 0,30 bpp vi daranno sicuramente un risultato di ottima qualità. Rimane comunque un certo margine di incertezza e non è infatti possibile usare solo questo parametro per garantire il risultato ottimale (massima qualità con il minimo spreco di spazio).
 
Facciamo un esempio in cui il metodo appena descritto del calcolo del rapporto bit/pixel in realtà non risulta utile per una stima corretta delle dimensioni minime del video atte a garantire una buona qualità.

Il "caso"  The Mothman Prophecies

"The Mothman Prophecies" di 115 minuti, risoluzione 640x272 è stato compresso in un solo CD, con una dimensione del file video di 555MB; facendo un po' di conti, risulta un rapporto bit/pixel = 0,15
"Balck Hawk Down" di 138 minuti, risoluzione 640x256 è stato compresso in due CD, con una dimensione del file video di 1167MB; facendo un po' di conti, risulta un rapporto bit/pixel = 0,29

Eppure vi assicuro che non si nota la differenza in termini qualitativi; relativamente parlando i due film sembrano compressi con lo stesso bitrate medio, ma ovviamente non è così. Tra l'altro a priori un rapporto bpp di 0,15 mi avrebbe suggerito che lo spazio non era sufficiente per una qualità accettabile. Il fatto è che  "The Mothman Prophecies" è un film composto di sequenze molto scure, vi sono notevoli sezioni in cui si hanno sfondi fissi con poco movimento in primo piano, insomma tutte situazioni che portano complessivamente ad un notevole abbassamento del bitrate necessario per la codifica (cosa che si poteva intuire osservando il film). In sintesi il primo film era estremamente comprimibile, una situazione estremamente favorevole, mentre il secondo risultava di una comprimibilità "normale".

Esiste dunque un metodo per prevedere la comprimibilità di un video?

Il metodo c'è, anzi ve ne sono 2; il primo consiste nell'effettuare un cosiddetto test di comprimibilità, il secondo consiste nell'eseguire il primo passaggio della codifica e creare il file video con quantizer = 2 oppure nell'analizzare il file stats creato dal codec sempre al termine del primo passaggio (rispetto al primo metodo è leggermente più preciso, ma non consente di stabilire la dimensione del file video a priori, ovvero prima ancora di iniziare la compressione).

Test di comprimibilità

Alcuni software, quali GordianKnot, consentono di effettuare un test sulla comprimibilità prima della codifica del film, ed il test è effettuabile sia con il codec Xvid, sia con il DivX. Iniziano ad essere disponibili anche i primi software che consentono di effettuare test di comprimibilità con praticamente qualunque codec video. Per il codec Xvid potete usare Enc by Jonny, che tra le varie cose permette anche di gestire anche la compressione del video (tramite VirtualDub). Come funziona un test di comprimibilità? Viene praticamente compressa e codificata una piccola parte del video (generalmente il 5%); terminata la compressione, note le dimensioni del file risultante e nota la percentuale di video compressa, è possibile risalire alle dimensioni che avrebbe il video intero compresso, commettendo generalmente un errore di qualche punto percentuale. Un test di comprimibilità simile a quello effettuato da GordianKnot (comprimendo ad esempio il 5% del film) potrebbe essere implementato utilizzando, all'interno di in uno script per AviSynth 2.5 il filtro SelectRangeEvery (video_di_input, periodo, num_fotogrammi) (è un filtro build-in, interno, di AviSynth, disponibile solo nelle versioni 2.5 e successive, ma non disponibile nelle versioni precedenti), dove periodo è un numero intero che descrive ogni quanti fotogrammi verranno selezionati il numero di fotogrammi specificati in num_fotogrammi. Ad esempio SelectRangeEvery(1000,50) seleziona 50 fotogrammi ogni 1000: vengono selezionati i fotogrammi 0-50, 1000-50, 2000-50, ecc... Si tratta quindi di effettuare la codifica con VirtualDub o con un altro programma a piacere, e, note le dimensioni del video corrispondente al 5% dell'intero film, stimare la dimensione finale del video moltiplicando tale valore per 20 (es: se il file video corrispondente al 5% risulta avere una dimensione di 75MB, è probabile che l'intero video abbia una dimensione finale di 75x20=1500MB). Per rendere attendibile il risultato vi consiglio di scegliere degli intervalli piuttosto ampi (1000-2000), onde consentire al codec di effettuare un certo grado di compensazione del moto. Questo metodo, in genere, data l'esiguità della parte di video da comprimere (generalmente il 5%) non richiede molto tempo.

Creazione del video durante il primo passaggio o analisi del file stats

E' il metodo sostanzialmente più preciso, ma che non consente di conoscere la possibile dimensione del nostro video se non al termine del primo passaggio. Disabilitando l'opzione "Discard first pass" nella finestra di configurazione  "Two Pass" del codec Xvid, durante il primo passaggio viene creato dal codec il video con quantizers = 2. Al termine si potrà quindi conoscere la dimensione del video creato alla massima qualità e quindi avente dimensione massima. Note le dimensioni del file video, è quindi possibile avere un'idea della comprimibilità, ovvero quanto sia comprimibile il video, ovvero quanti MB siano necessari per la massima qualità; più basso è questo valore, più il video risulta favorevolmente comprimibile, e quindi minore risulta lo spazio (o il numero di CD) di cui abbiamo bisogno per ottenere una qualità paragonabile all'originale. In genere si può ottenere un'ottima qualità impostando nella finestra del secondo passaggio, come dimensioni finali per il video, un valore tra il 70% e l'80% delle dimensioni del video ottenuto con la qualità massima (quantizer = 2). Potreste ottenere una qualità accettabile anche con un valore attorno al 60% (ma qui dipende da cosa intendete per accettabile).  Anche senza creare il video durante il primo passaggio (ad esempio nel caso abbiate problemi di spazio), è comunque possibile conoscerne le dimensioni utilizzando alcuni programmi che leggono il file stats; uno tra tutti "Nitrogen's XviD Stats Viewer", decisamente generoso nelle informazioni che è in grado di elargire.

Concludendo: partendo dalla durata del film è possibile farsi solo un'idea di partenza molto approssimativa dello spazio necessario per una buona codifica; tenendo poi conto del tipo di film che andiamo a comprimere, ovvero se ci troviamo in una situazione particolarmente favorevole  (film molto scuro, statico, con poche scene d'azione) potremmo ipotizzare di essere in una situazione di materiale video altamente comprimibile e quindi accettare anche valori del rapporto bit/pixel estremamente bassi. A questo punto si potrebbero verificare le ipotesi di partenza effettuando un test di comprimibilità oppure effettuare un primo passaggio e procedere quindi all'analisi del file stats. Questo ed un pò di pratica ed esperienza, dovrebbe essere tutto quello di cui avrete bisogno per creare dei video perfetti anche dal punti di vista qualitativo, senza inutile spreco di tempo e spazio (ovvero CD-R).


PARTE III - La configurazione del codec Xvid

Veniamo quindi alla configurazione del codec Xvid. Questa la prima finestra che si presenta quando andiamo a scegliere il codec ed a configurarlo tramite il nostro programma preferito (vedi ad esempio la Guida all'uso di VirtualDub).


 Le opzioni disponibili nella sezione "Encoding Options", variano a seconda di quello che viene selezionato in "Encoding Mode"; le modalità possibili di codifica sono le seguenti e verranno analizzate in dettaglio nel resto dell'articolo.



Si noti inoltre che anche le impostazioni configurabili nella sezione "Advanced options..." , variano a seconda del modo di compressione scelto (in particolare in alcune modalità certe opzioni potrebbero non essere disponibili).

Vediamo in dettaglio i singoli casi.

Encoding Options

Modalità ad un solo passaggio.

Questi metodi di compressione si differenziano dai metodi a due passaggi che vedremo di seguito, in quanto la compressione del video viene effettuata in un solo passaggio.

1 Pass - CBR: modalità ad un passaggio a bitrate costante (CBR = Constant Bit Rate); in questo caso ad ogni fotogramma viene assegnato lo stesso numero di bits, indipendentemente dalla sua complessità. In realtà è più un metodo a bitrate medio, in quanto il valore costante, più che essere rispettato sul singolo fotogramma, si tenta di rispettarlo in un determinato intervallo di fotogrammi (mediamente ai fotogrammi viene assegnato il bitrate selezionato). La quantità di bits, per la precisione di Kbps assegnati a ciascun fotogramma è selezionabile o spostando lo "slide" (indicato dalla freccia) o semplicemente scrivendo il numero di Kbps nell'apposito spazio. E' possibile impostare un valore qualsiasi compreso tra 1 e 10000 (ma impostare un valore uguale ad 1 non ha molto senso). Per rispettare lo standard richiesto dal consorzio che ha fondato l'Mpeg4, si considera 1 Kbit = 1000 bit (e non a 1024), ovvero il prefisso K indica semplicemente le migliaia (1000).

1 Pass - quality: modalità ad un passaggio cosiddetta a "qualità costante"; il codec tenta di comprimere ogni fotogramma con la stessa qualità, indifferentemente dalla complessità o meno del fotogramma stesso. E' possibile impostare un valore per la qualità spostando la barra o scrivendo un valore tra 1 e 100 nell'apposito spazio (100% = massima qualità). La differenza con la modalità "1 Pass - quantizer" dove il quantizer è fisso per ogni fotogramma e dove può assumere solo valori interi (es. 2, 3, 4...) , viene qui utilizzato un "quantizer medio costante" ovvero mediamente il quantizer rimane costate e può assumere anche valori non interi come ad es. 2,5, valori ottenuto facendo variare il quantizer tra 2 e 3 in fotogrammi successivi: il primo fotogramma viene ad esempio codificato con quantizer 2, il secondo con quantizer 3, il terzo con quantizer 2, il quarto con quantizer 3 e così via, in modo tale che mediamente il quantizer assume il valore 2,5.

1 Pass - quantizer: un altro metodo di compressione a "qualità costante"; la differenza con modalità 1 Pass - quality è che ora ad ogni fotogramma viene assegnato lo stesso quantizer, ovvero viene compresso ogni fotogramma allo stesso identico modo (vi ricordo che il quantizer indica il livello di dettaglio che viene rimosso), mentre nel metodo sopracitato (1 Pass - quality), i quantizer non erano fissi ma piuttosto modulati, variati, a seconda del comportamento di altri parametri del codec onde garantire complessivamente un effetto "qualità costante". Con questo metodo invece i quantizer vengono bloccati ed in un certo senso può essere considerato effettivamente il vero metodo a qualità costante; i valori possono variare da 1 a 31, ma non consiglio di usare il valore 1 (la cui differenza con il valore 2 è minima e non giustifica l'aumento notevole di dimensioni nel file finale), o valori superiori a 4 (se interessa un minimo di qualità).

I metodi di compressione ad una sola passata fin qui esposti, sono generalmente indicati in tutte quelle situazioni in cui non interessi minimamente lo spazio occupato dal file video ma esclusivamente la qualità del risultato. In particolare il metodo a quantizer fisso = 2 dovrebbe garantire il miglior risultato in termini di qualità, sebbene le dimensioni del file video possano essere piuttosto elevate. Se possedete un computer sufficientemente potente (soprattutto in termini di velocità del processore) potreste provare ad utilizzare una di queste alternative per la cattura video in tempo reale in formato mpeg4 (ad esempio per la registrazione da una videocamera o da una scheda TV). In particolare, in queste situazioni, si dovrebbe preferire il metodo 1 pass - CBR e disabilitare funzioni avanzate che potrebbero rallentare la cattura (B-Frames, VHQ Mode, Croma Motion, etc...)


Modalità a due passaggi.

La modalità di compressione in due passaggi richiede il doppio del tempo rispetto alle modalità ad una singola passata viste in precedenza, tuttavia è anche l'unico metodo di compressione che consente di impostare a priori la dimensione esatta del file video (con un margine di errore minimo) ed è anche quella che, a parità di bitrate fornirà la qualità video migliore. Sebbene sia possibile prevedere anche con il metodo "1 Pass - CBR" la dimensione finale del nostro file (è sufficiente effettuare qualche piccolo conto), è altrettanto vero che la modalità CBR non consente una elevata precisione sulla dimensione finale senza contare che la qualità ottenibile, a parità di bitrate medio impiegato, risulta generalmente inferiore.
L'utilizzo del doppio passaggio sostanzialmente consente di risparmiare bit preziosi nelle scene video semplici da comprimere, per riservarli a quelle più complesse. Lo schema seguente illustra il funzionamento della modalità "2 Pass...":



L'utilizzo dei sue passaggi è necessario in quanto il codec di compressione non può conoscere a priori quali e quante siano le scene più semplici e quali e quante quelle  più complesse. Ecco quindi che risulta necessario effettuare una prima analisi del video, cosa che viene effettuata nel primo passaggio. Durante il primo passaggio il codec comprime il film con la massima qualità possibile (minima compressione), impostando tutti i quantizers al valore di 2, un pò quello che succede quando comprimiamo con quantizer fisso = 2. Infatti, disabilitando l'opzione "Discard first pass" presente nella scheda "Two Pass", viene creato il file video ottenibile con la massima qualità possibile ed avente quindi anche dimensione massima (in realtà la massima qualità corrisponderebbe a quantizer = 1, tuttavia il lievissimo incremento qualitativo che si potrebbe ottenere abbassando i quantizers da 2 ad 1, non giustificherebbe il netto aumento delle dimensioni del file finale).
Oltre al file video codificato con quantizers costanti pari a 2 (che ripeto viene creato solo se è deselezionata l'opzione "Discard firts pass"), durante il primo passaggio viene generato anche un file contenente le statistiche di bitrate del file originale e le indicazioni dove posizionare i fotogrammi chiave, i P-frames ed i B-Frames (il famoso file "1st pass stats" che vedremo più avanti). Durante il secondo passaggio viene invece generato il filmato finale (generalmente un file avi, ma non necessariamente, essendo il formato avi solo un "contenitore" per il video mpeg4), usando tutte le informazioni raccolte durante il primo passaggio nel file .stats e integrando con qualche altro procedimento addizionale.

In sintesi: con il metodo di codifica a due passaggi è possibile mantenere sostanzialmente una qualità costante in tutto il video, indipendentemente dalla complessità della sezione di video in esame. La differenza sostanziale rispetto ai metodi ad un solo passaggio a qualità costante (1 Pass - Quality o 1 Pass - Quantizer), è che il bitrate risulta essere limitato, ovvero che non possiamo trascurare le dimensioni occupate dal video; resta comunque ovvio che la qualità media ottenibile dipenderà dal bitrate disponibile, ovvero dai megabyte occupati dal video e che al di sotto di un determinato numero di MB, per quanto si tenti di agire sui parametri di configurazione del codec, il bitrate sarà comunque troppo basso per garantire una buona qualità.

2 Pass - 1st pass: in tal modo viene effettuato il metodo di codifica in due passaggi, ed in particolare viene scelta la modalità primo passaggio (passo ovviamente obbligato se poi dovete effettuare il secondo passaggio) onde configurare le impostazioni avanzate del codec per il primo passaggio.

2 Pass - 2nd pass Internal: secondo passaggio della codifica in due passaggi; è necessario fornire al codec le dimensioni in kbyte (1 Kbyte = 1024 bytes) che desideriamo abbia il nostro video al termine della conversione. Il codec provvederà sulla base dei dati raccolti durante il primo passaggio e salvati nel file .stats a comprimere il video onde rispettare le dimensioni desiderate affidando agli algoritmi interni (implementati nel codec Xvid stesso) la ridistribuzione ottimale del bitrate.

2 Pass - 2nd pass External: secondo passaggio della codifica in due passaggi; i parametri da passare al codec, l'analisi del file stats e la compressione da assegnare ai singoli fotogrammi vengono gestiti da un programma esterno e non più dall'algoritmo interno al codec. Per essere utilizzato richiede un programma che sia in grado di gestire la curva di compressione del codec (es. GordianKnot).


Modalità Test

Null - test speed: non viene scritto nessun file video; l'opzione è utile quando si desideri studiare l'impatto di alcune opzioni sulla velocità di codifica.


Prima di affrontare le impostazioni della sezione "Advanced Options...", vediamo le altre impostazioni selezionabili in questa finestra.

Decoder Options

Cliccando su "Decoder Options..."



compare la seguente finestra:



Qui è possibile selezionare alcune opzioni per il postprocessing; queste opzioni comunque non influenzano in alcun modo la codifica ma solo la decodifica del video ovvero quando andremo a guardare il nostro film una volta compresso, e non è comunque necessario selezionarle o modificarne lo stato. Possono comunque essere modificate in un secondo momento. Generalmente per video compressi con una buona qualità, non consiglio di applicare filtri di postprocessing, in quanto tenderebbero a ridurre la qualità dell'immagine. Un caso particolare potrebbe essere quello dei cartoni animati o degli anime giapponesi, nei quali invece i filtri di deblocking potrebbero migliorare la qualità generale del video. Per maggiori dettagli vi rimando alla Guida introduttiva al postprocessing.

Load Defaults

Cliccando su "Load Defaults...":



vengono configurate tutte le opzioni così come impostate dagli sviluppatori in fase di compilazione del codec. In genere viene consigliato di caricare le impostazioni standard di default ogni qual volta si installa una nuova versione del codec oppure ogni qual volta si hanno problemi in fase di codifica e non si è in grado di individuarne la fonte.


Qui di seguito verranno ora illustrati e spiegati tutti i parametri disponibili nelle schede di impostazioni avanzate. In particolare dovete far riferimento a quanto spiegato nella sezione seguente se state codificando nelle modalità 1 Pass, o se state configurando i parametri per il primo passaggio nelle modalità a due passaggi. Se invece desiderate configurare le impostazioni per il secondo passaggio, fate riferimento alla sezione "Impostazioni del codec per il secondo passaggio". Vi ricordo inoltre che l'aspetto delle singole finestre, in particolare la disponibilità o meno di alcune opzioni, varia a seconda del tipo di codifica ("Encoding Mode") scelto; alcune opzioni potrebbero risultare non attive, in quanto utilizzate dal codec in altre modalità di codifica, mentre l'aspetto delle finestre qui rappresentato è quello relativo alla codifica in due passaggi, dove è stato scelto "2 Pass - 2nd pass Internal" per il secondo passaggio.

Modalità "1 Pass..." e "2 Pass - 1st pass": impostazioni per la codifica ad 1 solo passaggio ed impostazioni dei settaggi per il primo passaggio nella codifica a due passaggi.

Le impostazioni che verranno volutamente trascurate durante questa prima analisi, saranno affrontate nella seconda parte ("Impostazioni del codec per il secondo passaggio") in quanto inutili o non utilizzabili nella codifica ad 1 passaggio o durante il primo passaggio nella codifica a 2 passaggi.

Procediamo dunque con le "Advanced options...":



Si presenta la finestra seguente.

Scheda "Global"

Questa che vedete qui a lato la schermata della prima finestra di configurazione. I parametri mostrati non è detto siano i migliori. Procedendo con la lettura, troverete una spiegazione dei singoli campi modificabili. 

Global settings

Motion search precision: questo parametro indica l'accuratezza o precisione con cui il codec analizza il video ed è di fondamentale importanza per la qualità del risultato. Valori bassi consentono una maggior velocità ma una minor qualità; valori bassi possono essere consigliati solo per la cattura in tempo reale di un flusso video. In tutti gli altri casi vi consiglio di impostare il valore massimo, corrispondente a "6-Ultra High", che garantisce la miglior qualità possibile; solo nei casi di bitrate elevati o di processori non abbastanza potenti, potete provare ad utilizzare "5-Very High" che dovrebbe garantirvi un 10% in più in termini di velocità e quindi un certo aumento nel numero di fotogrammi al secondo (FPS) che il codec riesce a processare (maggiore il numero dei FPS, minore risulterà il tempo di codifica), ma anche qualcosina in meno in termini di comprimibilità (se è più comprimibile, le stesse informazioni richiedono meno bit che possono essere quindi utilizzati eventualmente in altre scene o risparmiati dando una dimensione finale del file inferiore, a parità di qualità). Ricordate comunque che la compressione del video in mpeg4 richiede una elevata potenza di calcolo, soprattutto se si utilizzano alcuni dei parametri avanzati disponibili per il codec (Lumi masking, B-Frames, Croma motion  etc...), quindi il componente del vostro PC che farà la differenza in termini di tempi di codifica sarà per il 95% il processore. Direi che processori AMD di almeno 1,2Ghz od Intel PIV di almeno 1,6Ghz, sono consigliabili per la codifica (almeno per non avere tempi esageratamente lunghi del tipo oltre le 10 ore). Entrando un pò nei dettagli tecnici, diciamo che livelli da 1 a 3 utilizzano le stesse impostazioni interne per la stima del moto. A partire dalla precisione 4, il codec usa una interpolazione a mezzo pixel per un risultato più preciso. A partire dal livello 5, il codec usa i "vettori di moto inter4v", ovvero tutti i 4 blocchi di dimensione 8x8 di ogni macroblocco di dimensione 16x16 (macroblocchi in cui viene suddiviso il fotogramma dal codec ai fini della compressione), riceve il proprio vettore di moto. Vi ricordo che la compensazione del moto viene effettuata ricercando, tra fotogrammi adiacenti, blocchi di 8x8 pixels tra loro simili. Con il livello di precisione 6, la ricerca è estesa ad un intervallo di pixel adiacenti maggiore, e quindi la codifica risulta più lenta (10% circa), a vantaggio tuttavia di una maggior comprimibilità (1) a causa di una miglior costruzione dei P e B-frames. Se si desidera la massima qualità, consiglio di utilizzare "6 - Ultra High".

Quantization type: in questo campo viene scelta la matrice di quantizzazione da utilizzare durante la compressione; tale matrice contiene i valori di quantizzazione (quantizers) che vengono utilizzati per la compressione (divisione) dei singoli coefficienti DCT. La scelta potrebbe dipendere non solo dal video, ma anche dal bitrate disponibile; per alti bitrate (2CD ad esempio), "MPEG" dovrebbe garantirvi un'immagine più dettagliata e definita, ovvero una qualità migliore sebbene potrebbe essere presente una certa "granulosità" nel video, cosa comunque tipica del video MPEG (si nota spesso anche nei DVD); la presenza di una granulosità maggiore rende comunque il video meno comprimibile ed è per questo che questo tipo di quantizzazione viene consigliata quando non si sia in situazioni di bitrate limitato o spazio limitato. Per bassi bitrate invece potrebbe essere più consigliabile utilizzare "H.263" che tratta allo stesso modo alte e basse frequenze video e dà un risultato più sfumato e meno dettagliato e quindi un video più comprimibile. Selezionando "MPEG-Custom" consente invece di utilizzare una matrice di quantizzazione personalizzata che può essere eventualmente caricata agendo nella scheda "Quantization". Le altre due possibilità, "Modulated" e "New Modulated HQ" possono essere utilizzate esclusivamente nel secondo passaggio della codifica a 2 passaggi, e non vanno utilizzate nelle codifiche ad 1 solo passaggio, né nel primo passaggio della codifica a 2 passaggi. Vi rimando alle impostazioni per il secondo passaggio per maggiori dettagli.


FourCC used: questo parametro è in realtà un residuo di quando lo sviluppo del codec Xvid era ancora agli albori, e non era stato ancora correttamente implementato un filtro DirectShow in grado di riprodurre i video compressi con Xvid. Tuttavia, poiché si trattava comunque di un formato mpeg4, era (ed è tuttora) possibile utilizzare un filtro DirectShow esistente disponibile per un altro codec (il DivX ad esempio) per decomprimere i flussi video Xvid. Se si lascia XVID viene utilizzato il filtro che viene installato con il codec Xvid stesso; DIVX consente invece di utilizzare il decodificatore distribuito con il codec DivX (che comunque deve essere installato). E' comunque possibile modificare in un secondo tempo anche al termine della conversione tale parametro, tramite un'apposito programma. Per maggiori informazioni, vi consiglio di leggere la guida sulle basi del postprocessing. 

VHQ Mode: la sigla VHQ non è un acronimo ben definito, Koepi l'ha definita "Vastly Hyped Quality" (qualcosa come qualità eccezionale o giù di li), comunque sia, come più volte sottolineato da qualcuno (3), VHQ non significa "Very High Quality", quindi non passate subito ad attivare il valore 4. In un certo senso questa opzione effettua una più precisa / economica (in termini di bit) ricerca e "mode decision" dei vettori di moto. Ovvero: il VHQ Mode fa sostanzialmente due cose.1) Anzitutto è in grado di prevedere il numero di bit che verranno assegnati ad un determinato macroblocco in diverse ipotesi e quindi scegliere quello che ne utilizza il numero minore, ovvero prova diversi modi (algoritmi?) con cui potrebbe essere compresso lo stesso macroblocco (sempre mantenendo però la stessa qualità) e quindi sceglie quello che consuma il numero minore di bit. 2) In secondo luogo, è in grado di effettuare una limitata ricerca sui vettori di moto onde minimizzare il numero di bit necessari per un determinato scenario, dove con scenario si intendono diverse modalità di macroblocchi (ovvero al macroblocco potrebbe essere assegnato un solo vettore di moto, oppure quattro vettori differenti od ancora nessun vettore, ed in tal caso il macroblocco sarebbe di tipo intra, come gli I-Frames).(3)
La decisione sulla modalità di "archiviazione" di un macroblocco, è basata sulla quantità di distorsione introdotta (Rate-Distortion (R-D) based VHQ modes); le conseguenze sono che generalmente l'utilizzo del VHQ porta ad una aumento della qualità (l'aumento sarà difficilmente visibile, ma comunque quantificabile come piccolo incremento del PSNR Picture Noise to Signal Ratio), ed a una diminuzione delle dimensioni del file video (dal 5 al 10% in meno nella modalità 4).
Il livello 1 (Mode Decision) sembra quello più consigliato, in quanto pare garantire un miglior rapporto tra qualità, riduzione delle dimensioni del file ovvero aumento della comprimibilità (2-5% in meno), e rallentamento della velocità di codifica (circa +20% del tempo rispetto a quando è disattivata, 0 - Off). Riguardo a quest'ultima affermazione, è doveroso sottolineare che l'opzione non è stata ottimizzata per la velocità di codifica. La conseguenza è che attivando la modalità 4 (Wide Search) i tempi di codifica potrebbero tranquillamente raddoppiarsi, cosa cui non tutti sono disposti ad accettare. Alla luce di queste considerazioni pare quindi saggio limitare l'utilizzo delle modalità 2, 3 e 4 solo in situazioni particolarmente difficili, quali casi di bitrate estremamente basso come ad es. film di durata superiore alle 2 ore, a risoluzioni elevate (640x... o 720x...) archiviati in un solo CD-R.
Si noti infine che il R-D VHQ Mode funziona solo sui P-Frames (ovviamente sugli I-Frames non viene effettuata alcun tipo di ricerca sui vettori di moto) e non è stato ancora implementato sui B-frames. Risulta quindi piuttosto logico ipotizzare che si ottengano i risultati migliori in termini di aumento della comprimibilità (ovvero di riduzione delle dimensioni finali del file video) quando non si stanno utilizzando i B-Frames.
VHQ mode al momento è compatibile con tutte le altre opzioni del codec ad esclusione del Global Motion Compensation (GMC). Non utilizzatela quindi in abbinamento con il GMC.
Più elevato è il valore dell'opzione "VHQ Mode", più in dettaglio viene effettuata la ricerca delle possibili alternative alle diverse configurazioni dei vettori di moto. Il valore 0 - Off disabilita l'opzione. Il valore 1 - Mode Decision effettua solo una decisione sugli scenari diversi senza effettuare una ricerca delle possibili alternative, cosa che invece viene effettuata dal livello 2 in poi.

Maximum e Minimum I-frame interval: indicano rispettivamente l'intervallo massimo e minimo in termini di fotogrammi, che può intercorrere tra un fotogramma chiave (key-frame od I-frame od Intra-frame) ed il successivo. Il valore Maximum dovrebbe essere qualcosa attorno a 10-12 volte il numero di FPS (fotogrammi per secondo) del film sorgente (in formato PAL, tipico in Europa ed in Italia, si hanno 25 FPS), ovvero un valore tra 250 e 300. Per quanto riguarda il "Minimum...", scegliete un valore tra 1 e 5 (anche se sono più propenso a consigliare il valore 1). Valori consigliati: 1/5-250/300.

Enable lumi masking: il luminance masking (mascheramento della luminanza) è simile al "psychovisual model" del DivX 5: si sfrutta la minor capacità dell'occhio umano nel distinguere i dettagli nelle zone molto scure o molto chiare di un'immagine, soprattutto se si sta osservando di sequenze di immagini (un video). Alla base del lumi masking vi è la possibilità peculiare del codec Xvid di assegnare ad ogni macroblocco (16x16 pixels) un differente quantizer, ovvero la possibilità di comprimere in maniera indipendente i singoli macroblocchi; risulta quindi logico utilizzare quantizers superiori per i macroblocchi particolarmente scuri o chiari ed impiegare i bit risparmiati in zone di luminosità intermedia onde aumentarne la qualità. E' chiaro che in situazioni di bassi bitrate questo potrebbe aumentare la qualità globale del video ovvero aumentarne la comprimibilità, dato che è possibile ottenere una qualità superiore a parità di bitrate. Sebbene teoricamente l'opzione si presenti estremamente interessante, al lato pratico è bene ricordare che è ancora in fase sperimentale, ed in alcune situazioni il video potrebbe presentare un numero superiore di artefatti (blocchettizzazione) rispetto a quando l'opzione non è attivata. Il consiglio è di non lasciare attivo il lumi masking di default e di limitarsi ad usarlo in tutti quei casi particolari che potrebbero effettivamente beneficiare dell'opzione, ovvero film particolarmente scuri e/o luminosi di cui si desidera aumentare la comprimibilità e/o nelle situazioni di basso bitrate (gli sviluppatori ritengono comunque l'opzione ancora non funzionante e ne sconsigliano l'uso, in quanto non sembra contribuire positivamente alla qualità del video). Un'ultima nota: nelle modalità di codifica a due passaggi, si consigliava di non attivare l'opzione durante il primo passaggio, ma non vi è un motivo preciso; per il perfetto funzionamento della curva di compressione interna del codec, l'opzione andrebbe usata in entrambi i passaggi. Comunque, nel caso abbiate problemi, solo come ultima risorsa provate a ripetere la codifica abilitando il l.m. solo nel secondo passaggio.

Enable grayscale: selezionate questa opzione solo nel caso vogliate codificare il film in bianco e nero (scala di grigi). Quando l'opzione è attivata, tutte le informazioni sui colori vengono scartate, in particolare si usano le sole informazioni sulla luminanza (Y), mentre le componenti sul colore memorizzate in Cb e Cr vengono eliminate.

Enable interlacing: attivate questa opzione nel caso il film sorgente sia in formato interlacciato (vi rimando per le spiegazioni all'ottimo articolo di Benny che trovate a questo indirizzo http://www.benis.it/dvd/template258/tmpeg258.html). L'opzione è necessaria in quanto in video interlacciato la gestione della compensazione del moto risulta più complessa (deve essere effettuata a fotogrammi alterni). E' importante sottolineare che questa opzione non elimina l'interlacciamento di un video, ma semplicemente attiva il supporto per video interlacciati.

Zoom (200%) su di un tipico esempio di linee orizzontali che si notano in un video interlacciato attorno a soggetti in rapido movimento

Use croma motion: effettuando una stima del movimento anche nelle componenti del colore (Cb e Cr), questa opzione migliora ulteriormente la precisione nell'analisi del movimento (Motion Estimation) nei blocchi 8x8, e può essere considerata qualcosa come un livello 7 di Motion search precision (7). L'ulteriore analisi di moto, può migliorare qualità e comprimibilità del video ma rallenta anche la velocità di codifica. Consigliato per bassi bitrate o per ottenere la massima qualità.

Quarterpel (Qpel, Quarter PixEL resolution): l'utilizzo del quarterpel aumenta la precisione nell'analisi del moto e quindi la qualità video, a favore di una superiore definizione del video (le immagini dovrebbero apparire più definite); non dovrebbero invece esserci sostanziali variazioni in termini di comprimibilità, sebbene si possa capitare di assistere ad una piccolo aumento delle dimensioni del file video. Il funzionamento: come già accennato in precedenza, ai fini della codifica vengono analizzate le differenze tra fotogrammi vicini, e sono queste differenze che vengono codificate, piuttosto che il fotogramma in se stesso (escluso ovviamente il caso degli I-Frames). Le differenze tra singoli fotogrammi vengono ricercate facendo riferimento ai macroblocchi di 16x16 pixels od ai blocchi di 8x8 pixels. Ad esempio, la parte del fotogramma corrente, individuata dal blocco di coordinate (1,1) (coordinate riferite alla griglia in cui è diviso il fotogramma), potrebbe spostarsi nei pressi della posizione (1,2) nel fotogramma successivo. Raramente capita che i movimenti siano perfettamente centrati nelle coordinate della griglia, e una risoluzione limitata a blocchi di coordinate 8x8 (ovvero alla possibilità di spostarsi solo di un numero intero di valori per le coordinate), potrebbe non essere sufficientemente precisa. E' stato così introdotto l'utilizzo dei quarti di valore per lo spostamento nei singoli blocchi della griglia, ovvero vengono considerati anche movimenti di soli 1/4 (quarter) di blocco. Il codec così è in grado di effettuare una modellizzazione del moto più precisa e di analizzare movimenti più piccoli, ad esempio dalle coordinate (1,1) alle coordinate (1.25, 1.75).(4) Si ottiene in tal modo la superiore precisione nell'analisi del moto cui accennavo in partenza. Dal lato pratico, vi erano stati inizialmente problemi nell'utilizzo del qpel (effetti di trascinamento, sfumatura o macchia che di si voglia, in inglese "smearing effects") che sono stati risolti con le più recenti distribuzioni del codec; ritengo sia comunque necessaria una certa prudenza nel suo utilizzo anche in virtù del fatto che riduce non di poco la velocità di codifica (un decremento di oltre il 30%) e che i miglioramenti ottenibili possono variare da video a video. Sono stati inoltre segnalate possibili incompatibilità con alcuni decoder Mpeg4 che non implementano ancora correttamente lo standard ISO e viene consigliato per la decodifica l'utilizzo del decoder Xvid o di ffdshow (vedi guida postprocessing).

Global Motion Compensation (GMC): in casi particolarmente favorevoli l'utilizzo del GMC potrebbe portare ad un decremento delle dimensioni video (a parità di qualità) dell'ordine dell'1 o 2%. Funzionamento: teoricamente il GMC dovrebbe compensare situazioni in cui si hanno movimenti globali di un intero fotogramma in una direzione preferenziale, come nei casi di panoramiche, zoom, ecc... od in tutti qui casi in cui i vettori di moto assegnati ai singoli blocchi risultano avere una direzione parallela (questo indica per l'appunto una traslazione globale dell'intero fotogramma). In un post apparso sul forum di doom9, si accennava al fatto che forse la GMC non interviene direttamente sulle panoramiche in quanto l'analisi sui vettori di moto effettuata dall'encoder dovrebbe essere in grado di trattare sufficientemente bene anche questi casi; il post continuava spiegando che più probabilmente la GMC interviene  nel ridurre il numero di dati necessari nella matrice DCT per descrivere un movimento, in quanto situazioni quali zoom o rotazioni, se viste alla scala del singoli blocco, approssimano ma non equivalgono ad una traslazione. In virtù del fatto che in ogni caso non dovrebbe portare a nessun degrado qualitativo (dovrebbe, e qui il condizionale è d'obbligo), e dato che la velocità di codifica non viene significativamente ridotta (1 FPS su di un AthlonXP 2400+), potreste decidere di lasciare il GMC abilitato di default tuttavia NON deve essere utilizzato in combinazione con il "VHQ Mode" in quanto funzioni attualmente non compatibili. A dovere di cronaca si noti che Nic generalmente non consiglia l'utilizzo del GMC, e Koepi sottolinea che  l'attuale implementazione del GMC può portare qualche beneficio solo in situazioni estremamente particolari, ben lontane dal tipico film o video di tutti i giorni.

B-Frame control

Maximum B-frames: il numero massimo di B-Frames consecutivi. Attualmente viene consigliato di impostarlo a 2, ma potreste provare anche i valori 3 o 4 sebbene valori superiori a 2 non siano consigliati per possibili impatti negativi che potrebbero avere sulla qualità; valori superiori a 4 non sembrano aumentare in modo significativo la comprimibilità (ovvero ridurre la quantità di bit necessari per la codifica). (3) Per disabilitare l'uso dei B-Frames, inserite il valore -1. Impostando il valore 1 si ottiene lo stesso numero di B-Frames massimi del DivX(10).

B-frame quantizer ratio (%) (rapporto) e B-frame quantizer offset (compensazione): questi ultimi due parametri servono per calcolare il quantizer da assegnare ad un determinato B-frame. La formula che viene usata per il calcolo del B-frame quantizer è la seguente: B-Frame quantizer = {1/2*[(Quantizer P-frame Precedente) + (Quantizer P-frame Successivo)]*(B-frame quantizer ratio) + B-frame quantizer offset} / 100. Un esempio sul funzionamento viene dalla risposta seguente pubblicata nel forum di Doom9:
 
...Se il "...quantizer ratio (%)" è settato al 100% ed anche il "...quantizer offset" è 100, il quantizer del fotogramma B (B-frame) sarà dato dal valore medio tra i quantizer del P-frame precedente e successivo addizionato di 1. Ovvero: P-frame(quant3), B-frame(quant = (3+3)/2 + 1 = 4), P-frame(quant3). Se viene aumentato l'offset ovvero la compensazione, ad esempio, a 200, lasciando inalterato "...quantizer ratio (%)" settato al 100%, il quantizer del B-frame verrà calcolato sempre come media dei quantizer dei P-frames adiacenti (precedente e successivo) ma sarà addizionato di 2. Ovvero: P-frame(quant3), B-frame(quant = (3+3)/2 + 2 = 5), P-frame(quant3). Se il "...quantizer ratio" è settato a valori superiori al 100%, il quantizer del B-frame non sarà più il valor medio addizionato di un fattore dipendente dall'offset, ma aumenterà esponenzialmente in funzione del valore dei quantizers dei P-frames. Se "...quantizer ratio" è settato al 150%, un P-frame quantizer uguale a 3, darà (teoricamente) un B-frame quantizer di 5.5, un P-frame quantizer uguale a 4, darà un B-frame quantizer di 7 e così via, con una crescita esponenziale del B-f quantizer in funzione del P-f quantizer e/o del "B-frame quantizer ratio"...".

Ancora, per chiarire le idee, utilizzando un quantizer ratio di 100, sostanzialmente verrà utilizzato per i B-Frames lo stesso quantizer usato per i fotogrammi P ed I (ovvero per il resto del video) e si utilizzerà sostanzialmente lo stesso grado di compressione su tutti i fotogrammi (l'offset consente eventualmente di aumentare compressione per i fotogrammi B); qualunque valore superiore a 100 tenderà invece a comprimere maggiormente i B-Frames rispetto agli altri fotogrammi, abbassandone quindi la qualità rispetto agli altri tipi di fotogrammi.

In sintesi, giocando con il quantizer ratio / offset, possiamo decidere il valore del quantizer da assegnare ai B-frames: tale valore può essere semplicemente calcolato come media tra il quantizer dei P-frames adiacenti addizionato di 1 (caso 100 / 100, maggior qualità), oppure possiamo scegliere di addizionare sempre un valore costante ma più elevato, lasciando invariato a 100 il ratio ed incrementando a piacere l'offset (es. 100/200, ma non c'è un limite superiore), oppure ancora possiamo preferire una crescita ancora maggiore aumentando entrambi i valori. In un certo senso possiamo pensare di aumentare in modo "indiscriminato" il quantizer del B-frame modificando l'offset, mentre potremmo preferire di utilizzare il ratio invece per un incremento più "mirato" sui frame più comprimibili (ovvero quelli cui è stato assegnato dal codec un quantizer superiore ai P-frames adiacenti). Un doveroso grazie a "blueseb" dal forum italiano di Doom9.
Difficile dire quali siano i valori migliori, ogni compressione video è una situazione diversa e non è quindi detto che un valore di 150 / 100 dia risultati migliori che non lasciare il ratio al 100% e variare il solo offset. Tuttavia è possibile dare alcune indicazioni: buone combinazioni ratio / offset con cui provare, sembrano essere: 150 / 100, 200 / 150, od anche 100 / 200 come consigliato da Iago (6). Potete comunque provare valori tra 100 e 200 per il "B-frame quantizer ratio (%)", tuttavia è stato sottolineato come valori superiori a 200 diano pessimi risultati in termini di qualitativi. (3) In sintesi, valori più bassi danno una qualità migliore a scapito ovviamente della comprimibilità (quantizers inferiori), valori più elevati danno quantizers superiori che portano ad una compressione maggiore ma ad una qualità inferiore. Nel caso vi si presenti il cosiddetto fenomeno dell'"undersize", provate ad usare la combinazione 100 / 100; nel mio caso ha risolto il problema.

B-Frames threshold: questo parametro influenza l'utilizzo dei B-frames da parte dell'encoder. Gli sviluppatori Xvid, a partire dalle distribuzioni del febbraio 2003, hanno modificato il comportamento dell'encoder nei confronti dei B-Frames, che vengono impiegati con più "parsimonia". L'encoder può ora "decidere" di non utilizzarli in tutte quelle scene statiche, nelle quali l'impiego dei B-Frames causava spesso la comparsa di artefatti video di compressione che portavano ad un conseguente degrado qualitativo dell'immagine. Il range dei valori possibili va da -40 a (teoricamente) +255: un valore negativo impone al codec di utilizzare un numero inferiore di B-frames, favorendo i P-frames che possono garantire una qualità superiore a scapito ovviamente di una dimensione superiore del video finale. Valori positivi invece "obbligano" il codec ad utilizzare un numero superiore di B-frames (il numero massimo di b-frames consecutivi è comunque limitato dal campo "Maximum B-Frames"). Il valore minimo -40 equivale a disabilitare l'utilizzo dei B-frames, mentre per valori superiori a +90 non dovrebbe notarsi più alcuna differenza. Il valore  0 dovrebbe andare bene nella maggior parte dei casi, tuttavia in situazioni di basso bitrate, potrebbe essere consigliato l'utilizzo di un maggior numero di B-Frames e quindi l'uso di valori tra +50 e +90.

Packed bitstream: se l'opzione viene attivata, l'encoder impacchetta un P-frame ed il successivo B-Frame in un unico bitstream; ad esempio, nel caso di un flusso video del tipo IPBBPBBPBB..., mentre normalmente i fotogrammi verrebbero impacchettati ciascuno nel suo bitstream: [I] [P] [B] [B] [P] [B] [B] [P] [B] [B]... ed in tal modo letti e decodificati uno alla volta, attivando l'opzione si avrebbe un flusso di questo tipo: [I] [PB] [B] [vuoto] [PB] [B] [vuoto] [PB] [B] [vuoto]...; in tal modo in fase di decodifica vengono letti (caricati in memoria dal decoder) due fotogrammi contemporaneamente, cosa che può velocizzare la fase di decodifica. Ed infatti una decodifica priva dei ritardi che potrebbero essere causati dalla presenza dei B-Frames, è proprio la funzione del Packed bitstream (che per la cronaca fu introdotto per la prima volta nel DivX versione 5.01). Qualcuno ha segnalato che la curva di compressione del codec potrebbe non essere in grado di gestire correttamente l'opzione (??...mah...), qualcun altro, invece, sostiene che potrebbe fornire una miglior qualità (...non vedo come), altri ancora hanno accennato al fatto che il video procede a scatti se abilitato il p. bitstream. Come potete intuire se ne sentono davvero di tutti i colori... Non ho effettuato ulteriori test, Nic consiglia di non utilizzarlo(10) (e se lo dice lui...): in sintesi: non attivatelo.

DX50 B-VOP compatibility: questa opzione è nata per garantire la compatibilità del video compresso anche con il decodificatore del DivX; infatti le versioni del DivX precedenti alla 5.03, non erano in grado di decomprimere flussi video in cui un B-Frame usava come referente futuro un I-Frame, e questa opzione impediva per l'appunto comportamenti di questo tipo. Ho aggiunto "in linea teorica" perché all'atto pratico l'incompatibilità apparentemente non si limitava solo a questo dettaglio, in quanto, come ho potuto constatare, sebbene si trattasse di video codificato con l'opzione attivata, questo non veniva riprodotto correttamente una volta che si cambiava il FourCC da Xvid a DivX (vedi "Guida introduttiva al postprocessing"). Comunque, dato che non influisce su velocità di codifica e qualità del risultato e che dovrebbe garantire una portabilità (leggi compatibilità maggiore) del video prodotto anche con futuri decoder hardware (es. lettori DivX da tavolo), consiglio di mantenerla attivata.

Print debug info on each frame: questo parametro è utile solo per eventuali test e verifiche; non influenza la qualità della codifica. Non è necessario selezionarlo a meno che non abbiate la necessità di effettuare dei test di controllo.


Scheda "Quantization"

I parametri di questa scheda risultano modificabili solo nelle modalità 1 Pass - CBR / quality (ed ecco perché viene mostrata adesso), e nella modalità 2 Pass - 2nd pass. Tuttavia restringere i quantizer ha effettivamente senso solo in quest'ultimo caso (2 Pass - 2nd pass) in quanto nelle altre modalità di codifica (CBR e quality), i quantizer utilizzati dipendono dal bitrate utilizzato (CBR) e dalla qualità scelta (quality). Nella codifica con il metodo 1 Pass - quantizer i parametri di questa scheda risultano non modificabili (in quanto costanti), come del resto non sono modificabili nella modalità 2 Pass - 1st pass che equivale sostanzialmente al metodo 1 Pass - quantizer = 2.





Utilizzando Load matrix... e Save matrix... è possibile caricare e salvare matrici esterne create da qualcun altro o da voi stessi.
 Quantizer restrictions

Min / Max I-frame quantizer: questi valori restringono il campo dei quantizer che possono essere utilizzati per i fotogrammi di tipo I. Valori consigliati sono quelli indicati in figura: 2 per "Min..." e 6 per "Max..." (viene quindi favorita la qualità per gli I-Frames).

Min / Max P-frame quantizer: questi valori restringono il campo dei quantizer che possono essere utilizzati per i fotogrammi di tipo P. Valori consigliati sono quelli indicati in figura: 2 per "Min..." e 16 per "Max...".

NOTA: anche i valori di default 2-31 per entrambi i campi garantiscono un risultato ottimale, in quanto non dovrebbe essere necessario limitare i quantizer in condizioni di bitrate sufficiente.

Min / Max B-frame quantizer: al momento non è ancora possibile gestire i quantizers dei B-frames, forse l'opzione sarà resa disponibile con le release successive del codec.

Edit Quantizer Matrix: Questo pulsante può essere utilizzato per modificare e personalizzare la matrice di quantizzazione di cui ho spiegato l'utilizzo in precedenza. Non credo sia necessario aggiungere altro, tranne precisare che non vi consiglio di modificarla se non sapete esattamente quello che state facendo (ma in tal caso dubito che stareste leggendo questa guida ;). Vi ricordo comunque che:
- ogni singolo valore non è altro che il numero per cui viene diviso ogni coefficiente della matrice 8x8 DCT;
- numeri più elevati corrispondono ad una compressione più elevata e quindi ad una maggior perdita di informazione (qualità video inferiore);
- in alto a sinistra vi sono i divisori per le basse frequenze video (che dovrebbero essere il più possibile fedeli all'originale), mentre in basso a destra i divisori per le alte frequenze (quelle alle quali il nostro occhio è meno sensibile e che possono essere quindi approssimate maggiormente od eliminate ovvero poste = 0).
Si noti infine come siano presenti due matrici diverse, una per gli Intra Frames (I-Frames) che in genere devono avere una qualità elevata, ed una per gli Inter Frames (P e B-Frames), sui quali è possibile effettuare una compressione superiore (notate il coefficiente in posizione (1,1)).

 

Scheda "Two Pass"

Non sono molte le impostazioni configurabili in questa scheda durante il primo passaggio nella codifica a 2 passaggi. In tutte le modalità di codifica ad 1 solo passaggio la scheda risulta non avere opzioni attive (e questo del resto è piuttosto ovvio).

Discard first pass: selezionate questa opzione per evitare la creazione del file video durante il primo passaggio, questo per evitare inutile spreco di spazio sul disco. Ricordo che durante il primo passaggio il film viene compresso con la massima qualità possibile (quantizers = 2) onde analizzarne la complessità. All'atto pratico, la presenza di tale file potrebbe essere giustificata solo per confrontarlo con il nostro video finale ed avere un'idea del livello qualitativo.

Hinted ME (Hinted Motion Estimation): (non più utilizzabile) è stata un tentativo di implementare un'opzione presente in alcuni encoder MPEG2; se questa opzione è attivata, durante il primo passaggio viene creato un file con estensione .MVH in cui vengono memorizzate le informazioni sui vettori di moto associati ai singoli macroblocchi, in modo simile all'opzione di logging dei vettori di moto (Motion Vector - MV Logging) del DivX 5.x. In pratica la stima del moto è effettuata solo durante il primo passaggio, con l'intento di velocizzare la codifica del secondo passaggio, in quanto non vengono ricalcolati i vettori di moto. L'opzione tuttavia non funziona in quanto nell'mpeg4 la stima di moto non è basata solo sul moto reale, ma piuttosto risulta correlata pesantemente alla stima di moto, all'immagine differenza, a sua volta correlata ai quantizers utilizzati e così via. L'opzione non sarà più supportata e non ne è previsto un ulteriore sviluppo.

1st pass stats: in questa riga potete scegliere il nome e la cartella in cui salvare il file che conterrà le statistiche video (ovvero i dati con l'analisi del video effettuata dal codec durante il primo passaggio) che saranno necessarie per la codifica nel secondo passaggio. Ricordatevi che questo valore non deve essere cambiato quando andate ad impostare il codec per la codifica del secondo passaggio. Al termine dei due passaggi potete cancellare tranquillamente il file. Potrebbe tornarvi utile per saltare il primo passaggio solo nel caso non andrete a cambiare le impostazioni di configurazione del codec, in particolare quelle che cambiano la compressibilità del video (Quantizers, B-frames, Quarterperl ecc...).


Scheda "Alt. (Alternative) Curve"

Gli unici parametri modificabili in questa scheda nelle codifiche ad 1 solo passaggio (1 Pass) o nella codifica a 2 passaggio, durante il primo passaggio, sono i seguenti:

Max bitrate (Kilobit/s): obbliga il codificatore Xvid a stare al di sotto di questo bitrate massimo. Lasciate il valore di default 10000.

Max overflow improvement % - Max overflow degradation %: indica la velocità con cui il codec può consumare un bitrate disponibile in eccesso (overflow) in tutte quelle situazioni in cui di sta ottenendo un file sottodimensionato (undersize) rispetto alle dimensioni specificate nella finestra iniziale della configurazione per il secondo passaggio. Un valore più elevato, dovrebbe colmare il divario più in fretta. Lasciate il valore di default.

--------------------------------------

La sezione "Use Alternative curve system" non è attivabile.


Scheda "Credits"

Si noti che nella modalità "1 Pass - CBR", questa scheda non è configurabile.

Credits at start of movie & Credits at end of movie: questa opzione sembra in particolare pensata per la codifica dei film. Se pensiamo ad esempio ad un film in DVD, questo contiene alla fine qualcosa come 6-8 minuti di crediti (o titoli di coda). Nella maggior parte dei casi questi sono costituiti da testo scorrevole che difficilmente verrà mai letto. Codificare questa parte con un bitrate basso se non con una qualità scadente consente di aumentare il bitrate disponibile per il restante film. Tale accorgimento risulta estremamente utile soprattutto quando ci si trova con spazio disponibile limitato. Prenderò in considerazione solo il caso di crediti alla fine del film in quanto è la situazione che più spesso si presenta. Spuntate la casella "Credits at end of movie" per attivare tale opzione. In "Credits begin at frame no.:" dovete inserire il numero del fotogramma in cui iniziano i titoli di coda mentre in "Credits end at frame no.:" il numero del fotogramma in cui finiscono (nella stragrande maggioranza dei casi questo coinciderà con l'ultimo fotogramma del film). Per conoscere il numero del fotogramma da inserire, la procedura è piuttosto semplice, vi serve solo una piccola calcolatrice. Ciò che dovete fare è aprire il film con il vostro DVD Player preferito (es. WinDVD o PowerDVD) e controllare sulla barra di stato il tempo in ore, minuti e secondi in cui compare il primo titolo di coda, ed il tempo in cui i titoli finiscono (oppure la durata totale del film). Ecco un esempio pratico. Supponendo di avere un film in formato PAL (è il tipico formato di tutti i film distribuiti in Italia), caratterizzato dall'avere 25 fotogrammi al secondo (fps). Per trovare il numero del fotogramma che corrisponde ad un determinato tempo T (espresso in ore, minuti e secondi), è necessario prima convertire il tempo in secondi e poi moltiplicare per il numero di fotogrammi al secondo. In parole povere, basta usare questa semplice formula:

Num. del fotogramma = [(num. di ore) x 3600 + (num. di minuti) x 60 + (num. di sec)] x 25

Utilizzando l'esempio mostrato nella tabella seguente:


Durata totale del film 2h 10m 40s
Inizio dei crediti finali (titoli di coda)
(si suppone che i crediti terminino con la fine del film)		 2h 03m 13s

si ottengono i seguenti valori:

inizio dei crediti al fotogramma:  [(2 x 3600) + (3 x 60) + 13] x 25 = 184825
fine dei crediti al fotogramma: [(2 x 3600) + (10 x 60) + 40] x 25 = 196000

Basta compilare i relativi campi con i valori trovati qui sopra, come mostrato nella figura precedente.

In linea di massima, l'inizio dei titoli di coda coincide con l'ultimo capitolo del film; potrebbe quindi essere sufficiente andare a leggere il file di testo contenente la lista dei capitoli che è stato creato da DVD Decrypter al momento della copia del film sul disco fisso. Tuttavia fate attenzione poiché questa regola non è rispettata in tutti i film (un esempio per tutti, Matrix).
Molti programmi consentono di semplificare notevolmente la procedura, in quanto mostrano il numero del fotogramma corrente per una determinata scena. VirtualDub è uno di questi.



Potete leggere in (2) il numero del fotogramma corrente, ed usare il cursore (1) per spostarvi all'inizio ed alla fine dei titoli di coda, annotando il loro valore. In tal modo la compilazione dei campi precedenti risulta molto più semplice.
Per chi usasse altri programmi, nel caso il programma in questione non disponga di una opzione simile a quella di VirtualDub, rimane la possibilità di eseguire il tutto manualmente seguendo la procedura spiegata, ovvero utilizzando il software DVD player e annotando da parte il tempo in cui iniziano e terminano i titoli di coda.

Encode credits in greyscale: per risparmiare ulteriormente bitrate nei crediti ed aumentarne la comprimibilità, consiglio di codificarli in bianco e nero (sempre ovviamente che nei titoli non siano presenti immagini o video a colori come talvolta capita). Per far ciò, selezionate questa opzione.

Credits rate reduction

Desired % rate: utilizzando questo campo, i crediti vengono compressi con un bitrate costante che è la percentuale indicata del bitrate utilizzato per il resto del video; ad esempio, se il bitrate medio del film è 800kbps, per i titoli di coda verrà utilizzato un bitrate di 80kbps se "desired % rate" è impostato a 10%.

I-frame quantizer / P-frame quantizer: indicate qui il quantizer fisso che verrà utilizzato per i fotogrammi I e P compresi nell'intervallo selezionato come appartenente ai crediti (o titoli di coda, nel caso dei crediti finali). Consiglio un valore tra 19 (migliore) e 25 (peggiore). Oltre si ottiene una qualità non accettabile nemmeno per i titoli di coda (ma questo è opinabile, nel senso che se proprio non ve ne frega niente dei titoli...).

Starting size / Ending size (kBytes): utilizzando questi campi è invece possibile specificare la dimensione in kB che si desidera assegnare ai crediti; in tal modo, il codec tenterà di codificarli in modo da fargli occupare la dimensione richiesta (es: supponendo di voler riservare 2MB ai titoli di coda, dovremmo inserire in "Ending size (kBytes)" il valore di 2048 (= 2 x 1024)). Problemi potrebbero insorgere nel caso la dimensione richiesta sia troppo piccola, in quanto al di sotto di una data compressione (quantizer = 31) il codec non è in grado di spingersi. (8)


Scheda "Debug"

Performance optimizations: se non fosse già automaticamente selezionato, scegliete "Automatically detect optimizazions". Vi ricordo che le istruzioni SSE2 sono supportate al momento dai soli processori della famiglia Pentium IV. Questa scheda in linea di massima non necessita di nessun aggiustamento. Solo nel caso abbiate seri problemi di codifica (es. continui crash del programma durante la codifica ecc...) potreste provare a forzare o meno alcune ottimizzazioni ("Force optimizations") alla ricerca di eventuali incompatibilità ma dovrebbe essere davvero l'ultima spiaggia.

Chroma Optimizer: questa opzione dovrebbe interpolare in fase di preprocessing (ovvero ad un livello precedente l'inizio della codifica vera e propria), le informazioni sui colori nelle zone molto scure o molto luminose per ridurre l'effetto di scalettatura dovuto ad una transizione troppo brusca tra i livelli. A livello matematico la differenza con il video originale dovrebbe aumentare, ed in quanto tale dovrebbe ridursi il PSNR, tuttavia la qualità soggettiva percettibile, dovrebbe aumentare (riduzione delle scalettature tra i colori). Ho usato il condizionale per ricordare che è una caratteristica ancora in fase di test (ecco il motivo per cui è stata messa nella scheda "Debug"). Consiglio il suo utilizzo solo ad utenti esperti.


Use trellis R-D quantisation: questa opzione è presente in questa scheda in quanto è da considerarsi in fase sperimentale; inoltre al momento attuale funziona solo con le matrici di quantizzazione H.263 e nella codifica in due passaggi (2 Pass). L'opzione, basata sulla teoria rate-distortion, lavora impostando (forzando) a 0 alcuni coefficienti della matrice DCT se il livello di distorsione introdotto con tale scelta non supera un determinato valore, valore a sua volta funzione del numero di bit risparmiati avendo impostato a 0 alcuni dei coefficienti DCT. Questo comporta una lieve perdita in termini di PSNR, compensato comunque dal decremento delle dimensioni del file video (aumento della comprimibilità).

Frame drop ratio: numero di fotogrammi saltati, non modificatela, lasciate 0 a meno che non sappiate esattamente cosa state facendo (0 = Nessun fotogramma viene saltato, 100 = Tutti i fotogrammi sono saltati).

CBR options
Questi parametri sono modificabili solo nella modalità "1 Pass - CBR" e consiglio di lasciare i valori di default, dato che il loro funzionamento non risulta spiegato in nessuna guida.

Reaction Delay Factor: il valore determina il ritardo in fotogrammi (?) che il codec deve attendere prima di correggere il bitrate al variare della complessità delle scene codificate (si ricordi che la modalità CBR è piuttosto una modalità a bitrate medio costante, piuttosto che a bitrate sempre costante). Questo parametro pare influenzare molto la qualità di codifica.

Average period: descrive il numero di fotogrammi consecutivi sul quale il codec può variare il bitrate onde ottenere mediamente il valore prestabilito.

Smoother: indica il numero di fotogrammi minimo che è necessario interporre tra la minima qualità possibile e la qualità corrente scelta dal codec. In pratica il parametro tenterebbe di prevenire una eccessiva differenza qualitativa tra fotogrammi adiacenti che potrebbe essere causata nel tentativo di rispettare il bitrate medio impostato in quelle situazioni in cui il codec abbia aumentato notevolmente il bitrate a causa di scene particolarmente complesse.


Cliccate quindi su OK fino a tornare alla finestra principale del programma che state utilizzando per la codifica.



Nel caso stiate codificando con 1 solo passaggio, la configurazione del codec Xvid è ora terminata e potete tranquillamente procedere con l'avvio della conversione o della cattura del video su cui state lavorando.
Nel caso stiate effettuando la codifica in due passaggi, procediamo oltre e vediamo come configurare il codec per il secondo passaggio. Per un esempio pratico, fate riferimento alla Guida alla configurazione del codec Xvid con VirtualDub.


Modalità "2 Pass - 2nd pass...": impostazioni del codec per il secondo passaggio

Siamo nuovamente alla finestra di configurazione principale del codec Xvid; è necessario ora scegliere "2 Pass - 2nd pass Int." od eventualmente "2 Pass - 2nd pass Ext.":



Supponiamo di aver scelto, secondo passaggio con utilizzo delle impostazioni interne al codec per la predizione della dimensione finale del vostro video. Accanto a "Desired size (kBytes)", è necessario inserire la dimensione finale che volete abbia il vostro file contenente il solo flusso video (questa operazione non è necessaria se si sta utilizzando un software esterno, "... - 2nd pass Ext." per regolare la curva di compressione del codec):



Vi ricordo che la dimensione in kBytes si ottiene moltiplicando per 1024 (1 kilobyte = 1024 bytes) la dimensione in MegaBytes, ovvero moltiplicando per 1024x1024 = 1048576 la dimensione in GigaBytes (es: 695MB = 695*1024 kB = 711680 kB; 1390MB = 1423360 kB). Nel caso dovessero verificarsi problemi con il raggiungimento delle dimensioni desiderate, vi consiglio di leggere l'appendice B.

Scheda "Global"

Non dovrete modificare nulla in questa scheda rispetto al primo passaggio; solo una piccola precisazione per quel che riguarda il "Quantization type".

Quantization type: per il secondo passaggio è necessario lasciare sempre lo stesso valore che è stato impostato durante il primo passaggio tranne nel caso vogliate utilizzare MODULATED o NEW MODULATED HQ. Nel caso scegliate MODULATED, verrà usato H.263 come matrice di quantizzazione nel caso di quantizers inferiori od uguali a 3 (fotogrammi poco compressi quindi), e MPEG nel caso di quantizers superiori od uguali a 4(6) (ovvero per tutti quei fotogrammi che sono stati compressi maggiormente); NEW MODULATED HQ invece usa H.263 come matrice di quantizzazione nel caso di quantizers inferiori od uguali a 4, e MPEG nel caso di quantizers superiori. In linea teorica questi due metodi dovrebbero riuscire ad eliminare una parte del rumore, della "granulosità", che si nota soprattutto nei fotogrammi meno compressi (quelli più grandi) che invece di essere trattati con la matrice MPEG, vengono trattati con la H.263. L'utilizzo invece della matrice MPEG per i fotogrammi più compressi consente comunque di mantenere una buona dose di dettaglio che verrebbe invece perso con la H.263. Si noti tuttavia che i metodi "Modulated" non rispettano lo standard Mpeg4 e quindi il video potrebbe non essere perfettamente compatibile con dei player Mpeg4; Inoltre sono stati segnalati possibili problemi (presenza di artefatti video) con l'utilizzo contemporaneo di B-Frames, Qpel e matrici "Modulated". (10)


Scheda "Quantization"


Quantizer restrictions

In questa scheda potrete ora modificare i quantizers cosa che non era invece possibile fare durante il primo passaggio della codifica in due passaggi (si ricordi in proposito che durante la codifica in 2 passaggi, nel primo passaggio si effettua sostanzialmente una codifica con quantizer fisso uguale a 2). Un breve richiamo delle opzioni selezionabili.

Min / Max I-frame quantizer: questi valori restringono il campo dei quantizer che possono essere utilizzati per i fotogrammi di tipo I. Valori consigliati sono quelli indicati in figura: 2 per "Min..." e 6 per "Max..." (viene quindi favorita la qualità per gli I-Frames).

Min / Max P-frame quantizer: questi valori restringono il campo dei quantizer che possono essere utilizzati per i fotogrammi di tipo P. Valori consigliati sono quelli indicati in figura: 2 per "Min..." e 16 per "Max...".

NOTA: anche i valori di default 2-31 per entrambi, dovrebbero comunque garantirvi un risultato soddisfacente.

Ricordatevi che non dovete modificare la matrice di quantizzazione rispetto a quella utilizzata nel primo passaggio.


Scheda "Two Pass"

Curva di compressione lineare: più semplice da configurare, più garanzia sulla qualità del risultato

Per la compressione mi sono basato su quanto consigliato da Koepi e da Iago (6) ovvero di utilizzare una curva di compressione lineare per la distribuzione del bitrate ai vari fotogrammi (Linear curve downscaling), non utilizzando quindi il metodo "Alternative Curve" implementato nel codec. Il concetto alla base dell'Alternative Curve consiste nel ridurre le dimensioni dei fotogrammi più grandi in favore dei più piccoli, mentre un metodo di compressione lineare ridimensiona tutti i fotogrammi tenendo semplicemente conto dello spazio disponibile. Una risposta di "unplugged" apparsa in una discussione nel forum di doom9 (http://forum.doom9.org/showthread.php?threadid=32294), chiarisce ulteriormente il concetto:

"...non è che una curva lineare per il calcolo della distribuzione dei bit ai singoli fotogrammi, sia meglio o superiore al metodo "Alternative Curve"; il suo principale vantaggio è nel garantire una distribuzione del bitrate più omogeneo; sebbene vi sia una effettiva penalizzazione nei confronti dei fotogrammi più piccoli, il metodo lineare potrebbe (e qui il condizionale è d'obbligo) garantire una qualità superiore semplicemente perché la Curva di Compressione (CC) del codec Xvid risulta piuttosto complessa da configurare e potrebbe non avere un codice (per il calcolo della distribuzione dei bit ai fotogrammi) ottimamente tarato per tutto il video, senza contare che risulta piuttosto complicato da configurare... cioè il metodo lineare può talvolta essere migliore non in quanto superiore dal punto di vista teorico rispetto all'Alternative CC, ma piuttosto perché l'algoritmo di distribuzione lineare risulta molto semplice da implementare in maniera omogenea e risulta quindi più preciso nel raggiungere la fine del video rispettando le dimensioni volute senza dover effettuare continui aggiustamenti nel bitrate (incremento di 1235, decremento di 4345, incremento di 7686, incremento di 2000... fluttuazioni tipiche di una curva di compressione lineare non ben tarata)".

Non verrà quindi usata l'"Alternative curve system" che dovrà essere in seguito disabilitata. I parametri in questa scheda che caratterizzano la curva di compressione sono I-frame boost %, High / Low bitrate scenes % e per ottenere una distribuzione perfettamente lineare, tutti dovranno essere impostati a 0. Tenete comunque sempre presente che potete scegliere il metodo "Alternative Curve Compression" selezionando i parametri interessati seguendo le alternative proposte.

Two pass tuning

I-frame boost %: con questa opzione è possibile aumentare della percentuale indicata i bytes assegnati ai fotogrammi chiave (I o Key frames). La qualità degli I-frames è calcolata in base ai parametri "Min / Max I-frame quantizer", ovvero vengono usati tali quantizers per il calcolo dei bytes assegnati ad ogni I-frame. In alternativa è possibile incrementare i bytes assegnati ad ogni fotogramma chiave della percentuale indicata in questo campo. Supponendo ad esempio, che un I-frame sia compresso (letteralmente scalato, dall'inglese "scaled") a 5000 bytes, con questa opzione attivata ed impostata al 20(%), verrebbe "riscalato" a 6000 bytes (5000+20% di 5000). (1) Il valore consigliato è 0 (linear curve), ovvero nessuna ridistribuzione. Da un punto di vista teorico, un I-Frame di maggiori dimensioni (ovvero di qualità elevata) potrebbe portare a dei vantaggi qualitativi nella codifica, poiché i delta-frames vengono calcolati partendo proprio da un I-frame. Nel caso si decida di incrementare (boost) la qualità e la dimensione degli I-Frames, vi consiglio di usare valori compresi tra 5 e 20% (max).

Discard first pass: vedi sopra.

Dummy 2nd pass: ovvero "finto secondo passaggio" o "secondo passaggio fantasma". Se attivata, non viene creato nessun file video durante il secondo passaggio; utile solo per test.

Below i-frame distance... e I-frame bitrate reduction %: nel caso che due fotogrammi chiave o i-frames si trovino vicini in un intervallo inferiore al numero di fotogrammi specificato in "below i-frame distance...", il codec provvederà a ridurre i numero di bit assegnati al secondo i-frames (e quindi a ridurne la qualità) della percentuale indicata in "I-frame bitrate reduction %". I valori consigliati sono 10-15 per "below i-frame distance..." e 20-30% per "I-frame bitrate reduction %" (per quest'ultimo parametro, valori più elevati sono preferibili in situazioni di basso bitrate).

Curve compression
I parametri seguenti controllano come vengono distribuiti i bit ai singoli fotogrammi dalla curva di compressione. Un metodo di compressione a bitrate variabile "puro" assegna il bitrate in base alla complessità dell'immagine; le immagini più complesse ovvero le scene con un'elevata quantità di movimento, riceveranno una maggior quantità di bit, quelle più statiche e quindi meno complesse, una quantità minore. Regolando i parametri "High / Low bitrate scenes %" è possibile regolare la distribuzione del bitrate rendendola più "uniforme". Da un punto di vista pratico, scene con una grande quantità di movimento risultano più complesse da codificare e richiedono una quantità maggiore di bit (High bitrate scenes); al contrario scene statiche richiedono una quantità decisamente inferiore di bit (Low bitrate scenes).

High / Low bitrate scenes %: impostando entrambi questi valori a 0, non viene applicata nessuna ridistribuzione del bitrate, che viene semplicemente allocato in base alla complessità delle scene (tipico di un metodo di codifica VBR puro). Tenendo conto della bassa sensibilità con cui il nostro occhio percepisce i dettagli nelle scene in rapido movimento rispetto a quelle statiche, nonché della scarsa sensibilità alle alte frequenze video (vedi qui), potrebbe essere preferibile riallocare alle scene statiche, un pò del bitrate riservato alle scene in rapido movimento. Il parametro in "high bitrate scenes %" indica la percentuale di cui deve essere ridotto il bitrate allocato ai fotogrammi che risultano avere una dimensione decisamente superiore al valore medio: più alto è questo valore, maggiore è il numero di bit che vengono tolti a queste scene e ridistribuiti alle altre; specifica la percentuale di bitrate che verrà presa dai frames più grandi della media per essere redistribuito. Il parametro in "low bitrate scenes %" indica invece di quale percentuale dovrà essere incrementato il bitrate assegnato ai fotogrammi che risultano avere una dimensione inferiore alla dimensione media. Valori consigliati: 0 / 0 per disabilitare la ridistribuzione dei bit (consigliato da Koepi e necessario se volete una linear curve compression pura). Se desiderate invece utilizzare questa opzione, sono consigliati i valori (High / Low) 20 / 12 per film d'azione, con un'elevato numero di scene in rapido movimento, ed i valori 25 / 10 per film più statici.

Bitrate payback delay (frames) ("dilazione del risarcimento del bitrate"): questo campo indica il numero di fotogrammi che vengono interessati nella redistribuzione in tutti i casi in cui si fosse verificato un sotto utilizzo od un abuso di bit (ridistribuzione calcolata in base ai 2 parametri precedenti). E' possibile disabilitare l'opzione inserendo il valore 1; penso comunque che lasciare il valore di default di 250 sia più consigliabile.

Payback with bias: ridistribuisce i bit tra il range di fotogrammi individuato in payback delay, non in maniera proporzionale alla dimensione dei fotogrammi, quanto piuttosto tende a favorire i piccoli fotogrammi (aumenta la qualità dei fotogrammi piccoli, che teoricamente potrebbero avere una qualità inferiore). Payback proportionally: ridistribuisce i bit proporzionalmente alla dimensione del fotogramma, ovvero i fotogrammi più grandi ricevono più bit, quelli più piccoli meno. In sintesi il metodo "proportionally" (proporzionale) distribuisce i bit in più a tutti i fotogrammi in base alle dimensioni, ovvero ogni fotogramma riceve un numero di bit dato da una percentuale delle sue dimensioni (i fotogrammi più grandi riceveranno quindi un numero di bit superiore in termini assoluti) e la percentuale è la stessa per tutti i fotogrammi; il metodo "bias" tende invece a favorire i piccoli fotogrammi e potrebbe essere indicato nelle situazioni di alto bitrate, per aumentare la qualità dei quei fotogrammi che sono stati comunque compressi molto.  (3) Non ci sarebbe comunque da stupirsi se non si riuscisse a notare alcuna differenza qualitativa nel video finale utilizzando un metodo piuttosto che l'altro.

Gli altri parametri, Hinted ME, e soprattutto "1st pass stats",non vanno modificati.


Scheda "Alt. (Alternative) Curve"

Use Alternative curve system: come già accennato viene consigliato di disabilitare l'"Alternative curve system". Tuttavia, sebbene non utilizzati, ho deciso comunque di fornire una piccola descrizione della funzione dei vari parametri (ovviamente i parametri non risultano selezionabili, se disabilitate l'opzione). L'idea dell'Alternative Curve consiste principalmente nel tentare di ridistribuire in modo più "equo" il bitrate, almeno questo in teoria. La sua implementazione e configurazione corretta è piuttosto complessa, soprattutto se paragonata ad una curva di compressione lineare che invece non ridistribuisce in alcun modo il bitrate.

Curve agression: questo valore modifica l'aggressività con cui verrà ridistribuito il bitrate. Un'elevata curva di aggressione (High) aiuterà il codec a trattare i fotogrammi a basso bitrate, mentre nuocerà alle scene ad alto bitrate, ed è l'ideale per scene altamente dinamiche (ad esempio scene lente seguite improvvisamente da scene in rapido movimento). Una bassa curva di aggressione (Low) si adatta più lentamente alle variazioni di bitrate e non migliora le scene a basso bitrate, ma non danneggerà le scene in rapido movimento. Una curva a media aggressione (Medium) è una via di mezzo tra le due. (11)

High distance from average %: specifica la dimensione di quel fotogramma per cui verranno applicati i parametri di qualità minima relativa ("Minimum relative quality %"), dimensione che si ottiene dalla percentuale qui indicata della dimensione media dei fotogrammi. Aumentando questo valore si tende a favorire i fotogrammi ad alto bitrate. Low distance from average %: specifica la dimensione di quel fotogramma per cui verranno applicati i parametri di massima qualità, dimensione che si ottiene dalla percentuale qui indicata della dimensione media dei fotogrammi. Abbassando questo valore si tendono a favorire i fotogrammi a basso bitrate. Valori consigliati, in base alle esperienze maturare nel forum di Doom9: "Low distance..." < 100 e "High distance..." tra 150 e 200. (11)

Enable automatic minimum relative quality: quando attivata, non è più possibile impostare "Minimum relative quality %", ma la minima qualità relativa viene calcolata automaticamente in base al parametro Strenght %: che relaziona la qualità minima in base alle dimensioni finali del video ovvero al bitrate disponibile. Tale parametro percentuale indica quanta influenza ha  la scelta di un basso bitrate (inteso come bitrate disponibile, in base alle dimensioni finali che si desiderano per il file video) sulla minima qualità accettabile (più elevato è il parametro, più bassa sarà la minima qualità accettabile nel caso di bassi bitrate). Tale parametro influenza notevolmente la qualità del video; il valore standard di 50 si è comunque visto fornine un'ottima qualità in tutto il film.(11)

Minimum relative quality %: la minima qualità prodotta non può essere inferiore alla percentuale qui indicata della massima qualità prodotta, ovvero il parametro limita in percentuale la differenza che vi può essere tra la miglior qualità possibile e la peggiore (nel tentativo di rendere più uniforme e costante la qualità, forse...). Non sono stato in grado di reperire informazioni maggiori in merito. Lasciate il valore di default (50).

Enable automatic bonus bias calculation: calcola automaticamente il bonus di bitrate da assegnare con il metodo pesato (bias).

Manually set bonus bias: è qui possibile indicare la percentuale del bonus di bitrate (ovvero di bitrate da ridistribuire) che deve essere riassegnata con il metodo pesato (bias) che andrà a favorire i piccoli fotogrammi. Il resto del bitrate sarà invece riassegnato in modo proporzionale. Più elevato questo valore, più si tende a favorire le scene a basso bitrate, ovvero quelle più statiche.

Max bitrate (Kilobit/s): l'opzione non va modificata rispetto a quanto impostato nel primo passaggio.

Max overflow improvement % - Max overflow degradation %: come sopra, non modificate questa opzione rispetto a quanto visto nel primo passaggio.


Le altre schede non necessitano di nessuna modifica. Cliccate quindi su OK fino a ritornare alla finestra principale del vostro software di conversione.



E con questo è tutto...

(That's all folks!)


Appendice A - I "difetti" dovuti ad una cattiva compressione video

Se il video è ben compresso (ovvero è stato usato un bitrate sufficientemente elevato per ogni situazione), generalmente potrebbe essere difficile distinguerlo dall'originale non compresso o compresso in altri formati ad elevata qualità. Ad esempio, è possibile ridurre di circa 1/3 le dimensioni di un video in formato MPEG2 (es. un DVD) convertendolo in MPEG4 (Xvid o DivX) e non essere in grado di notare (se non ad una più attenta analisi) una sostanziale differenza. Talvolta però se il bitrate non è sufficientemente elevato e se non si è configurato propriamente l'encoder, si possono presentare alcuni difetti tipici della compressione Mpeg e non dovuti magari ad un baco (bug) dell'encoder stesso. I più evidenti sono due e vengono generalmente indicati con il nome di "blocking-artifact" e "mosquito-noise".
Un esempio di "blocking-artifacts" del video dovuta ad un bitrate non adeguato (troppo basso)
 Un esempio di "mosquito-noise" attorno alle parole (indicato dalle frecce), anche qui causato da un bitrate inadeguato

Il "blocking-artifacts" o "blocchettizzazione" o "quadrettatura" che dir si voglia, è causato da una eccessiva compressione del fotogramma, cosa che consente l'individuazione dei blocchi in cui è stata suddivisa l'immagine ai fini della compressione prima dell'utilizzo della DCT (maggiori dettagli). Il fenomeno è causato da una non perfetta corrispondenza tra i diversi blocchi a causa di un numero troppo elevato di informazioni che sono state "eliminate" al momento della quantizzazione della matrice delle frequenze DCT (maggiori dettagli). Il "mosquito-noise" detto anche "ringing" si presenta invece come un alone di disturbo, rumore accanto agli oggetti che presentano una netto contrasto con lo sfondo. Le immagini qui sopra aiutano a chiarire i due concetti ed illustrano i due più tipici difetti causati da un compressione eccessiva basata sugli algoritmi Discrete Cosine Transform, ovvero da un bitrate non adeguato alla situazione.
Due sono i metodi per eliminare questi difetti:
  1. in fase di compressione, aumentando il bitrate disponibile (aumentando quindi le dimensioni del video);
  2. in fase di postprocessing, utilizzando dei filtri di "deringing" e "deblocking". Quest'ultimo metodo è comunque consigliato solo se risulta davvero impossibile aumentare le dimensioni del video e se la qualità è un fattore trascurabile (es. streaming video).
Se il problema dovesse presentarsi su di un video compresso in modalità "1 Pass - CBR" consiglio anzitutto di provare a effettuare nuovamente la compressione questa volta utilizzando una modalità a due passaggi lasciando inalterate le dimensioni del file; se il problema dovesse ripresentarsi anche con l'utilizzo di una modalità 2 Pass, allora sarà necessario aumentare il bitrate (ovvero le dimensioni del file video ed eventualmente il numero di supporti, es CD-R, in cui salvare il filmato).

Appendice B - Undersize (video sottodimensionato) e problemi simili.

Quanto qui descritto si riferisce alla sola modalità di compressione in due passaggi (2 Pass - ...).

Undersize
Per quel che riguarda la dimensione finale desiderata, come ho avuto io stesso modo di sperimentare, in taluni casi si può ottiene un file più piccolo di quanto richiesto ("undersize", sottodimensionato). In un caso, ad esempio, sebbene avessi impostato una dimensione di 1275MB, il file al termine della conversione, non superava i 900MB. Motivo? Qualcuno aveva inizialmente parlato di un bug nel codec quando vengono attivate alcune funzioni avanzate (Qpel, B-Frames etc...), ma in realtà non è così. Il fenomeno è dovuto al fatto che, con i parametri scelti, il codec riesce tranquillamente ad utilizzare la massima qualità possibile rimanendo al di sotto del massimo bitrate disponibile. In pratica il film risulta ottimamente comprimibile, il bitrate va in saturazione, e si ottiene un file più piccolo del richiesto. Possibili soluzioni sono quelle di aumentare la risoluzione del video, ad esempio mantenendo la risoluzione originale di 720 pixel di larghezza, senza ridimensionare a 640, e/o utilizzare dei valori più bassi nei vari quantizer (lasciando invariato 2 come "Min ...quantizer", provate ad abbassare "Max... quantizer" e/o abbassate "Maximum / Minimum I-frame interval", qualcosa tipo 250/1 invece di, ad esempio, 300/5) e/o utilizzare 100/100 in B-frame quantizer Ratio/Offset oppure ancora disabilitare del tutto l'uso dei B-Frames (Maximum B-frames = -1). Ricordate tuttavia che se da una parte la cosa può essere fastidiosa (nel caso abbiate ad esempio fatto tutti i conti con l'audio, per sfruttare appieno i 2 CD) dall'altro potrete ricomprimere l'audio ad una qualità nettamente superiore od in alternativa inserire anche una seconda traccia audio. Non necessariamente infatti un file di dimensioni inferiori significa che avrete un video di qualità inferiore, dato che il codec avrà comunque utilizzato la massima qualità possibile in base ai parametri che gli avevate assegnato.
Nel caso che, oltre ad un file sottodimensionato, il video risulti anche di scadente qualità, assicuratevi di non aver usato una versione dell'encoder video con qualche baco (se è una versione non ufficiale, la possibilità non è del tutto da scartare), e provate a ripetere il tutto installando una differente versione del codec Xvid.

Oversize
Problemi opposti, ovvero video sovradimensionato rispetto a quanto richiesto, sono in genere causati da un errore di implementazione della curva di compressione. Non mi è mai capitato di incontrare un simile problema usando la curva di compressione interna del codec; piuttosto può capitare di incorrere in tali errori nel caso si stia utilizzando un programma esterno per la configurazione del codec. Ho incontrato tali problemi utilizzando ad esempio Vidomi+Xvid per la compressione video. Soluzioni sono quelle di provare con una differente versione del codec o se il problema non si risolve, utilizzare un differente programma o se possibile, la curva di compressione interna al codec stesso.

Appendice C - PSNR (Peak Signal Noise Ratio)

Per la valutazione della qualità di un video compresso ci si basa generalmente su di un giudizio soggettivo, per così dire "ad occhio", e si formula un giudizio basandosi ad esempio su di una scala come quella illustrata qui di seguito:

Punteggio
 Scala della qualità
 Scala della presenza
di artefatti e disturbi
5
 Eccellente / Ottima
 Impercettibili
4
 Buona
 Appena percettibili ma non fastidiosi
3
 Sufficiente / Discreta
 Percettibili e leggermente fastidiosi
2
 Non sufficiente
 Fastidiosi
1
 Pessima, del tutto insufficiente
 Molto fastidiosi


Tuttavia è possibile valutare anche numericamente (matematicamente) la qualità di un video o di un'immagine compressa con un metodo di compressione lossy misurando la distorsione introdotta tra l'originale e la copia compressa. Tra i metodi più utilizzati, vi è il calcolo del PSNR, ovvero Peak Signal-to-Noise Ratio, la cui espressione matematica è la seguente:



L'unità di misura è il decibel (dB) cosa che ci si poteva aspettare se si tiene conto che il PSNR si calcola sostanzialmente come un rapporto segnale / rumore, dove per il segnale si usa una stima di massima considerando l'immagine completamente bianca (valore 255), mentre il rumore viene calcolato come varianza (sigma2) dell'immagine errore (|X-Y|), immagine che si ottiene effettuando la differenza pixel a pixel tra l'immagine non compressa (X) e l'immagine compressa e successivamente decompressa (Y). Il perché il valore 255 corrisponda al bianco è presto detto: anzitutto si deve tener conto che il PSNR confronta solo le componenti della luminanza delle due immagini (la componente Y), mentre non vengono confrontate le componenti dei colori (Cr e Cb). Ora, dato che il video è codificato nel sistema YUV 4:1:1, dove la componente Y utilizza una risoluzione di 8 bit per pixel, ricordando che il maggior numero decimale rappresentabile con un numero n di bit è dato dalla formula Max = 2n-1 (nel nostro caso 28-1 = 255), al valore 0 corrisponde il nero, mentre al valore 255 il bianco (e tutti i valori intermedi sono diverse tonalità di grigio).
Per quel che riguarda il denominatore, è necessario un piccolo ripasso di statistica con due definizioni:

Media di n valori x1, x2,..., xn:

Varianza  di n valori x1, x2,..., xn:

Applicando il tutto al nostro caso, ovvero all'immagine errore, dove ogni pixel ha coordinate |x(i,j) - y(i,j)| e sommando su tutti i pixel, si ottiene:



dove l'immagine ha una risoluzione di Larghezza x Altezza (L x A) pixel,
ogni pixel ha coordinate (i,j), con i = 1...L, j = 1...A,
x(i,j) è il valore del pixel nell'immagine originale non compressa
y(i,j) è il valore del medesimo pixel nell'immagine compressa e dove



è il valore medio dei pixel dell'immagine differenza

Chiuso con la teoria, al lato pratico il PSNR tipicamente assume valori compresi tra 20 e 50 dB (con due cifre decimali significative del tipo 43,54 dB) e valori più elevanti testimoniano un qualità superiore ovvero una maggior fedeltà con l'originale non compresso. La seguente immagine aiuta a farsi un'idea del rapporto tra esistente tra valore del PSNR, bitrate e qualità soggettiva percettibile:


Fonte: Compression lectures, Prof.dr.ir. Inald Lagendijk, Digital Signal Coding, Cap1, Introduction http://www-ict.its.tudelft.nl/~inald/vcdemo/lectures.htm

E' necessario sottolineare che piccole variazioni del PSNR, dell'ordine di 1-2 dB, difficilmente saranno evidenziabili con un giudizio soggettivo e che sebbene utilizzato universalmente per la valutazione della qualità di un'immagine, il PSNR è in grado di dire relativamente poco sulla gravità di alcuni difetti di compressione quali la "blocchettizzazione" ed il "ringing".
Per maggiori dettagli e per una procedura pratica su come effettuare un test per il calcolo del PSNR, consiglio di leggere l'ottima guida scritta da Kaiousama dal titolo "Guide To PSNR Computation Via AviSynth" e che dovreste trovare al seguente indirizzo: http://www31.brinkster.com/kaiousama/video_main.htm (nel caso il link fosse cambiato, provate a ricercare in rete l'homepage dell'autore); la guida richiede l'uso di AviSynth in combinazione con Virtualdub.
Un altro piccolo software (funziona da riga di comando) piuttosto comodo e che permette il confronto in PSNR tra due file video con estensione avi, è PSNR4avi che potete trovare a questo indirizzo: http://vsofts.com/codec/codec_psnr.html. Potrebbe ad esempio essere utilizzato per il calcolo del PSNR tra il video codificato con quantizer costanti uguali a 2 (primo passaggio) ed il file video risultante al termine del secondo passaggio.

Fonti:
Prove sperimentali sulla compressione lossy, tesi dall'università di Milano.
Rimozione di Blocking-Artifacts da immagini codificate con DCT, di Andrea Coslovich e Daniele Palazzolo
Guide To PSNR Computation Via AviSynth, Kaiousama
Digital Signal Coding, Prof.dr.ir. Inald Lagendijk

Appendice D - Rate-Distortion

La teoria
Dal punto di vista teorico, la teoria del Rate-Distortion (banda, bitrate - distorsione) è un branca delle teoria dell'informazione che si occupa del problema di determinare il minimo livello di informazione che può essere trasmessa o mantenuta, affinché il segnale originale possa essere ricostruito con un livello di distorsione non superiore ad un determinato valore. In tal senso quindi tale teoria fornisce un limite teorico al livello di compressione ottenibile usando dei metodi di compressione con perdita di informazione (lossy). Molte delle tecniche di compressione esistenti per la musica, il video, la voce, le immagini ecc... utilizzano al loro interno procedure di trasformate (es. DCT), quantizzazione e allocazione del bit-rate che derivano dalla forma generale delle funzioni sulla teoria che lega la banda disponibile (bitrate od in generale rate) ed il livello di distorsione ottenuto.
Il termine "rate" viene generalmente accomunato al numero di bits per campione di dati che devono essere trasmessi od archiviati. Il concetto di "distortion" invece richiede una discussione un pò più ampia. Nel caso più semplice (che fortunamente coincide con la maggior parte dei casi), si definisce distorsione la discordanza, differenza, tra il segnale in entrata "I" (l'originale) e quello in uscita "O" (il segnale compresso e quindi decompresso) ed è possibile ad esempio quantificarlo matematicamente tramite l'errore quadratico medio (Mean Square Error, MSE) della differenza:

L = larghezza in pixel dell'immagine
A = altezza in pixel dell'immagine
I(x,y) = valore del pixel dell'immagine originale
O(x,y) = valore del pixel dell'immagine compressa

Tuttavia, dato che la maggior parte delle tecniche di compressione "lossy" operano su dati che hanno a che fare con il sistema sensoriale umano (ascoltare della musica, vedere un'immagine od un video), la misura della distorsione dovrebbe rendere conto anche di alcuni aspetti di quest'ultimo. Nella compressione audio, modelli percettivi sensoriali, ovvero misure percettive della distorsione, sono ampiamente sviluppati e largamente utilizzati in algoritmi di compressione quali l'mp3, ma spesso non è così semplice incorporarli nei modelli pratici. Nella compressione delle immagini e del video, i modelli sensoriali umani sono invece meno sviluppati e la loro applicazione è per lo più ristretta alla scelta dei coefficenti delle matrici di quantizzazione e di normalizzazione nelle compressioni JPEG ed MPEG.
Tralasciando ora la parte più stretta di analisi matematica che richiederebbe una certa conoscenza di base (e che non ho tempo ne spazio a sufficienza per spiegarvi, anche perché mi costringerebbe ad un ripasso accelerato di statistica ed analisi 2 ;-), veniamo al succo della questione e riassumiamo il problema:
  • si deve minimizzare il tasso (rate) di informazione necessario per trasmettere, riprodurre, il nostro video, ovvero nel nostro caso minimizzare il bitrate, in modo tale che mediamente la differenza, distorsione, tra l'originale non compresso ed il video compresso (e poi decompresso) non superi un determinato valore o tasso di distorsione D;
  • un tasso D = 0 significa che l'immagine compressa e decompressa sono identiche ed ovviamente non si verificherà mai nelle situazioni di compressione lossy;
  • si desidera quindi che l'originale e il corrispettivo compresso differiscano in termini di distorsione a meno di un valore D (<D);
  • la teoria della Rate-Distortion mi fornisce una funzione R(D) che lega la distorsione D al bitrate utilizzato e trova il minimo livello di distorsione teorico che è possibile ottenere ad un determinato bitrate, ovvero esiste un limite inferiore per D sotto il quale non è possibile scendere, e tale limite è dato dalla teoria;
  • nessun sistema di compressione può trasmettere le informazioni con un rapporto rate-distortion R(D) inferiore a quello predetto dalla teoria (vedi figura più sotto);
  • l'obiettivo dell'algoritmo di compressione o dell'encoder video che dir si voglia è avvicinarsi il più possibile al valore teorico del R(D);
  • la compressione lossy del video è regolata dal valore dei quantizers ed è proprio sulle tecniche di quantizzazione e sulla loro implementazione matematica che si concentrano gli sforzi degli sviluppatori onde trovare quel metodo che maggiormente consente di avvicinarsi all curva teorica R(D) (es. "Vector Quantization" piuttosto che "Scalar Quantization").



Dal grafico possiamo ad esempio stabilire che ad un determinato bitrate R1, il minimo livello di distorsione ottenibile sarà D1 (si ricordi che minore il livello di distorsione, più fedele all'originale è il video o l'immagine compressa). Ad un bitrate più basso R2 < R1, necessariamente il livello di distorsione non potrà essere inferiore ma dovrà aumentare, ed il suo valore minimo sarà D2 > D1.

--------------------------------------------------

Nel caso del codec Xvid, l'algoritmo funziona a livello dei singoli macroblocchi in cui viene suddivisa l'immagine, prendendo in considerazione un vasto numero di parametri durante la fase della stima del moto (motion estimation). Per ogni blocco, vengono considerate la bontà della stima di moto in termini di precisione sull'individuazione del blocco corrispettivo nel fotogramma adiacente, il numero di bit impiegati per memorizzare tale scenario e la qualità finale del blocco stesso. In base a tutti questi criteri, il codec decide se utilizzare o meno lo scenario corrente per la motion estimation (ME). La teoria del livello di distorsione interviene nella scelta dello scenario per limitare il degrado qualitativo entro un valore stabilito; potrebbero presentarsi situazioni in cui spendendo qualche bit in più si ottiene un livello qualitativo notevolmente più alto rispetto alla situazione con bitrate più basso in assoluto. Si vuole quindi basare la scelta non solo sul bitrate utilizzato, ma anche sulla qualità ottenibile ed è per questo che l'algoritmo sceglie non solo in base al numero di bit risparmiati ma anche in base al livello di distorsione introdotto.

Fonti:
Rate distortion theory, Wikipedia, the free encyclopedia
Digital Signal Coding, Prof.dr.ir. Inald Lagendijk
Doom9's Xvid Forum

Appendice E - Schema dei parametri di conversione
Qui di seguito alcuni schemi riassuntivi per i parametri di configurazione del codec. Si noti che:

ON
 OFF

Modalità di compressione a 2 passaggi: miglior qualità possibile, a scapito di un maggior tempo di codifica

Primo passaggio
 Secondo passaggio
Encoding Mode: 2 Pass - 1st pass
Scheda Global:
Motion Search Precision: 6 - Ultra High
Quantization Type: MPEG / H.263
FourCC Used: XVID
VHQ Mode: da "1-Mode Decision" a "4-Wide Search" (rallenta di molto la velocità di codifica)
Max I-frame Interval: 250, Min I-frame Interval: 1
Lumimasking: OFF
Interlacing: OFF / ON (a seconda delle necessità)
Greyscale: OFF / ON (a seconda delle necessità)
Quarterpel: OFF / ON (rallenta di molto la velocità di codifica)
Global Motion Compensation: OFF
Chroma Motion: ON
Max B-frames: da 1 a 2
B-frames Quantizer Ratio(%): da 100% a 150%
B-frames Quantizer Offset: 100
B-frame threshold: 0 (da testare)
Packed bittream: OFF
DX50 B-VOB compatibility: ON
Print debug info on each frame: OFF
Scheda Two Pass
Discard First Pass: ON
Hinted Motion Estimation: OFF
Scheda Credits:
Start Credits: ON/OFF (a seconda delle necessità)
End Credits: ON/OFF (a seconda delle necessità)
Scheda Debug:
Automatically detect optimizations: ON / OFF
Chroma Optimizer: OFF/ON (da testare)
Use trellis R-D quantisation: OFF (da testare)
Frame drop ratio: 0
 Encoding Mode: 2 Pass - 2nd pass
Desired size (kBytes): a seconda delle necessità
Scheda Global:
Motion Search Precision: Come 1° passaggio
Quantization Type: Come 1° passaggio
FourCC Used: Come 1° passaggio
VHQ Mode: Come 1° passaggio
Max I-frame Interval / Min I-frame Interval: Come 1° passaggio
Lumimasking: Come 1° passaggio
Interlacing: Come 1° passaggio
Greyscale: Come 1° passaggio
Quarterpel: Come 1° passaggio
Global Motion Compensation: Come 1° passaggio
Chroma Motion: Come 1° passaggio
Max B-frames: Come 1° passaggio
B-frame Quantizer Ratio(%): Come 1° passaggio
B-frame Quantizer Offset: Come 1* passaggio
B-frame threshold: Come 1° passaggio
Packed bittream: Come 1° passaggio
DX50 B-VOB compatibility: Come 1° passaggio
Print debug info on each frame: OFF
Scheda Quantization
Min I-frame Quantizer: 2, Max I-frame Quantizer: 6
Min P-frame Quantizer: 2, Max P-frame Quantizer: 16
Scheda Two Pass
I-frame Boost %: 0
Discard First Pass: ON
Dummy 2nd Pass: OFF
Below I-frame Distance: 10%-15%
I-frame Bitrate Reduction: 20%-30%
High Bitrate Scenes: 0%
Low Bitrate Scenes: 0%
Bitrate payback delay (frames): 250
Payback with bias: ON
Payback proportionally: OFF
Hinted ME (Motion Estimation): Come 1* passaggio
Scheda Alt. Curve:
Use Alternative Curve System: OFF
Max Bitrate (Kilobit/sec): 10000 (default)
Max overflow improvement %: 60 (default)
Max overflow degradation %: 60 (default)
Scheda Credits: Tutto come nel primo passaggio
Scheda Debug:
Automatically detect optimizations: ON / OFF
Chroma Optimizer: Come 1° passaggio
Use trellis R-D quantisation:Come 1° passaggio
Frame drop ratio: Come 1° passaggio

Modalità di compressione 1 Pass - quantizer: miglior qualità possibile, a scapito di un maggior tempo di codifica

Unico passaggio
Encoding Mode: 1 Pass - quantizer
Quantizer: 2
Scheda Global:
Motion Search Precision: 6 - Ultra High
Quantization Type: MPEG / H.263
FourCC Used: XVID
VHQ Mode: da "1-Mode Decision" a "4-Wide Search" (rallenta di molto la velocità di codifica)
Max I-frame Interval: 250, Min I-frame Interval: 1
Lumimasking: OFF
Interlacing: OFF / ON (a seconda delle necessità)
Greyscale: OFF / ON (a seconda delle necessità)
Quarterpel: ON / OFF (rallenta molto la velocità di codifica)
Global Motion Compensation: OFF
Chroma Motion: ON
Max B-frames: da 1 a 2 o -1 (disabilitati)
B-frames Quantizer Ratio(%): da 100% a 150%
B-frames Quantizer Offset: 100
B-frame threshold: 0 (da testare)
Packed bittream: OFF
DX50 B-VOB compatibility: ON
Print debug info on each frame: OFF
Scheda Alt. Curve:
Max Bitrate (Kilobit/sec): 10000 (default)
Max overflow improvement %: 60 (default)
Max overflow degradation %: 60 (default)
Scheda Credits:
Start Credits: ON/OFF (a seconda delle necessità)
End Credits: ON/OFF (a seconda delle necessità)
Scheda Debug:
Automatically detect optimizations: ON / OFF
Chroma Optimizer: OFF/ON (da testare)
Use trellis R-D quantisation: OFF (da testare)
Frame drop ratio: 0

Cattura di un video, elevata velocità e bassa precisione: compressione 1 Pass - CBR
(il video catturato deve essere successivamente ricompresso)

Unico passaggio
Il bitrate da usare, dipende dalla risoluzione a cui catturate; consiglio un rapporto bit/pixel di 0,8 per garantire una buona qualità in tutte le situzioni (tale valore è puramente empirico e semplicemente si è dimostrato sufficiente e forse anche eccessivo, nella gran parte dei casi; il valore è comunque molto sensibile alla qualità ed al tipo di video; ad es. un video di pessima qualità con molto rumore di fondo, potrebbe richiedere un valore più elevato). Per calcolare il bitrate, partendo dalla risoluzione, utilizzate la seguente formula:

(*) Bitrate in Kilobit/sec = [(Ris_Oriz_in_Pixel * Ris_Vert_in_Pixel) * Num_Fotogrammi_Sec * Rapporto_Bit_per_pixel] / 1000

dove:
Il risultato è inteso in Kilobit/sec dove 1 Kilobit = 1000 Bit
Num_Fotogrammi_Sec = 25 per sistemi PAL
Rapporto_Bit_per_pixel >= 1

Ad esempio se catturate ad una risoluzione di 320x240, dovrebbe essere sufficiente un bitrate di: Bitrate = (320 * 240) * 25 * 0,8  / 1000 = 1536
Catturando ad una risoluzione di 640x480, dovrebbe essere sufficiente un bitrate di: Bitrate = (640 * 480) * 25 * 0,8  / 1000 = 6144

---------------------------------------------------

Encoding Mode: 1 Pass - CBR
Bitrate: Bitrate in Kilobit/sec(*)
Scheda Global:
Motion Search Precision: da 0 - None  a 1 - Very Low
Quantization Type: MPEG / H.263
FourCC Used: XVID
VHQ Mode: 0 - Off
Max I-frame Interval: 250, Min I-frame Interval: 1
Lumimasking: OFF
Interlacing: OFF / ON (a seconda delle necessità)
Greyscale: OFF / ON (a seconda delle necessità)
Quarterpel: OFF
Global Motion Compensation: OFF
Chroma Motion: OFF
Max B-frames: -1 (disabilitati)
Packed bittream: OFF
DX50 B-VOB compatibility: ON
Print debug info on each frame: OFF
Scheda Quantization
 Min I-frame Quantizer: 2, Max I-frame Quantizer: 31
Min P-frame Quantizer: 2, Max P-frame Quantizer: 31
Scheda Alt. Curve:
Max Bitrate (Kilobit/sec): 10000 (default)
Max overflow improvement %: 60 (default)
Max overflow degradation %: 60 (default)
Scheda Debug:
Automatically detect optimizations: ON / OFF
Chroma Optimizer: OFF
Use trellis R-D quantisation: OFF
Frame drop ratio: 0
Reaction Delay Factor: 16 (default)
Average period: 100 (default)
Smoother: 100 (default)


...buon divertimento.



(Rimuovi "NOSPM_" dall'indirizzo email per contattarmi)

Fonti

1) XviD Help (disponibile con ogni release del codec, cercate nel menù di avvio)

2) XviD Q&A (http://forum.doom9.org/showthread.php?threadid=16935)

3) Doom9's XviD forum (http://forum.doom9.org/forumdisplay.php?forumid=52)

4) DivX 5.0 Help Guide (http://www.divx.com/support/index.php)

5) Digital Video by Benny (http://www.benis.it/dvd/dig_vid.htm, http://www.benis.it/dvd/agg2.htm)

6) Iago's Xvid Guide  - two pass linear scaling (http://nic.dnsalias.com/xvid.html)

7) Doom9's Forum, Problem with Koepi's XviD-09122002-1 (http://forum.doom9.org/showthread.php?threadid=40182)

8) Xvid options explained vers. 1.3, by Koepi's (http://roeder.goe.net/~koepi/)

9) DivX Digest - XviD Codec Setup (http://www.divx-digest.com/articles/xvid_setup_print.html)

10)  Xvid "Newbie" Settings (http://forum.doom9.org/showthread.php?threadid=53136)

11) Doom9's guide: Xvid in VirtualDub (http://www.doom9.org/index.html?/xvid.htm)

12) Digital Signal Coding, Prof.dr.ir. Inald Lagendijk (http://www-ict.its.tudelft.nl/%7Einald/vcdemo/lectures.htm)

potete trovare articoli molto ben fatti sul sito di Benedetto (http://www.benis.it). Altro materiale interessante, in inglese, potete trovarlo ai seguenti indirizzi: http://www.csse.monash.edu.au/~timf/, (in particolare fate riferimento al modulo CSE5302) ed all'indirizzo http://www.vcodex.com.

Torna alla pagina principale del sito