Streaming Audio/Video su Architettura Service-Oriented OSGi
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
ALMA MATER STUDIORUM – UNIVERSITÀ DI BOLOGNA
SEDE DI CESENA
SECONDA FACOLTÀ DI INGEGNERIA CON SEDE A CESENA
CORSO DI LAUREA IN INGEGNERIA INFORMATICA
TITOLO DELL’ELABORATO
Streaming Audio/Video su Architettura Service-Oriented
OSGi
Elaborato in
Sistemi Distribuiti L-A
Relatore Presentata da
Ing. Andrea Omicini Claudio Buda
Co-Relatore
Ing. Alessandro Ricci
Sessione Iª
Anno Accademico 2002/03
Indice Buda Claudio
______________________________________________________________________________
Indice
CAPITOLO 0: Prologo ..................................................................................................................5
Introduzione ................................................................................................................................5
Obiettivo tesi ..............................................................................................................................5
CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale ...............................6
Problema ....................................................................................................................................6
Cos’è un’Architettura di Servizi ...............................................................................................7
Framework OSGi .......................................................................................................................8
OSGi in ambito domotico .......................................................................................................11
Streaming Audio/Video...........................................................................................................12
RealNetworks.......................................................................................................................13
Microsoft ...............................................................................................................................13
Apple .....................................................................................................................................14
JMF ........................................................................................................................................15
MMAPI...................................................................................................................................15
CAPITOLO 2: Analisi ..................................................................................................................16
Obiettivo tesi a livello d’analisi. .............................................................................................16
Gestione dei Servizi e del loro comando .............................................................................16
Esempio Telecamera-Televisore gestibili da PDA.........................................................17
Use Case ..................................................................................................................................20
Approfondimento sui servizi ‘dispositivo’.............................................................................25
Nuova visione: dai servizi “dispositivo” ai servizi “trasmissione e ricezione”.................26
Ritornando allo Use Case… ..................................................................................................27
CAPITOLO 3: Progetto ...............................................................................................................29
Obiettivo tesi a livello di progetto ..........................................................................................29
Come si crea un Bundle?.......................................................................................................29
Cos’è un proxy? .......................................................................................................................31
RMI ........................................................................................................................................31
Bundle acquisizione/trasmissioneAV (CaptureAV)............................................................32
Installazione .........................................................................................................................33
Servizio .................................................................................................................................33
Bundle ricezione/riproduzioneAV (PlayAV).........................................................................34
Installazione .........................................................................................................................35
Servizio .................................................................................................................................35
2
Indice Buda Claudio
______________________________________________________________________________
Ritornando allo Use Case… ..................................................................................................37
Multicasting ..............................................................................................................................39
Uno sguardo ai servizi con un occhio JAVA .......................................................................39
Servizio captureAV..............................................................................................................39
Servizio playAV....................................................................................................................41
CAPITOLO 4: Il protocollo RTP ................................................................................................45
Streaming Multimediale ..........................................................................................................45
Protocolli per Media Streaming .............................................................................................45
Real Time Transport Protocol ...............................................................................................46
Servizi RTP...............................................................................................................................46
Architettura RTP ......................................................................................................................47
Pacchetti dati........................................................................................................................47
Pacchetti di controllo ...........................................................................................................48
Applicazioni RTP ....................................................................................................................49
CAPITOLO 5: Studio delle performances del sistema ..........................................................50
Scelte.........................................................................................................................................50
Scalabilità .................................................................................................................................50
Sicurezza ..................................................................................................................................50
Robustezza ..............................................................................................................................51
Ridondanza ..............................................................................................................................51
Universalità ...............................................................................................................................51
Sincronizzazione in politiche di multicasting .......................................................................51
Mixaggio Audio/Video.............................................................................................................52
CAPITOLO 6: Implementazione & Testing .............................................................................53
Steps .........................................................................................................................................53
Bundle CaptureAV ..................................................................................................................54
Test 1.....................................................................................................................................57
Bundle PlayAV .........................................................................................................................57
Test 2.....................................................................................................................................60
Costruzione interfaccia grafica e rilevamento servizi ........................................................60
Modifica implementativa per la visualizzazione locale ..................................................61
Test 3.....................................................................................................................................62
Classe del servizio captureAV ..............................................................................................63
Classe per la Trasmissione multimediale ............................................................................64
3
Indice Buda Claudio
______________________________________________________________________________
Test 4.....................................................................................................................................67
Classe del servizio PlayAV ....................................................................................................68
Classe per la Ricezione multimediale ..................................................................................68
Test 5.....................................................................................................................................70
Mixaggio Audio e Video..........................................................................................................71
Test 6.....................................................................................................................................72
Proxy del servizio captureAV ................................................................................................72
Test 7.....................................................................................................................................73
Proxy del servizio playAV ......................................................................................................73
Test 8.....................................................................................................................................74
Variante distribuita ..................................................................................................................74
Test 9.....................................................................................................................................74
CAPITOLO 7: Epilogo ................................................................................................................75
Conclusioni e Ringraziamenti ................................................................................................75
Bibliografia................................................................................................................................76
Indice delle figure ....................................................................................................................77
4CAPITOLO 0: Prologo Buda Claudio
______________________________________________________________________________
CAPITOLO 0: Prologo
Introduzione
Il tema della distribuzione di servizi è più che mai oggi sentito dalla comunità scientifica e
chiunque si appresti a leggere questa tesi si troverà ad affrontare argomenti notevolmente
attuali e specializzati. Perciò con questa piccola prefazione si intendono focalizzare i punti
salienti della trattazione del testo. L’ambiente è quello domotico, ma nulla toglie la
possibilità di esportare il lavoro svolto in qualsiasi altro ambito distribuito. Il sistema
concepito è composto da dispositivi domestici con elevata capacità computazionale in
comunicazione fra loro tramite una qualsiasi rete. A livello superiore un’architettura
distribuita permette ad ogni entità di comunicare con un linguaggio comune: la fornitura e
l’utilizzo di servizi. È in questo contesto che la tesi contribuirà ad accelerare l’evoluzione di
un inequivocabile tipo di servizio, quello che permette lo streaming audio e video. Si
passerà perciò a progettare una categoria di servizi in ottemperanza con l’architettura e
tutto ciò che ne concerne, abile a fornire capacità e strumenti per distribuire audio-visione
nel sistema in cui si opera.
L’architettura di servizi scelta sarà quella definita dall’infrastruttura OSGi Framework
implementabile tramite programmazione JAVA di SUN Microsystem. I mezzi per gestire lo
streaming all’interno dei servizi saranno forniti dal framework JavaMedia, un pacchetto
aggiuntivo della SUN, che utilizza il protocollo RTP per la trasmissione di dati multimediali.
Obiettivo tesi
L’obiettivo sarà perciò sviluppare in maniera “ingegneristica” servizi che consentano il
traffico di audio e video per una architettura pensata all’interno delle abitazioni. Lo
svolgimento avrà come primo target la presa di coscienza delle alternative sia architetturali
che implementative; in seguito si passerà ad una progettazione svincolata da termini di
sviluppo a basso livello, per arrivare alla fase operativa con la massima libertà.
Quest’ultimo processo porterà allo produzione di prototipi applicabili al contesto di
riferimento.
5CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
CAPITOLO 1: Problemi e tecnologie in ambito domotico
multimediale
Problema
Oggi, con le nuove tecnologie che avanzano , la domotica non è più un fantasioso sogno
ma un po’ alla volta comincia a divenire realtà, inserendo in continuazione nelle abitazioni
qualche frammento in più che la riguarda. Già non è strano avere in casa una rete
domestica (LAN) basata su protocollo TCP/IP, magari come collegamento fra solamente
due postazioni ma facilmente ampliabile a più. Inoltre anche i servizi per la comunità
odierna passano sempre di più per questo percorso tecnologico, ed un lampante esempio
è internet, offrendo la possibilità di comprare, vendere, conoscere e divertirsi tutto
comodamente dalla scrivania di casa propria. Ma la domotica non è solo questo. Per
domotica si intende l’informatizzazione della “domus” perciò la possibilità di fare diventare
più intelligenti tanti strumenti che accompagnano la vita di tutti giorni. Lavatrici, impianti
luce, frigoriferi, computer, palmari e cellulari, oramai sono tutti collegabili tra loro
permettendone il dialogo reciproco all’interno della casa o anche dall’esterno tramite
internet.
Un’altra tecnologia che comincia a pervadere la realtà quotidiana è la video-
comunicazione. Pubblicità, messaggi personali, offerte e informazioni, se un tempo
venivano scambiati tramite carta, in seguito soppiantata dalla telefonia, oggi la video-
comunicazione sta aprendo le porte ad una nuova era. Sempre più imprese affermano la
loro presenza su internet avvalendo i loro portali di messaggi visivi, veri e propri filmati che
alla pari della televisione tentano di influenzare l’ipotetico cliente. Unendo video-
comunicazione a domotica si sente l’esigenza di stabilire delle regole per comunicare con
dati visivi e acustici all’interno della casa.
Se invece che inserire dispositivi intelligenti in casa e tentare di farli comunicare, si
ribaltasse la visuale, bensì costruire un’infrastruttura di comunicazione all’interno della
casa e sopra a questa impiantare i dispositivi, allora ci si troverebbe ad affrontare un tema
molto sentito al giorno d’oggi. Infatti in ambiente domestico, ma anche in altre realtà
(intelligence on board per auto), ci si sta indirizzando ad una linea comune che permetta di
vedere la casa come un mercato di servizi dove c’è chi li offre e chi li usa. Si è sentita così
l’esigenza di definire un’architettura (SOA: Service Oriented Architecture), una struttura
6CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
che può appoggiarsi ad una rete fisica, indipendente da sistemi operativi, che permette ad
applicazioni di comunicare attraverso lo scambio di servizi che ogni ente (nel seguente
caso si tratta di devices domestici) mette a disposizione per gli altri. L’astrazione dal
sistema operativo è possibile attraverso la Java Virtual Machine che una volta installata
permette alle applicazioni scritte in linguaggio Java di “girare” senza preoccuparsi di cosa
risiede a livello sottostante (Windows, Unix, Macintosh, Solaris).
Ma come un’architettura di servizi può influenzare la video-comunicazione domestica?
Con video-comunicazione domestica innanzitutto si intende una qualsiasi comunicazione,
che coinvolge immagini, sequenze visive e audio, perciò sia dispositivi di cattura
(videocamere e microfoni) che di riproduzione (qualsiasi schermo che lo permetta, dal
televisore al palmare). Perciò risultano già definiti i dispositivi presenti in un’architettura
domestica che hanno bisogno di scambiare servizi per il trasferimento di dati audio/video.
Saranno proprio questi devices che utilizzeranno l’architettura di servizi per comunicare tra
loro permettendo lo scambio di dati multimediali.
Cos’è un’Architettura di Servizi
Quali sono le tecnologie nate negli ultimi anni atte ad implementare architetture software in
grado di fare comunicare in un sistema distribuito componenti diversi fra loro? Si sta
parlando di queste architetture che seguono lo standard di progettazione orientata ai
servizi, che il paradigma SOA definisce nei suoi aspetti più vincolanti. In termini semplici,
una architettura orientata ai servizi, fornisce un modello di progettazione standard, che dà
la possibilità a componenti software, accoppiati in modo lasco e che si trovano in una rete,
di pubblicare le loro funzionalità, di essere ricercati e utilizzati, e di essere composti da tutti
gli altri attraverso la rete. Ogni applicazione costituita da servizi distribuiti, può interagire
con ogni altra applicazione basata sui servizi, senza preoccuparsi della locazione e
soprattutto del “protocollo” di comunicazione, ma basandosi solamente sul contratto
stipulato e sulla interfaccia. Questa tecnologie di cui andremo a parlare si basano su Java
per ottenere sistemi e servizi indipendenti dalla piattaforma su cui girano, per cui parlando
di interfacce, oggetti e classi si intendono interfacce, oggetti e classi Java. Risulta
fondamentale spiegare ora il perché di un’architettura tale. Sostanzialmente è un nuovo
modo di vedere le applicazioni software; gli attuali metodi di produzione di sistemi software
risultano troppo lenti e poco reattivi ai continui “spostamenti” del mercato. Quello che è
richiesto al sistema software, è che rispetti determinati requisiti, quali: flessibilità,
dinamicità, robustezza e qualità. Non è più possibile pretendere di costruire un sistema
7CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
che, dopo il suo rilascio, non necessiti più di modifiche. Un sistema basato sui servizi è
innovativo proprio in ciò, se un servi zio viene visto come l’applicazione che deve subire
modifiche risulta molto facile per l’azienda che lo sviluppa cambiarne una sua parte e
reinserirlo nel contesto dell’architettura senza dover svilupparla di nuovo. Questi concetti si
inseriscono anche in un tema di mercato più flessibile dove si riconoscono fornitori dei
servizi e clienti che li “affittano”, senza ottenerne la proprietà ma con la capacità di
lanciarlo e quindi di utilizzarlo, pagandolo alla società produttrice se non si tratta di
software ‘open source’. Questa visuale si potrebbe espandere a tutto il mondo informatico
ma le motivazioni per cui questa tecnologia rimane per ora ristretta nell’ambito domotico
ed embedded sembrano essere sostanzialmente due, l’impossibilità di cambiare da un
momento all’altro tutto il modo di pensare e sviluppare software e la difficoltà d’inserire
un’architettura in un ambiente così vasto come potrebbe essere internet.
Oggi sono diverse le tecnologie nate e sviluppate come SOA ma sono due le principali che
hanno ottenuto una presenza più sostenuta sul mercato, Jini di SUN Microsystem e OSGi
Framework di OSGi entrambe sviluppate alla fine degli anni ’90.
I seguenti motivi portano però alla scelta della seconda possibilità architetturale. La prima
è che OSGi oggi ha preso maggiormente piede in ambito industriale mentre Jini sembra
rimanere più un’infrastruttura utilizzata in ambito accademico, che non riesce a sfondare
nel mercato. La seconda motivazione è che, ad una prima analisi, oltre a non fornire utili
strumenti per lo sviluppo aumentando notevolmente il lavoro di chi vuole implementare
applicazioni (anche se ciò comporta una libertà maggiore), Jini non permette di scendere
di livello per applicazioni come lo streaming che hanno bisogno di arrivare allo stadio fisico
per lo scambio di veri e propri pacchetti personalizzati alla trasmissione di questo tipo di
dati che potrebbero dipendere anche dalla rete stessa potendo utilizzare Wireless LAN o
Bluetooth.
Framework OSGi
L’Open Service Gateway initiative (OSGi) è un'organizzazione non-profit, nata nel 1999,
con sede in California (USA). Dalle iniziali 15 compagnie partecipanti, tra cui: Ericsson,
IBM, Nortel, Oracle, Philips, Sun, Motorola, Lucent, ecc… OSGi ha implementato una
specifica cioè un insieme di API per la gestione del ciclo di vita dei servizi, per la
risoluzione delle dipendenze, per la gestione dei dati, per la gestione dei dispositivi, per
regolare l’accesso ai servizi, per la gestione delle risorse e per la sicurezza del sistema.
Attraverso queste API, i clienti ricercano e usano i servizi desiderati, lasciando al sistema
8CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
tutti i problemi di gestione. In OSGi per utilizzare un servizio, ovvero un oggetto Java (va
ricordato che anche qui come in Jini ci si trova ad un livello superiore della JVM, perciò
l'implementazione è totalmente in Java assicurando la portabilità in ogni macchina
presente sul mercato), bisogna pubblicarlo registrando l'interfaccia e l’oggetto servizio
stesso, oltre al nome del servizio che lo descrive che sarà usato dai clienti come filtro per
rintracciarlo.
L'infrastruttura OSGi può essere utilizzata su qualsiasi piattaforma ed è applicabile a
qualsiasi ambiente computazionale; essa è in grado di ospitare, in una singola service
platform, più applicazioni provenienti da differenti service provider, che in essa hanno
installato i propri servizi, e che nell'architettura SOA sono gli agenti che forniscono i
servizi. In realtà emerge la problematica della registrazione di servizi remoti su un
framework centrale. Ciò non è ancora facilmente possibile e per questo si aggira il
problema installando proxy dei servizi sul framework client che comunicherà attraverso
RMI o altri protocolli di comunicazione ad oggetti remoti (es.: CORBA) con gli altri
framework server che mantengono lo stato e le proprietà del servizio vero e proprio.
Per lo sviluppo operativo di questo progetto si utilizzerà il prototipo di una seconda tesi, dal
titolo “OSGi: dalla piattaforma all’infrastruttura per servizi distribuiti in ambito domotico”,
che permetterà a frameworks distribuiti di comunicare tra loro per scambiarsi servizi.
I servizi possono addirittura usarsi tra loro, essi vengono riconosciuti dinamicamente dalle
applicazioni presenti sul framework, grazie a meta-servizi che esso offre. L'infrastruttura
fornisce un ambiente sicuro per i servizi, astraendo dal particolare protocollo di rete
utilizzato a livello inferiore con politiche di sicurezza basate su Java.
Il cuore di questa specifica è il framework; esso fornisce un ambiente di esecuzione Java
gestito, sicuro e “general purpose”, che supporta la distribuzione di servizi flessibili,
dinamici e scaricabili contenuti all’interno di Bundles ed eseguibili all’interno del
Framework. I bundles installati possono registrare il proprio servizio che viene condiviso
con gli altri presente sullo stesso framework. Di seguito si riporta l'architettura di OSGi
nella quale si può notare la sua completa portabilità.
9CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
fig 1.1 Architettura di servizi basata sullo standard del Framework OSGi (struttura)
Il Framework stesso è un bundle “speciale” (system bundle) ove al suo interno possono
essere installati, disinstallati, sospesi o avviati tutti i bundle che forniscono o richiedono un
servizio. All'interno di questo ambiente è presente anche un "Service Registry" (Service
Repository per lo standard SOA) dove vengono registrati e ricercati i servizi, che deve
comunicare con qualsiasi componente per fornire e rendere disponibile a sua volta
qualunque servizio. Il framework che gestisce i servizi riconosce quelli registrati da terzi e
alcuni già definiti, di tipo speciale (meta -sevizi), in grado di salvare messaggi,
amministrare e gestire dipendenze e permessi; essi possono anche prelevare
informazioni, inviare comandi, valutare la configurazione e monitorare gli altri servizi. I
bundles possono essere considerati i service provider, le uniche entità in grado di
registrare, gestire e distribuire, all’interno del Framework, i servizi che possiedono. Un
bundle è costituito da classi Java e altre risorse, che, insieme, forniscono i componenti,
chiamati servizi, utilizzabili dagli utenti e da altri bundle. All’interno del framework essi
sono distribuiti sotto forma di Java ARchive (file JAR). Attraverso gli eventi, generati in
modo asincrono, il Framework comunica alle entità presenti il verificarsi di determinate
azioni. Il paradigma di sicurezza del Framework si basa sulle specifiche Java 2.
La Gestione in OSGi è meno flessibile ma già in parte indirizzata e definita
dall'architettura, garantendo maggior sicurezza e fornendo allo sviluppatore gli strumenti
(sotto forma di meta-servizi), ma non le politiche che devono esser risolte caso per caso,
per gestire l'applicazione.
Un implementazione di OSGi è fornita da Gatespace un azienda scandinava che
distribuisce le documentazioni delle proprie API java per lo sviluppo di bundle da registrare
10CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
nel proprio framework installabile su qualsiasi sistema operativo. Questa sarà la soluzione
implementativa adottata come di architettura di servizi.
OSGi in ambito domotico
Si vuole ora inquadrare come un’architettura di servizi può entrare in casa ed essere
applicata ai dispositivi che ogni giorno accompagnano la vita di chiunque. Innanzitutto va
specificato che si dovranno utilizzare dispositivi “intelligenti” ovvero in grado di supportare
un sistema operativo e una Java Virtual Machine. Infine oltre alla JVM essi dovranno
avere installato almeno una parte del Framework OSGi al fine di cooperare con gli altri per
lo scambio dei servizi (offerta e domanda). Risulta evidente che ogni dispositivo che
inseriamo in casa offrirà i propri servizi, mentre il framework visto come una struttura
generale che amalgama tutti i framework dei devices “girerà” in continuazione
permettendo l’entrata e l’uscita dal sistema di periferiche. Ipotizzando di aver in casa
almeno un server centrale sempre “on line” nella rete domestica, esso dovrebbe ospitare il
cuore di tutti i framework, quello che vive in continuazione e accetta l’inserimento di altri
frameworks nella casa (installati nei dispositivi stessi). In realtà con questa visuale si
ottiene che ogni servizio di ogni devices sta su un framework diverso, e ciò esula dalla
concezione originale di architettura di servizi; L’ideale sarebbe avere un unico Framework
installato nel server che permetta ai dispositivi di registrare sopra i propri servizi e renderli
disponibili agli altri, mantenendo comunque lo stato del servizio in locale sulla periferica.
Risulta difficile però immaginare come un servizio possa vivere su un device senza un
framework che lo sostenga. Una soluzione, che l’altra tesi precedentemente citata
propone, è quella di generare una colla fra i vari frameworks, gestita da
FrameworkServers centrali, che permetta di astrarre dal distaccamento fisico degli stessi,
dando allo sviluppatore l’impressione di avere un framework unico ma distribuito su tutte le
macchine. In questa tesi si astrarrà da qualsiasi concezione di infrastruttura immaginando
che non ci siano problemi di ricerca servizi e distribuzione fra frameworks e ipotizzando
che nella rete domestica esista un architettura capace di accettare e gestire qualsiasi
nuovo servizio, che entra a farne parte o ne esce, senza smettere di restare “accesa”.
Quindi se la casa dispone già di un’infrastruttura del genere, ogni qualvolta un nuovo
componente elettronico “intelligente” entra in casa può fornire i servizi che ha su di se
installati e iniziare fin da subito a comunicare con chiunque è già attivo nella rete. Facile
immaginare come un PDA (Personal Digital Assistent) possa essere il primo ad entrare in
casa come gestore e pilota degli altri dispositivi, capace di cercare servizi e pilotarli in
11CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
modo che altri possano comunicare, come l’accensione di un televisore su un canale per
l’acquisizione immagini da telecamere, che ricercherebbe il servizio fornito da quest’ultima
già presente in rete. In sostanza il problema risulta a chi dare il comando e la gestione dei
servizi; ciò verrà approfondito nel cap 2.
fig 1.2 Sistema di comando dei dispositivi di una casa da parte di un dispositivo più
intelligente (PDA) immerso in un’architettura OSGi
Streaming Audio/Video
È fondamentale capire come può esserci video-comunicazione su dispositivi intelligenti
(intendendo qualunque macchina fornita di un sistema operativo, una JVM e un
Framework OSGi), e perché molto spesso si parla di streaming. Con l’avvento di Internet
impelle il bisogno di comunicare “vedendosi” e ciò avvenne in principio attraverso il web,
con del semplice scambio di file multimediali che chiunque poteva scaricare e visualizzare
(tramite un player) sulla propria macchina, anche se non si era più collegati in rete. Questo
però portava ad un enorme spreco di tempo. Considerando che i file multimediali hanno
enorme capacità in numero di byte, un navigatore correva il rischio di perdere molto tempo
per il downloading del video, per magari accorgersi al termine che non era ciò che cercava
o voleva. A meta degli anni ’90 nasce lo streaming, una tecnica con la quale visualizzare
12CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
in contemporanea al downloading del filmato che interessa, con la possibilità quindi di
scartarlo nel caso non sia quello giusto. Tramite lo streaming ciò che si cattura viene
compresso attraverso appositi codec e inviato in rete allo stesso modo, sia che la fonte sia
una telecamera (in questo caso ci sarà una continua cattura di immagini), sia che essa sia
un file (la fase di cattura è già terminata). L’utente che riceve lo streaming potrà
decodificarlo e iniziare subito la visualizzazione evitando un inutile appesantimento del
proprio hard disk con file di grosse dimensioni, dato che in seguito alla visualizzazione i
dati vengono eliminati . In ambito domotico la questione è pressoché indifferente se non
per il fatto che a
l rete non è più globale e perciò si prevede una maggior ampiezza di
banda con una conseguente riduzione del tasso di compressione dei filmati trasmessi e
quindi maggior qualità audio e video.
Oggi sul mercato in ambito di streaming fanno da padroni tre importanti imprese,
RealNetwork, Microsoft e Apple. Il più delle volte queste applicazioni generano dati non
compatibili tra loro, da ciò nasce la difficoltà di implementare uno standard unico da
seguire.
RealNetworks
RealNetworks è presente sul mercato dal 1995 e oggi migliaia di imprese utilizzano i suoi
prodotti per soluzioni di video-streaming su web. Famosa per RealPlayer e il susseguirsi
delle sue versioni si è posta come una delle maggiori potenze nel campo. Nonostante il
player rimanesse gratuito, tutte le applicazioni a lato server sono sempre state prezzate.
Da giugno 2002 la RealNetworks ha aperto un nuovo progetto con il nome di Helix,
indirizzato sempre allo sviluppo di streaming audio e video ma con la particolarità di
essere OpenSource e gratuito in qualsiasi suo componente e si appresta a fare forte
concorrenza a Microsoft che negli ultimi anni sembra aver avuto la meglio. Il server di
Helix supporta oggi fin a 55 tipi di file multimediali compresi quelli di Microsoft, QuickTime
gli innovativi MPEG4. Non ha alcun problema di sistema operativo perché la piattaforma
può benissimo girare su qualsiasi, da Windows a Linux. Per la sicurezza è indipendente
dal sistema su cui si trova perciò astrae dai problemi di una piattaforma insicura.
Microsoft
Microsoft fornisce il suo Windows Media Video in unione con il sistema operativo perciò ad
un primo sguardo può sembrare vantaggioso considerandolo gratuito, ma non lo è, causa
13CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
la licenza del sistema e un ulteriore costo da pagare per installare un server multimediale.
Un successivo problema risulta la gamma di tipi di file compatibili. I server salvano i filmati
in file AVI o ASF di proprietà Microsoft costringendo a volte l’utente ad avere anche il
player omonimo a lato client. La sicurezza deriva soprattutto dell’unico sistema operativo
sui cui si appoggia perciò anche se questo potrebbe sembrare uno svantaggio, ha dalla
sua l’immenso utilizzo di migliaia di clienti che se lo trovano già a disposizione con
l’acquisto di Windows.
Apple
Nato per sistemi operativi Apple ha avuto un enorme sviluppo il prodotto QuickTime che
oggi è arrivato alla sua sesta versione. Completamente gratuito e open source è la
risposta alla ricerca di uno standard per lo streaming audio e video. Può trasformare filmati
in file multimediali di tantissimi tipi fra cui l’MPEG-4 che ha scelto QuickTime come codec
standard per la codifica del suo genere. In ultima analisi si nota come si è cercato anche di
rendere compatibile il player con Internet Explorer creando appositi activeX che possono
essere visti con questo browser di enorme diffusione. Di grande interesse è anche come
oggi vengano fornite delle API per lo sviluppo in JAVA di applicazioni per lo streaming.
Osservazione
Risulta però fondamentale per riuscire a compiere streaming su un
architettura OSGi avere API java per lo sviluppo (si ricorda che con
l’implementazione di GateSpace i servizi sono costruiti in Java). Perciò ci si
trova davanti alla scelta di scartare strumenti di video-comunicazione come
Windows Media e RealVideo che non forniscono alcun tipo di API Java per
lo sviluppo personale di applicazioni audio/video.
Resta valido QuickTime che con il package aggiuntivo fornisce API per permettere
d’inserire il player e quant’altro in applicazioni Java. Un’altra plausibile soluzione verrebbe
dalla SUN stessa con l’utilizzo di JMF (Java Media Framework, oggi alla versione 2.1), un
insieme di classi (API) per la cattura, la trasmissione e la visualizzazione/ascolto di formati
multimediali.
14CAPITOLO 1: Problemi e tecnologie in ambito domotico multimediale Buda Claudio
______________________________________________________________________________
JMF
Le API di questo framework estendono la piattaforma Java offrendo capacità avanzate di
processamento media, includendo la cattura, la compressione e la trasmissione per
importanti tipi di codecs come MP3, Flash, Microsoft AVI format, MPEG-1 attraverso
Real-time Transport Protocol and Real-time Streaming Protocol (RTP/RTSP). Questa
tecnologia sopporta inoltre i tipi di file come quelli di QuickTime. In aggiunta queste API
includono un’architettura aperta che permette agli sviluppatori di accedere e manipolare i
vari componenti di visualizzazione e gestione video e cattura immagini come effetti tracce
e renders. Permettono anche di utilizzare personali componenti plug -in.
MMAPI
Oltre che JMF la Sun ha sviluppato anche un package addizionale MobileMediaAPI per la
piattaforma di devices d’informazione (utilizzato per la telefonia mobile e altri dispositivi
mobili come i pda), che svolge praticamente gli stessi compiti del precedente ma con una
maggiore leggerezza in fatto di dimensione del pacchetto, escludendo strumenti a volte
inutilizzati.
Osservazione
Per non doversi legare sin dal principio alla tecnologia si sceglie di
continuare nell’analisi astraendo da essa, ipotizzando di utilizzarne una
compatibile con JAVA e OSGi, che in sostanza si deciderà con la scelta a
livello implementativo fra JMF e QuickTime.
15CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
CAPITOLO 2: Analisi
Obiettivo tesi a livello d’analisi.
L’obiettivo di questa tesi è quello di definire dei bundles standard per OSGi applicabili su
qualsiasi dispositivo Hi-Fi intelligente che permettano di farlo interagire in un infrastruttura
a servizi con altri componenti analoghi. Si dovrà perciò stabilire una gerarchia di interfacce
di servizi valida per dispositivi tali e un insieme di package che serviranno per lo streaming
Audio-Video utilizzando le API in Java messe a disposizione da tecnologie appropriate.
Ogni servizio pubblico sarà reso disponibile all’utente attraverso delle interfacce grafiche
debitamente costruite. Siccome l’evoluzione della tecnologia e del mercato sono continue
non si potrà costruire un sistema chiuso, anzi si deve tenere aperta qualsiasi soluzione
aggiuntiva perciò aspettarsi l’introduzione di nuovi dispositivi creando un ambiente
dinamico e aperto.
Gestione dei Servizi e del loro comando
Siccome la tesi è centrata nell’analisi di impianti Hi-Fi non verranno esaminati dispositivi
quali frigoriferi, forni, o condizionatori ma il concetto di gestione e comando dei dispositivi
può essere esportato anche a loro. Un ipotetico use case vedrebbe i seguenti quattro
operatori comunicare nell’intranet casalinga:
- un server che contiene il cuore del Framework e dove i servizi vengono
registrati e monitorati,
- un palmare capace di interagire col server per identificare i servizi,
- un televisore che può acquisire immagini e suoni sia da antenna che da
telecamere,
- una telecamera che acquisisce immagini e suoni usata ad esempio per
funzioni di video-sorveglianza,
Si considera che palmare, televisore e telecamera abbiano registrato il loro servizio
(implementato dalla casa produttrice) nel server di casa. Questo servizio consiste nel
mettere a disposizione strumenti per potere essere utilizzati da qualsiasi attore del sistema
e inoltre di comunicare col framework per poter installare altri Bundle che contengono
servizi. Questo è un po’ il concetto di ogni Architettura dei Servizi dove si hanno Provider
che mettono a disposizione servizi e Client che li usano affittandoli ma non acquisendone
16CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
la proprietà. Entrando in dettaglio nel caso di streaming ci possono essere più visioni di
funzionamento di tale sistema.
Esempio Telecamera-Televisore gestibili da PDA
Dal palmare si riesce ad accedere al servizio televisore che fornisce puntualmente per i
pda (o qualsiasi altro dispositivo mobile) un servizio proxy (un specie di telecomando
capace di pilotare il vero servizio che sta sul televisore attraverso il protocollo RMI) dotato
di un’interfaccia grafica in grado di scegliere le funzionalità da richiamare (es. accensione
e spegnimento tv, cambiare canale e volume, etc…). C’è la possibilità da palmare anche
di visualizzare l’interfaccia del servizio telecamera con le sue operazioni (attiva e arresta
trasmissione flusso audio, attiva e arresta trasmissione flusso video, etc…).
RMI
fig 2.1 Esempio di come il PDA può pilotare il Televisore attraverso il proxy del servizio
1° caso
A questo punto si potrebbe sintonizzare il televisore su un canale standard per la ricezione
dati dalla rete (precisamente dalle telecamere come ad esempio il canale AV) e attivare il
flusso di dati della telecamera nella rete. Avviene quindi in principio un handshake fra i due
dispositivi per localizzarsi e permettere la sincronizzazione dei dati. Ma se prima venisse
attivato il flusso della telecamera e poi il canale AV della televisione? A chi spetta pilotare
17CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
l’handshake? Se per la trasmissione di dati ogni dispositivo ha bisogno dell’indirizzo IP
dell’altro chi è il primo a fare la richiesta? È la telecamera che deve richiede quello del
televisore e settare il proprio alla tv o viceversa? Questi sono già due sottocasi.
2° caso
Da palmare, non si giunge ad avere nell’interfaccia della tv la possibilità di mettere su un
ipotetico canale AV, ma solamente azionando l’avvio del flusso della telecamera essa si
occuperà di reperire il servizio tv e utilizzare strumenti di cui è a conoscenza per eseguire
l’handshake e far visualizzare al televisore ciò che essa acquisisce.
3°caso
In contrapposizione al secondo caso non si hanno nell’interfaccia della telecamera tasti
per avviare la trasmissione dati, ma solo mettendo sul canale AV il televisore stesso si
occuperà di handshake e di far partire l’acquisizione e la trasmissione da parte della
telecamera attraverso le sue funzionalità già a conoscenza tramite interfacce standard.
4°caso
Non si dispone di un palmare ma semplicemente il televisore permette di visualizzare
l’interfaccia del suo servizio sullo schermo, e tramite un semplice telecomando, che
permetta di gestire un menu, si potrà proseguire in uno dei tre casi precedenti
visualizzando le interfacce di entrambi i dispositivi direttamente sul televisore.
5°caso
Invece che dalla postazione mobile o dal televisore i primi tre casi sono replicabili dal
computer che fa da server per l’architettura.
6°caso
Potrebbero esserci più televisori nella casa e più telecamere. Perciò decidere quale
telecamera deve acquisire e quale televisore deve riprodurre risulterebbe ancora più
complicato. Ad esempio, se ci sono due televisori e il flusso della telecamera viene
trasmesso, su quale televisore viene riprodotto? Su quello che ha posizionato il proprio
canale su AV? Su entrambi se si trovano tutti e due sul canale AV?
Osservazione
18CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
Se non risultasse possibile settare il canale AV come nel 2° caso come
faccio a capire quale televisore vuole ricevere? Perciò risulta impossibile
non dire al televisore di porsi su un canale apposito per la ricezione di
segnale da telecamera.
7°caso
Se si disponesse di un tv e due telecamere? Non si potrebbe dare il comando alla tv una
volta selezionato il canale AV di ricevere streaming da telecamera, non saprebbe quale
telecamera attivare! La soluzione potrebbe essere fare un canale AV per ogni telecamera
ma come predeterminare il tetto massimo di telecamere che possono entrare a fare parte
di un sistema di sicurezza?
Osservazione
Anche per questo caso risulta impossibile non definire quale telecamera
deve attivare il flusso per visualizzare i propri contenuti.
8°caso
E se si possedessero due telecamere e due televisori, attivando la trasmissioni
d’entrambe le telecamere cosa accadrebbe? Per questo si sente il bisogno impellente di
definire delle regole per la gestione del flusso di dati nella casa esaminando tutti possibili
casi dipendenti da chi si trova nelle rete domestica.
Altri casi
Si potrebbe andare avanti per molto nell’elenco dei casi, basti pensare alla possibilità di
visualizzare ciò che una telecamera acquisisce direttamente nel palmare piuttosto che in
un televisore, oppure pilotare il flusso di un microfono che non fa parte della famiglia delle
telecamere alle casse del televisore, etc…
Una soluzione ragionevole
Per poter dare una soluzione che comporti la massima flessibilità si deve pensare alla
massima disponibilità di dispositivi all’interno della casa. Ipotizziamo perciò un numero
illimitato di strumenti di categoria Hi-Fi (televisori, telecamere, VideoPlayer, microfoni,
impianti stereo) e di un numero illimitato di mobile devices (pda, smartphone, notebook;
19CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
ogni componente della famiglia potrebbe averne uno personalizzato per comandare il
sistema).
In questo agglomerato di dispositivi si pensa alla soluzione di una caso di vita familiare.
Use Case
La madre chiede al figlio maggiore (Giacomo) che si trova nel salotto a guardare la tv di
dare una controllata al fratellino (Mattia) che gioca col cane in giardino e comunicargli che
il pranzo è pronto, e aspettarsi una conferma da quest’ultimo. Per fare ciò sicuramente
Giacomo sa che nella casa oltre al televisore in salotto con un eventuale microfono a
portata di mano, risiedente ad esempio nel pda molto evoluto, si ha una telecamera che
da sul giardino prevista di microfono e mini casse. Siccome Mattia ha dimenticato il suo
pda in casa, Giacomo dovrà comunicare tramite la telecamera in giardino. In
contemporanea il fratello di mezzo (Nicola) vuole visualizzare da camera sua come
procede l’esperimento in cantina che il professore di chimica gli ha chiesto di fare a casa.
fig 2.2 Dispositivi presenti in un ipotetico use case di vita familiare
SOLUZIONE USE CASE
Giacomo, che prima stava guardandosi un film da dvd di vecchia generazione perciò
connesso al televisore tramite cavo SCART decide per prima cosa di visualizzare cosa fa
il fratello. Per fare ciò potrebbe semplicemente vederlo direttamente sul pda che ha in
20CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
mano tramite la funzione “visualizza da dispositivo” che il servizio della telecamera in
giardino mette a disposizione attraverso la sua interfaccia (ipotizzando che il proxy del
servizio telecamera ne abbia una). Per cui selezionando l’interfaccia della telecamera
giardino, il pda chiede alla telecamera l’indirizzo, se non ne è già a conoscenza, si mette in
ricezione e richiama l’operazione trasmetti_su_dispositivo indicando l’indirizzo del
dispositivo sul quale si vuole visualizzare. Siccome però Giacomo vuole vedere bene cosa
Mattia sta combinando preferisce visualizzarlo sullo schermo della Tv. In questo caso sul
pda decide di visualizzare l’interfaccia televisore. Da un ipotetico menu di quest’ultima si
potrà scegliere da quale telecamera presente nella casa si desidera visualizzare lo
streaming.
Osservazione
Come fa l’interfaccia grafica del televisore a sapere quali telecamere sono in
casa? Si potrebbe stabilire che ogni qualvolta venga aperta l’interfaccia di
un dispositivo di visualizzazione o ascolto, essa faccia un controllo su
Framework dei dispositivi di acquisizione presenti nella casa. O ancora
meglio quando un dispositivo di acquisizione entra in casa, venga lanciato
un evento che sollecita tutte le interfacce grafiche ad aggiornarsi, stando in
ascolto di questo tipo di eventi, così da avere un cambiamento real-time
dell’interfaccia, con l’aggiunta di nuove fonti.
fig 2.3 Controllo del servizio Tv attraverso il PDA che utilizza il Proxy Tv
21CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
Scegliendo la telecamera del giardino è il servizio televisore che si mette in ricezione della
telecamera selezionata, di cui saprà già l’indirizzo avendola scelta dal menu, e lancia lo
strumento del servizio telecamera_giardino che farà trasmettere su un dispositivo del
quale si conosce l’indirizzo passatogli dalla destinazione che ha il controllo.
fig 2.4 Il servizio TV si mette in ricezione dei dati della telecamera dopo aver effettuato una
connessione
Osservazione
Come fa il comando a passare dal pda al televisore? Se l’interfaccia di
scelta dispositivi trasmissione/ricezione era quella del proxy del servizio TV
automaticamente esso poteva dialogare con il televisore stesso che può
attivare un canale di ricezione conoscendo già la telecamera in questione e
le sue operazioni possibili. Il problema sarà a livello progettuale nel
richiamare queste operazioni.
In contemporanea Nicola fa la stessa cosa in camera sua visualizzando nel televisore di
camera l’audio e video della telecamera della cantina.
Osservazione
Ma se Nicola avesse voluto vedere anche lui in giardino? Allora si sarebbe
dovuta creare un sessione multicast, ovvero la telecamera avrebbe dovuto
22CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
aprire in principio una sessione diversa dove il flusso di dati non confluiva su
un unico indirizzo ma a più. Perciò non si può parlare di un’operazione
trasmetti_su_dispositivo_unico perché in seguito altri televisori avrebbero
potuto voler vedere. Quindi o si creano nuove sessioni ad ogni coppia
source-sink (sorgente -destinazione) oppure si attivano sessioni multicast. Si
definirà in seguito la scelta dopo uno studio di cosa le tecnologie mettono a
disposizione.
fig 2.5 È stata aperta una sessione multicast per trasmettere a più ricevitori della casa
Osservazione
Ma perché si preferisce dare il comando al dispositivo sink anziché a chi
trasmette? Dal palmare si sarebbe potuto visualizzare un menu a tendina
fornito dall’interfaccia della telecamera, per visualizzare su un determinato
tv. A questo livello non è ancora chiaro a chi dare il comando ma soprattutto
se attivare prima trasmissione o ricezione. Dipenderà dal protocollo che si
andrà ad usare per questo prima di negare qualsiasi soluzione si preferisce
continuare nell’analisi prendendo però ora per buona la scelta di pilotare la
telecamera direttamente dalla destinazione.
In realtà Nicola si accontenta di visualizzare come procede il suo esperimento utilizzando il
suo PDA proprio come Giacomo.
23CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
fig 2.6 Come in precedenza, la televisione visualizza dopo essere stata pilotata dal PDA
Ora Giacomo vede Mattia e vuole comunicargli che è pronto il pranzo. Per lo stesso
ragionamento seleziona la destinazione, ovvero le mini-casse della telecamera in giardino
e tramite il suo menu a tendina sceglie la fonte, che sarà il pda di se stesso (munito di un
microfono). Ancora una volta attraverso il PDA svolge un azione di controllo verso gli altri
dispositivi disponendo di un Proxy del loro servizio prelevato dal framework. Una volta
stabilita la connessione Mattia avviserà il fratello che sta arrivando, utilizzando la
precedente connessione televisore_salotto e camera_giardino ancora attiva.
24CAPITOLO 2: Analisi Buda Claudio
______________________________________________________________________________
fig 2.7 In questo caso il PDA sceglie se stesso come dispositivo di trasmissione audio e la
telecamera come destinazione
A questo punto Giacomo chiude entrambe le connessioni.
Osservazione
Può Giacomo chiudere la connessione tv-telecamera solamente cambiando
canale della tv? Sembrerebbe la cosa più logica e in effetti una prima
soluzione sarà proprio quella ma ciò indurrebbe a non potere visualizzare
due telecamere su uno stesso televisore se l’unico modo per chiudere una
connessione fosse effettivamente cambiare canale TV. Questi temi
verranno affrontati in seguito dopo uno studio della tecnologia soprattutto di
banda per la trasmissione di questo tipo di dati.
Approfondimento sui servizi ‘dispositivo’
Si vogliono ora evidenziare quali saranno i caratteri più generali e quali più particolari. Per
generale si può intendere un’architettura che accomuni tutti i servizi per Hi-Fi che si
desiderano standardizzare. Ricordiamo quali sono i dispositivi di cui si vuole fornire servizi:
1. PDA, SmartPhone, o Notebook
2. Televisore
3. Telecamera (compresa di microfono e casse)
4. Microfono
5. Impianto Stereo (compreso di casse ed apparati di acquisizione)
Ma quali sono le caratteristiche che accomunano servizi di dispositivi tali?
1. Tutti avranno uno stato interno:
a. Non alimentato perciò pure spento
b. Il dispositivo può essere alimentato ma spento
c. Alimentato e acceso ma non correttamente funzionante
d. Acceso e correttamente funzionante
2. Tutti avranno casse al di fuori del microfono…
a. Perciò si potrebbe pensare a disassemblare le parti dei dispositivi
i. Schermo
ii. Cattura video
25Puoi anche leggere
