Document

Università degli studi di Padova
Facoltà di scienze MM. FF. NN.
Laurea in Informatica
Progettazione di una piattaforma per lo
streaming video e la sincronizzazione di
contenuti multimediali
Laureando: Roberto Baldin
Matricola: 561592
Relatore: Dott.ssa Ombretta Gaggi
Anno accademico 2008/2009
Indice
1 Introduzione
1
1.1
Descrizione dell’azienda QBGROUP . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Descrizione dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Streaming server
2.1
2.2
2.3
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Concetto di streaming, storia e protocolli . . . . . . . . . . . . . . .
5
2.1.2
Confronto tra progressive download, pseudo streaming e
streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Scelta del server di streaming . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1
Configurazione hardware e software del server . . . . . . . . . . . . .
7
2.2.2
Soluzioni individuate . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.3
Installazione di Adobe Flash Media Streaming Server . . . . . . . .
8
2.2.4
Installazione di Red5 Media Server . . . . . . . . . . . . . . . . . . . 11
2.2.5
Installazione di Windows Media Services . . . . . . . . . . . . . . . . 15
2.2.6
Confronto tra le soluzioni e benchmark . . . . . . . . . . . . . . . . . 16
Completamento configurazione del server di streaming . . . . . . . . . . . . 17
2.3.1
Problematiche di accessibilità dei contenuti . . . . . . . . . . . . . . 17
2.3.2
Scelta del client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3
Formati e caratteristiche dei video . . . . . . . . . . . . . . . . . . . 21
2.3.4
Automazione della procedura di conversione . . . . . . . . . . . . . . 25
3 Sincronizzazione di contenuti multimediali
3.1
5
31
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1
Strumenti e tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . 32
3.1.2
SMIL: Synchronized Multimedia Integration Language . . . . . . . . 36
i
3.2
Sviluppo di un’applicazione web per la sincronizzazione di contenuti multimediali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1
Sviluppo di un’applicazione per la sincronizzazione tra video e slide
39
3.2.2
Sviluppo di un player SMIL per il web . . . . . . . . . . . . . . . . . 46
4 Conclusioni
57
Ringraziamenti
59
ii
Capitolo 1
Introduzione
Negli ultimi anni, si è assistito ad un interesse crescente verso le tecnologie per lo streaming di contenuti multimediali attraverso la rete ed, in particolare, attraverso Internet;
la diffusione della banda larga e l’aumento delle prestazioni dei calcolatori ne sono stati
contemporaneamente la causa e l’effetto. Aree applicative come e-learning, entertainment
e telemedicina sono solo alcuni degli esempi dove streaming e video on-demand risultano
di rilevanza critica, ma in molti altri campi queste tecnologie si stanno facendo avanti,
rivestendo sempre maggiore interesse per le aziende.
1.1
Descrizione dell’azienda QBGROUP
L’azienda QBGROUP [1] lavora nel settore della sanità. La principale caratteristica,
che le permette di differenziarsi dalle altre nello stesso ambito, consiste nella particolare
attenzione che dedica alle nuove tecnologie. I clienti dell’azienda possono essere riassunti
in aziende farmaceutiche, società scientifiche, strutture sanitarie pubbliche e private, e
altri enti o aziende che operano nell’ambito medicosanitario. Per rispondere in modo
mirato alle esigenze dei clienti, QBGROUP è formata da cinque divisioni specializzate che
collaborano tra loro:
• etiCRO: studi e ricerche
• Medilon: strategie Internet
• CAtedra: formazione
• Telèmesys: strumenti e telemedicina
• QUBIsoft: tecnologie informatiche
In particolare, etiCRO può essere definita come una Contract Research Organization,
ovvero un’organizzazione di servizio che offre appoggio all’industria farmaceutica/biotecnica. Si focalizza principalmente nell’epidemiologia clinica, nelle ricerche osservazionali e
negli studi di management sanitario. Medilon si occupa di realizzare siti internet italiani
all’avanguardia per la medicina specialistica, i pazienti e le società scientifiche. CAtedra è
la divisione specializzata nella realizzazione di corsi e percorsi di aggiornamento e approfondimento rivolti ai medici e agli operatori sanitari. Rivolge particolare attenzione alle
1
nuove tecnologie, utilizzandole per fornire una formazione innovativa. Telèmesys concentra
l’attenzione nella progettazione, realizzazione e distribuzione di strumenti elettromedicali,
atti soprattutto al telemonitoraggio di pazienti con patologie croniche. Utilizza la rete
Internet per la trasmissione, la visualizzazione e l’analisi dei dati. Infine QUBIsoft è la divisione il cui compito è progettare e sviluppare tecnologie informatiche in ambito sanitario.
QUBIsoft agisce sia per clienti esterni, rispondendo adeguatamente ai bisogni del mondo
sanitario, sia per l’azienda stessa, studiando e implementando le tecnologie informatiche
a supporto dei progetti sviluppati da QBGROUP.
1.2
Descrizione dello stage
Sono molti i campi applicativi in cui le soluzioni di streaming di contenuti multimediali,
sia live che on-demand, risultanto di grande interesse per l’azienda QBGROUP. Lo stage
nasce però inizialmente dall’esigenza di aggiornare la propria offerta relativa ad un portale
web: eDott [2].
eDott è un portale dedicato alla formazione e all’aggiornamento dei medici, nato nel
2000 e che conta oggi oltre 30 mila utenti registrati. Sin dalla nascita, il portale offre ai
visitatori gran parte dei contenuti in formato video, siano essi corsi di formazione, interviste a esperti di rilievo in ambiente medico, presentazioni di nuovi farmaci o registrazioni di
convegni. Attualmente il portale offre questo tipo di contenuti utilizzando la tecnica progressive download, che consente unicamente un accesso sequenziale ai dati: in pratica non
è possibile, usando questa tecnica, scegliere arbitrariamente dove iniziare la riproduzione
del video senza prima scaricare tutti i dati dall’inizio del video sino al punto scelto. Negli
ultimi anni però l’aspettativa dell’utente è cresciuta e QBGROUP ha deciso di allineare la
sua offerta a quella dei grandi portali e delle community di condivisione video. L’azienda
non può in effetti sfruttare le funzionalità offerte da questi portali, trattando materiale
relativo all’ambito medico che non può essere reso pubblico indiscriminatamente. In questo campo, l’adozione di un server di streaming consente maggior controllo sugli accessi e
quindi maggior sicurezza; inoltre usando una tecnologia di streaming, il client, al termine della visualizzazione, non ha una copia del media sul proprio computer. Non ultimo,
l’aggiornamento dell’offerta permetterebbe anche di ospitare trasmissioni live e non solo
on-demand.
Lo stage si prefigge in primo luogo l’obiettivo di studiare le soluzioni esistenti in materia
di streaming server, scegliere e quindi provare sul campo le opzioni ritenute più valide, in
merito a prestazioni, costi, scalabilità e flessibilità. Una seconda fase prevede lo studio delle
problematiche di accessibilità dei contenuti multimediali; in questo caso con accessibilità
si intendono in particolare le limitazioni dovute all’infrastruttura tecnologica con cui si
intende accedere ai contenuti, quindi configurazione del client e configurazione della rete.
L’ultima fase di questa prima parte di stage prevede infine lo studio delle caratteristiche
dei video da pubblicare. La scelta del formato e di altre caratteristiche, quali ad esempio
il bitrate di codifica, non sono infatti da trascurare e dovrebbero essere commisurate al
traffico reale di visitatori. Scelti questi parametri, si intende infine realizzare una procedura
per automatizzare le operazioni di conversione.
Per provare in maniera adeguata quanto svolto nella prima parte di stage, si è deciso
di realizzare un piccolo applicativo di interesse per l’azienda. L’esigenza è quella di crea2
re un software per la sincronizzazione di video e slide, che faccia naturalmente uso delle
tecnologie opportunamente approntate in precedenza e che sia il più accessibile possibile;
anche in questo caso il termine accessibile è usato per indicare la volontà di raggiungere il
massimo numero di utenti, indipendentemente dalla piattaforma di lavoro. L’ultima fase
dello stage, inizialmente non prevista nel piano, ha visto il potenziamento dell’applicativo
creato in precedenza, fino a renderlo un player in grado di interpretare un sottoinsieme
del linguaggio SMIL.
Di seguito sono esposti due diagrammi Gantt con il piano preventivo dello stage, uno
relativo alla prima parte e l’altro relativo alla seconda.
Figura 1.1: piano preventivo della prima parte dello stage
Durante il primo periodo dello stage il lavoro è stato incentrato principalmente sull’installazione, la configurazione e il test del server di streaming.
Rispetto a quanto previsto nel piano vi sono state poche variazioni; si sono verificati infatti
alcuni piccoli ritardi in alcune attività, che sono però stati compensati da altre attività
che si sono svolte in minor tempo. Alla fine si è scelto tra l’altro di installare e studiare
tre diverse soluzioni di streaming e non due, come inizialmente preventivato.
Figura 1.2: piano preventivo della seconda parte dello stage
Nella seconda parte dello stage ci si è concentrati principalmente su aspetti più applicativi
e si sono in particolare sviluppati alcuni software che fanno uso del server di streaming
predisposto precedentemente. In questo caso si sono verificati dei forti ritardi iniziali dovuti ad alcuni problemi esterni e non prevedibili (vedi paragrafo 2.2.4). Per poter tornare
in linea con il piano è stato necessario accelerare alcune attività ed eliminarne una, considerata di minor importanza. Inizialmente si era infatti previsto di sviluppare un sistema
che permettesse agli utenti di caricare i propri video in uno spazio web apposito; in seguito quest’attività è stata eliminata, in quanto l’azienda dispone già di alcune applicazioni
dedicate all’upload di contenuti sul web, e sarebbe sufficiente adattare una di queste per
ottenere il servizio voluto, senza svilupparne un’applicazione da zero.
Alla fine si è avanzato del tempo rispetto al piano iniziale, perciò si è creato lo spazio
CAPITOLO 1. INTRODUZIONE
3
necessario per un’ultima attività di interesse per l’azienda e cioè lo sviluppo del player
web per SMIL; per poterla completare è stato però necessario prolungare lo stage di una
settimana.
4
Capitolo 2
Streaming server
2.1
2.1.1
Introduzione
Concetto di streaming, storia e protocolli
Il termine stream indica, in ambito multimediale, un flusso di dati; la terminologia usa
la metafora di un flusso d’acqua che si sposta attraverso delle condutture, espandendosi
e riducendosi a seconda della dimensione delle stesse. In maniera simile, il media inizialmente presente sul server di streaming viene spezzato in diversi pacchetti più piccoli
(detti appunto stream), poi è trasmesso attraverso la rete e quando giunge a destinazione
è decompresso e infine riprodotto. Il vantaggio principale nell’utilizzo di una trasmissione
in streaming è quello di non dover attendere di ricevere interamente il media prima di
poter iniziare la riproduzione; per questo scopo sono state comunque realizzate alcune
tecniche in grado di lavorare con HTTP e che saranno discusse più approfonditamente nel
paragrafo 2.1.2.
Nel campo della trasmissione di contenuti multimediali, le tecnologie di streaming hanno cominciato a diffondersi solo nella seconda metà degli anni novanta. In precedenza per
distribuire questo tipo di contenuti, la soluzione più comune era quella di rendere disponibili i file per lo scaricamento tramite l’utilizzo di un server web. I limiti di questa soluzione
erano già noti da tempo, ma per poter migliorare l’offerta era necessario prima potenziare
fortemente le infrastrutture sottostanti, in particolare per quanto riguarda l’ampiezza di
banda e la potenza dei calcolatori (in termini di velocità di calcolo e di trasferimento dati
nel bus).
Quando le condizioni furono favorevoli, l’interesse per questa tecnologia crebbe fortemente. HTTP si rivelò essere inadatto alle trasmissioni in streaming, per cui furono
ideati opportunamente alcuni protocolli a livello di applicazione. Il più celebre fu Real
Time Streaming Protocol (RTSP), ideato nel 1998 da IETF e pubblicato nella RFC2326
[3]. RTSP lavora in congiunzione con altri due protocolli: Real-time Transport Protocol
(RTP), che si occupa dell’effettiva trasmissione del flusso di dati e Real-Time Control
Protocol (RTCP) che si occupa del controllo e della qualità di servizio (QoS)1 . Real Time Streaming Protocol offre dei comandi simili a quelli di un videoregistratore; oltre ai
normali comandi di setup iniziale, ci sono infatti
1
Il termine qualità di servizio indica alcuni parametri di rete, quali banda, ritardo, jitter, probabilità
di perdita di pacchetti, ecc. Tali parametri sono utili nell’inizializzazione della connessione.
5
• PLAY, che richiede la riproduzione di un media
• PAUSE, che ferma temporaneamente la riproduzione
• TEARDOWN, che ferma definitivamente la riproduzione e chiude la connessione
(STOP)
• RECORD, che registra su disco la trasmissione
Oggi RTSP è molto diffuso e tutti i maggiori player permettono la riproduzione di stream
RTSP. La sua diffusione però si limita ai player standalone, come Windows Media Player,
QuickTime, Real Player, VLC Media Player, ecc, eventualmente integrati nei browser
sotto forma di plug-in (controlli ActiveX su Internet Explorer).
Nel 2003 Adobe sviluppa un proprio protocollo per lo streaming video, Real Time
Messaging Protocol (RTMP); l’obiettivo primario di questo lavoro è il supporto alla trasmissione di contenuti Flash video. Inizialmente RTMP è proprietario e così rimane fino a
gennaio 2009, quando Adobe ne annuncia l’apertura entro la prima metà dello stesso anno.
Curiosamente, la stessa azienda decide di bloccare in seguito lo sviluppo di un progetto
open source ospitato su sourceforge [4], appellandosi al Digital Millennium Copyright Act
(DMCA) nel maggio 2009. Il progetto, rtmpdump, era un’implementazione di alcune specifiche RTMP individuate tramite reverse engineering, e mirava a memorizzare dei flussi
RTMP su disco [5]. Nel giugno 2009 Adobe rilascia definitivamente le specifiche complete
del proprio protocollo [6].
RTMP contiene molti dei comandi già visti in RTSP e aggiunge inoltre il comando SEEK
che permette di spostarsi ad un qualsiasi punto della timeline (anche RTSP permette di
effettuare le operazioni di seeking, ma solo attraverso il campo Range del comando PLAY;
non esiste quindi un comando esplicito SEEK). Real Time Messaging Protocol lavora in
maniera predefinita sulla porta 1935 e usa TCP al livello di trasporto. Per superare alcune limitazioni dovute a infrastrutture di rete particolarmente protette, RTMP può essere
anche incapsulato in pacchetti HTTP e viaggiare su porta 80; in questo caso si parla di
RTMP Tunneled (RTMPT). Esiste infine RTMP Secure (RTMPS), che lavora esattamente
come RTMPT, ma su pacchetti HTTPS e su porta 443.
Per concludere questa breve presentazione, è doveroso citare il prossimo avvento di
HTML5 che include un tag <video> che potrebbe in futuro eliminare l’esigenza di utilizzare
plug-in per la visualizzazione di video tramite browser. Ad oggi, però, non è chiaro se
saranno supportati protocolli di streaming per l’attributo src o come i diversi browser
decideranno di implementare questa funzione, per esempio per quanto riguarda l’interfaccia
per controllare la riproduzione.
2.1.2
Confronto tra progressive download, pseudo streaming e
streaming
Il progressive download, già citato in precedenza, è il modo più semplice per trasmettere dei
contenuti multimediali attraverso la rete. Il media è diviso in frammenti, incapsulati poi in
pacchetti HTTP insieme ad un header che contiene alcune informazioni (come la durata,
nel caso di un audio o un video); i pacchetti sono poi inviati a destinazione in ordine. Non
occorre attendere l’arrivo di tutti i pacchetti per iniziare la riproduzione, tuttavia non è
6
possibile scegliere arbitrariamente dove iniziare la riproduzione. Inoltre a destinazione è
necessario riordinare e memorizzare i vari frammenti del media su disco, di conseguenza al
termine della ricezione sul client sarà disponibile una copia esatta del media. Questo può
essere un problema serio nel caso in cui il video sia protetto da diritti d’autore o non si
desidera comunque che sia diffuso liberamente, per esempio perché contiene informazioni
riservate. La tecnica del progressive download è stata utilizzata per la prima volta per la
trasmissione delle immagini in formato jpeg ed è molto usata anche oggi per questo tipo
di media.
Per risolvere il problema dell’accesso casuale al media si può far uso di script lato server;
in questo caso si parla di HTTP pseudo-streaming. Lo script si occupa di interpretare le
richieste di seek del client e di costruire opportunamente i pacchetti del media dal punto
richiesto in poi. Questa soluzione è economica e non è difficile da mettere in pratica; per
questo motivo è molto diffusa ed è usata anche da grandi community, come per esempio
Youtube.
Con l’utilizzo di un server di streaming si può fare un ulteriore passo in avanti, permettendo non solo l’accesso casuale, ma rendendo inutile il caching del media sul client.
In questo modo si riesce ad evitare, o quanto meno limitare, la diffusione non controllata
di materiale confidenziale o protetto da diritti d’autore. È sempre possibile memorizzare
su disco uno stream, ma l’operazione non è banale e comunque lato server si ha maggior
controllo ed è quindi possibile individuare più facilmente eventuali client sospetti. In genere, inoltre, un server di streaming permette anche un discreto risparmio di traffico rispetto
alla soluzione pseudo-streaming; questo comunque non è sempre vero: in caso di numerosi
seek da parte del client, per esempio, il traffico può risultare molto più elevato.
2.2
2.2.1
Scelta del server di streaming
Configurazione hardware e software del server
Per effettuare test esaustivi sulle soluzioni di streaming individuate, si è reso necessario
disporre di un ambiente di test opportuno. L’azienda dispone di diversi server Dell, alcuni
dei quali fortemente orientati alla virtualizzazione. Mi è stata fornita quindi una macchina
virtuale vuota in uno di questi server, dove ho provveduto ad installare personalmente Microsoft Windows Server 2008. Grazie alla partnership con Microsoft, la licenza del server
è risultata gratuita, di conseguenza tutti i test sono stati fatti a costo zero.
Le specifiche hardware e software dell’ambiente di test sono:
CPU: Intel Xeon E5520 @ 2.27GHz
Memoria: 512MB
Sistema operativo: Microsoft Windows Server 2008 SP1 - edizione 32 bit
Per completezza, la soluzione di virtualizzazione adottata dall’azienda è VMware Server
[7], un prodotto gratuito di VMware Inc., che permette di gestire diverse macchine virtuali
attraverso un’interfaccia web di amministrazione, anche in maniera remota.
CAPITOLO 2. STREAMING SERVER
7
2.2.2
Soluzioni individuate
Dopo un attento studio delle soluzioni in commercio, si è deciso di proseguire lo studio
solo sulle seguenti soluzioni:
• Red5: software libero
Supporta i formati: FLV, AAC, and MP3
Costo: 0
Sito web: http://osflash.org/red5
• Windows Media Services 2008: soluzione di Microsoft, proprietaria
Supporta i formati: WMA, WMV, ASF, MPEG e MP3
Costo: 0 (compreso con la licenza server di Microsoft)
Sito web: http://technet.microsoft.com/it-it/library/cc645570.aspx
• Flash Media Streaming Server: soluzione di Adobe, proprietaria
Supporta i formati: FLV, MP3, AMF, MPEG4, H264
Costo: circa 1200 euro, oppure gratuito fino a 10 stream, ma solo per uso non
commerciale
Sito web: http://www.adobe.com/products/flashmediastreaming/features
• Helix Server: soluzione di RealNetworks
Supporta i formati: FLV, MP3, AMF, MPEG4, H264, formati Real e altri ancora
Costo: da 1500 a 10000 dollari, gratuito fino a 5 stream
Sito web: http://www.realnetworks.com/products/media_delivery.html
• Wowza Media Server: soluzione di Wowza Media System, proprietaria
Supporta i formati: FLV, MP3, AMF, MPEG4 (solo nelle versioni a pagamento),
H264
Costo: 65$ al mese, o 995$ per licenza illimitata. Versione gratuita fino a 10 stream
e senza supporto a MP4.
Sito web: http://www.wowzamedia.com/pricing.html
A causa dell’elevato costo di licenza, Helix Server è stato scartato prima dell’inizio dei
test. Analogamente, anche Wowza Media Server è stato scartato, perchè offre funzionalità
molto vicine a quelle di Adobe Flash Media Streaming Server, ad un prezzo simile. I
test sono quindi proseguiti unicamente su Adobe FMS, Red5 e Windows Media Services.
L’installazione, la configurazione e la prova d’uso degli stessi è descritta nei prossimi
paragrafi.
2.2.3
Installazione di Adobe Flash Media Streaming Server
Flash Media Streaming Server è la soluzione offerta da Adobe nel campo dello streaming.
La controparte client è Adobe Flash Player, un plugin disponibile per tutti i maggiori
browser, in grado di eseguire delle piccole applicazioni, note come filmati Shockwave Flash.
Nato nel 1996 dall’azienda FutureWave, è stato acquisito prima da Macromedia e poi da
Adobe nel 2004. Inizialmente pensato per portare la grafica vettoriale e alcune semplici
animazioni sul web, oggi Flash è prevalentemente utilizzato per la creazione di contenuti
web accattivanti e per l’inserimento di oggetti multimediali nelle pagine web. Diverse
8
statistiche affermano che le ultime versioni del Flash Player sono presenti in oltre il 97%
dei computer che navigano su Internet, e per questo motivo questa tecnologia, e la sua
controparte server, destano molto interesse per le aziende2 .
Adobe Flash Media Server è presente in tre versioni: Interactive, Streaming e Development. La prima versione è indicata per le aziende che vogliono sviluppare applicazioni
con tecnologia Flex, mentre la seconda si limita ad offrire le funzionalità per lo streaming
dei media. È inoltre possibile provare gratuitamente Adobe Flash Media Server, scegliendo la versione Development [8]. A differenza della versione completa, questa permette la
connessione concorrente di soli 10 utenti nello stesso momento, ma per la fase di testing
si è rivelata più che adatta.
L’installazione è guidata e risulta molto semplice; durante la stessa ci è chiesto di inserire
un nome utente e una password da utilizzare per accedere all’interfaccia di amministrazione. Una volta terminata l’installazione, sulla macchina sono attivi tre servizi:
Figura 2.1: installazione di Adobe Flash Media Streaming Server
• Il demone RTMP standard, sulla porta 1935
• Il demone RTMP Tunneled, sulla porta 80
• Un server web per l’amministrazione, sulla porta 1111.
Attraverso Start > Programmi > Adobe > Flash Media Server > Flash Media Administration Console, è possibile accedere all’interfaccia web di amministrazione, visibile in
figura 2.2.
La versione Development è una versione limitata di Adobe Flash Media Interactive Server,
2
Uno studio condotto per conto di Adobe nel settembre 2009 da una grande azienda in campo di
ricerche di mercato, Millward Brown, indica che il Flash player è installato in oltre il 99% dei computer
desktop nei mercati maturi, mentre si ferma al 97% nei mercati cosiddetti emergenti [9]. Altre statistiche
che riportano dati simili, pur se individuati con metodologie differenti, sono presenti sul sito StatOwl.com
[10]
CAPITOLO 2. STREAMING SERVER
9
Figura 2.2: interfaccia web per l’amministrazione di Adobe Flash Media Streaming Server
quindi contiene anche le funzionalità per lo sviluppo di applicazioni con tecnologia Flex3 ;
per questa ragione, dall’interfaccia di amministrazione è possibile trovare le voci apposite
per creare directory per le applicazioni, creare utenti, ecc.
È anche possibile controllare e amministratore i client che accedono ad una risorsa, come
per esempio un media in streaming (figura 2.3). In questo modo risulta facile ottenere dei
log di accesso alla risorsa e quindi individuare eventuali client sospetti; per esempio, può
capitare che l’indirizzo del media in streaming sia usato in pagine web esterne a quelle
dell’azienda, senza autorizzazione. In questo caso è possibile effettuare un controllo incrociato tra le informazioni contenute nei log del server di streaming e quelle contenute nei
log del server web per individuare gli utenti non autorizzati; naturalmente si tratta di una
procedura delicata che dev’essere progettata in maniera accurata, però in questo momento
si vuole solo evidenziare la possibilità di effettuare controlli di questo tipo, senza scendere
troppo nel dettaglio della loro implementazione.
Il server di streaming e il server di amministrazione sono due servizi distinti e si possono
attivare in maniera indipendente.
Per creare una directory dove inserire i media da rendere disponibili per lo streaming, è
sufficiente fare clic su New Instance, nella scheda View Application. Quando si crea
3
Adobe Flex [11] è un ambiente di sviluppo per applicazioni web sofisticate nato nel 2004. Questa
tecnologia richiede l’utilizzo di Adobe Flash Player per poter eseguire le applicazioni, ma non soffre dei
problemi di incompatibilità tra browser che si possono verificare con altre tecnologie. A differenza delle
applicazioni realizzate con Adobe Flash Professional, Flex non utilizza il paradigma delle animazioni per
lo sviluppo di applicazioni, ma un più comune linguaggio imperativo (ActionScript), in modo da rendere
più semplice il lavoro degli sviluppatori. Un esempio interessante di applicazione realizzata con tecnologia
Flex è Photoshop Express, una versione web del famoso strumento di fotoritocco di Adobe [12]
10
Figura 2.3: interfaccia per l’amministrazione degli utenti e delle risorse
una nuova istanza, viene creata anche una directory su disco, all’interno della directory
application dove è installato Adobe FMS; con essa vengono create anche due subdirectory annidate: streams e _definst_ ed è all’interno di quest’ultima che vanno inseriti
i media da pubblicare. Quando si specifica l’url del media è sufficiente indicare il nome
dell’applicazione e non quello delle subdirectory.
Esempio: se si è creata l’applicazione esempio, i media vanno inseriti nella directory
C: \ percorso_di_installazione_di_Adobe_FMS \ a p p l i c a t i o n \ e se m pi o \ s t r e a m s \ _ d e f i n s t _
e l’URL da usare per accedere al media è rtmp://nome_host/esempio/nome_media.
Il file di configurazione principale di Adobe FMS è fms.ini e si trova nella directory
conf dove si è installato il server. All’interno di questo file si possono modificare i parametri
immessi durante la fase di installazione, come nome e password dell’utente amministratore,
porte su cui avviare i servizi, percorsi, ecc.
2.2.4
Installazione di Red5 Media Server
Red5 Media Server [13] è uno streaming server open source che usa il protocollo RTMP e
lavora con tecnologia Flash; è generalmente considerato come un’alternativa libera e gratuita alla soluzione di Adobe. Nasce nel settembre 2005 da una comunità di appassionati
della tecnologia Flash e dell’ideologia open source, senza alcuna direzione aziendale alle
spalle. Poichè all’inizio del lavoro le specifiche di RTMP non sono libere, gli sviluppatori sono costretti ad adottare tecniche di Reverse Engeenering; nonostante ciò riescono a
realizzare una versione funzionante del server già per la fine dello stesso anno. Negli anni
seguenti il lavoro procede senza sosta, attirando un pubblico sempre maggiore ed anche
CAPITOLO 2. STREAMING SERVER
11
alcuni nomi importanti; tra i tanti, anche il social network Facebook utilizza Red5 per la
gestione dei video caricati dagli utenti [14].
Oggi il progetto è arrivato alla versione 0.8 ed è in grado di trasmettere in streaming, media
nei formati FLV, MP3 e AAC. Una versione in grado di lavorare anche con MPEG4 Part
10, un formato video ad alta definizione, è in via di sviluppo e dovrebbe essere rilasciato
a breve (la versione 0.9 RC2 è stata rilasciata a novembre 2009).
Red5 per Microsoft Windows è disponibile in tre versioni: installer binario, servlet da
usare in congiunzione con Apache Tomcat e codice sorgente. La soluzione più semplice
per provare questo server di streaming è tramite l’utilizzo dell’installer.
Figura 2.4: installazione di Red5
I servizi attivi al termine della configurazione sono:
• RTMP standard: in ascolto sulla porta 1935
• Server web: in ascolto su una porta specificata in fase di installazione (default: 5080).
Questa versione di Red5 incorpora un server web (Apache Tomcat), che è possibile utilizzare liberamente per caricare le proprie pagine web, ma è anche utile per verificare il
corretto funzionamento del server di streaming e per accedere al pannello di amministrazione.
Per avviare gli altri servizi offerti da Red5, occorre modificare il file red5-core.xml all’interno della directory conf dove si è installato il server, decommentando la parte desiderata.
Per esempio, per attivare RTMP Tunneled, bisogna decommentare il blocco XML
<bean i d ="rtmpt . s e r v e r " c l a s s =" o r g . r e d 5 . s e r v e r . tomcat . rtmpt . RTMPTLoader " i n i t −
method=" i n i t " l a z y −i n i t =" t r u e ">


