sistemi e reti multimediali - studio della codifica 3d

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 - [email protected]

Marco Suma – [email protected]

mailto:[email protected]

mailto:[email protected]

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

SbS – Configuration File ............................................................................................................................... 34

RIFERIMENTI .................................................................................................................................................... 37

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

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.

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

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.

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

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

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.

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.

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;

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

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;

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

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

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.

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

host address: garcon.ient.rwth-aachen.de

path: /cvs/jvt

user name: jvtuser

password: jvt.Amd.2

module name: jmvc

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.

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.

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

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

formato>_<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_<tipo-

formato>_<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_left-

plus-depth_34.log

./H264AVCEncoderLibTestStatic -vf cfg_left-plus-depth_34 1 >> encoding_1_left-

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

depth_34.yuv 2 >>decoding_left-plus-depth_34.log

./PSNRStatic 432 240 view_0.yuv decoded_left-plus-depth_34_0.yuv 0 0 stream-

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

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

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 log10

Max2

MSE Peak Signal to Noise Ratio

Formula n.1

MSE=1

M∗N∑i=0

M−1

∑j=0

N−1

[ x ( i , j)−x ' ( i , j ) ]2 Mean Squared Error

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.

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.

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

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:

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.

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

http://qt.digia.com/Try-Qt-Now/Qt-commercial-evaluation/?platform=embedded-linux-cpp

APPENDICE B

MV – Configuration File

# JMVC Main Configuration File

#====================== GENERAL =========================================

InputFile ./InputSample/test # input file

OutputFile ./OutputSample/QP21/stream # bitstream file

#./OutputSample/QP24/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

#====================== CODING ==========================================

SymbolMode 1 # 0=CAVLC, 1=CABAC

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

#====================== STRUCTURE =======================================

GOPSize 16 # GOP Size (at maximum frame rate)

IntraPeriod 16 # Anchor Period

NumberReferenceFrames 3 # Number of reference pictures

InterPredPicsFirst 1 # 1 Inter Pics; 0 Inter-view Pics

Log2MaxFrameNum 11 # specifies max. value for frame_num (4..16)

Log2MaxPocLsb 7 # specifies coding of POCâ€™s (4..15)

DeltaLayer0Quant 0 # differential QP for layer 0






MaxRefIdxActiveBL0 2 # active entries in ref list 0 for B slices


MaxRefIdxActiveP 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 1 # (Number of view to be coded minus 1)

ViewOrder 0-1 # (Order in which view_ids are coded)

View_ID 0 # view_id (0..1024): valid range

Fwd_NumAnchorRefs 0 # (number of list_0 references for anchor)

Bwd_NumAnchorRefs 0 # (number of list 1 references for anchor)

Fwd_NumNonAnchorRefs 0 # (number of list 0 references for non-anchor)

Bwd_NumNonAnchorRefs 0 # (number of list 1 references for non-anchor)




Fwd_NumNonAnchorRefs 0 #(number of list 0 references for non-anchor)

Bwd_NumNonAnchorRefs 0 #(number of list 1 references for non-anchor)

Fwd_AnchorRefs 0 0

VpD – Configuration File


#====================== GENERAL =========================================

InputFile view # input file

OutputFile stream-left-plus-depth_21 # bitstream file

#stream-left-plus-depth_24




ReconFile rec-left-plus-depth_21 # reconstructed file

#rec-left-plus-depth_24









#====================== CODING ==========================================


#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);



#24,

#28,

#31,

#34

#====================== INTERLACED ======================================



#====================== STRUCTURE =======================================


IntraPeriod 16 # Anchor Period (>=GOPSize)














#======================= MOTION SEARCH ==================================









#======================== LOOP FILTER ==========================================





#========================= WEIGHTED PREDICTION =================================



2:implicit)

#=================== PARALLEL DECODING INFORMATION SEI Message =================


1:enable)



#============================== NESTING SEI MESSAGE ============================



#========================= ACTIVE VIEW INFO SEI MESSAGE ========================


#==================== VIEW SCALABILITY INFOMATION SEI MESSAGE ==================






ViewOrder 0-1 # (Order in which view_ids are coded)









Fwd_NumNonAnchorRefs 0 #(number of list 0 references for non-anchor)

Bwd_NumNonAnchorRefs 0 #(number of list 1 references for non-anchor)

Fwd_AnchorRefs 0 0

SbS – Configuration File


#====================== GENERAL =========================================

InputFile ./InputSample/testSbS # input file

OutputFile ./OutputSample/QP21/streamSbS # bitstream file

#./OutputSample/QP24/streamSbS




ReconFile ./OutputSample/QP21/recSbS # reconstructed file

#...






#====================== CODING ==========================================




#24,28,31,34

#====================== INTERLACED ======================================



#====================== STRUCTURE =======================================


IntraPeriod 16 # Anchor Period














#======================= MOTION SEARCH ==================================









#======================== LOOP FILTER ====================================





#========================= WEIGHTED PREDICTION ============================



2:implicit)

#================== PARALLEL DECODING INFORMATION SEI Message ==================


1:enable)



#============================= NESTING SEI MESSAGE =============================



#========================== ACTIVE VIEW INFO SEI MESSAGE

========================


#===================== VIEW SCALABILITY INFOMATION SEI MESSAGE =================






ViewOrder 0 # (Order in which view_ids are coded)


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.

http://boccignone.di.unimi.it/Modelli_Percezione_files/LezPMPSpazio(1).pdf

http://sp.cs.tut.fi/mobile3dtv/stereo-video/

http://qt.digia.com/product/

http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I01-100827.pdf

sistemi e reti multimediali - studio della codifica 3d

Education