Capitolo V Valutazione delle prestazioni e statistiche

V.1 Introduzione

Dopo aver realizzato larchitettura di streaming le cui caratteristiche sono state evidenziate nello scorso capitolo, si è reputato di utilizzare i servers ed i clients a disposizione per arricchire le conoscenze sulla trasmissione dei dati multimediali, enfatizzando in particolare le problematiche relative alla pacchettizzazione degli stessi in un flusso RTP. Il poter contare infatti su applicativi efficienti e funzionali, ha spinto la conclusione della tesi verso una ricerca sperimentale tesa alla comprensione di alcune caratteristiche ancora non ben definite della trasmissione dei media.

Lidea alla base del lavoro presentato nel presente capitolo è stata quella di enfatizzare le caratteristiche della codifica audio e video, anche se questultima ha rappresentato loggetto predominante della ricerca ai fini della sperimentazione. Basti ricordare le problematiche e le tecniche molto complesse da utilizzare nella codifica video, per giustificare detta preferenza. Inoltre, si ricordi anche la sfrenata corsa attuale verso la creazione di sistemi supportanti la videotelefonia mobile, nel cui contesto, è da segnalare una presa di coscienza della ricerca che ha proposto il MPEG-4 come standard da utilizzare per simili applicazioni [5], motivando la scelta in particolare nelle caratteristiche molto performanti di tale codec in regime di banda limitata. A tal proposito, la lettura di vari articoli divulgativi del IEEE [6][7][8] sulle caratteristiche di trasmissione in particolare del MPEG-4, con relative descrizioni delle ricerche e modellizzazioni del trasporto, ci ha spinto ulteriormente verso un analisi sperimentale più approfondita delle modalità di realizzazione della trama RTP contenente dati multimediali in MPEG-4. Quello che si è cercato di studiare è leffettivo comportamento nella pacchettizzazione di una stessa sequenza video, ma con caratteristiche diverse, quali dimensione del quadro, frame rate e video bit rate, mediante realizzazioni e analisi di statistiche di traffico, in modo da poter trovare una correlazione tra i tre parametri suddetti e poter così confrontare i risultati ottenuti con alcuni già disponibili ma in genere ottenuti a partire da modellizzazioni.

Il poter contare su servers e clients egregiamente funzionanti, oltre naturalmente sul sistema di TV-on-Demand realizzato, ha permesso di basarsi sin da subito su tali efficienti dispensatori di risorse mediatiche con caratteristiche di codifica diverse, ciascuno dei quali ha rappresentato uno strumento necessario per lo studio dei pacchetti RTP, che di fatto, implicano una trasmissione di dati tra client e server.

 

V.2 Codificatori utilizzati per la ricerca

Per le prove da realizzare è nata sin dal primo momento la necessità di avere a disposizione dei media campioni, possibilmente diversi tra di loro, a partire dai quali poter poi fare dei confronti di prestazione e di qualità in funzione dello streaming.

Per detto motivo, è subentrata lesigenza stringente di poter contare su codificatori e decodificatori in grado di trattare le tracce video e audio dei media, per ottenere files di diverso formato e codifica. Per tale proposito, si sono presi in considerazione fondamentalmente tre codificatori.

 

V.2.1 Mencoder

Il mencoder, già citato nello scorso capitolo, è un codificatore e decodificatore utilizzante le stesse librerie di mplayer, quindi tutto sommato completo ai fini della codifica. Con esso si ha la possibilità di catturare live un evento televisivo da scheda TV, ma anche da DVD o CD e codificarlo in particolare con codifica MPEG-1/-2 o MPEG-4/DivX, creando un file in formato AVI. In realtà, esso permette anche la realizzazione di files AVI grezzi, ossia files il cui contenuto è rappresentato da una traccia video grezza in formato YUV 4:2:0 Planare e di una traccia audio in PCM. Una volta ottenuto un file del genere, è possibile allora codificarlo utilizzando uno dei codecs citati per il video e per laudio, in modo da poter contare su una traccia originale non codificata e di più tracce, con diverse caratteristiche, ottenute a partire da essa.

Si è però riscontrato un notevole problema nell'uso di tale codificatore, caratterizzato dalla necessità di voler hintare i files ottenuti, in modo da poter contare non solo sugli stessi contenuti della sequenza ma anche sulla possibilità di poter utilizzare lo stesso file sia per Helix, sia per Darwin. Lostacolo principale è stata la impossibilità di hintare detti files, poiché il file AVI costruito da mencoder, utilizza degli header non interpretabili da mp4creator, che come detto, è lunico strumento di trasformazione di un file su piattaforma Linux. Utilizzando mencoder come codificatore, lunica implementazione realizzabile è stata ottenere un file mp4 hintato, a partire dal AVI grezzo ottenuto da mencoder, mediante il codificatore mp4encode di MPEG4IP.

Questultimo non ha la possibilità di catturare live un evento da dispositivo, ma con input un file AVI con video yuv420p e audio pcm, è in grado di creare un file hintato con codifica video a scelta tra ISO MPEG-4 e XviD, anche se questultima si lascia preferire notevolmente per la rapidità ed efficienza e codifica audio AAC o MP3. Unendo allora le caratteristiche di mencoder e di mp4encode, si riesce ad ottenere files con caratteristiche diverse, quali dimensione quadro, bit rate, frame rate e audio bit rate, anche se cè da sottolineare un grosso inconveniente nella codifica audio dove purtroppo si è notata una carenza di sincronizzazione della traccia poiché essa viene codificata in genere a velocità doppia.

Il problema si suppone essere nel cambio di velocità di codifica tra il bit rate originale e quello voluto nel creare il file mp4. Analogamente, laver catturato con mencoder una sequenza grezza con un fissato frame rate, rende di fatto inutilizzabile la possibilità con mp4encode di modificare tale parametro, poiché si assisterebbe ad una modifica del tempo di visualizzazione; così, se il frame rate originale è 25 fps, e si tenta di codificare in MPEG-4 con frame rate 4 fps, leffetto è il rallentamento della sequenza di un fattore 6 (25/4). E così allora nata lesigenza di dover utilizzare necessariamente un videoregistratore, con il quale, quanto meno riuscire ad ottenere tante sequenze grezze quanti sono i frame rate campioni desiderati.

 

V.2.2 Ffmpeg

Altro codificatore preso in considerazione è stato il ffmpeg, dellomonimo gruppo di ricerca [25]; con esso è possibile catturare da TV il segnale, e codificarlo direttamente in MPEG-1/-2 o MPEG-4 e audio MP3, oppure ottenere un file grezzo, per poi codificarlo in seguito. Per questultima opzione però, è bene sottolineare che il codificatore è in grado di ottenere la sola traccia video in formato yuv420p o la sola traccia audio in pcm, ma non entrambe contemporaneamente. Questa grossa limitazione, comunque non ha rappresentato poi un così grave problema, poiché si è deciso di analizzare separatamente le tracce audio e video. La caratteristica più importante di ffmpeg, è che dal file grezzo, si possono ottenere file in formato MPEG-PS con codifica video MPEG-1/-2 e files in formato AVI, con codifica MPEG-4/DivX, entrambi hintabili con mp4creator. Si è reputato allora, per detta caratteristica, preferibile lutilizzo di questo codificatore al mencoder, il quale si ricorda, utilizza comunque le stesse librerie di FFMPEG. Inoltre è da sottolineare, la possibilità di ottenere durante la codifica video, mediante lopzione vstats un file di statistiche molto prezioso per lanalisi dei frames contenuti nella sequenza, in modo da poter controllare la successione dei GOP ed in particolare capire quali tipi di frames sono stati utilizzati durante la codifica.

 

V.2.3 Mp4live

Infine, altro codificatore preso in questione è stato lo stesso mp4live, di cui ampiamente si è discusso nello scorso capitolo e che si ricorda è anche e soprattutto un codificatore MPEG-4/XviD, molto più semplice da utilizzare rispetto agli altri precedentemente citati, data la sua interfaccia grafica molto completa, ma con lo svantaggio di non poter costruire un file grezzo da cui poi codificare, poiché esso fa codifica MPEG-4 al volo, quindi costruisce un file mp4 già hintato con codifica video XviD e audio a scelta tra AAC e MP3.

Nella realizzazione del materiale oggetto della sperimentazione si sono utilizzati i codificatori ffmpeg e mp4live, entrambi i quali hanno ricevuto in input le stesse sequenze riprodotte da un videoregistratore e separando la codifica video da quella audio; questa scelta ha naturalmente implicato codifiche diverse a seconda del codificatore scelto, potendo contare quindi su versioni non ufficiali del codec MPEG-4, ossia rispettivamente, il DivX per ffmpeg ed il XviD per mp4live. Naturalmente i tests effettuati hanno portato a delle conclusioni, elencate nel seguito, che nel caso mp4live si estendono implicitamente allarchitettura di TV-on-Demand realizzata, la quale, come evidenziato nello scorso capitolo, si basa interamente sulle codifiche audio e video di mp4live.

 

