TELEVISIONE DIGITALE SOLUZIONE DI STREAMING PER INTERNET A BANDA LARGA

Transcript

1 UNIVERSITÀ DI UDINE FACOLTÀ DI SCIENZE MATEMATICHE FISICHE NATURALI CORSO DI LAUREA IN INFORMATICA Anno Accademico TESI DI LAUREA SPERIMENTALE TELEVISIONE DIGITALE SOLUZIONE DI STREAMING PER INTERNET A BANDA LARGA Laureando: Federico Severin Relatore: Ch.mo Dott. Claudio Mirolo

2 2

3 INDICE CAPITOLO 1 : Introduzione 4 CAPITOLO 2 : Streaming 5 CAPITOLO 3 : Progetto : Requisiti : Analisi : Organizzazione generale 13 CAPITOLO 4 : Strumenti 14 CAPITOLO 5 : Caratteristiche tecniche : Dettagli tecnici di Helix Universal Server : Dettagli tecnici di Helix Producer Basic 9 23 CAPITOLO 6 : Realizzazione : Prima prova su PC : Installazione su PC appositi : Soluzione problemi con il server : Applicazione IP pubblico al server : Creazione dei client personalizzati : Client per un futuro cliente : Client per Asco Tlc 42 CAPITOLO 7 : Comunicazione tra Helix Producer Basic 9 ed Helix Universal 47 Server Basic 9 CAPITOLO 8 : Comunicazione tra Real Player 9 ed Helix Universal Server Basic 9 53 CAPITOLO 9 : Test, risultati, confronti : Test in locale : Test con cliente : Test con ADSL privata : Dimostrazione con un potenziale cliente : Conclusioni sull esito dei test 65 CONCLUSIONI 66 GLOSSARIO 67 BIBLIOGRAFIA 69 3

4 CAPITOLO 1 INTRODUZIONE Il concetto di streaming è poco conosciuto al giorno d oggi, nonostante venga impiegato sempre più spesso e per scopi sempre più vari. È una tecnologia innovativa che è destinata a far parte della nostra vita quotidiana in misura sempre maggiore, grazie anche all enorme diffusione di internet ed al continuo incremento della sua velocità. L esperienza del tirocinio mi ha dato l occasione di studiare questa tecnologia, apprenderne il funzionamento, apprezzarne le qualità e scoprirne i difetti. Questa tesi non è semplicemente il resoconto di un esperienza didatticolavorativa: ho cercato di approfondire il più possibile gli argomenti trattati, arrivando a volte a descrivere e spiegare le caratteristiche tecniche di mezzi e strumenti di cui mi sono avvalso. Comincio con un capitolo in cui definisco lo streaming, la struttura del processo con cui si trasmette un file multimediale nella rete in broadcasting, i vantaggi e gli svantaggi nell uso di tale tecnologia. Nel capitolo 3 ho sviluppato una descrizione dell organizzazione dei lavori condotta analizzando i requisiti dell azienda. Nel capitolo 4 ho elencato e descritto brevemente gli strumenti che mi hanno permesso di risolvere i problemi, semplificato lo sviluppo e consentito di svolgere accurate analisi. Il capitolo 5 è dedicato ad una descrizione tecnica dei due elementi principali di questo lavoro: Helix Universal Server ed Helix Producer Basic. Nel sesto capitolo racconto ed analizzo l esperienza maturata in azienda, dalle prime prove del server di streaming alla sua raffinazione, alla creazione delle tv embedded per vedere sia video on-demand che live. Il settimo ed ottavo capitolo riportano un analisi dettagliata ed approfondita dei protocolli di comunicazione server-client e server-producer. Numerosi screenshot arricchiscono questo approfondimento, che è stato di essenziale importanza per capire il funzionamento delle architetture in gioco e risolverne i problemi. Infine, nel capitolo 9, ho inserito alcuni semplici test eseguiti per determinare le prestazioni del sistema di streaming. 4

