Capitolo IV Architettura di streaming

IV.1 Introduzione

Lo scopo del presente capitolo, è quello di evidenziare gli studi, le scelte e le operazioni atte alla costruzione, presso il "laboratorio telematico", di un architettura di streaming che fosse chiaramente funzionante, funzionale e completa sotto tutti gli aspetti, il tutto, naturalmente, al puro scopo di ricerca. Nei precedenti capitoli si sono messi in evidenza oltre alla scelta di lavorare nellambito della interattività multimediale, due principali aspetti di base per la comprensione degli argomenti che qui di seguito verranno trattati; si è relazionato sugli aspetti protocollari, in cui si è posta particolare enfasi sul protocollo di streaming utilizzato, il RTSP e sui principali contenuti delle entità che andremo a trasmettere in rete durante una sessione di streaming, quindi dati multimediali caratterizzati ciascuno di essi da profonde differenze dettate dai diversi codecs e formati utilizzati nella loro implementazione. Costruire una architettura di streaming significa essenzialmente dotare il computer di lavoro (si chiamerà genni tale macchina) di servers RTSP, renderli operativi, determinare player/client che potessero lavorare in ambiente RTSP e testare quindi la funzionalità delle applicazioni in uso, facendole interagire tra loro secondo un comune paradigma di comunicazione client-server. A tale scopo, si è utilizzato anche un altro computer del laboratorio, comel, per permettere di poter meglio gestire la comunicazione tra due macchine remote. Il lavoro si è concluso come vedremo, con la realizzazione di una pagina web di prova, con la quale si è ottenuta una interfaccia grafica necessaria non tanto a "pubblicizzare" le risorse mediatiche presenti sui servers utilizzati, quanto a gestirne meglio lo streaming da varie piattaforme, non solo quelle del laboratorio, allo scopo di valutarne globalmente le prestazioni di funzionamento. Il lavoro successivo è nato da una idea che si inseguiva da tempo: un comune utente della Internet, infatti, si imbatte spesso in siti web da cui, con lausilio di opportuni players, poter ascoltare canzoni da emittenti radiofoniche trasmettenti di fatto anche sulla rete. Ci si è chiesto allora, per prima cosa di capire come ciò potesse avvenire, per poter tentare poi di trasmettere in rete il segnale di emittenti televisive nazionali, quindi questa volta immagini e suoni catturati eventualmente da una scheda TV. E bene precisare in questa sede che, pur a conoscenza delle enormi e del tutto giustificate restrizioni legali per tali applicazioni, dovute ai contratti di trasmissione e soprattutto alla questione spinosa delle licenze e concessioni governative per la trasmissione di eventi su territorio nazionale e estero, lo scopo principale del lavoro è stato unicamente finalizzato a motivi di studio e di ricerca in ambito streaming.

Il punto di partenza è stato allora la ricerca di applicazioni client e server che supportassero in ambito protocollare il real time streaming protocol, il real time transport protocol, il real time control protocol ed il session description protocol e che dessero prova di compatibilità nel maneggiare dati multimediali in quei formati file e codifiche audio-video descritte nel precedente capitolo. Il passo seguente è stato la valutazione delle prestazioni di ognuno di essi, mediante prove incrociate di funzionamento, allo scopo di determinare quali applicativi sarebbero diventati poi i principali attori dellarchitettura di streaming in questione. Da sottolineare, che per i fini preposti, si è dovuto necessariamente contare anche sullausilio di tools, quali codificatori, decodificatori, trasmettitori, in grado di creare le risorse che sarebbero state poi oggetto dello streaming.

Dopo aver valutato il corretto funzionamento delle risorse in questione, mediante tests i cui risultati sono descritti in seguito, si è dato inizio alla realizzazione del sistema di TV-on-demand, a cui si farà riferimento in chiusura di capitolo, mostrando lintero iter realizzativo e provando inoltre il corretto funzionamento dello stesso.

 

IV.2 Panoramica sulle applicazioni interattive di streaming

Nella fase di ricerca di applicativi per lo streaming in ambiente Linux, ci si è imbattuti in una serie di tools, ciascuno dei quali presenta in generale caratteristiche diverse dagli altri e quindi, naturalmente, anche prestazioni diverse.

IV.2.1 Clients

Per quel che concerne i players/clients, si sono riscontrati una serie di problemi legati non tanto allesistenza di tali softwares, che di fatto rappresentano nella loro totalità una risorsa corposa e completa in ambito multimediale, quanto al loro adeguato funzionamento e nel capire quindi, grazie a una molteplicità di tests effettuati, le proprie funzionalità e limitazioni. Ciò perché, in molti casi, si è riscontrato una carenza palese nella

documentazione e descrizione delle caratteristiche operative dei suddetti applicativi, da cui, lunico modo di vederci chiaro, è stato quello di cercare di decifrare il codice sorgente (là dove possibile per la natura open source di quel determinato tool!) e/o passare poi a prove di funzionamento. Da non sottovalutare, inoltre, il lavoro di ricerca delle librerie necessarie alla codifica e decodifica dei dati, necessarie in molti casi, per poter effettivamente avere a disposizione softwares consistenti ai fini dello streaming multimediale. I risultati della ricerca sono evidenziati in tabella IV.1, dove è possibile individuare i vari applicativi testati, relativamente ai quali si è preferito esaltarne alcune delle caratteristiche principali.

PLAYERS

MULTICAST

RTSP

RTP

RDT

H.261

MPEG-1/2

(MP3)

MPEG-4

REALPLAYER

SI (RDT)

NO (RTP)

SI***

SI

SI

NO

NO

(SI)

NO

MPEG4IP GMP4PLAYER

SI

SI***

SI

NO

NO

SI

SI

LIVE

OPENRTSP

SI

SI**

SI

NO

NO

SI

NO

POPCORN

XMMS

NO

SI*

NO

NO

NO

SI

(NO)

NO

KOM

CLIENT

NO

SI*

SI

NO

NO

SI

NO

MASH COLLABORATOR

SI

SI*

SI

NO

SI

NO

NO

MPLAYER

SI

SI***

SI

NO

NO

SI

SI

NO (RTSP)

 

Tabella IV.1 Implementazioni players/clients testate

A tal proposito si vuole ricordare che un buon player può essere valutato mettendo in evidenza essenzialmente tre funzionalità: il tipo di indirizzamento applicato, i protocolli implementati e i codecs supportati. Questultima caratteristica è forse la più delicata, dato che la qualità di un player è fortemente vincolata alla qualità del decodificatore su cui esso si basa ed essere quindi dotati di valide librerie per il supporto di molteplici sistemi di codifica, è indice di ottima qualità complessiva. Si è esaltato allora il supporto del multicast come modalità di indirizzamento (luso dellunicast viene dato per scontato) del RTSP, del RTP/RTCP e del Real Data Transport (RDT, sviluppato da Real Networks come protocollo di trasporto dei dati) come protocolli di controllo e trasferimento, e dei codecs MPEG-1/2, siano essi audio e video, e MPEG-4/DivX/XviD come codifiche multimediali dei media, ma anche del protocollo H.261 che, come detto, è essenzialmente utilizzato nella videoconferenza su Internet. Questultimo si è preferito comunque includerlo tra i codecs principali, per evidenziare la scarsa presenza di tool supportanti tale codifica e soprattutto per sottolineare la selettività delle applicazioni in questione che o nascono per fornire funzionalità alla multimedialità oppure alle comunicazioni interpersonali.

In tabella, per sintetizzare il supporto fornito da ciascun tool al RTSP, si è reputato significativo schematizzare il grado di funzionalità di ciascun player, individuando una scala di tre valori:

Si vuole anche sottolineare che, in alcuni casi, si è fatto riferimento non alla versione originale di ciascun player, ma alla stessa con laggiunta di librerie necessarie per il supporto del RTSP. E questo il caso di xmms-popcorn e di mplayer, entrambi con la necessità di aggiungere funzionalità per il supporto dello streaming protocol, come si può intuire da tabella, con esiti sicuramente diversi. Dai test di funzionamento infatti, xmms ha evidenziato grosse limitazioni dovute innanzitutto alla carenza di supporto al RTP come protocollo di trasferimento dei dati che lo rende di fatto isolato rispetto alla maggioranza dei servers; nella richiesta di SETUP infatti, chiede di poter utilizzare uno stream di tipo "RAW/UDP", che invece nessun server in circolazione supporta. Di conseguenza, la risposta al SETUP sarà sempre un 400 Bad Request. Altro problema riguarda la mancanza di possibilità nel contattare server rispondenti non alla porta di default 554, ma su altre porte, poiché non esiste alcun meccanismo in grado di leggere dalla URL la porta di comunicazione. Discorso simile per il client KOM, prodotto dalla TU Darmstadt con lintento di creare una propria architettura funzionante di streaming, ma che purtroppo non è in grado di portare a termine una sessione di trasferimento; i problemi sono da ricercare nel codice, il quale presenta molteplici bachi oltre alla mancanza assoluta di una corretta metodologia di comprensione delle descrizioni fornitegli dai servers che porta inevitabilmente alla morte del programma inaspettatamente durante la sessione.

Discorso a parte è il Collaborator del consorzio Open Mash [17], già citato nel capitolo I, nato con lintento di essere il (primo!!!) client RTSP per il supporto di codec H.261, ma che presenta una serie di problemi di difficile soluzione dato il criptico e soprattutto enciclopedico codice (17000 righe!). Si vuole poi sottolineare le caratteristiche di openRTSP di Live.com [16], ottimo client, che si è rivelato molto utile ai fini delle sperimentazioni dei servers data la sua semplicità ed efficienza, ma privo di una funzionalità importante, quale la possibilità di riprodurre direttamente i media. Esso infatti, lavorando come un semplice client, memorizza il flusso che gli arriva in uno o più files (se sono presenti streams per laudio e per il video), che possono poi essere riprodotti in un secondo momento con players canonici. Comunque, alla luce delle ovvie considerazioni che si possono evincere dalla lettura della tabella IV.1, si è preferito circoscrivere la scelta dei clients/players ai soli realplayer di Real Networks [18], al gmp4player del consorzio MPEG4IP [19] e al mplayer [20]con supporto del RTSP da librerie di Live.com. Essi, sono i tools che supportano meglio lo streaming protocol, oltre ad essere più affidabili nelle operazioni di trasferimento, ma che, naturalmente, presentano differenze tra di loro, anche limitazioni, che vanno a compensarsi a seconda dei casi. E proprio per questo motivo che si sono scelti tre clients diversi per il supporto dellarchitettura da costruire, dato che, al momento è impossibile trovare un client ottimo con tutte le funzionalità, ma anche per garantire più scelta e alternative per gli utenti in generale. Per i tre tools citati, si è preferito rimandarne una descrizione in seguito, in modo da esaltarne meglio loperatività e le caratteristiche.

 

IV.2.2 Servers

