SVILUPPO DI UN CODIFICATORE SOFTWARE PER VIDEO STEREOSCOPICO

Транскрипт

1 POLITECNICO DI TORINO III Facoltà di Ingegneria Laurea Specialistica in Ingegneria delle Telecomunicazioni SVILUPPO DI UN CODIFICATORE SOFTWARE PER VIDEO STEREOSCOPICO Relatore: Prof. Enrico MAGLI Correlatore: Ing. Daniele ALFONSO Candidato: David Fernando SUAREZ DIAZ Aprile 2011

2 ii

3 RINGRAZIAMENTI Un doveroso ringraziamento va all ing. Daniele Alfonso, il mio tutor aziendale, che con pazienza e competenza mi ha guidato nello svolgimento di questo lavoro di tesi. Lavorare con lui è stata una grande opportunità di apprendimento e miglioramento delle mie capacità sia a livello tecnico che personale. Vorrei ringraziare anche il professor Enrico Magli per la disponibilità dimostrata e per rendere possibile la realizzazione di questo lavoro. Grazie anche ad Andrea Ornstein, Emanuele Quacchio, così come a tutte le persone della divisione Advanced System Technology, che mi hanno accolto preso i locali di STMicroelectronics a Castelletto, e che sono stati sempre disponibili ad aiutarmi e darmi consulenza. Il ringraziamento più importante va alla mia famiglia, alla quale è dedicato questo elaborato, che con un costante supporto e incoraggiamento ha reso possibile il raggiungere questo importante traguardo. Tantissime grazie anche agli amici con cui ho condiviso numerose esperienze lungo questi anni. Loro mi hanno sempre consigliato e, in certa maniera, hanno influenzato questo lavoro di tesi. Grazie a tutti. iii

4 iv

5 ABSTRACT In the last years, 3D video has become one of the main arguments in signals elaboration field. For this reason new coding/decoding algorithms and compression strategies have been developed to offer an improvement to the services requested by users. In particular, in the case of stereoscopic video, in order to create the three dimensional effect, two high-definition sequences have to be used. This has powered the emergence of a standard that supports these features. That's the case of the H.264/AVC standard extension named MVC, officially chosen by the Blu-ray Disc Association as the coding standard for Bluray 3D. It allows to incorporate the second video track in a common support Bluray, with a 50% increase in occupied space, ensuring full backward compatibility with any player on the market. The work done in collaboration with the Advance System Technology Central Research and Development division at STMicroelectronics Srl., Milan, has as its purpose the implementation of the MVC Stereo high profile within the H.264/AVC STMicroelectronics proprietary encoder, and then the algorithm optimization used to perform motion estimation, taking advantage of the strong statistical interdependences between the two video sequences. This thesis is divided in five chapters. The first chapter is an introduction aimed to explain the importance of video coding as well as some of the tools used for this purpose. The second chapter is a brief description of H.264/AVC video coding standard, followed in chapter three, by today s 3-D/Multi-View video coding technologies and standards description. Chapter four introduces the MVC stereo high profile, followed by an analysis of the reference software JM 17.2 and the proposed modification of the HENC 8.3 STMicroelectronics encoder, intended to support the two video sequences encoding on a single bitstream. Chapter five presents SLIMH264 motion estimation algorithm and some proposals to achieve better performance when it s used to coding a stereoscopic video sequence as well as significant tests and results. v

6 vi

7 SOMMARIO Negli ultimi anni, la trasmissione di video in alta definizione, e più recentemente in 3D, è diventata uno dei principali argomenti su cui si lavora nel campo dell elaborazione dei segnali. Tuttavia, ci sono diversi ostacoli che ancora devono essere superati per garantire un ottimo funzionamento poiché le risorse a disposizione (larghezza di banda, spazio di archiviazione, ecc.) sono limitate. Tenendo conto di tutto ciò, si stano cercando soluzioni che garantiscano una migliore qualità visiva e un miglioramento dei servizi offerti all utente finale attraverso l utilizzazione di ottimizzate strategie di compressione e algoritmi di codifica/decodifica che approfittino delle peculiarità di questi segnali. In particolare, nel caso del video stereoscopico, devono essere trattate due sequenze video ad alta definizione che permettano creare l effetto 3D. Questo fenomeno ha fomentato l apparizione di uno standard che supporti tali caratteristiche, com è il caso dello standard H.264/AVC, nel quale è specificata, all interno del suo ultimo annesso, questa nuova funzionalità. Nominata MVC, questa estensione è stata ufficialmente scelta dalla Blu-ray Disc Association come standard di codifica dei Blu-ray 3D perché consente di inglobare la seconda traccia 1080p in un comune supporto Blu-ray, con un aumento del 50% dello spazio occupato, garantendo una piena compatibilità con qualunque lettore già presente nel mercato, anche se per la sola riproduzione in 2D nel caso di quelli non compatibili con il nuovo standard stereoscopico. Il presente elaborato è stato svolto in collaborazione con STMicroelectronics e ha come oggetto lo sviluppo di un codificatore software per segnali di video stereoscopico centralizzandosi nell ottimizzazione dell algoritmo per la stima del moto presente nel software di riferimento. Lo scopo è quello di implementare il profilo MVC Stereo all interno del codificatore H.264/AVC proprietario dell azienda ospitante e poi ottimizzare l algoritmo utilizzato per eseguire la stima del moto, approfittando la forte interdipendenza statistica fra le due sequenze video. La fase iniziale della tesi è dedicata allo studio degli standard di codifica video H.264/AVC e MVC, e della letteratura esistente sulla stima del moto. Segue l analisi del software di riferimento JM 17.2, e poi, con base in quello trovato, la modificazione dell encoder HENC 8.3 per supportare la codifica di due sequenze vii

8 video su un unico bitstream. Finalmente si procede con l ottimizzazione dell algoritmo SLIMH264 che svolge la stima del moto e lo sviluppo di tre profili diversi di funzionamento con particolari caratteristiche e applicazioni. viii

9 INDICE RINGRAZIAMENTI... iii ABSTRACT... v SOMMARIO... vii 1 CODIFICA VIDEO INTRODUZIONE I SEGNALI VIDEO IL PROCESSO DI CODIFICA Limitazioni Compressione con o senza perdite Codifica a singolo campione o Codifica a Blocchi La trasformata DCT: Riduzione della ridondanza spaziale Riduzione della ridondanza temporale STANDARD H.264/MPEG-4 AVC INTRODUZIONE CARATTERISTICHE DELLO STANDARD STRUTTURA DELLA CODIFICA VIDEO H.264/AVC Il Video Coding Layer Il Network Abstraction Layer Profili e livelli MULTI-VIEW VIDEO CODING (MVC) INTRODUZIONE APPLICAZIONI DI MVC CARATTERISTICHE PRINCIPALI LA STRUTTURA DEL BITSREAM IN MVC Le unità NAL Temporal and View Scalability DECODED PICTURE BUFFER Ordine della Codifica Requisiti del DPB SUPPORTO DEL PROFILO MVC STEREOSCOPICO INTRODUZIONE ix

10 4.2 SUPPORTO NEL SOFTWARE DI RIFERIMENTO JM IMPLEMENTAZIONE NEL CODIFICATORE HENC Il file di configurazione MVCInterViewReorder Gestione del DPB Informazioni addizionali ANALISI DELLE PRESTAZIONI DEL CODIFICATORE Analisi delle prestazioni di MVCInterViewReorder Analisi delle prestazioni di diverse configurazioni OTTIMIZZAZIONE DELL ALGORITMO SLIMH INTRODUZIONE DESCRIZIONE DELL ALGORITMO SLIMH La Coarse Search Ricerca grezza La Fine Search Ricerca fina Profiling IMPLEMENTAZIONE DI SLIMH264 NEL CODIFICATORE HENC Modificazioni nella Coarse Search Modificazioni per la Predizione Inter-view Analisi delle prestazioni OTTIMIZZAZIONE DEL TEMPO DI CODIFICA No mode Test SLIMH264 Fast Decision APPENDICE A: FILE DI CONFIGURAZIONE DEL SOFTWARE JM A.1 Parametri di configurazione del codificatore A.1.1 Opzioni dei file di ingresso e di uscita A.1.2 Impostazioni del codificatore A.1.3 Frame B A.1.4 MVC A.1.5 Controllo dell uscita A.1.6 Codifica interlacciata A.1.7 Restrizioni del Search Range / Ottimizzazione RD A.2 Parametri di configurazione del decodificatore APPENDICE B: CODICE INSERITO NEL CODIFICATORE JM 17.2 PER IL SUPPORTO DEL PROFILO STEREO DI MVC TABELLA DELLE FIGURE INDICE TABELLE BIBLIOGRAFIA LISTA DEGLI ACRONIMI x

11 1 CODIFICA VIDEO

12 1.CODIFICA VIDEO 1.1 INTRODUZIONE Il processo di compressione ha lo scopo di fornire una rappresentazione digitale compatta del segnale. In generale si cerca di minimizzare il bit-rate del flusso dei dati per adattarlo alla capacità limitata del canale di trasmissione oppure del supporto di memorizzazione. In letteratura il rapporto di compressione è definito come: Non esiste (o almeno non è ancora stata inventata) una tecnica di compressione universale, dunque è necessario utilizzare strumenti diversi a seconda della natura della sorgente e del tipo di compressione desiderata. L approccio più adeguato per una data sorgente dipende in prima analisi dal tipo di ridondanza contenuta nei dati. In particolare, l oggetto di questo elaborato sarà lo studio dei segnali video. Le sequenze video sono successioni di immagini (frame) molto correlate fra loro in una terza dimensione, il tempo. Figura 1. Rappresentazione di una sequenza video. I segnali video sono particolarmente idonei al processo di compressione grazie ad una serie di peculiarità che li caratterizzano: In ogni sequenza d immagini c è una considerevole ridondanza statistica, suddivisibile in: 1) Correlazione spaziale tra i campioni adiacenti di uno stesso frame. 2) Correlazione spettrale tra le diverse componenti di colore. 3) Correlazione temporale tra i campioni appartenenti a frame successivi. Una certa quota d informazione del segnale video può essere considerata superflua dal punto di vista percettivo. La capacità di sfruttare la ridondanza nel dominio del tempo costituisce la fondamentale differenza tra la compressione video e la compressione di immagini statiche. 2

13 1.CODIFICA VIDEO 1.2 I SEGNALI VIDEO I segnali video sono stati tradizionalmente catturati, conservati e trasmessi in forma analogica. Il termine segnale video analogico si riferisce a un segnale unidimensionale (1-D) variante nel tempo che rappresenta il pattern d intensità nelle coordinate verticali e temporali con la sua corrispondente rappresentazione elettrica. Questo processo di campionamento è noto come scanning o scansione. Il processo noto come Scansione Raster inizia nell'angolo in alto a sinistra e progredisce in senso orizzontale, con una leggera pendenza in senso verticale, attraverso l'immagine. Quando raggiunge il bordo a destra, torna indietro al lato sinistro (lungo un percorso orizzontale denominato horizontal retrace) per avviare una nuova scansione di linea. Quando si è raggiunto l'angolo in basso a destra, un frame completo è stato digitalizzato e la scansione scatta verso l'angolo in alto a sinistra (vertical retrace) per iniziare con un nuovo frame. I patroni di Raster più utilizzati sono i metodi di scansione progressiva e interlacciata, illustrati nella Figura 2. Nella scansione progressiva (nota anche come non interlacciata o 1:1), un frame è formato da un singolo passaggio di scansione. Invece, la scansione interlacciata (o 2:1), prevede la divisione delle linee di scansione in due parti, dette campi o semiquadri, suddivisi in linee pari e dispari. Figura 2. Metodi di Scansione Raster. Da [1]. L Aspect Ratio, la Risoluzione Verticale, il Frame Rate e la Refresh Rate sono importanti parametri dei segnali video. L'Aspect Ratio, o in italiano Rapporto d'aspetto, indica la relazione matematica tra la larghezza e l'altezza di un'immagine. La Risoluzione Verticale è correlata al numero di linee di scansione per frame. Il Frame Rate è il numero di frame scansionati al secondo, mentre la frequenza d'aggiornamento, termine tradotto dall'inglese Refresh Rate, è il numero di volte in un secondo che viene ridisegnata l'immagine su un display. 3

14 1.CODIFICA VIDEO La discussione precedente ha considerato soltanto i segnali video in bianco e nero. In pratica, tuttavia, la maggior parte delle sequenze video è a colori. Secondo la teoria tricromatica della visione a colori, essi vengono percepiti nell occhio attraverso tre classi di celle, denominate coni o fotorecettori, che generano un segnale elettrico in modulazione di ampiezza proporzionale al numero di fotoni assorbiti. Queste celle sono state classificate in termine di lunghezza di onda osservando il picco della sua risposta spettrale come: L (long), M (medium) e S (short), anche riferite alcune volte come coni rossi, verdi e blu rispettivamente. Di conseguenza, un video a colori può essere prodotto dalla sovrapposizione di tre segnali video. Ogni segnale rappresenta uno dei tre colori primari: rosso, verde e blu (RGB). I sistemi video, in genere, convertono questa rappresentazione RGB in uno spazio di colore diverso, composta da luminanza (che è strettamente legata alla percezione della luminosità) e crominanza (che è legata alla percezione di tonalità e saturazione). Questa rappresentazione dei video a colori serve principalmente a due compiti: In primo luogo, la luminanza garantisce la compatibilità con i video in bianco e nero. In secondo luogo, questa rappresentazione si presta più facilmente alla compressione video. Ciò può essere spiegato come segue: il sistema visivo umano ha una scarsa risposta al dettaglio spaziale del colore (crominanza), rispetto alla sua risposta al dettaglio spaziale della luminanza. Così, i segnali di crominanza possono essere a banda limitata o sottocampionati per ottenere la compressione. Tuttavia, negli ultimi anni, il mondo è vissuto una rivoluzione digitale. La maggior parte delle industrie ha subito un cambiamento dalla tecnologia analogica a quella digitale, e il video non è l eccezione. Il processo di digitalizzazione dei segnali video coinvolge tre operazioni di base: il filtraggio, il campionamento e la quantizzazione. L'ampiezza del segnale analogico filtrato viene campionata a istanti di tempo specifici per generare un segnale a tempo discreto. Avendo conto che i campioni risultanti a tempo discreto hanno ampiezze continue, sarebbe necessario avere precisione infinita per rappresentarli. Perciò, l'operazione di quantizzazione viene utilizzata per mappare tali valori su un insieme finito di ampiezze discrete che possono essere rappresentate da un numero finito di bit. Ogni campione che corrisponde a un tempo discreto, con un ampiezza discreta è chiamato elemento dell immagine e di solito abbreviato con il termine pixel. I pixel sono disposti in un array bidimensionale (2-D) che rappresenta un frame digitale, la cui sequenza costituisce un cosiddetto Video Digitale. Per il video a colori, le operazioni descritte in precedenza sono ripetute per ogni componente. Così, un immagine digitale è normalmente rappresentata da tre matrici 2-D. 4

15 1.CODIFICA VIDEO 1.3 IL PROCESSO DI CODIFICA Lo schema di principio di un generico sistema di codifica è rappresentato in Figura 3: Figura 3. Generico sistema di codifica. La codifica di sorgente costituisce la sezione fondamentale di un codificatore: qui il data-rate della sorgente è compresso a un livello tale da adattarlo alle caratteristiche del supporto di trasmissione o di memorizzazione. Nei sistemi reali, il codificatore di sorgente è seguito da un secondo livello di codifica: il codificatore di canale. Mentre il primo cerca di eliminare la ridondanza del segnale, quest ultimo svolge l operazione inversa, cioè aggiunge ridondanza al fine di rendere il segnale robusto agli effetti del canale di trasmissione (caratterizzato per una certa probabilità di errore sul bit come conseguenza del rumore che presenta) Limitazioni Nel procedimento di compressione ci sono ancora alcune condizioni che limitano le sue prestazioni le quali devono essere rispettate: Efficienza di codifica Si misura di solito in bit per campione o bit al secondo. Un fattore limitante dell efficienza di codifica è il contenuto d informazione della sorgente misurato tramite l entropia. Si ricorre all entropia per definire i limiti di comprimibilità della sorgente: quanto più è elevata l entropia tanto più il segnale è difficile da comprimere. Una descrizione dettagliata di questi concetti si può trovare in [2]. Complessità computazionale Questa misura corrisponde al carico computazionale necessario per l implementazione delle funzioni di codifica e decodifica. Al carico computazionale vengono solitamente associati la quantità di memoria e il numero di operazioni aritmetiche richieste al calcolatore per lo svolgimento di questi due processi. Ritardo di codifica Per raggiungere alti rapporti di compressione spesso sono richiesti complessi procedimenti che causano un incremento del tempo di elaborazione del segnale. Questi ritardi possono essere ridotti ricorrendo a macchine più potenti; tuttavia quest approccio risulta impraticabile se i limiti di potenza sono stringenti. La necessità di limitare i ritardi induce spesso il progettista a implementare algoritmi meno sofisticati, non ottimali. 5

16 1.CODIFICA VIDEO Compressione con o senza perdite In molti casi il decodificatore deve poter ricostruire i dati originali senza perdite, per esempio se si tratta di testi, dati bancari, dati scientifici, ecc. Per un processo con questa caratteristica (lossless), il segnale ricostruito deve essere identico a quello originale, cioè si tratta di un procedimento completamente reversibile. La compressione lossless prevede dunque un compromesso tra efficienza, ritardo e complessità di codifica. Tuttavia, la maggior parte delle elaborazioni di dati non richiede che il segnale ricostruito sia uguale a quello originale, infatti, è consentito un certo margine di perdita (com è il caso dei segnali audio, voce, video, ecc.). Si parla quindi di codifica con perdite (lossy). Il procedimento è irreversibile: il segnale ricostruito è degradato rispetto all originale. Per valutare il grado di perdita si ricorre a un nuovo parametro denominato Qualità del Segnale. Questo termine è usato per caratterizzare il segnale in uscita dal decodificatore. Non esiste un unica unità di misura della qualità, ma quella più utilizzata è il rapporto segnale-rumore o PSNR (Peak Signal to Noise Ratio) che può essere calcolato come: Dove I(x,y) e I (x,y) sono i valori dei pixel associati al frame originale e a quello ricostruito rispettivamente, ed M e N sono il numero di pixel orizzontali e verticali. Trattandosi di un rapporto segnale rumore di picco, al numeratore si fa riferimento al valore del segnale di massima intensità, K. Bisogna sottolineare che alti valori di PSNR non corrispondono necessariamente ad elevate qualità percettive in quanto si tratta di una misura oggettiva di qualità Codifica a singolo campione o Codifica a Blocchi Nel primo caso si elabora un campione d ingresso alla volta al quale è associata una rappresentazione compressa. Questo procedimento prende il nome di sistema di codifica pixel-per-pixel. I campioni dell immagine sono codificati uno a uno, sia nel dominio spaziale sia in quello della frequenza. Un esempio di questo tipo di schema è la Modulazione Differenziale d Impulso (DPCM) illustrata in Figura 4. Figura 4. Diagramma a blocchi del metodo di codifica DPCM. 6

17 1.CODIFICA VIDEO Per ogni campione d ingresso X ij viene calcolato l errore residuo e ij rispetto alla predizione P ij. Questa predizione P ij è di solito una somma pesata dei pixel adiacenti a X ij precedentemente co-decodificati. Se il frame ha una forte correlazione spaziale, P ij predice fedelmente X ij e l errore e ij risulta ridotto. Dall altra parte, negli schemi di codifica a blocchi si elaborano più campioni alla volta e sono generate una o più rappresentazioni compresse per l insieme dei valori di ingresso. L effettivo beneficio della codifica a blocchi è chiaramente esposto nella teoria di Shannon [2], secondo cui l efficienza di codifica può raggiungere i limiti teorici elaborando blocchi di dati sempre più grandi. Un gruppo di campioni molto correlati spazialmente tenderà ad avere una rappresentazione nel dominio della frequenza molto compatta. Nel caso dei video si deve tenere conto anche della correlazione temporale tra frame consecutivi. La codifica di blocchi di pixel ogni volta più grandi permette di avere bit-rate più bassi a parità di PSNR. Al contrario, fissato un certo bit-rate, la distorsione complessiva si riduce, cioè si ha un guadagno in termini di PSNR. Alcune delle più comuni funzioni di base per andare al dominio della frequenza sono la Trasformata Discreta di Fourier (DFT), la Trasformata Discreta del Coseno (DCT) e quella di Karhunen-Loeve (KLT). La KLT è quella migliore in termini di efficienza di codifica, tuttavia questa trasformata presenta alcuni inconvenienti, poiché dipende dai dati d ingresso, non disponibili al decodificatore. Invece, la DCT e la DFT sono indipendenti dall immagine da codificare. L uscita fornita dalla trasformata DCT è molto simile a quella della KLT, perciò è largamente diffusa negli standard di elaborazione d immagini e video La trasformata DCT: Riduzione della ridondanza spaziale L operazione fondamentale svolta dalla trasformata DCT è la trasformazione di un blocco NxN dell immagine dal dominio spaziale a quello trasformato. Questo processo equivale al calcolo per ogni forma d onda d ingresso di un peso F(u,v) tale che la somma delle NxN forme d onda, pesate opportunamente, dia la versione ricostruita del blocco di partenza. Tale peso è espresso nel seguente modo: La dimensione del blocco è stata impostata a 8x8 perché non richiede di allocare eccessive risorse di memoria, la complessità computazionale è ridotta e blocchi di dimensioni maggiori non apportano sostanziali incrementi del livello di compressione. 7

18 1.CODIFICA VIDEO Figura 5. Esempio di sistema di codifica basato sulla trasformata DCT 8x8. Com è descritto nella Figura 5, ogni blocco 8x8 del frame di partenza passa dal dominio spaziale a quello della DCT. I coefficienti sono quantizzati e quelli con minore energia risultano nulli dopo la quantizzazione. Solo i coefficienti quantizzati non nulli sono poi sottoposti a codifica entropica (lossless). Il diffuso utilizzo della DCT è determinato da una serie di fattori: Dove prevale una forte correlazione spaziale, la DCT è in grado di fornire un efficienza di codifica paragonabile a quella della KLT. La DCT è una trasformata ortogonale. La DCT e la IDCT bidimensionale sono trasformazioni reali e separabili, perciò è possibile realizzare in maniera indipendente la trasformata monodimensionale prima lungo le righe e poi lungo le colonne. L implementazione può essere fatta con algoritmi veloci che richiedono relativamente poche operazioni non complesse, come somme e shift di bit Riduzione della ridondanza temporale Per ridurre la ridondanza temporale, il problema diventa quello di valutare il movimento di un oggetto nel tempo, poiché si devono identificare le proprietà del moto da sfruttare ai fini della codifica. Nella Figura 6 sono rappresentati due frame consecutivi di una sequenza video in cui si è evidenziato un oggetto che si muove. Nel primo frame, l oggetto si trova nella regione spaziale A, intanto che, nel secondo, la proiezione dell oggetto in movimento è identificata con la regione B. Figura 6. Correlazione temporale tra frame consecutivi. 8