5 CAPITOLO 2 STREAMING Cosa si intende per streaming? Lo streaming è una tecnologia che permette di distribuire dati, audio, video e multimedia sulla rete, live o on-demand, senza il bisogno di scaricare file sul proprio computer. La distribuzione di multimedia in streaming consiste nella trasmissione simultanea di media digitali (quali video, voce, dati) in modo tale che siano ricevuti come un flusso continuo in tempo reale. Lo stream di dati viene trasmesso da un server ed è ricevuto da un client che lo riproduce in tempo reale. Le applicazioni client possono cominciare a riprodurre il multimedia appena hanno ricevuto abbastanza dati da riempire il buffer (operazione detta di preroll ) in modo da poter garantire la continuità del servizio in caso di perdita di dati. I protocolli coinvolti nello streaming sono principalmente l RTP e l RTSP (vedi Glossario). I passi principali in un processo che ha come scopo la trasmissione di un file multimediale in streaming nel web sono i seguenti: CATTURA AUDIO/VIDEO ED ACQUISIZIONE DEL SEGNALE CODIFICA DEL CONTENUTO CONSEGNA/DISTRIBUZIONE INTEGRAZIONE IN INTERFACCE WEB Figura 2.1 Cattura audio/video ed acquisizione del segnale: la prima cosa da fare è procurarsi il materiale da trasmettere. È dunque necessario catturare e registrare, tramite opportuni dispositivi (quali webcam, microfoni o schede di acquisizione audio/video), la clip desiderata. I dati catturati dai 5

6 dispositivi hardware devono essere trasmessi alla locazione in cui verranno codificati. La trasmissione può avvenire tramite satellite per esempio, o tramite un ponte telefonico. Varia a seconda del tipo di media e dei mezzi a disposizione. Codifica del contenuto: i dati acquisiti vengono convertiti da analogico a digitale e codificati nel formato più appropriato per poter essere poi distribuiti sulla rete. Nel nostro caso verrà usata la tecnica denominata Sure Streaming, con cui diversi flussi vengono codificati con tassi di trasferimento diversi e combinati in un singolo file. Consegna/distribuzione: è la fase in cui i dati codificati vengono inviati al server adibito alla loro distribuzione. Come si vedrà, i server odierni danno la possibilità di ricevere stream previa autenticazione, per ovvie ragioni legate alla sicurezza. Anche per visualizzare il contenuto in streaming può essere richiesta l autenticazione. La distribuzione del contenuto ai client può avvenire in due modalità: unicast e multicast. Verranno entrambe descritte nel capitolo 5, paragrafo 1. Integrazione in interfacce web: la distribuzione nel web di contenuti multimediali può essere operata inserendo in pagine web collegamenti che aprono automaticamente un lettore multimediale che riproduce il filmato. Alternativamente si può inserire direttamente in una pagina web uno schermo virtuale che riproduce il filmato e, qualora si voglia, dei controlli per consentire l interattività dell utente. Questa tecnologia innovativa rende le comunicazioni più efficaci premettendo, per esempio, di effettuare videoconferenze o la telefonia over IP. Strumenti molto utili nelle aziende odierne che, per svilupparsi ed essere competitive, necessitano di comunicazioni sempre più frequenti, rapide e ricche di informazioni. Sta prendendo piede, in ambito commerciale, anche in servizi rivolti verso utenti privati. Basti pensare alla martellante pubblicità in tv che reclama la possibilità di guardare le partite o le gare automobilistiche in streaming via internet. Possono altresì essere trasmessi in streaming anche alcuni video o trailer cinematografici o spezzoni di canzoni, o anche canzoni intere; infatti, non venendo memorizzato alcun dato sull hard disk, è possibile avere un anteprima o assaporare per intero il lavoro di un artista distribuito da un sito autorizzato, pur senza violare le normative concernenti il diritto d autore. Nello stesso tempo si evita di occupare grosse quantità di spazio sul disco del navigatore web. 6

