Una valutazione comparativa dei codec di

Transcript

1 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 Parole chiave: compressione video, codec, comparazione, standard, prestazioni Anno Accademico 2005/06

2

3 A mio padre e a mia madre "La Vita, senza Amore, sarebbe solo un conglomerato di molecole"

4 Indice generale VIDEO DIGITALE 1.1 Cos'è un codec? Lossy o Lossless?...10 Compressione lossless...10 Compressione lossy...11 Differenza tra flussi audio e video I container Formato File Specifiche...14 I formati container Linee TV, pixel e campioni I tipi di spazio colore RGB YUV YUV 4:4: YUV 4:2: YUV 4:2: Conversione RGB YUV...23 LA COMPRESSIONE VIDEO 2.1 Tipi di frames...27 Gli intra-frames I Delta-Frames od Inter-Frames B-frames / Bi-directional encoding: Conversione dello spazio di colore Blocking Modellizzazione del moto...33 Motion Estimation (ME) Motion Compensation (MC) DCT, Discrete Cosine Transform Quantizzazione Zig-Zag Scanning Run-Level encoding (RLE) e Variable-Lenght coding (VLC) Bit-rate CBR e VBR pass e n-pass Modalità 1-pass Modalità a 2-pass I difetti dei codec lossy LO STANDARD MPEG MPEG... 50

5 3.2 MPEG Componenti dell'mpeg H.264/AVC Algoritmi e profili Macro-blocchi e slice Predizione e codifica intra...59 Predizione e codifica inter...60 Trasformata e quantizzazione Filtro di ricostruzione...61 Codifica VLC Incremento in qualità e in complessità Applicazioni:...64 Diffusione televisiva a definizione standard Diffusione televisiva ad alta definizione Implementazioni software...66 VALUTAZIONE DELLA QUALITA' 4.1 Il problema dei metri di valutazione Problemi...69 Dipendenze dalle scene di input...69 Dipendenze dai sistemi di trasmissione digitali Nuovi disturbi del video digitale...69 La necessità dell'indipendenza della tecnologia Valutazione soggettiva Valutazione oggettiva Il PSNR SSIM VQM COMPARAZIONE 5.1 Risorse utilizzate Codec LOSSLESS Codec LOSSY...99

6

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

8 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

9 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 VIDEO DIGITALE 9

10 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 Compressione lossless Da un punto di vista teorico la massima qualità si otterrebbe facendo uso di video non compresso, 10 VIDEO DIGITALE

11 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 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 VIDEO DIGITALE 11

12 (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 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 volte al secondo. Quindi un flusso audio campionato tipicamente a 16 bit e 44.1 Khz (qualità cd) occuperà1 16 x = 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 Quindi: 1 KB = 1024 bit 1 MB = 1024 KB 1 GB = 1024 MB 12 VIDEO DIGITALE

13 2 x 16 x x 60 x 60 = 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 = bit/s = KB/s = 29,66 MB/s per un'ora di video non compresso ci vorranno allora 29,66 x 60 x 60 = 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 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. VIDEO DIGITALE 13

14 1.3 I container 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 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

15 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 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 VIDEO DIGITALE 15

16 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 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 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

17 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 freq. 50Hz 50Hz 60Hz 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 I tipi di spazio colore Vediamo le caratteristiche dei vari spazi colore, ovvero del modo di registrare le informazioni del VIDEO DIGITALE 17

18 singolo pixel 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 = = 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 = 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

19 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 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 VIDEO DIGITALE 19

20 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 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 = 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 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

21 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 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, VIDEO DIGITALE 21

22 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 = 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

23 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 YV 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) = (B-Y) = (R-Y) = R G B R G + 0.5B R G B 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 = operazioni e, per 1 secondo di filmato: VIDEO DIGITALE 23

24 x 25 = operazioni di cui: addizioni shift 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

25 2 LA COMPRESSIONE VIDEO 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. LA COMPRESSIONE VIDEO 25

26 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 LA COMPRESSIONE VIDEO

27 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 LA COMPRESSIONE VIDEO 27

28 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 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 secondi di video (250, 300 fotogrammi nel caso del sistema PAL) 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 LA COMPRESSIONE VIDEO

29 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 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 LA COMPRESSIONE VIDEO 29

30 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 LA COMPRESSIONE VIDEO

31 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 LA COMPRESSIONE VIDEO 31

32 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 LA COMPRESSIONE VIDEO

33 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: 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 LA COMPRESSIONE VIDEO 33

34 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 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 LA COMPRESSIONE VIDEO

35 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). LA COMPRESSIONE VIDEO 35

36 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 LA COMPRESSIONE VIDEO

