Capitolo 2

(1)

Capitolo 2

2.1 Introduzione

In questo capitolo, dopo una breve descrizione dell’ambiente di test, effettueremo una comparazione tra diversi modelli C del sistema: prima rapporteremo il JM2.1 con il JM6.1d e, osservandone un comportamento similare, estenderemo le considerazioni a cui si era giunti in[6] per il JM2.1 anche per il JM6.1d. In un secondo momento confronteremo questo ultimo con l’AHM20 per poi concentrare la nostra analisi sulla stima del moto che si rivela essere il componente del sistema più esteso in termini di costo computazionale, di memorizzazione e trasferimento dati.

(2)

2.2 Ambiente di test

2.2.1 Sequenze di test

Il testbench proposto in questo capitolo consiste di 4 sequenze con un diversi gradi di dinamismo, formati e bit-rate di riferimento. Le caratteristiche sono mostrate in Tabella 2.1. Mother&Daughter 30Hz QCIF (176x144 pixels) (di seguito riferita come MD) è una sequenza a mezzo busto tipica di applicazioni a bassi bit-rate (decine di Kbps). Foreman 30Hz QCIF (di seguito riferita come FOR1) presenta una complessità media ed è un buon test per applicazioni sempre a bassi bit-rate che sono comprese tra le decine di Kbps e poche centinaia di Kbps. La versione CIF (352x288 pixels) di Foreman (di seguito riferita come FOR2) rappresenta un test adatto per applicazioni a medi bit-rate. Infine Stefan CIF (di seguito riferita come SF), che contempla movimenti più rapidi, permette valutare applicazioni con bit-rate alti dell’ordine di poche migliaia. I test sono stati realizzati mantenendo costante il fattore di quantizzazione (QP), si è quindi ottenuto un bit-rate variabile.

Tabella 2.1Caratteristiche delle sequenze di test

Configurazio-ni di test Sequenze video Formato (pixels) Frame/s (Hz) QP Bit-rate (Kbps) MD Mother& Daughter QCIF (176x144) 30 28 30-40

FOR1 Foreman QCIF

(176x144) 30 28 100-200 FOR2 Foreman CIF

(352x288) 30 28 300-600

(3)

2.2.2 Configurazioni di test

La tabella 2.2 riporta le varie configurazioni del sistema in cui si sono effettuati i test.

Per ogni caso, identificato da un numero da 0 a 17, la tabella 2.2 indica l’attivazione di alcuni tools opzionali rispetto alla configurazione di base dell’H.264/AVC (caso 0) caratterizzato da un search_range pari ad 8, 1 reference frame, una risoluzione di ¼ di pixel, codifica di tipo intra. Un filtro di deblocking, un coder entropico di tipo UVLC (Universal Variable Lenght Coder), un primo frame codificato intra seguito da frame tutti di tipo P.

I primi due casi rappresentano una “semplice” implementazione dell’H.264/AVC con tutti i tools disabilitati e con un’area di ricerca rispettivamente di 8 e poi di 16. Per i casi dal 2 al 9 osserviamo una crescita di complessità dovuta alla sovrapposizione di più tools che vengono aggiunti in modo additivo. Si giunge poi a configurazioni complesse (10-12) dove si ottengono le prestazioni migliori. Comparando i casi 0-1 con i casi 2-12 abbiamo un idea dell’efficienza dei tools opzionali del codice confrontata con la complessità. I casi 13-17 sono stati scelti per ottenere prestazioni simili a quelle ottenute per le configurazioni 10-12 ma cercando di ridurre la complessità cercando di togliere alcuni tools e riducendo il numero di frame di riferimento e l’area di ricerca.

Tabella 2.2 Descrizione dei casi in esame