7 Quanto a svantaggi, il più importante sembra essere il costo. Se si vuole adottare un server di streaming potente ed efficiente bisogna spendere qualche migliaio di euro, per non parlare della necessità di un computer dedicato molto potente e una connessione a banda larga. 7

8 CAPITOLO 3 PROGETTO Vado ora ad esporre il progetto vero e proprio. Verrà effettuata un analisi dei requisiti basata sulle esigenze dell azienda. Tali requisiti verranno poi analizzati e, in base a questi, sarà condotta un indagine sui prodotti disponibili sul mercato e operata una scelta basata sui criteri dettati dai requisiti. 3.1: REQUISITI L azienda aveva la necessità di un server che fosse in grado di trasmettere file multimediali. Un obiettivo era quello di poter vedere via web presentazioni, conferenze, convegni o simili organizzati dalla ditta; ma target forse più affascinante era quello di riuscire a creare un sistema che permettesse la trasmissione di immagini e/o suoni in un broadcast live. Tale sistema, permettendo di vedere real-time immagini e audio, sarebbe poi stato la base per lo sviluppo di un sistema di video-conferenza. Un sistema facilmente personalizzabile, grazie alla potenza della combinazione dei linguaggi HTML e SMIL: pagine web con il logo della società e un player embedded che supporta persino la visualizzazione di più videate contemporaneamente, nonché una chat per permettere la comunicazione istantanea di tutti i partecipanti all evento. Per raggiungere tali obiettivi erano necessari: Un pc linux su cui far girare il server. Una distribuzione di linux. Un server per lo streaming. Un pc dal quale catturare le immagini live ed inviarle al server a seguito della codifica. Una webcam per catturare i filmati. Un software di codifica delle immagini. Collegamento dei due computer alla rete locale. Collegamento dei computer alla rete Internet. Un player multimediale per la parte client dello streaming. 8

9 3.2: ANALISI Viene ora il momento dell analisi dei requisiti e delle alternative che il mercato propone per soddisfarle. Una fase molto importante durante la quale si scelgono gli strumenti che ci condizioneranno durante la progettazione e ci supporteranno durante lo sviluppo. Mi sono stati messi a disposizione due pc Dell Optiplex, 2.8 GHz, 1GB di ram. In uno ho installato Windows XP Service Pack 2, fornito dalla Dell insieme alla macchina. Nel secondo pc, quello dedicato al server, come sistema operativo si è deciso di usare Linux per la sua comprovata stabilità e la sua sicurezza. Il problema si poneva riguardo quale distribuzione scegliere. Su consiglio del mio tutor aziendale, ho scelto di usare QiLinux 1.2 (kernel ), una distribuzione di recente comparsa e basata su Debian, gratuita e scaricabile dal web. Per la cattura di suoni e immagini mi è stata messa a disposizione una webcam USB Logitech QuickCam Pro I due computer sono stati connessi entrambi alla rete aziendale. Accedevano ad internet tramite il router dislocato nella server farm. La scelta di server, client e producer (il programma per la codifica) è stata invece più complessa. Serviva un prodotto che fosse in grado di supportare più stream contemporaneamente e più client contemporaneamente, oltre che gli stream live. Le soluzioni presenti sul mercato sono innumerevoli, ma molte sono a pagamento e a prezzi che si aggirano intorno ai 5000 euro per i prodotti più raffinati. L azienda invece, non necessitando di strumenti particolarmente sofisticati né potenti, si poteva accontentare del servizio che è in grado di fornire un software gratuito ed open source. Il campo della ricerca si restringeva così a pochi prodotti gratuiti ma di buona qualità, sviluppati da alcune tra le case più conosciute nel mondo dell informatica. Avevo individuato fondamentalmente tre candidati. Il primo era Helix Universal Server Basic, sviluppato dalla RealNetworks. Il secondo candidato era Helix DNA Server, sviluppato da Helix Community in collaborazione con RealNetworks. Infine Darwin Streaming Server, versione gratuita di Apple Quick Time Streaming Server. Ho cercato a lungo informazioni su questi programmi. Riguardo Darwin Streaming Server non ho trovato molte informazioni, mentre su Helix Universal Server ho trovato molta documentazione on-line. In particolar modo mi ha colpito un documento reperito dal sito della RealNetworks che riporta un test comparativo della KeyLabs tra i server di streaming Helix Universal Server e Windows Media Technology (WMT) 4.1. Sebbene il test sia relativamente vecchio (è stato realizzato nel giugno 2002 e con tecnologia Dual Intel Pentium III Xeon 700 9

10 MHz 2 GB di memoria RAM per i server) indica che, oltre a supportare oltre il doppio delle connessioni client rispetto a WMT 4.1 sotto Windows, Helix Universal Server arriva addirittura a duplicare le sue stesse capacità quando gira sotto Red Hat Linux. Riporto qui sotto tabelle e grafici comparativi tratti dal report della KeyLabs. Figura Come si può vedere, la prima tabella (in figura 3.2.1) compara le prestazioni dei due programmi sotto Windows e mostra poi le prestazioni di Helix Universal Server anche sotto Linux. Si nota subito la differenza anche tra le stesse performance del server della RealNetworks con i due sistemi operativi. Differenza rimarcata anche dalla seconda e terza tabella, che le traducono in termini percentuali. La seconda tabella mostra la superiorità di Helix Universal Server rispetto al prodotto della Microsoft a parità di condizioni (stesso hardware e stesso sistema operativo). La terza tabella, invece, rimarca il divario nelle prestazioni di Helix Universal Server in ambiente 10

