Your SlideShare is downloading. ×
Sistemi e Reti Multimediali - studio della codifica 3D
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Sistemi e Reti Multimediali - studio della codifica 3D

238
views

Published on

in collaborazione con il Dott. Barone Donato

in collaborazione con il Dott. Barone Donato

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
238
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. SISTEMI E RETI MULTIMEDIALI: 3D Video Coding Tema d’anno in: «Indagine sulla codifica del video 3D nei tre principali formati: MV, SideBySide, Video Plus Depth» Relatori: Prof. Ing. L.A.Grieco Ing. C. Ceglie Studenti: Donato Barone - red_barone@libero.it Marco Suma – smumrc@gmail.com
  • 2. Sommario 1. Introduzione ................................................................................................................................................... 4 2. Cos’è il Video 3D ............................................................................................................................................. 4 3. Formati video 3D ............................................................................................................................................ 5 3.1 Conventional Stereo Video ....................................................................................................................... 5 3.2 Video 2D+Mappa di profondità (Video Plus Depth) ................................................................................. 8 3.3 Mixed Resolution Stereo (MRS)..............................................................................................................11 4. Tecniche di codifica ......................................................................................................................................13 4.1 H.264/AVC ..............................................................................................................................................13 4.2 Multiview Video Coding .........................................................................................................................16 4.3 MPEG-C Parte 3 ......................................................................................................................................18 5. Strumenti Utilizzati .......................................................................................................................................19 5.1 JMVC .......................................................................................................................................................19 5.2 Compilazione piattaforma Linux.............................................................................................................20 6. VIDEO 3D ......................................................................................................................................................20 7. PSNR3D .........................................................................................................................................................21 8. Descrizione del lavoro svolto ........................................................................................................................22 8.1 Encoder Configuration ............................................................................................................................23 8.2 Operazioni svolte ....................................................................................................................................23 9. Discussione dei risultati ................................................................................................................................23 9.1 Osservazioni preliminari .........................................................................................................................24 9.2 Osservazioni grafiche..............................................................................................................................25 10. Conclusioni .................................................................................................................................................27 APPENDICE A ...................................................................................................................................................30 APPENDICE B....................................................................................................................................................31 MV – Configuration File ...............................................................................................................................31 VpD – Configuration File ..............................................................................................................................32
  • 3. SbS – Configuration File ...............................................................................................................................34 RIFERIMENTI ....................................................................................................................................................37
  • 4. 1. Introduzione Il lavoro svolto in questo tema d’anno è stato quello di confrontare le prestazioni di codifica inerenti ai tre formati principali di rappresentazione del video 3D: MV (Multiview Video) codificato con MVC[1], SbS (SideBySide) codificato con H.264/AVC e VpD (Video Plus Depth) codificato anch’esso con MVC. Di seguito mostriamo alcuni aspetti teorici riguardanti il video 3D ed i vari formati utilizzabili. 2. Cos’è il Video 3D Per poter capire cosa significhi esattamente realizzare un video 3D è opportuno chiedersi come l’essere umano sia in grado di percepire la tridimensionalità (stereoscopia = visione nello spazio)[6]. Il sistema visivo umano è un architettura complessa che cattura informazioni dall’esterno mediante l’uso degli occhi (due “dispositivi di input”), ma la domanda è: com’è possibile riuscire a percepire un informazione di profondità attraverso una membrana (rètina) dotata di una superficie bidimensionale? Tutto ciò è ovviamente possibile, e la spiegazione è data dal fatto che il nostro cervello è in grado di sfruttare i cosiddetti indizi pittorici (monoculari) [2] e indizi fisiologici (binoculari) [6], ricostruendo la scena 3D a partire dalle informazioni provenienti dalle due rètine. Sulla base di queste conoscenze, l’obiettivo è quindi quello di “ingannare” il nostro cervello cercando di riprodurre (su schermi o proiettori adeguati) immagini ricostruibili tridimensionalmente; le fasi saranno quindi le seguenti: 1) Acquisire flussi video da due telecamere distinte, emulando il comportamento dei nostri occhi; 2) Sfruttare gli indizi monoculari e binoculari per “ingannare” il cervello; Riuscire a discriminare il flusso video diretto all’occhio sinistro da quello diretto all’occhio destro; questo è possibile mediante: a. Stereoscopia passiva [6]; i. Separazione dei canali (rosso e ciano); ii. Polarizzazione (lineare o circolare); b. Stereoscopia attiva (active shutter – tecniche basate sulla persistenza retinica)[6]; c. Autostereoscopia (mediante la barriera di parallasse o rete lenticolare) [5][6].
  • 5. 3. Formati video 3D 3.1 Conventional Stereo Video Il Conventional Stereo Video (CSV) è un formato di rappresentazione di un video 3D e si compone di due flussi video distinti: uno per la vista sinistra e uno per la vista destra di una stessa scena. Si sfrutta il fenomeno della stereopsi, cioè basare la rappresentazione del video 3D su ciò che fa normalmente il nostro sistema visivo. Il nostro cervello preleva i due “flussi” video provenienti dall’occhio sinistro e destro e successivamente fonde le due immagini. In questo modo si ottiene una visione tridimensionale e si ricavano informazioni sulla profondità e sulla posizione dell’oggetto. Il principio che si utilizza per la CSV è appunto quello di usare due telecamere distinte poste ad una distanza usualmente di 65 mm (distanza interpupillare media); i due flussi rappresenteranno rispettivamente la vista sinistra e destra della scena. L’obiettivo è stimolare il cervello a riprodurre la stereopsi [6] andando a veicolare all’occhio sinistro il flusso video sinistro e all’occhio destro quello destro. Poi a seconda della tecnologia utilizzata i due frame saranno usati per ottenere l’effetto 3D. I problemi che ci si trova ad affrontare durante la fase di acquisizione non sono pochi; alcuni di questi sono:  Problemi di allineamento: le telecamere devono essere perfettamente allineate;  Problemi di sincronia: l’acquisizione dei due flussi deve essere sincronizzata;  Problemi di messa a fuoco e zoom: i parametri caratterizzanti lo zoom e la messa a fuoco devono essere identici. Di seguito, a titolo di esempio, in Fig.1 e Fig.2 vengono mostrati i due frame sinistro e destro di una stessa scena. Fig.1 : Esempio di frame di una vista.
  • 6. Fig.2 : Esempio di frame di un'altra vista. 3.1.1 Top-and-Bottom e Side-by-Side Il multiplexing dei frame di un video 3D [6][10][11] può essere suddiviso in:  Frame compatibile;  Frame incompatibile. Nel primo caso i due frame relativi alle due viste vengono sottocampionati e successivamente inseriti all’interno di un unico frame 2D. Questo approccio permette di utilizzare la stessa banda usata per l’invio di un normale video 2D, ma porta ad una perdita di risoluzione. Nel secondo caso, invece, i frame sono lasciati a piena risoluzione: questo porta ad un maggior spreco di banda, ma in compenso non si ha perdita di risoluzione. Se il multiplexing viene fatto inserendo in ogni frame le immagini delle due viste una sotto l’altra, allora si parlerà di formato Top and Bottom. Fig.3 : Schema Top-and-Bottom. In Fig.3 viene mostrato il Top-and-Bottom (TaB) frame compatibile in cui i frame relativi alle due viste subiscono il processo di undersampling verticale con fattore 2 e successivamente vengono inseriti uno sotto l’altro all’interno del frame multiplexato che avrà dimensioni pari a quelle del frame 2D. L’altra soluzione
  • 7. consiste nell’andare a prelevare le immagini a piena risoluzione e di andarle ad inserire all’interno di un unico frame con larghezza pari a quella del frame 2D e con altezza doppia rispetto allo stesso. Fig.4 : Frame Top-and-Bottom. Usualmente l’immagine inserita nella parte alta del frame si riferisce alla vista sinistra. Tale tecnica viene normalmente utilizzata con formati 720p e 1080p; nel primo caso (720p) le righe dalla 26 alla 385 saranno utilizzate per la vista sinistra, mentre dalla 386 alla 745 per la vista destra (in totale sono 720 righe relative all’immagine che stiamo inviando); nel secondo caso (1080p) invece l’immagine sinistra va dalla 42 alla 581 e quella destra dalla 582 alla 1121 (ossia 1080 righe). L’offset iniziale è dovuto ad un blanking verticale che viene fatto sul frame come mostrato nella Fig.4 per un frame 720p[11]. Se il multiplexing viene fatto inserendo in ogni frame le immagini delle due viste una affianco all’altra, allora si parlerà di formato Side-by-Side. Analogamente al Tab, anche il SbS può essere frame compatibile e in questo caso il sottocampionamento è effettuato orizzontalmente di un fattore 2 e i due frame sono inseriti uno di fianco all’altro all’interno di un frame di dimensione pari a quella di un frame 2D; oppure frame incompatibile in cui vengono prese le immagini a piena risoluzione e vengono inserite all’interno di un frame che avrà stessa altezza di quello 2D, ma larghezza doppia. I vantaggi e gli svantaggi delle due tecniche li abbiamo già analizzati. In Fig.5 viene mostrato un esempio di multiplexing SbS frame compatibile.
  • 8. Fig.5 : Schema Side-by-side. All’interno dei frame generati sia per il primo che per il secondo formato è importante che venga mantenuto l’allineamento. Nel TaB i pixel di una i-esima riga dell’immagine multiplexata devono ritrovare i corrispettivi pixel relativi alla seconda vista con un shift costante di M/2 (M=altezza). Stessa cosa deve succedere per il SbS in cui lo shift è orizzontale e non verticale ed è pari a N/2 (N=larghezza). È possibile osservare il frame SbS nella Fig.6. Fig.6 : Frame side-by-side. 3.2 Video 2D+Mappa di profondità (Video Plus Depth) Uno dei formati molto spesso utilizzati per la rappresentazione di un video 3D è il video 2D+Mappa di profondità. Tale formato consiste nell’andare ad associare ad ogni frame, prelevato dalla vista destra o
  • 9. sinistra, una mappa di profondità ossia un’immagine in scala di grigi con le stesse dimensioni dell’immagine di partenza. Quest’ultima associa ad ogni pixel un livello di grigio proporzionale alla posizione che ogni pixel deve assumere sull’asse cartesiano Z (profondità), cioè se deve essere rappresentato dentro o fuori dal piano dello schermo; per questo motivo tale rappresentazione viene anche chiamata 2D+Z. Ogni pixel viene rappresentato con 8 bit e quindi il range di variabilità va da 0 a 255. Nel formato classico più un’area è chiara, quindi più i suoi pixel sono prossimi a 255 e più questa dovrà essere percepita vicina dall’utente; viceversa più un’area è scura e più l’utente dovrà percepirla lontana. L’unione delle due immagini: quella 2D e la mappa di profondità, vengono usate per realizzare il video 3D. Un esempio di un’immagine più mappa di profondità è stato riportato in Fig.7: Fig.7 : esempio di Video2D+mappa di profondità. Le tecniche attualmente utilizzate per realizzare la mappa di profondità sono principalmente tre:  Singola immagine 2D;  Geometria epipolare;  Time of Flight. La tecnica basata su singola immagine 2D consiste nel partire da un normale frame bidimensionale sul quale vengono individuati degli oggetti. Ad ogni singolo oggetto verrà associata una determinata profondità espressa in livelli di grigio; più l’oggetto è vicino e più questo dovrà essere bianco. Il metodo basato su geometria epipolare va ad effettuare un’analisi di uno stesso frame prelevato da due viste differenti (sinistra e destra) e sfrutta le informazioni relative ai punti di acquisizione per poter calcolare la profondità. La geometria epipolare non fa altro che descrivere le relazioni che intercorrono fra i
  • 10. frame 2D prelevati da fotocamere con posizione e orientamento differente. Per realizzare la mappa di profondità si parte dalle informazioni relative alla posizione delle videocamere, ipotizzando di avere una situazione simile a quella visibile in Fig.8: Fig.8 : prinicio di base per la geometria epipolare. A e B in questo caso rappresentano le due videocamere e C rappresenta l’oggetto preso in considerazione. Avendo le informazioni relative agli angoli α e β e la distanza b diventa poi semplice calcolare d che rappresenterà la profondità all’interno della nostra immagine. La tecnica utilizzata per ottenere la mappa di profondità sfrutta gli stessi principi. La tecnica Time of Flight consiste nell’andare ad utilizzare telecamere ad impulsi ad infrarossi per poter realizzare la mappa di profondità. La scena è catturata tramite queste particolari telecamere che emettono impulsi di luce e successivamente basandosi sul ritardo con cui il fascio prodotto per un determinato pixel ritorna sul sensore della fotocamera, si calcola la distanza che verrà associata al pixel. Il tutto quindi si basa sulla velocità della luce c=300000 km/s e il ritardo che i fasci associati ad ogni pel producono. La distanza sarà banalmente calcolabile come segue: Nel formato video 2D+Mappa di profondità si hanno i seguenti vantaggi:  Bandwidth necessaria molto vicina a quella del video 2D, quindi è possibile utilizzare le infrastrutture preesistenti per poter trasmettere siffatti contenuti;  Compatibilità con i tool di codifica per video 2D;  Elaborazioni più semplici e veloci. La banda necessaria si avvicina molto a quella richiesta per la trasmissione di un video 2D, perché in questo caso ci troviamo ad avere un video 2D a cui viene associata una mappa di profondità, ricordiamo che ogni frame della mappa non è nient’altro che un’immagine in scala di grigi e questo spiega come mai ci sia così poco overhead nella comunicazione.
  • 11. Anche la complessità computazionale nella fase di codifica viene ridotta, dato che la seconda vista 2D è una semplice sequenza di immagini in scala di grigi. Ovviamente utilizzare il formato video+Mappa prevede anche degli svantaggi:  Alcuni display esistenti non sono compatibili con questo formato;  8 bit per rappresentare la profondità può non sempre essere sufficiente;  Non permette di gestire trasparenza o parziale occlusione degli oggetti;  Non gestisce fenomeni di riflessione e rifrazione;  Il processo di generazione delle mappe non è banale. 3.3 Mixed Resolution Stereo (MRS) Un altro formato utilizzato per la rappresentazione di video 3D è il mixed resolution stereo [3]. Tale formato è normalmente utilizzato per ridurre il bitrate, cercando di mantenere praticamente invariata la qualità percepita dall’utente. Nel MRS una delle due viste viene filtrata e poi sottocampionata, mentre l’altra viene lasciata a piena risoluzione, quindi avremo come risultato i frame della prima vista di dimensione MxN(M=larghezza e N=altezza) e i frame della seconda vista a risoluzione più bassa pari ad esempio ad M/2xN/2. Ciò che si tenta di fare è sfruttare la teoria della soppressione binoculare attraverso la quale, anche se la nitidezza e la risoluzione dei frame di una delle due viste sono inferiori rispetto a quelle dei frame dell’altra vista, la qualità binoculare percepita è molto vicina a quella che si otterrebbe utilizzando i due video a piena risoluzione. Lo svantaggio principale è legato all’affaticamento a cui è sottoposto il sistema visivo umano; per ovviare a tale problematica, solitamente la vista sottocampionata viene alternata. Le operazioni che normalmente vengono fatte su una delle due viste sono:  Filtraggio passa basso;  Sottocampionamento. Il filtraggio passa basso viene utilizzato per eliminare tutte le componenti in alta frequenza presenti nell’immagine. Come risultato di tale operazione si ottiene un frame identico a quello di partenza, ma meno nitido come mostrato in Fig 9.
  • 12. Fig.9 : a sinistra viene mostrata l’immagine non filtrata e a destra quella filtrata passa basso. L’operazione successiva consiste in un undersampling, ossia un sottocampionamento per poterne diminuire la risoluzione. A destinazione il frame verrà sovracampionato ed utilizzato per la riproduzione del contenuto 3D. Questo porta alla conclusione che il formato MRS permette di ottenere una qualità molto vicina a quella che si otterrebbe utilizzando le due viste a piena risoluzione, restituendo un bitrate inferiore. Normalmente il formato MRS viene utilizzato in applicazioni di MOBILE 3DTV, per diminuire il bitrate riuscendo comunque a mantenere una qualità del video 3D elevata. Altro vantaggio nell’utilizzo di questo formato è relativo alla minore complessità computazionale con cui è possibile effettuare la decodifica, il che su dispositivi dalle capacità computazionali limitate è un elemento importantissimo. 4. Tecniche di codifica 4.1 H.264/AVC Il protocollo H.264 nasce dalla collaborazione tra MPEG e ITU-T. H.264 mira all’obiettivo di creare una codifica video altamente scalabile in grado di adattarsi a qualsiasi evenienza (da trasmissioni in real-time a codifiche in alta definizione). Macroscopicamente, si basa su due tecniche di codifica: - CAVLC (Context-Adaptive Variable Length Coding): è una codifica che, a scapito di una minore efficienza, richiede un minore sforzo computazionale; - CABAC (Context Adaptive Binary Arithmetic Coding): consente una maggiore efficienza nella codifica, richiedendo una maggiore complessità computazionale. H.264 definisce tre profili di codifica: 1. Baseline profile: che supporta la codifica intra- e inter- (con I-slices e P-slices) mediante una codifica entropica di tipo CAVLC; 2. Main profile: fornisce il supporto per l’interlaced video, la codifica inter- con l’uso di B-slice e una codifica entropica di tipo CABAC;
  • 13. 3. Extended profile: non utilizza CABAC, ma introduce nuovi tipi di slice (SP- e SI-slice) con l’aggiunta di un modulo Data Partitioning per la gestione degli errori di trasmissione. La struttura di una generica coded picture (ottenuta dalla fase di encoding del corrispondente frame) è organizzata in macroblocks, i quali a loro volta sono raggruppati in slice (i macroblocks non sono necessariamente contigui). Ciascuna slice può essere di tipo I, P o B e quindi conterrà solo macroblocks rispettivamente di tipo I, P o B [12]. H.264 si basa sempre sulla codifica di tipo intra-coding e inter-coding (descritte in MPEG-1), ma aggiunge delle ulteriori tecniche predittive: in particolare, nella intra-coding, i pixel di un determinato blocco (che può essere di dimensioni 8x8 o 4x4, a seconda di come venga scomposto il macroblocco 16x16) possono essere predetti dai pixel adiacenti al blocco in alto e a sinistra, sfruttando così la correlazione spaziale (vedi Fig. 10 e Fig. 11). Fig.10. rappresentazione dei pixel da predire in funzione dei pixel di riferimento in H.264. Fig. 11. Le 9 possibilità di predizione (mostrate dalle frecce) di un blocco 4x4. Nella inter-coding vengono ampliate le tecniche di codifica MPEG-1, consentendo: - la predizione anche da più di due frame (come invece accadeva per i frame di tipo B); - la scelta di blocchi di dimensione variabile (vedi Fig.12);
  • 14. Fig 12. Le varie possibilità di scelta della dimensione di macroblocks e sub-macroblock. - l’utilizzo dei vettori di moto con risoluzione pari a ¼ di pixel per la componente di luminanza e ⅛ di pixel per le componenti di crominanza. In Fig.13 viene mostrata una possibile scelta della dimensione dei blocchi che ottimizzi le prestazioni di codifica Fig 13. Visualizzazione della scelta delle dimensioni dei blocchi ottimale. La codifica si basa non più sull’utilizzo della trasformata DCT, bensì sulla trasformata di Hadamard, costruita esclusivamente mediante operazioni di somma e shift. Un ulteriore feature introdotta per migliorare la qualità del video è il filtro di de-blocking, il quale consente di “smussare” (smoothing) i pixel dei blocchi adiacenti per annullare gli effetti di codifica a blocchi. La struttura di un terminale di encoding H.264/AVC, è composta da: - un blocco VLC, il quale effettua le operazioni di codifica;
  • 15. - un blocco Data Partitioning, il quale suddivide e frammenta i pacchetti in base a un ordine di priorità legata al contenuto degli stessi; - un blocco di Network Abstraction Layer, il quale si occupa di trasmettere in rete il contenuto codificato del video (vedi Fig.14). Fig. 14. Rappresentazione architetturale di un terminale di encoding H.264. 4.2 Multiview Video Coding La multiview video coding (MVC) [7][10] non è nient’altro che un estensione del codec H.264/AVC; la differenza fondamentale tra i due è che il primo è ottimizzato per la compressione di Multiview Video (MVV), mentre il secondo è stato realizzato per la compressione di filmati 2D. Un MVV è un formato di rappresentazione dei video 3D che non utilizza la classica stereocoppia, ma va a sfruttare le N viste ottenute da una stessa scena. L’acquisizione viene effettuata utilizzando N videocamere equidistanziate, quindi è possibile intuire come le immagini acquisite siano altamente correlate tra loro. La MVC va proprio a sfruttare questa elevata correlazione e cerca di eliminare le ridondanze intervista in modo tale da ottenere la massima compressione dei file originali. Ovviamente il codec di base per la compressione rimane H.264/AVC: la differenza sta appunto nel considerare la correlazione intervista che tale codec non prevede. L’approccio di MVC è il seguente: la prima vista passata viene codificata nel modo classico sfruttando solo le dipendenze intravista; le successive, al contrario, vengono codificate in modo tale da prendere in considerazione le ridondanze intervista. Un esempio della matrice di picture che si viene a generare è mostrata in Fig.15:
  • 16. Fig.15 : esempio di disposizione dei frame I,P,B nelle 8 viste. Si può osservare come solo all’interno della prima vista (prima riga) siano presenti frame di ancoraggio di tipo I, ossia la cui codifica va a considerare solo le ridondanze intraframe. Le successive viste negli istanti T0 e T8 presentano solo frame di tipo P o B e non frame di tipo I. Gli archi presenti nella figura ci mostrano quali sono le dipendenze in termini di immagine di riferimento che ci sono fra i vari frame. Ad esempio nella vista S2 il frame all’istante T0 ha come immagine di riferimento per la predizione quello della vista S0 all’istante T0, mentre il frame all’istante T0 della vista S1 utilizza come immagini di riferimento i frame corrispondenti nella vista S0 e S2 allo stesso istante. Le altre innovazioni portate nel MVC sono state la compensazione dell’illuminazione (Illumination Compensation) e del moto (Motion skip) [7]. Dato che vengono utilizzate immagini prese da N viste in molti casi si possono avere delle inconsistenze di illuminazione e di colore dovute a variazioni di illuminazione tra lo stesso frame appartenente a viste differenti. Per questo motivo si utilizza la compensazione dell’illuminazione che consiste nell’andare a calcolare un fattore di compensazione per ogni singolo macroblocco che in fase di ricostruzione del video viene sommato o sottratto allo stesso. Tale fattore di compensazione sarà presente se la compensazione dell’illuminazione è abilitata per quel determinato macroblocco; normalmente tale coefficiente viene ottenuto tramite delle medie effettuate sul macroblocco del frame di riferimento presente in un’altra vista. Per quanto riguarda la compensazione del moto, come abbiamo già visto in precedenza, non ci si limita a permettere la predizione dei frame solo con frame di riferimento appartenenti alla stessa vista, ma vengono utilizzati frame appartenenti a viste adiacenti. Nel nostro tema d’anno i formati video MV e VpD sono stati codificati entrambi con MVC. 4.3 MPEG-C Parte 3 Lo standard ISO/IEC 23002-3, conosciuto anche come MPEG-C Parte 3, è uno standard creato dal Motion Picture Experts Group ottimizzato per la compressione di file 3D rappresentati nel formato Video+Mappa di profondità.
  • 17. Con la realizzazione del MPEG-C Parte 3 si è cercato di realizzare uno standard che prevedesse le seguenti caratteristiche: 1. Interoperabilità; 2. Indipendenza dalla tecnologia degli schermi; 3. Retrocompatibilità; 4. Efficienza di compressione. L’indipendenza dalla tecnologia degli schermi utilizzati è una caratteristica importantissima da prendere in considerazione; infatti questo standard è in grado di funzionare (e quindi di essere utilizzato per la riproduzione di contenuti 3D) sia da schermi autostereoscopici con barriera di parallasse, sia da schermi autostereoscopici con rete lenticolare e sia da schermi basati su stereoscopia attiva o passiva in cui si ha bisogno dell’ausilio di occhiali per poter visionare il contenuto 3D. La retrocompatibilità è stata presa in considerazione in modo da sfruttare standard di codifica già consolidati e testati per video 2D e utilizzarli per codificare un video rappresentato nel formato VpD. Inoltre MPEG-C Parte 3 è stato realizzato in modo tale da poter consentire anche la compatibilità con eventuali standard di codifica futuri. In Fig.16, viene mostrata una completa catena stereoscopica che illustra le varie fasi che bisogna affrontare dal momento in cui il video nel formato VpD viene acquisito a quando viene visualizzato. Tale standard non si limita a definire come trattare la profondità, ma specifica un formato Dati per il Video Ausiliario [4]. Viene associato un vettore di N-bit ad ogni pixel che rappresenta la profondità e questo permette di poter comprimere tali informazioni con gli algoritmi attualmente presenti per la compressione di un normale video 2D. Aux_video_data_type è un elemento di dimensione pari ad un singolo byte utilizzato per poter descrivere il tipo di dati immagazzinato nel video ausiliario. La potenza di tale soluzione risiede nel fatto che viene specificata solo la semantica dell’elemento, ma non il modo in cui questo deve essere trasmesso. Due erano i tipi di dati inizialmente previsti: Profondità o Parallasse (restituisce informazioni sulla profondità). Il primo codificato con il valore 0x10 e il secondo con 0x11. Gli altri valori previsti sono stati riservati per usi futuri. MPEG-C Parte 3 può essere utilizzato anche con applicazioni a bassissimo bitrate, infatti viene data la possibilità di sottocampionare la mappa di profondità sia nel tempo che nello spazio, in questo modo si ha una bassa perdita di informazioni, ma si guadagna parecchio in termini di banda necessaria. A destinazione verrà effettuato un sovracampionamento per poter permettere la visualizzazione.
  • 18. Fig.16: esempio di una catena stereoscopica completa per il VpD. 5. Strumenti Utilizzati 5.1 JMVC La fase di codifica è stata elaborata per mezzo del software JMVC 8.5(Joint Multiview Video Coding), particolarmente adatto alla codifica MVC, ma utilizzabile anche per il SbS, il VpD (considerando la mappa di profondità come essa stessa una vista) e per il SbS (una sola vista). A conferma di quanto detto, JMVC è basato sulla codifica H.264/AVC: in aggiunta prevede le features opportune per codificare le varie viste. Questo software è ottenibile accedendo ad un CVS Server mediante un CVS client installabile sulla propria macchina specificando i parametri descritti nella Tab.1. Il software è scritto in C++ ed è disponibile per piattaforma Windows e Linux; viene messo a disposizione sottoforma di codice sorgente e quindi dev’essere compilato sulla propria macchina: nel nostro caso è stata utilizzata una piattaforma Linux (distribuzione Ubuntu v12.04). Tab.1: CVS access parameters authentication: host address: path: user name: password: module name: pserver garcon.ient.rwth-aachen.de /cvs/jvt jvtuser jvt.Amd.2 jmvc
  • 19. 5.2 Compilazione piattaforma Linux Utilizzando il compilatore gcc versione 4 è sufficiente, da linea di comando, posizionarsi all’interno della cartella JMVC/H264AVCExtension/build/linux e lanciare il comado make. In questo modo verranno generati gli eseguibili e le librerie necessarie per l’utilizzo. In particolare i file eseguibili utilizzati sono stati i seguenti: - bin/H264AVCDecoderLibTestStatic; - bin/H264AVCEncoderLibTestStatic; - bin/MVCBitStreamAssemblerStatic; - bin/PSNRStatic. H264AVCEncoderLibTestStatic: attraverso questo tool è possibile effettuare l’encoding vero e proprio di un video. MVCBitStreamAssemblerStatic: i vari stream .264 ottenuti dalla codifica di ciascuna vista vengono assemblati grazie all’utilizzo di questo tool. H264AVCDecoderLibTestStatic: questo tool è dedicato alla fase di decodifica ed è quindi utilizzato per poter ricostruire il flusso video .yuv simulando la fase di ricezione. PSNRStatic: passando il file originale e il file ottenuto dalla fase di decodifica, con questo eseguibile è possibile ottenere le informazioni circa il bitrate e il psnr per ciascuna delle tre componenti (Y, U, V). 6. VIDEO 3D Il video utilizzato e disponibile nei tre formati è ottenibile consultando [8] e utilizzando un client FTP per accedere ai contenuti richiesti; nel nostro caso abbiamo utilizzato quanto riportato in Fig.17: Fig.17 Descrizione del video e frame di esempio del video codificato.
  • 20. 7. PSNR3D Per poter valutare i risultati ottenuti dalla codifica e decodifica dello stesso video nei tre formati: MV, SbS e Video+Mappa è stato realizzato un applicativo con le librerie Qt [9]. La versione utilizzata è la 4.7.4. Il software, vedi Appendice A, permette all’utente di selezionare tramite una classica finestra di browsing, Fig.18, i file con estensione .txt che contengono i valori di bitrate e PSNR per le tre componenti generati dal tool messo a disposizione da JMVC. Essendo questi file .txt strutturati in maniera molto semplice, viene effettuata una banale scansione del testo e vengono estratti i dati di nostro interesse. Dopo aver caricato i file l’utente potrà decidere di generare i grafici associati ai dati caricati. I grafici generati dal software sono tre in totale e permettono di mettere in relazione il PSNR della componente Y in funzione sia del Qp che del bitrate e di analizzare il bitrate in funzione del Qp. In ogni singolo grafico sono state generate le curve evidenziandole rispetto al formato. Le motivazioni alla base della creazione di questo applicativo sono le seguenti:  Automatizzare il processo di reperimento dei dati dai vari file risultanti dal calcolo del PSNR attraverso il tool messo a disposizione da JMVM;  Rendere il caricamento dei dati UserFriendly grazie all’utilizzo di un’interfaccia grafica;  Generare e confrontare tutti i grafici di nostro interesse all’interno di un’unica schermata, così da rendere più semplice la loro analisi;  Riuso, nel caso si volesse effettuare la stessa elaborazione associata ad un video differente potrebbe essere fatta in pochi semplici click;  Acquisire i dati direttamente dai file eliminando possibili errori di trascrizione. Ovviamente si poteva optare anche per la via più semplice e cioè utilizzare banalmente Excel, ma per i motivi suddetti e per poter approfondire la conoscenza delle librerie Qt è stata scelta questa strada. Il software si presenta con una semplice interfaccia grafica tramite la quale è possibile caricare i file con all’interno i valori di PSNR per i tre formati. Dopo aver terminato il caricamento l’utilizzatore potrà generare i grafici cliccando sull’icona apposita. La GUI di partenza è mostrata in Fig.19.
  • 21. Fig.18 Finestra di browsing utilizzata per selezionare i file .txt Fig.19 : GUI del PSNR3D. 8. Descrizione del lavoro svolto Per analizzare in dettaglio le varie prestazioni ottenute dai tre formati video 3D, abbiamo opportunamente configurato il file .cfg utile alla procedura di encoding: in particolare, per ciascuno dei tre formati, abbiamo lanciato la procedura di encoding con 5 valori di BasisQp (Quantization parameter) diversi (21,24,28,31,34): il nostro obiettivo parziale è stato quello di misurare le prestazioni (in termini di bitrate e
  • 22. psnr) al variare del BasisQp, constatando, tra l’altro, una degradazione della qualità percepita all’aumentare dello stesso. 8.1 Encoder Configuration La configurazione dell’encoder per codificare i tre formati diversi è rimasta pressoché la stessa, in modo tale da poter effettivamente confrontare i risultati in maniera attendibile: questo è stato anche il motivo per il quale abbiamo utilizzato sempre JMVC per poter codificare MV e VpD con MVC e SbS con H.264/AVC. [per i file di configurazione vedi Appendice B]. 8.2 Operazioni svolte Sono stati lanciati i seguenti comandi relativi agli eseguibili messi a disposizione da JMVC per 5 volte, una per ogni BasisQp scelto. Tale procedura è stata ripetuta per tutti e tre i formati presi in analisi, il che ha condotto ad un totale di 15 iterazioni: ./H264AVCEncoderLibTestStatic -vf cfg_<tipo-formato>_<BasisQP> <view_x> >> encoding_<viev_x>_<tipo-formato>_<BasisQP>.log ./MVCBitStreamAssemblerStatic -vf assembler_<tipo-formato>_<BasisQP> >> assembling_<tipo-formato>_<BasisQP>.log ./H264AVCDecoderLibTestStatic stream-<tipo-formato>_<BasisQP>.264 decoded_<tipoformato>_<BasisQP>.yuv 2 >>decoding_<tipo-formato>_<BasisQP>.log ./PSNRStatic 432 240 view_0.yuv decoded_<tipo-formato>_<BasisQP>_<viex_x>.yuv 0 0 stream-<tipo-formato>_<BasisQP>_<view_x>.264 25 >>PSNR_<tipoformato>_<BasisQP>_<view_x>.log Ad esempio, per la codifica del formato VpD, la sequenza di istruzioni per BasisQp=34 è stata la seguente: ./H264AVCEncoderLibTestStatic -vf cfg_left-plus-depth_34 0 >> encoding_0_leftplus-depth_34.log ./H264AVCEncoderLibTestStatic -vf cfg_left-plus-depth_34 1 >> encoding_1_leftplus-depth_34.log ./MVCBitStreamAssemblerStatic -vf assembler_left-plus-depth_34 >> assembling_left-plus-depth_34.log ./H264AVCDecoderLibTestStatic stream-left-plus-depth_34.264 decoded_left-plusdepth_34.yuv 2 >>decoding_left-plus-depth_34.log ./PSNRStatic 432 240 view_0.yuv decoded_left-plus-depth_34_0.yuv 0 0 streamleft-plus-depth_34_0.264 25 >>PSNR_left-plus-depth_34_0.log ./PSNRStatic 432 240 view_1.yuv decoded_left-plus-depth_34_1.yuv 0 0 streamleft-plus-depth_34_1.264 25 >>PSNR_left-plus-depth_34_1.log 9. Discussione dei risultati Per ciascuno dei tre formati, vengono mostrati nelle Tab.2, Tab.3 e Tab.4 i risultati della codifica ottenuti variando i valori di BasisQp. Oss.: nei casi di MV e VpD i risultati sono ottenuti come media dei singoli valori ottenuti per ciascuna vista. Tab.2. – Video-plus-depth BasisQp bitrate [Kbps] PSNR-y [dB] 21 168,704 45,01075 24 112,342 43,7539
  • 23. 28 66,485 42,1062 31 45,848 40,72395 34 31,962 39,56145 Tab.3. – Side by Side BasisQp Bitrate [Kbps] PSNR-y [dB] 21 305,812 44,4761 24 207,316 43,1406 28 128,134 41,4000 31 92,832 40,1323 34 67,854 38,8073 Tab.4. –MultiView BasisQp bitrate [Kbps] PSNR-y [dB] 21 136,679 44,5571 24 91,037 43,2159 28 54,682 41,4419 31 39,437 40,12905 34 28,986 38,65445 9.1 Osservazioni preliminari Premesso che PSNR=10 log 10 Max 2 MSE Peak Signal to Noise Ratio Formula n.1 MSE = 1 M∗N M −1 N−1 ∑ ∑ [ x (i , j)−x ' (i , j )]2 i=0 Mean Squared Error j=0 Formula n.2 Nella Formula n.1 del rapporto tra Max e MSE viene calcolato il logaritmo in base 10 e poi quest’ultimo viene moltiplicato per 10 per poterlo esprimere in dB. Max all’interno della stessa formula sta ad indicare semplicemente il valore massimo che un pixel, appartenente alle due immagini che si stanno comparando, può assumere. MSE non è nient’altro che l’errore quadratico medio la cui espressione viene esplicitata nella Formula n.2. In quest’ultima M e N rappresentano la larghezza e l’altezza del frame. Infine x(i,j) e x’(i,j) rappresentano rispettivamente il valore del pixel che occupa la riga i-esima e la colonna j-esima del frame non compresso e di quello ricostruito. Possiamo immediatamente notare che, nei tre casi, all’aumentare del BasisQp diminuisce il bitrate e il PSNR della componente Y: questa è una ovvia conseguenza del ruolo che svolge il parametro BasisQp: esso infatti misura il fattore di degradazione inerente alla fase di quantizzazione della codifica.
  • 24. 9.2 Osservazioni grafiche Grafico 1. Rappresentazione del PSNR della componente di luminanza in funzione del BasisQp. Nel Grafico 1, il PSNR della componente di luminanza viene calcolato in funzione del BasisQp; per tutti e tre i formati possiamo osservare una relazione del tipo y=k-a*x, in cui x rappresenta il QP, y il PSNR della componente di luminanza, a il coefficiente angolare che determina l’inclinazione delle rette e k non è nient’altro che il termine noto che permette di shiftare le rette. In questo caso il formato VpD codificato con MVC, a parità di Qp, risulta avere un maggior valore del PSNR-Y: questo è un aspetto importante perché ci indica che il formato VpD ha subito una minore degradazione (in termini di qualità) rispetto agli altri. La motivazione è verosimilmente legata al fatto che, poiché la seconda vista è una mappa di profondità (vedi Fig. 20), si riesce a comprimere meglio un immagine di questo tipo.
  • 25. Fig.20 : esempio di mappa di profondità associata ad un dato frame: come è possibile vedere, la descrizione della profondità, ottenuta ad esempio come frutto di operazioni di segmentazione e labeling degli oggetti principali presenti nel frame, consente una codifica intra-frame ottimale. Grafico 2. Rappresentazione del PSNR della componente di luminanza in funzione del bitrate. Nel Grafico 2, rapportiamo il PSNR della componente di luminanza Y al bitrate necessario; ciascuno dei punti evidenziati (cerchio, croce o triangolo) corrisponde ad uno dei 5 valori di BasisQp (per valori più alti di bitrate corrispondono i BasisQP con valore più basso); nei tre casi l’andamento delle tre curve è di tipo logaritmico. L’osservazione che può essere fatta è che il massimo valore di PSNR (≈45) è stato ottenuto con il formato VpD codificato con MVC con BasisQp = 21, peraltro con un valore non elevato del bitrate. Nel
  • 26. complesso le prestazioni ottenute con i formati VpD e MV codificati con MVC sono piuttosto simili; il formato SbS codificato con H.264/AVC ha restituito risultati meno positivi. Grafico 3. Rappresentazione dell’andamento del bitrate in funzione del BasisQp Nel Grafico 3 il bitrate viene espresso in funzione del BasisQp: notiamo immediatamente nei tre casi che l’andamento del bitrate è inversamente proporzionale al BasisQp secondo la legge y=k/x, con ksbs>kvpd>kmx. Di conseguenza, a parità di BasisQp, il formato MV codificato con MVC necessità di un minor bitrate. Questo aspetto è sicuramente positivo, dal momento che in una ipotetica trasmissione multimediale in rete, avremmo bisogno di una banda inferiore rispetto agli altri formati. È anche vero che guardando il Grafico 1, a parità di QP il PSNR di VpD codificato con MVC è superiore al PSNR di MV codificato sempre con MVC; ciò significa che MV, a parità di QP, avrà un bitrate inferiore ma a scapito della qualità. 10. Conclusioni In conclusione si può affermare che i formati MV con codifica MVC e VpD con codifica MVC si equivalgono, nonostante ci si poteva aspettare delle prestazioni superiori da VpD codificato con MVC. Questo è dovuto ad un limite pratico dell’analisi effettuata in quanto non si dispone di un tool specifico per la codifica della mappa di profondità. Per sopperire a tale mancanza è stata utilizzata la codifica MVC che non è ottimizzata per la compressione di video con la sola componente di profondità. Infine per il formato SbS codificato con H.264/AVC non è stato possibile sfruttare alcuna correlazione tra viste poiché questo formato “ingloba” i frame provenienti dalle due viste in un unico frame; e, tra l’altro, nella codifica intra-frame non si sfrutta in maniera appropriata il fatto che ci sia un’elevata correlazione all’interno del dato frame. In conclusione possiamo osservare che utilizzando il tool JMVC i risultati prestazionalmente più elevati in termini di bitrate e PSNR si ottengono per i due formati MVC e VPD codificati con MVC. Per poter effettuare una scelta tra i due, bisogna prendere in considerazione altri fattori:
  • 27.  Numero di viste;  Apparecchi target;  Specifiche del servizio;  Costi. Il numero di viste è un elemento importantissimo nella scelta del formato di rappresentazione, infatti nel caso volessimo codificare N viste prelevate da N videocamere differenti allora la scelta propenderà verso il formato MV codificato con MVC; ma, se ci sono particolari vincoli in termini di bandwidth disponibile da dover rispettare, utilizzare N/2 viste associando ad ognuna una mappa di profondità potrebbe essere utile allo scopo e porterebbe anche ad un risparmio economico dimezzando il numero di videocamere necessarie. Gli apparecchi target, ossia i dispositivi a cui verrà affidata la decodifica di video 3D, sono un altro parametro importantissimo da valutare perché, come già accennato nel paragrafo 3.2, alcuni potrebbero non essere in grado di riprodurre il video 3D partendo da informazioni rappresentate nel formato VpD codificate con MVC e quindi la scelta dovrebbe propendere automaticamente verso l’MV codificato con MVC. Altro fattore da non sottovalutare sono le specifiche del servizio: bandwidth disponibile, capacità computazionali a disposizione, destinatari del video codificato, etc. Sicuramente è di fondamentale importanza avere informazioni relativamente a quale sia il fine dell’encoding di questo video 3D. Per poter effettuare una scelta corretta, quindi, bisogna capire se il video codificato dovrà essere visualizzato in locale oppure dovrà essere distribuito in rete. Nel secondo caso si potrebbe scegliere di usare il formato MV codificandolo con MVC dato che garantisce un bitrate leggermente più basso, a parità di QP, rispetto al VpD portando però ad una degradazione della qualità maggiore del video rispetto a quest’ultimo. Infine è il fattore economico, ossia i costi associati ad una determinata scelta. Utilizzare il formato di codifica VpD potrebbe essere una scelta vantaggiosa sotto alcuni punti di vista, ma potrebbe portare a dei costi maggiori sia in termine di tempo che economici, perché le tecniche di acquisizione o generazione della mappa di profondità, come spiegato sempre nel paragrafo 3.2, sono complesse e dispendiose. Ovviamente anche utilizzare l’MV può prevedere dei costi non indifferenti, basti pensare che si necessità di N videocamere che devono essere sincronizzate nel minimo dettaglio, allineate e stabili. Grazie ai risultati pervenuti possiamo quindi dire che in questo particolare confronto, ottenuto sfruttando il tool JMVC, l’MV codificato con MVC sembra fornire i risultati migliori e quindi ci sentiamo di poter affermare che è il formato di rappresentazione migliore tra i tre.
  • 28. APPENDICE A Qt è una cross-platform application e un framework UI dotato di APIs per la programmazione in C++. Per poter utilizzare il software realizzato su un'altra macchina, non è necessario effettuare alcuna installazione dello stesso, ma si dovranno installare le librerie Qt [9] (l’applicativo non è stato realizzato mediante compilazione statica delle librerie) e un compilatore gcc per sistemi Linux. Installare le librerie Qt è molto semplice, anche se attualmente viene solo fornita una versione di prova delle librerie per 30 giorni (le librerie Qt non sono più fruibili gratuitamente ma solo a pagamento, anche per scopi non commerciali): per la versione Linux, ci si dovrà registrare al seguente indirizzo http://qt.digia.com/Try-Qt-Now/Qt-commercial-evaluation/?platform=embedded-linux-cpp. Successivamente bisognerà seguire una semplice procedura di compilazione (i comandi da utilizzare saranno: “./configure” – “./make” – “./make install”) preceduta dal settaggio delle variabili d’ambiente del nostro sistema. Installate le librerie, bisognerà spostarsi (da terminale) nella cartella contenente l’eseguibile, accertarsi che l’utente sia dotato dei privilegi di esecuzione “chmod +x <nomefile>” e lanciarlo “./<nomefile>”.
  • 29. APPENDICE B MV – Configuration File # JMVC Main Configuration File #====================== GENERAL ========================================= InputFile ./InputSample/test # input file OutputFile ./OutputSample/QP21/stream # bitstream file #./OutputSample/QP24/stream #./OutputSample/QP28/stream #./OutputSample/QP31/stream #./OutputSample/QP34/stream ReconFile ./OutputSample/QP21/rec # reconstructed file #... MotionFile motion # motion information file SourceWidth 432 # input frame width SourceHeight 240 # input frame height FrameRate 25.0 # frame rate [Hz] FramesToBeEncoded 100 # number of frames #====================== SymbolMode FRExt BasisQP CODING ========================================== 1 # 0=CAVLC, 1=CABAC 1 # 8x8 transform (0:off, 1:on) 21 # Quantization parameters #24,28,31,34 #====================== INTERLACED ====================================== MbAff 0 # 0=frameMb, 1=MbAff PAff 0 # 0=frame, 1=field, 2=frame/field #====================== GOPSize IntraPeriod NumberReferenceFrames InterPredPicsFirst Log2MaxFrameNum Log2MaxPocLsb DeltaLayer0Quant DeltaLayer1Quant DeltaLayer2Quant DeltaLayer3Quant DeltaLayer4Quant DeltaLayer5Quant MaxRefIdxActiveBL0 MaxRefIdxActiveBL1 MaxRefIdxActiveP STRUCTURE ======================================= 16 # GOP Size (at maximum frame rate) 16 # Anchor Period 3 # Number of reference pictures 1 # 1 Inter Pics; 0 Inter-view Pics 11 # specifies max. value for frame_num (4..16) 7 # specifies coding of POC’s (4..15) 0 # differential QP for layer 0 3 # differential QP for layer 1 4 # differential QP for layer 2 5 # differential QP for layer 3 6 # differential QP for layer 4 7 # differential QP for layer 5 2 # active entries in ref list 0 for B slices 2 # active entries in ref list 1 for B slices 1 # active entries in ref list for P slices #======================= MOTION SEARCH ================================== SearchMode 4 # Search mode (0:BlockSearch, 4:FastSearch) SearchFuncFullPel 3 # Search function full pel # (0:SAD, 1:SSE, 2:HADAMARD, 3:SAD-YUV) SearchFuncSubPel 2 # Search function sub pel # (0:SAD, 1:SSE, 2:HADAMARD) SearchRange 32 # Search range (Full Pel) BiPredIter 4 # Max iterations for bi-pred search IterSearchRange 8 # Search range for iterations (0: normal) #======================== LOOP FILTER ==================================== LoopFilterDisable 0 # Loop filter idc (0: on, 1: off, 2:
  • 30. # on except for slice boundaries) # AlphaOffset(-6..+6): valid range # BetaOffset (-6..+6): valid range LoopFilterAlphaC0Offset 0 LoopFilterBetaOffset 0 #========================= WEIGHTED PREDICTION ============================ WeightedPrediction 0 # Weighting IP Slice (0:disable, 1:enable) WeightedBiprediction 0 # Weighting B Slice (0:disable, 1:explicit, 2:implicit) #=================== PARALLEL DECODING INFORMATION SEI Message ================== PDISEIMessage 0 # PDI SEI message enable (0: disable, 1:enable) PDIInitialDelayAnc 2 # PDI initial delay for anchor pictures PDIInitialDelayNonAnc 2 # PDI initial delay for non-anchor pictures #============================== NESTING ============================= NestingSEI 0 #(0: SnapShot 0 #(0: #========================== ACTIVE VIEW ======================== ActiveViewSEI 0 #(0: #===================== VIEW SCALABILITY ================== ViewScalInfoSEI 0 #(0: SEI MESSAGE NestingSEI off, 1: NestingSEI on) SnapShot off, 1: SnapShot on) INFO SEI MESSAGE ActiveViewSEI off, 1: ActiveViewSEI on) INFOMATION SEI MESSAGE ViewScalSEI off, 1: ViewScalSEI on) #============== Level conformance checking of the DPB size ============== DPBConformanceCheck 0 # (0: disable, 1: enable, 1:default) #================= MULTIVIEW CODING PARAMETERS =========================== NumViewsMinusOne 1 # (Number of view to be coded minus 1) ViewOrder 0-1 # (Order in which view_ids are coded) View_ID Fwd_NumAnchorRefs Bwd_NumAnchorRefs Fwd_NumNonAnchorRefs Bwd_NumNonAnchorRefs View_ID Fwd_NumAnchorRefs Bwd_NumAnchorRefs Fwd_NumNonAnchorRefs Bwd_NumNonAnchorRefs Fwd_AnchorRefs 0 0 0 0 # view_id (0..1024): valid range # (number of list_0 references for anchor) # (number of list 1 references for anchor) # (number of list 0 references for non-anchor) # (number of list 1 references for non-anchor) 0 0 0 1 1 0 0 0 # view_id (0..1024): valid range # (number of list_0 references for anchor) # (number of list 1 references for anchor) #(number of list 0 references for non-anchor) #(number of list 1 references for non-anchor) VpD – Configuration File # JMVC Main Configuration File #====================== GENERAL ========================================= InputFile view # input file OutputFile stream-left-plus-depth_21 # bitstream file #stream-left-plus-depth_24 #stream-left-plus-depth_28 #stream-left-plus-depth_31 #stream-left-plus-depth_34 ReconFile rec-left-plus-depth_21 # reconstructed file #rec-left-plus-depth_24 #rec-left-plus-depth_28
  • 31. #rec-left-plus-depth_31 #rec-left-plus-depth_34 MotionFile SourceWidth SourceHeight FrameRate FramesToBeEncoded motion 432 240 25.0 100 # # # # # motion information file input frame width input frame height frame rate [Hz] number of frames #====================== CODING ========================================== SymbolMode 1 # 0=CAVLC, 1=CABAC #CAVLC (Context Adaptive Variable Length Coding: minore complessità #computazionale e minore efficienza); #CABAC (Context Adaptive Binary Arithmetic Coding: maggiore complessità #computazionale richiesta e maggiore efficienza nella codifica); FRExt 1 # 8x8 transform (0:off, 1:on) BasisQP 21 # Quantization parameters #24, #28, #31, #34 #====================== INTERLACED ====================================== MbAff 0 # 0=frameMb, 1=MbAff PAff 0 # 0=frame, 1=field, 2=frame/field #====================== GOPSize IntraPeriod NumberReferenceFrames InterPredPicsFirst Log2MaxFrameNum Log2MaxPocLsb DeltaLayer0Quant DeltaLayer1Quant DeltaLayer2Quant DeltaLayer3Quant DeltaLayer4Quant DeltaLayer5Quant MaxRefIdxActiveBL0 MaxRefIdxActiveBL1 MaxRefIdxActiveP STRUCTURE ======================================= 16 # GOP Size (at maximum frame rate) 16 # Anchor Period (>=GOPSize) 3 # Number of reference pictures 1 # 1 Inter Pics; 0 Inter-view Pics 11 # specifies max. value for frame_num (4..16) 7 # specifies coding of POC’s (4..15) 0 # differential QP for layer 0 3 # differential QP for layer 1 4 # differential QP for layer 2 5 # differential QP for layer 3 6 # differential QP for layer 4 7 # differential QP for layer 5 2 # active entries in ref list 0 for B slices 2 # active entries in ref list 1 for B slices 1 # active entries in ref list for P slices #======================= MOTION SEARCH ================================== SearchMode 4 # Search mode (0:BlockSearch, 4:FastSearch) SearchFuncFullPel 3 # Search function full pel # (0:SAD, 1:SSE, 2:HADAMARD, 3:SAD-YUV) SearchFuncSubPel 2 # Search function sub pel # (0:SAD, 1:SSE, 2:HADAMARD) SearchRange 32 # Search range (Full Pel) BiPredIter 4 # Max iterations for bi-pred search IterSearchRange 8 # Search range for iterations (0: normal) #======================== LOOP FILTER ========================================== LoopFilterDisable 0 # Loop filter idc (0: on, 1: off, 2: # on except for slice boundaries) LoopFilterAlphaC0Offset 0 # AlphaOffset(-6..+6): valid range LoopFilterBetaOffset 0 # BetaOffset (-6..+6): valid range #========================= WEIGHTED PREDICTION ================================= WeightedPrediction 0 # Weighting IP Slice (0:disable, 1:enable) WeightedBiprediction 0 # Weighting B Slice (0:disable, 1:explicit, 2:implicit) #=================== PARALLEL DECODING INFORMATION SEI Message =================
  • 32. PDISEIMessage 1:enable) PDIInitialDelayAnc PDIInitialDelayNonAnc 0 # PDI SEI message enable (0: disable, 2 2 # PDI initial delay for anchor pictures # PDI initial delay for non-anchor pictures #============================== NESTING SEI MESSAGE ============================ NestingSEI 0 #(0: NestingSEI off, 1: NestingSEI on) SnapShot 0 #(0: SnapShot off, 1: SnapShot on) #========================= ACTIVE VIEW INFO SEI MESSAGE ======================== ActiveViewSEI 0 #(0: ActiveViewSEI off, 1: ActiveViewSEI on) #==================== VIEW SCALABILITY INFOMATION SEI MESSAGE ================== ViewScalInfoSEI 0 #(0: ViewScalSEI off, 1: ViewScalSEI on) #============== Level conformance checking of the DPB size ============== DPBConformanceCheck 0 # (0: disable, 1: enable, 1:default) #================= MULTIVIEW CODING PARAMETERS =========================== NumViewsMinusOne 1 # (Number of view to be coded minus 1) ViewOrder 0-1 # (Order in which view_ids are coded) View_ID Fwd_NumAnchorRefs Bwd_NumAnchorRefs Fwd_NumNonAnchorRefs Bwd_NumNonAnchorRefs View_ID Fwd_NumAnchorRefs Bwd_NumAnchorRefs Fwd_NumNonAnchorRefs Bwd_NumNonAnchorRefs Fwd_AnchorRefs 0 0 0 0 # view_id (0..1024): valid range # (number of list_0 references for anchor) # (number of list 1 references for anchor) # (number of list 0 references for non-anchor) # (number of list 1 references for non-anchor) 0 0 0 1 1 0 0 0 # view_id (0..1024): valid range # (number of list_0 references for anchor) # (number of list 1 references for anchor) #(number of list 0 references for non-anchor) #(number of list 1 references for non-anchor) SbS – Configuration File # JMVC Main Configuration File #====================== GENERAL ========================================= InputFile ./InputSample/testSbS # input file OutputFile ./OutputSample/QP21/streamSbS # bitstream file #./OutputSample/QP24/streamSbS #./OutputSample/QP28/streamSbS #./OutputSample/QP31/streamSbS #./OutputSample/QP34/streamSbS ReconFile ./OutputSample/QP21/recSbS # reconstructed file #... MotionFile motion # motion information file SourceWidth 864 # input frame width SourceHeight 240 # input frame height FrameRate 25.0 # frame rate [Hz] FramesToBeEncoded 100 # number of frames #====================== SymbolMode FRExt BasisQP CODING ========================================== 1 # 0=CAVLC, 1=CABAC 1 # 8x8 transform (0:off, 1:on) 21 # Quantization parameters #24,28,31,34 #====================== INTERLACED ====================================== MbAff 0 # 0=frameMb, 1=MbAff PAff 0 # 0=frame, 1=field, 2=frame/field
  • 33. #====================== GOPSize IntraPeriod NumberReferenceFrames InterPredPicsFirst Log2MaxFrameNum Log2MaxPocLsb DeltaLayer0Quant DeltaLayer1Quant DeltaLayer2Quant DeltaLayer3Quant DeltaLayer4Quant DeltaLayer5Quant MaxRefIdxActiveBL0 MaxRefIdxActiveBL1 MaxRefIdxActiveP STRUCTURE ======================================= 16 # GOP Size (at maximum frame rate) 16 # Anchor Period 3 # Number of reference pictures 1 # 1 Inter Pics; 0 Inter-view Pics 11 # specifies max. value for frame_num (4..16) 7 # specifies coding of POC’s (4..15) 0 # differential QP for layer 0 3 # differential QP for layer 1 4 # differential QP for layer 2 5 # differential QP for layer 3 6 # differential QP for layer 4 7 # differential QP for layer 5 2 # active entries in ref list 0 for B slices 2 # active entries in ref list 1 for B slices 1 # active entries in ref list for P slices #======================= MOTION SEARCH ================================== SearchMode 4 # Search mode (0:BlockSearch, 4:FastSearch) SearchFuncFullPel 3 # Search function full pel # (0:SAD, 1:SSE, 2:HADAMARD, 3:SAD-YUV) SearchFuncSubPel 2 # Search function sub pel # (0:SAD, 1:SSE, 2:HADAMARD) SearchRange 32 # Search range (Full Pel) BiPredIter 4 # Max iterations for bi-pred search IterSearchRange 8 # Search range for iterations (0: normal) #======================== LOOP FILTER ==================================== LoopFilterDisable 0 # Loop filter idc (0: on, 1: off, 2: # on except for slice boundaries) LoopFilterAlphaC0Offset 0 # AlphaOffset(-6..+6): valid range LoopFilterBetaOffset 0 # BetaOffset (-6..+6): valid range #========================= WEIGHTED PREDICTION ============================ WeightedPrediction 0 # Weighting IP Slice (0:disable, 1:enable) WeightedBiprediction 0 # Weighting B Slice (0:disable, 1:explicit, 2:implicit) #================== PARALLEL DECODING INFORMATION SEI Message ================== PDISEIMessage 0 # PDI SEI message enable (0: disable, 1:enable) PDIInitialDelayAnc 2 # PDI initial delay for anchor pictures PDIInitialDelayNonAnc 2 # PDI initial delay for non-anchor pictures #============================= NESTING SEI MESSAGE ============================= NestingSEI 0 #(0: NestingSEI off, 1: NestingSEI on) SnapShot 0 #(0: SnapShot off, 1: SnapShot on) #========================== ACTIVE VIEW INFO SEI MESSAGE ======================== ActiveViewSEI 0 #(0: ActiveViewSEI off, 1: ActiveViewSEI on) #===================== VIEW SCALABILITY INFOMATION SEI MESSAGE ================= ViewScalInfoSEI 0 #(0: ViewScalSEI off, 1: ViewScalSEI on) #============== Level conformance checking of the DPB size ============== DPBConformanceCheck 0 # (0: disable, 1: enable, 1:default) #================= MULTIVIEW CODING PARAMETERS =========================== NumViewsMinusOne 0 # (Number of view to be coded minus 1) ViewOrder 0 # (Order in which view_ids are coded) View_ID 0 # view_id (0..1024): valid range
  • 34. Fwd_NumAnchorRefs Bwd_NumAnchorRefs Fwd_NumNonAnchorRefs Bwd_NumNonAnchorRefs 0 0 0 0 # (number of list_0 references for anchor) # (number of list 1 references for anchor) # (number of list 0 references for non-anchor) # (number of list 1 references for non-anchor)
  • 35. RIFERIMENTI [1] N.A. Dodgson, J.R. Moore, S.R. Lang, “Multi-view autostereoscopic 3D display,” International Broadcasting Convention, pp.497-502, 1999 [2] Site: http://boccignone.di.unimi.it/Modelli_Percezione_files/LezPMPSpazio(1).pdf, “La percezione dello spazio (1): indizi monoculari”; [3] H. Brust, A. Smolic, K. Müller, G. Tech, and T. Wiegand, "Mixed Resolution Coding of Stereoscopic Video for Mobile Devices", Proc. 3DTVCON 2009, Potsdam, Germany, May 2009 [4] A. Bourge, J. Gobert and F. Bruls, “MPEG-C part 3: Enabling the introduction of video plus depth contents,” in Proc. of IEEE Workshop on Content Generation and Coding for 3D-television, Eindhoven, The Netherlands, June 2006. [5] M. Halle, “Autostereoscopic Displays and Computer Graphics,” Computer Graphics, ACM Siggraph, vol. 31, no. 2, 1997, pp. 58-62. [6] “Seminario sulle tecnologie 3D”, Ing. C.Ceglie, Telematics, Politecnico di Bari. [7] Y. Chen, M. Hannuksela, L. Zhu, A. Hallapuro, M. Gabbouj, and H. Li, "Coding techniques in multiview video coding and joint multiview video model," in Picture Coding Symposium, 2009. PCS 2009, pp. 1 -4, 6-8 2009. [8] Site: http://sp.cs.tut.fi/mobile3dtv/stereo-video/; [9] Site: http://qt.digia.com/product/ - Qt Products; [10] M. Flierl and B. Girod. Multiview video compression. IEEE Signal Processing Mag., 24(6):66–76, November 2007. [11] Site: http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I01-100827.pdf, “Content Encoding Profiles 3.0 Specification” [12] Iain E. G. Richardson, “H.264 and MPEG-4 Video Compression: Video Coding for Next-generation Multimedia”, 2003 John Wiley & Sons, Ltd. ISBN: 0-470-84837-5.