37 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 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 LA COMPRESSIONE VIDEO Rappresentazione grafica della matrice dei coefficienti DCT: solo pochi coefficienti presentano valori significativi. L'energia è stata concentrata soprattuto nel campo delle basse frequenze. 37

38 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)) LA COMPRESSIONE VIDEO Matrice dei coefficienti DCT(x,y) quantizzati

39 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 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). LA COMPRESSIONE VIDEO Matrice dei coefficienti DCT(x,y) "ricostruita" 39

40 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 LA COMPRESSIONE VIDEO

41 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 LA COMPRESSIONE VIDEO 41

42 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 LA COMPRESSIONE VIDEO

43 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. LA COMPRESSIONE VIDEO 43

44 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 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 LA COMPRESSIONE VIDEO

45 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 Kbit/s), mentre nelle scene particolarmente dinamiche in cui per avere una buona qualità occorrono spesso anche più di 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* * * *288 Bit rate di picco (Kbps) Bit rate medio (Kbps) 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) 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. LA COMPRESSIONE VIDEO 45

46 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 LA COMPRESSIONE VIDEO

47 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 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 LA COMPRESSIONE VIDEO 47

48 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à 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 LA COMPRESSIONE VIDEO

49 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. LA COMPRESSIONE VIDEO 49

50 3 LO STANDARD MPEG 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

51 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 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 LO STANDARD MPEG-4 51

52 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

53 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 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 è LO STANDARD MPEG-4 53

54 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 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 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 AVC File Format 54 Per la memorizzazione di video AVC (basato dulla part 12) LO STANDARD MPEG-4

55 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: 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 L'ITU sviluppò indipendentemente l'h.263 e due estensioni (pubblicate sotto forma di annessi) denominate H.263+ e H Nel frattempo in MPEG si procedeva allo sviluppo della parte 2relativa alla codifica video dello standard MPEG-4, partendo come base da H.263. LO STANDARD MPEG-4 55

56 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 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 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

57 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 LO STANDARD MPEG-4 57

58 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 kbit/s 80 kbit/s 192 kbit/s 256 kbit/s 128x96/ x144/15.0 1b kbit/s 160 kbit/s 384 kbit/s 512 kbit/s 128x96/ x144/ kbit/s 240 kbit/s 576 kbit/s 768 kbit/s 176x144/ x240/ kbit/s 480 kbit/s 1152 kbit/s 1536 kbit/s 176x144/ x240/ x288/ kbit/s 960 kbit/s 2304 kbit/s 3072 kbit/s 352x288/ Mbit/s 2.5 Mbit/s 6 Mbit/s 8 Mbit/s 352x288/ Mbit/s 5 Mbit/s 12 Mbit/s 16 Mbit/s 352x480/ x576/ Mbit/s 5 Mbit/s 12 Mbit/s 16 Mbit/s 720x480/ x576/ Mbit/s 12.5 Mbit/s 30 Mbit/s 40 Mbit/s 720x480/ x576/ Mbit/s 17.5 Mbit/s 42 Mbit/s 56 Mbit/s 1280x720/ x576/ Mbit/s 25 Mbit/s 60 Mbit/s 80 Mbit/s 1280x720/ Mbit/s 25 Mbit/s 60 Mbit/s 80 Mbit/s 1920x1088/ x1024/ Mbit/s 62.5 Mbit/s 150 Mbit/s 200 Mbit/s 1920x1088/ x1024/ Mbit/s 62.5 Mbit/s 150 Mbit/s 200 Mbit/s 1920x1088/ x1088/ Mbit/s Mbit/s 405 Mbit/s 540 Mbit/s 1920x1088/ x1920/ Mbit/s 960 Mbit/s 1920x1088/ x2048/ Mbit/s 720 Mbit/s LO STANDARD MPEG-4

59 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 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. LO STANDARD MPEG-4 59

60 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 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

61 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 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) 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. LO STANDARD MPEG-4 61

62 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

63 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): LO STANDARD MPEG-4 63

64 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

65 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 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 ( 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 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 ( 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 LO STANDARD MPEG-4 65

66 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

67 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 ).mpg E' il container di AVC definito nello standard MPEG-2 (ISO , 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 LO STANDARD MPEG-4 67

68 4 VALUTAZIONE DELLA QUALITA' 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 VALUTAZIONE DELLA QUALITA'

69 4.2 Problemi 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 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 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. VALUTAZIONE DELLA QUALITA' 69

70 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) 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 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 VALUTAZIONE DELLA QUALITA'

71 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 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 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. VALUTAZIONE DELLA QUALITA' 71

72 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 VALUTAZIONE DELLA QUALITA'

73 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. VALUTAZIONE DELLA QUALITA' 73

74 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 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: 74 VALUTAZIONE DELLA QUALITA'

75 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. VALUTAZIONE DELLA QUALITA' 75

76 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 () 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