11 Linux rispetto a WMT, che è stato sviluppato solo per Windows. Tutte e tre le tabelle si riferiscono a test svolti trasmettendo file multimediali in formato Windows Media 8. Il grafico in figura rappresenta con efficacia le dimensioni riportate dalle tabelle e dà una chiara idea del gap tra i due prodotti. Figura Ma i tecnici della KeyLabs non si sono fermati qui: hanno anche testato Helix Universal Server usando file multimediali nel formato RealNetworks Version 9, ossia nel formato proprietario della RealNetworks. Com è logico aspettarsi, le prestazioni sono ancora migliori. I dati nella figura 3.2.3: 11

12 Figura Pur consapevole che questi dati sono, come detto prima, relativamente vecchi e pur sapendo che il prodotto della Apple poteva essere una valida alternativa, ho considerato l esperienza della KeyLabs nel campo dei benchmark ed ho pensato che il prodotto della RealNetworks poteva essere una buona soluzione per l azienda. A questo punto ho preso in considerazione il prodotto offerto dalla Helix Community. Questa comunità, aperta a tutti, sviluppa software open-source per piattaforme multimediali con la collaborazione della RealNetworks. Questo significava che avrei potuto avere a disposizione la tecnologia di una delle compagnie leader nel settore del multimedia unitamente al supporto di un vasto team di sviluppatori e appassionati. Il sito infatti mette a disposizione newsletter, forum e persino chat in cui si possono trovare suggerimenti e porre domande. Ho così optato per Helix DNA Server come server di streaming. Di conseguenza ho 12