Contemporaneamente agli studi sopra citati, si è necessariamente avuto bisogno di estendere la ricerca anche verso quei servers in grado di gestire lo streaming e che, naturalmente, rappresentano lentità basilare e centrale di una architettura di streaming. Qui le cose però sono state di gran lunga più difficili, poiché non è stato facile trovare servers che quanto meno supportassero il RTSP; ciò è abbastanza comprensibile, se si considera lenorme diffusione dei servers web, che come detto negli scorsi capitoli, riescono, pur con forti limitazioni, a fare streaming multimediale mediante il protocollo HTTP. Inoltre un server RTSP è ben più complesso proprio perché deve dare luogo ad una sessione di streaming; dovrà essere in grado dunque di poter costruire una descrizione SDP della risorsa multimediale richiesta, quindi per tale scopo dovrà avere al suo interno un sistema di interpretazione dei codecs utilizzati per la codifica del media. Dovrà inoltre saper gestire il maggior numero di richieste da parte dei clients, anche quelle che richiedono maggior interazione come nel caso del metodo PAUSE, saper valutare la banda a sua disposizione nel tentativo di mantenere in vita più sessioni contemporaneamente, oltre naturalmente a trasmettere con opportuna pacchettizzazione, i dati usando possibilmente il protocollo di trasporto RTP. Ancora, dovrà riuscire a monitorare il traffico di rete mediante lausilio del RTCP e mostrare tendenze marcate verso una scalabilità e modularità di implementazione. Per alcuni dei servers testati, si sono evidenziate delle pesanti limitazioni in particolare dovute allo scarso supporto dei principali codecs multimediali, in particolare per il MPEG oltre che allincompletezza nei metodi da essi implementati. I risultati dei tests effettuati sono stati schematizzati in tabella IV.2, dove anche in questo caso, si è posta particolare enfasi alla tipologia di indirizzamento, ai protocolli e ai codecs supportati e dove si è usata la stessa scala di qualità nella valutazione del RTSP.

Servers

multicast

RTSP

RTP

RDT

H.261

MPEG-1/2

MPEG-4

APPLE

DARWIN

SI

SI***

SI

NO

NO

SI

HINTED

SI

HINTED

LIVE

SERVER

SI

SI**

SI

NO

NO

SI

NO

VOVIDA

SS

NO

SI**

SI

NO

NO

NO

NO

MASH

ROVER

SI

SI*

SI

NO

SI

NO

NO

FFMPEG

FFSERVER

SI

SI*

SI

NO

NO

SI

SI

REALNETWORKS

HELIX

SI

SI***

SI

SI

NO

SI

SI

Tabella IV.2 Implementazioni servers testate

Vediamo le caratteristiche di alcuni dei servers elencati in tabella. Il server di Live.com, in realtà nasce come streamer, ossia un tool che permette la trasmissione in round-robin di uno stesso file in codifica MPEG-1/2 audio-video, verso un indirizzo unicast o multicast. Gli si può far acquisire la funzionalità di server RTSP, mediante semplici modifiche nel codice sorgente, solo che in questo caso potrà lavorare solo in multicast e comunque non sarà in grado di dividere la funzionalità di server da quella di streamer; il server aspetterà sì una richiesta RTSP, ma contemporaneamente trasmetterà il media, utilizzando quindi banda inutile nello stato di wait. Altra pesante limitazione è il fatto che non è possibile scegliere le risorse tra un archivio di files, poiché ad essere richiesti e trasmessi saranno sempre i files di test, di cui, tra laltro, sono già costruite le descrizioni in formato SDP. Le caratteristiche sopra elencate, aggiunte alla totale incompatibilità con dati in codifica MPEG-4, hanno spinto a non poterlo considerare come una valida applicazione per i fini preposti, pur sottolineando, che lo stesso, nasce più come applicazione di test, aperta a qualsiasi modifica tesa a svilupparne le potenzialità, che come una full application.

Il server di Vovida [23], pur essendo lunico a non supportare il multicast, si è rivelato abbastanza valido nel suo funzionamento ed addirittura rappresenta lunica applicazione RTSP, in generale, in grado di supportare il metodo RECORD. Le sue limitazioni sono dovute al fatto che esso supporta solo media audio di formato wav o au/raw, manifestando quindi, la totale incapacità di gestire media video di qualsiasi natura, oltre che a risorse audio con codifica MPEG.

Il server del gruppo di ricerca FFMPEG [22], il FFserver, nonostante gli ottimi propositi iniziali, supportati dal fatto che è prodotto dagli stessi che hanno creato la libreria ffmpeg, tuttora forse la migliore per il supporto della codifica MPEG-4/DivX, ha mostrato tutte le sue limitazioni nel tentativo di farlo funzionare a dovere. Come citato dagli stessi sviluppatori, è tuttora in fase di sviluppo, e chiaramente si è reputato preferibile concentrarsi su alti applicativi. In tabella IV.2, si nota anche linclusione del server RTSP dellarchitettura Open Mash, il Mash Rover, anche in questo caso per voler forzatamente evidenziare lo stato di isolamento in cui tuttora si trovano applicativi supportanti la codifica H.261 in ambito streaming. Dalle considerazioni sopra citate e da un rapido sguardo alla tabella, si è preferito concentrarsi sui servers Helix, prodotto da Real Networks [18] e Darwin di Apple [21], i quali si sono rivelati in assoluto affidabili e completi. Di essi se ne è volutamente rimandare una completa descrizione in seguito, per meglio enfatizzarne le caratteristiche.

 

 

IV.3 Players-Clients

 

IV.3.1 RealPlayer

Questo lettore ha segnato un po una rivoluzione nel campo delle applicazioni multimediali; si è subito imposto nella comunità di utilizzatori come il player per eccellenza, data la sua enorme diffusione, dovuta in parte alla disponibilità gratuita delle versioni base ed al fatto che tuttora, il formato audio e video da esso principalmente supportato, il real media (anche nelle versioni realaudio e realvideo), rimane uno standard molto utilizzato ed efficiente, data soprattutto la qualità del media e in generale lottimo livello di compressione. E naturale infatti accostare il RealPlayer al formato real media, entrambi prodotti da RealNetworks con lintento di dotare lutenza di quegli elementi fondamentali per lo streaming. Da sottolineare che, nella versione per Linux testata, i files real media, smil ed mp3, sono gli unici a poter essere aperti. Ciò denota una sensibile carenza di librerie supportanti i codecs MPEG, rendendo di fatto il player non adatto per lo streaming di media in tali codifiche. E necessario allora trovare a tal fine, con molta difficoltà, librerie/plug-in da aggiungere nella configurazione del software, sebbene sia da sottolineare che il player non ha la licenza per riprodurre lMPEG-2. Rimane comunque il suo uso molto valido nella gestione dei files supportati direttamente, motivazione questa che ha spinto a tenerlo in considerazione, oltre naturalmente alla sua diffusione. Altro grosso problema, è la sua totale chiusura; non è un software open-source e come tale denota pesanti limitazioni. Una è proprio la mancanza di apertura alle librerie MPEG e di conseguenza allo sviluppo per renderne il software compatibile inoltre, ladozione di protocolli proprietari anchessi coperti da assoluta chiusura, ne limitano di fatto lapplicabilità per altri media tools; da sottovalutare poi la carenza di informazioni generali sul suo funzionamento e sulle caratteristiche.

Dai test effettuati, grazie allo sniffer "ethereal", si è potuto osservare e studiare i contenuti dei pacchetti RTSP, trasferiti durante le sessioni di streaming. Si é così potuto evincere, oltre alle caratteristiche sopra citate, anche altri dettagli che in seguito si andrà a citare. Per il supporto dello streaming, il player è fornito direttamente delle librerie necessarie alla gestione del RTSP di cui predilige il trasporto utilizzando il protocollo di livello inferiore TCP. A tal proposito è bene sottolineare che forse il vantaggio maggiore di utilizzare il tool come player remoto, sta nella vasta quantità di configurazioni che si possono settare prima e durante il trasferimento, riguardanti tra laltro il tipo di connessione da utilizzare, la gestione del buffer locale e del timeout di rete. Presenta inoltre, una pagina di visualizzazione delle statistiche sui pacchetti, che può rivelarsi molto utile nella valutazione delle prestazioni di trasferimento. In ambito RTSP, esso supporta i seguenti metodi: OPTIONS, DESCRIBE, ANNOUNCE, SETUP, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER, TEARDOWN, si può quindi ritenere completo ai fini della sessione di streaming.

Nella richiesta di DESCRIBE, invierà un informazione fondamentale ai fini della trasmissione, ossia la larghezza di banda stimata in bit/secondo a lato client, in modo da fornire al server già un primo strumento necessario alladattamento del flusso in uscita (naturalmente per quei servers che supportino detta funzionalità). Tale valore potrà naturalmente cambiare durante la connessione, ma rappresenta comunque un ottimo feedback iniziale. Una nota dolente del player è che predilige il trasporto dei dati utilizzando il Real Data Transport (RDT), protocollo di cui è proprietario, in luogo del più noto RTP, portando spesso, a problemi di comprensione per i servers remoti. Se nelle prime versioni, il RDT era lunico protocollo utilizzato, nelle ultime ad esso è stato accostato anche il RTP, necessario per garantire la compatibilità con la quasi totalità dei servers streaming in circolazione. Tramite ethereal, si è potuto evidenziare il tentativo del client in fase di SETUP, di ottenere una trasmissione in RDT; esso richiede infatti che il flusso dati avvenga in "x-real-rdt/udp", ma per fortuna, nella stessa stringa di richiesta, fornisce al server la possibilità di utilizzare anche il "rtp/avp", ma limitando tale possibilità al solo caso unicast. In multicast, infatti, esso richiede espressamente lutilizzo del RDT "x-real-rdt/mcast", creando allora pesanti problemi conflittuali con i servers multicast. Altra caratteristica interessante è che predilige linvio, come primo metodo, di un OPTIONS, mostrando così un ottima implementazione del protocollo RTSP. Ciò è importante, perché, dalla conoscenza dei metodi utilizzati dal server, può regolare le proprie richieste, evitando così la trasmissione di metodi non comprensibili. Infine, dallanalisi del pacchetto OPTIONS, si è notato inoltre che esso manda anche un header "ClientChallenge", necessario a RealPlayer per autenticare i servers a lui compatibili. E ovvio che un server prodotto da RealNetworks, riuscirà a esaudire la sfida del client, cosa impossibile invece per gli altri; tutto ciò ovviamente può creare dei problemi per quei servers non in grado di gestire una tale richiesta. La cosa più semplice sarebbe allora poter contare su un meccanismo capace di ignorarla, evitando così di rimanere impuntati.

Per concludere è bene sottolineare, laver notato un esasperato utilizzo del buffer di playout rispetto ad altri players, caratteristica questa che rende la riproduzione a volte un po fastidiosa, dovuto ai lunghi silenzi, specie quando si abbia a disposizione una banda limitata.

 

IV.3.2 Mplayer

MPlayer nasce come lettore, completamente open source, di filmati per Linux, distribuito sotto licenza GPL v.2. Di sicuro è il player più completo in circolazione, data lenorme quantità di codecs e formati, video e audio, da esso supportati [20]. La sua forza sta nellelasticità con cui può gestire una serie di librerie multimediali, tutte molto valide, che arricchiscono di fatto, le potenzialità di codifica e decodifica del player stesso. Il grande vantaggio, è allora paradossalmente laver sviluppato un software "incompleto", poiché, la grande maggioranza dei codecs, viene ereditata esternamente: in questo modo si è permesso quindi di non fossilizzare lo studio, tra laltro molto impegnativo, dello sviluppo delle risorse necessarie direttamente alla codifica e decodifica, ma viceversa impegnandosi a creare un applicativo molto stabile, completo ed efficace. Il tutto ha necessariamente portato a renderlo compatibile con praticamente tutti i media possibili, caratteristica questa non sottovalutabile. Esso legge la maggior parte dei file MPEG, VOB, AVI, OGG, VIVO, ASF/WMV, QT/MOV, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, con l'aiuto di molti codec nativi, di XAnim, di RealPlayer e di Win32. Si possono guardare VideoCD, SVCD, DVD, 3ivx, RealMedia, e film in DivX. L'altra importante caratteristica di mplayer è l'ampia scelta di driver e schede supportati per l'output.