<bean c l a s s =" o r g . apache . c a t a l i n a . c o n n e c t o r . Connector ">
<c o n s t r u c t o r −a r g t y p e =" j a v a . l a n g . S t r i n g " v a l u e =" o r g . apache .
c o y o t e . h t t p 1 1 . H t t p 1 1 N i o P r o t o c o l " />
<v a l u e >$ { rtmpt . p o r t }</ v a l u e ></
property>
12
<v a l u e >f a l s e </v a l u e ></
property>
</bean>


<map>
<e n t r y key=" maxKeepAliveRequests " v a l u e ="$ { rtmpt .
max_keep_alive_requests }"/>
<e n t r y key=" u s e E x e c u t o r " v a l u e =" t r u e "/>
<e n t r y key="maxThreads " v a l u e ="$ { rtmpt . max_threads }"/>
<e n t r y key=" acceptorThreadCount " v a l u e ="$ { rtmpt .
a c c e p t o r _ t h r e a d _ c o u n t }"/>
<e n t r y key=" p r o c e s s o r C a c h e " v a l u e ="$ { rtmpt . p r o c e s s o r _ c a c h e
}"/>
</map>


<bean c l a s s =" o r g . apache . c a t a l i n a . c o r e . StandardHost ">





</bean>

</bean>
In questo modo si possono attivare i servizi RTMP Tunneled, RTMP Secure e MRTMP
(Multiplexing RTMP), un protocollo sviluppato dalla comunità di Red5, che si occupa
del clustering di servizi RTMP. Per modificare alcune impostazioni, come indirizzi IP e
porte su cui i diversi servizi sono in ascolto, occorre modificare il file di configurazione
red5.properties, che si trova ancora nella directory conf. I media che si intendono rendere disponibili per lo streaming devono essere inseriti nella directory streams all’interno
di una delle subdirectory di webapps dove si è installato il server.
Quando l’installazione è completata, si può accedere all’interfaccia web da un comune
browser (figura 2.5).
Figura 2.5: interfaccia web di Red5 Media Server
CAPITOLO 2. STREAMING SERVER
13
Dalla stessa è possibile accedere ad una lista di dimostrazioni installabili con pochi clic,
utili per conoscere le potenzialità del server di streaming e per verificare che tutto sia
configurato correttamente.
Figura 2.6: installazione di una demo tramite l’interfaccia web di Red5
Figura 2.7: visualizzazione di oflaDemo, una delle dimostrazioni incluse in Red5
Dalla pagina con la lista delle demo di presentazione di Red5 si accede all’interfaccia di
amministrazione del server, dove è possibile visualizzare gli utenti connessi alle diverse
applicazioni ed anche ai singoli stream (figura 2.8).
Red5 è in definitiva una soluzione valida e completa, che non manca di offrire anche
alcune soluzioni particolarmente avanzate. Nonostante ciò, è doveroso indicare la maggior debolezza di questo prodotto: la mancanza di un’azienda alle spalle. L’adozione di
Red5 è, infatti, in qualche modo frenata dalla mancanza di assistenza, di garanzie di funzionamento e dalla scarsa documentazione (quasi completamente presente sotto forma di
mailing list). Una dimostrazione evidente di queste problematiche, si è verificata a luglio
2009, quando Adobe ha rilasciato un aggiornamento di sicurezza del proprio player Flash,
rivedendo la procedura di handshaking iniziale tra client e server; in pratica, con quest’ultimo aggiornamento, non è più possibile ricevere stream RTMP da server Red5 [15]. La
14
Figura 2.8: interfaccia web di amministrazione di Red5
versione attualmente in sviluppo è già stata corretta per risolvere questo problema, ma
non è ancora stata rilasciata in versione stabile.
2.2.5
Installazione di Windows Media Services
Windows Media Services è la soluzione offerta da Microsoft per la trasmissione di contenuti multimediali attraverso la rete. Da Windows Server 2008, WMS non è più integrato
direttamente nel sistema, ma può essere scaricato gratuitamente [16].
Per effettuare l’installazione è sufficiente accedere all’utility Server manager e quindi aggiungere il ruolo Servizi flussi multimediali.
Figura 2.9: Server manager di Windows Server 2008; Windows Media Services come ruolo
CAPITOLO 2. STREAMING SERVER
15
Durante l’installazione viene chiesto se si desidera avviare anche il demone HTTP (porta
80); questo può creare alcuni problemi se è già presente un server web. Queste problematiche saranno discusse nel paragrafo 2.3.1.
Una volta che il servizio Windows Media è installato, è possibile effettuare le operazioni
di configurazione tramite il tool di amministrazione Servizi Windows Media, negli strumenti di amministrazione di Windows. Il tool è molto simile, anche per i nomi usati, a
quello per l’amministrazione del server web Internet Information Services.
Figura 2.10: amministrazione dei servizi Windows Media.
Windows Media Services offre streaming attraverso RTSP, ma anche attraverso MMS
(Microsoft Media Server, un protocollo per lo streaming attualmente ritenuto obsoleto) e
in ultima istanza HTTP, nel caso in cui le altre alternative non dovessero andare a buon
fine. I formati supportati dal server di streaming di Microsoft sono i formati Windows
Media (WMA, WMV), MPEG, ASF e MP3; non è quindi possibile trasmettere in streaming contenuti Flash video (FLV). Questo limite si rivela essere molto importante, in
quanto impone che per la visualizzazione dei media si debba ricorrere a player standalone,
eventualmente integrati nei browser tramite l’utilizzo di plugin. In alternativa, si possono
utilizzare player sviluppati con tecnologia Silverlight, che però risulta essere molto meno
diffusa rispetto al concorrente diretto Flash. Anche queste problematiche saranno discusse
più approfonditamente in seguito.
2.2.6
Confronto tra le soluzioni e benchmark
Dopo aver effettuato alcuni test per verificare le varie funzionalità delle soluzioni individuate, si è passati alla fase di stress test (benchmark). Per questa fase è stato utile usare
le statistiche delle visite del portale attuale e che saranno discusse più in dettaglio nel
16
paragrafo 2.3.3. Tali informazioni comunque hanno portato all’individuazione di un limite
inferiore indicativo, scelto prendendo ogni volta il caso peggiore possibile; questo valore è
48 e indica il numero massimo di utenti che richiedono contemporaneamente la visualizzazione di un media. Si vuole che il server di streaming sia in grado di gestire almeno un
numero di utenti pari al numero di utenti massimo che il sistema attuale è stato in grado
di sopportare.
Si è quindi cercato lo strumento adatto allo scopo e si è individuato un prodotto gratuito,
sviluppato con tecnologia Flex [17]. Lo strumento è in grado di avviare molteplici richieste di flussi RTMP contemporaneamente e lavora egregiamente fino a circa 20 richieste,
dopo le quali comincia a degradare nelle prestazioni, sino al crash completo. Perciò si è
avviato il tool in contemporanea su quattro macchine, arrivando a superare le 100 connessioni concorrenti senza alcun problema per il server di streaming Red5, trascurando il
ragionevole rallentamento della riproduzione. Lo stesso test non si è potuto eseguire sul
server di Adobe, a causa della limitazione a 10 stream concorrenti imposta per la versione
Development. E’ comunque fortemente auspicabile che anche questo server sia in grado
di gestire senza problemi lo stesso numero di client concorrenti, tenendo sempre presente
che questi valori superano largamente il limite inferiore individuato con i dati di visite del
portale attuale.
Per quanto riguarda Windows Media Services, Microsoft mette a disposizione gratuitamente degli strumenti appositi per i test di carico sul proprio server di streaming [18]. Tali
prove sono state svolte con modalità simili a quelle utilizzate per Red5, cioè eseguendo il
test da più macchine e verificando l’impatto delle molteplici richieste sul server. Anche in
questo caso si è riusciti a superare senza difficoltà il centinaio di connessioni concorrenti.
La conclusione che si può trarre dai test di carico è che l’unico limite reale da considerare
è l’ampiezza di banda in upload della connessione dove risiederà il server di streaming, ma
anche questa questione sarà discusa nel paragrafo 2.3.3.
Una volta terminati i test si è arrivati alla conclusione della comparativa tra i server
di streaming ed è quindi giunto il momento di scegliere quale tra quelli valutati si sarebbe
usato per proseguire il lavoro. Nonostante la comodità e la gratuità dell’offerta Microsoft,
essa è stata scartata a causa dell’impossiblità di trasmettere in streaming il formato Flash
video (paragrafo 2.3.1).
Inizialmente si era scelto Red5, che si era dimostrato particolarmente valido ed a costo zero.
In seguito all’aggiornamento del Flash player (vedi par. 2.2.4), avvenuto proprio durante
lo stage, si è stati tuttavia costretti a rivedere la scelta, a causa delle serie difficoltà e dei
ritardi che la questione ha comportato. Problemi non accettabili, una volta che il server
di streaming fosse effettivamente installato e in funzione; per questo motivo si è alla fine
scelta la soluzione di Adobe, perché è plausibile pensare che eventuali aggiornamenti critici
del player sarebbero accompagnati dai necessari aggiornamenti del server.
2.3
2.3.1
Completamento configurazione del server di streaming
Problematiche di accessibilità dei contenuti
L’attuale offerta di contenuti audio e video sul portale eDott soffre, come già discusso, di
alcune problematiche dovute all’uso della tecnica progressive download per la trasmissione.
CAPITOLO 2. STREAMING SERVER
17
D’altro canto tale tecnica richiede una configurazione minimale da parte del client: l’unico
reale requisito è l’installazione del plugin Flash sul browser utilizzato per accedere al
portale. La necessità di aggiornare l’offerta non può precludere l’accesso ai contenuti a
una parte degli utenti, per cui obiettivo primario del processo di aggiornamento è quello
di garantire l’accessibilità dei media alla percentuale di utenti più grande possibile e,
idealmente, tutti.
Per ottenere questo risultato si dovrebbe fare meno assunzioni possibile sulla configurazione software e hardware del computer dal quale l’utente cerca di accedere ai contenuti
in streaming, tuttavia è necessario individuare quale tipologia di applicazione dovrà usare
il client per decidere opportunamente la configurazione del server. Si prenda come esempio la trasmissione attraverso il prodotto Microsoft Windows Media Services. A questo
punto si potrebbe offrire al client un sito web con alcuni collegamenti a media trasmessi
in streaming. Se l’utente utilizza il sistema operativo Windows e Internet Explorer, con
buona probabilità facendo clic sul collegamento vedrà avviarsi automaticamente Windows
Media Player che sarà in grado di collegarsi correttamente al server e mostrerà subito i
contenuti. Ma se l’utente facesse uso di un altro browser o di un altro sistema operativo?
Mozilla Firefox su Windows, per esempio, non associa in maniera predefinita i flussi RTSP
a Windows Media Player, quindi mostrerebbe un errore. Si potrebbe allora pensare di includere direttamente il player all’interno della pagina web, ma in questo caso gli utenti
che utilizzano altri sistemi operativi sarebbero esclusi.
L’ultima soluzione è quella di utilizzare un player sviluppato con tecnologia Silverlight,
un prodotto pensato per le applicazioni web sviluppato da Microsoft e diretto concorrente della tecnologia Flash. Silverlight è disponibile per Windows e Mac OS X, mentre
per GNU/Linux esiste un’implementazione open source del player di nome Moonlight,
sviluppata da Novell in collaborazione con Microsoft. Lo svantaggio principale di questa tecnologia è che è ancora poco diffusa tra gli utenti e perciò, qualora si intendesse
utilizzarla, sarebbe necessario obbligare l’utenza del portale ad installare questo plugin.
Questo naturalmente può essere solo una semplice seccatura (che si vorrebbe comunque
evitare all’utente), ma in alcuni casi può essere un vero e proprio limite, in quanto spesso,
sulla macchina su cui si lavora, non si hanno diritti amministrativi per poter installare
applicazioni. Nel caso precedente in cui si proponeva l’utilizzo di un player standalone
per la fruizione dei contenuti, è plausibile pensare che ogni installazione standard di ogni
sistema operativo ne fornisca uno; nel caso della tecnologia Silverlight, invece, non si può
dar per scontato che l’utente ne sia provvisto o che sia in grado di installarlo.
Per quanto detto finora, si è quindi scelto di adottare un server in grado di trasmettere
contenuti Flash video, e quindi un server RTMP. Questa scelta è basata principalmente sul
fatto che questa tecnologia è disponibile su tutte le piattaforme ed è contemporaneamente molto diffusa, con una quota di mercato superiore al 97% secondo alcune statistiche;
quindi si contravviene alla regola di non fare assunzioni sulla configurazione software dell’utente, ma lo si fa sulla base di numeri che danno una discreta certezza di successo, senza
considerare che anche la versione attuale del portale eDott utilizza, per la riproduzione,
un player sviluppato con tecnologia Flash.
I limiti della configurazione software sono solo una parte del problema, ma è altrettanto importante valutare eventuali limitazioni dovute alla configurazione di rete della
18
postazione dal quale l’utente intende accedere ai media in streaming. Un server RTMP
lavora in maniera predefinita sulla porta 1935, ma un amministratore di rete particolarmente attento potrebbe voler permettere la comunicazione tra entità interne ed esterne
alla rete solo attraverso alcune porte4 , in modo da limitare l’utilizzo di servizi indesiderati. In questo caso, utilizzando la versione standard del protocollo, l’utente non sarebbe
in grado di visualizzare il media; a peggiorar la situazione c’è un altro fatto da tener
presente: in un caso come quello descritto, il problema sta nel firewall della rete dell’utente, che ricevendo pacchetti considerati non legali li scarta. In questo modo la richiesta
al server è effettuata in maniera corretta, ma la risposta non giunge mai e il risultato è
che l’utente si trova ad aspettare potenzialmente all’infinito un media che non arriverà
mai. Può sembrare una differenza minimale, ma per un utente che tenta di accedere ad
una risorsa è di gran lunga preferibile ricevere subito una risposta negativa piuttosto che
dover attendere all’infinito senza sapere se sarà presto o tardi in grado di fruire del media.
L’unica tecnica attuabile in un caso come questo è l’uso di un timeout sul client, ma il
tempo stabilito dovrebbe tener conto di fattori come l’ampiezza di banda e il traffico sulla
rete, quindi non si tratta di una scelta banale. Per evitare di incorrere in questi problemi,
una soluzione è cercare di utilizzare una configurazione che sia il più possibile accettata
dai firewall aziendali. Avviare il server di streaming sulla porta 80 può essere un valido
punto di partenza, ma non è sufficiente. Talune configurazioni di rete particolarmente
restrittive possono limitare il passaggio ai soli pacchetti di protocolli (di livello applicazione) decisi a priori. Generalmente tra i protocolli consentiti vi è HTTP, in quanto non
si vuole impedire agli utenti di navigare sul web; e d’altra parte è evidente che gli utenti
del portale siano in grado di navigare sul web. In questo caso il protocollo RTMP ci viene
incontro, in quanto esiste una versione Tunneled dello stesso che permette l’incapsulamento dei pacchetti RTMP in pacchetti HTTP, senza perdere i vantaggi dell’utilizzo delle
trasmissioni in streaming. Questa è la soluzione che si è infine scelta per la configurazione
del server: si noti, infatti, che gli URL delle risorse in streaming cominceranno sempre con
rtmpt://195.103.97.99:80/...
Le due soluzioni per lo streaming su RTMP viste in precedenza, Adobe Flash Media
Server e Red5 Media Server, offrono entrambe un proprio server web, utilizzato prevalentemente per funzionalità amministrative e dimostrative. Si ha però l’esigenza di installare
un altro server web per aver maggior controllo sullo stesso, per esempio perchè occorre
estenderne le funzionalità. Il portale, in particolare, fa largo uso di script ASP e della
piattaforma .Net di Microsoft e non è possibile ottenere il supporto a queste tecnologie
con i browser integrati nei server di streaming.
Si desidera, inoltre, utilizzare la stessa macchina sia per l’offerta dei contenuti web che
per i media in streaming. Un esempio per cui si può desiderare avere entrambi i servizi
nello stesso server fisico è quello in cui si vuole offrire agli utenti la possibilità di caricare
dei video registrati personalmente; in questo caso il video caricato può essere facilmente
processato e spostato nella directory del server di streaming, senza bisogno di predisporre
4
una porta (in ambito di reti di calcolatori) è un numero che identifica un processo in esecuzione sul
destinatario di un messaggio. È un’informazione utilizzata a livello di trasporto e non è nota a livello
di rete; per questa ragione un’apparecchiatura di rete, per esempio un firewall, che voglia individuare
questo valore, deve ricorrere a tecniche di Deep Packet Inspection che esaminano in maniera approfondita
il contenuto di un messaggio TCP/IP. Tecniche ancor più avanzate di DPI permettono anche di esaminare
informazioni di livello più alto, per esempio pacchetti a livello di applicazione.
CAPITOLO 2. STREAMING SERVER
19
comunicazioni e sincronizzazioni tra macchine differenti.
Per ottenere questo risultato, occorre disporre di due servizi attivi sulla stessa porta: il
server web che non può essere naturalmente spostato dalla porta 80, e il server di streaming, che utilizza il tunnelling. Ci sono diversi modi per affrontare il problema, ma la
soluzione più semplice è installare una seconda scheda di rete sul server. Considerando
il fatto che l’ambiente di prova è una macchina virtuale, aggiungere una scheda di rete
virtuale è un’operazione a costo zero e che richiede pochissimi passaggi. Ora, con le dovute
configurazioni, si hanno due connessioni e quindi due indirizzi IP differenti; resta quindi
solo da associare i due servizi ai diversi indirizzi IP. Il server web utilizzato dall’azienda
è Internet Information Services di Microsoft, ma la stessa configurazione si può ottenere
con qualsiasi server web.
Per associare l’indirizzo IP di ascolto su server web IIS si deve entrare nell’interfaccia di
amministrazione del server web e fare clic destro su Default Web Site (e ogni altro sito
configurato), e quindi scegliere Modifica binding; a questo punto sarà possibile scegliere
su quale indirizzo il server web dovrà restare in ascolto, fra quelli associati alla macchina
(figura 2.12).
Figura 2.11: modifica binding in Internet Information Services
La procedura può essere eseguita tramite riga di comando, con le seguenti istruzioni:
netsh http add iplisten ipaddress=x.x.x.x
net stop http
net start http
iisreset
La configurazione del server di streaming è ancora più semplice: è sufficiente modificare
poche righe nel file di configurazione.
20
Nel caso di Red5 Media Server, il file da modificare è red5.properties e le righe da
modificare sono:
rtmpt.host=<indirizzo IP>
rtmpt.port=80
Mentre, nel caso di Adobe Flash Media Server, il file di configurazione è fms.ini e si deve
modificare la riga:
ADAPTOR.HOSTPORT = <indirizzo IP>:1935,80
2.3.2
Scelta del client
Si è sin qui discusso della configurazione lato server, ma naturalmente è altrettanto importante capire che cosa si intende offrire all’utente finale per accedere ai contenuti in
streaming. Le componenti che devono essere presenti sul client sono tre: il browser (indifferentemente dal tipo e dalla versione), il plugin Flash player di Adobe e un’applicazione
Flash in grado di visualizzare i contenuti in streaming. La tecnologia Flash offre tutte
le funzionalità per comunicare e ricevere trasmissioni da un server RTMP, ma occorre
un’applicazione che richiami queste funzionalità e che offra un’interfaccia all’utente, sia
per visualizzare il media, se si tratta di un video, sia per controllare la riproduzione tramite pulsanti di PLAY, PAUSE, STOP, ecc. Questa piccola applicazione, che tecnicamente
prende il nome di filmato o, in inglese, movie, non è scelta dall’utente, ma dev’essere disponibile per lo scaricamento sul server web, come se si trattasse di un qualunque documento
da trasmettere tramite HTTP; per questa ragione, anche la scelta del filmato da utilizzare fa in qualche modo parte della configurazione del server. È necessario in particolare
disporre di un filmato in grado di operare correttamente con il server di streaming e che
offra funzionalità adeguate.
Sono stati individuati due prodotti adatti. Il primo è JW Player [19], un prodotto
gratuito (ma non open source) e di installazione immediata. In questo ambito, per installazione si intende l’inserimento del codice del filmato all’interno della pagina web; questa
procedura richiede sempre l’inserimento di alcune righe nel corpo della pagina, ma anche
l’inclusione, ed eventualmente l’esecuzione, di alcuni script javascript. JW Player è risultato molto comodo nella prima fase di prova, ma molto meno potente e configurabile per
funzionalità più avanzate.
Il secondo prodotto individuato è Flowplayer [20], un prodotto open source e gratuito, che
si è rivelato essere molto potente e flessibile, a discapito di una procedura di installazione leggermente più complicata rispetto a quella di JW Player. Le funzionalità di questo
software saranno discusse in maniera più approfondita nel capitolo 3.
Per testare le funzionalità del server di streaming Microsoft, si è anche deciso di individuare un client sviluppato in tecnologia Silverlight; nonostante questa tecnologia sia
decisamente meno diffusa rispetto a Flash, esistono già diversi player gratuiti. Ne è stato individuato uno particolarmente valido, anche dal punto di vista grafico: Silverlight 2
Video Player [21].
2.3.3
Formati e caratteristiche dei video
La scelta dei formati e delle caratteristiche dei video è critica quando si tratta di realizzare
una piattaforma per lo streaming di contenuti multimediali: pochi minuti di un filmato
CAPITOLO 2. STREAMING SERVER
21
registrato con una moderna telecamera ad alta qualità possono arrivare a pesare diversi
gigabyte. Per questa ragione, è strettamente necessario scegliere un formato e delle opzioni
di compressione adatte alla rete e all’utenza a cui vogliamo trasmettere i nostri contenuti
in streaming. In seguito si porrà l’attenzione ai formati video, piuttosto che a quelli audio,
in quanto i primi sono di maggior interesse per l’azienda e contemporaneamente soffrono
di maggiori problematiche a causa dell’elevata dimensione.
Nel caso di uno streaming server che lavora con Flash video, i formati disponibili sono
solo due: FLV e MP4.
FLash Video (FLV) è un formato contenitore, cioè indica come sono contenuti al suo interno i diversi tipi di dato (audio, video, eventuali sottotitoli). Per la codifica e la decodifica
della traccia video possono essere usati diversi tipi di codec; le versioni più datate del
Flash player supportavano solo il codec Sorenson, un’implementazione proprietaria e non
completa dello standard H.263.
H.263 definisce uno standard per la codifica e la decodifica di video, tramite una compressione lossy che si articola in tre punti principali:
• Predizione del frame corrente basandosi sulle informazioni del frame precedente
• Utilizzo di Motion Vector, un vettore che indica la traslazione compiuta dai punti di
un’immagine alla successiva
• Compressione delle singole immagini attraverso la Trasformata Coseno Discreta
(DCT).
Lo standard H.263 è stato promulgato nel 1996 dal Video Coding Experts Group (VCEG),
una sezione dell’ente International Telecommunication Union (ITU), che si occupa della
standardizzazione in ambito radio e telecomunicazioni. Il principale obiettivo di questo
standard è quello di comprimere i dati in maniera sufficiente e particolarmente adatta per
chiamate in videoconferenza su linea ISDN; conseguentemente, il tasso di compressione
può essere anche molto elevato, a discapito della qualità dell’immagine. La versione 8
del Flash player, rilasciata nel 2005, ha aggiunto il supporto alla codifica VP6, ancora
una volta un codec proprietario, sviluppato nel 2003 da On2 Technologies. VP6 utilizza
tecniche simili a quelle di H.263, aggiungendo anche la codifica a bitrate dinamico e altre
ottimizzazioni. Rispetto al codec Sorenson, VP6 garantisce video di migliore qualità anche
utilizzando lo stesso bitrate per la codifica; d’altro canto questo codec ha bisogno di una
potenza di calcolo maggiore per la codifica e la decodifica e ne è perciò sconsigliato l’uso
su computer più datati.
Dal 2007, con la versione 9 del Flash player, è stato aggiunto anche il supporto alla
codifica video H.264. Frutto della collaborazione tra VCEG e Moving Picture Experts
Group (MPEG), un gruppo di lavoro interno a ISO/IEC, H.264 è rilasciato nel 2003 come
successore del precedente H.263. Il nuovo standard è molto flessibile; definisce infatti
diversi profili applicativi, ognuno con le proprie esigenze: basti pensare che lo stesso
standard può essere utilizzato per la codifica di una trasmissione in videoconferenza, quindi
di qualità relativamente bassa, ma anche per la codifica dei contenuti ad alta definizione,
quelli che attualmente troviamo su Blu-ray e HD DVD.
Per quanto concerne l’audio, FLV supporta anche dalle versioni più datate, il formato
MPEG-1 Audio Layer 3, comunemente noto come MP3. La versione 9 del player Flash
22
ha introdotto anche il supporto al formato Advanced Audio Coding (AAC), un formato
di compressione in grado di garantire risultati migliori di MP3.
Negli ultimi anni Adobe sta spingendo gli sviluppatori ad abbandonare il formato FLV
per adottare un nuovo formato contenitore: F4V [22]. Tale formato, però, è supportato
solo dalla versione 9 del player, di conseguenza l’abbandono di FLV potrebbe significare
escludere gli utenti con software meno aggiornato.
MP4, formalmente MPEG-4 Part 14, è anch’esso un formato contenitore, definito da
Moving Picture Experts Group e ufficialmente uno standard a partire dal 2003 con la sigla
ISO/IEC 14496-14:2003. Supporta diversi codec video e audio, ma prevalentemente i più
utilizzati sono H.264 per la codifica video e AAC o MP3 per la codifica audio. Utilizzare
un formato contenitore piuttosto che un altro non incide in maniera considerevole se si
utilizzano gli stessi codec per la codifica audio e video, anche se generalmente con MP4 è
possibile ottenere risultati migliori in termini di occupazione su disco; bisogna però tenere
presente che non tutti gli utenti sono provvisti di Flash player aggiornato, e quindi l’offerta
di contenuti ad alta qualità può ancora una volta rappresentare un ostacolo per alcune
fasce di utenti.
La scelta finale del formato è quella di utilizzare prevalentemente FLV (codec video Sorenson o VP6, codec audio MP3) per i contenuti da offrire agli utenti e in casi adeguati
offrire anche una versione a più alta definizione in formato MP4.
La seconda parte del lavoro richiede di individuare delle opzioni di codifica adeguate per il formato scelto, in base alla banda disponibile, al traffico sulla rete, alle visite
ricevute, ecc. L’attuale versione del portale eDott è dotata di un sofisticato sistema di
monitoraggio delle visite che ha permesso di individuare dei valori utili per stabilire le
migliori opzioni di compressione. Tali opzioni possono essere di secondaria importanza,
per esempio nel caso del rapporto delle dimensioni di un video: offrire un video in 16:9
piuttosto che in 4:3 ha una certa rilevanza in termini di interfaccia, ma non è critico e può
essere adattato in base a specifiche esigenze estetiche. Al contrario, ci sono delle opzioni
che richiedono un accurato studio della rete e delle statistiche delle visite degli utenti; tra
queste, la più importante è probabilmente il bitrate di codifica.
Il termine bitrate in campo multimediale indica quanti bit sono usati per la codifica di
un’unità di tempo, cioè generalmente un secondo. Questo valore influenza molto la qualità
video; più bit utilizziamo per rappresentare l’informazione in un certo istante, più particolari possiamo rappresentare. Contemporaneamente aumentando il bitrate si aumenta
inevitabilmente la dimensione su disco; questo potrebbe essere visto come un problema
di poco rilievo viste le dimensioni che assumono le memorie di massa attuali. In effetti
la dimensione su disco non è un reale problema: la trasmissione di un media di dimensione elevata perché molto lungo ha la stessa complessità della trasmissione di un media
di piccola dimensione, nel caso in cui i due abbiano lo stesso bitrate di codifica e a meno
di congestioni della rete. Quindi ancora una volta il punto cruciale rimane la scelta del
bitrate ed il motivo è semplice: qualora il bitrate fosse troppo elevato rispetto alla banda
disponibile, l’utente finale riceverebbe il video ad una frequenza troppo bassa per poterlo
riprodurre in maniera fluida. Visualizzerebbe, in pratica, pochi fotogrammi, per poi essere
costretto ad una nuova fase di buffering e così per tutta la durata del video. Naturalmente
nessun utente è disposto a visualizzare un media in questa maniera, di conseguenza occorre
evitare che ciò si possa verificare. Il buffering può aiutare ad avere una riproduzione più
CAPITOLO 2. STREAMING SERVER
23
fluida, ma fino ad un certo limite: non si può pensare di fare il buffering dell’intero media,
altrimenti si perderebbero i vantaggi della trasmissione in streaming; in secondo luogo,
permettere il buffering vuol dire permettere il caching delle informazioni nella memoria
del computer del client, ma come detto si vorrebbe evitare di distribuire il media.
D’altro canto non si può nemmeno scegliere un valore troppo basso per il bitrate, altrimenti si avrebbe una qualità del media molto scadente e anche questo rischierebbe di risultare
alquanto insoddisfacente per l’utente.
Idealmente, cioè in assenza di rallentamenti e traffico sulla rete, sarebbe opportuno scegliere un valore congruo alla banda disponibile: avendo a disposizione una banda di 500Kbps,
un media codificato con questo valore per il bitrate permetterebbe, a meno di qualche
secondo di buffering iniziale, di avere una riproduzione perfettamente fluida; per ogni secondo trascorso durante la visualizzazione del media si riceverebbero pacchetti sufficienti
a riprodurne un altro secondo. Naturalmente questo vuole solo essere un esempio ed oltre
a descrivere una situazione irriproducibile nella realtà, non tiene conto di alcuni fattori
importanti che saranno discussi in maniera più approfondita in seguito.
Per scegliere dei valori adatti è utile ricorrere alle statistiche di visita del portale attuale. Per scegliere un limite superiore si può pensare alla condizione più favorevole possibile,
cioè il caso in cui ci sia un solo client a richiedere la trasmissione del media e la rete sia
completamente priva di congestioni e rallentamenti. In questo caso, idealmente, il client
dovrebbe essere in grado di ricevere il media ad una velocità che è la minima tra la banda in download del client e quella in upload del server. Poichè il server si trova su una
rete particolarmente prestante (HDSL simmetrica, 10Mbps), occorre scegliere la velocità
in download del client. Grazie alle statistiche sulle visite del portale siamo in grado di
verificare che la quasi totalità degli utenti si connette con connessioni ADSL di almeno
640Kbps in download. Per questa ragione si è scelto 600k come valore massimo per il
bitrate di codifica; non è escluso che alcuni media possano essere codificati con bitrate più
alti, per offrire agli utenti con connessioni migliori video in alta definizione, ma in generale
è bene non superare il valore individuato per non escludere una parte degli utenti.
In maniera abbastanza simile si è individuato anche un limite inferiore, cioè si è partiti
dal caso peggiore. Questo caso peggiore è calcolato però in maniera diversa e cioè non
partendo dalla connessione peggiore, anche perchè sarebbe molto limitante offrire dei contenuti video con codifica minore di 56kbps (e quindi di qualità molto bassa) per i pochi
utenti che utilizzano ancora la linea analogica per connettersi, penalizzando tutti gli altri.
Piuttosto si è preferito prendere come punto di riferimento il giorno e l’ora con il massimo
numero di accessi contemporanei; in questo modo si può suddividere l’intera banda disponibile per tutti gli utenti e verificare la quantità di cui ciascuno di questi può disporre. Si
noti che anche questo è un caso ideale, in quanto si dà per scontato che non si verifichino
rallentamenti e congestioni sulla rete. Il metodo per calcolare il valore è euristico, ma non
è facile individuare un metodo matematico per ottenere questo tipo di misure.
Il valore massimo di visite raggiunte in uno stesso giorno (in una pagina contenente un
media) è risultato essere 581 e il picco, nello stesso giorno, si è registrato nell’orario 18.0019.00, con 116 visitatori. Considerando la durata media del video (12 minuti), si è ricavato
che nel caso peggiore il server di streaming dovrebbe essere in grado di servire circa 24
client contemporaneamente ( 116 / (60 / 12) = 23,2 ). Questo valore sarebbe valido se
non ci fossero sovrapposizioni, cioè se nel caso in cui durante i 12 minuti di durata media
24
del video ci fossero esattamente 24 utenti a guardare il media, per poi lasciare il posto ad
altri 24 e via dicendo. In realtà occorre considerare almeno un minimo di sovrapposizione,
di conseguenza è opportuno raddoppiare il valore individuato e considerare 48 il numero
massimo di utenti concorrenti nella visualizzazioe del media. Con questo valore possiamo assumere di distribuire in maniera equa tutta la banda disponibile agli utenti che ne
facciano richiesta; trattandosi di una 10Mbps simmetrica, l’operazione da eseguire è (10 *
1024) / 48 = 213Kbps.
Il valore 200Kbps potrebbe sembrare un valido limite inferiore, ma si tenga presente che è
stato calcolato sul caso peggiore in assoluto; il valore medio di visite a pagine contenenti
media è molto inferiore. Ancora una volta si deve quindi scegliere un compromesso tra
un valore di bitrate basso, che penalizzerebbe gli utenti in quanto a qualità video per la
maggior parte del tempo, oppure un valore più alto che rischierebbe in qualche caso di
comportare dei forti rallentamenti.
In definitiva un valore per il bitrate che sia situato tra i 200Kbps e i 600Kbps potrebbe
essere un buon candidato, ma occorre tener conto ancora di altri elementi. In primo luogo
i valori individuati non prendono in considerazione l’eventualità di traffico e congestioni
sulla rete, ma non solo, non tengono nemmeno in considerazione molti altri fattori: la
possibilità che i pacchetti possano arrivare con tempi differenti, eventualmente anche in
disordine; ritardi dovuti al carico di lavoro del server; dimensione reale dei pacchetti, dovuta al fatto che i pacchetti RTMP viaggiano sulla rete inscatolati in pacchetti TCP e
IP5 , ecc.
È opportuno perciò considerare i valori individuati come ideali e avere l’accortezza di
abbassare sufficientemente il valore del bitrate per attenuare i problemi dovuti a ritardi,
overhead e simili. Risulta comunque impossibile, qualunque sia il valore scelto, che non
si verificheranno mai rallentamenti; ed in ogni caso non si può pensare di penalizzare
eccessivamente la qualità del video a causa di alcuni, sporadici, rallentamenti. Occorre
per l’appunto trovare un compromesso, perciò alla fine si è scelto un valore attorno ai
250-300Kbps per il bitrate di codifica dei video.
2.3.4
Automazione della procedura di conversione
Dopo aver individuato il formato per i contenuti da trasmettere in streaming, si è ritenuto
opportuno realizzare un sistema in grado di automatizzare la procedura di conversione al
formato scelto. Questa operazione si è resa necessaria per semplificare le operazioni di
caricamento dei video da parte dell’azienda, ma anche per porre le basi per un servizio
che potrà in futuro essere offerto agli utenti, e cioè il caricamento di video personali. Attualmente, ogni community ed ogni social network offrono questo servizio, ma in ambiente
medico, come già detto, non è spesso possibile rendere pubblici questo tipo di contenuti;
di conseguenza avere un portale dedicato solo all’ambiente medico, può favorire molto la
fruizione di questo servizio da parte degli utenti.
Si è quindi cercato uno strumento adatto allo scopo, ma senza alcuna preferenza da
parte dell’azienda. Si sono scelti unicamente strumenti a riga di comando, perché general5
questo fenomeno prende il nome di overhead: ogni messaggio di livello applicazione è spezzato e
inscatolato in uno o più pacchetti TCP e poi in pacchetti IP; di conseguenza la dimensione reale dei
pacchetti che viaggiano sulla rete è maggiore di quella visibile a livello applicazione
CAPITOLO 2. STREAMING SERVER
25
mente più flessibili e semplici da inserire in procedure automatiche. A livello di codifica
della procedura si sarebbe potuto usare un batch file, ma si è preferito ricorrere all’utilizzo della nuova tecnologia PowerShell di Microsoft, perché ritenuta più configurabile, ma
anche per interesse personale del tesista.
Windows PowerShell [23] è un prodotto gratuito di Microsoft che mira alla creazione di
potenti script in grado di eseguire qualunque funzionalità amministrativa, cosa che con
le precedenti shell command.com e cmd.exe non era possibile fare. PowerShell si ispira
fortemente alle più famose shell Unix, in particolare Bash, e perciò vuole offrire le stesse
funzionalità e, quando possibile, anche di più. Per ottenere il risultato, offre una serie di
comandi, noti come cmd-lets, per le più svariate funzionalità e che possono essere combinati tra loro attraverso l’uso delle pipeline. Esattamente come le shell Unix quindi,
è possibile concatenare diversi comandi tra loro e fornire l’output del primo come input
del secondo, ma con una differenza: non si tratta di stream di caratteri, ma di veri e propri oggetti. PowerShell quindi è una shell orientata agli oggetti, costruita sul framework
.NET di Microsoft, di cui eredita tutte le caratteristiche. Per venire incontro alle esigenze
degli amministratori di sistema provenienti dal mondo Unix, infine, questa shell offre diversi alias dei comandi più comuni, analoghi a quelli utilizzati in Bash; per visualizzare il
contenuto di una directory, per esempio, si usa Get-ChildItem, ma anche il più noto ls.
Per la conversione dei video si è poi cercato uno strumento in grado di lavorare con
il maggior numero possibile di formati, in quanto non è noto quali potranno essere quelli
utilizzati dagli utenti. Esistono due strumenti open source estremamente potenti e utilizzati anche in progetti anche molto noti: MEncoder e FFmpeg. Si è scelto di utilizzare il
secondo perché fortemente documentato e perché è oggi considerato il tool di riferimento
per la codifica e decodifica video.
FFmpeg [24] è un progetto nato nel 2000, che mira a creare un unico strumento invocabile
tramite riga di comando, in grado di registrare, convertire e trasmettere il maggior numero di formati audio e video. È rilasciato con licenza GNU/GPL e GNU/LGPL ed è alla
base di moltissimi progetti [25], tra i quali spiccano VLC media player, Ambulant player,
GStreamer e Xine6 .
Esistono molte applicazioni dotate di interfaccia grafica che permettono di codificare e decodificare media utilizzando le funzionalità offerte da FFmpeg. Per realizzare la procedura
di automazione ci si è affidati però alla versione base, invocabile tramite riga di comando.
L’istruzione da usare è
ffmpeg − i i n p u t . mpg −a c o d e c libmp3lame −ab 160 k −b 300 k
−s 640 x480 −f f l v output . f l v
Le opzioni utilizzate in questo caso sono:
• -i input.mpg, indica al player il file di input da utilizzare. Notare che non devono
essere specificate le caratteristiche dello stesso; FFmpeg sarà in grado di capirne
formato e caratteristiche in maniera automatica. I formati accettati in input sono
moltissimi; si rimanda alla documentazione per una lista esaustiva [26].
• -acodec libmp3lame, indica il codec audio da utilizzare per il media convertito. In
questo caso si usa la libreria open source LAME per la codifica in MP3.
6
GStreamer e Xine sono due framework per la gestione di contenuti multimediali utilizzati in tutte le
versioni di GNU/Linux
26
• -ab 160k, indica il bitrate utilizzato per la codifica della traccia audio
• -b 300k, indica il bitrate utilizzato per la codifica della traccia video
• -s 640x480, indica le dimensioni in pixel del media convertito
• -f flv, indica il formato da utilizzare per il media. Questo valore è ricavato in
automatico dall’estensione scelta per il file di output, ma può essere forzato.
• output.flv, è il nome scelto per il file di output
In questo caso sono indicati solo una piccola parte delle opzioni di conversione che FFmpeg
è in grado di accettare; per una trattazione più completa si rimanda alla documentazione
del tool [26].
A questo punto siamo riusciti a convertire il video nel formato voluto, ma non è sufficiente. Se proviamo a riprodurre il video con un normale player notiamo che non è
possibile eseguire il seeking, cioè non è possibile scegliere un punto qualsiasi della riproduzione. FFmpeg in effetti si limita alla conversione delle tracce audio e video, ma non
si occupa di aggiungere alcune informazioni utili all’interno del nostro FLV. Tali informazioni sono dette metadata e possono contenere diversi campi, come titolo, autore, ecc.
Quel che interessa a noi sono però i campi cosidetti cuepoint; un cuepoint è un segnaposto
nella timeline del video, e può essere di tre tipologie: navigazione, evento e ActionScript.
A noi interessa il cuepoint di tipo navigazione, in quanto è quello che permette di effettuare il seeking del video; quando ci si sposta nella timeline del video, si raggiunge in
realtà il cuepoint immediatamente precedente o successivo. Questo implica che per ogni
video dobbiamo inserire molti cuepoint, per rendere le funzionalità di seeking più flessibili. Oltre a trattarsi di un lavoro abbastanza oneroso, è complicato dal fatto che tali
cuepoint dovrebbero essere in qualche modo correlati al contenuto e alla durata del media.
Fortunatamente il nostro server di streaming si occupa personalmente della gestione dei
cuepoint, inserendoli in maniera automatica. Tuttavia prima di affidare il nostro video
al server di streaming, dobbiamo prima predisporlo all’inserimento dei cuepoint, cioè in
pratica dobbiamo creare nel file contenitore lo spazio adatto a contenere i metadata.
Per questa operazione possiamo usare lo strumento FLVTool2 [27]. Sviluppato in Ruby,
Flvtool2 nasce nel marzo 2005 ed è un prodotto open source (licenza BSD) per la manipolazione di file FLash Video. Le funzionalità principali offerte dal programma sono:
lettura e modifica dei metadata, inserimento del tag onMetaData, aggiunta di cue point,
stampa della struttura del file e troncamento del media. Delle diverse funzioni offerte,
quel che interessa nel caso in esame è solo aggiungere lo spazio necessario al contenimento
dei cuepoint. Per ottenere questo risultato possiamo pensare di aggiungere almeno un
cuepoint fittizio, mentre il server di streaming si occuperà di gestire gli altri. L’istruzione
utilizzata per rendere il nostro media in grado di supportare il seeking è:
flvtool2 -AUt header.meta output.flv
In questo caso i parametri sono:
• -A, aggiunge i metatag al file
• -U, aggiorna il file con l’evento onMetaData, utile per la riproduzione del file in
streaming. In pratica si dà la possiblità ai player di catturare l’evento onMetaData
CAPITOLO 2. STREAMING SERVER
27
che permette agli stessi di conoscere alcune informazioni (come durata, autore, titolo)
prima di cominciare la riproduzione del media.
• -t header.meta, indica il file di input che contiene i metatag da inserire nel media
• output.flv, è il file in cui inserire lo spazio per i metatag
Anche in questo caso si rimanda alla documentazione del progetto per una trattazione più
completa delle funzionalità offerte dallo strumento7 .
Il contenuto del file header.meta è molto limitato, ma è sufficiente per rendere qualunque
file FLV in grado di supportare le funzionalità di seeking:
<t a g s >
<metatag e v e n t ="onCuePoint " o v e r w r i t e =" t r u e ">
<name>Cue Point </name>
<timestamp >500</timestamp>
<type>n a v i g a t i o n </type>
</metatag>
</t a g s >
L’effetto reale dell’inserimento di questo metatag all’interno del file FLV, è quello di inserire
un cuepoint di tipo navigazione e di nome Cue Point a 500 millisecondi dall’inizio del
media (posto che qualunque media inserito nel portale duri più di mezzo secondo).
Avendo quindi questi strumenti a disposizione, ora non resta che realizzare uno script
in PowerShell, capace di automatizzare le operazioni di conversione.
Figura 2.12: flowchart della procedura di conversione automatica dei video
Il codice della procedura realizzata è:
# C a r t e l l a dove sono c a r i c a t i i v i d e o
$src_path = "C: \ temp\ t o C o n v e r t "
# C a r t e l l a dove vengono s p o s t a t i i f i l e c o n v e r t i t i
$dest_path = "C: \ Programmi \Red5\ webapps \ c o n v e r t \ s t r e a m s "
# P e r c o r s o d e l f i l e con g l i h e a d e r FLV
$header_path = "C: \ temp\ h e a d e r . meta "
$ v i d s = Get−C h i l d I t e m −r e c $src_path
$number_of_videos = $ v i d s | Measure−O b j e c t − l i n e
# V e r i f i c a s e sono p r e s e n t i v i d e o da c o n v e r t i r e
7
Al momento della stesura di questo documento, il sito ufficiale del progetto è in manutenzione, di
conseguenza non è ancora possibile accedere alla sezione con la documentazione. Per ottenere le opzioni
d’uso del programma si può comunque invocare il comando con l’opzione -H
28
i f ( $number_of_videos ) {
" Sono p r e s e n t i v i d e o da c o n v e r t i r e "
# Converte o g n i v i d e o
foreach ( $vid in $vids ) {
# C o s t r u i s c e i l nome u n i v o c o p e r o g n i v i d e o
$ s u f f i x = get −d a t e −uformat "%Y%m%d−%H%M%S "
$ f i l e _ n a m e = $dest_path + " \ v i d e o " + $ s u f f i x +". f l v "
# Converte i l v i d e o
ff mp e g − i $src_path \ $ v i d −a c o d e c libmp3lame −ab 160 k −s 640 x480 −b
300 k −y . / ou tp ut . f l v | out−n u l l
# Aggiunge l ’ h e a d e r n e c e s s a r i o a l v i d e o
f l v t o o l 2 −AUt $header_path . / o ut pu t . f l v | out−n u l l
# Sposta i l video c o n v e r t i t o n e l l a p o s i z i o n e f i n a l e
mv . / out pu t . f l v $ f i l e _ n a m e
# Elimina i l video di partenza
rm $src_path \ $ v i d
} # foreach
} else {
" Nessun v i d e o da c o n v e r t i r e "
} # else
Le operazioni svolte dallo script sono abbastanza semplici. Inizialmente vengono definite
alcune variabili con i percorsi dove sono contenuti i video da convertire e dove devono
essere spostati quelli convertiti. Poi si verifica la presenza di video da convertire; se non
ce ne sono la procedura termina. Se sono presenti dei video invece, un ciclo li elabora ad
uno ad uno, occupandosi in primo luogo di convertirli al formato FLV tramite FFmpeg e
in seguito di aggiungere i metatag necessari per il seeking utilizzando FLVtool2. A questo
punto il video è pronto per essere spostato nella directory del server di streaming. Occorre
però evitare che vi siano più file con lo stesso nome, per non rischiare la sovrascrittura.
La soluzione più semplice per risolvere questo problema è quella di generare un nome file
univoco, per esempio basato sulla data e l’ora del server.
Per poter eseguire script non firmati digitalmente con Windows PowerShell, è necessario abbassare il livello di protezione della shell, tramite il comando
Set-ExecutionPolicy RemoteSigned
Una volta eseguita l’istruzione, essa sarà valida sino a che un’altra istruzione simile non
cambi lo stato; in pratica tale istruzione dev’essere eseguita una volta sola e non serve
inserirla nello script.
Bisogna anche assicurarsi di rendere disponibili i comandi FFmpeg e FLVtool2 alla shell,
inserendoli nella variabile d’ambiente PATH.
Adesso ci sono tutti gli elementi per poter automatizzare la procedura di conversione
dei video; è sufficiente richiamare lo script realizzato tramite un’operazione pianificata di
Windows a intervalli stabiliti a priori. Si tenga presente che uno script PowerShell non
è direttamente eseguibile come una procedura batch, ma può essere lanciato tramite il
comando:
powershell.exe nomescript.ps1
CAPITOLO 2. STREAMING SERVER
29
30
Capitolo 3
Sincronizzazione di contenuti
multimediali
3.1
Introduzione
Esistono diversi tipi di relazione che due o più media possono avere tra loro. In un foglio
di calcolo, per esempio, una serie di dati e il grafico che li rappresenta, hanno tra loro
una relazione di contenuto: entrambi rappresentano la stessa informazione, ma in modi
diversi; se cambia parte dell’informazione, entrambi devono cambiare. In un ambiente
bidimensionale o tridimensionale invece, ci possono essere relazioni di tipo spaziale: un
oggetto e la sua ombra devono muoversi in maniera coerente. Infine si parla di relazioni
temporali, quando due media hanno la necessità di essere riprodotti con precisi vincoli di
tempo; si pensi ad esempio ad un video ed all’audio ad esso associato.
Il termine sincronizzazione può essere applicato a tutti gli esempi di relazione presentati,
ma è più spesso associato ai vincoli temporali ed anche in questa sede si userà il termine
sincronizzare per indicare la volontà di far rispettare le relazioni temporali tra due o più
media.
Il tema della sincronizzazione è molto importante; se torniamo sull’esempio di un media
composto da video e audio, possiamo identificare diversi momenti in cui occorre mantenere relazioni temporali tra i due canali. Al momento dell’acquisizione, l’audio è acquisito
tramite microfono, mentre il video tramite una telecamera; i due canali poi sono generalmente inseriti in formato non compresso in un file contenitore, che deve mantenere la
sincronizzazione. Il media poi è trasferito su computer, dove viene in genere compresso in
un altro formato contenitore; anche questo nuovo formato deve mantenere la sincronizzazione tra l’audio e il video. Per essere riprodotto, infine, il media dev’essere decodificato
dal formato compresso, e ancora una volta è necessario conoscere i vincoli temporali per
poterlo presentare all’utente in modo coerente; si pensi all’eventualità di riprodurre un
media in cui si sente la voce di una persona, mentre si sta guardando il video di quella
persona che però non sta parlando affatto. Per l’utente è un risultato molto insoddisfacente, che può anche pregiudicare l’intero significato del media: si pensi ad un film dove
le frasi di un personaggio sono riferite da un altro personaggio.
Mantenere i vincoli temporali, però, non è un problema banale. Nel paragrafo 2.3.3, si è
parlato del formato FLash Video (FLV), descrivendolo come un formato contenitore, in
31
grado di memorizzare sia l’audio che il video di un media. I due canali non possono evidentemente essere memorizzati in maniera contigua, per esempio prima tutte le informazioni
video e poi tutte quelle audio, perché nel caso di una trasmissione in streaming dovremmo
attendere di ricevere tutte le informazioni video per ricevere anche i primi pacchetti audio
e quindi essere in grado di riprodurre il media. In effetti FLV memorizza frammenti audio
e frammenti video (chiamati tag) in modo alternato [28]; ma in questo caso occorre tener
presente che i due canali sono codificati con bitrate differenti, perché un secondo di video
richiede inevitabilmente più informazione di un secondo audio. Bisogna quindi tener conto
di queste differenze, sia nel caso di memorizzazione su disco, sia nel caso di trasmissione
su rete.
Gli esempi fin qui proposti dovrebbero chiarire almeno in parte le difficoltà, ma anche
l’importanza che il tema della sincronizzazione riveste in ambito multimediale. La seconda
parte dello stage verte proprio su questi temi, in quanto l’obiettivo è quello di realizzare
un prodotto in grado di sincronizzare alcuni contenuti multimediali.
Il primo obiettivo è quello di creare un software relativamente semplice che permetta la
sincronizzazione tra un video e alcune slide. L’esigenza nasce dal fatto che l’azienda dispone di diverse registrazioni di convegni e insegnamenti dove un relatore espone i contenuti
seguendo come traccia delle diapositive. Quello che ci si aspetta dal prodotto finale è
un’interfaccia che visualizzi la registrazione dell’incontro da un lato e la diapositiva dall’altro; quest’ultima dev’essere aggiornata negli stessi istanti in cui il relatore passa alla
slide successiva. Similmente si vorrebbe permettere di scegliere una slide ed effettuare
automaticamente il seeking del video all’istante corretto.
3.1.1
Strumenti e tecnologie utilizzate
In prima analisi, si sono valutate le soluzioni attualmente in uso dall’azienda per raggiungere scopi simili a quello di questa seconda parte di stage. Queste soluzioni si dividono
principalmente in due categorie: una, più semplice, che si limita a registrare non solo il
video del relatore, ma anche la diapositiva visualizzata, e la seconda che utilizza invece
un prodotto in grado di creare un’applicazione Flash dove video e slide sono incorporate
in un unico filmato swf e la timeline del video è aggiornata automaticamente in base alla
slide visualizzata (figura 3.1). Con questo prodotto non è però possibile scorrere lungo il
video e non è nemmeno possibile includere la presentazione in una pagina web esistente,
perché il filmato occupa in maniera predefinita l’intera pagina.
Le due soluzioni presentate sono considerate poco flessibili, tuttavia offrono due vantaggi
considerevoli: in primo luogo non richiedono nessun’applicazione lato utente, ad esclusione
del già discusso player Flash installato come plug-in in un browser; il secondo vantaggio
è che non richiedono nemmeno particolari accorgimenti lato server, per esempio script di
gestione in ASP. Se possibile, sarebbe opportuno disporre un prodotto più flessibile, ma
che mantenga i pregi elencati.
Come seconda fase di analisi si è scelto di verificare l’esistenza di prodotti sviluppati
da terzi, sia gratuiti che a pagamento, per valutare se fosse opportuno affidarsi a questi o
realizzarne effettivamente uno ex-novo. Anche in questa seconda ipotesi, l’analisi di prodotti concorrenti avrebbe comunque favorito lo sviluppo, suggerendo approcci da seguire
per la realizzazione del software. La ricerca, però, non ha dato risultati molto interessanti:
32
Figura 3.1: applicazione Relator in esecuzione
sono stati individuati pochi prodotti e generalmente orientati alla creazione di applicazioni
desktop, piuttosto che web.
Si è quindi passati alla fase di scelta degli strumenti per sviluppare l’applicazione; tali
strumenti saranno ora descritti brevemente.
AJAX, acronimo di Asynchronous Javascript And XML, è un insieme di tecnologie
utilizzate lato client per lo sviluppo di applicazioni web sofisticate. Non si tratta quindi
di un singolo oggetto o libreria, ma di diverse componenti:
• XHTML e CSS per la presentazione e formattazione delle informazioni
• XML o altre tecnologie per la rappresentazione dei dati
• Javascript per l’esecuzione di operazioni lato client
• un sistema per la comunicazione asincrona con il server
Si noti che, a dispetto del nome, nè XML nè Javascript sono realmente necessari per la
creazione di applicazioni AJAX; è possibile infatti sostituire il primo con altre tecnologie per la rappresentazioni dei dati, per esempio HTML, testo semplice o JSON1 . Non è
nemmeno necessario far strettamente uso di Javascript, in quanto altre tecnologie come
1
JSON è una tecnologia per rappresentare i dati comunemente utilizzata nelle applicazioni AJAX. È
talvolta preferita a XML perché più incentrata nel semplice scambio dati e quindi, sebbene meno estendibile,
risulta spesso più leggera.
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
33
JScript o VBScript, entrambe di Microsoft, sono in grado di effettuare chiamate asincrone; occorre tuttavia precisare che generalmente Javascript è preferito, perché offre meno
problemi di compatibilità tra i diversi browser utilizzati dagli utenti.
La vera novità introdotta da AJAX è un metodo per comunicare in maniera asincrona con
il server; esistono diverse soluzioni per ottenere questo scopo, ma la più nota e utilizzata è
l’uso dell’oggetto XMLHttpRequest (XHR). Introdotto per la prima volta nel 1999 in Microsoft Internet Explorer 5, XMLHttpRequest diventa celebre tra il 2004 e il 2005, quando
Google comincia ad utilizzarlo per le sue applicazioni GMail e Google Maps; sempre nel
2005 viene coniato l’acronimo AJAX per indicare questo tipo di nuove tecnologie che suscitano sempre maggior interesse per i web developer. Nell’aprile 2006 il W3C rilascia la
prima working draft sull’oggetto XMLHttpRequest, nel tentativo di creare uno standard
comune per tutti i browser [29]. Ad oggi ancora non si è usciti dallo stato di working draft,
anche se si prevede che ciò accadrà nei prossimi mesi; in ogni caso XMLHttpRequest è
supportato da tutti i browser più diffusi, anche se talvolta in modo differente rispetto alla
bozza del W3C.
La reale novità introdotta dall’oggetto XHR è la possibilità di ricevere delle informazioni
anche dopo che una pagina è stata completamente caricata, in maniera asincrona appunto. Prima della diffusione di AJAX, l’unica soluzione per realizzare applicazioni web in
grado di interagire con l’utente, era attraverso chiamate sincrone: l’utente inserisce alcuni
dati in un modulo e li invia; a questo punto il server li riceve, li elabora e prepara una
pagina di risposta per l’utente. Questo sistema, che è stato affiancato e non sostituito da
AJAX, ha alcuni svantaggi notevoli. In primo luogo può disorientare l’utente abituato alle
applicazioni desktop: si supponga di utilizzare un word processor che ad ogni salvataggio
nasconda la finestra di lavoro per qualche secondo. Occorre evidenziare che in questa
sede si sta discutendo di applicazioni web e non di siti vetrina o portali; se è vero che
l’approccio sincrono può disorientare l’utente di applicazioni web, è altrettanto vero che
utilizzare AJAX in contesti dove non è richiesta molta interazione con l’utente, può rendere più difficile la navigazione e meno accessibile la pagina (si tenga presente che browser
testuali e screen reader generalmente non eseguono contenuti javascript). Il secondo svantaggio dell’approccio tradizionale è lo spreco di risorse: se si deve aggiornare solo parte dei
contenuti di una pagina, non si dovrebbe esser costretti a scaricare nuovamente tutta la
pagina HTML, i fogli stile e gli eventuali script. Con AJAX queste informazioni possono
essere scaricate solo la prima volta, mentre il contenuto variabile può essere aggiornato
con chiamate asincrone.
Nel software che si intende sviluppare, AJAX rivestirà un ruolo molto importante, perché
sarà utilizzato per il download di un documento XML con le informazioni sui media e sulla
sincronizzazione. Non sarà tuttavia utilizzato in maniera asincrona, perché l’unica richiesta del documento XML sarà effettuata al caricamento della pagina. Si sarebbe quindi
potuto evitare di usare un documento XML per rappresentare i dati ed evitare anche la
chiamata AJAX, ma si è preferito seguire questa strada per separare in maniera netta
la logica di programma e lo stile di presentazione dai dati da rappresentare. In pratica
si è voluto rispettare il design pattern Model - View - Controller (MVC), per realizzare
un’applicazione più flessibile e mantenibile. La corrispondenza tra le entità del pattern e
le componenti del software realizzato è visibile in figura 3.2.
34
Figura 3.2: corrispondenza tra le entità del pattern MVC e le componenti software
Il secondo strumento di cui si farà largo utilizzo è jQuery [30]. Presentato per la prima
volta nel 2006, jQuery è una libreria JavaScript ideata da John Resig, un dipendente di
Mozilla Corporation. Le principali caratteristiche di questa libreria sono:
• Attraversamento e modifica del DOM2 di una pagina in maniera semplificata. È
possibile, tra l’altro, accedere ai nodi con l’utilizzo di selettori CSS
• Gestione migliorata e semplificata degli eventi JavaScript
• Inclusione di alcuni effetti ed animazioni
• Supporto ad AJAX
jQuery è un prodotto open source, gratuitamente scaricabile dal sito ufficiale in due formati: la versione di sviluppo, non compressa, che permette di leggere e modificare il codice
della libreria (117K) e la versione minified 3 che pesa soltanto 56K. Il principale vantaggio
nell’utilizzo della libreria, è che essa permette di concentrarsi sulla logica dell’applicazione
che si intende realizzare, senza doversi preoccupare eccessivamente delle problematiche di
compatibilità tra i browser; in pratica, jQuery offre un livello di astrazione che ci assicura che il codice produrrà gli stessi risultati, indipendentemente dal browser utilizzato.
2
Document Object Model (DOM) è un insieme di API per l’accesso agli elementi di un documento
XML. Dal 1998 DOM è una raccomandazione W3C.
3
Il termine minified indica una versione compressa del codice di un software. La compressione avviene
togliendo tutti gli spazi bianchi, rinominando variabili e funzioni in modo che contengano meno caratteri ed
eliminando i commenti; alcuni strumenti particolarmente avanzati permettono di individuare e rimuovere
codice inutile o sostituire alcuni costrutti con altri equivalenti ma che utilizzano meno caratteri. Utilizzare
uno strumento per la compressione del codice sorgente ha senso solo per i linguaggi interpretati, perché
in quelli compilati è lo stesso compilatore ad occuparsene. La versione compressa (o minified) del codice
è perfettamente equivalente alla versione originale, ma risulta incomprensibile per l’uomo; il suo scopo
principale è quello di diminuire la dimensione dei dati da trasmettere all’utente ed è oggi largamente
utilizzata per le applicazioni web. Anche nello sviluppo del software obiettivo dello stage si è utilizzato
uno strumento di compressione per realizzarne una versione compressa; il prodotto scelto è Yahoo! User
Interface (YUI) Compressor [31]
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
35
Per esempio si potrebbe utilizzare direttamente l’oggetto XMLHttpRequest per effettuare chiamate asincrone, ma il codice dovrebbe crearlo in maniera diversa a seconda del
browser; fino alla versione 6 di Internet Explorer infatti, l’oggetto si poteva ottenere solo
tramite un controlo ActiveX. In questo caso jQuery è di aiuto, perché offre, tra le altre
cose, un supporto cross-browser all’utilizzo di AJAX.
Il terzo prodotto di cui si ha necessità è il player Flash. Per l’applicazione si è scelto
fin da subito di utilizzare Flowplayer, perché si tratta di un prodotto open source, già noto
all’azienda ed estremamente flessibile.
Flowplayer è un software che nasce nel 2005, come progetto open source ospitato su Sourceforge. Nel giro di breve tempo, il player è in grado di offrire molte funzionalità, anche
avanzate, e per questo riscuote gran successo; la versione 2 del software, sviluppata tra il
2006 e il 2008, conta anche migliaia di download al giorno. Nell’ottobre 2008 è rilasciata
la versione 3, completamente ridisegnata per supportare jQuery. La nuova versione è ricca di funzionalità, che possono ulteriormente essere estese attraverso l’utilizzo di plugin.
Il design fortemente flessibile, permette di sviluppare applicazioni javascript in grado di
interagire con il player, ed è proprio grazie a questo che è stato possibile realizzare i prodotti descritti nei paragrafi seguenti. Flowplayer è aggiornato in maniera regolare e può
contare su una comunità molto attiva, che si occupa della creazione e del mantenimento
dei plugin e della stesura della documentazione. È presente in versione open source, con
licenza GNU/GPLv3, ma anche in versione commerciale, utile per sviluppare applicazioni
proprietarie che facciano uso di questo player. Le due versioni offrono esattamente le stesse
funzionalità, ma la versione commerciale permette di sostituire il logo di Flowplayer con
uno a scelta.
Per le prime fasi di sviluppo, si è fatto inoltre uso di un altro software: Galleria [32].
Si tratta di uno script open source e scritto in jQuery, che permette di inserire una galleria
di immagini in una pagina web. È un’applicazione abbastanza semplice, ma che offre
funzionalità interessanti ed anche qualche effetto visivo accattivante. L’applicazione è
stata modificata in più settori, in modo da renderla più adatta a gestire uno slideshow 4 e
da permettere la sincronizzazione con il video del relatore.
3.1.2
SMIL: Synchronized Multimedia Integration Language
Nel paragrafo precedente si è evidenziata la volontà di rispettare il pattern MVC nello
sviluppo dell’applicazione. In particolare si intendono mantenere separate dal resto le informazioni sui contenuti (video e diapositive) da visualizzare; questa scelta permetterebbe
tra l’altro di creare molte pagine con diverse presentazioni aggiornando solo la componente Model e riutilizzando senza modifiche le altre due. Per poter raggiungere questo
scopo però occorre scegliere un formato per il file con le informazioni sui media e, per
mantenere l’applicazione il più interoperabile possibile, sarebbe opportuno utilizzare un
formato aperto e leggibile. Il formato XML si rivela particolarmente adatto in situazioni
come questa, ma occorre anche scegliere una grammatica per poter validare il documento,
per esempio attraverso un DTD o un XML Schema.
4
Il termine slideshow indica una presentazione effettuata attraverso l’uso di una serie di immagini,
dette anche diapositive (o slide in inglese). Esistono dei software appositi per la creazione di questo tipo
di presentazioni, come Microsoft PowerPoint o OpenOffice.org Impress
36
A tal scopo esiste uno standard W3C che si occupa proprio della descrizione di documenti
multimediali in linguaggio XML: Synchronized Multimedia Integration Language (SMIL).
Dalla pagina del World Wide Web Consortium dedicata a SMIL [33]:
SMIL permette la creazione di presentazioni audiovisive interattive. SMIL
è tipicamente usato per presentazioni multimediali che integrano audio e video
in streaming con immagini, testo o qualunque altro tipo di media. SMIL è
un linguaggio facile da imparare, simile a HTML ed è possibile sviluppare
presentazioni SMIL con un semplice editor di testo.
SMIL è rilasciato come raccomandazione W3C nel giugno 1998. La prima versione dello
standard offre le prime funzionalità per il posizionamento e la temporizzazione dei media,
ma è abbastanza limitata; alcune implementazioni offrono diverse funzionalità aggiuntive
proprietarie.
Nel 2001 le specifiche della seconda versione di SMIL diventano raccomandazione W3C;
la nuova versione aggiunge nuove funzionalità, come supporto a eventi utente, transizioni
e animazioni. Due anni più tardi viene aggiunto il profilo per gli MMS, con funzionalità
ridotte per garantire un miglior supporto alle limitate risorse hardware dei dispositivi
mobili. Nel 2001, con la versione 2.1 dello standard, vengono incluse altre migliorie sempre
dedicate a questi dispositivi.
La versione più recente di SMIL è la 3.0, rilasciata nel dicembre 2008; essa introduce, fra
l’altro, il concetto di stato (attraverso l’uso di variabili) e una gestione più flessibile del
testo.
Lo standard prevede alcuni profili, cioè sottoinsiemi del linguaggio nel suo complesso;
in pratica un profilo limita i tag o gli attributi utilizzabili, oppure il modo in cui questi
interagiscono tra loro (per esempio un profilo può prevedere un grado massimo di annidamento tra alcuni elementi). L’esistenza dei profili semplifica la realizzazione dei player,
in quanto un’implementazione può limitarsi ad aderire ad un profilo piuttosto che dover
supportare l’intero linguaggio; in questo modo si possono avere delle classi di player equivalenti. Si pensi ad esempio ai telefoni cellulari: le limitazioni hardware impediscono di
poter aderire in maniera completa allo standard, ma si vorrebbe comunque disporre di
uno standard, in modo che due modelli distinti di telefono siano in grado di visualizzare
correttamente e in maniera identica la stessa presentazione.
I profili definiti nell’ultima versione di SMIL sono:
• SMIL 3.0 Language Profile, è la versione completa del linguaggio
• SMIL 3.0 UnifiedMobile Profile, è la versione pensata per i dispositivi mobili, con
risorse limitate
• SMIL 3.0 Daisy Profile, ideato per i documenti DAISY, cioè libri dedicati a persone
con disabilità visive
• SMIL 3.0 Tiny Profile, è il profilo minimale, con le basilari funzionalità di disposizione e temporizzazione dei media
Esistono inoltre altri profili per l’utilizzo di SMIL in maniera embedded in altri linguaggi.
È il caso, per esempio, dei profili smilText e XHTML+SMIL. Le principali funzionalità
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
37
che la versione più recente di SMIL (profilo Language) definisce sono:
• Definizione del layout del documento
• Inserimento di media di diversa natura
• Specifica delle relazioni temporali tra i media
• Inserimento di collegamenti ipermediali
• Aggiunta di effetti di transizione ai media
• Aggiunta di animazioni agli oggetti del documento
• Supporto agli eventi, anche scatenati dall’utente
Si noti che SMIL è solo il linguaggio che descrive la presentazione; non si tratta quindi di
uno strumento di authoring 5 .
Per riprodurre una presentazione SMIL abbiamo bisogno di un player, per esempio Real
Player [34] o Ambulant Player [35]. Attualmente non è possibile riprodurre direttamente
la presentazione SMIL tramite browser senza l’utilizzo di plugin, nonostante si tratti di un
linguaggio XML e di una raccomandazione W3C; occorre evidenziare però che Mozilla sta
gradualmente introducendo SMIL nel proprio browser, mentre Microsoft Internet Explorer
supporta in maniera non completa il profilo XHTML+SMIL (o meglio supporta il formato
proprietario HTML+TIME [36], che però è per gran parte equivalente allo standard).
Nonostante queste limitazioni, SMIL è oggi molto utilizzato: la tecnologia MMS supportata dai cellulari utilizza un profilo SMIL apposito, così come la televisione digitale
brasiliana per fare solo due esempi. Spesso questo linguaggio è utilizzato anche in maniera
più limitata, per esempio per gestire una playlist di un media player; una soluzione simile
si è adottata anche nella prima versione del software sviluppato durante lo stage.
La sintassi del linguaggio è simile a quella di HTML, nel senso che sono previste due
sezioni principali: head dove si definiscono il layout e le eventuali animazioni e body dove
si specificano i media e i vincoli temporali da rispettare. Nella sezione head possono
essere specificate le regioni, cioè le aree dello schermo adibite a contenere i media da
visualizzare. Una regione si definisce con il tag region; posizione e dimensione delle
regioni sono specificate attraverso gli attributi width, height, top, left e z-index; i
valori top e left sono relativi alla finestra che contiene la regione. Si noti la corrispondenza
con le proprietà omonime dei fogli stile CSS.
Nella sezione body invece si devono inserire i media da riprodurre e le informazioni sulla
temporizzazione. Un media è in particolare definito dal suo tipo (audio, video, immagine,
ecc), definito nel nome del tag6 , dal suo percorso, definito nell’attributo src, e dalle
informazioni di temporizzazione, definite dagli attributi begin, end e dur. Esistono anche
5
Uno strumento di authoring è un’applicazione che, attraverso interfaccia grafica, permette di posizionare i media e indicare cosa accade nella presentazione istante per istante. Esistono comunque strumenti
di authoring in grado di creare presentazioni SMIL
6
Il nome del tag in realtà è solamente indicativo; in pratica è, per esempio, possibile indicare che si
intende inserire un’immagine nella presentazione e indicare nel percorso un video. Il tipo reale del media
è individuato dal player durante la riproduzione
38
alcuni tag per la gestione dei vincoli temporali: seq crea una playlist in sequenza, par
permette la riproduzione parallela di due o più media (su regioni distinte), excl permette
la riproduzione alternata di uno solo dei suoi figli, a seconda di alcuni eventi. Seq, par
e excl supportano tutti gli attributi di temporizzazione definiti per i media; attraverso
l’uso di questi attributi si possono usare i costrutti per la temporizzazione in maniera
poco idonea, ma comunque considerata corretta per lo standard; è per esempio possibile
realizzare un par tra due media che sono però annidati in un seq. Questo accade perché
questi costrutti sono soltanto indicativi, esattamente come i tipi dei media; sta a chi crea
la presentazione usarli in maniera opportuna.
Si sono finora descritti gli elementi di SMIL necessari per comprendere il lavoro descritto
nelle successive sezioni; in realtà questo standard prevede molti altri tag e molti altri
attributi, ma per una trattazione completa si rimanda alla specifica W3C [37].
In conclusione, SMIL si rivela essere la scelta ideale per memorizzare le informazioni
sui media e sulla temporizzazione degli stessi.
L’adozione di uno standard porta con sè alcuni importanti vantaggi:
• Non occorre progettare un formato apposito per la memorizzazione delle informazioni, il che non solo riduce i tempi di sviluppo, ma garantisce di utilizzare un formato
corretto, flessibile ed estendibile
• Aumento dell’interoperabilità con eventuali altri software; per esempio si può utilizzare uno strumento di authoring per creare il documento SMIL della presentazione
Nella seconda versione dell’applicativo, l’importanza dell’adozione di uno standard sarà
ancor più critica, ma questo tema sarà discusso in dettaglio nel paragrafo 3.2.2.
3.2
Sviluppo di un’applicazione web per la sincronizzazione
di contenuti multimediali
3.2.1
Sviluppo di un’applicazione per la sincronizzazione tra video e
slide
Il primo prodotto da sviluppare, come già anticipato, è un’applicazione per la sincronizzazione di un video e di alcune slide, che il relatore ha mostrato durante l’evento (che può
essere, per fare un esempio, la presentazione di un nuovo farmaco). Il video dev’essere
disponibile sul server di streaming, in modo da sfruttarne le funzionalità, permettendo,
tra l’altro, di effettuare le operazioni di seeking in maniera più rapida e di non effettuare
il caching del media sul computer dell’utente. Lo slideshow dev’essere invece una semplice
sequenza di immagini, ottenute dal file originale della presentazione. Il formato delle immagini può essere ovviamente qualunque formato direttamente leggibile dal browser senza
l’utilizzo di plugin, quindi in particolare:
• il formato GIF (Graphics Interchange Format), che dovrebbe essere utilizzato quando sono presenti molte immagini artificiali, per esempio il testo, e possibilmente
sfumature in numero limitato.
• il formato JPEG (Joint Photographic Experts Group), che dovrebbe essere utilizzato
nel caso la presentazione utilizzi molte immagini naturali, per esempio fotografie. Si
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
39
tenga presenta che il rendering del testo con questo formato è generalmente più
scadente di quello del formato GIF.
• il formato PNG (Portable Network Graphics), che dovrebbe essere preferito a GIF
nella maggior parte dei casi, in quanto consente di ottenere risultati discreti ad
un grado di compressione generalmente più elevato. Nel caso si intenda utilizzare
immagini con trasparenza si deve tener presente che potrebbe mancare il supporto
su browser meno recenti.
Fortunatamente i due maggiori prodotti per la creazione di presentazioni con diapositive,
e cioè Microsoft PowerPoint e OpenOffice.org Impress, permettono entrambi di esportare
la presentazione in maniera automatica e in uno qualsiasi dei formati sopra esposti.
Il percorso delle immagini può essere indicato nel documento SMIL di configurazione in
modo assoluto. Questo significa che le immagini possono risiedere in un qualunque spazio
web; per semplicità saranno però inserite negli esempi seguenti nello stesso server che si
occupa di offrire le pagine web. Per realizzare l’interfaccia si è preso come riferimento
l’applicazione attualmente in uso dall’azienda, cioè Relator (figura 3.1). Si vorrebbe ottenere un prodotto simile, ma più flessibile, che permetta cioè di modificare radicalmente
l’aspetto visivo della pagina e offra alcune funzionalità aggiuntive. Per ottenere il primo
punto, si è scelto di dividere tutta la componente View, tra la pagina HTML e i fogli stile
CSS. In particolare la prima si occupa di posizionare gli elementi (player, titolo, pulsanti)
e di associare loro una classe CSS, mentre il secondo si occupa dello stile grafico degli
elementi. Anche in questo caso si sta rispettando il pattern MVC e precisamente si è
descritta la componente View.
Per la prima versione del lavoro si è scelto di utilizzare uno script realizzato in jQuery
per la gestione dello slideshow, Galleria (vedi par. 3.1.1). Tale scelta è stata fatta per
poter rendere più semplice e veloce la fase di sviluppo e per studiare un esempio d’uso
relativamente sofisticato della libreria jQuery. Sono state necessarie diverse modifiche
al codice di Galleria per raggiungere lo scopo; in primo luogo si è dovuto fare a meno
di alcune funzionalità, per esempio il plugin che gestisce l’oggetto history del browser.
Questo plugin permette di fare clic sul pulsante Indietro del browser per visualizzare
l’immagine precedente piuttosto che navigare alla pagina precedentemente visualizzata;
tale operazione però avrebbe reso più difficile la gestione del seeking del video, perché
si sarebbe dovuto intercettare l’evento del browser oltre che quello dello script per lo
slideshow. Si è anche eliminata la funzionalità che mostrava le anteprime delle immagini
della galleria, perché considerata poco flessibile e inadatta alla gestione di uno slideshow. In
maniera analoga sono state invece aggiunte delle funzionalità, in particolare lo scorrimento
tramite i pulsanti Precedente e Successiva (prima si poteva navigare solo attraverso le
anteprime o facendo clic sull’immagine stessa per passare alla successiva). È stato aggiunto
anche il supporto al seeking del video, gestito sempre tramite i pulsanti di navigazione della
galleria.
Al termine delle modifiche, lo script offre le seguenti funzionalità:
• Un costruttore7 che riceve come parametro un array di URL corrispondenti alle
immagini da visualizzare
7
JavaScript non è un linguaggio propriamente orientato agli oggetti, ma è possibile comunque creare
della variabili a cui associare metodi e attributi, facendo sì che queste si comportino in maniera simile
40
• Il metodo activate, che dato l’URL di un’immagine, visualizza questa come slide
corrente
• I metodi next e prev che navigano rispettivamente all’immagine successiva e precedente dello slideshow
• I metodi nextAndSeek e prevAndSeek che navigano nello slideshow e richiamano
opportunamente le funzionalità di seeking del player
L’oggetto Galleria mantiene al suo interno lo stato dello slideshow, quindi informazioni
come l’indice e l’url della slide correntemente visualizzata, utili per la realizzazione dei
metodi next, prev, nextAndSeek, prevAndSeek.
Si è detto che al costruttore dell’oggetto Galleria è passato l’array con i percorsi delle
immagini. Analogamente a questo, esiste un secondo array della stessa dimensione che
contiene invece i cuepoint a cui le slide devono essere sincronizzate. In pratica ad ogni
immagine corrisponde un elemento del secondo array che contiene un istante temporale
espresso in millisecondi; tali informazioni sono necessarie per ottenere la sincronizzazione
e devono essere gestite dal player.
Per quanto riguarda Flowplayer invece, non è stato necessario modificare in alcun modo lo script di gestione del player e questo grazie alla grande flessibilità del prodotto.
Flowplayer offre infatti molti metodi per l’accesso alle informazioni sullo stato della riproduzione e per la modifica delle stesse. Per esempio, attraverso il metodo getTime() è
possibile ottenere il tempo della riproduzione in millisecondi; si rimanda alla documentazione per una lista completa delle funzionalità [38].
Quando si crea l’oggetto Flowplayer, inoltre, è possibile passare al costruttore molte
opzioni. È possibile fra l’altro:
• impostare uno o più media da visualizzare
• cambiare in ogni aspetto lo stile grafico del player
• aggiungere opportuni plugin (in particolare ne occorre uno per poter riprodurre flussi
RTMP)
• specificare alcune operazioni da effettuare quando si verificano taluni eventi
È stato necessario utilizzare ciascuna di queste funzionalità nelle diverse fasi dello sviluppo
e in particolare l’ultima ha permesso di ottenere la sincronizzazione tra video e slide. Gli
eventi che è necessario gestire sono onStart, onSeek e onCuepoint.
L’evento onStart è richiamato quando il player ha terminato la fase di handshaking
e buffering iniziale, di conseguenza la riproduzione sta effettivamente per cominciare. Nel
frattempo l’utente sta già visualizzando la pagina ed anche lo slideshow, cioè ha a disposizione i pulsanti per navigare tra le slide e potrebbe volerli utilizzare anche prima di aver
cominciato la riproduzione del video, ma così facendo romperebbe la sincronizzazione. Di
conseguenza occorre bloccare la funzionalità fino a che il video non è pronto per essere
riprodotto oppure spostare la riproduzione al punto della slide correntemente visualizzata;
agli oggetti di un linguaggio OOP. Quest’approccio è stato seguito nella realizzazione di tutti gli script
utilizzati, quindi da jQuery, Flowplayer e Galleria. Ecco perché si può parlare di costruttore, campi e
metodi.
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
41
Evento
onStart
onSeek
onCuepoint
Tabella 3.1: funzionalità associate agli eventi del player
Quando è lanciato
Funzione associata
Inizio della riproduzione, dopo il Viene effettuato il seeking del vibuffering
deo al cuepoint associato alla slide
attualmente visualizzata
L’utente ha selezionato un punto È visualizzata la slide che corrinella timeline del video
sponde al cuepoint più vicino, tra
quelli con tempo minore
Raggiungimento di un cuepoint
È richiamato il metodo next() dello
slideshow
si è scelta questa seconda soluzione.
L’evento onSeek è richiamato quando l’utente ha selezionato un punto nella timeline del
video; occorre individuare la slide che dovrebbe essere visualizzata in quell’istante. Per
farlo è sufficiente individuare le slide associate ai cuepoint minori del tempo di riproduzione del video e scegliere quello più vicino all’istante di riproduzione selezionato. In pratica,
data la lista ordinata dei cuepoint, basta scorrerla dalla fine fino a raggiungere il primo
valore minore del tempo attuale del video.
L’evento onCuepoint è richiamato dal player quando la riproduzione incontra un cuepoint8 nel video. Poiché la riproduzione può andare solo in avanti, quando si raggiunge un
cuepoint vuol dire che si deve visualizzare la slide successiva a quella corrente. L’utente
può effettuare il seeking del video e tornare indietro, ma in tal caso il player genera prima
un evento onSeek visualizzando la slide corretta e poi, al primo cuepoint incontrato, quella
subito successiva, mantenendo in questo modo la sincronizzazione.
La prima versione dell’applicativo è stata sviluppata in tempi brevi e con funzionalità limitate, ma è stata una buona base di partenza per le successive evoluzioni. Un’immagine
dell’applicazione in esecuzione è visibile in figura 3.3.
Il software ha subito poi diversi aggiornamenti. Il primo passo ha visto la completa
riscrittura dello script di gestione dello slideshow. Si è cioè eliminato Galleria per sostituirlo con un prodotto sviluppato ad-hoc, in modo da avere maggior controllo sull’esecuzione
dell’applicazione nel suo complesso. L’operazione si è resa possibile grazie allo studio in
dettaglio di Galleria, che ha permesso da un lato di apprendere in maniera approfondita
jQuery e dall’altro di individuare sia i punti forti del programma (da replicare), sia quelli
deboli (da evitare). Va precisato che gli aspetti negativi dello script non sono dovuti a
cattiva programmazione, ma al fatto che gli obiettivi di Galleria non coincidono completamente con quelli del prodotto che si sta sviluppando.
Il nuovo script per la gestione della presentazione è stato chiamato semplicemente Slideshow, e offre gli stessi metodi offerti in precedenza da Galleria, seppur con implementazioni
diverse e più efficienti.
Il limite più grande di questa versione del prodotto è il fatto che si è scelto di inserire
i percorsi dei media e i tempi di sincronizzazione direttamente nel documento HTML.
Tale soluzione è stata adottata per semplificare le fasi iniziali del lavoro, permettendo di
8
Il cuepoint può essere interno al media (vedi paragrafo 2.3.4) oppure esterno, specificato nella costruzione del player. Per semplicità si è scelta questa seconda soluzione, considerata più flessibile, poiché
per modificare i cuepoint interni al media occorre utilizzare strumenti esterni come FLVtool2.
42
Figura 3.3: prima versione dell’applicazione per la sincronizzazione di video e slide
concentrarsi su altre funzionalità, ma è un limite che dev’essere necessariamente superato
per poter rispettare il pattern MVC. L’introduzione di questa funzionalità complica solo in
parte l’applicazione; in effetti la logica di programma resta esattamente la stessa, occorre
solo individuare i dati per l’inizializzazione delle componenti in un file esterno.
Di quest’operazione si occupa un nuovo script, Init, che è richiamato per primo e si occupa
della creazione degli altri componenti. Per prima cosa Init scarica il documento dal server;
poichè si tratta di un documento SMIL, per quanto detto nel paragrafo 3.1.2, l’operazione
può essere effettuata tramite AJAX. In seguito lo script utilizza le API DOM per accedere
alle informazioni sui media e sui punti di sincronizzazione (cuepoint). Con queste informazioni, possono essere inizializzati player e slideshow per funzionare esattamente come
nella versione precedente.
Occorre evidenziare che l’applicazione si aspetta un preciso formato per il file con le informazioni sui media, ovvero si aspetta di trovare esattamente un video in parallelo con una
sequenza di immagini. Questo implica che qualsiasi formato non riconosciuto genererà un
errore e impedirà l’avvio della presentazione, pur se si tratta di un documento SMIL ben
formato, valido e corretto.
Il formato accettato dalla versione finale dell’applicazione è il seguente:
<?xml v e r s i o n = " 1 . 0 " e n c o d i n g =" i s o −8859−1"?>
<!DOCTYPE s m i l PUBLIC "−//W3C//DTD SMIL 2 . 0 / /EN" " h t t p : / /www. w3 . o r g /2001/ SMIL20/WD/
SMIL20 . dtd">
<s m i l xmlns=" h t t p : / /www. w3 . o r g /2001/ SMIL20/ Language">
<head>
<meta name=" t i t l e " c o n t e n t =" T i t l e "/>
<meta name=" a u t h o r " c o n t e n t ="QB S o f t "/>
<meta name=" a b s t r a c t " c o n t e n t =" J u s t an example "/>
</head>
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
43
<body>
<par>
<v i d e o s r c ="rtmpt : / / 1 9 5 . 1 0 3 . 9 7 . 9 9 : 8 0 / t e s t i n g / sample . f l v "/>
<seq>
<img s r c =" s l i d e / 0 0 . j p g " t i t l e =" f i r s t s l i d e " b e g i n ="0 s "/>
<img s r c =" s l i d e / 0 1 . j p g " t i t l e =" s e c o n d s l i d e " b e g i n ="15 s "/>
<img s r c =" s l i d e / 0 2 . j p g " t i t l e =" t h i r d s l i d e " b e g i n ="37 s "/>
</seq>
</par>
</body>
</s m i l >
In realtà c’è un minimo di flessibilità nel parsing del documento: per esempio se sono
presenti tag inaspettati sono automaticamente ignorati e non generano errori; oppure se i
tag che devono essere presenti non sono nel giusto ordine (per esempio è presente prima
la sequenza di immagini e poi il video), la lettura avviene correttamente. Il formato che ci
si aspetta quindi è indicativo ed è un formato minimo; eventuali elementi di troppo sono
semplicemente scartati.
Con la lettura delle informazioni sui media dal documento SMIL, il prodotto si può
considerare funzionalmente completo. Si è perciò proceduto ad una fase di testing per l’individuazione dei bug e ad un miglioramento estetico. Per quest’ultimo punto si è creato un
tema attraverso l’uso di fogli stile e le opzioni di personalizzazione grafica di Flowplayer.
L’interfaccia dell’applicazione è stata rivista per sfruttare al meglio gli spazi disponibili, in
particolare grazie all’adozione di un layout fluido, che permette di ridimensionare dinamicamente lo spazio dedicato allo slideshow. L’applicazione nella sua veste finale è visibile
in figura 3.4.
Figura 3.4: versione finale dell’applicazione per la sincronizzazione di video e slide
44
Per completare la descrizione dell’applicazione, saranno nel seguito esposti l’albero
delle directory e il diagramma delle componenti software (figura 3.5).
La directory dell’applicazione che dev’essere caricata sul server web, ha la seguente struttura:
- index.html (pagina principale della presentazione. deve includere tutti gli script)
- nome.xml (documento SMIL con le informazioni sui media e sulla temporizzazione. Il nome può essere
specificato in index.html, mentre l’estensione deve essere .xml)
- include (directory)
– scripts (directory)
∗ flowplayer.js (script per la gestione di Flowplayer)
∗ init.js (script per l’inizializzazione delle componenti della presentazione)
∗ jquery.js (libreria jQuery)
∗ slideshow.js (script per la gestione dello slideshow)
– styles (directory)
∗ main.css (fogli stile usati nella presentazione)
∗ . . . (altri elementi grafici della pagina possono essere inseriti qui)
– swf (directory)
∗ flowplayer.swf (applicazione Flowplayer)
∗ flowplayer.controls.swf (plugin di Flowplayer per la gestione dei controlli PLAY, PAUSE, STOP,
ecc)
∗ flowplayer.rtmp.swf (plugin di Flowplayer per la gestione dei flussi RTMP)
Figura 3.5: diagramma delle componenti software dell’applicazione
In conclusione si è riusciti nell’intento di creare l’applicazione desiderata, rispettando i
vincoli imposti. Lo script, infatti, è in grado di eseguire correttamente (ed è stato testato)
su Internet Explorer 6+, Mozilla Firefox 2+, Apple Safari 3+, Opera 9+ e Google Chrome
2+, non richiede l’utilizzo di script server side e non richiede nemmeno l’installazione di
plugin aggiuntivi da parte dell’utente.
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
45
3.2.2
Sviluppo di un player SMIL per il web
Nel campo molto specifico della sincronizzazione tra video e slide, l’applicazione descritta nel paragrafo precedente è abbastanza soddisfacente; sfortunatamente però, nel caso
si desideri modificare anche solo in piccola parte l’andamento della presentazione, per
esempio aggiungendo un secondo set di immagini da visualizzare in maniera sincronizzata,
l’applicazione si rivela inadatta e richiede uno sforzo notevole e una modifica consistente
della logica di programma. Seguire quest’approccio, oltre che comportare grosse difficoltà,
sarebbe concettualmente un errore, perché si estenderebbe solo in piccola parte l’input
accettato, e quindi si creerebbero le condizioni per il ripetersi del problema.
Se si vuole estendere in maniera consistente e corretta le funzionalità dell’applicazione, in
modo da far sì che questa possa accettare e riprodurre correttamente molti più modelli
di input, occorre iniziare da zero un nuovo progetto. Nelle ultime due settimane di stage,
perciò, ci si è posti l’obiettivo di realizzare un vero e proprio player SMIL, in grado di
riprodurre una discreta quantità di presentazioni e che sia facilmente estendibile. I vincoli
imposti sono gli stessi del primo applicativo creato, e cioè garantire il funzionamento sulla
maggior parte dei browser e non obbligare l’utente a installare plugin di alcun tipo, escluso
il Flash player.
Si precisa che attualmente un’applicazione di questo tipo non esiste; per riprodurre contenuti SMIL in un browser occorre utilizzare qualche plugin apposito (per esempio Ambulant), oppure includere il documento nella pagina HTML secondo il profilo XHTML+SMIL.
Il progetto non mira però a creare un player completo, in grado di interpretare tutte le
presentazioni SMIL, ma solo un profilo ridotto (descritto in seguito).
Si è detto che l’approccio al problema dev’essere radicalmente diverso da quello usato
per lo sviluppo della prima applicazione ed i motivi sono molteplici:
• I media non occupano necessariamente due regioni e, soprattutto, le regioni non
dovrebbero essere stabilite a priori in fatto di posizione e dimensioni. Si deve permettere all’utente di definire le proprie regioni in maniera arbitraria e si deve essere
in grado di associare ogni media alla giusta regione.
• Non dovrebbero esser previsti modi per annidare i tag di temporizzazione in numero
limitato; ovvero dovrebbe essere possibile comporre i vari seq e par a discrezione
dell’utente.
• Non è sicuro che sia presente un media continuo nella presentazione, nè che sia
presente dall’inizio e per tutta la durata della stessa, di conseguenza il tempo non
dovrebbe essere gestito con le funzionalità di Flowplayer com’è stato fatto in precedenza.
Queste sostanziali differenze aiutano anche a capire quale dev’essere il modo di procedere.
La prima funzionalità da supportare è la creazione di regioni. Una regione in SMIL si specifica con il tag region contenuto nel la sezione head. Nel paragrafo 3.1.2 si è mostrata
la corrispondenza che c’è tra gli attributi di region e le proprietà omonime dei fogli stile
CSS; questa corrispondenza suggerisce di far corrispondere ad ogni regione definita nel
documento SMIL un contenitore (per esempio un div) XHTML, posizionato in maniera
46
assoluta. A questo punto basta usare gli stessi valori usati per gli attributi delle regioni nelle proprietà CSS del blocco XHTML, aggiungendo il suffisso px se opportuno (che
in SMIL può essere omesso). Gli attributi che vengono copiati sono left, top, width,
height e z-index; per semplicità si è scelto di non implementare il supporto a right e
bottom, perché top e left sono generalmente più usati ed è facile, con i dovuti calcoli,
passare da un sistema di posizionamento all’altro; l’eventuale supporto a questi attributi
può comunque essere facilmente introdotto estendendo l’applicazione.
Un altro punto importante è poter identificare univocamente la regione, per potervi associare i media. Per fare questo si è scelto di copiare il valore dell’attributo regionName
del file SMIL nell’attributo id del blocco div XHTML. Poiché gli attributi fin qui elencati
sono fondamentali per creare correttamente il layout della pagina, occorre che essi siano
presenti nel documento SMIL; se non lo sono è visualizzato un errore.
Il secondo punto dell’elenco delle funzionalità da supportare, richiede che non via siano limiti nel modo di annidare i tag di temporizzazione nella sezione body del documento
SMIL. Può sembrare un punto eccessivamente complicato da garantire, ma in realtà non
è così. Per spiegare come si risolve il problema occorre una piccola premessa.
Non si deve effettuare il parsing del documento durante la presentazione; bisogna sapere sin dall’inizio quando un media deve essere riprodotto. Ciò è dovuto al fatto che un
parsing durante la presentazione sarebbe molto inefficiente, perchè ripercorrerebbe necessariamente molti elementi più e più volte, quando in realtà è possibile stabilire sin
dall’inizio l’ordine di esecuzione di tutti i media della presentazione, percorrendo l’albero
una sola volta. Scegliendo il secondo metodo si riduce considerevolmente la complessità
del problema e si può effettuare un parsing molto più efficiente e veloce; l’unico aspetto
negativo è che richiede di memorizzare più informazioni, ma comunque non in numero
eccessivo.
Per costruire l’ordine di esecuzione dei media nella presentazione è sufficiente conoscere
solo, per ogni media esaminato:
• Il valore dell’attributo begin del media che si sta esaminando
• La durata del media, che può essere indicata nell’attributo dur oppure essere intrinseca, se si tratta di un media continuo; in questo caso possono sorgere dei problemi
che saranno discussi in seguito
• L’istante (assoluto) in cui è terminato il media precedente se ci troviamo all’interno
di un seq; tale valore è dev’essere aggiunto al valore di inizio del media in esame.
• L’istante (assoluto) di inizio dell’elemento padre se siamo all’interno di par o se
siamo i primi figli di body o seq; tale valore è dev’essere aggiunto al valore di inizio
del media in esame.
Tutte queste informazioni sono facilmente ottenibili se ad ogni nodo in esame si provvede
ad aggiornare tali informazioni usando quelle dei nodi precedenti; per esempio il tempo
di fine di un media, non è altro che il tempo di inizio più la sua durata. Supponiamo
di trovarci all’interno di un seq: se ora sommiamo il valore di inizio relativo del media
successivo al valore di fine di quello attuale, otteniamo un valore assoluto di inizio.
Non è difficile quindi capire che utilizzando una funzione ricorsiva per esaminare il documento SMIL, avendo cura di aggiornare correttamente i parametri ad ogni nodo, si può
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
47
facilmente costruire uno schema in cui per ogni media si possono conoscere il suo tempo
di inizio e di fine assoluti. Quest’approccio è stato adottato nella creazione del player ed
ha portato alla stesura della funzione parseMediaRec all’interno del file smil_player.js.
Il terzo e ultimo punto dell’elenco delle modifiche da effettuare indica che non possiamo utilizzare le funzionalità di Flowplayer per la gestione del tempo nel browser. Occorre
quindi trovare un altro modo, il più possibile preciso, per gestire lo scorrimento del tempo. Per fare questo si può implementare un semplice cronometro (in inglese stopwatch) in
JavaScript. L’implementazione più banale consiste nell’affidare il conteggio del tempo ad
una funzione che contiene solo un ciclo infinito in cui ad ogni iterazione ferma l’esecuzione
per un certo intervallo di tempo; in Java si potrebbe ottenere un risultato simile tramite
il metodo sleep() della classe Thread. In JavaScript non esistono thread, però si può
comunque ottenere un comportamento simile con la funzione setTimeout(). Il risultato
di quest’implmentazione del cronometro però non è accettabile, perchè introduce un errore
cumulativo molto grande; nessuna funzione di sospensione relativa, nemmeno in linguaggi orientati al real time come ADA, garantisce di fermare l’esecuzione esattamente per
l’intervallo di tempo richiesto. Generalmente questo genere di funzioni garantiscono una
sospensione per un tempo pari almeno a quello richiesto; ovvero se si sceglie di fermare
l’esecuzione per un secondo, accadrà quasi sempre che la reale sospensione sia di poco
maggiore ad un secondo e mai comunque minore. Come detto, questa soluzione introduce
un notevole errore cumulativo, cioè dovuto alle esecuzioni precedenti; utilizzare intervalli
di tempo più piccoli non risolve il problema ma lo sposta solo più avanti nel tempo.
È necessario quindi utilizzare dei riferimenti assoluti. Si può per esempio memorizzare il
tempo di inizio della riproduzione e controllare a intervalli regolari (la cui durata dev’essere
stabilita in base alla precisione che si vuole ottenere) quanto tempo è trascorso dall’inizio
fino a questo istante. Con questa soluzione non si è al riparo totale dagli errori, però non
vi è ritardo cumulativo, perciò a lungo termine si ottengono risultati decisamente migliori.
Per la realizzazione di questo script ci si è ispirati ad un lavoro pubblicato online [39].
Avendo a disposizione un cronometro, è sufficiente controllare in maniera regolare se vi
sono media da avviare o da fermare per poter riprodurre la presentazione. Si noti che il
cronometro dev’essere in grado di gestire la messa in pausa della presentazione.
Si sono fino a qui descritti i punti più delicati, che sono però solo una piccola parte dell’applicazione nel suo complesso. Segue ora una descrizione più dettagliata delle
componenti software utilizzate, interne ed esterne.
48
Figura 3.6: diagramma delle componenti software dell’applicazione
La pagina HTML è la pagina principale della presentazione; deve includere tutti gli
script necessari e avviare il player SMIL. Un esempio di pagina minimale e funzionante è
il seguente.
<html>
<head>
< t i t l e >Loading . . . < / t i t l e >
<l i n k h r e f =" i n c l u d e / s t y l e s / s m i l _ p l a y e r . c s s " r e l =" s t y l e s h e e t " t y p e =" t e x t / c s s " media
=" s c r e e n "/>
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " s r c =" i n c l u d e / s c r i p t s / j q u e r y . j s "></ s c r i p t >
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " s r c =" i n c l u d e / s c r i p t s / f l o w p l a y e r . j s "></ s c r i p t >
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " s r c =" i n c l u d e / s c r i p t s / jqModal . j s "></ s c r i p t >
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " s r c =" i n c l u d e / s c r i p t s / s m i l _ p l a y e r . j s "></ s c r i p t >
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " s r c =" i n c l u d e / s c r i p t s / s t o p w a t c h . j s "></ s c r i p t >
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " s r c =" i n c l u d e / s c r i p t s / media . c l a s s . j s "></ s c r i p t >
< s c r i p t t y p e =" t e x t / j a v a s c r i p t " s r c =" i n c l u d e / s c r i p t s / r e g i o n . c l a s s . j s "></ s c r i p t >
< s c r i p t t y p e =" t e x t / j a v a s c r i p t ">
<!−−
$ ( document ) . r e a d y ( f u n c t i o n ( ) {
// I n i z i a l i z z a l a p a g i n a l e g g e n d o i d a t i d a l f i l e SMIL p a s s a t o
s m i l _ p l a y e r ( " v i d e o . xml " , "# c o n t a i n e r " ) ;
}) ;
//−−>
</ s c r i p t >
</head>
<body>
<!−− C o n t e n i t o r e d e l l a p r e s e n t a z i o n e −−>
<d i v i d =" c o n t a i n e r "></div>
</body>
</html>
Si noti che non occorre specificare il titolo della pagina, perché sarà automaticamente
usato quello individuato nel documento SMIL. Occorre invece creare un contenitore per
la presentazione, provvisto dell’attributo id. Il selettore CSS di tale contenitore (cioè il
simbolo ’#’ più l’id) dev’essere passato insieme con il nome del documento SMIL alla
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
49
funzione di inizializzazione del player. Si è scelta questa soluzione per permettere di
includere il player SMIL in pagine esistenti; è sufficiente infatti aggiungere l’elemento
contenitore nel posto scelto della pagina per inserire la presentazione SMIL in quel preciso
punto; non si è perciò obbligati ad usare la presentazione a schermo intero su una pagina
apposita e separata.
I fogli stile permettono di personalizzare le regioni e qualche altro aspetto della presentazione, per esempio la visualizzazione del cronometro o gli stili da applicare alle finestre
di dialogo. In quest’applicazione i fogli stile rivestono un ruolo molto marginale, ma sono
stati comunque tenuti in considerazione per permettere la modifica dell’aspetto grafico di
alcune componenti. Si noti che è comunque possibile modificare liberamente lo stile dei
componenti esterni al player SMIL.
flowplayer.js e jquery.js sono rispettivamente gli script per la gestione di Flowplayer e le API di jQuery. Non sono stati modificati, per cui possono essere facilmente
sostituiti da versioni più aggiornate in caso di necessità.
jqModal.js [40] è un plugin open source per jQuery che permette di creare con pochi
comandi delle finestre modali 9 . Non si tratta di popup classici, che possono facilmente
essere bloccati dal browser, ma di elementi della pagina HTML che vengono visualizzati
solo quando necessario. Le finestre modali sono usate per notificare all’utente un errore
grave o una fase di caricamento e per impedire all’utente di interagire con i media (per
esempio mettendoli in pausa) durante il caricamento di altri media.
Figura 3.7: jqModal in esecuzione
Stopwatch è uno script che offre le basilari funzionalità di un cronometro. I metodi
che offre lo script sono:
• sw_start(), avvia il conteggio
• sw_stop(), mette in pausa il conteggio, senza azzerare il valore
9
una finestra di un’applicazione è detta modale se quando essa è visibile impedisce l’interazione
dell’utente con le altre finestre di programma. Generalmente sono modali le finestre che attendono un
input da parte dell’utente o le finestre che segnalano errori gravi.
50
• sw_reset(), azzera il conteggio
• sw_getTime(), ritorna il tempo attuale, in millisecondi
• sw_isRunning(), ritorna TRUE se il cronometro è in esecuzione, FALSE altrimenti
Quando non è più necessario aggiornare il cronometro, perché non ci sono più media che
devono essere terminati, il conteggio è automaticamente bloccato.
La classe Media è un oggetto JavaScript che memorizza alcune informazioni su un
singolo media e offre il metodo per disegnarlo nella pagina HTML. In particolare, Media
contiene:
• L’attributo type che indica il tipo di media (img, video, audio).
• L’attributo content che contiene l’URL del media.
• L’attributo additional che contiene informazioni aggiuntive, come un’eventuale
descrizione.
• Gli attributi begin ed end che indicano il tempo assoluto di inizio e di fine del
media. Il tempo di fine può essere 0, e in tal caso si considera la durata intrinseca
del media; ovvero un media continuo finisce al termine della sua riproduzione, mentre
un’immagine termina subito
• Il metodo draw() che disegna il media nella pagina, ovvero nel caso di un’immagine
la inserisce nella regione con il tag HTML img, mentre nel caso di video o audio il
metodo inizializza opportunamente Flowplayer.
La classe Region è un oggetto JavaScript che memorizza alcune informazioni relative
al posizionamento nella pagina e fornisce alcuni metodi per l’aggiornamento della regione.
In particolare, Region contiene:
• L’attributo name che indica il nome della regione.
• Il campo media[] che è la collezione di Media che devono essere riprodotti in una
certa regione, ordinati per tempo di inizio crescente.
• Gli attributi top, left, width e height e z-index che contengono le informazioni
sul posizionamento della regione nella pagina.
• Il metodo addMedia che permette di aggiungere il Media alla collezione dei media
da visualizzare nella regione
• Il metodo init che disegna la regione nella pagina, ovvero aggiunge il nodo div
corrispondente alla regione come figlio dell’elemento contenitore della presentazione
• Il metodo update che controlla se occorre riprodurre un Media della collezione (basta
guardare il primo, perché sono in ordine crescente per tempo d’inizio). Il metodo
verifica anche se il media attualmente in riproduzione dev’essere fermato perché ha
raggiunto il suo tempo di fine. Per poter valutare se la presentazione è terminata,
il metodo update() ritorna TRUE se sono ancora presenti dei video da visualizzare
nella regione, altrimenti ritorna FALSE.
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
51
• Il metodo updateTiming che è stato aggiunto per la risoluzione di un bug di cui si
discuterà in seguito
Il file smil_player.js contiene le funzioni per l’inizializzazione e la riproduzione della
presentazione. Sono presenti diverse funzioni di utilità, ma quelle più importanti sono:
• Il costruttore smil_player(_doc, _container) che riceve come parametri il nome
del documento SMIL e l’elemento contenitore della presentazione. La funzione si
occupa di scaricare tramite AJAX il documento XML e poi richiama le funzioni per
inizializzare ed avviare la presentazione.
• La funzione parseSMIL effettua il parsing del documento XML, dividendo il lavoro tra le funzioni parseHead, che si occupa dell’inizializzazione delle regioni, e
parseMediaRec, che si occupa di inizializzare i media e di aggiungerli alle regioni di
appartenenza.
• La funzione clock() che è la funzione richiamata a intervalli regolari e che controlla
l’intera riproduzione, ovvero richiama il metodo update() di ogni Region.
Per comprendere meglio come si comporta il player SMIL, si descriverà ora il flusso
dell’esecuzione a parole e graficamente con l’utilizzo di un diagramma UML delle attività
(figura 3.8).
Le prime operazioni eseguite dall’applicazione sono la visualizzazione della finestra modale
di caricamento e il download del documento SMIL con una chiamata AJAX. Se il documento non esiste è visualizzata una finestra di errore e l’applicazione termina; se invece
il documento esiste si può procedere al parsing. Se il documento non è valido il parsing
fallisce; viene perciò mostrato un errore e l’applicazione termina. Se non ci sono errori, la
funzione di parsing si occuperà di memorizzare le informazioni sulle regioni e sui media
e al termine avvierà il cronometro e la presentazione. Quest’operazione può essere effettuata richiamando la funzione clock(). A questo punto si può nascondere la finestra di
caricamento.
La prima operazione effettuata dalla funzione clock() è impostare un timer per fare in
modo che sia richiamata nuovamente dopo un certo intervallo di tempo. Quest’operazione viene effettuata solo se la presentazione non è ancora terminata; una presentazione si
considera terminata se non ci sono più media da attivare in seguito e se i media attivi in
quell’istante hanno un campo end uguale a 0, cioè si attende la loro terminazione naturale. Si noti che ci sono ancora dei media attivi, quindi per l’utente la presentazione non
è finita; il player però non ha più operazioni da effettuare, perciò la considera terminata.
Per verificare se sono presenti ancora media da gestire si può usare il valore di ritorno del
metodo update() della classe Region.
A questo punto la funzione clock() può richiamare il metodo update() su tutte le regioni;
questo metodo valuterà caso per caso se ci saranno media da attivare, media da fermare,
oppure nessuna operazione da effettuare.
52
Figura 3.8: diagramma delle attività del player SMIL
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
53
La directory che dev’essere caricata sul server web ha la seguente struttura:
- pagina HTML
- documento XML (l’estensione deve essere .xml)
- include (directory)
– scripts (directory)
∗ flowplayer.js
∗ jqmodal.js
∗ jquery.js
∗ media.class.js
∗ region.class.js
∗ smil_player.js
∗ stopwatch.js
– styles (directory)
∗ smil_player.css
∗ . . . (altri elementi grafici della pagina possono essere inseriti qui)
– swf (directory)
∗ flowplayer.swf
∗ flowplayer.rtmp.swf
È possibile modificare la struttura delle directory, ma occorre aggiornare anche la
pagina HTML di conseguenza.
Per l’installazione del player è sufficiente copiare le directory e i file elencati, definire una
presentazione SMIL in un documento XML e indicare il nome del documento nella pagina
HTML.
È stata preparata anche una versione minified del player SMIL, che risulta più semplice
da installare e di dimensione minore. La struttura delle directory rimane la stessa, ma tutti
i file contenuti nella cartella scripts sono sostituiti dall’unico file smil_player.min.js.
La pagina HTML va aggiornata per includere solo questo file. Il peso della versione Minified è di 83K, mentre quello della versione non compressa del player è di 170K; in pratica
la versione compressa permette di dimezzare i tempi di download dello script.
In conclusione, si vogliono elencare limiti e pregi del prodotto sviluppato.
La caratteristica più importante da valutare è il numero e il tipo di documenti che il player è
in grado di interpretare correttamente. Con qualche leggera discrepanza dallo standard, si
può dire che l’applicazione aderisce quasi interamente al profilo Tiny di SMIL 3.0, in quanto
sono supportati tutti i tag del profilo, ad esclusione di animation, ref, text e textstream
e la maggior parte degli attributi. Si noti che questi tipi di media possono essere aggiunti
modificando solo la classe Media e andando a ridefinire in particolare il metodo draw().
Grazie alla flessibilità dell’applicazione è possibile estenderne le funzionalità in maniera
semplice.
Per definire in maniera più precisa la classe di documenti che il player è in grado di interpretare correttamente, si è scelto di utilizzare una grammatica regolare; i simboli in maiuscolo sono non terminali, quelli in minuscolo sono invece terminali. I valori tra parentesi
quadre indicano attributi opzionali mentre con il singolo ’.’ si indica la concatenazione.
54
SMIL_ROOT −> <s m i l >.HEAD.BODY. </ s m i l >
HEAD −> <head >.META_GROUP.LAYOUT. </ head>
META_GROUP −> <meta name = " . . " c o n t e n t = " . . " / >.META_GROUP
LAYOUT −> <l a y o u t >.REGION_GROUP. </ l a y o u t >
REGION_GROUP −> <r e g i o n regionName = " . . " l e f t = " . . " top = " . . " width = " . . " h e i g h t = " . . " [
z−i n d e x = " . . " ] / >.REGION_GROUP
BODY −> <body >.MISC_CONTENT_GROUP. </body>
MISC_CONTENT_GROUP −> MISC_CONTENT.MISC_CONTENT_GROUP
MISC_CONTENT −> <s e q [ r e g i o n = " . . " ] [ b e g i n = " . . " ] [ end = " . . " ] [ dur = " . . " ] > .
MISC_CONTENT_GROUP. </ seq> |
−> <par [ b e g i n = " . . " ] [ end = " . . " ] [ dur = " . . " ] [ s y n c B e h a v i o r ="{ l o c k e d |
i n d e p e n d e n t } ] " > . MISC_CONTENT_GROUP. </ par> |
−> <v i d e o s r c = " . . " [ r e g i o n = " . . " ] [ b e g i n = " . . " ] [ end = " . . " ] [ dur = " . . " ] /> |
−> <a u d i o s r c = " . . " [ r e g i o n = " . . " ] [ b e g i n = " . . " ] [ end = " . . " ] [ dur = " . . " ] /> |
−> <img s r c = " . . " [ r e g i o n = " . . " ] [ b e g i n = " . . " ] [ end = " . . " ] [ dur = " . . " ] [ t i t l e
= " . . " ] />
Oltre alle funzionalità di sincronizzazione di base di SMIL, si è anche scelto di implementare la hard synchronization. Normalmente, quando si inseriscono due media in un par,
SMIL garantisce che i due partano assieme, non che procedano di pari passo. Supponiamo
di voler realizzare una presentazione in cui ci siano un video e alcune slide sincronizzate,
proprio come nel primo applicativo sviluppato. Se si mettono video e sequenza di immagini all’interno di un par senza ulteriori indicazioni, quando si andrà a riprodurre la
presentazione si potrà mettere in pausa il video, perdendo i vincoli temporali tra i due
media. In questo caso la sincronizzazione tra i media è soft; è possibile però ottenere
una sincronizzazione di tipo hard attraverso l’uso dell’attributo syncBehavior. In questo
modo si possono effettivamente avere i due media che procedono insieme, aspettandosi
l’un l’altro. Per ottenere questo risultato nell’applicazione, si è aggiunto un flag che è
impostato durante la fase di parsing, a seconda della presenza e del valore dell’attributo
syncBehavior. Nell’esempio precedente, se il flag è attivo, quando si mette in pausa il
video si mette in pausa l’intera presentazione, cronometro compreso. In questo modo non
si perde la sincronizzazione.
Nonostante il player interpreti correttamente un gran numero di documenti SMIL, non
è detto che sia in grado di riprodurli. I player desktop, come Ambulant o Real Player, cominciano ad avere difficoltà quando si tratta di riprodurre più media contemporaneamente,
in particolare se sono presenti effetti o animazioni. In un browser le risorse disponibili sono ancor più limitate, poichè questo software è fortemente orientato alla visualizzazione
di documenti e non certo a presentazioni multimediali. Queste limitazioni sono evidenti
quando si cominciano ad inserire più media continui nello stesso istante nella presentazione; spesso ne viene perso qualcuno. Occorre tenerne conto, quando si creano i documenti
SMIL, altrimenti si rischia di ottenere una presentazione troppo pesante da eseguire sul
browser.
Si deve inoltre evidenziare il fatto che si sta utilizzando la rete per la trasmissione dei
media continui. Questo comporta naturalmente dei ritardi dovuti alla trasmissione, ma
soprattutto implica che al momento del parsing del documento SMIL non si conoscono
alcune informazioni importanti sui media; in particolare non si conosce la durata di quelli
continui. Se non è specificato un valore esplicito di durata del media nel documento,
non è possibile costruire in maniera corretta la linea temporale della presentazione. È
tuttavia possibile limitare almeno in parte il problema, quando la durata del media serve
CAPITOLO 3. SINCRONIZZAZIONE DI CONTENUTI MULTIMEDIALI
55
per calcolare il tempo di inizio di un secondo media nella stessa regione. Per esempio, si
supponga di avere il frammento
<seq>
<v i d e o s r c = " . . " r e g i o n ="A" />
<img s r c = " . . " r e g i o n ="A" />
</seq>
nel documento SMIL. Se non è possibile conoscere la durata del video, per esempio perché
questo non è nel file system locale, quando la riproduzione raggiungerà questo frammento, il video sarà inserito nella regione A e poi sostituito immediatamente dall’immagine.
Occorre notare però, che sebbene le informazioni sul video non siano note nella fase di
parsing, lo sono invece quando la riproduzione raggiunge il punto in cui sono definiti. In
quel momento il client effettua la richiesta del media al server di streaming, e quest’ultimo comincia a trasmettere. Le prime informazioni che sono trasmesse sono i metadata,
che contengono tra l’altro, proprio l’informazione sulla durata del video. A questo punto,
ancora prima di iniziare la riproduzione del video, ne conosciamo la durata e possiamo
quindi aggiornare il tempo di inizio dell’immagine in base a questa. Con questa soluzione
possiamo risolvere il problema nel caso i media appartengano alla stessa regione, ma non
se appartengono a regioni diverse. Quando si passa dal documento SMIL alla linea temporale della presentazione, si perde ogni relazione temporale tra i media e si rimane con soli
riferimenti assoluti. Di conseguenza non è possibile sapere se un media è relazionato con
un altro dopo la fase di parsing. Si potrebbe comunque risolvere il problema in maniera
completa effettuando il download dei soli metadata dei video della presentazione durante
la fase di parsing; in questo caso, al costo di una fase di preparazione più lunga si può
conoscere fin dall’inizio la durata dei media.
Nonostante le limitazioni sin qui descritte, si può comunque ritenere il prodotto valido, innanzitutto perché copre un ambito di grande interesse, ma che ancora non mostra
evidenti sviluppi ed in secondo luogo perché, nonostante il breve tempo a disposizione,
si è riusciti a soddisfare comunque gli obiettivi che si erano posti. Anche i vincoli sono
rispettati; l’applicazione funziona correttamente ed è stata testata su Internet Explorer
6+, Mozilla Firefox 2+, Apple Safari 3+, Opera 9+ e Google Chrome 2+, inoltre non
sono richiesti ulteriori plugin per il suo funzionamento.
56
Capitolo 4
Conclusioni
Si può ritenere che lo stage si sia concluso con un discretto successo. La progettazione
della piattaforma di streaming è stata realizzata studiando in maniera approfondita tutte
le singole problematiche incontrate, senza tralasciare alcun dettaglio. Nonostante ciò si è
comunque riusciti a raggiungere tutti gli scopi prefissati ed anche ad aggiungere qualche
attività inizialmente non prevista nel piano.
Partendo da conoscenze in materia di streaming decisamente limitate, si è passati allo
studio dei principali protocolli e dei formati dei file più adatti e diffusi nel settore, per
arrivare poi a scegliere, installare e configurare alcune tra le principali soluzioni oggi in
commercio in ambito di server di streaming. A questo punto si sono potuti effettuare i
necessari test per verificare le prestazioni delle varie soluzioni e arrivare in conclusione alla
scelta finale sul server di streaming da usare. L’esigenza di aggiornare l’offerta di contenuti
multimediali di un portale aziendale ha imposto inoltre un attenzione particolare ad alcune
tematiche di accessibilità dei contenuti che non sempre sono prese in considerazione quando
si realizzano pagine web.
Per completare il quadro si è poi passati ad una fase più applicativa, che ha avuto come
obiettivo quello di realizzare due applicazioni che facessero uso del server di streaming
predisposto precedentemente. Si è quindi passati all’analisi, alla progettazione ed infine
allo sviluppo dell’applicazione per la sincronizzazione tra video e slide. Una prima versione
minimale è stata in più occasioni riadattata per aggiungere nuove funzionalità e per darle
un aspetto grafico gradevole; al termine si è giunti ad un prodotto un po’ limitato nelle
funzionalità, ma molto efficiente e di semplice installazione in pagine web esistenti.
A quel punto si è individuata subito la strada per un secondo prodotto ancor più flessibile
ed innovativo, cioè il player web per il linguaggio SMIL. Questo secondo applicativo è di
interesse non solo per l’azienda, che con esso può ulteriormente ampliare la propria offerta
di contenuti multimediali, ma anche per altri individui, in quanto non esistono attualmente
soluzioni simili per riprodurre contenuti SMIL su browser senza l’utilizzo di plugin o di
profili appositi.
Per il tesista lo stage è stato un momento di grande accrescimento personale grazie
all’ampia varietà di problematiche affrontate, che hanno richiesto un accurato studio per
essere risolte; da questo punto di vista si può ritenere lo stage svolto presso l’azienda
QBgroup un’ottima esperienza lavorativa e di vita.
57
58
Ringraziamenti
La prima persona che voglio ringraziare è la mia relatrice, la dott.ssa Ombretta Gaggi. Le
sono molto debitore per la disponibilità dimostrata, ma soprattutto per l’enorme pazienza
che ha saputo offrirmi anche nei momenti difficili. La ringrazio per essere stata sempre
attenta e precisa e per avermi dato spesso motivazioni per migliorare.
In secondo luogo voglio ringraziare l’azienda QBgroup per avermi dato la possibilità di
svolgere quest’esperienza importante. Un grazie di cuore va a Marco Regazzo, amico prima che collega, così come agli altri ragazzi di QUBIsoft: Roberto, Davide, Paolo, Stefano,
Efran, Giovanni e Alessandro “Rudy” che hanno reso splendida la permanenza in azienda.
Un doveroso ringraziamento va naturalmente a Giorgia, senza la quale non sarei la
persona che sono ora.
Desidero ringraziare anche la mia famiglia, mio fratello, Francesca e Gaia per il sostegno e la fiducia che hanno saputo darmi in tutti questi anni.
Ed infine non posso non ringraziare tutti gli amici, vecchi e nuovi, vicini e lontani, che
mi hanno sempre dato tantissimo e che spero di essere riuscito a contraccambiare.
Non vi cito singolarmente perché spenderei più soldi per stampar la tesi.
59
60
Bibliografia
[1] QBGROUP spa
http://www.qbgroup.it
[2] eDott
http://www.edott.it
[3] RFC 2326, Real Time Streaming Protocol (RTSP), 1998
http://tools.ietf.org/html/rfc2326
[4] Sourceforge
http://sourceforge.net
[5] Slashdot, Adobe Uses DMCA On Protocol It Promised To Open, Maggio 2009
http://yro.slashdot.org/article.pl?sid=09/05/22/1254246
[6] Adobe, Real-Time Messaging Protocol (RTMP) specification
http://www.adobe.com/devnet/rtmp
[7] VMware Inc., VMware Server
http://www.vmware.com/products/server
[8] Adobe, Flash Media Streaming Server 3.5
http://www.adobe.com/products/flashmediastreaming
[9] Adobe, Flash player version penetration, Settembre 2009
http://www.adobe.com/products/player_census/flashplayer/version_
penetration.html
[10] Stats Owl, Flash Player Version Support, Novembre 2009
http://www.statowl.com/flash.php
[11] Adobe Flex
http://www.adobe.com/it/products/flex
[12] Adobe Photoshop Express
https://www.photoshop.com
[13] OSFlash, Red5 : Open Source Flash Server
http://osflash.org/red5
[14] OSFlash, Red5 Showcase
http://osflash.org/red5/showcase
61
[15] OSFlash Mailing List, RTMP Handshake changes in Flash 10.0.32.18, Agosto 2009
http://osflash.org/pipermail/red5_osflash.org/2009-August/035378.html
[16] Microsoft, Windows Media Services
http://www.microsoft.com/windows/windowsmedia/forpros/serve/
prodinfo2008.aspx
[17] Paul Gregoire, RTMP load tester
http://gregoire.org/2008/09/12/rtmp-load-tester
[18] Microsoft, Windows Media Services Tools and Add-ins
http://www.microsoft.com/windows/windowsmedia/forpros/serve/tools.aspx
[19] JW Player
http://www.longtailvideo.com/players/jw-flv-player
[20] Flowplayer
http://flowplayer.org
[21] Silverlight 2 Video Player
http://www.widgetslab.com/2008/06/26/silverlight-2-open-source-video-player
[22] Tinic Uro, Adobe Developer, New File Extensions and MIME Types for Flash video
http://www.kaourantin.net/2007/10/new-file-extensions-and-mime-types.
html
[23] Microsoft, Scripting with Windows PowerShell
http://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx
[24] FFmpeg
http://ffmpeg.org
[25] Projects based on FFmpeg
http://ffmpeg.org/projects.html
[26] FFmpeg Documentation
http://ffmpeg.org/ffmpeg-doc.html
[27] FLVTool2
http://inlet-media.de/flvtool2
[28] Adobe, FLV file format specification
http://www.adobe.com/devnet/flv
[29] World Wide Web Consortium, XMLHttpRequest
http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/
[30] jQuery
http://jquery.com
[31] YUI Compressor
http://developer.yahoo.com/yui/compressor/
62
[32] Galleria
http://devkick.com/lab/galleria/
[33] World Wide Web Consortium, Synchronized Multimedia
http://www.w3.org/AudioVideo
[34] Real Player
http://real.com
[35] Ambulant Player
http://www.ambulantplayer.org
[36] Microsoft Developer Network (MSDN), Introduction to HTML+TIME
http://msdn.microsoft.com/en-us/library/ms533099(VS.85).aspx
[37] World Wide Web Consortium, Synchronized Multimedia Integration Language (SMIL
3.0)
http://www.w3.org/TR/2008/REC-SMIL3-20081201/cover.html
[38] Flowplayer Javascript API
http://flowplayer.org/documentation/api/index.html
[39] StopWatch Script in JavaScript
http://www.java-scripts.net/javascripts/Stop-Watch-Script.phtml
[40] jqModal, Minimalistic Modaling with jQuery
http://dev.iceburg.net/jquery/jqModal/
BIBLIOGRAFIA
63