13 usato Helix Producer Basic 9 (gratuito) e il player multimediale (anch esso gratuito) Real Player : ORGANIZZAZIONE GENERALE Spiego ora come ho deciso di procedere. Prima di tutto dovevo montare e testatare i pc comprati appositamente per lo scopo. Uno l avrei usato come server; l altro come client, postazione di cattura e codifica delle immagini nonché come postazione di sviluppo per il client personalizzato. Nelle due macchine era installato Windows XP come sistema operativo ma era un installazione personalizzata creata dalla Dell. Ho subito riscontrato anomalie ed instabilità nel comportamento del sistema operativo, così che ho deciso di reinstallarlo. Nella macchina adibita a client avrei reinstallato Windows XP Service Pack 2 e l avrei protetto con un antivirus (AVG) e un firewall (Sygate) che si trovano gratuiti su inernet. In seguito avrei proceduto con l installazione della webcam e di Helix Producer Basic. Nel pc adibito a server invece dovevo installare QiLinux e la versione 11 beta 2 di Helix DNA Server. Una volta installato il binario del server, avrei provato per prima cosa lo streaming on demand per testare il funzionamento del software. In un secondo momento, dopo essermi sincerato dell efficienza del server, sarebbe stato il momento di provare con lo streaming live. Appena reso operativo uno stream live, misurare eventuali ritardi. Impostare per il server un IP pubblico e verificarne il funzionamento. Costruire un client personalizzato con un player embedded su pagina web. 13

14 CAPITOLO 4 STRUMENTI Oltre ai sistemi operativi, al server, al client e al producer già citati nel paragrafo 3.2, mi sono avvalso di alcuni strumenti che vado ad elencare qui sotto. IPTraf: utility di Linux che fornisce statistiche ed informazioni importanti sulle connessioni TCP aperte e sul traffico UDP che passa attraverso l interfaccia di rete. Lo vedremo nel dettaglio in un esempio pratico nel capitolo 5. Ethereal: programma simile a IPTraf, mi è stato molto utile nel monitorare il traffico lato client. Specificata un interfaccia di rete, è sufficiente premere start per far iniziare la cattura dei pacchetti che attraversano la rete. A differenza di IPTraf, Ethereal cattura pacchetti solo per un lasso di tempo stabilito dall utente. Infatti bisogna premere stop per interrompere lo sniffing e poter visualizzare i risultati, mentre IPTraf usa una finestra a scorrimento dove i pacchetti nuovi compaiono in fondo e quelli vecchi, se non ci stanno più, scompaiono dalla visuale. Non si può salvare nessuna informazione con IPTraf, mentre Ethereal permette di salvare le informazioni catturate. Questa opportunità mi è stata molto utile per poter studiare con calma la composizione del traffico. Ethereal inoltre fornisce molte più informazioni di IPTraf sui singoli pacchetti. Quest ultimo infatti fornisce solamente la dimensione del pacchetto, l origine e la destinazione. Ethereal invece scompone ogni pacchetto in tutte le sue parti (per esempio header, flag, payload, codice di correzione degli errori) specificando la dimensione di ciascuna parte e i valori che essa assume. Se vengono trasmessi dati umanamente leggibili, come stringhe di testo, Ethereal le visualizza. Nei capitoli 7 e 8 dimostrerò come questo utilissimo strumento mi abbia permesso di studiare il protocollo di comunicazione tra il producer e il server e tra il client e il server. Dreamweaver: strumento molto potente per la realizzazione di siti web creato dalla Macromedia, mi è stato utile per creare le pagine web dei client. Mi è tornato utile per impostare la struttura delle pagine in modo semplice e veloce grazie alla creazione semplificata delle tabelle e dei frame, ma il resto del lavoro ho preferito svolgerlo utilizzando direttamente il codice HTML. WordPad: come ho appena detto, ho editato buona parte del codice HTML a mano. Questo semplice strumento, presente ormai di default in Windows, mi ha permesso di scrivere il codice agilmente grazie alla sua semplicità e rapidità. La sua leggerezza si fa apprezzare quando bisogna apportare poche modifiche in varie pagine e bisogna saltare 14

15 da una all altra aprendole per editarne il sorgente. La formattazione del testo è altresì utile per strutturare il codice in modo da renderlo più comprensibile e più accessibile anche a terzi. Webmin: pratico strumento per l amministrazione della rete. Molto apprezzato dai sistemisti per la sua intuitività dovuta ad un accattivante interfaccia grafica che permette di trovare immediatamente le risorse, ben divise per categorie, e modificarne i parametri di configurazione. 15