V.3 Generalità sui pacchetti audio e video

V.3.1 Audio

In tale contesto è buona norma evidenziare per prima cosa le differenze principali tra audio in codifica AAC e audio in codifica MP3. Per il AAC [15], infatti, laudio viene considerato come uno dei vari oggetti facenti parte di una sequenza, quindi nel caso in questione, si parla addirittura in termini di audio frames, che in realtà si riferiscono a detti oggetti sonori, i quali, se in una stessa scena ci fossero più fonti sonore, sarebbero vari e distinti tra loro. Si costruisce allora un'unica entità denominata AudioMuxElement, che rappresenta lunità base di trasferimento nel pacchetto RTP e inglobante uno o più audio frames. Ciascuno di essi, deve essere mappato in almeno 1 pacchetto RTP ed è previsto in generale luso del Marker bit nel header RTP, per segnalare, in caso di elemento "spalmato" su più pacchetti, la fine dello stesso. Nel MP3, invece, si parla in termini di Application Data Unit frames, ossia lintera traccia audio viene codificata nella sua interezza, quindi senza alcuna distinzione in oggetti separati, e successivamente spezzettata e interlacciata in tante ADU ciascuna di fissata dimensione, che successivamente vengono inpacchettate nella trama RTP, dando luogo, in genere, ad un payload di lunghezza uguale per ciascun pacchetto. Per il MP3 non sarebbe previsto luso del campo mark, che però, viene utilizzato comunque contravvenendo così alle specifiche di pacchettizzazione.

 

V.3.2 Video

V.3.2.1 Parametri principali

Nella codifica video, i parametri principali sono essenzialmente tre:

 

V.3.2.2 Frames

A differenza della codifica audio, ora i frames giocano un ruolo molto importante ai fini della codifica stessa; come detto infatti nel capitolo III, una sequenza video può essere considerata come una successione di tante immagini, ciascuna delle quali è unentità a sé stante. A partire da dette immagini, si ottiene una sequenza di frames, ricavati in maniera diversa; così un frame I si otterrà dalla codifica effettiva di una immagine data, mentre un frame P e un frame B, si otterranno da una predizione in avanti o in dietro dei campioni (frames) precedenti o a posteriori. La sequenza video quindi, viene ad essere modificata in una sequenza di frames, ciascuno dei quali contribuisce in maniera diversa al trasporto dei dati; un frame I, avrà più dati perché trasporta le informazioni effettive dellimmagine codificata, mentre un frame P e, peggio ancora un frame B, trasportando solo i vettori di movimento e lerrore di predizione, saranno meno "pesanti" poiché contengono informazioni indirettamente utili per la ricostruzione dellimmagine ad esso relativa. Con questo breve ripasso si è voluto così enfatizzare limportanza dello studio dei frames che di fatto rappresentano lunità base di una sequenza video codificata.

 

V.3.2.3 Relazione tra VOP e frame

Analizzando attentamente i pacchetti RTP mediante ethereal, si è notato la grossa influenza del bit rate sul campo mark della trama, come cera da attendersi; per prima cosa, per un fissato frame rate, si è voluto calcolare il numero medio dei VOPs per frame, per avere una idea della complessità dellalgoritmo di codifica precedentemente utilizzato per la realizzazione del media.

Si è così calcolato il numero medio di pacchetti marcati nellunità di tempo, evidenziando in questo modo, una particolarità molto curiosa: il numero di mark bit in un secondo, infatti, è comparabile con il frame rate e detta caratteristica rimane invariata al variare del frame rate Lavere una sequenza ad esempio con un frame rate 25, significa contare circa 25 pacchetti marcati al secondo, al contrario del caso a 4 fps, dove naturalmente i mark sono circa 4 al secondo. E stato allora facile evincere che, sia ffmpeg sia mp4live, associano ad un frame un unico VOP, che naturalmente coincide con il frame stesso, facendo in questo modo però perdere gran parte delle potenzialità del MPEG-4.

Da varie letture, comunque, si è notato che effettivamente nonostante i buoni propositi, la stragrande maggioranza dei codificatori MPEG-4 esistenti, utilizza detta scelta progettuale, risparmiando così notevolmente sulla complessità del tool realizzato. Una volta messa in evidenza questa caratteristica, si è potuto semplicemente associare ad ogni pacchetto marcato un frame, ricordando però che più pacchetti in genere sono necessari per trasportare il contenuto di un frame, utilizzando appunto il campo mark per segnalare lultimo pacchetto del frame stesso; i pacchetti tra due mark, avranno stesso timestamp, custode di informazione sullistanza di campionamento del frame, a conferma di quanto detto pocanzi.

 

V.3.2.4 Pacchetti e variazione della qualità funzione del BR e FR

Un aspetto molto interessante da evidenziare è che per un fissato bit rate, allaumentare del frame rate, la qualità del singolo frame decade, poiché gli stessi bit trasmessi in un secondo devono essere divisi su più immagini; quindi ad esempio, con un bit rate 500 kbps (500000 bit in un secondo), in una sequenza a bit rate 4 fps, ciascun frame sarà codificato mediamente 125000 bit, mentre in una sequenza a 25 fps, ogni frame peserà mediamente 20000. Stesso discorso si può fare nel caso in cui invece si mantenga fisso il frame rate, variando il bit rate; naturalmente, a parità di frame, allaumentare della velocità si avrà più informazione e quindi resa migliore.

Alla luce di quanto detto è allora naturale aspettarsi che per un fissato bit rate, allaumentare della velocità, aumenteranno i pacchetti inviati ed anche il numero dei pacchetti non marcati, poiché ora ciascun frame ha più dati, quindi necessita dellintero contenuto di più pacchetti RTP; si è assistito infatti con ethereal ad una sequenza di pacchetti non marcati tutti di dimensione massima (circa 1470 bytes), alternati da pacchetti marcati naturalmente più piccoli, poiché contengono linformazione rimasta da trasportare per il frame corrente.

E ovvio che, per quanto detto precedentemente, lo stesso discorso vale anche nel caso di fissato bit rate e frame rate decrescente, dove si verifica, per unità di tempo, un aumento della densità dei pacchetti a dimensione massima. Quanto detto fino ad ora però deve essere preso con le dovute cautele, in quanto, si è considerato il caso in cui tutti i frames abbiano lo stesso "peso". In realtà, si sa che i frames sono distinti tra loro, quindi ci saranno frames con più dati degli altri.

A parità della durata di sequenza per un fissato bit rate scelto infatti, se ad esempio dopo un frame P deve essere codificato un frame I, ci si aspetta da parte del codificatore un aumento istantaneo del bit rate in maniera proporzionale allaumento del numero di bit necessari alla codifica del frame I rispetto al P, che naturalmente si riflette anche in lato trasmissione. Il bit rate effettivo quindi, sarà fluttuante intorno al valor medio, con un andamento legato alla successione dei vari frames I, P e B.

 

V.4 Strumenti utilizzati per le statistiche

Per poter comprendere con precisione le caratteristiche di un flusso di dati multimediali mappato nella trama RTP, si è avuto bisogno di alcuni strumenti che permettessero di entrare nei pacchetti stessi ed evidenziarne così la struttura.

 

V.4.1 Sniffer

A disposizione come già detto si avevano già gli sniffer ethereal e tcpdump, due applicativi Linux molto potenti, perché in grado di catturare i pacchetti trasferiti da un client ad un server, di qualsiasi natura essi siano, per poi permetterne la lettura dei dati da essi trasportati. Così, nel caso in questione, utilizzando detti tools, si è potuto leggere il contenuto del payload dei pacchetti UDP trasferiti, ossia i pacchetti RTP incapsulati appunto nel datagramma; si ricordi, infatti, che le prove in questione sono state realizzate in laboratorio utilizzando due macchine distinte, genni e comel, collegate in rete tra loro mediante una LAN.

Con uno sniffer, forzando lascolto su uno dei due host, si catturano così i pacchetti Ethernet, costituiti da headers e carico pagante nella forma di datagrammi IP. Questi ultimi, a loro volta, saranno costituiti da bytes di intestazione più un payload costituito dai pacchetti UDP o TCP. Se si stanno trasportando dati multimediali con esigenze realtime, il protocollo di trasporto sarà il UDP, costituito anchesso di headers più payload rappresentato da pacchetti RTP.

A loro volta tali pacchetti, avranno un header più un carico pagante costituito proprio dai dati multimediali, oggetto del trasporto. Utilizzando uno sniffer allora, si possono controllare in particolare le caratteristiche del pacchetto RTP, studiandone il contenuto degli headers e leggendone il numero di bytes complessivo, per avere così unidea di quanti dati esso trasporta e quindi di quanto sia "prezioso" il carico da esso trasportato.

 