Come è facile verificare, la stabilità e la qualità sono le caratteristiche più importanti, ma anche la velocità non è da sottovalutare. Da sottolineare che il tool è anche un grabber TV, ha quindi la possibilità di catturare immagini e suoni direttamente dalla scheda TV, per poi riprodurli nel formato desiderato; a tal proposito, si vuole ricordare che in "simbiosi" al mplayer, esiste un codificatore audio/video molto potente, il mencoder (mplayers movie encoder), in grado di sfruttare le librerie sopracitate per creare files multimediali in formato AVI, con codifica variabile, in grado di catturare e codificare live il segnale televisivo o anche un semplice CD o DVD.

In realtà, un dettaglio importante da conoscere, è che, nella sua versione base, mplayer è essenzialmente un lettore/riproduttore, non ha quindi alcuna funzionalità nel supporto dello streaming multimediale. Per venire incontro alle esigenze della ricerca, si è sfruttato proprio la sua caratteristica di modularità, installando con esso, le librerie RTSP, RTP, RTCP di Live.com; in particolare, si è fatto puntare mplayer in fase di configurazione, alle librerie "groupsock", aventi classi per la gestione dellinterfaccia di rete e dei sockets necessari al trasferimento e ricezione dei datagrammi, e a "liveMedia", contenente le classi per la gestione dei protocolli standard e tra cui sono presenti anche i sorgenti per le implementazioni dei clients RTP/RTSP. Inoltre è qui presente la definizione dei codecs e dei formati files utilizzabili ai fini dello streaming; si ricorda a tal proposito che un client, ha la necessità di saper gestire il tipo di media che esso richiede, dato che la stessa sessione ha senso solo se il client ha le capacità per capire i contenuti e quindi per poter riprodurre il media. Capire i contenuti significa naturalmente essere dotato di strumenti in grado di leggere la descrizione del file, tramite il SDP e allocare di conseguenza le risorse per il trasporto, con il RTP e per il controllo, tramite il RTSP. Purtroppo, proprio in questo ambito, è da evidenziare una grossa limitazione di mplayer: i codecs supportati da Live, sono infatti i soli MPEG-1, MPEG-2 (audio e video, quindi anche lmp3), PCM e H.263. Come si vede non cè traccia dei codecs MPEG4/DivX/XviD, portando di conseguenza mplayer ad essere fortemente limitato per lo streaming. Se infatti, come lettore locale è assolutamente eccelso data la quasi totalità di codecs e formati in grado di leggere, come client si può per ora, utilizzarlo solo per il trasferimento di media MPEG-1/2. Certo, entrambi i codec citati rappresentano tuttora una grossa fetta di standard multimediali ma, il rapido avvento del MPEG-4 ed in particolare delle sue versioni non ufficiali, il DivX e il XviD, amplifica detta mancanza. Qualora si volesse tentare di ricevere via RTSP un file in codifica MPEG-4 ad esempio, mplayer risponderebbe con:

Failed to initiate "video/MP4V-ES2 RTP subsession

RTP payload format unknown or not supported

a conferma della mancanza di librerie in grado di decodificare il tipo di payload in questione trasportato dal RTP.

Una corretta implementazione di una sessione di streaming con mplayer viene mostrata in appendice A.

Infine è da sottolineare che, avendo ottenuto dalle librerie Live le giuste funzionalità di streaming, da esse ne eredita anche altri limiti, tra cui la mancanza del metodo PAUSE che, in fase di riproduzione, potrebbe sempre essere utile. Comunque, è bene accontentarsi di un prodotto che funziona veramente e che, quanto meno, ha dato la possibilità di gestire il trasferimento di media MPEG-1/2, incrementando le potenzialità dellarchitettura di streaming in costruzione. Fatta una panoramica su alcune caratteristiche, si vuole senza scendere nei dettagli implementativi, citare quali sono state le librerie utilizzate in laboratorio per i fini preposti alla realizzazione della tesi e che si sono installate in fase di configurazione di mplayer. Di sicuro la libreria "libavcodec" di ffmpeg è stata la più importante, poiché con essa si è ottenuta un DivX opensource, compatibile con il tradizionale DivX, permettendo la visione di filmati in codifica MPEG-4, oltre ai codecs MJPEG, H.263 e RealVideo 1.0, con il quale si riesce a vedere filmati senza la necessità di utilizzare i tools delluniverso Real. I codecs RealVideo 2.0 e 3.0 si sono resi disponibili direttamente dalla directory "codec" nel path di RealPlayer. Per quel che concerne lMPEG-4, si sarebbero potuto utilizzare le librerie DivX4/DivX5 di ProjectMayo, in particolare il DivX4Linux, versione semi open del classico DivX, ma il poter contare su un codec più veloce, ha spinto ad optare per il DivX di ffmpeg. Altra novità assoluta riguarda la possibilità di poter gestire codecs Microsoft, mediante la libreria win32, con la quale si superano anche le barriere dettate dalla diversità di piattaforma utilizzata. Per laudio invece, avendo già a disposizione il codice nativo per lMPEG layer 2 e layer 3, si è reputato importante dotare mplayer anche del supporto per il AAC, necessario nella decodifica di media MPEG-4, tramite la libreria faad e del mp3 della libreria lame (libmp3lame), anchesso necessario, in particolare nella codifica con mencoder.

Comunque, al di là degli aspetti legati alla codifica dei media, è interessante notare che mplayer possiede un meccanismo di controllo riproduzione valido sia in locale sia in streaming. Esso, sotto forma di linea di stato, permette di tenere sotto controllo il carico della CPU e la qualità della riproduzione, elementi questi non trascurabili in fase di valutazione delle prestazioni complessive. Ad esempio, la riga seguente:

A: 2.1 V: 2.2 A-V: -0.167 ct: 0.042 57 41% 0% 2.6% 0 4 49%
mette in risalto le seguenti caratteristiche:

A: posizione audio in secondi;

V: posizione video in secondi;

A-V: differenza audio-video in secondi (ritardo);

ct: correzione totale sincronia A-V fatta;