16 CAPITOLO 5 CARATTERISTICHE TECNICHE 5.1: DETTAGLI TECNICI DI HELIX UNIVERSAL SERVER 9 1. Formati supportati: RealNetworks: RealAudio (.rm), RealVideo (.rm,.rmvb), RealPix (.rp), RealText (.rt) Macromedia: Flash (.swf) Microsoft: Windows Media (.asf,.wma,.wmv) Apple: QuickTime (.mov) Standards-Based: MPEG-1, MPEG-4, MP3 Image Formats: GIF (.gif), JPEG (.jpg, jpeg), PNG (.png) Altri: AU (.au), AIFF (.aif,.ief), WAV (.wav) 2. Protocolli supportati: Real Time Streaming Protocol (RTSP) Progressive Networks Audio (PNA): vecchio protocollo usato dalla Real, mantenuto per questioni di compatibilità. Microsoft Media Services (MMS) HyperText Transfer Protocol (HTTP): non è un protocollo di streaming ma è utilizzato in vari modi, come la consegna delle pagine web di Helix Administrator che permettono la configurazione del server, o per aggirare le restrizioni dei firewall tramite cloaking. 3. Aliasing: tecnica grazie alla quale il server maschera l URL pubblico in cui si trova il file richiesto. 4. Content Caching (figura 5.1.1): il media player richiede il file ad un server detto subscriber che controlla se nella sua cache è già presente il file. Se non c è, lo richiede ad un server publisher che gli manda tutto o parte del file. In genere il subscriber richiede una quantità di dati che dipende dalla velocità di trasferimento del client in modo da risparmiare spazio della cache. Questa viene svuotata usando una politica LRU. Se il file viene cancellato sul publisher, non viene più trasmesso dal subscriber, anche se si trova ancora nella cache. Nel caso vi siano un cluster di server publisher, le richieste 16

17 vengono inoltrate con una politica di DNS rotation o Round Robin DNS per distribuire il carico. Figura Custom Logging: sistema flessibile che permette di creare report personalizzati. 6. SLTA: Simulated Live Transfer Agent. Utility che permette di riprodurre in streaming una clip video come se fosse un evento live. 7. RTSP Cache Directives: la possibilità di imporre restrizioni ai server Helix Universal Proxy riguardo la memorizzazione nella cache delle clip. 8. Redundant Servers (figura 5.1.2): ridondanza dell informazione da spedire. In caso di interruzione del collegamento con il server (ad esempio a causa di un guasto sul server o sulla linea), RealOne Player è in grado, grazie ad una lista di server alternativi fornita durante il set-up del collegamento, di stabilire una nuova connessione con un altro server scegliendo a caso tra quelli disponibili. 17

18 Figura Windows Media Streaming: usando MMS (Microsoft Media Services protocol) o HTTP invia in streaming anche file in formato Windows Media. 10. RTP-Delivered Formats: il formato RTS per i pacchetti è usato come standard di default con Quick Time e MPEG e opzionalmente con Real Media. Questo formato permette di trasmettere le clip sfruttando il protocollo RTSP. 11. SureStream Splitting (figura 5.1.3): vengono inviate al client man mano parti del file le cui dimensioni dipendono dal suo bit-rate. Figura