V.4.2 Uso di Tcpdump

Lidea di partenza è stata necessariamente quella di catturare i pacchetti in streaming, per poterli poi analizzare; si è preferito utilizzare a tal fine lo sniffer tcpdump, il quale permette con assoluta semplicità da riga di comando di creare files di testo dove memorizzare le informazioni necessarie.

Di sicuro ethereal è un tool molto più completo di tcpdump, in quanto è dotato di una utile interfaccia grafica che mette in evidenza lintera successione dei pacchetti con i relativi contenuti, ma è anche più complesso da maneggiare, data proprio la sua caratteristica veste grafica.

Con il comando:

tcpdump host comel and port 1026 w file.pcap

si è messo in ascolto lo sniffer sulla porta 1026 dellhost comel e si è costruito un file, file.pcap, in cui memorizzare le informazioni ottenute. Successivamente, tramite gmp4player, si è richiesto un media dai servers Darwin o Helix su genni, per poter dare luogo alla sessione di streaming e quindi al trasferimento e conseguente cattura dei pacchetti.

Laver utilizzato un filtro sulla porta 1026 è stato necessario in modo da poter catturare i soli pacchetti UDP dello streaming, mentre la scelta di quel preciso numero di porta (1026), è stata dettata dal fatto che il client gmp4player si mette in ascolto sempre sulle stesse porte; così, se il media ha solo una traccia esso utilizzerà per il RTP la 1026 e per il RTCP la 1027, se invece ha una traccia video e una audio, utilizzerà rispettivamente le porte 1026/1027 per RTP/RTCP video e 1028/1029 per RTP/RTCP audio.

Laver scoperto questa caratteristica notevole di gmp4player, ha senza dubbio risolto il problema di dover dare luogo prima allo streaming, scoprire la porta RTP di utilizzo e solo così lanciare in seguito il tcpdump. Poiché come detto in precedenza si è interessati allo studio di un solo flusso RTP per volta, si è deciso di optare per una cattura selettiva, rendendo così necessario il filtraggio della porta descritto in precedenza e mostrato nellesempio sopracitato.

Una volta terminato lo streaming e quindi creato il file file.pcap, si è riaperto tcpdump e gli si è fornito in lettura lo stesso file, in modo da poterlo visualizzare e controllare che la cattura sia andata a buon fine:

tcpdump r file.pcap > file.txt

Da notare dal comando mostrato come si sia preferito costruire un secondo file di testo a partire dalluscita del tcpdump, mediante semplice redirezione. Il file così creato si è mostrato come una sequenza di stringhe del tipo:

14:03:01.435688 genni.ing.uniroma1.it.21448 > comel.ing.uniroma1.it.1026: udp 1024 (DF)

ciascuna di essa, quindi, contiene lindicazione dellorario di arrivo, dellhost mittente, dellhost destinazione, del protocollo sniffato, della dimensione in byte del pacchetto.

Come si evince allora, con detto meccanismo, si è riuscito ad ottenere una prima mappatura dei pacchetti e per ciascuno di essi ad avere a disposizione due importantissime informazioni: i tempi di interarrivo e le dimensioni in byte. Da qui è nata allora lidea di utilizzare detto file per ottenere delle statistiche sui tempi di interarrivo e sulle dimensioni dei vari pacchetti.

 

V.4.3 Studio dei tempi di interarrivo

Mediante i tempi di interarrivo, si sono potute studiare due caratteristiche della trasmissione: da comel, quindi in LAN con genni, detti tempi hanno fornito un indicazione del profilo di invio dei pacchetti da parte dei due servers, evidenziandone eventualmente le differenze nel creare i pacchetti, inserirli nella trama RTP e spedirli; ciò perché i tempi di trasmissione dati tra genni e comel sono stati valutati in circa 500ms (evidenziato con il comando ping comel da genni; in questo modo si interroga lhost comel per verificarne lattività.

In caso di risposta affermativa, si riceve un messaggio in cui è indicato il tempo tra linvio della richiesta e la risposta ricevuta, quindi due volte circa il tempo necessario ad un pacchetto di arrivare da genni a comel), tempo questo molto piccolo, che quindi non ha pregiudicato la misurazione, dato che i tempi di interarrivo sono in genere dellordine dei 40-60 ms, non risentendo quindi più di tanto del ritardo di trasferimento.

E chiaro allora che in questo contesto, parlare di tempi di interarrivo ha significato parlare anche in termini di tempi di interpartenza, dato come si è visto lassoluta ininfluenza del ritardo di propagazione. Se invece le misurazioni sono state fatte altrove, quindi utilizzando effettivamente la rete Internet, con i tempi di interarrivo si è potuto evidenziare lo stato del traffico in rete e come esso abbia influito sul cammino di ciascun pacchetto.

 

V.4.4 Studio delle dimensioni dei pacchetti

Con le dimensioni dei pacchetti invece, non dipendendo naturalmente dalla rete, si è potuta valutare la differenza nel contenuto degli stessi, poiché si è riscontrata una ovvia e chiara proporzionalità tra sequenza trasmessa e quantità dei dati necessari alla codifica delle immagini o suoni costituenti la detta sequenza. Di questo comunque se ne parlerà nel prossimo paragrafo.

 

V.4.5 Uso di Octave

Quello di cui si è avuto veramente bisogno in questa fase, è stato allora un meccanismo in grado di avere in input il file file.txt e fornire in uscita le statistiche volute. A questa necessità, si è venuto incontro con lausilio di octave, tool equivalente al ben più noto matlab, che con le proprie librerie di calcolo, tra cui anche librerie di statistica appunto, ha fornito un notevole supporto per i fini preposti. Dandogli in ingresso infatti un programma implementante un dato algoritmo, udpstat, si sono riusciti ad ottenere i risultati cercati.

Il principio di esecuzione del detto algoritmo è il seguente: in ingresso gli viene fornito il file file.txt, da cui legge riga per riga le stringhe, memorizzando di volta in volta, in due vettori diversi, le differenze tra i tempi di interarrivo tra due pacchetti consecutivi e la dimensione in byte di ciascun pacchetto.

Successivamente, una volta fornite delle informazioni preziose quali il numero di pacchetti letti, il numero medio di byte in ciascun pacchetto e la dimensione massima riscontrata, esso permette di visualizzare quattro grafici in formato postscript, raffiguranti rispettivamente landamento del numero di byte al variare dei pacchetti, listogramma ad esso relativo, landamento dei tempi di interarrivo al variare dei pacchetti ed il relativo istogramma.

Tutto ciò naturalmente, riguarda la sola analisi dei pacchetti che, se per una traccia audio può essere sufficiente a fornire una descrizione dettagliata delle proprie caratteristiche, per una traccia video invece, permette ben poche conclusioni. Si può dire che, nel contesto della ricerca, il semplice studio dei pacchetti sia utile al fine di evincere alcune caratteristiche dei servers, mentre per uno studio della codifica, quindi interno alloggetto della trasmissione, è necessario entrare nei pacchetti, evidenziandone in particolar modo la distribuzione dei frames.

 

V.4.5.1 Studio del mark bit

Come primo passo allora, si è deciso di incrementare le funzionalità dellalgoritmo di statistica udpstat, fornendo un meccanismo di discriminazione dei frames nei pacchetti. Per tale proposito, si è considerata la caratteristica successione dei pacchetti marcati in una sequenza trasmessa, quindi, aggiungendo un semplice contatore dei bit mark per ciascun pacchetto, si è potuto così contare il numero dei frames della sequenza, darne la distribuzione statistica, evidenziandone le dimensioni in byte di ciascuno di essi e ottenere informazioni quali il numero medio di byte per ciascun frame, il numero di byte contenuti nel frame più grande ed il numero medio di pacchetti necessari a contenere i dati complessivi di ogni frame.

Prima però di poter contare sullalgoritmo, è stato necessario modificare il formato delle stringhe di output fornite in seguito alla cattura da tcpdump.

In quelle usate in precedenza infatti, era mappata la sola dimensione di ciascun pacchetto, a prescindere dal contenuto, così allora, aggiungendo lopzione T rtp al comando tcpdump (tcpdump host comel and port 1026 T rtp w stat.pcap) si permette allo sniffer di decodificare anche i primi bit del header rtp, riuscendo di fatto a memorizzare riga per riga anche il mark bit.

Dando come input un file costruito nei modi suddetti, si sono potuti ottenere dei grafici visualizzanti rispettivamente landamento delle dimensioni dei frames ed il relativo istogramma.

 

V.4.5.2 Studio della autocorrelazione della dimensione dei frames

Una volta che si è potuto contare su un efficiente meccanismo di controllo dei frames che permettesse lisolamento degli stessi dai pacchetti , ci si è chiesto come poter mettere in evidenza le caratteristiche dei tre tipi di frames conosciuti, gli I, P e B per poterne studiare così la distribuzione statistica.