frame letti (contando dall'ultima ricerca);

utilizzo cpu del codec video in percentuale;

utilizzo cpu video_out per avi, 0 per mpg;

utilizzo cpu codec audio in percentuale;

frame scartati per mantenere la sincronia A-V;

livello attuale del postprocessing dell'immagine;

dimensione della cache attualmente utilizzata (normalmente è ~50%).

Infine, è bene ricordare che mplayer supporta un livello di filtro video universale, che comprende numerosi plugin, in grado di compiere varie azioni sull'immagine, come ridimensionare, espandere, convertire in RGB o YUV ed altre operazioni di editing video in generale. Come tale, rappresenta una valida alternativa a prodotti commerciali, che di sicuro non possono competere con la completezza e ricchezza di funzionalità messi a disposizione dal player.

 

IV.3.3 Gmp4player

E il player sviluppato in seno al progetto MPEG4IP [19], nato per fornire alla comunità Linux un sistema, completamente basato sugli standards attuali, per la codifica, per lo streaming e per la riproduzione di media, audio e video, in codifica MPEG-4. Si basa su una serie di tools molto interessanti, come il gmp4player stesso, i codificatori mp4encoder, mp4creator e xvidenc ed un applicativo ibrido, il mp4live, in grado di catturare live il segnale TV, codificarlo in MPEG-4 e trasmetterlo sia in unicast sia in multicast. Di questultimo, comunque, si parlerà ampiamente in seguito. Il player è in grado di riprodurre files audio/video mp4, siano essi locali alla macchina di lavoro o ricevuti in streaming tramite RTSP/RTP da un server remoto. Inoltre è in grado nella sua versione base, di leggere anche media in codifica mp3, AAC, files wav, DivX, XviD. E buona norma comunque, in lato server poter disporre di files in formato QuickTime con estensione *.mp4, anche se in esso è contenuto il solo audio mp3. Si è riscontrato in fase di test, questo problema, dovuto ad un bug, in quanto il player, una volta ottenuto la descrizione SDP di un file con codifica MPEG4, si aspetta un file con estensione mp4, pena la segnalazione di un errore di decodifica. Si è così fornita una spiegazione del tutto personale, data la carenza di informazioni a riguardo: essendo gmp4player nato per lMPEG-4, il formato file ad esso compatibile è il QuickTime che, come detto, ha la possibilità di trasportare al suo interno dati codificati anche in altro modo, come appunto in mp3. Ultimamente, tale file ha assunto lestensione .mp4, dettata dalla stessa ISO MPEG-4 [24], quindi, ciò ha reso gmp4player esclusivamente sensibile a tale formato e quindi a tale estensione, a prescindere dalla codifica interna. Di conseguenza, anche nei servers in uso, si sono utilizzati sempre files con estensione .mp4. Relativamente ai codecs utilizzati, anche gmp4player, come mplayer, utilizza librerie per il supporto di vari codecs, prodotti esternamente ed implementabili nel pacchetto. Tra queste, le più importanti sono "libmpeg32", con i codec MPEG-1/2, "win32" per la compatibilità con applicativi Microsoft Windows, "faad-faac" per il supporto AAC e "lame" per il mp3, che rendono naturalmente il player più completo nella gestione di files multimediali nello streaming.

In Appendice A, viene riportato un esempio di riproduzione da parte del client, evidenziando la consultazione delle librerie necessarie alla decodifica del media in arrivo. Per quel che riguarda lo streaming, si utilizzano tutte le funzionalità dei protocolli IETF, permettendo al player, di essere compatibile con la maggior parte dei servers streaming, tra cui in particolare con Darwin, lo streaming server della Apple. Gmp4player infatti, nasce anche per coprire una grossa lacuna del mondo Linux in generale, ossia la mancanza del lettore QuickTime per tale ambiente di lavoro. Come sottolineato in precedenza, non sono disponibili al momento client Linux per lo streaming di media in MPEG-4 e la situazione è nettamente peggiorata, da quando il gruppo MPEG, ha standardizzato il formato file QuickTime quale formato ufficiale per il codec MPEG-4. Di conseguenza, lunica possibilità sarebbe il ricorso al player della Apple, di cui però, ripeto, non esiste una versione per Linux. Con gmp4player, si risolve tale problema spinoso, riuscendo così a superare questa grossa limitazione. Rimane però il problema di avere un unico player/client completo, nel supportare tutti i formati files e codecs a disposizione. Da notare infatti, che, nella architettura di streaming in descrizione, si devono utilizzare tre players diversi, per altrettanti diversi codecs!

 

IV.4 Servers

 

IV.4.1 Helix

IV.4.1.1 Caratteristiche generali

Progettato da RealNetworks [18] per gestire il trasferimento dei media in modo affidabile e flessibile, Helix Universal Server è in grado di supportare la maggior parte dei formati audio, video, testo, immagini conosciuti, oltre ad essere pienamente compatibile con i più importanti players utilizzati, quali RealPlayer naturalmente, Windows Media Player ed Apple QuickTime. I formati files da esso supportati sono, RealAudio, RealVideo, RealText, RealPix, Flash (.swf), Windows Media (.asf), QuickTime (.mov), WAV, AVI, oltre a praticamente tutti i codecs tuttora conosciuti tra i quali MPEG-1, MPEG-2, MPEG-4 con tutte le sue varianti. Altro aspetto da sottolineare è la sua assoluta natura multi piattaforma, che gli permette di essere utilizzato con qualsiasi sistema operativo e soprattutto di poter dialogare in tutta compatibilità con players remoti su S.O. diversi da quello su cui esso è installato, garantendo così unassoluta interoperabilità. E ovvio che predilige il trasferimento di dati in RealMedia, di cui ne esalta le qualità; quando un client infatti richiede un tale media, sfruttando la capacità del codec di codificare ed inserire differenti streams a differenti bit rate in uno stesso clip, oltre allindicazione della larghezza di banda a lato client (informazione in genere fornita da RealPlayer), riesce ad inviare il flusso adatto per le esigenze di banda del client, in modo da garantirne la migliore qualità. Non a caso infatti due punti di forza sono lottimo grado di scalabilità e riduzione della larghezza di banda. Per quel che concerne invece luniverso MPEG, come detto, esso supporta i tre codecs principali e più precisamente: lMPEG-1, nei files di estensione mpa, mpg, mpeg, mpv, mps, tramite i soli protocolli RTP/RTSP; lMPEG-2, nel solo formato Program Elementary Stream (quindi non Transport Stream), sempre utilizzando RTP/RTSP; lMPEG-4, con files opportunamente "trattati" in modo da evidenziare bene le tracce al suo interno e trasferiti mediante RTP/RTSP.

 

IV.4.1.2 Protocolli supportati

I protocolli sono molteplici in modo da venire incontro alle esigenze di interoperabilità tra piattaforme differenti: di sicuro per il trasporto, il RTP si fa preferire al proprietario RDT in generale, così come per il controllo di sessione, il RTSP è preferito ad altri quali il Progressive Networks Audio (PNA); da precisare però, che al momento, Microsoft non è in grado, per propria volontà, di supportare il RTSP, con notevoli conseguenze per il Windows Media Player. Per tale ragione, si è fatto in modo di fornire ad Helix, il supporto del protocollo MMS, Microsoft Media Services, utilizzato da detto player.

IV.4.1.3 Gestione amministrativa

Da segnalare, inoltre, la gestione amministrativa del sever, utilizzando a tal fine una sicura interfaccia HTML che permette, allamministratore del sistema, di interagire con il server dovunque esso si trovi. Si potrà allora attivare o disattivare il server, oltre a configurarne le caratteristiche principali. In figura IV.1, viene mostrata linterfaccia web del server installato in laboratorio,rispondenteallindirizzo:

http://genni.ing.uniroma1.it:14459/admin/index.html.

 

Figura IV.1 - Helix Administrator web page

Con essa, si potrà controllare la banda istantanea utilizzata, il carico della CPU, gli utenti connessi, i files inviati, la storia degli accessi oltre a poter settare tra laltro il tempo massimo di connessione.

Per la configurazione del server, si può lavorare anche localmente per mezzo di un configuration file, rmserver.cfg, che può essere editato manualmente nellintento di effettuare delle modifiche, senza ricorrere al web. Si ricorda, che Helix, non fa soltanto streaming ma è anche un server web. In fase di installazione, vengono richieste le porte necessarie alla comunicazione tra i vari protocolli, in modo da settarle in funzione delle proprie esigenze. Su genni ad esempio, si è dovuto utilizzare la porta 180 per il HTTP, poiché la porta 80, di default, è già occupata dal web server Apache.

 

IV.4.1.4 Limitazioni

Alla luce delle caratteristiche sicuramente interessanti e funzionali del server bisogna mettere in evidenza però la più grande limitazione, ossia il fatto di essere un prodotto completamente close-source. Non permette quindi di osservare, capire il codice, in particolare le librerie relative ai codecs video/audio e a quelle per la gestione dei protocolli utilizzati. Rimane quindi un ottimo prodotto, ma fine a se stesso, con relative possibilità di sviluppo future.

 

IV.4.2 Darwin

IV.4.2.1 Caratteristiche generali

Nato come versione completamente open-source del già noto QuickTime Streaming Server, Darwin Streaming Server rappresenta un ottimo applicativo per lo streaming multimediale su piattaforma Linux, utilizzante il protocollo di trasporto RTP ed il protocollo di controllo sessione RTSP, rendendolo di fatto compatibile con i clients più completi tuttora implementati. Può supportare il multicast ed è in grado di gestire la trasmissione di media codificati in MPEG-1/-2/-4 per il video, MP3 o AAC per laudio; il formato file prediletto è il QuickTime, altri formati non è in grado di leggerli.

 

IV.4.2.2 Hinted files

A tal proposito, si vuole evidenziare una caratteristica molto particolare del server: tutti i files che esso può maneggiare devono essere necessariamente convertiti in formato QuickTime e successivamente devono essere "hintati", ossia resi in una forma tale da poter essere compresi dal server ed anche da un eventuale riproduttore in grado di gestire files QT. Rendere hinted un file significa, infatti, utilizzare particolari software che analizzino i dati e creino delle tracce in cui vengano specificate varie informazioni necessarie al server per pacchettizzare i dati stessi da trasmettere. In un hinted file si troveranno allora tante tracce quante sono le tracce nel media originale a cui saranno allegati dettagli sul tipo di codifica utilizzato, bit rate, frame rate se video o frequenza di campionamento se audio, durata della traccia e informazioni esplicite su dove sono localizzati i payloads delle varie tracce; se il media è codificato in MPEG-4, ci saranno poi descrittori delloggetto e il BIFS, di cui si è parlato nello scorso capitolo, come si può evincere dallesempio seguente in cui si mostra il contenuto di un file hintato MPEG-4:

[root@genni testmpeg4]# mp4info mp4vr500fr25.mp4

mp4info version 0.9.6

mp4vr500fr25.mp4:

Track Type Info

1 video MPEG-4 Simple @ L3, 118.960 secs, 515 kbps, 320x240 @ 25.00 fps

2 hint Payload MP4V-ES for track 1

5 audio MPEG-4, 60.255 secs, 95 kbps, 44100 Hz

6 hint Payload mpeg4-generic for track 5

7 od Object Descriptors

8 scene BIFS

[root@genni testmpeg4]#

Da sottolineare, che a seconda del software utilizzato per tale operazione, non è necessario che il file sorgente sia in formato QT, non a caso infatti, in generale, un file in tale formato è già hintato. La scelta di gestire files così particolari, può essere spiegata nella scelta, degli sviluppatori, di alleggerire il carico di elaborazione del server; è ovvio, infatti, che avere un file, le cui tracce siano ben distinte e che per ciascuna di esse ne siano evidenziate le caratteristiche principali, rappresenta un dispendio di lavoro non trascurabile per il decodificatore. Inoltre si vuole precisare che hintare un file, non significa decodificare e codificare i dati in esso contenuti, ma semplicemente operare una trasformazione del formato file; i dati al suo interno non vengono modificati, garantendo quindi un minimo di flessibilità sui codecs utilizzati. Si potrà allora hintare un file con dati in MPEG-1/-2/-4 e, se il software di conversione lo permette, anche di altri codecs. Questa particolare caratteristica però, ha reso il lavoro particolarmente complicato, soprattutto nella fase di test, data la necessità di dover gestire obbligatoriamente detti files. Di questo aspetto e dei test relativi al suo funzionamento, se ne riparlerà nel prossimo paragrafo.

 

IV.4.2.3 Gestione delle risorse e amministrazione

Darwin ha mostrato comunque interessanti caratteristiche, quali laccessibilità, permettendo la trasmissione di media utilizzando RTP e RTSP sul protocollo HTTP, per rendere il tutto insensibile ad eventuali firewalls disposti in lato client o server; ciò rende necessario luso della porta 80, creando però non pochi conflitti con leventuale web server installato sulla stessa macchina. Una possibile soluzione sarebbe il ricorrere al virtual hosting, quindi associare al web server e allo streaming server sullo stesso computer, due differenti indirizzi IP. Inoltre, come Helix, permette la gestione remota dellamministrazione per mezzo di uninterfaccia web, da cui è possibile lanciare lapplicativo, configurarlo e mostrare quindi le relative informazioni di configurazione, quali le statistiche di connessione e i media streams allocati.

Per consultare tali risorse, ad esempio nel caso del server in laboratorio, si può contattare la URL http://genni.ing.uniroma1.it:1220, di cui se ne mostra linterfaccia grafica in figura IV.2. Da web si potrà così controllare il carico della CPU, la banda utilizzata, il totale dei byte e delle connessioni servite, gli utenti connessi, oltre a poter settare la directory cui memorizzare tutti i media accessibili dal server, il massimo numero di connessioni (valore attuale 1000) ed il massimo throughput (valore attuale 100Mbps). I metodi RTSP supportati sono: DESCRIBE, SETUP, OPTIONS, ANNOUNCE, PLAY, PAUSE, TEARDOWN, quindi, si può considerare tutto sommato abbastanza completo ai fini di una sessione di streaming.

Figura IV.2 Darwin Administrator web page

IV.4.2.4 Darwin Reflector

Infine, si vuole evidenziare la caratteristica più significativa del server, ossia la possibilità da parte di Darwin, di essere utilizzato come reflector, in modo da poter trasmettere ad un client in streaming, una sessione live. In figura IV.3 viene mostrata una semplice rappresentazione di detta funzionalità.

Figura IV.3 - Darwin Reflector

Come si vede, si deve essere dotati, da qualche parte e non necessariamente sulla stessa macchina, di un broadcaster, che acquisisca un flusso live, proveniente ad esempio da un CD-DVD o da una scheda TV, lo codifichi utilizzando un codec opportuno, pacchettizzi tale stream nel RTP e lo invii, tramite UDP, ad un determinato indirizzo unicast o anche multicast, il tutto dopo aver costruito la descrizione SDP del media oggetto della trasmissione.

Se, allora, questa descrizione venisse fornita a Darwin, esso, "sintonizzandosi" su detti indirizzi e sulle relative porte per laudio e/o il video descritte proprio nel SDP, diventerebbe un client in ascolto dallo stesso broadcaster, con la differenza che invece di riprodurre il media, si limiterebbe a rifletterlo, ossia trasmetterlo ad un client remoto che volesse iniziare una sessione live di questo genere. Prima di far ciò però, avrà ben cura di modificare la descrizione del media fornitagli, sostituendo le caratteristiche del mittente con le proprie coordinate; in questo modo, si ritroverà una descrizione nuova ed efficace da mandare al client in risposta al DESCRIBE.

 

IV.5 Tests incrociati di streaming

IV.5.1 Risorse utilizzate

Nel precedente paragrafo, si sono enfatizzate le caratteristiche delle cinque applicazioni opportunamente scelte per dare luogo allarchitettura di streaming oggetto della tesi: i clients RealPlayer, Gmp4player, Mplayer ed i servers Helix e Darwin. Da una prima valutazione, basandosi su documentazioni, bibliografie e semplici prove di laboratorio, si è infatti reputato i sopra citati gli applicativi più interessanti, oltre ad essere di sicuro quelli più consistenti ed affidabili. Dopo questa classificazione iniziale, il lavoro è consistito allora nelle prove esaustive dei servers suddetti, utilizzando detti clients, al fine di evidenziarne leffettivo corretto funzionamento, gli eventuali limiti e le prestazioni. E ovvio che una simile analisi, ha contribuito anche a rafforzare le conoscenze sui players utilizzati, caratteristiche queste non pubblicizzate in alcuna documentazione e che quindi si sono rivelate inedite e molto interessanti dal punto di vista sperimentale. Come detto, per i tests ci si è servito di due computers, classificati come genni e comel; su genni si sono installati i due servers ed i players, mentre su comel soltanto i tre clients.

Gli indirizzi RTSP di Helix e Darwin su genni sono stati allora rispettivamente rtsp://genni.ing.uniroma1.it:654/ e rtsp://genni.ing.uniroma1.it/. Come si evince, Darwin risponde alla porta di default 554, mentre Helix alla porta 654, riuscendo in questo modo a discriminarli. Per entrambi, si è fatto in modo che puntassero alla stessa directory in cui sono allocati i media da trasmettere ed il cui path è /home/tomosan/tesi/helix/Content; in questo modo, è stato più agevole gestire le risorse multimediali che come appena visto, sono condivise dai due servers.

Si è utilizzato inoltre come strumento di cattura dei pacchetti, lo sniffer Ethereal, con il quale si è potuto studiarne il contenuto e quindi valutare il corretto uso del paradigma server-client del RTSP. Ma vediamo in dettaglio gli esiti delle sperimentazioni.

 

IV.5.2 Darwin e hinted files

Da evidenziare innanzitutto, la caratteristica un po spiacevole di Darwin nel gestire i soli hinted files. Quando infatti, gli viene richiesto un file non hintato, al DESCRIBE, risponde con un "Error 415 Unsupported Media Type", chiudendo quindi la comunicazione con il client. Il motivo è che, per i files normali, non riesce a costruirne la descrizione SDP, poiché, come detto, non è in grado di interpretare completamente il flusso di dati contenuto nel file. E nata quindi subito lesigenza di trovare un meccanismo per convertire i files in un formato hinted.

A tal proposito si sono stabiliti vari contatti con ricercatori della Apple Computers, nei quali però, più volte è stato erroneamente suggerito di utilizzare il QuickTime Pro, il lettore/client della Apple, di cui però, non esiste alcuna versione per Linux. Ci si è trovati quindi inizialmente con un server sì funzionante ma dal solo punto di vista amministrativo dello stesso, poiché, nessuno, nella comunità è stato in grado di fornire chiarimenti opportuni. Non solo ma, ben presto, si è capito che il problema naturalmente ha coinvolto i tanti altri utilizzatori di Darwin per Linux.

Successivamente comunque, la risposta a tale limitazione la si è avuta da uno dei tools presenti nel pacchetto MPEG4IP, il mp4creator, che oltre a generare files in formato QT, con lopzione "-hint" permette di hintare detti files. In questo modo, si è potuto iniziare la sperimentazione contemporanea per Darwin ed Helix.

IV.5.3 Compatibilità Servers-Clients

Si è preferito iniziare i tests, utilizzando come oggetto dello streaming un file audio in codifica MP3, per garantire linteroperabilità di tutti i players; la scelta è stata dettata dalla diversità di supporti dei 3 clients a disposizione.

Si ricorda infatti la impossibilità ad esempio del mplayer di riprodurre media in codifica MPEG-4. Si è reputato allora fondamentale fare le prime prove utilizzando uno stesso file, tale da poter essere gestito da tutti gli applicativi in questione e che quindi si è dovuto modificare nel formato, passando dalloriginale al formato hinted QuickTime. In questo modo, si è garantito la assoluta compatibilità anche a livello di servers.

Le prove hanno dato tutte esito positivo, tranne nella comunicazione di RealPlayer con Darwin.

 

IV.5.3.1 Comunicazione tra Darwin e RealPlayer

Qui, si è infatti evidenziato una forte incompatibilità tra client e server. La comunicazione RTSP tra Real e Darwin, procede fino alla richiesta di SETUP avanzata dal client, in cui, comunica il tipo di trasporto che predilige e che quindi vorrebbe ottenere, come indicato nella stringa seguente:

Transport: x-real-rdt/mcast; client_port=6972;

mode=play, x-real-rdt/udp; client_port=6972;

mode=play, x-pn-tng/udp; client_port=6972;

mode=play, rtp/avp;unicast; client_port=6972;

Ad essa Darwin risponde con un errore "400 Bad Request", terminando di fatto la comunicazione. Si suppone che il di tale incompatibilità sia da ricercare al di là della impossibilità di RealPlayer di gestire files QT, nella mancanza di comprensione da parte del server della stringa sopra indicata, poiché, RealPlayer, comunica comunque la possibilità di ottenere i dati in RTP, mentre Darwin sembra ignorare tale informazione e quindi crede di dover trasmettere necessariamente i dati in RDT, cosa che ovviamente non può fare. Per tutti gli altri casi invece, tutto è andato bene, la comunicazione incrociata tra i servers e i clients ha dato i frutti previsti, così si è assistito al trasferimento corretto dei dati, evidenziandone anche delle caratteristiche inaspettate.

 

IV.5.3.2 Gestione delle porte e flussi di streaming

Helix ad esempio, per gestire più connessioni utilizza più porte diverse, dalle quali fa partire le diverse connessioni per gli altrettanto diversi clients. Darwin invece, mantiene una sola porta attiva, dalla quale fa uscire più flussi diversi, tra di loro distinti dal campo ssrc, (Sinchronization SouRCe [10]) del RTP, oltre naturalmente alle porte ed indirizzi di destinazione. Esso infatti, sin dalla risposta al SETUP, fornisce un primo ssrc nello streaming protocol, in modo già da distinguere le sessioni in atto e per poi dare luogo alla trasmissione RTP con i vari clients.

Se il flusso è live, quindi non ci sono vincoli di inizio riproduzione, addirittura per ogni pacchetto ne vengono fatte due copie e successivamente inviati ai due clients dalla stessa porta ma con SSRC diversi. A tal proposito, si vuole sottolineare che, anche i clients mplayer e gmp4player usano sempre la stessa porta a parità di computer su cui girano, al contrario di RealPlayer che, invece ne apre diverse, una per ogni sessione.

 

IV.5.3.3 Autenticazione per Helix e RealPlayer

Altra caratteristica interessante, riguarda il meccanismo di autenticazione su cui si basano gli applicativi della RealNetworks, quindi RealPlayer ed Helix; il player, infatti, a prescindere dal server, manda nel messaggio di richiesta di OPTIONS, un header "ClientChallenge:" seguito da una stringa esadecimale. Se il server con cui sta comunicando è Darwin, questultimo, rimane insensibile a tale campo, quindi prosegue il protocollo RTSP senza risposte particolari per detta richiesta. Se invece il server è Helix, si instaura uno scambio di richieste-risposte con il client, infatti, il server in risposta al OPTIONS, fornisce un header "RealChallenge1:" seguito, anchesso da una stringa esadecimale.

A questo punto, dopo il DESCRIBE, nel messaggio di SETUP, il client inserirà un nuovo header "RealChallenge2:" seguito sempre da una stringa, ma con laggiunta nella stessa riga di un campo "sd=" stringa esadecimale, a cui il server risponde con un header "RealChallenge3:" e la stringa "sdr=". Purtroppo la cripticità delluniverso applicativo Real, non ha permesso di comprendere il significato esatto dei campi sopracitati ma, dopo varie ricerche, si è capito appunto che questo è un meccanismo di autenticazione nato dalla necessità dei servers Helix, di dover autenticare i clients che richiedono risorse.

Ottenendo nel campo OPTIONS, il messaggio ClientChallenge, i servers possono allora autenticare correttamente il RealPlayer, lanciando appunto una sfida, basata su determinati algoritmi di crittografia. Se una stessa richiesta viene fornita da un altro player, con lassenza di detto campo, il server comunque permette la comunicazione e quindi l'instaurazione della sessione. Se, viceversa, RealPlayer comunica con Darwin, alla richiesta di ClientChallenge, come detto, il server non risponde, lasciando capire al client che il server non è Helix (come del resto è indicato nel campo server del messaggio OPTIONS dove in questo caso ci sarà DSS, Darwin Streaming Server), quindi nel SETUP seguente, non sfiderà più il server perché è inutile.

 

IV.5.3.4 Gestione del metodo PAUSE

Infine, altra caratteristica di interesse riguarda la gestione del metodo PAUSE da parte dei servers e clients testati. Darwin ed Helix hanno di per se la possibilità di gestire tale richiesta, fermando linvio dei pacchetti RTP, tenendo memoria dellultimo pacchetto inviato, in modo da riprendere esattamente dal primo pacchetto non inviato la trasmissione in seguito ad una richiesta successiva di PLAY.

Ciò che è davvero interessante è la gestione del metodo da parte dei players; se infatti, Mplayer non ha tale funzionalità, ossia il pause equivale ad un mute (la riproduzione del lettore si ferma, ma dal player non parte nessun messaggio RTSP di PAUSE), RealPlayer e Gmp4player si comportano diversamente.

RealPlayer, infatti, manda semplicemente una richiesta di PAUSE, seguita eventualmente da una semplice richiesta di PLAY, senza specificare altro; gmp4player, invece, in seguito al PAUSE, memorizza linformazione del tempo relativo di riproduzione del media (il campo npt) letta dallultimo pacchetto arrivato.

Successivamente, nella richiesta di PLAY, allega linformazione temporale npt=xx yy, dove xx è listante di tempo relativo al primo pacchetto non arrivato in seguito al PAUSE e da cui si vuole reiniziare la riproduzione, e yy è listante di fine del media.

Come si vede allora, gmp4player, manda una informazione ridondante, poiché i servers sapranno comunque da dove far ripartire il flusso. Rimane valida la sua funzionalità per quei servers che invece hanno dei problemi nella gestione di detto metodo.

 

IV.5.3.5 Analisi con tracce audio - video

Altre informazioni sulle prestazioni e differenze dei servers sono state messe alla luce mediante analisi più complesse, di cui se ne parlerà nel prossimo capitolo. Una volta messe alla luce queste caratteristiche, si è passato quindi ad un secondo livello di tests, ossia alla trasmissione di un media audio e video. Tutto quello che è stato sopra detto per un file MP3, è stato confermato per un media più complesso, composto da traccia audio e traccia video, con la differenza però che nel solo caso di video con codifica MPEG-1 MPEG-2 si è potuto utilizzare il mplayer, quindi non con video MPEG-4, e in tutti i casi con video MPEG, non si è potuto contare sul RealPlayer; i tests con il MPEG-4, li si sono potuti realizzare usando tracce hintate, entrambi i servers e gmp4player come client; per i tests con video MPEG-1/-2, si sono usate sempre tracce hintate, con entrambi i servers e clients gmp4player e mplayer.

I risultati qualitativi sono stati tutti soddisfacenti, evidenziando la bontà dei servers utilizzati e mostrando tutto sommato una discreta compatibilità, enfatizzata in figura IV.4, tra gli applicativi in questione.

 

Figura IV.4 Compatibilità players/servers

IV.6 TV-on-Demand

Laver realizzato una architettura di streaming, come si è visto, del tutto efficiente e funzionale, ha spinto naturalmente allo sviluppo di un sistema di TV-on-Demand, che di fatto, rappresenta una particolare applicazione dello streaming; studiando infatti il RTSP, spesso ci si è imbattuti nella citazione di eventi live, quindi di media non memorizzati preventivamente sul proprio hard-disk la cui fruizione, avvenga mediante cattura di suoni o immagini in tempo reale per mezzo di hardware e software opportuni.

Lidea è stata la seguente: realizzare una pagina web (http://genni.ing.uniroma1.it/~tomosan/tvondemand.html) da cui, poter richiedere la trasmissione in streaming di un evento televisivo in onda sulla rete analogica terrestre nazionale, "sintonizzando" quindi opportunamente il player sul canale scelto e permettendo inoltre la scelta di caratteristiche varie, quali ad esempio il bit rate, frame rate, dimensione quadro, etc.

Per prima cosa ci si è chiesto di quali risorse si necessitava per tale realizzazione e tra queste quali se ne avevano già a disposizione. Naturalmente si aveva bisogno di un server RTSP che gestisse le richieste e trasmettesse il media; la scelta è caduta subito su Darwin, dato che presenta maggiori attitudini alla trasmissione live poiché è dotato della funzionalità di reflector vista in precedenza. Si necessitava poi di un trasmettitore, in grado di catturare il segnale TV, codificarlo e trasmetterlo verso un indirizzo unicast o multicast; si è allora preferito utilizzare lapplicazione mp4live del pacchetto MPEG4IP, poiché permette tutte le operazioni sopra citate. E chiaro che per ricevere il segnale televisivo si è avuto bisogno anche di una scheda TV, fortunatamente già a disposizione sul computer di lavoro genni (scheda Pinnacle TV/Rave) e di un web server, da utilizzare per permettere linterfacciamento del sistema con la rete. Si è utilizzato a tal fine il server Apache, di cui è dotato genni. Questi sono stati i mattoni basilari per permettere la costruzione dellarchitettura di streaming televisivo, dai quali però, è nata subito lesigenza di farli dialogare a dovere. Il lavoro è costituito allora nella necessità di trovare soluzioni per linterfacciamento delle applicazioni utilizzate, arrivando così alla realizzazione di uno script, una pagina web in HTML e un semplice programma in linguaggio C, con i quali si è reso possibile quanto desiderato.

 

IV.6.1 Mp4live

IV.6.1.1 Caratteristiche generali

Mp4live è un software molto utile e completo che riunisce una serie di funzionalità molto interessanti per i fini preposti; si basa su una interfaccia grafica, da cui si può, in maniera molto semplice, scegliere il tipo di configurazione preferita per la visione della TV. Si potrà allora scegliere per prima cosa il dispositivo da cui catturare le immagini, (nel caso in questione la scheda TV di riferimento fa capo al device /dev/video0), per poi indicare il canale preferito, il sistema di codifica desiderato (ovviamente PAL nel nostro caso), la dimensione del quadro (a scelta ad esempio tra SQCIF: 128X96 QCIF: 176X144 SIF: 320X240), il video bit rate ed il frame rate. Naturalmente il tutto dopo aver indicato la preferenza verso la riproduzione grezza del video, quindi utilizzando il tool come semplice riproduttore o verso la codifica del video in MPEG-4, facendo lavorare mp4live come codificatore di immagini. Simili operazioni di configurazione, saranno da farsi per laudio; così, si dovrà indicare il device che fa capo alla scheda audio (/dev/dsp/ nel nostro caso), il tipo di codifica audio (qualora si decida di catturare e codificare contemporaneamente il segnale) tra AAC e MP3, la frequenza di campionamento, il numero dei canali disponibili (1 mono, 2 stereo) e laudio bit rate.

 

IV.6.1.2 File di configurazione

Tutte queste informazioni, possono essere memorizzate in un file di configurazione, utile qualora, si decida di riprodurre la TV una seconda volta con gli stessi parametri scelti in precedenza, il tutto mediante interazione con linterfaccia grafica, di cui per comodità se ne mostra un esempio in figura IV.5. Il file di configurazione, sarà un semplice file di testo, dove saranno elencati una serie di nomi di variabili, seguite dai valori scelti per esse. Così ad esempio, per comunicare al programma la volontà di vedere il programma 44, a 25 fps e 500 kbps, nel file ci saranno i seguenti campi:

videoChannelIndex = 34

videoFrameRate = 25

videoBitRate = 500

Si noti come lindicazione del canale televisivo, sembri errato (34 in luogo di 44); in realtà esso è dovuto ad uno shift nella numerazione dei canali sintonizzabili da mp4live. Un esempio completo di file di configurazione, comunque, è consultabile in Appendice A.

 

Figura IV.5 Mp4live

 

IV.6.1.3 Funzionalità di codificatore e trasmettitore

Tutto ciò riguarda la semplice funzionalità di riproduttore di cui il tool mostra un ottimo affidamento e semplicità di utilizzo. In realtà mp4live presenta altre funzionalità ben più importanti. Prima di tutto, essendo dotato di un codificatore interno, sfrutta tale caratteristica permettendo, su richiesta dellutente, di registrare in un file di formato QT, per giunta già di tipo hinted, il media catturato in diretta; non solo, ma sempre su richiesta, può acquisire la funzionalità di broadcaster, ossia, può trasmettere verso un prefissato (dallutente) indirizzo e porte per laudio ed il video usando il protocollo RTP, il segnale televisivo codificato in video MPEG-4 e audio AAC o MP3 a seconda delle preferenze.

Per renderlo più consistente, gli sviluppatori lo hanno dotato anche di un meccanismo per la generazione, su richiesta, della descrizione SDP del media. In essa verrà indicato l'indirizzo unicast o multicast e le porte verso cui si inviano i dati, il tipo di codifica audio e video utilizzata, laudio ed il video bit rate, la frequenza di campionamento, oltre ad altre informazioni di configurazione necessarie al ricevitore per prepararsi alla decodifica e successiva riproduzione. E ovvio allora che con questi strumenti, si superano i grossi ostacoli relativi alla codifica del segnale e alla trasmissione degli stessi in maniera del tutto affidabile.

 

IV.6.1.4 Comunicazione con Darwin Reflector

Una volta valutata lassoluta garanzia di funzionamento di mp4live, ricordando il reflector utilizzato da Darwin, si è deciso di inglobare le due funzionalità. Per prima cosa, dopo aver settato la configurazione di interesse, si è iniziata la cattura/codifica del segnale, il quale poi, è stato trasmesso verso le porte di un indirizzo multicast di default. Lavvenuta trasmissione è stata testimoniata da ethereal che ha messo in evidenza il corretto trasferimento dei pacchetti RTP. Successivamente, dopo aver costruito tramite mp4live la descrizione SDP in forma di un file capture.sdp, si è preso detto file e lo si è collocato nella directory in cui sono localizzate tutte le risorse multimediali dei servers.

A questo punto si aveva un file, capture.sdp, che poteva essere trattato come un media qualunque, quindi, richiedendolo a Darwin tramite gmp4player via RTSP, si è assistito allattivazione della sessione di streaming, che ha portato con successo alla riproduzione del media. Il tutto si può spiegare come segue: Darwin, quando gli arriva una richiesta RTSP per il file capture.sdp (il quale naturalmente deve essere stato preventivamente costruito e memorizzato nella directory di interesse), apre detto file leggendo lindirizzo e le porte di trasmissione e lo modifica sostituendo nel campo "c" del SDP [12] (indirizzo da contattare per ricevere il media) allindirizzo multicast originale il proprio indirizzo IP (genni: 151.100.122.85) e nei campi "m" (tipo di media, porte, trasporto e payload type RTP) le porte audio e video con uno "0", facendo così capire al client che le porte di comunicazione saranno negoziate successivamente durante la fase di SETUP. A questo punto invia il file modificato al client come risposta al DESCRIBE, dando di fatto luogo ad una sessione che sarà quindi sempre in unicast tra client e server.

Una volta risposto al SETUP, fornendo in tale occasione le porte di trasmissione, si mette in "ascolto" sullindirizzo multicast verso cui il broadcaster mp4live sta trasmettendo il media e aprendo dei sockets, cattura i pacchetti non per riprodurli, ovviamente, ma per spedirli verso lindirizzo del client che gli ha richiesto lo streaming televisivo. A conferma di quanto detto, si è verificato con successo, che tra le porte attive durante le trasmissioni contemporanee in multicast e RTSP (informazione ottenuta usando il comando netstat), quella aperta per il RTSP era utilizzata proprio da Darwin (mediante il comando fuser), il quale contemporaneamente catturava i pacchetti trasmessi in multicast.

 

IV.6.2 Interfaccia web

Una volta appurato che Darwin e mp4live interagiscono ai fini della trasmissione in streaming, è nata la necessità di dover creare un meccanismo in grado di poter comandare a distanza la riproduzione del media. Lidea presa in considerazione è stata quella di realizzare una pagina web, fatta di vari menù a tendina, con i quali si potesse configurare la trasmissione ed il media scegliendo: il canale televisivo, la dimensione del quadro, la codifica audio, il numero di canali audio, la frequenza di campionamento, l'audio bit rate, il frame rate ed il video bit rate. I valori dati, sarebbero stati necessari alla costruzione, in maniera perfettamente interpretabile, del file di configurazione in modo da poter dare inizio alla codifica e trasmissione del media. E chiaro allora che si doveva riuscire a comandare da remoto il lancio di mp4live fornendogli il file di configurazione, per poi successivamente far costruire la descrizione SDP (sempre funzione del file di configurazione scelto) e renderla disponibile al server Darwin, collocandola opportunamente nella stessa directory di Helix /home/tomosan/tesi/helix/Content.

Tutto ciò, ha necessitato fondamentalmente di tre operazioni essenziali da dover realizzare.

 

IV.6.2.1 Uso delle opzioni di mp4live

Per prima cosa, bisognava studiare se mp4live potesse lavorare correttamente da linea di comando, ossia, se nel codice prevedesse la possibilità di essere invocato aggiungendo al nome del file di riferimento (mp4live) le opzioni sul suo funzionamento. Fortunatamente si è scoperto che è prevista la possibilità di includere le seguenti opzioni:

 

IV.6.2.2 Uso di CGI e FORM HTML

Una volta appurato che mp4live potesse essere comandato completamente da linea di comando, si è dovuto trovare un modo per far dialogare la pagina web di richiesta, sotto lentità del web server Apache, con mp4live stesso, creare quindi quel meccanismo in grado di leggere dalla pagina i dati richiesti dallutente, con essi costruire il file di configurazione ed invocare così il lancio della cattura, codifica e trasmissione del media. Il lavorare in ambito Linux, ha permesso di superare brillantemente lostacolo. Tale sistema operativo, infatti, permette di gestire agevolmente lavvio ed il controllo dei vari programmi mediante la shell, ossia la superficie con cui lutente interagisce quando vuole comunicare con il sistema stesso. La shell, che nel caso presente è rappresentata dalla riga di comando, in realtà è un potente interprete di un linguaggio di programmazione orientato al lancio e quindi al controllo dei programmi presenti nellelaboratore. Le operazioni ordinate dallutente, potranno essere sotto forma di semplice comando da riga, oppure di un file script, scritto nel linguaggio della shell; in questultimo caso, si possono articolare una serie di comandi tesi ad operazioni diverse. Alla luce di ciò, si è così optato per la realizzazione dello script, in grado di poter leggere i dati importati dalla pagina e di dar luogo ad una serie di operazione tese a rendere solido ed efficiente il sistema di tv-on-demand in realizzazione. Per iniziare si è allora costruito la citata pagina web mediante luso di FORM, in modo da associare ad ogni richiesta un nome di variabile e allopzione scelta nei menù a tendina, un valore prefissato; si sono così ottenute una serie di informazioni del tipo <variabile>=<valore>. Ad esempio, nella pagina è richiesto di specificare la frequenza di campionamento per laudio e nel menù relativo a tale opzione, cè la possibilità di scegliere tra due valori, 44100 Hz e 16000 Hz. Per mappare tale informazione si è utilizzato il nome di variabile freqaudio a cui, in seguito alla scelta, gli si associa il valore 44100 o 16000. Naturalmente, è subentrata così la necessità di determinare il modo con cui importare tali variabili nello script realizzato. Si è utilizzato a tal proposito uno script CGI (Common Gateway Interface), proccgi.sh, anchesso scritto in un linguaggio della shell e reperito in rete. Lazione di detto programma è la seguente: invocandolo allinizio dello script realizzato, mette a disposizione il valore corrente di una variabile definita nella FORM della pagina web, nello script stesso, per poter essere utilizzata nel nuovo ambiente di lavoro. Per garantire ciò, è necessario utilizzare nello script la seguente sintassi: $FORM_nomevariabile. Quindi, per utilizzare il contenuto della variabile freqaudio sopracitata, si dovrà scrivere $FORM_freqaudio. In questo modo linterprete shell, capirà dal carattere "$" che deve fornire il contenuto della variabile FORM non locale freqaudio, importata dalla pagina web, che di per sé naturalmente, dovrà richiedere nellintestazione HTML, che le sue variabili vengano esportate al programma script realizzato (<form action=http://genni/cgi-bin/tv.cgi>).

 

IV.6.2.3 Scelta di indirizzamento unicast

Prima di spiegare i contenuti dello script realizzato, si vuole però sottolineare un aspetto molto importante. Si è detto infatti, che nelle prime prove di comunicazione tra Darwin e mp4live, si è utilizzato un indirizzo multicast, verso cui mandare il media. Mantenere una simile scelta, anche per il sistema da realizzare, avrebbe comportato però un ingente spreco di risorse, poiché, contemporaneamente allo streaming RTSP, ci sarebbe stata una trasmissione RTP verso un indirizzo multicast, tra laltro senza sapere effettivamente a chi o cosa facesse capo detto indirizzo. Per ovviare a tale problema, si è deciso di far trasmettere mp4live da genni verso se stesso (IP 151.100.122.85, porta audio 38430, porta video 28428) creando di fatto una sorta di loopback. In questo modo, non facendo uscire pacchetti dallhost genni, si è evitato così di caricare in maniera superflua la rete. Tests relativi a tale scelta, hanno dato esito positivo, portando così alladozione di tale semplice quanto efficace implementazione della trasmissione.

 

IV.6.3 Script

IV.6.3.1 Comando reset

Nella realizzazione dello script shell tv.cgi (di cui ne viene mostrato il codice nellAppendice B), oltre a i problemi sopra citati si sono dovute tenere in considerazione varie problematiche relative in particolare al controllo del programma in esecuzione e quindi della trasmissione. E buona norma infatti, quando si realizza un sistema di trasmissione, fare in modo che esso possa essere abilitato non solo naturalmente allinvio dei dati ma, anche alla inibizione degli stessi, mediante un comando di reset. Ciò nel caso in questione ha portato alla dotazione dellinterfaccia web di un tasto reset, in modo da fermare la trasmissione e poter così dare inizio successivamente ad un'altra. Per tale realizzazione si è pensato di ricorrere ad un semaforo che controllasse le riproduzioni, in modo da segnalare una riproduzione che fosse già in atto (rendendo di fatto il sistema inutilizzabile fino al rilascio delle risorse preposte alla trasmissione) e permettere il reset della trasmissione, qualora essa fosse in esecuzione. E chiaro che un tale sistema è assolutamente non democratico, in quanto, a chiunque viene data la possibilità di resettare una trasmissione in corso, richiesta magari precedentemente da un utente diverso che nel frattempo sta vedendo la TV. Ciò che deve essere chiaro è che il sistema in questione, nasce per fini sperimentali e non a scopo di intrattenimento, così, avere una possibilità di controllare la riproduzione per tests multipli senza dover agire direttamente sui processi in esecuzione, è di gran lunga più importante che non avere un sistema robusto alla gestione dellutenza.

 

IV.6.3.2 Condivisione risorse con ohphone

Ma ancor prima di gestire dette operazioni, è apparsa fondamentale la necessità di realizzare un secondo semaforo, che permettesse la condivisione indolore delle risorse su genni, tra il sistema di TV-on-Demand in questione e la visione della TV tramite lapplicativo ohphone, precedentemente installato sulla stessa macchina. Questultimo, dà la possibilità di vedere un canale televisivo fisso, quindi senza la possibilità di interazione per la scelta dello stesso, catturando il segnale dalla scheda TV e trasmettendolo in codifica H.323 con la possibilità di riprodurlo utilizzando ad esempio gnomemeeting. Anche detto sistema, prevede la possibilità di essere lanciato tramite interfaccia web, creando però non pochi problemi, in quanto, facendo capo allo stesso device video (/dev/video0) di mp4live, una sua attivazione, pregiudica la possibilità di far funzionare mp4live stesso. Sono quindi mutuamente esclusivi. Ecco spiegato allora, la necessità di dover gestire i due tipi di riproduzione, con un meccanismo che quanto meno segnalasse loccupazione delle risorse allutente che cerchi invano di poter accedere al servizio da lui richiesto. Si è così fatto in modo da far condividere ad ohphone e a mp4live lo stesso semaforo. Lidea è la seguente:

Quando si lancia una delle due applicazioni, contemporaneamente viene creato dal web server Apache un file vuoto, di nome testmp4live nella directory /tmp, in cui successivamente, viene collocato un messaggio di dialogo da mostrare allutente. Così, se ad esempio viene lanciato mp4live, in /tmp ci sarà il file testmp4live con dentro scritto il messaggio:

La risorsa televisiva è impegnata nella trasmissione MPEG4

Per partecipare alla trasmissione MPEG4 collegati con gmp4player o quicktime a rtsp://genni.in.uniroma1.it/capture.sdp

Per ulteriori informazioni sulla trasmissione MPEG4 qui a LabTel visita questa pagina http://genni.ing.uniroma1.it/tesi/ts

Se ti interessa invece la videoconferenza in H.323, visita questa pagina

http://genni.ing.uniroma.it/tesi/ac

Con un semplice if allinizio dello script, si controlla se il comando inviato dallutente della TV-on-Demand, sia un play; se è così, si verifica lesistenza del file /tmp/testmp4live mediante la riga:

if ( ls /tmp/testmp4live > /dev/null )

Se il controllo dà esito positivo (esiste già il file), si restituisce allutente il messaggio mappato in testmp4live (cat /tmp/testmp4live) e si esce dal programma shell; se lesito è negativo invece, si crea il file testmp4live e si continua, poiché si è nella situazione in cui le risorse video siano libere. Lo stesso meccanismo lo si è utilizzato nello script di gestione del ohphone, in modo che, qualora un utente gnomemeeting volesse vedere il canale TV, anche ad esso comparirebbe lo stesso messaggio visualizzato precedentemente e contenuto in testmp4live, proprio perché, come detto, i due scripts puntano allo stesso semaforo e quindi allo stesso file. Se viceversa, fosse ohphone ad essere lanciato per primo, il messaggio in testmp4live sarebbe diverso, indicando questa volta che è in atto la riproduzione H.323 ed invitando gli utenti che facciano richieste successive ad attendere il rilascio delle risorse. Così, se in seguito sia un utente ohphone, sia un utente mp4live richiedessero la trasmissione, ad entrambi comparirebbe lo stesso messaggio.

 

IV.6.3.3 Modalità di funzionamento

Ritornando al solo mp4live, si supponga ora che le risorse siano libere e che quindi la riproduzione possa prendere inizio. Vediamo cosa accade.

Dopo avere costruito il file testmp4live, per prima cosa si costruisce il file di configurazione livetv, (di cui è mostrato un esempio in Appendice A) anche esso situato nella directory /tmp, in cui cè una colonna di parametri del tipo <nome>=<valore>; il nome, indicherà il tipo di configurazione da settare, ad esempio, con duration si intende la durata di riproduzione, con file0 il dispositivo audio, con file1 il dispositivo video e così via. Il valore invece sarà lopzione scelta per quel particolare tipo di configurazione; così, con duration="2" si comunicherà a mp4live la volontà di ricevere in streaming due minuti di televisione, il cui segnale audio dovrà essere reperito dal device /dev/dsp (file0="/dev/dsp") e il rispettivo segnale video dal /dev/video0 (file1="/dev/video1") e così via. Da notare, che nello script, alcune opzioni sono forzate su determinati valori, a differenza di altre, i cui valori invece sono importati dalle FORM della pagina web tramite CGI. Tutto ciò è stato necessario poiché realizzando uninterfaccia pubblica e quindi di fatto accessibile da chiunque, si doveva garantire un minimo di configurabilità, per evitare anche possibili manomissioni esterne.

I valori fissati sono oltre i tre visti in precedenza, anche il tipo di input audio (line), linput, il segnale ed il tuner video, lindice di lista dei canali (3 = canali nazionali italiani), linibizione della registrazione contemporanea del media e labilitazione invece della trasmissione RTP, lindirizzo, le porte ed il Ttl verso cui trasmettere il media ed infine il nome del file sdp da costruire in base alle configurazioni scelte.

Alla luce di quanto detto quindi, un utente che tramite pagina web selezioni le caratteristiche di trasmissione e riproduzione del media volute, in realtà fornisce soltanto alcune opzioni di configurazioni, quali il canale, il frame rate, il video bit rate, la dimensione del quadro, codifica audio, frequenza di campionamento, audio bit rate. Ma dire che un utente fornisce opzioni, significa che, tramite le FORM html nella pagina web, sarà associato a ciascun menù a tendine un nome a cui fornire come valore quello scelto nel menù.

Se ad esempio, lutente sceglie un frame rate 10, si crea una variabile videofr il cui valore è 10. Il CGI, importerà nello script tale valore mediante lassegnazione:

echo videoFrameRate="$FORM_videofr" >> /tmp/livetv

con la quale si appende (>>) nel file livetv la stringa videoFrameRate=10, poiché, la sintassi $FORM_videofr, come già detto, si riferisce al contenuto della variabile importata videofr.

Lo stesso meccanismo viene allora reiterato per tutte le stringhe necessarie alla realizzazione di un file di configurazione valido e completo. Da notare però che la scelta dellaudio bit rate è formalmente legata alla scelta della frequenza audio, infatti per frequenza 44100 Hz il minimo audio bit rate supportato dal codificatore è 56 kbps; quindi si è fatto in modo da forzare la riproduzione a 56 kbps qualora si fosse scelta la frequenza 44100 e audio rate a 8/16/24 kbps.

Una volta realizzato il file di configurazione, si è potuto dare inizio alla trasmissione; invocando a tal proposito un secondo file, tvlive.sh (il cui codice è mostrato in Appendice B), si commissiona a mp4live la costruzione del file sdp in funzione del file di configurazione appena realizzato mediante il comando:

/usr/local/bin/mp4live --file /tmp/livetv --sdp > /dev/null

Da notare come si dia in ingresso a mp4live il file livetv e gli si comandi di creare il file /tmp/capturedalinkare.sdp (come è appunto richiesto nello stesso file di configurazione dove è presente listruzione echo sdpFile="/tmp/capturedalinkare.sdp" >> /tmp/livetv ), mediante lopzione -- sdp.

In questo modo si crea il file capturedalinkare.sdp nella directory tmp e al quale, si fa puntare con un link simbolico, il file capture.sdp della directory /home/tomosan/tesi/helix/Content. Così facendo, quando lutente chiederà di instaurare una sessione RTSP per la visione del media utilizzando la URL rtsp://genni.ing.uniroma1.it/capture.sdp, il sistema operativo in realtà gli fornirà il file capturedalinkare.sdp.

Successivamente, viene è stato chiesto a mp4live di lanciare la trasmissione, rifornendo in ingresso il file di configurazione livetv e utilizzando le opzioni --automatic per imporre linizio istantaneo del play e --headless, in modo da evitare che parta anche linterfaccia grafica che naturalmente è inutile. A tal proposito, nel file tvlive.sh ci sarà il comando:

/usr/local/bin/mp4live --file /tmp/livetv --automatic --headless > /dev/null 2>&1.

Una volta che la trasmissione si è conclusa e che quindi mp4live si chiude, si comanda il rilascio del file testmp4live, in modo che un utente successivo che volesse utilizzare lapplicativo, non trovi il semaforo "rosso".

A questo punto, lesecuzione del programma shell continua, facendo apparire allutente una pagina web di dialogo con cui si dà la conferma dellinizio della trasmissione, comunicando inoltre anche le caratteristiche di riproduzione scelte e invitando ad aprire un player RTSP quale gmp4player (Linux) o QuickTime (Windows; Apple) per vedere il media. Contemporaneamente, si scrive nel file testmp4live il messaggio visualizzato in precedenza con cui si conferma loccupazione delle risorse. In questo modo, qualsiasi altro utente che volesse successivamente visualizzare la TV o utilizzare ohphone, avrebbe in risposta detto messaggio.

 

IV.6.3.4 Uccisione di un vecchio processo

Tutto quello che è stato detto finora riguarda il caso in cui un utente abbia cliccato sul tasto play, richiedendo quindi lavvio della trasmissione; come detto in precedenza, si è però trovato un metodo anche per comandare il termine di essa. Per tal fine si è così proceduto:

mediante le FORM, nella pagina HTML realizzata si è associato alla variabile "button" due possibili valori: play e reset. In questo modo se lutente clicca sul tasto play, button avrà valore play e da qui scaturiranno in seguito al controllo iniziale nello script, tutte le operazioni dette fino ad ora. Se invece viene cliccato il tasto reset, button avrà valore reset, quindi il pezzo di codice analizzato fino ad ora verrà bypassato per arrivare alla stringa:

if [ "$FORM_button" = reset ] then

con cui si controlla appunto il valore del campo button. Qualora lif dia esito positivo, si verifica per prima cosa che effettivamente ci sia una riproduzione da terminare, controllando lesistenza del file testmp4live; qualora esso non esista, viene detto allutente sotto forma di pagina web che la trasmissione non può essere resettata perché essa non esiste. Se invece esiste, viene fatto un kill del processo mp4live. Nella gestione di tale operazione però, è subito sorto un problema; quando infatti si abilita mp4live alla trasmissione, vengono creati più processi, tutti figli di un processo principale che ha chiamato tutti gli altri (processi threads), come si può facilmente controllare con il comando "ps axf" da riga di comando. A ciascuno di questi processi è associato un PID, identificativo del processo stesso, la cui conoscenza è fondamentale per "uccidere" lapplicazione. Esiste un comando sotto Linux, "kill", che permette di uccidere un processo, e che quindi è stato usato per detto scopo. Ma al kill deve seguire lindicazione di un PID, non di tutti, quindi è nata lesigenza di trovare il PID del processo padre, la cui uccisione avrebbe comportato luccisione di tutti gli altri e quindi dellintera applicazione. Rimaneva inoltre il problema di conoscere i PIDs dei processi padre e figli di mp4live; per tal proposito, si è utilizzato il comando, "pidof", che restituisce sotto forma di stringa i PIDs dellapplicazione in esecuzione, quindi leffetto del comando pidof mp4live è la restituzione sullo standard output della stringa dei PIDs, ad esempio 2326 2325 2324 2322 2321 2320. Il problema invece delluccisione del processo padre è stato superato nel modo seguente:

si crea in seguito alla richiesta di reset, un file pido.txt nella directory /temp, in cui viene redirezionata luscita del comando pidof, quindi in esso si scriverà la stringa di PIDs. Successivamente viene invocata lesecuzione di un programma C molto semplice, pido, che legge il file pido.txt e restituisce in un file di testo da esso creato, pidouno.txt, il PID del processo padre, che tra gli elementi della stringa è sempre lultimo della lista. In seguito, col comando:

read pidtokill < /tmp/pidouno.txt

si associa alla variabile di ambiente pidtokill, il valore contenuto nel file pidouno.txt, quindi il PID in questione, in modo da poterlo poi fornire al comando kill, mediante listruzione kill $pidtokill, e così uccidere il processo padre più tutti i figli. Da notare però, che per raffinare il meccanismo e renderlo più robusto allinteroperabilità con lohphone, si sono aggiunte le seguenti istruzioni:

if [ "$pidtokill" = 1073834212 ]

then

echo "<h3>non posso resettare la trasmissione della TV in quanto essa non è in atto!</h3>"

cat /tmp/testmp4live

Senza i comandi sopra scritti, qualora il file testmp4live fosse creato da ohphone e non da mp4live, in seguito ad una richiesta di reset televisivo, ci sarebbe stata una risposta del tipo "ho ucciso il processo con pid 1073834212", poiché, il pidof mp4live avrebbe fornito una stringa vuota, ma portando il programma pido ad interpretare erroneamente come pid padre il valore 1073834212. Ecco spiegato allora la necessità di rispondere, qualora fosse associato a pidtokill quel valore, di non poter essere in grado di resettare nulla, perché nulla di TV-on-Demand è in onda.

E comunque ovvio che qualora non fosse in esecuzione alcuna applicazione, quindi lif iniziale desse esito negativo, la risposta sarà inevitabilmente del tipo: "non è in atto alcun processo!".

IV.6.3.5 Gestione dei permessi

Una volta terminato lo script, prima di effettuare le prove di funzionamento, è stata necessaria compiere unoperazione molto particolare quanto importante. Si è accennato infatti al problema dei permessi per accedere a determinate directory degli utenti di un calcolatore in ambiente Linux. Il web server Apache, viene considerato un utente alla stessa stregua di un umano, quindi, gli viene inibita la possibilità di accedere ed in particolare di scrivere files in determinate directory.

Ecco perchè, i files creati dallo script e quindi da Apache, sono stati tutti posizionati in /tmp, poichè in tale directory, il web server ha il permesso ad accederci. Il problema in realtà era ben più complesso, poiché Apache deve comandare lavvio di un programma, mp4live, utilizzante i devices /dev/video0 e /dev/dsp, rispettivamente per il video e laudio, per i quali però non ha i permessi ad utilizzarli rendendo quindi vano il lancio del programma di cattura e trasmissione. Si è così arrivati alla soluzione di modificare detti permessi intervenendo nel file /etc/security/console.perms, in cui in corrispondenza di <sound> e <v4l> si è inserito il codice 666 in luogo di 600, dando la possibilità ai dispositivi video e audio di poter essere utilizzati da tutti gli utenti del computer genni, compreso naturalmente Apache.

 

IV.6.4 Valutazione delle prestazioni

Con le modifiche ai files di gestione dei permessi, si è così resa possibile linterazione tra il web server Apache e mp4live, allo scopo di far partire lo streaming in seguito alla richiesta di un client remoto. Il meccanismo di funzionamento illustrato precedentemente, viene mostrato in figura IV.6, dove vengono evidenziati i principali protagonisti del sistema.

Figura IV.6 Architettura di TV-on-Demand

Le prove di funzionamento hanno dato gli esiti previsti; in laboratorio, utilizzando come client su comel gmp4player, si è assistito alla perfetta riproduzione del media, naturalmente con un leggero ritardo dovuto alla codifica, elaborazione dei dati e trasmissione dei pacchetti da parte di mp4live-Darwin. Anche la sincronia audio/video funziona discretamente, evitando quindi di assistere al fastidioso problema di vedere prima le immagini e poi il suono o viceversa, mostrando quindi tutta la qualità di mp4live nel codificare il segnale TV grezzo, di Darwin nel pacchettizzare correttamente i dati nel flusso RTP e di gmp4player nel riprodurre fedelmente il media. Si è notato come sporadico inconveniente, lerrata o addirittura mancata riproduzione della sola componente audio, dovuta in parte al codificatore interno ad mp4live e in parte al decodificatore di gmp4player.

In generale, comunque, la codifica MP3 ha dato più garanzie, anche se nei casi di 2 canali e frequenza 44100 Hz con bit rate 56 e 96 kbps, si è registrata una riproduzione più veloce, dando luogo al caratteristico innalzamento del tono di voce del parlatore, seguito naturalmente dalla perdita definitiva di sincronizzazione.

Anche la codifica AAC ha, tutto sommato, superato i tests egregiamente, dato che su 14 combinazioni diverse, al variare di canali, frequenze e bit rate, in sole 4 occasioni si è avuta una inefficienza della riproduzione, dovuta comunque più al decodificatore che alla codifica stessa.LMP3, invece, come detto in sole due occasioni non si è rivelato allaltezza. Negli eventi negativi, da ethereal si è potuto evincere che i pacchetti audio sono giunti correttamente al client, il quale, probabilmente in funzione del carico elaborativo, o non sincronizza bene la traccia, dando luogo ad una riproduzione velocizzata, (come detto le parole si intuiscono ma il tono è più alto), oppure non comprende la descrizione SDP, inibendo la decodifica del codec.

Addirittura, come si può evincere dalla pagina web di richiesta, si può ottenere anche laudio a 16 kHz/8 kbps, un bit rate quindi bassissimo, che nonostante tutto permette ad un ascoltatore di discriminare le parole ed i suoni, anche se cè da dire che nel caso di codifica AAC, con detti parametri la qualità è migliore. Tutte le prove incrociate di trasmissione, quindi modificando in tutti i modi possibili le varie opzioni di configurazione, hanno avuto esito positivo rendendo di fatto il sistema utilizzabile anche da client con ridotte capacità di banda, quale un utente domestico con modem a 56 kbps, il quale potrà scegliere la configurazione più stringente, ad es. video bit rate 7 kbps e audio 8 kbps a 16 kHz per permettersi la visione e ascolto della TV anche a casa!

Inoltre si è rivelato la assoluta robustezza dellarchitettura nella gestione di richieste multiple, del reset e dei casi di interlavoro con la trasmissione di un canale TV in H.323 mediante ohphone, il tutto mediante limplementazione dei meccanismi a semaforo illustrati precedentemente.

Comunque, considerazioni più dettagliate sulla trasmissione dei pacchetti e sulla qualità di riproduzione verranno trattati nel prossimo capitolo.