19 1.CODIFICA VIDEO Oltre alla correlazione spaziale che questo gruppo di pixel può avere con i campioni adiacenti, se l oggetto è in movimento, ci si aspetta anche una forte correlazione temporale con il frame seguente. Negli standard di codifica la ridondanza temporale è analizzata considerando le informazioni di moto associate a regioni dell immagine di dimensione 16x16 dette macroblocchi, per ciascuno dei quali viene determinata una ricostruzione rispetto a uno o più frame di riferimento. Uno dei primi approcci è stato la tecnica nota come Conditional Replenishment. In questo metodo il frame di ingresso è diviso in regioni qualificate come changed e unchanged, che corrispondono rispettivamente agli oggetti che si muovono rispetto al frame precedente e al fondo dell immagine. Le regioni unchanged non devono essere codificate un altra volta poiché possono essere semplicemente copiate dal frame di riferimento, mentre che le posizioni di quelle che sono cambiate vengono codificate. Tuttavia, un approccio più efficiente è codificarle in forma predittiva rispetto alle regioni corrispondenti nel frame di riferimento. Nel caso d immagini in movimento, per migliorare la predizione delle regioni changed, si ricorre alle tecniche di stima del moto (Motion Estimation - ME) e quella fase successiva denominata compensazione del moto (Motion Compensation - MC). La prima consiste nel modellare l immagine attuale come una traslazione di blocchi di pixel da una o più immagini di riferimento, descrivendo lo spostamento dai vettori di moto (Motion Vector - MV). Poi, nella seconda, il codificatore utilizza l informazione appena ricavata per muovere i contenuti dei frame di riferimenti fornendo così una predizione migliore del frame attuale. Finalmente l errore tra frame originale e quello ricostruito viene codificato dopo che è sottoposto a una fase di riduzione della ridondanza spaziale, comunemente attraverso la DCT com è descritto nella Figura 7. Figura 7. Codifica dell errore tra frame originale e ricostruito. 9

20 1.CODIFICA VIDEO In generale, il frame di riferimento usato per realizzare la ME può trovarsi ad un generico istante di tempo del passato t-n (forward prediction) o del futuro t+k (backward prediction). Nella predizione bidirezionale, però, due frame di riferimento (uno precedente e uno successivo) sono impiegati e le sue predizioni sono interpolate. Figura 8. Stima del moto. Il metodo più diffuso per fare il ME è l algoritmo conosciuto come blockmatching [3]. In quest algoritmo, il frame attuale prima è diviso in blocchi, i cui moto è stimato cercando il miglior blocco nel frame di riferimento che minimizza una certa misura di distorsione. La ricerca è usualmente costretta a una finestra centrata intorno al blocco corrispondente nel frame di riferimento. Dal momento che si considera solo la stima di movimenti traslatori e si escludono rotazioni o zoom, la regione di ricerca ha forma rettangolare, e per motivi di complessità, essa non è estesa a tutto il frame ma è limitata al range [-p,p]. Per valutare la bontà della predizione si definisce come funzione di costo l Errore Assoluto Medio (MAE): dove C(x+k, y+l) rappresenta i pixel del frame corrente, R(x+i+k, y+j+l) è il blocco incaricato alla ricostruzione e gli indici i e j sono compresi nell intervallo [-p,p]. Il miglior blocco di riferimento è quello che minimizza MAE (i,j). Sono possibili anche altre funzioni di costo come, ad esempio, la Somma delle Differenze Assolute (SAD). 10

21 2 STANDARD H.264/MPEG-4 AVC

22 2.1 INTRODUZIONE 2.STANDARD H.264/MPEG-4 AVC Nell anno 1998, il Video Coding Experts Group (VCEG- ITU-T SG16 Q.6) lanciò un invito per proposte su un progetto denominato H.26L, il cui obiettivo fu raggiungere il doppio di efficienza nella codifica (cioè ridurre alla metà il bit rate necessario a parità di fedeltà) rispetto a tutti gli standard di codifica video esistenti per diversi propositi [4]. Con lo scopo di finire questo nuovo standard per l anno 2003, è stato creato in Dicembre del 2001 il Joint Video Team (JVT), composto di un gruppo di esperti dal VCEG e dal Moving Pictures Expert Group (MPEG - ISO/IEC JTC 1/SC 29/WG 11). Come risultato del lavoro svolto da questo gruppo nasce lo standard denominato H.264/MPEG-4 AVC (seguendo sia la convenzione del nome degli standard video rilasciati da ITU-T, H.26x, sia da quelli appartenenti alla suite degli standard sviluppati per l ISO). Esso supporta le più efficienti tecniche di compressione video oggi disponibili e fornisce la flessibilità sufficiente per consentire di essere usato in una vasta gamma di applicazioni in una varietà di reti e sistemi, che vano da quelle a basso bit-rate come per esempio Internet Streaming fino a quelle di HDTV Broadcast, riportando in ogni scenario, una codifica con quasi nessuna perdita. A questo standard, lungo questi anni, sono state aggiunte alcune modifiche, come le Fidelity Range Extensions (FRExt), per abilitare codifica di alta qualità, supportare un maggiore livello di precisione e una risoluzione superiore nell informazione del colore, usare più bit per campione, e l aggiunta dello Scalable Video Coding (SVC), una nuova estensione che permette la costruzione di bitstream che contengono in se stessi sub-bitstream, tra i quali ce n è uno conosciuto come base layer che può essere decodificato per qualsiasi ricevitore, anche se non supporta SVC, mentre tutti gli altri layer permettono, alla ricezione, avere una sequenza video con diversi livelli di qualità (temporal and spacial bitstream scalability). Una descrizione dettagliata di tutte queste funzionalità si trova in [5]. L ultima caratteristica che è stata aggiunta allo standard H.264/MPEG-4 AVC è il Multi-view Video Coding (MVC) della quale si parlerà in profondità nel capitolo successivo. Questa estensione, completata nel Novembre del 2009, consente la costruzione di sequenze di bit (bitstream) che rappresentano più di una vista da una scena video. Relativo a MVC, sono stati sviluppati due profili diversi: uno per supportare un numero arbitrario di viste e un altro progettato specificamente per visualizzare il video 3D stereoscopico (due viste), profilo sul quale è focalizzato questo elaborato. Tale attributo nasce come risposta al crescente interesse per il video in tre dimensioni (3D) da parte dei consumatori e alle sue diverse applicazioni [6]. 12

23 2.STANDARD H.264/MPEG-4 AVC 2.2 CARATTERISTICHE DELLO STANDARD Rispetto ai precedenti standard di codifica video, sono state introdotte delle nuove funzionalità con lo scopo di incrementare la qualità dei video codificati: Compensazione del moto a blocchi di dimensione variabile, con grandezze di blocco ridotte: maggiore flessibilità nella selezione della dimensione e della forma dei blocchi per la compensazione del moto. I blocchi di dimensione minima sono composti da 4x4 pixel. Compensazione del moto con risoluzione a un quarto di pixel. Vettori di moto oltre i bordi delle immagini: Nello standard H.264/AVC è stata inclusa la tecnica di estrapolazione dei bordi, proposta per la prima volta in H.263. Compensazione del moto con immagini di riferimento multiple: H.264/AVC sfrutta la tecnica di predizione dalle immagini introdotta in H che permette una codifica efficiente selezionando la migliore immagine di riferimento per la compensazione del moto tra una serie di immagini precedentemente codificate e disponibili anche al decodificatore. Disaccoppiamento dei metodi di riferimento delle immagini dalla capacità di riferimento delle stesse: Poiché a volte le immagini codificate con la predizione bidirezionale sono maggiormente correlate con l immagine corrente, è possibile usarle per la predizione di altre immagini nella sequenza video. Predizione pesata: un opzione innovativa di H.264/AVC prevede la possibilità di pesare il segnale di predizione moto-compensato e di abbinargli un offset definito dal codificatore. Filtro di deblocking in-the-loop a bassi bit-rate: la codifica a blocchi produce delle alterazioni del segnale video, ad esempio la blocchettizzazione o il ringing, originate sia dal meccanismo di predizione sia da quello di quantizzazione. Il filtro di deblocking adattativo dello standard H.264/AVC è stato inserito all interno dell anello di predizione per la compensazione del moto, in modo che al migliorare l immagine di riferimento possa anche tradursi in un vantaggio per le immagini successive. Trasformate su blocchi di piccole dimensioni: tutti i maggiori standard di codifica precedenti usavano delle trasformate basate su blocchi 8x8. H.264/AVC prevede l utilizzo di una trasformata 4x4. Questo consente al codificatore di rappresentare i segnali con una migliore adattabilità e di ridurre quei disturbi noti come ringing. Trasformata gerarchica a blocchi: sebbene a volte l utilizzazione della trasformata di dimensione 4x4 dia un beneficio percettivo, esistono segnali con una correlazione tale da far preferire funzioni di base più lunghe. Lo standard H.264/AVC lo consente in due modi: usando una trasformata gerarchica per le informazioni a bassa frequenza dei blocchi 8x8 di crominanza e inoltre selezionando un secondo tipo di codifica per i blocchi 16x16 di luminanza, in modo simile a quanto fatto per la crominanza. 13

24 2.STANDARD H.264/MPEG-4 AVC Trasformata con lunghezza delle parole ridotta: gli standard precedenti richiedevano dei calcoli molto complessi per applicare le trasformate. Mentre tutti gli algoritmi anteriori esigevano di un aritmetica a 32 bit, per H.264/AVC ne bastano 16. Trasformata inversa univocamente definita: la trasformata usata negli standard precedenti era generalmente specificata su un intervallo di tolleranza, perché, in pratica, era impossibile ottenere un valore univoco della trasformata inversa. Come risultato ogni decoder produceva una versione decodificata del video leggermente diversa. Codifica entropica aritmetica: in H.264/AVC è stato introdotto un sistema avanzato di codifica entropica noto come CABAC (context-adaptive binary arithmetic coding), in alternativa alla CAVLC (Context-Adaptive Variable Length Coding). Codifica entropica adattativa al contesto: i due metodi di codifica entropica disponibili, CAVLC e CABAC, usano l adattabilità al contesto per incrementare le prestazioni rispetto agli standard precedenti, i cui erano basate su tabelle di codifica simbolica predeterminate. Struttura dell insieme di parametri: poiché la perdita di pochi bit di informazione (come il header della sequenza o del singolo frame) può avere effetti disastrosi sul processo di decodifica, questa è trattata separatamente. Dimensionamento flessibile delle slice. Ordinamento flessibile dei macroblocchi (FMO): è stata sviluppata una nuova struttura di partizione dei dati, detta slice group, in cui ogni slice fa parte di un gruppo di slice decodificabili indipendentemente. Questo permette di migliorare sensibilmente la robustezza del frame alla perdita di dati gestendo le relazioni spaziali tra le regioni codificate in ogni slice. Ordinamento arbitrario delle slice (ASO): poiché ogni slice di ciascun immagine può essere decodificata in maniera indipendente dalle altre slice, H.264/AVC permette di inviare e ricevere le slice di un frame in qualsiasi ordine. Questa funzionalità serve per ridurre il ritardo di trasmissione nelle applicazioni in tempo reale, in modo particolare quando si lavora con reti che non mantengono l ordine dei dati inviati (ad esempio le reti basate su IP). Slice ridondanti: per incrementare la robustezza alla perdita dei dati, H.264/AVC prevede la possibilità di inviare delle rappresentazioni ridondanti delle slice, permettendo il recupero di parte delle informazioni visive nel caso in cui la rappresentazione primaria sia stata persa in trasmissione. Partizionamento dei dati: poiché alcune informazioni utilizzate per codificare le immagini sono più importanti in fase di ricostruzione, H.264/AVC prevede che la sintassi di ogni slice sia divisa in tre parti di importanza diversa a seconda del ruolo svolto. Una slice può essere divisa in una partizione A, che contiene l intestazione della slice e i dati relativi ai vettori di moto, una partizione B, con il residuo dei blocchi codificati Intra16x16 e in parte di altri tipi di macroblocco, e una C, con la restante parte del residuo non appartenente alla partizione B. 14

25 2.STANDARD H.264/MPEG-4 AVC Immagini di sincronizzazione SP: H.264/AVC include una nuova funzionalità che permette di utilizzare un particolare tipo di immagini per mantenere o recuperare una esatta sincronizzazione tra bitstream codificati a bit-rate diversi. 2.3 STRUTTURA DELLA CODIFICA VIDEO H.264/AVC Data la grande varietà di applicazioni e dei tipi di reti esistenti, H.264/AVC ha bisogno di un architettura flessibile e facilmente adattabile. Per questo motivo, lo standard è fornito di un Video Coding Layer (VCL), il cui compito è di rappresentare in modo efficiente i contenuti del segnale video, e da un Network Abstraction Layer (NAL), la cui funzione è formattare la sequenza video compressa in uscita dal VCL nel modo più conveniente per ogni layer di trasporto e ogni dispositivo di archiviazione Il Video Coding Layer Figura 9. Struttura della codifica video H.264/AVC. Da [4]. Il Video Coding Layer (VCL) è presente in tutti gli standard dell ITU-T e dell ISO/IEC JTC1 a partire dall H.26L. Esso implementa un meccanismo di codifica ibrido a blocchi in cui ogni immagine è data da un contributo di luminanza e due di crominanza. L algoritmo è detto ibrido poiché si basa su una predizione inter-immagine in grado di sfruttare la ridondanza temporale e su una codifica a trasformate dei residui per ridurre la ridondanza statistica spaziale. Figura 10. Gerarchia delle strutture dati in H.264/AVC. 15

26 2.STANDARD H.264/MPEG-4 AVC Il bitstream generato da H.264/AVC assume una struttura gerarchica con lo scopo di separare entità che nel flusso dati sono indipendenti, migliorando in modo sensibile la resistenza dell algoritmo ad eventuali errori di trasmissione e facilitando i processi di codifica e decodifica. Detta struttura è descritta nella Figura 10. Una sequenza codificata con H.264/AVC è formata da una serie di immagini, dove ciascuna può rappresentare sia un frame completo oppure un field. Generalmente si può considerare che un frame contenga due campi interlacciati, uno inferiore e un altro superiore (corrispondenti con le righe dispari e pari rispettivamente). Se i due campi sono stati acquisiti in due tempi diversi, come avviene in una normale ripresa televisiva, il frame è detto interlacciato, altrimenti si dice che è progressivo (Figura 11). Figura 11. Struttura del frame progressivo e interlacciato. Ogni immagine è frazionata in macroblocchi di dimensione fissa, ognuno dei quali ricopre una regione di 16x16 campioni (pixel) di luminanza e due di 8x8 campioni di crominanza ciascuna. Una serie di macroblocchi elaborati in ordine di Scansione Raster, oppure secondo lo schema di partizionamento Flexible Macroblock Ordering (FMO), si denomina slice. Un immagine può essere composta da una o più slice, com è mostrato nella seguente figura: (a) (b) (c) Figura 12. Suddivisione di un immagine in slice con FMO: (a) disattivo, (b) e (c) attivato. Da [4]. L utilizzazione dello schema FMO permette di usare dei pattern diversi, come slice interlacciate o mappate a modo di griglia a quadri com è specificato nelle Figure 12 (b) e 12 (c). 16

27 2.STANDARD H.264/MPEG-4 AVC Indipendentemente dall uso o meno del FMO, ogni slice può essere codificata con una delle seguenti configurazioni: Slice I: tutti i macroblocchi della slice sono codificati in modalità INTRA. Slice P: i macroblocchi possono essere codificati sia in modalità INTRA sia con un processo di predizione basato sulla stima temporale del moto unidirezionale. Slice B: oltre ai tipi di codifica disponibili per le slice P, si può ricorrere anche alla predizione bidirezionale per la compensazione del moto dei macroblocchi. Slice SP: le slice Switching P sono codificate in modo tale da permettere il passaggio da un immagine a un altra senza seguire l ordine di decodifica. Slice SI: le slice Switching I forniscono una ricostruzione esatta dei macroblocchi. Sono utilizzate per la correzione degli errori o per l accesso casuale all interno del bitstream. Predizione Intra-frame Su ogni campione di un blocco che appartiene a un frame di tipo Intra è effettuata la predizione usando come riferimenti i campioni dei blocchi adiacenti precedentemente codificati. Infatti, per la predizione sono considerati solo i campioni dei macroblocchi superiori o alla sinistra del macroblocco corrente. Questo meccanismo può causare la propagazione d errore in seguito a falli nella trasmissione dell informazione associata alla moto compensazione dei macroblocchi inter. A questo proposito può essere attivata un opzione che permette la predizione a partire dai soli macroblocchi codificati in modalità intra (Constrained Intra Prediction). Predizione Inter-frame Corrisponde a quella effettuata sulle slice di tipo P e B. La codifica Inter utilizza predizione (moto compensazione), prendendo come riferimento immagini in precedenza codificate. Per svolgere la compensazione del moto ogni macroblocco può subire un ulteriore suddivisione in sottoblocchi di varie dimensioni. Lo standard prevede il partizionamento del macroblocco in blocchi di luminanza con dimensione 16x16, 16x8, 8x16 e 8x8. Nell ultimo caso il sottoblocco può essere ulteriormente ripartito in gruppi di 8x4, 4x8 e 4x4 campioni. La Figura 13 riporta le possibili scomposizioni del macroblocco. Figura 13. Suddivisioni del macroblocco per la moto-compensazione. Da [4]. 17

28 2.STANDARD H.264/MPEG-4 AVC Il segnale di predizione di ciascun blocco di luminanza MxN è ottenuto selezionando un area con le stesse dimensioni da un immagine in precedenza codificata, individuata da un vettore di moto che ne indica la traslazione e da un indice abbinato al frame di riferimento. Se, ad esempio, un macroblocco è stato diviso in quattro regioni 8x8, ognuna delle quali è partizionata in sottoblocchi di dimensione 4x4, devono essere trasmessi complessivamente sedici vettori di moto. I valori della crominanza sono sempre ottenuti applicando un interpolazione bilineare. Poiché hanno una risoluzione inferiore a quelli della luminanza, per i campioni croma è necessario un ulteriore raffinamento per avere la stessa risoluzione dei luma. I vettori di moto sono codificati in modo differenziale rispetto alla mediana oppure alla predizione direzionale dei vettori di moto dei blocchi adiacenti. In ogni caso, nessuna componente dei vettori di moto si estende oltre i limiti della slice. Lo standard anche prevede l analisi di più frame di riferimento (multiple reference frames) per il procedimento di stima del moto. È quindi possibile usare più di un immagine decodificata precedentemente come riferimento per la compensazione del moto, come illustrato in Figura 14. Figura 14. Compensazione del moto con frame di riferimento multipli. Il sistema di multiple reference frames richiede che sia il codificatore sia il decodificatore salvino in un buffer di memoria le immagini di riferimento usate per la predizione inter. Il decodificatore mantiene nel proprio buffer gli stessi dati usati dal codificatore seguendo le informazioni di gestione della memoria specificate nel bitstream. Nel caso in cui sono usate immagini di tipo B o bidirezionali, la predizione è fatta usando frame sia passati che futuri, rispetto all ordine cronologico in cui sono stati registrati. La sostanziale differenza tra una slice P e una B è data dal fatto che quest ultima può comprendere blocchi codificati usando la media pesata di due valori di riferimento distinti per ottenere il segnale predetto. Le slice di tipo B usano due distinte liste di frame di riferimento, denominate Lista_0 e Lista_1, che permettono di gestire sia la forward prediction sia la backward prediction. 18

29 2.STANDARD H.264/MPEG-4 AVC Figura 15. Esempi della predizione in un macroblocco di tipo B. (a) one past/one future, (b) two past, (c) two future. Da [5]. Nella Figura 16 è riportato il diagramma a blocchi del complessivo VCL. Il segnale video all ingresso è suddiviso in macroblocchi, i quali a loro volta sono associati alle rispettive slice, ricorsivamente ogni macroblocco di ciascuna slice è processato secondo lo schema. Si può realizzare un efficiente elaborazione in parallelo nel caso di più slice all interno dell immagine. Figura 16. Catena di codifica dei macroblocchi. Da [4]. Nei frame interlacciati con oggetti in moto o con movimenti dell inquadratura, due righe adiacenti tendono ad avere un livello di correlazione ridotta rispetto al caso di frame progressivi. Risulta quindi più vantaggioso comprimere ogni field separatamente. Per fornire un elevata efficienza di codifica, il codificatore in H.264/AVC dispone delle seguenti alternative: Considerare i due field insieme e codificarli come se si trattasse di un singolo frame (modalità frame), anche se i field fanno riferimento a due istanti temporali diversi. Non combinare i due field ma elaborarli separatamente (modalità field). 19

30 2.STANDARD H.264/MPEG-4 AVC Comprimere i due field insieme come se fossero un solo frame, ma per ogni coppia di macroblocchi in verticale stabilire adattativamente se si tratta di blocchi in modalità frame o field. Se la scelta viene limitata alle prime due opzioni, il procedimento prende il nome di codifica picture-adaptive frame/field (PAFF). La terza modalità è invece identificata dalla sigla MBAFF, che sta per codifica macroblock-adptive frame/field. Trasformata e quantizzazione Come già ricordato in precedenza, anche H.264/AVC applica una codifica a trasformata all errore residuo di predizione. Tuttavia l innovazione rispetto agli standard precedenti sta nell uso di blocchi di dimensione 4x4 e di una trasformata intera e separabile, al posto della DCT, con proprietà simili a quelle della trasformata discreta del coseno. Inoltre la trasformata inversa è completamente specificata nello standard e se applicata correttamente non si producono differenze tra i segnali ricostruiti al codificatore e al decodificatore. Per quantizzare i coefficienti della trasformata si ricorre al parametro di quantizzazione QP, che può assumere 52 valori. Il passo di quantizzazione Δ QP è definito in modo tale che l incremento di 1 di QP induce un aumento del Δ QP del 12 % (un aumento di 6 per QP equivale esattamente al raddoppio del passo di quantizzazione). Si può notare che un aumento del 12 % del Δ QP porta a una riduzione del bit-rate del 12 % circa. Codifica entropica In H.264/AVC sono disponibili due tecniche di codifica entropica: CAVLC (Context-Adaptive Variable Length Coding), la quale utilizza codici a lunghezza variabile per codificare i coefficienti risultanti dopo la trasformata e la quantizzazione. CABAC (Context-Adaptive Binary Arithmetic), che permette di migliorare l efficienza della codifica entropica assegnando un numero di bit non intero a ogni simbolo dell alfabeto, procurando ottime prestazioni nel caso di simboli con probabilità maggiore di 0.5. La CABAC assicura una riduzione del bitrate tra il 5 e il 15%, i guadagni maggiori si rilevano per la codifica di segnali televisivi interlacciati. Una conseguenza indesiderata della codifica a blocchi è la creazione di alterazioni nella sequenza ricostruita a bitrate bassi. Il principale e più visibile effetto della distorsione di codifica è la blocchettizzazione. Per questo motivo lo standard H.264/AVC definisce un Filtro Adattativo di Deblocchettizzazione (Adaptive Deblocking Filter), che opera all interno dell anello di predizione. In sintesi il principio di funzionamento consiste nel misurare la differenza tra i valori dei pixel ai bordi di blocchi adiacenti, se questa misura è elevata probabilmente si tratta di un alterazione ed il dislivello deve essere ridotto tramite il filtraggio. Tuttavia, se la differenza tra i valori è così elevata da non poter essere giustificata dall errore introdotto dalla quantizzazione, il bordo quasi certamente ricalca una struttura presente nell immagine originale e non deve essere sottoposto a filtraggio. 20