A tal proposito però, quel che mancava era la conoscenza precisa della dimensione dei GOPs, in quanto, per poter implementare un algoritmo efficiente che contasse le dimensioni di ciascun frame di uno stesso tipo, bisognava avere come dato iniziale il periodo di riproposizione dei frames e quindi del GOP stesso. Si è allora pensato di determinare la autocorrelazione del vettore dei frames costruito (le cui osservazioni sono le dimensioni in byte di ciascun frame), in modo da verificare dal suo studio, in che modo i frames fossero tra di loro correlati.

Lanalisi di studi precedentemente realizzati in altri ambiti di ricerca [8], hanno dimostrato la bontà di una tale indagine, che avrebbe dovuto fornire un andamento tipico della autocorrelazione, con dei picchi molto distinti tra loro, i frames I, nel mezzo dei quali individuare una fluttuazione dovuta allalternarsi di due frames B e un frame P; è naturale che da tale osservazione, si può quindi facilmente evincere il periodo tra due picchi I e quindi la dimensione del GOP ricercata.

Viceversa il trovare una sequenza molto scorrelata, avrebbe potuto mettere in evidenza lassenza di una dimensione standard del GOP o, addirittura, linutilizzo nella codifica dei frames B. Per il calcolo della autocorrelazione nellalgoritmo realizzato, si è utilizzata la funzione autocor di octave. Per lo studio dei frames, del GOP e della loro distribuzione, si è preferito anche poter utilizzare i files di statistiche realizzati dal codificatore ffmpeg durante la codifica, poiché in essi già è mappata la successione dei frame I,P e B, in modo da poter contare anche su risorse che fungessero da prova quanto meno per il controllo della distribuzione dei frames.

Si è deciso allora di creare un altro algoritmo, udpstatgop.m (mostrato in Appendice B), che sempre tramite octave potesse leggere detti files di statistiche ffmpeg e realizzare così istogrammi sulla dimensione dei GOPs.

V.4.5.3 Studio del throughput

Infine, una volta appurato di aver in mano solidi strumenti per lo studio della pacchettizzazione in generale, si è reputato interessante poter ulteriormente ampliare le funzionalità dellalgoritmo udpstat aggiungendo il calcolo del throughput, per poter così avere una chiara traccia dellandamento istantaneo del bitrate dei servers in trasmissione.

Si è fatto in modo che da riga di comando un utente qualsiasi potesse decidere se far calcolare il throughput al programma (con lopzione t), fornendogli quindi il valore del DT (con lopzione d valore) e potendo personalizzare il range di visualizzazione (opzione r) imponendo il calcolo del parametro utilizzando non tutti i pacchetti ma solo alcuni di essi da un estremo inferiore (-x valoremin) ad un estremo superiore (-y valoremax).

Si ottengono così due grafici, uno relativo alla distribuzione dei bytes/ DT al variare dei DT e laltro relativo al throughput effettivo, in bytes/secondo, al variare degli istanti DT di osservazione. Con lultimo grafico si ottiene landamento istantaneo del bit rate effettivo, come se si stesse fotografando ad intervalli di DT il comportamento del server/trasmettitore.

Inoltre, mediante la scelta opportuna del valore del DT, si possono evidenziare varie caratteristiche: un DT uguale al frame rate fornisce, infatti, un andamento in uscita molto frastagliato poiché riflette landamento delle dimensioni dei vari frames, che come detto, oscillano al variare del tipo di frames. Con un DT più piccolo del frame rate, landamento è ancor più frastagliato, poiché in questo modo si tendono ad evidenziare le oscillazioni delle dimensioni dei pacchetti, mentre per un DT grande rispetto al frame rate, landamento è più smussato, poiché, nellintervallo di tempo si sta catturando la somma dei byte di più frame; addirittura nel caso in cui la sequenza avesse GOPs di dimensione fisse, ad esempio di 12 frames per GOP, con un DT 12 volte il frame rate si prenderebbero in ogni osservazione 12 frames, quindi il GOP stesso.

Il risultante algoritmo così ottenuto, udpstatmio.m, completo di tutte le funzionalità sopra citate, può essere consultato in Appendice B, dove ne viene mostrato il codice e dove si può trovare anche il codice del programma udpstatmio necessario a far girare lalgoritmo con octave.

 

V.5 Statistiche audio AAC/MP3

Con tutte le informazioni ottenute da octave e reiterando le operazioni sopra citate per i vari files multimediali a disposizione, si è riuscito ad effettuare una tornata di tests generali nel tentativo di evidenziare le differenze tra media con codifiche diverse distribuiti dallo stesso server e viceversa le differenze di stessi media, ma ottenuti da servers diversi.

 

V.5.1 AAC vs MP3

Le prove per laudio sono state molteplici e tese ad evidenziare caratteristiche diverse. Innanzitutto si è presa una sequenza audio di stessa natura (tratta da video musicale) e la si è codificata in maniera diversa: a parità di codifica utilizzata, AAC o MP3, si sono scelte 5 configurazioni diverse modificando la frequenza di campionamento e laudio bit rate: con freq. 16000 Hz i bit rates 8/56/112 kbps e con freq. 41000 Hz i bit rates 56/112 kbps. Si è ottenuto quindi un totale di 10 files diversi per altrettante diverse prove di trasferimento.

Dallosservazione dei grafici ottenuti con octave, il primo dato che è emerso è stato la marcata differenza tra le dimensioni dei pacchetti in codifica AAC e quelli in MP3; in MP3, infatti, come ci si aspettava, tutti e cinque i casi hanno evidenziato, per ciascuno di essi, tendenzialmente la stessa dimensione dei pacchetti, naturalmente variabile da caso a caso, salvo sporadiche oscillazioni; in AAC invece, si è denotata una distribuzione abbastanza variabile di detta dimensione, oscillante nei cinque casi in un range di 40-80 bytes e con un valor medio naturalmente diverso al variare dei casi.

A parità di frequenza e di bit rate, per i dati in codifica AAC, si è riscontrata una dimensione media dei pacchetti più alta di quella registrata nel caso MP3. Sono state poi valutate le differenze a parità di codifica e di frequenza di campionamento del bit rate: quel che è stato notato è un andamento altalenante delle dimensioni medie dei pacchetti, che nei casi a frequenza 16000 Hz, hanno mostrato una crescita moderata passando da 112 kbps ai 56 kbps, per poi decrescere sensibilmente tra i 56 kbps e i 8 kbps, tutto ciò sia nel caso MP3 sia nel caso AAC.

Naturalmente, per tale andamento, si è registrata un compensazione dovuta alla diminuzione molto marcata del numero dei pacchetti al diminuire del bit rate, garantendo quindi la ovvia diminuzione del numero totale dei byte necessari alla codifica del media. A parità infatti di durata del clip, dei frames, della frequenza e della codifica, diminuendo il numero di bit al secondo, deve naturalmente diminuire anche il computo totale dei byte di ciascun pacchetto.

Così ad esempio, per MP3 a 16000 Hz e bit rate 112 kbps, sono stati riscontrati 1600 pacchetti tutti di lunghezza 1026 per un totale di 1,64 Mbyte, per mp3 a 16000 Hz e bit rate 56 ne sono stati individuati 607 di lunghezza 1280 per un totale di 0.77 Mbyte e per mp3 a 16000 Hz e bit rate 8 ne sono stati individuati 400 di lunghezza 305 per un totale di 0,12 Mbyte. Discorso analogo per il caso AAC.

A parità di codifica e bit rate invece, allaumentare della frequenza di campionamento (da 16 kHz a 41 kHz) si è assistito ad un incremento del numero medio di byte per ciascun pacchetto, molto limitato comunque nella codifica MP3 ed invece molto sensibile nel caso AAC.

Tutto ciò ha riguardato lanalisi delle dimensioni dei pacchetti, per un fissato server, Darwin, ma è bene sottolineare che gli stessi andamenti relativi alle differenti configurazioni viste si sono ripetuti anche per Helix.

 

V.5.2 Tempi di interarrivo

Per quel che concerne invece lanalisi dei tempi di interarrivo, sempre nel caso di una stessa traccia audio e a parità di server, dalle analisi statistiche ottenute si sono evidenziate le seguenti conclusioni: a parità di codec e di frequenza di campionamento, al diminuire del bit rate, si è assistito al mantenimento dello stesso tempo massimo di interarrivo, ma con una sostanziale inversione di tendenza. Vediamola in dettaglio:

Per audio MP3, a frequenza 16 kHz e bit rate 112 kbps, sono stati contati 1400 pacchetti partiti a distanza 50 ms gli uni dagli altri e 200 a distanza 500 ms, quindi si è potuto affermare che mediamente ogni 7 pacchetti spediti a distanza 50 ms luno dallaltro, ne è stato spedito 1 a distanza 500 ms dallultimo inviato; si è messa in evidenza quindi una modalità di trasmissione tipica a burst.