caso 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Hadamard N N N N N N N Y Y Y Y Y Y N N N N N 1/8Risol. N N N N N N N N Y Y Y Y Y N N N N N Ref. Frame 1 1 1 1 3 5 5 5 5 5 5 5 5 5 5 3 2 1 Block sizes* 1 1 4 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 B-frames N N N N N N N N N N 1 1 2 1 1 1 1 1 CABAC N N N N N N N N N Y Y Y Y Y Y Y Y Y RD-Lagrange N N N N N Y Y Y Y Y Y Y Y Y Y Y Y Y Search Range 8 16 16 16 16 16 16 16 16 16 16 32 16 16 8 8 8 8

(4)

2.3 Confronto tra la versione 2.1 e la versione 6.1d

2.3.1 Analisi con MOTHER&DAUGHTER

La prima sequenza che prendiamo in esame è una tipica sequenza che può trovare applicazione in videoconferenze. Vengono di seguito riportati i grafici che indicano il comportamento dei due software al variare dei casi di configurazione. I parametri vengono di volta in volta modificati agendo sul file encoder.cfg dove si configura il sistema.

Il grafico in Figura 2.1 è relativo al tempo di codifica (e-time).I tempi di codifica riportati nel grafico sono normalizzati rispetto al caso n°1.

0 50 100 150 200 250 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 profili di configurazione te m po di c odi fi ca 6.1d 2.1

Figura 2.1: tempo di codifica per i vari casi (MD test)

Dal grafico si osserva come, mentre per i casi (0-9) i tempi di codifica sono simili, per i casi (10-17) si ha un evidente risparmio di tempo con una percentuale che va dal

(5)

Mentre l’andamento del bit-rate è pressoché identico si osserva che il PSNR della versione 2.1 è costantemente migliore della versione 6.1d di circa 0.4dB, è comunque un peggioramento poco rilevante, soprattutto se messo in confronto con la riduzione dei tempi di codifica. 35 36 37 38 39 40 41 42 43 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 profili di configurazione P S NR (dB) 6.1d 2.1

Figura 2.2:rapporto segnale/rumore per i vari casi (MD test)

0 5 10 15 20 25 30 35 40 45 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 profili di configurazione b it-r at e (Kb p s) 6.1d 2.1

(6)

2.3.2 Analisi Con FOREMAN QCIF

Anche questa sequenza, come Mother&Daughter può essere pensata per applicazioni tipo videoconferenza con bit-rate da 100 a 200 Kbps. Vengono di seguito riportati i grafici che indicano il comportamento dei due software al variare dei casi di configurazione.

In Figura 2.4 viene preso in esame l’andamento del tempo di codifica per i vari casi. Si può osservare come l’andamento per i casi (0-9) sia in pratica identico. Nei casi (10-17) si ha un risparmio di tempo dal 15% fino circa al 33%.

Figura 2.4: tempo di codifica per i vari casi (FOR1 test)

Per quanto riguarda il rapporto segnale/rumore si osserva dalla Figura 2.5 che il suo andamento per i casi è pressoché identico. Per questa sequenza inoltre si riscontra oltre

(7)

33 34 35 36 37 38 39 40 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 profili di configurazione P S NR (dB) 6.1d 2.1

Figura 2.5: rapporto segnale/rumore per i vari casi (FOR1 test)

0 25 50 75 100 125 150 175 200 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 profili di configurazione b it-r at e (Kb p s) 6.1d 2.1

(8)

2.3.3 Analisi con FOREMAN CIF

Questa sequenza presenta un bit-rate di centinaia di Kbps (300-600). Nella Figura 2.7 viene preso in esame l’andamento del tempo di codifica per i vari casi. Si può osservare come l’andamento per i casi (0-9) sia in pratica identico. Nei casi (10-17) si ha un risparmio di tempo veramente notevole dal 30% fino addirittura al 60%.

0 500 1000 1500 2000 2500 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 profili di configurazione te m po di c odi fi ca 6.1d 2.1

Per quanto riguarda il rapporto segnale/rumore si osserva dalla Figura 2.8 che il suo andamento per i casi è pressoché identico. Per questa sequenza inoltre si riscontra oltre che in abbassamento dei tempi di codifica addirittura una riduzione del 8% del bit-rate. L’andamento del bit-rate è mostrato in Figura 2.9.