31 2.STANDARD H.264/MPEG-4 AVC Il Network Abstraction Layer Il Network Abstraction Layer (NAL) è l ultimo passo del processo della codifica di un singolo frame. È stato progettato per permettere di adattare il bitstream codificato ai vari livelli trasporto come RTP/UDP/IP. Il video codificato è organizzato in unità NAL (NALU), ognuna delle quali costituisce effettivamente un pacchetto contenente un numero intero di byte. In H.264/AVC il primo byte di ogni NALU è un byte di intestazione che indica il tipo di dati in esso contenuti, mentre i byte seguenti contengono i contenuti del tipo indicato nell header. I dati contenuti all interno delle unità NAL possono essere intervallati da una serie di Emulation Prevention Bytes, che sono byte con valori specifici inseriti per evitare che nel pacchetto sia accidentalmente generata una particolare sequenza riservata detta Start Code Prefix. Essa è una speciale stringa di tre byte che precede ogni NALU con lo scopo di permettere l identificazione delle singole unità sia attraverso dei pattern prefissati che si trovano all interno dei dati codificati. Così gli estremi delle NALU sono facilmente identificabili dalla presenza di queste parole chiave. Nelle reti basate sui protocolli IP o nei sistemi RTP, i dati sono divisi in pacchetti dal protocollo di trasporto e gli estremi delle unità NAL coincidono con quelli dei pacchetti. Non è quindi necessario dover ricorrere a particolari stringhe di bit identificative. In questi sistemi, infatti, l inclusione di un prefisso all inizio dell unità costituirebbe solo uno spreco delle risorse di rete, perciò le unità NAL vengono inviate senza prefisso. Le unità NAL sono classificate come segue: Unità VCL: Contengono l informazione sulle immagini codificate dal Video Coding Layer (VCL). Unità non-vcl: Riguardano le informazioni addizionali, come per esempio l insieme dei parametri e altri dati supplementari che possono essere inviati nel bitstream (informazioni di sincronizzazione e altre indicazioni non indispensabili per la decodifica delle sequenze video). Un insieme di parametri contiene tutte quelle informazioni che di norma cambiano molto raramente e che sono comuni alla decodifica di un gran numero di NALU di tipo VCL. Esistono due tipi di insiemi di parametri: 1) Insieme dei parametri della sequenza (SPS): si applica a una serie di immagini codificate successivamente. 2) Insieme dei parametri dell immagine (PPS): si applica a una o più immagini all interno di una stessa sequenza video. Questa informazione è trasmessa soltanto quando è necessario; anche si può trasmettere in intervalli regolari per fornire robustezza ai dati codificati. Da altra parte, l informazione supplementare, meglio conosciuta come Supplemental Enhancement Information (SEI), corrisponde a dei dati inviati nel bitstream che non contengono informazione essenziale per il processo di decodifica ma che possono migliorare l utilizzabilità del video decodificato. Ad esempio in questi messaggi si trovano dei dati generati dall utente, informazione di controllo del buffer, ecc. 21

32 2.STANDARD H.264/MPEG-4 AVC Unità di accesso (Access Unit): L insieme di più unità NAL in ordine consecutivo di decodifica prende il nome di unità di accesso e la sua decodifica porta alla ricostruzione di un intera immagine. Figura 17. Procedimento di creazione di un'unita di accesso. Da [4]. All interno di ogni unità di accesso, l insieme delle NALU di tipo VCL costituisce una Primary Coded Picture, e ogni unità NAL a sua volta è costituita dai campioni dell immagine raggruppati in slice. Ci può essere inoltre un Access Unit Delimiter che facilita l individuazione dell inizio dell unità di accesso. Alcune informazioni addizionali (SEI) possono precedere la sezione riguardante l immagine. Poi possono essere inviate ulteriori unità NAL contenenti una rappresentazione ridondante di alcune porzioni critiche (Redundant Coded Pictures) che possono essere sfruttate dal decodificatore in fase di correzione degli errori. Infine, l ultima immagine codificata di una sequenza video può essere marchiata con una speciale NALU detta End of Sequence. Se l immagine codificata è l ultima dell intero flusso di unità NAL, allora può essere presente l identificativo End of Stream. Una sequenza video codificata consiste in una serie di unità di accesso che compongono il flusso di unità NAL. La sezione iniziale è costituita da un unità di accesso detta Instantaneous Decoding Refresh (IDR). L elemento IDR contiene un immagine codificata di tipo Intra, la cui peculiarità è quella di poter essere decodificata senza nessun riferimento alle immagini precedenti. Nessuna immagine successiva può fare riferimento a frame precedenti al IDR. La sintassi del bitstream video è organizzata secondo lo schema proposto nella Figura

33 2.STANDARD H.264/MPEG-4 AVC Profili e livelli Figura 18. Sintassi complessiva del bitstream in H.264/AVC. Da [5]. I livelli e profili erano già presenti negli standard precedenti; la loro funzione principale è quella di garantire l'interoperabilità tra diverse applicazioni. Un profilo definisce un set di funzionalità o algoritmi di codifica che possono essere usati per generare il bitstream mentre un livello impone dei vincoli su alcuni parametri chiave del bitstream. In H.264/AVC esistono quattro profili: 1) Baseline: Supporta tutte le caratteristiche di H.264/AVC tranne quelle descritte nei Set1 e nel Set2. 2) Main: Supporta anche le caratteristiche del Set1. 3) Profile X: supporta sia il Set1 sia il Set2, tranne l algoritmo di codifica entropica CABAC e lo switch adattativo tra codifica a frame o a field. 4) High Profile: supporta tutte le funzionalità descritte nei Set1 e Set2. Dove i due set corrispondono alle seguenti configurazioni: Set1: slice di tipo B, predizione pesata, CABAC, codifica a field, switch adattativo tra frame e la codifica di un field. Set2: slice SP e SI. Nello standard H.264/AVC sono stati definiti undici diversi livelli per ogni profilo supportato; questi definiscono dei limiti superiori per le dimensioni dell'immagine, il rate di elaborazione delle immagini, la dimensione dei buffer e il bitrate della sequenza video. 23

34 2.STANDARD H.264/MPEG-4 AVC 24

35 3 MULTI-VIEW VIDEO CODING (MVC)

36 3.1 INTRODUZIONE 3.MULTI-VIEW VIDEO CODING (MVC) Multi-view Video Coding (MVC) è un estensione descritta all interno dell Annesso H dello standard di compressione video H.264/MPEG-4 AVC menzionato nel capitolo precedente, la quale abilita una codifica efficiente di sequenze catturate simultaneamente da più videocamere usando un unico flusso video supportando particolari funzionalità come l accesso casuale a una certa vista (Random View Access) e la Scalabilità di Viste (View Scalability). MVC è stato sviluppato dal Joint Video Team (JVT) ed è destinato sia alla codifica di video stereoscopico (due viste), nonché a free viewpoint e multi-view 3D television, applicazioni di cui si parlerà in seguito nella sezione APPLICAZIONI DI MVC Il video tridimensionale recentemente ha ottenuto un notevole interesse. Inoltre, grazie ai progressi nelle tecnologie di acquisizione e visualizzazione, il video 3D sta diventando una realtà nel consumatore mercato dell elettronica di consumo. Con l'aiuto del Multi View Coding (MVC) diverse applicazioni sono man mano più fattibili. Le applicazioni al video 3D possono essere raggruppate in tre categorie: Free-viewpoint Video, 3D TV e Teleconferenza Immersiva. I requisiti di queste applicazioni sono molto diversi e ognuna ha le proprie sfide da affrontare. Per illustrare queste sfide, si consideri la Figura 19. In questa immagine, un video multi-view viene prima catturato e poi codificato utilizzando un encoder MVC. Un server trasmette il bitstream codificato a diversi clienti con differenti capacità. Nella fase finale, il video è decodificato e riportato attraverso mezzi diversi a seconda dello scenario applicativo e delle capacità del ricevitore. Figura 19. Architettura dei sistemi MVC. Da [7]. (a) Free Viewpoint Video (b) 3D TV Autostereoscopica per utenti multipli (c) 3D TV Stereoscopica per utente singolo (d) Head Mounted Display (e) 2D HDTV. 26

37 3.MULTI-VIEW VIDEO CODING (MVC) Nel caso di Free-viewpoint Video, lo spettatore può scegliere in modo interattivo la sua posizione nello spazio 3D per osservare una scena del mondo reale dal suo punto di vista preferito. Esso fornisce impressioni molto realistiche e interattive poiché lo spettatore può navigare liberamente in scena entro un certo intervallo, e analizzarla da prospettive diverse. In questo caso ogni scena video è catturata usando un'ampia serie di fotocamere sincronizzate. Un array di questo tipo è mostrato nella Figura 20. Figura 20. Array semi-circolare di camere all'università di Nagoya. Da [8]. Le applicazioni di questa nuova piattaforma possono essere dedicate a diverse aree come intrattenimento, osservazione della natura, turismo, arte, museologia, archiviazione, produzione di contenuti educazionali, medicina, sicurezza, e così via. Lo scenario (a) nella Figura 19 illustra questa applicazione, dove lo spettatore può scegliere fra diverse viste. Nel momento in cui una vista viene selezionata dall utente, essa è visualizzata. In questo scenario, non tutte le viste possibili devono essere decodificate, quindi il decoder può concentrare le proprie risorse solo sulla decodifica della vista richiesta. Da altra parte, 3D TV si riferisce all estensione del tradizionale schema di televisione 2D a uno in grado di mostrare immagini 3D. In questa applicazione più di una vista è decodificata e visualizzata simultaneamente. Una semplice applicazione 3D TV può essere realizzata usando video stereoscopico, la cui visualizzazione può essere ottenuta utilizzando occhiali speciali o altri mezzi per fornire agli occhi dello spettatore due immagini diverse, che rappresentano due punti di vista dello stesso oggetto. Questo è ovviamente ciò che accade con gli esseri umani, in cui i due occhi, essendo a una distanza media di circa 6,5 centimetri, ricevono due viste della stessa area da angolazioni leggermente diverse. Questi due punti di vista hanno molte caratteristiche in comune ma ogni occhio raccoglie informazioni visive che l'altro non riceve. L'ultimo passo è fatto dal cervello, che crea un senso di profondità a partire della fusione di queste due immagini in un impressione tridimensionale. Tuttavia, è più piacevole per l'utente avere la sensazione 3D direttamente attraverso apparecchi auto-stereoscopici in grado di supportare la parallasse 27

38 3.MULTI-VIEW VIDEO CODING (MVC) attraverso la decodifica e visualizzazione di più viste da diversi punti contemporaneamente. Lo spettatore allora può sperimentare una scena leggermente diversa muovendo la testa (per esempio, l'utente può guardare cosa c'è dietro un certo oggetto nella scena). In questo scenario, varie viste devono essere decodificate simultaneamente, pertanto l'elaborazione di esse in parallelo è molto importante. Le Figure 19 (b) e 19 (c) mostrano gli scenari tipici per questa applicazione. La videoconferenza sta diventando sempre più attraente per varie linee di business poiché essa incoraggia la collaborazione distribuita in un mercato globale emergente ed è anche un meccanismo molto importante per il processo decisionale, perciò gli sviluppatori di applicazioni video si sono preoccupati per offrire nuovi servizi ai loro utenti. La naturale evoluzione di questo tipo di ambiente è la Teleconferenza Immersiva, dove quello che si cerca è una forma di collaborazione più attiva e una maggiore efficienza negli incontri online, in cui sia la realtà virtuale sia l'interattività può essere preferita dai partecipanti, cioè qualsiasi delle applicazioni descritte in precedenza può essere supportata. In questo caso i partecipanti da diversi siti geografici possono incontrarsi virtualmente e vedere l'altro sia utilizzando Free-viewpoint Video o 3D TV, quindi i suoi problemi ed esigenze sono ancora esistenti e validi, sommati al fatto di essere un applicazione in tempo reale. Alcune delle sue possibili applicazioni sono le teleconferenze aziendali, la formazione a distanza, e la tele-chirurgia. Figura 21. Blue-c portal, Eidgenössische Technische Hochschule, Zurigo. Nell attualità ci sono alcuni esempi di ambienti per Teleconferenza Immersiva sviluppati da università o centri di ricerca. Uno di questi è il blue-c portal (Figura 21), un ambiente immersivo di proiezione e acquisizione di video 3D pensato per la progettazione virtuale creato all ETH. Esso combina l'acquisizione simultanea di multipli flussi video con un'avanzata tecnologia di proiezione 3D in uno spazio simile a una grotta, creando l'impressione di una totale immersione. La Figura 19 (d) mostra un altro meccanismo che può rendere alle persone sentirsi immerse in un ambiente 3D, conosciuto come HMD (head-mounted display), in cui si ha bisogno di un dispositivo indossato sulla testa, con un piccolo display ottico di fronte a ciascun occhio. 28

39 3.MULTI-VIEW VIDEO CODING (MVC) Poiché le applicazioni della televisione normale 2D o HDTV ancora dominano il mercato, il contenuto MVC offre la possibilità per quei decoder 2D, ad esempio il decoder H.264/AVC nel set-top box (STB) della TV digitale generare una sequenza video in alta definizione da un bitstream MVC, com è mostrato nella Figura 19 (e). Ciò richiede che i bitstream MVC siano compatibili con H.264/AVC. 3.3 CARATTERISTICHE PRINCIPALI A causa dell enorme quantità di dati, in particolare quando il numero di viste da decodificare è grande, le applicazioni per la trasmissione di video MVC si basano fortemente sulla compressione del video catturato dalle telecamere. Una caratteristica molto importante di queste sequenze video multi-view è che contengono una quantità molto ampia d interdipendenze statistiche fra le distinte viste, poiché ogni camera cattura la stessa scena da diversi punti nello spazio. Pertanto, se si combina la predizione temporale usando i frame presi con la stessa camera con quella fatta usando anche dei frame ottenuti dalle camere vicine nello stesso istante di tempo, si può raggiungere una predizione più efficiente, cioè una maggiore compressione. Questo richiede di salvare ulteriori immagini decodificate, però, quando il numero di viste è grande, la memoria richiesta dal buffer può essere proibitiva. Per questa ragione, al fine di rendere efficienti le implementazioni di MVC, il codec deve includere una gestione efficiente della memoria delle immagini decodificate. Con l'eccezione della predizione inter-view, le immagini di ciascuna vista sono codificate con gli strumenti supportati da H.264/AVC. In particolare, la scalabilità temporale gerarchica è risultata essere efficace per la codifica multi-view. Una struttura tipica di predizione per MVC, che utilizza sia la predizione inter-view sia la scalabilità temporale gerarchica, è mostrata nella Figura 22. Figura 22. Struttura di predizione tipica per MVC. 29

40 3.MULTI-VIEW VIDEO CODING (MVC) Nella figura precedente è rappresentata la struttura di predizione per una sequenza MVC catturata usando otto camere. I segnali video sono numerati da S0 a S7 e i valori di T rappresentano diversi istanti di tempo. Le frecce descrivono le dipendenze fra le diverse viste in decodifica. Ad esempio, la vista S0 non dipende di nessun altra vista mentre quella S1 dipende sia dalla vista S0 sia dalla S2. La vista S0 è denominata Vista Base ed è compatibile con H.264/AVC. Le immagini di ciascuna vista sono raggruppate in Gruppi di Immagini (GOP), ad esempio le immagini corrispondenti agli istanti T1 a T8, per ogni vista, formano un GOP. Per consentire la sincronizzazione, ogni GOP comincia con un frame di tipo I (anchor frame). Questi anchor frame sono utilizzati per fornire l'accesso casuale in quanto i frame a loro successivi temporalmente sono privi di alcun riferimento a quei frame che lo precedono temporalmente. Altri aspetti importanti che sono stati requisiti per la progettazione dello standard MVC sono: Scalabilità: la Scalabilità di Viste (View Scalability) e la Scalabilità Temporale sono considerate nella progettazione di MVC per l'adeguamento alle preferenze dell'utente, larghezza di banda della rete e complessità del decoder. La prima è utile nello scenario illustrato nella Figura 1 (a), in cui alcune delle viste non vengono trasmesse né decodificate. Gestione delle risorse del decoder: Negli scenari di 3D TV, come quei mostrati in figura 1 (b) e 1 (c), un certo numero di viste deve essere decodificato e visualizzato, quindi un decoder ottimale in termini di gestione di memoria e complessità è di vitale importanza per rendere possibile la decodifica in tempo reale dei bitstream MVC. Elaborazione in parallelo: Negli scenari 3D TV, poiché varie viste devono essere decodificate simultaneamente, l'elaborazione in parallelo è molto importante per ridurre il tempo di calcolo e supportare decodifica in tempo reale. Accesso Casuale (Random Access): Oltre all accesso temporale casuale, l'accesso a una vista casuale significa supportare l accesso a un qualsiasi frame di una certa vista tramite la decodifica del minimo numero possibile di frame. Ad esempio, nel caso del Free-viewpoint Video, per avere una navigazione senza salti o transizioni questa funzionalità deve essere supportata. Robustezza: Se il flusso di bit MVC viene trasmesso in un canale con perdite deve essere possibile gestire questi errori e se è possibile, correggerli. Lo standard H.264/AVC comprende meccanismi che possono essere usati anche per le applicazioni MVC. In accordo con le funzionalità menzionate prima è possibile pensare a casi in cui non è necessario trasmettere o salvare l intero bitstream, ad esempio quando l utente necessita soltanto della Vista Base. In questo scenario sarà utile eseguire un adattamento del bitstream MVC, e per questo proposito è necessario definire il concetto di Operation Point (Punto d operazione). 30

41 3.MULTI-VIEW VIDEO CODING (MVC) Un Punto d Operazione di un bitstream MVC descrive un certo livello di Scalabilità sia a Viste che Temporale. Esso comprende soltanto le NALU richieste per conformare un bitstream valido che rappresenta un certo sottoinsieme di viste a un certo livello temporale. Un Operation Point può dipendere di altri Punti d Operazione e l informazione sulle sue caratteristiche e interdipendenze è presente nei messaggi SEI riguardanti la Scalabilità di Viste. Figura 23. Punti di Operazione in MVC. (a) Struttura di predizione con 5 viste. (b) Punti d Operazione corrispondenti con la configurazione (a). Per capire questo concetto la Figura 23 (b) presenta i possibili Punti d Operazione corrispondenti alla struttura di predizione riportata in Figura 23 (a). L Operation Point 0 (Op0) permette di decodificare la vista 0; l Operation Point 1 contiene il minimo numero di viste richieste per decodificare la vista 2, ma entrambi la vista 0 o quella 2 sarebbero in grado essere decodificate; il Punto d Operazione 2 contiene il minimo numero di viste necessario per poter decodificare la vista 1, ma, sia la vista 0, 1 oppure quella 2 possono essere decodificate, e così via. 3.4 LA STRUTTURA DEL BITSREAM IN MVC Nello standard H.264/AVC, ogni elemento sintattico è allocato in un pacchetto dati chiamato unità NAL (Network Abstraction Layer). L uso delle NAL permette di adattare il bitstream allo specifico protocollo di trasporto di ogni tipologia di rete. La descrizione dettagliata dello standard si trova in [9]. 31

42 3.MULTI-VIEW VIDEO CODING (MVC) Le unità NAL I dati del video codificato vengono organizzati in Unità NAL (NALU), ognuna delle quali costituisce un pacchetto contenente un numero intero di byte. Il primo byte di ogni unità NAL è un byte d intestazione che indica il tipo di dati in esso contenuti, mentre i byte seguenti contengono i dati a seconda del tipo indicato nell header. Questo primo byte ha il seguente formato: F NRI Type Figura 24. Formato del primo byte di una NALU. F (1 bit): forbidden_zero_bit. Lo standard definisce una violazione nella sintassi se è uguale a 1. NRI (2 bit): nal_ref_idc. Se il suo valore è uguale a 00, indica che il suo contenuto non è usato per ricostruire immagini di referenza per predizioni future. Un valore più elevato indica che la decodifica di questa NALU è necessaria per mantenere l integrità delle immagini di referenza nella stessa vista. Type (5 bit): nal_unit_type. Specifica il tipo di unità NAL. Questa struttura, presa da H.264/AVC, viene rispettata in MVC. Tuttavia, ci sono due classi di unità NAL usate in MVC che hanno una sintassi diversa: quelle di tipo 14 (prefisso), che contengono informazione descrittiva delle NALU VCL di tipo 1 o 5 immediatamente successive, e quelle di tipo 20 (slice codificate che non appartengono alla vista base). Queste NALU speciali sono conformate per 4 byte di header, e un payload variabile R I PRID VID TID A V O Figura 25. Formato dei 3 byte aggiunti alle NALU di tipo 14 e 20 in MVC. R (1 bit): reserved_zero_one_bit. Bit riservato per future estensioni. Deve essere uguale a 0. I (1 bit): idr_flag. Questo bit identifica le unità NAL delle immagini di tipo IDR da una vista diversa a quella base. PRID (6 bit): priority_id. Questo flag è l identificatore della priorità per la NALU. Un valore più basso del PRID indica una priorità più alta. VID (10 bit): view_id. Corrisponde a un identificatore della vista cui appartiene la NALU. 32

43 3.MULTI-VIEW VIDEO CODING (MVC) TID (10 bit): temporal_id. Indica la gerarchia per l applicazione della scalabilità temporale, o in maniera indiretta, il frame rate. Un punto di operazione il quale ha NALU caratterizzate con un valore massimo del temporal_id più piccolo corrisponde a un frame rate più basso rispetto a quello con valori massimi del temporal_id più alti. Dato un temporal layer, questo non può dipendere da un altro che abbia un valore più alto di temporal_id. A (1 bit): anchor_pic_flag. Indica se la NALU corrisponde a un immagine codificata tipo ancora, cioè quella in cui tutte le slice fanno parte della stessa access unit e per la quale tutte le immagini codificate dopo, in ordine d uscita, non usano predizione inter da nessuna immagine prima di essa. V (1 bit): inter_view_flag. Indica se l elemento è usato per predizione inter-view. O (1 bit): reserved_one_bit. Bit riservato per future estensioni. Deve essere uguale a Temporal and View Scalability Una porzione di un bitstream MVC può corrispondere a un punto d operazione caratterizzato per l utilizzo di un certo numero di viste e un certo frame rate. Dati con un frame rate alto, oppure certe viste che non sono state scelte dall utente possono essere troncate sia nel processo di codifica, che di decodifica, per abbassare la complessità. La struttura del bitstream di MVC è caratterizzata da due elementi di sintassi: view_id e temporal_id. Il primo corrisponde all'identificativo di ciascuna vista. Questa indicazione negli header delle NALU permette la sua identificazione al momento della decodifica e l'accesso rapido alle viste decodificate per la visualizzazione. Dall altra parte, l elemento di sintassi temporal_id indica la gerarchia per la scalabilità temporale o, indirettamente, il frame rate. Le immagini codificate con un valore più alto del temporal_id tipicamente dipendono da quelle con valori più bassi all'interno della vista, ma non dipendono da nessuna immagine codificata con maggiore temporal_id. Ogni volta che il punto di operazione contiene solo un sottoinsieme del bitstream intero MVC, come negli scenari (a) e (c) mostrati nella Figura 19, si devono estrarre soltanto le NALU necessarie dal bitstream intero. Il processo di estrazione dal bitstream dovrebbe essere a bassa complessità e non richiedere un analisi molto minuziosa. A tal fine, il mapping tra ogni punto di operazione (identificato dalla combinazione di view_id e temporal_id) e le unità NAL necessarie è specificato come parte del messaggio SEI della scalabilità di viste (View Scalability SEI). Dopo che il punto di operazione è concordato, il server può semplicemente estrarre il sottoinsieme richiesto dal bitstream scartando le unità NAL non richieste controllando tali valori nel suo header. 33