Passando da 112 kbps a 56 kbps, si è invece assistito ad una inversione di tendenza: sono stati calcolati infatti 400 pacchetti spediti a distanza 50 ms e 207 a distanza 500 ms, quindi cè stato una diminuzione dei pacchetti spediti più velocemente, ossia in questo caso, ogni 2 pacchetti inviati a distanza 50 ms, è stato inviato 1 pacchetto dopo 500 ms dallultimo. Per 8 kbps, il trend è stato confermato: 175 pacchetti a distanza 50 ms tra linvio di ciascuno di essi e 225 a distanza 500 ms, quindi in questo caso si è evidenziata una più omogenea ripartizione dellinvio dei pacchetti, non notando quindi più il profilo di trasmissione a burst segnalato nel primo caso.

Lo stesso discorso appena fatto vale anche per la frequenza di 41000 Hz, confermando la tendenza generale ad un appiattimento omogeneo della trasmissione, anche se nel caso in questione, si è registrato una diminuzione del tempo massimo di interarrivo, passando infatti dai 500 ms nel caso 16 kHz ai 350 ms nel caso attuale; i due tempi di interarrivo principali riscontrati sono stati allora 50 ms (rimasto invariato) e 350 ms.

Quanto detto per il caso MP3, rimane inalterato passando alla codifica AAC, dove sono state confermate tutte le considerazioni suddette.

In prove invece realizzate al di fuori del laboratorio, utilizzando una linea ADSL, quindi con capacità di banda tale da poter comunque sopportare il flusso continuo di bit da uno dei due server, si è evidenziato una sostanziale sovrapposizione della distribuzione delle dimensioni dei pacchetti, come naturalmente doveva accadere, con rare impercettibili differenze dovute evidentemente a perdita completa dei pacchetti durante il tragitto dal server al client.

Dai tempi di interarrivo, non si sono notate sostanziali differenze, lasciando intuire che la rete non ha pregiudicato più di tanto il trasporto dei pacchetti; se ritardi ci sono stati, essi sono stati evidentemente tutti proporzionali tra loro, dato che gli andamenti delle distribuzioni nei due casi sono molto simili, con tempi di interarrivo compresi tra 0.01 sec e 0.1 sec circa.

Unica incongruenza è stata linterarrivo di due pacchetti giunti a distanza rispettivamente di 0.5 secondi e 2.3 secondi dai pacchetti che li hanno preceduti.

 

V.5.3 Helix vs Darwin

Entrambi i servers come già detto non hanno mostrato palesi differenze nel comportamento, in particolare dal punto di vista della pacchettizzazione, in cui le distribuzioni statistiche si sono rivelate perfettamente identiche; da notare invece che allaumentare del carico elaborativo del server, Darwin ha dimostrato di rispondere in maniera diversa da Helix; se questultimo, nel fornire un file che è già in trasmissione verso un altro client, non modifica le caratteristiche di trasmissione, in particolare i tempi di inter-partenza dei pacchetti che rimangono sostanzialmente uguali al caso in cui quel file sia già stato richiesto da altri utenti, Darwin, cambia dette caratteristiche.

Dai grafici dei tempi di inter-partenza, si nota infatti un cambiamento compensativo nella trasmissione. Se, quindi, con un file richiesto da un solo client, trasmette la maggioranza dei pacchetti ogni 80 ms, (come del resto anche Helix fa), con un file che è contemporaneamente distribuito ad un altro client, la maggioranza suddetta, si divide: una metà circa dei pacchetti verranno trasmessi ogni 120 ms, laltra metà dopo appena 5 ms luno dagli altri, mostrando quindi, una modalità di invio a burst.

 

V.6 Statistiche video MPEG-4

Gran parte di quanto detto per lanalisi della sola traccia audio, può venire esteso anche per la valutazione delle statistiche sui pacchetti di un flusso RTP con dati in codifica MPEG-4 video; tuttavia in questo contesto, si è reputato di enfatizzare maggiormente le caratteristiche video, con studi talvolta più approfonditi data la complessità sicuramente maggiore di un tale tipo di codifica.

 

V.6.1 MPEG-4: DivX vs XviD

V.6.1.1 Modalità operativa della ricerca

Come detto, per lo sviluppo della tesi è stato necessario utilizzare dei codificatori in grado di realizzare le risorse oggetto dello streaming, in generale cercando di partire da una stessa sequenza video e cercando di codificarla variando determinati parametri di interesse ai fini della ricerca. Ci si è serviti allora dei tools ffmpeg ed mp4live. La differenza sostanziale tra i due è nel tipo di codifica MPEG-4 implementata, che spazia da una versione opensource del codec DivX nel caso di ffmpeg, alla versione ufficiale e quindi originale del codec anchesso opensource XviD di mp4live. Lidea basilare dello studio è stata il prendere una stessa sequenza video (video musicale) di circa due minuti opportunamente registrata su videocassetta e codificarla successivamente mediante i due tools, potendo contare su tre valori tipo, per altrettanti parametri:

Facendo variare i tre parametri nei tre modi diversi, si sono ottenute 27 combinazioni, che sono state poi oggetto di analisi, per entrambi i casi, in modo da cercare di evidenziare eventuali differenze o affinità nei codecs.

Con ffmpeg la codifica è stata più agevole poiché ha comportato la cattura da scheda TV collegata al videoregistratore di soli 3 media, uno per ciascun frame rate di interesse, in formato avi con codifica video grezza, quindi YUV12 (YUV:4:2:0:P) data la predisposizione di ffmpeg a supportare detta funzionalità; successivamente si è pensato a convertire i tre files in DivX variando la dimensione del quadro ed il bitrate.

Con mp4live, invece, è stato necessario catturare 27 volte da videoregistratore, per permettere la creazione di altrettanti files già in codifica XviD. Tutti i files così ottenuti, sono stati hintati mediante mp4creator, per ottenere files in formato mp4 interpretabili dal server Darwin.

 

V.6.1.2 Limitazioni della codifica

E bene però sottolineare che nella codifica si sono registrate delle incongruenze, dovute alle potenzialità limitate dei codificatori nel supporto di particolari configurazioni, che hanno inevitabilmente portato a falsare la maggior parte dei risultati conseguiti. In particolare, da una analisi effettuata mediante il tool di MPEG4IP mp4info, entrambi, hanno dimostrato di supportare bene tutti i nove casi a dimensione quadro QCIF, quindi variando velocità e frame rate, mentre al quadruplicamento delle dimensioni del quadro, da QCIF a CIF, si sono registrati primi cenni di cedimento della codifica; così ad esempio, per ffmpeg con 10 fps la velocità minima che si è potuto ottenere è stata 179 kbps, in luogo dei 30 desiderati, come del resto per mp4live, dove si è raggiunta una soglia minima di 140 kbps.

Ma la caratteristica più distruttiva, lha mostrata mp4live, poiché, con detta dimensione, ha dimostrato di supportare frame rate non superiori ai 20 fps, creando quindi enormi problemi in fase di valutazione delle analisi.

Aumentando la dimensione ancora, passando da CIF a VGA, le limitazioni mostrate dai precedenti casi, si sono amplificate ulteriormente, rendendo praticamente inutilizzabili detti files per la ricerca; in particolare, mp4live, ha mostrato un totale rigetto alle forzature imposte dai parametri scelti, così per frame rate 4 fps, la soglia minima di bit rate riscontrata è stata 174 kbps, per 10 fps 283 kbps (codificati però a 8.8 fps effettivi) e per frame rate richiesto a 25 fps, un bit rate 192 kbps a 4.61 fps! Ffmpeg, invece, ha dimostrato di subire limitazioni meno stringenti di mp4live poiché in tutti i casi si è mantenuto il frame rate voluto.

 

V.6.1.3 Catalogazione dei risultati

Comunque, una volta ottenuti tutti i media (27 per ffmpeg + 27 per mp4live), si è proceduto a trasmetterli tramite Darwin verso lhost comel, dove mediante gmp4player si è provveduto a riceverli; contemporaneamente sono stati catturati i pacchetti in transito, mediante tcpdump con i metodi descritti in precedenza, in particolare facendo cura a decodificare gli headers del RTP, in modo da evidenziare la successione dei mark bit.

Successivamente, dopo aver esportato tutti i files di statistiche su genni, è iniziata una minuziosa opera di catalogazione dei risultati conseguiti con il programma octave, con lausilio dellalgoritmo udpstatmio.m di cui si è già discusso. In particolare per tutti i 54 files, si sono ottenute le seguenti informazioni:

Oltre ai suddetti dati numerici si sono ottenuti una serie di grafici molto esplicativi sulla distribuzione delle dimensioni dei pacchetti e dei frames, sulla distribuzione dei tempi di interarrivo dei pacchetti e sulla autocorrelazione dei vettori delle dimensioni dei frames.

