La compressione video Mpeg4


(Versione 1.0)

Questa pagina è stata pubblicata da Andrea Panisson su http://andypanix.altervista.org. Ultimo aggiornamento: 13/07/2003.
(Rimuovi "NOSPM_" dall'indirizzo email per contattarmi)

INDICE

Premessa

Un'introduzione ai formati MPEG

PARTE I - La teoria

La compressione video MPEG: come funziona

Una definizione: Il codec video
I differenti e possibili approcci della compressione video
I diversi modi di comprimere un fotogramma:
gli Intra-Frames (I-Frames)
i Delta-Frames od Inter-Frames (P e B-Frames) e la codifica bidirezionale
Come lavora un encoder video
Conversione RGB to YV12
Blocking
Modellizzazione del moto
DCT, Discrete Cosine Transform
Quantizzazione
Scansione a ZigZag
Run-Level encoding e Variable-Lenght coding
Motion Estimation e Motion Compensation in pratica

"Quantificare" la compressione: il 'Quantizer PARTE II - Alcune cose di cui tener conto 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

Premessa

Forse molti di voi non sanno che quando guardano un film in DVD, stanno in realtà guardando un video compresso, ovvero lo spazio occupato dal video è solo una frazione dello spazio che questo stesso occuperebbe in formato cosidetto "raw" (ovvero non compresso) sebbene la perdità di qualità risulti praticamente insignificante, tanto che spesso non si esiterebbe a definire "perfetta" la qualità video di un DVD.
Ma come funziona questa compressione e soprattutto, perchè è necessario comprimere un video?

Vediamo anzittutto perchè è necessario comprimere un video. Torniamo al nostro DVD. Un film in DVD, ha una risoluzione di 720 punti (pixel) orizzontali per 576 punti (pixel) verticali, o se preferite, è formato da 576 linee orizzontali sovrapposte e ciascuna linea è a sua volta formata da 720 punti. Ora, facendo un rapido calcolo, ogni singola immagine del nostro video è composta da 720x576 punti, ovvero 414.720 punti. I DVD che acquistiamo in Italia ed in tutta Europa sono in formato PAL, ovvero rispettano le particolari specifiche PAL, ed in particolare ogni secondo di video contiene 25 fotogrammi (o immagini).

Un'immagine non compressa a colori può essere memorizzata nel formato RGB (Red, Green e Blu) a 24 o 32 bit. Detto in maniera più semplice, il colore di ogni pixel viene calcolato come combinazione dei tre colori fondamentali Rosso, Verde (Green) e Blu, dove ogni colore viene descritto con un valore di 8 bit, che in decimale equivale ad un numero tra 0 e 255 (con "n" bit è possibile rappresentare esattamente "2n-1" numeri decimali). 8 bit per colore, moltiplicato per 3 colori, equivalgono a 24 bit. Se le immagini sono codificate a 32 bit, si aggiunge anche un canale aggiuntivo denominato "alfa" e che possiamo pensare come un parametro aggiuntivo che descrive la luminosità del singolo pixel. Ad esempio, nel formato RGB 24 bit, il clore bianco è descritto dalla terna di numeri (255 , 255, 255). Facendo qualche rapido conto, con 24bit si possono rappresentare 2553 colori differenti, ovvero 16.581.375.

Ritorniamo al singolo fotogramma del DVD. Vediamo lo spazio che occuperebbe il video se non fosse compresso, supponendo che i singoli fotogrammi siano memorizzati con una profondità di colore di 24bit. Abbiamo detto che ogni fotogramma con risoluzione di 720x576 pixel, è composto da 414.720 punti e che per ogni secondo di video sono necessari 25 fotogrammi. Supponiamo che il film duri un'ora e mezza, ovvero 5.400 secondi. Questo equivale ad avere in tutto 25x5.400 = 135.000 fotogrammi, ovvero 135.000x414.720 = 55987200000 pixel o punti che di si voglia. Se per ogni punto sono necessari 24bit, abbiamo in tutto 55.987.200.000x24 = 1.343.692.800.000 bit. Ora, dato che 1 Byte = 8 bit e che 1 GigaByte = 1.024 MegaByte = 1.024x1.024 KByte = 1.024x1.024x1.024 Byte = 1.024x1.024x1.024x8 bit, risulta che per un'ora e trenta di video DVD non compresso sarebbero necessari circa 156 GigaByte (1.343.692.800.000 / 8.589.934.592), ben più dei miseri 8,5 GigaByte disponibili su di un tipico DVD a doppio strato.

Capite ora quale sia la necessità di comprimere una mole così notevole di dati, nonchè l'enorme efficienza degli algoritmi di compressione video grazie ai quali è possibile inseire un'ora e mezza di video in poco più di 5 GigaByte mantenendo al tempo stesso una qualità invidiabile (un rapporto di compressione nell'ordine di 30:1).

Quasi dimenticavo: l'algoritmo di compressione utlizzato nei DVD è l'MPEG-2.

Il video digitale ultimamente sta avendo un incredibile boom. Da una parte il notevole abbassamento dei prezzi ha portato ad una sempre maggior diffusione dei lettori DVD e più recentemente dei masterizzatori DVD. Dall'altra, il rapido diffondersi della banda larga nella connessione ad internet ha portato molti utenti a scambiare nei sistemi "peer to peer" non solo musica (MP3) ma anche video, soprattutto grazie all'introduzione delle nuove tecnologie di compressione video MPEG4 e la disponibilità di codec video gratuiti od a cifre decisamente abbordabili (DivX ed Xvid in primis), che consentono di ridurre ulteriormente le dimensioni dei film fino alle dimensioni di 1 o 2 CD (700-1400MB). La diffusione di videocamere digitali e schede di acquisizione a prezzi sempre più abbordabili, Il notevole incremento della potenza di calcolo dei computer casalinghi che consentono di effettuare oggi operazioni di compressione video in tempi ragionevoli anche senza disporre di macchine molte costose, ha poi contribuito a fare il resto.

Disporre tuttavia dei mezzi adatti per potersi divertire con il video digitale, non è però condizione sufficiente per garantire la buona riuscita, soprattutto in termini di qualità, dei nostri video casalinghi. Per rendersene conto basta confrontare uno qualunque dei film scaricati dalla rete (operazione peraltro illegale!) con la sua controparte in DVD. Molto spesso, il confronto non è nemmeno proponibile, e la qualità del cosidetto DivX risulta così scadente da inficiarne la visione stessa.

La compressione video infatti non è un'operazione così immediata e semplice come si potrebbe pensare: se si vogliono ottenere dei buoni risultati, un video almeno qualitativamente vicino ai DVD, è necessaria almeno un minimo di conoscenza sul suo funzionamento. Questa guida come prima cosa vi introdurrà ai principi generali della compressione video MPEG (1, 2 e 4) e tenterà quindi di di fornirvi le idee di base su come procedere per la creazione di buoni video digitali, con un occhio di riguardo alla compressione MPEG4, in particolare al codec video Xvid.

Un'introduzione ai formati MPEG

Prima di iniziare con il funzionamento di un codec video, ritengo sia doveroso un piccolo chiarimento per quel che riguarda i vari formati video MPEG ed al loro utilizzo più diffuso. Questa tabella dovrebbe fornire tutti i dettagli di cui dovreste avere bisogno.


MPEG1 MPEG2 MPEG4
E' il formato più "vecchio" ed oggi non viene praticamente più utilizzato. Sono disponibili diversi programmi gratuiti che consentono di creare video MPEG-1, quali ad esempio TMPGEnc.
 E' il formato utilizzato nei DVD e nei SVCD. Si tratta attualmente del formato video che consente di ottenere la qualità migliore, sebbene i migliori codec di compressione non siano molto abbordabili in termini di prezzo.
E' lo standard più recente, ed i codec di compressione MPEG4 sono tutt'ora in fase di sviluppo. Pensato anche per lo streaming video (trasmissione tramite internet) è in grado di fornire una qualità sostanzialmente identica a quella di un DVD in 1/4 - 1/3 dello spazio (a parità di risoluzione). I più promettenti codec MPEG-4 sono il noto DivX (a pagamento nella versione con piene funzionalità) e la sua controparte opensource Xvid, liberamente utilizzabile a fini non commerciali.
Utilizzi possibili: creazione di video CD (VCD) compatibili con i normali lettori DVD da tavolo. In un VCD è possibile inserire generalmente 30-40 minuti di video, sebbene la qualità non sia paragonabile a quella del suo successore MPEG-2, quanto piuttosto a quella di una videocassetta VHS.
 Utilizzi possibili: creazione di super video CD (SVCD) o di DVD compatibili con i normali lettori DVD da tavolo. Il formato SVCD consente una qualità notevolmente superiore al vecchio VCD, e generalmente è possibile inserie 40-45 minuti di video di buona qualità (superiore a quella di una VHS) in un comune CD da 80 minuti. A mio avviso, disponendo di un programma con codec di compressione MPEG-2, è il formato ideale in cui salvare i video provenienti dalla videocamera digitale se si desidera una qualità discreta ed una buona compatibilità.
 Utilizzi possibili: è teoricamente possibile inserie fino ad 1 ora e mezza di video di buona qualità in un solo CD (con risoluzioni fino a 640x368 punti), ed è l'ideale per comprimere i DVD in uno o due CD. Tuttavia il formato non risulta compatibile con i normali lettori DVD (che decodificano solo video MPEG-1 e MPEG-2). Solo recentemente sono stati introdotti lettori da tavolo in grado di riprodurre DivX (od Xvid), tuttavia, la loro compatibilità non è garantita (data l'elevata variabilità dei formati e dei parametri di compressione utilizzati).

Per maggiori informazioni e per approfondimenti sull'MPEG1 e 2, vi consiglio questo sito: Digital Video by Benny (in italiano).

PARTE I - La teoria

La compressione video MPEG: come funziona

Ora addentriamoci un pò di più nei meandri della compressione video. Sebbene non sia strettamente necessario conoscere il funzionamento di un codec video per effettuare delle buone compressioni, credo possa comunque rivelarsi utile avere una minima comprensione di come questo operi.

DEF: Vediamo anzitutto di dare una definizione per chiarire un termine che fin qui ho usato più di una volta ma di cui forse non tutti comprendono appieno il significato: 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 tutto:

Video originale (non compresso)
Video originale
(non compresso)		 EnCOder
freccia
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.		 Postprocessing
 Video Decompresso
Video decompresso che "scorre" sul monitor o sulla TV

In questo articolo mi occuperò della sola 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. Vediamo dunque in cosa consiste la compressione di un flusso video.

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).