44 3.MULTI-VIEW VIDEO CODING (MVC) 3.5 DECODED PICTURE BUFFER Rispetto a H.264/AVC, il nuovo strumento di compressione implementato in MVC è la predizione inter-view. Questo meccanismo, però, provoca un aumento sostanziale della dimensione del Decoded Picture Buffer (DPB). A seconda dell applicazione per cui MVC sarà usato, ad esempio, una di quelle menzionate nella sezione 3.2, le risorse disponibili possono essere molto differenti, sia in termini di larghezza di banda, che di capacità di memorizzazione, che di tempi attesi di elaborazione, ecc., perciò è desiderabile avere un efficiente gestione del buffer che sfrutti al massimo le risorse a disposizione. Innanzitutto si parlerà dell ordine in cui è fatta la codifica e poi si analizzeranno i requisiti riguardanti la struttura adottata Ordine della Codifica In H.264/AVC, l'ordine in cui le unità NAL sono poste all'interno del bitstream è riferito all'ordine di decodifica. Tuttavia, nel video multi-view, dove due dimensioni, il tempo e la vista, sono coinvolte, diventa più complicato definire la maniera in cui si svolge tale processo. Fondamentalmente sono stati due i modi considerati dal JVT: view-first coding e time-first coding. In view-first coding, sviluppata dal Fraunhofer Heinrich Hertz Institute e prima soluzione per MVC, all'interno di ciascun GOP le immagini di ognuna delle viste sono contigue nell ordine della decodifica, com è mostrato nella Figura 26 dove la direzione orizzontale indica il tempo (ogni istanza temporale è rappresentato da T m ), e la direzione verticale denota la vista (ogni vista è rappresentata dall indice S n ). Figura 26. Schema del View-first Coding. Questo schema di codifica causa un problema rilevante per la memorizzazione dei bitstream multi-view nei file multimediali basati nel formato di file ISO. Le immagini codificate appartenenti a diverse viste, ma con la stessa 34

45 3.MULTI-VIEW VIDEO CODING (MVC) istanza temporale, sono intercalate nel bitstream con immagini di altre istanze, e di conseguenza non appartengono alla stessa unità di accesso. Queste diverse unità di accesso, quando si compongono in un file in base al formato ISO, corrispondono a diversi campioni, richiesti dal formato per essere ordinati secondo il loro ordine di decodifica. Secondo il formato ISO, il tempo di decodifica di un campione è una funzione crescente del numero del campione stesso, e il tempo di composizione (usato anche come tempo di presentazione) di un campione è indicato come un incremento non negativo rispetto al suo tempo di decodifica. Di conseguenza, view-first coding richiederebbe un offset nel tempo di composizione proporzionale alla dimensione del GOP moltiplicato per il numero di viste, che sarebbe percepito come un significativo ritardo iniziale. Inoltre, la possibilità di decodifica parallela sarebbe difficile da realizzare perché i tempi indicati di decodifica e composizione assumono che le operazioni siano svolte da un singolo processore. Per superare i problemi citati e tenendo conto che la struttura di predizione non è legata all ordine di codifica, è stata adottata nello standard MVC un'altra soluzione, sviluppata da Nokia e dalla University of Technology di Tampere, la quale sostituisce l'originale proposta dal FhG-HH. Nel time-first coding, com è stata nominata, le immagini corrispondenti a una certa ubicazione temporale sono contigue nell ordine di decodifica, com è mostrato nella Figura 27. In questo caso è possibile definire un access unit come tutte quelle immagini appartenenti alla stessa istanza temporale anche se fanno parte di diverse viste. Grazie a questa caratteristica, tale soluzione è più conveniente per le applicazioni in tempo reale rispetto a quella precedente. Inoltre, in generale, richiede una dimensione minore del Decoded Picture Buffer. È importante notare che l'ordine di decodifica delle unità di accesso potrebbe non essere identico all'ordine di presentazione. Figura 27. Schema del Time-first Coding. 35

46 3.MULTI-VIEW VIDEO CODING (MVC) Requisiti del DPB I requisiti della dimensione del DPB per il modello di riferimento usato in MVC provengono dalla complessità trovata in H.264/MPEG4-AVC. Poiché il numero di frame al secondo è N viste volte maggiore, rispetto alla codifica di una singola vista, la decodifica in tempo reale deve essere adattata di conseguenza. Per la dimensione minima del DPB, assumendo che sia utilizzata la struttura gerarchica con immagini-b nell asse temporale e ci sia un ritardo minimo causato dall ordine della codifica, i seguenti modelli danno la minima dimensione necessaria per ospitare tutte le immagini di riferimento necessarie, rispetto alla soluzione esaminata (VF per view-first e TF per time-first): Per esempio, nel caso di GOP length = 16 e N viste = 9, le dimensioni del DPB sono 77 e 49, per view-first e time-first, rispettivamente. Tuttavia, dal momento che aumenta il numero di viste, si amplifica la dimensione necessaria del buffer per entrambi i casi. Con un GOP di dimensione fissa, quando il numero di viste è superiore a una certa soglia, lo schema time-first coding ha bisogno di un DPB più capace di quello necessario per view-first coding [8]. 36

47 4 SUPPORTO DEL PROFILO MVC STEREOSCOPICO

48 4.1 INTRODUZIONE 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Nel terzo capitolo si è fatta una breve descrizione del funzionamento e le caratteristiche del Multi-View Video Coding (MVC) senza fare molta attenzione alla quantità di sequenze da codificare (numero di viste). Tuttavia nella pratica, sia per abbassare la complessità sia per le particolarità dell applicazione in cui si vuole implementare questo codec video, diventa necessario limitare questo parametro. Nel caso del video 3D stereoscopico si lavora con due sequenze, le quali coincidono con le immagini che vedranno gli occhi sinistro e destro rispettivamente. In maniera corrispondente, nel profilo stereoscopico di MVC implementato, si usano soltanto due sequenze, conservando una struttura di predizione conforme a quella riportata nello schema generale per MVC nella Figura 22, se si prendono due viste alla volta, ad esempio, soltanto prendendo le viste S0 ed S2. Oltre a quanto si è discusso finora, è importante segnalare che in questo profilo si mantengono molti meccanismi e algoritmi utilizzati nell implementazione dello standard H.264/AVC per un unica sequenza video. Infatti, anche se altri cambiamenti devono essere fatti rispetto a un codificatore H.264/AVC, prendendo come riferimento il suo schema generale, i blocchi principali da modificare sono la gestione del Decoded Picture Buffer (DPB) così come il blocco che svolge la predizione di tipo INTER, evidenziati nella Figura 28. Di questo argomento si tratterà in profondità nelle sezioni 4.3 e 5.3 di questo elaborato che corrispondono all implementazione del MVC Stereo Profile nel codificatore HENC 8.3 proprietario di STMicroelectronics, e all ottimizzazione dell algoritmo SLIMH264 per la stima del moto, rispettivamente. Figura 28. Diagramma semplificato di un codificatore MVC stereoscopico. Poiché lo scopo principale di questo elaborato sono le applicazioni in tempo reale, la struttura di predizione usata per lo svolgimento della maggior parte delle prove è stata quella mostrata nella Figura 29. In questo caso non sono usate le immagini di tipo B (bidirezionali) e soltanto si prendono come riferimento, per fare la predizione, un unico frame codificato in precedenza oltre a quello appartenente alla stessa istanza temporale, nel caso in cui si stia codificando un frame della seconda vista. L oggetto di queste restrizioni corrisponde con il fatto 38

49 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO che, in tempo reale, non è possibile avere come immagine di riferimento un frame futuro. Inoltre cercando di ridurre al massimo sia la lunghezza del DPB sia la complessità conviene usare soltanto un frame di riferimento. Nella sezione si daranno più dettagli e si mostreranno alcune prove per sostentare questa scelta. Figura 29. Struttura di predizione tipica per applicazioni in tempo reale. 4.2 SUPPORTO NEL SOFTWARE DI RIFERIMENTO JM 17.2 Il codificatore video JM è un software messo a disposizione dal JVT, aggiornato costantemente con le nuove funzionalità sviluppate. Sul sito è possibile scaricare tutte le versioni ed anche la documentazione ufficiale per la loro utilizzazione. Dalla versione JM 17.0 rilasciata a Marzo 2010, il software JM è capace di supportare la codifica di Video Stereoscopico. Per la preparazione di questo elaborato è stata presa come riferimento una versione antecedente, cioè la 16.2 rilasciata a Novembre 2009, e sono state osservate le modifiche apportate al codice, rispetto alla versione più recente, la JM 17.2 del Gennaio 2011, per capire com è stato realizzato questo sviluppo. Tuttavia, non tutte le variazioni trovate hanno l obiettivo desiderato. Alcune corrispondono a cambiamenti nel nome delle variabili o delle funzioni, a trasformazioni o estensioni di quelle esistenti, come per esempio il supporto del formato TIFF come formato d ingresso/uscita delle immagini, oppure alla correzione degli errori riportati per gli utenti. Poiché lo scopo di questa tesi è stato l implementazione del profilo Stereo MVC, si farà riferimento solo alle modifiche individuate che abbiano tale finalità. Innanzitutto si enumerano i diversi tipi di modifiche che sono state ricavate nel software di riferimento dopo averne esaminato il codice 1. 1) Abilitazione del supporto della nuova funzionalità e creazione di un flag che renda facile capire il suo inserimento nel codice (MVC_EXTENSION_ENABLE), tutto ciò trovato nel file defines.h. Inoltre, sono state definite due costanti per identificare i due profili che supportano la codifica stereoscopica ( Multiview High" e Stereo High ). 1 Nell appendice B sono elencate e ordinate per tipo le modifiche trovate nei file corrispondenti al software JM 17.2 mostrando le linee in cui sono state fatte, così come una referenza alla struttura dati, funzione o file a cui appartiene. 39

50 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO 2) Definizione di alcune variabili globali necessarie per registrare sia le statistiche del processo di codifica, sia quelle pertinenti ai calcoli delle metriche di distorsione. Sono anche state create alcune strutture dati per gestire e salvare delle caratteristiche proprie della sequenza video e concernenti la seconda vista (global.h ed enc_statistics.h). 3) Estensione, nel file params.h, dei parametri d ingresso riguardanti il profilo Stereo di MVC che potranno essere elencati per l utente del software nel file di configurazione per settare la codifica usando due viste della stessa sequenza video, ed anche la loro introduzione nella mappa generale delle caratteristiche, struttura dati in cui si salvano le preferenze dall utente, nel file configfile.h. 4) Valutazione del profilo da usare per la codifica, che è stato selezionato da parte dell utente nel file *.cfg (conformance.c), così come della compatibilità fra i parametri d ingresso con le scelte di configurazione desiderate (configfile.c). Nel caso in cui il programma trovi delle incompatibilità, sono lanciati diversi messaggi di errore che servono per chiarire i cambiamenti che devono essere fatti nel file di configurazione per il suo corretto funzionamento. 5) Cambiamenti delle strutture dati, nel file img_dist_snr.c, in cui sono salvati i calcoli che si riferiscono alle metriche di SSE (Sum of squared error) e PSNR (Peak Signal-to-Noise Ratio) nel caso che sia abilitato il profilo Stereo di MVC e si utilizzino due viste per fare la codifica (i conteggi però non sono modificati, soltanto sono copiati al posto adeguato). 6) Inserimento, in alcuni istruzioni if trovate nelle funzioni poc_ref_pic_reorder_frame_default e poc_ref_pic_reorder_field definite nel file list_reorder.c, di una condizione addizionale quando è usato il supporto per MVC. In questo caso detta condizione permette di verificare se si sta lavorando con un unica sequenza video (num_of_views == 1), oppure nel caso in cui si usano due viste, se il frame o il field che si sta prendendo come riferimento appartiene alla stessa vista della quale fa parte la slice in ingresso. 7) Per supportare le unità NAL usate nell estensione MVC, oltre alla definizione dei campi aggiuntivi di cui si ha bisogno (nalucommon.h), i quali sono stati descritti nella sezione precedente, sono stati anche annessi nuovi parametri in funzioni esistenti, com è il caso di GenerateSeq_parameter_set_rbsp nel file parset.c in cui è stato aggiunto un campo che permette di identificare se la NALU da codificare fa parte di una sub sequenza di viste, cioè in pratica se corrisponde o no alla seconda vista, visto che nel profilo MVC stereo si hanno al massimo due viste. Inoltre, nello stesso file, sono state aggiunte verifiche della correttezza del profilo selezionato (MULTIVIEW_HIGH e STEREO_HIGH sono ora 40

51 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO inclusi nella lista dei profili validi) ed è stata definita una nuova funzione, GenerateSubsetSeq_parameter_set_NALU, la quale serve per generare una NALU che contiene i parametri della sequenza mettendo particolarmente NALU_type = 15, che corrisponde a una sub sequenza. Altresì sono stati trovati alcuni cambiamenti riguardanti la scrittura della NALU nel formato ANNEX B (poiché si devono scrivere tre byte in più nel caso delle NALU di tipo 14 e 20). Nel file filehandle.c, che contiene le funzioni per aprire i file d uscita del codificatore e la generazione degli header delle sequenze, sono state inserite alcune istruzioni per la creazione delle NALU corrispondenti alle sub sequenze, nel caso in cui si usino due viste, e inoltre sono salvate le statistiche corrispondenti nella struttura dati adeguata. 8) Complemento del file dove sono riportate le statistiche della codifica utilizzando i calcoli realizzati lungo l esecuzione del programma, avendo conto dei dati presi dalla seconda vista. Per fare questo, sono creati nuovi puntatori che vengono indirizzati alle statistiche calcolate in precedenza, i quali poi sono usati per la scrittura dei dati nel file *.stat. 9) Verifica nel file mmco.c, in cui sono descritte le Management Memory Control Operations (MMCO) (ovvero routine per la gestione del buffer delle immagini decodificate), del caso in cui si lavora con due viste al momento di calcolare il numero del frame corrente e scriverlo tramite la funzione poc_based_ref_management_frame_pic. Se il profilo usato supporta MVC, detta quantità dovrà essere calcolata in un altra maniera, cioè non sarà più uguale a current_pic_num - pic_num 1, ma l offset diventerà (current_pic_num - pic_num)/2 1 dato il fatto che il frame che deve essere segnalato non sarà più alla stessa distanza temporale dal precedente, ma corrisponderà a quella ridotta espressa nella seconda formula (nel caso di due viste). 10) Definizione, nel file header.c, della funzione mvc_ref_pic_list_reordering per gestire la sintassi del bitstream corrispondente al riordinamento della lista delle immagini riferimento nel caso in cui sono usate due viste ed è attiva la scelta MVCInterViewReorder. Sono gestite in questa maniera tutte le slice di tipo P e di tipo B quando è usato il profilo Stereo MVC. Sono state trovate, sempre nello stesso file, modifiche nell header della slice quando si lavora con due viste (funzione SliceHeader). 11) Nel file lencod.c sono state rilevate le seguenti modifiche: a) Nella funzione init_encoder, quando sono usate le due viste, si procede in primo momento alla verifica dell apertura del file corrispondente alla seconda sequenza video. In seguito, sono inizializzate le strutture dati a essa corrispondenti con la sua conseguente allocazione in memoria. 41

52 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO b) Nella funzione encode_sequence è stato ricalcolato il numero dei frame da codificare: poiché si sono usate due viste, questo sarà due volte quello indicato dall utente nel file di configurazione. Inoltre per ogni singolo frame da codificare, si deve verificare se nella struttura di predizione devono essere aggiunti riferimenti ad altri frame. Anche nel caso in cui siano usate due viste, si deve fare una correzione nel suo indice di riferimento, giacché questa volta due immagini diverse avranno lo stesso FrameNumber (uno per ogni vista). c) Nelle funzioni init_img e init_global_buffers sono dati i valori iniziali di alcune variabili ed è allocata la memoria dei buffer in cui saranno messi i frame corrispondenti alla seconda vista. d) Nelle funzioni free_encoder_memory e free_global_buffers sono state aggiunte le istruzioni per liberare la memoria utilizzata per le strutture riguardanti alla seconda vista quando è attivo il profilo stereo MVC. 12) Nel file pred_struct.c: a) Nelle funzioni init_seq_structure sono dati i valori iniziali di alcune variabili ed è allocata la memoria dei buffer concernenti le strutture di predizione. b) Sono state definite due nuove funzioni, populate_frm_struct_mvc e copy_frame_mvc, il cui proposito è riempire i buffer in cui sono salvati i frame nel caso in cui sia usato il profilo MVC con due viste, poiché è necessario copiare l informazione concernente a ogni singolo frame per sviluppare sia la predizione sia la codifica. Sono referenziate dalla funzione encode_sequence trovata nel file lencod.c. 13) Nel file image.c sono state trovate molteplici modifiche: a) Nella funzione writeout_picture, quando è attivo il flag MVC_EXTENSION_ENABLE, è stato aggiunto il parametro is_bottom che permette la scrittura delle unità NAL di tipo prefisso corrispondenti alla prima vista nel caso in cui le partizioni della slice che si sta scrivendo non siano vuote. b) Si definiscono due nuove funzioni che servono per scrivere il frame codificato sia come un unica immagine (write_non_vcl_nalu_mvc), sia come un immagine interlacciata, cioè a due campi (write_el_field_vcl_nalu) quando è usato il profilo MVC e si lavora con le due viste. c) Nella funzione encode_one_frame, molte istruzioni che nella versione precedente erano fatte al suo interno sono rimpiazzate per funzioni nuove, com è il caso delle funzioni: read_input_data, perform_encode_field, perform_encode_frame, write_frame_picture, free_slice_data, store_coded_picture, update_video_stats, 42

53 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO update_bitcounter_stats e update_idr_order_stats. In queste funzioni anche sono stati messi i processi riguardanti alla seconda vista. d) Sono state modificate anche le funzioni che generano i report sullo schermo a seconda del valore di verbose desiderato. 14) Nel file md_low.c, in cui è definita la funzione encode_one_macroblock_low, è stata modificata una linea che forza la codifica Intra nel caso in cui le liste delle immagini di riferimento siano vuote, sempre nel caso in cui sono usate due viste. 15) Modifica dei buffer dei frame utilizzati per fare la codifica: a) Completamento dei parametri riguardanti la seconda vista nelle strutture dati: StorablePicture, Frame Store e DecodedPictureBuffer. Sono stati anche definiti i prototipi di tre funzioni già definite nella versione precedente che si possono trovare nel file mbuffer.c. b) Accomodamento della dimensione del DPB nel caso in cui sono usate due viste. Sono state modificate anche le funzioni che permettono allocare la memoria delle strutture dati presenti al suo interno (FrameStore, StorablePicture). c) Sono state definite tre funzioni: update_pic_num, init_lists_p_slice, init_lists_b_slice, chiamate dalla funzione init_slice, le quali sono usate per aggiornare i campi all interno della struttura dati Slice attualmente a codificare. d) Sono state fate delle piccole modifiche a quattro funzioni: update_ref_list, update_ltref_list, idr_memory_management, ed sliding_window_memory_management che servono per gestire le liste dei frame di riferimenti nel DPB. In più sono state modificate le funzioni store_picture_in_dpb e insert_picture_in_dpb, che controllano l inserimento delle immagini nel buffer quando sono usate due viste. In particolare, sono assegnati i valori dei flag inseriti nella struttura StorablePicture per il supporto del profilo Stereo MVC. 16) Modificazioni della struttura slice: a) Aggiunta dei campi addizionali alle NALU riguardanti le slice. b) Inizializzazione di alcuni campi concernenti al profilo Stereo MVC. c) Sono state modificate le funzioni init_slice e init_slice_lite che servono per inizializzare i parametri delle slice e per l allocazione in memoria di quelle già codificate. 43

54 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO 4.3 IMPLEMENTAZIONE NEL CODIFICATORE HENC Il codificatore HENC 8.3 sviluppato per STMicroelectronics su cui si è fatta l implementazione del profilo MVC Stereoscopico è un encoder software H.264/AVC compatibile con JM Detta implementazione segue lo schema a blocchi di un generico codificatore MVC Stereoscopico riportato nella Figura 28. Come ingresso al codificatore si considerano due sequenze video non compresse in formato RAW. I parametri di configurazione dati dall utente sono importati al codificatore, com è anche fatto per JM 16.2, attraverso un file di configurazione *.cfg in cui è possibile gestire i diversi meccanismi trovati al suo interno 2. Finalmente, come uscita, si avranno un file compresso *.264 compatibile con lo standard video H.264/AVC, un file in cui saranno riportate le statistiche della codifica, e facoltativamente, le due sequenze video ricostruite dal codificatore anche in formato RAW Il file di configurazione Com è menzionato prima, nel file di configurazione è possibile amministrare tutte le funzionalità del codificatore. Con lo scopo di conservare la compatibilità con il codificatore video H.264/AVC e per gestire il suo funzionamento quando il profilo Stereo MVC è attivo, si sono aggiunti alcuni parametri: Figura 30. Parametri rilevanti a MVC aggiunti nel file *.cfg. MVCNum_of_views indica il numero di sequenze video da codificare e può assumere soltanto i valori 1 o 2. MVCInterViewReorder permette di abilitare il riordinamento delle liste delle immagini di riferimento quando si esegue la predizione inter-vista. Nella sezione si approfondirà sul funzionamento di questo strumento. MVCFlipViews cambia la maniera in cui sono scritte le NALU nel formato AnnexB, particolarmente modificando il campo view_id. In questo scenario il decodificatore ricostruisce le due sequenze video nell ordine opposto in cui sono state codificate, così facendo, la seconda sequenza diventa la prima vista e viceversa. 2 Nell appendice A sono descritti i parametri più rilevanti che si possono trovare nel file di configurazione *.cfg corrispondente al codificatore video JM 17.2 mostrando la loro utilizzazione per gestire la codifica. 44

55 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO MVCEnable_inter_view_flag abilita l uso delle immagini di tipo B appartenenti alla prima vista per essere usate come riferimenti al fare la predizione nella seconda vista. MVCInterViewPredFlag serve per controllare uno strumento aggiunto in questo codificatore che disabilita la predizione intervista, lasciando inalterata il resto della struttura di predizione. In questo caso è possibile svolgere le cosiddette simulazioni di tipo Simulcast e fare un vero confronto dei vantaggi dell utilizzazione delle immagini di un altra sequenza video come riferimenti per la predizione del moto. Inoltre è stato aggiunto il profilo 118, nominato Multiview High, che corrisponde al profilo MVC Stereoscopico MVCInterViewReorder Secondo lo standard H.264/AVC, le liste con le immagini di riferimento usate per svolgere la predizione sono ordinate d accordo al suo numero di Picture Order Count (POC), 3 collocando al primo posto quella con il valore più alto e continuando d accordo con la sua diminuzione. Tuttavia, tenendo conto che immagini appartenenti alla stessa istanza temporale avranno lo stesso valore del POC, è necessario definire come ne saranno gestite all interno delle liste dei frame usate per la predizione inter-view. Lo standard MVC utilizza diversi meccanismi denominati di Reference Picture List Reordering (RPLR) che incrementano l efficienza della codifica al consentire che immagini più correlate con il frame corrente siano messe negli indici più bassi della lista di riferimento. In particolare, nel caso della implementazione del codificatore di video stereoscopico, si è definito lo strumento MVCInterViewReorder, che consiste in una serie di istruzioni di RPLR riguardanti la predizione inter-view. (a) (b) Figura 31. MVCInterViewReorder. (a) Spento, (b) attivo. 3 Picture order count (POC), è una caratteristica inclusa nello standard video H.264/AVC che serve per conservare isolato sia l ordine delle immagini sia i valori dei campioni nei frame decodificati dall informazione temporale. Questo consente che essa sia inviata, controllata e cambiata separatamente per un sistema senza affettare il contenuto delle immagini decodificate. Il suo valore è usato per calcolare un parametro che permette di gestire sia immagini precedenti che successive nella predizione temporale. 45