(9)

33 34 35 36 37 38 39 40 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 profili di configurazione P S NR (dB) 61d 2.1

0 100 200 300 400 500 600 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 profili di configurazione b it-r at e (Kb p s) 6.1d 2.1

(10)

2.3.4 Analisi Con STEFAN CIF

Questa sequenza che presenta un bit-rate di poche migliaia di Kbps (900-2000) può essere pensata per applicazioni tipo video sportive. Vengono di seguito riportati i grafici che indicano il comportamento dei due software al variare dei casi di configurazione.

In Figura 2.10 viene preso in esame l’andamento del tempo di codifica per i vari casi. Si può osservare come l’andamento per i casi (0-9) sia molto vicino. Nei casi (10-17) si ha un risparmio di tempo fino al 30%.

Figura 2.10: tempo di codifica per i vari casi (SF test)

Per quanto riguarda il rapporto segnale/rumore si osserva dalla Figura 2.11 che il suo andamento per i casi è pressoché identico. Per questa sequenza inoltre si riscontra un andamento del bit-rate vicino tra i due software per i casi (0-9) ho bit-rate più bassi per la versione 6.1d mentre per i casi (10-17) ho bit-rate più bassi per la versione 2.1. L’andamento del bit-rate è mostrato in Figura 2.12.

(11)

31 32 33 34 35 36 37 38 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 profili di configurazione P S NR (dB) 6.1d 2.1

Figura 2.11: rapporto segnale/rumore per i vari casi (SF test)

0 250 500 750 1000 1250 1500 1750 2000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 profili di configurazione b it-r at e (Kb p s) 6.1d 2.1

Figura 2.12: bit-rate per i vari casi (SF test)

2.3.5 Conclusioni

Dall’analisi del comportamento dei due codici sulle sequenze proposte, per più applicazioni in termini di bit-rate, si evince che la nuova versione 6.1d del modello di

(12)

codice consente un notevole risparmio del tempo di codifica e come controparte solo un modesto abbassamento di prestazioni in termini di PSNR e bit-rate che si riscontra essenzialmente a bassi e medi bit-rate. Le prestazioni comunque restano molto vicine per i due codici e con la versione 6.1d si riesce ad avere una codifica delle sequenze in tempi minori e quindi è su questa ultima che continueremo lo studio.

L’andamento delle prestazioni, come è mostrato nei grafici, sia per il tempo di codifica che per il PSNR che per il bit-rate è molto simile; questa osservazione ci permette di espandere le considerazioni fatte in [6] per la versione di codice 2.1 anche per la versione 6.1d. Giungiamo quindi alle conclusioni che anche per il sistema basato sul software 6.1d il collo di bottiglia sia rappresentato dalla stima del moto, essa verrà trattata nel capitolo successivo.

2.4 Confronto tre la versione 6.1d e la AHM20

2.4.1 AHM20: evoluzione della 6.1d

La versione AHM20 si basa sulla stessa struttura della 6.1d alla quale apporta due modifiche importanti. Si propone l’introduzione di una stima del moto con una area di ricerca adattiva (adaptive search area) [JVT-C065] (vedi [11]) e un dispositivo di controllo sulla quantizzazione che permette di fissare un bit-rate desiderato (rate control) [JVT-F086] (vedi [12]).

La decisione della ampiezza dell’area di ricerca riveste un ruolo fondamentale nella stima di moto e permette la riduzione di complessità dell’ encoder rispetto alla versione 6.1d che adotta, come la 2.1, il classico algoritmo di Full Search. L’algoritmo che viene proposto consta di più passi.

B C

(13)

Possiamo assumere che E sia un macroblocco sulla quale viene operata la stima del moto, e A,B,C siano dei blocchi 4x4 vicini come mostrato in Fig. 2.13. Possiamo inoltre assumere che i motion vectors di A, B, C siano (MV_AX, MV_AY), (MV_BX, MV_BY),