19 Il server sceglie il bitrate in base alla stima iniziale che Real Player gli invia tramite il protocollo RTSP. In seguito adatta il rate in base alle condizioni della rete per evitare la perdita di troppi dati che causerebbe il blocco della riproduzione. 12. RealOne Player Statistics: informazioni su stream aperti e bit-rate dei client connessi. 13. Distributed Licensing: un gruppo di server della stessa organizzazione che condividono dei files possono condividerne anche l eventuale licenza, le cui informazioni sono generalmente mantenute su un server publisher primario. 14. Port Hinting: per i client che ricevono dati da Helix Universal Server solo attraverso HTTP cloaking per passare attraverso un firewall, il numero di porta non è più quello standard del protocollo RTSP (che viene bloccata dal firewall) ma la 80 dell HTTP. Quindi si fornisce tramite l URL la porta corretta. 15. HTTP Cloaking: alcuni firewall limitano protocolli di streaming come RTSP o MMS e il client non riesce a stabilire la connessione. In questi casi, il client e il server mascherano il traffico multimediale come HTTP, una soluzione conosciuta come HTTP cloaking. Poichè la maggior parte dei firewall lascia passare il traffico HTTP, questa soluzione risolve il problema. Tuttavia HTTP non è stato progettato per lo streaming e gli utenti non ottengono la massima qualità dallo stream. I client RTSP usano due stream HTTP per connettersi ad un unico Helix Universal Server. La prima connessione sfrutta il comando HTTP GET, usato per richiedere una Web page. Helix Universal Server elimina il mascheramento HTTP e usa le informazioni RTSP incapsulate per determinare quali informazioni mandare al client. Helix Universal Server quindi aspetta la seconda connessione HTTP dallo stesso client per poter procedere con lo streaming del media. Questa seconda connessione usa il comando standard per richiedere dati da un server HTTP: HTTP POST. Una volta che il client ha stabilito questi due stream, inizia con Helix Universal Server a passarsi pacchetti RTSP in due direzioni, attraverso un firewall che blocca il traffico RTSP. 16. Redundant Encoders (figura 5.1.4): ridondanza dei codificatori dei file multimediali da inviare in streaming. Se un codificatore va in crash ce n è subito pronto uno alternativo. 19

20 Figura Unicasting (figura 5.1.5): è il modo più semplice per trasmettere uno stream live. Il server invia ad ogni player multimediale uno stream distinto. Con questa tecnica può trasmettere sia un evento live che un media on-demand. Gli stream separati consentono ad ogni client di interagire con esso come se si stesse guardando un filmato in locale, quindi controllandone la riproduzione per esempio mettendola in pausa o saltando ad un punto preciso. Figura Multicasting: a differenza dell unicast, la tecnica del multicasting trasmette il media su di un unico stream al quale possono collegarsi più utenti contemporaneamente. La figura mostra una tipica situazione di streaming multicast. 20

21 Figura Nonostante siano tutti collegati allo stesso stream, ciascun client può mantenere un canale di controllo con il server che permette di inviare comandi come stop, inviare statistiche all archivio dei log, inviare i dati necessari ad un eventuale autenticazione, tenere traccia nel server del numero di client connessi che, vista l onerosità implicita nel mantenimento del canale, sarà limitato. Questa tecnica è detta back-channel multicasting (figura 5.1.7). Figura Utilizzando invece la tecnica scalable multicasting (figura 5.1.8) non viene mantenuto un canale di controllo e si può trasmettere ad un numero illimitato di player multimediali. La comunicazione infatti è unidirezionale, usa una porzione minore di banda, impegna 21

22 meno risorse di sistema del server e si ha minore overhead amministrativo. Ovviamente non sarà possibile ricevere statistiche né sapere quanti client sono connessi. Figura Tabella riassuntiva: la tabella riassume le caratteristiche di Helix Universal Server mostrando i servizi che è in grado di offrire a seconda del formato del media trattato. 22

23 Helix Universal Server Feature Windows Media Apple QuickTime RTP- Based HTTP cloaking for firewalls yes no no Launch utility for Web page links yes no no Aliases in URLs yes yes yes Viewable clip source information no no no Reconnection to a redundant server no no no Cached content yes yes yes Proxied on-demand and live streams yes yes yes Unicasting yes yes yes Redundant live stream encoders yes yes yes Back-channel multicasting no no no Scalable multicasting yes yes yes Splitting from transmitter to receiver yes yes yes Simulated live broadcasts yes yes yes Access control by IP address yes yes yes User name and password validation no yes no Media player ID validation no no no SMIL-based ad insertion no no no Access request logging yes yes yes Custom logging reports yes yes yes Online activity monitoring yes yes yes Tabella : DETTAGLI TECNICI DI HELIX PRODUCER BASIC 9 Helix Producer è un programma che serve per codificare e comprimere i dati audio e video che arrivano da una sorgente (quale potrebbe essere una webcam) preparandoli per la trasmissione al 23