56 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Quando si realizza la codifica di un frame che fa parte della seconda vista e MVCInterViewReorder è attivo, la lista dei frame di riferimento viene riordinata, impostando in questo caso che l immagine della prima vista corrispondente alla stessa istanza temporale sia situata al primo posto della lista, davanti a quella con il valore del POC più alto. In ogni caso, anche se si usa questa immagine come riferimento, per svolgere la predizione sarà inoltre tenuto in conto un numero di immagini pari a quello messo per l utente come RefFrmNum nel file di configurazione, mentre esse siano disponibili. Nella Figura 31 è possibile osservare un esempio: in questa configurazione, si assume che l utente abbia messo 1 come numero dei frame di riferimento. Nello scenario (a), in cui MVCInterViewReorder è spento, per la seconda vista soltanto il primo frame sarà predetto utilizzando come riferimento uno della prima vista, mentre tutti gli altri useranno soltanto quelli appartenenti alla seconda. D altra parte, nello scenario (b) in cui viene attivo lo strumento menzionato prima, per ogni frame, oltre a uno della seconda vista, sarà tenuto come riferimento quello che appartenga alla stessa istanza temporale nella prima vista. Si veda come questo ultimo caso corrisponde con la struttura di predizione tipica per applicazioni in tempo reale riportata nella Figura Gestione del DPB Quando si svolge la codifica di una sequenza MVC, si devono salvare i frame già codificati necessari a questo scopo, almeno fintanto che essi siano usati nella struttura di predizione. Tuttavia, com è stato discusso in precedenza nella sezione 3.5.2, la dimensione ottima del DPB dipenderà soltanto dal numero di viste da codificare e dal numero massimo dei frame di riferimento disponibili nel codificatore. Con base in questa considerazione e tenendo conto che non è possibile salvare tutti i frame man mano si esegue la codifica, si sono introdotti diversi algoritmi che servono per ottimizzare l utilizzazione del buffer. Innanzitutto, nel codificatore HENC, si è fissata la dimensione del DPB secondo le seguenti relazioni: Dove le equazioni (1) e (2) corrispondono a sequenze in cui non siano usate le immagini di tipo B, o nelle quale esse vengano utilizzate, rispettivamente. In (1), il termine MAX_REF_FRAMES fa riferimento al numero massimo di frame di riferimento per la predizione, mentre in (2), il termine corrisponde al valore massimo fra 3 e il numero di frame di riferimento scelto per l utente nel file di configurazione. Nel codificatore HENC, il valore MAX_REF_FRAMES è impostato come cinque, quindi se si utilizzano soltanto immagini di tipo I e P, la dimensione massima del DPB sarà costante e uguale a undici. (1) (2) 46

57 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Tenendo conto di questi limiti, si sono inclusi alcuni strumenti che servono per gestire i frame salvati nel DPB. Per aiutare a capire il suo funzionamento, si mette a disposizione un esempio, il quale usa la struttura di predizione riportata nella Figura 32, con i seguenti parametri di configurazione: IntraPeriod = 2 NumBPictures = 2 NumRefFrames = 2 Figura 32. Struttura di predizione utilizzata per l'esempio. Nell esempio mostrato, rimpiazzando nella formula (2), si ricava che la dimensione massima che può avere il buffer è uguale a 7. Ogni volta che la dimensione del DPB arriva al massimo prestabilito, come succede nell esempio dopo che si fa la codifica del frame indicato nella Figura 32 con il numero 7, si seguono i passi descritti qui di seguito: 1) Prima, si prova a rimuovere dal DPB il primo frame che non sia segnato come di riferimento. Nella Figura 33, in cui si è mostrato il riempimento del DPB, si evidenzia con il numero 1 il frame che è stato tolto dopo la codifica del frame numero 7. 2) Dopodiché si cerca negli altri frame salvati nel DPB se ce n é qualcuno che, essendo marcato come di riferimento, non sarà più usato nella codifica, e si assegna a questi il flag out. Questo è messo in evidenza nella Figura 33 con il numero 2, in cui i primi due frame codificati, cioè quelli marcati con i numeri 0 e 1 nella Figura 32, saranno pronti per uscire, dal momento che non saranno più usati nella codifica dei frame successivi. 3) Nei passi di codifica seguenti, come evidenziato con il numero 3 nella Figura 33, il primo frame marcato con il flag out identificato dal codificatore esce dal DPB. Questo passo si ripete finché non ci saranno più frame marcati, dopodiché si tornerà nuovamente al passo 1. 47

58 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Figura 33. Gestione del DPB. 48

59 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Informazioni addizionali Nel caso del codificatore implementato, con lo scopo di verificare la correttezza nel suo funzionamento e volendo, a volte, dati specifici riguardanti la codifica, si è implementato uno strumento che permette di visualizzare le liste dei frame di riferimento usati per eseguire la predizione di tipo INTER. Figura 34. Funzionamento dello strumento PRINTREFLISTS Nella Figura 34 si vede un esempio del suo funzionamento. Nel caso in cui è attiva questa opzione, l informazione della codifica di ogni frame riportata sullo schermo sarà completata con la visualizzazione sia della lista LIST_0 se è un frame di tipo I o P, oppure di entrambi le liste LIST_0 e LIST_1 se il frame corrente è di tipo B. 4.4 ANALISI DELLE PRESTAZIONI DEL CODIFICATORE Di seguito sono riportate alcune simulazioni che mostrano il funzionamento del codificatore per video stereoscopico sviluppato. Sono analizzate diverse sequenze video di test con risoluzioni e contenuti in termini di movimento differenti, in modo da fornire una panoramica delle sue prestazioni. Tutte le simulazioni mostrate nel seguito sono state implementate con il Codificatore HENC modificato (compatibile con JM 17.2) proprietario di STMicroelectronics, su una macchina con processore P8600 (Intel Core 2 Duo a 2,4 GHz). Ogni sequenza è stata codificata a bit-rate variabile, cioè mantenendo il passo di quantizzatone fisso, per vari valori di QP, testando, a seconda della prova, un numero variabile di frame di riferimento, diversi valore del IntraPeriod, o diverse configurazioni. I risultati ottenuti sono analizzati attraverso le curve ottenute riportando il PSNR luma mediato sui frame codificati ed il relativo bitrate in corrispondenza dei diversi valori di QP per la seconda vista. Inoltre si sono considerate le prestazioni in tempo dell encoder riguardanti la codifica completa. Per ogni prova saranno riportati i valori dei principali parametri di configurazione, illustrati di maniera più approfondita nell Appendice A. Per confermare il corretto funzionamento dell encoder sarà usato il decodificatore JM 49

60 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO 17.2, anche rilasciato dal JVT. Nella Figura 35 è riportata l uscita del decodificatore per la configurazione usata come esempio della gestione del DPB (Figura 32). Figura 35. Decodificatore JM Analisi delle prestazioni di MVCInterViewReorder Le sequenze video usate per questa prova sono Akko&Kayo (Figura 36), caratterizzata por una quantità media di moto, e Ballroom (Figura 38), più movimentata e dalla quale saranno osservate 3 sequenze differenti ottenute combinando le immagini prese per 6 camere diverse. In questa prova saranno testate tre configurazioni diverse: Simulcast, in cui le due viste sono codificate separatamente, MVCInterViewReorder = 0 e MVCInterViewReorder = 1, per ognuna dei quali si eseguirà la codifica con valori di QP uguali a [22, 27, 32, 37]. Ogni sequenza sarà testata con un metodo di codifica entropica diversa (CAVLC per Akko&Kayo e CABAC per Ballroom). L algoritmo utilizzato per la stima del moto sarà Full Search e il valore dell IntraPeriod uguale a 0, in altre parole, soltanto la prima immagine della vista base sarà codificata tipo I, mentre le restanti saranno di tipo P. In tutte le simulazioni sono attive tutte i modi di codifica INTRA ed INTER (da 16x16 a 4x4). 50

61 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Sequenza Akko&Kayo Figura 36. Sequenza 30 fps I principali parametri di configurazione per questa sequenza sono: Tabella 4. 1: Sequenza Akko&Kayo (Full Search) QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,928 43, ,474 43,081 2,82-0, ,540 43,189 7,18 0, ,654 40, ,802 40,039 5,21-0, ,984 40,364 4,08 0, ,406 36, ,556 36,687 7,26-0, ,204 37,238-6,45 0, ,240 33, ,036 33,597 9,14-0, ,670 34,180-27,10 0,501 Come si può notare nella Figura 37, a parità di bit-rate, la configurazione MVCInterViewReorder = 0 fornisce un guadagno di circa db rispetto alla simulazione Simulcast, raggiungendo un incremento del PSNR di circa 0.5 db, per bit-rate bassi. Da un altra parte, sempre rispetto alla simulazione Simulcast, MVCInterViewReorder = 1 fornisce un guadagno di circa db, quasi costante, per valori del bit-rate intermedi e alti. 51

62 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Figura 37. PSNR vs Bit-Rate. Sequenza Akko&Kayo (Full Search) Nella Tabella 4. 1, così come in quelle elencate in seguito, si osservano, per alcuni valori del passo di quantizzazione, il bit-rate e il PSNR luma medio nella sequenza video corrispondenti alla seconda vista, la riduzione percentuale del rate e la variazione percentuale del PSNR rispetto alla configurazione Simulcast, per le due possibile scelte di MVCInterViewReorder in confronto. Si noti come per QP = 37, che corrisponde con il valore più basso del bitrate, la configurazione che non svolge l algoritmo di reordering raggiunge il guadagno massimo (9.14%), mentre in quella in cui è attivo questo strumento, si ottiene il peggiore scenario, con un aumento del rate di circa il 27%, fenomeno percepibile dall incrocio delle curve nella Figura 37. Sequenza Ballroom Figura 38. Sequenza 25 fps I principali parametri di configurazione per questa sequenza sono: 52

63 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Sequenza Ballroom 0-1 Tabella 4. 2: Sequenza Ballroom 0-1 (Full Search) QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,025 40, ,550 40,392 1,31-0, ,120 40,433 3,01 0, ,370 37, ,710 37,536 3,35-0, ,410 37,673 2,33 0, ,520 34, ,370 34,638 5,34-0, ,005 34,933-0,40 0, ,485 32, ,695 31,875 7,32-0, ,555 32,297-10,95 0,115 Nella Tabella 4. 2 si osserva come questa sequenza ha un comportamento simile a quanto si è trovato per la sequenza Akko&Kayo. Infatti, con QP = 37 si ottiene una diminuzione del rate di 7.32% per MVCInterViewReorder = 0 di fronte a un incremento del 10.95% per MVCInterViewReorder = 1. Figura 39. PSNR vs Bit-Rate. Sequenza Ballroom 0 1 (Full Search) 53

64 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Dalla Figura 39 si può osservare come in questo caso il guadagno in prestazioni ottenuto con MVC non è molto alto per queste le sequenze testate, di fatto, con MVCInterViewReorder = 0 al massimo si ottiene un miglioramento di circa 0.1 db, mentre per MVCInterViewReorder = 1, si consegue un aumento medio del PSNR di circa 0.2 db; tuttavia, le curve presentano lo stesso comportamento apprezzato nella simulazione fatta con Akko&Kayo per valori bassi del bit-rate. Sequenza Ballroom 3-4 Tabella 4. 3: Sequenza Ballroom 3-4 (Full Search) QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,220 40, ,455 40,515 2,03-0, ,685 40,560 8,97-0, ,665 37, ,740 37,547 4,37-0, ,670 37,665 13,27 0, ,850 34, ,610 34,506 6,44-0, ,235 34,725 13,57 0, ,915 31, ,605 31,694 8,35-0, ,735 32,003 5,31 0,165 Sequenza Ballroom 6-7 Figura 40. PSNR vs Bit-Rate. Sequenza Ballroom 3 4 (Full Search) Tabella 4. 4: Sequenza Ballroom 6-7 (Full Search) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR QP [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,880 40, ,015 40,473 1,73-0, ,255 40,503 7,94-0, ,305 37, ,310 37,432 3,37-0, ,500 37,500 11,57-0, ,750 34, ,615 34,229 4,70-0, ,615 34,368 10,00-0, ,865 31, ,605 31,312 6,93-0, ,835 31,505 0,67-0,136 54

65 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Figura 41. PSNR vs Bit-Rate. Sequenza Ballroom 6 7 (Full Search) Le sequenze video Ballroom 3 4 e Ballroom 6 7 hanno un comportamento molto simile nel caso in cui MVCInterViewReorder = 1, com è possibile vedere nella Figura 40 e nella Figura 41, raggiungendo un guadagno massimo di circa 0.9 db nel caso della prima sequenza (Ballroom 3 4) e pari a 0.7 db nella seconda. Quando MVCInterViewReorder = 0, le prestazioni sono superiori in Ballroom 3 4, con un incremento medio del PSNR di db contro quello ottenuto in Ballroom 6 7 pari a 0.1 db. Dai dati acquisiti testando le quattro sequenze video MVC presentate in precedenza, si rileva un notevole miglioramento delle prestazioni raggiunte con l implementazione dell algoritmo di riordinamento delle liste delle immagini di riferimento (MVCInterViewReorder) rispetto a un implementazione che non usi tale strumento. In termine di PSNR il guadagno è più apprezzabile, particolarmente con valori alti e medi del bi-rate, e si aggira intorno a 0.6 db, secondo la quantità e natura del moto nel video e la calibrazione delle camere con cui essi sono ottenuti. Rispetto alla simulazione di tipo Simulcast, si osserva un notevole miglioramento, com era sperato, dall utilizzazione della predizione inter-view e la stima della disparity come strumenti per ottimizzare la codifica. Tuttavia è opportuno valutare l impatto dell utilizzazione dello strumento MVCInterViewReorder sotto il profilo della complessità computazionale, poiché, si deve raddoppiare il numero di operazione eseguite per la codifica di tipo INTER nella seconda vista. A tale scopo nelle tabelle di seguito si mettono a confronto i tempi di codifica con l algoritmo esaustivo Full Search per i tre casi riportati prima, mettendo in evidenza l incremento medio, rispetto alla prova Simulcast. 55

66 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Tempi di codifica per le simulazioni delle sequenze Akko&Kayo e Ballroom Tabella 4. 5: Tempi di codifica Akko&Kayo (Full Search) Akko&Kayo_26 & Akko&Kayo_27, 30 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] , , , , , , , , , , , , , , ,912 Valore medio 1,42 50,64 Δt [%] Tabella 4. 6: Tempi di codifica Ballroom 0 1 (Full Search) Ballroom_0 & Ballroom_1, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] , , , , , , , , , , , , , , ,174 Valore medio 0,76 47,49 Δt [%] Tabella 4. 7: Tempi di codifica Ballroom 3 4 (Full Search) Ballroom_3 & Ballroom_4, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] , , , , , , , , , , , , , , ,562 Valore medio 1,80 49,82 Δt [%] Tabella 4. 8: Tempi di codifica Ballroom 6 7 (Full Search) Ballroom_6 & Ballroom_7, 25 fps QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] , , , , , , , , , , , , , , ,992 Valore medio 1,17 49,85 Δt [%] 56

67 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Le routine riguardanti l implementazione del profilo stereoscopico di MVC causano un incremento nel tempo di codifica delle sequenze video esaminate, rispetto alla sua codifica per separato. Nel caso in cui MVCInterViewReorder = 0 si rileva un aumento nel tempo usato per la codifica dal %, intanto che, con MVCInterViewReorder = 1, la variazione nel tempo di codifica è Δt 50%, per tutte le sequenze testate. Tale andamento nel tempo di codifica rimane quasi costante per passi diversi di quantizzazione, anche se il tempo di elaborazione dei dati decresce al crescere del QP, in quanto la quantizzazione produce un maggior numero di coefficienti nulli e, di conseguenza, la codifica entropica richiede meno tempo, come si osserva nella Figura 42. (a) (b) (c) (d) Figura 42. Confronto dei tempi di codifica (Full Search) (a) Sequenza Akko&Kayo, (b)(c) e (d) Sequenza Ballroom Analisi delle prestazioni di diverse configurazioni Nel secondo scenario si testerà l influenza di alcuni parametri di configurazione del codificatore sia nelle prestazioni ottenute del PSNR vs bit-rate, sia in quelle riguardanti il tempo di elaborazione, quando viene utilizzato lo strumento MVCInterViewReorder. La sequenza video usata per questa prova è Breakdancers (Figura 43), caratterizzata per una quantità alta di moto. Si osserveranno tre configurazioni 57

68 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO diverse a seconda del valore assunto per il IntraPeriod, 0, 5 o 1. Nel primo caso soltanto il primo frame della vista base sarà di tipo I, mentre tutti gli altri saranno di tipo P, cioè nella prima vista si terrà una configurazione del tipo IPPPPP Da un altra parte, IntraPeriod = 5 corrisponderà a un caso intermedio in cui, ogni 5 frame, se ne avrà uno di tipo I, conforme a una struttura di predizione per la prima vista del tipo IPPPPIPPPPI Finalmente, l ultimo sarà il caso limite in cui tutti i frame della vista base saranno codificati come tipo I. Per ognuno dei test si eseguirà la codifica con valori di QP uguali a [22, 27, 32, 37] e si varierà il numero dei frame usati come riferimento per fare la predizione (1, 3 e 5). Sequenza Breakdancers Figura 43. Sequenza 15 fps I principali parametri di configurazione per questa sequenza sono: Nelle Tabelle 4. 9, e 4. 13, si elencano, per diversi valori del passo di quantizzazione, il bit-rate e il PSNR luma medio nella sequenza video corrispondenti alla seconda vista, la riduzione percentuale del rate e la variazione percentuale del PSNR rispetto alla configurazione in cui si utilizza soltanto 1 frame di riferimento per fare la predizione. 58

69 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Nelle Tabelle 4. 10, e 4. 14, si elencano, per diversi valori del passo di quantizzazione, sia il tempo di codifica sia il bit-rate corrispondenti alla sequenza stereoscopica completa, per le tre configurazioni con 1, 3 e 5 frame di riferimento. Inoltre, si riportano i valori medi di queste misure, così come la sua variazione percentuale rispetto al caso di riferimento (1 reference frame). Si noti che il caso con 1 frame di riferimento corrisponde alla struttura di predizione tipica per applicazione in tempo reale mostrata nella Figura 29. IntraPeriod = 0 Tabella 4. 9: Sequenza Breakdancers 4 5 (IntraPeriod = 0) QP 1 ref frm 3 ref frm 5 ref frm bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,270 40, ,152 40,569 0,89 0, ,292 40,581 1,42 0, ,458 38, ,060 38,723 0,91 0, ,248 38,733 1,64 0, ,278 37, ,202 37,189-1,36 0, ,796 37,221-1,85 0, ,324 35, ,666 35,570-2,52 0, ,038 35,583-2,60 0,100 Figura 44. PSNR vs Bit-Rate (IntraPeriod = 0). Sequenza Breakdancers 4-5. Tabella 4. 10: Tempi di codifica Breakdancers 4 5 (IntraPeriod = 0) QP 1 ref frm 3 ref frm 5 ref frm Tempo di Bit-rate Tempo di Bit-rate Tempo di Bit-rate codifica [s] [kbps] codifica [s] [kbps] codifica [s] [kbps] , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,707 Valore medio 118,38-1,44 225,79-1,95 Δ [%] 59

70 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO IntraPeriod = 5 Tabella 4. 11: Sequenza Breakdancers 4 5 (IntraPeriod = 5) 1 ref frm 3 ref frm 5 ref frm QP bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,188 40, ,748 40,569 1,08 0, ,480 40,582 1,55 0, ,104 38, ,064 38,722 0,75 0, ,826 38,732 1,71 0, ,704 37, ,874 37,211-1,81 0, ,360 37,230-1,88 0, ,386 35, ,932 35,594-2,57 0, ,184 35,623-2,63 0,124 Figura 45. PSNR vs Bit-Rate (IntraPeriod = 5). Sequenza Breakdancers 4-5. Tabella 4. 12: Tempi di codifica Breakdancers 4 5 (IntraPeriod = 5) QP IntraPeriod = 1 1 ref frm 3 ref frm 5 ref frm Tempo di Bit-rate Tempo di Bit-rate Tempo di Bit-rate codifica [s] [kbps] codifica [s] [kbps] codifica [s] [kbps] , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,893 Valore medio 112,61-1,42 214,72-1,91 Δ [%] Tabella 4. 13: Sequenza Breakdancers 4 5 (IntraPeriod = 1) QP 1 ref frm 3 ref frm 5 ref frm bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,674 40, ,128 40,576 0,92 0, ,198 40,587 1,70 0, ,802 38, ,262 38,737 0,45 0, ,256 38,744 1,27 0, ,152 37, ,492 37,233-2,02 0, ,644 37,253-2,18 0, ,940 35, ,348 35,619-3,98 0, ,454 35,649-4,44 0,118 60

71 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Figura 46. PSNR vs Bit-Rate (IntraPeriod = 1). Sequenza Breakdancers 4-5. Tabella 4. 14: Tempi di codifica Breakdancers 4 5 (IntraPeriod = 1) QP 1 ref frm 3 ref frm 5 ref frm Tempo di Bit-rate Tempo di Bit-rate Tempo di Bit-rate codifica [s] [kbps] codifica [s] [kbps] codifica [s] [kbps] , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,701 Valore medio 86,39-0,07 164,79-0,28 Δ [%] In generale, i miglioramenti apportati al testare più da un frame di riferimento sono piuttosto esigui per la sequenza analizzata, anche se essa presenta un alto contenuto di movimento. Infatti, nelle prove svolte, al massimo, con 5 frame di riferimento, si è trovato un miglioramento del PSNR di 0.1 db, che può essere considerato trascurabile. Inoltre, l efficienza del sistema di riferimento ad immagini multiple è ridotta per QP elevati, in quanto i frame di riferimento ricostruiti sono maggiormente distorti e la stima del moto è meno efficace. Questo fatto si traduce in una crescita del bit-rate con il numero di reference frames usati per alti QP. Tale evento si osserva sempre per QP = 32 e QP = 37, casi in cui, oltre a un miglioramento molto limitato del PSNR, si presenta un aumento nel bitrate, presentandosi lo scenario peggiore per IntraPeriod = 1, dove il bit-rate cresce in un 4%. Dai dati riguardanti i tempi di codifica, si osserva che l utilizzazione di più da un immagine di riferimento per fare la predizione causa il raddoppio circa per 3 reference frames, con Δt %, e l incremento di circa 3 volte per il caso di 5 reference frames, con Δt %, come si può meglio apprezzare nella Figura 47. Si noti che la complessità cresce linearmente con il numero di RF. 61