77 5.1 Risorse utilizzate HARDWARE Tutti i test sono stati effettuati con il seguente hardware: processore AMD Athlon @2,53Ghz Scheda madre ASUS A8n-E RAM 2x 512MB PC3200 V-DATA DDR scheda video Radeon x MB VIVO Hard Disk Maxtor 6B250s0, 7200rpm, 250GB, SATA2 monitor LG 795FT+ a tubo catodico - FLATRON risoluzione SOFTWARE Sistema Operativo Windows XP Professional SP2 Software per l'encoding: PROGRAMMA FUNZIONE VERSIONE 2.55 LINK AviSynth frameserving VirtualDub editing ed encoding build VirtualDubMod editing ed encoding build aldubmod Yamb Mux / demux yuv2avi conversione video - players: PROGRAMMA VERSIONE LINK Media Player Classics &package_id=84358 Elecard Mpeg Player VideoLan Windows Media Player 11-beta COMPARAZIONE 77

78 software per l'analisi qualitativa oggettiva: PROGRAMMA VERSIONE LINK MSU Video Quality Measure 1.2 beta PSNR Creator Avisynth (funzione compare() ) 2.55 ww.avisynth.org Software utilizzato per il decoding: E' stato usato il pacchetto opensource ffdshow ( contente le librerie libavcodec che, testate sull'autorevole forum di doom9, sono risultate sviluppare i migliori decoder ( CLIPS Sono state utilizzate sequenze video test standard, disponibili per il download sul sito del VQEG (Video Quality Experts Group) 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

79 5.2 Codec LOSSLESS Codec analizzati: Alpary Avizlib Camstudio CorePng FFV1 Huffyuv Lagarith Lzo Mindvid MSU lossless Picvideo lossless COMPARAZIONE 79

80 Alpary v2.0 build (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

81 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 (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. COMPARAZIONE 81

82 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

83 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 SECONDI KBytes RATIO Alpary ,619 2,07 Avizlib ,314 0,97 Cam_gzip ,251 1,30 Cam_lzo ,748 1,07 CorePng ,640 1,83 COMPARAZIONE 83

84 CODEC SECONDI KBytes RATIO Ffv1 [1] ,859 2,50 Huffyuv ,741 1,74 Lagarith ,137 2,33 Lzo [1] 60 76,756 3,43 Mindvid ,686 1,67 MSU ,276 2,41 Picvideo ,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

85 velocità/compressione. Huffyuv arriva secondo di poco. MSU comprime meglio di tutti ma è deludente nel fattore velocità. Massima compressione CODEC SECONDI KBytes RATIO Alpary ,385 2,14 Avizlib ,104 1,29 Cam_gzip ,095 1,305 CorePng ,065 1,84 Huffyuv ,403 1,85 Lagarith * ,137 2,33 Mindvid * ,686 1,67 MSU ,244 2,53 Picvideo * ,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 COMPARAZIONE 85

86 moltissimo la velocità (344 secondi sono davvero tanti). Lagarith e Alpary sono due scelte più ragionevoli. Massima velocità CODEC SECONDI KBytes Fps Alpary rgb , Avizlib , Cam_gzip , Cam_lzo , CorePng , Huffyuv , Lagarith * , Mindvid * ,686 8 MSU ,276 3 Picvideo * , * 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

87 codec MSU. COLORE: YUY2 (4:2:2) Dimensioni originali: 174 MB Standard CODEC SECONDI KBytes RATIO Alpary ,32 Avizlib Camstudio CorePng ,35 Huffyuv ,83 Lagarith ,56 Mindvid , 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. COMPARAZIONE 87

88 Massima compressione 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, CorePng 15 85, huffyuv 9 91, Lagarith * 9 68, msu 37 62,773 5 COMPARAZIONE

89 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 SECONDI KBytes RATIO Alpary ,13 Avizlib Camstudio CorePng ,24 Ffv ,60 Huffyuv Lagarith ,36 Lzo_gzip ,88 COMPARAZIONE 89

90 CODEC SECONDI KBytes RATIO Lzo_lzo ,23 Mindvid , 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

91 Massima compressione CODEC SECONDI KBytes RATIO Alpary ,20 CorePng ,28 Ffv ,60 Lagarith ,24 Lzo_gzip ,86 Lzo_lzo ,23 MSU ,70 Vince sempre MSU, confermando il suo predominio per quanto riguarda la capacità di compressione Massima velocità CODEC SECONDI KBytes Alpary CorePng Ffv COMPARAZIONE 91

92 CODEC SECONDI KBytes Lagarith Lzo_gzip Lzo_lzo MSU Sorprende Alpary con i suoi 6 secondi, seguito come sempre da Lagarith con solo 7 secondi. Gzip è praticamente fuori gara. 92 COMPARAZIONE

93 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 Settaggi standard (velocità\compressione) Ottimo Lagarith, bene anche Huffyuv COMPARAZIONE 93

94 Massima velocità Massima compressione Pareggio tra Alpary e Huffyuv Vince ancora MSU COLORE: YUV 4:2:2 (YUY2) Settaggi standard (velocità\compressione) Primo Lagarith, secondo Huffyuv 94 COMPARAZIONE

95 Massima velocità Massima compressione Pareggio tra Alpary, Uffyuv e Lagarith Vince ancora MSU COLORE: YUV 4:2:0 (YV12) Settaggi standard (velocità\compressione) Questa volta c'è un pareggio tra ben 3 codec: Lagarith, Ffv1 e MSU COMPARAZIONE 95

96 Massima velocità Massima compressione 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

97 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: COMPARAZIONE 97

98 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

99 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 è COMPARAZIONE 99

100 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

101 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 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. COMPARAZIONE 101

102 HDX (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

103 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. COMPARAZIONE 103

104 Prezzi e containers dei codec 104 CODEC PREZZO CONTAINER 3vix Free AVI DivX $ AVI flv1 free AVI Fdd_H.264 free AVI HDX $ AVI, MP4, 3GP Indeo 5.11 free AVI Mainconcept 499 $ MPG, 264 Mpegable?$ MP4 Mpeg $ 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

105 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 29,97 fps COMPARAZIONE 105

106 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 = Kbit = 5.418,75 KB CODEC SEC Kbps SCARTO (%) KB SCARTO (%) PSNR 3vix , ,67 37,6219 DivX [2] 0, ,33 37, COMPARAZIONE

107 CODEC SEC Kbps SCARTO (%) KB SCARTO (%) PSNR flv , ,12 38,2180 Fdd_H , ,76 38,2180 HDX , ,44 37,8299 Indeo , ,83 35,4350 Mainconcept , ,04 errore Mpegable , ,94 errore Mpeg , ,27 33,9742 Nero , ,67 errore Quicktime , ,53 errore Real , ,01 38,8809 Sorenson , ,05 errore theora [3] 1, ,72 38,0651 VP [4] 0, ,75 38,8835 [1] VSS , ,05 38,5731 wmv , ,71 35,0351 x , ,61 39,3433 XviD [5] 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 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 di KB con bitrate di 4132 Kbps [4] Nella configurazione del codec ho settato 5500 KBPS. Impostando il bitrate a 5000 Kbps si ottiene in realtà un file di KB con bitrate di 4580 Kbps [5] Nella configurazione del codec ho settato 5300 KBPS. Impostando il bitrate a 5000 Kbps si ottiene in realtà un file di KB con bitrate di 4669 Kbps video2: a bitrate costante di 4000 Kbps il file di output corretto dovrebbe essere di: 4000 Kbit/sec x 8,80 sec = Kbit = KB CODEC SEC Kbps SCARTO (%) KB SCARTO (%) PSNR 3vix [1] 0, ,23 35,4688 DivX [2] 1, ,98 35,9435 flv , ,10 38,3994 COMPARAZIONE 107

108 CODEC SEC Kbps SCARTO (%) KB SCARTO (%) PSNR Fdd_H , ,09 36,5352 HDX , ,10 35,9460 Indeo , ,59 35,8113 Mainconcept , ,80 - Mpegable , ,42 - Nero , ,08 - Quicktime , ,23 - Real , ,59 40,4095 Sorenson , ,68 - theora [3] 0, ,29 38,5570 VP [4] 0, ,97 39,2690 VSS , ,06 39,6566 wmv , ,85 39,8369 x , ,13 40,4707 XviD , ,44 39,6461 [1] Nei settaggi ho dovuto mettere 1800 Kbps [2] Nei settaggi ho dovuto mettere 3200 Kbps [3] Nei settaggi ho dovuto mettere 7500 Kbps [4] Nei settaggi ho dovuto mettere 4500 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

109 VIDEO 1 VIDEO 2 COMPARAZIONE 109

110 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

111 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 COMPARAZIONE 111

112 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

113 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 Mpegable 440 theora DivX Mpeg VP flv Nero 531 VSS Ffd_H Quicktime wmv9 641 HDX Real x Mainconcept Sorenson XviD 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. COMPARAZIONE 113

114 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: 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 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

115 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 COMPARAZIONE 115

116 correttamente. Tralasciamo quindi i risultati 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

117 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: COMPARAZIONE 117

118 Confrontiamo i vincitori con gli altri codec con una valutazione soggettiva: x264: 5+ VP7: 5 Mainconcept: 5 nero: 4 Quicktime: 4 sorenson: 4 mpegable: 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

119 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 COMPARAZIONE 119

120 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