Per quel che riguarda la dimensione dei pacchetti, si è riscontrata una chiara differenza tra i due codecs, anche se non è stato possibile individuare un trend effettivo tra i due comportamenti dato un continuo susseguirsi di fluttuazioni reciproche dovute in particolare alle limitazioni nella codifica vista in precedenza. Nel numero dei frames invece, i valori ottenuti sono stati nella maggior parte dei casi confrontabili, anche se, ffmpeg ha dimostrato di essere più consistente del mp4live, dato che al variare della dimensione quadro e bit rate si sono registrati gli stessi numeri di frames, tranne per il caso VGA, dove ci sono state delle lievi differenze; per mp4live invece, il numero dei frames letti si è rivelato fluttuante, lasciando presagire una non chiara suddivisione della sequenza nei frames.

Tutti valori numerici ottenuti, comunque, sono serviti per la costruzione delle figure C.1, C.2, C.3, C.4, C.5, C.6, C.7, C.8, C.9, C.10, mostrate in appendice C, dove si sono messe in evidenza le seguenti caratteristiche:

 

V.6.1.4 Valutazione dei risultati

V.6.1.4.1 Byte/Frame medio

Naturalmente, gli andamenti visualizzati sono quelli sperati, dato che, come detto, per fissato bit rate, allaumentare del frame rate cè una diminuzione del numero di byte e quindi di pacchetti per frame e per fissato frame rate, un aumento del bitrate comporta un aumento del numero medio di byte e pacchetti per frame.

Nellosservare le differenze tra i tre quadri (ffmpeg), si registra un sostanziale avvicinamento delle curve a bitrate 30 e 150 kbps, dovute sostanzialmente allinesattezza delle codifiche, come si è cercato di evidenziare nelle tabelle in cui sono mostrati i valori relativi alle codifiche non esatte.

Il caso QCIF, il più attendibile dei tre, mostra distintamente una caratteristica molto interessante, ossia una pendenza diversa per le tre curve, motivata comunque da una corretta proporzionalità, dato il quadruplicamento delle prestazioni al variare del frame rate o del bit rate. Inoltre allaumentare della dimensione del quadro cè un aumento proporzionale del numero medio di byte per frame. Gli stessi andamenti sono osservabili chiaramente con i risultati della codifica XviD di mp4live, di cui però si sono considerati solo i casi QCIF e CIF. Nel confronto tra i due codecs, si nota come mp4live mostri la tendenza a codificare utilizzando più byte per frame, come si evince in particolare nella differenza tra picchi a bit rate 750 kbps.

V.6.1.4.2 Pacchetti/Frame medio

Per quel che concerne il numero medio di pacchetti per frame, si sono riscontrate le stesse mutue relazioni del caso precedente, sia tra stesso codec al variare della dimensione del quadro, del bit rate e del frame rate, sia tra il DivX ed il XviD, con una tendenza comunque da parte di questultimo a necessitare mediamente di più pacchetti per frame.

Dallanalisi dei due contesti, si è potuto constatare quindi che a parità di sequenze, quindi stessi contenuti dei frames, il codificatore mp4live occupa mediamente più spazio, poiché esso utilizza mediamente più pacchetti e quindi più byte per frame di ffmpeg, a parità di frame rate, dimensione quadro e naturalmente di durata del clip.

V.6.1.4.3 Autocorrelazione e GOP

Successivamente, dopo aver tratto tali conclusioni, si è deciso di studiare in maniera più approfondita le differenze nei due tipi di codifica, cercando di determinare, innanzitutto, le dimensioni dei GOP in entrambi i casi. Si è passati allora alla valutazione degli andamenti delle autocorrelazioni dei media a stessi parametri ma con codifiche diverse mediante lutilizzo di octave e dellalgoritmo implementato. Sono emersi così dettagli molto significativi ed assolutamente inattesi.

Prendendo infatti alcuni media campioni, per entrambe le codifiche, confrontando i due andamenti si sono evidenziate notevoli differenze, come viene mostrato nelle figure C.11 e C.12, raffiguranti le due autocorrelazioni per media con parametri QCIF/25/150.

Per la codifica XviD di mp4live, si è riscontrato una totale mancanza di correlazione tra i vari frames, lasciando intuire una distribuzione della dimensione dei GOP molto casuale, quindi assolutamente imprevedibile.

Evidentemente, il codificatore adatta la lunghezza di ciascun GOP in funzione della scena, verso cui mostra maggiore sensibilità; nel momento in cui i vettori del movimento lasciano presagire brusche variazioni nel quadro, esempio cambi di scena, si inserisce un frame I, in modo da minimizzare quanto più è possibile la qualità dellimmagine, ma comportando così un minore di livello di compressione che si ripercuote sulle dimensioni più grandi del media, come già verificato in precedenza.

Del resto, comunque, è abbastanza sensibile la differenza di qualità oggettiva percepita nella visione di un filmato codificato con ffmpeg e di uno con mp4live. Nellautocorrelazione di ffmpeg, invece si nota un andamento più simile a quello sperato, in cui sono messi in evidenza i picchi dovuti ai frames I e le fluttuazione intermedie dovute però ai soli frame P, poiché se nel GOP ci fossero dei frames B, landamento dovrebbe essere a zig-zag, poiché si passa da frames più grandi (P) a due frames più piccoli (B), per poi risalire al P e così via.

Quindi, se da un lato contando le spezzate tra due picchi si è potuto constatare che il GOP ha una lunghezza media tutto sommato deterministica, da unaltro non si è potuto implementare alcun meccanismo di controllo delle statistiche dei frames di tipo I e di tipo P, dato comunque la variabilità, seppur come visto non eccessiva, di detta caratteristica.

Inoltre, per ffmpeg, si è riusciti almeno ad avere conferma della mancanza di frames B, nella codifica, come si può anche pensare nel caso di mp4live, manifestando quindi la predilezione ad ottenere una leggera complessità di codifica a scapito di un basso livello di compressione del media. Del resto, il dover utilizzare i suddetti codificatori su computer comunque eterogenei tra loro, ha spinto giustamente gli sviluppatori del software verso detta scelta, in modo da alleggerire anche il carico della CPU.

 

V.6.2 Codifica FFMPEG-DivX

Si è visto come le sequenze video codificate con il tool ffmpeg, abbiano mostrato delle caratteristiche più interessanti nellambito dello studio della distribuzione statistica dei frames. Purtroppo però con i dati catturati dal tcpdump, non è possibile risalire direttamente al tipo di frame, poiché la dimensione del GOP non è fissata, quindi, basandosi sui soli mark bit, senza conoscere in alcun modo la precisa periodicità dei frames, non si riesce ad ottenere le stime volute.

V.6.2.1 Files di statistiche

Fortunatamente, ffmpeg ha la possibilità durante la codifica di creare dei files di statistiche, in cui è elencata la successione dei frames, facendo riferimento anche al tipo di frame in questione. Con un listato del genere allora, mediante lalgoritmo udpstatgop creato apposta per lobiettivo, si è riuscito ad ottenere una successiva informazione, ossia la distribuzione della dimensione dei GOPs.

 

V.6.2.2 Distribuzione del GOP al variare del FR

Per un analisi consistente, si è reputato di partire ovviamente dai soli 27 files ottenuti da ffmpeg (poiché con quelli ottenuti da mp4live, non si può lavorare per la mancanza di statistiche iniziali), scegliendone alcuni significativi; in particolare si è preferito analizzare landamento dei frames e dei GOPs per una stessa sequenza a fissato bit rate e a frame rate variabile, in modo da poterne esaltare le differenze nellautocorrelazione e quindi nella distribuzione dei GOPs. Si è quindi optato per tre media con i seguenti parametri:

Si parta dallanalisi delle tre autocorrelazioni mostrate nelle figure C.13, C.14, C.15.

Quello che si può evincere è un progressivo aumento di pseudoperiodicità dellandamento poiché, per frame rate molto basso, 4fps, il contenuto dei frames è maggiormente dipendente dalla sequenza in atto rispetto al caso con 25 fps, poiché, a parità di tempo, le immagini saranno minori, quindi il codificatore predilige lutilizzo di frame I almeno per riuscire ad ottenere una soddisfacente qualità per quadro riprodotto, rinunciando in questo modo a una codifica più semplice, basandosi su di un fissato GOP predominante.

Del resto, è facile intuire che dividendo lintervallo temporale di riferimento (1 secondo) in quattro intervalli (gli istanti tra i 4 frames successivi in 1 secondo), a parità di durata del media, le immagini saranno di sicuro più scorrelate tra loro, perché prese a ditanza maggiore le une dalle altre.

Allaumentare del frame rate, invece, poiché nellunità di tempo ci saranno più immagini, il codificatore si potrà basare su una sequenza di GOP, sempre più a distribuzione fissa, con delle eccezioni però caratterizzate dalla codifica forzata di un frame I o addirittura da un burst di frame I, quando, naturalmente, la scena cambi istantaneamente facendo quindi optare per una codifica effettiva dellimmagine piuttosto che di una sua predizione.