72 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO D altra parte, man mano che ci sono più immagini I nella struttura di predizione, il tempo di codifica diminuisce, poiché l elaborazione di questo tipo di frame richiede un numero molto minore di calcoli rispetto a quelli di tipo P o B, infatti, per un implementazione con IntraPeriod = 1, è possibile raggiungere una riduzione nel tempo di codifica superiore al 30% rispetto allo scenario di riferimento. (a) IntraPeriod = 0 (b) IntraPeriod = 5 (c) IntraPeriod = 1 Figura 47. Confronto dei tempi di codifica. Sequenza Breakdancers. (a) IntraPeriod 0, (b) IntraPeriod 5 e (c) IntraPeriod 1 Tuttavia, finora si sono considerate soltanto le prestazioni rispetto al bit-rate nella seconda vista. Considerando i dati corrispondenti alla variazione del bit-rate complessivo della sequenza video stereoscopica e dei tempi di codifica totali, riportati nella Tabella 4. 15, si osserva che a parità di una diminuzione considerevole nella complessità, cioè una riduzione nel tempo di codifica, che nel caso di 5 frame di riferimento raggiunge un Δt 44%, il fatto di avere più immagini I nella prima vista comporta un aumento molto grande (di circa il 50% per IntraPeriod = 1) nel bit-rate. Tabella 4. 15: Confronto del bit-rate complessivo per Breakdancers 4 5 Breakdancers_4 & Breakdancers_5, 15 fps 1 ref frm 3 ref frm 5ref frm Intra Δ tempo Δ Δ tempo Δ Δ tempo Δ Period di codifica bit-rate di codifica bit-rate di codifica bit-rate 5 4,56% 8,44% 7,08% 8,46% 7,80% 8,49% 1 31,15% 47,73% 41,23% 49,80% 44,04% 50,25% 62

73 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO Tenendo conto del compromesso esistente fra complessità (tempo di codifica), bit-rate e PSNR, si può concludere che i vantaggi introdotti dall aumento del numero di frame di riferimento usati per la codifica così come dall inclusione di un maggior numero di immagini I nella struttura di predizione, sono molto limitati, poiché si incrementano troppo le risorse necessarie in termine di memoria e quantità di operazioni svolte dal processore o si perde molto in rate di compressione. A questo punto, si vedono i vantaggi della configurazione di riferimento (IntraPeriod = 0, 1 frame di riferimento), seppure con le sue limitazioni legate al tempo di elaborazione della sequenza video. Tuttavia, nel capitolo 5, si tratterà questa problematica, in particolare si esporrà l algoritmo per eseguire la stima del moto SLIMH264, molto meno complesso rispetto all algoritmo Full Search usato fino a questo momento, e si faranno alcune considerazioni collegate alla sua implementazione e successiva ottimizzazione nel caso di sequenze video stereoscopiche. 63

74 4.SUPPORTO DEL PROFILO MVC STEREOSCOPICO 64

75 5 OTTIMIZZAZIONE DELL ALGORITMO SLIMH264

76 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH INTRODUZIONE SLIMH264 è un algoritmo gerarchico-recursivo di stima del moto a blocchi, applicabile allo standard di codifica video H.264/AVC il cui scopo è ridurre i tempi di elaborazione del segnale video semplificando il processo di predizione temporale. È basato sull algoritmo di ME SLIMPEG, sviluppato in precedenza in MPEG-2 per il settore dei registratori DVD e poi adattato alla compressione a bassi bit-rate di MPEG-4 per applicazioni multimediali di telefonia mobile. SLIMH264 è compatibile con i video sia interlacciati che progressivi, può trattare tutte le partizioni in blocchi da 16x16 a 4x4 previste da H.264/AVC e gestire un numero illimitato di frame di riferimento. Quest algoritmo è stato implementato nel codificatore H.264/AVC proprietario di STMicroelectronics ed è compatibile con il decodificatore di riferimento rilasciato dal JVT, dalla versione JM 9.3 di Gennaio Usando un insieme di sequenze video di tipi diversi si sono confrontate le sue prestazioni con quelle dell algoritmo Full Search ottenendo un utilizzazione media del 3% della complessità computazionale per una finestra di ricerca di +/- 32 pixel [10]. 5.2 DESCRIZIONE DELL ALGORITMO SLIMH264 SLIMH264 è definito come algoritmo gerarchico-recursivo di stima del moto a blocchi [11]: È gerarchico perché il procedimento di ricerca è articolato in due fasi: 1) La ricerca grezza (Coarse Search - CS), per i soli blocchi 16x16, fornisce una predizione grezza e il relativo vettore di moto. 2) La ricerca fina (Fine Search - FS) perfeziona la predizione grezza per trovarne una più raffinata per ogni tipo di blocco, rispetto a ogni immagine di riferimento e in entrambe le direzioni forward e backward. È recursivo giacché i vettori di moto dei blocchi codificati in precedenza rappresentano i vettori candidati per la ricerca della migliore predizione temporale del blocco corrente, cioè si sfrutta la correlazione temporale e spaziale tra macroblocchi adiacenti La Coarse Search Ricerca grezza Durante questa prima fase l algoritmo SLIMH264 identifica un vettore di moto per ciascuno dei blocchi 16x16 dell immagine corrente; la ricerca del migliore predittore è effettuata prendendo i frame di riferimento in base all ordine di visualizzazione. Sono necessarie tre fasi successive per determinare questo predittore: 1. si testano i predittori spaziali 2. si testano i predittori temporali 3. si esegue il raffinamento tramite i vettori denominati updates. 66

77 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Predittori spaziali È ragionevole assumere che in un immagine reale un macroblocco non si possa muovere in modo del tutto indipendente da ciò che lo circonda. Perciò, per definire il miglior predittore del macroblocco corrente, si può confrontare con quelli dei macroblocchi adiacenti, testando tre predittori spaziali (S1, S2 e S3 della Figura 48) e scegliendo il migliore. Per il generico MB identificato dalla posizione (x,y) nel frame N-esimo, i predittori esaminati sono espressi dalle coordinate MV(x-1,y;N), MV(x,y-1;N) e MV(x-1,y-1;N). Figura 48. Predittori spaziali. Da [11]. Predittori temporali Un altra peculiarità tipica delle sequenze video è che il moto non può cambiare drasticamente tra due immagini consecutive (a meno di casi particolari come i cambi di scena). Per definire il miglior predittore del macroblocco corrente, si può confrontare con i macroblocchi adiacenti in frame appartenenti a istanze temporali diverse, testando tre predittori spaziali (T1, T2 e T3 della Figura 49) e scegliendo il migliore. Per il generico MB identificato dalla posizione (x,y) nel frame N-esimo, i predittori esaminati sono espressi dalle coordinate MV(x,y;N-1), MV(x+1,y;N-1) e MV(x,y+1;N-1). Figura 49. Predittori temporali. Da [11]. 67

78 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Updates Al termine delle prime due fasi si hanno a disposizione i migliori tra i predittori spaziali e temporali. Il migliore tra i due è raffinato con l aggiunta di dodici vettori di moto, detti updates, che puntano in direzioni predeterminate. D accordo al valore del SAD o SAT(D) del miglior predittore trovato nei primi due passi possono essere usati tre set diversi di updates (Figura 50). Figura 50. Posizioni degli updates. Da [11]. Dopo aver considerato tutti i 12 punti della griglia, il MV con la minor SAD/SAT(D) è eletto vettore di moto grezzo del MB in esame (Figura 51). La CS richiede in totale l elaborazione di tre predittori spaziali, tre temporali e dodici updates, per un totale di diciotto vettori per ogni MB. Figura 51. Scelta del vettore di moto finale per la Coarse Search. Da [11] La Fine Search Ricerca fina I vettori di moto trovati tramite la ricerca grezza vengono affinati durante la fase di ricerca fina, con lo scopo di trovare il miglior predittore per ogni possibile blocco, immagine di riferimento e direzione (forward o backward). Come già per la Coarse Search, si testano tre predittori spaziali, tre temporali e dodici updates, in più si considerano i MV predetti dal codificatore H.264 e il MV nullo. Al migliore di questi sono, infine, applicati otto updates ad ¼ di pixel. Al termine di tale procedimento, risultano essere stati elaborati 28 diversi predittori per ogni tipo di blocco, RF e direzione di predizione. 68

79 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 La ricerca fina differisce da quella grezza perché segue l ordine di codifica dei frame, non quello di visualizzazione. Perciò i predittori spaziali finali sono il prodotto del raffinamento della FS sui vettori forniti dalla CS, mentre i predittori temporali sono il risultato di questa ultima, scalati di un opportuno fattore temporale. Ad esempio, nella Figura 52 è rappresentata la ricerca del miglior MV per un particolare blocco nel frame N-esimo di tipo P rispetto all immagine P precedente (all istante N-2). Se è già stata effettuata la ricerca grezza per tutti i frame precedenti in ordine di visualizzazione. A questo punto SLIMH264 usa i tre vettori di moto dei blocchi S1, S2 e S3, dello stesso formato di quello corrente, ed elegge il migliore. In seguito testa i tre predittori temporali appartenenti ai macroblocchi T1, T2 e T3: questi sono l esito della ricerca grezza effettuata per il frame N rispetto al frame N-1. Per poter usare questo vettore in riferimento al frame N-2 in base all ordine di codifica, lo si deve moltiplicare per un fattore 2, che rappresenta la distanza temporale tra N e N-2. Nel caso di frame di tipo B, è necessario ridimensionare di un fattore negativo il predittore temporale dato dalla CS per la predizione backward: nell esempio della Figura 52 la stima effettuata per il frame N-1 rispetto al frame N deve essere moltiplicata per -1. Infatti, la distanza temporale tra N-1 ed N è pari a 1 e la CS è sempre in direzione forward, perciò i vettori devono essere invertiti con il segno negativo Profiling Figura 52. Fine Search in SLIMH264. Da [11]. Per eseguire l analisi del funzionamento del codificatore HENC si è usato lo strumento di profiling Valgrind, software che permette di realizzare uno studio minuzioso del programma in esame. In particolare si è utilizzato il tool Callgrind di questo software per ottenere sia una rappresentazione grafica delle chiamate alle varie funzioni incluse nel codice, sia le percentuali corrispondenti al loro numero di istruzioni esecutate. Nella Figura 53 è fornito, a titolo di esempio, il grafo ottenuto dal profiling dell'encoder HENC quando viene usato l algoritmo per la stima del moto SLIMH

80 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 53. Grafo del profiling di HENC usando l'algoritmo SLIMH264. In questo grafo possiamo osservare lo scheletro semplificato del codificatore HENC quando si realizza la codifica di un unica sequenza video. È possibile vedere nella parte bassa del grafo, come le funzioni che eseguono la stima del moto concentrano i calcoli nella funzione SlimTestPredictor, evidenziata nella Figura 53. Tale funzione è quella maggiormente chiamata, e come possiamo 70

81 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 anche vedere dal grafo, il suo funzionamento corrisponde a circa il 65% delle operazioni del programma. Da questo punto di vista, e tenendo anche conto che nel caso di una sequenza MVC stereoscopica il numero di operazioni necessarie per svolgere la codifica sarà circa il doppio rispetto alla codifica di una singola sequenza video, si è fatta un implementazione dell algoritmo SLIMH264 cercando di minimizzare i calcoli computati al codificare la seconda vista, approfittando la sua forte correlazione con la vista base. 5.3 IMPLEMENTAZIONE DI SLIMH264 NEL CODIFICATORE HENC Uno dei fattori più importanti dell implementazione di un codificatore video è la sua complessità computazionale. Come si è discusso nel capitolo precedente, l algoritmo esaustivo Full Search offre risultati limitati, in termine del tempo di codifica, poiché richiede molte operazioni da essere svolte per il processore. Nella sezione anteriore si è fatta una breve descrizione dell algoritmo SLIMH264, tuttavia, si devono fare alcune considerazioni riguardanti la codifica della seconda vista, cercando di ridurre i calcoli necessari e approfittando delle particolarità del segnale video stereoscopico Modificazioni nella Coarse Search Siccome la Coarse Search viene effettuata sui blocchi 16x16 e il suo ruolo è quello di trovare un predittore di base da essere usato per eseguire la predizione temporale, è possibile pensare che i risultati ottenuti lungo la sua esecuzione nella prima vista, possano essere usati in certa maniera per eseguire la codifica della seconda sequenza video. Di fatto, tenendo conto che i vettori di moto trovati in questo step descrivono in forma grezza il cambiamento fra due frame successivi, al posto di fare tutte le operazioni per calcolarli, nella seconda vista si prendono gli stessi vettori ricavati nella codifica della prima sequenza, e si riutilizzano come predittori temporali nella Fine Search, com è mostrato nella Figura 54. Figura 54. Eliminazione della Coarse Search nella seconda vista. A questo punto, per ogni MB della seconda vista, si è risparmiata la prova di 18 vettori di moto (predittori spaziali, temporali e updates). 71

82 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH Modificazioni per la Predizione Inter-view Quando viene eseguita la predizione inter-view, la quale si basa nella stima della disparity tra due frame appartenenti alla stessa istanza temporale, non è possibile usare i vettori trovati nella Coarse Search come predittori temporali, poiché essi descrivono il movimento fra due frame consecutivi nell ordine temporale. Nell implementazione del codificatore stereoscopico, seguendo la stessa struttura della Coarse Search, si sono salvati ogni volta, per ognuno dei macroblocchi, i migliori vettori trovati nella Fine Search nel modo 16x16. In questa maniera, nella Ricerca Fina saranno usati al posto dei predittori temporali, i vettori trovati per l istanza temporale immediatamente anteriore, piuttosto che quelli trovati nella CS. La Figura 55 mostra uno schema di questo comportamento. Figura 55. Riutilizzazione dei risultati precedenti nella predizione inter-view. Rispetto a un implementazione in cui non siano realizzati gli aggiustamenti menzionati in precedenza per svolgere la codifica della seconda vista, si raggiunge, utilizzando in entrambi casi gli stessi parametri di configurazione, un guadagno nel tempo di codifica di circa il 5%, con un incremento medio del valore del PSNR di circa 0.6 db a parità di bit-rate Analisi delle prestazioni Con lo scopo di verificare il giusto funzionamento dell algoritmo SLIMH264 nell encoder HENC, e cercando di fare un confronto delle sue prestazioni rispetto a quelle conseguite con l algoritmo Full Search, si sono testate le stesse quattro sequenze video usate nella sezione per analizzare le caratteristiche dello strumento MVCInterViewReorder: Akko&Kayo (Figura 36) e Ballroom (Figura 38). I parametri utilizzati per eseguire la codifica si sono messi anche uguali, tranne l algoritmo usato per la stima del moto che si è cambiato a SLIMH264. In seguito sono riportati i risultati ottenuti sia in termine di bit-rate vs PSNR, sia di tempo di codifica vs QP. 72

83 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Sequenza Akko&Kayo Tabella 5. 1: Sequenza Akko&Kayo (SLIMH264) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,904 43, ,882 43,117 3,34-0, ,918 43,200 8,12 0, ,488 40, ,246 40,051 5,14-0, ,710 40,331 5,52 0, ,386 36, ,854 36,598 7,02-0, ,462 37,116-5,06 0, ,142 33, ,150 33,529 7,75-0, ,044 34,026-25,37 0,395 Figura 56. PSNR vs Bit-Rate. Sequenza Akko&Kayo (SLIMH264) Tabella 5. 2: Tempi di codifica Akko&Kayo (SLIMH264) QP Akko&Kayo_26 & Akko&Kayo_27, 30 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] 22 93,030 93, , ,950 92, , ,058 92, , ,686 91, ,740 93,431 92, ,943 Valore medio -1,12 32,66 Δt [%] 73

84 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Sequenza Ballroom Sequenza Ballroom 0 1 Tabella 5. 3: Sequenza Ballroom 0-1 (SLIMH264) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,010 40, ,920 40,438 1,81-0, ,790 40,417 4,46-0, ,430 37, ,350 37,569 3,11-0, ,935 37,649 2,60 0, ,095 34, ,910 34,642 4,76-0, ,420 34,887-0,05 0, ,015 32, ,160 31,856 6,35-0, ,920 32,218-10,81 0,032 Figura 57. PSNR vs Bit-Rate. Sequenza Ballroom 0-1 (SLIMH264) Tabella 5. 4: Tempi di codifica Ballroom 0 1 (SLIMH264) QP Ballroom_0 & Ballroom_1, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] 22 93,954 95, , ,774 92, , ,198 92, , ,230 92, ,712 92,789 93, ,140 Valore medio 0,63 35,94 Δt [%] 74

85 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Sequenza Ballroom 3 4 Tabella 5. 5: Sequenza Ballroom 3-4 (SLIMH264) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,500 40, ,265 40,559 2,03-0, ,795 40,549 7,20-0, ,720 37, ,755 37,571 3,78-0, ,585 37,657 9,86 0, ,005 34, ,355 34,526 5,39-0, ,905 34,670 9,59 0, ,465 31, ,380 31,712 6,84-0, ,665 31,927 1,36 0,059 Figura 58. PSNR vs Bit-Rate. Sequenza Ballroom 3-4 (SLIMH264) Tabella 5. 6: Tempi di codifica Ballroom 3 4 (SLIMH264) Ballroom_3 & Ballroom_4, 25 fps QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] 22 92,754 93, , ,774 92, , ,290 92, , ,238 91, ,988 Sequenza Ballroom ,764 92, ,336 Valore medio 1,01 37,67 Δt [%] Tabella 5. 7: Sequenza Ballroom 6-7 (SLIMH264) QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,335 40, ,900 40,512 1,54-0, ,570 40,490 6,47-0, ,565 37, ,780 37,446 2,58-0, ,330 37,484 8,73-0, ,535 34, ,430 34,216 3,41-0, ,145 34,316 7,43-0, ,910 31, ,915 31,304 4,60-0, ,390 31,435-2,61-0,208 75

86 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 59. PSNR vs Bit-Rate. Sequenza Ballroom 6-7 (SLIMH264) Tabella 5. 8: Tempi di codifica Ballroom 6 7 (SLIMH264) QP Ballroom_6 & Ballroom_7, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Tempo di codifica Tempo di codifica [s] [s] [s] 22 93,990 94, , ,150 93, , ,742 92, , ,106 92, ,256 92,247 93, ,002 Valore medio 1,11 34,42 Δt [%] Come si può notare nella Figura 56, Figura 57, Figura 58 e Figura 59, l algoritmo SLIMH264 ha un comportamento molto simile a quello ottenuto con l algoritmo Full Search, presentando di nuovo dei vantaggi quando si utilizza lo strumento MVCInterViewReorder rispetto al caso in cui esso non viene usato. A parità di bit-rate, la configurazione MVCInterViewReorder = 0 fornisce un guadagno di db, a seconda dalla sequenza video testata, rispetto alla simulazione Simulcast, raggiungendo un incremento massimo del PSNR di circa 0.5 db, per bit-rate bassi, nella sequenza Akko&Kayo. Da un altra parte, sempre rispetto alla simulazione Simulcast, nel caso in cui MVCInterViewReorder = 1 l algoritmo SLIMH264 fornisce un guadagno approssimato di db, quasi costante per valori del bit-rate intermedi e alti. In questo scenario il caso migliore si trova quando viene utilizzata la sequenza Ballroom 34, dove il guadagno raggiunge i 0.7 db e il caso peggiore, com era già successo per Full Search, si riporta nella sequenza Ballroom 01, in cui il guadagno raggiunto è di circa db. Ugualmente, con QP = 37, si trova il maggiore incremento di bit-rate per MVCInterViewReorder = 1, e il comportamento proprio contrario quando tale strumento è disattivato. 76

87 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Confronto dei tempi di codifica per le simulazioni svolte (a) (b) (c) (d) Figura 60. Confronto dei tempi di codifica (SLIMH264) (a) Sequenza Akko&Kayo, (b)(c) e (d) Sequenza Ballroom Rispetto al tempo di elaborazione dei video stereoscopici, riportato nella Figura 60 per tutte le sequenze testate, quando viene utilizzato SLIMH264 le differenze esistenti fra i due algoritmi sono piuttosto apprezzabili, principalmente con MVCInterViewReorder = 1. Nel caso in cui lo strumento MVCInterViewReorder non è attivo, si rileva un aumento nel tempo usato per la codifica di circa un 1%, intanto che, con MVCInterViewReorder = 1, la variazione nel tempo di codifica è circa Δt 34%, per tutte le sequenze testate, al posto di Δt 1.8% e Δt 50% ottenuti con l algoritmo Full Search. Tale comportamento permette osservare come l algoritmo SLIMH264 diventa sempre più robusto con l utilizzazione della predizione inter-view, svolgendo la codifica in maniera più veloce senza abbassare le prestazioni in termine di PSNR. Nondimeno, essendo un algoritmo non esaustivo, si spera che i tempi di codifica siano notevolmente minori da quelli conseguiti con l algoritmo Full Search. Nella Figura 62 è riportato un paragone fra i due algoritmi per la stima del moto, in cui vengono messi in confronto i tempi medi di codifica per i tre tipi di prove eseguite, Simulcast, MVCInterViewReorder = 0 e MVCInterViewReorder = 1, per ognuna delle sequenze video testate. Nei due primi scenari si osserva che, in tutte le simulazioni, il tempo di elaborazione con l algoritmo SLIMH264 è circa il 19 % 77

88 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 61. Confronto dei tempi di codifica. SLIMH264 vs Full Search 78

89 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 mentre che per MVCInterViewReorder è circa il 17 % del tempo impiegato nella codifica per l algoritmo Full Search. Per quel che riguarda i tempi di codifica, si ricorda che i tempi di simulazione con Full Search aumentano con il quadrato del valore della finestra di ricerca: l algoritmo esaustivo deve testare tutte le posizioni del blocco, o macroblocco, all interno della zona di ricerca, invece SLIMH264 prevede un numero fisso di confronti (si veda la Figura 5.41). Poiché è previsto un numero di confronti finito e indipendente dalla dimensione della finestra, anche dilatando all infinito la sua dimensione per SLIMH264 si incrementa la qualità della ricerca, ma non aumenta il tempo di simulazione. Figura 62. Numero di operazioni svolte per SLIMH264 e Full Search. Da [11]. 5.4 OTTIMIZZAZIONE DEL TEMPO DI CODIFICA Sebbene finora si siano ottenuti dei risultati soddisfacenti con l implementazione dell algoritmo SLIMH264, tenendo conto che lo scopo di questo elaborato sono le applicazioni in tempo reale, si è cercato di abbassare ancora di più la complessità dell algoritmo, cioè ridurre il tempo impiegato nella codifica. A questo fine si sono sviluppati due profili diversi dell algoritmo, oltre a quello mostrato in precedenza, con prestazioni ben diverse fra loro No mode Test In questa implementazione, ogni volta che si esegue la codifica di un macroblocco appartenente alla seconda vista, al posto di testare tutti i possibili modi di codifica di tipo INTRA, INTER ed SKIP, viene scelto soltanto un piccolo sottoinsieme di modalità da provare, basandosi nell informazione corrispondente al modo in cui è stato codificato il MB trovato nella stessa posizione nella prima vista. Per tutti i MB appartenenti a un frame della seconda sequenza video, dipendendo del modo in cui è stato codificato il MB corrispondente nella vista base, la scelta è fatta com è indicato in seguito: 79