I progettisti dei codec MPEG, analizzando le caratteristiche tipiche di un flusso video, furono in grado di individuare delle "peculiarità" che potevano essere sfruttate ai fini della compressione. Così, quando si posero la fatidica domanda "come implementare un algoritmo di compressione video", individuarono diverse possibili vie da perseguire: ottimizzare il metodo di memorizzazione digitale dei dati relativi al video, sfruttare delle caratteristiche intrinseche al video stesso dovute alla sua struttura sequenziale, e, studiando accuratamente il sistema visivo umano, cercarono quelle caratteristiche che era possibile sfruttare ai fini della compressione stessa. La tabella seguente riassume a grandi lineee gli approcci che furono individuati ed utilizzati nella progettazione dell'encoder video, approcci che combinati tra loro avrebbero consentito di sviluppare algoritmi di compressione così efficienti da ridurre ad esempio di 30 volte le dimensioni occupate da un file video senza apparente degrado qualitativo (MPEG-2).

I differenti e possibili approcci della compressione video

A. Tecniche relative al modo di memorizzazione del video stesso, in combinazione con le caratteristiche del sistema visivo umano.
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.

B. Tecniche che sfruttano alcune caratteristiche intrinseche al video stesso
 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 cioè una rappresentazione "meno correlata" delle immagini, correlata nel senso delle similitudini all'interno dello stesso fotogramma e tra fotogrammi adiacenti, eliminando quindi nel possibile tutte le "ripetizioni".