Si è supposta allora la presenza di un meccanismo di controllo a soglia innestata a monte della misurazione dei vettori del movimento; qualora, infatti, la scena del quadro corrente sia completamente diversa da quella precedente, è ovvio che i vettori del movimento saranno completamente sballati, quindi si preferirà rinunciare alla trasmissione dei vettori e quindi dellerrore di predizione, entrambi custodi dellinformazione relativa ad un frame P, per utilizzare invece un frame I.

Tutto ciò, può essere ulteriormente confermato osservando le diverse distribuzioni delle dimensioni dei GOPs raffigurate nelle figure C.16, C.17, C.18, dove si evince chiaramente la tendenza allaumentare del frame rate alla predilezione per un GOP di lunghezza 12.

Si è preferito inoltre visualizzare in figura C.19, landamento delle dimensioni dei GOPs, nel caso CIF/4/750, dove si nota maggiormente lutilizzo di burst di frame I, dovute eventualmente in quei precisi istanti, a cambi repentini di scena.

Da evidenziare che, naturalmente, per i tre casi analizzati, si sono riscontrati diversi numeri di GOPs, partendo dai 146 per il CIF/4/750, passando per i 166 per il CIF/10/750 e arrivando ai 303 per CIF/25/750, come ci si aspettava dato che cè un aumento del numero dei frames nella sequenza.

Quello che si vuol comunque sottolineare è che le caratteristiche qui evidenziate in fondo sono testimonianza della bontà del codificatore in analisi.

In generale, infatti, nella letteratura sul MPEG-4, non si è mai fatto riferimento alla modifica adattativa del GOP, il quale sarebbe dovuto essere vincolato nelle dimensioni iniziali, ripetute per tutta la durata della codifica, rispettando un range tipico tra 3 frames e 12 frames; lo studio di risultati conseguiti in altri ambiti di ricerca [8], conferma quanto detto, ossia la tendenza da parte della implementazione ISO MPEG-4 a consigliare oltre che ad utilizzare direttamente (con il codificatore ISO MOMUSYS MPEG-4) di un GOP standard e fissato, riuscendo così ad ottenere una ottima compressione a scapito però di una più bassa qualità delle immagini rispetto al codificatore ffmpeg.

 

V.6.2.3 Distribuzione del GOP al variare del BR

Successivamente allanalisi dei media citati in precedenza, si è reputato interessante anche analizzare altri 3 media, mantenendo questa volta fisso il frame rate e modificando quindi il bit rate. Si è preferito considerare una diversa dimensione del quadro per permettere anche una analisi comparativa tra quadri diversi. Gli andamenti delle tre correlazioni sono mostrati nelle figure C.20, C.21, C.22.

Si possono fare due osservazioni predominanti: allaumentare del bit rate, si assiste ad un andamento più marcato dellautocorrelazione, che si può spiegare pensando che un tale aumento comporta il disporre di più byte per la codifica del singolo frame, quindi, la periodicità del GOP diventa sempre più deterministica, poiché a parità di cambio repentino dei movimenti in quadri limitrofi, si riesce comunque meglio a codificare nei vettori del movimento tale informazione, senza dover ricorrere allimpiego di un altro frame I, modificando quindi la periodicità del GOP.

 

V.6.2.4 Distribuzione del GOP al variare della DQ

La seconda osservazione, invece, riguarda il confronto a parità di frame rate e bit rate (25 fps, 750 kbps), tra quadri a dimensioni diverse (CIF vs QCIF), che evidenzia un palese miglioramento nella periodicità del GOP, al diminuire dellarea dellimmagine, passando quindi da CIF a QCIF. Le motivazioni di una tale differenza sono da individuarsi nelle stesse citate in precedenza; così, per un fissato frame rate, il poter contare su una area di scansione più piccola, aumenta la risoluzione in byte di ciascun frame a parità di bit rate, rendendo di fatto la codifica più robusta ad un cambio di scena, evitando di dover necessariamente rinunciare alla predizione, poiché si ha più capacità per gestire linformazione necessaria alla codifica di un frame P.

Da mettere in evidenza infine, che in questultimo caso si è riscontrato un numero di GOP pari a 268, quindi minore dei 303 necessari per la codifica del caso CIF, come ci si aspettava, dato che naturalmente, il numero dei frames I è minore per quanto detto in precedenza.

 

V.6.3 Helix vs Darwin

Lultima tornata di tests effettuati per la conclusione della tesi, ha riguardato lanalisi comparativa dei servers Helix e Darwin, largamente utilizzati nel lavoro svolto. Si è preferito procedere in questo modo. Prima di tutto con uno stesso file, quindi stessa sequenza, bit rate , frame rate e dimensione quadro (QCIF/25/150 ottenuto da ffmpeg) si sono volute mettere in evidenza le eventuali differenze tra i due servers nella gestione delle dimensioni dei pacchetti, dei tempi di interarrivo e quindi del throughput.

 

V.6.3.1 Dimensione dei pacchetti

Non si sono riscontrate differenze nelle dimensioni dei pacchetti, dato che le rispettive distribuzioni sono del tutto comparabili.

 

V.6.3.2 Distribuzione dei tempi di interarrivo

Ciò che invece ha destato più attenzione è stato lanalisi delle distribuzione dei tempi di interarrivo (praticamente coincidenti con quelli di interpartenza), in cui si sono rivelate le principali differenze.

V.6.3.2.1 Caso A: richieste da un solo client

Helix ha mostrato una maggiore reattività media alla distribuzione dei pacchetti, inviando la maggior parte di essi, circa 2800 a distanza di 40 ms gli uni dagli altri ed i rimanenti con tempi di interpartenza confinati nei 10 ms. Il tutto lascia quindi intuire una predilizione da parte del server ad una distribuzione dei pacchetti in maniera omogenea e ben distanziata, come si può intuire da figura C.29, in cui vengono mostrati i tempi di interarrivo di 100 pacchetti, per semplicità di veduta. Da notare come il server invii praticamente sempre, salvo rare occasioni, un pacchetto ogni 40 ms.

Darwin, invece, ha distribuito 1300 pacchetti a distanza 80 ms tra essi, quindi con tempi di interarrivo maggiori rispetto a quelli di Helix, ma compensando il tutto con un invio a burst di 1800 pacchetti a distanza 10 ms gli uni dagli altri. Da figura C.30, mostrante i tempi di interarrivo di 100 pacchetti da Darwin, si può notare come il server, prediliga un invio a burst spedendo 2,3oanche 4 pacchetti alla volta per poi ritardare linvio della raffica successiva a 80 ms.

V.6.3.2.2 Caso B: richieste da più clients contemporaneamente

Successivamente, per enfatizzare i comportamenti dei due servers, ci si è orientati verso lo studio della seguente situazione operativa: il caso in cui i due servers debbano gestire la distribuzione contemporanea di uno stesso media a tre clients distinti, per evidenziarne le sicure differenze nella distribuzione dei tempi di interarrivo. Naturalmente i risultati ottenuti sono molto diversi per i due clients.

Con Helix, infatti, si è registrato un appiattimento della distribuzione, ossia si è passato dallavere due soli principali tempi di interarrivo (10 ms / 40 ms) a più tempi distinti; quindi per 200 pacchetti si è avuto un tempo di interarrivo di 10 ms, per 150 di essi un tempo 20 ms, per 850 un tempo di 30 ms, etc. fino ad arrivare ad un tempo massimo di interarrivo pari a circa 70 ms.

In figura C.31, si evidenzia la variazione di distribuzione dei pacchetti rispetto al caso di un solo client (si può confrontare la distribuzione di figura C.29) da cui però si può notare comunque tutto sommato il mantenimento di una discreta "distanza" tra invii di pacchetti successivi. Quindi le due distribuzioni sono comunque molto simili.

Darwin invece, ha continuato a mantenere una distribuzione con due tempi predominanti, con punte però ora di 120 ms, passando quindi a spedire a raffica più pacchetti rispetto al caso precedente (da 1900 a 2400) e ritardando la inter-distribuzione dei rimanenti (circa 800) a 120 ms gli uni dagli altri.

Dal confronto di figura C.32 con figura C.30, si può notare come sia aumentato il burst rispetto al caso precedente, poiché ora il server invia raffiche di 3,4 e 5 pacchetti anche se ogni 120 ms.

V.6.3.3 Valutazione del throughput

V.6.3.3.1 Caso A: richieste da un solo client

Per completezza di analisi, allora si è deciso di studiare gli andamenti del throughput, mediante lalgoritmo udpstatmio, citato in precedenza. Quindi, come prima analisi, basandosi sui tracciati dei pacchetti ottenuti con tcpdump e già utilizzati per le statistiche appena descritte, si è deciso di scegliere come finestra temporale un DT pari al valore del frame rate (1/25 = 40 ms); si sono così ottenuti gli andamenti mostrati nelle figure C.23 e C.24.