(MV_CX, MV_CY), e il range di ricerca che viene inserito in ingresso sia definito come

imput_saerch_range. Un nuovo range di ricerca viene definito con i seguenti passi:

Step 1. Si verifica il numero di blocchi 4x4 vicini, se sono almeno due vado al

passo 2 altrimenti al 4.

Step 2. Dai motion vectors dei blocchi vicini determino la massima componente

orizzontale e verticale.

[

), ( _ )

]

_

max_MV E_i =max abs(MV_A_i),abs(MV_B_i abs MV Ci per i = x,y (2.1)

nell’equazione (2.1) se un blocco non è disponibile le componenti dei vettori sono settate a 0.

Step 3. Determinazione del range di ricerca locale (local_search_range).

[

_i i

]

i max k ,2xmax_MV E

range search

local_ _ = _ (2.2)

ki è definito come: (input_search_range + 4)>>3 se alphai = 0.

(3x input_search_range +8)>>4 se 0<alphai<2

(input_search_range +2)>>2 altrimenti

[

_i _i) ( _ i)

]

i abs(MV_A ) abs(MV_B abs MV C

alpha = + + (2.3)

Step 4. Viene determinato ora il nuovo search range che al massimo può essere pari

al valore posto in ingresso oppure assume il valore del range di ricerca locale determinato nello step 3.

(14)

[

i i

]

i input_search_range,local search range

range search

new_ _ =min _ _ (2.4)

oppure se il numero di blocchi disponibili e minore di due

i i input search range

range search

new_ _ = _ _ (2.5)

L’algoritmo proposto permette un risparmio in termini di tempo di codifica , come vedremo nel paragrafo successivo, in quanto determina, dove possibile, un range di ricerca più piccolo. La stima del moto diventa così meno pesante e può essere eseguita in tempi minori.

Nel paragrafo successivo analizzeremo l’andamento di questa versione del codice confrontata con la 6.1d per varie sequenze come fatto in precedenza.

2.4.2 Analisi Con MOTHER&DAUGHTER

Come premessa stavolta non analizzeremo tutti i casi visti in precedenza ma faremo il confronto solo sui casi senza l’introduzione dei frame codificati B, aggiungendo i tools volta per volta.

La prima sequenza che prendiamo in esame è una tipica sequenza che può trovare applicazione in videoconferenze. Vengono di seguito riportati i grafici che indicano il comportamento dei due software al variare dei casi di configurazione.

Il primo grafico che si riporta in Figura 2.14 è quello relativo al tempo di codifica (e-time).

(15)

0 10 20 30 40 50 60 70 80 90 1 2 3 4 5 6 7 8 9 10 profili di configurazione te m po di c odi fi ca 6.1d ahm20

Si osserva dal grafico in Figura 2.13 come ottengo un notevole risparmio di tempo dal 35% al 40%.

Per quanto riguarda il rapporto segnale/rumore si vede in Figura 2.14 che l’andamento è pressoché identico; si ha invece un aumento del bit-rate di circa il 9% come mostra la Figura 2.15.

36 36,5 37 37,5 38 38,5 39 39,5 40 1 2 3 4 5 6 7 8 9 10 profili di configurazione P S NR (dB) 6.1d ahm20

(16)

0 10 20 30 40 50 1 2 3 4 5 6 7 8 9 10 profili di configurazione b it-r at e (Kb p s) 6.1d ahm20

Figura 2.16: bit-rate per i vari casi (MD test)

2.4.3 Analisi Con FOREMAN QCIF

Anche questa sequenza,come Mother&Daughter può essere pensata per applicazioni tipo videoconferenza con bit-rate da 100 a 200 Kbps. Vengono di seguito riportati i grafici che indicano il comportamento dei due modelli C al variare dei casi di configurazione.

Nel grafico in Figura 2.16 viene preso in esame l’andamento del tempo di codifica per i vari casi.

Con questa sequenza ho un risparmio in termini di tempo di codifica fino al 30%.

30 40 50 60 70 80 90 fi ca 6.1d

(17)

Di seguito si riportano anche i grafici del PSNR e del bit-rate. Si osserva, a parità di PSNR, che mediamente si ha un aumento del bit-rate del 5%, quindi sempre meno rilevante rispetto al guadagno ottenuto in termini di velocità di codifica.

0 50 100 150 200 1 2 3 4 5 6 7 8 9 10 profili di configurazione b it-r at e (Kb p s) 6.1d ahm20

(18)

2.4.4 Analisi Con FOREMAN CIF

Questa sequenza che presenta un bit-rate di centinaia di Kbps (300-600). Vengono di seguito riportati i grafici che indicano il comportamento dei due modelli C al variare dei casi di configurazione.

0 50 100 150 200 250 300 350 1 2 3 4 5 6 7 8 9 10 profili di configurazione te m po di c odi fi ca 6.1d ahm20

Dal grafico in Figura 2.19 si osserva, escluso il primo caso, una riduzione del tempo di codifica fino al 25%.

Di seguito si riportano i grafici relativi al PSNR e al bit-rate. Si osserva che, a parità di PSNR si ha un aumento del bit-rate di circa il 13%. Vale la pena di sottolineare che questo valore rappresenta il massimo aumento riscontrato per le quattro sequenze ed è comunque inferiore al guadagno in termini temporali.

(19)

0 100 200 300 400 500 600 1 2 3 4 5 6 7 8 9 10 profili di configurazione b it-r at e (Kb p s) 6.1d ahm20

(20)

2.4.5 Analisi Con STEFAN CIF

0 50 100 150 200 250 300 350 1 2 3 4 5 6 7 8 9 10 profili di configurazione te m po di c odi fi ca 6.1d ahm20

Abbiamo ancora,escluso il primo caso, una diminuzione del tempo di codifica fino al 25%.

Dai grafici successivi si osserva poi come l’andamento del PSNR sia pressoché identico e si abbia un aumento del bit-rate in media del 5%

(21)

0 200 400 600 800 1000 1200 1400 1600 1800 1 2 3 4 5 6 7 8 9 10 profili di configurazione b it-r at e (Kb p s) 6.1d ahm20

Figura 2.25: bit-rate per i vari casi (SF test)

2.4.6 Conclusioni

Dall’analisi del comportamento dei due codici sulle sequenze proposte, per più applicazioni in termini di bit-rate, si evince che con la nuova versione AHM20 del modello C, ottenuto dal 6.1d apportando le due modifiche discusse sopra, ho un

(22)

notevole risparmio del tempo di codifica, fino al 40%, e come controparte solo una modesto abbassamento di prestazioni in termini di bit-rate,dal 5% al 13%.

2.5 Analisi della versione AHM20 disattivando il rate

control

2.5.1 Motivazione dell’analisi

Il confronto tra la versione 6.1d e la AHM20, che è stato esaminato nel paragrafo precedente, è stato effettuato mantenendo attivi sia l’area di ricerca adattiva che il rate control. Vogliamo ora mettere in luce a quale dei due tools aggiunti sia da attribuire la maggior parte del guadagno riscontrato nella diminuzione del tempo di codifica. Confronteremo adesso la versione del codice con entrambe i tools non attivi (che si assimila quindi alla 6.1d) e quella in cui sia mantenuto attivo soltanto l’area di ricerca adattiva. Ci aspettiamo che il guadagno in termini di tempo di codifica sia da attribuire proprio a questo tool che permette di fare una ricerca efficace su un’area ridotta rispetto all’originale fornita in ingresso, e quindi più rapida. In questa analisi torneremo anche a considerare i casi in cui introduciamo i frame codificati B.

2.5.2 Analisi Con MOTHER&DAUGHTER

Torniamo adesso a estendere la nostra analisi anche ai casi in cui vengono introdotti i frame codificati B.

La prima sequenza che prendiamo in esame è una tipica sequenza che può trovare applicazione in videoconferenze. Vengono di seguito riportati i grafici che indicano il comportamento dei due software al variare dei casi di configurazione.

(23)

0 50 100 150 200 250 300 1 3 5 7 9 11 13 15 17 profili di configurazione te m po di c odi fi ca AHM20 no tools AHM20 no-rate_control

Si osserva una notevole riduzione del tempo di codifica, per alcuni casi si arriva addirittura ad un guadagno del 60%.

Questo risultato inoltre deve essere associato agli andamenti di PSNR e bit-rate, mostrati nei grafici in Fig. 2.27 e 2.28, che per la nostra sequenza sono pressoché identici. Da questi grafici si capisce come, a bassi bit-rate, sia importante l’introduzione di un’ area di ricerca adattiva.

37,2 37,3 37,4 37,5 37,6 37,7 37,8 37,9 38 38,1 38,2 1 3 5 7 9 11 13 15 17 profili di configurazione PS N R AHM20 no tools AHM20 no-rate_control

(24)

0 5 10 15 20 25 30 35 40 45 1 3 5 7 9 11 13 15 17 profili di configurazione b it-r at e (Kb p s) AHM20 no tools AHM20 no-rate_control

Figura 2.28: bit-rate per i vari casi (MD test)

2.5.3 Analisi Con FOREMAN QCIF

Anche questa sequenza, come Mother&Daughter può essere pensata per applicazioni tipo videoconferenza con bit-rate da 100 a 200 Kbps. Vengono di seguito riportati i grafici che indicano il comportamento dei due software al variare dei casi di configurazione. 50 100 150 200 250 te m po di c odi fi ca ahm20 AHM20 no-rate_control

(25)

Si osserva dal grafico in Fig. 2.29 una riduzione del tempo di codifica fino al 50% mentre, in Fig. 2.30 e 2.31, non si evince una rilevante variazione di prestazioni .

28 28,5 29 29,5 30 30,5 31 31,5 32 1 3 5 7 9 11 13 15 17 profili di configurazione P S NR (dB) AHM20 no tools AHM20 no-rate_control

0 10 20 30 40 50 60 70 1 3 5 7 9 11 13 15 17 profili di configurazione b it-r at e (Kb p s) AHM20 no tools AHM20 no-rate_control

(26)

2.5.4 Analisi Con FOREMAN CIF

Questa sequenza che presenta un bit-rate di centinaia di Kbps (300-600). Vengono di seguito riportati i grafici che indicano il comportamento dei due codici C al variare dei casi di configurazione

0 100 200 300 400 500 600 700 800 900 1 3 5 7 9 11 13 15 17 19 profili di configurazione te m po di c odi fi ca AHM20 no tools AHM20 no-rate_control

Si osserva ancora una riduzione del tempo di codifica fino al 45%. Dagli altri grafici in Fig. 2.33-2.34 si vede che l’andamento relativo al PSNR e al bit-rate sono pressoché identici.

(27)

34,5 35 35,5 36 36,5 37 37,5 1 3 5 7 9 11 13 15 17 19 profili di configurazione P S NR (dB) AHM20 no tools AHM20 no-rate_control

0 100 200 300 400 500 600 1 3 5 7 9 11 13 15 17 19 profili di configurazione b it-r at e (Kb p s) AHM20 no tools AHM20 no-rate_control

(28)

2.5.5 Analisi Con STEFAN CIF

0 100 200 300 400 500 600 700 800 900 1 3 5 7 9 11 13 15 17 19 profili di configurazione te m po di c odi fi ca AHM20 no tools AHM20 no-rate_control

Si osserva ancora una riduzione del tempo di codifica fino al 45%. Dagli altri grafici in Fig. 2.36-2.37 si vede che l’andamento relativo al PSNR e al bit-rate subiscono un peggioramento di circa il 2%.

(29)

32 32,5 33 33,5 34 34,5 35 35,5 36 1 3 5 7 9 11 13 15 17 19 profili di configurazione P S NR (dB) AHM20 no tools AHM20 no-rate_control

0 200 400 600 800 1000 1200 1400 1600 1800 1 3 5 7 9 11 13 15 17 19 profili di codifica b it-r at e (Kb p s) AHM20 no tools AHM20 no-rate-control

(30)

2.5.6 Conclusioni

Dall’ analisi del comportamento dei due codici sulle sequenze proposte, per più applicazioni in termini di bit-rate,si evince che il guadagno in termini di tempo di codifica che si otteneva nel confronto tra la versione 6.1d del codice C e la versione AHM20 con entrambi i tools non attivi, è da attribuirsi principalmente all’introduzione di un’area di ricerca adattiva. Questo risultato in realtà era prevedibile in quanto una riduzione dell’area di ricerca permette una riduzione del tempo che deve essere speso per la codifica di ogni singolo macroblocco. Inoltre il prezzo che dobbiamo pagare in termini di prestazioni per la diminuzione dei tempi è piccolo se confrontato col guadagno ottenuto. Infatti osservando i dati che si hanno sulle varie sequenze operando con una ricerca esaustiva ,”full-search”, e utilizzando l’area di ricerca adattiva, “adaptive-search”, ho un peggioramento di prestazioni inferiore al 5% mentre ottengo un guadagno sui tempi di oltre il 50% tale guadagno è molto elevato per bassi bit-rate dove ho inoltre non si presente alcuna diminuzione delle prestazioni.

2.6 Peso della stima di moto all’interno dell’encoder

Come avevamo accennato nel paragrafo 2.3 la stima del moto rappresenta un collo di bottiglia per l’encoder, è possibile stimare in percentuale il peso che essa ha nell’intera codifica di immagini in termini di tempo necessario che adopriamo come stima della complessità. Per la nostra analisi utilizzeremo la versione originale del codice (mantenendo cioè non attivi l’area di ricerca adattiva e il rate-control) e la confronteremo con lo stesso codice in cui opereremo due variazioni. Prima utilizzeremo una stima di moto banale, cioè semplicemente differenziale (come si aveva per lo standard H.261), successivamente utilizzeremo il codice disabilitando completamente la stima del moto, giungendo dunque a una codifica di tipo intra e non più inter. La prima modifica si ottiene forzando a 0 il search_range nella parte di codice riguardante la stima del moto, testando quindi il codice C così ottenuto posso capire il tempo minimo

(31)

riguardante la stima del moto. In tale caso il tempo che misuriamo ci dà un’idea del tempo che è necessario spendere nella codifica senza effettuare la stima del moto.

Effettuando questa analisi su più sequenze ottengo i risultati in Tabella 2.3:

Tabella 2.3 Confronto tra il tempo di elaborazione ottenuto con la FS e quelli ottenuti utilizzando rispettivamente una codifica differenziale e una codifica di tipo intra.

Video sequenze QP Bit-rate PSNR TempoFS/ tempoRange0 TempoFS/ tempoIntra Mother&Daughter _qcif 28 47,6 Kbps 37,1 2,9 4,8 Foreman_qcif 28 150,3 Kbps 35,8 2,9 4,8 Stefan_cif 28 1250,9 Kbps 35,2 2,6 4,1 Mobile&Calendar_sif 28 2124 Kbps 33,3 2,6 3,9

In Figura 2.38 si mette in evidenza la percentuale del tempo totale di codifica, ottenuto utilizzando l’algoritmo di Full Search, che è da attribuire alla stima del moto (1+3), e alla scelta di una stima del moto più complessa di quella differenziale (1).

(32)

1 2 3

Figura 2.38: tempi di codifica:

1. percentuale dovuta unicamente alla scelta dell’algoritmo di FS

2. percentuale dovuta alla codifica di tipo intra ( che comunque deve essere spesa per un qualunque approccio di codifica)

3. percentuale che deva essere aggiunta alla 2 per un approccio di codifica di tipo inter differenziale (rappresenta la percentuale minima che devo spendere comunque per una codifica inter)