Quindi, dato che è statisticamente provato 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), venne ideata la codifica intra-frames che si occupò per l'appunto di rimuovere questa ripetitività o ridondanza spaziale all'interno dello stesso fotogramma.

Inoltre, dato che esiste una netta correlazione non solo tra i pixel dello stesso fotogramma, ma anche tra i pixels di fotogrammi adiacenti. Infatti, dato che ogni secondo si susseguono diversi fotogrammi (25 nello standard PAL), è logico aspettarsi che un fotogramma ed i due a lui 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, venne trattata con l'implementazione della codifica inter-frames.

C. Tecniche che sfruttano intensivamente le caratteristiche del sistema visivo umano.
Studiando la percezione che l'occhio e del cervello umano hanno della realtà ed in particolare del movimento, ci si è resi conto della scarsa sensibilità del sistema visivo umano nei riguardi delle cosidette alte frequenze video. Il concetto di frequenza nel video è associato alla "complessità" di una scena: “…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...” (1). 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).

Due termini presenti nel riquadro precedente richiedono delle spiegazioni aggiuntive. Nel riquadro si accennava infatti alla codifica intra-frames ed a quella inter-frames. Vediamone il significato.

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

Anzitutto è necessario pensare ad un video come ad una serie di immagini (fotogrammi) che si susseguono in rapida sequenza. Quindi quando si comprime un flusso video si stanno sostanzialmente comprimendo delle immagini, ma non solo: si stanno comprimendo immagini in sequenza. E' possibile farsi un'idea su come viene trattato un flusso video, osservando la figura seguente:



Ogni immagine viene scomposta in singoli blocchetti ed ogni blocchetto è trattato singolarmente. Il singolo fotogramma è formato da gruppi di blocchi ed i fotogrammi sono a loro volta impacchettati in gruppi di fotogrammi. La codifica intra-frames ed a quella inter-frames non sono altro che metodi diversi con cui vengono trattati (leggi compressi) i singoli fotogrammi. In pratica, se prima della compressione tutti i fotogrammi sono sostanzialmente uguali, ed una sequenza video non compressa sarà qualcosa del tipo FFFFFFFFFFFFF..., il file compresso conterrà invece una sequenza di fotogrammi del tipo IPBBBPBBBPIBBBP..., dove con i ho indicato un intra-frames ( I-Frames o fotogramma I o fotogramma chiave) mentre P e B descrivono due differenti tipi di fotogrammi di tipo inter-frames. Vediamoli più in dettaglio.

Gli Intra-Frames
I-Frames: i fotogrammi di tipo I, chiamati anche Intra-Frames o Key-Frames (fotogrammi chiave), sono fotogrammi che vengono codificati (compressi) 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. Intervengono solo tecniche di rimozione di rindondanza spaziale (similitudine tra pixel adiacenti), mentre non viene applicato nessun algoritmo di compressione temporale (ovvero compressione che tiene conto anche dei fotogrammi successivi e/o precedenti). Sebbene con un'immagine compressa in formato JPEG di buona qualità si possa ottenere un rapporto di compressione anche di 20:1, siamo ancora lontani dal valore del rapporto di compressione cercato per il video; prima si parlava di qualcosa tipo 30:1 per un video MPEG-2, mentre per un video in MPEG-4, il rapporto può scendere anche a valori di 50-60:1. Gli I-Frames sono inseriti generalmente dall'encoder video ogni qualvolta vi sia un cosidetto cambio di scena, ovvero in tutti quei casi nei quali manchi una corrispondenza temporale tra fotogrammi adiacenti. 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 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).

I Delta-Frames od Inter-Frames
P-Frames: si usa una codifica di tipo P (Predicted frames) per quei fotogrammi che vengono codificati utilizzando informazioni acquisite dal fotogramma precedente, sia questo di tipo I o di tipo P.  Ogni blocco di 16x16 pixels in cui viene suddiviso il singolo fotogramma, con la codifica di tipo P può essere compresso 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. 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 l'altro tipo di inter-frames, ovvero i fotogrammi di tipo B (bidirectional) 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. (2)

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

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 appena detto, credo sia doveroso anticipare quello che dovrebbe essere uno dei principali fattori da tenere in considerazione quando ci si accinge a comprimere un video.

Sequenze video con scene in rapido movimento o con un'elevata dinamica sono molto più impegnative da codificare e richiedono un numero di bit (bitrate) 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 bitrate.


Scendiamo ora un pò di più nel dettaglio, ed analizziamo i singoli passaggi della compressione.

La prima fase è una conversione dello spazio di colore: la prima compressione applicata è di tipo A, ovvero cambia il modo in cui vengono memorizzate le informazioni del video stesso. 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"(1). 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.


Bene, ora dovreste avere almeno una vaga idea del procedimento generale che sta alla base del processo di compressione video, almeno per quel che riguarda la compressione MPEG. Uno dei punti forse più difficili da focalizzare è il funzionamento delle compensazione del moto e di come questa tecnica possa essere utilizzata per ridurre il numero di informazioni che devono essere memorizzate e quindi ridurre la dimensione del file video. L'esempio seguente dovrebbe aiutarvi a chiarire le idee.

Motion Estimation e Compensation in pratica

Bene, vediamo ora 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 differenza sulla 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) è centrato sul relativo macroblocco, ed indica la direzione in cui si sposterà tale macroblocco nel fotogramma B successivo. La direzione del vettore è stata precedentemente calcolata mediante il procedimento di motion estimation. L'immagine di destra è il risultato della 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, se possibile adottate una risoluzione, ovvero un numero di pixels verticali ed orizzontali che siano un multiplo di 16, come ad esempio 640x272 piuttosto che 640x280. In altre parole fate si che le dimensioni orizzontali e verticali del video siano divisibili per 16 (senza resto!). Sebbene molti codec consentano anche dimensioni multiple di 8, di 4 o di 2, per una compressione ottimale sono da preferirsi comunque multipli di 16.