24 server di streaming. Non solo: è anche in grado di convertire vari formati di file in modo da poterli poi trasmettere con Helix Universal Server. Helix Producer Basic supporta i seguenti tipi di file: AIFF Files: *.aif; *.aifc; *.aiff AVI Files: *.avi Digital Video Files: *.dv MPEG: *.mpg; *.mpeg; *.m1v; *.mp2; *.mp3 NeXT Sound Files: *.snd QuickTime Files: *.mov; *.qt Sun Audio Files: *.au WAV Files: *.wav Windows Meta Files: *.wma; *.wmf; *.wmv La figura mostra la schermata principale di Helix Producer: Figura

25 Nella parte di sinistra si sceglie la sorgente per l audio e per il video, che sono mantenute distinte dando la possibilità, per esempio, di creare un video con una colonna sonora musicale anziché con l audio originale. In alternativa si prende in input un file. In tal caso il file verrà convertito nel formato rm. C è anche la possibilità di limitare la cattura audio/video con un tempo preimpostato. Il pulsante Video Filters nella parte di destra apre una finestra nella quale si possono impostare vari filtri quali noise filter, resize filter, inverse-telecine e de-interlace filter. In Clip Information si possono invece impostare informazioni riguardanti la clip, come la provenienza, il genere e altre. Molto più interessante è il pulsante Audiences che consente di scegliere fino a tre bitrate ai quali codificare la clip (nella versione Plus si possono codificare infiniti bitrate). Il Sure Splitting si può così garantire grazie alla codifica a più bitrate dello stesso file. In genere codificavo il bitrate della clip per un modem a 56 Kbps (34 Kbps effettivi per la trasmissione della clip in streaming), una ISDN a 128 Kbps (100 Kbps effettivi) e un ADSL a 500 Kbps (450 Kbps effettivi). La figura mostra come appare l interfaccia che permette di impostare i suddetti parametri: Figura

26 Sempre sulla destra (della figura 5.2.1) si trova un pulsante con l icona di un server che apre una finestra di dialogo nella quale inserire i dati del server di destinazione della clip. Dati quali indirizzo IP, porta di destinazione, nome del file di destinazione, eventuale mount point ed eventuali user name e password. Gli ultimi due non sono richiesti per tutti i tipi di broadcast. Ecco nel dettaglio quali sono le modalità di broadcast e in cosa consistono. Account-Based Push Broadcast (figura 5.2.3): è la modalità standard di trasmettere all audience attraverso il server i media codificati. Il vantaggio principale del metodo Push è che i dati vengono appunto spinti dentro il server continuamente, quindi un client che si collega non deve aspettare che il producer si colleghi al server (come nel metodo Pull) e non subirà alcun ritardo. Ecco cosa succede: Figura Al passo 1 il producer si collega al server ed invia user name e password. Al passo 2 il server dà la conferma della avvenuta connessione e delle modalità di trasmissione dei pacchetti (come le porte alle quali indirizzarli). Al passo 3 il producer inizia la trasmissione dei dati, sia che un client li abbia chiesti o no. Al passo 4 vi è un client che si collega al server e richiede lo stream. Al passo 5 il server invia i dati al client che li decodifica e riproduce. Questa è la modalità che ho scelto di usare per la semplicità e sicurezza, oltre ai bassi tempi di latenza e dato che non sussistevano problemi di spazio su disco nel server. La comunicazione tra producer e server e tra client e server sarà approfondita nei capitoli 7 e 8. 26