Facolt di Ingegneria Informatica

Utilizzo delle Trasformate

nella codifica delle immagini fisse, in movimento ed audio

Studente:
Francesco Bucciantini

Professore:
Giovanni Murari

Si ringrazia
il Dott. Ingegner Tiziano Squarcia

ANNO ACCADEMICO 2015-2016

 Indice:

Introduzione
0) Cenni storici ed importanza della compressione video
1) Basi della codifica tramite trasformata

1.1) Trasformate unitarie

1.2) Trasformate ad una dimensione (monodimensionali)
1.3) Trasformate a due dimensioni (bidimensionali)
1.4) Trasformate a tre dimensioni (tridimensionali)
1.5) Trasformate direzionali
1.6) Analisi del funzionamento di alcune trasformate prese in esame

Trasformata di Karhunen-Love
Trasformata Discreta di Fourier
Trasformata Discreta del Coseno
Trasformata di Walsh Hadamard
Trasformata Discreta di Wavelet

2) Utilizzo delle trasformate nei codec di codifica delle immagini

2.1) Lo standard JPEG

2.2) Lo standard JPEG2000
2.3) Lo standard GIF
2.4) Lo standard PNG

3.0) Basi della codifica video

3.0.1) Scene video naturali

3) Utilizzo delle trasformate nei codec di codifica video

Generalizzazione su encoder e decoder

3.1) H.261
3.2) Video Standard, MPEG-1
3.3) Video Standard, MPEG-2
3.4) Video Standard, H.263
3.5.0) Video Standard, MPEG-4
3.5.1) Video Standard, MPEG-4 Visual (MPEG-4 Part 2)
3.5.2) Video Standard, MPEG-4 (Part 10), AVC H.264
3.6.0) Introduzione all'HEVC H.265
3.6.1) Una trasformata adattiva per la codifica video migliorata basata sull'H.264
3.6.2) Architettura
3.6.3) Dettagli della trasformata adattiva
3.6.4) Valutazione delle prestazioni
3.7) HEVC H.265
3.7.1) HEVC vs H.264

4) Utilizzo delle trasformate nei codec di codifica audio

4.1) MPEG-1 Layer 1 (.mp1)

4.2) MPEG-1 Layer 2 (.mp2)
4.3) MPEG-1 Layer 3 (.mp3)
4.4) Advanced Audio Coding (AAC)
4.5) AC3 Audio Coding 3
4.6) Vorbis (.ogg)
4.7) Opus (.opus)
4.8) I codec audio lossless: FLAC e WAV a confronto

Valutazioni finali della tesi

Bibliografia

Introduzione:
La tesi si basa sull'analisi delle tecnologie di codifica in un particolare metodo di compressione:
la codifica mediante trasformata.
Tale metodo di codifica basato sul rimuovere la ridondanza spaziale presente in una data
immagine (che sia singola o parte di un video frame ) trasformandola dal dominio spaziale a
quello delle frequenze.
Il metodo di codifica preso in esame trae vantaggio dal fatto che l'occhio umano percepisce in modo
minore le alte frequenze rispetto alle basse frequenze in modo da poter tagliare dettagli meno
significativi a livello di percezione visiva.
Ad oggi, quasi tutti i pi conosciuti ed utilizzati metodi di codifica utilizzano la DCT (Discrete
Cosine Trasformate) ovvero la Trasformata Discreta del Coseno, tuttavia in fase di sviluppo un
nuovo metodo di codifica che punta a trarre vantaggio da un diverso metodo di codifica tramite
trasformata: l'HEVC.
Lo scopo della tesi di analizzare nel dettaglio la nuova codifica video HEVC, la codifica audio ed
i vari metodi di trasformata utilizzabili, nonch comparare i risultati dei precedenti metodi di
codifica, in particolar modo con l'MPEG-4 Part 10 (AVC, H.264) che verr analizzato in modo
completo e dettagliato.
Come introduzione alle codifiche video, inoltre, verranno esplicati i vari metodi di codifica delle
immagini fisse, con particolare importanza rivolta allo standard lossless PNG ed, infine, verranno
analizzati anche i codec audio.

0) Cenni storici ed importanza della compressione video

La velocit delle connessioni internet in continuo aumento, cos come i bitrate dei network e la
grandezza di Hard Disk, memorie flash e media ottici.
Con il prezzo delle trasmissioni e dell'archiviazione in continua diminuzione, potrebbe non essere
immediatamente chiaro perch la compressione video tanto necessaria e perch ci sono cos tanti
sforzi ora come in passato per renderla migliore.
La compressione video ha due importanti benefici: il primo che rende possibile utilizzare video
digitali nelle trasmissioni e nello storage in ambienti che non sono in grado di supportare video non
compressi, chiamati raw.
Ad esempio, per quanto possa essere veloce, la fibra ottica che raggiunge le attuali abitazioni
ancora insufficiente per poter gestire video non compressi in tempo reale (anche a bassi frame rate
immagini al secondo e basse risoluzioni).
Un altro esempio che sia i DVD che i Bluray Disk sono in grado di contenere solo pochi frame di
un video raw conforme alle qualit ed ai frame rate degli standard televisivi e sarebbero dunque
inutilizzabili senza un'opportuna compressione video.
Il secondo beneficio offerto dalla compressione video che permette un utilizzo pi efficiente delle
risorse di trasmissione e storage.
Un segnale pu dunque essere compresso rimuovendo la ridondanza e ci sono due metodi principali
di compressione: il metodo lossless e quello lossy.
Nelle compressioni lossless (prive di perdita) la ridondanza statistica rimossa in modo che il
segnale originale possa essere perfettamente ricostruito dal decoder.
Sfortunatamente, al momento, i metodi di codifica lossless riescono a comprimere le immagini in
modo insufficiente e, mentre per la codifica delle immagini fisse molto utilizzata la codifica
lossless, non possibile affermare la stessa cosa per la codifica video.
I pi comuni metodi di compressione video infatti sono basati su compressioni lossy (con perdita),
nelle quali possibile ottenere grandi benefici in termini di compressione,

al costo per di perdere parte delle informazioni; difatti l'immagine ricostruita dal decoder non sar
mai identica a quella originale.
L'obiettivo dei codec di codifica video dunque quello di ottenere il massimo beneficio in termini
di compressione, con la minima distorsione introdotta dal processo di compressione.
Gli algoritmi di compressione video rimuovono la ridondanza temporale, spaziale e/o i domini di
frequenza.
Come prima introduzione, si guardi ora l'immagine sottostante che rappresenta un esempio di un
singolo frame video.

All'interno delle regioni evidenziate (rettangolo di sinistra e destra) presente una lieve variazione
nel contenuto dell'immagine e, quindi, c' una ridondanza spaziale significativa.
Si prenda ora in analisi la seconda immagine riportata di seguito.

Questa seconda immagine mostra lo stesso identico frame dopo essere stato processato da un filtro
passa-basso in modo da rimuovere alcuni dei contenuti ad alta frequenza.

L'occhio umano pi sensibile alle basse frequenze e l'immagine ancora riconoscibile, sebbene
parte delle informazioni sono andate perdute (si pensi ai lineamenti del muro sullo sfondo).
Si prenda ora in esame questa terza immagine che mostra il frame successivo della sequenza video.

La sequenza originale era stata catturata da una videocamera a 25 fps, quindi c' un piccolo
cambiamento tra i due frame e c' una chiara ridondanza temporale (la maggior parte dell'immagine
rimane identica tra i frame successivi).
Rimuovendo i diversi tipi di ridondanza (spaziale, delle frequenze e/o temporale), possibile
comprimere i dati al costo di una perdita di informazioni (distorsione).
Un'ulteriore compressione pu essere raggiunta encodando i dati processati utilizzando una codifica
entropica come quella di Huffman.
La compressione video e delle immagini rappresenta da anni un prolifero campo di ricerca e sono
stati sviluppati numerosi sistemi ed algoritmi di compressione e decompressione e sono stati definiti
numerosi standard.
Dopo questa breve introduzione, passiamo adesso ad analizzare le fondamenta sulle quali si basa la
codifica mediante trasformata per poi introdurre i primi standard di codifica delle immagini fisse.

1) Basi della Codifica Tramite Trasformata

La codifica tramite trasformata uno degli strumenti fondamentali della codifica audio e video che
utilizziamo oggi giorno in quasi ogni settore.
Il suo funzionamento da ricondurre al processo di riduzione di ridondanza spaziale rappresentando
i pixel nel dominio delle frequenze per poi poter effettuare una riduzione della quantit di dati in
uscita tramite compressione e quantizzazione.
Per poter essere compresso, un segnale deve essere decorellato tramite una trasformata apposita,
ridistribuendo la sua energia ad un piccolo numero di coefficienti,
collocati nella regione delle basse frequenze.
Questi coefficienti possono essere quantizzati in modo da poter eliminare una piccola quantit di
informazioni meno rilevanti senza intaccare la qualit finale dell'immagine una volta ricostruita.
Sebbene il processo di trasformata non comporti una perdita di dati (cio lossless), il processo
di quantizzazione la comporta e viene dunque detto lossy - cio con perdita; si ha cos quello
che viene chiamato un errore di quantizzazione in quanto non pi possibile accedere ai dati

originali una volta quantizzati.

Ad ogni modo, non del tutto corretto dire che il processo di trasformata privo di perdita, poich,
sebbene lo sia da teoria, in pratica pu comportare una limitazione in quanto la sua
implementazione pu avere dei limiti numerici dovuti al suo stesso impiego, quali, ad esempio,
arrotondamenti e troncamenti.
Il segnale viene segmentato in blocchi pari, tipicamente da 8x8.
Ogni blocco poi trasformato individualmente mediante l'operazione di transformazione dei
macroblocchi.
Grazie a questo processo basato sui blocchi, possibile ridurre la complessit totale dei calcoli di
trasformata in quanto risulta molto pi facile eseguire i blocchi individualmente rispetto che a
processare tale operazione sull'intera immagine.
Trasformare ogni blocco singolarmente pu inoltre catturare le informazioni in modo migliore,
sfruttando la correlazione tra di essi in modo migliore, anche se, in realt, tale correlazione non
mai veramente sfruttata a dovere e spesso questo pu risultare in errori di riproduzione dovuti alla
ricostruzione finale dell'intera immagine.
Un esempio dato da un'immagine fortemente quantizzata nella quale possibile notare artefatti
dovuti a blocking, ovvero possibile notare con facilit i bordi dei vari blocchi.
In altre parole: maggiore la compressione, pi facile sar vedere tali artefatti.
Dal punto di vista teorico, una trasformata tenuta a soddisfare alcuni punti fondamentali in modo
da rendere la sua adozione utile al fine pratico.
Il primo dei requisiti fondamentali la reversibilit, ovvero il fatto che il segnale di ingresso
possa essere ricostruito senza errori dal segnale di uscita al quale stato applicato il calcolo di
trasformata.
Questo forse il pi importante dei requisiti - almeno per quanto riguarda la codifica video - in
quanto per poter visualizzare un'immagine necessario poter ricreare il segnale di partenza.
Un altro elemento riguarda la riduzione della quantit di dati, ovvero il fatto che la trasformata
debba concentrare il segnale in entrata nel minor numero possibile di coefficienti.
Importante anche il fatto che la stessa informazione non deve essere ripetuta in coefficienti
diversi, o, se ci accade, la ripetizione deve essere ridotta al minimo in modo da assicurare
un'efficiente decorrelazione.
Idealmente, possiamo dire che, oltre alle cose sopraelencate, una trasformata debba essere anche il
meno complessa possibile (parlando in termini di operazioni da eseguire) in quanto logico pensare
che meno calcoli vengono eseguiti, maggiore sar la sua efficienza a livello di calcolo
computazionale.
1.1) Trasformate Unitarie:
Una trasformata unitaria di un dato vettore x in ingresso definita da:

Dove B una matrice unitaria pari ed y il vettore con i coefficienti di trasformata.

Una matrice pari unitaria se il suo inverso uguale al suo trasposto coniugato.
Se una matrice unitaria ha solo valori reali, allora la sua inversa sar uguale al suo coniugato
e viene definita matrice ortogonale.
Ricordo che i vettori colonna ed i vettori riga di una matrice unitaria sono ortogonali
(perpendicolari tra loro) e normalizzati e possono essere definiti come segue:

dove b di k la k 'esima colonna della matrice unitaria B.

I vettori b di k costituiscono un gruppo di vettori base ortonomali.
I vettori base sono un gruppo di vettori che possono essere combinati linearmente per rappresentare
ogni vettore in un dato spazio vettoriale.
A sua volta, le funzioni base sono un gruppo di funzioni che possono essere combinate linearmente
per rappresentare ogni funzione in un dato spazio di funzione.
In questo caso, la matrice unitaria B rappresenta la trasformata unitaria di funzione base.
Le trasformate unitarie comprendono le caratteristiche sopraelencate tra cui, in primis,
la reversibilit; in questo caso abbiamo che:

Un'altra propriet di quelle sopraelencate che viene rispettata quella della riduzione della quantit
di dati tramite i coefficienti ed il fatto di preservare l'energia dell'onda mediante gli stessi:

Le trasformate unitarie, solitamente, sono le pi utilizzate negli standard di compressione video.

1.2) Trasformate ad Una Dimensione (monodimensionali):
Considerando x(n) un blocco di N campioni in entrata (dominio spaziale) ed y(k) un gruppo di N
coefficienti di trasformata (dominio delle frequenze), una trasformata monodimensionale data da:

dove a(k,n) sono le funzioni di trasformata base.

La trasformata inversa usata per ricomporre il segnale originale invece definita da:

dove b(k,n) sono le funzioni di trasformata base inversa.

Tenendo conto che il primo vettore base tipicamente corrispondente alla frequenza di componente
zero, corrisponde alla funzione costante, allora y(0) chiamato coefficiente DC, che rappresenta il
principale indicatore della forma d'onda sotto trasformata.
proprio questo il coefficiente di trasformata pi importante dato che associato alla frequenza pi
bassa percepibile.
Tutti gli altri coefficienti, invece, sono chiamati coefficienti AC.

1.3) Trasformate a Due Dimensioni (bidimensionali):

Considerando ora x(m,n) come blocco di campioni NxN a due dimensioni e y(k,l) un gruppo di NxN
coefficienti di trasformata, la trasformata bidimensionale data da:

La trasformata bidimensionale inversa invece data da:

a(k,l,m,n) e b(k,l,m,n) sono rispettivamente le funzioni di trasformata bidimensionale e trasformata

bidimensionale inversa.
Ci sono due classi fondamentali di trasformate bidimensionali: le trasformate separabili e le
trasformate non separabili.
Le trasformate non separabili sono calcolate utilizzando semplicemente le N colonne in ingresso da
un capo all'altro per formare una singola colonna di vettori di lunghezza N^2 e solo dopo viene
effettuato il calcolo di trasformata.
Le trasformate separabili sfruttano sia le correlazioni orizzontali che quelle verticali del segnale in
ingresso e, tipicamente, richiedono un'operazione aritmetica N^4.
In una trasformata separabile bidimensionale, entrambe le funzioni di trasformata di base sono
separate in operazioni distinte (orizzontale e verticale):

Con queste due operazioni, una trasformata separabile bidimensionale pu essere elaborata in due
fasi indipendenti, eseguite una dopo l'altra.
La prima fase utilizza la funzione base orizzontale ah (l,n),
sfruttando la correlazione orizzontale dei dati.
La seconda fase utilizza invece la funzione di base verticale av (k,m),
sfruttando la correlazione verticale dei dati.
Le trasformate bidimensionali separabili sono implementate come due trasformate
monodimensionali consecutive e sono date da:

In notazione di matrice abbiamo:

Le funzioni di base simmetriche sono funzioni che hanno componenti orizzontali e verticali
simmetriche Av = Ah = A. In questo caso, abbiamo:

La moltiplicazione di due matrici NxN richiede un'operazione matematica di N^3.

Di conseguenza, una trasformata separabile bidimensionale, che ha due moltiplicazioni di matrice,
richiede un'operazione 2N^3 (ricordo che la trasformata non separabile richiede N^4).
Quindi, nel caso in cui si abbia N > 2, preferibile utilizzare una trasformata bidimensionale.
1.4) Trasformate a Tre Dimensioni (tridimensionali):
Consideriamo adesso x(m,n,p) come un blocco di campioni NxNxN tridimensionale in ingresso.
Tale segnale d'ingresso ha due componenti spaziali ed una componente temporale.
Considerando y(k,l,q) i coefficienti di trasformata, la trasformata tridimensionale data da:

La trasformata tridimensionale inversa invece data da:

a(k,l,q,m,n,p) e b(k,l,q,m,n,p) sono rispettivamente le funzioni di trasformata tridimensionale e

trasformata tridimensionale inversa.
Con una trasformata tridimensionale possibile sfruttare la correlazione tra i dati in tre dimensioni:
due nello spazio ed uno nel tempo.
In particolare, nella codifica video, possibile rimuovere non solo la ridondanza spaziale,
ma anche la ridondanza temporale!
Ovviamente, utilizzando questo tipo di trasformata, la durata di codifica subir un significativo
rallentamento, soprattutto su video con un elevato numero di frame.
1.5) Trasformate Direzionali
Una trasformata direzionale una trasformata che utilizza le informazioni dei bordi presenti in
alcuni dati in entrata per poter sfruttare meglio la correlazione dei gruppi di dati.
Lo scopo di questa trasformata di aumentare la compressibilit rilevando e rimuovendo la
ridondanza spaziale in modo migliore rispetto alle trasformate non direzionali,
aumentando cos il rapporto di compressione rispetto alle stesse.
Le trasformate bidimensionali come ho detto prima sono processate individualmente calcolando
due trasformate monodimensionali (una verticale ed una orizzontale).
Tale approccio pu risultare molto utile in alcuni casi, ma non sempre possibile applicarlo
ottenendo il risultato sperato in tutte le situazioni.

Consideriamo il seguente blocco che ha la peculiarit di avere una linea diagonale che divide due
regioni.

In questo caso, una trasformata bidimensionale separabile genererebbe un numero pi elevato di

coefficienti non nulli, deteriorando cos l'efficienza di compressione della trasformata stessa.
proprio in questo caso che ci vengono in aiuto le trasformate direzionali.
Le trasformate direzionali sono varie e possono avere approcci e risultati diversi l'una dall'altra a
causa del loro modus operandi.
Ci sono le trasformate direzionali dipendenti dal modo che possono utilizzare diverse funzioni base,
ognuna per un bordo specifico.
Dopo aver analizzato la direzione dei bordi, selezionano quale funzione base utilizzare ed effettuano
una trasformata bidimensionale.
Ci sono le trasformate direzionali a singola dimensione ripetuta.
Nella prima fase, viene eseguita una trasformata monodimensionale sulla direzione del bordo.
Nella seconda fase, viene effettuata una trasformata monodimensionale orizzontale.
Ci sono infine le trasformate direzionali di ordinamento e bidimensionali.
In questo caso, i gruppi di dati in ingresso vengono riordinati a seconda del bordo direzionale.
Dopodich, viene eseguita una trasformata monodimensionale per le righe e per le colonne,
similmente a quanto accade in un processo di trasformata bidimensionale.
1.6) Analisi del funzionamento di alcune trasformate prese in esame
Dopo una breve introduzione sui tipi di trasformata, procedo ora col prendere in esame le
trasformate pi importanti utilizzate per la codifica video.

Trasformata di Karhunen-Love

La Trasformata di Karhunen-Love (KLT) una trasformata unitaria ortogonale non separabile,

la cui trasformata monodimensionale e la sua inversa monodimensionale per un vettore x sono
definite da:

La matrice rappresenta la funzione di trasformata di Karhunen-Love di base.

Questa trasformata non ha un insieme di funzioni base predefinite poich le sue funzioni base sono
dipendenti dal dato di origine e sono determinate nel seguente modo:
Convarianza: la convarianza della matrice definita come

dove
il valore dell'i-esimo dato in ingresso nel vettore x.
Autovettori ed Autovalori della convarianza computazionale della matrice: computazione della
matrice degli autovettori della matrice di convarianza
dove la matrice diagonale di autovalori della matrice di convarianza

dove m l'm-esimo autovalore della matrice di convarianza . Le colonne della matrice

corrispondono agli autovettori della matrice di convarianza , rappresentata nelle funzioni di base
della trasformata di Karhunen-Love.
Questa trasformata la miglior trasformata possibile in termini di compressione in quanto riesce a
codificare il segnale utilizzando il minor numero di coefficienti possibile.
Ad ogni modo, la trasformata di Karhunen-Love utilizza delle funzioni di base dipendenti dal dato
di ingresso, il che comporta la continua computazione della matrice di convarianza del segnale in
ingresso, cos come la sua memorizzazione e trasmissione.
Non solo, proprio per ottenere una codifica tanto efficiente, la trasformata di Karhunen-Love
richiede una grande quantit di calcoli per poter determinare le funzioni di base,
il che ne aumenta la complessit.
Proprio a causa della grande quantit di calcoli richiesti, il suo utilizzo nell'ambito della codifica
video limitato, anche se una sua versione modificata proprio alla base del nuovo codec HEVC.

Trasformata Discreta di Fourier

La Trasformata Discreta di Fourier (DFT) una trasformata unitaria ed ortogonale che utilizzata
per scomporre il dato originale nelle sue componenti di seno e coseno.
una trasformata unitaria bidimensionale e la sua trasformata ed inversa (per un blocco di dati
NxN) sono definite da:

Le funzioni base della trasformata discreta di Fourier corrispondono alle onde di seno e coseno con
frequenze in aumento.
Il primo coefficiente y(0,0) rappresenta i componenti DC.
A differenza di quella di Karhunen-Love, quella di Fourier una trasformata separabile e le sue
funzioni di base possono essere rappresentate come prodotti di due trasformate unitarie date da:

Per un vettore di lunghezza N, computare una trasformata di fourier monodimensionale richiede

N^2 operazioni aritmetiche.
Per ridurre la complessit di questa trasformata, spesso viene utilizzata un'implementazione speciale
chiamata Trasformata Discreta di Fourier Veloce (FFT).
Utilizzando la FFT al posto della DFT normale, possibile ridurre le operazioni aritmetiche per la
trasformata monodimensionale ad un semplice NlogN.
La trasformata Discreta di Fourier Veloce dunque in grado di ridurre significativamente la
complessit della Trasformata Discreta di Fourier normale ed il fatto di poter contare su una
versione veloce della stessa senza dubbio un grande vantaggio rispetto alla trasformata di
Karhunen-Love.
Ad ogni modo, la FFT ha un grande difetto che quello di produrre nella codifica dei coefficienti
complessi (cio con parti reali ed immaginarie) e quindi difficili da gestire, salvare e manipolare.
Viene in aiuto, in questo caso, la DCT cio la Trasformata Discreta del Coseno (della quale parler
di seguito) che utilizza valori reali e non numeri complessi.

Trasformata Discreta del Coseno

La Trasformata Discreta del Coseno (DCT) una trasformata unitaria ortogonale concettualmente
simile a quella di Fourier (DFT) ma con il vantaggio di utilizzare solamente numeri reali (e non
complessi come quella di Fourier).
La trasformata bidimensionale per un blocco NxN definita da:

e la sua inversa data da:

con

Come per la trasformata Discreta di Fourier, la trasformata Discreta del Coseno pu essere
rappresentata come prodotto di due trasformate monodimensionali, visto che anch'essa una
trasformata separabile.
~ DFT e DCT a confronto
In questo grafico prendo come modello una funzione base da 8x8 sia per la Trasformata Discreta di
Fourier che per la Trasformata Discreta del Coseno, onde evidenziarne il differente funzionamento:

Trasformata Discreta di Fourier (DFT)

8x8

Trasformata Discreta del Coseno (DCT)

Dato che la funzione coseno reale e pari cos(x) = cos(-x) ed il segnale in ingresso anch'esso
reale, la trasformata Discreta del Coseno inversa genera una funzione pari periodica in 2N,
considerando N la lunghezza della sequenza del segnale originale.
La trasformata Discreta di Fourier inversa, invece, produce un segnale ricostruito che periodico in
N.
La trasformata Discreta del Coseno, inoltre, introduce delle discontinuit molto pi lievi di quella di
Fourier e gli errori di ricostruzione ai bordi dei blocchi sono pi piccoli, di conseguenza gli artefatti
da compressione (blocking) sono meno pesanti di quelli della trasformata Discreta di Fourier.

Dall'illustrazione facile notare come la DFT sia periodica in N e la DCT sia periodica in 2N.
Il che significa che, nella DFT, ci sono delle discontinuit tra N ed N nei punti di bordo che sono
invece evitate nella DCT.
Per quanto concerne i segnali altamente correlati, la DCT ha dei risultati di codifica molto simili
alla trasformata di Karhunen-Love.
Ad ogni modo, a differenza di quest'ultima, le funzioni di base della DCT non sono dipendenti dai
dati in ingresso, favorendone cos, ancora una volta, l'utilizzo.

La DCT, inoltre, cos come la DFT, ha una versione veloce chiamata Trasformata Discreta del
Coseno Veloce.
La versione veloce riduce i calcoli aritmetici per una trasformata monodimensionale per un
vettore di lunghezza N a solo NlogN, esattamente come per la trasformata Discreta di Fourier
Veloce.
Grazie a tutte queste peculiarit, la Trasformata Discreta del Coseno diventata la trasformata di
riferimento per codifiche come il JPEG, l'H.264 e l'MPEG-2 nel quale la DCT bidimensionale viene
effettuata su blocchi da 8x8 ed in seguito viene effettuata una quantizzazione dei suoi coefficienti.
Per quanto riguarda l'H.264 AVC, per, questi non si serve solamente della DCT, bens esegue una
seconda passata per mezzo di un'altra trasformata: la trasformata di Walsh-Hadamard,
che illustrer di seguito.

Trasformata di Walsh-Hadamard

La trasformata di Walsh-Hadamard una trasformata unitaria ed ortogonale.

una trasformata separabile e la sua trasformata ed inversa monodimensionali per un vettore x
di lunghezza 2^m sono definite da:

dove la matrice Hm rappresenta la funzione di base della WHT.

La matrice Hm una matrice di Hadamard da 2^m x 2^m, ovvero una matrice quadrata i cui valori
di ingresso possono essere sia +1 che -1 e le cui righe sono reciprocamente ortogonali ed data da:

in cui 1 su radice di due il fattore normalizzante.

La trasformata di Walsh-Hadamard, cos come le precedenti due, possiede una sua versione
veloce, chiamata Trasformata di Walsh-Hadamard Veloce.
Cos come per le altre sopraelencate, la versione veloce di questa trasformata pu ridurre il
numero di operazioni aritmetiche per una trasformata monodimensionale da N^2 a NlogN.
La trasformata di Walsh-Hadamard lavora con matrici puramente reali, contenendo valori di +1 e
-1; cos facendo, le operazioni che deve compiere sono limitate a calcoli molto semplici e,
soprattutto per la sua versione veloce, la trasformata col pi basso livello di complessit.
Ad ogni modo, proprio per la semplicit dei calcoli che effettua, la sua capacit di compressione
altrettanto modesta, per questo il suo utilizzo autonomo pressoch nullo nel campo della codifica
video, ma come ho detto prima molto importante in quanto viene associata alla DCT per poter
ottenere una miglior compressione nel codec H.264 AVC.

Trasformata Discreta di Wavelet

La trasformata Discreta di Wavelet una trasformata unitaria, ortogonale e separabile che di solito
applicata all'intero dato in ingresso e non a dei piccoli blocchi come invece accadeva per le
trasformate viste in precedenza.
La DWT di un segnale in ingresso x eseguita passandolo attraverso vari filtri.
Per prima cosa, il segnale in entrata decomposto usando un filtro passa basso, ovvero un filtro che
passa le basse frequenze ed attenua le alte frequenze, dopodich viene processato da un filtro passa
alto che passa le alte frequenze ed attenua le basse frequenze.
Tale operazione effettuata utilizzando:

dove ylow and yhigh sono rispettivamente i coefficienti di banda passa basso e passa alto.
I filtri g ed h devono essere in stretto rapporto tra loro per poter dividere il segnale in ingresso in
due bande, formando cos un filtro di quadratura a specchio:
dove f la frequenza.
Tale propriet assicura che non ci sia alcuna perdita di informazioni durante il processo di
decomposizione.
Con l'operazione di filtraggio passa basso e passa alto, met delle frequenze del segnale sono
rimosse in entrambe le bande.
In questo modo, possibile utilizzare il teorema di campionamento:
se una funzione x(f) contiene frequenze che sono pi piccole di B hertz, allora determinata dando
le sue ordinate ad una serie di punti distanziati 1/(2B) secondi.
Met dei campioni possono essere tagliati e l'output dei due filtri (g ed h) pu essere
sotto-campionato per due. Tale operazione data da:

Dopo questo processo, la maggior parte dell'energia generalmente concentrata nella banda passa
basso.
Per poter aumentare la frequenza di risoluzione in questa banda, possono essere eseguite pi
decomposizioni, ripetendo l'operazione di sopra.
Per un segnale in ingresso monodimensionale, le applicazioni successive dei filtri sull'output passa
basso risultano in una scomposizione dinamica, ovvero il numero di coefficienti per ogni nuova
banda bassa met del numero della scomposizione precedente.
Per un segnale in ingresso bidimensionale, il numero dei coefficienti di ogni nuova banda bassa
un quarto del numero della scomposizione precedente.
La trasformata Discreta di Wavelet ha la peculiarit di possedere coefficienti in grado di ricostruire
varie risoluzioni spaziali.
Cos come per le altre trasformate sopraelencate, la trasformata Discreta di Wavelet ha la sua
versione veloce chiamata Trasformata Discreta di Wavelet Veloce e pu eseguire una
trasformata monodimensionale per un vettore di lunghezza N in sole N operazioni aritmetiche.
Tra i pregi della Trasformata Discreta di Wavelet ci sono l'assenza di blocking come artefatto da
compressione (questo perch viene applicata all'intera immagine e non a blocchi), sfrutta la
correlazione di tutti i blocchi vicini (visto che viene applicata a tutta l'immagine) consentendo alti
livelli di compressione ed ha una decomposizione dinamica ed quindi possibile aumentare o
diminuire la risoluzione spaziale dei dati recuperati semplicemente aumentando o diminuendo il
numero dei coefficienti decodificati.
L'unico problema che processare l'intera immagine assieme invece di dividerla in blocchi richiede
un alto carico computazionale dal punto di vista dei calcoli.
La trasformata Discreta di Wavelet utilizzata nello Standard JPEG 2000 di cui parler di seguito.

2) Utilizzo delle Trasformate nei codec di codifica immagini

Al fine di esplicare l'utilizzo dei metodi di codifica all'interno dei codec video, preferibile
affrontare prima il loro impiego nei codec di codifica di immagini statiche in quanto pi semplici.
Inoltre, in questo capitolo viene rappresentato passo per passo l'utilizzo dei metodi di trasformata
visti sopra in un contesto reale e di utilizzo pratico.
2.1)

Lo Standard JPEG

Lo standard JPEG utilizza due tipi di codifica: lossy (con perdita) e lossless (privo di perdita); nel
secondo caso, inoltre, non viene effettuata una codifica tramite trasformata.
doveroso dire, comunque, che la codifica lossless molto meno efficiente in termini di
compressione rispetto a quella lossy che, per, comporta la perdita di una parte di informazione.
Non solo, non sempre detto che il metodo di compressione lossless riesca sempre a ridurre la
dimensione finale del file e potrebbero esserci casi in cui questo risulta essere addirittura pi grande
del file di partenza!
In tale caso, quindi, preferibile optare per lasciare il file originale invariato al posto di tenere
quello processato dalla codifica lossless.
Generalmente, il metodo pi utilizzato quello lossy ed proprio questo a cui dar pi importanza.
La trasformata utilizzata dal JPEG nella codifica lossy la trasformata discreta del coseno
bidimensionale, unitaria, ortogonale e separabile ed data da:

dove y(k,l) il coefficiente alle coordinate (k,l) e x(m,n) il valore di ingresso (di chroma
componente del colore e luma immagine in bianco e nero in s per s) alle coordinate (m,n).
Il JPEG utilizza dunque la Trasformata Discreta del Coseno per la sua implementazione e procede
nella codifica nel seguente modo:
1) L'immagine originale viene divisa in blocchi da 8x8.
2) Ogni blocco da 8x8 viene trasformato utilizzando un'operazione di trasformata Discreta del
Coseno bidimensionale (cio, rappresentandolo in un'opportuna base dello spazio
vettoriale); il risultato dato da 8x8 coefficienti (quindi 64) creati dalla DCT stessa.
3) Tutti i 64 coefficienti creati dalla DCT sono poi quantizzati utilizzando una specifica matrice
di quantizzazione.

4) I coefficienti DCT quantizzati vengono organizzati in una sequenza monodimensionale a

zig zag.
Grazie a questa particolare sequenza, l'encoder incontrer tutti i coefficienti DCT non nulli
del blocco il pi velocemente possibile.
Non solo, dato che tale ordine corrisponde (molto approssimativamente) ad una lista
ordinata dei coefficienti di percezione visiva, il suo impiego fa s che i coefficienti pi
importanti dal punto di vista visivo siano sempre trasmessi prima di quelli meno importanti.
Dopodich, il JPEG crea una coppia (run, level) per ogni coefficiente.
Il run la quantit di coefficienti DCT nulli che precedono i veri coefficienti che vengono
codificati nella sequenza a zig zag.
Il level la grandezza quantizzata dei coefficienti per essere codificati.
Il run ed il numero di bit utilizzati per codificare il level sono poi codificati utilizzando
la codifica di Huffman ed il level codificato utilizzando il VLI (Variable Length Integer).
Per sfruttare meglio la correlazione spaziale, i coefficienti DC di ogni blocco sono codificati
come la differenza dei blocchi DC precedente e successivo.
Il processo di decodifica altro non che l'inverso di quello di codifica: il decoder entropico
decodifica la sequenza a zig zag dei coefficienti DCT quantizzati e, dopo averli de-quantizzati,
vengono ri-trasformati in blocchi da 8x8.
Le matrici di quantizzazione non sono standardizzate, bens il JPEG suggerisce una matrice di
quantizzazione utilizzando i valori corrispondenti alle minime differenze percettive di ogni
coefficiente DCT.
Questa matrice di quantizzazione di base pu essere utilizzata per generare matrici di
quantizzazione di qualit pi bassa semplicemente moltiplicando la matrice di partenza con un certo
coefficiente di quantizzazione intero.
I processi di quantizzazione sono prevalentemente bassi per le basse frequenze
ed alti per le alte frequenze.
In questo modo, il noise di quantizzazione concentrato nelle frequenze di percezione visiva
minore ed molto importante in quanto sfrutta l'irrilevanza di segnale, ovvero evita di trasmettere
informazioni di immagine che non hanno importanza a livello percettivo.
Infine, la matrice di quantizzazione (se utilizzata) deve essere trasmessa.
Chiaramente, pi la quantizzazione marcata, pi il rapporto di compressione aumenter e pi la
qualit dell'immagine finale ricostruita sar affetta.

facilmente possibile percepire come l'immagine di sinistra, processata con una forte
quantizzazione JPEG, al costo di avere una codifica maggiore (e quindi occupare meno spazio)
introduca anche dei vistosi artefatti da compressione quali ad esempio il blocking, il blur (sfocatura)

ed il banding (bande di colore nel cielo invece di un gradiente uniforme di sfumatura).

Come detto precedentemente, i blocchi vengono processati dal quantizzatore che effettua un
taglio di parte dell'informazione nella codifica lossy.
Ebbene, il quantizzatore rimuover per prime le alte frequenze poich sono meno importanti dal
punto di vista percettivo rispetto alle basse frequenze.
inoltre doveroso aggiungere che, per quanto riguarda il JPEG (ma tanti altri standard utilizzano lo
stesso approccio) al momento del processo di DCT, l'immagine viene considerata nelle sue due
componenti fondamentali, quali il luma ed il chroma.
Il luma definito come la composizione dell'immagine in scala di grigi, mentre il chroma la sua
componente di colore.

A sinistra rappresentata l'immagine originale, mentre a destra sono rappresentate le sue

componenti di luma e chroma.
In altre parole, l'immagine e la sua componente di colore vengono separate, processate
separatamente mediante il processo sopraelencato relativo ai blocchi da 8x8 e poi ri-assemblate
per poter ricreare l'immagine finale.
L'occhio umano percepisce meglio il luma del chroma (cio l'immagine rispetto al colore), dunque,
in fase di quantizzazione, verr data pi importanza al luma e minore al chroma; in altre parole,
verranno tagliate maggiormente le frequenze relative al chroma rispetto a quelle relative al luma.
Questo perch l'occhio umano composto da coni e bastoncelli e la nostra vista affetta da tre tipi
di visione: fotopica, mesopica e scotopica.

Nella visione fotopica (molta luce), solo i coni (che sono in grado di percepire luma e chroma) sono
in funzione (immagine in alto).
Nella visione mesopica (media luce), i soli coni non sono sufficienti ad offrire una corretta visione
ed entrano in gioco i bastoncelli che, per, sono in grado di percepire solamente il luma, ma non il
chroma (immagine media).
Nella visione scotopica (scarsa luce), solo i bastoncelli sono attivi e la visione principalmente in
bianco e nero con pochissima sensibilit alle variazioni di colore (immagine in basso).
In questo caso, abbiamo dunque una differenza della variazione di colore del fiore rappresentato
sopra durante la giornata, quindi abbiamo una variazione della sua percezione nel campo del
chroma, ma non in quello del luma che resta invariato.
2.2)

Lo Standard JPEG 2000

Il JPEG 2000 venne creato attorno al 2000 con l'obiettivo di ottenere una miglior compressione a
parit di qualit rispetto allo standard precedente.
Ogni immagine pu essere codificata per intero oppure divisa in tile ovvero aree rettangolari non
sovrapposte che sono compresse indipendentemente e, talvolta, una tile pu corrispondere ad
un'intera immagine.
Per prima cosa, ogni tile (o l'intera immagine, a seconda dei casi) trasformata utilizzando la
Trasformata Discreta di Wavelet bidimensionale.
Grazie a questo processo, le immagini, dalle loro due componenti (luma e chroma),
sono scomposte in differenti livelli di risoluzione.
Tali livelli sono effettuati su sotto bande popolate dai coefficienti della Trasformata di Wavelet che
descrivono le caratteristiche di frequenza delle aree locali di ogni componente dell'immagine.
lecito ricordare che la Trasformata Discreta di Wavelet pu essere irreversibile (metodo di
default) o reversibile.

Ad ogni modo, dopo il processo di trasformata, i coefficienti sono sottoposti ad una quantizzazione
scalare uniforme, sfruttando una zona morta prefissata attorno all'origine.
La dimensione del passo di quantizzazione consentita per sotto-bande, ad ogni modo,
il JPEG 2000 non definisce alcun metodo particolare per il passo di quantizzazione,
quindi possibile utilizzare svariati metodi a proprio piacimento.
Questo fatto pu tornare molto comodo in quanto possibile aggiustarlo in base all'importanza
visiva dei coefficienti di sotto-banda; in altre parole possibile utilizzare un passo di quantizzazione
pi grande per i coefficienti meno importanti dal puro punto di vista di qualit visiva
ed un passo pi piccolo per quelli pi importanti.

Dopo la quantizzazione, ogni sotto-banda della scomposizione di trasformata divisa in un blocco

rettangolare non sovrapposto chiamato blocco di codifica e la codifica entropica effettuata
indipendentemente su ognuno di essi, bitplane per bitplane.

I bitplane sono array binari rappresentanti un blocco di codifica dal suo bit pi significativo
a quello meno significativo.
Ogni bitplane codificato con una codifica adattiva binaria basata sul contesto in modo da ottenere
un bit-stream molto complesso per ogni blocco.
Ogni bit-stream viene poi organizzato in pacchetti.
Ogni pacchetto pu essere interpretato come un incremento di qualit per un livello di risoluzione in
una locazione spaziale.
Questi pacchetti vengono poi raggruppati in strati dove ogni strato pu essere interpretato come un
incremento di qualit per l'intera immagine a risoluzione completa.

I vantaggi del JPEG 2000 rispetto al JPEG si possono notare maggiormente a bitrate molto bassi
poich il JPEG 2000 non soffre del blocking.

Questo perch, dato che il JPEG utilizza la DCT che calcola ogni blocco di pixel indipendentemente
(e pu quindi esserci blocking), la Trasformata di Wavelet (per il procedimento visto sopra) analizza
l'intera immagine (o una tile).
Di seguito, sono riportati alcuni esempi di codifica JPEG contro il JPEG 2000 a bassi bitrate.
possibile notare la qualit visiva sensibilmente maggiore in quest'ultimo standard.

Ad ogni modo, proprio per la differenza delle due trasformate utilizzate, il vantaggio del JPEG 2000
diventa pressoch nullo ad alti bitrate: per immagini di 0.25bpp il peso di quella in JPEG 2000 del
53% minore, mentre per immagini a 1.00bpp pi piccolo solo del 18%.

 possibile dunque notare come, in immagini con un bitrate relativamente alto, la differenza
percettiva sia molto minore.
Non solo, la decodifica del JPEG 2000 comporta anche una maggiore complessit rispetto a quella
del JPEG.
2.3)

Lo standard GIF

Analizzando i due standard precedenti stato introdotto il termine lossless (privo di perdita)
senza per prestare particolare attenzione a questo metodo di codifica.
Analizzando lo standard GIF basato su una codifica lossless possibile andare a vedere nel
dettaglio tale tipo di codifica ed analizzare i pregi ed i difetti comparandola ai due tipi di codifica
lossy (con perdita) introdotti con gli standard JPEG e JPEG 2000.
Prima di cominciare, per, doveroso ricordare che lo standard GIF ha subito due aggiornamenti di
versione, ovvero il GIF87a ed il GIF89a (utilizzato per lo pi per le animazioni) e la versione
utilizzata ricavabile dai caratteri ASCII dei primi 6 byte del file codificato.
Seppur lo standard GIF utilizzi una codifica lossless basata su un algoritmo di compressione
lossless universale ideato da Lempel, Ziv e Welch e che prende il nome da tali (LZW), durante il
processo di conversione di un'immagine in GIF ci pu essere una sostanziale perdita di qualit
e di informazioni.
Questo perch la codifica GIF associa ad ogni pixel un numero di bit che va da 1 ad 8 ed associa,
tramite questi, un massimo di 256 diversi possibili colori ed ogni pixel potr assumere uno tra
questi 256 possibili colori.

Algoritmo di Huffman e quello di Lempel Ziv Welch

Come stato elencato sopra, lo standard di codifica GIF utilizza l'algoritmo LZW, tuttavia,
necessario analizzare anche l'algoritmo di Huffman in quanto quello di LZW dipende da esso.
Supponiamo che la fonte in ingresso mandi una sequenza di simboli di un alfabeto.
Tale alfabeto pu essere un testo oppure una sequenza di bit corrispondente ad un'immagine digitale
od anche un video.
Di base, un codice mappato in simboli e parole di codice.
Il motivo per cui mappato che preferibile adattare il messaggio in una forma che pu essere
manipolata (processata), salvata e trasmessa tramite i canali di comunicazione e le parole di codice
fatte di bit (zero ed uno) sono un modo efficiente per farlo.
Ad esempio, se volessimo comunicare delle lettere dell'alfabeto quali A, B, C, D per indicare i
livelli di efficienza energetica di una determinata marca di frigoriferi, utilizzeremmo 1 per A, 01 per
B, 000 per C e 001 per D.
Se volessimo poi mandare una sequenza di lettere tipo DCAAABCB possiamo mandare un unico
messaggio che sar 0010001110100001 e sar il ricevitore a decodificarlo per poter ottenere tali
lettere.

Nel processo di decodifica, dunque, il decodificatore andr a cercare le appropriate sotto-stringhe

contigue non sovrapposte del messaggio ricevuto nel codice condiviso e nella source.
Una propriet molto utile che un codice dovrebbe possedere che un simbolo corrispondente ad
una parola di codice ricevuta pu essere decodificato appena la parola di codice corrispondente
ricevuta; in tal caso si parla di codice istantaneo.
L'esempio che ho riportato prima proprio un codice istantaneo.
Il motivo che se il ricevitore ha gi decodificato la sequenza e, successivamente,
riceve nuovamente 1, sa gi che il simbolo corrispondente sar per forza A.
Se riceve uno 0, allora aspetter il bit successivo e, se questo un 1, allora sa che il simbolo B,
mentre se un altro 0, sar ancora incapace di sapere quale simbolo ed aspetter ancora una volta
quello successivo ed allora sapr per certo quale lettera sar: 0 dar C mentre 1 dar D.
Per quanto riguarda invece i codici non istantanei, questi sono pi difficili da decodificare.
Ad esempio, prendiamo la solita lista A, B, C, D ed assegniamo 0 ad A, 01 a B, 011 a C ed 111 a D.
In questo modo, abbiamo un codice non istantaneo e, se riceviamo una stringa del tipo 01111101,
non siamo in grado di decodificare il primo simbolo come A semplicemente ricevendo il primo 0.
Difatti, non possiamo essere sicuri che il primo simbolo sia A poich potrebbe anche essere B.
Di conseguenza, si deve aspettare la fine della trasmissione della sequenza per cominciare a
decodificare ed, in questo caso, la sequenza decodificata BDB.
Questo codice preso in esempio unicamente decodificabile, ma non sempre cos con i codici non
istantanei, cosa che invece non accade nei codici istantanei che sono tutti unicamente decodificabili.
Un esempio di un codice non istantaneo non unicamente decodificabile pu essere il seguente:
A con 0, B con 1, C con 01 e D con 11.
Con questo codice possono esistere diverse sequenze di bit che non mappano un unico simbolo;
ad esempio, 01 potrebbe essere AB oppure solo C.
Ad ogni modo, dato che la maggior parte delle codifiche lossless fanno utilizzo di codici istantanei,
mi limiter ad analizzare quest'ultimi.
Un modo conveniente per visualizzare i codici il metodo dell'albero di codice.
Nell'esempio, riporto l'albero di codice per la sequenza A con 10, B con 0, C con 110 e D con 111.

In generale, un albero di codice un albero binario con tre simboli ai nodi e le cui estremit sono
0 o 1 a significare l'encoding.
Per trovare l'encoding di un simbolo, il ricevitore deve semplicemente percorrere il percorso che va
dall'inizio dell'albero fino alla lettera desiderata.
Ad esempio, partiremo dall'alto e ci sposteremo a sinistra, trovando B (0).
Oppure, partiremo dall'alto, scenderemo di una posizione e troveremo 1, poi ci sposteremo a sinistra
e troveremo 0, quindi 10 ovvero A e cos via.
necessario aggiungere un'altra definizione prima di andare a parlare dell'algoritmo di Huffman ed
quella della lunghezza di codice aspettata.
Dati N simboli, con simboli i che si presentano con probabilit p con i, se abbiamo un codice il cui
simbolo i ha lunghezza l con i, nell'albero di codice (ovvero la parola di codice lunga l con i bit) la
lunghezza di codice aspettata sar:

In generale, i codici con una piccola lunghezza di codice aspettata sono utili perch consentono
di comprimere i messaggi, consegnandoli senza alcuna perdita di informazione (lossless),
ma consumando comunque meno bit.
Diremo quindi che la lunghezza L debba essere pi corta possibile, in quanto pi possibile
comprimere tali dati senza perdita, meglio .
L'albero di codice corrispondente ci d la mappatura ottimale tra i simboli e le parole di codice e,
solitamente, non unico.
stato dimostrato inoltre che la lunghezza di codice aspettata di ogni codice decodificabile non pu
essere pi piccola dell'entropia, H, della sottostante probabilit di distribuzione tra i simboli.
stato inoltre dimostrata l'esistenza di codici che raggiungono l'entropia asintoticamente come la
lunghezza di codice dei messaggi si approssima all'infinito.
Inoltre, un codice ottimale deve avere una lunghezza di codice aspettata che concordi con l'entropia
per i lunghi messaggi.
Tenendo conto di tutto quello esplicato sopra, ora possibile andare ad introdurre due metodi di
codifica: il primo metodo, quello di Huffman, ottimale per codici istantanei quando le probabilit
dei vari simboli sono note, i simboli sono indipendenti ed identicamente distribuiti con tali
probabilit e la mappatura ristretta ad un simbolo per simbolo.
Il secondo, l'algoritmo LZW, adotta l'attuale distribuzione di simboli nel messaggio,
non rifacendosi ad alcuna conoscenza della probabilit dei simboli.

La Codifica di Huffman:

La codifica di Huffman effettua un encoding efficiente per una lista di simboli che devono essere
trasmessi quando sappiamo la probabilit di un dato messaggio.
Tornando ad analizzare l'albero di codici analizzato sopra, possibile notare come i simboli pi
probabili (ad esempio B) siano pi vicini all'inizio dell'albero e quindi hanno una codifica pi corta,
mentre quelli meno probabili (tipo C o D) sono pi distanti ed hanno una codifica pi lunga.
David Huffman utilizz questa osservazione per realizzare un algoritmo di decodifica ad albero
per un codice di lunghezza variabile ottimale.
Quello che Huffman voleva fare era creare un albero di decodifica dal basso verso l'alto
che cominciasse con i simboli meno probabili.
In entrata all'algoritmo abbiamo dunque un set di simboli e le loro rispettive probabilit di
occorrenza.
In uscita, abbiamo un albero di codifica dal quale possibile leggere la parola chiave
corrispondente ad ogni simbolo.
1) Ingresso: un set di S tuple. Ogni tupla consiste in un simbolo di messaggio e la sua
probabilit associata.
Esempio: S{(0.333, A), (0.5, B), (0.083,C), (0.083, D)}
2) Vengono poi rimosse da S le due tuple con la probabilit pi bassa. Poi, i due simboli delle
tuple rimosse vengono combinati per formare una nuova tupla (che rappresenta un nodo
interno dell'albero di codici). Viene poi computata la probabilit di questa nuova tupla
aggiungendo le due probabilit dalle tuple.
Questa nuova tupla viene in seguito aggiunta ad S.
Per far chiarezza, diciamo che se S ha N tuple all'inizio, ora ne ha N 1 poich due tuple
erano state rimosse e ne stata aggiunta nuovamente una sola).
Esempio: S{(0.333, A), (0.5, B), (0.167,C D)}
3) Viene poi ripetuta la fase due finch S contiene una sola tupla.

Esempio: S{(0.5, B), (0.5, A (C D))}

S{(1.0, B (A (C D)))}

Il risultato dunque un albero di codice che rappresenta un codice di lunghezza variabile per i dati
simboli e probabilit.
La codifica di Huffman d risultati migliori quando alcuni simboli sono sostanzialmente pi
probabili di altri.
Se tutti i simboli sono equiprobabili, allora tutte le parole di codice saranno approssimativamente
della stessa lunghezza.
Per quanto concerne le propriet della codifica di Huffman, mi limiter ad elencarne alcune,
senza per dimostrarle formalmente.
Non unicit: Banalmente, dato che 0/1 parti di ogni coppia di rami in un albero di codice possono
essere invertiti, ci sono diversi encoding che hanno la stessa lunghezza aspettata. Difatti, potrebbero
esserci diversi codici ottimali per un dato set di probabilit di simboli e, a seconda di quanti legami
sono spezzati, la codifica di Huffman pu produrre diversi alberi di codice non isomorfi, ovvero
alberi di codice che sembrano strutturalmente diversi.
Ad esempio, se prendiamo sei simboli le cui probabilit sono , , 1/8, 1/8, 1/8, otterremo i
seguenti alberi di codice (entrambi validi):

Ottimizzazione: La codifica di Huffman ottimizzata nel senso che non ci sono codici con una
lunghezza aspettata minore quando ristretti a dei codici istantanei ed i messaggi occorrono in una
forma ideale in una probabilit di distribuzione conosciuta.
In ogni albero di codice ottimale per un codice senza prefisso, ogni nodo pu avere due figli o non
averne.
Per dimostrarlo, supponiamo che un albero di codice ottimale abbia un nodo con un figlio.
Se prendiamo quel nodo e lo muoviamo in su di un livello al suo padre, avremo ridotto la lunghezza
di codice aspettata, lasciando il codice ancora decodificabile.
In questo caso, allora, significa che l'albero di codice di partenza non era un albero di codice
ottimale.
Nell'albero di codice di una codifica di Huffman, nessun nodo ha esattamente un figlio.

Anche questa proposizione ovvia, in quanto, come detto sopra nei 3 punti della codifica di
Huffman, abbiamo sempre combinato i due nodi con la probabilit pi bassa in un singolo nodo,
il che significa che nell'albero di codifica, ogni nodo interno deriva da due nodi combinati assieme.
Esiste un codice ottimale in cui i due simboli meno probabili hanno la lunghezza pi lunga e sono
fratelli, ovvero le loro parole di codice differiscono esattamente di un solo bit, l'ultimo.
Supponiamo che z sia il simbolo meno probabile.
Se non alla massima profondit nell'albero di codice ottimale, allora qualche altro simbolo
(chiamiamolo s) deve essere alla massima profondit.
Tuttavia, dato che p con z minore di p con s, se scambiassimo z ed s nell'albero di codice,
finiremmo con un codice con una lunghezza aspettata pi piccola.
Dunque, z deve avere una parola di codice lunga almeno quanto ogni altra parola di codice.
Ora, il simbolo z deve avere un fratello nell'albero di codice ottimale (per quanto detto sopra)
e lo chiameremo x. Diciamo inoltre che y il simbolo con la seconda probabilit pi bassa,
ovvero px py pz.
Se px = py, allora la proposizione sopraelencata dimostrata.
Se cambiamo x con y nell'albero di codice, avremo y fratello di z.
La lunghezza di codice aspettata di quest'albero di codice non pi grande dell'albero di codice
ottimale prima del cambio perch p con x pi grande di p con y,
il che prova la proposizione sopraelencata.
La codifica di Huffman produce un albero di codice la cui lunghezza aspettata ottimale quando
ristretto ad una codifica simbolo per simbolo con simboli in forma ottimale e con una
probabilit di distribuzione conosciuta.
Facciamo s che i simboli siano x1, x2, . . . , xn1, xn e facciamo s che le rispettive probabilit di
occorrenza siano p1 p2 . . . pn1 pn.
Da quanto detto sopra, esiste un albero di codice ottimale in cui xn1 e xn hanno la lunghezza
maggiore e sono fratelli.
Ipotesi induttiva: presupponiamo che la codifica di Huffman produca un albero di codice ottimale
con un input di n 1 simboli con associate probabilit di occorrenza.
Facciamo s che Hn sia il costo dell'albero di codice generato dalla codifica di Huffman
negli n simboli x1, x2, . . . , xn.
Poi, Hn = Hn1 + pn1 + pn, dove Hn1 il costo aspettato dell'albero di codice generato dalla codifica
di Huffman su n 1 simboli in ingresso x1, x2, . . . xn2, xn1,n
con delle probabilit p1, p2, . . . , pn2, (pn1 + pn).
Dall'ipotesi induttiva: Hn1 = Ln1, il costo aspettato per l'albero di codice ottimale su n 1 simboli.
Inoltre, per quanto detto sopra, esiste un albero di codice ottimale su n simboli
per cui Ln = Ln1 + (pn1 + pn).
Dunque, esiste un albero di codice ottimale il cui costo aspettato, Ln, uguale al costo aspettato, Hn,
della codifica di Huffman su n simboli.

Codifica di Huffman con simboli raggruppati: Supponiamo che la codifica di Huffman per dei dati
simboli produca un codice con una lunghezza aspettata di un certo tot.
La domanda che lecito porsi : possiamo utilizzare la codifica di Huffman per avvicinarci
all'entropia?
Un approccio potrebbe essere quello di raggruppare i simboli in dei meta-simboli pi grandi
ed encodare quest'ultimi.
Consideriamo allora di encodare coppie di simboli, triple di simboli, quadruple di simboli e cos via.
possibile quindi avvicinarsi all'entropia aumentando il numero di simboli encodati per volta,
ma al costo di aumentare anche la complessit di codifica e decodifica.
Tale approccio ha comunque due problemi di base: il primo che bisogna sapere la probabilit
di ogni simbolo, il secondo che bisogna presuppone che la probabilit di ogni simbolo sia
indipendente ed equamente distribuita.
Ad ogni modo, nella realt delle cose, la probabilit dei simboli cambia messaggio per messaggio o,
alcune volte, addirittura nel mezzo di uno stesso messaggio.
Dunque, sarebbe opportuno creare un encoding a lunghezza variabile adattivo
che tiene in considerazione il contenuto di ogni messaggio, ma la cosa bella che tale encoding
esiste gi ed proprio l'algoritmo LZW che analizzer di seguito!
Per poter esplicare meglio il problema, andiamo ad analizzare il problema di rappresentare
digitalmente e trasmettere i caratteri di un libro (per esempio).
L'approccio pi semplice sarebbe quello di analizzare tale libro e di fare una stima della probabilit
della ricorrenza di diverse lettere dell'alfabeto, dopodich trattare ogni lettera come simbolo ed
applicare la codifica di Huffman per comprimere il tutto.
Questo metodo assolutamente legittimo e funzionante,
tuttavia permette di avere solo un leggero guadagno in termini di compressione.
Questo perch la probabilit con cui una lettera compare non sempre la stessa.
Ad esempio, possiamo fare una stima dell'utilizzo delle vocali e dare loro pi importanza
per poi andare a fare un elenco della ricorrenza delle consonanti, ma pu capitare che,
in una determinata frase, alcuni consonanti catalogate come meno importanti
possano comparire pi volte.
Inoltre, tornando all'inizio del nostro approccio, abbiamo detto di aver voluto scegliere come
simboli le lettere, tuttavia, a seconda del contesto analizzato,
avremmo addirittura potuto scegliere le parole.
Dunque, un metodo che si adatti al materiale che deve essere compresso
pu portare vantaggi significativi.
Un approccio di codifica adattiva quello di utilizzare la doppia passata: nel primo passo si effettua
il conteggio del numero di volte in cui ogni simbolo compare, dopodich viene utilizzato
tale conteggio per sviluppare una codifica di Huffman adatta a quel tipo di file.
Ovviamente, possibile analizzare anche coppie di simboli o triple di simboli od anche quadruple
di simboli (e cos via) a seconda del livello di raggruppamento scelto.
Per quanto concerne la seconda passata, viene effettuato l'encoding vero e proprio utilizzando
la codifica di Huffman personalizzata.
Ad ogni modo, anche cos facendo non si raggiunge ancora la massima efficienza.
Il fatto che, a prescindere dal livello di raggruppamento scelto, non ci sar mai una codifica
ottimale per i gruppi di grandezza diversa (siano questi pi grandi o pi piccoli).
Inoltre, se le probabilit di un simbolo cambia radicalmente in un certo punto del file,
una codifica di Huffman fatta in questo modo risulter comunque non essere ottimale.
Un altro approccio di codifica adattiva proprio quello utilizzato dalla LZW.
Appena il messaggio da codificare processato, l'algoritmo di codifica LZW crea una tabella di
stringhe (arbitrariamente lunga) che mappa le sequenze di simboli in un index di N-bit.

La tabella di stringhe ha 2^N voci in entrata ed il codice trasmesso pu essere utilizzato dal decoder
come index della tabella di stringhe per poter ricostruire la sequenza di simboli originale.
L'algoritmo sviluppato in modo che la tabella di stringhe possa essere ricostruita dal decoder in
base alle informazioni nello stream encodato; in altre parole, la tabella di stringhe non mai
trasmessa ed proprio questo il principale vantaggio della codifica LZW.
Quando si encoda un byte stream (ovvero una stringa contigua di 8bit), le prime 2^8 (256) voci in
entrata alla tabella di stringhe (numerate da 0 a 255) sono inizializzate a contenere
tutte le possibili sequenze ad un byte.
Le altre voci in entrata saranno compilate appena il byte stream sar processato.
Il procedimento di codifica semplice e si divide in varie fasi.
Per prima cosa, vengono accumulati byte di messaggio finch le sequenze accumulate compaiono in
qualche voce in ingresso della tabella di stringhe.
Ad un certo punto, l'appending tra il byte successivo (chiamiamolo b) con la sequenza accumulata
(chiamiamola S) creer una sequenza S+b che non pi nella tabella di stringhe.
L'encoder poi proceder trasmettendo il codice di N-bit per la sequenza S, aggiunger una nuova
voce in ingresso nella tabella di stringhe per S+b (se la tabella piena al momento dell'aggiunta
della nuova voce in ingresso, prima di aggiungerla) ed infine resetta S
per poter contenere solo il byte b.
Questo processo viene ripetuto finch non vengono consumati tutti i byte;
a quel punto l'encoder esegue la trasmissione finale del codice di N-bit per la sequenza S corrente.
Notiamo dunque come, per ogni trasmissione fatta dall'encoder,
questi crea una nuova voce di ingresso nella tabella di stringhe.
Il decoder, dunque, in grado di capire quali siano le nuove voci in ingresso
non appena riceve il rispettivo codice di N-bit.
Con una tavola di stringhe duplicata costruita dal decoder man mano che l'algoritmo procede,
possibile risalire al messaggio d'origine: basta usare il codice di N-bit ricevuto come index nella
tavola di stringhe del decoder.
2.4)

Lo standard PNG

Come ultimo standard della codifica delle immagini, proceder ad analizzare nel dettaglio il PNG
in quanto uno degli standard pi diffusi per la codifica delle immagini fisse in modo lossless.
Lo standard PNG venne ideato proprio come sostituto del GIF e ne conserva alcune funzionalit
quali le immagini indexate con un massimo di 256 colori, la possibilit di leggere e scrivere file in
maniera seriale, la possibilit di elaborare le immagini in maniera immediata appena ricevute (come
quando si clicca un link) per poi procedere ad un successivo incremento della qualit, la possibilit
di marcare parti di immagini come trasparenti, la possibilit di salvare all'interno del file di
immagine stesso dei commenti ed ovviamente, come gi detto, il fatto di essere lossless.
Oltre a queste precedenti possibilit, il PNG introduce anche alcune importanti innovazioni quali
immagini con chroma fino a 48 bit per pixel, mentre le immagini con solo luma sono possibili fino
a 16 bit per pixel; un alpha channel completo per una gestione migliore della trasparenza,
informazioni sulla gamma dell'immagine (che supporta la corretta riproduzione dell'immagine con
luminosit e contrasto riprodotti correttamente a prescindere dalla macchina utilizzata per
riprodurre l'immagine), un affidabile autocontrollo per individuare file corrotti
ed una rappresentazione iniziale pi veloce nei display progressivi.

Rappresentazione dei dati

Tutti gli interi che richiedono pi di un byte devono essere ordinati con quelli pi significativi prima
e quelli meno significativi dopo in discendente ordine di importanza.

Il bit pi alto (di valore 128) di un byte numerato bit 7, mentre il bit pi basso (di valore 1)
numerato bit 0.
I valori sono unsigned a meno che non sia esplicitato diversamente;
in caso di valori signed, questi sono rappresentati in notazione complemento a due.
In caso di valori unsigned, interi da 4 byte sono limitati al range da 0 a 2^31 -1 per compatibilit,
mentre per quelli signed, gli interi da 4 byte sono limitati al range da -(2^31 1) a 2^31 1 per
compatibilit.

Valori dei Colori

Le immagini possono essere rappresentate sia con solo il luma,

sia con il chroma in RGB (red, green, blue).
In caso di immagini a colori, questi possono essere rappresentati con informazioni di colore
calibrate (se il cHRM presente) o non calibrate (se il cHRM assente).
Il range dei valori di colore va da zero (che rappresenta il nero) alla massima intensit al massimo
valore per la stessa profondit (considerando il valore massimo di una data profondit come
2^profondit -1 e non 2^profondit).
I valori dei dati non sono necessariamente proporzionali all'intensit luminosa;
il gAMA specifica la relazione tra i valori dei dati e l'intensit del display in output.
I dati in ingresso con una precisione non direttamente supportata dal PNG vengono scalati
alla massima profondit di bit pi vicina supportata.
Il processo di scalatura reversibile e non implica perdita di dati,
inoltre riduce il numero di casi che i decoder devono affrontare.

Layout delle immagini

Concettualmente, un'immagine PNG un array rettangolare di pixel, con i pixel che appaiono da
sinistra verso destra ad ogni scansione di linea e tali scansioni avvengono dall'alto verso il basso.
La dimensione di ogni pixel determinata dalla profondit di bit (bit depth).
Ci sono tre tipi di pixel supportati:
1) Pixel a Colori Indexati: ovvero pixel rappresentati da un singolo dato che nell'index in una
tavolozza fornita. La profondit di bit dell'immagine determina il numero massimo di
tavolozze in entrata, ma non la precisione di colore delle stesse.
2) Pixel in bianco e nero: ovvero rappresentati da un singolo dato in un livello in bianco e nero,
dove zero nero ed il massimo valore possibile per la profondit di bit bianco.
3) Pixel TrueColor: ovvero rappresentati da tre dati quali rosso (zero equivale a nero ed il
massimo al rosso), verde (zero equivale a nero ed il massimo al verde) e blu (zero equivale a
nero ed il massimo al blu). La profondit di bit specifica la grandezza di ogni dato,
non la grandezza totale dei pixel.
A seconda della necessit, i pixel in bianco e nero e quelli in TrueColor possono includere anche
dati alpha dei quali parler pi approfonditamente in seguito.
I pixel sono sempre raggruppati in scanline senza alcun spreco di bit tra i pixel.
I pixel pi piccoli di un byte sono salvati in byte con il pixel pi a sinistra nei bit di ordine superiore
di un byte, quelli pi a destra nei bit di ordine minore.
Le profondit di bit permesse ed i tipi di pixel sono ristretti,
in modo da rendere il salvataggio semplice ed efficiente.

Quando i pixel hanno meno di 8 bit e la larghezza delle linee di scansione non divisibile per il
numero di pixel per byte, i bit di ordine minore nell'ultimo byte di ogni linea di scansione vengono
buttati ed il loro contenuto non specificato.
Un byte filter-type aggiuntivo aggiunto all'inizio di ogni linea di scansione e questo non viene
considerato parte dei dati dell'immagine, ma incluso nello stream di dati inviato in fase di
compressione.

Il canale alpha

Il canale alpha rappresenta le informazioni di trasparenza per pixel e pu essere incluso sia nella
modalit in bianco e nero, sia in quella turecolor, come gi detto sopra.
Il valore zero dell'alpha rappresenta una trasparenza completa, mentre un valore di 2^bitdepth 1
rappresenta un pixel completamente opaco.
Valori intermedi, dunque, indicano pixel parzialmente trasparenti che possono essere combinati con
un'immagine di sfondo per comporre poi l'immagine finale.
Il canale alpha pu essere incluso con immagini che hanno sia 8 che 16 bit per dato,
ma non con immagini che ne hanno meno di 8.
I dati del canale alpha sono rappresentati con la stessa profondit di bit utilizzata per i dati
delle immagini ed i dati del canale alpha per ogni pixel sono salvati immediatamente dopo i dati
dei pixel in bianco e nero o in RGB.
I valori di colore per ogni pixel non sono intaccati dal valore alpha assegnato allo stesso
e questa regola viene chiamata non associativit.
Ad ogni modo, il controllo della trasparenza comunque possibile anche senza un canale alpha
completo: in un'immagine a colori indexati, il valore alpha pu essere definito per ogni tavolozza in
entrata, mentre per le immagini in bianco e nero e per quelle in truecolor, il valore di un singolo
pixel pu essere identificato come trasparente.
Tutto questo gestito dal canale alpha o dai tRNS ausiliari, tuttavia, se nessuno dei due presente,
i pixel vengono trattati come completamente opachi.

Filtraggio

Lo standard PNG consente di filtrare l'immagine prima di comprimerla in modo da aumentarne la

compressibilit senza per perdere informazioni (visto che, appunto, ripeto, il PNG lossless).
Lo standard PNG ha definito vari e diversi algoritmi per il filtraggio, inclusa la modalit none
che indica nessuno e quindi non filtra l'immagine.
L'algoritmo di filtraggio specificato per ogni linea di scansione da un byte filter-type che precede
la linea di scansione filtrata nel datastream pre-compresso.
L'encoder pu passare da un filtro ad un altro ed il metodo secondo il quale vengono scelti
lasciato all'encoder stesso.

Ordinamento dei dati interlacciati

Un'immagine salvata con lo standard PNG pu essere salvata sia progressiva che interlacciata ed i
decoder sono in grado di leggere quest'ultima in ogni occasione,
indipendentemente dalla tipologia del display di riferimento.
Con il metodo di interlacciamento di tipo 0, i pixel sono salvati in sequenza da sinistra verso destra
e le linee di scansione sono in sequenza dall'alto verso il basso.
Con il metodo di interlacciamento di tipo 1, conosciuto come metodo di Adam M. Costello (nome
dell'autore), si hanno sette diverse passi sull'immagine: ogni passo trasmette un subset dei pixel
nell'immagine.

Il passo in cui ogni pixel trasmesso viene definito replicando il seguente pattern 8 per 8,
cominciando da in alto a sinistra.

In ogni passo, i pixel selezionati sono trasmessi da sinistra verso destra in una linea di scansione
e le scansioni sono selezionate sequenzialmente dall'alto verso il basso.
Ad esempio, il secondo passo contiene i pixel 4, 12, 20 e cos via delle linee di scansione 0, 8, 16
(contando da 0,0 in alto a sinistra); l'ultimo passo contiene invece 1, 3, 5 ecc.
I dati di ogni passo sono disposti come se fossero un'immagine completa delle dimensioni
appropriate; ad esempio, se un'immagine completa di 16 per 16 pixel, allora il terzo passo conterr
due linee di scansione, ognuna contenente quattro pixel.
Quando i pixel hanno meno di 8 bit, ogni linea di scansione portata a raggiungere un intero
numero di byte.
Il filtraggio fatto sull'immagine ridotta nel solito modo e viene trasmesso un byte filter-type
ad ogni linea di scansione.
Da notare, comunque, che l'ordine di trasmissione definito in modo che tutte le linee di scansione
trasmesse in un passo abbiano lo stesso numero di pixel,
necessario per il corretto utilizzo di alcuni filtri.
Se per un'immagine contiene meno di cinque righe o meno di cinque colonne,
alcuni passi saranno completamente vuoti.
Gli encoder ed i decoder devono essere in grado di gestire anche questa particolare occasione e,
nello specifico, i byte filter-type sono associati solo con le linee di scansione non vuote, per cui,
in un passo vuoto, non ci sar alcun byte filter-type.

Correzione della Gamma

Le immagini codificate secondo lo standard PNG possono specificare, mediante il gAMA,

le informazioni relative alla rappresentazione in output.
I programmi per la riproduzione sono fortemente incoraggiati ad utilizzare queste informazioni in
modo da consentire una corretta riproduzione all'utente che sta guardando l'immagine, tuttavia,
la correzione di gamma non applicata al canale alpha.
Per applicazioni di alto livello, l'esatta chromaticit dei dati RGB pu essere specificata tramite il
cHRM, consentendo una riproduzione pi accurata rispetto a quella offerta dalla sola correzione di
gamma normale.

Stringhe di testo

Un file PNG in grado di salvare porzioni di testo associate all'immagine, quali, ad esempio,
la descrizione delle immagini o informazioni relative al copyright.
Il set di caratteri consigliato l'ISO/IEC 8859-1 (Latin-1) e, in caso le informazioni vengano scritte
in un set di caratteri diverso, c' il rischio che i diversi decoder (nelle diverse piattaforme)
le interpretino in vario modo e potrebbero non essere in grado di riprodurle.

Firma

Lo standard di codifica PNG include una firma che viene sempre riportata dai primi otto byte di
ogni file di immagine quali: 137 80 78 71 13 10 26 10 ed indica che il file un'immagine
PNG e consiste in una serie di dati che cominciano con un dato IHDR e finiscono con un dato
IEND.

Layout dei dati

Ogni dato consiste in quattro parti quali:

1) lunghezza: in intero di 4 byte unsigned che indica il numero di byte nel campo dati del dato.
La lunghezza conta solo il campo dati e non se stessa, il dato stesso per intero od il CRC e
zero considerato un valore accettabile. Ad ogni modo, anche se molti decoder trattano la
lunghezza come unsigned, il suo valore non deve eccedere 2^31 1 byte.
2) Tipo di dati: un codice di 4 byte. Per convenienza nella descrizione e nell'esaminazione dei
file PNG, i tipi di codice sono ristretti per consentire maiuscole e minuscole in lettere ASCII
(A-Z, a-z, oppure 65-90, 97-122 decimali). Ad ogni modo, encoder e decoder devono
trattare i codici come valori binari fissati e non come stringhe di caratteri.
3) Dati del tipo di dato: sono byte riferiti al tipo di dato, se ci sono. Nel caso non ci siano,
questo campo pu tranquillamente assumere lunghezza zero.
4) CRC: il Cyclic Redunancy Check (Controllo di Ridondanza Ciclico) fatto da 4 byte ed
calcolato nei byte precedenti, incluso il codice del tipo di dati ed i dati del tipo di dato,
ma senza includere il campo della lunghezza ed sempre presente, anche per i dati vuoti.

Convenzione di nomenclatura dei dati

I dati del tipo di dati sono assegnati in modo che il decoder possa determinare alcune propriet di
tali dati anche senza riconoscere il tipo.
Queste regole sono state introdotte per questione di sicurezza e flessibilit del formato PNG,
consentendo ai decoder di decidere il da farsi quando incontrano un dato a loro sconosciuto;
ad ogni modo, le regole di nomenclatura di solito non sono contemplate quando il decoder
riconosce il tipo di dato.
Per trasmettere le propriet dei dati, sono utilizzati quattro bit del codice del tipo,
ovvero 5 bit (di valore 32) di ogni byte.
Questa scelta significa che un umano in grado di leggere le propriet assegnate a seconda del caso
in cui ogni lettera del codice del tipo sia maiuscola (il quinto bit 0) o minuscola (il quinto bit 1).
Ad ogni modo, i decoder dovrebbero testare le propriet di un dato sconosciuto testando
numericamente i bit specificati; testare se un carattere maiuscolo o minuscolo del tutto
inefficiente e persino incorretto in alcuni casi.
del tutto insignificante sapere che i bit di propriet sono parte integrante del nome dei dati e che
sono sistemati per ogni tipo di dato.
Dunque, BLOB e bLOb sarebbero tipi di dato non relazionati e non lo stesso dato
con propriet differenti.
I decoder devono riconoscere i codici del tipo di dato eseguendo semplicemente un confronto a 4
byte.

Per quanto riguarda la semantica dei bit di propriet, si dividono in:

1) Bit ausiliari: cinque bit del primo byte.
0 (maiuscolo) ovvero critico, 1 (minuscolo) ovvero ausiliario.
I dati che non sono strettamente necessari a riprodurre significativamente il contenuto del
file, sono considerati dati ausiliari. Un decoder che incontra un dato sconosciuto nel quale
il bit ausiliario 1, pu tranquillamente ignorarlo e procedere alla riproduzione
dell'immagine. Un esempio di dato critico l'header (IHDR).
2) Bit privati: cinque bit del secondo byte.
0 (maiuscolo) ovvero pubblico, 1 (minuscolo) ovvero privato.
Un dato pubblico parte delle specifiche PNG oppure registrato nella lista dei tipi di dato
pubblici speciali. Le applicazioni possono anche definire dati privati (non registrati) per i
propri scopi. I nomi dei dati privati devono avere la seconda lettera minuscola, mentre a
quelli pubblici saranno sempre assegnati nomi con la seconda lettera maiuscola. Da notare
che i decoder non hanno bisogno di testare i bit di propriet dei dati privati, visto che non
hanno un significato funzionale; una semplice convenzione assicurarsi che i nomi dei dati
pubblici e privati siano corretti.
3) Bit di riserva: cinque bit del terzo byte.
0 (maiuscolo) in conformit con la corrente versione PNG.
I bit di riserva possono essere utilizzati nel caso in cui la terza lettera del nome del dato sia
riservata per una possibile espansione futura e tutti i nomi devono avere una terza lettera
maiuscola.
4) Bit sicuri da copiare: cinque bit del quarto byte
0 (maiuscolo) ovvero non sicuro da copiare, 1 (minuscolo) ovvero sicuro da copiare.
Questo bit di propriet non importante al puro scopo della decodifica, ma necessario per
gli editor dei PNG (cio programmi che modificano i PNG) in quanto definisce la corretta
gestione dei dati non riconosciuti in un file che stato modificato.
Se sicuro da copiare (1), il dato potrebbe essere copiato nel file PNG modificato sia che
il software ne riconosca il tipo o meno.
Se insicuro da copiare (0), significa che il dato dipendente dai dati dell'immagine. Se il
programma ha fatto qualche cambiamento ad alcuni dati critici, allora i dati insicuri da
copiare non devono essere copiati nel PNG di output.
L'editor dei PNG sempre autorizzato a copiare tutti i dati non riconosciuti se ha solamente
aggiunto, rimosso, modificato o riordinato i dati ausiliari.
Se invece l'editor non in grado di riconoscere un dato critico, dovrebbe riportare un errore
ed interrompere la modifica del file PNG.

L'algoritmo CRC

I dati CRC sono calcolati utilizzando un metodo CRC standard ed il polinomiale utilizzato :
x^32 + x^26 +x^23 +x^22 +x^16 +x^12 +x^11 +x^10 + x^8 +x^7 +x^5 + x^4 + x^2 +x+1

Il registro CRC a 32bit inizializzato a tutti 1 e poi ogni dato da ogni byte viene processato
dall'ultimo bit significativo (1) a quello pi significativo (128).
Quando tutti i dati sono processati, il registro CRC invertito (viene preso il suo stesso
complemento) e tale valore viene poi trasmesso.
Per poterlo separare in byte ed ordinare, l'ultimo bit significativo del CRC a 32bit definito per
essere il coefficiente dell' x^31esima termine.

Header dell'immagine IHDR

Parlando della semantica dei bit di propriet (in particolare dei bit ausiliari critici) ho utilizzato come
esempio l'header senza per specificare cosa fosse nel dettaglio.
L'IHDR deve apparire per primo e contiene 4 byte per la larghezza, 4 byte per l'altezza, 1 byte per la
profondit di bit, 1 byte per il tipo di colore, 1 byte per il metodo di compressione, 1 byte per il metodo di
filtraggio ed 1 byte per il metodo di interlacciamento.
Larghezza ed altezza indicano le dimensioni dell'immagine in pixel e sono date da interi di 4 byte; zero viene
considerato un valore non valido ed il massimo di 2^31 1 in modo da evitare problemi con le lingue

che hanno difficolt a gestire i valori di 4 byte unsigned.

La profondit di bit data da un intero di un byte ed indica il numero dei bit per index di tavolozza
(e non per pixel) e pu assumere i valori 1, 2, 4, 8 e 16, anche se non tutti sono consentiti per tutti i
tipi di colore.
Il tipo di colore dato da un intero di 1 byte e descrive l'interpretazione del dato dell'immagine.
I codici del tipo di colore rappresentano somme dei seguenti valori: 1 (tavolozza utilizzata), 2
(colore utilizzato), 4 (canale alpha utilizzato) e pu assumere valori 0, 2, 3, 4 e 6.
Le restrizioni della profondit di colore per ogni tipo di colore sono imposte per semplificare
l'implementazione e per proibire combinazioni che non sono ben comprimibili.
I decoder devono supportare tutte le combinazioni valide di profondit di bit e tipo di colore ovvero:
tipo di colore 0, profondit di bit consentite (1, 2, 4, 8, 16) ogni pixel in bianco e nero;
tipo di colore 2, profondit di bit consentite (8, 16) ogni pixel una tripla RGB;
tipo di colore 3, profondit di bit consentite (1, 2, 4, 8) ogni pixel un indice della tavolozza e
compaiono i dati PLTE;
tipo di colore 4, profondit di bit consentite (8, 16) ogni pixel in bianco e nero, seguito dal
canale alpha;
tipo di colore 6, profondit di bit consentite (8, 16) ogni pixel una tripla RGB, seguito dal canale
alpha.
I dati di profondit sono gli stessi di quelli della profondit di bit, eccetto nel caso del tipo di colore
3, in cui i dati della profondit sono sempre 8 bit.
Il metodo di compressione un intero di un byte che indica il metodo utilizzato per comprimere i
dati dell'immagine.
Attualmente, solo il metodo di compressione 0 definito.
Tutte le immagini compresse con lo standard PNG devono seguire questo schema.
Il campo del metodo di compressione fornito per cambi futuri dello stesso standard ed i decoder
devono controllare questo byte e riportare un errore se ha un codice non riconosciuto.
Proseguendo al campo successivo, il metodo di filtraggio dato da un intero di 1 byte che indica il
metodo di pre-processing applicato al dato dell'immagine prima della compressione.
Attualmente, solo il metodo 0 (filtraggio adattivo con cinque tipi di filtri base) definito.
Per quanto riguarda il campo del metodo di compressione, i decoder devono controllare questo byte
e riportare un errore se ha un codice non riconosciuto.
Il metodo di interlacciamento, infine, indicato da un intero di 1 byte che riferisce l'ordine dei dati
dell'immagine; attualmente sono definiti due valori: 0 (non interlacciato) oppure 1 (interlacciamento
Adam7).
Ad ogni modo, parler dell'ordine dei dati interlacciati pi avanti.

Tavolozze PLTE

I dati PLTE contengono da 1 a 256 tavolozze in entrata, ognuna delle quali ha una serie di tre byte
RGB: Red (1 byte; 0 equivale a nero, 255 a rosso), Green (1 byte; 0 equivale a nero, 255 a verde),
Blue (1 byte; 0 equivale a nero, 255 a blu), come gi detto prima.
Il numero di valori in entrata determinato dalla lunghezza dei dati e questa risulta in errore se non
divisibile per 3.
Questo tipo di dato deve comparire nel tipo di colore 3 e pu apparire per i tipi 2 e 6, ma non deve
comparire per i tipi 0 e 4.
Se questo dato compare, deve precedere il primo dato IDAT e non pu esserci pi di un dato PLTE.
Per il tipo di colore 3 (colori indexati), richiesto il PLTE.
Il primo valore in entrata nel PLTE riferito dal valore del pixel 0, il secondo dal valore del pixel 1
e cos via.
Il numero di tavolozze in entrata non deve eccedere il range rappresentabile dalla profondit di bit
dell'immagine, ma possibile averne meno.
Per i tipi di colore 2 (truecolor) e 6 (truecolor con il canale alpha), i dati PLTE sono opzionali.
Se presenti, dichiarano un set di colori suggerito da 1 a 256 col quale l'immagine truecolor pu
essere quantizzata se l'utente non in grado di riprodurre l'immagine truecolor direttamente.
Se non sono presenti n il PLTE, n l'sPLT, l'utente dovr scegliere i colori da solo,
ma preferibile che tale scelta venga fatta dall'encoder.
doveroso ricordare che la tavolozza utilizza 8 bit (1 byte) a prescindere dalla profondit di bit
dell'immagine.

Dati dell'immagine IDAT

I dati IDAT vengono creati a partire dalle linee di scansione dell'immagine rappresentate come
descritto precedentemente e la dimensione finale di questi dati determinata dai campi dell'IHDR.
Dopodich, i dati dell'immagine vengono filtrati secondo il metodo di filtraggio specificato sempre
dall'IHDR.
Infine, i dati dell'immagine sottoposta a filtraggio vengono compressi utilizzando il metodo di
compressione specificato, ancora, dall'IHDR.
I dati IDAT contengono lo stream di dati di output e l'algoritmo di compressione.
Per leggere i dati dell'immagine, il processo l'inverso.
Possono esserci pi dati IDAT e, in quel caso, appaiono consecutivamente e lo stream di dati
compresso sar la concatenazione di tutti i dati IDAT.
Gli encoder possono dividere lo stream di dati compresso in dati IDAT a piacimento: sono
consentiti pi dati IDAT in modo che gli encoder possano lavorare in una certa quantit di memoria
e, generalmente, la dimensione dei dati corrisponde al buffer size dell'encoder.
doveroso ricordare che i bordi dei dati IDAT non hanno importanza a livello semantico e possono
collocarsi in qualsiasi punto dello steam di dati compresso.
Un file PNG nel quale ogni dato IDAT contiene solo un byte di dati valido, seppur rappresenti un
incredibile spreco di spazio; allo stesso modo, anche i dati IDAT di lunghezza zero sono validi,
seppur rappresentino uno spreco ancora pi grande!

Il dato IEND

L'IEND deve apparire per ultimo in quanto indica la fine dello stream di dati del file PNG ed i suoi
campi sono vuoti.

Dati ausiliari

Tutti i dati ausiliari sono opzionali, nel senso che gli encoder non hanno l'obbligo di scriverli ed i
decoder possono tranquillamente ignorarli.
Ad ogni modo, gli encoder sono invitati a scrivere dei dati ausiliari standard quando possibile
ed i decoder sono invitati ad interpretare questi dati quando possibile.
Parler dei vari dati ausiliari possibili di seguito, ad ogni modo, l'ordine in cui ne parlo
non necessariamente l'ordine in cui compaiono in uno stream di dati PNG.

Informazioni ausiliarie di trasparenza

Questo dato contiene le informazioni nello stream di dati che non include un canale alpha completo.

tRNS

Il tRNS specifica che l'immagine utilizza una trasparenza semplice: i valori alpha associati alle
tavolozze in entrata (per le immagini a colori indexati) o i colori trasparenti singoli (per le immagini
in bianco e nero e quelle truecolor).
Anche se una trasparenza semplice non efficiente come un canale alpha completo,
questa richiede meno spazio ed in molti casi sufficiente.
Per il tipo di colore 3 (colori indexati), il tRNS contiene una serie di valori alpha di un byte
corrispondenti ai valori in entrata del PLTE.
Ogni entrata indica che pixel dell'indice di tavolozza corrispondente devono essere trattati come se
avessero il valore alpha specifico ed i valori alpha sono come quelli in un canale alpha completo ad
8 bit: 0 completamente trasparente, 255 completamente opaco,
a prescindere dalla profondit di bit dell'immagine.
Il tRNS non deve contenere pi valori alpha dei dati di tavolozze in entrata, tuttavia ne pu
contenere di meno; in quest'ultimo caso, tutti i valori rimanenti vengono considerati 255.
Per il tipo di colore 0 (bianco e nero), il tRNS contiene un solo valore di livello di grigio, del tipo:
Gray: 2 bytes, range 0. . .2^profondit di bit 1

Se la profondit di bit minore di 16, vengono utilizzati gli ultimi bit significativi e gli altri sono 0.
Pixel del livello di grigio specificato sono trattati come trasparenti (cio come valore alpha 0),
mentre tutti gli altri pixel sono trattati come completamente opachi (valore alpha 2^profondit di bit 1).
Il tRNS proibito per i tipi di colore 4 e 6, visto che presente un canale alpha completo.
Quando si ha a che fare con bianchi e neri o dati truecolor da 16bit, importante comparare
entrambi i byte dei valori dei campioni (sample) per determinare se un pixel trasparente.
Ultimo appunto che il tRNS, quando presente, deve precedere il primo dato IDAT e seguire il
PLTE, se presente.

Informazioni dello spazio di colore

Questi dati sono relativi alla riproduzione dei campioni (sample) dell'immagine.

Gamma dell'immagine gAMA

I dati gAMA specificano la relazione tra i campioni (sample) dell'immagine e l'intensit di

riproduzione in output desiderata: sample = light out^gamma

sample e light_out sono normalizzati nel range 0.0 (intensit minima), 1.0 (intensit massima).
Dunque:

Il valore encodato come un intero unsigned di 4 byte.

Il valore di gamma non ha effetto sugli alpha sample,
che sono sempre una frazione lineare dell'opacit completa.
Se l'encoder non sa il valore di gamma dell'immagine, dovrebbe evitare di scrivere il dato gAMA.
Tecnicamente, l'intensit di riproduzione in output desiderata ancora troppo vago come dato.
In altre parole, si devono specificare le condizioni di riproduzione in cui desiderato.
Per il gAMA ci sono condizioni di riproduzione di referenza delle specifiche sRGB.
Aggiustare per le diverse condizioni di riproduzione un procedimento complesso
e di solito gestito dal CMS (Color Management System).
Se non viene fatto alcun aggiustamento, l'errore, di solito, comunque piccolo.
Le applicazioni che richiedono un'alta fedelt di colore potrebbero voler utilizzare un dato sRGB
o un dato iCCP ed analizzer entrambi pi avanti.
Se il gAMA presente, deve precedere il primo dato IDAT e deve anche precedere il PLTE,
se presente.
Se sono presenti l'sRGB o l'iCCP, il dato gAMA viene sovrascritto.

Cromaticit primarie cHRM

Le applicazioni che richiedono una specifica di colore indipendente dal device in un file PNG
possono utilizzare i dati cHRM per specificare le 1931 cromaticit CIE x, y di rosso, verde e blu
primarie utilizzate nell'immagine ed i punti bianchi di riferimento e contiene:

Ogni valore encodato come intero unsigned di 4 byte.

Il cHRM consentito in tutti i file PNG, sebbene sia di poca importanza
per le immagini in bianco e nero.
Se l'encoder non conosce i valori di cromaticit, dovrebbe evitare di scrivere il cHRM
e l'assenza di tale dato indica che i colori primari dell'immagine sono dipendenti dal device.
Se presente, il cHRM deve precedere il primo IDAT ed il PLTE, se presente.
Se presenti e riconosciuti, i dati sRGB e iCCP sovrascrivono il dato cHRM.

sRGB, Spazio di colore standard per l'RGB

Se l'sRGB presente, i sample dell'immagine sono conformi allo spazio di colore sRGB
e dovrebbero essere riprodotti utilizzando un rendering specifico.
L'sRGB contiene un dato di rendering che definisce 4 valori: percettivo, relativo alla colorimetrica,
della saturazione e colorimetrico assoluto.
Quello percettivo per le immagini per le quali preferibile un buon adattamento della gamma per
il device di output al costo di un accuratezza colorimetrica, come nelle fotografie.

Quello relativo alla colorimetrica per le immagini che richiedono che l'apparenza dei colori sia
fedele, tipo i loghi.
Quello della saturazione per le immagini per le quali preferibile preservare la saturazione al
costo di un accuratezza in hue e luminosit, come nei grafici.
Quello colorimetrico assoluto per le immagini per le quali necessario preservare
una colorimetrica assoluta.
Un'applicazione che scrive un dato sRGB dovrebbe anche scriverne uno gAMA (e, magari, anche
un cHRM) per compatibilit con le applicazioni che non sono in grado di utilizzare l'sRGB stesso.
Se presente, le applicazioni che riconoscono l'sRGB e sono capaci della gestione del colore,
ignorano i dati relativi a gAMA e cHRM.
Tale dato deve precedere il primo dato IDAT ed il PLTE, se presente.
Ricordo infine che l'sRGB e l'iCCP non dovrebbero comparire insieme.

iCCP, profilo ICC integrato

Se il dato iCCP presente, i sample dell'immagine sono conformi allo spazio di colore e vengono
rappresentate dal profilo ICC integrato.
Lo spazio di colore del profilo ICC dev'essere RGB per le immagini del tipo di colore 2, 3 e 6
o in bianco e nero per il tipo di colore 0 e 4 (scala di grigi).
L'iCCP contiene il nome del profilo (una stringa di caratteri da 1 a 79 byte),
il null separator di 1 byte, il metodo di compressione di 1 byte ed il profilo compresso di n byte.
Il nome del profilo pu essere qualsiasi cosa; case sensitive e soggetto alle stesse restrizioni delle
parole chiave in un dato di tipo testo di cui ho parlato sopra.
Un'applicazione che scrive l'iCCP, dovrebbe anche scrivere il gAMA ed il cHRM che approssimano
la funzione del profilo ICC, per compatibilit con le applicazioni che non sono in grado di utilizzare
l'iCCP.
Se presente, le applicazioni che sono in grado di riconoscere l'iCCP e che sono capaci della gestione
del colore dovrebbero ignorare il gAMA ed il cHRM, tuttavia, se non sono in grado di effettuare
una gestione del colore completa, dovrebbero utilizzare il gAMA ed il cHRM, se presenti.
Un file dovrebbe contenere al massimo un profilo integrato, che sia esplicito come l'iCCP
o implicito come l'sRGB.
Se l'iCCP presente, deve precedere il primo IDAT ed il PLTE, se presente.

Informazioni testuali (tEXt, zTXt e iTXt)

I dati tEXt, zTXt e iTXt sono utilizzati per le informazioni testuali associate con l'immagine,
ma mi riferir a tutti e tre come informazioni testuali per semplicit,
dopodich li analizzer separatamente.
Ogni dato di testo contiene come primo campo una parola chiave che indica il tipo di informazione
rappresentata dalla stringa di testo.
Le parole chiave riportate di seguito sono predefinite e dovrebbero essere utilizzate,
quando opportuno:
Title: titolo o nome dell'immagine.
Author: nome dell'autore dell'immagine.
Description: descrizione dell'immagine.
Copyright: copyright dell'immagine.
Creation Time: quando stata creata l'immagine originale.
Software: il software utilizzato per creare l'immagine.

Disclaimer: disclaimer.
Warning: avvertimento sulla natura del contenuto.
Source: il device utilizzato per creare l'immagine.
Comment: commenti vari (conversione dal commento dei GIF).
1) tEXt
Le informazioni testuali che l'encoder vuole registrare assieme all'immagine sono salvate nei dati
tEXt.
Ogni dato tEXt contiene una parola chiave, una stringa di testo nel formato:

La parola chiave e la stringa di testo sono separate da uno zero byte (null) e n la prima n la
seconda possono contenere valori nulli; da notare che la stringa di testo, invece, non terminata da
un null.
2) zTXt
Anche lo zTXt contiene dati di tipo testuale cos come il tEXt ma trae vantaggio dalla
compressione.
Per tutto il resto, sono semanticamente equivalenti, ma comunque consigliato lo zTXt se si ha a
che fare con lunghe porzioni di testo.
Lo zTXt contiene:

La parola chiave ed il null separator sono esattamente gli stessi del tEXt,
dunque la parola chiave non compressa.
Il metodo di compressione identifica il metodo utilizzato e l'unico valore attualmente definito
lo zero ed il byte del metodo di compressione infine seguito da uno stream di dati compresso.
3) iTXt
L'iTXt semanticamente equivalente al tEXt ed allo zTXt, ma il testo scritto in UTF-8 Unicode
invece del Latin-1 utilizzato dai precedenti due e contiene:

La parola chiave la stessa dello zTXt.

Il compression flag 0 per il testo non compresso ed 1 per il testo compresso e solo il campo text
pu essere compresso.

Per il testo non compresso, l'encoder dovrebbe impostare il metodo di compressione a zero
ed il decoder dovrebbe semplicemente ignorarlo.
Il language tag indica il linguaggio umano utilizzato per tradurre la parola chiave ed il testo.
A differenza della parola chiave, il language tag case sensitive.
una stringa di caratteri ASCII del tipo (it, en-us, en-uk, cn ecc.).
Se il language tag vuoto, la lingua non specificata.
Il campo translated keyword ed il campo text utilizzano entrambi l'UTF-8 Unicode ed il testo,
a differenza degli altri, non ha un null separator.

bKGD, colore di background

Il dato bKGD specifica un colore di background di default per rappresentare l'immagine, tuttavia,
gli utenti non sono tenuti a seguire tale dato e possono tranquillamente scegliere di utilizzare un
background differente.
Per il tipo di colore 3 (colori indexati), il bKGD contiene un index di tavolozza di 1 byte ed altro
non che il valore del colore da utilizzare come background.
Per i tipi di colore 0 e 4 (bianco e nero con e senza alpha), il bKGD contiene:
Se la profondit di bit dell'immagine minore di 16, vengono utilizzati i bit meno significativi e gli
altri sono 0.
Tale valore altro non che il livello di grigio utilizzato come background.
Per i tipi di colore 2 e 6 (truecolor con e senza alpha), il bKGD contiene:

Se la profondit di bit dell'immagine minore di 16, vengono utilizzati i bit meno significativi e gli
altri sono 0.
Tale valore altro non che il colore RGB da utilizzare come background.
Quando presente, il dato bKGD deve precedere il primo dato IDAT e deve seguire il PLTE, se
presente.

pHYs, dimensioni fisiche del pixel

I dati di pHYs specificano la dimensione dei pixel desiderata o l'aspect ratio per la riproduzione
dell'immagine.

E per lo unit specifier sono definiti i seguenti valori:

Quando lo unit specifier 0, il pHYs definisce solamente l'aspect ratio,

mentre la grandezza dei pixel rimane non specificata.
Se questo dato ausiliario non presente, i pixel vengono trattati come quadrati
e la dimensione fisica di ogni pixel rimane sconosciuta.
Se presente, invece, deve precedere il primo dato IDAT.

sBIT, bit significativi

L'sBIT utilizzato per memorizzare il numero originale di bit significativi, consentendo cos ai
decoder di recuperare il dato originale in maniera lossless anche se tale dato ha un sample depth
non direttamente supportato dal PNG.
Per il tipo di colore 0 (bianco e nero), l'sBIT contiene un singolo byte
che indica il numero di bit significativi nel dato di origine.
Per il tipo di colore 2 (truecolor), l'sBIT contiene tre byte che indicano il numero di bit significativi
nel dato di origine rispettivamente per i canali rosso, verde e blu.
Per il tipo di colore 3 (colori indexati), l'sBIT contiene tre byte che indicano il numero di bit
significativi nel dato di origine rispettivamente per i componenti rosso, verde e blu
dei valori in entrata della tavolozza.
Per il tipo di colore 4 (bianco e nero con canale alpha), l'sBIT contiene due byte che indicano il
numero di bit significativi rispettivamente nel dato di origine in bianco e nero
e nel dato di origine in alpha.
Per il tipo di colore 6 (truecolor con canale alpha), l'sBIT contiene quattro byte che indicano il
numero di bit significativi rispettivamente nel dato di origine rosso, verde e blu
e nel dato di origine in alpha.
Ogni profondit specificata nell'sBIT deve essere pi grande di zero e minore o uguale alla
profondit del sample (che 8 per le immagini a colori indexati e la cui profondit data dall'IHDR
per gli altri tipi di colore).
Se l'sBIT presente, deve precedere il primo dato IDAT ed il PLTE, se presente.

sPLT, tavolozza suggerita

Questo dato pu essere utilizzato per suggerire una tavolozza ridotta da usare quando il device che
deve riprodurre l'immagine non capace di riprodurre il range completo di colori
presenti nella stessa.
Se presente, fornisce un set di colori consigliato con l'alpha e le informazioni di frequenza
da poter usare per costruire una tavolozza ridotta con cui l'immagine PNG pu essere quantizzata.
Questo dato contiene una stringa di testo terminata da un null che d il nome alla tavolozza ed un
sample depth da un byte, seguito da una serie di valori in ingresso alla tavolozza ed ogni serie di 6
o 10 byte contiene cinque interi unsigned:

Il decoder determina il numero dei valori in entrata dalla lunghezza dei dati rimanenti dopo il byte
del sample depth e, se non divisibile per 6 (se il sample depth dell'sPLT 8) o 10 (se il sample
dapth dell'sPLT 16), allora risulter in un errore.
I valori in ingresso devono comparire in ordine decrescente di frequenza e non richiesto
che debbano essere utilizzati nell'immagine, n che siano tutti differenti.
Il nome della tavolozza (palette name) pu essere un nome qualsiasi che si riferisce alla tavolozza e
pu essere utile alle persone per scegliere la giusta tavolozza suggerita quando ce ne sono diverse
nel file PNG.
Il nome della tavolozza case sensitive ed soggetto alle stesse restrizioni delle parole chiave.

Il sample depth dell'sPLT dev'essere 8 o 16.

I sample rosso, verde, blu ed alpha sono possono essere di uno o di due byte ciascuno,
a seconda del sample depth dell'sPLT, a prescindere dalla profondit di bit dell'immagine.
I sample del colore non sono pre-moltiplicati dall'alpha,
tantomeno sono pre-compositi su alcun background.
Un valore alpha di zero significa completamente trasparente, mentre un valore alpha di 255 (quando
il sample depth dell'sPLT 8) o di 65535 (quando il sample depth dell'sPLT 16)
significa completamente opaco.
I sample della tavolozza hanno gli stessi valori di gamma e cromaticit
di quelli dell'immagine PNG.
Ogni valore di frequenza proporzionale alla frazione dei pixel dell'immagine pi vicini ai valori
di ingresso della tavolozza nello spazio RGBA, prima che l'immagine sia composta
su qualche background.
L'esatto fattore di scala scelto dall'encoder, ma dovrebbe essere scelto in modo che il range dei
valori individuali riempia ragionevolmente il range da 0 a 65535.
accettabile aumentare artificialmente le frequenze per colori importanti tipo quelli del logo
di una compagnia.
Zero considerata una frequenza valida e significa che il colore meno importante o che,
se usato, usato raramente.
Ad ogni modo, quando tutte le frequenze sono zero, diventano inutili in quanto niente
pu essere dedotto sulle frequenze attuali dei colori.
L'sPLT pu essere presente in qualsiasi tipo di colore nel PNG.
Da notare che i valori in entrata dell'sPLT possono essere esterni allo spazio di colore dell'immagine
PNG; ad esempio, in un'immagine PNG in bianco e nero, i valori in entrata sPLT
probabilmente soddisfaranno R=G=B anche se non richiesto.
La stessa cosa vale se consideriamo l'alpha, difatti i valori in entrata sPLT possono avere valori
alpha non opachi anche quando l'immagine PNG non utilizza la trasparenza.
Se l'sPLT presente, deve precedere il primo dato IDAT.
Possono esserci pi dati sPLT, ma, in tal caso, devono per forza avere nomi di tavolozza diversi.

hIST, istogramma di tavolozza

Il dato hIST rappresenta la frequenza di utilizzo approssimativa di ogni colore

nella tavolozza di colori.
Un dato hIST pu comparire solo se presente il PLTE.
Se il riproduttore non in grado di provvedere a tutti i colori della tavolozza,
l'istogramma pu aiutare a decidere quale subset di colori scegliere per la riproduzione.
L'hIST contiene una serie di interi unsigned di 2 byte (16 bit).
Ci dev'essere esattamente un valore in entrata per ogni valore in entrata nel PLTE.
Ogni valore in entrata proporzionale alla frazione dei pixel nell'immagine
che hanno quell'indice di tavolozza; l'esatto fattore di scala scelto dall'encoder.
I valori in entrata dell'istogramma sono approssimati, con l'eccezione che un valore in entrata zero
specifica che il corrispondente valore in entrata della tavolozza non utilizzato nell'immagine.
richiesto che un valore in ingresso all'istogramma sia diverso da zero
se ci sono dei pixel di quel colore.
Quando la tavolozza una quantizzazione suggerita di un'immagine truecolor, l'istogramma
necessariamente approssimato, dato che il decoder potrebbe mappare i pixel ai valori in ingresso
della tavolozza diversamente rispetto a come ha fatto l'encoder;
in questo caso, non dovrebbero comparire valori in ingresso zero.
Il dato hIST, se presente, deve seguire il PLTE e deve precedere il primo dato IDAT.

tIME, data dell'ultima modifica dell'immagine

Il dato tIME fornisce la data dell'ultima modifica dell'immagine e non della creazione
dell'immagine iniziale.
Contiene 2 byte per l'anno (che completo, tipo 1993 e non '93), 1 byte per il mese (che va da 1 a
12), 1 byte per il giorno (che va da 1 a 31), 1 byte per l'ora (che va da 0 a 23), 1 byte per il minuto
(che va da 0 a 59) ed un byte per il secondo (che va da 0 a 60).
Il tempo viene generalmente indicato in UTC (Universal Time) e non nel fuso locale
e si aggiorna automaticamente ogni qual volta che l'immagine viene modificata.

Compressione diminuita/aumentata

Il metodo di compressione del PNG 0 (l'unico attualmente definito per il PNG)

specifica una compressione diminuita od aumentata con un margine di massimo 32768 byte.
La compressione diminuita una derivata LZ77 utilizzata nello zip, nel gzip, nel pkzip
ed altri programmi.
Gli stream di dati a compressione diminuita del PNG sono salvati nel formato zlib
che ha la seguente struttura:

Per il metodo di compressione del PNG 0, il compression method/flags code deve specificare il
codice di metodo 8 (compressione diminuita) ed il margine dell'LZ77
non deve essere superiore a 32768 byte.
Da notare che il numero del metodo di compressione non lo stesso del PNG:
i flag aggiuntivi non devono specificare un dizionario presente.
Il decoder PNG dev'essere in grado di decomprimere ogni stream di dati zlib valido
che soddisfi questi vincoli aggiuntivi.
Se il dato da comprimere contiene 16384 byte o meno,
l'encoder pu settare il margine arrotondando ad una potenza di 2 (minimo 256).
Cos facendo, viene diminuita la memoria richiesta non solo per l'encoding,
ma anche per il decoding, senza intaccare negativamente il rapporto di compressione.
Il dato compresso nello stream di dati zlib salvato in una serie di blocchi, ognuno dei quali pu
rappresentare un dato raw (non compresso), un dato LZ77 compresso encodato con una codifica di
Huffman fissata o un dato LZ77 compresso encodato con una codifica di Huffman personalizzata.
L'ultimo blocco identificato da un marcatore nel suo bit finale e consente al decoder
di riconoscere la fine dello stream di dati compresso.
Il check value salvato alla fine dello stream di dati zlib calcolato sui dati non compressi
rappresentati dallo stream di dati.
Da notare che l'algoritmo utilizzato non lo stesso del CRC utilizzato per il check value del PNG.
Il check value dello zlib utile pi che altro come controllo incrociato
che gli algoritmi di compressione diminuita od aumentata siano implementati correttamente.
Verificando i dati, il CRC conferisce una sicurezza abbastanza alta che il dato di immagine PNG
stato trasmesso correttamente.
In un file PNG, la concatenazione dei contenuti di tutti i dati IDAT crea uno stream di dati zlib,
come specificato sopra.
importante ricordare che i bordi tra i dati IDAT sono arbitrari e possono trovarsi ovunque nello
stream di dati zlib.

Non c' alcuna correlazione necessaria tra i bordi dei dati IDAT ed i bordi dei blocchi di
compressione diminuita; ad esempio, perfettamente possibile che il check value finale dello zlib
sia diviso tra i dati IDAT.
D'altro canto, non c' alcuna correlazione richiesta tra la struttura dei dati dell'immagine (ovvero i
bordi delle linee di scansione) ed i bordi dei blocchi di codifica diminuita o dei bordi dei dati IDAT.
Il dato dell'immagine completo rappresentato da un singolo stream di dati zlib
che salvato in alcuni numeri dei dati IDAT.
Il PNG utilizza inoltre lo stream di dati zlib per i dati iTXt, zTXt ed iCCP, dove il resto dei dati
successivi al byte del metodo di compressione uno stream di dati zlib, come specificato sopra.
A differenza del dato di immagine, tali stream di dati non sono divisi: ogni dato iTXt, zTXt o iCCP
contiene uno stream di dati zlib indipendente.

Tipi di filtri

Come gi detto varie volte sopra, l'unico metodo di filtraggio attualmente definito il metodo 0 e
questo definisce 5 tipi di filtro base numerati da 0 a 4:

Da notare che il metodo 0 nell'IHDR specifica esattamente questo set di cinque tipi di filtro.
Se il set dei tipi di filtro esteso, viene assegnato un metodo di filtraggio diverso al set esteso,
in modo che i decoder non abbiano bisogno di decomprimere i dati
per scoprire che contengono un tipo di filtro non supportato.
Ad ogni modo, tornando a noi, l'encoder pu scegliere quale di questi algoritmi di filtraggio
applicare in un procedimento linea di scansione per linea di scansione.
Nel dato dell'immagine inviato nel passo di compressione, ogni linea di scansione preceduta da un
byte del tipo di filtro che specifica l'algoritmo di filtraggio utilizzato per tale linea di scansione.
Gli algoritmi di filtraggio sono applicati ai byte (e non ai pixel), a prescindere dalla profondit di bit
o dal tipo di colore dell'immagine.
L'algoritmo di filtraggio funziona sulla sequenza di byte formata da una linea di scansione che
stata rappresentata come descritto sopra nella sezione relativa al layout delle immagini.
Se l'immagine include un canale alpha, i dati alpha sono filtrati nello stesso modo
dei dati dell'immagine.
Quando un'immagine interlacciata, ogni passo del pattern di interlacciamento
trattato come immagine indipendente per il filtraggio.
I filtri funzionano sulla sequenza di byte formata dai pixel attualmente trasmessi durante un passo
e la linea di scansione precedente quella trasmessa precedentemente nello stesso passo
e non quella adiacente nell'immagine completa.
Da notare che la sotto-immagine trasmessa in un passo sempre rettangolare,
ma ha larghezza e/o altezza minori rispetto all'immagine completa.
Inoltre, il filtraggio non applicabile quando questa sottoimmagine vuota.
Per tutti i filtri, il byte da sinistra al primo pixel nella linea di scansione
dev'essere trattato come se fosse zero.
Per i filtri che si rifanno alla linea di scansione precedente, l'intera linea di scansione precedente
dev'essere tratta come se fosse zero per la prima linea di scansione di un immagine (o per un passo
di un'immagine interlacciata).

Per fare il procedimento inverso, il decoder deve utilizzare i valori decodificati del pixel precedente
della stessa linea di scansione, il pixel immediatamente precedente al pixel corrente sulla linea
precedente ed il pixel a sinistra del pixel precedente.
Anche se alcuni tipi di filtro non si rifanno alla linea di scansione precedente, il decoder avr
comunque sempre bisogno di salvare ogni linea di scansione appena decodificata, dato che la linea
di scansione successiva potrebbe utilizzare un filtro che si rif a quest'ultima.
Il PNG non impone restrizioni su che tipo di filtro applicare ad una immagine, tuttavia,
i filtri non sono egualmente efficienti su tutti i tipi di dato.
0) Filter type 0, None
Con il None(), la linea di scansione trasmessa senza alcuna modifica;
se necessario, viene inserito solamente un byte tipo di filtro prima del dato.
1) Filter type 1, Sub
Il Sub() trasmette la differenza tra ogni byte ed il valore del byte corrispondente del pixel
precedente e viene applicata la seguente formula ad ogni byte della linea di scansione:
Sub(x) = Raw(x) Raw(x-bpp)

dove x pu assumere valori che vanno da zero

al numero di byte rappresentanti la linea di scansione, meno 1.
Il Raw() si riferisce al byte del dato raw a quel byte di posizione nella linea di scansione.
Il Bpp definito come il numero di byte per pixel completo, approssimato ad uno.
Ad esempio, per il tipo di colore 2 con una profondit di bit di 16,
il bpp uguale a 6 (3 sample, due byte per sample).
Per il tipo di colore 0 con una profondit di bit di 2, il bpp sar uguale ad 1
(per via dell'arrotondamento).
Per il tipo di colore 4 con una profondit di bit di 16, invece, il bpp sar uguale a 4
(sample in bianco e nero da due byte ed un alpha sample da 2 byte).
Da notare che questo procedimento effettuato per ogni byte, a prescindere dalla profondit di bit.
In un'immagine a 16 bit, ogni MSB predetto dall'MSB precedente ed ogni LSB dall'LSB
precedente, proprio per il modo in cui definito il bpp.
Viene utilizzato il modulo aritmetico unsigned 256 in modo che tutti i valori entrino in 8 bit
e non ci sia overflow e la sequenza dei valori Sub trasmessa come la linea di scansione filtrata.
Per effettuare invece il processo inverso del filtro Sub() dopo la decompressione,
si ha il seguente valore in output:
(modulo 256 computato), dove Raw() si riferisce al numero di byte gi decodificati.
2) Filter type 2, Up
Il filtro Up() esattamente come il Sub() eccetto per il fatto che vengono utilizzati per la predizione
i pixel immediatamente precedenti al pixel corrente e non solo quelli alla sua destra,
come accadeva invece nel Sub.
Per computare il filtro Up(), si applica la seguente formula ad ogni byte della linea di scansione:
dove x pu assumere valori che vanno da zero al numero di byte rappresentanti la linea di scansione
meno 1.
Il Raw() si riferisce al byte del dato raw a quel byte di posizione nella linea di scansione.

Il Prior(x) si riferisce ai byte non filtrati della linea di scansione precedente.

doveroso ricordare che questo viene fatto per ogni byte, a prescindere dalla profondit di bit.
Viene utilizzato anche qui il modulo aritmetico 256 unsigned, in modo che tutti i valori entrino in 8
bit e non ci sia overflow e la sequenza dei valori Up trasmessa come linea di scansione filtrata:
nella prima linea di scansione di un'immagine (o di un passo, se interlacciata),
si suppone che Prior(x) sia uguale a 0 per ogni x.
Per effettuare il processo inverso del filtro Up() dopo la decompressione,
si ha il seguente valore in output:

(modulo 256 computato), dove Prior() si riferisce ai byte decodificati della linea di scansione
precedente.
3) Filter type 3, Average
Il filtro Average() utilizza l'average (la media) dei due pixel vicini (sinistro e precedente)
per predire il valore di un pixel.
Per computare il filtro Average(), si applica la seguente formula ad ogni byte della linea di
scansione:

dove il risultato il modulo 256 computato, ma la predizione calcolata nello stesso modo
dell'encoding.
Raw() si riferisce ai due byte gi decodificati ed il Prior() si riferisce ai byte decodificati
della linea di scansione precedente.
4) Filter type 4, Paeth
Il filtro Paeth computa una semplice funzione lineare dei tre pixel vicini (sinistro, precedente,
superiore sinistro), poi sceglie come predizione il pixel vicino pi vicino al valore computato.
Per computare il filtro Paeth(), si applica la seguente formula ad ogni byte della linea di scansione:

dove x assume valori che vanno da zero

al numero di byte rappresentante la linea di scansione meno 1.
Il Raw() si riferisce al byte del dato raw a quel byte di posizione nella linea di scansione.
Il Prior() si riferisce ai byte non filtrati della linea di scansione precedente.
Il bpp definito come il numero di byte per pixel completo, approssimato ad uno,
esattamente come gi detto quando stavo trattando il Sub().
Da notare che questo fatto per ogni byte, a prescindere dalla profondit di bit
e che il modulo aritmetico unsigned 256 viene utilizzato in modo che tutti i valori entrino in 8 bit
e non ci sia overflow.
La sequenza di valori Paeth trasmessa come linea di scansione filtrata.
La funzione di PaethPredictor() definita dal seguente pseudo-codice:

I calcoli all'interno della funzione PaethPredictor() devono essere fatti in modo esatto e senza
overflow ed il modulo aritmetico 256 utilizzato solamente per la fase finale di sottrazione del
risultato della funzione dal valore di byte desiderato.
Per ogni x < 0, si considera che Raw(x) sia uguale a 0 e Prior(x) sia uguale zero.
Nella prima linea di scansione di un'immagine (o di un passo se interlacciata),
si considera che Prior(x) sia uguale a 0 per ogni x.
Per effettuare il processo inverso del filtro Paeth dopo la decompressione,
il valore in output dato da:
(modulo 256 computato), dove Raw() e Prior() si riferiscono ai byte gi decodificati
e la stessa funzione PaethPredictor() utilizzata sia dall'encoder che dal decoder.

Regole di ordinamento dei dati

Per consentire ai nuovi tipi di dato di essere aggiunti allo standard PNG, necessario porre delle
regole relative all'ordinamento degli stessi, altrimenti un programma qualsiasi che incontra un dato
sconosciuto nel file PNG, non avr idea del da farsi.
Definiamo un editor PNG un programma in grado di modificare un file PNG e che cerca di
preservare pi dati ausiliari possibile.
Due esempi di editor PNG sono un programma che aggiunge o modifica dati di testo
ed un programma che aggiunge una tavolozza suggerita ad un'immagine truecolor in PNG.
Gli editor di immagini ordinari non sono editor PNG in questo senso, perch di solito
non mantengono tutte le informazioni non riconosciute mentre leggono un'immagine.
Come esempio dei possibili problemi, consideriamo un ipotetico nuovo tipo di dato ausiliario
che sicuro da copiare che deve comparire dopo il PLTE, se presente.
Se il programma per aggiungere un PLTE suggerito non riconosce questo nuovo dato,
potrebbe inserire il PLTE nel posto sbagliato, ovvero dopo il nuovo dato!
Sarebbe possibile prevenire tale problema richiedendo agli editor PNG di cancellare tutti i dati
non riconosciuti, ma non esattamente l'approccio ottimale.
Per evitare tutto questo, sono state poste alcune restrizioni sia di comportamento degli editor,
sia sull'ordine dei dati.
Tali restrizioni sono:
1) Quando viene copiato un dato ausiliario sconosciuto non sicuro da copiare, l'editor PNG
deve evitare di muovere qualsiasi dato critico. Pu ri-allocare i dati relativi agli altri dati a
suo piacimento, ma non quelli critici. L'editor non pu aggiungere, eliminare, modificare
o riordinare i dati critici se sta preservando dati non riconosciuti non sicuri da copiare.

2) Quando viene copiato un dato ausiliario sconosciuto sicuro da copiare, l'editor PNG deve
evitare di muovere i dati da prima dell'IDAT a dopo l'IDAT (o vice versa),
ogni altra ri-allocazione permessa.
3) Quando viene copiato un dato ausiliario conosciuto, l'editor deve rispettare le regole di
ordinamento relative a quel tipo di dato.
4) Gli editor PNG devono bloccare l'editing se incontrano un tipo di dato non riconosciuto
catalogato come critico. Questo perch non possibile sapere se la modifica del file
contenente tale dato dar un file risultante corretto. A prima vista potrebbe essere
ragionevole pensare di eliminarlo semplicemente per risolvere il problema, tuttavia non
possibile farlo perch tale dato potrebbe comunque essere importante per l'interpretazione di
altri dati!
Per quanto riguarda invece l'ordinamento dei tipi di dato, si hanno due regole di base:
1) I dati non sicuri da copiare possono avere requisiti di ordinamento relativi a dati critici.
2) I dati sicuri da copiare possono avere requisiti di ordinamento relativi all'IDAT.

Comparazione con GIF e JPEG

Ora che siamo arrivati ad avere un quadro completo e dettagliato dello standard pi utilizzato per la
diffusione di immagini su internet (il PNG), il momento di tirare le somme
e compararlo al suo predecessore (il GIF) ed al suo rivale lossy (il JPEG).
Nelle immagini pi piccole, il GIF pu ottenere una compressione migliore rispetto al PNG,
tuttavia, nella maggior parte delle immagini, il GIF risulter avere una dimensione maggiore.
Il PNG, inoltre, consente una gamma di trasparenza maggiore del GIF.
Inoltre, mentre il GIF limitato ai colori indexati ad 8 bit,
il PNG consente un pi ampio raggio di profondit di colore,
incluso il 24-bit (8 bit per canale) ed il 48-bit (16 bit per canale) truecolor,
consentendo una precisione maggiore.
Non solo, considerando il canale alpha, si possono avere fino a 64 bit per pixel
(prima della compressione).
Se un'immagine viene convertita da PNG in GIF ed ha pi di 256 colori,
l'immagine risultante in GIF potrebbe soffrirne a causa della posterizzazione.
Per capirne l'effetto, prendiamo in esame la seguente immagine.
La prima ha 24 bit (quindi 16.7 milioni di colori), mentre la seconda stata ridotta a 256 colori.

 comunque doveroso ricordare che il GIF supporta nativamente le immagini animate, mentre il
PNG no. Per quanto concerne la versione animata del PNG che possibile trovare su internet,
assolutamente non ufficiale.
Infine, il PNG non supportato in maniera capillare,
basti pensare che Internet Explorer 6 lo supporta solo in parte.
Per quanto riguarda il JPEG, invece, pu produrre immagini pi piccole visto che utilizza un
metodo lossy e quindi viene tagliato via dettaglio,
oltre al fatto che il JPEG non supporta la trasparenza.

Dopo aver analizzato il PNG e dopo averlo comparato a GIF e JPEG,

posso dichiarare chiuso il capitolo relativo alla codifica delle immagini fisse
e proceder con la parte tre di questa tesi.

3.0.0) Basi della codifica video

Prima di andare a parlare dell'utilizzo delle trasformate nei codec di codifica video,
doveroso introdurre le basi della codifica video.

3.0.1) Scene video naturali

Una scena video del mondo reale (o naturale) composta da molteplici oggetti, ognuno con una
propria forma caratteristica, la propria profondit, la propria texture ed illuminazione.
I colori e la luminosit di una scena video naturale cambiano con diversi gradi di intensit tra le
scene (tono continuo).
Le caratteristiche di una scena video naturale rilevanti per la compressione includono
le caratteristiche spaziali (variazione delle texture all'interno della scena, numero e forma
degli oggetti, i colori e cos via) e le caratteristiche temporali (movimento degli oggetti,
cambiamenti nell'illuminazione, movimenti della videocamera, punto di vista e cos via).
Una scena video naturale continua sia spazialmente che temporalmente.
Rappresentare una scena visiva in forma digitale comporta fare il sampling (campionamento)
spaziale della scena reale (solitamente in una griglia rettangolare nel piano dell'immagine video)
e temporale (come una serie di immagini fisse o componenti di frame
campionate ad intervalli di tempo regolari).
Un video digitale la rappresentazione di una scena di video campionato in forma digitale.
Ogni sample spazio-temporale (elemento dell'immagine o pixel) rappresentato come un numero
od un set di numeri che descrivono il luma ed il chroma del sample.

Per ottenere un'immagine bidimensionale campionata, la videocamera concentra la proiezione

bidimensionale della scena video in un sensore, come un array CCD (Charge Coupled Devices).
Nel caso di cattura di immagine a colori, ogni componente di colore filtrata separatamente
e proiettata in un array CCD.
L'output di un array CCD un segnale video analogico,
un segnale elettrico che rappresenta un'immagine video.
Campionando il segnale in un punto in un tempo si ottiene un'immagine campionata
od un frame che ha valori definiti ad un set di punti di campionamento.
Il formato pi comune per un'immagine campionata un rettangolo
con i punti di campionamento posizionati in una griglia quadrata o rettangolare.

La figura rappresentata mostra un frame a tono continuo con due diverse griglie di campionamento.
Il campionamento si verifica ad ogni punto di intersezione sulla griglia e l'immagine campionata
pu essere ricostruita rappresentando ogni sample (campione) come un elemento quadrato
dell'immagine (pixel).
La qualit visiva dell'immagine influenzata dal numero di punti di campionamento.
Scegliere una griglia di campionamento grossolana avr l'effetto di produrre un'immagine
campionata a bassa risoluzione, mentre una griglia di campionamento efficiente (con tanti punti),
produrr un'immagine decisamente pi accurata.
Per questo test sono state utilizzate due griglie: la prima quella nera (grossolana)
e la seconda quella grigia (pi accurata), rappresentate nell'immagine soprastante.
Di seguito sono riportate le immagini campionate dalle due griglie: quella a sinistra stata
campionata dalla griglia nera, mentre quella a destra stata campionata da quella grigia.

possibile dunque notare la differenza tra le due immagini campionate

e l'efficienza della seconda griglia utilizzata (quella grigia).
Questo per quanto riguarda il campionamento spaziale, per quanto concerne invece
il campionamento temporale, un'immagine video in movimento catturata prendendo foto
rettangolari del segnale ad intervalli di tempo periodici.
Riproducendo all'indietro queste foto si ha un movimento apparente.
Un rapporto di campionamento temporale (detto anche frame rate) pi alto d un movimento
apparente pi fluido nella scena video, ma richiede anche pi campioni catturati e salvati.

Frame rate sotto i 10fps (frame per second) sono solitamente utilizzati per le comunicazioni video
a bassissimi bitrate, ma l'impressione di movimento chiaramente innaturale.
Tra i 10 ed i 20 fps, l'immagine un po' pi fluida ma si notano sempre gli scatti.
Infine, per campionamenti a 25 o 30 fps si ha un'immagine abbastanza fluida,
sebbene sia possibile comunque notare gli scatti.
Quest'ultimi fps sono stati scelti come standard per le immagini televisive,
anche se solamente con frame rate di 50 o 60 fps si ha un movimento apparente fedele alla realt.
Questo perch il video solamente una serie di immagini riprodotte, ma l'occhio umano in grado
di percepire fino a 55 fps e, di conseguenza, noter sempre un movimento innaturale
nelle immagini televisive con lo standard attuale.
Inoltre, un segnale pu essere campionato come una serie di frame completi (campionamento
progressivo) o come una sequenza di field interlacciati (campionamento interlacciato).
In una sequenza video interlacciata, met dei dati in un frame (un field)
campionata ad ogni intervallo di campionamento temporale.
Un field formato dalle linee pari e dispari all'interno di un frame video completo ed una sequenza
video interlacciata contiene una serie di field, ognuno rappresentante met dell'informazione
di un frame video completo.
Il vantaggio di questo metodo che possibile mandare il doppio delle informazioni inviate in una
sequenza video progressiva con lo stesso data rate, dando una migliore impressione di movimento.
Ad esempio, una sequenza video PAL consiste in 50 field per second (25 righe pari e 25 righe
dispari) e, in fase di riproduzione, il movimento appare pi fluido rispetto a quello della rispettiva
sequenza video a 25 fps.
Stessa cosa per l'NTSC che utilizza invece 60 field per second (30 righe pari e 30 righe dispari).
Ad ogni modo, mentre le televisioni a tubo catodico ed i pannelli ALiS plasma sono in grado di
riprodurre nativamente le sequenze video interlacciate, i moderni monitor per computer e le TV
basate sulla tecnologia LCD non lo sono.
Dunque, per poter riprodurre tali segnali, deve essere effettuato un processo di deinterlacciamento.
Il metodo di trasmissione interlacciata era stato inizialmente ideato infatti per le televisioni a tubo
catodico; il funzionamento alla base di tali televisioni avere un fascio di elettroni che colpisce dei
fosfori. Ogni pixel, una volta colpito dal fascio, conserva l'energia per un certo periodo di tempo,
per poi spegnersi pian piano.
Dunque, se supponessimo di effettuare una scansione progressiva del quadro (lo schermo del
televisore), avremmo il fascio che investe, riga dopo riga, tutti i pixel a partire dal primo in alto a
sinistra, fino all'ultimo in basso a destra.
Ebbene, cos facendo si andrebbero a creare fenomeni di sfarfallio in quanto non appena l'ultimo
pixel in basso a destra investito dal fascio di elettroni (e si accende), il primo pixel in alto a
sinistra ha ormai consumato parte dell'energia acquisita ed prossimo a spegnersi.
Per evitare tale sfarfallio e per l'adozione della tecnica del refresh rate di pari passo con la frequenza
della corrente, venne utilizzato il metodo di trasmissione interlacciato come lo conosciamo noi oggi.
La scansione del quadro viene quindi fatta in due passi: il primo passo illumina tutti i pixel,
da in alto a sinistra ad in basso a destra, delle righe dispari,
mentre il secondo effettua la stessa cosa ma con i pixel contenuti nelle righe pari.

Top Field

Bottom Field

Molteplici applicazioni video digitali hanno l'esigenza di consentire la riproduzione di video a

colori e quindi necessitano di un meccanismo di cattura e rappresentazione dell'informazione
del colore.
Un'immagine monocromatica richiede solamente un valore per indicare il luma di ogni campione
spaziale. Le immagini a colori invece richiedono almeno tre valori per pixel per rappresentare
adeguatamente il colore.
Il metodo scelto per la rappresentazione del luma e del chroma detto spazio di colore.
Il pi conosciuto spazio di colore l'RGB, nel quale il campione dell'immagine a colori
rappresentato da tre valori che indicano le relative proporzioni di Red, Green, Blue
(Rosso, Verde, Blu), i tre colori primari della luce.
Qualsiasi altro colore pu essere creato dalla combinazione di rosso, verde e blu,
variandone le proporzioni.
Lo spazio di colore RGB un ottimo spazio per la cattura delle immagini a colori e, per poterlo
utilizzare, necessario catturare l'immagine filtrando le componenti rosso, verde e blu della scena,
catturandole ciascuna con una matrice di sensori separata.
Le televisioni a tubo catodico e quelle a cristalli liquidi rappresentano le immagini RGB
illuminando separatamente le componenti di rosso, verde e blu di ogni pixel secondo l'intensit
di ogni componente e, da una distanza non eccessivamente corta, i componenti separati sono visti
come unificati e danno l'impressione del colore.
Come gi detto precedentemente per la codifica delle immagini fisse,
l'occhio umano meno sensibile al chroma (colore) rispetto che al luma (luminanza).
Nello spazio di colore RGB, i tre colori sono egualmente importanti e sono solitamente salvati alla
stessa risoluzione, ma possibile rappresentare il colore di un'immagine in maniera pi efficiente
separando le informazioni del luma da quelle del chroma e rappresentando il luma con una
risoluzione maggiore rispetto al chroma.
Lo spazio di colore YcbCr e le sue varianti (YUV) il metodo pi utilizzato
per la rappresentazione delle immagini a colori.
Y rappresenta la componente di luma e pu essere calcolato come il peso medio di rosso, verde
e blu (RGB):
dove k sono i fattori di peso.
Le informazioni di colore possono essere rappresentate come differenza di colore,
dove ogni componente di chroma la differenza tra rosso, verde o blu (RGB) ed il luma (Y):

La descrizione completa di un'immagine a colori data da Y (componente di luma) e dalle tre

differenze di colore Cb, Cr e Cg che rappresentano la differenza tra l'intensit di colore
ed il luma medio di ogni campione dell'immagine.
A primo impatto potrebbe sembrare strano poich, mentre l'RGB aveva solo le tre componenti Red,
Green e Blue, adesso abbiamo quattro componenti, ovvero una in pi.
Ebbene, Cb + Cr + Cg una costante e quindi solamente due delle tre componenti di chroma
devono essere salvate o trasmesse, visto che la terza componente pu sempre essere calcolata
dalle altre due.
Nello spazio di colore YcbCr, solo le componenti di luma (Y) e quelle di chroma blu e rosso
(Cb, Cr) sono trasmesse.
YcbCr ha un vantaggio significativo rispetto all'RGB ed che le componenti Cr e Cb possono
essere rappresentate con una risoluzione minore rispetto ad Y proprio perch, come ho detto pi

volte prima, l'occhio umano meno sensibile al chroma rispetto che al luma.
Questo riduce la quantit di dati richiesta per rappresentare le componenti di chroma
senza avere un impatto significativo sulla qualit visiva (ovvero quella percepita).
Un'immagine nativa in RGB pu inoltre essere convertita in YcbCr in modo da ridurne il peso
o i requisiti di trasmissione.
Prima di riprodurre l'immagine, di solito necessario per convertirla di nuovo in RGB.
Le equazioni per convertire un'immagine RGB in YCbCr e viceversa, sono le seguenti:

possibile notare che non c' bisogno di specificare un fattore separato kg perch abbiamo che kb +
kr + kg = 1 e che G pu essere ricavato dalla rappresentazione YcbCr sottraendo Cr e Cb da Y,
dimostrando cos che non necessario salvare o trasmettere la componente Cg.
Le tre matrici di colore pi utilizzate sono la BT.601 (utilizzata per le definizioni standard), la
BT.709 (utilizzata per le alte definizioni) e la nuova BT.2020 (utilizzata per le altissime definizioni).
Supponendo di dover convertire da YCbCr e RGB un video con la matrice BT.601, avremo,
secondo l'ITU-R, Kb = 0.114 e Kr = 0.299

Attualmente, l'H264 in grado di supportare diversi tipi di campionamento per lo spazio di colore
YCbCr, ovvero il 4:2:0, il 4:2:2 ed il 4:4:4.
4:4:4 significa che le tre componenti Y, Cb e Cr hanno la stessa risoluzione e quindi esiste un
campione di ogni componente ad ogni posizione di pixel.
I numeri indicano il rapporto di campionamento di ogni componente nella direzione orizzontale:
per ogni campione di luma ci sono 4 campioni Cb e 4 campioni Cr.
possibile quindi capire che il campionamento 4:4:4 preserva la completa fedelt
delle componenti di chroma.
Nel campionamento 4:2:2 (chiamato anche YUY2), i componenti di chroma hanno la stessa
risoluzione verticale di quelli del luma, ma met risoluzione orizzontale.
I numeri 4:2:2, infatti, significano che per ogni 4 campioni di luma nella direzione orizzontale,
ci sono due campioni Cb e due campioni Cr.

Il 4:2:2 utilizzato per la riproduzione ad alta qualit ed spesso utilizzato per i file inviati tra gli
studi di produzione, ma il pi popolare il 4:2:0.
Nel 4:2:0 (detto anche YV12), Cb e Cr (chroma) hanno met risoluzione orizzontale
e met risoluzione verticale di Y (luma).
Il termine 4:2:0 potrebbe portare confusione in quanto i numeri non hanno alcun riferimento
preciso e sembra sia stato deciso di chiamarlo in questa maniera per motivi storici,
oltre che per differenziarlo dal 4:4:4 e dal 4:2:2.
Il 4:2:0 utilizzato comunemente per le applicazioni di tipo consumer come le video conferenze,
la televisione digitale ed i DVD.
Siccome ogni componente di colore contiene un quarto del numero di campioni della componente
di luma (Y), i video in 4:2:0 YCbCr richiedono esattamente la met dei campioni richiesti
per il 4:4:4 e per l'RGB.
Ad esempio, supponiamo di avere una source a 720x576.
La risoluzione del luma Y di 720x576 campioni, ognuno rappresentato con 8 bit.
Per quanto riguarda il chroma, abbiamo il campionamento 4:4:4 nel quale la risoluzione di Cb e Cr
di 720x576 campioni, ognuno rappresentato con 8 bit, per un numero di bit totale dato da
720x576x8x3 = 9'953'280 bit.
Abbiamo poi invece il campionamento 4:2:0 nel quale la risoluzione di Cb e Cr di 360x288
campioni, ognuno rappresentato con 8 bit, per un numero di bit totale dato da
(720x576x8) + (360x288x8x2) = 4'976'640 bit.
dimostrato, quindi, che il campionamento 4:2:0 richiede met bit della rappresentazione in 4:4:4.

Il campionamento 4:2:0 chiamato anche 12 bpp (12 bit per pixel).

Il motivo di chiara interpretazione se esaminiamo il gruppo di quattro pixel
rappresentato nella figura soprastante (il quadrato).
Utilizzando il campionamento 4:4:4, sono richiesti 12 campioni, 4 per Y, 4 per Cb e 4 per Cr,
con un totale di 12x8 = 96 bit, una media di 96/4 = 24 bpp (24 bit per pixel).
Utilizzando il campionamento 4:2:0, sono richiesti solamente 6 campioni, 4 per Y, 1 per Cb
ed 1 per Cr, richiedendo un totale di 6x8 = 48 bit, una media di 48/4 = 12 bpp (bit per pixel).
In una sequenza video interlacciata con campionamento 4:2:0, i campioni di luma (Y) e chroma
(Cb e Cr) corrispondenti ad un frame video completo sono allocati in due field e l'H.264
utilizza il metodo riportato dalla figura sottostante: il numero totale di campioni in una coppia di
field lo stesso del numero di campioni nel frame progressivo equivalente.

Dunque, dopo aver esplicato i diversi tipi di campionamento, tornando alla matrice di colore
BT.601 utilizzata per i segnali video per la produzione televisiva curioso sapere che la
componente di luma di un segnale video campionata a 13.5 Mhz e che la componente di chroma
campionata a 6.75 Mhz per produrre un segnale YCbCr 4:2:2.
I parametri del segnale digitale campionato dipendono dal frame rate del video (30 Hz per un
segnale NTSC e 25 Hz per un segnale PAL).

NTSC:
Frame rate: 30 Hz
Field al secondo: 60
Linee per frame completo: 525
Campioni di luma per linea: 858
Campioni di chroma per linea: 429
Bit per campione: 8
Bitrate totale: 216 Mbps
Linee attive per frame: 480
Campioni attivi per linea (luma Y): 720
Campioni attivi per linea (Chroma Cr, Cb): 360
PAL:
Frame rate: 25 Hz
Field al secondo: 50
Linee per frame completo: 625
Campioni di luma per linea: 864
Campioni di chroma per linea: 432
Bit per campione: 8
Bitrate totale: 216 Mbps
Linee attive per frame: 576
Campioni attivi per linea (luma Y): 720
Campioni attivi per linea (Chroma Cr, Cb): 360
Il frame rate dell'NTSC (30 Hz) che pi alto del 25Hz del PAL compensato da una
risoluzione spaziale pi bassa in modo che il bitrate totale sia lo stesso in entrambi i casi: 216 Mbps.
bene ricordare per che l'immagine rappresentata sul display pi piccola del numero totale in
quanto esclude gli intervalli orizzontali e verticali che esistono fuori dai bordi di ogni frame
e si definisce area attiva o area di display.
Inoltre, ogni campione ha un possibile range che va da 0 a 255 ed i livelli 0 e 255 sono riservati per
la sincronizzazione ed il segnale di luma attivo ristretto ad un range che va da 16 (nero)
a 235 (bianco).
Negli standard di codifica video che tratter pi avanti,
far utilizzo di termini quali il QCIF o l'SQCIF.
In pratica, di solito, si cattura o si converte un set di formati di intermezzo prima di encodare e
trasmettere ed il Common Intermediate Format (CIF) alla base di numerosi set di formati.

L'immagine soprastante mostra la componente di luma di un frame video campionato in varie

risoluzioni, dal 4CIF al SQCIF (Sub-QCIF).
La scelta della risoluzione del frame dipende dalle applicazioni e dalle capacit di storage e
trasmissione: il 4CIF appropriato per la televisioni a definizione standard e per i DVD, il CIF
ed il QCIF sono usati per le videoconferenze, ma il QCIF utilizzato anche per le applicazioni
multimediali in ambito mobile, cos come l'SQCIF, dove la risoluzione ed il bitrate sono limitati.

3) Utilizzo delle Trasformate nei codec di codifica video

Dopo aver introdotto le trasformate pi utilizzate, la tesi si sviluppata analizzando la loro
implementazione nella codifica delle immagini fisse,
prendendo in esame gli standard pi utilizzati (sia lossless che lossy).
In questa terza parte, proceder nell'illustrazione della codifica tramite trasformata nei video,
partendo dall'H.261, descrivendo l'MPEG-1, illustrando l'MPEG-2,
argomentando sull'H.263, ponendo particolare attenzione sull'H.264
ed analizzando in modo dettagliato il nuovo codec HEVC.
Prima di trattare direttamente i codec ed esaminarli singolarmente,
bene esplicare le loro funzionalit comuni ed i loro obiettivi.

Generalizzazione su encoder e decoder

Un codec video ha l'obiettivo di encodare un'immagine o una sequenza video in forma compressa e
decodificarlo per produrre una copia esatta (lossless) o approssimativa (lossy) della sequenza video.
Un codec video rappresenta la sequenza video originale con un modello,
ovvero una rappresentazione codificata che pu essere utilizzata per ricostruire il dato a video,
esattamente come gi detto per la codifica delle immagini.
L'encoder video fatto da tre unit funzionali principali: il modello temporale, il modello spaziale
e l'encoder entropico.
L'input al modello temporale una sequenza video non compressa.
Il modello temporale cerca di ridurre la ridondanza spaziale sfruttando le similitudini tra i frame
video vicini, generalmente costruendo una predizione del frame corrente.
In alcuni standard, inoltre, la predizione formata da uno o pi frame precedenti e futuri
ed migliorata dalla compensazione per differenze tra frame (predizione moto-compensata).
L'output del modello temporale un frame residuo creato sottraendo la predizione dal frame
corrente ed un set di parametri di modello, di solito un set di vettori movimento
che descrivono come stato compensato il movimento.
Il frame residuo forma l'input al modello spaziale che fa uso delle similitudini tra i campioni vicini
nel frame residuo per ridurre la ridondanza spaziale ed, in alcuni standard, tale processo viene
effettuato proprio applicando una trasformata ai campioni residui e quantizzando i risultati.
La trasformata converte i campioni in un altro dominio in cui sono rappresentati come coefficienti
di trasformata. I coefficienti sono quantizzati per rimuovere i valori insignificanti,
lasciando un piccolo numero di coefficienti significativi che garantiscono una rappresentazione
del frame residuo.
L'output del modello spaziale un set di coefficienti di trasformata quantizzati.
I parametri del modello temporale (di solito vettori movimento)
ed i coefficienti del modello spaziale sono compressi dall'encoder entropico.
Quest'ultimo rimuove la ridondanza statistica nei dati (ad esempio, rappresentando i vettori
ed i coefficienti che occorrono pi comunemente con dei codici binari corti)
e produce un bit-stream compresso o un file che pu essere trasmesso o salvato.

Una sequenza compressa consiste in parametri di vettori movimento codificati,

coefficienti residui codificati e le informazioni dell'header.
Il decoder video, invece, ricostruisce i frame compressi del bit-stream.
I coefficienti ed i vettori movimento sono decodificati da un decoder entropico,
dopodich il modello spaziale decodificato per ricostruire una versione del frame residuo.
Il decoder utilizza i parametri dei vettori movimento (assieme ad uno o pi frame decodificati
precedentemente) per creare una predizione del frame corrente
ed il frame stesso ricostruito aggiungendo frame residui a tale predizione.

3.1) H.261

L'H.261 fu il primo standard di codifica video internazionale con un'adozione di mercato rilevante.
Per raggiungere un'alta efficienza di compressibilit, le soluzioni di codifica video devono sfruttare
la ridondanza spaziale (tipicamente utilizzando una trasformata), la ridondanza temporale
(tipicamente facendo alcune predizioni nel tempo) e la ridondanza statistica
(tipicamente tramite la codifica entropica).
Questo darebbe come risultato una codifica video lossless, tuttavia, dato che le soluzioni di codifica
video lossless non raggiungono un rapporto di compressione adeguato, le soluzioni di codifica
video sfruttano l'importanza degli elementi a livello percettivo per eliminare, tramite
quantizzazione, tutte le informazioni che non sono visivamente rilevanti, in modo da ricreare una
qualit visivamente simile all'originale, ma di fatto diversa.
Se sono necessari alti fattori di compressione, l'encoder pu decidere di eliminare anche le
informazioni rilevanti a livello visivo, comportando una riduzione della qualit originale,
ma cercando comunque di preservare quanta pi qualit percepita possibile.
L'unit base per la codifica video per l'H.261 sono i macroblocchi; ogni macroblocco
corrisponde a sample (campioni) di luma da 16x16 e ci sono due modi per encodare tali blocchi:

Codifica Intra
Questi macroblocchi sono codificati utilizzando la stessa tecnica analizzata precedentemente
quando ho trattato il JPEG. In questo caso, non sfruttata la ridondanza spaziale. La
codifica Intra spesso utilizzata per il primo frame, per il frame successivo ad un cambio
scena ed anche per i macroblocchi corrispondenti agli oggetti che compaiono per la prima
volta in una scena, catalogati dunque come nuovi.
Il macroblocco diviso in blocchi da 8x8 che sono trasformati utilizzando la DCT
bidimensionale ed i coefficienti risultanti dalla DCT sono poi quantizzati.
Infine, tutti i coefficienti quantizzati sono ordinati in una sequenza monodimensionale a zig
zag. Ogni coefficiente rappresentato utilizzando un simbolo bidimensionale (run, level),
dove sono indicate la sua posizione e la sua quantizzazione. Poi, per poter sfruttare la
ridondanza statica, tali simboli vengono codificati con la codifica di Huffman.

Codifica Inter
Con questa codifica, possibile utilizzare le informazioni dei frame precedenti per encodare
il frame corrente, sfruttando la ridondanza spaziale tra i frame vicini.
Inoltre, questa modalit di codifica anche in grado di individuare, stimare e compensare il
movimento in una sequenza, sfruttando la predizione temporale.
L'esempio che sto per proporre deve essere visto come anticipazione dell'MPEG-1, di cui
parler pi avanti, ma comunque valido per capire concettualmente la motocompensazione
ed ho ritenuto opportuno parlarne ora per un fatto di integrit relativa alla codifica inter.
Supponiamo dunque di avere una rappresentazione di un paesaggio (pensiamo ad una
videoconferenza in cui, come introduzione, si mostra il paesaggio visto dalla finestra) e
supponiamo di avere una ripresa che si muove da sinistra verso destra.

Prendiamo adesso un punto di riferimento: il faro.

Com' logico pensare avremo i frame iniziali che contengono solo il mare ed il paesaggio, i
frame successivi che conterranno il faro (che entra da destra) e quelli seguenti che
vedranno uscire il faro (da sinistra).
Ripetere tutte le informazioni relative ai blocchi del faro sarebbe inutile quanto dispendioso
in termini di compressione leggera, quindi, tali informazioni, vengono semplicemente
ripetute spostando i blocchi di riferimento.
Dunque, per eseguire la stima del movimento, il macroblocco corrente comparato coi
macroblocchi vicini del macroblocco corrispondente nel frame precedente.
Se viene individuato il movimento, le due direzioni (orizzontale e verticale) vengono salvate
in due interi chiamati componenti del vettore di movimento ed i vettori di movimento
vengono poi sottoposti alla codifica entropica.
La differenza tra il macroblocco corrente ed il macroblocco predetto computata eseguendo
quella che si chiama motocompensazione.
Se invece non viene individuato movimento, la differenza considerata errore di
predizione ed computata tra il macroblocco corrente ed il macroblocco corrispondente
nel frame precedente.
Queste differenze (che dovrebbero essere il pi piccole possibile) sono poi trasformate,
quantizzate e sottoposte a codifica entropica.

 doveroso per ricordare che anche se la moto-compensazione rappresenta un grandissimo

vantaggio in termini di compressione, anche vero che il calcolo computazionale richiesto
per eseguirla incredibilmente alto, sia in encoding che in decoding.
Questo perch in fase di encoding dev'essere effettuata la ricerca sui blocchi del frame
precedente, mentre in fase di decoding, il decoder dovr effettuare uno spostamento.
Ultima nota di colore che il processo di predizione pu essere modificato dal loop filter
(LF) che pu essere on o off per aumentare la qualit dell'immagine rimuovendo il noise
ad alta frequenza quando necessario.

Trasformata
La trasformata utilizzata dall'H.261 molto simile a quella utilizzata nel JPEG:
una DCT bidimensionale separabile di grandezza 8x8.
Prima di eseguire la trasformata, il range dei dati impostato in modo da essere centrato su
zero; questo significa che effettuata una sottrazione di 128 ai sample nel range 0-255 per i
sample a 8bit.

Quantizzazione
L'H.261 pu utilizzare come passi di quantizzazione tutti i valori pari che vanno da 2 a 62.
All'interno di ogni macroblocco, tutti i coefficienti DCT sono quantizzati con lo stesso passo
di quantizzazione ad eccezione dei coefficienti DC per i macroblocchi intra che sono sempre
quantizzati con il passo 8 a causa della loro critica importanza visiva.
Ovviamente, pi il valore del passo di quantizzazione alto, pi la quantizzazione sar
marcata, pi il valore sar basso, pi la quantizzazione sar minore.
Tramite il processo di quantizzazione, dunque, come accadeva nella codifica delle immagini
fisse, vengono tagliati i valori di importanza visiva minore per passare a quelli di importanza
maggiore. Un passo di quantizzazione 10 (ad esempio) sar molto pi vicino alla qualit
percepita da una codifica lossless di quanto non lo sia un passo a 50.
bene ricordare ancora una volta che sebbene la quantizzazione cerchi di tagliare fattori di
minore importanza visiva, se il passo molto alto (e quindi si desidera una grande
compressione), si vanno a tagliare parti importanti di informazione
a livello di percezione visiva.
Ad ogni modo, anche se si ha una perdita di qualit, questo viene fatto nel modo pi
leggero possibile, proprio perch si cerca di tagliare sempre quelli meno rilevanti.
Alcune parti considerate dunque meno rilevanti da un passo a 50,
potrebbero invece essere considerate rilevanti da un passo a 10 e cos via.

Informazioni aggiuntive e valutazioni finali

L'H.261 opera a bitrate tra 40kbit/s e 2 Mbit/s e supporta risoluzioni spaziali QCIF (176x144
pixel) e, volendo, CIF (352x288 pixel) ad un sotto-campionamento 4:2:0 (ogni chroma
sottoposto a sotto-campionamento da un fattore di 2, sia orizzontalmente che verticalmente).
L'algoritmo di codifica opera su contenuti progressivi a 30 fps (frame per second, immagini
al secondo), ma questo frame rate pu essere ridotto saltando 1, 2 o 3 frame ogni volta che
ne trasmesso uno.
doveroso ricordare che l'H.261 era stato ideato per la videotelefonia
e per le videoconferenze tramite linee telefoniche ISND (Integrated Service Digital
Network) che hanno tipicamente bitrate multipli di 64 kbit/s.
Proprio a causa delle applicazioni per cui stato pensato, l'H.261 ha dei critici requisiti di
ritardo, in modo da consentire una normale conversazione bidirezionale.
D'altra parte, i suoi requisiti di qualit non sono poi tanto critici, visto che, in questo caso,
una qualit medio-bassa potrebbe essere sufficiente per le comunicazioni personali.

Come primo standard di codifica, l'H.261 non ha nessun altro standard precedente a cui
poter essere comparato, ad ogni modo, possibile valutare le sue performance a seconda dal
bitrate disponibile, dalle caratteristiche delle sequenze video e, pi che altro, dall'encoding.

Prendiamo per esempio la figura soprastante che raffigura la qualit dell'immagine

(utilizzando la metrica di qualit PSNR), contro il bitrate per la nota sequenza videotelefonica Miss America a risoluzione QCIF.
Il diagramma rappresenta i risultati per la sequenza codificata a 30 fps e 10 fps.
Inoltre, sono rappresentati i risultati con e senza i vettori di movimento e con e senza i filtri
di loop a bassa frequenza quando sono utilizzati i vettori movimento (+MV +LF).
Osservando il grafico chiaro che la qualit dell'immagine dipende principalmente
dal bitrate disponibile.
Come previsto, a bitrate pi bassi, il PSNR medio pi basso che per gli alti bitrate.
Per alcuni bitrate, la sequenza video a 10 fps ha, di media, pi bit per frame rispetto alla
sequenza video a 30 fps.
Non solo, il PSNR medio per la sequenza video con il frame rate pi basso
tipicamente pi alta, sebbene l'impressione del movimento possa non essere buona
se la sequenza particolarmente in movimento ( doveroso ricordare che l'occhio umano
in grado di percepire fino a 55 fps).

Nel grafico soprastante raffigurata la variazione del PSNR contro il rapporto di

compressione nella stessa sequenza video.
All'aumentare del rapporto di compressione, il numero di bit disponibile per rappresentare la
sequenza video diminuisce; questo risulta in una riduzione del valore medio del PSNR
ed una conseguente riduzione della qualit dell'immagine.
Analizzando entrambi i grafici possibile concludere che l'introduzione della motocompensazione ed il loop filter (LF) aumentano sempre la qualit della sequenza video
ricostruita per tutti i bitrate ed i rapporti di compressione; ovviamente, per, bisogna tenere
conto che si ha un aumento del costo computazionale.
I benefici, inoltre, sono molto pi visibili ai bassi bitrate ed agli alti rapporti di
compressione.

3.2) Video Standard, MPEG-1

Lo standard video MPEG-1 era il primo standard di codifica video definito dall'MPEG.
L'obiettivo principale dello standard di codifica MPEG-1 era di comprimere in modo efficiente le
informazioni audiovisive per il video storage, in particolare per salvare digitalmente la qualit
visiva delle sequenze delle VHS nei Compact Disk (CD).
Inoltre, lo standard MPEG-1 definisce i codec video ed audio nelle sue parti video ed audio
associate.
Per il video dell'MPEG-1, il bitrate finale si aggira intorno a 1.2 Mbit/s per comprimere risoluzioni
CIF di video a 25 Hz.
A differenza dell'H.261, l'MPEG-1 video non ha requisiti critici per il real-time,
visto che l'obiettivo principale non sono applicazioni in tempo reale.
Ad ogni modo, ha altri requisiti critici relativi al video storage, come gli accessi random,
per provvedere alle funzionalit di storage tipiche, tipo il fast forward ed il reverse playback.
Questo standard venne originariamente ottimizzato per il SIF, che ha una risoluzione di 352x288
pixel a 25 Hz e 325x240 a 30 Hz con un sotto-campionamento 4:2:0.
Oltre ai metodi di predizione utilizzati dall'H.261 dove un macroblocco pu essere predetto da un
macroblocco del frame precedende (predizione in avanti), l'MPEG-1 pu adottare una predizione
all'indietro, basata sul principio che i macroblocchi possono essere predetti anche prendendo
come riferimento i macroblocchi dei frame futuri.
Questo tipo di predizione temporale ha il suo costo, specialmente in termini di ritardo di codifica e
di complessit, che possono essere accettabili, considerando che le applicazioni in real-time non
sono l'obiettivo principale di questo standard e che la codifica offline il campo pi utilizzato.
A causa delle strutture di memorizzazione richieste sopraelencate,
l'MPEG-1 definisce tre tipi di frame dipendenti dai tool di codifica utilizzati:

Intra-frame (I-frame):
I frame Intra includono solamente i macroblocchi codificati in intra.
Questi frame sono principalmente utilizzati per provvedere accessi random dato che non
dipendono da altri frame.
Prevengono inoltre la propagazione d'errore associata alla derivazione, dato che gli altri tipi
di frame dipendono da questi e quindi potrebbero potenzialmente propagare l'errore nei
frame successivi!

Inter-frame (P e B):
I frame inter potrebbero includere macroblocchi codificati intra e si dividono in due: P
(parzialmente predetti) e B (totalmente predetti).

Prima ho parlato di predizione in avanti e predizione all'indietro; ebbene, i fotogrammi

P utilizzano solo la predizione in avanti, mentre i fotogrammi B possono utilizzarle
entrambe. In particolare, negli Inter P-frame, i macroblocchi codificati in inter possono
essere predetti solo dai frame I precedenti (o dagli stessi fotogrammi P precedenti),
da cui predizione in avanti.
Per quanto riguarda gli Inter B-frame, invece, i macroblocchi codificati in inter B possono
utilizzare la predizione in avanti, la predizione indietro oppure entrambe;
si ha cos la predizione bidirezionale.
Come ho gi detto, i fotogrammi B sono totalmente predetti, nel senso che possono
utilizzare solo i fotogrammi I e P e richiedono meno bit degli altri tipi di frame.
Ad ogni modo, se troppi frame B si susseguono, possono esserci dei problemi.
Questo per due motivi di base: il primo che si avr un ritardo nella codifica per il fatto che
i fotogrammi di referenza I e P saranno distanti, ed il secondo che proprio perch sono
distanti, si avr anche una maggiore possibilit di propagazione d'errore.
comunque importante sottolineare che l'efficienza di compressione dei P-frame rispetto agli Iframe e dei B-frame rispetto ai P-frame strettamente relazionata alla complessit associata al
processo di stima del movimento (con un raference frame per i P e due reference frame per i B)
e il ritardo aggiuntivo per i B-frame.

Ho ritenuto opportuno servirmi della rappresentazione dell'architettura rappresenta nella figura

soprastante per spiegare come vengono trattati gli intra ed gli inter.
Per quanto riguarda i macroblocchi intra:

DCT: Dopo aver diviso i macroblocchi in blocchi 8x8, i sample (campioni) vengono
trasformati utilizzando la Trasformata Discreta del Coseno Bidimensionale.

Quantizzazione: Dopo il processo di trasformata, i coefficienti vengono quantizzati.

Encoding Entropico: Infine, i coefficienti quantizzati della DCT sono encodati

entropicamente utilizzando la codifica di Huffman.

Per quanto riguarda i macroblocchi inter:

Stima del movimento: I macroblocchi dei frame di predizione precedenti e futuri (I o P)

sono comparati al macroblocco corrente.

Se questa operazione individua movimento, i vettori movimento sono encodati

entropicamente. L'MPEG-1 utilizza un'accuratezza della stima di movimento di mezzo pixel
per consentire una stima pi precisa del movimento con una conseguente riduzione
dell'errore di predizione.

Invio delle differenze: Se viene individuato movimento, le differenze sono codificate

utilizzando la moto-compensazione, altrimenti, avviene una semplice predizione dal frame
di predizione rilevante corrispondente al macroblocco. Queste differenze, vengono poi
trasformate, quantizzate ed encodate entropicamente.

Anticipo inoltre che, visto che lo standard valido anche per gli altri codec di cui parler pi avanti,
non lo ripeter ogni volta.

Trasformata e Quantizzazione

Per quanto riguarda il processo di quantizzazione utilizzato nell'MPEG-1,

posso dire che simile a quello utilizzato dal JPEG.
Il passo di quantizzazione pu essere differente per ogni coefficiente della DCT
ed definito con le matrici di quantizzazione.
Ci sono due matrici di quantizzazione standard di base: una per gli intra ed una per gli inter.
Per quanto riguarda gli inter, i coefficienti alle alte frequenze non sono necessariamente associati ai
contenuti ad alta frequenza dato che possono risultare da un'immagine povera
o dal noise introdotto dalla cinepresa; in questo caso, i passi di quantizzazione sono constanti.
Per gli intra, la quantizzazione tiene in conto la sensibilit visiva delle varie frequenze spaziali
e le matrici di quantizzazione possono cambiare per ottenere una migliore efficienza di codifica.
Esattamente come l'H.261, i coefficienti DC dei macroblocchi codificati in intra
sono sempre quantizzati con il passo 8.

Nell'MPEG-1 i coefficienti DC sono codificati differentemente in ogni macroblocco

e tra macroblocchi vicini; tale approccio stato scelto proprio per sfruttare le similitudini
tra i coefficianti DC dei blocchi adiacenti.

Informazioni aggiuntive e valutazioni finali

Comparato all'H.261, l'MPEG-1 molto migliore in termini di efficienza di compressione,

grazie alle innovazioni introdotte a livello tecnico.
Un esempio la possibilit di avere predizioni bidirezionali ed anche l'accuratezza del movimento
di met pixel, tuttavia, ovviamente, questo ha portato ad un aumento della complessit
e del costo computazionale.
Ad ogni modo, dato che stiamo parlando del video storage e non del real-time (come accadeva
per l'H.261), tale costo perfettamente tollerabile, soprattutto se si pensa al fatto che lo scopo
principale dell'MPEG-1 di ottenere la maggior compressione possibile per il video storage.

Per le sequenze meno compresse e con meno bitrate, l'H.261 raggiunge in genere rapporti di
compressione migliori dell'MPEG-1 (a pari qualit),
visto che l'MPEG-1 ottimizzato per bitrate di 1.2 Mbit/s.
Inoltre, le videoconferenze e la videotelefonia presentano in genere poco movimento,
bitrate pi bassi e richiedono una bassa complessit ed un basso costo computazionale
a causa del real-time, dunque, in questo caso,
l'H.261 potrebbe ancora essere la scelta migliore rispetto all'MPEG-1.
Ad ogni modo, per contenuti video generali tipo i film,
l'MPEG-1 presenta significativi vantaggi in termini di efficienza di compressione.

3.3) Video Standard, MPEG-2

L'MPEG-2 fu il primo standard creato sia per il broadcast che per lo storage e venne ideato
per codificare sequenze video ad alta qualit e risoluzione senza una visibile perdita di qualit, ed
aveva i seguenti target (obiettivi):

Distribuzione Secondaria: per il broadcast, il segnale da 3-5 Mbit/s dev'essere migliore

o simile alla qualit dei sistemi analoghi disponibili dell'epoca coi quali venivano lavorati
e trasmessi materiali in PAL, SECAM ed NTSC.

Distribuzione Primaria: per le pubblicazioni interne (ad esempio le trasmissioni tra gli
studi), la qualit del segnale ad 8-10 Mbit/s dev'essere simile alla qualit originale,
ovvero simile alla rappresentazione della raw di partenza.

L'MPEG-2 basa il suo utilizzo principale sulle trasmissioni video digitali come il via cavo,
il satellitare ed il digitale terrestre, cos come il Digital Video Disk storage,
pi comunemente noto come DVD.
Inizialmente, l'MPEG-2 era pensato per coprire la codifica video fino a 10 Mbit/s,
lasciando gli alti bitrate e le alte risoluzioni spaziali ad un altro codec video, l'MPEG-3.
Ad ogni modo, l'MPEG-3 non venne mai definito come standard,
visto che l'MPEG-2 si dimostr in grado di poter gestire anche l'HD.
A differenza dei precedenti standard gi analizzati sopra, l'MPEG-2 capace di codificare contenuti
video interlacciati, cos come quelli progressivi e questo torn essere molto utile
in quanto le trasmissioni televisive fanno uso di contenuti interlacciati.
Un'altra caratteristica introdotta da questo standard la scalabilit (fedelt temporale e spaziale)
e tale funzione pu essere molto utile per poter trasmettere in network eterogenei
e con vari tipi di terminali quali, ad esempio, i canali a risoluzione standard ed HD.
Proprio a causa degli ampi e vari campi di utilizzo dell'MPEG-2, le sue impostazioni
(ed i suoi standard) sono stati definiti in termini di profile e level.
Il profile definisce un sottoinsieme dei tool di codifica e della sintassi di bitstream,
provvedendo una variet di caratteristiche richieste da alcune applicazioni
con un certo livello di complessit, quali, ad esempio, la codifica interlacciata, i B-Frame
e la scalabilit.
All'interno di ogni profile, il level definisce il limite del range dei parametri operativi,
quali la risoluzione spaziale (da 352x288 a 1920x1152) ed il bitrate (da 4 Mbit/s ad 80 Mbit/s).

Architettura

I tool di codifica utilizzati dall'MPEG-2 sono molto simili a quelli utilizzati dall'MPEG-1;
le due differenze sostanziali sono legate alle due principali caratteristiche innovative dell'MPEG-2:
la codifica interlacciata e la codifica scalabile.
Quest'ultima caratteristica importante in quanto offre una scalabilit temporale (cambio del frame
rate), una scalabilit spaziale (cambio di risoluzione)
ed una scalabilit di fedelt (cambio della qualit).
Di seguito, viene rappresentata l'architettura dell'MPEG-2 senza la codifica scalabile.

importante ricordare che la scalabilit temporale era gi stata introdotta con l'MPEG-1,
in quanto effettuata gi dalla semplice struttura di predizione temporale basata sui tipi I, P e B
gi analizzati precedentemente, il che significa che le novit della codifica scalabile
introdotte nell'MPEG-2 riguardano la risoluzione spaziale e la scalabilit della qualit.

Trasformata

Lo standard video MPEG-2 utilizza sempre la stessa Trasformata Discreta del Coseno
bidimensionale utilizzata dall'MPEG-1.
Per quanto riguarda la possibilit di effettuare la codifica di sequenze video interlacciate,
stata introdotta la possibilit di utilizzare un diverso ordine di scansione, appositamente per esse.

Con questo diverso ordine di scansione, i coefficienti DCT corrispondenti alle transizioni verticali
sono privilegiati (in termini di ordine di scansione),
dato che la correlazione verticale ridotta per le immagini interlacciate con pi movimento.

Quantizzazione

Per quanto riguarda la quantizzazione, l'MPEG-2 utilizza la stessa tecnica di quantizzazione

utilizzata dall'MPEG-1, facendo uso delle matrici di quantizzazione presentate precedentemente e,
ancora una volta, i coefficienti DC dei macroblocchi codificati intra sono quantizzati con passo 8.

Valutazioni finali

A confronto con l'MPEG-1, chiaro che l'MPEG-2 possa produrre una qualit video migliore
per video interlacciati a prescindere dalla quantit di movimento presente, tuttavia,
per i video progressivi e per i bitrate attorno a 1.2 Mbit/s, l'MPEG-1 superiore all'MPEG-2.
Questo perch l'MPEG-2 ha una struttura sintattica pi complicata,
che pu aumentare il peso delle informazioni a bassi bitrate.
Per gli alti bitrarte (ovvero dai 3.0 Mbit/s in su), invece, anche per i video progressivi,
l'MPEG-2 raggiunge qualit superiori rispetto all'MPEG-1 allo stesso bitrate,
visto che quest'ultimo non ottimizzato per questo genere di bitrate, mentre l'MPEG-2
riesce ad ottenere ottime compressioni per video ad alte risoluzioni ed alta qualit.
3.4)

Video Standard, H.263

Lo standard H.263 venne creato con l'intento di rimpiazzare l'H.261,

aumentando l'efficienza di compressione, soprattutto ai bassi bitrate.
La motivazione principale dietro alla creazione di questo standard era l'assenza di uno standard che
potesse garantire l'interoperativit tra i terminali digitali di video-telefonia
per gli analoghi network telefonici (PSTN) ed i mobile network emergenti.
Questo processo di standardizzazione doveva essere effettuato velocemente
per provvedere ad una veloce distribuzione dei prodotti del mercato.
Inoltre, l'H.263, basato principalmente sulle tecnologie gi pre-esistenti,
in particolar modo sull'H.261 e sull'MPEG-1.

Architettura

Sebbene l'H.261 e l'H.263 condividano la stessa struttura di codifica di base,

presentano comunque alcune differenze, anche se, alcune di esse,
sono miglioramenti gi introdotti nell'MPEG-1.
possibile individuare 6 differenze sostanziali tra l'H.261 e l'H.263:
1) Target Bitrate Il target bitrate dell'H.261 px64 kbit/s (p=1, 2... 30) mentre l'H.263
punta a bitrate al di sotto dei 64 kbit/s per consentire la video-telefonia PSTN.
2) Formati di Immagine Oltre ai formati gi utilizzati dall'H.261 (ovvero il QCIF ed il CIF),
l'H.263 supporta i formati sub-QCIF, 4CIF ed il 16CIF.
3) Accuratezza di motocompensazione Come lo standard MPEG-1,
l'H.263 supporta l'accuratezza fino a met pixel.
4) Predizione dei vettori spostamento I vettori spostamento sono codificati come nell'H.261,
ma, oltre ai macroblocchi precedenti, anche i macroblocchi nella riga di macroblocchi
precedente sono utilizzati per la predizione di vettori spostamento

e questo consente di ridurre l'errore nel bitstream.

5) Modalit PB-Frame Un PB-Frame consiste in due immagini codificate come una unit.
Il frame di tipo P predetto dall'ultimo frame P decodificato
ed il frame B predetto sia dall'ultimo che dal corrente frame P.
6) VLC tables L'H.263 utilizza triplette run, level, eob per codificare i coefficienti DCT
e non pi le doppiette run, level per evitare di codificare esplicitamente il simbolo eob (End
of Block).

Trasformata

Per quanto riguarda la trasformata, l'H.263 utilizza la stessa Trasformata Discreta del Coseno
bidimensionale utilizzata dall'H.261 e, come sempre, tale trasformata applicata a blocchi di 8x8.

Quantizzazione

Per quanto concerne la quantizzazione, l'H.263 utilizza lo stesso metodo descritto per l'H.261.
Lo stesso identico passo (valori pari contenuti tra 2 e 62) utilizzato per tutti i coefficienti
nello stesso macroblocco, ad eccezione dei coefficienti DC dei macroblocchi codificati intra,
che sono quantizzati con passo 8.

Valutazioni finali

Lo standard H.263 superiore in termini di efficienza di compressione al precedente H.261

per qualsiasi bitrate, anche sopra ai 64 kbit/s.
Con una tale dimostrazione di efficienza, possibile affermare che l'H.263 ha rimpiazzato
positivamente e completamente l'H.261 come standard di codifica video per le comunicazioni a
bassi bitrate; inoltre, la complessit dell'H.263 solo appena pi alta di quella dell'H.261.

3.5.0) Video Standard, MPEG-4

Prima di andare a parlare dell'MPEG-4, bene chiarire a quale versione andr a fare riferimento.
L'MPEG-4, ancora oggi, in continua evoluzione ed diviso in part (parti).
Spesso le compagnie che promuovono la compatibilit con tale video standard non forniscono alcun
dato sulla part dello standard a cui fanno riferimento, il che potrebbe creare un po' di confusione.
Le part pi importanti e rilevanti, nonch quelle di cui parler in questa tesi sono la part2 (che
include l'Advanced Simple Profile utilizzato da codec come il DviX e l'Xvid) e la part 10 (ovvero
l'Advanced Video Coding AVC, meglio conosciuto come H.264, utilizzato dall'x264,
nonch standard di codifica ad alta risoluzione per i bluray).

3.5.1)

Video Standard, MPEG-4 Visual (MPEG-4 part 2)

L'MPEG-4 Visual ha l'obiettivo di specificare i codec per vari tipi di oggetti visivi da utilizzare nel
contesto dello standard MPEG-4, che adotta per la prima volta un paradigma di rappresentazione
visiva basata sugli oggetti e non sui frame.
In questo contesto, lo standard MPEG-4 copre una vasta gamma di applicazioni come, ad esempio,
le telecamere di sorveglianza, le comunicazioni mobile, lo streaming in internet ed intranet,
le TV digitali, la post-produzione ecc.
Lo standard MPEG-4 Visual specifica codec per oggetti visivi naturali e sintetici;
in termini di codec video, specifica i codec per oggetti visivi rettangolari e di forma arbitraria.
Per gli oggetti rettangolari, la risoluzione spaziali va dal sub-QCIF a risoluzioni da studio
che si aggirano attorno ai 4k x 4k pixel.
Ovviamente, come considerato negli standard precedenti,
un frame un caso particolare di oggetto video.

Architettura

Lo Standard MPEG-4 Visual include strumenti per codificare video naturali ed immagini fisse
(textures visive) e questo consente di codificare scene che contengono immagini fisse
ed in movimento utilizzando lo stesso standard.
Ogni scena da codificare pu essere composta da uno o pi oggetti video.
Nella codifica basata sugli oggetti, i frame video sono definiti in termini di VOP (Video Object
Planes) ed ogni VOP la rappresentazione video momentanea
di uno specifico oggetto di interesse da codificare o col quale interagire.
Ogni oggetto video incapsulato in un rettangolo di selezione che diviso poi in macroblocchi
da 16x16 pixel che possono essere classificati come trasparenti, opachi o di bordo.
I macroblocchi del rettangolo di selezione che sono completamente all'esterno del VOP
non hanno bisogno di essere codificati e vengono definiti trasparenti.
I macroblocchi del rettangolo di selezione che sono completamente all'interno del VOP
sono codificati inter o intra utilizzando la motocompensazione e l'encoding tramite DCT
e vengono definiti opachi.
I macroblocchi del rettangolo di selezione che sono in parte esterni ed in parte interni al VOP
sono processati con strumenti specifici atti alla codifica degli oggetti di forma arbitraria
e vengono definiti di bordo.
Per capire meglio le distinzione, i tre tipi di macroblocchi sono riportati nella figura sottostante:

Per quanto riguarda invece la codifica video rettangolare (o basata sui frame),
che funzionalmente simile alla codifica basata sui frame precedentemente analizzata,
ci sono alcuni miglioramenti introdotti dall'MPEG-4 Visual,
soprattutto in termini di moto-compensazione.

La moto-compensazione supporta vettori di movimento con una maggiore accuratezza,

soprattutto ad un quarto di pixel, consentendo migliori predizioni
e riducendo gli errori di predizione.

Invece di utilizzare vettori di movimento locali per ogni macroblocco,

lo strumento di Moto-compensazione Globale consente di utilizzare
anche un vettore movimento per VOP (che potrebbe essere un frame).
Questo pu tornare utile per sequenze con un'ampia porzione di movimento globale
traslazionale (come il camera panning) ed anche per il movimento non-traslazionale
(come lo zoom o la rotazione).

La Direct Mode nella predizione bidirezionale una generalizzazione dei PB-Frame

gi introdotta nell'H.263; vengono utilizzate sia la predizione in avanti che quella
all'indietro, ma i vettori movimento richiesti sono derivati dai vettori movimento
dei macroblocchi collocati nel riferimento all'indietro
ed trasmesso solo un termine di correzione chiamato delta vector.

Nella figura sottostante riportata l'architettura di encoding di oggetti video rettangolari.

inoltre doveroso ricordare che gli oggetti fissi, chiamati anche visual textures,
sono codificati mediante una soluzione basata sulla Trasformata di Wavelet,
simile a quella utilizzata dallo standard JPEG2000 precedentemente analizzato.

Trasformata

L'MPEG-4 Visual utilizza anch'esso la Trasformata Discreta del Coseno bidimensionale

per trasformare i blocchi da 8x8 che compongono un macroblocco.

Quantizzazione

L'MPEG-4 Visual ha la possibilit di quantizzare i coefficienti in due modi diversi:

il primo derivato dall'MPEG-2 (metodo 1) ed il secondo dall'H.263 (metodo 2).
Per quanto riguarda il metodo 1, tale metodo prende in considerazione le propiet
del sistema visivo umano, consentendo un passo di quantizzazione diverso
per ogni coefficiente di trasformata per mezzo delle matrici di quantizzazione.
Di sotto sono riportate le matrici di quantizzazione di default per i macroblocchi codificati intra
(sinistra) e quelli codificati inter (destra).

Per quanto concerne invece il metodo 2, meno complesso e pi facile da implementare,

ma consente un solo valore di passo per macroblocco;
il che significa che l'intero macroblocco verr processato con tale passo!
La selezione del metodo di quantizzazione decisa dall'encoder
e tale decisione viene poi trasmessa al decoder.
Per i blocchi codificati intra,
il coefficiente DC quantizzato usando un passo di quantizzazione prefissato.

Come gi esplicato prima, l'MPEG-1 predice i valori dei coefficienti DC utilizzando i valori
dei coefficienti DC dei blocchi vicini.
Per alcuni coefficienti DC ed AC dei blocchi vicini ci sono alcune dipendenze statistiche
quali il fatto che il valore di un blocco pu essere predetto dal valore corrispondente
di uno dei blocchi vicini.
Tale fatto sfruttato dall'MPEG-4 ed chiamato predizione DC/AC
e tale predizione applicata solo in caso di macroblocchi codificati intra.
Per la scansione dei coefficienti DCT (che corrisponde ad una conversione da bidimensionale a
monodimensionale delle informazioni dei coefficienti DCT), ci sono due modalit di scansione
aggiuntive disponibili, oltre a quella a zig-zag utilizzata in molti standard,
quali la scansione alternata orizzontale e la scansione alternata verticale.

Per quanto riguarda i macroblocchi di bordo, questo standard supporta anche l'utilizzo
di una trasformata speciale chiamata Shape-Adaptive DCT ovvero DCT a forma adattiva.
In pratica, lo scopo di tale trasformata di codificare solo i pixel opachi
all'interno dei macroblocchi di bordo che non sono completamente riempiti da dati di texture.

Valutazioni Finali

L'obiettivo principale dell'MPEG-4 Visual non quello di aumentare l'efficienza di compressione,

anche se, per alcuni dei suoi profili, in particolare per la codifica video basata sui frame,
ci sono alcuni benefici di compressione rispetto agli standard precedenti,
grazie ai nuovi strumenti di codifica.
Per gli alti bitrate (ovvero bitrate che vanno da 5 Mbit/s a 15 Mbit/s),
l'MPEG-2 ottiene gi buoni risultati e, per tali range di bitrate,
l'MPEG-4 Visual non porta alcun beneficio significativo.
Ad ogni modo, per i bitrate medio-bassi (ovvero bitrate fino ad un massimo di 3 Mbit/s),
l'MPEG-2 non consente una buona compressione ed addirittura superato dall'MPEG-1 (come
detto nel paragrafo precedente) ed proprio in questo ambito che l'MPEG-4 Visual
sfodera il suo potenziale, ottenendo risultati di compressione migliori
in tutti i tipi di sequenza video.
Per i bitrate veramente bassi (ovvero circa 50 kbit/s), invece, l'H.263 ancora superiore all'MPEG-4
Visual in quanto, per tali bitrate, quest'ultimo non utilizza tutti gli strumenti di codifica disponibili
ed utilizza il Simple Profile in modo da ridurre la complessit
ed il ritardo causato dal loro utilizzo.
Ad ogni modo, per bitrate medi (ovvero 1.5 Mbit/s), l'MPEG-4 Visual superiore anche all'H.263,
in quanto pu utilizzare l' Advanced Simple Profile che sfrutta tutti gli strumenti di codifica,
quali i B-frame, la motocompensazione per quarti di pixel,
il metodo di quantizzazione 1 basato sull'MPEG-2 e la motocompensazione globale.

3.5.2)

Video Standard, MPEG-4 (Part 10), AVC H.264

Dopo aver analizzato l'MPEG-4 (Part 2) Visual, doveroso esplicare l'MPEG-4 (Part 10),
ovvero l'MPEG-4 Advanced Video Coding H.264.
L'H.264 lo standard attualmente pi utilizzato, nonch alla base di servizi di streaming come
Vimeo, software web come Adobe Flash Player e Microsoft Silverligth ed anche per le trasmissioni
HDTV terrestri (ISDB-T, DVB-T, DVB-T2), via cavo (DVB-C) e satellitari (DVB-S, DVB-S2).
L'intento dell'H.264 era di creare uno standard in grado di fornire una buona qualit video a bitrate
pi bassi degli standard precedenti (met bitrate dell'MPEG-2, dell'H.263 o dell'MPEG-4 Part 2),
senza aumentare di tanto la complessit ed evitare di renderlo troppo esoso di risorse e, difatti,
inutilizzabile.
Un altro obiettivo era quello di garantire abbastanza flessibilit da consentire allo standard di essere
applicato ad una vasta gamma di applicativi su un ampio raggio di network e sistemi,
che variano da bitrate molto bassi a bitrate molto alti, da risoluzioni molto basse
a risoluzioni molto alte, dal broadcasting, allo storage (rip) DVD, all'RTP, ai sistemi di telefonia.

Encoder (percorso in avanti)

Un frame in input o field Fn processato in unit di un macroblocco.

Ogni macroblocco encodato in intra o inter e, per ogni blocco del macroblocco,
viene effettuata una predizione PRED (segnata come P nella figura soprastante)
basata sui campioni dell'immagine ricostruita.
Nella modalit intra, il PRED formato dai campioni della parte corrente
precedentemente encodata, decodificata e ricostruita (uF'n in figura;
notare che i campioni unfiltered sono usati per formare il PRED).
Nella inter mode (modalit inter), il PRED formato dalla predizione moto-compensata da una
o due immagini di riferimento selezionate dalle immagini della lista 0 e/o della lista 1.
In figura, l'immagine di riferimento mostrata come l'immagine precedentemente encodata F'n-1,
ma il riferimento di predizione per ogni partizione di macroblocco (in modalit inter)
potrebbe essere scelto da una selezione di immagini passate o future (in ordine di visualizzazione)
che sono gi state encodate, ricostruite e filtrate.
La predizione PRED sottratta dal blocco corrente per produrre un blocco Dn residuo che
trasformato (usando una trasformata a blocchi) e quantizzato per dare X,
un set di coefficienti di trasformata quantizzati che sono riordinati dall'encoder entropico.

I coefficienti encodati entropicamente, assieme alle informazioni secondarie richieste

per decodificare ogni blocco nel macroblocco (modelli di predizione, parametri del quantizzatore,
informazioni dei vettori movimento ecc), formano il bit-stream compresso
che passato al NAL (Network Abstraction Layer) per la trasmissione o lo storage.

Encoder (percorso di ricostruzione)

Cos come encoda e trasmette ogni blocco in un macroblocco, l'encoder decodifica (ricostruisce)
ogni blocco per consentire un riferimento per le predizioni future.
I coefficienti X sono messi in scala (Q^-1) ed inversamente trasformati (T^-1)
per produrre un blocco di differenza D'n.
Il blocco di predizione PRED aggiunto a quello D'n per creare un blocco ricostruito uF'n:
una versione decodificata del blocco originale, dove u indica che unfiltered.
Viene applicato un filtro per ridurre l'effetto di blocking
e poi viene costruita un'immagine di riferimento da una serie di blocchi F'n.

Decoder

Il decoder riceve il bit-stream compresso dal NAL e decodifica entropicamente i dati

per produrre un set di coefficienti quantizzati X.
Questi sono messi in scala ed inversamente trasformati per dare D'n
(che identico al D'n dell'encoder).
Utilizzando le informazioni di header decodificate dal bit-stream,
il decoder crea blocchi di predizione PRED (identici agli originali blocchi PRED
formati in fase di encoding) ed i PRED sono poi aggiunti a D'n per produrre uF'n
che filtrato per creare ogni blocco di decodifica F'n.

Profile

L'H.264 definisce un set di tre Profiles principali, ognuno dei quali supporta un particolare set di
funzioni di codifica ed ognuno specifica cos' richiesto ad encoder e decoder
che supportano tale Profile.
Il Profile Baseline supporta la codifica intra ed inter (utilizzando i frame codificati I e P)
e la codifica entropica con codici adattivi al contesto e di lunghezza variabile:
CAVLC (Context Adaptive Variable Length Codes).
Il Profile Main include il supporto ai video interlacciati, la codifica inter utilizzando
i frame codificati B, la codifica inter utilizzando la predizione adattiva e la codifica entropica
utilizzando una codifica aritmetica basata sul contesto:
CABAC (Context Based Arithmetic Coding).

Il profile Extended non supporta i video interlacciati od il CABAC,

ma aggiunge modalit per abilitare uno switch efficiente tra il bit-stream codificato (SP ed SI)
ed una resilienza di errori migliorata (Partizionamento dei Dati).
Ogni Profile ha una flessibilit abbastanza ampia da supportare un vario utilizzo.
Durante gli anni, inoltre, sono stati aggiunti vari profili che sono in grado di coprire una vasta
gamma di applicativi nello specifico, per un totale di 18 profile e 5 sub-profile.
1) Constrained Baseline Profile
Usato principalmente per le videoconferenze e per le applicazioni mobile.
2) Baseline Profile
Usato per le applicazioni a basso costo ed utilizzato per le videoconferenze
e le applicazioni mobile ed include tutte le feature supportate dal Constrained Baseline
Profile, pi altre tre feature.
3) Extended Profile
Usato per lo streaming. Questo profilo ha una capacit di compressione relativamente alta.
4) Main Profile
Questo profilo utilizzato per il broadcasting televisivo a definizione standard che utilizza
il formato MPEG-4 definito nello standard DVB.
5) High Profile
Utilizzato per il broadcasting ad alta qualit (DVB HDTV) e per i Blu-ray.
6) Progressive High Profile
Molto simile all'High Profile, ma, ovviamente, non supporta la codifica dei field.
7) Constrained High Profile
Simile al Progressive High Profile, ma senza il supporto ai frame codificati B.
8) High 10 Profile (Hi10P)
Questo profilo va oltre alla capacit di decodifica della fascia consumer e consente di
utilizzare 10 bit per campione invece di 8, ma non supportato dagli applicativi standard
come le console e la maggior parte delle televisioni.
9) High 4:2:2 Profile (Hi422P)
Utilizzato principalmente per gli applicativi professionali che utilizzano video interlacciati.
Questo profilo si basa sul profilo Hi10P aggiungendo il supporto al 4:2:2 per il chroma.
10) High 4:4:4 Predictive Profile (Hi444PP)
Utilizzato per le registrazioni da videocamere professionali, per l'editing professionale
ed altre applicazioni professionali. Questo profilo basato sull'High 4:2:2,
aggiungendo il supporto al 4:4:4 per il chroma.
11) High 10 Intra Profile
basato sull'Hi10P ma limitato a codificare tutti i frame come intra.

12) High 4:2:2 Intra Profile

basato sull'Hi422P ma limitato a codificare tutti i frame come intra.
13) High 4:4:4 Intra Profile
basato sull'Hi444PP ma limitato a codificare tutti i frame come intra.
14) Stereo High Profile
Utilizzato per la visualizzazione dei video stereoscopici 3D.
15) Multiview High Profile
Utilizzato per la visualizzazione doppia o multipla, ma non supporta le immagini a field.
16) Multiview Depth High profile
17) CAVLC 4:4:4 Intra Profile
basato sull'Hi444PP ma limitato a codificare tutti i frame come intra
ed utilizza la codifica entropica CAVLC (ovvero non supporta il CABAC).
Per quanto concerne il CAVLC 4:4:4 Intra Profile, questi contiene a sua volta cinque sub-profile
scalable:
17.1)
Scalable Baseline Profile
Utilizzato per le video conferenze, per le applicazioni mobile e di sorveglianza.
Questo profilo basato sul profilo Constrained Baseline al quale il base layer (un subset
del bit-stream) deve essere conforme. Inoltre, per i tool di scalabilit,
stato abilitato un subset per i tool.
17.2)
Scalable Constrained Baseline Profile
Utilizzato principalmente per le comunicazioni in tempo reale.
Questo profilo basato sul profilo Scalable Baseline.
17.3)
Scalable High Profile
Utilizzato principalmente per il broadcasting e lo streaming.
Questo profilo basato sull'High Profile, al quale il base layer deve essere conforme.
17.4)
Scalable Constrained High Profile
Utilizzato principalmente per le comunicazioni in tempo reale.
Questo profilo basato sul profilo Scalable High.
17.5)
Scalable High Intra Profile
Utilizzato principalmente per le applicazioni di produzione.
Questo profilo basato sul profilo Scalable High, ma codifica tutti i fotogrammi in Intra.

Levels

Il level uno specifico set di limitazioni che indicano il livello di performance

che il decoder deve avere per poter riprodurre un determinato profile.
Un level specifica la risoluzione massima, il frame rate ed il bitrate che un decoder potrebbe dover
utilizzare e, ovviamente, i decoder che supportano un determinato level devono essere in grado
di decodificare tutti i bit-stream encodati per quel livello e tutti quelli ai livelli inferiori.

La maggior parte dei decoder della fascia consumer come le televisioni, le console, nonch i bluray
supportano fino al level 4.1, High Profile (quindi 8 bit con spazio di colore 4:2:0),
per tanto doveroso rispettare l'authoring per la distribuzione per assicurare la compatibilit.

Il bitrate massimo dell'High Profile 1.25 volte pi alto di quello dei profile Baseline, Extended
e Main.
Il bitrate massimo dell'Hi10P 3 volte pi alto di quello dei profile Baseline, Extended e Main.
Il bitrate massimo dell'Hi444PP 4 volte pi alto di quello dei profile Baseline, Extended e Main.

Campionamento

L'H.264 supporta la codifica e la decodifica di video progressivi ed interlacciati 4:2:0

e questi il campionamento di default.
Come visto precedentemenete, possibile encodare in campioni da 4:2:2 e 4:4:4,
tuttavia la loro decodifica non supportata dalla maggior parte dei device della fascia consumer
e tali campionamenti sono limitati quasi esclusivamente all'utilizzo in campo professionale.

Nel campionamento di default, le componenti di chroma (Cb e Cr) sono allineate orizzontalmente
con ogni secondo campione di luma e sono situate verticalmente tra i due campioni di luma.

Formato di Codifica dei Dati

L'H.264 effettua una distinzione tra il VCL (Video Coding Layer)

ed il NAL (Network Abstraction Layer).
L'output del processo di encoding un dato VCL, ovvero una sequenza di bit che rappresenta
i dati video codificati, che sono mappati in unit NAL prima della trasmissione o dello storage.
Ogni unit NAL contiene un RBSP (Raw Byte Sequence Payload), ovvero un set di dati
che corrispondono ai dati video codificati od alle informazioni di header.
Una sequenza video codificata rappresentata da una sequenza di unit NAL
che possono essere trasmesse in un network a pacchetti od in un link di trasmissione bit-stream
od anche salvati in un file.

Il fatto di specificare separatamente VCL e NAL utile in quanto serve a distinguere le feature
specifiche della codifica (VCL) e le feature specifiche del trasporto (NAL),
ma parler di quest'ultimo pi avanti.

Reference frame e Slice

L'H.264, in fase di encoding, potrebbe utilizzare una o pi immagini precedentemente encodate

come riferimento per la predizione moto-compensata di ogni macroblocco
o partizioni di macroblocco codificati inter.
Questo consente all'encoder di cercare il miglior riferimento per la partizione di macroblocco
corrente da un'ampia gamma di immagini, invece che usare l'immagine precedentemente encodata.
L'encoder ed il decoder mantengono una o due liste di immagini di riferimento,
contenenti immagini che sono state precedentemente encodate e decodificate
(che si verificano prima e/o dopo l'immagine corrente nell'ordine di riproduzione).
I macroblocchi codificati inter e le partizioni di macroblocchi codificate in P
sono predetti dalle immagini in una sola lista: la lista 0, gi incontrata precedentemente.
I macroblocchi codificati inter e la partizioni di macroblocchi codificate in B
potrebbero invece essere predette da due liste: la lista 0 e la lista 1.
In precedenza stata trattata la codifica in Intra (I), Predicted (P) e Bi-predictive (B), ma l'H.264,
per il profile Extended, fa utilizzo anche dello Switching P (SP) e dello Switching I (SI).
Nell'H.264, inoltre, questi assumono il nome di Slice.
Un'immagine video quindi codificata come uno o pi Slice, ognuno contentente un numero intero
di macroblocchi che va da 1 (1 MB per Slice) al numero totale di macroblocchi nell'immagine
(1 Slice per immagine).
Il numero di macroblocchi per Slice non deve essere costante nell'immagine
e c' una interdipendenza minimale tra gli Slice codificati
che pu aiutare a limitare la propagazione degli errori.
Ci sono cinque tipi di Slice codificati (ovvero I, P, B, SP ed SI) ed un'immagine codificata
potrebbe contenere un misto di Slice I e P; ad esempio, un'immagine codificata con il Main
e l'Extended profile potrebbe contenere un misto di slice I, P e B.
Lo Slice header definisce il tipo di Slice e l'immagine codificata cui appartiene lo Slice
e pu contenere istruzioni relative alla gestione dell'immagine di riferimento.

Il dato Slice consiste in una serie di macroblocchi codificati ed/o un'indicazione di macroblocchi
skippati (non codificati) ed ogni macroblocco contiene una serie di elementi header
e dati residui codificati.
Gli Slice Intra contengono solo macroblocchi Intra.
Gli Slice P contengono macroblocchi P e/o macroblocchi codificati I.
Per quanto riguarda quelli codificati P, ogni macroblocco (o partizione di questo)
predetto da un'immagine di riferimento contenuta nella lista 0.
Gli Slice B contengono macroblocchi B e/o macroblocchi I.
Per quanto riguarda quelli codificati B, ogni macroblocco (o partizione di questo)
predetto da un'immagine di riferimento contenuta nella lista 0 e/o nella lista 1.
Gli Slice Switching P (SP) servono a facilitare lo switch tra gli stream codificati
e contengono macroblocchi P e/o I.
Gli Slice Switching I (SI), invece, servono a facilitare lo switch tra gli stream codificati
e contengono macroblocchi SI, ovvero un particolare tipo di macroblocco codificato Intra.

I Macroblocchi

Un macroblocco contiene dati codificati corrispondenti a regioni campione del frame video 16x16
(16x16 campioni luma, 8x8 campioni Cb ed 8x8 campioni Cr) e contiene elementi di sintassi
mb_type, mb_pred, sub_mb_pred, coded_block_pattern, mb_qp_delta e residual.
L'mb_type determina se il macroblocco codificato in intra o inter (P o B)
e determina la grandezza di partizione del macroblocco.
L'mb_pred determina la modalit di predizione intra (macroblocchi intra) e determina i riferimenti
in lista 0 e/o lista 1 ed i vettori di movimento codificati per ogni partizione di macroblocco
(macroblocchi inter, eccetto per i macroblocchi inter con grandezza di partizione 8x8).
Il Sub_mb_pred solo per i macroblocchi inter con grandezza di partizione 8x8 e determina la
grandezza di partizione del sotto-macroblocco per ogni sotto-macroblocco,
i riferimenti appartenenti alla lista 0 e/o lista 1 per ogni partizione di macroblocco
ed i vettori movimento codificati per ogni sotto-partizione di macroblocco.
Il code_block_pattern identifica quali blocchi 8x8 (luma e chroma) contengono i coefficienti di
trasformata codificati.
L'mb_qp_delta cambia il parametro del quantizzatore.
Il residual definisce i coefficienti di trasformata codificati
corrispondenti ai campioni di immagine residua dopo la predizione.

Il Profilo Baseline

Il profilo Baseline supporta la codifica delle sequenze video contenenti Slice I e P.

Gli Slice I contengono macroblocchi codificati intra nei quali le regioni di luma da 16x16 o 4x4
e quelle da 8x8 del chroma sono predette dal campione precedentemente codificato
nello stesso Slice.
Gli Slice P possono contenere macroblocchi codificati intra, codificati inter o skippati.
I macroblocchi codificati inter in uno Slice P sono predetti da un numero di immagini codificate
precedentemente utilizzando la compensazione di movimento con accuratezza
di un vettore movimento di un quarto di campione (luma).
Dopo la predizione, i dati residui per ogni macroblocco
sono trasformati usando una trasformata intera 4x4 (basata sulla DCT) e quantizzati.
I coefficienti di trasformata quantizzati sono riordinati
e gli elementi di sintassi sono codificati entropicamente.
Nel profilo Baseline, i coefficienti di trasformata sono codificati entropicamente utilizzando
lo schema CAVLC (Context adaptive variable length coding) gi trovato in precedenza e tutti gli
altri elementi di sintassi sono codificati utilizzando una lunghezza fissata
od i codici di lunghezza variabile Golomb-Esp.
I coefficienti quantizzati sono messi in scala, inversamente trasformati, ricostruiti
(aggiunti alla predizione formata in fase di encoding) e filtrati con un filtro di deblocking
(a discrezione dell'encoder) prima di essere salvati per un possibile uso nelle immagini
di riferimento per macroblocchi intra ed inter futuri.
Dopo questa visione generale del Baseline profile,
lecito passare ad esplicare come viene effettuata la gestione delle immagini di riferimento.
Le immagini che sono state encodate precedentemente sono salvate nel buffer di riferimento
(il buffer delle immagini decodificate, detto DPB, decoded picture buffer)
sia nell'encoder che nel decoder.
L'encoder ed il decoder mantengono una lista di immagini codificate precedentemente,
la lista 0 di immagini di riferimento, per l'utilizzo nelle predizioni moto-compensate
di macroblocchi inter in Slice P.
Per la predizione degli Slice P, la lista 0 contiene immagini prima e dopo l'immagine corrente
(nell'ordine di riproduzione) e possono contenere immagini di riferimento sia short term
sia long term.
Di default, un'immagine encodata ricostruita dall'encoder e markata come immagine short term,
ovvero un'immagine recentemente codificata che disponibile per la predizione.
Le immagini short term sono identificate dal PicNum, una variabile derivata
dal loro numero di frame. Le immagini long term sono, in genere, le immagini pi vecchie
che possono essere utilizzate per la predizione e sono identificate da un LTPN (Long Term PicNum)
variabile.
Le immagini long term rimangono nel DPB (decoded picture buffer)
finch non vengono esplicitamente rimosse o sostituite.
Quando un'immagine encodata e ricostruita (nell'encoder) o decodificata (nel decoder),
inserita nel DPB e pu essere marcata come a (non utilizzabile per i riferimenti),
come b (short term), come c (long term) o come d (semplice output al display).
Di default, le immagini short term nella lista 0 sono ordinate secondo il PicNum,
dal pi alto al pi basso e le immagini long term sono ordinate dall'LTPN (Long Term PicNum)
pi basso a quello pi alto; ad ogni modo, l'encoder pu segnalare un cambiamento nell'ordine
della lista delle immagini di riferimento di default.
Come ogni nuova immagine aggiunta alla lista short term in posizione 0,
gli indici delle immagini short term rimanenti sono incrementati.

Se il numero degli short term e dei long term uguale al massimo numero di reference frame,
l'immagine short term pi vecchia (cio con l'indice pi alto) rimossa dal buffer;
questo processo conosciuto come controllo di memoria sliding window - finestra scorrevole.
L'effetto di questo processo che l'encoder ed il decoder mantengono una finestra di N immagini
di riferimento short term, inclusa l'immagine corrente
ed (N-1) immagini precedentemente encodate.
I comandi di controllo memoria adattiva inviati dall'encoder gestiscono gli index d'immagine
short term e long term.
Utilizzando questi comandi, le immagini short term possono essere assegnate ad un frame index
long term oppure un'immagine short term o long term pu essere marcata come
non utilizzabile come riferimento.
L'encoder sceglie l'immagine di riferimento dalla lista 0 per encodare
ogni partizione di macroblocco in un macroblocco codificato inter.
La scelta dell'immagine di riferimento segnalata da un numero di index, dove l'index 0
corrisponde al primo frame nella sezione short term e gli indici dei frame long term
iniziano dopo l'ultimo short term.
Procedendo oltre, un encoder manda anche un'immagine codificata IDR (Instantaneous Decoder
Refresh) - fatta di Slice I o SI - per chiarire i contenuti del buffer dell'immagine di riferimento.
Quando riceve un'immagine codificata IDR, il decoder marca tutte le immagini nel buffer di
riferimento come non utilizzabile come riferimento.
Tutti gli Slice trasmessi di seguito possono essere decodificati senza riferimento
ad alcuna immagine decodificata prima dell'immagine IDR
e la prima immagine in una sequenza video codificata sempre un'immagine IDR.
Un bit-stream conforme al profilo Baseline contiene Slice codificati I e/o P.
Uno Slice I contiene solo macroblocchi codificati intra (predetti dai campioni codificati in
precedenza nello stesso Slice) ed uno Slice P pu contenere macroblocchi codificati inter
(predetti da campioni nelle immagini precedentemente codificate),
macroblocchi codificati intra o macroblocchi skippati.
Quando un macroblocco skippato segnalato nel bit-stream,
non sono inviati ulteriori dati per quel macroblocco.
Il decoder calcola un vettore per il macroblocco skippato e ricostruisce il macroblocco
utilizzando la predizione moto-compensata dalla prima immagine di riferimento nella lista 0.
Un encoder H.264 pu inserire opzionalmente un'unit RBSP delimitante
ai bordi delle immagini codificate.
Questo per indicare l'inizio di una nuova immagine codificata ed indicare quali tipi di Slice
sono consentiti nell'immagine codificata seguente.
Se il delimitatore non utilizzato, il decoder cerca le informazioni sul verificarsi dei nuovi frame
nell'header del primo Slice nella nuova immagine.
Passando oltre, un'immagine marcata come ridondante contiene una rappresentazione parziale
o completa dell'immagine codificata.
Nelle operazioni normali, il decoder ricostruisce il frame dalla prima immagine non ridondante
e dimentica ogni immagine ridondante.
Ad ogni modo, se la prima immagine codificata danneggiata (ad esempio a causa di un errore
di trasmissione), il decoder pu decidere di sostituire l'area danneggiata con i dati decodificati
di un'immagine ridondante, se disponibile.
Tornando a parlare degli Slice, doveroso introdurre l'ASO (Arbitrary Slice Order)
ordine degli Slice arbitrario.
Il profilo baseline supporta l'ASO ed utilizzare questo tool significa semplicemente
che gli Slice in un frame codificato possono seguire qualsiasi ordine di decodifica.

L'ASO definito per essere utilizzato se il primo macroblocco in uno Slice in un frame decodificato
contiene un indirizzo di macroblocco pi piccolo del primo macroblocco in uno Slice decodificato
precedentemente nella stessa immagine.
Sempre parlando di Slice, ci sono anche i Gruppi di Slice.
Un gruppo di slice un subset (sottoinsieme) dei macroblocchi in un'immagine codificata
e pu contenere uno o pi Slice.
All'interno di ogni Slice in un gruppo di Slice, i macroblocchi sono codificati in ordine raster.
Se utilizzato un solo gruppo di Slice per immagine, allora tutti i macroblocchi nell'immagine
sono codificati in ordine raster (a meno che l'ASO sia in uso).
Pi gruppi di Slice (descritti nelle precedenti versioni dello standard come FMO - Flexible
Macroblock Ordering) rendono possibile la mappatura della sequenza di macroblocchi codificati
all'immagine decodificata in tanti modi flessibili.
L'allocazione di macroblocchi determinata da una mappatura di macroblocco a gruppo di Slice
che indica a quale gruppo di Slice appartiene ogni macroblocco
e ci sono 6 tipi di mappatura di macroblocco a gruppo di Slice.
Tipo 0, l'interleaved: i macroblocchi run_length sono assegnati ad ogni gruppo di Slice.
Tipo 1, Dispersed: i macroblocchi in ogni gruppo di Slice sono dispersinell'immagine.
Tipo 2, Foreground and Background: tutti i gruppi di Slice tranne l'ultimo sono definiti
come regioni rettangolari all'interno dell'immagine. L'ultimo gruppo di Slice
contiene tutti i macroblocchi non contenuti in ogni altro gruppo di Slice (il background).
Tipo 3, Box-out: viene creato un box a partire dal centro del frame (con la grandezza controllata
dai paramentri dell'encoder) che contiene il gruppo 0,
mentre tutti gli altri macroblocchi sono nel gruppo 1.
Tipo 4, Raster scan: il gruppo 0 contiene i macroblocchi nell'ordine di scansione raster
dall'alto a sinistra e tutti gli altri macroblocchi sono nel gruppo 1.
Tipo 5, Wipe: il gruppo 0 contiene i macroblocchi in ordine di scansione verticale
dall'alto a sinistra e tutti i macroblocchi sono in gruppo 1.
Tipo 6, Explicit: inviato un parametro, lo slice_group_id, per ogni macroblocco
per indicare il suo gruppo di Slice, ovvero la mappatura del macroblocco
totalmente definita dall'utente.
Dopo aver parlato dei sei tipi di mappatura, sempre all'interno del profilo baseline,
doveroso trattare la predizione dei macroblocchi.
Ogni macroblocco codificato in uno Slice H.264 predetto da un dato encodato precedentemente.
I campioni all'interno di un macroblocco sono predetti da campioni nello slice corrente
che gi stato encodato, decodificato e ricostruito ed i campioni in un macroblocco inter
sono predetti da quelli encodati precedentemente.
Viene creata una predizione per il macroblocco - o blocco - corrente (un modello che il pi simile
possibile al macroblocco - o blocco - corrente) dal campione d'immagine che gi stato encodato
(sia nello stesso Slice che nello Slice precedentemente encodato).
Questa predizione sottratta dal macroblocco - o blocco - corrente ed il risultato della sottrazione
(residuo) compresso e trasmesso al decoder, assieme all'informazione richiesta dal decoder
per ripetere il processo di predizione (vettori movimento, modalit di predizione ecc).
Il decoder crea una predizione identica ed aggiunge questa al residuo o blocco decodificato.
L'encoder basa la sua predizione sui campioni d'immagine encodati e decodificati (piuttosto che sui
campioni di frame video originali) in modo da assicurarsi che le predizioni di encoder e decoder
siano identiche.
Parlando di predizioni, la predizione inter crea un modello di predizione da uno o pi frame o field
video precedentemente encodati utilizzando la moto-compensazione basata sui blocchi.

Le differenze importanti dagli standard precedenti includono il supporto ad un ampio raggio

di dimensioni di blocco (da 16x16 a 4x4) e dei precisi sotto-campioni di vettori movimento
(risoluzione di un quarto di campione nella componente di luma).
Nel profilo baseline la componente di luma di ogni macroblocco sono campioni 16x16 che possono
essere divisi in quattro modi e moto-compensati come una partizione di macroblocco univoca
da 16x16, come due partizioni da 16x8, due partizioni da 8x16 o quattro partizioni da 8x8.
Se viene selezionata la modalit 8x8, ogni sotto-macroblocco (quattro da 8x8) all'interno
del macroblocco pu essere diviso in altri 4 modi: come una partizione di sotto-macroblocco
da 8x8, come due partizioni di sotto-macroblocco da 8x4, due partizioni di sotto-macroblocco
da 4x8 o quattro sotto-partizioni da 4x4.
Queste partizioni e questi sotto-macroblocchi danno vita ad un'ampia gamma
di possibili combinazioni all'interno di ogni macroblocco.
Questo metodo di partizionamento dei macroblocchi in sotto-blocchi moto-compensati
di varia grandezza conosciuto come moto-compensazione con struttura ad albero.
richiesto un vettore movimento separato per ogni partizione o sotto-macroblocco
ed ogni vettore movimento deve essere codificato e trasmesso
e la scelta delle partizioni dev'essere encodata nel bit-stream compresso.
Scegliere una dimensione di partizionamento grande (16x16, 16x8, 8x16) significa che
sar richiesto un numero di bit minore per segnalare la scelta dei vettori movimento
ed il tipo di partizione, ma i residui di motocompensazione potrebbero contenere una quantit
di energia significativa nelle aree di frame ad alto dettaglio.
Scegliere una dimensione di partizionamento piccola (8x4, 4x4, ecc) potr anche dare residui
con minore energia dopo la moto-compensazione, ma richiede un numero di bit maggiore
per segnalare i vettori movimento ed il tipo di partizione.
Dunque, la scelta della dimensione di partizionamento ha un impatto significativo
sulle performance di compressione.
In generale, una partizione grande appropriata per le aree omogenee del frame
ed una partizione piccola utile per le aree con pi dettaglio, come i lineamenti nei volti ecc.

Ogni componente di chroma (Cb e Cr) in un macroblocco ha met risoluzione orizzontale

e met risoluzione verticale della componente di luma.
Ogni blocco di chroma partizionato nello stesso modo di quello della componente di luma,
eccetto per il fatto che la dimensione di partizionamento ha esattamente met risoluzione
orizzontale e verticale; in altre parole, una partizione da 8x16 di luma corrisponde
ad una partizione da 4x8 nel chroma ed una partizione di 8x4 nel luma

corrisponde ad una di 4x2 nel chroma e cos via e le componenti orizzontale e verticale di ogni
vettore movimento (uno per partizione) sono dimezzate quando applicate ai blocchi di chroma.
Nell'immagine sottostante possibile vedere la scelta della dimensione di partizionamento
per il luma in un frame residuo (senza motocompensazione).

possibile notare come per le parti meno dettagliate come quelle dello sfondo siano stati scelti
blocchi da 16x16, mentre per quelle pi dettagliate come i lineamenti dei volti o i bordi del libro
sono stati scelti blocchi pi piccoli o sotto-blocchi.
Finora ho parlato molto dei vettori movimento, ma non ho mai analizzato il loro funzionamento e,
dunque, lecito nonch opportuno esplicarlo.
Come sappiamo, ogni partizione o partizione di sotto-macroblocco in un macroblocco codificato
inter predetta da un'area della stessa dimensione nell'immagine di riferimento.
L'offset tra le due aree (il vettore movimento) ha risoluzione di un quarto di campione
per la componente di luma e di un ottavo di campione per le componenti di chroma.
I campioni di luma e chroma nelle posizioni di sotto-campionamento non esistono nell'immagine di
riferimento, per cui necessario crearli utilizzando un'interpolazione tra i campioni vicini codificati.

Nell'immagine soprastante il frame corrente (a) predetto da una regione dell'immagine

di riferimento nelle vicinanze della posizione del blocco corrente.
Se le componenti orizzontale e verticale del vettore movimento sono interi (b),
i campioni rilevanti nel blocco di riferimento esistono (notare i pallini grigi).
Se una od entrambe le componenti di vettore sono valori frazionari (c), i campioni di predizione (i
pallini grigi) sono generati dall'interpolazione tra i campioni adiacenti
ed i frame di riferimento (pallini bianchi).
dunque lecito domandarsi come vengono generati nello specifico i campioni interpolati.
Ebbene, i campioni a met strada tra i campioni di posizione intera (detti campioni half-pel)
nella componente di luma dell'immagine di riferimento sono generati per primi
e sono rappresentati nell'immagine sottostante.

Ogni campione half-pel adiacente a due campioni interi (b, m, s, h) interpolato dai campioni
di posizione intera utilizzando un filtro FIR (Finite Inpulse Response) a sei passi
da 1/32, -5/32, 5/8, 5/8, -5/32. 1/32.
Ad esempio, il campione half-pel b calcolato dai sei campioni interi orizzontali E, F, G, H, I, J.
Abbiamo dunque b = [(E 5F + 20G + 20H - 5I + J) / 32].
In modo del tutto affine, h interpolato da A, C, G, M, R, T.
Quando tutti i campioni orizzontali e verticali adiacenti ai campioni interi sono stati calcolati,
le posizioni half-pel rimanenti sono calcolate interpolando sei campioni orizzontali o verticali
half-pel dal primo set di operazioni.
Ad esempio, j generato da cc, dd, h, m, ee, ff ed il risultato lo stesso sia interpolando j
orizzontalmente, sia interpolandolo verticalmente; inoltre, per generare j,
vengono utilizzate le versioni non arrotondate di h ed m.
L'interpolazione a sei passi relativamente complessa,
ma produce dei buoni risultati ai campioni di dati interi e, quindi, una buona moto-compensazione.
Quando tutti i campioni half-pel sono disponibili, i campioni al quarto passo
(chiamati quarter-pel) sono prodotti da un'interpolazione lineare.

Le posizioni quarter-pel con due campioni di posizione intera o a met orizzontali o verticali
(a, e, c, i, k e d, f, n, q) sono interpolati linearmente tra i campioni adiacenti.
Ad esempio, per a abbiamo: a = [(G + b) / 2].
Le posizioni quarter-pel rimanenti (e, g, p ed r in figura) sono interpolate linearmente
tra le coppie di campioni half-pel diagonalmente opposte; ad esempio, e interpolato tra b ed h.
I vettori movimento quarter-pel nella componente di luma richiedono vettori di otto campioni
nella componente del chroma nel campionamento 4:2:0.
I campioni interpolati sono generati ad intervalli di 8 campioni tra i campioni interi
in ogni componente di chroma utilizzando l'interpolazione lineare.

Ogni posizione a di sotto-campione una combinazione lineare dei campioni interi vicini
di posizione A, B, C e D.

Precisamente, nell'immagine di sopra, abbiamo che dx uguale a 2 e che dy uguale a 3, quindi:

I vettori movimento per ogni partizione possono richiedere un significativo numero di bit,
specialmente se sono scelte partizioni di grandezza ridotta.
I vettori movimento delle partizioni vicine di solito sono molto correlati, quindi
ogni vettore movimento predetto dai vettori di partizioni vicine precedentemente codificate.

Un vettore predetto, MVp (Motion Vector predicted), formato a partire dai vettori movimento
precedentemente calcolati e la MVD (Motion Vector Difference),
ovvero la differenza tra il vettore corrente ed il vettore predetto, encodata e trasmessa.
Il metodo di creazione delle predizioni MVp dipende dalla grandezza di partizione
della moto-compensazione e dalla disponibilit dei vettori vicini.

Supponiamo che E sia il macroblocco corrente, partizione di macroblocco o

partizione di sotto-macroblocco.
Supponiamo che A sia la partizione o sotto-partizione immediatamente a sinistra di E.
Supponiamo che B sia la partizione o sotto-partizione immediatamente sopra E.
Supponiamo infine che C sia la partizione o partizione di sotto-macroblocco sopra ed a destra di E.
Se ci sono pi di una partizione immediatamente a sinistra di E,
la partizione pi alta viene scelta come A.
Se ci sono pi di una partizione immediatamente sopra E,
la partizione pi a sinistra viene scelta come B.
Se tutte le partizioni hanno la stessa grandezza, si verifica la situazione riportata
nella figura soprastante e le partizioni sono da 16x16 (in questo caso).
Se invece le partizioni vicine hanno una grandezza differente da quelle vicine,
si ha la situazione riportata nell'immagine sottostante.

Per le partizioni trasmesse escluse quelle da 16x8 ed 8x16, la MVp (Motion Vector predition)
la media dei vettori movimento per le partizioni A, B e C.
Per le partizioni 16x8, la MVp per la partizione superiore predetta da B
e la MVp per la partizione inferiore predetta da A.

Per le partizioni 8x16, la MVp per la partizione sinistra predetta da A

e la MVp per la partizione destra predetta da C.
Per i macroblocchi skippati la MVp generata come se il blocco fosse encodato in 16x16
in modalit inter.
Se uno (o pi blocchi) precedentemente trasmessi non disponibile
(ad esempio, se fuori dallo Slice corrente), la scelta della MVp varia di conseguenza.
Nella fase di decodifica, la MVp formata nello stesso modo
ed aggiunta alla MVD (Motion Vector Difference).
Nel caso di un macroblocco skippato, non c' alcun vettore differenza decodificato
ed il macroblocco moto-compensato prodotto usando la MVp come vettore movimento.
Procedendo oltre, per quanto riguarda la modalit intra, un blocco di predizione P
formato partendo dai blocchi precedentemente encodati e ricostruiti
ed sottratto dal blocco corrente prima dell'encoding.
Per i campioni di luma, P formato per ogni blocco 4x4 o per un macroblocco da 16x16.
Ci sono un totale di nove possibili modalit di predizione per ogni blocco 4x4 di luma,
quattro modalit per il blocco di luma da 16x16 e quattro modalit per le componenti di chroma.
L'encoder generalmente sceglie la modalit di predizione per ogni blocco
che minimalizza la differenza tra P ed il blocco da encodare.
Un'altra modalit di codifica intra, l'LPCM, abilita l'encoder a trasmettere i valori dei campioni
dell'immagine direttamente (cio senza predizione o trasformazione).
In alcuni casi particolari (si parla di contenuti anomali e/o con bassissimi parametri
di quantizzazione), questa modalit pu risultare essere pi efficiente rispetto al solito
processo di predizione intra, trasformazione, quantizzazione e codifica entropica.
Includendo la modalit LPCM, possibile porre un limite assoluto sul numero di bit
che possono essere contenuti in un macroblocco codificato
senza vincolare la qualit dell'immagine decodificata.

La figura soprastante ha un macroblocco evidenziato che deve essere predetto.

Il campione in alto a sinistra (segnato come M-A in figura) stato precedentemente encodato e
ricostruito ed dunque disponibile nell'encoder e nel decoder come riferimento per una predizione.
I campioni a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p del blocco di predizione P sono calcolati
in base ai campioni A-M come segue.

Modalit 0 (Verticale): i campioni superiori A, B, C, D sono estrapolati verticalmente.

Modalit 1 (Orizzontale): i campioni di sinistra I, J, K, L sono estrapolati orizzontalmente.
Modalit 2 (DC): tutti i campioni in P sono predetti dalla media dei campioni A...D ed I...L.
Modalit 3 (Diagonale inferiore sinistra): i campioni sono interpolati ad un angolo di 45
tra l'inferiore sinistro ed il superiore destro.
Modalit 4 (Diagonale inferiore destra): i campioni sono estrapolati ad un angolo di 45
in basso a destra.
Modalit 5 (Verticale Destra): estrapolazione ad un angolo di circa 26.6 a sinistra della verticale
(larghezza/altezza = ).
Modalit 6 (Orizzontale inferiore): estrapolazione ad un angolo di circa 26.6 sotto l'orizzontale.
Modalit 7 (Verticale sinistra): estrapolazione (o interpolazione) ad un angolo di circa 26.6
a destra della verticale.
Modalit 8 (Orizzontale superiore): interpolazione ad un angolo di circa 26.6 sopra l'orizzontale.
Nella modalit 2, la predizione DC modificata a seconda di quali campioni A-M
sono stati encodati precedentemente e le altre modalit possono essere utilizzate
solo se tutti i campioni di predizione richiesti sono disponibili.
Da notare che se i campioni E, F, G ed H non sono stati ancora decodificati,
il valore del campione D copiato in queste posizioni
e queste vengono marcate come disponibili.
Per le modalit 3-8 i campioni di predizione sono formati da una media pesata
dei campioni di predizioni A-M.
Ad esempio, se viene scelta la modalit 4, il campione in alto a destra di P
(chiamato d nell'immagine precedente) predetto da: B/4 + C/2 + D/4.
Come alternativa alla modalit 4x4 del luma descritta precedentemente,
l'intera componente da 16x16 di un macroblocco pu essere predetta in un'operazione.

Sono disponibili quattro modalit che vanno da 0 a 3.

Modalit 0 (Verticale): estrapolazione dai campioni superiori (H).

Modalit 1 (orizzontale): estrapolazione dai campioni sinistri (V).
Modalit 2 (DC): media dei campioni superiori e sinistri (H + V)
Modalit 3 (Planare): una funzione lineare planare applicata ai campioni superiori e sinistri
H e V e funziona particolarmente bene nelle aree con luma variabile.
Per quanto riguarda invece il chroma, ogni componente di chroma 8x8 di un macroblocco
codificato intra predetta da campioni di chroma precedentemente encodati superiori e/o sinistri
ed entrambe le componenti di chroma utilizzano sempre la stessa modalit di predizione.
Le quattro modalit di predizione sono molto simili alla predizione da 16x16 del luma
descritta un attimo fa e riportata nella figura soprastante, ma la numerazione delle modalit
differente: la modalit 0 la DC, la modalit 1 quella orizzontale,
la modalit 2 quella verticale e la modalit 3 quella planare.
Comunque, la scelta di una modalit di predizione intra per ogni blocco da 4x4 deve essere
segnalata al decoder e questo potrebbe potenzialmente richiedere un grande numero di bit.
Ad ogni modo, con le modalit intra per i blocchi da 4x4 vicini, questi sono spesso correlati.
Ad esempio, supponiamo che A, B ed E siano macroblocchi da 4x4 rispettivamente sinistro,
superiore e corrente.
Se i blocchi 4x4 A e B precedentemente encodati sono predetti utilizzando la modalit 1,
probabile che la miglior modalit per il blocco E (cio il blocco corrente) sia sempre la modalit 1.
Per poter sfruttare la correlazione, per segnalare le modalit intra da 4x4
viene usata la codifica predittiva.
Per ogni blocco corrente E, l'encoder ed il decoder calcolano la modalit di predizione
pi probabile, il minimo delle modalit di predizione di A e B.
Se entrambi i blocchi vicini non sono disponibili (sono esterni allo Slice attuale o non codificati
in modalit intra 4x4), il varo corrispondente A o B settato a 2 (modalit di predizione DC).
L'encoder invia un flag per ogni blocco 4x4, prev_intra4x4_pred_mode.
Se il flag l, viene utilizzata la modalit di predizione pi probabile.
Se il flag 0, viene mandato un altro parametro rem_intra4x4_pred_mode
per indicare un cambiamento di modalit.
Se rem_intra4x4_pred_mode pi piccolo della modalit pi probabile corrente, allora la modalit
di predizione settata su rem_intra4x4_pred_mode,
altrimenti la modalit di predizione settata su rem_intra4x4_pred_mode+1.
In questo modo, solo otto valori di rem_intra4x4_pred_mode sono richiesti (da 0 a 7)
per segnalare la modalit intra corrente (da 0 a 8).
La modalit di predizione per il luma codificato in modalit intra 16x16 o per il chroma codificato
in modalit intra segnalata nell'header del macroblocco e la codifica predittiva della modalit
non utilizzata in questi casi.
Procedendo oltre, il profilo baseline (cos come gli altri profili) supporta un filtro di deblocking
per evitare di produrre spiacevoli artefatti dovuti alla compressione.

Il fenomeno del blocking e le sue cause sono state affrontate precedentemente ed era stata proposta
come soluzione l'utilizzo di un diverso tipo di codifica tramite trasformata,
ovvero quello adottato dal JPEG 2000.
Ebbene, l'H.264 offre una soluzione se cos si pu chiamare al fenomeno di blocking
dovuto alla compressione che altro non che un filtro di deblocking.
Il filtro viene applicato dopo la trasformata inversa prima di ricostruire e salvare il macroblocco
per le predizioni future nell'encoder e prima di ricostruire e riprodurre il macroblocco nel decoder.
Il filtro leviga le estremit dei blocchi, migliorando l'aspetto dei frame ricostruiti
e l'immagine filtrata utilizzata per la predizione moto-compensata di frame futuri.
L'encoder pu decidere di attivare o disattivare il filtro,
cos come di regolarne i parametri di strength e trashold che vanno da 0 a -6 e da 0 a 6.
I valori da 0 a -6 effettuano un deblocking pi leggero, atto alla conservazione dei dettagli.
I valori da 0 a 6 effettuano un deblocking pi pesante, atto alla rimozione degli artefatti di blocking.
Generalmente, vengono utilizzati valori di strength 1 e treshold 1 per le animazioni e di -1, -1
per i film, dove il presente pi dettaglio.

Di default, il filtraggio applicato alle estremit orizzontali e verticali dei blocchi 4x4 in un
macroblocco (eccetto per le estremit ai bordi degli Slice) e viene rispettato il seguente ordine:
1 Vengono filtrati 4 bordi verticali della componente di luma (a, b, c, d).
2 Vengono filtrati 4 bordi orizzontali della componente di luma (e, f, g, h).
3 Vengono filtrati 2 bordi verticali di ogni componente di chroma (i, j).
4 Vengono filtrati 2 bordi orizzontali di ogni componente di chroma (k, l).
Ogni operazione di filtraggio coinvolge tree campioni in ogni parte del bordo.
Per una migliore compresione, si osservi la figura sottostante.

L'immagine rappresenta 4 campioni di ogni lato del bordo (orizzontale e verticale)

nei blocchi adiacenti (p0, p1, p2, p3 e q0, q1, q2, q3).
L'intensit del filtro dipende dal quantizzatore corrente, dalla modalit di codifica,
dai blocchi vicini e dal gradiente dei campioni di immagine attraverso il bordo.

La scelta di filtrare dipende dalla boundary strength (forza di bordo)

e dal gradiente dei campioni di immagine attraverso il bordo.
Il parametro di boundary strength chiamato bS ed scelto secondo le seguenti regole
(per i frame progressivi):
bS = 4: p e/o q sono codificati intra ed il bordo il bordo di un macroblocco.
bS = 3: p e q sono codificati intra ed il bordo non il bordo di un macroblocco.
bS = 2: p o q non codificato intra; p e q contengono coefficienti codificati.
bS = 1 p o q non codificato intra; p o q non contengono coefficienti codificati;
p e q utilizzano immagini di riferimento diverse o un diverso numero di immagini di riferimento
od hanno valori di vettore movimento che differiscono di un campione di luma o pi,
altrimenti: bS = 0.
Il risultato di applicare queste regole che il filtro pi forte dove c' un blocking maggiore, come,
ad esempio, ai bordi di un macroblocco codificato intra o
in un bordo tra blocchi contenenti coefficienti codificati.
Per quanto riguarda la decisione di filtraggio, un gruppo di campioni dal set (p2, p1, p0, q0, q1, q2)
filtrato se e solo se bS maggiore di zero, | p0 q0| minore di Alpha, |p1 p0| minore di Beta
e |q1 q0| minore o uguale a beta.
Alpha e Beta sono i thresholds definiti nello standard
ed aumentano col parametro di quantizzazione media QP dei due blocchi p e q.
L'effetto della decisione di filtraggio che possibile spegnere il filtro quando c'
un cambiamento significativo (gradiente) attraverso il bordo del blocco nell'immagine originale.
Quando il QP piccolo, probabilmente c' solo un piccolo gradiente attraverso il bordo
e tutto il resto semplicemente il dettaglio dell'immagine stessa e non un effetto di blocking e,
proprio perch deve essere conservato, i thresholds di Alpha e Beta sono bassi.
Quando il QP grande, l'effetto di blocking, probabilmente, pi marcato
ed Alpha e Beta sono pi alti in modo da filtrare pi campioni di bordo.
Prendiamo in esame il macroblocco di luma da 16x16 rappresentato nell'immagine sottostante.

All'interno del macroblocco sono stati rappresentati 4 blocchi da 4x4 chiamati a, b, c, d.

Presupponendo che il QP abbia un valore medio-alto, il bordo di blocco tra a e b verr
probabilmente filtrato perch il gradiente attraverso questo bordo piccolo.
Non ci sono dettagli dell'immagine significativi da dover preservare
ed ovviamente questa presenter artefatti di blocking se non filtrato.
Ad ogni modo, c' un significativo cambiamento nel luma attraverso il bordo tra c e d a causa del
dettaglio orizzontale dell'immagine, per cui il filtro viene spento per preservare tale dettaglio.
Osserviamo ora il suo funzionamento a livello analitico ed individuiamo due casi: A e B.
Nel caso A, abbiamo bS {1,2,3} e viene applicato un filtro a 4 passate agli input p1, p0, q0 e q1,
producendo output filtrati p'0 e q'0.
Se |p2 p0| minore del threshold Beta, viene applicato un altro filtro a quattro passate con input
p2, p1, p0 e q0, producendo un output filtrato p'1 (solo luma).
Se |q2 q0| minore del threshold Beta, viene applicato un filtro a quattro passate con input q2, q1,
q0 e p0, producendo un output filtrato q'1 (solo luma).
Nel caso B, abbiamo bS = 4.
Se |p2 p0| minore di Beta e |p0 q0| minore dell'intorno Alpha/4 ed un blocco di luma:
p'0 prodotto dal filtraggio a 5 passate di p2, p1, p0, q0 e q1,
p'1 prodotto dal filtraggio a 4 passate di p2, p1, p0 e q0,
p'2 prodotto dal filtraggio a 5 passate di p3, p2, p1, p0 e q0.
Altrimenti p'0 prodotto dal filtraggio a tre passate di p1, p0 e q1.
Se |q2 q0| minore di Beta e |p0 q0| minore dell'intorno Alpha/4 ed un blocco di luma:
q'0 prodotto da un filtraggio a cinque passate di q2, q1, q0, p0 e p1,
q'1 prodotto da un filtraggio a quattro passate di q2, q1, q0 e p0,
q'2 prodotto da un filtraggio a cinque passate di q3, q2, q1, q0 e p0.
Altrimenti q'0 prodotto da un filtraggio a tre passate di q1, q0 e p1.
Dopo aver analizzato il filtro di deblocking, opportuno mostrare un esempio.
Prendiamo come esempio il seguente frame:

Encodiamo ora tale frame con una quantizzazione costante di 36 (che molto alta).
Disabilitando il filtro di deblocking, il risultato rappresentato nella seguente immagine nella quale
possibile notare grandi artefatti di blocking.

Ovviamente, l'alta quantizzazione ha creato questi artefatti che sono molto utili a livello di studio
poich possibile notare i residui della moto-compensazione gi affrontata in precedenza.
curioso difatti vedere come, nello sfondo, possibile notare i blocchi da 16x16 (blocchi grandi),
mentre il volto e, soprattutto, la mano destra (in movimento ed ad alto dettaglio)
formata da blocchi da 4x4.
Ripetiamo ora lo stesso encoding ma con il filtro di deblocking attivato:

possibile notare che la maggior parte dell'effetto di blocking scomparso e l'immagine

chiaramente starvata (soffre di carenza di bitrate),
ma decisamente pi piacevole all'occhio dell'immagine precedente.
inoltre possibile osservare come i bordi ad alto contrasto (come il contorno del braccio in
contrasto con il pianoforte scuro) sono stati conservati.

I bordi dei blocchi appartenenti a regioni piane (come il muro sullo sfondo), invece,
sono stati smussati.
Per eseguire tale comparison stata encodata una sequenza in entrambi i modi
e sono stati infine selezionati gli stessi frame per poterli comparare.
stato dunque possibile osservare l'efficienza di compressione in termini di peso del video finale.
In questo esempio il contributo del filtro di deblocking minimo, ad ogni modo, la qualit visiva
decisamente migliore, quindi comunque positivo utilizzarlo.
Ripetendo l'encoding a quantizzazione costante 32, possibile vedere ancora come il filtro di
deblocking viene in aiuto (prima immagine senza deblocking, seconda immagine con il
deblocking):

Per la rappresentazione di tali esempi ho parlato di encoding a quantizzazione costante.

Ebbene, l'H.264 utilizza due trasformate a seconda del tipo di dato residuo che deve essere
codificato: la trasformata di Walsh-Hadamard per l'array di 4x4 dei coefficienti DC di luma nei
macroblocchi intra predetti in modalit 16x16, la trasformata di Walsh-Hadamard per l'array di 2x2
dei coefficienti DC del chroma (in ogni macroblocco) e la Trasformata Discreta del Coseno per tutti
gli altri blocchi da 4x4 nei dati residui.

I dati all'interno del macroblocco sono trasmessi in un determinato ordine.

Se il macroblocco codificato in modalit intra 16x16, il blocco viene segnato come -1,
contiene i coefficienti trasformati DC di ogni blocco di luma da 4x4 ed trasmesso per primo.
Poi, i blocchi residui di luma 0-15 sono trasmessi in un determinato ordine
(ma i coefficienti DC nel macroblocco codificato in modalit intra 16x16 non sono inviati).
I blocchi 16 e 17 sono inviati e contengono un array di 2x2 dei coefficienti DC
rispettivamente dai componenti di chroma Cb e Cr.
Infine, i blocchi di chroma residui 18-25 (senza i coefficienti DC) sono inviati.
Per i blocchi di dati residui segnati come 0-15 e 18-25 in figura dopo la predizione di motocompensazione e la predizione intra, viene effettuata un'operazione di trasformata DCT; in realt
tale trasformata non la DCT, ma basata sulla DCT, ed ha alcune differenze fondamentali:
1) una trasformata intera (tutte le operazioni possono essere svolte utilizzando l'aritmetica
degli interi, senza perdita dell'accuratezza di codifica).
2) possibile assicurare una differenza pari a zero nell'operazione di trasformata inversa tra
encoder e decoder (grazie all'aritmetica degli interi).
3) La moltiplicazione scalare (parte della trasformata) integrata nel quantizzatore, riducendo
il numero totale di moltiplicazioni.
Le operazioni di quantizzazione inversa e quella di trasformata inversa possono essere svolte con
l'aritmetica degli interi a 16 bit (eccetto alcuni casi in cui ci sono alcuni residui anomali) con un
solo multiplo per coefficiente, senza alcuna perdita di precisione.
La DCT per i blocchi 4x4 data da:

dove:

Questa moltiplicazione di matrice pu essere fattorizzata alla sequente forma:

CXC^T una trasformata bidimensionale. E una matrice di fattori di scala ed il simbolo indica
che ogni elemento della CXT^T moltiplicato dal fattore di scala nella stessa posizione
nella matrice E (moltiplicazione scalare invece della moltiplicazione di matrice).
Le costanti a e b sono come prima e d c/b (approssimativamente 0.414).
Per semplificare l'implementazione della trasformata, d approssimato a 0.5.
Per essere sicuri che la trasformata rimanga ortogonale, b ha bisogno di essere modificato cos che:

La seconda riga e la quarta riga della matrice C e la seconda e la quarta colonna della matrice C^T
sono scalate da un fattore di due e la matrice E post-scalatura scalata per compensare,
evitando la moltiplicazione per met nella trasformata bidimensionale CXC^T
che potrebbe risultare in una perdita di accuratezza utilizzando l'aritmetica ad interi.
La trasformata in avanti finale diventa:

Questa trasformata un'approssimazione della DCT 4x4, ma a causa del cambiamento apportato ai
fattori d e b, il risultato della nuova trasformata non sar identico a quello della DCT 4x4.
Per rendersi conto delle differenze tra le due, opportuno servirsi di un esempio.
Supponiamo di avere il seguente blocco da 4x4:

L'output della DCT originale :

L'output della trasformata approssimata invece:

Per meglio notare le differenze, stata apportata la sottrazione tra l'output della DCT originale (Y)
e quello della trasformata approssimata (Y'):

C' una chiara differenza tra i coefficienti di output che dipendono da b o d.

Nel contesto del codec H.264, la trasformata approssimata ha una performance di compressione
quasi identica a quella della DCT ed ha numerosi vantaggi.
La trasformata bidimensionale CXC^T pu essere effettuata con l'aritmetica degli interi,
utilizzando solamente addizioni, sottrazioni e spostamenti.
Il range dinamico delle operazioni di trasformata tale che l'aritmetica a 16 bit pu essere utilizzata
tranquillamente (eccetto per alcuni casi anomali, come gi detto sopra),
dato che gli input sono nel range 255 + 255.
Le operazioni post-scalatura Ef richiedono una moltiplicazione per ogni coefficiente
che pu essere assorbito nel processo di quantizzazione.
La trasformata inversa data dalla sequente equazione e lo standard H.264
definisce tale trasformata come una sequenza di operazione aritmetiche:

Questa volta, Y pre-scalato moltiplicando ogni coefficiente con un fattore di pesatura appropriato
dato dalla matrice Ei.
Da notare che i fattori 1/2 nelle matrici C e C^T possono essere implementati da uno spostamento
a destra senza una perdita significativa di accuratezza poich i coefficienti Y sono pre-scalati.
Infine, ricordo che le trasformate in avanti ed inversa sono ortogonali, ovvero:
Per quanto riguarda la quantizzazione, l'H.264 utilizza una quantizzazione scalare.
Il meccanismo di quantizzazione in avanti ed inversa hanno due requisiti principali:
1) Evitare la divisione e/o l'aritmetica a virgola mobile.
2) Incorporare le matrici post e pre-scalatura Ef ed Ei.
L'operazione di quantizzazione in avanti di base :
Dove Yij un coefficiente della trasformata descritta sopra,
Qstep la grandezza del passo di quantizzazione e Zij un coefficiente quantizzato.
Sono supportati 52 valori in totale per il Qstep,
indexati da un parametro di quantizzazione QP (Quantisation Parameter).
Il Qstep raddoppia in grandezza per ogni incremento di 6 nel parametro di quantizzazione QP.
L'ampio range di passi di quantizzazione fa s che l'encoder possa controllare il compromesso
tra bitrate e qualit in modo accurato e flessibile.

I valori del parametro di quantizzazione QP possono essere differenti per luma e chroma.
Entrambi i parametri sono nel range di 0-51 e di default il parametro del chroma Qpc
derivato da Qpy in modo che Qpc sia minore di Qpy per Qpy maggiore di 30.

Esiste inoltre un dato chiamato Picture Parameter Set

nel quale possibile segnalare una mappatura definita dall'utente tra Qpy e Qpc.
I fattori post-scalatura a^2, ab/2 o b^2/4 dell'equazione trattata sopra
sono incorporati nella quantizzazione in avanti.
Per prima cosa, il blocco in input X trasformato per dare un blocco di coefficienti non scalati
W = CXC^T.
Poi, ogni coefficiente Wij quantizzato e scalato in una singola operazione:

PF a^2, ab/2 o b^2/4 a seconda della posizione (i, j).

Per semplificare l'aritmetica, il fattore PF/Qstep implementato nel Reference model software
come una moltiplicazione di un fattore MF ed uno spostamento a destra,
evitando ogni operazione di divisione:

dove

e
che nell'aritmetica ad interi pu essere implementata come:

dove >> indica uno spostamento binario a destra. Nel Reference Model Software,
f 2^gbits /3 per i blocchi intra o 2^gbits /6 per i blocchi inter.
Il Reference Model Software un'implementazione software
che pu essere scaricata gratuitamente e serve per dare un esempio del codec,
piuttosto che essere un'applicazione utilizzabile per s (come invece x264).
Il Reference Model Software utilizzato in questa tesi la versione JM6.1b.

I primi sei valori di MF (per ogni posizione di coefficiente) utilizzati dal Reference Software
Encoder dell'H.264 sono riportati nell'immagine soprastante.
La seconda e la terza colonna dell'immagine (posizioni coi fattori b^2 /4 e ab/2)
sono stati leggermente modificati dai risultati dell'equazione vista in precedenza.
Di fatto, possibile modificare la quantizzazione in avanti in modo da aumentare, per dire,
la qualit percepita in fase di decoding, visto che solo il processo di rescaling (la quantizzazione
inversa) standardizzato.
Per QP maggiore di 5, i fattori MF rimangono invariati, ma il divisore 2^gbits aumenta di un fattore
di due per ogni incremento di sei in QP; ad esempio, avremo qbits = 16 per QP compreso tra 6 e 11,
qbits = 17 per QP compreso tra 12 e 17 e cos via.
Per quanto concerne il rescaling (quantizzazione inversa), invece, l'operazione :
Il fattore di pre-scaling per la trasformata inversa (dalla matrice Ei, contenente valori a^2, ab e b^2
a seconda della posizione del coefficiente) incorporato in questa operazione,
assieme al fattore di scalatura costante di 64 per evitare errori di approssimazione:
W'ij un coefficiente scalato che trasformato dalla trasformata inversa:
I valori all'output della trasformata inversa sono divisi per 64 per rimuovere il fattore di scalatura
(questo pu essere implementato usando solo l'addizione e lo spostamento a destra).
Lo standard H.264 non specifica il Qstep od il PF direttamente.
Difatti, il parametro V = (Qstep.Pf.64) definito per QP compreso tra 0 e 5
e per ogni posizione di coefficiente in modo che l'operazione di scalatura diventi:

Il fattore 2^floor(QP/6) nell'equazione riportata sopra

causa l'aumento dell'output scalato di un fattore di due per ogni incremento di 6 nel QP.
I valori di V definiti nello standard per QP compreso tra 0 e 5 sono riportati nella tabella sottostante:

Se il macroblocco encodato nella modalit di predizione intra da 16x16 (ovvero l'intera

componente luma da 16x16 predetta dai campioni vicini), ogni blocco residuo da 4x4
prima trasformato utilizzando la trasformata descritta sopra:
Il coefficiente DC di ogni blocco 4x4 poi trasformato ancora utilizzando la trasformata di WalshHadamard a 4x4:

WD il blocco di coefficienti DC da 4x4 e YD il blocco dopo la trasformazione.

I coefficienti di output YD(i, j) sono quantizzati per produrre un blocco di coefficienti quantizzati DC:

MF(0,0) il fattore di moltiplicazione per la posizione (0, 0) nella tabella riportata sopra
precedentemente ed f e qbits sono definiti come prima.
In fase di decoding, viene applicata la trasformata di Walsh-Hadamard inversa,
seguita da un rescaling (ma l'ordine non ripristinato come si potrebbe invece pensare):

Lo scaling del decoder fatto da:

V(0,0) il fattore di scala V per la posizione (0, 0) nella tabella riportata di sopra precedentemente.
Siccome V(0,0) costante durante il blocco, il rescaling e la trasformata inversa
possono essere applicati in qualsiasi ordine.
L'ordine specificato (prima la trasformata inversa, poi lo scaling) designato per massimizzare
il range dinamico della trasformata inversa.
I coefficienti DC riscalati W'D sono inseriti nei rispettivi blocchi da 4x4 ed ogni blocco di
coefficienti da 4x4 inversamente trasformato utilizzando la trasformata inversa basata sulla DCT:
In un macroblocco 16x16 codificato intra, la maggior parte dell'energia
concentrata nei coefficienti DC di ogni blocco da 4x4 che tendono ad essere altamente correlati.
Dopo questa trasformazione extra, l'energia concentrata ulteriormente
in un piccolo numero di coefficienti significativi.
Ogni blocco da 4x4 nelle componenti del chroma trasformato come descritto precedentemente.
I coefficienti DC di ogni blocco da 4x4 dei coefficienti del chroma sono raggruppati in blocchi
da 2x2 (WD) e sono trasformati ulteriormente prima della quantizzazione:

La quantizzazione del blocco YD di output data da:

MF(0,0) il fattore di moltiplicazione per la posizione (0, 0) ed f e qbits sono definiti come prima.
Durante la fase di decoding, la trasformata inversa applicata prima dello scaling:

Lo scaling effettuato da:

I coefficienti ri-scalati sono sostituiti nei rispettivi blocchi da 4x4 dei coefficienti del chroma
che sono trasformati come sopra.

Per quanto riguarda i coefficienti DC intra del luma, la trasformata extra aiuta a de-correlare
i coefficienti DC del chroma da 2x2 ed aumenta le performance di compressione.
Il processo completo da un blocco X residuo di input ad un blocco X' residuo di output
descritto di seguito:
Encoding:
1) Input: campioni residui da 4x4, X
2) Trasformata in avanti (non la DCT originale):
(seguita da una trasformata in avanti per i coefficienti DC del chroma o per gli intra-16 del luma)
3) post-scalatura e quantizzazione:
(differente per DC del chroma o DC intra-16 del luma).
Decoding:
4) Scaling del decoder:
(differente per DC del chroma o DC intra-16 del luma).
5) Trasformata inversa (non la trasformata inversa DCT originale):
6) post-scalatura:

7) Output dei campioni residui da 4x4: X''

Per chiarire il tutto, lecito procedere con un esempio.
Supponiamo di avere un QP = 10
Il blocco in input X :

L'output della trasformata W (non la DCT originale) :

MF = 8192, 3355 o 5243 a seconda della posizione del coefficiente.

qbits = 16.
f = 2^qbits /3.

L'output della quantizzazione in avanti Z :

V = 16, 25 o 20 a seconda della posizione.

2^floor (QP/6) = 2^1 cio 2.
L'output del rescale W' :

L'output della trasformata inversa X'' (non la trasformata inversa DCT originale)
dopo la divisione per 64 ed approssimazione :

Nella figura sottostante infine rappresentata la scansione zig-zag per un blocco da 4x4 del luma
(modalit frame):

Passiamo quindi ora ad esplicare la fase di riordinamento.

Nell'encoder, ogni blocco da 4x4 di coefficienti di trasformata quantizzati mappato in un array
di 16 elementi in ordine a zig zag, come mostrato nella figura soprastante, appunto.

In un macroblocco encodato in modalit intra da 16x16, i coefficienti DC (in alto a sinistra)

di ogni blocco di luma da 4x4 sono scansionati e questi coefficienti DC formano un array da 4x4
che scansionato nell'ordine mostrato sempre dalla figura soprastante.
Questo lascia 15 coefficienti AC in ogni blocco di luma
che sono scansionati a partire dalla seconda posizione.
Allo stesso modo, i coefficienti DC da 2x2 di ogni componente di chroma sono scansionati
(in ordine raster) e poi i 15 coefficienti AC di ogni blocco da 4x4 del chroma
sono scansionati a partire dalla seconda posizione.
Al di sopra dello slice layer, gli elementi di sintassi sono encodati come codici binari
di lunghezza fissata o variabile.
Allo slice layer e sotto, gli elementi sono codificati utilizzando sia codici a lunghezza variabile
(VLC Variable Length Codes) che la codifica ad aritmetica adattiva al contesto (CABAC
Context Adaptive Based Arithmetic Coding) a seconda della modalit dell'encoder entropico.
Quando l'entropy_coding_mode (modalit di codifica entropica) settata su 0, i dati dei blocchi
residui sono encodati utilizzando uno schema di codifica adattiva al contesto di lunghezza variabile
(CAVLC Context Adaptive Variable Length Coding) e sono codificate altre unit
codificate a lunghezza varibile utilizzando i codici Exp-Golomb.
I parametri che devono essere encodati e trasmessi includono i seguenti:

Elementi di sintassi sequence-, picture- e slice-layer (contengono gli header ed i parametri).

Tipo di macroblocco mb_type (contiene il metodo di predizione per ogni macroblocco
codificato).
Pattern del blocco codificato (indica quali blocchi all'interno del macroblocco contengono i
coefficienti codificati).
Parametro di quantizzazione ( trasmesso come un valore delta dal precedente valore di QP).
Index di reference frame (identifica i reference frame per la predizione inter).
Vettore movimento (trasmesso come differenza differenza di vettore movimento
dal un vettore movimento predetto).
Dati resudui (coefficiente di dati per ogni blocco da 4x4 o 2x2).

Sono stati nominati prima i codici Exp-Golomb ed quindi bene affrontare

anche la codifica entropica Exp-Golomb.
I codici Exp-Golomb (che sta per Exponential Golomb) sono codici di lunghezza variabile
con una costruzione regolare e basta esaminare le prime parole di codice per rendersene conto:

[M zero][1][INFO]
INFO un field di M-bit che contiene le informazioni.
La prima parola di codice non ha zero iniziali o INFO.

Le parole di codice 1 e 2 hanno un campo INFO di un solo bit, le parole di codice 3-6
hanno un campo INFO a due bit e cos via.
La lunghezza di ogni parola di codice Exp-Golomb (2M + 1) bit ed ogni parola di codice
pu essere costruita dall'encoder sulla base del suo index code_num:

Una parola di codice pu essere decodificata come segue:

1) Leggere M zero seguiti da 1.
2) Leggere M-bit campi INFO.
3) code_num = 2^M + INFO 1.
Un parametro k che deve essere encodato mappato al code_num nelle seguenti maniere:

ue: mappatura diretta unsigned; code_num=k. Viene utilizzato per il tipo di macroblocco,
per l'index di reference frame ed altre cose.
te: una versione della tabella di parole di codice Exp-Golomb nella quale le parole di codice
corte sono troncate.
se: mappatura signed; utilizzata per la differenza di vettori movimento, per il delta QP ed
altre cose.

Code_num=2|k| (k minore o uguale a 0)

Code_num=2|k|-1 (k maggiore di 0)

me: simboli mappati; il parametro k mappato al code_num secondo la tabella specificata

nello standard.

Di seguito riportata una piccola parte del coded_block_pattern per i macroblocchi predetti Inter,
indicando quali blocchi da 8x8 in un macroblocco contengono coefficienti non zero:

Ognuna di queste mappature (ue, te, se ed me) designata per produrre parole di codice brevi
per valori che si presentano frequentemente e parole di codice pi lunghe per valori meno ricorrenti.
Ad esempio, al macroblocco inter P_L_0_16x16 (predizione di una partizione di luma da 16x16 da
un'immagine precedente) assegnato il code_num 0 perch si presenta frequentemente
ed al macroblocco P_8x8 (predizione di una partizione di luma da 8x8 da un'immagine precedente)
assegnato il code_num 3 perch si presenta meno frequentemente.
Infine, la differenza di vettore movimento (MVD Motion Vector Difference)
comunemente ricorrente di valore 0 mappata al code_num 0,
mentre l'MVD meno ricorrente = -3 mappato al code_num 6.
Per quanto riguarda la CAVLC citata in precedenza (Codifica a lunghezza variabile adattiva al
contesto), questa utilizzata per encodare i blocchi residui da 4x4 (e 2x2) ordinati a zig zag
dei coefficienti di trasformata e si serve di numerose caratteristiche dei blocchi da 4x4 quantizzati:
1) Dopo la predizione, la trasformazione e la quantizzazione, i blocchi sono tipicamente sparsi
(contengono per lo pi zero). La CAVLC utilizza una codifica a livello di esecuzione
per rappresentare stringhe di zero in modo compatto.
2) I coefficienti non zero pi alti dopo la scansione a zig zag sono solitamente sequenze di 1 e
la CAVLC segnala il numero di coefficienti ad alta frequenza 1 TrailingOnes
in modo compatto.
3) Il numero di coefficienti non zero nei blocchi vicini correlato.
Il numero di coefficienti encodato utilizzando una tabella scelta
e tale scelta dipende proprio dal numero di coefficienti non zero nei blocchi vicini.
4) Il livello (magnitudine) dei coefficienti non zero tende ad essere pi grande all'inizio
dell'array riordinato (vicino ai coefficienti DC) e pi piccolo intorno alle alte frequenze.
La CAVLC trae vantaggio da questa cosa adattando la scelta della tavola VLC per il
parametro livello basato sul livello delle magnitudini recentemente codificate.
La codifica CAVLC encoda un blocco di coefficienti di trasformata come segue:

1.coeff_token: encoda il numero di coefficienti non zero TotalCoeff

ed i TrailingOnes (uno per blocco).

2.trailing_ones_sign_flag: segno/flag per il valore TrailingOne.

3.level_prefix: prima parte di codice per i coefficienti non zero (uno per coefficiente,
escludendo i TrailingOnes).

3.1level_suffix: seconda parte del codice per i coefficienti non zero (non sempre presente).

4.total_zeros: encoda il numero totale di zero che si verificano

dopo il primo coefficiente non zero (nell'ordine a zig zag; uno per blocco).

5.run_before: encoda il numero di zero precedente ogni coefficiente non zero

nell'ordine di zig zag inverso.

1.coeff_token:
Il primo VLC, il coeff_token, encoda sia il numero totale di coefficienti non zero (TotalCoeffs)
che il numero di valori 1 TrailingOnes.
Il TotalCoeffs pu essere qualsiasi valore da 0 (non ci sono coefficienti nel blocco da 4x4)
a 16 (16 coefficienti non zero) ed il TrailingOnes pu essere qualsiasi valore da 0 a 3.
Se ci sono pi di tre trailing 1s, solo gli ultimi tre sono trattati come casi speciali
e gli altri sono codificati come normali coefficienti.
Ci sono quattro scelte da usare come tabella per l'encoding del coeff_token per un blocco di 4x4;
tre tavole di codice a lunghezza variabile ed un tavolo a lunghezza fissa.
La scelta del tavolo dipende dal numero di coefficienti non zero
nei blocchi codificati precedentemente a sinistra e superiori (rispettivamente nA e nB)
e viene calcolato un parametro nC.
Se i blocchi superiore e sinistro nB ed nA sono entrambi disponibili
(ovvero nello stesso slice codificato):

Se disponibile solo quello superiore: nC=nB.

Se disponibile solo quello sinistro: nC=nA.
Se nessun blocco disponibile: nC=0.
Il parametro nC seleziona la tabella in modo che la scelta del VLC si adatti
al numero di coefficienti codificati nei blocchi vicini (adattiva al contesto).
La tabella 1 fatta per un piccolo numero di coefficienti in modo che bassi valori di TotalCoeffs
sono assegnati a codici particolarmente corti
ed alti valori di TotalCoeff sono assegnati a codici particolarmente lunghi.
La tabella 2 fatta per coefficienti di numero medio (valori di TotalCoeff di 2-4 sono assegnati a
codici relativamente corti).
La tabella 3 fatta per i coefficienti di grande numero e la tabella 4 assegna un codice fissato
di 6 bit ad ogni coppia di valori TotalCoeff e TrailingOnes.
2.trailing_ones:
Per ogni TrailingOne (1) segnalato dal coeff_token, il segno encodato con un singolo bit
(0 = +, 1 = -) in ordine inverso, a partire dal TrailingOne di frequenza pi alta.
3.level_prefix e 3.1 level_suffix:
Il level (segno e magnitudine) di ogni coefficiente non zero rimanente nel blocco encodato
in ordine inverso, partendo dalla frequenza pi alta e lavorando sui coefficienti DC.
Il codice per ogni level fatto da un prefix (level_prefix) ed un suffix (level_suffix).
La lunghezza del suffisso (suffixLength) pu essere tra 0 e 6 bit e la suffixLength adattata
a seconda della magnitudine di ogni level codificato successivo (adattiva al contesto).
Un basso valore di suffixLength adatto a level con basse magnitudini
ed un alto valore di suffixLength adatto a level con alte magnitudini.
La scelta del suffixLength fatta come segue:
1) Inizializzazione del suffixLength a 0 (a meno che non ci siano pi di 10 coefficienti non
zero e meno di tre TrailingOnes; in tal caso, il suffixLength viene inizializzato ad 1).
2) Encoding del coefficiente non zero di frequenza pi alta.
3) Se la magnitudine di questo coefficiente pi grande del threshold predefinito,
il suffixLength viene incrementato. (Se p il primo level ad essere encodato
ed il suffixLength era inizializzato a 0, il suffixLength viene settato a 2).

In questo modo, la scelta del suffix (e quindi il VLC completo)

concordato con la magnitudine dei coefficienti recentemente encodati.
I threshold sono mostrati nell'immagine di seguito:

Il primo threshold zero, il che significa che il suffixLength sempre incrementato

dopo che il primo level di coefficiente stato encodato.
4.total_zeros:
La somma di tutti gli zero precedenti il coefficiente non zero pi alto nell'array riordinato
codificata con la VLC; zero totali.
Il motivo dietro al fatto di inviare un dato VLC separato per indicare gli zero totali
che molti blocchi contengono un certo numero di coefficienti non zero all'inizio dell'array
e questo approccio fa s che i primi zero all'inizio dell'array non debbano essere encodati.
5.run_before:
Il numero di zero precedenti ogni coefficiente non zero (run_before) encodato in ordine inverso.
Viene encodato un parametro run_before per ogni coefficiente non zero,
a partire dalla frequenza pi alta, con due eccezioni:
a) se non ci sono pi zero da encodare, non necessario encodare altri valori di run_before.
b) non necessario encodare il run_before per il coefficiente finale non zero (frequenza pi bassa).
La VLC per ogni run di zero scelta a seconda del numero di zero
che non sono stati ancora encodati (ZerosLeft) e dal run_before.
Ad esempio, se ci sono rimasti solo due zero da encodare, run_before pu assumere solamente
tre valori (0, 1 o 2) cos che non c' bisogno che il VLC sia pi lungo di due bit.
Se ci sono sei zero ancora da encodare, allora il run_before pu assumere sette valori (da 0 a 6)
e la tabella VLC deve essere corrispondentemente grande.
Prima di passare al main profile, bene chiarire quest'ultima parte con degli esempi.
Prendiamo come primo esempio il seguente blocco da 4x4:

blocco riordintato:
TotalCoeffs = 5 (indexati dalla frequenza pi alta 4 alla frequenza pi bassa 0 ).
total_zeros = 3.
TrailingOnes = 3 (ci sono, in effetti, 4 TrailingOnes, ma solo tre possono essere encodati come
casi speciali, come gi detto precedentemente.

Encoding:

Il bit-stream trasmesso per questo blocco :

Decoding:
L'array di output creato dai valori decodificati
e sono evidenziati di seguito i valori aggiunti all'array di output ad ogni stadio:

Il decoder ha gi inserito due zero: il TotalZeros uguale a 3 cos che un altro zero inserito prima
del coefficiente pi basso, facendo s che l'array finale di output sia:

Procediamo ora con un altro esempio.

Supponiamo di avere il seguente blocco da 4x4:

blocco riordinato:
TotalCoeffs = 5 (indexato dalla frequenza pi alta 4 a quella pi bassa 0 )
total_zeros = 2.
TrailingOne = 1.
Encoding:

Il bitstream trasmesso per questo blocco :

Soffermandoci sulla tabella precedente, possibile notare che il Level (3), con un valore di -3,
encodato come caso speciale.
Se ci sono meno di 3 TrailingOnes, allora il primo level non TrailingOne
non pu avere un valore di 1 (altrimenti sarebbe stato encodato come TrailingOne).
Per poter salvare bit, questo level incrementato se negativo (e decrementato se positivo)
in modo che 2 mappa 1; 3 mappa 2 e cos via;
in questo modo, vengono utilizzati VLC pi corti.
Dopo aver encodato il level (3), level_VLC incrementato
perch la magnitudine di questo level pi grande del primo threshold (che zero).
Dopo l'encoding del level(1), con una magnitudine di 4,
viene incrementato ancora perch il level(1) pi grande del secondo threshold (che 3).
da sottolineare infine che il level finale (-2) utilizza un VLC differente dal primo level encodato
(anch'esso -2).
Decoding:

Tutti gli zero sono stati ora decodificati e l'array di output :

Procediamo ora con un ultimo esempio; supponiamo di avere il seguente blocco da 4x4:

blocco riordinato:
TotalCoeffs = 3 (indexati dalla frequenza pi alta 2 a quella pi bassa 0 ).
total_zeros = 7.
TrailingOnes = 3.
Encoding:

Il bit-stream trasmesso per questo blocco :

Decoding:

Il decoder ha inserito quattro zero: il total_zero uguale a 7 in modo che altri tre zero
sono inseriti prima del coefficiente pi basso:

Con questo si chiude la parte dedicata al profilo Baseline

ed possibile quindi passare ad analizzare il Main Profile, implementato per applicativi differenti.

Il Main Profile

Gli applicativi del Main Profile includono (ma non sono limitati) al broadcasting
(televisioni digitali) ed allo storage dei video digitali.
Il Main Profile una sorta di soprainsieme del profilo Baseline, tranne per il fatto che i gruppi
di slice multipli, l'ASO e gli slice ridondanti (tutti inclusi nel profilo Baseline) non sono supportati.
Gli strumenti aggiuntivi utilizzati dal Main Profile sono i B slice (slice bi-predicted
per una migliore efficienza di codifica), la predizione pesata (che garantisce una maggiore
flessibilit nel creare blocchi di predizione moto-compensati), il supporto ai video interlacciati
(la codifica dei field oltre a quella dei frame) ed il CABAC
(un metodo di codifica entropica alternativo basato sulla codifica aritmetica).
Cominciamo dunque ad analizzare gli strumenti aggiuntivi e partiamo proprio dai B slice.
Ogni partizione di macroblocco in un macroblocco codificato inter in un B slice pu essere predetto
da una o due immagini di riferimento, prima o dopo l'immagine corrente (in ordine temporale).
A seconda delle immagini di riferimento salvate nell'encoder e nel decoder,
possibile avere pi opzioni per scegliere i riferimenti di predizione
per le partizioni di macroblocco in un macroblocco di tipo B.
Osserviamo ora la seguente figura:

La figura soprastante raffigura tre esempi: il primo (a) un riferimento passato ed un riferimento
futuro (simile alla predizione delle immagini B gi affrontata nei precedenti video standard MPEG);
il secondo (b) mostra due riferimenti passati ed il terzo (c) mostra due riferimenti futuri.
Gli slice B utilizzano due liste di immagini di riferimento precedentemente encodate: la lista 0
e la lista 1, contenenti immagini a breve ed a lungo termine, come gi affrontato in precedenza.
Queste due liste possono contenere immagini codificate passate e/o future (immagini antecedenti
o precedenti all'immagine corrente nell'ordine di riproduzione).
Le immagini a lungo termine in ogni lista si comportano in modo simile a quanto descritto
quando ho trattato le immagini di riferimento in precedenza.
Le immagini a breve termine, invece, possono essere immagini codificate passate e/o future
e l'ordine d'index di default di queste immagini il seguente:

Lista 0: all'immagine passata pi vicina (sulla base dell'ordine di conteggio delle immagini)
assegnato index 0, seguita da ogni altra immagine passata (aumentando l'ordine di
conteggio delle immagini), seguita da ogni altra immagine futura (aumentando l'ordine di
conteggio delle immagini dall'immagine corrente).

Lista 1: all'immagine futura pi vicina assegnato index 0, seguita da ogni altra immagine
futura, seguita da ogni immagine passata.

Facciamo un esempio: supponiamo che un decoder H.264 salvi 6 immagini di riferimento a breve
termine con ordine di conteggio delle immagini 123, 125, 126, 128, 129, 130.
L'immagine corrente numerata 127.
Tutte e sei le immagini di riferimento a breve termine sono marcate come usate per il riferimento
nella lista 0 e nella lista 1.
Le immagini sono indexate nelle liste 0 ed 1 del buffer a breve termine:

Nei macroblocchi B slice ci sono le seguenti opzioni:

partizione da 16x16: diretta, lista 0, lista 1, bi-predictive.

partizione da 16x8 o 8x16: lista 0, lista 1, bi-predictive (scelta separatamente

per ogni partizione).

partizione da 8x8: diretta, lista 0, lista 1, bi-predictive (scelta separatamente

per ogni partizione).

Il buffer index selezionato inviato come parola di codice Exp-Golomb (gi affrontata
in precedenza) in modo che venga indexata come 0 la scelta pi efficiente di index di riferimento
(con la parola di codice pi corta), ovvero l'immagine precedentemente codificata nella lista 0
e l'immagine successivamente codificata nella lista 1.
Per quanto concerne le opzioni di predizione, le partizioni di macroblocchi in uno slice B
possono essere predette in varie maniere: in modalit diretta, da una predizione moto-compensata
da un'immagine di riferimento appartenente alla lista 0, da una predizione moto-compensata
da un'immagine di riferimento appartenente alla lista 1
o anche da una predizione moto-compensata bi-predictive appartenente alla lista 0 o alla lista 1.
Le diverse modalit di predizione possono essere scelte per ogni partizione;
se utilizzata una partizione di grandezza 8x8, la modalit scelta per ogni partizione 8x8
applicata a tutte le sotto-partizioni all'interno di quella partizione.

La figura soprastante mostra due esempi di combinazioni di modalit di predizione validi.

A sinsitra, abbiamo due partizioni da 16x8 che utilizzano rispettivamente la lista 0
e la predizione bi-predictive ed a destra abbiamo quattro partizioni da 8x8
che utilizzano la predizione diretta, la lista 0, la lista 1 e la predizione bi-predictive.

Nella modalit bi-predictive, il blocco di riferimento (della stessa grandezza del macroblocco di
partizione o sotto-macroblocco di partizione) creato dalle immagini di riferimento della lista 0 e
della lista 1. Due aree di riferimento moto-compensate sono ottenute dalle immagini rispettivamente
della lista 0 e della lista 1 (e quindi sono richiesti due vettori movimento) ed ogni campione di
blocco di predizione calcolato come una media dei campioni di predizione della lista 0
e della lista 1.
Ad eccezione di quando viene utilizzata la predizione pesata, viene utilizzata la seguente equazione:
pred0(i,j) e pred1(i, j) sono campioni di predizione derivati dalle immagini di riferimento
della lista 0 e della lista 1 e pred(i, j) un campione bi-predictive.
Dopo aver calcolato ogni campione di predizione, il residuo moto-compensato
creato dalla sottrazione del pred(i, j) da ogni campione del macroblocco corrente, come al solito.
Per una maggiore comprensione, supponiamo di avere, per esempio, un macroblocco predetto in
modalit B_Bi_16x16 (ovvero bi-prediction del macroblocco completo). Osserviamo di seguito le
aree di riferimento ottenute dalle immagini di riferimento della lista 0

e quelle della lista 1:

Di seguito infine mostrata la bi-prediction formata dalle due aree di riferimento

(predizione non pesata):

I vettori della lista 0 e della lista 1 in un macroblocco bi-predictive (o blocco) sono predetti dai
vettori movimento vicini che hanno la stessa direzione temporale; ad esempio, un vettore per il
macroblocco corrente che punta ad un frame passato predetto da altri vettori vicini che puntano
anch'essi a dei frame passati.
Per quanto riguarda la predizione diretta, invece, non viene trasmesso alcun vettore movimento
per un macroblocco (o partizione di macroblocco) B slice encodato in modalit diretta.
Infatti, il decoder calcola i vettori della lista 0 e della lista 1 sulla base dei vettori precedentemente
codificati ed utilizza questi vettori per la moto-compensazione bi-predictive dei campioni residui
decodificati. Un macroblocco skippato in un B slice, ad esempio, ricostruito dal decoder
utilizzando proprio la predizione diretta.
Un flag nello slice header indica se verr utilizzato un metodo spaziale o temporale
per calcolare i vettori per i macroblocchi o partizioni in modalit diretta.
Procediamo ora col riportare la modalit di calcolo per i vettori predetti della lista 0 e della lista 1
nella modalit diretta spaziale.
I vettori di predizione della lista 0 e della lista 1 sono calcolati utilizzando lo stesso identico metodo
gi affrontato in precedenza. Se il macroblocco co-locato o la partizione nella prima immagine di
riferimento della lista 1 ha un vettore movimento che minore di 1/2 campioni di luma in
magnitudine (ed in alcuni altri casi), uno od entrambi i vettori predetti sono settati a zero, altrimenti
i vettori predetti della lista 0 ed 1 sono utilizzati per la moto-compensazione bi-predictive.
Nella modalit diretta temporale, invece, il decoder compie i seguenti step:
1) Trova l'immagine di riferimento della lista 0 per il macroblocco co-locato o la partizione
nell'immagine della lista 1. Questo riferimento di lista 0 diventa il riferimento di lista 0 del
macroblocco (o partizione) corrente.
2) Trova il vettore della lista 0, MV, per il macroblocco co-locato o partizione nell'immagine
della lista 1.
3) Il vettore di scala MV basato sull'ordine dell'immagine conta la distanza tra quella
corrente e le immagini della lista 1: questo il nuovo vettore MV1 della lista 1.
4) Il vettore di scala MV basato sull'ordine dell'immagine conta la distanza tra le immagini
correnti e quelle della lista 0: questo il nuovo vettore MV0 della lista 0.
Queste modalit sono modificate quando, ad esempio, i macroblocchi di riferimento di predizione
(o partizioni di essi) non sono disponibili o sono codificati intra.
Serviamoci, ancora una volta, di un esempio.
Supponiamo di trovarci nella situazione in cui il riferimento della lista 1 per il macroblocco corrente
si verifica ogni due immagini dopo il frame corrente.

Il macroblocco co-locato nel riferimento della lista 1 ha un vettore MV (+2.5, +5) che punta
all'immagine di riferimento della lista 0 che si verifica tre immagini prima dell'immagine corrente.
Il decoder calcola MV1 (-1, -2) e MV0 (+1.5, +3) che puntano alle immagini della lista 1 e 0
rispettivamente. Questi vettori sono derivati da MV ed hanno magnitudini proporzionali
al conteggio della distanza in ordine di immagini alle immagini di riferimento della lista 0 ed 1.
Per quanto concerne la predizione pesata, altro non che un metodo di modifica (scaling)
dei campioni dei dati di predizione moto-compensata nei macroblocchi di slice P o B.
Ci sono tre tipi di predizione pesata in H.264:
1) Macroblocchi P slice: predizione pesata esplicita.
2) Macroblocchi B slice: predizione pesata esplicita.
3) Macroblocchi B slice: precisione pesata implicita.
Ogni campione di predizione pred0(i, j) o pred1(i, j) scalato da un fattore di pesatura w0 o w1 prima
della predizione moto-compensata. Nelle predizioni pesate esplicite, i fattori di pesatura
sono determinati dall'encoder e trasmessi nello slice header.
Se viene utilizzata la predizione pesata implicita, w0 e w1 sono calcolati sulla base delle relative
posizioni temporali delle immagini di riferimento della lista 0 ed 1.
Viene applicato un fattore di pesatura pi largo se l'immagine di riferimento temporalmente vicina
all'immagine corrente e viene applicato un fattore di pesatura pi stretto
se l'immagine di riferimento temporalmente lontana dall'immagine corrente.
Un'applicazione della predizione pesata di consentire il controllo esplicito o implicito dei relativi
contributi all'immagine di riferimento al processo di predizione moto-compensata. Ad esempio, la
predizione pesata pu essere utile nella codifica di transizioni di dissolvenza
(quando una scena si dissolve in un'altra).
Come stato gi anticipato, con il profilo Main anche possibile encodare video interlacciati.
La codifica efficiente di un video interlacciato richiede strumenti che sono ottimizzati
per la compressione di macroblocchi a field.

Se la codifica a field supportata, il tipo di immagine (frame o field) segnalato nell'header di ogni
slice. Nella modalit di codifica adattiva ai macroblocchi di frame/field (MB-AFF),
la scelta di codifica di field o frame pu essere specificata a livello di macroblocchi.
In questa modalit, lo slice corrente processato in unit di 16 campioni di luma (larghezza)
e 32 campioni di luma (altezza), ognuno dei quali codificato come coppia di macroblocchi.
L'encoder pu scegliere di encodare ogni coppia di macroblocchi come due macroblocchi frame,
oppure come due macroblocchi field e pu selezionare la modalit di codifica ottimale
per ogni regione dell'immagine.
La codifica di uno slice o di una coppia di macroblocchi nella modalit field richiede
delle modifiche al numero di passi di encoding e decoding descritti in precedenza; ad esempio,
ogni field codificato trattato come immagine di riferimento separata per la predizione di slice P
e B, la predizione delle modalit di codifica nei macroblocchi codificati intra ed i vettori movimento
nei macroblocchi codificati inter richiedono di essere modificati a seconda che i macroblocchi
adiacenti siano codificati in modalit frame o field e la scansione di riordinamento seguente
va a rimpiazzare quella a zig zag:

Quando nell'immagine appare il flag entropy_coding_mode settato su 1, viene utilizzato un sistema

di codifica aritmetica per encodare e decodificare gli elementi di sintassi dell'H.264. La codifica
aritmetica binaria adattiva al contesto (CABAC Context based adaptive arithmetic coding)
raggiunge buone performance di compressione attraverso la selezione dei modelli di probabilit
per ogni elemento di sintassi secondo il contesto dell'elemento ed adattando le stime di probabilit
sulla base della statistica locale, nonch usando la codifica aritmetica invece di quella a lunghezza
variabile; tale codifica comporta 4 passi.
1) Binarizzazione. La CABAC utilizza la codifica aritmetica binaria, il che significa che solo le
decisioni binarie (1 o 0) vengono encodate. I simboli di valore non binario (tipo i
coefficienti di trasformata o i vettori movimento generalmente ogni simbolo con pi di due
possibili valori ) binarizzato o convertito in codice binario prima della codifica
aritmetica. Questo processo simile al processo di conversione di simboli di dato
in codice a lunghezza variabile, ma il codice binario encodato a sua volta (dal codificatore
aritmetico) prima della trasmissione.
I passi 2, 3 e 4 sono ripetuti per ogni bit (o bin) dei simboli binarizzati:
2) Selezione del modello di contesto. Un modello di contesto un modello probabile per uno o
pi bin dei simboli binarizzati ed scelto da una selezione di modelli disponibili a seconda
delle statistiche dei dati di simboli recentemente codificati. Il modello di contesto salva la
probabilit di ogni bin di essere 0 o 1.
3) Codifica aritmetica. Un codificatore aritmetico encoda ogni bin secondo il modello di
probabilit scelto e ci sono solo due sub-range per ogni bin e corrispondono a 0 ed 1.

4) Aggiornamento della probabilit. Il modello di contesto selezionato aggiornato sulla base

del valore codificato attuale (ad esempio, se il valore di bin era 1, il primo contatore di
frequenza incrementato).
Proceder ora con l'illustrazione di un esempio.
Supponiamo di voler codificare una differenza di vettore movimento in direzione x,
codificata per ogni partizione o partizione di sotto-macroblocco in un macroblocco intero: mvdx.
1) La binarizzazione del valore mvdx... mvdx mappata alla seguente tabella di parola di codice
non unicamente decodificabile per |mvdx| < 9 (grandi valori di mvdx sono binarizzati
utilizzando la parola di codice Exp-Golomb).

Il primo bit della parola di codice binarizzata bin 1, il secondo bit bin 2 e cos via.
2) Scelta di un modello di contesto per ogni bin. Uno dei tre modelli selezionato per il bin 1,
basato sulla norma L1 di due valori mvdx precedentemente codificati, ek:
dove A e B sono i blocchi immediatamente a sinistra e sopra il blocco corrente.

Se ek piccolo, c' un'alta probabilit che l'MVD corrente abbia una piccola magnitudine e,
al contrario, se ek grande probabile che l'MVD corrente abbia una grande magnitudine.
Viene dunque selezionata una tabella di probabilit (modello di contesto)
ed i bin rimanenti sono codificati usando uno dei quattro ulteriori modelli di contesto:

3) Encoding di ogni bin. Il modello di contesto selezionato offre due stime di probabilit
(la probabilit che il bin contenga 1 e quella che il bin contenga 0) che determinano
due sub-range usati dal codificatore aritmetico per encodare il bin.

4) Aggiornamento dei modelli di contesto. Ad esempio, se per il bin 1 selezionato il modello

di contesto 2 ed il valore del bin 1 0, il contatore di frequenza di zero incrementato in
modo che, la prossima volta in cui questo modello selezionato, la probabilit di uno 0 sar
pi alta. Quando il numero totale di ricorrenze al modello eccede il valore di threshold,
il contatore di frequenza per 0 ed 1 ridimensionato e d maggior importanza
alle osservazioni pi recenti.
I modelli di contesto e gli schemi di binarizzazione per ogni elemento di sintassi sono definiti come
standard. Ci sono circa 400 modelli di contesto per i vari elementi di sintassi. All'inizio di ogni slice
codificato, i modelli di contesto sono inizializzati a seconda del valore iniziale del parametro
di quantizzazione QP (dato che ha un effetto significativo sulla probabilit di occorrenza dei vari
simboli). In aggiunta, per gli slice codificati P, SP e B, l'encoder pu scegliere uno dei 3 set dei
parametri di inizializzazione del modello di contesto all'inizio di ogni slice per consentire l'adozione
di diversi tipi per contenuti video.
Il decoder aritmetico ha tre propriet distinte:
1) La stima della probabilit fatta da un processo di transizione tra 64 stati di probabilit
separati per l'ultimo simbolo meno probabile (LPS Least Probable Symbol) delle due
decisioni binarie (ovvero 0 od 1).
2) Il range R rappresentante lo stato attuale del codificatore aritmetico quantizzato in piccoli
range di valori predefiniti prima del calcolo del nuovo range ad ogni passo,
rendendo possibile il calcolo di nuovi range utilizzando una tabella di ricerca.
3) Per i simboli di dati con probabilit di distribuzione pressoch uniforme sono definiti un
encoding semplificato ed un processo di decoding
(in cui il la parte del modello di contesto bypassata).
La definizione di processo di decoding designata a facilitare le implementazioni di codifica
e decodifica aritmetica a bassa complessit e, soprattutto, la CABAC offre un'efficienza di codifica
migliore rispetto alla VLC.

Il Profilo Extended

Il profilo Extended (conosciuto anche come X Profile nelle versioni precedenti dello standard
H.264) pu essere particolarmente utile per applicativi come lo streaming video. Questo profile
include tutte le caratteristiche del profilo Baseline (cio un sovrainsieme del profilo Baseline,
a differenza del Main Profile), ma aggiunge i B slice, la predizione pesata ed altre caratteristiche
atte al supporto dello streaming tramite network, come lo streaming internet.
Gli slice SP ed SI facilitano il passaggio tra stream codificati in modo differente e la funzionalit
tipo VCR e gli slice di dati partizionati possono avere un buon impatto
negli ambienti di trasmissione pi affini ad errori.
Procediamo dunque a parlare degli strumenti aggiuntivi del Profilo Extended
e cominciamo con gli slice SP ed SI.
Gli slice SP ed SI sono slice codificati in modo speciale che consentono uno switch efficiente tra gli
stream video ed un efficiente accesso random per i decoder video. Un requisito comunemente
richiesto in un contesto di streaming la possibilit da parte del decoder di switchare tra tanti
stream encodati. Ad esempio, lo stesso materiale video codificato varie volte a bitrate diversi per
la trasmissione tramite internet ed il decoder cerca di decodificare lo stream con il bitrate pi alto
che pu ricevere, ma potrebbe essere necessario switchare automaticamente ad uno stream a bitrate
pi basso per motivi relativi alla linea od altro.

Facciamo un esempio pratico: un decoder sta decodificando uno stream A e vuole switchare alla
decodifica dello steam B. Per semplicit, supponiamo che ogni frame sia encodato come un singolo
slice e predetto da una referenza (il frame decodificato precedentemente).

Dopo la decodifica degli slice P A0 ed A1, il decoder vuole switchare dallo stream A allo stream B
e decodificare B2, B3 e cos via. Se tutti gli slice nello stream B sono codificati come slice P,
allora il decoder non avr il frame di riferimento precedentemente codificato corretto
per decodificare B2, proprio perch stava codificando lo stream A prima, ma B2 predetto
dall'immagine precedentemente decodificata B1, che, chiaramente, non esiste nello stream A. Una
soluzione sarebbe quella di codificare il frame B2 come slice I; codificando senza predizione da altri
frame, pu essere decodificato indipendentemente dai frame precedenti nello stream B ed il decoder
pu per tanto switchare tra lo stream A e B. Dunque, quello che pu essere fatto inserire degli
slice I (detti anche punti di switch ad intervalli regolari nella sequenza codificata in modo da
consentire al decoder il passaggio tra uno stream ed un altro. Ad ogni modo, uno slice I contiene
molti pi dati di uno slice P ed il risultato altro non che un picco nel bitrate ad intervalli regolari
(cio ad ogni punto di switch); ecco che entrano in gioco gli slice SP! Gli slice SP sono fatti per
supportare lo switch tra sequenze codificate in modo simile (ad esempio, la stessa source encodata
a bitrate differenti per uno streaming) senza aumentare il bitrate per colpa degli slice I.

Al punto di switch (frame 2 in ogni sequenza), ci sono tre slice SP, ognuno dei quali codificato
utilizzando una predizione moto-compensata (cos da renderli pi efficienti degli slice I).
Lo slice SP A2 pu essere decodificato utilizzando l'immagine di riferimento A1 e lo slice SP B2 pu
essere decodificato utilizzando l'immagine di riferimento B1. La chiave per il processo di switching
lo slice SP AB2 (conosciuto come slice di switching SP), creato in modo che possa essere
decodificato utilizzando l'immagine di riferimento moto-compensata A1 per produrre il frame
decodificato B2 (ovvero l'output del decoder B2 identico sia decodificando B1 seguito da B2,
sia decodificando A1 seguito da AB2). richiesto uno slice SP extra ad ogni punto di switch
(difatti, per switchare nell'altra direzione, sarebbe richiesto un altro slice SP, BA2),
ma sempre pi efficiente che encodare i frame A2 e B2 come slice I.
Di seguito vengono mostrati gli step impiegati quando un decoder deve switchare da uno stream A
ad uno stream B:

L'immagine sottostante mostra un diagramma semplificato del processo d'encoding per uno slice SP
A2, prodotto dalla sottrazione di una versione moto-compensata di A'1 (frame A1 decodificato)
dal frame A2 e codificando poi il residuo:

A differenza dei normali slice P, la sottrazione viene effettuata nel dominio di trasformata
(dopo la trasformata del blocco). Lo slice SP B2 encodato nello stesso modo:

Un decoder che ha decodificato precedentemente il frame A1 pu decodificare lo slice SP A2,

come mostrato nell'immagine sottostante:

Come ho gi detto, questi diagrammi sono semplificati, difatti, in realt, sono richiesti ulteriori passi
di quantizzazione e rescaling per evitare il mismatch tra encoder e decoder.
Di seguito viene mostrato l'encoding dello slice SP AB2 (sempre in maniera semplificata):

Il frame B2 (il frame a cui stiamo switchando) trasformato e la predizione moto-compensata

formata da A'1 (il frame decodificato dal quale stiamo switchando).
Il blocco MC in questo diagramma cerca di trovare il match migliore per ogni macroblocco di frame
B2 utilizzando l'immagine decodificata A1 come riferimento. La predizione moto-compensata
trasformata, poi sottratta da B2 trasformato. Il residuo (dopo la sottrazione) quantizzato, encodato
ed infine trasmesso.
Un decoder che ha precedentemente decodificato A'1 pu decodificare lo slice SP AB2
per produrre B'2:

A'1 moto-compensato (utilizzando il dato di vettore movimento encodato come parte di AB2),
trasformato ed aggiunto al residuo decodificato e scalato (inversamente quantizzato),
poi il risultato inversamente trasformato per produrre B'2.
Se gli stream A e B sono versioni della stessa sequenza d'origine codificati a bitrate differenti,
la predizione moto-compensata di B2 da A'1 (slice SP AB2) dovrebbe essere efficiente.
I risultati mostrano che utilizzando gli slice SP per switchare tra diverse versioni della stessa
sequenza significativamente pi efficiente che inserire slice I nei punti di switch.
Un altro applicativo degli slice SP di garantire accessi random tipo funzionalit VCR.
Ad esempio, uno slice SP ed un slice di switching SP sono posizionati al frame 10.

Un decoder pu fare una predizione in avanti da A0 direttamente ad A10 decodificando A0

e decodificando lo slice SP di switching A0-10 per produrre la predizione A10 da A0.
Il profilo Extended supporta un altro tipo di slice di switching, lo slice SI. Il suo utilizzo simile
allo slice di switching SP, eccetto per il fatto che la predizione formata utilizzando modalit di
predizione intra da 4x4 per i campioni precedentemente decodificati del frame ricostruito.
Questa modalit di slice pu essere utilizzata, per esempio, per switchare da una sequenza ad una
sequenza completamente differente (nel qual caso non sar efficiente utilizzare la predizione motocompensata perch non c' correlazione tra le due sequenze).
Il dato codificato che genera uno slice collocato in tre partizioni di dati distinte: A, B e C,
ognuna delle quali contiene un sottoinsieme dello slice codificato. La partizione A contiene l'header
dello slice ed i dati di header per ogni macroblocco nello slice. La partizione B contiene i dati
residui codificati per ogni slice di macroblocchi intra ed SI. La partizione C contiene dati residui
codificati per i macroblocchi codificati inter (in avanti e bi-direzionali). Ogni partizione pu essere
inserita in una unit NAL separata e pu essere trasportata separatamente.

Se i dati della partizione A sono persi, molto difficile o addirittura impossibile ricostruire lo slice,
visto che la partizione A molto sensibile agli errori di trasmissione. Le partizioni B e C possono
(con molta attenzione alla scelta dei parametri di codifica) essere fatti per essere codificabili
indipendentemente e, di conseguenza, un decoder sar in grado di decodificare (per esempio) solo A
e B o solo A e C, consentendo una migliore flessibilit in un ambiente soggetto ad errori.

Trasporto dell'H.264

Dunque, come accennato, una partizione pu essere inserita in una unit NAL.
Una sequenza video codificata H.264 consiste in una serie di unit NAL, ognuna contenente un
RBSP. Di seguito sono elencati i tipi di RBSP:

Parameter Set: parametri globali per una sequenza, come la dimensione dell'immagine, il
formato video, la mappa di allocazione del macroblocco ecc.
Informazioni supplementari: messaggi supplementari che non sono essenziali per la corretta
decodifica della sequenza video.
Delimitatore d'immagine: bordi tra le immagini video. Se non presente, il decoder deduce il
bordo sulla base del numero di frame contenuti all'interno di ogni slice header.
Slice codificato: header e dati per uno slice; questa unit RBSP contiene i dati video
codificati attuali.
Dato di partizione (A, B, C): tre unit; la partizione A contiene il dato di header per tutti i
macroblocchi nello slice, la partizione B contiene i dati codificati intra e la partizione C
contiene i dati codificati inter.
Fine della sequenza: indica che la prossima immagine (nell'ordine di riproduzione)
un'immagine IDR. (Non essenziale per la corretta decodifica della sequenza).
End of stream: indica che non ci sono altre immagini nel bit-stream.
(Non essenziale per la corretta decodifica della sequenza).
Dato filler: contiene dati fittizi che possono essere utilizzati per aumentare il numero di byte
nella sequenza. (Non essenziale per la corretta decodifica della sequenza).

Gli slice codificati (inclusi gli slice di dati partizionati e gli slice IDR) e l'RBSP di fine sequenza
sono codificati come unit NAL VCL mentre tutti gli altri elementi sono solo unit NAL.
Un esempio di sequenza tipica di unit RBSP mostrata dalla seguente immagine:

Ognuna di queste unit trasmessa in un'unit NAL separata. L'header di unit NAL (un byte)
segnala il tipo di unit RBSP ed i dati RBSP compongono il resto dell'unit NAL.
L'H.264 introduce inoltre il concetto di parameter sets, ognuno dei quali contiene informazioni
che possono essere applicate ad un grande numero di immagini codificate.
Un sequence parameter set contiene parametri che possono essere applicati ad una sequenza
video completa (un set di immagini codificate consecutive).
I paramentri nel sequence parameter set includono un identificativo seq_parameter_set_id,
limitato ai numeri dei frame ed al conteggio dell'ordine delle immagini, al numero di immagini
di riferimento che pu essere usato in decodifica (inclusi i frame di riferimento a breve e lungo
termine), all'altezza ed alla larghezza dell'immagine decodificata, nonch alla scelta di codifica
progressiva (frame) o interlacciata (field).
Il picture parameter set contiene i parametri che sono applicati ad una o pi immagini
decodificate all'interno di una sequenza.

Ogni picture parameter set include, tra gli altri parametri, un identificativo
pic_parameter_set_id, un seq_parameter_set_id, un flag per scegliere la codifica entropica VLC
o CABAC, il numero di gruppi di slice in uso (ed una definizione del tipo di slice nella group map),
il numero di immagini di riferimento nella lista 0 e nella lista 1 che pu essere utilizzato
per la predizione, i parametri di quantizzazione iniziale ed un flag indicante se i parametri di default
del filtro di deblocking devono essere modificati o meno.
Generalmente, uno o pi sequence parameter set e picture parameter set sono inviati al decoder
prima della decodifica degli slice header e dei dati slice. Uno slice header codificato si riferisce
ad un pic_parameter_set_id e questo attiva quel picture parameter set particolare.
Il picture parameter set attivato rimane attivo finch non viene attivato un altro picture parameter
set dal riferimento di un altro slice header. In modo analogo, il picture parameter set si riferisce
al seq_parameter_set_id, che attiva quel sequence parameter set. Il set attivato rimate in vigore
(ovvero i suoi parametri sono applicati a tutte le immagini codificate consecutive)
finch non viene attivato un altro sequence parameter set.
Il meccanismo dei parameter set consente all'encoder di segnalare sequenze importanti
che cambiano non frequentemente ed i picture parameters,
separatamente dagli slice codificati stessi.
I parameter set possono essere inviati prima degli slice che li riferiscono,
o da un altro meccanismo di trasporto (ad esempio, in un canale di trasmissione affidabile
od addirittura cablato nell'implentazione del decoder). Ogni slice codificato
pu richiamare l'immagine rilevante ed i sequence parameters utilizzando un singolo VLC
(pic_parameters_set_id) nello slice header.
Il metodo di trasmissione delle unit NAL non specificato nello standard, ma sono fatte alcune
distinzioni tra i meccanismi di trasporto basate sui pacchetti (network basati sui pacchetti)
e le trasmissioni in uno stream di dati continuo (ambienti a commutazione di circuito).
In un network basato sui pacchetti, ogni unit NAL pu essere trasmessa in un pacchetto separato
e deve essere organizzata nell'ordine corretto di sequenza prima della decodifica.
Negli ambienti a commutazione di circuito, un prefisso di inizio codice (un codice delimitante
unicamente identificabile) inserito prima di ogni unit NAL per creare un byte stream
prima della trasmissione. Questo fa s che il decoder possa cercare lo stream
per trovare il prefisso di inizio codice che identifica l'inizio di un'unit NAL.
In un applicativo comune, il video codificato richiesto di essere trasmesso o salvato con tracce
audio a lui associate ed informazioni aggiuntive. possibile usare un range di maccanismo
di trasporto per farlo, come l'RTP (Real Time Protocol) e l'UDP (User Datagram Protocol).
Molti altri applicativi richiedono il salvataggio di video ed audio multiplexed
ed informazioni aggiuntive (come il playback dei DVD).

Comparison tra H.264 8bit e H.264 10bit

Come gi detto precedentemente quando sono stati analizzati i vari profile,

l'H.264 anche in grado di encodare video a 10bit.
In alcuni applicativi professionali, possibile avere source a 10bit
ed pertanto possibile lavorare con tali video.
Il motivo dietro all'utilizzo del 10bit che, tendenzialmente, possibile avere banding nei file video
codificati dalla stessa source ad 8bit, rispetto a quelli a 10bit.
Per mostrare un esempio pratico, sono state riportate due immagini;
tali immagini sono state estratte da due video encodati dalla stessa source.
I parametri di encoding sono stati lasciati invariati, ma la prima immagine stata estratta dalla
sequenza video codificata con l'encoder H.264 di riferimento a 8bit,
mentre la seconda stata encodata utilizzando l'encoder H.264 di riferimento a 10bit.

 possibile notare come, nella prima immagine, sono stati introdotti artefatti di banding
che sono molto visibili nel cielo:

Encodando la stessa sequenza video dalla stessa source ed estraendo lo stesso frame dal flusso
video codificato a 10bit con gli stessi settaggi, possibile notare come tale sgradevole effetto sia
scomparso:

Dagli esempi codificati possibile inoltre notare come le performance di codifica siano aumentate:
maggiore qualit allo stesso bitrate. Il guadagno medio oscilla dal 5 al 20% per gli encoding fatti
sulle source prese in esame. Questo perch quando il video viene encodato in 10bit, vengono
utilizzati gli strumenti di codifica 10bit ed il processo di codifica eseguito con accuratezza a 10bit,
contro la normale accuratezza a 8bit. In questo modo, c' un minor errore di troncamento,
soprattutto durante la l'importante fase della moto-compensazione.

Dunque, l'efficienza degli strumenti di compressione aumenta e, di conseguenza, c' minor bisogno
di quantizzare per raggiungere un dato bitrate.

Valutazioni finali:

L'H.264 offre un meccanismo di codifica video ottimizzato per l'efficienza di compressione e punta
a venire incontro alla richiesta di applicativi comuni e pratici di comunicazione multimediale.
Grazie alle sue funzionalit, alle sue performance ed ai numerosi settaggi possibili, stato
ampiamente diffuso negli anni precedenti. La possibilit di lavorare su materiale progressivo ed
interlacciato, a 8 e 10bit ed in 4:2:0, 4:2:2 e 4:4:4, nonch gli anni di sviluppo che ha alle spalle ed i
profile adatti ad innumerevoli utilizzi lo hanno reso un codec stabile, maturo, versatile ed affidabile.
3.6.0)

Introduzione all'HEVC H.265

L'ITU-T Video Coding Experts Group (VCEG) cominci a portare avanti degli studi su una
tecnologia in grado di consentire la creazione di un nuovo standard di video compressione (o, per
meglio dire, un miglioramento dello standard H.264/MPEG-4 Part 10 AVC). Furono presto proposte
varie tecniche di miglioramento dello standard H.264 e vennero considerati due approcci
fondamentali per la standardizzazione della nuova tecnologia di compressione: creare un nuovo
standard o creare un'estensione per lo standard H.264. Il progetto venne chiamato H.265 o H.NGVC
(Next-Generation Video Coding) ed era portato avanti dal VCEG. I requisiti preliminari per
l'NGVC erano di ottenere una riduzione del bitrate del 50% rispetto all'H.264 (High profile) allo
stesso livello di qualit soggettiva d'immagine, con una complessit computazionale che va da met
a 3 volte quella dell'High profile. Allo stesso tempo, l'ISO/IEC Moving Picture Experts Group
(MPEG) inizi un progetto simile, chiamato High performance video coding. L'obiettivo
dell'ISO/IEC MPEG era di ottenere una riduzione del bitrate del 50%, ma, dopo mesi e mesi di
sviluppo, erano riusciti ad ottenere solamente il 20% di bitrate in meno rispetto all'H.264 AVC High
Profile. Visti i risultati, dunque, l'ISO/IEC MPEG decise di unire le forze con il VCEG nella
standardizzazione del nuovo codec. Vennero fatte varie proposte (27 in totale) che vennero proposte
al primo meeting tra MPEG ed il VCEG. Durante tale meeting, vennero valutate tutte le proposte
mostrate ed alcune di esse riuscirono ad ottenere una riduzione del bitrate del 50% rispetto all'H.264
(durante i numerosi test proposti) al costo di un aumento del doppio o di 10 volte nella complessit
computazionale, ed alcune proposte raggiunsero una buona qualit soggettiva e risultati di bitrate
con minore complessit computazionale rispetto a quella dell'H.264 High Profile.
Visti gli ottimi risultati ottenuti, la collaborazione venne consolidata e nacque cos l'HEVC
(High Efficiency Video Coding).
3.6.1)

Una trasformata adattiva per la codifica video migliorata

basata sull'H.264/AVC

La trasformata spaziale sempre stato uno strumento di codifica di base negli standard di codifica
video sviluppati in passato. In molti casi stata adottata la DCT in modo che sia l'encoder che il
decoder sapessero, fin dall'inizio, quali funzioni di trasformata di base devono essere usate.
Il lato negativo di questo tipo di approccio che le funzioni di trasformata di base non tengono
conto del contenuto specifico e, di conseguenza, non si adattano ad esso,
riducendo una potenziale maggiore efficienza di codifica. Ad ogni modo,
c' da dire che le funzioni di trasformata di base non devono essere computate n trasmesse.
Comunque, una soluzione alternativa di adottare una trasformata adattiva le cui funzioni di base
cambiano a seconda del contenuto.

Una soluzione che segue questo principio l'adozione della DCT o della MKLT, ovvero una KLT
modificata (trasformata di KarhunenLove), a seconda del blocco da encodare. Questa soluzione
consente l'adattamento al contenuto dei blocchi senza dover trasmettere le funzioni di base KLT
dato che sono equalmente stimate sia dall'encoder che dal decoder.
Questo metodo stato integrato nell'H.264 mod per migliorarne le capacit rispetto all'H.264
normale.
Richiamando quanto detto ad inizio tesi (quando ho analizzato le varie trasformate), la trasformata
di Karhunen-Love la trasformata ottimale in termini di compressione. Ad ogni modo, tutti gli
standard di codifica video attualmente disponibili fanno uso della DCT per rappresentare
le informazioni video nel dominio delle frequenze. Questa scelta data dal fatto che la DCT,
a differenza della KLT, non richiede computazione, codifica e trasmissione all'encoder delle sue
funzioni di base per ogni blocco (ovvero, indipendente dai dati) e pu raggiungere un'efficienza
di compressione pressoch ottimale per i segnali altamente correlati. Difatti, il vantaggio in fase di
compressione ottenuto dalla KLT rispetto alla DCT virtualmente perso dai bit extra richiesti
per rappresentare le sue funzioni di base.
La proposta fu quindi di utilizzare una trasformata adattiva che consentisse una selezione dinamica
tra la DCT e la MKLT (Karhunen-Love modificata) a seconda del contenuto dei blocchi.
Questa soluzione non richiede la codifica e la trasmissione delle funzioni di base della MKLT;
al contrario, queste vengono stimate dall'encoder e dal decoder utilizzando la stessa tecnica ed
assicurando cos le stesse funzioni di trasformata di base per entrambi. In questo modo, possibile
sfruttare l'ottimo funzionamento della KLT, in particolare per i blocchi che sono pi difficili
da codificare utilizzando la DCT, come, ad esempio, i blocchi con bordi diagonali.
Per quanto riguarda la tecnica basata sulla KLT proposta, possibile applicarla solo sui blocchi
soggetti ad errore di predizione in quanto tale trasformata pu portare benefici in termini
di compressione solamente per i blocchi codificati inter.
Questa limitazione imposta dalle caratteristiche della tecnica stessa che descriver di seguito.
3.6.2)

Architettura

Come gi detto sopra, tale soluzione era stata designata per essere integrata nello standard H.264
per portare benefici nell'efficienza di compressione. In tale contesto, l'architettura principale per il
codec video proposto praticamente la stessa dell'architettura dell'H.264, con l'eccezione
dei moduli di trasformata in avanti ed inversa. Ad ogni modo, la sintassi di bit-stream, la semantica
ed il comportamento in fase di decodifica cambiano e la compatibilit con l'H.264 normale
viene meno. L'architettura generale viene riportata nella figura sottostante:

Il processo di encoding si divide in:

Divisione in macroblocchi: per prima cosa, il video in input diviso in macroblocchi da

16x16, cos come nell'H.264 normale. Per la soluzione di codifica proposta, sono state
utilizzate le estensioni FRExt, implicando che anche i blocchi da 8x8 sono disponibili.
Ad ogni modo, in questo caso, solo i blocchi da 8x8 vengono utilizzati per l'operazione
di trasformata, ma gli autori non hanno mai fornito alcuna spiegazione a riguardo.
Trasformata: per trasformare ogni blocco in input, l'encoder decide se utilizzare la DCT
dello standard H.264 oppure la MKLT. Poi, tale scelta viene segnalata al decoder utilizzando
solo 1 bit per ogni blocco codificato. (Nella prossima sezione verr spiegata in dettaglio).
Quantizzazione: i coefficienti di trasformata (DCT o MKLT) per ogni blocco sono poi
quantizzati nello stesso modo dell'H.264 standard.
Codifica entropica: infine, i coefficienti quantizzati sono codificati entropicamente
utilizzando la CAVLC. Per i blocchi DCT trasformati, viene utilizzato l'ordine di scansione
dell'H.264 normale (ovvero la scansione a zig-zag e la scansione alternata),
mentre per i blocchi MKLT i coefficienti sono messi (da quello con varianza pi alta
a quello con varianza pi bassa) in quattro blocchi da 4x4 che sono poi passati all'encoder
entropico.

Per quanto riguarda il decoder, l'unica differenza rispetto all'H.264 normale relativa
al modulo di trasformata, che verr descritto nella prossima sezione. La scelta tra la DCT inversa
e la MKLT inversa fatta secondo le informazioni incluse nel bit-stream dall'encoder per ogni dato.
3.6.3)

Dettagli della Trasformata Adattiva

Come accennato sopra, la soluzione proposta fa uso di una delle due trasformate: la DCT o la
MKLT. Questa trasformata adattiva applicabile solamente ai blocchi codificati inter,
dove solo l'errore di predizione trasformato e quantizzato.
Di seguito viene rappresentata l'architettura per la trasformata in avanti:

Come mostrato in figura, la trasformata adattiva in avanti consiste in pratica nella computazione
della DCT in avanti e della MKLT in avanti, seguite dalla selezione della trasformata
che offre le migliori performance. Per computare la MKLT, l'errore di predizione dev'essere stimato
e le funzioni di base computate sulla base dell'errore di predizione stimato,
come verr descritto di seguito.

Per quanto riguarda la decodifica, la trasformata adattiva inversa consiste nella computazione della
DCT inversa o della MKLT inversa, a seconda di quale trasformata era stata selezionata
in fase di encoding. Ancora una volta, per computare la MKLT, l'errore di predizione dev'essere
stimato e le funzioni di base MKLT computate sulla base dell'errore di predizione stimato,
come verr descritto in seguito.
Mentre la DCT esattamente la stessa di quella usata nell'H.264 per i blocchi 8x8, l'MKLT,
per quanto simile alla KLT standard, ha alcune particolarit che verranno spiegate di seguito.
Dunque, la prossima sezione dedicata a tale trasformata.
Dall'osservazione delle architetture di trasformata adattiva in avanti ed inversa possibile
concludere che il processo della MKLT (Modified Karhunen-Love Transform) include 3 moduli
principali (notare i blocchi colorati nelle immagini soprastanti): stima dell'errore di predizione,
computazione delle funzioni di base MKLT e computazione della MKLT
(sia che sia una KLT in avanti o la KLT inversa).
I tre moduli sono descritti di seguito:
1) Modulo di stima dell'errore di predizione:
L'errore di predizione la differenza tra il blocco originale ed il blocco MCP (Motion Compensated
Prediction) che in H.264 codificato utilizzando vettori movimento associati con uno o pi
immagini di riferimento. In questo contesto, l'unica possibilit di evitare la trasmissione delle
funzioni di base al decoder di stimare l'errore di predizione. Per poterlo fare, presupposto che
l'errore di predizione sia causato dagli errori nel processo di moto-compensazione, in particolare:

errori di interpolazione: nel processo di moto-compensazione, alcuni errori possono

verificarsi quando vengono interpolati i pixel delle immagini di riferimento per
un'accuratezza di un quarto di pixel.

Predizione dei bordi imprecisa: nei blocchi con forti bordi diagonali, i vettori movimento
potrebbero non essere predetti con piena accuratezza, causando un piccolo shift
nella locazione dei bordi tra l'originale ed il blocco MCP.

Seguendo queste supposizioni, stata proposta la stima dell'errore di predizione simulando

tali condizioni. Questo fatto sottraendo versioni spostate e ruotate del blocco MCP dal blocco
MCP stesso che, in questo caso, gioca il ruolo di dato originale.

L'utilizzo del blocco MCP per questa funzione abbastanza naturale in quanto l'unica parte di
informazione che disponibile contemporaneamente sia all'encoder che al decoder. Per semplificare
questa operazione, l'immagine sottostante rappresenta un blocco originale da 8x8 che viene
chiamato (a) , il suo blocco MCP corrispondente che viene chiamato (b)
ed il blocco di errore di predizione che viene chiamato (c).

Il blocco MCP poi spostato verticalmente di -0.25 pixel e ruotato di -0.5 (a) e, per completare
l'operazione, il blocco MCP spostato e ruotato poi sottratto al blocco MCP (b):

Malgrado il cambio di segno quando comparato con l'errore di predizione attuale (prima
immagine, blocco c), la correlazione tra i pixel nella stima dell'errore di predizione (seconda
immagine, blocco b) sembra simile alla correlazione inter-pixel nel vero errore di predizione.
Questo pu essere utile dato che le funzioni di base KLT sono computate dalla matrice di
convarianza del blocco (di errore) di input. Per consentire lo sfruttamento della propriet dell'errore
di predizione descritto sopra nelle varie direzioni, sono stati proposti il seguente spostamento
e la seguente rotazione del blocco MCP per la stima dell'errore di predizione:

Shift (spostamento): il blocco MCP spostato orizzontalmente e verticalmente di:

Rotazione: il blocco MCP ruotato di:

Ad ogni modo, non mai stato rivelato il criterio utilizzato per definire i parametri di spostamento
e rotazione massimi (rispettivamente 0.5 pixel e 0.5).
La combinazione di tutti i 5 parametri di spostamento sulle direzioni orizzontale e verticale
d vita a 25 blocchi MCP spostati (5x5 = 25).
Questi blocchi MCP spostati possono essere ruotati con 3 parametri di rotazione differenti
(-0.5, 0.0 e 0.5), dando vita ad un set di 75 blocchi MCP spostati e ruotati (25x3 = 75).
Poi, la differenza tra il blocco MCP attuale ed il set di blocchi MCP spostati e ruotati
computato in modo da ottenere un set di 75 blocchi di errore di predizione stimato.
Consideriamo come esempio la figura riportata di seguito nella quale viene rappresentato un set
di 25 blocchi di errore di predizione stimato (in questo caso sono rappresentati solo i risultati
per la rotazione -0.5):

Con un set di blocchi di errore di predizione stimato poi possibile computare le funzioni di base
della MKLT.
2) Modalit di computazione delle funzioni di base MKLT
Come detto precedentemente, la KLT una trasformata unitaria ed ortogonale, tuttavia, a differenza
della DCT, non separabile. Inoltre, per trasformare un blocco bidimensionale, necessario prima
convertire tale blocco in una colonna o in una riga di vettori. Poi, la matrice di convarianza del
vettore dev'essere computata per determinare, dopo i suoi autovettori, quali colonne rappresentano
le funzioni di base della trasformata. L'MKLT proposta comprende le caratteristiche della KLT
descritte sopra, tuttavia, in questo caso, ci sono pi blocchi di input rappresentanti un set di blocchi
di errore di predizione stimato (le vere predizioni non sono disponibili al decoder).
Per determinare la matrice di convarianza di questo set, necessario definire la convarianza tra ogni
posizione di pixel. Inoltre, la convarianza tra un pixel in posizioni (u, v) ed un pixel in posizione
(r, s) per un set di blocchi nxn dato da:

Tornando ai tre esempi esposti sopra, possibile determinare la matrice di convarianza per un set di
blocchi di predizione stimato utilizzando l'equazione appena proposta; il risultato questo:

La riga evidenziata mostra la convarianza del pixel in riga 3, colonna 0

(considerata qui come il pixel di riferimento) con i pixel in tutte le altre posizioni.
Riportando questa riga alla sua forma originale bidimensionale, si ha il blocco dei valori di
convarianza mostrato dall'immagine sottostante, dove l'asterisco rosso segnala la posizione
del pixel di riferimento:

Osservando l'immagine soprastante possibile concludere che la convarianza con il pixel di

riferimento pi alta per i pixel in direzione del bordo, se una convarianza positiva (nella stessa
locazione del pixel di riferimento) o negativa (in un altro bordo del blocco).
Con la matrice di convarianza per un particolare set di blocchi di errore di predizione stimato
disponibili, poi possibile determinare gli autovettori e gli autovalori associati:
dove phi la matrice di autovettori e lambda la matrice diagonale di autovalori della matrice
di convarianza .
Successivamente, la matrice transposta della matrice di autovettori phi computata,
risultando in funzioni di base MKLT.
Per l'esempio di sopra, le funzioni di base sono illustrate nell'immagine seguente:

Nella figura soprastante il set di funzioni di base arrangiato in un ordine di scansione raster
orizzontale dov' possibile vedere che le prime funzioni di base (in alto a sinistra) mostrano una
similitudine soggettiva all'errore di predizione attuale.
3) modulo di computazione MKLT
Dopo la determinazione delle funzioni di base MKLT, poi attualmente possibile computare la
MKLT sia per l'encoder che per il decoder. Inoltre, la MKLT in avanti e la MKLT inversa
sono date da:

dove x l'errore di predizione attuale, TMKLT sono le funzioni di base MKLT, CMKLT sono i coefficienti
MKLT, x' l'errore di predizione ricostruito ed i coefficienti MKLT quantizzati sono dati da:

Tornando all'esempio precedente, i coefficienti MKLT del blocco di errore di predizione attuale
sono mostrati di seguito con i coefficienti DCT per lo stesso blocco:

doveroso ricordare inoltre che questo blocco ha un forte bordo diagonale per il quale la DCT
(col fatto che separabile) non molto adatta.
Da tale immagine possibile vedere non solo l'alta compattezza di energia raggiunta dalla MKLT
(con quasi tutta l'energia concentrata nei coefficienti in alto a sinistra),
ma anche possibile compararla con le performance corrispondenti della DCT per lo stesso blocco,
che distribuisce la stessa energia di segnale in input
in un maggiore numero di coefficienti di trasformata.
Un'analisi pi approfondita pu essere fatta per la scansione per ogni trasformata.
Considerando una scansione a zig zag per i coefficienti DCT ed ordinando i coefficienti MKLT
diminuendo la varianza possibile tracciare i coefficienti mostrati nella figura soprastante
in termini di ampiezza e posizione di scansione:

Il grafico rappresentato qua sopra mostra che, per questo esempio, l'MKLT non solo comprime
l'energia del segnale in entrata in meno coefficienti, ma questi coefficienti sono anche i primi ad
essere scansionati! Per quanto riguarda la DCT, invece, l'energia del segnale in input distribuita
in un maggior numero di coefficienti ed, inoltre, la scansione a zig zag sembra non posizionarli
efficientemente per riduzione di ampiezza. Di conseguenza, dovrebbe essere possibile codificare
entropicamente i coefficienti MKLT con meno bit di quelli richiesti per codificare
i coefficienti DCT.
3.6.4)

Valutazione delle prestazioni

Per valutare le performance della soluzione di trasformata adattiva proposta

(cio la selezione dinamica tra MKLT e DCT) questo nuovo metodo stato integrato nell'H.264.
Il test sperimentale stato condotto con sequenze video di risoluzioni QCIF e CIF a 30fps
per le seguenti sequenze video: Foreman, Mobile, Garden ed Husky.
I test sono stati fatti encodando 50 frame di ogni sequenza video e misurando il PSNR risultante
come:

dove MSE l'errore quadrato medio tra i frame del video originale e quelli del video ricostruito.

Per valutare i benefici della soluzione proposta (H.264 mod AT), le sue performance sono state
comparate a quelle dell'H.264 standard (il profilo preciso non specificato). Le sequenze video
codificate utilizzano un pattern regolare di un frame I seguito da frame P per ogni GOP
(Group of Picture). Le sequenze video codificate sono state selezionate come particolarmente
difficili da codificare con la DCT ed hanno un alto dettaglio ed/o blocchi con alta varianza e bordi
diagonali. I grafici riportati di seguito mostrano le performance di distorsione per l'H.264 mod (AT)
proposto e l'H.264 normale (standard):

I grafici soprastanti mostrano un guadagno medio PSNR di 0.5 dB per la soluzione proposta (H.264
mod AT) contro l'H.264 standard. La sequenza Mobile pu addirittura raggiungere un guadagno
di circa 0.9 dB (o, vista da un altro punto di vista, un bitrate minore del 20% per la stessa qualit).

3.7)

HEVC H.265

Dato che tutte le proposte presentate all'HEVC Call for Proposal facevano uso dell'architettura
di codifica di base utilizzata negli standard di codifica video precedenti (in particolar modo
dell'H.264), l'architettura HEVC basata anch'essa sulle modalit di codifica intra ed inter
utilizzando una predizione moto-compensata e la codifica basata su trasformata.
L'architettura HEVC di base presentata nell'immagine sottostante:

Prendendo in conto che la differenza fondamentale tra l'HEVC e l'H.264 per le risoluzioni cui
sono destinati, le proposte inviate si concentravano sullo sfruttamento dell'alta ridondanza spaziale e
temporale disponibile sui contenuti ad alta risoluzione ed UHD. Tali sforzi dettero vita a vari nuovi
strumenti di codifica che cambiano alcuni dei principali moduli architetturali, come evidenziato
nella figura soprastante. Questi nuovi strumenti di codifica sono descritti di seguito, con l'eccezione
di quelli relativi alla codifica tramite trasformata che sono spiegati in modo pi dettagliato
successivamente.

Picture partitioning

Per prima cosa, lo standard HEVC introduce un nuovo schema di partizionamento delle immagini
basato su una nuova definizione dell'unit di codifica e non pi i soliti macroblocchi.
Il concetto di macroblocchi precedente sostituito da una struttura pi flessibile: il CTB
(Coding Tree Block). Con questa struttura, ogni CTB pu avere una grandezza diversa (da 8x8 a
128x128, utilizzando sempre potenze di due) e pu essere ricorsivamente diviso
in un partizionamento a Quad tree.
La grandezza massima di un CTB e la profondit massima del partizionamento quad tree
sono definiti dal level della sequenza video.
L'unit di codifica pi grande denominata LCTB (Largest Coding Tree Block) e quella pi piccola
denominata SCTB (Smallest Coding Tree Block).
Ogni immagine divisa in LCTB non sovrapposti ed ogni CTB caratterizzato dalla sua grandezza
LCTB e la sua profondit gerarchica in relazione col suo LCTB corrispondente.
Per comprendere meglio questa struttura, l'immagine qui sotto rappresenta un esempio dove la
grandezza del LCTB di 128 e la profondit gerarchica massima di 5.

Come mostrato dalla figura soprastante, la struttura ricorsiva rappresentata da una serie di
split flag. Se lo split flag uguale ad 1, allora il CTB corrente diviso (splittato) in quattro
CTB indipendenti, caratterizzati da una profondit incrementata e da met grandezza del CTB
precedente. Il partizionamento dell'immagine fermato quando lo split flag uguale a zero o
quando viene raggiunta la profondit massima, raggiungendo l'SCTB.
Con questa nuova struttura di partizionamento possibile codificare grandi aree omogenee con
blocchi di codifica pi grandi dei precedenti macroblocchi da 16x16 utilizzati dall'H.264,
sfruttando in modo migliore la ridondanza spaziale.
Inoltre, questa struttura di codifica consente una scelta pi flessibile delle grandezze dei blocchi
per una codifica pi efficiente di vari contenuti, puntando a pi applicativi e device.
Quando il processo di divisione (splitting) completato, le leaf nodes del tree gerarchico CTB
diventano PU (Prediction Unit) e possono essere splittate nei seguenti modi:

Intra PU: i PU intra non sono splittati o sono splittati in 4 partizioni uguali.

Inter PU: i PU inter possono avere 4 split simmetrici, 4 split asimmetrici oppure possono
essere splittati con una modalit di partizionamento geometrica. In quest'ultima modalit,
il blocco diviso in due regioni da una retta caratterizzata da due parametri: la distanza tra
la linea di partizione e l'origine del blocco (p), che misurata da una linea perpendicolare
alla linea di partizione, e l'angolo sostenuto da questa linea perpendicolare e l'asse x .

Un esempio rappresentato dalla figura sottostante:

Oltre ai CTB ed ai PU, l'HEVC introduce anche i TU (Transform Unit). Queste unit sono definite
per la trasformazione e la quantizzazione e possono essere larghi tanto quanto la grandezza della
foglia (leaf) CTB corrispondente, ovvero il PU corrispondente.
Il partizionamento dei TU rappresentato anche dai quad trees,
con la loro grandezza massima e la profondit gerarchica segnalate nel bitstream.
Le dimensioni di blocco di trasformata sono obbligate dalle dimensioni di trasformata
massima e minima, rispettivamente 4x4 e 64x64.
Queste caratteristiche sono affrontate nel dettaglio pi avanti,
quando parler del processo di trasformata e quantizzazione.

Intra prediction

Per i blocchi codificati intra, l'HEVC supporta fino a 33 direzioni di predizione spaziale per blocchi
da 8x8 fino a 64x64; questo viene fatto tramite la modalit di predizione planare.
Per i blocchi da 4x4, vengono utilizzate le 9 modalit di predizione gi definite nell'H.264.

Moto-compensazione

Per consentire lo sfruttamento dei vettori movimento con accuratezza a quarto di pixel,
i frame di riferimento devono essere upsampled ed essere in grado di procurare un'interpolazione
di accuratezza a quarto di pixel.
Nell'H.264, per tale interpolazione, viene utilizzato da prima un filtro di Wiener fissato a 6 passi,
seguito da una combinazione bilineare di interi e valori di met pixel.
Con l'HEVC, possibile utilizzare un filtro di interpolazione a 12 passi basato sulla DCT
per ottenere la stessa interpolazione con accuratezza a quarto di pixel.
In questo modo, necessaria una sola procedura di filtraggio, consentendo una semplificazione
dell'implementazione ed una riduzione della complessit del processo di filtraggio.

Filtro di deblocking e filtro in loop

Il filtro di deblocking dell'H.264 stato adattato nell'HEVC per supportare le nuove dimensioni
dei blocchi (che sono pi grandi).
Inoltre, stato aggiunto un filtro di Wiener simmetrico per consentire una riduzione
della distorzione di quantizzazione nei blocchi ricostruiti.

Codifica entropica

L'HEVC offre due tipi di metodo di codifica entropica:

codifica entropica a bassa complessit: per quella a bassa complessit, sono designate 10
tabelle VLC pre-determinate per diverse distribuzioni di probabilit; ogni elemento di
sintassi utilizza una delle 10 tabelle di riferimento. Per la codifica entropica dei coefficienti
di trasformata, viene utilizzato un metodo CAVLC migliorato.
Codifica entropica ad alta complessit: per quella ad alta complessit, viene utilizzata una
variazione della soluzione CABAC definita nell'H.264. Le basi di questo codec sono simili,
ma introdotta la parallelizzazione della codifica e della decodifica entropica.
Queste sono le principali innovazioni introdotte dall'HEVC.
Nella sezione successiva, vengono descritte in modo pi esaustivo i processi di trasformata
e quantizzazione.

Transformata e Quantizzazione:

Una trasformata pi grande pu portare alti benefici in termini di compattezza di energia e ridurre
l'errore di quantizzazione per grandi aree omogenee. Le sequenze in HD tendono ad avere pi
correlazione spaziale, il che significa parti di immagine pi grandi. Inoltre, l'HEVC introduce tre
grandezze di trasformata aggiuntive oltre a quelle gi supportate dall'H.264 (4x4 e 8x8): 16x16,
32x32 e 64x64. Con l'aumentare della grandezza di trasformata, la complessit tende ad aumentare.
Per minimizzare questa complessit, l'HEVC fa uso della versione veloce della DCT. Questo tipo di
algoritmo utilizzato per la sua complessit ridotta e la sua pronta estensione a grandezze
di trasformata pi grandi.
Di seguito viene riportata la fattorizzazione veloce per una DCT di ordine 16:

Nella figura riportata sopra, le constanti di moltiplicazione sono rappresentate da una funzione
sinusoidale di angoli particolari, che pu risultare in operazioni in virgola mobile;
per superare questo ostacolo, vengono utilizzati i seguenti valori predefiniti:

Con questa approssimazione, la trasformata perde la sua propriet ortogonale, ma gli errori associati
sono considerati meno significativi dell'aumento di complessit corrispondente alle operazioni
in virgola mobile.
Oltre alla DCT, vengono adottati due tipi di trasformata direzionale nell'HEVC.

Queste trasformate sono utilizzate quando le funzioni di base DCT

non offrono una buona performance di trasformazione, ovvero per segnali non correlati o blocchi
con gandi bordi diagonali. La prima trasformata direzionale la trasformata rotazionale (ROT),
che applicata come seconda trasformata dopo la DCT per i blocchi da 16x16
e di grandezza superiore. Il principio base dietro a questa trasformata direzionale la rotazione
del sistema di coordinazione di base di trasformata, invece della rotazione del dato in input.
Le matrici di rotazione utilizzate (per le rotazioni verticale ed orizzontale) sono:

L'angolo alpha rappresenta i sei angoli di rotazione possibili. Da questi sei angoli,
solo quattro angoli di rotazioni possono essere quantizzati ed utilizzati per minimizzare
la complessit dell'encoder. In questo contesto, anche doveroso ricordare che, per i TU pi grandi
di 8x8, la ROT applicabile solo ai coefficienti DCT da 8x8 alle frequenze pi basse.
Il secondo tipo di trasformata direzionale la MDDT (Mode-Dependent Direction Transform) che
utilizzata per encodare residui di predizione intra da 4x4 ed 8x8 e da accoppiare alla modalit di
predizione intra selezionata. Le 33 modalit di predizione intra per i blocchi di grandezza 8x8 sono
raggruppate in nove direzioni separate; la MDDT pensata con nove funzioni di base separate,
una per ogni direzione. Queste funzioni di base sono stimate delle statistiche dei residui di
predizione intra per ogni modalit, utilizzando una trasformata separabile basata sulla KLT, la SVD
(Singular Value Decomposition). Questa trasformata utilizzata per sfruttare meglio la ridondanza
spaziale senza aumentare eccessivamente la complessit. In questo modo, la SVD utilizzata prima
in verticale, poi in orizzontale. Ancora una volta, per questioni di calcolo computazionale, le matrici
di trasformata sono approssimate ad un punto fissato.
Dopo l'operazione di trasformata, i coefficienti risultanti sono quantizzati nello stesso modo
descritto per l'H.264 e riarrangiati in vettori monodimensionali per la codifica entropica.
Oltre all'ordine di scansione a zig zag utilizzato per i coefficienti trasformati DCT (inclusi quelli
ottenuti utilizzando la ROT), viene utilizzato un nuovo ordine di scansione per i coefficienti
trasformati MDDT, basato sulla modalit direzionale utilizzata nella codifica di predizione intra.
Cos facendo, possibile compattare i coefficienti non zero all'inizio dei vettori monodimensionali
risultanti.

Profile e Comparison

Per quanto riguarda il profile, l'HEVC vanta vari profile, dedicati a diversi bit-depth,
campionamenti di colore e, pi in generale, ad un diverso utilizzo.
1) Main profile: il main profile consente un bit-depth di 8 bit per campione
con un campionamento a 4:2:0, che il pi comune dal punto di vista dei consumer device.

2) Main 10: il main 10 consente un bit-depth di 8 o 10bit per campione con un campionamento
di 4:2:0. I decoder HEVC conformi al profile Main 10 devono essere in grado di
decodificare bit-stream fatti con il profilo Main. Un bit-depth maggiore consente un maggior
numero di colori (come gi detto sopra). 8 bit per campione consentono 16.78 milioni di
colori, mentre 10 bit per campione consentono 1.07 miliardi di colori e, come visto sopra,
cos facendo possibile evitare il banding. Il profile Main 10 consente una qualit video
migliore visto che pu codificare pi colori e, inoltre, se la source non nativa a 10bit,
questa pu essere portata e codificata a 10bit dal codec.
Main 10 vs Main profile:
Visto che le migliori comparison si fanno sul campo, stata presa una sequenza video di risoluzione
3840x2160 (UHD 4K) nativa a 10bit ed stata encodata prima con il Main 10 e poi col semplice
Main profile. Il video encodato col Main 10 , chiaramente, rimasto a 10bit, mentre quello encodato
col Main profile stato scalato ad 8 bit. Nella sequenza video presa in esame, il profile Main 10
riuscito ad ottenere una riduzione del bitrate del 5% per la codifica dei frame inter, comparato al
Main profile. stato inoltre proposto il Main 10 profile per portare un'alta qualit video per le
applicazioni consumer e tale profilo attualmente in grado di supportare la matrice di colore
Rec.2020, specifica per i video in UHD che in grado di rappresentare fedelmente i colori senza
provocare banding.
3) Main Still Picture profile: il Main Still Picture profile consente l'encoding di una singola
immagine fissa con le stesse limitazioni del Main profile. Come sottoinsieme del Main
profile, il Main Still Picture profile consente un bit depth di 8 bit per campione
ed il campionamento 4:2:0.
Main Still Profile (HEVC) vs JPEG:
Visto che stiamo parlando di codifica delle immagini fisse, alquanto interessante fare una
comparazione tra l'HEVC con un codec di codifica delle immagini lossy;
per tale scopo, ho scelto come avversario iniziale il JPEG.
Dal test effettuato, curioso sapere come la riduzione del bitrate stata del 56.0%
rispetto a quella del JPEG.
Main Still Profile (HEVC) vs JPEG2000:
Come secondo avversario, ho deciso di prendere il JPEG2000 in quanto, come gi visto, utilizza un
metodo di codifica tramite trasformata non a blocchi proprio per evitare gli artefatti di blocking.
Il fatto che utilizzi la trasformata di Wavelet e non la DCT, lo rendeva appetibile per un confronto.
Il risultato del test che l'HEVC ha una riduzione del bitrate del 30.0% rispetto al JPEG2000.
Main Still Profile (HEVC) vs H.264:
Per quanto riguarda l'ultimo test, ho deciso di comparare l'HEVC con l'H.264 ed i risultati ottenuti
sono una riduzione del bitrate del 15.8% da parte dell'HEVC nei confronti dell'H.264.
4) Monochrome profile: Il profile monochrome consente un bit-depth di 8 bit per campione e
supporta il campionamento 4:0:0.
5) Monochrome 12: il monochrome 12 consente un bit-depth da 8 a 12 bit per campione e
supporta il campionamento 4:0:0.
6) Monochrome 16: il monochrome 16 consente un bit-depth da 8 a 16 bit per campione e
supporta il campionamento 4:0:0. I decoder HEVC conformi al profile monochrome 16
devono essere in grado di riprodurre anche il Monochrome ed il Monochrome 12.

7) Main 12: il Main 12 consente un bit-depth da 8 a 12 bit per campione e supporta il

campionamento 4:0:0 ed il 4:2:0. I decoder HEVC conformi al profile Main 12 devono
essere in grado di riprodurre anche il Monochrome, il Monochrome 12, il Main ed il
Main10.
8) Main 4:2:2 10: il Main 4:2:2 10 consente un bit-depth da 8 a 10 bit per campione e supporta
il campionamento 4:0:0, 4:2:0 e 4:2:2. I decoder HEVC conformi al profile Main 4:2:2 10
devono essere in grado di riprodurre anche il Monochrome, il Main ed il Main10.
9) Main 4:2:2 12: il Main 4:2:2 12 consente un bit-depth da 8 a 12 bit per campione e supporta
il campionamento 4:0:0, 4:2:0 e 4:2:2. I decoder HEVC conformi al profile Main 4:2:2 12
devono essere in grado di riprodurre anche il Monochrome, il Monochrome 12, il Main, il
Main10, il Main 12 ed il Main 4:2:2 10.
10) Main 4:4:4: il Main 4:4:4 consente un bit-depth di 8 bit per campione e supporta il
campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4. I decoder HEVC conformi al profile Main
4:4:4 devono essere in grado di riprodurre anche il Monochrome ed il Main.
11) Main 4:4:4 10: il Main 4:4:4 10 consente un bit-depth da 8 a 10 bit per campione e supporta
il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4. I decoder HEVC conformi al profile Main
4:4:4 10 devono essere in grado di riprodurre anche il Monochrome, il Main, il Main 10,
il Main 4:2:2 10 ed il Main 4:4:4.
12) Main 4:4:4 12: il Main 4:4:4 12 consente un bit-depth da 8 a 12 bit per campione e supporta
il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4. I decoder HEVC conformi al profile Main
4:4:4 12 devono essere in grado di riprodurre anche il Monochrome, il Monochrome 12, il
Main, il Main 10, il Main 12, il Main 4:2:2 10, il Main 4:2:2 12, il Main 4:4:4 ed il
Main 4:4:4 10.
13) Main 4:4:4 16 intra: il Main 4:4:4 16 intra consente un bit-depth da 8 a 16 bit per campione
e supporta il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4. I decoder HEVC conformi al
profile Main 4:4:4 16 intra devono essere in grado di riprodurre anche il Monochrome Intra,
Monochrome 12 Intra, Monochrome 16 Intra, Main Intra, Main 10 Intra, Main 12 Intra,
Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 Intra ed il Main 4:4:4 10 Intra.
14) High Throughput 4:4:4 16 Intra: l'High Throughput 4:4:4 16 Intra consente un bit-depth da 8
a 16 bit per campione e supporta il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4. Questo
profile ha un HbrFactor 12 volte pi grande degli altri profile dell'HEVC, il che consente di
avere un bitrate massimo 12 volte pi grande del profile Main 4:4:4 16 intra. Tale profile
creato esclusivamente per la creazione di contenuti professionali e non richiesto ai decoder
di supportare altri profile.
15) Main 4:4:4 Still Picture: il Main 4:4:4 Still Picture consente l'encoding di una singola
immagine con le stesse limitazioni del profile Main 4:4:4; come sottoinsieme del profile
Main 4:4:4, il Main 4:4:4 Still Picture consente un bit-depth di 8 bit per campione e supporta
il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4.
16) Main 4:4:4 16 Still Picture: il Main 4:4:4 16 Still Picture consente l'encoding di una singola
immagine con le stesse restrizioni del profile Main 4:4:4 16 Intra; come sottoinsieme del
profile Main 4:4:4 16 Intra, il Main 4:4:4 16 Still Picture consente un bit-depth da 8 a 16 bit
per campione e supporta il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4.
17) Scalable Main: il profile Scalable Main conforme al Main profile.
18) Scalable Main10: il profile Scalable Main 10 conforme al Main10 profile.
19) Multiview Main: il profile Multiview Main conforme al Main profile.
20) 3D Main: il 3D Main conforme al Main profile e permette la riproduzione 3D.
21) Screen Extended Main: lo Screen Extended Main consente un bit-depth di 8 bit per
campione e supporta il campionamento a 4:0:0 e 4:2:0. I decoder HEVC conformi allo
Screen Extended Main devono essere in grado di riprodurre anche il Monochrome ed il
Main profile.

22) Screen Extended Main 10: lo Screen Extended Main 10 consente un bit-depth da 8 a 10 bit
per campione e supporta il campionamento a 4:0:0 e 4:2:0. I decoder HEVC conformi allo
Screen Extended Main 10 profile devono essere in grado di riprodurre anche il
Monochrome, il Main, il Main 10 e lo Screen Extended Main profile.
23) Screen Extended Main 4:4:4: lo Screen Extended Main 4:4:4 consente un bit-depth di 8 bit
per campione e supporta il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4. I decoder HEVC
conformi allo Screen Extended Main 4:4:4 devono essere in grado di riprodurre anche il
Monochrome, il Main, il Main 4:4:4 e lo Screen Extended Main profile.
24) Screen Extended Main 4:4:4 10: lo Screen Extended Main 4:4:4 10 consente un bit-depth da
8 a 10 bit per campione e supporta il campionamento a 4:0:0, 4:2:0, 4:2:2 e 4:4:4. I decoder
HEVC conformi allo Screen Extended Main 10 devono essere in grado di riprodurre anche il
Monochrome, il Main, il Main 10, il Main 4:2:2 10, il Main 4:4:4, il Main 4:4:4 10, lo
Screen Extended Main, lo Screen Extended Main 10 e lo Screen Extended Main 4:4:4
profile.

Level e Tier

Rispetto all'H.264, con l'HEVC non si hanno solo i level, ma anche i tier.
Per quanto riguarda i level, esattamente come per H.264, servono a formalizzare il bit-stream
facendo s che i produttori possano implementare applicazioni in grado di riprodurre in modo ideale
tutti i video appartenenti alla fascia considerata supportata e tagliando fuori tutti quelli non
supportati, onde evitare possibili incopatibilit, blocchi e quant'altro; in questo contesto entrano in
gioco i tier. In pratica, invece di avere semplicemente un level numerato (1, 2, 2.1, 3, 3.1, 4, 4.1, 5,
5.1, 5.2, 6, 6.1, 6.2) si hanno anche due tier (Main ed High) che ne specificano il bitrate massimo.
L'esigenza di aggiungere i tier nasce dal fatto che alcuni decoder potrebbero essere in grado di
riprodurre un certo numero di kbit/s e, in fase di encoding, se si supera il numero di kbit/s massimo
per un certo livello, si costretti a passare al livello successivo, rischiando di perdere la
compatibilit con alcuni hardware. Grazie ai tier, invece, possibile rimanere nello stesso level
(invece di passare al level successivo). Di seguito sono riportati i tier ed i level:

Per quanto riguarda lo standard, doveroso ricordare che stato recentemente approvato il nuovo
standard bluray disk 4K (UHD).
Secondo il nuovo standard, i video verranno encodati utilizzando l'HEVC a risoluzione UHD
con bit-depth di 10bit, campionamento a 4:4:4 ed una nuova matrice di colore, la BT.2020.

La nuova matrice di colore BT.2020

Con il bisogno di rappresentare contenuti in UHD, cos come c' stata l'evoluzione nel codec,
c' stata una evoluzione anche nella color matrix. doveroso dire che, comunque, anche l'H.264
attualmente in grado di supportare la nuova matrice di colore e che, nell'ultima versione rilasciata,
in grado di riprodurla. Ad ogni modo, la BT.2020 specifica due risoluzioni: 3840x2160 4K UHD e
la 7680x4320 8K (16:9). Per quanto riguarda gli fps, invece, sono possibili 120 fps, 119.88 fps, 100
fps, 60 fps, 59.94 fps, 50 fps, 30 fps, 29.97 fps, 25 fps, 24 fps, 23.976 fps ed consentita la sola
scansione progressiva. Per quanto riguarda il bit-depth, si possono avere sia 10 che 12 bit, con
livelli differenti: per il campionamento a 10bit, il livello del nero definito come codice 64 ed il
picco nominale definito dal codice 940. I codici 0-3 e1020-1023 sono utilizzati per i riferimenti,
i codici da 4 a 63 contengono le informazioni sotto al livello del nero, mentre i codici da 941 a 1019
contengono le informazioni sopra al picco nominale. Per il campionamento a 12 bit, il livello del
nero definito come codice 256 ed il picco nominale definito dal codice 3760. I codici da 0-15 e
4080-4095 sono utilizzati per i riferimenti, i codici da 16 a 255 contengono le informazioni sotto al
livello del nero, mentre i codici da 3761 a 4079 contengono le informazioni sopra al
picco nominale.

La BT.2020 in grado di riprodurre colori che non possono essere riprodotti dalla BT.709 e la
lunghezza d'onda dei colori primari della BT.2020 di 630 nm per il rosso, 532 nm per il verde e
467 nm per il blu. Inoltre, per la BT.2020, stato deciso di utilizzare colori reali (invece di colori
immaginari) in modo da poter riprodurre la BT.2020 a display senza bisogno di conversione.
Inoltre, la BT.2020 supporta l'RGB e l'YCbCr con campionamento a 4:4:4, 4:2:2 e 4:2:0.
La BT.2020 definisce una funzione di trasferimento non lineare che pu essere usata per la
correzione di gamma con RGB ed YCbCr. L'RGB pu essere utilizzato quando richiesta la miglior
qualit possibile, mentre l'YCbCr pu essere utilizzato quando si punta alla compatibilit con le
SDTV ed HDTV e le componenti di luma e chroma nell'YCbCr sono calcolate dall'RGB gi
sottoposto a correzione di gamma. La BT.2020 definisce inoltre una versione linearmente encodata
dell'YCbCr (chiamata YcCbcCrc) e le cui componenti sono calcolate dall'RGB lineare
e poi sottoposte a correzione di gamma.
Dunque, per quanto riguarda la versione a 10bit della BT.2020, viene utilizzata la stessa funzione
utilizzata dalla BT.709, mentre per la versione a 12bit, la BT.2020 ci sono dei cambiamenti nella
funzione di trasferimento non lineare dato che il punto di minimo in un range di intensit di luce da
0 a 1 dove comincia la funzione di trasferimento portato da 0.018 a 0.0181. La funzione di
trasferimento non lineare lineare vicino a 0 e poi trasferisce ad una funzione di potenza il resto del
range di intensit di luce:

dove E il segnale proporzionale all'intensit di luce, E ' il segnale non lineare risultante ed alpha
e beta equivalgono a 1.099 e 0.018 per 10bit e 1.0993 e 0.0181 per 12 bit.

Conclusioni

L'HEVC risulta essere un nuovo utile codec video in grado di ottenere i traguardi designati
e supporta altissime risoluzioni in modo migliore rispetto al suo predecessore, l'H.264.
Ad ogni modo, proprio per la loro differenza strutturale e proprio perch l'H.264 ha ormai tanti anni
di sviluppo alle spalle ed ormai maturo da anni (mentre l'HEVC ancora in piena fase di
sviluppo), opportuno comparare l'efficienza di entrambi i codec.
3.7.1) HEVC vs H.264
Come stato gi detto pi volte, l'HEVC nasce con l'obiettivo di ottenere una riduzione del 50%
rispetto all'H.264 e, tale scopo, stato raggiunto durante la sua implementazione.
Ad oggi, l'HEVC in piena fase di sviluppo, mentre l'H.264 un codec che ha maturato ormai anni
di esperienza ed ha dimostrato di essere affidabile e flessibile per molteplici applicativi.
Mentre una parte del mondo gi proiettata verso il futuro, altri sono ancora restii
al cambiamento; vuoi perch ritengono l'HEVC ancora acerbo, vuoi perch vogliono rimanere con
una tecnologia che hanno imparato a conoscere appieno durante gli anni.
C' da dire che l'applicazione dell'HEVC in ambito professionale (e non) si sta ancora muovendo a
rilento in quanto l'approdo di tale codec ha dovuto fare i conti con gli hardware e con i vari
produttori. Ad oggi, solo un piccolo numero di produttori supporta l'HEVC e solo le schede video
pi recenti hanno la possibilit di avere l'accelerazione hardware (decoding utilizzando l'hardware)
e tutti questi fattori hanno reso l'utilizzo dell'HEVC impossibile per alcuni applicativi.
Se vero che da una parte la complessit aumentata (sia in encoding che in decoding) rispetto
all'H.264, anche vero che la riduzione del bitrate (o l'aumento di qualit a pari bitrate)
un vantaggio da non sottovalutare (nonch scopo del progetto).

Inoltre, l'HEVC in grado di supportare altissimi frame rate (immagini al secondo),

raggiungendo i 300 fps in decodifica per un video in 4K, cosa che l'H.264 non in grado di fare.
Sempre riguardo al fatto della complessit, potrebbe inoltre tornare scomodo durante gli
applicativi professionali avere un tempo di encoding molto superiore a quello dell'H.264 per la
stessa qualit finale. Ad ogni modo, il progetto HEVC nasce con l'idea di concentrarsi sulla
parallelizzazione, il che significa che dovrebbe essere in grado di sfruttare motherboard dual socket
(multiprocessore), nonch riuscire a sfruttare appieno processori con un elevato numero di core,
cosa che l'H.264 non dovrebbe essere in grado di fare, vista la natura della sua architettura.
Inoltre, verr comparata la complessit dell'encoding in H.264 con le massime impostazioni
possibili in termini di compressione con un possibile equivalente in HEVC (sia in codifica che in
decodifica). inoltre doveroso affermare che, visto che il crf dell'H.265 (HEVC) non equivale al crf
dell'H.264 (AVC), stato deciso di adottare la modalit a bitrate costante in quanto unico vero
mezzo di comparazione. Il test stato effettuato grazie a numerosi candidati che si sono sottoposti
alla prova per confrontare i due video proposti ad ogni encoding.
Test1:
x264 preset medium, profile main, bitrate 2500 kbit/s, risoluzione 1920x1080, 23,976 fps, 4:2:0
x265 preset medium, profile main, bitrate 2500 kbit/s, risoluzione 1920x1080, 23,976 fps, 4:2:0
In questo primo test, stato possibile notare come il 95% delle persone sottoposte al test qualitativo
visivo stato concorde nell'affermare che l'H.265 (x265) ha raggiunto performance qualitative
migliori rispetto al suo predecessore H.264 (x264). 2500 kbit/s un bitrate assolutamente troppo
basso per l'H.264 ad una risoluzione di 1080p e sarebbe accettabile su una risoluzione di 720p,
mentre accettabile nell'H.265 che si comportato meglio e non ha creato vistosi artefatti e
banding tipici di un encoding starvato (che soffre da carenza di bitrate).
Test2:
x264 preset medium, profile High, bitrate 3000 kbit/s, risoluzione 1920x1080, 23,976 fps, 4:2:0
x265 preset medium, profile Main, bitrate 3000 kbit/s, risoluzione 1920x1080, 23,976 fps, 4:2:0
Per questo secondo test stato preso un bitrate pi veritiero in termini di FULL HD per l'H.264;
si tratta del bitrate utilizzato dal noto servizio di streaming Crunchyroll, i cui numerosi utenti
affermano che abbia una qualit accettabile il pi delle volte. Anche sfruttando il profilo High ed un
bitrate tradizionalmente alto, l'H.264 risulta ancora una volta essere inferiore rispetto all'H.265 che
riesce a comportarsi generalmente meglio nelle immagini che richiedono pi attenzione quali quelle
a bassa luminosit (con molti neri) e sui cambio scena. Ancora una volta, l'80% delle persone
sottoposte al test d'accordo sulla vittoria dell'H.265.
Test3:
x264 preset medium, profile High10, bitrate 3000 kbit/s, risoluzione 1920x1080, 23,976 fps, 4:2:0
x265 preset medium, profile Main10, bitrate 3000 kbit/s, risoluzione 1920x1080, 23,976 fps, 4:2:0
Questa volta sono state utilizzate le stesse impostazioni del test precedente, ma stato utilizzato il
profilo a 10bit per entrambi i codec. In questo caso, l'H.264 ha fatto buon utilizzo del profilo a
10bit, andando a correggere buona parte degli errori di banding causati dalla precedente scalatura a
8bit, ma, in casi di movimenti eccessivamente veloci in scene scure e/o con gradienti seguite da
cambio scena repentini, diventa comunque difficile per tale codec non produrre degli artefatti.

L'approccio dell'H.265 in questo senso diverso e, proprio per coprire gli artefatti che si potrebbero
venire a creare in queste scene, quando sottoposto a tensione, decide di blurrare l'immagine.
L'immagine risultante risulta blurrata e quasi leggermente piallata in alcuni punti, ma solo se
sottoposta alla visione di un occhio allenato; in generale, nel video in movimento ed ad una prima
visione, questa risulta molto pi piacevole rispetto a quella prodotta dall'H.264 (che contiene
artefatti). In altre parole, la leggera perdita di dettaglio, totalmente trascurabile visto l'ottimo
risultato finale raggiunto; difatti, il 75% degli intervistati ha trovato l'immagine dell'H.265 pi
piacevole alla vista rispetto a quella dell'H.264.
Test4:
x264 preset medium, profile High, crf 25, risoluzione 1280x720, 23,976 fps, 4:2:0
x264 preset medium, profile Main, crf 25, risoluzione 1280x720, 23,976 fps, 4:2:0
Come gi detto sopra, il crf dell'H.264 completamente diverso da quello dell'H.265 e questo test
atto proprio a dimostrarlo. Mentre l'H.264 con il crf 25 riesce a raggiungere buone performance di
compressione, il bitrate finale seppur oscilla per mantenere la stessa qualit finale risulta essere
troppo basso per numerose scene, creando artefatti vistosi. L'H.265 ha invece un buon rapporto di
compressione con il crf25 e riesce a produrre un'immagine abbastanza pulita in molte occasioni,
passando ancora una volta il test con l'85% di voti. Ad ogni modo, i due codec non sono
comparabili proprio perch i due crf utilizzati non sono uguali (a livello pratico).
Test 5:
x264 preset medium, profile High10, bitrate 5000 kbit/s, risoluzione 3840x2160, 23,976 fps, 4:2:0
x265 preset medium, profile Main10, bitrate 5000 kbit/s, risoluzione 3840x2160, 23,976 fps, 4:2:0
Visto che l'H.264 aggiornato all'ultima versione risulta essere in grado di encodare video in 4K,
stato deciso di affrontare uno scenario ideale per l'H.265 in cui confrontare i due codec.
In tale scenario, l'H.264 risulta essere incapace di gestire una risoluzione cos elevata e richiede
bitrate ben pi alti per encodarla in maniera accettabile. La codifica basata sui macroblocchi mostra
tutta la sua inefficienza ed il codec fa fatica a sfruttare la correlazione spaziale nelle aree omogenee,
quali, ad esempio, gli sfondi, risultando in un malo uso del bitrate totale assegnato (5000 kbti/s) e
producendo notevoli artefatti a video. In questo scenario, tutti i nuovi strumenti introdotti nell'H.265
fanno la differenza ed il livello qualitativo finale incomparabile, garantendo al nuovo codec la
vittoria alla quasi unanimit (98%) in questo test.
Test 6:
x264 preset placebo, profile Hi444 10p, me esa, subme 11, crf 16, risoluzione 1280x720, 23,976 fps
x265 preset placebo, profile Main444 10p, crf 20, risoluzione 1280x720, 23,976 fps
In questo test stato invece preso un ambito in cui l'H.264 in grado di brillare: un HD da encodare
con campionamento a 4:4:4, 10bit con un crf sufficientemente basso (per garantire un'altissima
qualit, fedele all'originale) compensato dalla ricerca della compressibilit pi alta possibile data dal
preset placebo, me esa e subme 11. In questo scenario, l'H.264 riesce a codificare il file master
video non compresso in maniera eccellente, producendo un file di dimensioni ridotte (24 minuti)
ad una qualit eccellente. I dettagli sono preservati ed il campionamento a 4:4:4 evita perdite
percettibili nel campo del chroma che, grazie ai 10bit ed al bitrate sufficientemente alto dato dal
crf16, non presenta banding in alcuna scena.

Il tempo di encoding notevolmente alto, soprattutto per i reference frame impostati a 16 e per il
grande lavoro svolto in fase di moto-compensazione e ricerca della corellazione spaziale
e temporale. L'approccio dell'H.265, invece, molto diverso. Mentre il preset medium raggiunge
in genere un buon rapporto di velocit/compressione in questo codec (seppur sia molto pi lento
ed esoso di risorse dell'H.264), il preset placebo non risulta essere all'altezza delle aspettative.
Utilizzando tale preset, si ha un aumento del costo computazionale in fase di encoding di oltre il
60% in fase di encoding (rispetto al preset medium), ma il guadagno all'atto pratico in MB
del solo 20%. L'H.265, sulla stessa macchina, ha impiegato il 72% di tempo in pi rispetto
all'H.264 in encoding, ma ha comportato un guadagno in termini di peso del solo 42%.
Quando stato proposto il test qualitativo, infine, molte persone hanno titubato molto nello
scegliere quale dei due risultati fosse migliore e molti hanno scelto di valutare le immagini come
aventi la stessa qualit finale. Questo, ancora una volta, sancisce la vittoria dell'H.265
dal punto di vista della dimensione finale del file, ma al costo di un grande incremento del costo
computazionale in fase di encoding che non da sottovalutare in alcuni ambiti.

Valutazioni Finali sui test

I test presi in esame hanno messo in luce i pregi ed i difetti dell'H.265: mentre questi risulta essere
molto performante ad alte risoluzioni, il suo impiego risulta comunque molto difficile per colpa dei
problemi a livello hardware. Inoltre, il preset placebo dell'H.265 comporta un alto incremento del
costo computazionale, senza portare un pari incremento in termini di compressione.
Per quanto riguarda invece la parallelizzazione in ambito server, stato verificato che l'H.265
in grado di sfruttare schede madri dual socket intel che montano due processori Xeon di ultima
generazione, aiutando cos a distribuire in maniera uniforme il costo computazionale
ed aiutando l'adozione di tale codec anche in ambito professionale.
Di seguito vengono riportati ulteriori test effettuati a default cambiando i vari crf per ottenere un
rapporto tra quelli impiegati dall'H.264 e quelli dell'H.265, tenendo conto di bitrate e velocit di
encoding (fps medi).
I file encodati sono FULL HD 1920x1080p (progressivi) a 23,976 fps, il level stato lasciato
unresticted (a puro scopo di test) e la sequenza video stata scelta in modo da essere
particolarmente difficile da codificare.
La macchina utilizzata per effetturare gli encoding un server
che monta un Intel Xeon E5 1650 v2 da 12 MB di cache l3, set di istruzioni AVX supportate, 6 core,
12 thread, 3.5 GHz. Entrambi i codec sono ad 8 bit:

4) Utilizzo delle trasformate nei codec di codifica audio

Dopo aver trattato i vari tipi di codifica video, giunto il momento di completare il ciclo della
tesi trattando la codifica audio. Analogamente a quanto visto per la codifica delle immagini fisse e
la codifica delle immagini in movimento, anche per la codifica audio si parla di codec lossy e
lossless e l'intento delle varie codifiche (a livello concettuale) pressoch uguale a quello gi
trattato precedentemente. Prima di tutto, per, bene porre alcune premesse: un uccellino che canta,
una madre che parla al telefono col figlio od ancora una sinfonia di musica classica sono tutti
esempi di segnali audio; difatti tutto quello che sentiamo un segnale audio ed un dato codec deve
essere in grado di poter codificare in maniera ottimale tante tipologie di segnale audio differenti,
visto che la natura del segnale incredibilmente varia.
La rappresentazione digitale di un segnale audio non compresso, ad oggi, pressoch identica al
formato CD sviluppato per il mondo consumer anni fa. Esistono, chiaramente, anche altri formati
tipo il DAT, ma questi sono per lo pi utilizzati negli studi per lo storage ad alta qualit.
Il segnale audio nel formato CD campionato a 44.1 kHz usando un PCM a 16bit (Pulse Core
Modulation), che risulta in un bitrate non compresso di 705.6 kbps per gli audio in modalit canale
mono ed 1.41 Mbps nella modalit canale stereo. Ad ogni modo, questi bitrate altissimi non sono
affatto positivi per la trasmissione.

Segnali musicali

I segnali musicali sono tipicamente armonici e sono dati da:

dove f() la frequenza fondamentale (picco), cm l'ampiezza,

la fase ed a(t) la fascia.
La struttura armonica di uno strumento musicale costituita da una serie di ampiezze
delle armoniche relative alla frequenza fondamentale (misurata in dB).
Le differenze nella struttura armonica e la fascia rendono i suoni diversi.

Segnali parlati

I blocchi di costruzione di base di una lingua sono detti fonemi. Un fonema pu essere di voce
se generato da corde vocali, o non di voce se le corde vocali non sono coinvolte.
Quando viene progettato un codificatore di segnali parlati, solitamente, viene prestata molta pi
attenzione ai fonemi di voce rispetto a quelli non di voce in quanto generalmente molto pi
presenti. Il tratto vocale generalmente dato da un sistema lineare che varia nel tempo con una
funzione razionale ed all-pole nella quale p tipicamente 8-12:

La descrizione matematica del segnale generato dalle corde vocali un flusso di impulsi quasi

periodico, nel senso che gli intervalli tra gli impulsi successivi e le ampiezze di impulsi differenti
non sono esattamente costanti.

Il reciproco dell'intervallo medio tra gli impulsi successivi chiamato picco di frequenza ed
caratteristico per ogni persona. Il picco di un uomo adulto si aggira generalmente tra gli 80 ed i 120
Hz, mentre per una donna adulta si aggira tra i 150 ed i 300 Hz. Le due equazioni riportate di sopra
sono combinate in un modello a breve periodo per i segnali parlati:

Questo modello chiamato LPC (Linear Predective Coding) ed infatti un modello auto-regressivo
con y[n] come componente di errore in questa predizione.

Organizzazione di un Encoder Audio

Di seguito viene riportato un template generale che offre un esempio di come la compressione audio
sia svolta a livello pratico:

Per prima cosa, il dato audio partizionato in molteplici frame, da 2 a 50 ms di durata, a seconda
dell'algoritmo. Il segnale audio digitale poi passato simultaneamente al blocco time-frequency
ed a quello psychoacoustic. Il blocco time-frequency trasforma il dato audio e d in output una
rappresentazione di coefficiente di trasformata dei valori di ampiezza. Il blocco psychoacoustic
sfrutta l'irrilevanza percettiva tra il dato audio ed i masking threshold di output. Questi threshold
definiscono il livello di noise consentito, in modo da mantenere questo noise inudibile.
Vengono utilizzati nel processo di allocazione di bit (blocco bit allocation) per controllare la
quantizzazione dei coefficienti di trasformata in modo che il noise di quantizzazione non ecceda i
threshold. Le ridondanze statistiche rimanenti sono poi eliminate da un algoritmo di codifica
entropica che comprime la rappresentazione binaria del dato audio.
Infine, i coefficienti di trasformata codificati in forma binaria assieme alle informazioni
secondarie necessarie sono trasmessi al channel.
Il processo di decodifica l'inverso, ma molto pi semplice visto che solamente necessario
identificare la rappresentazione binaria dei coefficienti quantizzati ed estrarre le informazioni
secondarie necessarie, in modo da ricostruire il dato audio dai coefficienti quantizzati.

Fondamenti del modello psico-acustico

Il primo passo per rimuovere le informazioni dal segnale audio originale fatto studiando come
l'analizzatore delle frequenze temporali umano pi comunemente detto orecchio tratta i
segnali audio. L'output di questo primo passo (o processo) sono i masking threshold che indicano
il livello di distorsione tollerato in modo da mantenere le informazioni rimosse inudibili. Questa
simulazione della risposta dell'orecchio umano ai suoni chiamata, appunto, modello psicoacustico ed esplora i limiti dell'abilit umana di percepire suoni e distorsione,
in modo da comprimere efficientemente il segnale audio.
Ad ogni modo, i risultati ottenuti nell'area di ricerca della psico-acustica
sono lungi dall'essere perfetti e teoreticamente derivati.

L'orecchio

L'orecchio umano consiste nell'orecchio esterno, l'orecchio interno e l'orecchio medio.

Nell'orecchio esterno, troviamo la pinna che fornisce informazioni sulla direzione dell'origine
del suono; aggiunge questa informazione all'informazione di pressione del suono
decodificata dal cervello.
La parte esterna consiste inoltre nel canale dell'orecchio, che amplifica i suoni che vi passano
a certe frequenze.
La parte media una cavit piena d'aria contenente tre piccole ossa che formano un'impedenza
meccanica per collegare correttamente la parte esterna con la parte interna ripiena di liquido.
L'obiettivo dell'orecchio medio di trasferire in modo pi efficiente possibile tutta l'energia data
dalle vibrazioni alla parte interna.
La parte interna l'unica parte dell'orecchio che gli scienziati non hanno ancora compreso appieno
per poter dare agli ingegneri un modello esatto di percezione uditiva umana.
A grandi linee, consiste nel meccanismo di bilanciamento (equilibrio) del corpo ed formato
da tre canali semi-circolari e l'organo di processo uditivo conosciuto come cochlea.
La parte interna divisa da due membrane, conosciute come la membrana di Reissner
e la membrana di base.

Il threshold uditivo assoluto

La definizione di threshold assoluto dell'udito dato dalla quantit di energia richiesta in un tono
puro, in modo da essere percepita da un uditore in un ambiente privo di noise.
Nel modello psico-acustico completo viene utilizzato un threshold assoluto atto ad evitare un
under-coding, ovvero evitare di mantenere informazioni al di sotto di tale livello (threshold),
visto che sarebbero irrilevanti per la qualit percepita del segnale audio.
Un'approssimazione di threshold uditivo assoluto data da:

Il punto pi basso della curva 4 kHz e dato che il livello di playback sconosciuto a priori,
lo schema del codificatore audio solitamente eguaglier questo punto con l'energia in un seno a 4
kHz, con un ampiezza di +/- 1bit dell'ampiezza del segnale audio.

Bande critiche

Le bande critiche modellano come come l'orecchio (ed il cervello) eseguono l'analisi spettrale.
Rappresentano il punto in cui l'orecchio non pu distinguere due frequenze differenti nella stessa
banda critica. Questo effetto ha la sua origine nella membrana di base, che utilizza diverse parti
della sua superficie a seconda della frequenza. mostrato che il cervello pu decodificare pi
facilmente le informazioni ricevute alle estremit, dove sono decodificate le frequenze pi basse.
Quando si ha a che fare con bande critiche, conveniente parlare di distanze di bande critiche
e la distanza di una banda critica misurata in un bark e, per convertire da frequenza a bark,
si utilizza la seguente formula:

Banda Frequenza centrale (Hz) Intervallo (Hz)

1 50 - -100
2 150 - 100-200
3 250 - 200-300
4 350 - 300-400
5 450 - 400-510
6 570 - 510-630
7 700 - 630-770
8 840 - 770-920
9 1000 - 920-1080
10 1170 - 1080-1270
11 1370 - 1270-1480
12 1600 - 1480-1720
13 -1850 - 1720-2000

Banda Frequenza centrale (Hz) Intervallo (Hz)

14 2150 - 2000-2320
15 2500 - 2320-2700
16 2900 - 2700-3150
17 3400 - 3150-3700
18 4000 - 3700-4400
19 4800 - 4400-5300
20 5800 - 5300-6400
21 7000 - 6400-7700
22 8500 - 7700-9500
23 10500 - 9500-12000
24 13500 - 12000-15500
25 19500 -15500La banda delle bande critiche diventa pi grande all'aumentare della frequenza, poich, come detto
prima, la membrana di base utilizza per le frequenze pi alte la sua parte interna meno sensibile
invece delle estremit pi sensibili.

Banda equivalente rettangolare

Un problema delle bande critiche celato nella loro derivazione sperimentale, che effettuata con
una maschera a piccola banda ed un tono sonda. Il problema dimostra infatti che tra il segnale sonda
e la maschera si possono verificare effetti come i prodotti di inter-modulazione.
Un modello migliore per le bande di frequenza l'ERB (Equivalent Rectangular Bandwidth) e,
a livelli di pressione sonora moderati, la conversione da frequenza ad ERB :

dove f la frequenza centrale in Hz. Il numero di ERB sotto ogni frequenza :

dove f in Hz. La differenza principale tra le bande critiche e l'ERB che quest'ultimo in grado di
evitare gli errori che si verificano per le bande critiche alle frequenze pi basse (inferiori a 500 Hz).

Masking Simultaneo

Il masking un fonema che si verifica quando un'eccitazione di una certa forza sulla membrana di
base, con una banda critica, blocca la trasmissione di un segnale pi debole. Questo un fatto molto
importante per il design del modello psico-acustico, visto che ci permette di rimuovere informazioni
che sono mascherate da un segnale pi forte. Il masking simultaneo si presenta in due forme:
tono di masking noise, ovvero il noise threshold in cui un forte tono originato dal centro di una
banda critica maschera il noise ovunque all'interno della banda critica.
Il secondo il masking noise di tono, ovvero il threshold di tono in cui un forte noise originato
dal centro di una banda critica maschera i toni ovunque all'interno della banda critica.
Potenzialmente, il masking (sia questo di tono o di noise) pu avvenire anche in altre bande critiche
ed in questo caso viene definito masking di inter-banda.

Dove x in bark. Il noise masking threshold dato invece da:

dove ET l'energia della maschera di tono e B il numero di banda critica.
Il masking threshold di tono, invece, dato da:

dove EN il noise di banda critica e K un parametro che viene generalmente settato tra 3 e 5.

Masking Temporale

Un colpo emesso da una grancassa un ottimo esempio di masking temporale.

Questo tipo di masking si verifica quando il threshold udibile innalzato momentaneamente dallo
shock; la funzione di decodifica del cervello parzialmente paralizzata da questo evento durante
un corto periodo di pre-masking (circa 5ms), dal periodo di evento stesso
e un periodo di post-masking pi lungo (circa 50-300ms).

Entropia percettiva

L'entropia percettiva (PE Perceptual Entrophy) una combinazione di principi di masking

e quantizzazione del segnale che definisce una misura per il limite teoretico della compressibilit
di un segmento audio o, in altre parole, il contenuto minimo di informazione che il cervello pu
decodificare senza notare una perdita di qualit.
L'algoritmo di Entropia Percettiva funziona principalmente come segue:
1) Trasforma il segnale nel dominio delle frequenze.
2) Ottiene il masking threshold utilizzando le regole percettive.
3) Calcola il numero minimo di bit richiesti per quantizzare un segmento audio
senza introdurre noise udibile.

Modello Psico-acustico MPEG

Il metodo di compressione pi conosciuto ed utilizzato, ad oggi, lo standard MPEG, anche per

quanto riguarda la codifica audio. Ci sono state tante proposte durante gli anni per quanto riguarda
la codifica audio ed una delle pi conosciute utilizza la trasformata di Wavelet; al contrario, MPEG,
nei suoi standard audio, utilizza un filterbank polifase ed i due modelli psico-acustici che prender
di seguito in esame forniscono un ottimo esempio
del funzionamento dei modelli psico-acustici attuali.
1) Modello Psico-acustico I
Il primo modello utilizza 512 campioni per il Layer 1 che produce un nuovo vettore da 384
campioni. Per i Layer 2 e 3 vengono invece utilizzati 1024 campioni. Ad ogni modo, l'analisi di
1152 campioni per i Layer 2 e 3, quindi alcuni campioni decadono nel modello 1 durante il
calcolo completo. Questi campioni sono trasformati attraverso il dominio delle frequenze
utilizzando la trasformata di Fourier veloce, gi analizzata in precedenza nella prima parte della tesi.
Dopodich, i campioni sono compensati per effetti di bordo attraverso una finestra di Hann pesata.

(funzione di Hann sulla sinistra e la sua risposta in frequenza a destra)

La finestra di Hann una combinazione lineare di finestre rettangolari modulate
Dalla formula di Eulero:

A causa delle propriet di base della trasformata di Fourier, il suo spettro :

con lo spettro della finestra rettangolare:

(il fattore di modulazione svanisce se le finestre sono shiftate di tempo attorno allo zero)

La funzione di Hann, infatti, proprio una funzione finestra discreta ed difatti utilizzata come
funzione finestra per selezionare un sotto-insieme di campioni per poter eseguire la trasformata di
Fourier od altri calcoli. Ad ogni modo, una volta eseguite le varie operazioni sui campioni, il
momento di calcolare lo spettro discreto di Bark e questo fatto sommando l'energia in ogni banda
critica e separando i valori spettrali in componenti di tono e non di tono. Le componenti di tono
sono individuate ricercando i picchi locali nello spettro di potenza, e le componenti non di tono
sono situate nell'indice pi vicino alla media geometrica della banda critica. Le componenti non di
tono sono i valori spettrali rimanenti sommati in ogni banda critica. Fatto questo, viene applicata al
segnale audio una funzione di maschera empiricamente determinata, che calcola il noise masking
threshold ed incorpora inoltre il threhsold uditivo assoluto. Viene poi calcolato masking threshold in
ogni banda critica ed infine viene derivato il rapporto segnale-maschera dividendo l'energia di
segnale totale in ogni banda dal masking threshold minimo corrispondente.
2) Modello Psico-acustico II
Il modello pisco-acustico MPEG II una versione pi avanzata del modello originale che utilizza
1024 campioni per tutti e tre i Layer. I due modelli hanno molte cose in comune e, dunque, all'atto
pratico, molto pi semplice esplicare il secondo modello partendo dalle differenze che ha rispetto
al primo. Per ogni analisi nel Layer 2 e 3, il modello computa due finestre con l'analisi psicoacustica corrispondente e poi combina i risultati utilizzando il pi alto dei rapporti segnalemaschera per ogni banda ed il pi basso dei noise masking threshold per ogni banda. Invece di
separare i valori in di tono e non di tono, questo modello computa un indice di tonalit che
misura ogni componente rispetto alle sue caratteristiche di tono. L'indice poi utilizzato per
l'interpolazione tra il tono di masking noise ed il masking noise di tono. Il noise masking threshold
viene poi calcolato da una funzione incorporata con il threshold uditivo assoluto. Infine, il masking
minimo altro non che i threshold calcolati dalla media dei masking threshold in ogni sotto-banda
di overlap con la banda critica attuale.

Analisi Tempo-Frequenza

L'analisi tempo-frequenza in uno schema di codifica audio trasforma i dati audio nel dominio delle
frequenze in modo da rappresentare l'informazione con i coefficienti di trasformata invece dei valori
di ampiezza, dato che possibile distribuire l'energia del segnale in questi coefficienti e decorrelare
il segnale, in modo analogo a come accadeva nella codifica delle immagini fisse ed in movimento.
Il modo pi comune per farlo quello di utilizzare una trasformata unitaria quale, ad esempio, la
DCT (Trasformata Discreta del Coseno) che risulta essere un'ottima trasformata non solo per i
codec visti precedentemente nel campo visivo, ma anche per quanto riguarda alcuni tipi di segnale
audio! Come sappiamo, per, le trasformate unitarie non offrono la possibilit di avere una
risoluzione temporale sufficiente, ma, d'altro canto, forniscono stime spettrali ad alta risoluzione,
che compensano questo punto a loro sfavore. Un altro modo per eseguire l'analisi tempo-frequenza
sono i filterbank con la trasformata di Wavelet od altre trasformate.

Quantizzazione scalare

1) Quantizzazione uniforme
Nella tecnica di quantizzazione uniforme, il range di valori in input possibili viene diviso in bande
di uguale grandezza, in modo che i valori in input appartenenti alla stessa banda siano collegati
ad un valore scalare univoco del set di quantizzazione.

Come esempio, se volessimo quantizzare uniformemente l'intervallo tra 1 e 2 con 2 bit,

dovremmo ricevere 2^2 = 4 possibili valori scalari tra questi due valori, ovvero 1, 1.33, 1.66 e 2.
La quantizzazione uniforme un metodo molto semplice (ma inefficiente) di quantizzare i
coefficienti di trasformata, dato che molti valori rimangono inutilizzati. Quando vogliamo
quantizzare i coefficienti di trasformata che sono molto deboli, abbiamo il problema che ogni valore
quantizzato a zero e questo pu essere risolto utilizzando la tecnica di quantizzazione
non uniforme.
2) Quantizzazione non uniforme
Per avere una quantizzazione precisa per i segnali deboli e grossolana per i segnali pi forti e
per avere un noise di quantizzazione pi proporzionato al segnale, dobbiamo usare una tecnica di
quantizzazione non uniforme. Ci viene in aiuto, in questo caso, la quantizzazione con compressione
a funzione logaritmica che comprime il segnale con una funzione logaritmica appropriata, quantizza
uniformemente l'output ed espande il segnale con l'inversa della funzione logaritmica usata in
origine. L'Europa ed il Nord America utilizzano due formule leggermente differenti che raccolgono
i tre passaggi elencati precedentemente in una formula di compandorizzazione.
In Europa la formula la seguente:

dove A una costante positiva (il valore standard 87.6), x il valore in input ed y il valore
quantizzato in output.

Quantizzazione vettoriale

La quantizzazione vettoriale un'estensione della quantizzazione scalare, nel senso che, in questo
caso, stiamo cercando un collegamento tra un vettore in input ed un libro di codice di vettori di
quantizzazione. La ricerca per il collegamento migliore un processo esaustivo se eseguito con
l'intento di trovare il miglior collegamento possibile testando tutte le combinazioni. Dunque,
l'algoritmo di ricerca della quantizzazione vettoriale cerca di identificare ed eliminare i pattern
meno probabili e cerca di individuare un collegamento semi-ottimale. Questo pu essere fatto con
un test di errore quadratico medio pesato tra i vettori in input ed il set di vettori quantizzati che pu
stoppare il test se la somma dell'errore quadratico medio tende a violare il threshold di errore
quadratico medio totale predefinito. Quindi possibile evitare di compandorizzare l'intero vettore
quando sappiamo che fallir.

Allocazione di bit parametrica

A questo punto, abbiamo presentato i primi passaggi di uno schema di codifica audio. Abbiamo ora
la rappresentazione trasformata del dato audio e dei masking threshold e, nell'allocazione di bit
parametrica, queste saranno combinate. Il processo di allocazione di bit regola la quantizzazione dei
coefficienti di trasformata con l'aiuto dei masking threshold dal modello psico-acustico. L'obiettivo
di assottigliare la distorsione di quantizzazione sui coefficienti di trasformata in modo da far
rimanere il tutto inudibile dopo la compressione. L'allocazione di bit parametrica stata ideata
principalmente per essere utilizzata dall'AC-3 ed basata sui principi psico-acustici. Combina
inoltre i principi sia dell'adattamento in avanti che di quello indietro. L'adattamento in avanti
significa che l'encoder computa i bit e poi trasmette i bit di assegnamento come informazioni
secondarie in modo da consentire una maggiore flessibilit nell'algoritmo di allocazione.

L'adattamento indietro, invece, ha anch'esso l'encoder che computa i bit, ma invece di trasmettere i
bit di assegnamento, questi sono ri-computati dal decoder, salvando bit importanti.
I bit che sono stati risparmiati, dunque, possono essere utilizzati per encodare i coefficienti stessi!
Entrambe le strategie condividono caratteristiche che lo schema di allocazione di bit parametrico
cerca di incorporare. L'allocazione costruita con parametri che controllano la forma della curva di
masking e, dunque, che controllano i bit. Dato che il segnale audio potrebbe essere ristretto in modo
da non avere dei bit sufficientemente ottimizzati utilizzando tali parametri, vengono trasmessi
codici di bit-stream aggiuntivi. Questi codici di bit-stream portano informazioni sulle differenze tra
la forma della curva di masking controllata dai parametri ed un'analisi psico-acustica indipendente
che aggiunge i necessari aggiustamenti alla curva. I delta, come vengono chiamati i codici di bitstream, possono essere di varia lunghezza, consentendo all'encoder di utilizzare solamente questo
spazio per apportare i cambiamenti necessari alla curva di masking.

Struttura di dati Zerotree interna

Visto che con segnali deboli riceviamo valori di coefficienti vicini a zero, la probabilit di ottenere
uno zero dopo la quantizzazione molto alta. Questo fatto ha spinto lo sviluppo verso l'utilizzo di
mappe di significato, ovvero una tabella di decisione binaria che ci comunica se un dato coefficiente
ha un valore di quantizzazione zero o non zero. Il costo totale di encoding di una tabella di
coefficienti di valore sopra lo zero, pi la rappresentazione dei coefficienti non zero
molto pi bassa che senza la mappa di significato. Viene cos usato un algoritmo di compressione
per le mappe di significato che utilizza i cos detti Zerotree dei coefficienti di Wavelet ed,
anche se era originariamente pensata per la compressione delle immagini, i risultati possono essere
applicati alla compressione audio senza troppi problemi. Lo Zerotree una struttura di dati che
marca ogni coefficiente di Wavelet con un flag che denota la sua importanza (il suo significato)
rispetto al threhsold scelto sul valore di coefficiente. Vengono usati 4 flag, ovvero:
1) Zerotree root, che denota che gli elementi in scala pi precisa di questo elemento non sono
significativi, ma molti hanno elementi significativi a scale pi grossolane.
2) Zero isolato, che denota che il coefficiente non significativo, ma ha alcuni discendenti
significativi
3) Positivo significativo, che applica un segno positivo sull'elemento significativo.
4) Negativo significativo, che applica un segno negativo sull'elemento significativo.
Lo Zerotree consente all'encoder di concentrare i bit a disposizione solo nelle regioni significative
e questo, ovviamente, un grande miglioramento nel processo di allocazione dei bit.
Detto questo, il momento di andare a vedere i vari codec audio nello specifico
e come si sono evoluti nel tempo, standard dopo standard.
4.1)

MPEG-1 Layer I (.mp1)

Il primo codec audio preso in esame proprio l'MPEG-1 Layer I, pi comunemente conosciuto
come .mp1, a causa della sua estensione. Precedentemente abbiamo visto le basi di un modello
psico-acustico, questo perch, come gi accennato, l'MPEG basa la sua tecnologia
sul funzionamento del modello psico-acustico nei suoi codec
ed il primo preso in esame, il semplice .mp1, non fa esclusione.

Grazie alla psico-acustica, l'MPEG audio pu ridurre significativamente il bitrate richiesto per uno
stream audio in quanto riduce (od elimina completamente) alcune parti dell'audio che deduce che
l'orecchio umano non in grado di sentire.
Questo perch tali parti di audio potrebbero essere in frequenze per le quali l'orecchio umano
meno sensibile, o mascherate da altri suoni, tipicamente pi forti. Al tempo della sua creazione,
l'MPEG-1 Layer I (.mp1) venne creato in modo da avere un basso costo computazionale, in modo
da poter favorire gli applicativi in real time come le teleconferenze e consentire dunque un encoding
in real time. L'MPEG-1 Layer I (.mp1) in grado di encodare frequenze di campionamento di 32
KHz, 44.1 KHz e 48 KHz ad un bitrate di 32, 64, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416 e
448 kbit/s ed utilizza una codifica a 32 sotto-bande. Il suo utilizzo pi importante, all'epoca,
fu la sua implementazione nello standard DGC (Digital Compact Cassette) che prevedeva l'audio
in .mp1 384 kbit/s. Seppur ampiamente supportato dalla maggior parte dei riproduttori audio
e molto leggero in riproduzione, l'.mp1 ormai caduto in disuso
ed stato soppiantato dagli standard successivi.
4.2)

MPEG-1 Layer II (.mp2)

Dopo l'mp1, il turno dell'mp2, un codec che stato pensato per portare una buona qualit a circa
192 kbit/s per un audio stereo. L'mp2 un encoder che si serve del dominio del tempo ed utilizza un
filter bank a 32 sotto-bande. Il modello psico-acustico basato sui principi di masking uditivo,
sugli effetti di masking simultaneo e sul threshold uditivo assoluto, tutti concetti gi affrontati di
sopra. Come ho appena detto, l'mp2 opera sul dominio del tempo; il dominio del tempo perch mi
riferisco a come vengono effettuate analisi e quantizzazione su piccoli campioni discreti di forme
d'onda audio. Cos facendo si ha un basso ritardo in quanto solo un piccolo numero di campioni
sono analizzati prima dell'encoding, al contrario di come accade, ad esempio, nello standard
successivo e famosissimo (l'mp3) che si serve del dominio della frequenza e deve, per tanto,
analizzare molti pi campioni prima di decidere come trasformare ed outputtare l'audio encodato.
Per quanto riguarda il filter bank a 32 sotto-bande, questo genera 32 coefficienti di ampiezza, uno
per ogni banda di frequenza di egual grandezza dell'audio, che largo circa 700 Hz (a seconda della
frequenza di campionamento). L'encoder poi utilizza il modello psico-acustico per determinare
quali sotto-bande contengono informazioni audio che sono meno importanti, ovvero dove la
quantizzazione sar inudibile o, quantomeno, meno notabile. Il modello psico-acustico applicato
utilizzando una trasformata veloce di Fourier a 1024 punti; 1024 perch dei 1152 campioni,
ne vengono ignorati 64 in cima e 64 in fondo al range di frequenza per questa analisi, visto che,
presumibilmente, non sono abbastanza significativi per poter cambiare il risultato. Il modello psicoacustico utilizza un modello di masking determinato empiricamente per determinare quali sottobande contribuiscono maggiormente al masking threshold e quanto noise di quantizzazione possono
contenere prima che questo diventi percepibile. Qualsiasi suono sotto al threshold uditivo assoluto
viene completamente eliminato ed i bit disponibili vengono assegnati ad ogni sotto-banda.
Tipicamente, le sotto-bande sono meno importanti se contengono suoni pi attenuati (con meno
coefficienti) delle sotto-bande vicine (ovvero con frequenza simile) con suoni pi alti (con pi
coefficienti). Inoltre, le componenti di noise hanno un effetto di maschera pi significativo rispetto
alle componenti di tono. Le sotto-bande meno significative sono ridotte in accuratezza dalla
quantizzazione e questo, praticamente, comporta comprimere il range delle frequenze (l'ampiezza
dei coefficienti). L'mp2 pu anche utilizzare l'ISC (Intensity Stereo Coding), una forma di
joint stereo. Questo vuol dire che le frequenze sopra ai 6 KHz, di entrambi i canali sono combinate
in un singolo canale mono, ma le informazioni secondarie di canale sulla relativa intensit
(volume, ampiezza) di ogni canale sono preservate ed encodate separatamente nel bitstream.

In fase di playback, il singolo canale viene riprodotto tramite gli speaker destro e sinistro, con le
informazioni di intensit applicate ad ogni canale per dare l'illusione del suono stereo; questo trucco
percettivo chiamato irrilevanza stereo. Sebbene tale trucco comporti un'ulteriore riduzione di
bitrate, in generale si preferisce mantenere un vero stereo ed utilizzare alti bitrate.

Valutazioni finali

Esattamente come per gli altri codec, anche per i codec di codifica audio interessante testare sul
campo la loro efficienza teorica, in modo da poter dare un giudizio completo. Per il test sono state
scelte come source dei CD a 16bit, 44.1 KHz e, per mantenere una qualit audio accettabile rispetto
a quella delle source, l'mp2 si dovuto spingere fino a 256 kbit/s, ottenendo un peso finale di circa
1/6 rispetto all'audio wav non compresso del CD; un risultato veramente impressionante per l'epoca
della creazione di tale codec, ma del tutto inefficace ai giorni nostri, visto che l'AAC in grado di
comprimere la stessa source utilizzando met del peso dell'mp2 (a pari qualit). Dai test, per,
risultato che l'mp2, per particolarissimi tipi di segnali audio, si piazza leggermente sotto a codec
come AAC ed AC3, con risultati sbalorditivi. Questi particolari tipi di segnali sono impulsi ad alta
energia, come gli applausi di un grande pubblico.
4.3)

MPEG-1 Layer III (.mp3)

Come accennato prima, l'MPEG-1 Layer III pi comunemente .mp3 un encoder che si serve
del dominio della frequenza, al contrario di come accadeva per l'mp2 e, seppur l'mp3 utilizza alcune
delle caratteristiche dell'mp2, i due standard sono molto differenti. L'mp3 lavora a 1152 campioni,
ma come gi detto sopra ha bisogno di prendere molti pi dati per l'analisi. In output d un
numero variabile di campioni, utilizzando un buffer di bit per consentire l'encoding a bitrate
variabile (VBR - variable bitrate) mantenendo una grandezza di output di 1152 campioni.
Questo causa un ritardo significativamente lungo prima dell'output, rendendo l'mp3 inutilizzabile
per le codifiche in tempo reale. L'mp3 non si avvale del filter bank polifase a 32 sotto-bande,
ma utilizza una MDCT (Trasformata Discreta del Coseno modificata) su ogni output per dividere i
dati in 576 componenti di frequenza, processando il tutto nel dominio della frequenza.
Tutto questo consente all'mp3 di avere un modello psico-acustico pi preciso e di applicare
attentamente una quantizzazione appropriata ad ogni banda, ottenendo performance molto migliori
rispetto ai precedenti codec a bassi bitrate. Ad ogni modo, utilizzare il dominio della frequenza
comporta qualche limitazione, causando una risoluzione temporale 12 o 36 volte peggiore di quella
dell'mp2. Tutto questo, porta ad artefatti di quantizzazione a causa di suoni di transizione come
eventi ripetitivi ed altri eventi ad alta frequenza che si verificano in un grande range.
Dunque, si possono verificare fenomeni di pre-eco o eco in avanti, ovvero artefatti di
compressione audio digitale nei quali un suono viene percepito prima che si verifichi
ed molto notabile negli strumenti a percussione. Grazie ad uno strumento di rilevamento di preeco e l'encoding a bitrate variabile (VBR), l'mp3 in grado di aumentare temporaneamente il bitrate
nei punti di maggiore difficolt in modo da attenuare tali difetti.
Oltre al normale joint stereo gi visto nell'mp2, l'mp3 pu utilizzare il joint stereo a matrice.
Con il joint stereo a matrice alcuni range di frequenze di entrambi i canali sono uniti in un singolo
canale mono (L+R Sinistro pi Destro), mentre le differenze tra i canali destro e sinistro sono
salvate in un altro canale (L-R Sinistro meno Destro). A differenza del joint stereo originale
dell'mp2, nel joint stereo a matrice dell'mp3 non c' alcuna perdita di informazioni;
ad ogni modo, dopo a quantizzazione, gli artefatti generati possono essere molto accentuati.
Se le differenze tra il canale di destra e quello di sinistra sono poche, il secondo canale quello
delle differenze (L-R Sinistro meno Destro) sar piccolo e questo pu comportare fino ad un
massimo di 50% di riduzione del bitrate.

Se, al contrario, le differenze tra i canali destro e sinistro sono tante, decisamente preferibile
utilizzare il normale encoding stereo, visto che il joint stereo a matrice non comporterebbe alcun
beneficio. Non solo, l'mp3 anche in grado di passare dalla normale codifica stereo a quella joint
stereo a matrice nello stesso file, il che comporta una ulteriore riduzione di peso.
Un'altra differenza dell'mp3 rispetto all'mp2 che utilizza la codifica di Huffman a lunghezza
variabile per ridurre ulteriormente il bitrate, senza una ulteriore perdita di qualit.

Valutazioni finali

Le limitazioni tecniche insite all'mp3 fanno s che sia impossibile ottenere una qualit audio
cristallina a qualsivoglia bitrate. Questo fa s che, ad un bitrate sufficientemente alto, l'mp2 risulti
ancora superiore all'mp3, in termini di pura qualit. La popolarit che ha conquistato l'mp3 al
momento del suo debutto dovuta pi che altro al lato consumer che, illo tempore, si concentrava
sulla quantit pi che sulla qualit. Per i mezzi dell'epoca, potersi portare dietro nel proprio lettore
USB mp3 una grande quantit di file in uno spazio molto ridotto era vista come una cosa
straordinaria. Seppur ci fossero delle grandi limitazioni nella qualit finale rispetto ai file wav non
compressi estratti dai CD originali, un mp3 a 192 kbit/s veniva all'epoca considerato
accettabile per l'ascolto da uso comune. Per il nostro test, stata utilizzata una canzone estratta in
formato lossless wav dal CD originale per una durata totale di 5 minuti e 43 secondi.
Il file non compresso ha un peso di 59,203 MB, stereo ed ha un campionamento a 44'100 Hz.
Questo file stato poi encodato in mp3 utilizzando le stesse impostazioni usate all'epoca del suo
utilizzo comune; il risultato stato un file .mp3 con tecnologia joint stereo a matrice di 192 kbit/s a
44'100 Hz di soli 7,860 MB. possibile quindi capire come l'mp3 fosse molto utilizzato a suo
tempo per la sua possibilit di compressione. Tornando all'mp2 per un attimo, seppur vero che a
bitrate sufficientemente alti l'mp2 migliore in termini di qualit dell'mp3, anche vero che, a bassi
bitrate, l'mp3 produce artefatti meno significativi rispetto all'mp2.
4.4)

Advanced Audio Coding (AAC)

Introduzione

Col passare degli anni, vennero migliorate anche le varie tecnologie audio e video. Si giunse alla
volta dell'MPEG-2 e venne cos deciso di rilasciare un aggiornamento retro-compatibile per l'mp1,
l'mp2 e l'mp3 gi introdotti con l'MPEG-1. Ad ogni modo, c'era bisogno di un nuovo codec audio
capace di soddisfare i requisiti sempre pi alti per le trasmissioni: cominciarono cos i lavori per la
creazione di un nuovo ed innovativo codec non retro-compatibile che si estesero fino all'MPEG-4
Part 10 AVC (Advanced Video Coding) H.264 e dettero vita all'AAC (Advanced Audio Coding).

Il codec

L'AAC, in linea di massima, segue le stesse caratteristiche indicate per i codec audio precedenti
(filterbank, quantizzazione non uniforme, codifica di Huffman), ma comporta molti miglioramenti
rispetto ai precedenti standard, soprattutto rispetto al suo predecessore e diretto concorrente, l'mp3.

Tra le migliorie pi significative rispetto all'mp3 troviamo una risoluzione della frequenza pi alta;
parliamo di 1024 contro 576 dell'mp3. Il secondo punto di forza dell'AAC la predizione.
L'AAC ha la possibilit di effettuare una predizione all'indietro che consente di ottenere una
maggiore efficienza di codifica, soprattutto per i segnali di tono. Il terzo punto di forza dell'AAC
una versione migliorata del joint stereo. Comparato a quello dell'mp3, le due modalit di codifica
(joint stereo normale ed a matrice) sono molto pi flessibili, facendo s di poter applicare tali
modalit pi frequentemente in modo da ridurre il bitrate in modo maggiore.
Il quarto punto di forza dell'AAC, una codifica di Huffman migliorata.
Ma i vantaggi dell'AAC non comportano solo una compressione audio migliore rispetto ai suoi
predecessori per i normali segnali audio, l'AAC riuscito a migliorare anche il comportamento nei
segnali pi difficili! Una delle tecnologie pi interessanti dell'AAC il cambio avanzato dei
blocchi. Invece di utilizzare un filterbank ibrido come quello dell'mp3, l'AAC utilizza un filterbank
con la Trasformata Discreta del Coseno Modificata con un impulso di risposta (per i blocchi pi
piccoli) di 5.3 ms ad una frequenza di campionamento di 48 KHz. Comparato all'mp3 che
raggiunge 18.3 ms un ottimo risultato, contando anche il fatto che gli artefatti di pre-eco sono
ridotti in modo notevole. Un'altra tecnologia introdotta dall'AAC il TNS (Temporal Noise
Shaping) che esegue un riduzione del noise a livello temporale eseguendo una predizione di loop
aperta nel dominio della frequenza. Dai test eseguiti, il TNS si dimostrato essere particolarmente
utile per il miglioramento della qualit nel parlato a bassi bitrate. Sommando tutte queste piccole
migliorie, l'AAC raggiunge in media la stessa qualit dell'mp3 utilizzando il 70% del bitrate.
Un'altra differenza tra l'AAC e l'mp3 proprio la frequenza di campionamento, visto che l'AAC in
grado di supportare frequenze che vanno dagli 8 ai 96 KHz e fino a 48 canali, contro i due canali
supportati dall'mp3 prima dell'aggiornamento ed i 5.1 canali dopo l'aggiornamento effettuato
all'epoca dell'MPEG-2. In altre parole, non solo l'AAC migliore dell'mp3 a bassi bitrate,
ma pu raggiungere codifiche di qualit che l'mp3 non neanche in grado di processare!
L'approccio che l'AAC ha nei confronti della codifica audio, inoltre, un approccio modulare,
nel senso che in grado di adattarsi al meglio a tutte le varie situazioni e tipologie di segnali audio
e, per farlo, si serve di vari profili:
1) Main audio profile
Il profilo Main era un profilo molto usato, stabilito ai tempi del primo sviluppo del codec, ovvero
all'epoca dell'MPEG-2, ma poi diventato obsoleto.
2) Scalable audio profile
Il profilo Scalable venne ideato per avere la necessit di avere un profilo scalabile nel codec.

3) Speech audio profile

Il profilo Speech venne ideato per favorire la codifica di segnali audio prevalentemente parlati.
4) Synthetic audio profile
Il profilo Synthetic altro non che una sintesi del profilo Main.
5) High Quality audio profile
L'High Quality profile venne ideato per concentrarsi sulla qualit, pur comportando un ritardo nella
velocit di codifica; per questo profile l'importante la qualit finale.
6) Low Delay audio profile
Mentre il profilo precedente era concentrato sulla qualit, questo concentrato sulla velocit,
ovvero sul basso ritardo e sul cercare di ottenere una codifica il pi vicino possibile a quella in
tempo reale.
7) AAC profile
Il profilo AAC il primo profilo a far parte della seconda fase di sviluppo dell'AAC, quella
dell'MPEG-4 Part 10 AVC H.264. Questo profilo il profilo pi utilizzato nei recenti encoding in
AAC e viene spesso associato come audio di default negli encoding in H.264.
8) High Efficiency AAC profile
L'High Efficiency AAC profile nasce per sfruttare la tecnologia SBR (Spectral Band Replication)
all'interno dell'AAC. Tale profilo non nasce come sostituto del profilo AAC, ma come un soprainsieme che estende le funzionalit dell'AAC, ed i decoder in grado di riprodurre l'HE-AAC sono
in grado di riprodurre anche il profilo AAC. Come detto prima, l'SBR una tecnica di estensione
della banda che non rimpiazza il core del codec, ma opera in congiunzione ad esso per poter creare
un sopra-insieme del codec originale pi efficiente, in grado di dimezzare il bitrate richiesto.
Presente in entrambi i processi di encoding e decoding, l'SBR sfrutta al massimo la correlazione tra
le basse e le alte frequenze in un segnale audio per descrivere le alte frequenze di un segnale
utilizzando una piccolissima quantit di dati. Il dato SBR che descrive le alte frequenze poi
accoppiato ai dati compressi a bassa frequenza del codec AAC. Una volta combinati in fase di
decoding, il bit stream completo HE-AAC contiene tutti i dati per ricreare il segnale delle alte
frequenze (SBR) dal segnale codificato alle basse frequenze dall'AAC.

Il profilo HE-AAC incluso come profilo nell'AAC e non un nuovo standard a parte,
proprio perch retro-compatibile. Difatti, se un file audio encodato in HE-AAC viene mandato ad
un decoder che supporta solo i profili fino a quello AAC, questi sar comunque in grado di
riprodurre tale file, ma non sar in grado di combinare il file SBR con quello encodato in AAC e,
di conseguenza, non sar in grado di ricreare le alte frequenze, ma potr riprodurre solo le basse
frequenze. Ad esempio, per creare un file stereo con un bitrate di 48 kbit/s col profilo HE-AAC,
l'encoder genera due segnali: un segnale AAC da 42 kbit/s ed un segnale SBR di circa 6kbit/s.
Dunque, i decoder in grado di leggere solo il profilo AAC, leggeranno solo il segnale AAC da 42
kbit/s, mentre quelli in grado di riprodurre l'HE-AAC potranno combinare entrambi i segnali.
Grazie a questa modalit di codifica, l'HE-AAC consente di raggiungere una buona qualit a
bassissimi bitrate, come 128 kbit/s, e tale efficienza di compressione l'ideale per il file-sharing
e per il futuro digital broadcasting. Ad ogni modo, proprio a causa della sua struttura,
non utilizzabile per le radiocomunicazioni tra due o pi persone quali la telefonia in tempo reale
a causa del suo alto costo computazionale.
9) High Efficiency AAC v2 profile
Come risultato dello sviluppo dell'HE-AAC, stato rilasciato un ulteriore, nuovo profilo che
comporta delle piccole migliorie rispetto al profilo HE-AAC originale.

Chiudendo la parte relativa ai profili, l'AAC ha anche sviluppato un metodo di correzione degli
errori che viene applicato nei punti nei quali il codec potrebbe essere pi soggetto agli errori e non
all'intera traccia audio, in modo da salvaguardare la qualit finale. Inoltre, vengono utilizzati degli
strumenti quali il VCB11 (Virtual Codebook) che individua gli errori all'interno dei dati spettrali
e il RVLC (Reverse Variable Length Code) che riduce la propagazione di errori.

Valutazioni finali

L'AAC ha segnato un giro di vite nello sviluppo dei codec di codifica audio ed in grado di
encodare audio di altissima qualit, con campionamenti altissimi e con un grande numero di canali.
Come codec, raggiunge performance imbattibili sia ad alti bitrate che a bassissimi bitrate ed stato
in grado di essere superiore ai predecessori sotto numerosi aspetti, soprattutto rispetto all'mp3,
suo rivale diretto. Proprio per le sue grandi capacit e per il suo sviluppo che si protratto per
tempo (dall'MPEG-2 all'MPEG-4 Part 10), l'AAC stato adottato da numerose compagnie e servizi
e, ad oggi, risulta essere il codec migliore in rapporto qualit-efficienza-supporto.
Giusto per fare alcuni esempi, l'AAC stato adottato dallo standard di radio digitale DAB+, per gli
standard televisivi DVB-H ed ATSC-M/H, ma anche da numerosi servizi online quali YouTube ed
iTunes ed supportato nativamente da iPhone, iPad, iPod, NintendoDSi, Nintendo3DS,
PlayStation4, PlayStation3, PlayStationVita, Nintendo Wii, da Android, dal Black Berry,
da Windows Phone, da numerose autoradio ed altrettanto numerosi televisori.

4.5)

AC-3 Audio Coding 3

Parallelamente allo sviluppo dell'AAC, prese piede una nuova tecnologia, il Dolby Digital Audio e,
con esso, l'AC-3, un codec nato specificatamente per l'audio digitale delle sale cinematografiche e
che prese subito piede. Tale codec trov inoltre un buon riscontro anche nella televisione digitale
e nei DVD.

Encoding

L'algoritmo dell'AC-3 raggiunge grandi guadagni in termini di compressione quantizzando la

rappresentazione nel dominio della frequenza del segnale audio. Il primo passaggio nel processo di
encoding quello di trasformare la rappresentazione dell'audio da una sequenza di campioni
temporali PCM in una sequenza di blocchi di coefficienti di frequenza e questo viene fatto tramite il
filterbank. I blocchi di overlap di 512 campioni di tempo sono moltiplicati da una finestra di tempo
e trasformati nel dominio della frequenza. A causa dei blocchi di overlap, ogni campione PCM in
input rappresentato in due blocchi trasformati sequenziali.
La rappresentazione nel dominio della frequenza pu poi essere decimata da un fattore di due,
in modo che ogni blocco contenga 256 coefficienti di frequenza.
I coefficienti di frequenza individuali sono rappresentati in notazione binaria esponenziale come un
esponente binario ed una mantissa. Il set di esponenti encodato in una rappresentazione
approssimata dello spettro del segnale che viene chiamato involucro spettrale. Questo involucro
spettrale utilizzato dal processo di allocazione di bit che determina quanti bit usare per encodare
ogni mantissa individuale. L'involucro spettrale e le varie mantissa quantizzate per 6 blocchi audio
(1536 campioni audio per canale) sono formattati in un dato di sync AC-3
ed il bitstream AC-3 altro non che una sequenza di dati di sync AC-3.

A dire la verit, il processo di encoding audio effettuato dall'AC-3 pi complesso di quello

descritto sopra e le seguenti parti non sono state incluse nella spiegazione riportata sopra:
1) Viene incluso un dato header che contiene varie informazioni quali il bitrate, il
campionamento, il numero di canali encodati ed altre informazioni richieste per decodificare
il bitstream encodato.

2) Vengono inseriti dei codici di rilevamento degli errori in modo da consentire al decoder di
verificare se un determinato dato di sync AC-3 corrotto o meno.
3) La risoluzione spettrale del filterbank di analisi pu essere alterata dinamicamente in modo
da adattarsi al meglio alle caratteristiche tempo-frequenza di ogni blocco audio.
4) L'involucro spettrale pu essere encodato con risoluzioni tempo-frequenza variabili.
5) Pu essere effettuata un'allocazione di bit pi complessa ed i parametri del processo di
allocazione dei bit possono essere modificati in modo da produrre un'allocazione migliore.
6) I canali possono essere accoppiati assieme alle alte frequenze in modo da raggiungere un
migliore guadagno di codifica per operazioni a bassi bitrate.
7) Nella modalit a due canali pu essere effettuato un processo re-matrizzazione in modo da
raggiungere maggiori performance di codifica ed ottenere risultati migliori nel caso in cui un
segnale a due canali venga decodificato con un decoder a matrice surround.

Decoding

Il processo praticamente l'inverso del processo di encoding. Il decoder deve ordinare il bitstream
encodato, controllare che sia privo di errori e de-formattare i vari tipi di dati quali l'involucro
spettrale encodato e le mantissa quantizzate. Il processo di allocazione dei bit viene inizializzato ed
i risultati sono utilizzati per scompattare e de-quantizzare le mantissa. L'involucro spettrale
decodificato per produrre gli esponenti, dopodich, gli esponenti e le mantissa sono trasformati
di nuovo nel dominio del tempo per produrre i campioni PCM di tempo decodificati.

In realt, esattamente come per il processo di encoding, anche il processo di decoding pi

complesso di quello descritto di sopra e sono stati esclusi i seguenti passaggi:
1) Pu essere applicata la correzione degli errori se questi vengono individuati.

2) I canali che hanno i contenuti ad alta frequenza accoppiati devono essere disaccoppiati.
3) Il processo di de-matrizzazione deve essere applicato (nella modalit due canali) ogni volta
che i canali sono stati re-matrizzati.
4) La risoluzione del filterbank di sintesi deve essere dinamicamente alterata nello stesso modo
usato dall'encoder nel filterbank di analisi durante il processo di encoding.

Valutazioni finali

L'AC-3 un codec in grado di encodare una source con un massimo di 6 canali in un bitrate che
varia da 32kbps a 640kbps. Quando tutti i sei canali sono presenti, la composizione audio viene
detta 5.1. Lo 0.1 si riferisce infatti al canale a banda frazionaria pensato appositamente per i segnali
delle basse frequenze (subwoofer). L'utilizzo dell'AC-3 molto ampio e tale codec utilizzato
soprattutto negli standard di televisione digitale e per i DVD grazie alla sua struttura che lo rende un
codec affidabile e capace di poter codificare segnali a qualit molto alta.

AC-3 vs AAC

Un interessante confronto quello tra AC-3 ed AAC; sebbene i due codec nascano con intenti
diversi, entrambi sono in grado di codificare segnali audio non compressi in maniera ottimale dal
punto di vista della qualit percettiva finale. Ad ogni modo, proprio per il loro scopo di utilizzo
finale, l'AC-3 risulta essere leggermente inferiore all'AAC per quanto riguarda la compressione di
segnali audio ad altissima qualit dal mero punto di vista del peso finale e l'AAC si rivela infatti
essere superiore dal punto di vista della compressibilit. Nel test effettuato ho deciso quindi di
utilizzare un file stereo wav lossless a 44.1 KHz, 1411kbps da 1 minuto e 29 secondi per un peso
complessivo di 15.1 MB. Per l'encoding stato scelto un bitrate di 384 kbps per entrambi i codec
audio AC-3 ed AAC. Entrambi sono stati encodati utilizzando il comando -vbr (Variable Bitrate) in
ffmpeg, tuttavia il codec AC-3 ha ignorato tale comando producendo un file a bitrate costante di
384 kbps, mentre l'AAC ha prodotto un file a bitrate variabile il cui bitrate oscilla tra i 254 kbps ed i
432 kbps, con una media di 384 kbps. Il peso finale dei file di 4.11 MB per l'AC-3 e 4.01 MB per
l'AAC che, come dicevo, risulta essere migliore in termini di compressione (rapporto qualit/peso).
Grazie al bitrate variabile l'AAC riuscito a salvare spazio nei punti meno importanti della
sequenza audio ed ha sfruttato tale bitrate risparmiato per coprire i punti di maggiore richiesta in
termini di bitrate; cos facendo il risultato finale senza dubbio impeccabile e migliore rispetto a
quello sempre comunque ottimale dell'AC-3.

4.6)

Vorbis (.ogg)

Un altro interessante codec audio il Vorbis .ogg che nacque come codec totalmente libero e senza
licenze. Al tempo della creazione del codec, il suo rivale diretto era l'mp3 e proprio per questo
venne ideato in modo da esservi superiore. Ad ogni modo, tale codec stato aggiornato per molto
tempo e si scontrato anche contro l'AAC, non riuscendo per ad ottenere i risultati sperati.
Seppur la sua compatibilit sia molto inferiore rispetto a quella dall'AAC ed i risultati ottenuti nei
test siano stati inferiori a quest'ultimo (ma pur sempre superiori all'mp3),
ho deciso di riservargli un piccolo spazio in questa tesi.

Il codec (encoding e decoding)

Il vorbis riesce ad encodare master audio da 8 KHz a 192 KHz e varie rappresentazioni di canali
quali quella stereo, la 5.1 ed addirittura fino a 255 canali discreti. Prendendo come source un audio
wav non compresso di un CD a 44.1 KHz, il vorbis in grado di produrre un file di output da 45 a
500 kbit/s, a seconda della qualit. Questa viene impostata secondo i parametri -q, ovvero: -q-1
(45kbit/s), -q0 (64kbit/s), -q1 (80kbit/s), -q2 (96kbit/s), -q3 (112kbit/s), -q4 (128kbit/s), -q5
(160kbit/s), -q6 (192kbit/s), -q7 (224kbit/s), -q8 (256kbit/s), -q9 (320kbit/s), -q10 (500kbit/s).
Chiaramente, questi bitrate sono indicativi in quanto il vorbis utilizza esattamente come l'AAC
il VBR (bitrate variabile) per massimizzare l'efficienza di compressione. Sotto l'aspetto tecnico, il
vorbis basato sulla Trasformata Discreta del Coseno Modificata e la utilizza per convertire i dati
sonori dal dominio del tempo a quello della frequenza. Il dato risultante del dominio della frequenza
poi diviso in piano di noise (ovvero la misura del segnale creata dalla somma di tutte le fonti di
noise ed i segnali non voluti, con qualsiasi altro segnale oltre a quello tenuto in considerazione) ed i
componenti residui, per poi essere quantizzato ed encodato entropicamente utilizzando un algoritmo
di quantizzazione vettoriale basato sulle parole di codice. Per quanto riguarda il processo di
decoding, invece, altro non che il processo inverso dell'encoding.

AAC vs Vorbis

Seppur il vorbis risulti essere superiore all'mp3 in termini di qualit, senza dubbio inferiore
all'AAC sia in termini di compressione che, soprattutto, in termini di supporto. Mentre l'AAC un
codec supportato da praticamente ogni piattaforma, il vorbis non lo e questo ha frenato
ulteriormente il suo impiego. Per quanto riguarda i bassi bitrate, il vorbis ha un approccio singolare
con quest'ultimi e, invece dei soliti artefatti da compressione, vengono percepiti dei suoni simili ad
un riverbero in un grande anfiteatro. Questo genere singolare di artefatti dato proprio
dall'approccio che ha scelto il vorbis come codec audio, ovvero quello del piano di noise.
Per quanto riguarda invece il problema di pre-eco gi affrontato per gli altri codec, il vorbis non ne
esente, tuttavia cerca di eliminarlo utilizzando una funzione automatica interna di tune che si
attiva per i bassi bitrate, cercando di ridurne l'effetto. Sebbene i suoi risultati siano stati inferiori a
quelli dell'AAC (soprattutto quando l'AAC utilizza il profilo HE ed HE v2), molte compagnie
hanno deciso di utilizzare il vorbis proprio per il fatto che open source.
Tra i nomi pi famosi spiccano compagnie come Spotify, Wikipedia ed anche giochi come
Grand Theft Auto: San Andreas, Halo: Combat Evolved, World of Warcraft e persino Minecraft.

4.7)

Opus (.opus)

Per quanto riguarda il campo delle radiocomunicazioni in tempo reale, spicca il nome del codec
Opus .opus; un codec che nasce con un unico principale intento: la bassa latenza. Come stato
possibile appurare nel corso della tesi, per, in genere per ottenere una bassa latenza necessario
avere una bassa complessit e, dunque, un basso costo computazionale che non sintomo di buona
efficienza in caso di compressione. Per arginare il problema, l'opus si serve della codifica predittiva
lineare (algoritmo SILK originariamente inventato ed utilizzato da Skype) e della Trasformata
Discreta del Coseno Modificata, passando da un metodo all'altro;
il bitrate, la banda audio, la complessit e l'algoritmo possono essere modificati tutti in tempo reale.

Il codec

L'opus supporta bitrate costanti e variabili che vanno da 6 kbit/s a 510 kbit/s, con campionamenti
che vanno dagli 8 KHz (con 4 KHz di banda) a 48 KHz (con 20 KHz di banda),
ovvero che comprendono il raggio uditivo umano.
L'opus supporta fino a 255 canali audio e consente l'accoppiamento dei canali tra gruppi di canali di
due. In ogni stream opus, il bitrate, la banda e la latenza cambiano continuamente senza introdurre
alcuna distorsione o discontinuit; persino mischiando pacchetti di stream diversi
si verifica un regolare cambiamento invece di una distorsione!
Non solo, a differenza del vorbis, l'opus non ha bisogno di lunghe parole di codice per ogni singolo
file, rendendolo pi efficiente per piccole clip audio. Per quanto riguarda il lato tecnico, l'opus
basato su una combinazione di CELT (Constrained Energy Lapped Transform) e SILK, entrambi
estremamente modificati: il CELT basato sulla Trasformata Discreta del Coseno Modificata,
utilizzando la CELP (Code-excited linear prediction) per una migliore predizione, mentre il SILK
basato sulla codifica predittiva lineare. Nella loro implementazione nel codec Opus, entrambe sono
state modificate per ottenere ulteriori miglioramenti algoritmici, nonch per poter supportare range
pi vasti. Inoltre, il CELT include sia la replicazione spettrale che la generazione del noise (simile
all'SBR dell'AAC) ed in grado di salvare ulteriormente bit filtrando i suoni armonici e facendoli
replicare dal decoder in fase di decoding.

I preset (mode)

L'opus ha tre preset chiamati mode, ovvero:

1) Speech mode, che utilizza il SILK puro, consentendo basse latenze e bitrate per le
conversazioni audio.
2) Hybrid mode, che utilizza il SILK puro fino a 8 KHz, per poi passare al CELT per raggi di
frequenze superiori agli 8 Khz.
3) CELT, che utilizza il CELT puro, pensato principalmente per la codifica audio generica.
Mentre il SILK esclusivamente VBR (bitrate variabile) e non pu raggiungere un determinato
bitrate, il CELT in grado di utilizzare il CBR (bitrate costante) e viene automaticamente attivato
nei casi in cui questo viene richiesto.

Opus VS AAC

Concettualmente, i due codec nascono per scopi molto diversi ed hanno difatti ottenuto risultati
molto diversi nei vari test. L'opus, con la sua bassa latenza, nasce per le conversazioni audio in
tempo reale e per gli eventi live e risulta essere molto superiore all'AAC per bitrate come 64 kbit/s.
Ad ogni modo, per quanto riguarda la qualit finale di un prodotto professionale quale l'audio di un
film in Dolby 5.1, ma anche di una semplice serie televisiva in stereo, l'AAC risulta essere migliore
per due motivi fondamentali: in primo luogo, il vantaggio in termini di compressione dell'opus va
scemando all'aumentare del bitrate e secondariamente poi, l'AAC al contrario dell'opus
largamente supportato come standard, rendendo il piccolissimo e talvolta quasi nullo
(se non totalmente nullo) vantaggio in termini di compressione ad alti bitrate assolutamente non
sufficiente a giustificare il suo utilizzo in tal campo.

4.8)

I codec audio lossless: FLAC e WAV a confronto

Cos come accadeva per la codifica delle immagini fisse e quella delle immagini in movimento,
possibile codificare segnali audio in modo lossless. Mentre per le immagini fisse risulta ancora
conveniente adottare una codifica lossless a causa dell'ottima rappresentazione visiva e delle
dimensioni comunque ridotte (PNG), non si pu certo dire lo stesso per i video che, in modalit
lossless, risultano essere di circa 50 GB (AVI lossless senza compressione) o 22 GB (H.264 con
compressione lossless) per un video di 24 minuti in 1280x720 da 23,976 fps, progressivo.
Certamente, seppur rispetto ad una codifica lossless senza compressione ci sono stati miglioramenti,
un divario di 22 GB H.264 lossless contro i 550 MB H.264 lossy High 10bit, preset placebo, crf 14
per un video da 24 minuti di qualit ottima troppo vasto. Dunque, tutto ci conveniente per le
immagini ed impraticabile per i video, ma, per quanto riguarda la codifica audio, si ha una via di
mezzo. Come mostrato dai precedenti test, una canzone di durata media da 1 minuto e 14 a 44.1,
1411 kbps stereo da 15.1 MB pu essere compresso in 4.01 MB AAC lossy da 384 kbps VBR o in
4.11 MB AC3 lossy da 384 kbps CBR; ad ogni modo, ci potrebbe non tornare comodo nel mercato
consumer quando si hanno canzoni lossless da 4 minuti ed oltre che raggiungono la soglia di 50
MB. In questo senso, viene in aiuto il FLAC, un codec audio lossless che consente di avere una
compressione migliore rispetto al WAV e che, senza dubbio, pu tornare utile in innumerevoli casi.

WAV (Waveform Audio File Format)

Il WAV uno standard ideato agli albori dei computer da Microsoft ed IBM per poter portare i
bitstream audio proprio sui computer ed molto simile (se non quasi identico) all'AIFF ideato per il
MAC. Il WAV stato costantemente aggiornato fino al 2007, anno in cui stata effettuata l'ultima
release. L'audio contenuto nel WAV audio non compresso nel formato LPCM (Linear Pulse Core
Modulation), ovvero lo standard dei CD, che hanno due canali (stereo) LPCM con campionamento
a 44.1 KHz. Sebbene il WAV non sia molto utilizzato dal lato consumer e sia stato utilizzato in
passato prevalentemente per avere una copia identica del CD acquistato da poter riprodurre sui
computer, questo tutt'ora molto utilizzato nel lato professionale. Negli studi, difatti, talvolta
necessario avere un file stereo lossless non compresso da poter lavorare, modificare e preparare per
la messa in onda. Le emittenti radio pi famose che utilizzano il WAV per i file audio non compressi
nei vari passaggi di lavorazione interna (dallo studio di registrazione al playout) sono la BBC,
Global Radio UK e la ABC. Ad ogni modo, al momento della creazione del WAV agli albori dei
computer venne scelto di utilizzare un intero a 32bit per registrare il file size nell'header e dunque
un file audio singolo WAV non pu essere pi grande di 4GB ed alcuni lettori sono limitati a 2GB.
Mentre per la qualit CD di 44.1 KHz stereo a 1411 kbps CBR (bitrate costante) non compresso un
limite di 4GB pu sembrare un'enormit (circa 7 ore), tale limite facilmente oltrepassabile quando
si aumenta il campionamento e si hanno pi canali e non pi la codifica stereo.
Per tale motivo, stata rilasciata una nuova versione del WAV chiamata WAV64 che utilizza un
header a 64bit. Tale scelta stata d'obbligo, soprattutto se si pensa alle capacit del WAV che pu
vantare un campionamento che va da 1 Hz a 4.3 GHz ed un numero di canali che va dal mono,
allo stereo ad aumentare fino a 65535!

WAV ed il CD-DA (Compact Disk Digital Audio)

Molto spesso, nel lato consumer, vengono creati CD per autoradio od altro partendo dal WAV,
anche se il formato dei CD il CD-DA. Questo possibile in quanto sia il CD-DA che il WAV
contengono l'audio in PCM. Il WAV, difatti, nato proprio come formato audio per computer
e non pu essere riconosciuto dai CD in modo diretto.

Per poter inserire un file WAV su un CD in modo che questo possa essere riprodotto secondo gli
standard dei lettori CD, questo dev'essere privato dell'header ed i dati audio PCM devono essere
scritti direttamente sul CD secondo lo standard con un campionamento a 44.1 KHz.

FLAC (Free Lossless Audio Codec)

Il FLAC un codec audio che nasce dall'esigenza di avere una codifica audio lossless con
compressione e non pi priva di compressione come accadeva con il WAV. Il FLAC supporta
campionamenti da 1 a 655350 Hz e da 1 ad 8 canali. I canali, inoltre, possono essere accoppiati
(come nel caso dei canali stereo o della composizione 5.1) per sfruttare la loro correlazione
ed aumentare la compressione. Il funzionamento del FLAC molto semplice: questo codec utilizza
la predizione lineare per convertire i dati audio; tale predizione pu essere di quattro tipi quali
zero, verbatim, fixed linear e FIR linear. Per poter comprimere i file, possibile scegliere 8
livelli di compressione (tutti lossless, ovviamente) che vanno da 0 (fastest) ad 8 (smallest) e
cambiano precisione ed approccio. Una volta completato il calcolo di predizione secondo il
parametro di compressione richiesto (da 0 ad 8), vengono calcolate le differenze tra la predizione
ed il dato calcolato ed il risultato ottenuto da questo calcolo viene chiamato residuo.
Il residuo viene poi salvato utilizzando la codifica lossless di Golomb-Rice.

Il cuore del FLAC: la codifica di Golomb-Rice

La codifica di Golomb utilizza un parametro M per dividere il valore in input in due parti, quali q
(ovvero il risultato della divisione per M) ed r (il resto). Il quoziente inviato in codifica unaria
(encoding entropico che rappresenta un numero naturale n con n-uno seguiti da uno zero se il
numero naturale intero e non negativo, ed n meno 1 uno se il numero naturale intero e positivo)
seguita dal resto in encoding binario troncato.
Quando M uguale ad 1, la codifica di Golomb equivalente a quella unaria:

I codici di Golomb-Rice possono essere pensati come codici che indicano un numero per la
posizione di q e dell'offset con r. La figura soprastante mostra infatti la posizione di q e dell'offset r
per l'encoding di N interi utilizzando il parametro di Golomb-Rice M.
Formalmente, le due parti sono date dalla seguente espressione, dove x il numero da encodare:

ed r = x -qM -1. Il risultato finale assomiglia a (q + 1) r.

Da notare che r pu essere di un numero variabile di bit; nello specifico b bit nella codifica Rice,
e cambia da b-1 a b bit per la codifica di Golomb (ovvero M non una potenza di 2).
Supponiamo che:
Se:
allora vengono utilizzati b-1 bit per encodare r; ma se:

allora vengono utilizzati b bit per encodare r. Chiaramente,

se M una potenza di 2 e possiamo encodare tutti i valori di r con b bit.
Il parametro M una funzione del corrispondente processo di Bernoulli, che parametrizzato da:
la probabilit di successo in un dato tentativo di Bernoulli.
M anche la media della distribuzione o la media +/- 1 e pu essere determinata
da queste disuguaglianze:
Golomb dice che, per un largo M, c' una piccolissima penalizzazione nel prendere:

Il codice di Golomb per questa distribuzione equivalente al codice di Huffman per le stesse
probabilit, se fosse possibile computare il codice di Huffman.
Lo schema di Golomb era designato per per encodare sequenze di numeri non negativi, tuttavia
facilmente esteso per accettare sequenze contenenti numeri negativi utilizzando uno schema di
overlap ed interleave, nel quale tutti i valori sono riassegnati ad alcuni numeri positivi in modo
unico ed irreversibile. La sequenza comincia con 0, -1, 1, -2, 2, -3, 3, -4, 4 ecc. L'n-esimo valore
negativo (ovvero -n) mappato all'n-esimo valore dispari (2n-1) e l'm-esimo valore positivo
mappato all'm-esimo valore pari (2m). Questo pu essere matematicamente espresso come segue:
un valore positivo x mappato a
ed un valore negativo y mappato a:
Questo un codice prefisso ottimale solo se sia il positivo che la magnitudine dei valori negativi
seguono una distribuzione geometrica con lo stesso parametro.
Il FLAC utilizza anche il run-length encoding: dato un alfabeto di due simboli, o un set di due
eventi, P e Q, con probabilit rispettivamente di p e (1-p), dove p maggiore o uguale ad , la
codifica di Golomb pu essere utilizzata per encodare run di zero o pi Ps separati da un singolo
Q's. In questa applicazione la miglior impostazione per il parametro M l'intero pi vicino a:

Dove p = , M = 1 ed il codice di Golomb corrisponde all'unario (n maggiore o uguale a 0 P's,

seguito da un Q encodato come n uno seguiti da zero).

Valutazioni finali sul FLAC

Come visto ed analizzato in precedenza, il FLAC utilizza un metodo di codifica lossless che,
a differenza del WAV, utilizza un particolare metodo di compressione.
A differenza degli altri algoritmi di compressione lossless come il DEFLATE utilizzato nella
compressione zip, il FLAC, in quanto codec audio, comprime servendosi delle caratteristiche audio
ed i produttori attestano che in grado di raggiunge risultati molto pi efficienti rispetto alla
codifica usata dallo zip. Un file FLAC, inoltre, pronto per la decodifica in maniera immediata,
mentre un file zip deve essere estratto e poi riprodotto. Ad ogni modo, il FLAC, a differenza del
WAV, ha un'adozione minima proprio per il suo supporto che molto limitato.

Nel test effettuato, stato preso un file master originale da 3 minuti e 52 secondi a 44.1 KHz PCM.
Il processore utilizzato per effettuare questo test un Intel Atom N450 monocore, dual thread
con 512 kb di cache l2 (privo di cache l3) e 1.62 GHz con moltiplicatore statico a x10
(1662.7 MHz). Il file WAV 44.1 Khz 1411 kbps stato salvato in circa 4 secondi ed ha una
dimensione di 39.1 MB. Il file .rar salvato con modalit di compressione migliore stato invece
creato in 25 secondi ed ha un peso sostanzialmente minore del file WAV non compresso, di 30.8
MB. venuto poi il turno dei file FLAC che per la modalit di compressione migliore ha
impiegato ben 9 minuti e 47 secondi per encodare tale file con risultati discutibili, tra l'altro.
Il file finale un VBR da 31.4 MB, senz'altro migliore rispetto ai 39.1 MB del file WAV non
compresso, ma comunque inferiore rispetto ai 30.8 MB del file .rar. C' da dire che,
mentre il file rar deve essere estratto per essere riprodotto, il file FLAC no,
e 600 KB non sono di certo un grande vantaggio da parte del file .rar, per, di certo,
l'alto costo computazionale in encoding di 9 minuti e 47 secondi soprattutto se si utilizza una
macchina poco potente non da sottovalutare.
Come ultima riprova finale del fatto di essere lossless, ho deciso di mettere a confronto le due tracce
audio WAV non compressa e FLAC, analizzandone la forma:

- Valutazioni Finali della Tesi Con questo si conclude il percorso della tesi che ha visto il suo evolversi in 4 punti fondamentali:
le trasformate, il loro utilizzo nella codifica delle immagini fisse, nella codifica di quelle in
movimento e nella codifica dei segnali audio. Alla fine di questo percorso, stato possibile appurare
come la trasformata di Karhunen-Love sia la miglior trasformata possibile in termini di
compressione, ma questa sua peculiarit sia in parte vanificata dal fatto che utilizza delle funzioni di
base dipendenti dal dato di ingresso, il che comporta la continua computazione della matrice di
convarianza del segnale in ingresso, cos come la sua memorizzazione e la trasmissione.
Il suo utilizzo nell'HEVC si dimostrato utile, ma solo quando la trasformata Discreta del Coseno
non riesce ad avere risultati ottimali. La DCT infatti si dimostrata essere un'ottima trasformata
e le sue caratteristiche quali utilizzare solo numeri reali ed il fatto di essere periodica in 2N hanno
sancito la sua vittoria contro la trasformata di Fourier che utilizza invece numeri complessi ed
periodica in N, introducendo discontinuit pi grandi. La trasformata di Walsh-Hadamard utilizza
invece matrici puramente reali ed il suo impiego ha un bassissimo costo computazionale, tuttavia,
anche la sua capacit di compressione altrettanto modesta. Durante la tesi stato poi inoltre
possibile vedere come la trasformata Discreta di Wavelet sia tornata utile nel tentare un altro
approccio nella codifica delle immagini fisse, quella del JPEG2000, con la trasformata non pi
applicata a blocchi, per ottenere un'immagine esente da blocking, a differenza del JPEG normale.
Durante la tesi stato poi possibile appurare come, per la codifica delle immagini fisse, sia possibile
ottenere dei buoni rapporti di compressione in modalit lossless (come nel caso del PNG) e come
questo non sia possibile per la codifica delle immagini in movimento, con la codifica audio a met
strada con lo standard FLAC lossless che non porta per compressioni ottimali ed il cui supporto
ancora limitato ad un numero ridotto di device. La tesi ha inoltre illustrato l'evoluzione dei vari
standard di codifica video e l'implementazione di una versione modificata dell'H.264,
che poi ha portato allo sviluppo dell'H.265 HEVC. Durante la tesi stato infine possibile vedere
come alcuni approcci abbiano aperto le strade allo sviluppo di nuovi codec, mentre altre si siano
rivelate inefficaci e siano state poi abbandonate negli standard successivi. In definitiva,
posso affermare che da sempre l'uomo ha cercato di comprimere i segnali inviati, siano questi video
od audio, nei pi diversi modi ed utilizzando le pi disparate tecnologie; sono stati ideati diversi
metodi che utilizzano vari tipi di trasformata ed, addirittura, pi di una trasformata, cercando di
tenere in conto il rapporto tra compressione, qualit e costo computazionale.
Alcune soluzioni sono state un inizio, altre sono state sorpassate ed altre ancora non hanno
funzionato fin dai loro albori, ma ognuna di esse, ognuno di questi approcci senz'altro servito ai
ricercatori successivi per sviluppare al meglio i modelli susseguenti e, cos come i ricercatori del
passato hanno usufruito delle tecnologie e degli sbagli dei loro predecessori, anch'io spero che le
ricerche svolte possano servire agli sviluppatori futuri - che un domani volteranno lo sguardo al
passato - di poter continuare il loro sviluppo per far evolvere le tecnologie verso il futuro.
Francesco Bucciantini
Computer Science Engineer

Bibliografia

W.J Choi, S.Y Jeon, C.B Ahn, S.J Oh A multi-dimensional transform for future video
coding, the 23rd international technical conference on circuits/systems
B.Furht, K.Gustafson, H. Huang, O. Marques, An adaptive three-dimensional DCT
compression based on motion analysis, proceedings of the ACM symposium on applied
computing
B.Zeng, J.Fu Directional discrete cosine transform a new framework for image coding
IEEE transactions on circuits and systems for video technology
S.Ma C.Kuo High-definition video coding with super-macroblocks, proceeding SPIE
visual communications and image processing
J.Dong, K.N. Ngan, C.K. Fong, W.K Cham, 2-D order 16 integer transforms for HD video
coding IEEE transactions on circuits and systems for video technology
N. Kamaci, Y. Altunbasak Performance comparison of the emerging H.264 video coding
standard, IEEE International conference on Multimedia and Expo
M.H Pinson, S.Wolf, G.Cermak, HDTV Subjective quality of H.264 vs MPEG-2, with and
without packet loss, IEEE Transactions on broadcasting
T.Wiegard, G.J Sullivan, G.Bjontegaard, A. Luthra, Overview of the H.264/AVC Video
Coding standard, IEEE transactions on circuits and systems for video technology
K.Panusopone, A. Luthra, Performance comparison of MPEG-4 and H.263+ for streaming
video applications, circuits systems signal processing
F. Pereira, T. Ebrahimi, Eds, The MPEG-4 book
B. Girod, E. Steinbach, N.Farber, Comparison of H.263 and H.261 video standards,
standard and common interfaces for video information systems
Brogent Techologies Inc, Video compression
ITU-T, Reccomendation, H.263
L.Maki, Video compression standards
S.Liu, Performance comparison of MPEG-1 and MPEG-2 video standards, IEEE
Proceedings of COMPCON
T.Von Roden, H.261 and MPEG-1 A comparison, Conference proceedings, IEEE annual
international phoenix conference of computer communications
F.Pereira, Digital video storage
M.Handley, H.261
M.Liou Overview of the px64kbit/s video coding standard, communications of the ACM
Athanassios Skodras, Charilaos Christopulos, Touradj Ebrahimi, The JPEG 2000 Still
image compression standard, IEEE Signal processing magazine
M.W Marcellin, M.J Gormish, A. Bilgin, M.P Boliek, An overview of JPEG 2000, IEEE
Data compression conference
ITU-T, Reccomendation T.81
G.Bjontegaard Calculation of the average PSNR Differences between RD-Curves, VCEGMeeting
JCT-VC Common test conditions and software reference configurations JCTV-B300,
meeting, Switzerland

F. Pereira, Digital Image Compression

Math-works: eigenvalues and eigenvectors function
Math-works: Reshape function
Math-works: Cosine function
Math-works: Sine function
Math-works: Discrete Cosine Transform matrix
Math-works product: MATLAB
W.H Chen, C. Smith, S. Fralick, A fast computational algorithm for the Discrete Cosine
Transform, IEEE Transactions on communications
M. Naccari, Recent advances on High Efficiency Video Coding (HEVC)
M. Naccari, F. Pereira Integrating a spatial just noticeable distortion model in the under
development HEVC codec, International conference on acoustics, speech and signal
processing, Czech Republic
JCT-VC Suggestion for a Test Model, JCTV meeting, Germany
JCT-VC Draft call for proposal on High Performance Video Coding (HVC), Japan
M.Lobato, D.F.P. Capelo, Advances on transforms for High Efficiency Video Coding
BBC UK: HEVC software coordination
Iphome Deustchland: H.264/AVC software coordination
M.R Pickering, Optimum basis function estimation for inter-frame perdiction errors
F. Pereira: advanced multimedia coding
P. Waldemar, S.O Aase, J.H. Husoy, A critique of SVD-based image coding systems,
proceeding of the IEEE international symposium on circuits and systems, Florida, USA
M. Biswas, M. R. Pickering, M.R Frater, Improved H.264 based video coding using an
adaptive transform, proceeding of IEEE international conference on image processing,
Hong Kong
R. Westwater, B. Furht, Real time video compression techniques and algorithms,
Norwell, USA
A. N Netravali, B. G Haskell, Digital pictures: representation, compression and standards,
New York, USA
G. R Pehrson, T. Boutell, A. M. Costello, T. Lane, PNG (Portable Network Graphics)
Specification
H. Autti, J. Bistrom Mobile audio, from mp3 to AAC and further
D. Y. Pan, Digital audio compression
Hari, Compression algorithms: Huffman and Lempel-Ziv-Welch (LZW)

This work is licensed under a Creative Commons Attribution 4.0 International License.

Francesco
Bucciantini

Digitally signed by Francesco

Bucciantini
DN: cn=Francesco Bucciantini, o, ou,
email=franceopf@gmail.com, c=US
Date: 2016.04.22 13:33:42 +02'00'