90 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 1) Si testeranno i modi INTRA 16x16 e 4x4. 2) Nel caso in cui il modo in trovato sia SKIP, si testerà anche il modo INTER 16x16. 3) Se il modo trovato è INTER 16x16, 16x8, 8x16 oppure 8x8, esso si aggiungerà ai modi da testare. 4) Nel caso in cui il MB sia stato partizionato nella prima vista in blocchi di dimensione 8x4, 4x8 o 4x4, ognuna delle partizioni del MB corrispondente nella seconda vista, sarà testata utilizzando lo stesso modo. 5) Infine sarà testato, per tutti i MB, il modo SKIP. Alla fine, si sceglie il miglior modo di codifica per il macroblocco in base alla funzione di costo. Per vedere le prestazioni di questo profilo di codifica semplificato, si sono fatte le solite prove, utilizzando le sequenze Akko&Kayo e Ballroom, mettendo gli stessi parametri di configurazione usati nella sezione Sequenza Akko&Kayo Tabella 5. 9: Sequenza Akko&Kayo (No mode test) QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,182 42, ,016 42,796 2,49-0, ,716 42,904-1,39 0, ,990 39, ,182 39,817 3,78-0, ,022 40,074-0,78 0, ,586 36, ,398 36,426 4,80-0, ,152 36,878-5,84 0, ,176 33, ,394 33,398 6,07-0, ,790 33,875-16,94 0,363 Figura 63. SLIMH264 vs No mode test. Sequenza Akko&Kayo. 80

91 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Tabella 5. 10: SLIMH264 vs No mode test. Sequenza Akko&Kayo. QP Akko&Kayo_26 & Akko&Kayo_27, 30 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 64,064 31,14 68,724 26,55 77,381 38, ,444 33,18 67,208 27,20 73,857 40, ,712 31,54 64,004 30,49 70,596 42, ,712 31,26 63,840 30,30 69,184 44,09 31,78 28,63 41,31 Valore medio Nella Figura 63 si può vedere come per la sequenza Akko&Kayo le prestazioni in termine di PSNR contro bit-rate ottenute utilizzando il profilo No mode Test sono al disotto di quanto si era raggiunto con la versione completa dell algoritmo SLIMH264, in un rango che va da circa 1.7 db fino a circa 2.7 db, compromettendo notevolmente la qualità del video ottenuto corrispondente alla seconda vista. Tuttavia, com è riportato nella Tabella 5. 10, il tempo di elaborazione complessivo per codificare l intera sequenza stereoscopica è certamente minore, ottenendo un guadagno percentuale Δt rispetto alla versione completa in cui sono testati tutti i modi di codifica del macroblocco, di circa il 30 % per MVCInterViewReorder = 0 e di circa 40 % quando lo strumento di reordering viene usato. Oltre a quanto si è detto finora si vede che, com era già riportato per l algoritmo Full Search e l algoritmo SLIMH264, il caso in cui il passo di quantizzazione QP è pari a 37, cioè con valori bassi del bit-rate, corrisponde con lo scenario peggiore per MVCInterViewReorder = 1, con un incremento del bitrate di circa il 17 %. Sequenza Ballroom Sequenza Ballroom 0 1 Tabella 5. 11: Sequenza Ballroom 0-1 (No mode test) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,675 40, ,725 40,273 1,40-0, ,745 40,302-0,40-0, ,850 37, ,005 37,458 2,48-0, ,205 37,534-1,36 0, ,560 34, ,315 34,534 3,82-0, ,855 34,733-2,91 0, ,920 32, ,165 31,788 4,87-0, ,050 32,084-8,84-0,026 81