La differenza sostanziale tra i due, si evince dal fatto che, Helix mantiene, tranne che per un periodo iniziale, un throughput sempre al di sopra dello 0, quindi non così fluttuante come quello per Darwin, dove invece si è riscontrato un continuo azzeramento del bit rate istantaneo.

Le motivazioni sono ovvie, ricordando lo studio dei tempi di inter arrivo.

Helix infatti, ha tempo massimo di interarrivo pari proprio a 40 ms, si nota allora che nei primi istanti si trasmissione, il server trasmette un po più lentamente, prediligendo quindi una inter partenza di 0.04 secondi, che naturalmente cadendo in un intervallo di durata simile, porta alla registrazione di pochi, se non addirittura nessun byte. Successivamente, Helix sembra spedire un po più rapidamente i pacchetti per fissato intervallo di osservazione.

Darwin, invece, poiché come visto spedisce ben 1800 pacchetti con un tempo di interarrivo pari a 80 ms, quindi doppio dellintervallo di osservazione, mostra un aspettato andamento fluttuante tra 0 byte al secondo e punte massime variabili, funzione naturalmente della distribuzione dei frames I, che come detto, necessitano di più banda. Da evidenziare che comunque, in entrambi i casi, il valore medio dei Byte/secondo inviati istantaneamente è pari a circa 19000 B/s, quindi ritrovando il valore scelto per la codifica, 19000 X 8 = 152 kbps.

Per poter meglio evidenziare le differenze tra i due andamenti, si riporta nelle figure C.25 e C.26, il throughput relativo al traffico dei due servers, mediato però sui pacchetti compresi tra il 100 ed il 500.

Inoltre, si è reputato opportuno, mostrare nelle figure C.27 e C.28, leffetto di una scelta diversa del DT utilizzato, rispettivamente considerando un DT uguale ad 1/10 di frame rate (1/10 X 1/25 = 4ms) e ad un DT uguale a 10 volte il frame rate (10 X 1/25 = 400 ms). Naturalmente, si evince la differenza tra le due scelte poiché nel primo caso, si mette meglio in risalto loscillazione dei byte trasmessi, quindi si aumenta la risoluzione per i pacchetti, mentre considerando una finestra più ampia, si può meglio discriminare landamento medio del bit rate.

V.6.3.3.2 Caso B: richieste da più clients contemporaneamente

Detto questo, si è proceduto allo studio dei tracciati relativi al caso di contemporanea distribuzione di uno stesso media verso tre clients distinti. In questo contesto si è confermato per Helix quanto visto per i tempi di interarrivo, ossia tutto sommato, gli andamenti sono molto simili in termini di picchi e valor medio, differendo solo per gli istanti in cui il bit rate è sceso a circa 0, dato che, come si è visto, i tempi di interarrivo si sono distribuiti diversamente dal caso precedente entro un range tra 10 ms e 70 ms. Ciò ha permesso di intuire che Helix, per mantenere tutto sommato gli stessi tempi di interarrivo, deve chiaramente aumentare il proprio throughput istantaneo totale, poiché a parità di tempo garantisce lo stesso throuhput per i 3 clients e nel far ciò, preferisce distribuire i pacchetti in maniera abbastanza omogenea tra i vari clients, dato che i tempi di interarrivo sono comunque confrontabili.

Per Darwin, gli andamenti valutati considerando tutti i pacchetti, non hanno permesso più di tanto una corretta valutazione, se non intuire che i due profili sono rimasti praticamente invariati, così, si è deciso di "fotografare" il throughput relativo soltanto ai pacchetti compresi tra il 100 ed il 500. Quello che si è notato è stato un incremento abbastanza distribuito del bit rate istantaneo, valutato studiando la maggiorazione del bit rate tra picchi omologhi, alternati a maggiori diminuzioni, quindi più istanti con basso bit rate istantaneo.

Il server aspetta più tempo per linvio di una successiva raffica di più pacchetti, da cui landamento più frastagliato del throughput come si può evincere dal confronto di figura. C.33 con figura C.34 mostranti appunto il throughput di Darwin per i casi A e B. Infatti, la tendenza a distribuire più pacchetti a burst ogni 10 ms, compensati da altri pacchetti con ritardi di 120 ms, evidenzia la caratteristica di trasmettere a parità di clients più pacchetti ravvicinati, per poi attendere 40 ms in più rispetto al caso precedente (120 ms 80 ms) per permettere evidentemente la distribuzione dei dati anche per gli altri clients.

Quindi, se il carico elaborativo è tutto sommato lo stesso per i due servers, la distribuzione è diversa poiché Darwin tenderà a inviare per ciascun client una raffica di pacchetti e quindi di byte, per poi dedicarsi ad una successiva raffica di bit ma verso un altro client.

 

V.6.3.4 Caratteristiche di trasmissione in regime di banda limitata

Sfruttando la semplicità di configurazione del server Darwin via web, si è reputato interessante introdurre delle limitazioni alla banda sostenibile del server. Tutte le prove fino ad ora svolte infatti, sono state effettuate con una limitazione di throughput del server a 100 Mbps, quindi tale da poter giustificare le prove a clients multipli. Limitando allora il throughput a 200 kbps, si è notato che Darwin, piuttosto che rallentare il bit rate istantaneo per ciascun client, permettendo comunque larrivo dei 3 flussi che chiaramente avrebbero necessitato di una corretta bufferizzazione in lato client, lascia partire solo due delle tre (al client la cui richiesta RTSP arriva per ultima, il server risponde con un 450 Not Enough Bandwidth), per poi praticamente interrompere linvio dei dati verso uno dei due, il client arrivato dopo tra i due

. Quindi dimostra una tendenza a servire correttamente un solo client dei tre da cui è pervenuta la richiesta e per quel client, lanalisi dellandamento del throughput ha evidenziato le stesse caratteristiche viste nel caso generale a 100 Mbps.

Con una limitazione invece a 1000 kbps, il server riesce a fornire i dati necessari per la riproduzione a due clients su tre, dato che allultimo arrivato, risponde con il solito codice di stato 450. Analizzando gli andamenti di uno dei due throughputs, si evince quello che ci si aspettava, ossia una diminuzione dei picchi ad alto bit rate, poiché nello stesso intervallo di osservazione, il server dovrà distribuire i pacchetti tra i due clients in maniera altalenante; ciò significa, in parole semplici, che ora potranno capitare degli intervalli dove vengono trasmessi meno bit, poiché nello stesso frangente, Darwin sta trasmettendo pacchetti verso laltro client.

Con un incremento finale a 2000 kbps, si è riusciti infine ad erogare nel migliore dei modi il media a tutti e tre i clients.

 

V.7 Conclusioni

Di sicuro il primo dato da sottolineare è lessere riusciti tutto sommato ad implementare un architettura di streaming, che come dimostrato nel presente e nel precedente capitolo, ha mostrato una corretta funzionalità ed efficienza basandosi in particolare sui servers Helix e Darwin.

Ciò, ha permesso di realizzare in un successivo step, il sistema di TV-on-Demand a lungo descritto in precedenza, con la cui valutazione di robustezza ed efficienza, si è voluto anche dimostrare come con semplici risorse a disposizione, si sia riusciti a trovare un modo di sicuro molto economico, per la distribuzione del segnale televisivo basandosi sulla Internet esistente.

Con linsieme dei due streaming servers a disposizione, si è poi riusciti ad evidenziarne le caratteristiche principali e quindi anche e soprattutto le mutue differenze, mediante un attento studio del comportamento in trasmissione, che ha permesso tra laltro di individuare anche delle limitazioni non note dei servers in questione.

Inoltre, basandosi sulle loro funzionalità, si è effettuata unanalisi abbastanza esaustiva degli aspetti legati alla codifica multimediale. Si sono potuti così evidenziare le differenze tra codecs multimediali implementanti la stessa codifica, in particolare tra il DivX ed il XviD, entrambi i quali rappresentano oramai una grossa fetta dellinteresse globale di applicazioni in rete, oltre che naturalmente ad enfatizzare in definitiva, molte delle caratteristiche dellintera codifica MPEG-4, che, possono essere comunque considerate un buon punto di partenza per lo sviluppo del codec stesso, in particolare nel tentativo, oramai prossimo, di implementare correttamente detto codec anche nella video telefonia.

Infine, si vuol sottolineare laver realizzato degli strumenti di calcolo statistico molto semplici ma al tempo stesso molto validi, che, seguendo la filosofia generale dellopen-source, possano essere in seguito utilizzati o meglio arricchiti di funzionalità, da chiunque voglia analizzare i contenuti multimediali di un traffico RTP, contribuendo di fatto al potenziamento dei codecs esistenti oltre che naturalmente allo sviluppo di nuovi di essi che siano sempre più efficienti e legati alle esigenze attuali.