Una valutazione comparativa dei codec di

Transcript

Università di Bologna
Facoltà di Scienze Matematiche, Fisiche e Naturali
Dipartimento di Informatica
Corso di Laurea in Informatica
Tesi di Laurea
Una valutazione comparativa dei codec di
compressione video di ultima generazione
Relatore
Prof. Fabio Panzieri
Candidato
Simone Chiesa
Università di Bologna
matr. 0000119125
Parole chiave: compressione video, codec, comparazione, standard, prestazioni
Anno Accademico 2005/06
A mio padre e a mia madre
"La Vita, senza Amore,
sarebbe solo un conglomerato
di molecole"
Indice generale
VIDEO DIGITALE
1.1 Cos'è un codec?........................................................................................................................9
1.2 Lossy o Lossless?...................................................................................................................10
Compressione lossless.......................................................................................................10
Compressione lossy...........................................................................................................11
Differenza tra flussi audio e video.................................................................................... 12
1.3 I container.............................................................................................................................. 14
Formato File...................................................................................................................... 14
Specifiche..........................................................................................................................14
I formati container.............................................................................................................15
1.4 Linee TV, pixel e campioni................................................................................................... 17
1.5 I tipi di spazio colore............................................................................................................. 17
RGB.................................................................................................................................. 18
YUV.................................................................................................................................. 19
YUV 4:4:4.........................................................................................................................20
YUV 4:2:2.........................................................................................................................20
YUV 4:2:0.........................................................................................................................21
Conversione RGB ↔ YUV...............................................................................................23
LA COMPRESSIONE VIDEO
2.1 Tipi di frames.........................................................................................................................27
Gli intra-frames................................................................................................................. 28
I Delta-Frames od Inter-Frames........................................................................................ 28
B-frames / Bi-directional encoding:..................................................................................29
2.2 Conversione dello spazio di colore........................................................................................31
2.3 Blocking.................................................................................................................................32
2.4 Modellizzazione del moto......................................................................................................33
Motion Estimation (ME) .................................................................................................. 33
Motion Compensation (MC)............................................................................................. 34
2.5 DCT, Discrete Cosine Transform.......................................................................................... 37
2.6 Quantizzazione.......................................................................................................................38
2.7 Zig-Zag Scanning.................................................................................................................. 40
2.8 Run-Level encoding (RLE) e Variable-Lenght coding (VLC)..............................................40
2.9 Bit-rate................................................................................................................................... 44
2.10 CBR e VBR......................................................................................................................... 44
2.11 1-pass e n-pass..................................................................................................................... 45
Modalità 1-pass................................................................................................................. 46
Modalità a 2-pass.............................................................................................................. 47
2.12 I difetti dei codec lossy........................................................................................................ 48
LO STANDARD MPEG-4
3.1 MPEG.................................................................................................................................... 50
3.2 MPEG-4................................................................................................................................. 52
Componenti dell'MPEG-4.................................................................................................54
3.3 H.264/AVC............................................................................................................................ 55
Algoritmi e profili............................................................................................................. 56
Macro-blocchi e slice........................................................................................................ 59
Predizione e codifica intra.................................................................................................59
Predizione e codifica inter.................................................................................................60
Trasformata e quantizzazione........................................................................................... 60
Filtro di ricostruzione........................................................................................................61
Codifica VLC.................................................................................................................... 61
3.4 Incremento in qualità e in complessità.................................................................................. 62
3.5 Applicazioni:..........................................................................................................................64
Diffusione televisiva a definizione standard..................................................................... 65
Diffusione televisiva ad alta definizione...........................................................................65
3.6 Implementazioni software......................................................................................................66
VALUTAZIONE DELLA QUALITA'
4.1 Il problema dei metri di valutazione...................................................................................... 68
4.2 Problemi.................................................................................................................................69
Dipendenze dalle scene di input........................................................................................69
Dipendenze dai sistemi di trasmissione digitali................................................................ 69
Nuovi disturbi del video digitale.......................................................................................69
La necessità dell'indipendenza della tecnologia................................................................70
4.3 Valutazione soggettiva...........................................................................................................70
4.4 Valutazione oggettiva............................................................................................................ 71
Il PSNR............................................................................................................................. 71
SSIM................................................................................................................................. 74
VQM................................................................................................................................. 74
COMPARAZIONE
5.1 Risorse utilizzate....................................................................................................................77
5.2 Codec LOSSLESS................................................................................................................. 79
5.3 Codec LOSSY........................................................................................................................99
Introduzione
Il video digitale è ormai una realtà che abbraccia diversi momenti della nostra giornata. Tutti, chi
più e chi meno, si trovano e si troveranno sempre più a fare i conti con la tecnologia di trasmissione
audiovisiva digitale. Come negli anni '50 la diffusione della Televisione ha dato un contributo
fondamentale all'alfabetizzazione di massa, così nel 2000 la diffusione dei servizi di video on
demand ha iniziato il processo di alfabetizzazione avanzata per il cittadino, che comporta
un'estensione di alcuni valori fondamentali della democrazia come libertà di stampa, di pensiero, di
espressione. Se fino ad oggi queste libertà si sono concretizzate limitatamente alla scrittura ed alle
immagini per problemi, così diciamo, tecnici, oggi con l'abbassamento dei prezzi delle nuove
tecnologie trasmettere l'informazione tramite audiovisivi è più che mai alla portata di tutti. Il video
è molto più diretto, veloce, appetibile rispetto alle parole scritte che richiedono più concentrazione
da parte di chi le legge. Le immagini accompagnate dai suoni descrivono da sole una scena con un
colpo d'occhio da mezzo secondo (un principio conosciuto bene dai professionisti della pubblicità).
I canali di trasmissione si moltiplicano, le fonti aumentano in maniera esponenziale ogni giorno e la
sete di conoscenza accresce anche e soprattutto laddove esistono restrizioni alla libertà (guerre,
dittature, regimi totalitari, ecc.). Ormai sono note a tutti le potenzialità della rete Internet e già da
qualche anno i servizi di informazione on-line hanno sorpassato i tradizionali giornali e telegiornali.
Le TV via Internet tramite streaming o download sono già una realtà (in Italia è popolare l'ottima
Arcoiris.tv) così come lo scambio di files tramite peer-to-peer o l'archiviazione in rete di grandi
database audiovisivi (Google Video). Presto non saranno più solo poche persone a decidere che
cosa debba passare sugli schermi, ma sarà il singolo individuo a scegliere come, quando e cosa
guardare. Già oggi sono disponibili anche servizi di video on demand tramite satellite o digitale
terrestre, ma è una realtà ancora per “pochi” (dati i costi degli abbonamenti) e che “puzza” ancora
del vecchio sistema televisivo in cui c'è sempre qualcuno che sceglie che cosa proporre allo
spettatore. Entro qualche anno sono convinto che le televisioni come le conosciamo noi
scompariranno: il sistema piramidale attuale lascerà il posto a un'informazione e una produzione
artistica “dal basso”, in cui il confine tra produttore di audiovisivi e spettatore sarà molto sfumato.
Oggi è facile prendere in mano una videocamera e girare un video digitale. Ma è ancora difficile per
molti semi-professionisti fare il passo successivo: renderlo un prodotto distribuibile e consultabile
da tutti in maniera corretta e semplice. L'encoding è l'ultimo passo della post-produzione digitale e
giugno 2006
7
rappresenta uno scoglio che sia il professionista sia l'amatore cineasta, giornalista o quant'altro
devono imparare a superare al più presto se si vuole produrre in maniera autonoma, corretta e
standardizzata video di qualità. Anche l'utente semplice che fruisce delle nuove tecnologie
audiovisive (I-pod, fotocamere digitali, videofonini, ecc.) deve conoscere le basi dell'encoding se
vuole sfruttare a pieno le potenzialità dei dispositivi. E per finire, anche il semplice spettatore che
preleva video della rete dovrebbe sapere che cosa è un codec o rischia di ritrovarsi svariati messaggi
di errore ogni qualvolta cerchi di aprire un video sul proprio lettore multimediale, per non parlare
dell'aumento di qualità possibile tramite un corretto settaggio delle impostazioni di decoding.
Questo documento tratta dell'encoding di video digitale. E' una panoramica sulle tecnologie attuali e
sui codec di compressione video disponibili attualmente sul mercato commerciale e opensource. Il
Capitolo 1 è un'introduzione per capire come funziona il video digitale. Il capitolo 2 tratta i principi
e le tecniche di base della compressione video. Il capitolo 3 è dedicato all'MPEG-4 e al nuovo
importantissimo standard H.264/AVC. Nel capitolo 4 si discutono le tecniche per valutare la qualità
e le prestazioni di un video digitale. Nel capitolo 5 c'è una comparazione e una valutazione pratica
dei migliori codec video in circolazione, per aiutare a scegliere quello più adatto alle proprie
esigenze.
Per il suo linguaggio e per il suo contenuto questo documento è indicato sia al neofita, sia
all'appassionato, sia al professionista del video digitale.
8
giugno 2006
1
VIDEO DIGITALE
1.1 Cos'è un codec?
Un CODEC (enCOder/DECoder o COmpressor/DECompressor) è un programma o un dispositivo
che si occupa di codificare e decodificare digitalmente un segnale o un flusso di segnali
(tipicamente audio o video). Tale programma può essere installabile (su personal computer o
apparecchiature multimediali predisposte) oppure essere integrato in un componente hardware
dedicato (ad es. nei lettori CD o DVD casalinghi o in alcune schede video/audio per PC).
Un codec codifica il segnale per la trasmissione, la memorizzazione o la criptazione e lo decodifica
per la visione o la modifica. Oltre alla digitalizzazione del segnale, i codec effettuano anche una
compressione (e decompressione in lettura) dei dati ad esso relativi, in modo da poter ridurre lo
spazio di memorizzazione occupato a vantaggio della portabilità o della trasmissibilità del flusso
codificato.
Esistono vari tipi di codec, differenti tra loro per il tipo di segnale cui sono destinati e per
l'algoritmo di compressione in essi implementato. Molti flussi di dati multimediali hanno necessità
di contenere sia dati audio che dati video, e spesso qualche forma di meta-dati che permettano la
sincronizzazione dell'audio e del video. Ognuno di questi tre flussi possono essere gestiti da
giugno 2006
VIDEO DIGITALE
9
differenti programmi, processi o circuiti hardware, ma per essere utilizzabili devono essere
incapsulati insieme in un "container". Molte persone credono che AVI sia un codec, ma questo è
sbagliato. AVI è un container che i diversi codec possono usare. La confusione deriva dal fatto che
spesso il nome del formato (estensione), del container e del codec coincidono (un esempio è MP3).
Ci sono altri container alternativi ben conosciuti come per esempio Ogg, ASF, QuickTime,
RealMedia. Mentre alcuni esempi di codec sono m4a, CDA, FLAC, wave, AC3 per l'audio; MPEG2, DivX, Huffyuv, Xvid, H.264 per il video. In definitiva, un codec è un insieme di algoritmi che
analizzano, decompongono, comprimono e infine memorizzano un flusso audio/video, che seguirà
il processo inverso per essere utilizzato. In questa tesi ci occuperemo principalmente di analizzare il
processo di coding.
1.2 Lossy o Lossless?
L'obiettivo di ogni progettista di codec dovrebbe essere di mantenere la qualità audio e video e allo
stesso tempo comprimere lo spazio il più possibile. Ma questi 2 fattori sono inversamente
proporzionali, ovvero maggiore è la qualità maggiore è lo spazio occupato e viceversa, quindi lo
scopo del progettista diventa trovare un algoritmo che abbia il miglior compromesso tra qualità,
compressione e velocità di esecuzione. Le tecniche di compressione video (ma questo vale per gli
algoritmi di compressione in generale) possono essere suddivise in due grandi categorie: le tecniche
cosiddette "lossless", nelle quali la compressione è un processo perfettamente reversibile che
avviene senza perdita di informazione e dove video originale e video decompresso sono identici in
tutti i dettagli, e le tecniche "lossy" o tecniche di compressione non reversibile, nelle quali video
compresso e decompresso non sono più identici in quanto al momento della compressione sono
state volutamente eliminate alcune informazioni ritenute "sacrificabili". Le tecniche "lossy" sono le
più diffuse per la compressione del multimediale, ed infatti appartengono a questa categoria le
codifiche MPEG (1, 2 e 4), il Divx, l'Xvid, l'mp3, il Vorbis ecc...; invece generalmente le tecniche
di compressione lossless vengono utilizzate nella compressione dei documenti (zip, rar, etc...) o nel
multimediale nella gestione di materiale sia per l'editing (audio e video) che per l'archiviazione
sicura.
1.2.1 Compressione lossless
Da un punto di vista teorico la massima qualità si otterrebbe facendo uso di video non compresso,
10
VIDEO DIGITALE
giugno 2006
ma passando alla pratica ci si scontra subito con due problemi fondamentali: il video non compresso
occupa troppo spazio (soprattutto quando si utilizzano risoluzioni elevate, ad esempio un video in
RGB24 di 720x576 pixel occupa circa 30MB al secondo, e con 2GB si riescono a registrare al
massimo un paio di minuti), ed inoltre richiede prestazioni elevate per il corretto funzionamento
(soprattutto per quanto riguarda la velocità dell'Hard Disk..). I codec lossless permettono di ottenere
la stessa qualità ma riducendo lo spazio occupato. Un video compresso con il codec Huffyuv per
esempio, richiede circa un terzo dello spazio necessario rispetto a quello di un video non compresso
(video a 704x576 richiedono intorno ai 9MB al secondo, valore alla portata della maggior parte
degli Hard Disk in commercio). I codec lossless vengono principalmente utilizzati in ambito
professionale: per l'editing, per il passaggio del materiale tra sistemi diversi o per l'archiviazione di
materiale audiovisivo. Alcuni esempi di codec audio lossy sono: AAC (Advanced Audio Coding),
MP3 (MPEG-1 Layer 3), Vorbis, lossy Windows Media Audio. I codec video sono elencati nel
capitolo 5.
1.2.2 Compressione lossy
Quando si parla di codec video si parla soprattutto di codec lossy. I metodi di compressione di dati
di tipo lossy sono quelli in cui i dati prima compressi e poi decompressi sono diversi dagli originali,
ma sono "abbastanza somiglianti" per essere utili a seconda dei casi. Il vantaggio dei metodi lossy è
che producono file molto più piccoli rispetto ai metodi lossless, pur mantenendo i requisiti di
qualità
minima dell'applicazione. Questo tipo di compressione è spesso usata in Internet e
specialmente nello streaming di dati multimediali e nelle applicazioni di videotelefonia. Quando un
utente acquisisce un file compresso lossy (per esempio per ridurre il tempo di download da Internet)
il file ricevuto può essere molto diverso dall'originale a livello di bit ma può essere indistinguibile
alle orecchie o agli occhi umani per la maggior parte degli utilizzi. Molti metodi si focalizzano sulle
idiosincrasie dell'anatomia umana considerando, per esempio, che l'occhio può vedere solo alcune
frequenze della luce e che ci sono modelli psico-acustici che descrivono come il suono può essere
altamente compresso senza degradare la qualità del suono percepito. L'incremento della qualità
utilizzando codec lossless sarebbe spesso impercettibile e il considerevole aumento di spazio
richiesto (soprattutto per il video) non ne giustifica di fatto l'utilizzo nei prodotti user-consumer.
Ecco perché sugli scaffali dei negozi si trovano DVD (che è codificato con MPEG-2, lossy) e non
cassette Mini-DV o DV-CAM (lossless). Eppure per i non addetti ai lavori il DVD è considerato
video ad alta qualità. Su Internet vengono venduti MP3 (lossy) e non tracce audio CDA o file WAV
giugno 2006
VIDEO DIGITALE
11
(lossless). Anche i nuovi supporti di alta definizione (Blu-Ray e HD-DVD) fanno uso di codec lossy
e in particolare del codec H.264/AVC, il codec video della specifica standard definita nell'MPEG-4
part-10 (vedi Capitolo 3). Per realizzare una compressione lossy si fa quindi ricorso alla riduzione
della precisione dei colori dei singoli pixel (codec video) o delle frequenze da riprodurre (in alcuni
codec audio vengono soppresse le frequenze non udibili dall'orecchio umano), alla eliminazione
delle ridondanze o alla scrittura delle sole differenze (codec video) rispetto ad una immagine di
riferimento. Esistono codec molto buoni che riescono a comprimere i dati senza che la differenza di
qualità sia percettibile. Esempi di codec audio lossless sono: Apple Lossless, FLAC, Monkey's
Audio, Shorten, TTA, lossless Windows Media Audio, WavPack.
1.2.3 Differenza tra flussi audio e video
Quando si vuole comprimere un video ci si trova a dover fare i conti con diversi parametri di
configurazione, qualsiasi codec si utilizzi. Facendo alcuni esperimenti si nota subito come un
piccolo cambiamento nel settaggio della codifica video influisca molto sul file-size finale, mentre
cambiando i parametri per l'audio non si ottengono variazioni significative. E' importante a questo
punto capire la differenza, in termini di spazio occupato, tra differenti tipi di dato multimediale.
Un flusso audio è in un certo senso bidimensionale: un suono ha bisogno di un solo numero per la
sua rappresentazione (il valore di ampiezza del segnale), tipicamente 16 o 24 bit (al massimo 32).
Questo valore viene registrato un certo numero di volte in un determinato intervallo di tempo (di
solito un secondo), in relazione alla frequenza desiderata. Campionare un suono a 32 Khz significa
registrare la variazione del segnale di ampiezza 32.000 volte al secondo. Quindi un flusso audio
campionato tipicamente a 16 bit e 44.1 Khz (qualità cd) occuperà1
16 x 44.100 = 705.600 bit/s = 86,13 KB/s
Per un'ora di audio stereo (a 2 canali, quindi si registrano 2 flussi audio) non compresso saranno
quindi necessari
1 Per la comprensione dei calcoli effettuati ricordiamo alcune nozioni di base delle unità di misura digitali:
•
1 Byte = 8 bit
•
i Bytes si indicano con la B maiuscola, i bit con la b minuscola
•
Quando si passa tra Kilo, Mega e Giga bisogna moltiplicare o dividere per 1024, non per 1000. Quindi:
1 KB = 1024 bit
1 MB = 1024 KB
1 GB = 1024 MB
12
VIDEO DIGITALE
giugno 2006
2 x 16 x 44.100 x 60 x 60 = 5.080.320.000 bit = 605,62 MB
Un dato video, o pixel, ha bisogno tipicamente anch'esso di 24-bit per essere rappresentato
correttamente (vedi sezione 1.5) ma questo valore va moltiplicato per il numero di linee orizzontali
e verticali dell'immagine. E' quindi un valore a 4 dimensioni in cui i fattori sono: valore del pixel,
larghezza, altezza e tempo. Supponendo di avere valori standard come 24-bit per pixel e risoluzione
di 720 linee per 576 colonne ad una frequenza (PAL) di 25 immagini al secondo, si fa un rapido
calcolo:
24 x 720 x 576 x 25 = 248.832.000 bit/s = 30.375 KB/s = 29,66 MB/s
per un'ora di video non compresso ci vorranno allora
29,66 x 60 x 60 = 106.787 MB = 104,28 GB
Un minuto di audio stereo non compresso pesa 10 MB, un ora 605 MB. Un minuto di video non
compresso pesa 1780 MB, un'ora 106.800 MB. Abbiamo quindi un rapporto di 178:1, ovvero i dati
video non compressi pesano 178 volte più di quelli audio (stereo). Si conclude che lo spazio
richiesto per memorizzare un flusso video non compresso è enormemente maggiore di quello
richiesto per memorizzare un flusso audio. Pertanto una corretta e bilanciata codifica di un
documento audiovisivo avrà sempre un audio di ottima qualità, anche se la qualità video sarà scarsa.
Nei codec lossy però il rapporto di compressione (ovvero lo spazio di memorizzazione richiesto dal
file compresso comparato a quello richiesto dal file non compresso) su dati di tipo video è quasi
sempre largamente superiore rispetto a quello su dati di tipo audio. L'audio può essere compresso a
10:1 senza perdita di qualità percettibile, il video può essere compresso anche oltre 300:1 senza che
l'occhio umano scorga le differenze. Questo di fatto attenua un po' la forbice tra audio e video.
Inoltre si pensi che immagini ferme compresse con metodi lossy (per esempio un'immagine JPEG)
sono spesso compresse a 10:1, così come l'audio, ma la perdita di qualità è più visibile, soprattutto
se le immagini sono piccole. Si può già ipotizzare quindi che nel comprimere video si utilizzino
tecniche avanzate che agiscono sui flussi di immagini con maggiore efficacia rispetto alla
compressione dei singoli fotogrammi.
giugno 2006
VIDEO DIGITALE
13
1.3 I container
1.3.1 Formato File
In informatica, un formato di file è la convenzione che viene usata per leggere, scrivere e
interpretare i contenuti di un file. Poiché i files non sono altro che insiemi ordinati di bytes, cioè
semplici numeri, per poter associare al loro contenuto cose diverse si usano convenzioni che legano
i bytes ad un significato. Ad esempio, un formato di file per immagini può stabilire che i primi due
bytes sono l'altezza e la larghezza dell'immagine, e i seguenti i colori secondo uno schema
preordinato. I files di testo usano vari standard di codifica (come lo standard ASCII) per
rappresentare lettere e formattazioni diverse. È teoricamente possibile, con leggere manipolazioni,
interpretare il contenuto di un file come se fosse codificato secondo un formato diverso da quello
con cui è stato creato: i byte letti sono generalmente validi, anche se non dotati di molto senso; ad
esempio è possibile leggere un'immagine come se fosse un file musicale, ma molto probabilmente si
otterranno solo rumori e non musica. Il formato di un certo file è comunemente indicato attraverso
l'estensione, che è una serie di lettere (in genere tre, per motivi storici) unita al nome del file
attraverso un punto. Ad esempio, "prova.txt" è un file di testo (o meglio, il suo contenuto va
interpretato come testo), mentre "prova.jpg" è un'immagine.
1.3.2 Specifiche
Per molti formati sono state pubblicate delle specifiche che descrivono esattamente come i dati
devono essere codificati e che possono essere usate per stabilire se un programma specifico tratti
correttamente o meno un determinato formato. Non sempre tali specifiche sono disponibili:
innanzitutto alcuni formati sono considerati segreti industriali e le loro specifiche non vengono
distribuite pubblicamente, come avviene ad esempio per molti dei formati proprietari di Microsoft;
inoltre in molti casi gli sviluppatori non scrivono un documento di specifica separato, ma
definiscono il formato solo implicitamente attraverso il programma che lo gestisce.
In questo modo i dati salvati con quel programma non possono essere letti con altri programmi
simili (il file può sempre essere letto da qualunque programma: ma i dati restano incomprensibili, se
non si conosce il formato con cui sono stati salvati). Risalire ai dati originali salvati in un formato
sconosciuto è sempre possibile, attraverso un lavoro di reverse engeenering, ma è di solito un
processo molto lungo e costoso. Se il formato in questione è anche criptato, risalire ai dati diventa
14
VIDEO DIGITALE
giugno 2006
praticamente impossibile. Ci sono esempi in cui si effettua invece il contrario, ovvero si progettano
e si pubblicano le specifiche e gli standard ma non si implementano concretamente i programmi. E'
il caso del gruppo di lavoro internazionale MPEG, che ha stabilito alcuni degli standard video più
importanti e diffusi a livello mondiale.
1.3.3 I formati container
Un formato container è un formato di file che può contenere vari tipi di dati multimediali. Si
potrebbe dire che il container sia un sottoinsieme del concetto di formato, specializzato per i dati
multimediali. Conoscendo le specifiche del container il programma dedicato è in grado di
identificare e interpretare i differenti tipi di dato e di farne l'interleaving (ad esempio individuare e
settare un valore che stabilisce quanto spesso i flussi audio e video sono sincronizzati). I formati
container più semplici possono contenere un solo tipo di audio o video codificato, mentre i più
avanzati (e flessibili) sono in grado di raggruppare audio, video, sottotitoli, capitoli e meta-dati
(tags), insieme con le informazioni necessarie per riprodurre i vari flussi sincronizzati. Ad esempio
WAV è un container audio semplice mentre mp4 è un container flessibile che può gestire al suo
interno molti tipi di audio e video. L'estensione di un file caratterizza il tipo di container: per
esempio “prova.mkv” è un formato container Matroska, “prova.rm” è un formato container Real
Media. Da notare che il termine “formato container” viene spesso abbreviato solo in “container”
oppure direttamente in “formato” creando così una certa confusione terminologica. In questo testo
cercheremo di mantenere le distinzioni, ma il lettore non si preoccupi troppo se fa confusione tra i
due termini, che in fondo nella pratica sono la stessa cosa. Le differenze tra i vari container
risiedono in cinque principali punti:
1. Popolarità: quanto largamente è diffuso e supportato un container. AVI è ancora il
container più popolare sebbene ormai sia obsoleto, perché è stato lo standard adottato nei
sistemi Microsoft
2. Sovra-spazio: è la differenza in MB tra due file con lo stesso contenuto ma due container
diversi. Un film di due ore in AVI può occupare fino a 3 MB in più dello stesso film in
Matroska.
3. Supporto per funzionalità avanzate dei codec. I container più vecchi come AVI non
supportano nuove funzionalità come B-Frames, VBR audio, VFR nativo, sebbene possano
giugno 2006
VIDEO DIGITALE
15
essere "truccati" per aggiungere il supporto, ma creando così problemi di incompatibilità
4. Supporto per contenuto avanzato, come capitoli, sottotitoli, meta-tags, user-data.
5. Supporto per lo streaming.
Tabella 1.3.3 - Confronto tra i container più diffusi: Matroska è il formato container di dominio pubblico: è
sicuramente il migliore e il più flessibile. Peccato sia ancora poco popolare e poco utilizzato.
Container
3GP
Proprieta BVBR VBR Capitoli Sottotitoli
rio
frame audio video
3GPP
ASF
(Advanced
Microsoft
Systems
Format)
?
si
si
si
?
?
Standard video
supportati
Standard audio
supportati
Stream
3gp Timed
Text
MPEG-4, H.263 e
H.264/AVC
AMR-NB/WB e
(HE)-AAC
si
Quasi tutti tramite
VFW o DMO,
H.264/AVC è
problematico
Quasi tutti tramite
ACM o DMO,
Vorbis è
problematico
si
Quasi tutto tramite
Quasi tutti tramite
VFW, H.264/AVC è
ACM o DMO,
problematico a
Vorbis è
causa dei bproblematico
frames
si
si
si
si
Si, ma
solo
tramite
“hacks”
AVI
Microsoft
si
si
si
Si, ma
solo
tramite
“hacks
”
DivX
DivX
si
si
si
si
si
Tutti quelli
codificati con
FourCC DivX
mp3, PCM, AC-3
si
pubblico
si
si
si
si
si
Tutti
tutti
si
BSD
?
?
?
?
?
tutti
tutti
si
MPEG-2
PS
(Program
Stream)
MPEG
si
si
?
Solo
nei file
VOB
su DVD
Solo nei
file VOB
su DVD
MPEG-1, MPEG-2
MPEG-1 Layers I,
II, III (mp3), AC-3,
LPCM, DTS
si
MPEG-2
TS
(Transport
Stream)
MPEG
si
si
si
No
possibile
via ETSI
EN 300
743
MPEG-1, MPEG-2,
MPEG-4 ASP,
H.264/MPEG-4
AVC
MPEG-1 Layers I,
II, III (mp3), AC-3,
LPCM, DTS, AAC
si
MOV
Apple
si
si
si
si
si
Tutti tramite
QuickTime codec
manager
Tutti tramite
Sound Manager o
CoreAudio
si
si
Si, ma
con
restrizi
oni
Si, ma con
restrizioni
MPEG-1, MPEG-2, MPEG-1 Layers I,
MPEG-4 ASP,
II, III (mp3), MPEGH.264/MPEG-4
2/4 (HE)-AAC,
AVC
vorbis
si
Theora, quasi
Si, ma con tutto tramite VFW, Vorbis, quasi tutto
OGMtools
H.264/AVC non
tramite ACM
funziona
si
Matroska
MCF
MP4
MPEG
si
si
OGG/
OGM
Xiph.org
RMVB
RealNet
works
si
?
si
MPEG
si
si
si
VOB
16
si
si
No
si
?
Si, ma
solo
tramite
“hacks”
si
VobSub
RealVideo 8, 9, 10
(HE)-AAC, Cook
Codec, Vorbis,
RealAudio
Lossless
si
MPEG-2 Part 2
AC-3, Linear PCM,
DTS, MPEG-2 Part
3, MPEG-1 Layer II
si
VIDEO DIGITALE
giugno 2006
1.4 Linee TV, pixel e campioni
Una immagine TV analogica viene normalmente descritta come il risultato di una scansione operata
da sinistra verso destra e dall'alto verso il basso. Ogni scansione completa è costituita da 625 linee
e, in base allo standard adottato in Europa (PAL), viene ripetuta per 25 volte in un secondo. Per
motivi storici esistono diversi standard che vengono adottati in tutto il mondo come illustrato nella
cartina geografica a lato.
Standard
PAL
SECAM
NTSC
FPS
25,00
25,00
29,97
linee
625
625
525
freq.
50Hz
50Hz
60Hz
1.4 - Distribuzione degli standard
video nel mondo
Le 625 linee TV non vengono impiegate totalmente per descrivere l'immagine. Infatti oltre alle
informazioni sul contenuto di luminanza e crominanza dell'immagine sono necessarie altre
informazioni per la cui trasmissione si richiede un periodo di pausa pari al tempo di trasmissione di
ben 49 linee. Le linee attive dell'immagine sono quindi 576.
Nel campo della TV digitale si utilizza invece un altra modalità di descrizione dell'immagine,
suddividendola in pixel. Per ogni linea TV si considerano quindi 720 pixel pertanto una intera
immagine TV è formata da 720 x 576 pixel. Ad ogni pixel sono associati i valori di luminosità
dell'immagine, in gergo luminanza Y, e i valori relativi al colore, in gergo crominanza C. Ogni pixel
è quindi costituito da campioni di luminanza e crominanza in numero variabile in funzione del
livello qualitativo che si deve ottenere che viene descritto nella raccomandazione CCIR.601.
1.5 I tipi di spazio colore
Vediamo le caratteristiche dei vari spazi colore, ovvero del modo di registrare le informazioni del
giugno 2006
VIDEO DIGITALE
17
singolo pixel.
1.5.1 RGB
RGB è l'acronimo di Red, Green e blue. E' possibile esprimere ciascun colore come somma dei tre
contributi elementari a partire dai quali si creano tutti gli altri con misture additive. Numerosi
formati di immagini fisse, come BMP, GIF e TIFF, memorizzano ciascun pixel come triade RGB.
Le informazioni di ogni pixel sono date da una coordinata spaziale del tipo (numero, numero,
numero) = (Red, Green, Blu) dove "numero" è un valore da 0 a 255 che è rappresentabile in binario
con 8 bit (il più grande numero decimale rappresentabile con n bit si ottiene con la formula: 2n-1,
ovvero 28-1 = 256-1 = 255). Questo significa che in formato colore RGB servono 24 bit per ogni
pixel ovvero 3 bytes (1 byte = 8 bit). Per la cronaca nero = (0,0,0), bianco = (255,255,255); tutte le
tonalità di grigio sono rappresentate da valori del tipo (x,x,x), ovvero terne dello stesso numero.
Perciò un'immagine 720 x 576 occupa (stesso calcolo fatto in precedenza ma senza contare numero
di frame/s):
720 x 576 x 24 = 9.953.280 bit = 1.19 MB circa
Uno degli sprechi di questo modello rappresentativo è dovuto alle caratteristiche dell'occhio umano.
Questo infatti, non è sensibile in maniera identica a tutti e tre i colori fondamentali ma in maniera
decrescente al verde, al rosso ed infine al blu. Inoltre, la sua capacità di discernere i dettagli spaziali
è accentuata nei verdi al centro dello spettro visibile, e decisamente inferiore nei blu.
In parole un po' più semplici, l'occhio umano è più sensibile alle differenze di luminosità piuttosto
che a quelle di colore; e nella pratica ciò si traduce nel fatto che siamo "più bravi" nel riconoscere la
differenza tra due grigi, piuttosto che la differenza di sfumature cromatiche tra rossi, verdi o azzurri.
18
VIDEO DIGITALE
giugno 2006
Risposta relativa dell'occhio alla soglia dei cambi di
intensità a differenti frequenze angolari
Tutti i punti sopra la curva rappresentano la condizione in cui l'occhio non è capace di rilevare alcun
cambiamento di intensità, i punti al di sotto invece la condizione nella quale l'occhio percepisce le
variazioni. L'intensità luminosa è chiamata luminanza, mentre la somma dei contributi cromatici
delle radiazioni RGB è chiamata crominanza. La luminanza è, per intenderci, la grandezza che da
sola caratterizza ogni punto dell'immagine in bianco e nero. Da quanto detto fino ad ora, si deduce
dunque come sia inutile trasmettere tutti i dati relativi alla crominanza, visto che l'occhio ne vuole
solo una parte. E' per questo motivo che è stato concepito lo standard di rappresentazione YUV.
1.5.2 YUV
Anche in questo caso si tratta di una sigla, nella quale Y è la componente luminanza (la luminosità
del pixel, ciò che nel linguaggio di tutti i giorni viene definito come "chiaro" o "scuro") mentre U e
V sono le componenti di crominanza o componenti differenza: esse definiscono la quantità di
colore. Spesso U viene indicato anche come Cb (componente differenza del blu), mentre V con Cr
(componente differenza del rosso). L'obbiettivo che ci si è prefissati con la definizione dello
standard YUV, è quello di rappresentare un gruppo di pixel con un numero inferiore di bytes
rispetto alla corrispondente rappresentazione RGB. Esistono diversi tipi di YUV:
•
YUV 4:4:4
giugno 2006
VIDEO DIGITALE
19
•
YUV 4:2:2
•
YUV 4:2:0
•
YUV 4:1:1 (utilizzato per la TV americana, NTSC)
tutti riferiti a gruppi di 4 pixel. Per ogni pixel viene memorizzata la luminanza corrispondente,
mentre si risparmiano bit sulle informazioni riguardanti il colore, descrivendo questo per gruppi e
non per singoli pixel.
1.5.3 YUV 4:4:4
In questa rappresentazione non si effettua alcuna approssimazione, perciò non si ha nessun
guadagno. E' per questo motivo che non viene utilizzata nella compressione. In pratica, per
descrivere ciascun pixel si utilizzano 3 byte (24 bit)
Pixel 1
Pixel 2
Pixel 3
Pixel 4
Y
1 byte
1 byte
1 byte
1 byte
U
1 byte
1 byte
1 byte
1 byte
V
1 byte
1 byte
1 byte
1 byte
Perciò un'immagine 720 x 576 occupa:
720 x 576 x 24 = 9.953.280 bit = 1.19 MB
proprio come se fosse rappresentata in RGB. E dunque 1 secondo di filmato occupa ,come già
visto, ben 30 MB, una massa di dati difficilmente gestibile anche su macchine molto potenti, dal
momento che richiederebbe un transfer rate di circa 248 Mbit/s.
1.5.4 YUV 4:2:2
Questa rappresentazione in ambiente Windows Direct Draw è conosciuta col nome YUY2.
In essa vengono eliminate informazioni di colore, utilizzando otto byte per rappresentare un blocco
(quadrato) di quattro pixel. Per ciascun pixel si memorizza per intero la luminanza, come sempre,
20
VIDEO DIGITALE
giugno 2006
mentre per la crominanza si divide il gruppo in coppie, e a ciascuna coppia si assegna un byte per il
colore U e uno per il colore V, facendo la media tra le componenti U e V dei singoli pixel (es. U =
(U1+U2)/2)
Pixel 1
Pixel 2
Pixel 3
Pixel 4
Y
1 byte
1 byte
1 byte
1 byte
U
V
1 byte
1 byte
1 byte
1 byte
Dove
U 1U 2
2
ecc.
V 1V 2 
2
ecc
U 12=
V 12=
Ne segue che ogni pixel è descritto da:
1 + 0,5 + 0,5 = 2 byte = 16 bit
quindi una immagine 720 x 576 occuperà:
 720 x 576 x 16 
= 0,79 MB
 8 x 1024 x 1024 
con un risparmio rispetto a RGB e YUV 4:4:4 del 33%
Questo formato standard viene utilizzato per la digitalizzazione di video PAL, che non trarrebbe
vantaggio dall'utilizzo del 4:4:4, poiché il PAL colore utilizza una banda video dimezzata rispetto al
bianco/nero.
1.5.5 YUV 4:2:0
Questa rappresentazione, in ambito Windows Direct Draw va sotto il nome di YV12, ed è il
formato utilizzato dalla maggior parte dei codec nella prima fase di compressione. In questo caso,
giugno 2006
VIDEO DIGITALE
21
per descrivere un blocco di 4 pixel, si utilizzano 6 byte. Come sempre 4 per la luminosità (uno per
pixel), mentre gli altri due vengono utilizzati uno per ciascun componente di crominanza
U=
U1U2U3U4 
4
Pixel 1
Pixel 2
Pixel 3
Pixel 4
Y
1 byte
1 byte
1 byte
1 byte
U
V
1 byte
1 byte
Pertanto ogni pixel è rappresentato da:
1 + 0,25 + 0,25 = 1,5 byte = 12 bit
e un'immagine 720 x 576 occuperà
720 x 576 x 12 = 4.976.640 bit = 0,593 MB
esattamente la metà di una stessa immagine in RGB o YUV 4:4:4. Risparmio netto del 50%
dunque, e sensibile aumento della velocità di compressione. Utilizzare la modalità YV12 non
presenta alcuno svantaggio soprattutto se si utilizzano codec lossy. Facendo un confronto tra due
immagini codificate in RGB24 e in YV12 non si nota alcuna differenza, nemmeno
all'ingrandimento. In fondo, se ci pensate, un quadrato di quattro pixel in un campo di 720 x 576
occupa solo lo 0,00096% del totale, quindi una porzione infinitesimale.
RGB24
22
YUY2
VIDEO DIGITALE
YV12
giugno 2006
Per contro, ci sono almeno due vantaggi. Uno, già accennato, è l'incremento di velocità, che si
traduce in oltre 3 frames al secondo (varia a seconda dell'hardware), il secondo sta nel fatto che
evitando la doppia conversione con la legge della televisione, si evitano pure i piccoli errori sui
colori che essa genera.
In conclusione, nella compressione video conviene usare lo spazio colore YV12.
1.5.6 Conversione RGB ↔ YUV
Il passaggio dalla modalità RGB a quella YUV si può effettuare attraverso la "Legge Della
Televisione", la cui formula è:
CONVERSIONE
RGB → YUV
Y=
U (Cb) =
V (Cr) =
0.5635(B-Y) + 128 =
0.7133(R-Y) + 128 =
0.2990R + 0.5870G + 0.1140B
-0.1684R - 0.3316G + 0.5B + 128
0.2R - 0.4187G - 0.0813B + 128
Basta una rapida occhiata per capire come esista un legame univoco tra le due rappresentazioni, la
formula è infatti facilmente invertibile. Uno stesso colore può pertanto essere rappresentato
indifferentemente in ciascuno dei due modi. E' sufficiente un byte (8 bit) per descrivere il singolo
fattore (RGB o YUV) e dunque occorrono 3 x 8 = 24 bit per descrivere ciascun pixel col proprio
colore, sia che lo si rappresenti in modalità RGB che YUV.
Dunque per effettuare una trasformazione da RGB a YUV, bisogna applicare la legge della
televisione. Naturalmente ciò va ripetuto per ogni pixel dell'immagine, il ché significa che il
processore deve compiere per ciascun pixel ben sei addizioni, due operazioni di shift (divisione per
2) e due somme per 128. Ciò si traduce, per una immagine di 720 x 576 in un totale di:
10 x 720 x 576 = 4.147.200 operazioni
e, per 1 secondo di filmato:
giugno 2006
VIDEO DIGITALE
23
4.147.200 x 25 = 103.680.000 operazioni
di cui:
62.208.000 addizioni
20.736.000 shift
20.736.000 somme per 128
Nei moderni processori, grazie alle istruzioni MMX ed SSE, questo non comporta un eccessivo
impegno della CPU, tuttavia sottrae numerosi cicli di clock alla compressione, rallentandola.
Ovviamente lo stesso discorso vale per la conversione da YUV a RGB.
24
VIDEO DIGITALE
giugno 2006
2
Contrariamente a quanto verrebbe da pensare, comprimere un video non equivale a comprimere
nello stesso modo ogni singolo fotogramma, trattandolo come se si comprimesse una qualsiasi
immagine digitale, e poi rimetterli in sequenza. I progettisti dei codec MPEG, analizzando le
caratteristiche tipiche di un flusso video, furono in grado di individuare delle "peculiarità" che
potevano essere sfruttate ai fini della compressione. Così, quando si posero la fatidica domanda
"come implementare un algoritmo di compressione video", individuarono diverse possibili vie da
perseguire: ottimizzare il metodo di memorizzazione digitale dei dati relativi al video, sfruttare delle
caratteristiche intrinseche al video stesso dovute alla sua struttura sequenziale, e, studiando
accuratamente il sistema visivo umano, cercarono quelle caratteristiche che era possibile sfruttare ai
fini della compressione stessa. L'elenco seguente riassume a grandi linee gli approcci che furono
individuati ed utilizzati nella progettazione dell'encoder video MPEG-1, approcci che combinati tra
loro avrebbero consentito di sviluppare algoritmi di compressione così efficienti da ridurre ad
esempio di 30 volte2 le dimensioni occupate da un file video senza apparente degrado qualitativo.
A. Tecniche relative al modo di memorizzazione del video stesso, in combinazione con le
caratteristiche del sistema visivo umano. E' possibile comprimere un video riducendo la precisione
con cui vengono memorizzate le informazioni: un esempio tipico di questo tipo di compressione,
nel caso di un flusso video digitale, è il passaggio dallo spazio colore RGB a quello YUV.
B. Tecniche che sfruttano alcune caratteristiche intrinseche al video stesso. E' possibile
comprimere un segnale video rimuovendo la ridondanza (ripetitività) statistica contenuta in un
video e mantenendo solo le nuove informazioni, ovvero quelle effettivamente utili; si cerca cioè una
rappresentazione "meno correlata" delle immagini, correlata nel senso delle similitudini all'interno
dello stesso fotogramma e tra fotogrammi adiacenti, eliminando quindi nel possibile tutte le
ripetizioni. Quindi, dato che è statisticamente provato che pixel adiacenti (e vicini) all'interno di una
2 L'MPEG-2, che è tuttora lo standard di compressione più importante del mondo, e che è stato il successore
dell'MPEG-1, riduce di 30 volte lo spazio richiesto per la memorizzazione di un video non compresso.
giugno 2006
25
stessa immagine presentano caratteristiche molto simili per quel che riguarda il colore e la
luminosità (cosa del resto piuttosto intuitiva: se considero una porzione azzurra di cielo, con buona
probabilità i pixel vicini avranno lo stesso colore), venne ideata la codifica intra-frames che si
occupò per l'appunto di rimuovere questa ripetitività o ridondanza spaziale all'interno dello stesso
fotogramma. Inoltre esiste una netta correlazione non solo tra i pixel dello stesso fotogramma, ma
anche tra i pixel di fotogrammi adiacenti. Infatti, dato che in ogni secondo si susseguono 25
fotogrammi (PAL), è logico aspettarsi che un fotogramma ed i due a lui vicini (il successivo ed il
precedente) spesso risultano pressoché identici (fanno eccezione le situazioni in cui si hanno cambi
di scena); questa correlazione o ridondanza temporale venne trattata con l'implementazione della
codifica inter-frames.
C. Tecniche che sfruttano intensivamente le caratteristiche del sistema visivo umano. Studiando
la percezione che l'occhio e il cervello umano hanno della realtà ed in particolare del movimento, ci
si è resi conto della scarsa sensibilità del sistema visivo umano nei riguardi delle cosiddette alte
frequenze video. Il concetto di frequenza nel video è associato alla "complessità" di una scena. Le
basse frequenze corrispondono ai colori uniformi (un cielo sereno senza nubi, il colore di una
automobile) mentre le alte frequenze corrispondono alle immagini frastagliate tipo le foglie di un
albero visto da lontano, i quadretti minuti di una giacca, o i caratteri della pagina di un giornale. E'
possibile "tagliare", buttar via, alcune delle informazioni sulle alte frequenze di un'immagine senza
per questo portare ad un visibile deterioramento dell'immagine stessa. Per come è strutturato, il
sistema visivo umano non è in grado di percepire le variazioni nei dettagli di figure molto
frastagliate; è molto difficile rendersi conto di una perdita di dettaglio nelle fronde di alcuni alberi
in movimento; è molto più semplice invece notare anche la più piccola variazione di colore o
luminosità nell'azzurro di un cielo limpido e sereno sullo sfondo di un video.
Ci sono due schemi di base di compressione lossy:
•
Nei transform codecs vengono presi dei campioni di immagine o di suono, spezzettati in
piccoli segmenti, trasformati in un nuovo spazio di base e quantizzati. I valori risultanti sono
poi codificati ricorsivamente.
•
Nei predictive codecs i dati precedenti e/o successivi già decodificati sono usati per
prevedere il corrente campione di suono o frame video. L'errore tra il dato previsto e il dato
reale, insieme ad ogni altra informazione extra necessaria per riprodurre la previsione, è poi
quantizzata e codificata.
26
giugno 2006
In alcuni sistemi le due tecniche sono combinate, con i codec di trasformazione che vengono usati
per comprimere i segnali errati generati dallo stadio di previsione.
2.1 Tipi di frames
Anzitutto è necessario pensare ad un video come ad una serie di immagini (fotogrammi) che si
susseguono in rapida sequenza. Quindi quando si comprime un flusso video si stanno
sostanzialmente comprimendo delle immagini, ma non solo: si stanno comprimendo immagini in
sequenza. E' possibile farsi un'idea su come viene trattato un flusso video, osservando la figura
seguente:
Ogni immagine viene scomposta in singoli blocchetti ed ogni blocchetto è trattato singolarmente. Il
singolo fotogramma è formato da gruppi di blocchi ed i fotogrammi sono a loro volta impacchettati
in gruppi di fotogrammi. La codifica intra-frames e quella inter-frames non sono altro che metodi
diversi con cui vengono trattati (compressi) i singoli fotogrammi. In pratica prima della
compressione una sequenza video non compressa è qualcosa del tipo FFFFFFFFFFFFF..., mentre
giugno 2006
27
dopo la compressione conterrà una sequenza di fotogrammi del tipo IPBBBPBBBPIBBBP..., dove
con I ho indicato un intra-frame mentre P e B descrivono due differenti tipi di fotogrammi di tipo
inter-frame. Vediamoli più in dettaglio.
2.1.1 Gli intra-frames
I fotogrammi di tipo I, chiamati anche I-frames o Key-Frames (fotogrammi chiave), sono
fotogrammi che vengono codificati utilizzando le informazioni contenute nel fotogramma stesso e
non contengono nessun riferimento od informazione sui fotogrammi adiacenti. In pratica sono
compressi alla stregua di un'immagine singola, allo stesso modo di quando un'immagine viene
salvata in formato JPEG. Intervengono solo tecniche di rimozione di ridondanza spaziale
(similitudine tra pixel adiacenti), mentre non viene applicato nessun algoritmo di compressione
temporale (ovvero compressione che tiene conto anche dei fotogrammi successivi e/o precedenti).
Sebbene con un'immagine compressa in formato JPEG di buona qualità si possa ottenere un
rapporto di compressione anche di 20:1, siamo ancora lontani dal valore del rapporto di
compressione cercato per il video; prima si parlava di qualcosa tipo 30:1 per un video MPEG-2,
mentre per un video in MPEG-4, il rapporto può scendere anche a valori di 50-60:1. Gli I-Frames
sono inseriti generalmente dall'encoder video ogni qualvolta vi sia un cosiddetto cambio di scena,
ovvero in tutti quei casi nei quali manchi una corrispondenza temporale tra fotogrammi adiacenti.
Quando ad esempio un fotogramma è completamente diverso dal precedente, l'encoder
probabilmente codificherà tale immagine come fotogramma di tipo I o chiave. Se inoltre viene
specificato un intervallo massimo tra un fotogramma chiave ed il successivo il codec dovrà
necessariamente inserire un fotogramma chiave anche se non strettamente necessario. Questo risulta
utile in quanto quando ci si sposta all'interno di un file video mentre lo si sta guardando, alla ricerca
di una particolare scena, è possibile solo spostarsi tra un fotogramma chiave ed il successivo.
Fotogrammi chiave troppo distanziati renderebbero la ricerca piuttosto complicata ed è per questo
che in genere si utilizza un valore massimo per la distanza tra un key-frame ed il successivo
corrispondente a circa 10-12 secondi di video (250, 300 fotogrammi nel caso del sistema PAL).
2.1.2 I Delta-Frames od Inter-Frames
Chiamati anche P-frames: si usa una codifica di tipo P (Predicted frames) per quei fotogrammi
che vengono codificati utilizzando informazioni acquisite dal fotogramma precedente, sia questo di
tipo I o di tipo P. Ogni blocco di 16 x 16 pixel in cui viene suddiviso il singolo fotogramma, con la
28
giugno 2006
codifica di tipo P può essere compresso in modo indipendente (come nel caso dell'I-Frame) oppure
può essere compensato e bilanciato utilizzando informazioni del fotogramma precedente.
Utilizzando le somiglianze tra fotogrammi successivi i fotogrammi P risultano essere più piccoli dei
corrispondenti I-Frames. Spesso in una sequenza video, un gruppo o serie di fotogrammi risultano
tra loro molto simili. Considerate ad esempio il caso limite del conduttore di un telegiornale che
parla seduto alla scrivania. Per la gran parte del tempo, lo sfondo rimarrà praticamente invariato.
Prendendo in considerazione che
per ogni secondo di video si susseguono 25 fotogrammi,
risulterebbe molto più utile poter memorizzare non i singoli fotogrammi in modo indipendente,
quanto piuttosto memorizzare e quindi successivamente comprimere esclusivamente le minime
differenze tra di loro. A questo scopo vengono utilizzati i fotogrammi di tipo P, che consentono di
eliminare le informazioni ridondanti e ripetitive: un fotogramma di tipo P contiene le informazioni
della posizione (X',Y') nel fotogramma corrente in cui si è spostato un blocco che aveva coordinate
(X,Y) in quello precedente (Motion Estimation / Compensation). Ripeto, in tal modo, al posto di
mantenere l'informazione spaziale (tipo JPEG) del singolo fotogramma, vengono memorizzate le
sole informazioni sulla variazione di posizione (ad ogni blocco viene associato il suo vettore di
moto che consente di ricostruire l'immagine originale), informazioni che a conti fatti richiedono
molti meno bit rispetto alla memorizzazione dell'immagine completa. Lo svantaggio dell'utilizzo di
questo tipo di fotogrammi si ha in fase di decodifica; è infatti necessario "ricostruire" ciascun
fotogramma P prima di poterlo visualizzare, e per far questo si deve sempre partire dal fotogramma
P seguente all'ultimo fotogramma chiave; ovvero per visualizzare ad esempio il quarto fotogramma
P di una sequenza tipo IPPPPPPP è necessario comunque ricostruire anche i 3 fotogrammi P
precedenti.
Un discorso piuttosto approfondito meritano l'altro tipo di inter-frames, ovvero i fotogrammi di tipo
B (bi-directional) che introducono la codifica bi-direzionale.
2.1.3 B-frames / Bi-directional encoding:
Per i fotogrammi di tipo B la ricerca del moto (Motion Estimation / Compensation) è effettuata non
solo sul fotogramma precedente (come nel caso di P-Frames) ma anche sul fotogramma successivo.
La codifica ed anche la decodifica risultano quindi decisamente più complesse. Sostanzialmente i
fotogrammi B sono di tipo "bi-direzionale", nel senso che fanno riferimento sia a ciò che li precede,
sia a quello che segue. Inserire in un fotogramma informazioni che si riferiscono ad un fotogramma
successivo è possibile solo alterando l'ordine in cui i fotogrammi vengono archiviati all'interno del
giugno 2006
29
file video compresso. Questo è effettivamente quello che fa l'encoder (e di cui tiene conto il decoder
in fase di decodifica). Facciamo un esempio. Supponiamo di avere 4 fotogrammi da comprimere. Il
primo di questi sarà necessariamente un fotogramma chiave (I-Frame), mentre vogliamo che i
successivi due siano B-Frames (che generalmente hanno una dimensione di 1/4 del P-Frame
corrispondente); l'ultimo deve essere necessariamente un P-frame, in quanto i fotogrammi B
necessitano dopo di loro di qualcosa da cui essere derivati. In sequenza avremmo:
n° fotogramma
tipo di fotogramma:
1
I
2
B
3
B
4
P
tuttavia i fotogrammi verranno archiviati all'interno del filmato in questo modo:
n° fotogramma
tipo di fotogramma:
1
I
4
P
2
B
3
B
Dopo aver codificato l'I-Frame, l'encoder salta avanti di due fotogrammi e codifica quello che è
destinato ad essere il fotogramma P (ovvero il quarto) e lo codifica come se seguisse
immediatamente l'I-frame:
n° fotogramma
tipo di fotogramma:
1
I
4
P
Questo processo genererà un P-frame di dimensioni superiori a quello che si avrebbe codificando
come P-frame il 2° fotogramma, in quanto generalmente vi saranno più cambiamenti (ovvero
differenze) tra il 1° fotogramma ed il 4° che non tra il 1° ed il 2°. Tuttavia, l'utilizzo dei due Bframe porterà complessivamente ad una riduzione del numero di informazioni (dimensioni)
necessarie alla codifica (come ho già detto un B-frame occupa 1/4 delle dimensioni di un P-frame).
Ora abbiamo un fotogramma I ed uno P compressi. Fatto questo, l'encoder ritorna al 2° fotogramma
(che è destinato ad essere il nostro primo B-Frame) e facendo riferimento sia al fotogramma I che a
quello P per la stima e ricerca del movimento, analizza le eventuali somiglianze e procede alla
codifica del B-Frame:
n° fotogramma
tipo di fotogramma:
1
I
4
P
2
B
L'encoder prende quindi il 3° fotogramma e confrontandolo sempre con l'I-frame ed il P-frame
30
giugno 2006
iniziale genera il secondo B-frame:
n° fotogramma
tipo di fotogramma:
1
I
4
P
2
B
3
B
I B-frame non possono comunque mai fare riferimento uno all'altro, ovvero è sempre necessario
avere un I-frame e un P-frame tra più B-frames consecutivi. Questa procedura porta a complicare
ulteriormente la fase di decodifica in quanto ora non solo è necessario rigenerare i fotogrammi in
base alle informazioni codificate, ma i fotogrammi stessi risultano non essere più archiviati con il
corretto ordine.
Sintesi
L'utilizzo di queste tecniche permette di ridurre la quantità di bit necessari per la codifica
dell'informazione trasmettendo (codificando) le differenze tra fotogrammi, piuttosto che
archiviando i fotogrammi stessi. Alla luce di quanto appena detto, credo sia doveroso anticipare
quello che dovrebbe essere uno dei principali fattori da tenere in considerazione quando ci si
accinge a comprimere un video. Sequenze video con scene in rapido movimento o con un'elevata
dinamica sono molto più impegnative da codificare e richiedono un numero di bit (bitrate) più
elevato: essendo maggiori le differenze tra i fotogrammi adiacenti, maggiori sono le informazioni
che
devono
essere
memorizzate
e
conservate.
Al contrario, scene statiche con movimenti lenti o pochi cambi di scena, presentano minime
differenze tra fotogrammi adiacenti, minime differenze che si traducono con un numero
decisamente inferiore di informazioni da mantenere e trasmettere ovvero con un basso bitrate.
2.2 Conversione dello spazio di colore
Spesso quando si comprime un file video viene applicata anche una trasformazione del suo spazio
colore, ovvero come abbiamo visto, il modo in cui vengono memorizzate le informazioni del video
stesso. E' prassi trasformare un filmato RGB24 o RGB32 in YV12 prima della compressione vera e
propria poichè nel formato YV12 c'è un notevole guadagno di spazio senza compromettere
sensibilmente la qualità. Si ha comunque una prima perdita totale di informazioni, in quanto si
passa da 24 o 32 bit per pixel (bpp) del formato RGB ai soli 12 bpp del formato YV12; si ha in
pratica un dimezzamento delle dimensioni del video, con perdita irreversibile di informazioni ma
giugno 2006
31
degrado qualitativo praticamente nullo (non percettibile), data la ridotta sensibilità alle variazioni di
colore del sistema visivo umano.
2.3 Blocking
L'immagine originale viene suddivisa in macro-blocchi di 16 x 16 pixel; di qui la necessità che il
video da comprimere sia un multiplo di 16 nelle dimensioni verticali ed orizzontali (altezza e
larghezza). Alcuni codec consentono di comprimere flussi video con risoluzioni anche multiple di 8
, di 4 e probabilmente di 2, tuttavia in queste situazioni la suddivisione in macro-blocchi non è
ottimizzata, e potrebbero richiedere un bitrate più elevato od addirittura presentare degli artefatti
video durante la decompressione, a causa di una Motion Estimation effettuata su macro-blocchi non
standard.
Immagine originale
blocking
Nello spazio di colore YV12 all’interno di ciascun macro-blocco 16 x 16, si possono distinguere 4
blocchi di 8 x 8 pixel per quel che riguarda la luminosità ed 1 solo blocco di 8 x 8 valori (ogni
valore rappresenta 4 pixel) per ogni componente del colore Cb e Cr (dato che la risoluzione per il
colore viene dimezzata), per un totale 6 blocchi di 8 x 8 pixel. L'encoder a questo punto decide
quali fotogrammi devono essere trattati come I-Frames e quali invece saranno trattati come P o Bframes. Sugli I-Frames viene direttamente applicata la DCT (vengono compressi come vere e
proprie immagini in formato JPEG), mentre sugli altri fotogrammi vengono effettuate delle
procedure di modellizzazione del moto.
32
giugno 2006
Y, Luminanza:
risoluzione invariata, 16x16
pixels, ovvero 4 blocchi di 8x8
Cr, Crominanza Rosso:
Ingrandimento di uno dei
macroblocchi 16x16 in cui è stata
suddivisa l'immagine e simulazione
(nel senso che le componenti Cb e Cr
non corrispondono alla realtà) della
decomposizione del macroblocco
selezionato nelle componenti dello
spazio di colore YV12
risoluzione dimezzata, il
macroblocco 16x16 è
approssimato con un blocco di
8x8 pixel
Cb, Crominanza Blu:
risoluzione dimezzata, il
macroblocco 16x16 è
approssimato con un blocco di
8x8 pixel
2.4 Modellizzazione del moto
La procedura è piuttosto complessa ed è difficile sintetizzare il tutto in poche righe. Tenterò di
illustrare solo i concetti di base in modo tale da farsi per lo meno un'idea generale. Ripeto: le cose
in realtà non sono così semplici ma un'analisi dettagliata di come funziona una compressione video
non è l'oggetto di questa tesi. In questa fase viene sfruttata la ridondanza temporale dei fotogrammi
del video e vengono quindi costruiti i P-frames ed i B-frames. Come? Con due procedure:
2.4.1 Motion Estimation (ME)
per ciascun macro-blocco 16 x 16 o blocco 8 x 8 (a seconda della precisione sulla ricerca del moto,
la ricerca viene effettuata sui macro-blocchi 16 x 16 o sui blocchi 8 x 8; di seguito utilizzerò sempre
il termine blocco, restando sottinteso che potrebbe anche trattarsi di un macro-blocco) viene
giugno 2006
33
effettuata una stima del movimento. In pratica l'encoder tenta di individuare tra i fotogrammi
adiacenti (nel solo fotogramma precedente per i P-Frames, nel precedente e nel successivo per i BFrames) il blocco più simile (se non uguale). Dopodiché viene associato al blocco su cui è stata
effettuata l'analisi un vettore di moto, cioè una coppia di numeri tipo (x,y) = (-1,4) che individuano
sul piano ipotetico rappresentato dal fotogramma, il vettore di spostamento, sostanzialmente una
freccia che mi indica direzione, verso e entità dello spostamento del blocco passando dal
fotogramma 1 al fotogramma 2. Tale vettore deve essere necessariamente associato ad ogni blocco
su cui viene effettuata la ME, e viene utilizzato in fase di decodifica per ricostruire l'immagine
originale. Si noti inoltre che la ricerca per il blocco di riferimento viene generalmente effettuata in
un intorno limitato del blocco di partenza (area in grigio nella figura in basso) in quanto se la ricerca
fosse effettuata su tutto il fotogramma, i tempi per la codifica potrebbero allungarsi in modo non
accettabile; l'efficenza del metodo è assicurata dal principio della ridondanza spaziale: la
probabilità di trovare un blocco simile man mano che ci si allontana dal blocco di partenza,
diminuisce in modo esponenziale con l'aumentare della distanza.
2.4.2 Motion Compensation (MC)
viene creato il blocco differenza, in pratica viene sostituito il blocco originale su cui è stata
effettuata la ricerca, con il risultato che si ottiene sottraendo dal blocco molto simile trovato nel
fotogramma 1 (reference frame) il blocco in questione nel fotogramma 2. Se tutto ha funzionato a
dovere, ovvero l'encoder non ha commesso errori nella ricerca del blocco di riferimento (nel
fotogramma 1), si ottiene un netto vantaggio consistente nel fatto che il nuovo blocco "differenza"
sarà costituito da un numero decisamente inferiore di dati (nella matrice del blocco saranno presenti
molti zeri (colore nero). Le uniche informazioni aggiuntive da considerare saranno quelle relative al
vettore di moto (una coppia di numeri).
34
giugno 2006
Esempio
Osservate le seguenti immagini: si tratta di una sequenza video di un'auto che si sposta da sinistra a
destra. A sinistra abbiamo il fotogramma A, a destra il fotogramma successivo B:
Fotogramma A
Fotogramma B (successivo)
Il fotogramma seguente mostra la differenza tra le due immagini, differenza calcolata pixel a pixel
senza l'utilizzo di nessuna tecnica di compensazione del moto; è in bianco e nero, in quanto si tratta
della differenza sulla sola componente della luminanza (Y).
giugno 2006
35
L'immagine differenza tra i due fotogrammi A e B, senza Motion Compensation
Osservate ora le due immagini seguenti: l'immagine di sinistra mostra il fotogramma A con tracciati
i vettori di moto; ogni vettore (linea) è centrato sul relativo macro-blocco, ed indica la direzione in
cui si sposterà tale macro-blocco nel fotogramma B successivo. La direzione del vettore è stata
precedentemente calcolata mediante il procedimento di motion estimation. L'immagine di destra è il
risultato della differenza tra i due fotogrammi A e B, utilizzando, al posto del fotogramma A, il
fotogramma A su cui è stata effettuata la stima di moto. Quello che è importante osservare è che
l'immagine di destra contiene un numero di dettagli (informazioni) notevolmente inferiore rispetto
all'immagine qui sopra mostrata (ottenuta dalla differenza senza ME) e richiede quindi un numero
inferiore di bit per essere codificata.
Fotogramma A con tracciati i vettori di moto
36
L'immagine differenza tra i due fotogrammi A e B, con
Motion Compensation
giugno 2006
2.5 DCT, Discrete Cosine Transform
Torniamo ai macro-blocchi di 16 x 16 pixel, che, per la conversione nel formato colore YUV 4:2:0
(YV12), corrispondono a 6 blocchi di 8 x 8 pixel, numeri o coefficienti che dir si voglia (4 per la
luminosità e 2 per il colore). Ognuno di questi blocchi 8 x 8 può essere descritto da una matrice di 8
x 8 valori numerici, ovvero un quadrato di 64 numeri da 0 a 255, che, a seconda del blocco in
questione, descrivono luminosità (Y) di ciascun pixel o colore (Cb e Cr) di ciascun gruppo di 4 (2 x
2) pixel. Generalmente queste singole matrici risultano composte tutte da valori non nulli (a meno
che non si tratti di immagini totalmente nere). Una funzione matematica, la DCT (Discrete Cosine
Transform), viene applicata alle singole matrici 8x8; questa funzione trasforma le matrici dei valori
Y, Cb e Cr, nelle matrici 8x8 contenenti i valori delle frequenze video. Ovvero si ottengono nuovi
quadrati 8 x 8 sempre di 64 numeri, con la differenza che ora i singoli coefficienti non
rappresentano più, ad esempio, la luminosità dei 64 pixel del nostro blocchetto, ma la distribuzione
delle frequenze video. Ogni coefficiente rappresenta una determinata frequenza video: le basse
frequenze (colori uniformi) sono rappresentate dai coefficienti in alto a sx della matrice, le alte
frequenze (colori frastagliati) nell'angolo in basso a dx. Generalmente, ad una risoluzione di 8 x 8
pixel, si ha una certa uniformità nella distribuzione del colore, ovvero pixel adiacenti risultano
piuttosto simili se non addirittura uguali. Per questo motivo, nella grande maggioranza dei casi la
matrice dei coefficienti DCT avrà valori significativi (diversi da 0) concentrati nell'angolo in alto a
sinistra, ovvero nel campo delle basse frequenza. In particolare il valore in posizione (1,1) (il primo
coefficiente in alto a sinistra) descrive il valore medio di tutto il blocco 8 x 8 ed è il coefficiente più
importante. L'operazione è del tutto reversibile; nessuna informazioni fin qui viene persa e dalla
matrice 8 x 8 DCT è comunque possibile ritornare alla matrice originale 8 x 8 tramite l'operazione
inversa iDCT (inverse DCT).
Uno dei blocchi 8x8
dell'immagine
originale
giugno 2006
Rappresentazione grafica della matrice
contenente i valori originali del blocchetto
8x8: i valori, nella maggior parte dei casi,
sono piuttosto simili a causa della
uniformità spaziale delle distribuzioni di
colore delle immagini di 8x8 pixels
Rappresentazione grafica della matrice
dei coefficienti DCT: solo pochi
coefficienti presentano valori
significativi. L'energia è stata
concentrata soprattuto nel campo
delle basse frequenze.
37
2.6 Quantizzazione
Fino a questo punto tutte le operazioni effettuate dall'encoder sono perfettamente reversibili;
nessuna informazione è stata persa ed è possibile ritornare ai fotogrammi originali effettuando le
operazioni nella direzione inversa. Per ottenere un ulteriore risparmio di bit, a questo punto non
rimane che scartare alcune informazioni “poco significative”, poco importanti. Per quanto detto in
precedenza, data la relativa insensibilità del nostro occhio alle alte frequenze video, potremmo
scartare alcune delle informazioni relative alle alte frequenze senza per questo percepire un qualche
degrado qualitativo. A tal fine, ogni coefficiente della matrice 8 x 8 DCT viene diviso per un
numero intero (divisore) ed il resto della divisione viene scartato. Ovvero tutti i coefficienti più
piccoli del divisore vengono approssimati a 0 e vengono scartati (perdita di informazioni). I 64
divisori con cui dividere ognuno dei 64 coefficienti della matrice 8 x 8 DCT si trovano nella matrice
di quantizzazione (che è appunto una matrice di 8 x 8 = 64 numeri interi), matrice che è possibile
scegliere in fase di codifica. Vengono utilizzate due differenti matrici di quantizzazione: una per gli
Intra-Frames (I-Frames) ed una per gli Inter o Delta-Frames (P e B-Frames). Quello che avviene
durante la fase di quantizzazione può essere intuito osservando le seguenti immagini (i pallini nelle
singole celle rappresentano i coefficienti e, maggiore il diametro del pallino, maggiore è il
coefficiente in valore assoluto; lo zero è rappresentato da una cella vuota. Si noti che i coefficienti
DCT possono assumere anche valori negativi):
Matrice dei coefficienti DCT(x,y)
38
Matrice di quantizzazione Q,
Intra o Inter-Frames
(Coefficienti Q(x,y))
Matrice dei coefficienti DCT(x,y)
quantizzati
giugno 2006
Il netto vantaggio è ora quello di avere
una matrice DCT con un elevato numero
di coefficienti nulli; in molti casi restano
da 1 a 3 coefficienti diversi da zero,
raggruppati nell'angolo superiore sinistro
della matrice.
Si noti come i coefficienti di quantizzazione per le alte frequenze (in basso a destra) siano
nettamente superiori rispetto a quelli per le basse frequenze: il coefficiente DCT in alto a sinistra
(quello più importante, che descrive il valore medio dell'intero blocco) dovrà essere approssimato
(quantizzato) di meno, ed infatti risulta avere il minor coefficiente di quantizzazione. Durante la
fase di decodifica, il decoder moltiplicherà ogni coefficiente DCT quantizzato per il rispettivo
valore della matrice di quantizzazione, e ricostruirà la relativa matrice dei coefficienti DCT, che
ovviamente non potrà essere equivalente all'originale, ma ne sarà una sua approssimazione; tuttavia,
sebbene molti dei 64 coefficienti della matrice DCT originale siano stati "persi", se la compressione
(quantizzazione) non è stata troppo elevata (ovvero coefficienti della matrice di quantizzazione
troppo elevati) difficilmente si è in grado di notare la differenza tra l'immagine originale (non
compressa) e quella (de)compressa, questo poiché le informazioni (quelle più importanti)
dell'immagine originale sono state in gran parte concentrate in alcuni dei coefficienti DCT (quelli
delle basse frequenze). Qui sotto è illustrato il procedimento che avviene in fase di decodifica; come
si può notare la matrice dei coefficienti DCT non risulta uguale a quella di partenza:
Matrice dei coefficienti
DCT(x,y)Quantizzati
giugno 2006
Durante la decodifica, moltiplicando la
matrice quantizzata dei coefficienti DCT per
la matrice di quantizzazione Q utilizzata
dall'encoder, si ottiene una
approssimazione della matrice dei
coefficienti DCT originale di partenza. Tale
matrice DCT "ricostruita" viene quindi
utilizzata dal decoder per ricostruire
l'immagine originale, tramite la trasformata
inversa del coseno (iDCT).
Matrice dei coefficienti
DCT(x,y) "ricostruita"
39
2.7 Zig-Zag Scanning
I coefficienti delle matrici DCT quantizzate vengono memorizzati e salvati in array (sono delle
matrici lineari) con dei metodi detti Scansione a Zig-Zag (ma solo se il video è deinterlacciato,
altrimenti il procedimento di scansione è diverso). Per le caratteristiche delle matrici DCT (tutti i
coefficienti non nulli risultano per lo più concentrati nell’angolo in altro a sinistra nella matrice), i
numeri diversi dallo 0 tendono ad essere raggruppati tutti assieme. Il risultato: una lunga sequenza
di zeri, intervallata da alcuni coefficienti non nulli:
2.8 Run-Level encoding (RLE) e Variable-Lenght
coding (VLC)
Il procedimento fin qui descritto è servito per trasformare i dati in una forma trattabile da una serie
di algoritmi matematici descritti generalmente come Entropy Encoding che, sfruttando la
distribuzione casuale dei dati, tentano di rimuovere una certa ridondanza statistica naturalmente
presente, ad esempio memorizzando i valori più comuni con dei codici brevi, mentre quelli meno
comuni con dei codici più complessi. Tra le tecniche di questo tipo rientrano:
•
codifica Run-Lenght: utilizzata quando i dati presentano ripetizioni consecutive di alcuni
simboli
•
codifica di Huffman: rappresenta simboli a probabilità di occorrenza decrescente mediante
una codifica a lunghezza crescente
•
40
codifica DPCM (Difference Pulse Code Modulation): rappresenta i simboli originali come
giugno 2006
differenza tra il simbolo corrente ed una predizione dei simboli precedenti
•
codifica LZW: utilizza una tabella per rappresentare sequenze ricorrenti di simboli
•
codifica aritmetica: rappresenta gruppi di simboli, in base alla probabilità di ricorrenza
degli stessi, mediante una rappresentazione in virgola mobile.
Vediamo qui di seguito un esempio di applicazione della prima di queste tecniche (Run-Lenght).
Al termine della procedura di scansione a Zig-Zag, ci troviamo in presenza di una sequenza di
numeri del tipo:
Sequenza originale:
90, 5, 10, 2, 10, 1, 0, 0, -2, -4, 3, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 1, -2, ...
Utilizzando la Run-Level encoding, sequenze consecutive di simboli identici vengono combinati
assieme e vengono rappresentati da un singolo simbolo o codice. Ad esempio è possibile
rappresentare la serie di numeri qui sopra rappresentata come una coppia di coefficienti (run, level)
dove run = numero di zeri precedenti al valore level, con level corrispondente ad ogni valore diverso
da zero che è presente nella nostra sequenza; utilizzando l'esempio di sopra, applicando una codifica
Run-Level come quella descritta (in cui tutte le sequenze di 0 consecutive sono rappresentate con il
numero degli zeri che precedono il coefficiente non nullo), si otterrebbe la sequenza seguente:
Sequenza Run-Level:
(0, 90)(0, 5)(0, 10)(0, 2)(0, 10)(0, 1)(2, -2)(0, -4)(0, 3)(4, 3)(5, 1)(0, -2) ...
A questo punto è possibile applicare tecniche di compressione Entropy Encoding o VariableLenght Coding, dove le sequenze od i gruppi di dati che si presentano più frequentemente vengono
rappresentati con un codice breve, mentre vengono assegnati codici più lunghi a quelle sequenze
che si presentano piuttosto di rado. La conseguenza di questa nuova rappresentazione dei dati è che
mediamente occorrono un numero inferiore di bit per la memorizzazione dello stesso simbolo
rispetto a quando i dati si presentavano nella forma di partenza. Esempi tipici di algoritmi che
vengono applicati nella codifica a codice a lunghezza variabile, sono il cosiddetto albero di
Huffman (che porta ad un rapporto di compressione tipicamente 1.5:1), le codifiche aritmetiche e le
giugno 2006
41
codifiche sostituzionali come ad esempio l'algoritmo LZW usato nella compressione delle immagini
GIF e che in una forma modificata, combinata con la codifica di Huffman, è presente nei famosi
formati di compressione lossless gzip, pkzip e png.
SINTESI
Lo schema riassuntivo di una compressione video può essere il seguente:
Il risultato della codifica video è un flusso di dati binari denominato Elementary Stream (ES):
esso contiene tutta l'informazione necessaria a decodificare un segnale video. La figura seguente è
una rappresentazione schematica dell'organizzazione dei dati presenti nello stream e può essere
utilizzata per ricapitolare brevemente gli algoritmi e le funzioni precedentemente descritti.
42
giugno 2006
A livello superiore troviamo la Sequence. L'intestazione (Sequence header) contiene le
informazioni di base, necessarie per iniziare la decodifica, quali le dimensioni delle picture, il
formato dell'immagine (aspect ratio), la frequenza di quadro, le tabelle di quantizzazione.
L'intestazione, data la sua importanza, è ripetuta periodicamente (ad esempio due volte al secondo).
Raggruppati nella sequenza vi sono i Group Of Pictures. L'intestazione (GOP header) contiene le
informazioni necessarie per la riproduzione temporalmente corretta del video (time code) e alcuni
flag utilizzati nell'editing. Le picture costituiscono ciascun GOP. L'intestazione (picture header)
contiene un riferimento temporale e l'indicazione del tipo di picture (I,P,B). La picture è costituita
da slice. L'intestazione (slice header) è identificata, come le altre intestazioni, da un codice (start
code) che non può essere duplicato all'interno del flusso. E' l'entità minima, all'interno del flusso
elementare video, grazie alla quale è possibile ottenere la sincronizzazione e quindi la corretta
decodifica. In genere una slice corrisponde ad un insieme di macro-blocchi pari a 16 righe video,
ma in applicazioni in cui occorra una veloce e sicura sincronizzazione, è possibile avere più slice, al
limite una slice in corrispondenza di ciascun macroblocco. L'intestazione del macro-blocco
(macroblock header) contiene tutta l'informazione necessaria a decodificare correttamente la
porzione di immagine, ovvero i 64 elementi di immagine che lo costituiscono: l'indirizzo spaziale
all'interno dell'immagine, i vettori movimento, i modi di predizione e di trasformazione
(field/frame), il fattore di quantizzazione. Seguono i coefficienti DCT codificati VLC (run+level) e
le parole EOB (End Of Block) separano i quattro blocchi (block) di luminanza e i due di
crominanza.
OSSERVAZIONI
Le tecniche descritte in questo capitolo sono quelle di base della compressione MPEG-2 ma
valgono per qualsiasi codificatore. Ogni codec utilizza metodi diversi e approcci diversi, utilizzando
anche tecniche non descritte in queste pagine. Un'analisi dettagliata del funzionamento di ogni
codec testato sarebbe impossibile per almeno 2 buoni motivi: il primo è la complessità del
funzionamento di ciascuno di essi e il fatto che un lavoro del genere andrebbe oltre gli scopi di
questo documento; il secondo è che molti codec sono closed-source (come Real Media e Windows
Media Video) e quindi il loro funzionamento è coperto da segreto industriale. Nel capitolo 3 sarà
analizzato il funzionamento di H.264 che è lo standard open di maggiore interesse in quanto è
quello adottato attualmente da molti sistemi e che rappresenta il presente e il futuro prossimo della
codifica digitale.
giugno 2006
43
2.9 Bit-rate
il bitrate (o bit-rate) è il metro di misura della velocità di un flusso video (lo dice la parola stessa,
bit-rate = velocità dei bit), ovvero la quantità di bit che vengono trasmessi in ogni secondo. L'unità
di misura del bitrate sono i bit al secondo (bps), o generalmente i kilobit per secondo (kbps) e tutti i
loro multipli (megabit, gigabit, ecc...). Per codificare una singola immagine o fotogramma sono
necessari un determinato numero di bit, e poiché nel caso di un flusso video si ha un determinato
numero di fotogrammi ogni secondo, ecco che si passa dai bit (o Kilobit) al bitrate. L'immagine
seguente aiuta a chiarire il concetto (si ricorda ancora che 25 frame/s vale per il sistema PAL):
Ovviamente, più alto il bitrate, mantenendo costante il numero di fotogrammi che scorrono ogni
secondo, più alta è la quantità di bit riservata ad ogni fotogramma. Più elevato è il numero di bit
disponibili per ogni singolo fotogramma, maggiore sarà il numero di informazioni che possono
essere memorizzate e maggiore sarà quindi la qualità del singolo fotogramma.
2.10 CBR e VBR
Esistono fondamentalmente due metodi di codifica: la CBR (Constant Bit Rate, codifica a bit rate
costante) e la VBR (Variable Bit Rate, codifica a bit rate variabile).
La codifica CBR è il metodo meno ottimizzato: si fissa un bitrate e si comprime tutto il video
utilizzando tale flusso costante. La scarsa ottimizzazione deriva dal fatto che fissato un bitrate,
44
giugno 2006
diciamo così, medio (per avere una idea 4000 Kbit/s per un video progressivo 720x576) nelle scene
statiche tale bit rate è eccessivo (in certi casi bastano anche 2500-3000 Kbit/s), mentre nelle scene
particolarmente dinamiche in cui per avere una buona qualità occorrono spesso anche più di 60007000 Kbit/s) si ottengono immagini piene di artefatti. L'alternativa sarebbe quella di mantenere
fisso un bit rate ad esempio di 8000 Kbit/s garantendo sempre ottima qualità: lo svantaggio è la
elevata occupazione di spazio.
Il discorso è ben diverso se si utilizza il metodo VBR: in tal caso l'encoder utilizza un maggior bit
rate nelle scene più dinamiche e al contrario minore bit rate nelle scene statiche, ottimizzando lo
spazio occupato. La scelta del tipo di bit-rate è spesso lasciata all'utente, che può anche definire i
valori di "picco" entro i quali può oscillare il bitrate, per meglio controllare le dimensioni finali del
file. Valori per una codifica di buona qualità possono essere quelli riportati nella seguente tabella:
Risoluzione
720*576
480*576
352*576
352*288
Bit rate di picco
(Kbps)
6500
4500
3600
2400
Bit rate medio
(Kbps)
4000-5000
2800-3600
2400-2600
1600-1750
Per certe applicazioni è conveniente utilizzare una codifica a qualità costante, per altre a bit-rate
variabile: la codifica VBR è spesso adottata per il video memorizzato, ad esempio su supporto
ottico (DVD). In altri casi invece è vincolata la velocità, ad esempio perché l'informazione deve
essere trasferita su un canale a bitrate costante (streaming).
2.11 1-pass e n-pass
Ovvero il numero di "passate" a cui è sottoposto un video per la compressione. Nella compressione
a 1-pass viene analizzato il video originale e contemporaneamente si crea l'output del video
compresso. Nella modalità a più passate (in genere 2) il primo passaggio serve per analizzare il
filmato e creare un file di log con delle statistiche che verrà usato nelle passate successive per creare
un video compresso ottimizzato.
giugno 2006
45
2.11.1 Modalità 1-pass
La modalità a 1-pass si può fare genericamente in 3 modi diversi:
1-Pass – CBR
Modalità ad un passaggio a bitrate costante: in questo caso ad ogni fotogramma viene assegnato lo
stesso numero di bit, indipendentemente dalla sua complessità. In realtà è più un metodo a bitrate
medio, in quanto il valore costante, più che essere rispettato sul singolo fotogramma, si tenta di
rispettarlo in un determinato intervallo di fotogrammi (mediamente ai fotogrammi viene assegnato
il bitrate selezionato). La quantità di bit, per la precisione di Kbps assegnati a ciascun fotogramma è
selezionabile dall'utente.
1-Pass – quality:
Modalità ad un passaggio cosiddetta a "qualità costante": il codec tenta di comprimere ogni
fotogramma con la stessa qualità, indifferentemente dalla complessità o meno del fotogramma
stesso. La differenza con la modalità "1-Pass - quantizer" dove il quantizer è fisso per ogni
fotogramma e dove può assumere solo valori interi (es. 2, 3, 4...) , viene qui utilizzato un "quantizer
medio costante" ovvero mediamente il quantizer rimane costate e può assumere anche valori non
interi come ad es. 2,5, valori ottenuto facendo variare il quantizer tra 2 e 3 in fotogrammi
successivi: il primo fotogramma viene ad esempio codificato con quantizer 2, il secondo con
quantizer 3, il terzo con quantizer 2, il quarto con quantizer 3 e così via, in modo tale che
mediamente il quantizer assume il valore 2,5.
1-Pass – quantizer
Un altro metodo di compressione a "qualità costante": la differenza con modalità 1 Pass - quality è
che ora ad ogni fotogramma viene assegnato lo stesso quantizer, ovvero viene compresso ogni
fotogramma allo stesso identico modo (ricordo che il quantizer indica il livello di dettaglio che
viene rimosso), mentre nel metodo sopracitato (1-Pass - quality), i quantizer non erano fissi ma
piuttosto modulati, variati, a seconda del comportamento di altri parametri del codec onde garantire
complessivamente un effetto "qualità costante". Con questo metodo invece i quantizer vengono
bloccati ed in un certo senso può essere considerato effettivamente il vero metodo a qualità
costante; i valori possono variare da 1 a n, ma non si consiglia mai di usare il valore 1 (la cui
46
giugno 2006
differenza con il valore 2 è minima e non giustifica l'aumento notevole di dimensioni nel file
finale). Nel caso del codec x.264 per esempio il range consigliato è da 15 a 40 su una scala da 0 a
51.
2.11.2 Modalità a 2-pass
La modalità di compressione in due passaggi richiede circa il doppio del tempo rispetto alle
modalità ad una singola passata viste in precedenza, tuttavia è anche l'unico metodo di
compressione che consente di impostare a priori la dimensione esatta del file video (con un margine
di errore minimo) ed è anche quella che, a parità di bitrate, fornirà la qualità video migliore.
Sebbene sia possibile prevedere anche con il metodo "1 Pass - CBR" la dimensione finale del nostro
file (è sufficiente effettuare qualche piccolo conto), è altrettanto vero che la modalità CBR non
consente una elevata precisione sulla dimensione finale senza contare che la qualità ottenibile, a
parità di bitrate medio impiegato, risulta generalmente inferiore. Inoltre, dai test effettuati a basso
bitrate, è risultato che molti codec nella modalità CBR producono un file dalle dimensioni
completamente sballate, o comunque con una differenza notevole rispetto alla dimensione “teorica”.
L'utilizzo del doppio passaggio sostanzialmente consente di risparmiare bit preziosi nelle scene
video semplici da comprimere, per riservarli a quelle più complesse. Lo schema seguente illustra il
funzionamento della modalità 2-Pass:
L'utilizzo dei due passaggi è necessario in quanto il codec di compressione non può conoscere a
priori quali e quante siano le scene più semplici e quali e quante quelle più complesse. Ecco quindi
che risulta necessario effettuare una prima analisi del video, cosa che viene effettuata nel primo
passaggio: il codec comprime il film con la massima qualità possibile (minima compressione) e
genera un file contenente le statistiche di bitrate del file originale e le indicazioni dove posizionare i
fotogrammi chiave, i P-frames ed i B-Frames. Durante il secondo passaggio viene poi generato il
giugno 2006
47
filmato finale sulla base di queste statistiche.
SINTESI
con il metodo di codifica a due passaggi è possibile mantenere sostanzialmente una qualità costante
in tutto il video ottimizzando il sistema VBR, indipendentemente dalla complessità della sezione di
video in esame. La differenza sostanziale rispetto ai metodi ad un solo passaggio (CBR e VBR), è
che con i 2 passaggi si ottiene un video ancora più ottimizzato e dalle dimensioni e bitrate più
corretti. Resta comunque ovvio che la qualità media ottenibile dipenderà dal bitrate scelto
dall'utente e che al di sotto di determinati valori, per quanto si tenti di agire sui parametri di
configurazione del codec, il bitrate sarà comunque troppo basso per garantire una buona qualità.
2.12 I difetti dei codec lossy
I difetti causati dalla compressione lossy percettibili dai sensi umani sono conosciuti come artefatti
(dall'inglese "artifacts"). Se il bitrate non è sufficientemente elevato e se non si è configurato
propriamente l'encoder, si possono presentare alcuni difetti dovuti proprio al tipo di compressione e
non magari ad un bug dell'encoder stesso. I più evidenti sono due e vengono generalmente indicati
con il nome di "blocking-artifact" e "mosquito-noise".
Un esempio di "blocking-artifacts" del video dovuta ad un
bitrate non adeguato (troppo basso)
48
Un esempio di "mosquito-noise" attorno alle parole
(indicato dalle frecce), anche qui causato da un bitrate
inadeguato
giugno 2006
Il "blocking-artifacts" o "blocchettizzazione" o "quadrettatura" che dir si voglia, è causato da una
eccessiva compressione del fotogramma, e la conseguenza è che si vedono ad occhio nudo i blocchi
in cui è stata suddivisa l'immagine ai fini della compressione prima dell'utilizzo della DCT. Il
fenomeno è causato da una non perfetta corrispondenza tra i diversi blocchi a causa di un numero
troppo elevato di informazioni che sono state "eliminate" al momento della quantizzazione della
matrice delle frequenze DCT
Il "mosquito-noise" detto anche "ringing" si presenta invece come un alone di disturbo, un rumore
accanto agli oggetti che presentano un netto contrasto con lo sfondo. Le immagini qui sopra aiutano
a chiarire i due concetti ed illustrano i due più tipici difetti causati da un compressione eccessiva
basata sugli algoritmi Discrete Cosine Transform, ovvero da un bitrate non adeguato alla situazione.
Si ricorda inoltre che la compressione di dati lossy soffre del fenomeno chiamato generation loss,
ovvero la ripetizione del ciclo di compressione sugli stessi dati peggiora di molto la qualità rispetto
al singolo ciclo.
giugno 2006
49
3
LO STANDARD MPEG-4
3.1 MPEG
Innanzitutto una cosa importante da chiarire: MPEG non è un codec e nemmeno un formato.
MPEG (da pronunciare "em-peg") è l'acronimo di "Moving Pictures Experts Group", ed è il
soprannome attribuito all' ISO/IEC JTC1 SC29 WG11, dove:
ISO: International Organization for Standardization
IEC: International Electrotechnical Committee
JTC1: Joint Technical Commitee 1
SC29: Sub-committee 29
WG11: Working Group 11
MPEG è quindi un gruppo di lavoro internazionale che stabilisce degli standard. Fondato dall'Ing.
Leonardo Chiariglione del CSELT (Centro Studi e Laboratori di Telecomunicazioni), lavora allo
studio di sistemi di compressione per immagini in movimento con audio associato. La metodologia
adottata suddivide il lavoro in tre fasi, che riguardano i Requisiti, la Competitività e la
Convergenza.
Requisiti:
La precisa definizione dei requisiti è di estrema importanza nella ricerca degli obiettivi che si
vogliono raggiungere, e costituisce il primo passo del lavoro.
Competitività:
Nello sviluppo di uno standard internazionale, è importante che la vita dello standard stesso sia la
50
LO STANDARD MPEG-4
giugno 2006
più lunga possibile. Ciò significa che la tecnologia utilizzata dev'essere lo stato dell'arte, e che le
competenze della ricerca accademica e industriale devono essere fuse in un unico obiettivo comune.
In questa fase, l'MPEG lavora in concerto con le industrie che si dimostrano interessate allo
standard, valutando le differenti proposte presentate.
Convergenza:
In questa fase finale le proposte considerate valide e promettenti vengono integrate in un'unica
soluzione, rifinita mediante passi successivi attraverso programmi di simulazione, software e
sperimentazioni.
MPEG è nato nel 1988 e da allora ha prodotto diverse versioni dello standard.
•
MPEG-1: Utilizzato nei Video CD è un formato a bassa qualità (analoga al sistema VHS).
Definito a livello di standard nel 1992, questo formato è stato progettato per la codifica di
immagini in movimento e per l'audio ad esse associato con bitrate fino a circa 1,15 Mbit/s
per il video e dai 384 ai 192 Kbit/s per l'audio.
•
MPEG-2 E' stato sviluppato a partire dall'MPEG-1 ma progettato per una varietà più ampia
di applicazioni. Esiste dal 1994. L'applicazione primaria è la trasmissione a qualità
televisiva CCIR 601 con un bitrate tra 3 e 10 Mbit/s, ma è efficiente anche per applicazioni
con bitrate superiori come HDTV. E' utilizzato nelle trasmissioni satellitari digitali, nei
DVD e nel digitale terrestre. La sua caratteristica principale è la scalabilità, cioè la
possibilità di creare soluzioni di codifica e decodifica più o meno complesse in base al tipo
di prodotto da realizzare.
•
MPEG-3 Inizialmente sviluppato per HDTV in seguito si è scoperto che l'MPEG-2 era
sufficiente per HDTV e quindi questo nuovo standard venne abbandonato
•
MPEG-4 Sviluppato dal 1993 al 1998, è stato progettato per la codifica audiovisiva a
bassissimo bitrate. Tale formato può essere considerato un'evoluzione dell'MPEG-2 nella
gestione di immagini provenienti dalla televisione digitale, dalle applicazioni grafiche
interattive, nella distribuzione e nell'accesso di multimedialità in rete. La principale
caratteristica è la capacità di gestire la codifica di singoli oggetti: audio, video, sottotitoli
sono considerati indipendenti. lo standard supporta anche caratteristiche specificate da terze
parti come una particolare gestione dei Digital Rights Management o una gestione
giugno 2006
LO STANDARD MPEG-4
51
interattiva dei contenuti. A livello qualitativo lo standard non offre miglioramenti evidenti
come nel passaggio da MPEG-1 a MPEG-2, ma a livello di bitrate il risparmio è
significativo. Per la codifica video è stabilito lo standard H.264.
•
MPEG-7 Un sistema formale per descrivere i contenuti multimediali
•
MPEG-21 Gruppo nato per sviluppare una piattaforma comune per le future applicazioni
multimediali
Quello che ci interessa maggiormente è l'MPEG-4 in quanto è lo standard che attualmente si sta
affermando in quasi tutti i campi della codifica video digitale. Nonostante le sue specifiche siano
ormai "vecchie" di 8 anni solo adesso, nel 2006, si stanno diffondendo sul mercato prodotti
hardware e software che implementano questo standard. Nel corso degli anni sono state aggiunte ed
elaborate delle altre parti ed alcune di queste sono tutt'ora in evoluzione.
3.2 MPEG-4
L'ing L. Chiariglione, così definisce le comunicazioni multimediali:
"Comunicazione Multimediale" è la possibilità di comunicare informazione audio-video che
1. sia naturale, sintetica, o entrambe
2. sia in tempo reale e non
3. supporti differenti funzionalità a seconda delle esigenze dell'utente
4. fluisca da e verso differenti sorgenti simultaneamente
5. non richieda all'utente di preoccuparsi di specifici canali di comunicazione, ma usi una
tecnologia che ne sia cosciente
6. dia all'utente la possibilità di interagire con differenti elementi di informazione
7. consenta di presentare all'utente i risultati della sua interazione con il contenuto in una
maniera idonea alle sue necessità
52
LO STANDARD MPEG-4
giugno 2006
Nel Luglio del 1993, l'MPEG ha iniziato lo sviluppo dell'MPEG-4, che soddisferà i sette punti qui
elencati; le specifiche MPEG-4 diventeranno Standard Internazionale nel Novembre del 1998, con
codice ISO/IEC 14496 e titolo ``Coding of Audio-Visual Objects''.
Il progetto è basato su tre idee fondamentali:
Indipendenza dalla rete fisica: L'indipendenza dal livello fisico del paradigma OSI per le reti di
telecomunicazione è stata adottata fin da MPEG-1, ed è confermata in MPEG-4. Ciò non significa
che lo standard non possa trarre tutti i possibili vantaggi dalle peculiarità della rete utilizzata.
Interattività: Il successo del World Wide Web, dovuto alla capacità che ha l'utente di interagire
con il contenuto della rete Internet, ha spinto i progettisti dell'MPEG a dotare di simili funzionalità
il nuovo standard (si pensi al nuovo Google Video o ai canali televisivi via web). Anche il video per
i telefonini e le videoconferenze sono in MPEG-4.
Codice on demand: Prima ancora che venissero ideati i Network Computer, era già stato
dimostrato che un decodificatore programmabile, in grado di scaricare quando necessario gli
opportuni algoritmi di decodifica, è una soluzione preferibile all'avere già tutto il codice in locale.
L'MPEG-4 fa un largo uso del concetto di "oggetto audio-video" (AVO). Ogni sequenza MPEG
risulta composta da più AVO, ognuno dei quali è costituito da informazioni sul contenuto
dell'oggetto e da informazioni su come, quando e dove l'oggetto vada riprodotto. Il codificatore
esegue un multiplexing, o "mux", ovvero mixaggio degli AVO, eventualmente su diversi canali
logici, e li invia al decoder, dove avviene il de-multiplexing, o "demux", ovvero gli AVO vengono
decompressi, composti in una sequenza audio-video, e infine mandati in output. All'utente si dà la
possibilità di interagire con la composizione e la presentazione degli oggetti: le informazioni di
interazione posso essere trattate localmente dal decodificatore, o trasmesse al codificatore. Ogni
AVO può appartenere a una classe di oggetti già nota al decodificatore, oppure a una classe non
nota. In quest'ultimo caso, il decodificatore deve essere in grado di richiedere e ricevere le
definizioni delle nuove classi, possibilmente in parallelo agli altri dati, e quindi di provvedere alla
decodifica dell'AVO. Il decoder, quindi, deve possedere una libreria di classi comprendente le classi
standard, quelle eventualmente installate dall'utente, e quelle scaricate "al volo" dalla rete.
In parole semplici, un MPEG-4 non è né un file video né un file audio ma una "scatola" che li
contiene entrambi o uno solo dei due e contiene al suo interno molte altre informazioni. Questa è
giugno 2006
LO STANDARD MPEG-4
53
una grossa differenza concettuale da altri tipi di formato come l'MPEG-2 in cui audio e video sono
mixati all'origine in un solo file e non possono essere trattati separatamente.
3.2.1 Componenti dell'MPEG-4
Ecco la lista dei diversi sotto-standard divisi in Part (parti), quelli evidenziati sono di maggiore
interesse per i nostri scopi:
Part
Tipo
descrizione
1
Systems
Descrive la sincronizzazione e il multiplexing di video e
audio
2
Visual
codec per dati visivi (video, still textures, synthetic
images, ecc). Uno dei molti "profili" in Part 2 è
l'Advanced Simple Profile (ASP)
3
Audio
codec per la compressione di segnali audio
4
Conformance
Descrive le procedure per testare la conformità delle altre
part
5
Reference Software
Fornisce software per mostrare e chiarire le altre part
6
Delivery Multimedia
Integration Framework
(DMIF)
Interfaccia tra l'applicazione e il trasporto
7
Optimized Refernce Software
Fornisce esempi di come fare al meglio le
implementazioni (è in relazione con la part 5)
8
Carriage on IP networks
Specifica un metodo per trasportare il contenuto MPEG-4
su reti IP
9
Reference Hardware
Fornisce disegni hardware per mostrare come
implementare le altre part
10
Advanced Video Coding
(AVC)
Codec per segnali video. E' tecnicamente identico allo
standard ITU-T H.264
11
Scene description and
Application engine (BIFS)
Può essere usato per contenuto 3D o sottotitoli
12
ISO Base Media File Format
Formato file per memorizzare contenuto multimediale
13
Intellectual Property
Management and Protection
(IPMP) Extension
Gestisce i diritti d'autore
14
MPEG-4 File Format
Il formato file designato come container, che è basato
sulla part 12
15
AVC File Format
54
Per la memorizzazione di video AVC (basato dulla part
12)
LO STANDARD MPEG-4
giugno 2006
Part
Tipo
descrizione
16
Animation Framework
eXtension (AFX)
Gestisce le animazioni
17
Timed Text subtitle format
Gestisce i sottotitoli
18
Font Compression and
Streaming
Per i font Open
19
Synthesized Texture Stream
(non ancora finito)
20
Lightweight Scene
Representation (LASeR)
(non ancora finito – allo stadio FCD in luglio 2005, ha
raggiunto lo stadio CD in gennaio 2006)
21
MPEG-J Graphical
(non ancora finito – allo stadio FCD in luglio 2005, ha
Framework eXtension (GFX) raggiunto lo stadio CD in gennaio 2006)
22
Open Format Specification
(OFFS)
Una
descrizione
dettagliata
Basato su OpenType (non ancora finito – allo stadio CD
in luglio 2005)
dell'MPEG-4
è
disponibile
sul
sito
ufficiale:
http://www.chiariglione.org/mpeg/
3.3 H.264/AVC
La codifica delle informazioni video è
oggetto
di
studio
dei
gruppi
di
normalizzazione ISO/IEC (MPEG, Motion
Picture Expert Group) e ITU (VCEG, Video
Coding Experts Group), il cui lavoro portò
alla definizione della parte 2 di MPEG-2 e
allo standard ITU-T H.262 nel 1995. L'ITU
sviluppò indipendentemente l'H.263 e due
estensioni
(pubblicate
sotto
forma
di
annessi) denominate H.263+ e H.263++. Nel
frattempo in MPEG si procedeva allo
sviluppo della parte 2relativa alla codifica
video dello standard MPEG-4, partendo
come base da H.263.
giugno 2006
LO STANDARD MPEG-4
55
Nel 2001 fu deciso, per evitare divergenze nello sviluppo ed i problemi di sincronizzazione fra i due
organismi di standardizzazione, di stabilire un gruppo congiunto, il JVT (Joint Video Team) per
portare a termine il lavoro di definizione di un unico sistema di codifica video. Nella riunione
MPEG-4 del marzo 2003 a Pattaya venne approvato il nuovo sistema di codifica, AVC (Advanced
Video Coding), come parte 10 dello standard MPEG-4 ISO/IEC 14496-10. In ambito ITU lo
standard, inizialmente indicato provvisoriamente come H.26L, sarà pubblicato come ITU-T H.264.
H.264 e MPEG-4 part 10 sono quindi tecnicamente identici
3.3.1 Algoritmi e profili
Lo standard AVC, così come avviene nel caso di MPEG-1 e MPEG-2, non definisce un CODEC,
bensì la sintassi del flusso dati (stream syntax) e il metodo di decodificarlo.
Tabella 3.3.1a: Confronto tra le funzionalità di alcuni standard. Fonte: Wikipedia.org
56
LO STANDARD MPEG-4
giugno 2006
I tool, cioè gli algoritmi, adottati, non sono
sostanzialmente diversi da quelli illustrati
nel Capitolo 2: la maggiore efficienza di
codifica è dovuta alla cura dei dettagli di
ciascun elemento funzionale. La tabella
nella pagina accanto illustra le differenze, a
livello di algoritmi usati, tra i vari standard,
tra cui MPEG-4 ASP e MPEG-4 AVC (sono
due standard diversi, uno
rispetta le
specifiche della part-2, più datate, l'altro le
specifiche della part-10, più recenti). Lo
standard supporta la codifica del video nel
formato 4:2:0, interlacciato o progressivo.
Schema di codifica di H.264/AVC
In MPEG-4 H.264/AVC sono previsti differenti profili, indirizzati ad applicazioni differenti:
–
Baseline Profile (BP): destinato ad applicazioni in cui si richieda un ridotto ritardo dovuto alla
codifica/decodifica, ad esempio videotelefonia.
–
Main Profile (MP): per applicazioni diffusive o generiche, anche con video interlacciato.
–
Extended Profile (XP): per applicazioni mobili e streaming.
–
High Profile (HiP): per applicazioni broadcasting e di disc storage, in particolare per le
applicazioni televisive HD (è il profilo adottato in HD-DVD e Blu-ray).
–
High 10 Profile (Hi10P): andando oltre le capacità dei prodotti consumer di oggi, questo
profilo è superiore all'High Profile, aggiungendo il supporto fino a 10 bit per campione di
precisione dell'immagine decodificata.
–
High 4:2:2 Profile (Hi422P): principalmente orientato alle applicazioni professionali che usano
video interlacciato, si pone al di sopra dello standard Hi10P, aggiungendo il supporto per il
formato di campionamento colori 4:2:2 oltre ai 10 bit già citati per Hi10P.
Per ciascun elemento funzionale, nel seguito si descrivono brevemente i miglioramenti apportati in
giugno 2006
LO STANDARD MPEG-4
57
AVC rispetto ad MPEG-2, che possono essere sintetizzati in:
•
applicazione della trasformata su blocchi più piccoli
•
miglioramenti relativi alla valutazione e alla compensazione del movimento
•
filtro di ricostruzione nel loop di decodifica per ridurre l'effetto di blocchettizzazione
•
miglioramento della codifica entropica.
Sono definiti diversi livelli in AVC (che si trovano per esempio nei parametri di settaggio):
Tabella 3.3.1b: Schema dei livelli per H.264/AVC
Level
Max video bit
Max
Max frame
rate (VCL) per
macroblocks size
Baseline,
per secondo (macroblocks) Extended e
Main profile
Max video
Max video
bit rate
bit rate
(VCL) per
(VCL) per
High 10
High Profile
Profile
Max video
bit rate
(VCL) per
High 4:2:2
profile
Esempi di
risoluzioni /
framerate
1
1485
99
64 kbit/s
80 kbit/s
192 kbit/s
256 kbit/s
128x96/30.9
176x144/15.0
1b
1485
99
128 kbit/s
160 kbit/s
384 kbit/s
512 kbit/s
128x96/30.9
176x144/15.0
1.1
3000
396
192 kbit/s
240 kbit/s
576 kbit/s
768 kbit/s
176x144/30.3
320x240/10.0
1.2
6000
396
384 kbit/s
480 kbit/s
1152 kbit/s
1536 kbit/s
176x144/60.6
320x240/20.0
352x288/15.2
1.3
11880
396
768 kbit/s
960 kbit/s
2304 kbit/s
3072 kbit/s
352x288/30.0
2
11880
396
2 Mbit/s
2.5 Mbit/s
6 Mbit/s
8 Mbit/s
352x288/30.0
2.1
19800
792
4 Mbit/s
5 Mbit/s
12 Mbit/s
16 Mbit/s
352x480/30.0
352x576/25.0
2.2
20250
1620
4 Mbit/s
5 Mbit/s
12 Mbit/s
16 Mbit/s
720x480/15.0
352x576/25.6
3
40500
1620
10 Mbit/s
12.5 Mbit/s
30 Mbit/s
40 Mbit/s
720x480/30.0
720x576/25.0
3.1
108000
3600
14 Mbit/s
17.5 Mbit/s
42 Mbit/s
56 Mbit/s
1280x720/30.0
720x576/66.7
3.2
216000
5120
20 Mbit/s
25 Mbit/s
60 Mbit/s
80 Mbit/s
1280x720/60.0
4
245760
8192
20 Mbit/s
25 Mbit/s
60 Mbit/s
80 Mbit/s
1920x1088/30.1
2048x1024/30.0
4.1
245760
8192
50 Mbit/s
62.5 Mbit/s
150 Mbit/s
200 Mbit/s
1920x1088/30.1
2048x1024/30.0
4.2
522240
8704
50 Mbit/s
62.5 Mbit/s
150 Mbit/s
200 Mbit/s
1920x1088/64.0
2048x1088/60.0
5
589824
22080
135 Mbit/s
168.75 Mbit/s 405 Mbit/s
540 Mbit/s
1920x1088/72.3
2560x1920/30.7
5.1
983040
36864
240 Mbit/s
960 Mbit/s
1920x1088/120
4096x2048/30.0
58
300 Mbit/s
720 Mbit/s
LO STANDARD MPEG-4
giugno 2006
3.3.2 Macro-blocchi e slice
I macro-blocchi sono anche in AVC costituiti da 16 x 16 elementi di immagine: 16 x 16 campioni
(sample) di luminanza e 8 x 8 campioni per ciascuna componente di crominanza Cb e Cr. I blocchi
(block) sono costituiti da 4 x 4 campioni (un quarto della dimensione adottata in MPEG-2). I macroblocchi sono organizzati in slice, un sottoinsieme di immagine decodificabile indipendentemente
dalle altre. L'ordine di trasmissione dei macro-blocchi non è necessariamente quello originario
nell'immagine, ma è indicato dal codificatore in una apposita mappa (Macroblock Allocation Map).
Sono definiti 5 differenti tipi di slice. I primi tre, analogamente a quanto visto nel capitolo 2, sono I
(intra), P (predictive) e B (bipredictive) e le predizioni sono ottenute a partire dalle picture
precedentemente codificate. In AVC più picture possono essere utilizzate per le predizioni e
pertanto codificatore e decodificatore memorizzano le picture utilizzate per le predizioni in una
apposita memoria (multipicture buffer) e il controllo per la gestione del buffer è specificato nel
flusso dati.
Nelle applicazioni di streaming via internet spesso lo stesso video è codificato a differenti bitrate ed
il decoder tenta di accedere al flusso a più elevato bitrate, che fornisce una più elevata qualità, ma se
le condizioni del canale non lo permettono, commuta al flusso a bitrate più basso. Quando si utilizza
MPEG-2 queste operazioni di commutazione possono essere effettuate a livello di GOP, in
corrispondenza di una I-picture e ciò implica l'uso di GOP relativamente corti e lo sfruttamento non
ottimale della ridondanza temporale dell'informazione video. In AVC sono stati pertanto definiti
ulteriori due tipi di slice, denominati SI (Switching I) e SP (Switching P) che consentono
un'efficiente commutazione fra flussi di dati a bitrate differente, senza rinunciare al massimo
sfruttamento della ridondanza temporale.
3.3.3 Predizione e codifica intra
Nella codifica intra è sfruttata la sola correlazione spaziale: per aumentare l'efficienza vengono
codificate le differenze fra i campioni del macro-blocco e i campioni precedentemente codificati,
tipicamente quelli posizionati sopra e a sinistra e sono definiti 9 modi distinti di predizione. Nel
caso di aree piatte, con scarso dettaglio si può adottare la codifica intra sull'intera area 16 x 16 ed in
tal caso sono definiti altri 4 modi di predizione per l'intero macro-blocco.
giugno 2006
LO STANDARD MPEG-4
59
3.3.4 Predizione e codifica inter
Nella codifica di tipo inter, come abbiamo visto nel capitolo 2, si parte da una predizione ottenuta,
sfruttando la correlazione temporale, da uno o due quadri precedentemente codificati. La predizione
può essere ottenuta mediante una stima ed una compensazione del movimento (motion compesated
prediction). A differenza dagli standard precedenti, in H.264 la dimensione del blocco su cui si
effettua la predizione può variare da 16 x 16 fino a 4 x 4. Questo metodo di partizionare i macroblock in sub-block è denominato tree structured motion compensation e in fase di codifica sono
possibili molteplici scelte che hanno implicazioni differenti sul numero di bit necessario a
codificare i vettori movimento e le differenze residue: in genere dimensioni elevate del blocco sono
convenienti in aree piatte, mentre in aree ricche di dettagli si può trarre vantaggio dall'uso di aree
ridotte.
La precisione per i vettori movimento si incrementa da 1/2 elemento di immagine, utilizzato in
MPEG-2, a 1/4 di elemento di immagine in AVC. Per ottenere questa precisione si utilizza un filtro
digitale (6-tap FIR, Finite Impulse Response) che fornisce, a partire dalla somma pesata dei valori
dei 6 campioni di luminanza adiacenti, i valori interpolati a 1/2 e una successiva interpolazione
bilineare permette di ricavare i valori a 1/4. Nel caso della crominanza e di formato 4:2:0 la
precisione
è
portata
a
1/8,
che
corrisponde
al
valore
1/4
per
la
luminanza.
Esiste una correlazione fra i vettori movimento delle sotto-partizioni adiacenti: essa è sfruttata
calcolando un valore di predizione MVp dei vettori movimento relativi ad un macro-blocco. Il
valore di MVp è calcolato sia in codifica che in decodifica sulla base della struttura in termini di
sotto-partizioni che costituiscono il macro-block. In questo modo al decoder vengono inviati solo
gli MVd, i valori delle differenze fra i vettori movimento e il valore predetto MVp.
3.3.5 Trasformata e quantizzazione
Si utilizzano tre trasformate che dipendono dal tipo di dati che devono essere elaborati:
–
una trasformata 4 x 4 dei 16 coefficienti DC nel caso di macro-blocchi intra 16 x 16
–
una trasformata 2 x 2 per i coefficienti DC delle crominanze di tutti i macro-blocchi
–
una trasformata 4 x 4 di tutti gli altri dati differenze.
Il tipo di trasformata adottato è basato sulla DCT (Discrete Cosine Transform), ma sono state
apportate delle modifiche affinché le operazioni richiedano somme e shifting effettuabili con
60
LO STANDARD MPEG-4
giugno 2006
numeri interi a 16 bit in modo da non avere perdita di precisione effettuando la trasformazione
diretta seguita da quella inversa. Esistono 52 passi di quantizzazione, denominati QP e questa ampia
gamma di valori permette al codificatore di raggiungere il miglior compromesso fra qualità e
bitrate.
3.3.6 Filtro di ricostruzione
L'effetto di blocchettizzazione è uno dei degradamenti caratteristici delle tecniche di compressione
che operano su macro-blocchi di campioni video: è particolarmente visibile e fastidioso. AVC
introduce un filtro apposito che è applicato prima della trasformata inversa sia nel codificatore,
prima della ricostruzione delle immagini utilizzate per le predizioni, sia nel decodificatore. Si
ottengono due principali vantaggi: una minore visibilità dei bordi dei blocchi e una migliore
predizione inter con compensazione del movimento (nel caso di predizione intra i macroblocchi
sono filtrati, ma la predizione è ottenuta dai macro-blocchi ricostruiti non filtrati).
3.3.7 Codifica VLC
I simboli che rappresentano i parametri relativi ai modi di codifica e predizione, i vettori movimento
e i coefficienti della trasformata vengono codificati con codici a lunghezza variabile. Lo standard
specifica diversi tipi di codifica entropica: una codifica a lunghezza variabile (VLC, Variable
Lenght Coding) basata su tabelle di assegnazione statiche oppure basate sul contesto CAVLC
(Context Adaptive Variable Lenght Coding) e CABAC (Context Adaptive Binary Arithmetic
Coding). Il CAVLC utilizza diverse tabelle VLC specificatamente ottimizzate per i vari elementi
sintattici in base a quelli precedentemente trasmessi. A seguito della predizione, trasformazione e
quantizzazione i valori relativi ai coefficienti sono molto spesso nulli o molto piccoli: la codifica a
lunghezza variabile sfrutta le sequenze di zero (codifica run-level), l'elevata frequenza di valori +1 e
-1, e la correlazione fra il numero di coefficienti non nulli di un blocco e quello nei blocchi
adiacenti. Il CABAC, che è utilizzato nel Main Profile, sfrutta in modo ancora più efficiente la
correlazione fra simboli perché utilizza la statistica dei simboli precedentemente codificati per
stimare la probabilità condizionata, usata per selezionare uno fra i diversi modelli.
giugno 2006
LO STANDARD MPEG-4
61
3.4 Incremento in qualità e in complessità
Il sistema di codifica MPEG-2 video è stato definito nella prima metà degli anni '90 in base alle
possibilità realizzative, in termini di complessità circuitale e quindi di costi, disponibili all'epoca. E'
stato proprio il corretto compromesso fra qualità offerta e costi che ha consentito l'affermazione
dello standard e il suo ampio campo di applicazione, soprattutto nell'ambito dei prodotti del mercato
di massa. Nel 1994 gli ASIC (Application Specific Integrated Circuit) utilizzati per la progettazione
del decoder erano caratterizzati da una densità di integrazione per microcircuito (chip) pari a 120
mila porte logiche (gate) con dimensioni del gate fra 0,5 a 1 μm. Dieci anni dopo si arriva a 25
milioni di gate con dimensione della porta inferiore a 0,1 μm. L'immediata conseguenza è che oggi
è pensabile la realizzazione di uno standard che, come l'AVC, pur non traendo origine da
cambiamenti sostanziali degli algoritmi, raffina l'uso dei tool di compressione al fine di sfruttare
tutte le fonti di correlazioni spazio-temporali fra le informazioni video e di ridurre le distorsioni più
visibili, in particolare l'effetto di blocchettizzazione. La tabella 3.4 riassume una valutazione
dell'incremento in complessità e in efficienza previsto per AVC. Il decodificatore per il Main
Profile di AVC, adatto per le applicazioni televisive, è fino a quattro volte più complesso di quello
per il Main Profile di MPEG-2 e la complessità sale fino a otto volte nel caso del codificatore.
Tabella 3.4: Complessità e miglioramenti di H.264/AVC rispetto a MPEG-2
Profilo
Applicazioni previste
Aumento della
complessità stimata
per il decodificatore
Stima preliminare
del miglioramento
in efficienza
Baseline
Applicazioni a basso ritardo,
videotelefono, mobile, ...
Circa 2,5 volte
Circa 1,5 volte
eXtended
Mobile, streaming, ...
Circa 3,5 volte
Circa 1,75
Main
Distribuzione del segnale video
interlacciato
Circa 4 volte
Circa 2
All'incremento in complessità corrisponde quello in termini di qualità percepita dell'immagine codecodificata. La possibilità di usare diverse dimensioni dei blocchi (da 16 x 16 fino a 4 x 4) e di
aumentare la precisione dei vettori movimento a 1/4 di elemento di immagine è un contributo
62
LO STANDARD MPEG-4
giugno 2006
importante all'efficienza di codifica, a spese di un incremento delle possibilità di scelta da parte del
codificatore (e quindi della sua complessità). Lo sfruttamento della correlazione fra i coefficienti
appartenenti a macro-blocchi adiacenti consente un miglioramento significativo nel caso di ampie
aree di immagine con caratteristiche simili (ad esempio l'erba nel campo di calcio), a spese di un
incremento in complessità: debbono essere effettuati elaborazioni che coinvolgono più macroblocchi sia a livello di codificatore che di decodificatore. Un ulteriore incremento nell'efficienza è
dato dal miglior sfruttamento della correlazione fra i dati: la codifica entropica (CAVLC e, nel
Main Profile, CABAC) richiede più memoria per le tabelle, anche a livello di decodificatore.
L'adozione del filtro di ricostruzione all'interno del loop di decodifica è molto importante per
migliorare la qualità soggettiva: riduce infatti l'effetto blocchettizzazione, particolarmente fastidioso
nel caso di codifica a basso bitrate oppure per immagini particolarmente critiche. MPEG-2 non è
particolarmente efficiente nella codifica degli elementi di sintassi quali le intestazioni (di sequence,
picture, slice) e ciò lo rende totalmente inadatto all'uso ai bitrate inferiori a 2 Mbit/s (come vedremo
nei test). AVC è molto più efficiente anche in questo compito, rendendolo adatto anche ad
applicazioni in cui non sono disponibili elevati bitrate, ad esempio streaming su web. In generale, si
può sostenere che i miglioramenti oggettivi e soggettivi offerti da AVC rispetto a MPEG-2 siano
soprattutto validi nel caso di elevati fattori di compressione ed uso a bassi bitrate e ovviamente
dipendano dal contenuto delle immagini.
Vediamo le differenze in termini pratici: per codificare 90 minuti di un DVD mantenendo la stessa
qualità visiva l'H.264/AVC permette di risparmiare 3 volte lo spazio richiesto con MPEG-2 e quasi
2 volte quello richiesto con MPEG-4 ASP (part 2, non-AVC):
giugno 2006
LO STANDARD MPEG-4
63
Così come è avvenuto nel caso di MPEG-2, è probabile che inizialmente non tutti i tool previsti
dallo standard vengano utilizzati nel modo ottimale (per ragioni di complessità, e quindi costo e
tempo di codifica) e che quindi i primi codificatori non offriranno il miglioramento desumibile dai
test effettuati con codificatori che non operano in tempo reale. Le prestazioni dei codificatori
miglioreranno nel tempo, comunque la qualità percepita dipende non solo dal bitrate disponibile,
ma anche dalla criticità del materiale video da codificare e dalle condizioni di visualizzazione e da
tecnologia, dimensioni e risoluzione degli schermi.
3.5 Applicazioni:
L'elevata efficienza a bassi bitrate rende AVC adatto ad applicazioni di tipo mobile, normalmente
caratterizzate da una limitata disponibilità di banda. Tra i dispositivi ideali ci sono telefoni cellulari,
PDA (Personal Digital Assistant), PC palmari, fotocamere digitali e sistemi di archiviazione
portatile come il famosissimo I-Pod di Apple. Ma H.264 si è rivelato ideale per molti altri tipi di
applicazione. La distribuzione dell'informazione video per mezzo di connessioni a larga banda
(xDSL e fibra ottica) fruibile in modalità streaming, download o video on demand mediante
protocollo internet e utilizzando il PC o il terminale TV è un'applicazione attraente per le società di
telecomunicazioni poiché le mette in grado di fornire contemporaneamente servizi di telefonia, dati
e TV (tipo Fastweb). I concorrenti principali di AVC Extended Profile per questo tipo di
applicazioni sono standard proprietari (che analizzeremo nei test) come Windows Media Video e
Real Video. AVC è un open standard, è stato sviluppato mediante un processo di Open Call for
Proposal e, in linea di principio, offre significativi vantaggi rispetto ai sistemi proprietari. Nessun
elemento di un open standard può essere sotto il controllo di una singola industria e un singolo
64
LO STANDARD MPEG-4
giugno 2006
produttore non può causare, introducendo una nuova versione hardware o software, discontinuità
nella compatibilità con il pregresso (backward compatibility). Il gran numero di industrie che
competono, introducendo miglioramenti nell'uso dei tool e incrementando l'efficienza, favorisce lo
sviluppo del prodotto, così come si è verificato nel caso di MPEG-2.
3.5.1 Diffusione televisiva a definizione standard
Il Main Profile di AVC è caratterizzato da una maggiore complessità, per consentire la codifica del
segnale video interlacciato e offrire una qualità adatta alla diffusione televisiva, con una qualità
simile a quella ottenibile con MPEG-2 video, ma con un risparmio in termini di bitrate mediamente
valutabile nell'ordine del 50%. l'adozione di AVC per la diffusione satellitare potrebbe triplicare la
capacità in confronto a quella attuale. Ovviamente l'investimento relativo ai terminali d'utente
(STB, set-top-box) rappresenta in questo caso una porzione molto significativa per lo sviluppo del
servizio e quindi è difficile giustificare una sostituzione dell'attuale parco di STB. Analogamente il
gruppo DVB-T, relativo allo standard di diffusione terrestre, è interessato a valutare l'adozione di
AVC: in questo caso si potrebbe avere un incremento del numero di programmi disponibili per ogni
canale terrestre. Occorre ricordare che MPEG-2 è attualmente utilizzato soprattutto nei
decodificatori DVD: il DVD Forum (www.dvdforum.org) infatti sta valutando la possibile adozione
di AVC per incrementare significativamente la durata del video disponibile sul DVD, oltre ad
utilizzarlo sicuramente per i nuovi supporti HD-DVD.
3.5.2 Diffusione televisiva ad alta definizione
L'adozione di AVC consentirebbe di utilizzare l'attuale formato DVD anche per la memorizzazione
di film in alta definizione, non rendendo necessario il passaggio a tecnologie più complesse e
costose di registrazione ottica. Relativamente alla diffusione, l'AVC è preso in considerazione
dall'Advanced Television Systems Committee (www.atsc.org), l'organizzazione internazionale che
si occupa di definire lo standard HDTV (High Definition TeleVision). Anche nel caso della TV ad
alta definizione, i concorrenti sono gli standard proprietari Microsoft VC-1 (il nuovo standard
derivato dall'attuale codec Windows Media Video 9) e Realvideo.
Alcune applicazioni candidate all'utilizzo di H.264/AVC:
–
formato HD-DVD del DVD Forum
giugno 2006
LO STANDARD MPEG-4
65
–
formato Blu-Ray del Blu-Ray Disc Association (BDA)
–
Il Digital Video Broadcast (DVB) ha approvato l'uso di H.264/AVC per la televisione
broadcast in Europa alla fine del 2004
Standard per i ricevitori di canali HDTV e Pay-TV per i servizi di televisione broadcast
–
digitale terrestre in Francia (fine 2004)
I' Advanced Television Systems Committee (ATSC) in USA sta considerando la possibilità di
–
adottare uno o due codec video avanzati per il modo opzionale di trasmissione avanzata
Enhanced-VSB (E-VSB) per la televisione broadcast negli Stati Uniti. H.264/AVC e VC-1
(Microsoft) sono i due candidati maggiori.
–
Il servizio Digital Multimedia Broadcast (DMB) nella Repubblica di Korea userà H.264/AVC
–
I servizi di broadcast del ISDB-T in Giappone useranno il codec h.264/AVC, inclusi i
maggiori broadcasters: NHK, Tokyo Broadcast System (TBS), Nippon Television (NTV), TV
Asahi, Fuji Television, TV Tokyo
useranno il nuovo standard i servizi di broadcast diretto satellitare come: BBC HD (UK),
–
DirecTV(USA), Dish Network(USA), Euro1080(EU), Premiere (DE), ProSieben (DE), SkyHD
(UK e Irlanda) e soprattutto Sky Italia (IT)
L'IETF ha completato un formato payload (RFC 3984) per trasportare video H.264/AVC
–
usando il Real-Time Transport Protocol (RTP)
l'Internet Streaming Media (ISMA) ha adottato H.264/AVC per le sue nuove specifiche ISMA
–
2.0
Ma la lista è ancora lunga e comprende servizi di telefonia, canali di comunicazione interni militari,
e soprattutto Video su Internet.
3.6 Implementazioni software
Il numero di codec AVC disponibili sul mercato ha raggiunto il numero di 65 (aprile 2006). La lista
dettagliata e i relativi links è disponibile al seguente indirizzo:
66
LO STANDARD MPEG-4
giugno 2006
http://forum.doom9.org/showthread.php?t=95939
Ricordiamo che tra i primi sostenitori di H.264 c'è la Apple Computer che ha integrato H.264 nel
Mac OS X 10.4 (Tiger) e in molti suoi prodotti, tra i quali il celeberrimo I-Pod.
CONTAINERS
Molte implementazioni supportano diversi formati di container e questo genera gran confusione e
svariati problemi di interoperabilità. I tipi di file prodotti da codec H.264 possono essere:
.mp4
E' il container di AVC definito nello standard MPEG-4 (ISO 14496-15)
.mpg
E' il container di AVC definito nello standard MPEG-2 (ISO 13818-1, AMD3)
.avi
L'uso di AVC-in-AVI non è standardizzato e quindi provoca problemi di incompatibilità. Le
limitazioni tecniche di AVI e VFW (per esempio riguardo i b-frames) unite all'hacking necessario
per farli funzionare con AVC, impediscono la piena implementazione di tutte le caratteristiche
possibili offerte da AVC e quindi frenano la qualità e la velocità di sviluppo, l'interoperabilità e la
competizione.
.264/.h264
il bitstream video puro, non contenuto in nessun container
giugno 2006
LO STANDARD MPEG-4
67
4
4.1 Il problema dei metri di valutazione
L'avvento dei sistemi di compressione, memorizzazione e trasmissione di video digitale ha portato
con sé limitazioni fondamentali delle tecniche e metodologie che venivano usate per misurare la
qualità di un segnale video analogico. I parametri tradizionali hanno sempre contato sulla
"costanza" delle performance di un sistema video per differenti scene di input. Ovvero, si poteva
mandare un segnale di test (per esempio le classiche barre di colore statiche) ed essere
relativamente fiduciosi che il sistema avrebbe risposto similmente anche per del video con
immagini in movimento. Molte ricerche sono state effettuate per stabilire i parametri delle
prestazioni di un video analogico tradizionale (guadagno, fase, distorsione della forma d'onda, ecc).
Mentre l'avvento dei sistemi di compressione video (i codec) non ha invalidato questi parametri
tradizionali, esso ha certamente reso più inconsistente la loro connessione con la qualità del video
percepito dall'utente.
Barre colore tradizionali (statiche)
68
un frame estratto da un video test per il controllo del
segnale digitale (15 secondi in loop). La scena è
dinamica: le gigure geometriche ruotano e gli oggetti si
spostano sullo schermo
giugno 2006
4.2 Problemi
4.2.1 Dipendenze dalle scene di input
I sistemi video digitali adattano e cambiano il loro comportamento a seconda della scena di input.
Le prestazioni possono variare molto in base alle caratteristiche dinamiche del segnale di input
(movimento, livello dei dettagli nello spazio, ecc.). Nella fase di testing di un sistema di
trasmissione digitale, usare scene di input diverse da quelle che verrano usate poi in produzione3
può indurre a valutazioni qualitative sbagliate.
4.2.2 Dipendenze dai sistemi di trasmissione digitali
Le caratteristiche operative sei sistemi di trasmissione digitale (bitrate, error-rate, dropped packet
rate) possono variare nel tempo e questo può produrre fluttuazioni di qualità. Questi cambiamenti
transitori possono essere molto difficili da catturare senza che le prestazioni del sistema vengano
monitorate continuamente. Idealmente, questo monitoraggio dovrebbe essere fatto in produzione, in
quanto mettere off-line il sistema di trasmissione e inserire segnali di test conosciuti cambierebbe le
condizioni sotto le quali il sistema sta operando e falserebbe la misurazione. Due esempi che
dimostrano questo effetto sono il multiplexer (un dispositivo hardware deidicato), che unisce in un
singolo canale a bitrate costante diversi canali a bitrate variabile, e la trasmissione in streaming via
Internet utilizzando una bandwidth non garantita. Solo un monitoraggio in produzione continuo e
non intrusivo può catturare accuratamente ciò che lo spettatore sta vedendo in ogni preciso istante.
E' quindi necessario un nuovo paradigma di misurazione.
4.2.3 Nuovi disturbi del video digitale
I sistemi di video digitale producono differenti tipi di disturbo (artefatti) rispetto ai sistemi video
analogici. Esempi di questi artefatti sono la blocchettizzazione, gli error-blocks (blocchi di
immagine completamente sbagliati), il mosquito-noise, il blurring (sfocatura), il jerkiness o strobing
(blocchi o insiemi di macro-blocchi che rimangono fermi). Per quantificare pienamente le
caratteristiche di performance di un sistema video digitale, è auspicabile avere un set di parametri in
cui ogni parametro è sensibile ad uno specifico tipo di disturbo. Questo è simile a ciò che era stato
3 Col termine in produzione si intende “durante il funzionamento reale”, come per esempio un sistema di streaming
durante la vera trasmissione dei filmati e non una trasmissione di test o simulata.
giugno 2006
69
sviluppato per i disturbi analogici (per esempio il multi-burst misura la risposta di frequenza, il
signal-to-noise misura il livello del rumore nel segnale analogico).
4.2.4 La necessità dell'indipendenza della tecnologia.
La persistenza degli stessi sistemi video analogici negli ultimi 40 anni ha permesso di ottenere oggi
materiale di video testing molto accurato. Al contrario, la rapida evoluzione della compressione,
memorizzazione e trasmissione di video digitale prevede un'operazione di misurazione delle
prestazioni molto più difficile. Per evitare che diventino in breve tempo obsolete, i nuovi sistemi di
misurazione per il video digitale devono essere indipendenti dalla tecnologia attuale, o comunque
non direttamente dipendenti da uno specifico codec o da architetture di trasporto. Una via per
ottenere quest'indipendenza è di far sì che lo strumento di misurazione percepisca e misuri i disturbi
video come farebbe un essere umano. I metodi oggettivi attuali si avvicinano molto a questo scopo,
ma il giudizio degli esseri umani resta ancora il più affidabile e completo.
4.3 Valutazione soggettiva
Nella valutazione della qualità soggettiva di un video compresso ci si basa su di un giudizio, per
così dire "ad occhio", e si dà un voto basandosi ad esempio su di una scala come quella illustrata qui
di seguito:
Punteggio
5
4
3
2
1
Qualità
Eccellente / Ottima
Buona
Sufficiente / Discreta
Non sufficiente
Pessima, del tutto insufficiente
Presenza
di artefatti e disturbi
Impercettibili
Appena percettibili ma non fastidiosi
Percettibili e leggermente fastidiosi
Fastidiosi
Molto fastidiosi
Da quanto si evince nei test che ho effettuato personalmente è ancora il metodo più affidabile.
Come vedremo in seguito esistono metodi oggettivi basati su modelli matematici che cercano di
simulare il giudizio di un essere umano, ma nessun programma potrà mai sostituire le "sensazioni",
le "percezioni" di un singolo individuo. Soprattutto perché ogni persona percepisce in maniera
diversa i difetti di un video, e solo unendo giudizi di persone diverse si può avere una visione
70
giugno 2006
globale della qualità. In alcuni test di sistemi disponibili in commercio sono state notate nelle
valutazioni soggettive differenze anche di 3 punti sulla scala da 1 a 5. Per esempio, risultati di test
soggettivi sulla qualità di sistemi a 45 Mbit/s (sistemi usati da alcuni broadcasters che trasmettono
con diverse coppie di codec) hanno variato da 2.16 a 4.64.
4.4 Valutazione oggettiva
Le tecniche di valutazione oggettiva sono modelli matematici che emulano i risultati delle
valutazioni di qualità soggettive basati su criteri e metriche che possono essere misurate
oggettivamente. La via più tradizionale per valutare la qualità di un codec consiste nel calcolare il
rapporto di picchi di signal-to-noise (SNR) tra il segnale sorgente e il segnale processato, ma negli
ultimi anni sono stati elaborati anche altri metri di misura più precisi. Vediamoli.
4.4.1 Il PSNR
E' l'acronimo di Peak-to-peak Signal-to-Noise Ratio. E' il sistema più usato per misurare la qualità
di un'immagine ricostruita partendo da quella originale. Per capire come funziona analizziamo
prima il Mean Squared Error (MSE). Per 2 immagini monocromatiche I e K di m x n pixel si
definisce l'approssimazione del disturbo generato come:
Genericamente il PSNR è uguale al MSE ma è più conveniente perché usa una scala logaritmica.
Viene definito nel modo seguente:
dove MAXI è il massimo valore di pixel dell'immagine. Quando i pixel sono rappresentati usando 8
bit per pixel, esso è 255.
giugno 2006
71
Originale
Compresso
Y-YUV MSE
Originale
Compresso
Y-YUV PSNR
Al lato pratico il PSNR tipicamente assume valori compresi tra 20 e 50 dB (con due o quattro cifre
decimali significative) e valori più elevati testimoniano un qualità superiore ovvero una maggior
fedeltà con l'originale non compresso. La seguente immagine aiuta a farsi un'idea del rapporto
esistente tra valore del PSNR, bitrate (espresso in Mbps) e qualità soggettiva percettibile:
72
giugno 2006
Il PSNR può essere calcolato per ciascuna delle componenti Y-YUV, U-YUV, V-YUV, R-RGB, GRGB, B-RGB. Un grafico del PSNR di un'immagine YUV potrebbe essere il seguente:
Come si nota l'andamento delle 3 curve è molto simile, pertanto si potrebbe fare una media tra
queste e realizzare una sola curva rappresentativa delle 3 componenti YUV, così da ridurre il
numero di informazioni ed avere una visione più chiara nel caso si confrontino più video sullo
stesso grafico. Nei test effettuati è stata usata la funzione compare() del programma AVISynth che
effettua il calcolo del PSNR e restituisce un file di log con i valori per ogni singolo frame (utile per
fare i grafici) e il valore della media, chiamato overall PSNR che verrà adottato come valore unico
per le misurazioni PSNR.
E' necessario sottolineare che piccole variazioni del PSNR, dell'ordine di 1-2 dB, difficilmente
saranno evidenziabili con un giudizio soggettivo (sopratutto per bitrate elevati) e che sebbene
utilizzato universalmente per la valutazione della qualità di un'immagine, il PSNR è in grado di dire
relativamente poco sulla gravità di alcuni difetti di compressione quali la blocchettizzazione ed il
ringing.
giugno 2006
73
4.4.2 SSIM
L'indice SSIM è basato sulla misura di 3 componenti (luminanza, contrasto e struttura) e sulla loro
combinazione in un unico valore.
Orginale
Compresso
SSIM
4.4.3 VQM
Il sistema VQM, sviluppato da Feng Xiao nel 2000, usa le DCT per simulare la percezione umana.
Originale
Compresso
VQM
La spiegazione di come viene calcolato è piuttosto complessa e può essere consultata nel rapporto
ufficiale al seguente indirizzo: http://www-ise.stanford.edu/class/ee392j/projects/projects/xiao_report.pdf
74
giugno 2006
Altre metriche sono state proposte recentemente, tra cui:
•
MSAD
•
Delta
•
Bluring measure
Nei test effettuati non sono però stati utilizzati in quanto non ancora diffusi e riconosciuti
ufficialmente.
giugno 2006
75
5
COMPARAZIONE
In questo capitolo ci occuperemo di valutare nella pratica il comportamento dei più recenti codec di
compressione video sia lossless che lossy. La scelta dei codec è stata determinata da diversi fattori,
tra i quali: popolarità, efficienza già comprovata (escludendo quindi quei codec le cui performance
sono molto al di sotto della media) e disponibilità (free, trial versions, ecc.). Codec basati su
hardware specifico non sono stati presi in considerazione. Tutti i test sono stati effettuati
personalmente da chi ha scritto il presente documento, verificando sempre la correttezza del file di
output ottenuto e effettuando ove necessario valutazioni soggettive della qualità. I test hanno lo
scopo di confrontare le prestazioni dei codec e di stabilire quali siano i migliori codec attualmente
disponibili (giugno 2006) sul mercato. Il confronto verrà affrontato come una “gara” in cui ci
saranno vincitori e perdenti. Si effettueranno test a differenti bitrate e su differenti video, cercando
di ottenere risultati scientificamente validi, basati su criteri affidabili.
Nel confronto dei codec lossless, non essendoci variazioni di qualità visiva, verranno premiati:
●
velocità
●
rapporto di compressione
●
versatilità
Nei codec lossy invece verranno premiati:
76
●
velocità
●
compressione
●
qualità visiva
●
versatilità
COMPARAZIONE
giugno 2006
5.1 Risorse utilizzate
HARDWARE
Tutti i test sono stati effettuati con il seguente hardware:
processore
AMD Athlon 64 3000+@2,53Ghz
Scheda madre
ASUS A8n-E
RAM
2x 512MB PC3200 V-DATA DDR
scheda video
Radeon x850 256MB VIVO
Hard Disk
Maxtor 6B250s0, 7200rpm, 250GB, SATA2
monitor
LG 795FT+ a tubo catodico - FLATRON
risoluzione
1280x1024 @85Hz
SOFTWARE
Sistema Operativo
Windows XP Professional SP2
Software per l'encoding:
PROGRAMMA
FUNZIONE
VERSIONE
2.55
LINK
AviSynth
frameserving
www.avisynth.org
VirtualDub
editing ed encoding 1.6.15 build 24442 www.virtualdub.org
VirtualDubMod
editing ed encoding 1.5.10.2 build 2542
http://sourceforge.net/projects/virtu
aldubmod
Yamb
Mux / demux
1.6.0
http://yamb.unite-video.com
yuv2avi
conversione video
-
www.streamcrest.com
players:
PROGRAMMA
VERSIONE
LINK
Media Player Classics
6.9.4.0
http://sourceforge.net/project/showfiles.php?group_id=
82303&package_id=84358
Elecard Mpeg Player
4.0.61
www.elecard.com
VideoLan
0.8.5
www.videolan.org/vlc/
Windows Media Player
11-beta
www.microsoft.com
giugno 2006
COMPARAZIONE
77
software per l'analisi qualitativa oggettiva:
PROGRAMMA
VERSIONE
LINK
MSU Video Quality Measure
1.2 beta
www.compression.ru
PSNR Creator
1.1
www.canalxvid.com
Avisynth (funzione compare() )
2.55
ww.avisynth.org
Software utilizzato per il decoding:
E' stato usato il pacchetto opensource ffdshow (http://ffdshow.sourceforge.net) contente le librerie
libavcodec che, testate sull'autorevole forum di doom9, sono risultate sviluppare i migliori decoder
(http://forum.doom9.org/showthread.php?t=99402).
CLIPS
Sono state utilizzate sequenze video test standard, disponibili per il download sul sito del VQEG
(Video Quality Experts Group) http://media.xiph.org/vqeg/TestSeqences/Reference/ . Tali files
sono in formato .yuv quindi ho utilizzato il programma yuv2avi per convertire i files in AVI con
spazio colore RGB a 24-bit. Alcune di queste clip erano interlacciate (vedere l'appendice per un
approfondimento) e per valutarne correttamente la qualità video con tutti i codec (molti non
supportano l'interlacciamento) ho dovuto prima de-interlacciarle. Esistono vari modi per deinterlacciare un video ma non è l'argomento di questa tesi. Io ho scelto un metodo misto che si basa
sull'eliminazione del campo dispari e sul ridimensionamento dell'immagine. Dopo varie prove ho
constatato che per la valutazione qualitativa di un frame è il metodo migliore, che evita la
formazione di qualsiasi artefatto e garantisce maggior coerenza con l'immagine originale.
78
COMPARAZIONE
giugno 2006
5.2 Codec LOSSLESS
Codec analizzati:
Alpary
Avizlib
Camstudio
CorePng
FFV1
Huffyuv
Lagarith
Lzo
Mindvid
MSU lossless
Picvideo lossless
giugno 2006
COMPARAZIONE
79
Alpary v2.0 build 957.040607 (12/04/2005)
Creato dalla società Alparysoft, supporta compressione lossless in RGB, YUY2 e YV12. Non
supporta il codec instance.
AVIzlib v2.2.3
E' un codec lossless per Video For Windows. E' indicato dagli autori come l'ideale per animazione
digitale o l'animazione in 3DCGs. Contiene due tipi di codec a seconda dell'uso. Può essere usato
come input solo un segnale RGB. Comunque il codec permette di convertirlo in YUV (i.e. YUV2 o
YV12) senza perdita visibile all'occhio umano.
CamStudio Lossless codec 1.0 (13/03/2003)
Codec molto veloce ottimizzato per le applicazioni di screen capture.
–
Opera in RGB ed è in grado di comprimere a 16,24 o 32-bit RGB bitmaps.
–
Supporta la compressione temporale
–
Può comprimere utilizzando 2 algoritmi diversi di compressione: LZO o GZIP. LZO è molto
veloce ed è usato per lo screen capturing. GZIP è molto utile quando si converte/ricomprime un
file AVI già compresso con CamStudio. Nei test le due modalità verranno indicate come
cam_gzip e cam_lzo.
Il piccolo file size prodotto con l'algoritmo GZIP lo rende ideale per scopi di archivio.
CorePNG v0.8.2
Essenzialmente, ogni frame è compresso come un'immagine PNG quindi ciò che fa il PNG lo fa
anche questo codec. Ha inoltre l'abilità di scrivere P-frames e di auto-decidere quando farlo. Il Pframe prende la differenza tra il frame precedente e il frame corrente e la codifica come un PNG.
CorePNG è stato inizialmente sviluppato per l'uso con i sottotitoli, comprime i cartoni animati e le
animazioni in CG molto bene e in molti casi meglio di HuffYUV e Loco.
80
COMPARAZIONE
giugno 2006
FFV1, fddshow (29/11/2005)
fddshow è un codec DirectShow e VFW per codificare/decodificare molti formati audio e video,
inclusi filmati DivX e XviD, usando libavcodec, xvid e altre librerie opensource, con un ricco set di
filtri postprocessing. FFV1 è un codec lossless semplice ma efficacie incluso nel software.
HuffYUV 2.1.1 (18/05/2004)
Scritto da Ben Rudiak-Gould (università di Berkeley, California), HuffYUV è un codec lossless
per WIN32 molto veloce. L'output del decompressor è identico bit a bit con l'input originale. E'
ritenuto da tutti come uno dei migliori e per questo si propone di rimpiazzare il formato video di
cattura uncompressed YUV. E' abbastanza veloce da comprimere in real-time a piena risoluzione un
video CCIR 601 (720 x 480 x 30fps) su un misero Celeron a 416Mhz. Supporta anche la
compressione lossless di dati RGB, quindi è molto versatile ed in più è free software.
Lagarith v1.3.8 (12/03/2006)
Si tratta di un codec opensource scritto da Ben Greenwood. E' stato disegnato con pochi ma chiari
obiettivi in testa:
–
Velocità: lo stesso creatore riconosce che non è veloce come il codec Huffyuv, ma la velocità di
encoding è comparabile a quella di molti altri codec lossless, anche se la velocità di decoding
potrebbe essere inferiore. Supporta il parallelizing nei sistemi multi-processore.
–
Supporto color-space: le conversioni color-space possono causare errori di arrotondamento,
introducendo perdita di dati, contrariamente all'ideale di una compressione lossless. Lagarith
cerca di evitare questo problema supportando direttamente i colorspace YV12, YUY2, RGB e
RGBA
–
keyframes: non permettere l'inter-prediction significa che ogni frame è codificato
separatamente. Ciò rende il cutting, il joining e il seeking più veloci.
Queste tre cose, unite al fatto che è più potente di Huffyuv, rendono Lagarith un codec utile per lo
stadio di editing video.
giugno 2006
COMPARAZIONE
81
LZOcodec v0.3 (01/05/2006)
Può essere usato come capture codec ma l'uso principale potrebbe essere quello di comprimere
video generati dal computer o film di animazione. Può convertire per esempio un file SWF (Flash)
o un Power Point in un file AVI.
MindVid 1.0 Beta 1 (06/06/2006)
Semplicità e facile utilizzazione è ciò che è alla base di questo codec. Le recensioni indicano che
raggiunge alti livelli di compressione usando lo stesso tempo di coding e decoding.
MSU lossless video codec v0.6 (25/09/2005)
Sicuramente uno dei migliori, sviluppato direttamente dal team di Compression Project, gruppo di
ricerca autorevole nel campo della compressione video. Vanta di essere assolutamente lossless,
evvero uguale bit a bit al file sorgente. Eaccetta in input RGB, YUY2 e YV12 e restituisce l'output
nello stesso formato, seppur permettendo la conversione tra un formato e l'altro. Ha inoltre una
funzionalità chiamata "denoising" che dovrebbe aumentare addirittura la qualità dell'immagine
sorgente e contemporaneamente il livello di compressione.
PICVideo Lossless JPEG codec v3 (25/02/2003)
Ottimizzato da Pegasus Imaging Corporation, è sia un codec Video for Windows che un filtro di
trasformazione DirectShow. Disegnato per l'editing professionale e per applicazioni di video
mediche, comprime RGB a 24-bit usando Predictor 1 lossless JPEG.
NOTA
Tutti i codec analizzati sono gratuiti e liberamente scaricabili dalla rete.
82
COMPARAZIONE
giugno 2006
TEST
(Giugno 2006)
tester:
SIMONE CHIESA
LOSSLESS
Video 1: sorgente originale: src6_ref__625.yuv
Video:
ferrari.avi
Colore:
RGB 24-bit
frames:
220 (8,8 secondi)
risoluzione
720 x 576
sistema
PAL
dimensione:
261 MB
25 fps
Si tratta di una breve sequenza video prelevata dagli archivi del Centro Ricerche RAI di Torino. Il
video mostra l'uscita di pista di una Ferrari durante un sessione di Formula1. La prima parte del
video è caratterizzata dal movimento della macchina su uno sfondo quasi immobile. Dopo il taglio
al frame 75 la macchina finisce fuori pista restando al centro dello schermo mentre tutto intono
scorre l'erba e la terra, caratterizzata da una grana molto grossa.
COLORE:
RGB-24bit
Settaggi standard (velocità\compressione)
CODEC
giugno 2006
SECONDI
KBytes
RATIO
Alpary
26
126,619
2,07
Avizlib
16
267,314
0,97
Cam_gzip
31
200,251
1,30
Cam_lzo
17
243,748
1,07
CorePng
63
142,640
1,83
COMPARAZIONE
83
CODEC
SECONDI
KBytes
RATIO
Ffv1 [1]
16
104,859
2,50
Huffyuv
11
150,741
1,74
Lagarith
12
112,137
2,33
Lzo [1]
60
76,756
3,43
Mindvid
24
156,686
1,67
MSU
59
108,276
2,41
Picvideo
12
199,916
1,31
[1] Da una verifica effettuata è risultato che anche se si imposta il codec a produrre un video RGB, il video prodotto è
invece un YV12, con evidente risparmio di spazio. Pertanto il codec viene squalificato per i test RGB e YUY2.
Lagarith è sicuramente la scelta migliore in quanto riesce ad ottenere il miglior rapporto
84
COMPARAZIONE
giugno 2006
velocità/compressione. Huffyuv arriva secondo di poco. MSU comprime meglio di tutti ma è
deludente nel fattore velocità.
Massima compressione
CODEC
SECONDI
KBytes
RATIO
Alpary
36
122,385
2,14
Avizlib
29
202,104
1,29
Cam_gzip
43
200,095
1,305
CorePng
108
142,065
1,84
Huffyuv
11
141,403
1,85
Lagarith *
12
112,137
2,33
Mindvid *
24
156,686
1,67
MSU
344
103,244
2,53
Picvideo *
12
199,916
1,305
* non permette di scegliere impostazioni riguardo il livello di compressione/velocità
Come anticipato MSU riesce a raggiungere il maggior coefficiente di compressione ma sacrificando
giugno 2006
COMPARAZIONE
85
moltissimo la velocità (344 secondi sono davvero tanti). Lagarith e Alpary sono due scelte più
ragionevoli.
Massima velocità
CODEC
SECONDI
KBytes
Fps
Alpary rgb
11
142,442
18
Avizlib
20
201,245
10
Cam_gzip
22
199,860
10
Cam_lzo
16
243,748
14
CorePng
22
152,777
10
Huffyuv
12
180,078
17
Lagarith *
12
112,137
17
Mindvid *
24
156,686
8
MSU
58
108,276
3
Picvideo *
12
199,916
17
* non permette di scegliere impostazioni riguardo il livello di compressione/velocità
Nelle impostazioni a massima velocità quasi tutti i codec si comportano bene. Vince Alpary, ma di
solo 1 secondo. Al secondo posto a parimerito Huffyuv, Lagarith e Picvideo. Paurosamente lento il
86
COMPARAZIONE
giugno 2006
codec MSU.
COLORE:
YUY2 (4:2:2)
Dimensioni originali: 174 MB
Standard
CODEC
SECONDI
KBytes
RATIO
Alpary
17
75.977
2,32
Avizlib
-
-
-
Camstudio
-
-
-
CorePng
45
74.077
2,35
Huffyuv
10
95.592
1,83
Lagarith
9
68.361
2,56
Mindvid
-
-
-
37
62.773
2,76
-
-
-
MSU
Picvideo
I codec evidenziati in rosso non permettono un utilizzo dello spazio colore YUY2
Nel rapporto velocità/compressione Vince nettamente Lagarith, seguito da Alpary a parimerito con
Huffyuv.
giugno 2006
COMPARAZIONE
87
CODEC
SECONDI
KBytes
RATIO
Alpary
23,22
73,955
2,38
CorePng
184,23
72,943
2,41
Huffyuv
10,02
95,592
1,83
Lagarith *
9,49
68,361
2,55
320,06
60,866
2,9
MSU
MSU vince ancora, seguito dal sempre ottimo Lagarith.
Massima velocità
CODEC
88
SECONDI
KBytes
Fps
alpary
21
86,625
20
CorePng
15
85,170
14
huffyuv
9
91,675
22
Lagarith *
9
68,361
24
msu
37
62,773
5
COMPARAZIONE
giugno 2006
Stessi risultati che per RGB, con un pari al primo posto per Huffyuv e Lagarith.
COLORE:
YV12 (4:2:0)
Dimensioni originali: 130 MB
Impostazioni standard
CODEC
giugno 2006
SECONDI
KBytes
RATIO
Alpary
15
61.056
2,13
Avizlib
-
-
-
Camstudio
-
-
-
CorePng
32
58.263
2,24
Ffv1
9
50.329
2,60
Huffyuv
-
-
-
Lagarith
7
54.717
2,36
Lzo_gzip
56
69.709
1,88
COMPARAZIONE
89
CODEC
SECONDI
KBytes
RATIO
Lzo_lzo
11
105.874
1,23
Mindvid
-
-
-
31
50.050
2,6
-
-
-
MSU
Picvideo
I codec evidenziati in rosso non permettono un utilizzo dello spazio colore YV12
Nello spazio colore YV12 Ffv1 conquista il posto d'onore, seguito a breve distanza da Lagarith.
Bene anche Alpary. MSU è ancora lento, peccato.
90
COMPARAZIONE
giugno 2006
CODEC
SECONDI
KBytes
RATIO
Alpary
19
59.225
2,20
CorePng
133
57.474
2,28
Ffv1
9
50.329
2,60
Lagarith
7
54.717
2,24
Lzo_gzip
277
69.770
1,86
Lzo_lzo
11
105.874
1,23
MSU
313
48.157
2,70
Vince sempre MSU, confermando il suo predominio per quanto riguarda la capacità di
compressione
Massima velocità
CODEC
giugno 2006
SECONDI
KBytes
Alpary
6
68.978
CorePng
13
66.789
Ffv1
9
50.329
COMPARAZIONE
91
CODEC
SECONDI
KBytes
Lagarith
7
54.717
Lzo_gzip
56
69.709
Lzo_lzo
11
105.874
MSU
30
50.140
Sorprende Alpary con i suoi 6 secondi, seguito come sempre da Lagarith con solo 7 secondi. Gzip è
praticamente fuori gara.
92
COMPARAZIONE
giugno 2006
Video 2: sorgente originale: src14_ref__525.yuv
Video:
new_york.avi
Colore:
RGB 24-bit
frames:
260 (8,67 secondi)
risoluzione
320 x 216
sistema
NTSC
dimensione:
51,4 MB
29,97 fps
Questo video è un'unica panoramica presa da un aereo che si sposta parallelamente all'immagine
verso sinistra. Il video originale è un NTSC ad alta risoluzione con un'ottima qualità dei dettagli. La
sua risoluzione è stata diminuita fino al valore di 320 x 216 così da testare il comportamento dei
codec a basse risuluzioni.
Per questo test riportiamo solo i grafici tralasciando i dettagli dei valori nelle tabelle.
COLORE:
RGB-24bit
Ottimo Lagarith, bene anche Huffyuv
giugno 2006
COMPARAZIONE
93
Massima velocità
Pareggio tra Alpary e Huffyuv
Vince ancora MSU
COLORE:
YUV 4:2:2 (YUY2)
Primo Lagarith, secondo Huffyuv
94
COMPARAZIONE
giugno 2006
Massima velocità
Pareggio tra Alpary, Uffyuv e Lagarith
Vince ancora MSU
COLORE:
YUV 4:2:0 (YV12)
Questa volta c'è un pareggio tra ben 3 codec: Lagarith, Ffv1 e MSU
giugno 2006
COMPARAZIONE
95
Massima velocità
Pareggio tra Alpary e Lagarith
Al primo posto sempre MSU
CONCLUSIONI
I risultati dei test fatti su 2 video così diversi tra loro (per frame/s, risoluzione, tipo di filmato, ...)
sono risultati quasi del tutto identici. Utilizzando il principio di induzione si potrebbe quindi
pensare che i risultati siano simili per qualsiasi video venga compresso. Diamo una valutazione per
ogni codec:
•
Alpary: E' risultato il codec più veloce e comprime piuttosto efficacemente in tutti gli spazi
colore. Una buona scelta per la compressione real-time. Voto: 8
•
Avizlib: E' il fanalino di coda per quanto riguarda la compressione. Restituisce un file dalle
dimensioni quasi identiche a quello del video non compresso e funziona solo con RGB.
Praticamente inutile. Voto: 2
•
Camvideo: Come Avizlib, funziona solo in RGB e produce un file poco compresso. Però ha
il vantaggio di poter scegliere tra due tipi di compressione diversi e se si utilizza l'algoritmo
lzo si può fare sufficientemente bene acquisizioni in real-time. Voto: 4
•
CorePNG: E' un codec dalle prestazioni mediocri, ma si ha la sicurezza che funzioni
dappertutto. Voto: 6
96
COMPARAZIONE
giugno 2006
•
Ffv1: La scelta migliore per la compressione nello spazio YV12 in quanto è veloce ed
efficace senza necessità di nessun settaggio. Si installa col pacchetto fddshow quindi è facile
da utilizzare. Il fatto che funzioni solo in YV12 riflette una certa tendenza dell'opensource di
creare solo cose “intelligenti” e utili (come abbiamo visto i vantaggi di comprimere in YV12
sono molti). Peccato però che in molti ambiti professionali si utilizzi solo RGB o YUY2,
quindi escludendoli si “autolimita” l'utilizzo e la diffusione. Voto: 8
•
Huffyuv: Lo standard de facto nel mondo dei codec lossless ma dai test non è risultato il
migliore in assoluto e inoltre ha il grosso difetto di non comprimere in YV12, che lo
penalizza parecchio. Comunque è un buon codec. Voto: 8
•
Lagarith: Se si pensa che questo codec è stato creato da un matematico per usi personali, la
cosa sembra incredibile. Nei test è risultato senz'altro il miglior codec lossless disponibile:
veloce, efficace e molto versatile (funziona in tutti gli spazi colore con ottime prestazioni).
Voto: 10
•
Lzo: Funziona solo in YV12. Anche questo codec, come Camvideo, ha la facoltà di
utilizzare 2 algoritmi diversi per la compressione: gzip o lzo. Gzip è meglio non
considerarlo nemmeno, voto: 0. Lzo invece è molto veloce ma non è efficace come Ffv1.
Voto: 5
•
Mindvid: E' ancora in versione beta ma già, se non si registra il prodotto, inserisce una frase
di disturbo nel video. E' un codec dalle prestazioni mediocri che funziona solo in RGB.
Inutile e pure arrogante. Voto: 3
•
MSU lossless: Veniva annunciato come il miglior codec lossless nei risultati dei test di
confronto fatti dallo stesso team scientifico russo che l'ha sviluppato. In effetti MSU è il
codec che riesce a comprimere con un'efficienza migliore di tutti gli altri in tutti gli spazi
colore e questo conferma quanto pubblicato sul sito. Però le loro analisi non prendevano in
considerazione il fattore velocità, che infatti risulta un grosso tallone d'Achille di questo
codec (è lentissimo). Se il tempo non è un problema e si ha una macchina potente, è la scelta
obbligata. Altrimenti, mentre codifica un film di 2 ore si può tranquillamente andare fuori al
ristorante nel frattempo. Voto: 8
•
Picvideo: E' molto veloce ma comprime poco e funziona solo in RGB. Nel complesso:
giugno 2006
COMPARAZIONE
97
scarso. Voto: 5
E' difficile determinare quale sia in assoluto il codec più veloce o quello con migliore
compressione, perché come abbiamo visto non tutti i codec supportano tutti gli spazi colore.
Dividendo in categorie si ha:
Spazio colore
Miglior velocità
Miglior compressione
Miglior bilanciamento
RGB
Alpary
MSU
Lagarith
YUY2
Huffyuv / Lagarith
MSU
Lagarith
YV12
Alpary
MSU
Ffv1
La mia conclusione finale è che il codec lossless migliore risulta essere:
Lagarith
98
COMPARAZIONE
giugno 2006
5.3 Codec LOSSY
Codec analizzati:
MPEG-4 AVC:
MPEG-4 ASP:
non-MPEG-4:
Mainconcept/Elecard
3ivx
FLV1
Mpegable
DivX
Indeo 5.11
Nero AVC
Fdd_H.264
MPEG-2 (come
Quicktime 7
HDX4
Sorenson
XviD
referenza)
Real Video 10
Theora
VSS H.264
VP7
x.264
Windows Media
Video 9 (Wmv9)
MPEG-4 AVC: codec conforme alle specifiche MPEG-4 part 10
MPEG-4 ASP: codec conforme alle specifiche MPEG-4 part 2
non-MPEG-4: codec non conforme alle specifiche MPEG-4
MPEG-4 AVC
Mainconcept H.264/AVC v2 / Elecard
E' un programma standalone molto completo. Il codec è sviluppato da una collaborazione tra
Elecard e Mainconcept e deve essere usato all'interno dell'applicazione apposita. Mainconcept è
giugno 2006
COMPARAZIONE
99
stata leader nei codec MPEG-2 e rappresenta sicuramente un punto di riferimento nel mercato
professionale. Supporta 1pass (CBR/VBR/fixed Quants), P-Frame Reorder, CABAC, Loop,
Multiple B-Vops, Multiple Ref, 4x4 P-Frame Sizes, PAR, RDO
Mpegable
Sviluppato dalla DIGAS, è stato utilizzato attraverso il software X4Live. supporta 1pass (fixed
quants) uses P-Frames only, 8x8 P-Frame Blocksizes, CAVLC only, Loop. Non consente la
modalità 2-pass
Nero AVC
Co-sviluppato da Nero AG e Ateme, include un encoder e un decoder. L'encoding va fatto tramite il
software apposito. Supporta 2pass, CABAC, (adaptive) Loop, multiple B-Frames, mulitple
Reference Frames, weighted prediction, 8x8 P-Frame Blocksizes, 16x16 B-Frame Blocksizes,
Adaptive Quant.
Quicktime 7.1
Il celebre pacchetto Apple per l'audio/video. Leader nella creazione di multimedia nel mondo
Macintosh, è disponibile anche per piattaforma Windows. Supporta 2pass, max 1 B-frame, Loop
(0,0), P8x8,B8x8,I4x4, Adapt. Quant, 5 Slices, no CABAC, no Weighted Pred., no multi Ref.
Sorenson AVC Pro
Utilizzato attraverso il software Sqeeze 4.3. Non ho dettagli tecnici.
Vss H.264 v2.3
Sviluppato dalla Vsofts, è utilizzabile in VirtualDub.
x264 v352 (12/06/2006)
Si tratta del nuovo video codec opensource, che dopo mesi di gavetta arriva finalmente a produrre
100
COMPARAZIONE
giugno 2006
delle versioni sempre più stabili, sebbene ancora nuove versioni vengano rilasciate con cadenza
quasi settimanale. Il nuovo codec rappresenta una validissima alternativa ad i codec attuali sia per
prestazioni che per qualità, ed è sicuramente una delle più importanti promesse che appare oggi
sullo scenario del digitale. E' l'unica implementazione opensource e free-software dello standard
H.264/AVC. Supporta 2-pass, CABAC, Loop, multiple B-Frames, B-References, multiple
Reference Frames, 4x4 P-Frame, 8x8 B-Frame Blocksizes, segnale anamorfico e High Profile: 8x8
dct e intra prediction, matrici di quantizzazione lossless e custom.
MPEG-4 ASP
3ivx 4.5.1
Nella sua semplicità (manca compressione con B-frames, rate distortion, ecc..) rappresenta un po' i
codec del passato, per intendersi Divx 3, 4, le prime versioni di XviD o al massimo le prime
versioni del codec DivX 5. Impostazioni: default + MPEG Quantizer (ASP) + Adaptive
Quantization.
DivX v6.2.5 (15/06/2006)
E' sicuramente il codec più popolare ma forse non è il più performante. E' stato sottoposto a molti
test dalle comunità di sviluppo del video digitale e le sue prestazioni sono risultate abbastanza
deludenti rispetto agli avversari. Però è facile da usare e per ragioni storiche e commerciali è
sicuramente il più conpatibile, e questo è un punto molto grosso a suo favore. Non è un codec
H.264. Impostazioni: default + Quantization: H.263 optimized.
Fdd_H.264 (ovvero l'H.264 di libavcodec)
Compare nella lista dei codec disponibili quando si installano le librerie libavcodec. Libavcodec fa
parte del pacchetto ffdshow, che contiene tutti i codificatori e decodificatori audio/video di Ffmpeg
(DirectShow e VFW). FFmpeg è una collezione di free-software che raccoglie al suo interno molti
dei progetti opensource legati alla codifica audio/video. Il progetto è partito da Gerard Lantau, un
alter-ego di Fabrice Bellard ma è attualmente gestito da Michael Niedermayer. Molti sviluppatori di
Ffmpeg fanno parte di altri progetti quali Mplayer, xine e VideoLan. Output: RGB24. Non permette
la modalità 2-pass.
giugno 2006
COMPARAZIONE
101
HDX4 1.5.4.419 (19/04/2006)
E' stato ufficialmente rilasciato nel 2005 da Jomigo Visual Technology GmbH, Germany. Sul sito
ufficiale si presenta come il codec H.264 più veloce sul mercato e i primi test effettuati
effettivamente confermano questa ipotesi.
XviD v1.1.0 (30/12/2005)
Il codec più popolare nel mondo opensource. L'installazione fornisce numerosi tools per l'analisi, la
gestione e il debugging del codec. Ho usato la build compilata per windows 32-bit da Koepi, che è
una delle migliori. Si attende con ansia il rilascio della versione AVC, che è ancora in versione beta
ma non è disponibile al pubblico.
non-MPEG-4
FLV1 (libavcodec)
Un altro dei codec video di libavcodec. Non si sa molto sulla sua provenienza ma è abbastanza
performante.
Indeo 5.11
Originariamente sviluppato da Intel e poi passato nelle mani della società Ligos, è stato usato per
molti anni per la codifica lossy . E' stato scelto perchè rappresenta uno dei codec più usati della
vecchia generazione. Non permette la modalità 2-pass
Mianconcept MPEG-2 v1.5 (2005)
L'implementazione MPEG-2 di Mainconcept è universalmente riconosciuta come la migliore sul
mercato, pertanto è stata utilizzata come referenza per il confronto con il "vecchio" codec MPEG-2.
RealVideo 10
E' il celebre codec maggiormente usato negli ultimi anni per lo streaming su Internet e infatti viene
102
COMPARAZIONE
giugno 2006
utilizzato con un software prettamente orientato al broadcasting e allo streaming.
Theora 1.0 alpha6 (30/05/2006)
Si tratta di un altro interessante codec non-MPEG-4 freeware facente parte di ffdshow. Sviluppato
dalla fondazione Xiph.org come parte del loro progetto Ogg (un progetto che mira ad integrare il
codec video VP3, il codec audio Vorbis e il container Ogg per competere con MPEG-4). Theora è
derivato direttamente dal codec VP3 di On2 (società che poi ha continuato il suo sviluppo fino ad
ottenere l'attuale VP7), attualmente i due sono praticamente identici ma lo sviluppo è ancora in
corso.
VP7
True Motion VP7 (VP70) è sviluppato da On2 Technologies come successore dei codec VP3, VP5
e TrueMotion VP6. Ha il supporto sia VFW che DirectShow e sembra abbia la migliore
compressione nella famiglia di codec MPEG-4 e H.264.
Windows Media Video 9 (Wmv9)
Windows Media Video è il nome generico per una serie di tecnologie proprietarie sviluppate da
Microsoft per lo streaming di file video. Fa parte della piattaforma Windows Media. A partire dalla
versione 7 (WMV1), Microsoft ha usato una sua versione modificata dello standard MPEG-4. Lo
stream video è spesso abbinato a quello audio di Windows Media Audio. Microsoft ha sottoposto
alla Society of Motion Picture and Television Engineers (SMPTE) lo standard VC-1 per
l'approvazione come standard internazionale e poco tempo fa è stato approvato, diventando quindi
ufficialmente il maggior rivale di MPEG-4. Windows Media Video 9 è una implementazione di
questo standard, ma probabilmente presto ne nasceranno altre. Questo codec è usato anche per la
diffusione della televisione ad alta definizione su DVD in un formato che Microsoft commercializza
col marchio WMV HD. Questo formato può essere riprodotto anche su computer o lettori DVD
compatibili.
giugno 2006
COMPARAZIONE
103
Prezzi e containers dei codec
104
CODEC
PREZZO
CONTAINER
3vix
Free
AVI
DivX
19.99 $
AVI
flv1
free
AVI
Fdd_H.264
free
AVI
HDX4
39.90 $
AVI, MP4, 3GP
Indeo 5.11
free
AVI
Mainconcept
499 $
MPG, 264
Mpegable
?$
MP4
Mpeg-2
149 $
MPG
Nero
29,99 $
MP4
Quicktime
29,99 $
MP4, 3GP, MOV
Real
Basic: free, Pro: 199,95 $
RM, RMVB
Sorenson
399 $
MP4
theora
Free
AVI
VP7
Free
AVI
VSS
99 $
AVI
wmv9
free
WMV
x264
Free & Opensource
AVI, MP4, RAW
XviD
Free & Opensource
AVI
COMPARAZIONE
giugno 2006
TEST
(Giugno 2006)
tester:
SIMONE CHIESA
LOSSY
NOTA per il decoding:
Per il decoding non sono stati usati filtri di postprocessing particolari. Ove possibile è stato usato
ffdshow, per gli altri è stato usato il decoder fornito dal produttore.
Per garantire lo stesso tipo di input nei software di analisi ho utilizzato il seguente script AVISynth
per il frameserving:
a=DirectShowSource(clip clip).ConvertToRGB24.Trim(8,240)
DirectShowSource(): permette di passare come input files in formato AVI, MPG, MP4, ecc.
ConvertToRGB24: garantisce che entrambi i filmati siano in RGB a 24 bit. Trim(): seleziona i
frames da analizzare: è stato necessario eliminare qualche frame all'inizio e alla fine dei filmati in
quanto a volte si creavano valori sballati a causa dell'eliminazione o duplicazione di frames.
VIDEO 1
sorgente originale: src13_ref__525.yuv
Video:
luna_park.avi
Colore:
RGB 24-bit
frames:
260 (8,67 secondi)
risoluzione
720 x 576
sistema
NTSC
dimensione:
308 MB
giugno 2006
29,97 fps
COMPARAZIONE
105
Questa sequenza video è una breve ripresa ambientata in un luna park. E' caratterizzata da molti
dettagli e molti colori diversi e da un buon dinamismo dei soggetti. C'è un unico taglio al frame 135
in cui si passa da un piano largo a una mezza figura in cui un papà tiene in braccio un bambino
mentre tutto intorno sventolano bandierine e scoppiano palloncini. La codifica in NTSC sembra
abbia creato qualche problema nella sincronia durante il confronto.
VIDEO 2
sorgente originale: src5_ref__625.yuv
Video:
canoa.avi
Colore:
RGB 24-bit
frames:
220 (8,80 secondi)
risoluzione
400 x 320
sistema
PAL
dimensione:
80,5 MB
25 fps
Questo breve filmato mostra un canottiere che risale per qualche metro un fiume, si gira, torna
indietro e saluta il pubblico mentre sullo sfondo si vedono altre canoe. E' un soggetto che rimane
fisso al centro dello schermo mentre l'acqua e lo sfondo “scorrono” con molti dettagli in
movimento. Non ci sono stacchi. Ho ridotto la risoluzione a 400 x 320 pixel così da testare il
comportamento dei codec a risoluzioni inferiori.
Facciamo una prima analisi sulla velocità dei codec e sulla correttezza e la qualità del file di output.
Impostiamo ogni codec alla massima velocità possibile per una codifica 1-pass:
video1: a bitrate costante di 5000 Kbps il file di output corretto dovrebbe essere di:
5000 Kbit/sec x 8,67 sec = 43.350 Kbit = 5.418,75 KB
CODEC
SEC
Kbps
SCARTO (%)
KB
SCARTO (%)
PSNR
3vix
8
4796
4,25
5.278
2,67
37,6219
DivX
7
5044 [2]
0,87
5.244
3,33
37,6569
106
COMPARAZIONE
giugno 2006
CODEC
SEC
Kbps
SCARTO (%)
KB
SCARTO (%)
PSNR
flv1
8
5031
0,62
5.536
2,12
38,2180
Fdd_H.264
29
4887
2,31
5.378
0,76
38,2180
HDX4
8
5048
0,95
5.554
2,44
37,8299
Indeo 5.11
53
4884
2,38
5.374
0,83
35,4350
Mainconcept
32
4990
0,20
5.363
1,04
errore
Mpegable
20
4713
6,09
5.115
5,94
errore
Mpeg-2
8
4970
0,60
5.351
1,27
33,9742
Nero
45
5012
0,24
5.278
2,67
errore
Quicktime
73
5075
1,48
5.390
0,53
errore
Real
48
5137
2,67
5.474
1,01
38,8809
Sorenson
80
5223
4,27
5.589
3,05
errore
theora
19
5062 [3]
1,22
5.570
2,72
38,0651
VP7
9
5012 [4]
0,24
5.515
1,75
38,8835 [1]
VSS
29
5028
0,56
5.532
2,05
38,5731
wmv9
86
5120
2,34
5.513
1,71
35,0351
x264
32
4955
0,91
5.452
0,61
39,3433
XviD
15
4962 [5]
0,77
5.460
0,76
38,8270
[1] misurazione diretta (errore in AVISynth)
[2] Nella configurazione del codec ho settato 3500 Kbps. Impostando il bitrate a 5000 Kbps si ottiene in realtà un file
di 9.243 KB con bitrate di 8405 Kbps
[3] Nella configurazione del codec ho settato 6700 KBPS. Impostando il bitrate a 5000 Kbps si ottiene in realtà un file
video2: a bitrate costante di 4000 Kbps il file di output corretto dovrebbe essere di:
4000 Kbit/sec x 8,80 sec = 35.200 Kbit = 4.400 KB
CODEC
SEC
Kbps
SCARTO (%)
KB
SCARTO (%)
PSNR
3vix
4
4006[1]
0,15
4410
0,23
35,4688
DivX
2
4077 [2]
1,89
4489
1,98
35,9435
flv1
2
4041
1,01
4449
1,10
38,3994
giugno 2006
COMPARAZIONE
107
CODEC
SEC
Kbps
SCARTO (%)
KB
SCARTO (%)
PSNR
Fdd_H.264
9
4000
0,00
4404
0,09
36,5352
HDX4
2
3953
1,19
4352
1,10
35,9460
Indeo 5.11
20
4020
0,50
4426
0,59
35,8113
Mainconcept
16
3978
0,55
4365
0,80
-
Mpegable
2
3810
4,99
4096
7,42
-
Nero
7
3690
8,40
3997
10,08
-
Quicktime
20
4062
1,53
4410
0,23
-
Real
12
3979
0,53
4289
2,59
40,4095
Sorenson
15
4165
3,96
4475
1,68
-
theora
22
4008 [3]
0,20
4413
0,29
38,5570
VP7
6
4036 [4]
0,89
4443
0,97
39,2690
VSS
9
3916
2,15
4311
2,06
39,6566
wmv9
24
4131
3,17
4529
2,85
39,8369
x264
9
3952
1,21
4351
1,13
40,4707
XviD
2
4097
2,37
4510
2,44
39,6461
[1] Nei settaggi ho dovuto mettere 1800 Kbps
I valori evidenziati in rosso erano così sballati che per un corretto confronto di PSNR ho dovuto
cambiare le impostazioni nei settaggi degli encoder. DivX e 3ivx producevano file
sovradimensionati a tal punto che ho dovuto abbassare il settaggio a 3500 Kbps e 1800 Kbps per
ottenere file con bitrate e filesize corretti. Al contrario Theora, VP7 e XviD producevano file molto
sottodimensionati e ho dovuto alzare i bitrate. Tutti questi verranno quindi squalificati nei grafici
seguenti, che mostrano i margini di errore di bitrate e dimensioni dei file di output:
108
COMPARAZIONE
giugno 2006
VIDEO 1
VIDEO 2
giugno 2006
COMPARAZIONE
109
Escludendo i codec squalificati, per quanto riguarda l'accuratezza del bitrate a 1-pass, il codec più
affidabile è Mainconcept, ma anche altri riescono a stare sotto il margine d'errore dell'1%. Il codec
che invece restituisce un file dalle dimensioni più corrette è Quicktime. Nel confronto, il codec che
ha meno margini di errore e che quindi si può considerare più corretto e affidabile, è Mainconcept.
Vediamo ora le velocità:
VIDEO 1 (720 x 576)
VIDEO 2 (400 x 320)
110
COMPARAZIONE
giugno 2006
Per la velocità vincono a pari merito DivX, HDX4 e Flv1, ma ottimi anche 3ivx, HDX4, MPEG-2
e x.264. Nero, Real e theora sono piuttosto lenti. Quicktime ancora peggio, molto deludente. Wmv9
e Sorenson sono i più lenti. Passiamo alla qualità:
VIDEO 1
VIDEO 2
giugno 2006
COMPARAZIONE
111
In una prima analisi della qualità oggettiva sembra prevalere x.264 seguito da Real 10. Bene VP7,
VSS e XviD. Su Wmv9 ho dei dubbi che il PSNR in video 1 abbia funzionato bene, ho ripetuto
numerose volte il test, ma sempre con lo stesso risultato. Si nota invece il grande distacco con
Indeo5 e MPEG-2, come era lecito aspettarsi. Nei prossimi test terrò solo mpeg2 come codec di
riferimento col passato (e solo per il video 1, perché a 400 x 320 non ha senso) poiché Indeo5 è
ormai obsoleto e non si utilizza più, mentre MPEG-2 invece è ancora lo standard più usato per il
buone e alte risoluzioni.
Mainconcept, Mpegable, Nero, Quicktime e Sorenson hanno prodotto errori nella misurazione del
PSNR che evidentemente ha problemi nel misurare gli mp4. Per questi codec userò una misurazione
soggettiva, confrontandoli con il vincitore del PSNR: Tutti gli altri si aggirano intorno al valore 38,
un valore molto buono. E' molto difficile valutare soggettivamente in questo caso perché la qualità è
alta per tutti e ad occhio nudo non si scorgono differenze significative. Andiamo a vedere un
ingrandimento del 90%:
112
Originale
Wmv9
x.264
Mainconcept
Mpegable
Nero
Quicktime
Sorenson
COMPARAZIONE
giugno 2006
Da una valutazione soggettiva la conferma di x.264 è netta. Mainconcept se la cava comunque bene.
Vediamo ora di analizzare i codec impostandoli per la massima qualità possibile
VIDEO 1
CBR 1-PASS
400 Kbits
CODEC
KB
CODEC
KB
CODEC
KB
3vix
2.106
Mpegable
440
theora
1.430
DivX
1.492
Mpeg-2
527
VP7
1.306
flv1
1.274
Nero
531
VSS
1.118
Ffd_H.264
680
Quicktime
1.074
wmv9
641
HDX4
2.090
Real
1.559
x264
524
Mainconcept
1.015
Sorenson
1.688
XviD
1.076
Dalla tabella è chiaro come a bitrate così bassi e a risoluzione così elevata (720 x 576) i codec si
comportano in modo strano. La grande differenza in KB tra un video e l'altro la dice lunga. Molti
codec non riescono ad ottenere il bitrate ricercato: si va dai 2708 kbps di Ffd_H.264 ai 469 kbps di
x.264. Le analisi effettuate non sono quindi valide e vengono riportate solo a fini informativi.
giugno 2006
COMPARAZIONE
113
1000 Kbits
Come nel test precedente, utilizzando la funzione 1-pass molti codec non riescono a raggiungere il
bitrate richiesto. I risultati non sono validi. Vengono riportati comunque i grafici della qualità.
Gli unici codec che hanno rispettato il bitrate richiesto sono: Mainconcept, MPEG-2, Mpegable,
Nero, Quicktime e x.264. Tra questi, la mia analisi soggettiva li premia nel seguente ordine:
x.264: 5
Mainconcept: 4
Quicktime: 3
Nero: 3
Mpegable: 2
MPEG-2: 0
2000 Kbits
Vince di un soffio Real 10, seguito con un lievissimo distacco da x.264. Fdd_H.264 e 3ivx vengono
squalificati in quanto ancora una volta restituiscono un file con un bitrate a 2700 kbps invece che
2000. Nei 2 grafici seguenti si vedono le curve del PSNR in dettaglio: ho diviso in 2 grafici per una
maggiore chiarezza, prendendo DivX come codec di riferimento. Si nota come tutti i codec abbiano
114
COMPARAZIONE
giugno 2006
più problemi nella seconda parte del video, quando si taglia sulla mezza figura.
blu: DivX
viola: MPEG-2
rosso: flv1
verde: HDX4
arancione: Wmv9 salmone: VSS
blu: DivX
rosso: Real
verde: theora
viola: VP7 arancione: x.264 salmone: XviD
Il SSIM e il VQM confermano i risultati del PSNR:
VBR - 2PASS
Nota: Non tutti i codec permettono la modalità 2-pass. Ove non possibile verrà utilizzata la
modalità 1-pass.
600 Kbps
Anche con 2 passate molti codec a 600kbps e risoluzione 720 x 576 non riescono a lavorare
giugno 2006
COMPARAZIONE
115
correttamente. Tralasciamo quindi i risultati.
1000 Kbps
Dal grafico sembrerebbe vincere VP7 seguito da theora. Questi due codec però hanno restituito un
file con bitrate troppo alto (1330 e 1770 rispettivamente) pertanto la mia scelta come vincitore è
invece x.264 che supera i 32,5 con un bitrate di soli 1080kbps. Confrontiamolo attraverso una
valutazione soggettiva con gli altri codec mp4 che non sono potuti entrare nel grafico:
x264: 4
quicktime: 3
nero: 3
mainconcept: 3
mpegable e sorenson: errori rispettivamente nella decodifica e nel file-size
2000 Kbps
Questa volta VP7 centra perfettamente il bitrate e vince, ma x264 gli è molto vicino. Contando che
x264 ha prodotto un file con 100 kbps meno del rivale, potremmo dire che in questo caso ci sia un
116
COMPARAZIONE
giugno 2006
pareggio.
Ecco le curve del PSNR:
blu: DivX
rosso: 3ivx verde: flv1
viola: HDX4
arancione: real
salmone: theora
blu: DivX
rosso: VP7
viola: Wmv9 arancione: x.264
verde: VSS
salmone: XviD
I grafici di SSIM e VQM:
giugno 2006
COMPARAZIONE
117
Confrontiamo i vincitori con gli altri codec con una valutazione soggettiva:
x264: 5+
VP7: 5
Mainconcept: 5
nero: 4
Quicktime: 4
sorenson: 4
mpegable: 3
4000 Kbps
E' netta la vittoria di VP7, come sempre seguita da x.264 e da Real. Vediamo ricomparire
fdd_h.264 che finalmente riesce a dare in output un file con un bitrate corretto, ma le prestazioni
sono piuttosto scarse. Notiamo come ci sia ancora un grande distacco con MPEG-2 nonostante il
bitrate a 4000 kbps sia più consono alle sue frequenze di lavoro standard (che si aggirano attorno ai
7000 kbps nei DVD), a testimoniare che i nuovi codec H.264 sono sicuramente la scelta migliore
118
COMPARAZIONE
giugno 2006
anche per i nuovi standard internazionali e per i nuovi supporti ottici.
VIDEO 2
Per il video 2 riassumo in un grafico i risultati dei PSNR ai diversi bitrate:
Dal grafico e dal confronto soggettivo con gli altri codec non misurabili oggettivamente, VP7 si
conferma come il codec con la migliore qualità visiva. Stavolta x.264 va molto male, mentre
guadagna il secondo posto Real Video seguito da Wmv9. Ma bene anche Xvid, Quicktime,
Mainconcept e Nero.
VIDEO 3
Rugby.avi
Questo video ha le stesse caratteristiche del video 2, tranne che per la risoluzione di 600 x 480.
Vince di nuovo x.264 e ancora bene Wmv9
giugno 2006
COMPARAZIONE
119
Valutazione Soggettiva
Riporto di seguito 2 tabelle con 2 livelli di dettaglio delle immagini prese dal video 1. La prima
riporta un confronto su uno zoom del 60% del frame 146, la seconda su uno zoom all'80% del frame
152. La prova visiva conferma quanto ipotizzato attraverso le misurazioni oggettive e soggettive.
X264 e VP7 sono sicuramente i codec che riproducono un'immagine più simile all'originale,
mantenendo i dettagli (si osservino i coriandoli sul viso del bambino) e la nitidezza delle linee.
Originale
Originale
Pag. 121: 2-pass VBR 2000 Kbps – dettaglio zoom 60%
Pag. 122: 2-pass VBR 2000 Kbps – dettaglio zoom 80%
120
COMPARAZIONE
giugno 2006
Mainconcept
3ivx
DivX
flv1
Quicktime
Real
HDX4
Nero
theora
VP7
VSS
Wmv9
x264
XviD
Sorenson
giugno 2006
COMPARAZIONE
121
122
Mainconcept
3ivx
DivX
flv1
Quicktime
Real
hdx4
nero
theora
VP7
vssh
Wmv9
x264
XviD
sorenson
COMPARAZIONE
giugno 2006
CONCLUSIONI FINALI
E' difficile trarre delle conclusioni assolute in quanto come abbiamo visto i codec hanno
caratteristiche diverse tra di loro e le loro prestazioni variano a seconda del video e della
risoluzione. Una cosa abbastanza certa è che se un codec ha delle buone prestazioni per un certo
bitrate, ce le avrà anche per tutti i bitrate; se invece va male andrà male in tutti i bitrate. Questo mi
porta a dire che per testare i codec sarebbe più opportuno fare molti test su molti video diversi tra
loro ma a pochi bitrate precisi. Nel trarre le mie conclusioni mi baserò anche sui risultati,
sicuramente più autorevoli dei miei, di alcune comunità scientifiche riconosciute a livello mondiale.
Una di queste è il CS MSU Graphics&Media Lab Video Group, che ha effettuato recentemente dei
test su alcuni dei codec che ho preso in analisi (con più di 3000 grafici e numerosissimi test su tutti i
bitrate).
Prima di tutto vorrei dare un giudizio sull'usabilità dei codec. Ho avuto davvero parecchi problemi
per capire come alcuni di questi andassero usati correttamente. Sebbene i codec VFW (Video For
Windows) siano ancorati ad AVI e non sfruttino le potenzialità dei nuovi container, sono ancora
quelli che garantiscono maggior compatibilità. A parte i software di misurazione oggettiva, che in
teoria, senza frameserving, accetterebbero solo AVI in input, c'è tutta una serie di applicazioni per
l'editing e la visione degli AVI che è sicuramente più vasta e inter-compatibile rispetto ad mp4. Ho
avuto problemi nel demux e nel visualizzare correttamente molti dei codec AVC che ho testato.
Mpegable risulta leggibile correttamente quasi solo all'interno del suo player e questo lo penalizza
molto, dà parecchi problemi per la decodifica. Stessa cosa vale per mainconcept H.264 e per
Sorenson, anch'essi con alcune difficoltà nella lettura con i player più diffusi. Nero è risultato
invece abbastanza versatile, e anche Quicktime e Real Video non hanno avuto particolari problemi.
Wmv9 è stato problematico in quanto l'applicazione Windows Media Encoder non accettava i video
di test in ingresso, quindi ho dovuto usare il programma di Sorenson, X4Live, per utilizzarlo.
Wmv9 Advanced Profile (VC-1) era già disponibile per i primi test al momento della
pubblicazione di questo documento, ma dopo alcune prove di utilizzo con un software apposito (in
versione alpha) ho deciso che non era ancora maturo per partecipare al confronto.
In definitiva, tra i codec AVC più versatili c'è sicuramente x.264: permette il settaggio manuale di
molti parametri, può scegliere vari formati di output ed essendo ancora in via di sviluppo potrà solo
migliorare le sue funzionalità. Il più maneggevole e facile da usare è sicuramente Nero Digital, che
fornisce un'ottima piattaforma click'n go (io ho utilizzato Nero Recode) stand-alone e senza bisogno
giugno 2006
COMPARAZIONE
123
di nessuna configurazione o conoscenza particolare. I codec più veloci sono DivX e HDX4 ma tra i
due è preferibile il primo perché alla stessa velocità si ottiene maggior qualità dell'immagine. I
codec con migliore qualità visiva mi sono sembrati x.264 e VP7 ma qui l'incertezza è molta
considerato che la qualità varia a seconda del filmato. Altri miei colleghi autorevoli sono comunque
d'accordo e ritengono questi due codec tra i migliori. x.264 è un codec H.264/AVC di ultimissima
generazione, tuttora in sviluppo con release quasi settimanali, è gratuito e opensource e questo è un
grosso punto a suo favore. VP7 non è AVC ma si è rivelato un'alternativa molto valida all'MPEG-4
ed è gratuito. Quicktime 7 è il codec di Mac OSX, dell'I-pod, di tutto ciò che circonda il mondo
Apple. Molti utenti Macintosh conoscono solo questo codec e si trovano comunque bene.
Sicuramente non è male, ma c'è di meglio in giro. Soprattutto la pecca di Quicktime è la lentezza: è
davvero esasperante aspettare un minuto quando altri codec impiegano pochi secondi per fare la
stessa cosa. Ma Microsoft riesce a fare ancora peggio, ottenendo con Wmv9 prestazioni velocistche
scandalose. Visivamente il codec di casa Redmond è molto valido alle basse risoluzioni, ma ciò non
ne giustifica l'utilizzo se paragonato ad alternative gratuite e più performanti. Real Video 10 è una
di queste, con un ottimo livello qualitativo dell'immagine ma il fatto che utilizzi container e
standard proprietari secondo me ne limita la diffusione tra la massa. Sorenson AVC Pro è un codec
AVC senza grandi pretese ma con un software di utilizzo intuitivo e funzionale. Certo secondo me
non vale i 399 $ della licenza, veramente un po' fuori luogo per le prestazioni mediocri che ha avuto
nei test. E' lento e tende a “spalmare” l'immagine eliminando molti dettagli. VSS sta un po' nel
mezzo, è sicuramente un buon codec AVC ma considerando che nemmeno lui è gratuito forse non
vale la pena. 3ivx è un po' vecchio ma dice ancora la sua se comparato con i nuovi codec. Ormai
comunque sarebbe il caso di metterlo da parte. I codec di ffdshow Flv1 e ffd_H.264 mi hanno
lasciato un po' perplesso, sono indubbiamente validi ma hanno poca, come dire, “personalità”.
Theora è interessante ma non da molta sicurezza per il futuro, come compare nel messaggio bene
in vista sull'interfaccia “Usare solo per scopi sperimentali, il codec potrebbe diventare incompatibile
in futuro”. La battaglia tra DivX e Xvid secondo me si chiude in un sostanziale pareggio. I due
codec si comportano in modo simile e insistere sul confronto tra questi due, come avviene ormai da
molti mesi su Internet, mi sembra inutile. Certo, conoscendo la storia di entrambi (XviD è nato da
una "costola" di DivX) è normale che nasca rivalità, ma il confronto confluisce spesso nella
consueta guerra di religione tra Closed-source e Open-source. DivX 6.5 sembra apportare dei
miglioramenti significativi rispetto alle versioni passate, e lo riporta a gradini un po' più dignitosi
rispetto ai test dei mesi scorsi. E' comunque ancora un buon punto di riferimento per i codec nonAVC. XviD, prima dell'avvento del recentissimo x264, era il miglior codec video opensource
disponibile. E' molto simile a DivX nelle prestazioni, quindi in generale buono, ma visivamente non
124
COMPARAZIONE
giugno 2006
all'altezza dei codec H.264. Aspettiamo la prossima release di XviD AVC e vedremo come andrà il
confronto con il suo nuovo rivale x264. Nel frattempo possiamo concludere che tra DivX e XviD è
sicuramente preferibile il secondo, considerato che è gratuito e opensource, mentre la licenza di
DivX è a pagamento.
Personalmente, e tenendo conto di tutto, posso conferire il titolo di miglior codec lossy a:
x.264
giugno 2006
COMPARAZIONE
125
APPENDICE
LA STORIA DI DIVX
Nel 1997, la Microsoft inizia a sviluppare un innovativo sistema di compressione video. Il suo
obiettivo è creare un file video di ottima qualità e di ridotte dimensioni, da destinare allo streaming
e alla diffusione nella rete. Tuttavia, la ristretta banda delle connessioni Internet e l'impossibilità di
sfruttare il già creato formato Mpeg, si schierano come un ostacolo insormontabile. Dopo circa un
anno, gli sviluppatori dell'azienda di Seattle realizzano il sistema di compressione Div (Digital
Internet Video) che fu chiamato MPEG-4 (codename Windows Media Video V3) e scherzosamente
definito l'Mp3 del video. Fu deciso di associare a questo tipo di file l'estensione ASF (Advanced
Streaming Format) e, di conseguenza, nel codec fu integrata la funzione AVI Lock, in modo da
impedire la creazione di file video AVI. Nonostante gli sforzi dei programmatori, i risultati furono,
però, pessimi: l'immagine, in particolare nelle scene molto movimentate, tendeva a rovinarsi in
modo ben visibile. Dunque, il progetto fu abbandonato (verrà ripreso per creare il formato WMV).
Nasce il DivX
Nel 1998, un hacker francese di nome Jerome Rota (allora conosciuto in rete come Gej), deluso dal
formato ASF e interessato all'idea di creare un formato video adatto alla diffusione in rete, decide di
estrarre il codice sorgente dal codec. Nell'estate del 1999, grazie all'aiuto dell'hacker tedesco Max
Morice, ci riesce e viene a conoscenza dell'algoritmo di compressione che è il cuore dell'Mpeg-4.
Come prima modifica, annullano il sistema AVI Lock, permettendo, così, la realizzazione di file
AVI in formato Mpeg-4. Successivamente, integrano un sistema per riprodurre l'audio nel formato
Mp3: una modifica che, nella sua semplicità, permette di ridurre ulteriormente le dimensioni finali
del file video. Jerome decide di chiamare il codec DivX ;-) (includendo nel nome una emoticon
sorridente, con riferimento sarcastico al fallimento del Div di Microsoft).
DivX ;-) 3.11 alpha
Nell'ottobre del 1999, dal sito http://divx.ctw.cc il codec prodotto da Jerome inizia a circolare nella
rete come DivX ;-) release 3.11 alpha. Fornito di un'interfaccia che viene richiamata nell'ambito
della creazione di un file DivX, il codec presenta due impostazioni principali: una definita Low
126
COMPARAZIONE
giugno 2006
Motion e una definita Fast Motion, la prima destinata all'elaborazione di filmati con molte scene
statiche, la seconda, invece, di filmati con molte scene d'azione e dinamiche. Permette di impostare
key frame e il bitrate per definire la compressione del video. L'unico difetto di questa versione è
l'impossibilità di gestire il flusso audio nel formato WMA. Jerome, infatti, nomina la sua versione
alpha perché, ancora, non è riuscito a crackare il codice del codec Mpeg-4 predisposto alla gestione
del WMA e del decoder Direct Show.
Il progetto Mayo
Il codec DivX ;-) 3.11 alpha si dimostra essere una vera rivoluzione nel campo della creazione di
file video con immagini di alta definizione e di ridotte dimensioni in Megabyte. Con il successivo
avvento dei programmi di decriptazione dei DVD (il DeCSS) e di software freeware per generare
file video, il DivX diventa il punto di riferimento per tutti coloro che vogliono copiare film DVD
sui più diffusi ed economici CD-Rom. Dato l'enorme successo, Jerome decide di sviluppare il DivX
a un livello più professionale e, soprattutto, legale, in quanto prodotto da una copia rubata del
Mpeg-4 di proprietà Microsoft. Quindi, assieme a Joe Bezdek e Eldon Hylton, fonda la Project
Mayo, con lo scopo di realizzare una versione ufficiale ed evoluta del DivX. Nel 2000, Jerome e i
suoi colleghi iniziano lo sviluppo del DivX 4. Sfruttando le esperienze acquisite dal precedente
codec e rielaborando l'algoritmo di compressione video in modo da essere del tutto estraneo da
quello dell'Mpeg-4, vengono realizzate alcune versioni alpha che, purtroppo, risultano deludenti.
Nonostante la buona qualità, le prestazioni e la velocità di elaborazione sono nettamente inferiori al
DivX 3.
DivX 4.0
Il 18 Luglio 2001, la Project Mayo rilascia la prima beta ufficiale del DivX 4.0 (successivamente,
usciranno la beta 2 e la beta 3). Finalmente, tutti i problemi delle release precedenti sono stati
risolti. Il nuovo codec è velocissimo nell'elaborazione, restituisce una sorprendente qualità
dell'immagine ed è totalmente compatibile con tutte le versioni precedenti. L'ultima versione di
questa release sarà la 4.11 Final. Molte sono le funzionalità introdotte rispetto alla versione 3, in
particolare:
•
Codifica a 1 o a 2 passaggi: nella versione 3 era possibile la creazione di un file video ad un
unico passaggio. Adesso, è possibile creare un file video anche attraverso 2 passaggi, dove il
giugno 2006
COMPARAZIONE
127
primo ha il compito di analizzare il filmato per individuare le impostazioni migliori per
generare il DivX.
Datarate aumentato: adesso è possibile utilizzare un datarate fino a 6000 kbps.
•
DivX 5.0
Nel 2002 ormai il DivX si è imposto come scelta privilegiata per chi crea copie di DVD e diffonde
filmati nella rete. Jerome fonda la DivX Network Inc. Il suo intento è commercializzare il codec
DivX e tentare di introdurlo nell'ambito della produzione professionale. Il 3 Settembre rilascia il
nuovo codec DivX 5.0, disponibile in tre versioni per i sistemi operativi Windows, Linux e
Macintosh:
Bundle Edition: una versione gratuita contenente il codec per la sola riproduzione dei film in
•
DivX e un Player specifico.
•
Standard Edition: una versione a pagamento del codec per riprodurre e creare DivX.
•
Professional Edition: una versione a pagamento simile alla versione Standard che include il
software Dr. DivX, specifico per la creazione di film in formato DivX.
Le novità introdotte rispetto alla versione 4 sono tantissime, ma queste le più rilevanti:
•
One-pass VBR (Bitrate Variabile)
•
Encoding in più passi (multi-pass encoding)
•
Possibilità di selezionare il numero di key-frame
•
Inserimento key-frame Automatico
•
Rilevamento automatico della scena
•
5 livelli di qualità di compressione predefiniti
•
Possibilità di impostare il ridimensionamento del video (resizing)
•
Possibilità di tagliare parte del video (cropping)
128
COMPARAZIONE
giugno 2006
•
Risoluzione: qualsiasi intero multiplo di 4 fino a 1920x1088
•
Bitrate fino a 8000 Kbps
•
Compatibilità con il formato Mpeg-4
Rivoluzione: il DivX 6.0
Nel Novembre del 2004, la DivX Labs (una sezione della DivX Networks Inc. dedicata allo
sviluppo del codec) annuncia il rilascio di DivX Plasma Alpha. Si tratta del primo prototipo
dell'atteso DivX 6. Ma si dovrà aspettare l'estate del 2005 per l'uscita ufficiale della sesta release.
DivX 6 non è una semplice, nuova versione del codec. Si tratta di una vera e propria rivoluzione.
DivX 6, oltre ad una serie lunghissima di migliorie tecniche, supporta una serie di novità che lo
rendono il diretto concorrente del DVD. Adesso, infatti, può incorporare menu interattivi, capitoli,
sottotitoli, tracce audio e video indipendenti (per nuove lingue e nuovi contenuti video) e l'audio
fino a 6 canali (quindi dal Surround 5.1 al DTS).
DivX "alternativi"
La storia del DivX è un percorso molto travagliato: è nato come prodotto illegale da una versione
crackata dell'Mpeg-4 di Microsoft, quindi diventato un prodotto freeware e legale, infine sviluppato
come prodotto commerciale. Se ad un lato, l'essere diventato una soluzione a pagamento, gli ha
permesso di raggiungere elevati standard qualitativi e di integrare funzioni molto avanzate, dall'altro
lato ha, certamente, deluso tutta quella utenza che abbraccia la politica open source e del "software
libero". Per questo motivo, mentre la DivX Networks Inc. sviluppava il DivX come soluzione
avanzata commerciale, altri hanno utilizzato il codice nativo del "vecchio" DivX per creare delle
soluzioni alternative.
Kristal Studio e DivX 3.2
Verso la fine del 1999, un gruppo di appassionati di DivX fonda la Kristal Studio. Utilizzando il
codice del DivX ;-) 3.11 alpha, sviluppano un codec alternativo: eliminano l'elaborazione Fast
Motion (a favore di un miglioramento del Low Motion) e vi integrano la tecnologia VKI (acronimo
di Variable Keyframe Interval, inizialmente disponibile come patch da installare separatamente) che
inserisce automaticamente un keyframe ad ogni cambio di scena. Inizialmente, il nuovo codec viene
giugno 2006
COMPARAZIONE
129
distribuito come DivX ;-) 3.11 VKI. Successivamente, la Kristal Studio decide di cambiarne la
release in 3.2 (la cui versione definitiva sarà la 3.22).
OpenDivX
Nel Gennaio del 2001, la Project Mayo inizia a sviluppare il codec DivX Deux, allo scopo di creare
un codec DivX indipendente, legale ed evoluto. Quindi, propongono a tutti gli utenti un progetto
open source per avviare lo sviluppo dell'OpenDivX, il codice che sarà alla base del DivX Deux.
Come base di partenza, rielaborano il coder del MoMuSys (una versione open source del codec
Mpeg-4), mentre decidono di sviluppare da zero il decoder. Durante lo sviluppo, la Project Mayo
decide di disporre un'autorizzazione restrittiva al codice: solo i membri del DARC (DivX Advanced
Research Center) possono partecipare. Nel Giugno del 2001, improvvisamente, la Project Mayo
decide di chiudere il progetto OpenDivX scatenando il dissenso di tutti coloro che avevano
partecipato. La Project Mayo viene, quindi, accusata di aver sfruttato le idee dei partecipanti per
sviluppare il DivX 4.
XviD
Poco prima della chiusura del progetto OpenDivX, uno dei membri del DARC, un giovane
programmatore che si faceva chiamare Sparky, sviluppa la tecnologia encore2, destinata alla
codifica del flusso video. Chiuso il progetto OpenDivX, l'encore2 viene utilizzato nel codec DivX4.
Deluso e indignato, Sparky decide non solo di continuare lo sviluppo di encore2, ma di creare un
proprio progetto, chiamandolo XviD, il cui nome non è altro che DivX letto al contrario (una
evidente azione sarcastica). Nel Luglio del 2001, Sparky apre il sito www.xvid.org e ufficializza il
suo progetto open source. Le prime versioni hanno un buon successo ed integrano funzioni molto
avanzate come:
•
utilizzo di b-frame;
•
global and quarter pixel motion compensation;
•
lumi masking;
•
Trellis quantization;
130
COMPARAZIONE
giugno 2006
•
tecnologia H.263 e mpeg.
Tuttavia, alcune funzioni integrate risultano essere protette da licenza in alcuni paesi. Dunque,
Sparky compila subito la versione 1.0 e la pone sotto licenza GNU GPL v2. Oggi, il codec Xvid è
considerato il diretto e degno concorrente del DivX.
3ivX
Sviluppato dalla 3ivX Technologies, il codec 3ivX non deriva direttamente dal DivX, ma sfrutta la
parte di codice dell'Mpeg-4 preposta all'encoding che è stata alla base del DivX fino alla versione 5.
Per questo motivo, il codec 3ivX è in grado di riprodurre filmati creati con le versioni 3, 4 e 5 del
DivX e anche quelli creati con l'Xvid. Il codec 3ivX è particolarmente apprezzato nell'ambiente
Macintosh poiché è stato il primo codec basato sull'Mpeg-4 ad offrire, sin da subito, un totale
supporto al sistema operativo Mac OS.
giugno 2006
COMPARAZIONE
131
BIBLIOGRAFIA
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Wikipedia "The free Encyclopedia", www.wikipedia.org
MPEG, Movie Pictures Experts Group, www.chiariglione.org/mpeg/
International Telecommunication Union, www.itu.org
MPEG Industry Forum, www.m4if.org
"AVC+AAC: The Next Generation of Compression", Harmonic white paper,
www.harmonicinc.com
"The emerging H.264/AVC standard", EBU Tech. Rev, www.ebu.ch
"H.264/MPEG-4 AVC Video Compression Tutorial", LSI Logic, www.lsilogic.com
Compression Project, www.compression.ru/video/
CRIT, "Centro Ricerche e Innovazione Tecnologica", www.crit.rai.it
Institute for Telecommunication Sciences (ITS) Video Quality Research Project,
www.its.bldrdoc.gov/n3/video/index.html
Video & Image Compression Resources and Research, www.vcodex.com/h264.html
"Image and Video Compression Standards: Algorithms and Architectures", Vasudev
Bhaskaran e Konstantinos Konstantinides, edizioni Springer, II edizione, 1997
"H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia",
Iain E.G. Richardson, edizioni Jhon Wiley & Sons, 2003
DSP Research, www.dspr.com/www/technology/technology.htm
www.divxmania.it
Doom9, il più autorevole forum dedicato ai codec, www.doom9.net
"La compressione video Mpeg4", Andrea Panisson, http://andypanix.altervista.org
"Trattamento e Compressione di Dati Multimediali", Ignazio Infantino, ICAR-CNR,
www.pa.icar.cnr.it/infantino/slides_tcdm/
"I formati MPEG-1 e MPEG-2", http://www.benis.it/dvd/mpeg/mpeg.htm
Simone Chiesa
[email protected]
132
COMPARAZIONE
giugno 2006

Una valutazione comparativa dei codec di

Transcript

Documenti analoghi

Grafica: I Programmi Più Popolari - World Design

Scheda di Acquisizione MJ 600

DivX6 00.indd - McGraw-Hill Education (Italy)

K-Lite installazione pacchetto codec Scarichiamo il pacchetto dei

Formati video - Pagina principale

9254/02 OJ/CRP1 19 ORDINE DEL GIORNO PROVVISORIO d

9890/06 ARB/fo 1 CAB CONSIGLIO DELL`UNIONE EUROPEA

Programmi Indispensabili

indo codec

5162/03 OJ/CRP1 2 ORDINE DEL GIORNO P