92 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 64. SLIMH264 vs No mode test. Sequenza Ballroom 0-1. Tabella 5. 12: SLIMH264 vs No mode test. Sequenza Ballroom 0-1. QP Ballroom_0 & Ballroom_1, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 67,176 28,50 68,028 28,73 78,217 38, ,812 31,22 64,508 30,48 73,001 41, ,008 28,41 67,392 26,99 70,868 43, ,116 28,31 68,824 25,95 70,456 44,83 29,11 28,04 42,02 Valore medio Sequenza Ballroom 3 4 Tabella 5. 13: Sequenza Ballroom 3-4 (No mode test) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR QP [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,955 40, ,060 40,389 1,74-0, ,695 40,414-1,57-0, ,735 37, ,695 37,434 3,04-0, ,180 37,503 0,19-0, ,845 34, ,105 34,393 3,77-0, ,640 34,536 0,51 0, ,980 31, ,810 31,603 5,06-0, ,000 31,818-3,48 0,040 82

93 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 65. SLIMH264 vs No mode test. Sequenza Ballroom 3-4. Tabella 5. 14: SLIMH264 vs No mode test. Sequenza Ballroom 3-4. QP Ballroom_3 & Ballroom_4, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 66,500 28,30 66,756 28,90 70,628 43, ,300 28,85 66,116 28,80 68,828 44, ,032 28,76 65,812 28,58 68,828 47, ,076 29,77 64,736 29,54 68,112 45,51 28,92 28,95 45,28 Valore medio Sequenza Ballroom 6 7 Tabella 5. 15: Sequenza Ballroom 6-7 (No mode test) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,235 40, ,295 40,351 1,19-0, ,220 40,361-0,85-0, ,705 37, ,630 37,287 1,95-0, ,390 37,327-0,22-0, ,310 34, ,295 34,095 2,91-0, ,235 34,186-0,68-0, ,280 31, ,765 31,236 3,43-0, ,585 31,350-5,84-0,172 83

94 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 66. SLIMH264 vs No mode test. Sequenza Ballroom 6-7. Tabella 5. 16: SLIMH264 vs No mode test. Sequenza Ballroom 6-7. QP Ballroom_6 & Ballroom_7, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 65,220 30,61 66,152 29,82 70,116 43, ,800 30,77 64,712 30,87 68,860 44, ,340 30,96 64,360 30,67 68,996 44, ,164 30,67 64,008 30,70 68,224 44,65 30,75 30,52 44,32 Valore medio Nella Figura 64, Figura 65 e la Figura 66 vengono riportati gli andamenti del PSNR vs bit-rate per le tre sequenze video Ballroom 01, Ballroom 34 e Ballroom 67. Da questi grafici si vede che, anche com era già osservato per la sequenza Akko&Kayo, quando sono testati pochi modi per svolgere la codifica dei macroblocchi appartenenti alla seconda vista, le prestazioni ottenute diminuiscono considerevolmente. Per queste tre sequenze, molto simili fra loro poiché corrispondono alla stessa scena presa da differenti punti di vista, le curve corrispondenti alle loro prestazioni in termine di PSNR quando è usato il profilo No mode Test si trovano db al disotto di quelle rispettive alla versione ad alta complessità. D altra parte, i tempi di elaborazione dell intera sequenza riportati per completezza nella Figura 67, si riducono in circa 30 % per le configurazioni di tipo Simulcast ed MVCInterViewReorder = 0, e di circa un 44 % quando lo strumento di reordering è attivo. 84

95 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Confronto dei tempi di codifica per le simulazioni svolte (a) (b) (c) (d) Figura 67. Confronto dei tempi di codifica (No mode test) (a) Sequenza Akko&Kayo, (b)(c) e (d) Sequenza Ballroom SLIMH264 Fast Decision Il secondo approccio sviluppato per migliorare il funzionamento dell algoritmo SLIMH264 cerca di mantenere prestazioni similari a quelle ottenute testando tutti i modi di codifica per ogni MB nella seconda vista, però, riducendo il tempo di elaborazione del segnale video. In questa implementazione com è stato già fatto nell algoritmo descritto prima, si approfitta la correlazione esistente fra la distribuzione dei modi di codifica di due frame appartenenti a viste vicine, con il fine di sottrarre l esecuzione di modi superflui. Una delle ragioni di adottare modi di codifica di dimensioni variabile quando viene fatta la codifica di tipo INTER in una sequenza video è quella di catturare la vera natura del moto o la disparity, rappresentando i movimenti nella forma più accurata spendendo una quantità di informazione ragionevole. Uno dei criteri che è usato a questo punto è la separazione dei frame in regioni, caratterizzate sia per avere una struttura similare, sia per presentare un movimento omogeneo. L algoritmo di decisione veloce del modo di codifica (Fast mode decision for Multi-view Coding) trovato in [12] e implementato nel codificatore HENC, si serve di tali considerazioni. Facendo l analisi esperimentale con diverse sequenze 85

96 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 video si è notato che i macroblocchi appartenenti a regioni con struttura omogenea ( textures ) o poco movimento vengono sempre codificati con un numero ristretto di modi, corrispondenti a quelli di dimensioni più grandi. Dall altra parte, i MB corrispondenti a zone dell immagine in cui ci sono tanti dettagli o a regioni con molto movimento sono codificati utilizzando generalmente i modi di dimensioni più piccole. Per determinare le caratteristiche proprie di un certo macroblocco appartenente alla seconda sequenza video, si fa uso di un parametro denominato mode complexity, il cui è derivato dai modi in cui sono stati codificati, nella vista base, sia il macroblocco corrispondente, sia gli otto MB vicini (si veda la Figura 68). Figura 68. MB corrispondente e MB vicini nella vista base. Da [12]. Il parametro mode complexity per un certo MB, definito MDC, viene calcolato come: dove w i è il mode factor assegnato al macroblocco i (Tabella 5. 17), ed N è il numero di MB considerati. Generalmente, maggiore è il valore del mode factor, maggiore è la complessità del macroblocco. Tabella 5. 17: Mode factors dei MB per ogni modo di codifica. Da [12]. Mode SKIP MC16x16 MC16x8 MC8x16 8x8 INTRA w Finalmente, si sono impostate due soglie, che permettono di determinare la complessità del MB a seconda del valore del MDC, e il corrispondente sottoinsieme di modi di codifica da testare: 86

97 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Nel caso di un MB di complessità bassa, soltanto è testato il modo MC16x16. Per quelli di complessità media, si testano i modi MC16x16, MC8x16 ed MC16x8, mentre per i più complessi, se ne devono testare tutti. Finalmente, com è fatto di solito, secondo la valutazione della funzione di costo dei modi testati viene scelto il modo in cui sarà codificato il macroblocco. Inoltre, se si pensa alla struttura dell algoritmo SLIMH264, in particolare sulla maniera come viene svolta la Fine Search, e tenendo anche in considerazione la forte correlazione fra le due sequenze video considerate, è possibile rendersi conto che alcune delle operazioni eseguite nella codifica della prima vista possono essere riutilizzate per risparmiare tempo senza danneggiare le prestazioni ottenute al farle tutte. In particolare, per la seconda vista, la prima fase della Fine Search corrispondente alla ricerca di un vettore di moto per il MB utilizzando come base i tre predittori spaziali e i tre predittori temporali, può essere sostituita semplicemente copiando, in ogni caso, il predittore già ottenuto per la prima sequenza, il cui alla fine sarà raffinato nei passi successivi tramite gli updates. In questo modo, al posto di testare 28 diversi predittori per ogni tipo di blocco, RF e direzione di predizione, se ne testeranno 22. Tuttavia, nel caso speciale dell interview prediction, l utilizzazione dei predittori temporali, cioè dei vettori di moto ottenuti nella codifica del frame della prima vista corrispondente alla stessa istanza temporale, saranno ancora impiegati, in altre parole, per ogni tipo di blocco, se ne testeranno 25 predittori. Se si prende ad esempio in considerazione la struttura di predizione per applicazioni in tempo reale della Figura 29, in cui si ha soltanto 1 RF, per ogni tipo di blocco della seconda vista, al posto di testare 56 predittori, ne saranno testati 47, che corrisponde a un risparmio di circa il 16% delle operazioni riguardanti la Fine Search. Per osservare le prestazioni ottenute con questo profilo di codifica ottimizzato, si sono fatte le solite prove, utilizzando le sequenze Akko&Kayo e Ballroom, mettendo gli stessi parametri di configurazione usati nella sezione Sequenza Akko&Kayo Tabella 5. 18: Sequenza Akko&Kayo (SLIMH264 Fast Decision) QP Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,878 43, ,864 43,055 2,88-0, ,836 43,150 9,48 0, ,538 39, ,006 39,960 4,68-0, ,188 40,240 9,07 0, ,734 36, ,814 36,474 6,81-0, ,174 36,983 1,97 0, ,982 33, ,232 33,336 7,43-0, ,186 33,839-8,75 0,353 87

98 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 69. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Akko&Kayo. Tabella 5. 19: SLIMH264 vs SLIMH264 Fast Decision. Akko&Kayo. QP Akko&Kayo_26 & Akko&Kayo_27, 30 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 80,905 13,03 82,621 11,70 102,378 17, ,433 20,56 76,813 16,80 93,182 24, ,925 21,63 74,569 19,02 88,290 28, ,032 23,36 72,557 20,78 87,565 29,23 19,65 17,07 25,10 Valore medio Sequenza Ballroom Sequenza Ballroom 0 1 Tabella 5. 20: Sequenza Ballroom 0-1 (SLIMH264 Fast Decision) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,505 40, ,830 40,397 1,75-0, ,405 40,396 4,00-0, ,965 37, ,110 37,505 3,26-0, ,865 37,610 5,32 0, ,390 34, ,415 34,547 4,58-0, ,000 34,797 5,48 0, ,945 32, ,525 31,709 5,94-0, ,370 32,073 1,11 0,023 88

99 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 70. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Ballroom 0-1. Tabella 5. 21: SLIMH264 vs SLIMH264 Fast Decision. Ballroom 0-1. Ballroom_0 & Ballroom_1, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 85,085 9,44 86,353 9,53 114,295 9, ,437 19,77 78,637 15,26 96,034 23, ,757 21,09 73,485 20,39 91,302 26, ,084 22,93 73,565 20,85 88,230 30,91 18,30 16,51 22,73 Valore medio Sequenza Ballroom 3 4 Tabella 5. 22: Sequenza Ballroom 3-4 (SLIMH264 Fast Decision) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR QP [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,370 40, ,700 40,515 2,16-0, ,035 40,528 7,17-0, ,405 37, ,210 37,524 3,75-0, ,320 37,609 11,21 0, ,170 34, ,060 34,472 5,12-0, ,910 34,599 12,32 0, ,075 31, ,445 31,578 6,61-0, ,665 31,841 9,37 0,069 89

100 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 71. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Ballroom 3-4. Tabella 5. 23: SLIMH264 vs SLIMH264 Fast Decision. Ballroom 3-4. Ballroom_3 & Ballroom_4, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 QP Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 84,397 9,01 84,561 9,93 109,199 12, ,653 18,66 75,541 18,65 94,810 23, ,161 19,86 73,913 19,79 89,586 31, ,364 21,78 72,745 20,82 86,601 30,71 17,33 17,30 24,68 Valore medio Sequenza Ballroom 6 7 Tabella 5. 24: Sequenza Ballroom 6-7 (SLIMH264 Fast Decision) Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 bit-rate PSNR Y bit-rate PSNR Y BR Δ PSNR bit-rate PSNR Y BR Δ PSNR QP [kbps] [db] [kbps] [db] % [db] [kbps] [db] % [db] ,130 40, ,760 40,490 1,46-0, ,770 40,479 6,51-0, ,645 37, ,150 37,401 2,40-0, ,625 37,456 10,49-0, ,135 34, ,605 34,162 3,48-0, ,770 34,256 10,65-0, ,010 31, ,030 31,211 4,68-0, ,775 31,349 4,73-0,212 90

101 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 72. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Ballroom 6-7. Tabella 5. 25: SLIMH264 vs SLIMH264 Fast Decision. Ballroom 6-7. QP Ballroom_6 & Ballroom_7, 25 fps Simulcast MVCInterViewReorder = 0 MVCInterViewReorder = 1 Tempo di codifica Δt Tempo di codifica Δt Tempo di codifica Δt [s] [%] [s] [%] [s] [%] 22 88,898 5,42 89,334 5,23 117,163 6, ,717 16,75 77,825 16,86 94,794 23, ,093 19,24 74,669 19,57 90,482 26, ,932 21,05 72,817 21,17 87,137 29,30 15,61 15,71 21,51 Valore medio Dai dati elencati in precedenza e dai grafici di PSNR contro bit-rate corrispondenti a ciascuna delle sequenze video testate, si vede come il profilo SLIMH264 Fast Decision sviluppato è caratterizzato per una minore complessità rispetto alla versione completa dell algoritmo SLIMH264, senza compromettere le sue prestazioni. Si vede ad esempio nella Figura 69, corrispondente alla sequenza Akko&Kayo, come al massimo le curve del PSNR contro il rate riguardanti questo profilo si trovano sotto circa di 0.3 db da quelle relative alla versione completa di SLIMH264, presentando una riduzione media del tempo complessivo di codifica di %, % e % per le configurazioni Simulcast, MVCInterViewReorder = 0 ed MVCInterViewReorder = 1 rispettivamente. Nel caso della sequenza Ballroom, le tre prove svolte mostrano dei risultati analoghi, tenendo per la configurazione per applicazioni in tempo reale, cioè quella con MVCInterViewReorder = 1, una riduzione media del tempo di elaborazione delle due viste di circa %, con una differenza di PSNR quasi costante per valori di bit-rate alti e intermedi rispetto alla versione completa di circa 0.1 db, la cui potrebbe essere considerata quasi trascurabile. 91

102 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Confronto dei tempi di codifica per le simulazioni svolte (a) (b) (c) (d) Figura 73. Confronto dei tempi di codifica (SLIMH264 Fast Decision) (a) Sequenza Akko&Kayo, (b)(c) e (d) Sequenza Ballroom Facendo la media del tempo di elaborazione della sequenza completa per diversi valori di QP sia per la versione completa di SLIMH264, per il profilo No mode Test che per SLIMH264 Fast Decision, è possibile paragonare facilmente le loro prestazioni. Nella Figura 74, in cui sono riprodotti tali risultati, si osservano le bontà dell algoritmo di ottimizzazione implementato, SLIMH264 Fast Decision, poiché rispetto all approccio sviluppato in precedenza il quale offre la codifica più veloce, cioè quella a più bassa complessità, non rappresenta un incremento notevole del tempo complessivo impegnato nella codifica, intanto che le sue prestazioni in termine di PSNR si avvicinano molto a quelle ottenute con l algoritmo SLIMH264 completo. Tali vantaggi rispondono alla combinazione di diversi strumenti capaci di sfruttare nel modo giusto l interdipendenza fra le sequenze video corrispondenti a viste vicine, però, potrebbero cambiare a seconda dalla calibrazione delle camere con cui essi sono presi così come la natura del moto, le quali sono caratteristiche intrinseche del video. Addirittura, si potrebbero raggiungere migliori risultati semplicemente ingrandendo la finestra di ricerca dell algoritmo senza aumentare la complessità. 92

103 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Figura 74. Confronto fra i diversi profili sviluppati di SLIMH264 93

104 5.OTTIMIZZAZIONE DELL ALGORITMO SLIMH264 Tuttavia, secondo l applicazione in cui si voglia fare l implementazione del codificatore MVC stereoscopico e delle risorse a disposizione, è possibile scegliere fra i diversi profili svolti, sia cercando di velocizzare il processo, sia volendo migliorare la qualità visiva del video, oppure impostando un punto intermedio delle prestazioni. 94

105 APPENDICE A: FILE DI CONFIGURAZIONE DEL SOFTWARE JM 17.2 Il software JM 17.2 è composto fondamentalmente da due moduli: un codificatore, il quale esegue la compressione delle sequenze video in base ad una lista di parametri dati per l utente, e un decodificatore, che fa il processo inverso per arrivare a un approssimazione del segnale originale. Le linee di comando per avviare il processo di codifica/decodifica sono: Codificatore lencod.exe [-h] [-d defenc.cfg] {[-f curenc1.cfg]...[-f curencn.cfg]} {[-p EncParam1=EncValue1]...[-p EncParamM=EncValueM]} -h Mostra la forma in cui devono essere usati i diversi parametri d ingresso. -d Utilizza <defenc.cfg> per l inizializzazione dei parametri di codifica. Se non è specificato, il codificatore prende quello di default, encoder.cfg. -f Aggiorna il file di default utilizzando <curencm.cfg>. Ci possono essere diversi file. -p Sovrascrive il parametro <EncParamM> con il valore <EncValueM> all interno del file di configurazione. Decodificatore ldencod.exe d <defdec.cfg> Il file <defdec.cfg> contiene i parametri di configurazione del decodificatore. Nel caso particolare in cui si vuole riprendere due viste, è necessario avere il flag DecodeAllLayers impostato a 1. A.1 Parametri di configurazione del codificatore A.1.1 Opzioni dei file di ingresso e di uscita InputFile1: sequenza d ingresso corrispondente alla prima vista. InputFile2: sequenza d ingresso corrispondente alla seconda vista. FramesToBeEncoded: frame della sequenza originale da codificare. SourceWidth: larghezza dell immagine espressa in pixel. SourceHeight: altezza dell immagine espressa in pixel. OutputFile: il nome del file compresso (nel formato.264). 95

106 A.1.2 Impostazioni del codificatore ProfileIDC: Profilo IDC. IntraPeriod: periodo dei frame di tipo I. FrameSkip: numero di frame della sequenza di ingresso da saltare. SearchRange: massima dimensione della finestra di ricerca del vettore di moto durante la ME (in pixel). NumberReferenceFrames: numero dei frame di riferimento per fare la stima (0 16). A.1.3 Frame B NumberBframes: numero di frame B inseriti (0=disabilitati). DirectModeType: direct mode type (0=temporale, 1=spaziale). A.1.4 MVC NumberOfViews: Numero di viste a codificare. (1=1 vista, 2 =2 viste) MVCEnableInterViewFlag: Flag per l abilitazione della predizione inter vista (interview prediction). A.1.5 Controllo dell uscita SymbolMode: metodo di codifica entropica (0=CAVLC, 1=CABAC). OutFileMode: modo del file di uscita (0=Annex B, 1=RTP). PartitionMode: partizionamento dei dati (0= disabilitato, 1=3 partizioni per slice). A.1.6 Codifica interlacciata PicInterlace: riferito alla modalità di codifica interlacciata (0=codifica a frame, 1=codifica a field, 2=codifica adattativa frame/field). MbInterlace: riferito alla modalità di codifica interlacciata (0=codifica a frame, 1=codifica a field, 2=codifica adattativa frame/field, 3=codifica dei MB adattativa frame/field). A.1.7 Restrizioni del Search Range / Ottimizzazione RD RestrictionSearchRange: limitazioni alla ricerca dei vettori i di moto (0=blocchi e riferimenti, 1=riferimenti, 2=nessuna limitazione). RDOptimization: ottimizzazione lagrangiana RD (0=disabilitata, 1=attiva con alta complessità, 2=attiva con bassa complessità, 3=con perdite). WeightedPrediction: predizione pesata delle immagini P (0=disabilitata). A.2 Parametri di configurazione del decodificatore I parametri importanti del file <decoder.cfg> sono: InputFile: Sequenza compressa di ingresso nel formato.264. OutputFile: file di uscita nel formato YUV o RGB. RefFile: File di riferimento per il calcolo dello PSNR. DecodeAllLayers: Abilita la decodifica delle diverse viste. 96

107 APPENDICE B: CODICE INSERITO NEL CODIFICATORE JM 17.2 PER IL SUPPORTO DEL PROFILO STEREO DI MVC Per ogni file sono state riportate le diverse modifiche realizzate nella nuova versione del software di riferimento, segnalate lungo il codice con la bandiera MVC_EXTENSION_ENABLE. TIPO 1 TIPO 2 TIPO 3 JM 17.2\lencod\inc\defines.h: Header file containing useful global definitions. Linee 52, 74 fino a 75. JM 17.2\lencod\inc\global.h: Global definitions for H.264 encoder. Definizione della struttura PrevCodingStats: Linee 776 fino a 799. Struttura DistortionParams: Linee 813 fino a 816. Struttura VideoParameters: Linee 909 fino a 915, 1199 fino a 1201, 1213 fino a JM 17.2\lcommon\inc\enc_statistics.h: statistics reports for the encoding process. Typedef StatParameters: statistics reports for the encoding process. Linee 56 fino a 66. JM 17.2\lcommon\inc\params.h: Input parameters related definitions. Struttura inp_par_enc: Linee 67 fino a

108 TIPO 4 TIPO 5 TIPO 6 TIPO 7 JM 17.2\lencod\inc\configfile.h: Prototypes for configfile.c and definitions of used structures. Linee 67 fino a 74. JM 17.2\lencod\src\conformance.c: Level & Profile related conformance functions. Funzione ProfileCheck: Check Profile conformance. Linee 189 fino a 192, 197 fino a 203. JM 17.2\lencod\src\configfile.c: Configuration handling. Funzione PatchInp: Checks the input parameters for consistency. Linee 735 fino a 741, 899 fino a 911, 1125 fino a JM 17.2\lencod\src\img_dist_snr.c: Compute signal to noise ratio (SNR) between the encoded image and the reference image. Funzione find_snr: Find SNR for all three components. Linee 45 fino a 60, 68 fino a 74. JM 17.2\lencod\src\list_reorder.c: Generate the slice header, setup the bit buffer for slices, and generates the slices NALU(s). Funzione poc_ref_pic_reorder_frame_default: Linee 95 fino a 100. Funzione poc_ref_pic_reorder_field: Linee 294 fino a 299. JM 17.2\lcommon\inc\nalucommon.h: NALU common to encoder and decoder. Enum NaluType: Values for nal_unit_type. Linee 37 fino a 42. Struttura NALU_t: NAL unit structure. Linee 64 fino a 73. JM 17.2\lencod\src\nalu.c: Common NALU support functions. Funzione RBSPtoNALU: Converts an RBSP to a NALU. Linee 50 fino a 54, 62 fino a 72. JM 17.2\lencod\inc\parset.h: Picture and Sequence Parameter Sets, encoder operations. Linee 30 fino a 32, 43 fino a 47. JM 17.2\lencod\src\parset.c: Picture and Sequence Parameter set generation and handling. 98

109 TIPO 8 TIPO 9 Funzione GenerateSeq_parameter_set_NALU: Linee 153 fino a 157. Funzione GenerateSubsetSeq_parameter_set_NALU: Linee 164 fino a 194. Funzione GenerateSequenceParameterSet: Linee 262 fino a 265. Funzione GeneratePictureParameterSet: Linee 433 fino a 436. Funzione GenerateSeq_parameter_set_rbsp: Linee 636 fino a 640, 655 fino a 667, 750 fino a 831. JM 17.2\lencod\src\annexb.c: Annex B Byte Stream format NAL Unit writing routines. Funzione WriteAnnexbNALU: Linee 67 fino a 96, 113 fino a 126. JM 17.2\lencod\src\filehandle.c: Start and terminate sequences. Funzione start_sequence: This function opens the output files and generates the appropriate sequence header. Linee 105 fino a 120, 137 fino a 142. Funzione rewrite_paramsets: This function opens the output files and generates the appropriate sequence header. Linee 193 fino a 203, 220 fino a 225. JM 17.2\lencod\src\report.c: Report related files. Funzione report_frame_statistic: Linee 120 fino a 124. Funzione report: Linee 666 fino a 668, 735 fino a 755, 766 fino a 784, 839 fino a 872, 885 fino a 910, 913 fino a 921, 927 fino a 935. Funzione information_init: Prints the header of the protocol. Linee 1011 fino a 1014, 1019 fino a 1025, 1171 fino a 1179, 1187 fino a 1204, 1221 fino a 1238, 1255 fino a JM 17.2\lencod\src\MMCO.c: Memory Management Control Operations Funzione poc_based_ref_management_frame_pic: Linee 100 fino a 105. TIPO 10 JM 17.2\lencod\src\header.c: H.264 Slice and Sequence headers. Funzione SliceHeader: Linee 84 fino a 91, 181 fino a 185, 41 fino a 43, 321 fino a 371. Funzione get_picture_type: Linee 544 fino a

110 TIPO 11 JM 17.2\lencod\src\lencod.c: H.264/AVC reference encoder project main(). Funzione alloc_video_params: Allocate the Video Parameters structure. Linee 141 fino a 143. Funzione init_encoder: Initialize encoder. Linee 303 fino a 312, 384 fino a 391, 411 fino a 420, 439 fino a 447, 481 fino a 491. Funzione encode_sequence: Encode a sequence. Linee 577, 581 fino a 596, 600 fino a 617, 630 fino a 652, 665 fino a 671, 711 fino a 716. Funzione free_encoder_memory: Free memory allocated for the encoder. Linee 738 fino a 743. Funzione init_img: Initializes the Image structure with appropriate parameters. Linee 891 fino a 898. Funzione init_global_buffers: Dynamic memory allocation of frame size related global buffers. Linee 1315 fino a Funzione free_global_buffers: Free allocated memory of frame size related global buffers. Linee 1524 fino a TIPO 12 JM 17.2\lencod\inc\pred_struct_types.h: Header file for prediction structure types. Struttura FrameUnitStruct: Linee 88 fino a 90. Struttura SeqStructure: Linee 131 fino a 134. JM 17.2\lencod\src\pred_struct.c: Source file for prediction structure function headers. Funzione init_seq_structure: Linee 436 fino a 438, 472 fino a 475, 486 fino a 496. Funzione free_seq_structure: Free sequence structure. Linee 514 fino a 517. Funzione populate_frame: Set parameters for a single frame unit. Linee 1802 fino a Funzioni populate_frm_struct_mvc: Populate frame structure. Linee 2208 fino a Funzioni copy_frame_mvc: Linee 46 fino a 48, 2246 fino a TIPO 13 JM 17.2\lencod\inc\image.h: Headers for image processing. Linee 40 fino a

111 JM 17.2\lencod\src\image.c: Code one image/slice. Funzione writeout_picture: This function write out a picture. Linee 76 fino a 80, 1375 fino a Funzione write_el_field_vcl_nalu: Write EL (Enhancement layer) NALUs for field coded pictures. Linee 419 fino a 525. Funzione write_frame_picture: Write coded frame (one frame picture or two field pictures). Linee 527 fino a 607. Funzione read_input_data_32pulldown: Read input data while considering and performing a 3:2 pulldown process. Linee 624 fino a 653. Funzione read_input_data: Linee 690 fino a 704. Funzione perform_encode_field: Linee 729 fino a 733, 744 fino a 746, 762 fino a 765, 792 fino a 794, 805 fino a 807, 811 fino a 838, 846 fino a 851. Funzione free_slice_data: Linee 884 fino a 907. Funzione update_bitcounter_stats: Linee 981 fino a Funzione update_video_stats: Linee 1080 fino a Funzione encode_one_frame: Linee 1172 fino a 1181, 1189 fino a 1194, 1228 fino a 1241, 1314 fino a Funzione ReportSimple: Linee 2138 fino a Funzione ReportVerbose: Linee 2208 fino a Funzione ReportVerboseNVB: Linee 2280 fino a Funzione ReportVerboseFDN: Linee 2356 fino a Funzione ReportVerboseSSIM: Linee 2435 fino a Funzione ReportVerboseNVBSSIM: Linee 2463 fino a Funzione ReportVerboseFDNSSIM: Linee 2491 fino a Funzione ReportNALNonVLCBits: Linee 2524 fino a

112 Funzione ReportFirstframe: Linee 2576 fino a Funzione write_non_vcl_nalu_mvc: Linee 3049 fino a TIPO 14 JM 17.2\lencod\src\md_low.c: Main macroblock mode decision functions and helpers. Funzione encode_one_macroblock_low: Mode Decision for a macroblock. Linee 89 fino a 92. TIPO 15 JM 17.2\lencod\inc\mbuffer.h: Frame buffer functions. Linee 236 fino a 240. Typedef StorablePicture e FrameStore: Linee 124 fino a 128, 175 fino a 180. Typedef DecodedPictureBuffer: Linee 199 fino a 201. JM 17.2\lencod\src\mbuffer.c: Frame buffer functions. Funzione dump_dpb: Print out list of pictures in DPB. Used for debug purposes. Linee 87 fino a 90. Funzione init_dpb: Allocate memory for decoded picture buffer and initialize with sane values. Linee 223 fino a 235, 269 fino a 271. Funzione free_dpb: Free memory for decoded picture buffer. Linee 308 fino a 310. Funzione alloc_frame_store: Allocate memory for decoded picture buffer frame stores and initialize with sane values. Linee 344 fino a 350. Funzione alloc_storable_picture: Allocate memory for a stored picture. Linee 410 fino a 414. Funzione update_pic_num: Linee 1093 fino a 1095, 1101 fino a 1105, 1111 fino a 1115, 1129 fino a 1133, 1157 fino a 1161, 1185 fino a Funzione init_lists_p_slice: Initialize reference lists for a P Slice. Linee 1233 fino a 1236, 1262 fino a 1266, 1282 fino a 1286, 1309 fino a 1313, 1331 fino a 1333, 1347 fino a 1384, 1387 fino a Funzione init_lists_b_slice: Initialize reference lists for a B Slice. Linee 1449 fino a 1453, 1483 fino a 1487, 1504 fino a 1508, 1538 fino a 1542, 1572 fino a 1576, 1588 fino a 1592, 1656 fino a 1698, 1701 fino a Funzione update_ref_list: Update the list of frame stores that contain reference frames/fields. Linee 2004 fino a

113 Funzione update_ltref_list: Update the list of frame stores that contain long-term reference frames/fields. Linee 2058 fino a Funzione idr_memory_management: Perform Memory management for idr pictures. Linee 2118 fino a Funzione sliding_window_memory_management: Perform Sliding window decoded reference picture marking process. Linee 2148 fino a Funzione mm_unmark_short_term_for_reference: Adaptive Memory Management (mark short term picture unused). Linee 2214 fino a Funzione store_picture_in_dpb: Store a picture in DPB. Linea 2800 fino a 2824, 2880 fino a 2884, 2888 fino a Funzione replace_top_pic_with_frame: Insert the frame picture into the buffer if the top field has already been stored for the coding decision. Linee 2977 fino a 2981, 3010 fino a Funzione insert_picture_in_dpb: Insert the picture into the DPB. Linee 3079 fino a 3084, 3103 fino a 3109, 3134 fino a 3140, 3165 fino a 3171, 3176 fino a Funzione output_one_frame_from_dpb: Output one picture stored in the DPB. Linee 3463 fino a 3472, 3478 fino a 3482, 3488 fino a Funzione flush_dpb: All stored picture are output. Should be called to empty the buffer. Linee 3530 fino a TIPO 16 JM 17.2\lencod\src\slice.c: Headerfile for slice-related functions. Funzione create_slice_nalus: This creates a NAL unit structures for all data partition of the slice. Linee 310 fino a 313, 327 fino a 338, 347 fino a 349, 354 fino a 363. Funzione init_slice: Initializes the parameters for a new slice and allocates the memory for the coded slice in the Picture structure. Linee 1171 fino a 1186, 1314 fino a 1321, 1381 fino a Funzione init_slice_lite: Lite-weight initialization of the parameters for a new slice and allocates the memory for the coded slice in the Picture structure. Linee 1653 fino a 1668, 1763 fino a 1770, 1824 fino a

114 104

115 TABELLA DELLE FIGURE Figura 1. Rappresentazione di una sequenza video Figura 2. Metodi di Scansione Raster. Da [1] Figura 3. Generico sistema di codifica Figura 4. Diagramma a blocchi del metodo di codifica DPCM Figura 5. Esempio di sistema di codifica basato sulla trasformata DCT 8x Figura 6. Correlazione temporale tra frame consecutivi Figura 7. Codifica dell errore tra frame originale e ricostruito Figura 8. Stima del moto Figura 9. Struttura della codifica video H.264/AVC. Da [4] Figura 10. Gerarchia delle strutture dati in H.264/AVC Figura 11. Struttura del frame progressivo e interlacciato Figura 12. Suddivisione di un immagine in slice con FMO: Figura 13. Suddivisioni del macroblocco per la moto-compensazione. Da [4] Figura 14. Compensazione del moto con frame di riferimento multipli Figura 15. Esempi della predizione in un macroblocco di tipo B Figura 16. Catena di codifica dei macroblocchi. Da [4] Figura 17. Procedimento di creazione di un'unita di accesso. Da [4] Figura 18. Sintassi complessiva del bitstream in H.264/AVC. Da [5] Figura 19. Architettura dei sistemi MVC. Da [7] Figura 20. Array semi-circolare di camere all'università di Nagoya. Da [8] Figura 21. Blue-c portal, Eidgenössische Technische Hochschule, Zurigo Figura 22. Struttura di predizione tipica per MVC Figura 23. Punti di Operazione in MVC Figura 24. Formato del primo byte di una NALU Figura 25. Formato dei 3 byte aggiunti alle NALU di tipo 14 e 20 in MVC Figura 26. Schema del View-first Coding Figura 27. Schema del Time-first Coding Figura 28. Diagramma semplificato di un codificatore MVC stereoscopico Figura 29. Struttura di predizione tipica per applicazioni in tempo reale Figura 30. Parametri rilevanti a MVC aggiunti nel file *.cfg Figura 31. MVCInterViewReorder. (a) Spento, (b) attivo Figura 32. Struttura di predizione utilizzata per l'esempio Figura 33. Gestione del DPB Figura 34. Funzionamento dello strumento PRINTREFLISTS

116 Figura 35. Decodificatore JM Figura 36. Sequenza 30 fps Figura 37. PSNR vs Bit-Rate. Sequenza Akko&Kayo (Full Search) Figura 38. Sequenza 25 fps Figura 39. PSNR vs Bit-Rate. Sequenza Ballroom 0 1 (Full Search) Figura 40. PSNR vs Bit-Rate. Sequenza Ballroom 3 4 (Full Search) Figura 41. PSNR vs Bit-Rate. Sequenza Ballroom 6 7 (Full Search) Figura 42. Confronto dei tempi di codifica (Full Search) Figura 43. Sequenza 15 fps Figura 44. PSNR vs Bit-Rate (IntraPeriod = 0). Sequenza Breakdancers Figura 45. PSNR vs Bit-Rate (IntraPeriod = 5). Sequenza Breakdancers Figura 46. PSNR vs Bit-Rate (IntraPeriod = 1). Sequenza Breakdancers Figura 47. Confronto dei tempi di codifica. Sequenza Breakdancers Figura 48. Predittori spaziali. Da [11] Figura 49. Predittori temporali. Da [11] Figura 50. Posizioni degli updates. Da [11] Figura 51. Scelta del vettore di moto finale per la Coarse Search. Da [11] Figura 52. Fine Search in SLIMH264. Da [11] Figura 53. Grafo del profiling di HENC usando l'algoritmo SLIMH Figura 54. Eliminazione della Coarse Search nella seconda vista Figura 55. Riutilizzazione dei risultati precedenti nella predizione inter-view Figura 56. PSNR vs Bit-Rate. Sequenza Akko&Kayo (SLIMH264) Figura 57. PSNR vs Bit-Rate. Sequenza Ballroom 0-1 (SLIMH264) Figura 58. PSNR vs Bit-Rate. Sequenza Ballroom 3-4 (SLIMH264) Figura 59. PSNR vs Bit-Rate. Sequenza Ballroom 6-7 (SLIMH264) Figura 60. Confronto dei tempi di codifica (SLIMH264) Figura 61. Confronto dei tempi di codifica. SLIMH264 vs Full Search Figura 62. Numero di operazioni svolte per SLIMH264 e Full Search. Da [11].. 79 Figura 63. SLIMH264 vs No mode test. Sequenza Akko&Kayo Figura 64. SLIMH264 vs No mode test. Sequenza Ballroom Figura 65. SLIMH264 vs No mode test. Sequenza Ballroom Figura 66. SLIMH264 vs No mode test. Sequenza Ballroom Figura 67. Confronto dei tempi di codifica (No mode test) Figura 68. MB corrispondente e MB vicini nella vista base. Da [12] Figura 69. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Akko&Kayo Figura 70. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Ballroom Figura 71. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Ballroom Figura 72. SLIMH264 vs SLIMH264 Fast Decision. Sequenza Ballroom Figura 73. Confronto dei tempi di codifica (SLIMH264 Fast Decision) Figura 74. Confronto fra i diversi profili sviluppati di SLIMH

117 INDICE TABELLE Tabella 4. 1: Sequenza Akko&Kayo (Full Search) Tabella 4. 2: Sequenza Ballroom 0-1 (Full Search) Tabella 4. 3: Sequenza Ballroom 3-4 (Full Search) Tabella 4. 4: Sequenza Ballroom 6-7 (Full Search) Tabella 4. 5: Tempi di codifica Akko&Kayo (Full Search) Tabella 4. 6: Tempi di codifica Ballroom 0 1 (Full Search) Tabella 4. 7: Tempi di codifica Ballroom 3 4 (Full Search) Tabella 4. 8: Tempi di codifica Ballroom 6 7 (Full Search) Tabella 4. 9: Sequenza Breakdancers 4 5 (IntraPeriod = 0) Tabella 4. 10: Tempi di codifica Breakdancers 4 5 (IntraPeriod = 0) Tabella 4. 11: Sequenza Breakdancers 4 5 (IntraPeriod = 5) Tabella 4. 12: Tempi di codifica Breakdancers 4 5 (IntraPeriod = 5) Tabella 4. 13: Sequenza Breakdancers 4 5 (IntraPeriod = 1) Tabella 4. 14: Tempi di codifica Breakdancers 4 5 (IntraPeriod = 1) Tabella 4. 15: Confronto del bit-rate complessivo per Breakdancers Tabella 5. 1: Sequenza Akko&Kayo (SLIMH264) Tabella 5. 2: Tempi di codifica Akko&Kayo (SLIMH264) Tabella 5. 3: Sequenza Ballroom 0-1 (SLIMH264) Tabella 5. 4: Tempi di codifica Ballroom 0 1 (SLIMH264) Tabella 5. 5: Sequenza Ballroom 3-4 (SLIMH264) Tabella 5. 6: Tempi di codifica Ballroom 3 4 (SLIMH264) Tabella 5. 7: Sequenza Ballroom 6-7 (SLIMH264) Tabella 5. 8: Tempi di codifica Ballroom 6 7 (SLIMH264) Tabella 5. 9: Sequenza Akko&Kayo (No mode test) Tabella 5. 10: SLIMH264 vs No mode test. Sequenza Akko&Kayo Tabella 5. 11: Sequenza Ballroom 0-1 (No mode test) Tabella 5. 12: SLIMH264 vs No mode test. Sequenza Ballroom Tabella 5. 13: Sequenza Ballroom 3-4 (No mode test) Tabella 5. 14: SLIMH264 vs No mode test. Sequenza Ballroom Tabella 5. 15: Sequenza Ballroom 6-7 (No mode test) Tabella 5. 16: SLIMH264 vs No mode test. Sequenza Ballroom

118 Tabella 5. 17: Mode factors dei MB per ogni modo di codifica. Da [12] Tabella 5. 18: Sequenza Akko&Kayo (SLIMH264 Fast Decision) Tabella 5. 19: SLIMH264 vs SLIMH264 Fast Decision. Akko&Kayo Tabella 5. 20: Sequenza Ballroom 0-1 (SLIMH264 Fast Decision) Tabella 5. 21: SLIMH264 vs SLIMH264 Fast Decision. Ballroom Tabella 5. 22: Sequenza Ballroom 3-4 (SLIMH264 Fast Decision) Tabella 5. 23: SLIMH264 vs SLIMH264 Fast Decision. Ballroom Tabella 5. 24: Sequenza Ballroom 6-7 (SLIMH264 Fast Decision) Tabella 5. 25: SLIMH264 vs SLIMH264 Fast Decision. Ballroom

119 BIBLIOGRAFIA [1] D. R. Bull, M. E. Al-Mualla, C. N. Canagarajah. Video Coding for Mobile Communications: Efficiency, Complexity, and Resilience. Academic Press, [2] C. E. Shannon. A Mathematical Theory of Communication. The Bell System Technical Journal, vol. 27, pp , , October [3] J. R. Jain, A. K. Jain. Displacement Measurement and Its Application in Interframe Coding. IEEE Transactions on Communications, vol. 12, pp , Dicembre [4] T. Wiegand, G.J. Sullivan, G. Bjontegaard, A. Luthra. Overview of the H.264/AVC Video Coding Standard. IEEE Transactions on Circuits and Systems for Video Technology, vol. 13, n. 7, pp , Luglio [5] I. Richardson. H.264 and MPEG-4 Video Compression, pp John Wiley & Sons, England, [6] Y. Chen, Y. Wang, K. Ugur, M. M. Hannuksela, J. Lainema, M. Gabbouj. The Emerging MVC Standard for 3D Video Services. EURASIP Journal on Advances in Signal Processing, vol. 2009, pp Hindawi Publishing Corporation,Tampere, Finland. [7] D. Aliprandi. MULTIVIEW VIDEO CODING - Overview and Applications. STMicroelectronics, [8] D. Aliprandi. ST Technical Report - Multi-view Video Coding Status. STMicroelectronics, [9] ITU, International Telecomunication Union. Recommendation ITU-T H.264. [Online] Edition 5.0, In [10] D. Alfonso, D. Bagni, L. Pezzoni, E. Piccinelli. Fast Motion Estimation with detection of Scenes Changes and Interlaced/Progressive Content for H.264/AVC Encoding. STMicroelectronics. [11] L. Pezzoni. ST Technical Report - SLIM264 Motion Estimation Algorithm for H.264 video coding. STMicroelectronics, [12] S. Liquan, Y. Tao, L. Zhi, Z. Zhaoyang, A. Ping, Y. Lei. Fast Mode Decision for Multiview Video Coding. 17th IEEE International Conference on Image Processing,

120 110

121 LISTA DEGLI ACRONIMI CABAC CAVLC DCT DFT DPB DPCM FMO GOP IDR JVT KLT MAE MC ME MPEG MVC NAL NALU POC PSNR RPLR SAD SEI SVC VCEG VCL Context Adaptive Binary Arithmetic Coding Context Adaptive Variable Length Coding Discrete Cosine Transform Discrete Fourier Transform Decoded Picture Buffer Differential Pulse Code Modulation Flexible Macroblock Ordering Group of Pictures Instantaneous Decoding Refresh Joint Video Team Karhunen-Loeve Transform Mean Absolute Error Motion Compensation Motion Estimation Motion Pictures Experts Group Multi-View Video Coding Network Abstraction Layer Network Abstraction Layer Unit Picture Order Count Peak Signal-to-Noise Ratio Reference Picture List Reordering Sum of Absolute Differences Supplemental Enhancement Information Scalable Video Coding Video Coding Experts Group Video Coding Layer 111