Un piccolo commento riguardo alla nota di qui sopra. Come già accennato, utilizzare una risoluzione multipla di 8 o di 4 non necessariamente porta problemi od errori in fase di codifica o decodifica (dipende comunque dal codec impiegato), tuttavia per la struttura stessa dei macroblocchi, utilizzando dei multipli di 16 si dovrebbero ottenere dei benefici in termini di ottimizzazione del codec. Intuitivamente, usando una risuluzione ad esempio di 640x360 pixel  (640 è multiplo di 16, mentre 360 è multiplo di 8), avremmo una linea orizzontale di "macroblocchi" non standard 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/) e ripeto, dipende dal codec impiegato.

PARTE II - Mettere tutto in pratica

I metodi di compressione

Prima di procedere con i consigli sulla scelta del metodo di compressione, credo sia doveroso illustrare quali siano effettivamente questi metodi. Ho descritto in precedenza i passaggi fondamentali che avvengono durante le diverse fasi della compressione. Ma quello che non ho detto è che vi possono essere approcci differenti per quel che riguarda il modo in cui questi vengono effettuati. Ovvero, diversi sono i metodi con cui l'encoder procede alla compressione. Sostanzialmente si possono fare due grosse distinzioni: metodi ad un solo passaggio e metodi a più passaggi (generalmente si tratta di due passaggi). Nei metodi ad un solo passaggio, il codec video analizza singoli blocchi di fotogrammi e poi procede alla loro compressione. Si tratta di metodi a bitrate costante, oppure a bitrate medio costante, metodi a qualità costante. I metodi di compressione a passaggio multiplo, in particolare a doppio passaggio, si differenziano dai precedenti in quanto prima viene analizzato tutto il video (primo passaggio) e solo in un secondo momento si procede alla compressione.

La scelta del metodo di compressione

Fin'ora abbiamo visto come funziona un codec video. Effettivamente, se questo può risultare utile per padroneggiare l'arte della compressione, è difficile ricavarne una qualche informazione "pratica". Teoria a parte, come ho gia detto in precedenza, comprimere un video richiede delle conoscenze aggiuntive. Se l'esperienza è sicuramente uno dei migliori mezzi per garantire buoni risultati, è possibile comunque tracciare delle linee guida che dovrebbero aiutare a comprendere quali siano i fattori fondamentali da tenere in considerazione al momento della 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, il filmino delle nostre vacanze o del materiale creato ad hoc.

1) lo spazio occupato dal video è sostanzialmente ininfluente, ciò che conta è la sola qualità.

2) Siamo in presenza di uno spazio limitato, ma 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 si desidera mantenere i video digitali su di un disco fisso dedicato (dischi di grosso taglio, superiore ai 120GB sono oggi piuttosto economici). Oppure, data la rapida diffusione ed il costante ribasso dei prezzi, si potrebbe optare per i supporti DVD: i  4,7GB di un supporto DVD (o gli 8,5 nel caso di un DVD doppio strato), sono sicuramente più che sufficienti per un normale video di 3-4 ore in Mpeg4 ad elevata risoluzione (es. 1024x576), lasciando anche spazio libero per eventuali tracce audio multicanale. In questi casi, non ci si preoccuperà dello spazio disponibile o di quello occupato dal video, quanto piuttosto di 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 nel caso il codec lo consenta (es. quality = 99%, quantizer fisso = 2, etc...). 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 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).

Nel primo caso, si tratta sostanzialmente di configurare in maniera corretta l'encoder video in modo tale da garantirsi la miglior qualità possibile. Facendo riferimento quindi al manuale di configurazione del codec, impostate il tutto per la codifica, ricordandovi che sono sufficienti metodi ad un solo passaggio, a bitrate costante (molto elevato, possibilmente massimo) o a qualità costante massima. In queste situazioni, una codifica a due passaggi non porterà a nessun giovamento in termini qualitativi, e non è pertanto consigliata dato che avrà come conseguenza un raddoppiamento dei tempi di compressione.

Nel secondo caso invece le cose si complicano un pochino. Andiamo ora ad analizzare più in dettaglio la problematica sollevata da questa seconda situazione.

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 improponibile.

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).


(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

...buon divertimento.



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

Fonti

1) Digital Video by Benny (http://www.benis.it/)

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




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.