Sistemi efficienti con autenticazione per TV Digitale

Transcript

1 Università degli studi di Ferrara FACOLTA DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica e dell Automazione Sistemi efficienti con autenticazione per TV Digitale Tesi di laurea di: ELISA BENETTI Relatore: Prof. Ing. GIANLUCA MAZZINI Anno Accademico 2007/2008 i

2 Desidero per prima cosa ringraziare il mio relatore, il Prof. Ing. Gianluca Mazzini per avermi assistita ed aiutata durante il periodo della tesi e per avermi dato l opportunità di collaborare con LepidaTV. Ringrazio chi, seppur così lontano, è sempre nel mio cuore. Ringrazio gli amici, che nonostante i miei periodi di assenza per lo studio, sono sempre stati al mio fianco ed hanno saputo aspettarmi, ed i colleghi che sono sempre stati un valido e sicuro sostegno nella mia vita universitaria. Grazie a mio padre, che c è sempre stato nel momento del bisogno. Grazie alle zie che mi hanno sempre sostenuta con slancio ed affetto. Infine, un ringraziamento particolare a mia madre che ha sempre creduto in me e, pur essendo di un pianeta totalmente diverso dal mio, per prima ha capito ed accettato le mie attitudini e mi ha spronata e sostenuta negli studi, ed in ogni altra mia scelta, tutti i giorni della mia vita. ii

3 Indice Introduzione TV digitale terrestre interattiva Struttura trasmissiva Il Transport Stream Service Information Tables Struttura delle tabelle SI Il protocollo DSM-CC Gli standard di trasmissione Lo standard MHP Standard di base Architettura Esecuzione delle applicazioni Pofili Enhanced Broadcasting Interactive Broadcasting Internet Access Il decoder interattivo Interattività forte e debole Xlet e piattaforme di emulazione Il software stack Le API JavaTV Ciclo di vita di una Xlet Contesto di applicazione Interfaccia grafica HAVi level 2 GUI Coordinate in MHP HScene e HsceneTemplate iii

4 Il set di widgets HAVi Il Controllo remoto Emulatori Open-Source XleTView Limiti riscontrati Meccanismi di autenticazione con bassa interattivi Modello standardizzato Scelta della bassa interattività e sue problematiche Ottimizzazioni Esempio di implementazione Accessibilità ed usabilità Implementazione della grafica Struttura dei file Funzionamento su Lepida TV OpenCaster PMT e AIT Tables Generazione di uno stream DSM-CC Multiplexing Messa in onda su LepidaTV Adattamento Web parallelo Conclusioni e sviluppi futuri Elenco delle figure Bibliografia e sitografia iv

5 Introduzione Negli ultimi anni è evidente come la tecnologia digitale stia prendendo il sopravvento su quella analogica portando ad un miglioramento della qualità offerta all utente grazie soprattutto alla compressione dei segnali ed alla riduzione del rumore presente. In questo contesto si inserisce il DVB (Digital Video Broadcasting): un insieme di standard aperti ed accettati a livello internazionale, atti allo sviluppo e la diffusione della televisione digitale. Nello specifico del nostro Paese lo switch-off da analogico a digitale si distribuirà nella varie regioni dall anno corrente fino al 2012, con una stima di 37 milioni di utenti digitali già nel Questa evoluzione tecnologica porterà ad avere ovviamente un miglioramento della qualità dell immagine, un aumento del numero di canali disponibili e soprattutto, novità su cui si basa questa tesi, l interattività, possibile tramite l introduzione della nuova tecnologia MHP (Multimedia Home Platform). Gli studi che verranno qui illustrati sono stati effettuati all interno di LepidaTV, canale digitale della Regione Emilia Romagna che punta a fornire ai cittadini molteplici servizi erogati da Comuni, Province, Enti Locali e Regione stessa. L'innovatività nei servizi offerti da LepidaTV consiste nel cercare una standardizzazione delle interfacce e soprattutto nella velocizzazione dell'accesso ai dati, al fine di consentire all utente una navigazione su un insieme di dati nettamente maggiore rispetto a quanto avviene nelle implementazioni tipicamente utilizzate. L interattività offerta si può definire debole in quanto Lepida TV non utilizza un canale di ritorno, ma scarica sul decoder dell utente tutte le informazioni disponibili dando all atto della navigazione una parvenza di interattività, per questo motivo la mole di dati da trattare risulta notevole. Nel primo capitolo si comincia quindi con una parte teorica che analizza la struttura del digitale terrestre. Più nello specifico è strutturato in tre parti: la prima si occupa della descrizione di un Transport Stream, la seconda tratta più in dettaglio il protocollo di trasporto DSM-CC, infine si prende invece 5

6 in considerazione lo standard MHP, la sua architettura ed i profili esistenti, soffermandosi sulle differenze tra interattività forte e debole. Nel secondo si introduce la descrizione di applicazioni interattive nel digitale terrestre partendo dal sistema sottostante ad esse, ovvero l ambiente Java e le specifiche API JavaTV e passando poi ad una breve descrizione delle funzionalità che tali applicazioni, chiamate Xlet, forniscono. L ultima parte del capitolo è dedicata invece all emulatore open source che abbiamo utilizzato per le applicazioni MHP, XletView spiegandone le caratteristiche principali ed i limiti da noi riscontrati. Nel terzo si comincia ad illustrare il serivzio implementato, partendo dalla scelta di un modello standardizzato e le soluzioni adottate per ottimizzare le tempistiche di navigazione. Nel quarto vi sono invece una parte dedicata alla struttura dei file ottimizzata per la navigazione di grandi quantità di contenuti, ed un'altra sulle scelte grafiche dovute all obiettivo di Lepida TV di offrire usabilità ed accessibilità, avendo come utenti un target ampio come può essere quello di tutti i cittadini della Regione: dalla casalinga al giovane, dall anziano a chiunque si trovi ad avere più familiarità con il televisore piuttosto che con il Web. Nel quinto ed ultimo capitolo si parte con una breve panoramica del funzionamento del software open source OpenCaster, per spiegare poi come grazie a questo, sono state effettuate le messe in onda dei servizi su LepidaTV. 6

7 Capitolo 1 Aspetti tecnici della TV digitale Per comprendere il funzionamento della tv digitale terrestre è necessario dapprima capire come il segnale viene gestito al fine di contenere sia il flusso audio/video che i dati necessari alle applicazioni interattive. 1.1 Struttura trasmissiva La struttura trasmissiva di un sistema broadcast digitale può essere schematizzata come in figura 1.1. In questa struttura tramite un encoder il segnale analogico viene convertito in uno digitale con formato MPEG-2, chiamato transport stream. Lo stream creato può essere di due tipologie: la prima a constant bit rate, in cui si ha appunto bit rate costante: in caso il segnale risulti troppo complesso per essere codificato nel bit rate specifico viene ridotta la qualità, in caso contrario vengono aggiunti invece pacchetti nulli fino al raggiungimento del bit rate corretto, sprecando però così la banda a disposizione. La seconda tipologia è invece a bit rate variabile in cui la banda utilizzata varia in base alla complessità del segnale. Figura 1.1: Struttura trasmissiva del sistema digitale terrestre 7

8 In seguito un multiplexer prende uno o più stream MPEG e li associa in un singolo transport stream occupandosi di inserire un insieme di servizi all interno della banda prefissata a disposizione della rete. I segnali digitali così ottenuti non possono essere trasmessi direttamente ma devono prima essere modulati e poi convertiti in segnali analogici per trasmetterli usando segnali radio o segnali elettrici su cavo. Un modulatore produce quindi un segnale analogico dato un transport stream in ingresso modulando il segnale a bassa frequenza per poi farlo convertire ad alta frequenza da un upconverter e passarlo al sistema di trasmissione composto da trasmettitore ed antenna. 1.2 Il Transport Stream Il segnale digitale televisivo è trasmesso come uno stream di dati MPEG-2, chiamato transport stream. Ogni transport stream ha un tasso di dati superiore a 24 Mbit/s, sufficiente per 7/8 canali televisivi distinti. Inoltre è composto da un insieme di sotto-stream, chiamati elementary stream, ognuno dei quali può contenere o una traccia audio codificata MPEG-2, o una traccia video MPEG-2 o dati incapsulati in uno stream MPEG-2. Ogni stream elementare ha un identificativo di pacchetto, conosciuto come PID, che lo identifica univocamente all interno del transport stream. Non possono quindi due elementary stream all interno dello stesso flusso di trasporto avere il PID uguale: questo non è un problema grave dal momento che il PID è formato da 13 bit e vi sono quindi 2 13 PID diversi da poter assegnare. La generazione di un flusso di trasporto avviene multiplexando più flussi elementari: per prima cosa si codificano l audio e il video separatamente e in seconda istanza vi si aggiunge la parte contenente i dati delle applicazioni. I vari flussi generati sono poi suddivisi in transport packet, dove ogni pacchetto è lungo 188 byte: il multiplexer prende quindi questi pacchetti e li inserisce nel transport stream. Con questo meccanismo si ottiene un transport stream finale contenente un certo numero di elementery stream senza però indicare quali tipi di dati vengono trasportati, né come ricostruire tali stream nel ricevitore. Per risolvere questo problema vengono quindi aggiunte in fase di multiplexing altre informazioni sottoforma di 8

9 ulteriori stream elementari per fornire informazioni di servizio, chiamati infatti service information. Questi non sono altro che tabelle, ognuna delle quali descrive un servizio contenuto nel transport stream indicando gli elementary stream che formano un servizio, i PID degli stream ed i tipi di dati contenuti. Figura 1.2: Struttura di un transport stream L utilizzo di queste tabelle è molto vantaggioso in quanto porta ad un possibile riuso dello stesso elementary stream in servizi diversi. Figura 1.3: Suddivisione del transport Stream in più servizi diversi Riassumendo quindi lo schema, come si può vedere in figura 1.3, uno stream di trasporto è un flusso MPEG-2 che contiene numerosi servizi, ogni servizio è legato ad un singolo canale televisivo ed è formato da una 9

10 serie di eventi consecutivi, ogni evento è uno spettacolo televisivo ed è formato da più stream elementari che sono composti a loro volta da dati, audio e video codificati in MPEG-2. La figura 1.4 invece mostra un transport stream reale, ripreso da un transport stream analyzer. Nelle prima colonna indica il tipo di stream, la seconda il PID associato a ciascun flusso elementare, ed infine il bit rate per ciascun stream elementare, sia in forma grafica che numerica, in Mbit/s. Figura 1.4: Esempio di Transport Stream Analyzer Oltre al raggruppamento fisico appena descritto, i servizi vengono raggruppati anche in modo logico tramite un bouquet, che permette di suddividere i servizi in modo da indirizzarli solo a chi ha determinato privilegi, vediamolo con un esempio. Un broadcaster deve trasmettere 30 canali, essendo il transport stream limitato a 40 Mb/s, gestendo quindi circa 7/8 canali, serviranno 4 transport stream per trasmetterli tutti. Supponiamo quindi che un utente possa acquistare, ad esempio, un pacchetto base di 10 canali, un pacchetto di sport con 5 canali tematici, o un pacchetto cinema da 3 canali. Il pacchetto base comprende troppi canali per essere contenuto interamente nello stesso transport stream, si comprende quindi come l idea 10

11 di identificare un pacchetto in base al transport stream di appartenenza sia fallimentare. Per questo motivo si è pensato invece di raggruppare i canali in bouquet logici ed assegnare un bouquet ad ogni pacchetto. 1.3 Service Information Tables Come spiegato in precedenza le service information sono flussi elementari speciali che contengono un database, diviso in tabelle, che descrive la struttura dello stream di trasporto ed i servizi. Alcune tabelle descrivono i servizi specifici contenuti nel transport stream, mentre altri, più generali, descrivono la struttura del transport stream stesso. In alcuni casi questi particolari elementary stream vengono trasmessi con un PID fissato così da rendere più facile la loro ricerca ai decoder, in altri casi i PID delle SI sono memorizzati in un altra tabella SI. Le tabelle che si trovano in un flusso si trasporto DVB sono le seguenti: PAT (Program Association Table): è una tabella fondamentale, l unica che viene trasmessa con PID fisso e descrive la quantità dei servizi contenuti nel transport stream indicando per ognuno di essi un riferimento alla tabella PMT che ne elenca i componenti elementari; PMT (Program Map Table): contiene l elenco degli elementi che compongono un servizio. In base alle informazioni in essa contenute, il decoder individua in quali pacchetti del transport stream sono contenuti il video, l audio e gli elementi aggiuntivi da mostrare sullo schermo. Il PMT non viene trasmesso con un PID prefissato ed esiste un PMT per ogni servizio contenuto nel transport stream; NIT (Network Information Table): identifica il transport stream contenuto nella frequenza sintonizzata e riporta informazioni che si riferiscono alle proprietà fisiche del canale di trasmissione utilizzato. Contiene inoltre il nome del Network ed il relativo ID, che identifica univocamente la rete che trasmette lo stream di trasporto, e può differire dall ID della rete originale in caso il flusso sia ritrasmesso. SDT (.Service Description Table): contiene informazioni che descrivono i servizi trasmessi nel transport stream. A differenza della PMT esiste un'unica SDT interna ad uno stream di 11

12 trasporto.tipicamente contiene il nome del servizio, il relativo ID e lo stato del servizio stesso. EIT (Event Information Table): contiene le informazioni che descrivono i singoli programmi trasmessi sui servizi della tv digitale terrestre, come ad esempio il nome dello spettacolo, la durata, ora e inizio. CAT (Conditional Access Table): contiene informazioni che consentono, all utente che ne ha il diritto, di visualizzare correttamente i programmi criptati. BAT (Bouquet Association Table): elenca e descrive i canali e i servizi che sono raggruppati in base a particolari esigenze. TDT (Time Definition Table) e TOT (Time Offset Table): forniscono un riferimento temporale per lo stream. La TDT contiene l ora corrente al meridiano zero, mentre TOT contiene l offset per avere l ora locale. AIT (Application Information Table): Tabella extra, definita da MHP segnala la presenza di un applicazione interattiva all interno del transport stream, e contiene le informazioni necessarie al decoder per eseguire l applicazione ed avvisare l utente della sua disponibilità. Avrà quindi una voce per ogni applicazione presente per quel servizio e comprenderà: un identificatore univoco formato da organization ID, a 32 bit, unico per ogni organizzazione che produce applicazioni MHP e application ID di 16 bit. Vi è inoltre uno status indicator che indica se l applicazione deve essere avviata automaticamente quando viene selezionato il servizio, se deve essere terminata automaticamente da un ricevitore, o se un utente può avviarla manualmente. Infine l application local descriptor identifica l object carousel che contiene l applicazione Struttura delle tabelle SI La struttura della varie tabelle SI risulta abbastanza simile, formata da un header seguito da zero o più descrittori i quali referenziano le informazioni a loro attribuite in una determinata riga del database. I descrittori sono soggetti ad un riuso che li fa quindi comparire in diversi tipi di tabella, rendendo così più semplice l analisi delle informazioni. 12

13 I descrittori più usati sono quelli qui di seguito illustrati: service_descriptor: nella SDT identifica il nome ed il tipo di servizio. linkage_descriptor: allocato in diverse tabelle, fornisce riferimenti ad altre informazioni su un elemento inerente alle SI, come ad esempio un link ad un canale televisivo che prende le veci di un secondo servizio bloccato. component_descriptor: nella EIT procura informazioni che riguardano il flusso elementare, come ad esempio il tipo, il formato, e nel caso di uno stream audio, la lingua. data_broadcast_id_descriptor: si trova nella PMT e contiene informazioni sul tipo di codifica utilizzata da uno stream dati. stream_identifier_descriptor: anch esso nella PMT, serve per attribuire un tag ad uno stream elementare al fine di indentificarlo univocamente. CA_identifier_descriptor: compare in varie tabelle ed identifica il sistema di cifratura quando questo è presente. 1.4 Il protocollo DSM-CC Il DSM-CC, ovvero Digital Storage Media Command and Control, è uno standard per la trasmissione di dati basato sullo stream MPEG, e viene usato per trasmettere le applicazioni ai ricevitori, fornendo un controllo dei server video MPEG in una rete con play, stop e pausa di un video o audio. I sistemi broadcast sono di natura unidirezionale: questo indica che un ricevitore non può richiedere un file specifico dal server, come avviene invece per i PC. Come soluzione il broadcaster trasmette periodicamente ogni file del filesystem, ed il ricevitore resta in attesa per quelli che gli interessano, esattamente come avviene per il teletext attuale: le pagine sono identificate dal loro numero univoco e vengono trasmesse continuativamente in rotazione, quando l utente seleziona un numero di pagina la televisione attende che la pagina venga trasmessa, per poi decodificarla e visualizzarla. Questo tipo di soluzione è chiamata carousel. Il DSM-CC supporta due tipo di carousel. Il primo, data carousel, consiste in una serie di moduli in cui ognuno contiene un dato come un file, il 13

14 modulo può essere diviso a blocchi per facilitarne la trasmissione. Questo va bene per il teletext o una applicazione molto semplice ma non fornisce informazioni sulla natura dei dati e per le applicazioni MHP `e un grande problema, poiché è importante conoscere la struttura dei file e delle directory per distinguere il codice delle applicazioni dalle risorse. La seconda tipologia è l object carousel che è costruito in cima ad un modello data carousel estendendolo con il concetto di file, directory e stream, permettendo ad un carousel di contenere un vero e proprio filesystem ed un insieme di directory. Ogni object carousel consiste in un directory tree, suddiviso in una serie di moduli, ognuno dei quali è di dimensione 64 KB e può contenere uno o più file. Non è permesso inserire file in un modulo per dimensione superiore a 64 KB, né suddividere i file in più moduli, così se si ha un file di dimensione maggiore a 64 KB, deve essere inserito in un proprio modulo, che conterrà solo quel file. I file contenuti in un modulo non devono appartenere alla stessa directory ma possono provenire da qualsiasi parte dell albero. Ad esempio, supponiamo di voler trasmettere la seguente struttura di figura 1.5: Figura 1.5: Esempio di file da trasmettere in un carousel Per prima cosa inseriamo in un modulo i primi due file index.html e image1.jpg, non possiamo aggiungervi anche il terzo, image2.jpg in quanto la grandezza del modulo supererebbe i 64 KB. Si può invece aggiungere il file clip1.aiff ed aggiungere l annotazione della directory audio senza causare problemi. Il file image2.jpg è più grande di 64 KB e viene inserito 14

15 in un modulo a parte. Infine i file contenuti nella directory classi vanno suddivisi in due moduli non potendo rientrare tutti nello stesso: per prima cosa inserendo la entry della directory e poi aggiungendo più file possibili. In questo caso aggiungeremo Main.class e Other.class, mentre Big.class sarà inserita in un ultimo modulo. Figura 1.6: Trasmissione dei moduli I moduli vengono quindi trasmessi sequenzialmente uno dopo l altro, per poi ricominciare dal primo e per accedere ad un file il ricevitore deve aspettare che arrivi il modulo contenente il file che gli serve: questo può essere poco efficiente se la mole dei dati inviati è grande. Per questo motivo molti ricevitori hanno una cache che memorizza file singoli o moduli interi. Inoltre quando si trasmette un DSM-CC carousel, si possono trasmettere i moduli più di una volta, come si può vedere in figura 1.6: in questo modo si può ridurre il tempo di accesso ai file più utilizzati, ovviamente a discapito di quelli meno usati che avranno un tempo di ricezione maggiore, dal momento che il carousel avrà un incremento della dimensione totale. 15

16 1.5 Gli standard di trasmissione Creato il transport stream, questo deve ovviamente essere inviato in qualche modo ai vari Set Top Box. Per quanto riguarda la trasmissione dei programmi televisivi mediante segnali digitali, il consorzio DVB ha sviluppato tre classi standard diverse, le cui differenze si basano soprattutto sul mezzo attraverso il quale passa il contenuto informativo: DVB-S: questo standard viene utilizzato per le trasmissioni digitali satellitare (non solo TV ma anche internet via satellite). Per la ricezione, oltre al Set Top Box, è quindi richiesta un antenna parabolica. DVB-C: in questo caso invece lo standard prevede l utilizzo di una fibra ottica per la creazione di reti televisive su cavo. La realizzazione di queste reti presenta diffivoltà dal punto di vista topografico ( difficile infatti raggiungere alcune particolari zone del territtorio come quelle montane) e finanziarie, essendo molto alto il costo per la costruzione di una rete televisiva di questo tipo. DVB-T: è lo standard per le trasmissioni digitali terrestri, rilasciato fin dal Utilizza le frequenze VHF/UHF e permette di trasmettere dai 4 ai 7 canali digitali dove adesso può transitare un solo canale analogico. Questo sistema di trasmissione è il più diffuso in quanto permette di riutilizzare le vecchie antenne usate per la ricezione dei canali analogici, per cui l utente dovrà solamente fornirsi un Set Top Box per la decodifica del segnale digitale. Figura 1.7: I tre standard DVB D ora in poi verranno trattate le tecnologie che permettono l implementazione di servizi interattivi (MHP) nella distribuzione del segnale digitale per via terrestre (DVB-T). 16

17 1.6 Lo standard MHP MHP, ovvero Multimedia Home Platform è uno standard molto giovane rilasciato dal DVB project nella sua prima versione nel DVB ha prodotto un insieme di specifiche che definiscono una piattaforma middleware e da qui si è definita l interoperabilità tra le applicazioni interattive ed i terminali su cui possono essere eseguite. Durante la creazione del pacchetto MHP, il DVB Project ha scelto di utilizzare Java per il core del middleware così da permettere ai fornitori di servizi di poter sviluppare, seguendo lo standard DVB-MHP, i propri servizi in modo indipendente dal sistema di ricezione sottostante. Infine, c è da notare come alcuni elementi di MHP vengano forniti da altre organizzazioni: per esempio le applicazioni java si basano sulle API JavaTV, mentre per l interfaccia grafica vengono utilizzate le API HAVI. Figura 1.8: Set top box MHP Standard di base Lo standard di base specifica in quale ambiente si possono eseguire le applicazioni per la tv interattiva digitale, indipendentemente da hardware e software sottostant, ed è definito dalla specifica MHP 1.0 che contiene: l architettura di base dell MHP, informazioni dettagliate sui profili Enhanced Broadcasting ed Interactive TV, profili che tratteremo più avanti, diversi formati contenuti in MHP tra cui JPEG e MPEG-2 video e audio, protocolli di trasporto, compreso DSM-CC per la trasmissione 17

18 broadcast e IP per il canale di ritorno eventuale, modelli di applicazione DVB-J e DVB-HTML, allegati al profilo DSM-CC, una presentazione testuale e varie API. In un secondo momento è stata rilasciata la specifica MHP 1.1, per implementare il profilo Internet Access, e contiene: informazioni dettagliate sui profili Interactive TV ed Internet Access, la disponibilità di immagazzinare le applicazioni nella memoria persistente, download delle applicazioni mediante i canali broadcast o di interazione, estensioni al DVB-J per supportare meglio le applicazioni e l accesso a lettori di smart card non certificati, supporto per la gestione di plug-in interoperabili supporto per i riferimenti bidirezionali tra il contanuto di MHP ed il contenuto Internet Architettura L architettura base della piattaforma MHP è strutturata su tre livelli: Figura 1.9: I livelli dell architettura MHP Resources: Le risorse e periferiche dell MHP sono standardizzate solo in parte allo stato attuale. Tra le risorse hardware abbiamo: sintonizzatore, demodulatore hardware MPEG, moduli di accesso 18

19 condizionato, gestione della grafica, processore, memorie, hard disk. Tra le periferiche: telecomando, lettore DVD, smart-card. System Software: il software di sistema ha accesso diretto alle informazioni dello stream audio-video in modo conforme agli standard MPEG2 e DVB. Gestisce inoltre le risorse hardware e le periferiche. Questo livello strutturale include: una macchina virtuale Java (JVM), pacchetti software con funzioni generali (nucleo con API Java di Sun) e con funzioni specifiche (Java TV API,DAVIC e HAVI), un application manager responsabile della gestione del ciclo di vita delle applicazioni e i protocolli di trasporto DVB. Applications: sono l interfaccia tra un servizio interattivo e il display di visualizzazione e si dividono in 3 categorie: o residenti: specifiche del decoder costituiscono una differenziazione dei terminali ed un motivo di competizione commerciale tra i produttori, o installabili: offerte dagli operatori di servizi per arricchire il bouquet proposto, sono applicazioni che integrano il funzionamento di quelle residenti, o scaricabili, sono facoltative e conformi allo standard, anch esse offerte dagli operatori per l arricchimento del bouquet. Figura 1.10: L architettura MHP 19

20 1.6.3 Esecuzione delle applicazioni MHP offre la possibilità di implementare applicazioni come: EPG (Electronic Program Guide), servizi informativi come il super teletext, servizi interattivi come la navigazione vincolata o la navigazione aperta su internet, e servizi transattivi come e-commerce. Nello standard MHP queste applicazioni si chiamano Xlet e possono contenere solo tipologie spicifiche di dati: classi java, file xml o txt, immagini png, jpg o gif, audio mp2 e video mpg. Il middleware del ricevitore contiene un application manager che gestisce il monitoring dei servizi e la gestione delle applicazioni, segnalando all utente la lista delle applicazioni MHP disponibili su quel canale televisivo. Prima che sia possibile eseguire l applicazione l application manager deve sapere se è disponibile un applicazione MHP e se l utente ha il permesso di eseguirla in quel dato momento, infine deve poter accedere alle risorse necessarie all applicazione come i file class e i dati. Quando l utente seleziona una applicazione dalla lista di quele disponibili, l application manager inizia il download in memoria dei moduli relativi all applicazione scelta, partendo dallo scaricare quelli necessari alla pertenza dell Xlet, per poi scaricare, solo se necessari, quelli rimanenti. I soggetti che partecipano allo scenario della trasmissione dei segnali digitali e delle applicazioni sono: Content Producer: elabora le applicazioni MHP. Broadcaster: si occupa della diffusione dei canali televisivi e della aggregazione delle applicazioni interattive. Operatori di rete MHP: in alcuni casi, ad esempio nella trasmissione satellitare, l operatore di rete non coincide con il broadcaster, quindo l operatore aggrega le applicazioni prima della trasmissione. Venditore dei terminali MHP: il set top box è il terminale su cui le applicazioni MHP vengono eseguite Profili Lo standard MHP prevede tre profili, che si riferiscono ognuno ad un area applicativa e quindi sono legati alle capacità dei set top box. Ogni profilo è 20

21 a sua volta diviso in due profili evolutivi. Per ogni profilo sono richieste determinate dotazioni hardware di cui la piattaforma deve obbligatoriamente disporre, ed altre invece che sono raccomandate o opzionali. Varia di conseguenza anche la presenza delle interfacce software necessarie a gestire tali periferiche. Figura 1.11: I profili MHP Enhanced Broadcasting Questo è il profilo base che è stato progettato al fine di mostrare le funzionalità del sistema middleware esistente e le applicazioni possibili da eseguire. Permette servizi di arricchimento del contenuto audio-video come contenuti multimediali, EPG, super teletext, e giochi, che vengono memorizzati nella memoria del terminale dell utente. Per questo profilo non sono quindi richieste prestazioni elevate nel set top box, è necessario essere provvisti di un accesso al canale di trasmissione broadcast mentre la presenza di un canale di ritorno è opzionale. Comprende la Java virtual machine, le API Java DVB, i protocolli di trasporto broadcast e le opzioni HTML. 21

22 Interactive Broadcasting Questo è un profilo intermedio che tramite un canale di ritorno obbligatorio, è in grado di fornire servizi multimediali interattivi più complessi, come la pubblicità interattiva, le transazioni (home-banking, e- commerce). I servizi interattivi possono essere indipendenti o meno dai contenuti trasmessi in broadcast, permettendo anche di rendere i contenuti, ricevibili da tutti gli utenti, accessibili solo da che ne possiede l autorizzazione. In questo profilo la navigazione Internet è implicita, ciè trasparente all utente in quanto codificata all interno delle applicazioni. Le applicazioni possono essere scaricabili o residenti, e in quest ultimo caso sono implementate in modo proprietario. Figura 1.12: Schematizzazione di una catena DTT interattiva Alcuni di questi servizi potrebbero anche richiedere che le applicazioni software abbiano accesso ad una o più smart-card, connesse tramite un lettore embedded nel terminale MHP. Per fornire il canale interattivo sul set top box sono possibili due modalità: tramite modulo di rete integrato o modulo di rete esterno. In quest ultimo caso la connessione tra il modulo di rete ed il set top box è realizzata tramite In Home Digital Network, che permette l utilizzo di interfacce stabdard quali Ethernet, Wi-fi o Bluetooth. 22

23 Internet Access Quest ultimo profilo è ancora più complesso e permette, tramite il canale di ritorno, di accedere ai contenuti di Internet e consentirà di effettuare transazioni commerciali sfruttando i protocolli di sicurezza già sviluppati per Internet. Si può quindi dire che Internet Access rappresenti il vero punto di convergenza tra le tecnologie informatiche e quelle televisive. L integrazione dei sistemi di accesso condizionato con la piattaforma può essere realizzata: Dal costruttore della stessa che quindi, concordandosi con gli operatori dei servizi, individua anche il sistema da integrare, Dall operatore del servizio televisivo interessato, se il costruttore ha introdotto nel proprio apparato il dispositivo standard di Interfaccia Comune. Le applicazioni possono quindi controllare le operazioni basilari dei client residenti su Internet, come web browser ed . Per rendere possibili le funzionalità descritte ed integrare il formato applicativo DVB-J, lo standard MHP 1.1 ha definito un nuovo nuovo tipo di applicazione opzionale: DVB-HTML, che è un linguaggio di mark-up basato su HTML e permette ad un ricevitore di presentare le applicazioni della tv interattiva digitale in HTML. Le specifiche DVB-HTML presentano le stesse estensioni e restrizioni delle specifiche del linguaggio W3C esistente Il decoder interattivo Per ricevere i segnali digitali del DTT, è necessario quindi avere un decoder, anche chiamato Set top Box da collegare alla presa d antenna ed al televisore tramite una normalissima presa SCART. Tramite questo dispositivo si può innanzitutto decodificare il segnale da digitale ad analogico per gli apparecchi televisivi analogici, ed inoltre si possono eseguire applicazioni Java grazie alla presenza di una Personal JVM embedded. Come mostrato in figura 1.13 questo decoder è formato da una parte hardware (Cpu, memoria, modem), da un sistema operativo e da una interfaccia MHP. 23

24 Figura 1.13: Schematizzazione della struttura di un Set Top Box Più nello specifico dal segnale ricevuto e demodulato si ottiene uno stream binario che viene elaborato dalla circuiteria digitale, l elaborazione del segnale digitale viene in seguito effettuata mediante un microprocessore ed il software ad esso associato. Ogni funzionalità implementata dal ricevitore è controllata via software. Questo software di gestione può inoltre essere aggiornato da remoto permettendo il miglioramento delle funzioni già comprese e l inclusione di nuove funzionalità. Il modello base di Set Top Box è un semplice ricevitore digitale con possibilità di organizzare le liste dei programmi ed accedere al teletext. I Set Top Box con funzioni avanzate invece si suddividono in tre categorie: Livello 1: dotato di interattività locale, cioè con la possibilità di scaricare dall etere le applicazioni con le quali l utente può agire con il telecomando. Livello 2: offrono invece funzionalità multimediali di tipo interattivo mediante l utilizzo del canale di ritorno Livello 3: è provvisto di interattività avanzata, cioè l accesso al World Wide Web, e di diversi optional come videoscrittura, videocamera e microfono A livello 2 e 3 è necessario quindi un collegamento tra il decoder dell utente e quello che viene chiamato Centro Servizi. In questo centro Servizi vengono svolte le seguenti principali operazioni: 24

25 Gestione del traffico di richieste provenienti dagli utenti Dialogo con il broadcaster Dialogo con i server del fornitore dei servizi Trasformare l informazione dalla codifica idonea al Set top Box alla codifica idonea al server del fornitore di servizi Ricevere ed inviare informazioni ad ogni utente connesso Figura 1.14: Modello delle relazioni nella catena DTT Tutte queste richieste di interazione vengono verificate da opportuni componenti presenti nel Centro Servizi che, se necessario, si occuperanno in seguito di reperire i dati richiesti dall utente dai Service Provider, secondo modalità concordate tra le parti. Come ultimo step il Centro Servizi provvederà poi ad inviare queste informazioni verso l utente finale. Vediamo ora più approfonditamente le differenze che intercorrono tra un interattività che sfrutti il canale di ritorno ed una in cui questo non sia invece utilizzato Interattività forte e debole Da ciò che abbiamo appena visto si può quindi dedurre che i servizi interattivi per il digitale si suddividono in due grandi tronconi a seconda 25

26 che sia o meno utilizzato il canale di ritorno. Il canale di ritorno consiste in un collegamento fra il box interattivo ed il centro servizi, e può essere eseguito mediante la linea telefonica PSTN (scelta attualmente utilizzata dalla totalità dei decoder in commercio), un collegamento di tipo ADSL o un collegamento mediante rete mobile. Vediamo quindi le due tipologie di interattività che si possono sviluppare: Interattività forte: queste applicazioni ricadono nel profilo precedentemente illustrato dell Interactive Broadcast, e per queste DVB ha definito protocolli di comunicazione ed interfaccia con la rete in grado di assicurare l elevata affidabilità che questi servizi richiedono. Si può notare come, dovendo il contenuto essere fruito solamente nell istante in cui viene richiesto, non è rilevante l aspetto riguardante la capacità di memorizzazione del decoder o la presenza di un data carousel con ciclo di vita breve. L interazione on-line dell utente con il fornitore di contenuti consente quindi una maggiore libertà nella creazione di nuove tipologie di servizi, a discapitò però di sicurezza e semplicità. Interattività debole: dove non è invece presente il canale di ritorno, il telespettatore può accedere a un servizio attraverso un applicazione con interattività locale. Utilizzerà cioè una serie di contenuti trasmessi ciclicamente mediante il data carousel. Queste applicazioni possono essere sfruttate al momento o memorizzate nel decoder per essere utilizzate successivamente, navigando al loro interno. Nel caso il Set Top Box disponga di memoria di massa elevata è anche possibile introdurre servizi basati sul caricamento via etere, o downloading, di elevate quantità di dati. Questa seconda tipologia di servizi ricade quindi all interno del profilo Enhanced Broadcasting. 26

27 Capitolo 2 Le applicazioni per MHP: le Xlet Per comprendere come sia possibile creare un apllicazione interattiva, dobbiamo prima esaminare le API Java su cui MHP si basa, e in cosa consiste più nello specifico una Xlet. 2.1 Il software stack Il software stack MHP è molto complesso. Uno degli aspetti più importanti delle API MHP è che molte di loro possono essere costruite su altre API e questo permette un approccio modulare nella costruzione del software. Figura 2.1: Schematizzazione delle API che compongono lo stack MHP Le API possono essere suddivise in due parti, una delle quali si occupa dei servizi relativi agli stream MPEG, l altra fornisce servizi costruiti direttamente le API pjava. La principale differenza sarà che le API del primo tipo saranno legate più strettamente alla piattaforma hardware sottostante. Il core delle API che si occupano dell MPEG sono le API section filtering, tutte le altre API riguardanti MPEG sono costruite sopra queste. Le API DSM-CC analizzano le sezioni DSM-CC ed utilizzano le API SI, service information, per cercare nelle tabelle SI quali stream in un servizio contengono gli object carousel DSM-CC. Le API tuning, sempre tramite le 27

28 API SI, individuano il transport stream che deve essere visualizzato cosi da potersi sintonizzare su quello corretto, analogamente le API JavaTV service selection cercano il servizio che deve essere sintonizzato. Infine le API service selection usano le API application management per terminare le applicazioni quando viene selezionato un nuovo servizio o viene distrutto un service context. Passando alle altre API dobbiamo dire innanzitutto che date le differenze tra MHP e le normali implementazioni Java, sono necessari dei cambiamenti rispetto all AWT conosciuto: ad esempio, la maggior parte dei widget awt sono stati rimossi in quanto la piattaforma MHP non richiede un window manager. Le API HAVi sono costruite su AWT, quindi molte classi in Havi sono sottoclassi in AWT, inoltre sono stati aggiunti nuovi elementi, come ad esempio HScenes. Le API DVB UI, nella maggior parte dei casi estendono semplicemente le funzionalità di AWT. Per ultime le API UI events reindirizzano l input event al normale processo di gestione degli eventi di AWT. 2.2 Le API Java TV Queste API di Sun hanno sicuramente un ruolo fondamentale e forniscono un set di classi ed interfacce per sviluppare servizi interattivi della telecisione digitale utilizzando il linguaggio di programmazione Java. Il loro scopo è quello di accedere alle funzionalità dei ricevitori digitali quali lo streaming audio e video, l accesso ai canali dati, i controlli per cambiare canale e quelli per l interfaccia grafica sul televisore. Forniscono inoltre alcune importantissime funzionalità addizionali come la sincronizzazione dei media, che permette ai contenuti interattivi di sincronizzarsi con l audio-video di un programma televisivo, ed il controllo del ciclo di vita delle applicazioni. Le API Java TV permettono ai programmatori di non occuparsi dei dettagli specifici dell hardware sottostante e si differenziano dallo standard MHP in quanto non sono vincolate ai sistemi DVB per la TV digitale. Sono composte da un insieme di pacchetti Java, il più importante dei quali è appunto javax.tv.xlet che contiene le classi necessarie a gestire il ciclo di vita delle Xlet. 28

29 Le Xlet, anche chiamate abblicazioni DVB-J, sono quindi particolari applicazioni scritte in Java che consistono in un insieme di classi trasmesso in broadcast. Sono molto simili alle applet: come queste infatti, permettono ad un software specifico esterno, nel caso MHP l application manager, di controllarne il ciclo di vita, ma la differenza più grande è che un Xlet, al contrario di un applet, può essere messa in pausa ed essere riavviata in un secondo momento. Le interfacce fondamentali da utilizzare sono java.tv.xlet.xlet e java.tv.xlet.xletcontext, che verranno ora analizzate più nello specifico Ciclo di vita di una Xlet Una Xlet di fatto implementa i 4 metodi presenti in java.tv.xlet.xlet: initxlet che viene invocato dall application manager per inizializzare l Xlet; startxlet che serve per eseguire l Xlet; pausexlet per mettere in pausa l Xlet; destroyxlet invocata dall application manager alla terminazione dell Xlet. Figura 2.2: Ciclo di vita di un Xlet Il ciclo di vita di una Xlet infatti è caratterizzato da 4 stati: Loaded: Xlet creata ma ancora non inizializzata. Se avviene un eccezione in questa fase, passa allo stato di Destroy. Una Xlet si trova in questo stato una sola volta nel suo ciclo di vita. 29

30 Paused: L Xlet è inizializzata e può trovarsi in questo stato sia dopo che il metodo initxlet ritorna con successo dallo stato Loaded, sia dopo che il metodo pausexlet ritorna con successo dallo stato Active. Active: L Xlet è attiva e utilizza le risorse che le servono per fornire i suoi servizi. Destroyed: L Xlet si predispone alla sua terminazionerilasciando tutte le risorse in suo possesso. L esempio di una tipica sequenza di ciclo di vita è il seguente: 1. L applicazione si trova nello stato Loaded dopo che l application manager ha caricato la classe principale della Xlet, segnalata dal broadcaster, e ne ha creato un istanza. 2. Quando l utente, o un altra Xlet, avvia questa Xlet, l application manager invoca il metodo initxlet e dopo l inizializzazione l Xlet si trova nello stato Paused, pronta per essere eseguita. 3. L application manager quindi invoca startxlet segnalando il passaggio dell Xlet dallo stato Paused allo stato Active. 4. Durante l esecuzione può essere invocato il metodo pausexlet che fa passare da Active a Paused l Xlet. Questa tornerà allo stato Active dopo l invocazione di startxlet, e ciò può accadere svariate volte nella vita di un Xlet. 5. Alla fine del ciclio di vita. L application manager invoca destroyxlet, con cui l Xlet passa allo stato Destroyed, liberando tutte le risorse, e a questo punto non può più essere richiamata Contesto di applicazione Ogni Xlet ha un contesto di applicazione, chiamato XletContext che è un istanza della classe javax.tv.xlet.xletcontext che prevede i seguenti metodi: notifydestroyed; notifypaused; getxletproperty; resumerequest. 30

31 I primi due metodi notifydestroyed e notifypaused permettono ad una Xlet di notificare al decoder che l applicazione sta per terminare o per mettersi in pausacosì che il ricevitore possa conoscere lo stato di ogni applicazione e possa effettuare le azioni appropriate. Questi metodi devono essere richiamati immediatamente prima che l Xlet entri negli stati Paused o Destroyed, per evitare che il ricevitore possa effettuare alcune operazioni per le quali l applicazione non è pronta. Per passare dallo stato Paused allo stato Active l Xlet può usare il metodo resumerequest, che richiede che un applicazione venga fatta partire nuovamente, anche se il software del ricevitore potrebbe scegliere di ignorare questa richiesta a causa di limiti nelle risorse. Il metodo getxletproperty permette alla Xlet di accedere alle proprietà segnalate dal broadcaster. Allo stato attuale è stata definita una sola proprietà da JavaTV e da MHP, XletContext.ARGS, che permette ad un applicazione di accedere agli argomenti che le vengono segnalati tramite AIT. Analizziamo ora con un esempio cosa succede quando una Xlet chiede di cambiare il proprio stato tramite l Xlet context, considerando una Xlet che voglia mettersi in pausa e successivamente richieda di riavviarsi. 1. Innanzitutto, l Xlet notifica al suo Xlet context che si è messa in pausa, invocando il metodo XletContext.notifyPaused(). 2. L Xlet context inoltra questa informazione all application manager presente nel middleware. 3. L application manager aggiorna il suo stato interno per notificare che l applicazione si è messa in pausa, quindi l Xlet si ferma. Figura 2.3: Dialogo tra applicazione e context per la messa in pausa 31

32 4. Quando un applicazione vuole riavviare le operazioni, ad esempio perché è passato un certo tempo prefissato oppure perchè l utente ha premuto un tasto, viene richiamato dalla Xlet il metodo XletContext.requestResume(). 5. Come accaduto in precedenza, l Xlet context passa tale richiesta all application manager. 6. L application manager può quindi decidere se riavviare l applicazione oppure no. Se la riavvia, aggiorna il proprio stato interno per notificare il cambiamento, quindi chiama il metodo startxlet() sulla Xlet: come tutte le altre operazioni che controllano il ciclo di vita della Xlet, questo metodo viene richiamato direttamente dall application manager e non attraverso l Xlet context. 7. Infine l Xlet riavvierà le proprie operazioni. Figura 2.4: Dialogo tra applicazione e context per il riavvio Il costruttore della classe principale di ogni Xlet deve essere lasciato vuoto: quando il middleware avvia un applicazione, all inizio crea un istanza della classe principale. In questo modo invoca il costruttore di default, se esiste, ed esegue il codice contenuto. In realtà una Xlet possiede un altro metodo che deve essere usato per questo tipo di setup: il metodo initxlet(), che permette un controllo migliore delle operazioni. Tutte le inizializzazioni devono essere fatte nell implementazione di questo metodo. Durante l inizializzazione, se qualcosa fallisse verrebbe lanciata un eccezione, passando direttamente allo stato Destroyed. 32

33 2.3 Interfaccia grafica Lo standard MHP basa la creazione di un interfaccia grafica sull utilizzo di una parte della classe AWT e di una GUI API appartenente alle specifiche Havi (Home Audio Video interoperability). Per la grafica bisogna necessariamente considerare le seguenti problematiche: Diversi rapporti di formato dei pixel: Possono esserci difetti di visualizzazione in quanto le Api grafiche assumono che i pixel siano quadrati, mentre le applicazioni TV non usano pixel di questo tipo. Diversi rapporti di formato dello schermo: Il rapporto del segnale video TV è passato da 4:3 a widescreen (16:9 o 14:9), o a causa dello stesso segnale tv o per una segnalazione da parte dell utente. In entrambi i casi una grafica non progettata per questa tipologia di formato potrebbe causare molti problemi. Translucenza e trasparenza: può essere necessario uno strumento che renda la grafica trasparente così che l utente possa vedere ciò che è al di sotto di essa. Spazio dei colori: Ci deve essere un interfaccia hardware che mappi lo spazio dei colori RGB, che usa Java, nello spazio YUV utilizzato nei segnali televisivi. Impossibilità dell uso di Window Manager: per la maggior parte di piattaforme MHP essi sono infatti troppo complessi da usare, servirà quindi una soluzione alternativa per ottenere un area su cui inserire oggetti grafici. Differenze di interfaccia utente: un applicazione MHP non potrà avere la focalizzazione di un input (input focus) se un altra applicazione è attiva in quell istante HAVi level 2 GUI Lo standard HAVi definisce un ampliamento delle GUI Java standard, conosciuto appunto come HAVi level 2 GUI le cui classi sono contenute nel package org.havi.ui e sono usate per molteplici applicazioni grafiche. All interno di questo package vi è un set du GUI extra, create appositamente per l utilizzo della grafica su un display televisivo, che soddisfano l 33

34 adattamento alle limitazioni e richieste delle specifiche TV. Infatti le classi relative alle GUI HAVi, come ad esempio org.havi.ui.hcomponent e org.havi.ui.hcontainer, devono essere utilizzate al posto delle classi corrispondenti in AWT. Come si può vedere dalla figura 2.5 il modello grafico definito dallo standard MHP si basa su 3 layer: Background layer: può contenere un colore o un immagine statica, rappresentata da un particolare frame MPEG-2) Video layer: rappresentato dal flusso audio-video del canale TV o da una qualsiasi altra fonte in formato MPEG-2 Graphic layer: conterrà la grafica creata nell Xlet, e può essere strutturato su più livelli sovrapposti. Figura 2.5: I tre layers del display TV Il Graphic layer può avere una risoluzione diversa rispetto a quella del layer video e di background e può avere un diverso formato dei pixel. I layer possono essere configurati separatamente in quanto i componenti responsabili della loro generazione sono diversi. Può comunque esservi qualche piccola interazione fra questi apparati che porrebbe così vincoli sulla configurazione di uno o più strati. Nell ambito di questa problematica HAVi e MHP definiscono la classe HScreen che rappresenta un apparato di visualizzazione fisico: ogni ricevitore MHP avrà quindi un istanza HScreen per ogni display ad esso 34

35 connesso. Ad ognuno di questi HScreen viene attribuito un numero di oggetti HscreenDevice, che rappresentano i diversi layer dello schermo: HBackgroundDevice, rappresenta il layer di background HVideoDevice, rappresenta il layer video HGraphicDevice, rappresenta il layer grafico Vediamo la definizione della classe HScreen: public class HScreen { public static HScreen[] gethscreens(); public static HScreen getdefaulthscreen(); public HVideoDevice[] gethvideodevices(); public HGraphicsDevice[] gethgraphicsdevices(); public HVideoDevice getdefaulthvideodevice(); public HGraphicsDevice getdefaulthgraphicsdevice(); public HBackgroundDevice getdefaulthbackgrounddevice(); public HScreenConfiguration[] getcoherentscreenconfigurations(); public boolean setcoherentscreenconfigurations( HScreenConfiguration[] hsca); } Come si può notare, possiamo ottenere le referenze dei device sopra descritti chiamando i metodi appropriati sull oggetto HScreen. Possiamo avere accesso ai device di default, ma nel caso di quelli video e graphic possono essere presenti ulteriori device ai quali accedere. Ovviamente si può avere un solo background, ma caratteristiche come picture-in-picture permettono l esistenza di video device multipli, e se sono supportati layer grafici multipli, si puà avere un device grafico per ogni layer, come mostrato nello schema in figura 2.6: Figura 2.6: Periferiche Video e Grafiche multiple 35

36 Una volta individuato un device, questa periferica di schermo può essere configurata con istanze della classe HScreenConfiguration e delle sue sottoclassi. Grazie al loro utilizzo possiamo settare il rapporto di formato dei pixel, il rapporto del formato video, la risoluzione dello schermo ed altri parametri che si potrebbe desiderare cambiare. Queste configurazioni sono impostate utilizzando sottoclassi della classe HScreenConfigTemplate. L oggetto HscreenConfigTemplate prevede un meccanismo che ci permette di impostare i parametri che desideriamo per un determinato device e si possono avere informazioni sulla possibilità o meno di attribuire la configurazione ottenuta ad altri display. Per esaminare il suo funzionamento si prende come esempio una periferica grafica. La classe HgraphicsDevice ha la seguente interfaccia: public class HGraphicsDevice extends HScreenDevice { public HGraphicsConfiguration[] getconfigurations(); public HGraphicsConfiguration getdefaultconfiguration(); public HGraphicsConfiguration getcurrentconfiguration(); public boolean setgraphicsconfiguration( HGraphicsConfiguration hgc) throws SecurityException, HPermissionDeniedException, HConfigurationException; public HGraphicsConfiguration getbestconfiguration( HGraphicsConfigTemplate hgct); public HGraphicsConfiguration getbestconfiguration( HGraphicsConfigTemplate hgcta[]); } I primi tre metodi illustrati sono abbastanza ovvi e ritornano un elenco di possibili configurazioni, la configurazione di default e la configurazione corrente. Il metodo successivo è altrettanto ovvio e ci permette di impostare la configurazione del dispositivo. Da notare invece la presenza dell eccezione HConfigurationException, che viene lanciata se si tenta di impostare una configurazione che non è compatibile con quelle associate agli altri schermi. Gli ultimi due metodi risultano invece più interessanti. Il metodo getbestconfiguration() ha come argomento un oggetto 36

37 HGraphicsConfigTemplate, sottoclasse di HScreenConfigTemplate. Questo permette all utente di costruire una maschera, settare alcune preferenze e vedere qual è la migliore configurazione che può essere generata, data l attuale configurazione degli altri dispositivi. La variante di questo metodo prende un array di oggetti HGraphicsConfigTemplate e ritorna la struttura migliore dopo averli esaminati tutti. Una volta che abbiamo la configurazione adatta possiamo settarla tramite il metodo setgraphicsconfiguration(). Come abbiamo già visto le API HAVi utilizzano la classe HScreenConfigTemplate per definire una serie di preferenze di configurazione. Questa classe definisce costanti che referenziano ogni possibile preferenza, dando la possibilità di attribuire ad ognuna di esse un livello di priorità. ZERO_GRAPHICS_IMPACT e ZERO_VIDEO_IMPACT sono preferenze che vengono utilizzate per specificare che la configurazione non deve interferire con applicazioni grafiche già in corso o in fase di riproduzione video. VIDEO_GRAPHICS_PIXEL_ALIGNED invece indica che i pixel nel layer video e nel layer grafico devono essere allineati in modo perfetto. La parte più interessante è comunque quella che riguarda le priorità che viene assegnata ad ogni preferenza. Queste possono assumere uno dei seguenti valori: REQUIRED, indica che la preferenza deve essere rispettata PREFERRED, indica che la preferenza dovrebbe essere rispettata, ma se necessario, può essere ignorata UNNECESSARY, indica che l applicazione non ha bisogno di un valore specifico da attribuire a questo tipo di preferenza PREFERRED_NOT, indica che la preferenza non dovrebbe assumere il valore specificato, ma lo può fare se ritenuto strettamente necessario REQUIRED_NOT, indica che la preferenza non deve per alcun motivo assumere il valore specificato. Questo permetta all applicazione di avere un buon grdo di libertà nelle specifiche della configurazione, e allo stesso tempo dà comunque modo al ricevitore di essere flessibile in corrispondenza delle esigenze degli applicativi, in virtù della presenza di altre applicazioni e di vincoli imposti 37

38 dalle configurazioni delle altre periferiche. Quando l applicazione chiama il metodo HGraphicsDevice.getBestConfiguration(), il ricevitore controlla le preferenze specificate nell HScreenConfigTemplate e tenta di trovare una configurazione che soddisfi tutte le richieste indicate come REQUIRED e REQUIRED_NOT, rispettando i vincoli imposti dalle altre applicazioni. Se tutto va a buon fine, il metodo restituisce un oggetto HGraphicsConfiguration che rappresenta la nuova configurazione o NULL se i vincoli non possono essere rispettati. Per ciascuna delle tre classi del dispositivo HBackgroundDevice, HVideoDevice e HGraphicsDevice si hanno nomi analoghi per le classi di configurazione, HBackgroundConfiguration, HVideoConfiguration e HGraphicsConfiguration, e così pure per le maschere di configurazione: HBackgroundConfigTemplate, HVideoConfigTemplate ed infine HGraphicsConfigTemplate. Appare evidente come un tipo di configurazione possa cambiare mentre un applicazione è in esecuzione. Dal momento che gli applicativi per piattaforma MHP hanno necessariamente bisogno di sapere se le proprietà del display sono cambiate, la classe HScreenDevice permette loro di aggiugersi al sistema nel ruolo di ascoltatori, ovvero listener, di eventi HScreenConfigurationEvent utilizzando il metodo addscreenconfigurationlistener(). Grazie a questo un applicazione può quindi accorgersi di cambiamenti nella configurazione del display e reagire di conseguenza. Il layer di Background in un ricevitore MHP è in grado di mostrare un colore solido o un immagine. Una applicazione può scegliere quale di queste due opzioni usare settando le preferenze appropriate nell HBackgroundConfigTemplate in fase di configurazione. Se un applicazione sceglie l opzione immagine, allora la configurazione che ritirnerà sarà una sottoclasse di HBackgroundConfiguration. Questa sottoclasse, HStillImageBackgroundConfiguration, aggiunge due metodi extra a quelli standard della classe HBackgroundConfiguration: public void displayimage(hbackgroundimage image); public void displayimage(hbackgroundimage image, HScreenRectangle r); 38

39 Entrambi I metodi prendono come parametro un HBackgroundImage, classe progettata per manipolare immagini nel layer di background. Questo differisce dalla classe java.awt.image dal momento che implementa solo i metodi necessari per visualizzare immagini di sfondo, come vediamo dal seguante codice: public class HBackgroundImage { public HBackgroundImage(String filename); public void load(hbackgroundimagelistener l); public void flush(); public int getheight(); public int getwidth(); } La classe HBackgroundConfiguration accetta file di tipo.gif,.jpeg,.png o.mpeg I-frame come argomenti del costruttore, e l immagine deve essere caricata e disposta in modo esplicito usando rispettivamente i metodi load() e flush() Coordinate in MHP MHP supporta tre diversi sistemi di coordinate, utilizzati per fornire diverse soluzioni per il posizionamento degli oggetti sullo schermo. Differenti API sono associate a questi sistemi, che elenchiamo qui di seguito: Sistema di coordinate normalizzate: Questo sistema ha l origine delle coordinate posta a (0.0,0.0) nell amgolo in alto a sinistra dello schermo, per raggiungere il valore massimo (1.0,1.0) nell angolo in basso a destra. Con questa modalità si possono posizionare oggetti in relazione ad altri, senza specificare il valore assoluto delle coordinate dello schermo. Il sistema a coordinate normalizzate è utilizzato dalle classi HAVi, specialmente da HScreenPoint e HScreenRectangle. Sistema di coordinate schermo: Ha un valore massimo non predefinito che varia in funzione della periferica: per quanto riguarda l MHP le sue specifiche indicano che il valore riferito alla coordinata x non deve superare 72, quello della coordinata y non deve invece superare 576. Questo secondo spaziodi coordinate è definito dall oggetto HGraphicsDevice e viene utilizzato da HAVi, nel posizionamento 39

40 delle Hscene e per la configurazione della risoluzione degli oggetti HScreenDevice. Sistema di coordinate AWT: è utilizzato dall omonimo package ed è basato su pixel. Non si riferisce all intero display ma lla finestra radice dell applicativo per la quale l origine è posizionata in alto a sinistra del container AWT, mentre il massimo è in basso a destra nella finestra che lo stesso container referenzia. Figura 2.7: Sistemi di coordinate MHP Hscene e HSceneTemplate Come già accennato, non è possibile implementare un Window Manager a causa della limitata memoria e potenza di calcolo dei set-top-box. Non si può quindi usare la classe java.awt.frame come finestra top-level dell applicazione. Si usa al suo posto org.havi.ui.hscene che definisce un oggetto simile come concetto al frame ma con svariate limitazioni: ad esempio un applicazione MHP non può accedere a componenti diverse da quelle inserite nella gerarchia AWT della proprioa Hscene, tutti gl applicativi quindi sono totalmente isolati dalle altre attività grafiche. Un esempio di questa visibilità è dato dalla figura 2.8 in cuil applicazione associata ai componenti blu non può manipolare gli eventi della struttura rosa poiché sono appartenenti ad un altro applicativo. Una volta istanziata l HScene infatti, l applicazione a essa associata non sarà nemmeno a conoscenza dell esistenza di altri componenti al di fuori della propria gerarchia. 40

41 Figura 2.8: Esempio di visibilità in HScene Un altra differenza tra la classe Frame e quella di HAVi è che mentre in Java non vi è limiute al numero di frame, in MHP solo una HScene può essere istanziata. Questo è possibile solo nel caso vi siano più display disponibili e quindi le HScene sono associate ad HScreen diversi. Per istanziare una HScene si utilizza la classe HSceneFactory, mentre la classe HSceneTemplate permette di specificare vincoli come la grandezza, la locazione, ed attribuire a questi elementi una certa priorità come si può notare dalla classe stessa: public class HSceneTemplate extends Object { } // priorities public static final int REQUIRED; public static final int PREFERRED; public static final int UNNECESSARY; // possible preferences that can be set public static final Dimension LARGEST_DIMENSION; public static final int GRAPHICS_CONFIGURATION; public static final int SCENE_PIXEL_RESOLUTION; public static final int SCENE_PIXEL_RECTANGLE; public static final int SCENE_SCREEN_RECTANGLE; // methods to set and get priorities public void setpreference( int preference, Object object, int priority); public Object getpreferenceobject(int preference); public int getpreferencepriority(int preference); Analizzando le priorità, quelle unnecessary vengono ignorate nel momento in cui si crea un istanza HScene, quelle referred sono considerate solo se 41

42 la piattaforma MHP le supporta, e quelle required non devono essere ignorate: se non si riescono a soddisfare tutte, l applicazione chiamata non potrà mai istanziare una HScene. La classe HSceneFactory definisce i metodi seguenti: public class HSceneFactory extends Object{ public static HSceneFactory getinstance(); public HSceneTemplate getbestscenetemplate( HSceneTemplate hst); public HScene getbestscene(hscenetemplate hst); public void dispose(hscene scene); public HSceneTemplate resizescene( HScene hs, HSceneTemplate hst) throws java.lang.illegalstateexception; public HScene getselectedscene( HGraphicsConfiguration selection[], HScreenRectangle screenrectangle, Dimension resolution); public HScene getfullscreenscene( HGraphicsDevice device, Dimension resolution); } Dove, ad esempio, getbestscene prende come argomento unn HSceneTemplate e ritorna, se tutti i vincoli sono rispettati, un HScene, oppure NULL. Una volta ottenuta l HScene se ne può disporre con il metodo dispose. Il getbestscenetemplate invece permette all applicativo di negoziare con la piattaforma per l uso delle risorse disponibili Il set di widgets HAVi HAVi Level 2 GUI offre un set di widget che può essere utilizzato in modo sostitutivo a quelli mancanti di AWT e sono il set standard che ci si aspetta da un qualunque sistema GUI: Bottoni, check-boxes e radio buttons Icone Liste corredate di scroll Finestre di dialog Campi di testo 42

43 Questi sono in effetti molto simili alle classi AWT. Ad esempio se vogliamo implementare una label utilizzeremo la classe Htext, che comprende un numero notevole di metodi per la gestione della stessa: dal la dimensione, al posizionamento, fino alla gestione del focus che permette una navigazione grafica Il controllo remoto Un decoder MHP si interfaccia con l utente tramite il controllo del telecomando. Vengono riportate in figura 3.9 tutti i key event possibili specificando il nome della costante, il relativo pulsante ed il codice associato. I codici di VK_UP, VK_DOWN, VK_LEFT, VK_RIGHT e VK_ENTER sono definiti dalla piattaforma Java e sono gli unici sicuramente ricevibili su qualsiasi decoder MHP, mentre per altri il telecomando può generare codici differenti. La lista completa degli eventi è descritta nella classe org.havi.ui.event.hrcevent. Nel modello convenzionale Java standard è da ricordare che purtroppo un componente può ricevere un evento da tastiera solo dopo esser stato focalizzato. Per questo motivo è stato creato il package org.dvb.event che definisce un API che permette alle applicazioni di avere accesso agli eventi prima che essi entrino nel meccanismo di gestione di AWT. Nome della costante Key Key code VK_UP Freccia verso l alto Non standardizzata VK_DOWN Freccia verso il basso Non standardizzata VK_LEFT Freccia sinistra Non standardizzata VK_RIGHT Freccia destra Non standardizzata VK_ENTER Tasto OK Non standardizzata VK_0 to VK_9 Tasti numerici VK_EXIT Tasto EXIT Non standardizzata VK_COLORED_KEY_0 Tasto rosso 403 VK_COLORED_KEY_1 Tasto verde 404 VK_COLORED_KEY_2 Tasto giallo 405 VK_COLORED_KEY_3 Tasto blu 406 Figura 2.9: Key event per il controllo remoto 43

44 Una classe che implementa UserEventListener può ricevere un evento anche se l applicativo non ha un componente focalizzato dall utente. Prima di poter ricevere segnalazioniè necessario istanziare un UserEventRepository che definisce i seguenti metodi per abilitare e disabilitare il ricevitore alla ricezione di gruppi di tasti: public class UserEventRepository { public UserEventRepository (String name); public void adduserevent (UserEvent event); public UserEvent[] getuserevent (); public void removeuserevent (UserEvent event); public void addkey (int keycode); public void removekey (int keycode); public void addallnumerickeys(); public void addallcolourkeys(); public void addallarrowkeys(); } public void removeallnumerickeys(); public void removeallcolourkeys(); public void removeallarrowkeys(); Una volta che l applicazione ha definito il set di tasti tramite i quali è abilitata a ricevere eventi, si può utilizzare la classe EventManager per richiedere l accesso alle segnalazioni elencate. EventManager è definita da un oggetto unico, che viene istanziato tramite il metodo EventManager. getinstance(). Dopo l istanziazione si usano i metodi addusereventlistener() e removeusereventlistener() per aggiungere e rimuovere ascoltatori per il set di eventi definiti dall oggetto UserEventRepository. 2.4 Emulatori Open Source I software Open Source che permettono di emulare una piattaforma MHP attraverso un Personal Computer, sono attualmente davvero pochi. Tra di essi spicca senza dubbio XleTView, che è il più usato tra gli sviluppatori di applicazioni per il difitale, nonostante non sia in grado ancora di emulare in tutto e per tutto un ricevitore MHP. 44

45 2.4.1 XleTView L unico prerequisito per l utilizzo di XleTView è quello di aver installato sul proprio pc il supporto Java 2 Runtime Environment SE v1.4 o successive versioni. XleTView può essere scaricato in formato.zip, nella sua ultima versione, xletview-0.3.6, rilasciata il 06 Giugno L installazione consiste semplicemente nella decompressione del file scaricato, nella directory da cui desideriamo eseguire il programma, per poi poterlo da lì lanciare con java jar xletview.jar. Il file xletview.jar è in effetti l applicazione XleTView stessa ed include tutte le classi delle API MHP necessarie all esecuzione delle applicazioni in XleTView. Gli altri file.jar contenuti nell apposita directory del programma, sono semplicemente usati da XleTView e non devono essere quindi inclusi nelle applicazioni che si intendono sviluppare. Figura 2.10: Esempio di Implementation status di XleTView Nel sito da cui è possibile effettuare il download del file si uò anche visualizzare, alla pagina l attuale elenco completo delle classi già implementate (segnalate da un quadrato verde), quelle in costruzione (quadrato giallo), quelle implementate ma con bug riconosciuti (quadrato blu) e quelle non implementate (quadrato rosso). L interfaccia grafica iniziale di XleTView è quella che vediamo in figura 4.2: essa simula uno schermo televisivo, con alla sua destra un telecomando dotato dei principali tasti presenti sui telecomandi dei decoder MHP. 45

46 Cliccando su questi tasti si interagisce con l applicazione simulando il controllo remoto che si avrebbe nella realtà. Figura 2.11: Interfaccia grafica iniziale di XleTView Ogni TV ha una lista di canali disponibili, e XleTView offre la possibilità di gestirli. I pulsanti + e presenti nel telecomando, infatti, non interagiscono con gli applicativi ma permettono di cambiare canale. Ciò è possibile editando il file \config\channels.xml: <?xml version="1.0" encoding="iso "?> <CHANNELS> <CHANNEL> <NAME>Nome del primo canale</name> <MEDIA> defaultbg.jpg</media> </CHANNEL> </CHANNELS> All interno del tag media, che segnala cosa mostrare in background, vi può essere o un immagine jpg, di 720x576 pixel, o un file.avi codificato con il codec Cinepack, unico formato attualmente supportato. Non tutti i televisori sono in grado di visualizzare la stessa area dello schermo: fino al 10% dell immagine può essere persa per overscan e un ulteriore 10% può soffrire di distorsione. Per aiutare lo sviluppatore XleTView mostra un marcatore per indicare quali parti dello schermo sono all interno della zona di sicurezza. Come impostazione predefinita è un marcatore di colore giallo che indica una zona rientrante 10 pixel dai bordi 46

47 dello schermo, è possibile però configurare la zona di sicurezza nel file config/settings.txt che contiene le seguenti opzioni: safearea.show: attiva/disattiva la visualizzazione del marcatore (default: vero); safearea.color: colore del marcatore (default: #ffee00) safearea.height: altezza della zona di sicurezza (default: 556) safearea.width: larghezza della zona di sicurezza (default: 700) safearea.x: pixel di distanza dal bordo sinistro (default: 10) safearea.y: pixel di distanza dal bordo in alto (default: 10) Infine è possibile configurare la visualizzazione del telecomando: tramite il file config\remote_control.xml si può cambiare il numero di pulsanti, la loro posizione a la KEY a loro legata. Per eseguire un applicazione è necessario precedentemente aggiungerla alla lista di applicazioni in XleTView. Una volta laniato il programma, cliccare su Applications e in seguito su Manage applications. Questo aprirà una finestra che ci permette di aggiungere directory e nuove applicazioni. Scelto il nome da dare all applicazione, basta scrivere in Path il percorso della directory contenente i file necessari alla sua esecuzione, in Xlet selezionare la classe di partenza nel caso ve ne siano più di una, ed infine premere OK e SAVE & CLOSE. A questo punto cliccando su Applications comparirà anche l applicazione da noi inserita, che verrà lanciata cliccandoci sopra, potendo così simulare la notra Xlet su un televisore. Quanto appena descritto lo si può realizzare anche tramide un editing del file \config\applications.xml, come si può vedere nel seguente esempio: <!-- top element in this xml file --> <APPLICATIONS> <!-- top element for one Xlet,r default group --> <APPLICATION> <!-- name of the Xlet --> <NAME>SecondXlet</NAME> <!-- path to the Xlet --> <PATH>/home/elisa/workspace/SecondXlet</PATH> <!-- the main class of the Xlet --> <XLET>SecondXlet </XLET> </APPLICATION> 47

48 Figura 2.12: Inserimento nuova applicazione in XleTView Precendentemente abbiamo accennato al controllo remoto: questo è gestibile attraverso l utilizzo del mouse sul telecomando visualizzato, ma anche tramite la tastiera, con la seguente mappatura: Frecce telecomando = Frecce tastiera OK = Invio Numeri dei canali = Numeri del KeyPad Tasto Rosso = F1 Tasto Verde = F2 Tasto Giallo = F3 Tasto Blu = F Limiti riscontrati Come è già stato accennato in precedenza, non tutte le caratteristiche funzionanti sui decoder MHP sono state implementate in XleTView, vediamone una lista un po più dettagliata delle principali carenze: Video MPEG Caricamento di applicazioni da un transport stream Le API org.dvb.si e JavaTV SI 48

49 Supporto per un object carousel Comunicazioni inter-xlet Controllo del ciclo di vita di un applicazione Supporto per dvb:// locators Sicurezza Una discordanza tra ciò che viene visualizzato in XleTView e ciò che realmente si vede su uno schermo televisivo è invece l utilizzo dei metodi setbackground( Color c) definiti per le classi HAVi come ad esempio HText e HgraphicButton, mentre sembrano funzionare sull emulatore, mantengono a prescindere uno sfondo trasparente sul televisore. Questo comporta l obbligo dell utilizzo di immagini di sfondo, sia di background, sia per simulare un focus o comunque la variazione del colore di sfondo di un componente per qualunque motivo. Ovviamente ciò implica un peggiore utilizzo della banda, dovendo trasmettere file.jpg che non dovrebbero essere necessari. Una classe che invece è perfettamente implementata sui decoder MHP ma non è utilizzabile sull emulatore è la RandomAccessFile. Nel lavoro effettuato per questa tesi, che verrò ampiamente illustrato nel prossimo capitolo, è stato fondamentale l utilizzo di file binari ad accesso casuale, che vengono appunto gestiti in Java dalla classe suddetta. Questo ha creato non pochi problemi nell implementazione dell applicazione dal momento che i test e i debugging non sono più stati possibili su emulatore in locale, e sono stati fatti direttamente tramite messe in onda sul canale LepidaTV. 49

50 50

51 Capitolo 3 Meccanismi di autenticazione con bassa interattività Il Piano Telematico Regionale (PiTER) 2007/2009 ha come obiettivo quello di creare una efficiente base comune di comunicazione sul territtorio, tramite una nuova rete di connessione a banda larga tra la Regione e l intero sistema degli enti locali: province, comuni, comunità montane. LepidaTV è uno degli strumenti di PiTER al servizio delle pubbliche amministrazioni e dei cittadini e si propone di combattere il digital divide ed il knowledge divide offrendo le stesse opportunità e gli stessi servizi anche a chi non è provvisto di connettività a banda larga. LepidaTV si basa sulla tecnologia digitale terrestre. Lo switch-off nazionale del sistema televisivo da tecnologico a digitale è stato recentemente parzialmente anticipato. Il nuovo calendario indicato dal decreto ministeriale e presentato il 9 Settembre 2008 ha sancito uno switchoff progressivo sul territtorio italiano che, partendo dalla Sardegna nel 2008, terminerà nel 2012 assicurando però già al 2010, anno in cui avverrà lo switch-off anche nella regione Emilia Romagna, che il 70% della popolazione vedrà la tv con il nuovo segnale digitale. Figura 3.1: Calendario grafico dello switch-off in Italia 51

52 I servizi che LepidaTV attualmente offre sono quindi quelli che già sono erogati dai vari enti sul Web, e li riadatta per renderli disponibili al cittadino sulla tv digitale, tramite l interfaccia grafica chiamata super teletext, sfruttando una interattività di tipo debole, che spiegheremo in questo capitolo, dove cominciamo ad analizzare l implementazione di un Xlet provvista di autenticazione. 3.1 Modello standardizzato Per massimizzare la comprensibilità dell applicazione, LepidaTV ha deciso di creare un minimo numero di interfacce standardizzate che possano essere riutilizzate per più servizi possibili. Così facendo l utente si troverà a dover capire il funzionamento di 2 o 3 servizi solamente, ritrovando la stessa impostazione grafica e gli stessi tasti di navigazione anche negli altri. Lo studio di questa tesi verte sull interfaccia standardizzata che permetta di visualizzare contenuti personalizzati a seguito di un login, ed è strutturata come illustrato in figura 3.2: Figura 3.2: Interfaccia Standardizzata Vi è quindi una fascia superiore riservata ai loghi del servizio e degli Enti coinvolti, più quello della rete televisiva che trasmette l applicazione. Subito sotto un area dedicata all immissione di testo da parte dell utente. 52

53 Vi sono poi due zone verticali: in quella di sinistra vi è la parte di inserimento dei parametri per il login e sotto l area di visualizzazione dei contenuti, a destra in alto un resize dell audio-video così che l utente abbia sempre sotto controllo la programmazione in trasmissione mentre naviga, infine in basso la parte dedicata alle istruzioni di navigazione. Questo modello offre quindi l opportunità di gestire implementazioni di servizi diversi che abbiano la stessa necessità: visualizzare contenuti personalizzati legati ad una precedente autenticazione. 3.2 Scelta della bassa interattività e sue problematiche Come spiegato nel paragrafo 1.5.5, si possono sfruttare due tipologie di interattività a seconda che vi sia o meno la presenza di un canale di ritorno: interattività forte e debole. Lepida TV ha scelto di utilizzare l interattività debole, per svariati motivi: innanzitutto per una maggiore semplicità dello schema trasmissivo, inoltre per problematiche di sicurezza, che senza canale di ritorno non si pongono. Esempio tipico, ben conosciuto anche sul Web soprattutto in passato, è il Dialer: si può vedere in un esempio semplificato nel seguente codice, quanto sia semplice realizzarne uno da utilizzare poi interponendosi tra l utente ed il centro servizi: public class ReturnChannelXlet implements Xlet, ResourceClient, ConnectionListener{ private ConnectionParameters getconnectionparameters() throws UnknownHostException{ return new ConnectionParameters(" <num di tel maligno> ", "isp","passwd"); } public void initxlet(xletcontext ctx) throwsxletstatechangeexception{ [... ] try{ //Richiesta di un interfaccia al canale di ritorno ConnectionRCInterface cif = getconnectionrcinterface(); [... ] //Richiesta dei parametri di connessione cif.settarget(getconnectionparameters()); //Connessione in corso cif.connect(); } catch (Exception e) {... } } 53

54 Inoltre, anche riuscendo ad ottenere un buon livello di sicurezza, si deve ricordare l ampio target di utenza di LepidaTV: alcune fasce, come ad esempio gli anziani, o chi comunque non ha molte esperienze con la gestione generica di una connessione, potrebbe rifiutarsi di collegare la linea telefonica al decoder, per la paura di avere spese inattese. Così facendo, ovviamente, non potrebbero più usufruire dei servizi interattivi, mentre lo scopo di LepidaTV è appunto renderli accessibili a tutti. La scelta di utilizzare una interattività debole ha però creato alcune problematiche dal punto di vista implementativo: all utente devono essere infatti inviati tutti i contenuti disponibili, per offrirgli poi una visualizzazione selettiva di questi basati sulle loro selezioni, dando così una parvenza di interattività con il Centro Servizi. Alcune implementazioni reali del modello che stiamo trattando potrebbero essere le seguenti: Informazioni sull'avanzamento delle pratiche di residenza o di permesso di soggiorno Verifica dell'iter della propria pratica edilizia consultazione del cedolino della pensione e verifica dell avvenuto pagamento Consultazione delle proprie multe Prendendo in considerazione, ad esempio, l ultima, dovranno essere trasmesse ad ogni utente tutte le multe di tutti i cittadini iscritti a questo servizio: ciò si traduce in decine di migliaia di contenuti almeno limitandosi ad un servizio pensato per una sola provincia e con una bassa media di multe. In seguito all autenticazione l utente potrà poi ovviamente visualizzare solo quelle corrispondenti a username e password inseriti. 3.3 Ottimizzazioni I Set Top Box attualmente in commercio hanno bassa memoria e limitatissima capacità di processamento dei dati e quest ultimo è un notevole problema all interno della scelta di una interattività debole. Pur essendo infatti i contenuti inseriti in file di testo, che sono quindi di limitate dimensioni, la navigazione all interno di essi può risultare molto rallentata. 54

55 In prima istanza i contenuti sono stati inseriti in normali file di testo letti in modo sequenziale con la seguente struttura: Figura 3.3: Struttura file sequenziale Si inizia quindi scrivendo uno username, la password associata, e di seguito il titolo e il contenuto di ogni notizia legata a quelle credenziali. Si prosegue poi con un altro username, la sua password e le notizie di queste ultime credenziali, e così via. Utilizzando questo sistema, anche suddividendo il file principale in più sottofile, è stato notato come già una navigazione di 40 contenuti possa dare dei ritardi nell ordine di 1 secondo e arrivando a 100 contenuti si hanno tempi di caricamento anche di parecchi secondi, che senza ogni dubbio stancano e disorientano l utente. Ciò è dovuto soprattutto alla scansione sequenziale del file, oltre ad una non ottimizzata struttura: si è pensato quindi di risolvere questa problematica tramite l utilizzo di file binari, che permettono accessi casuali al contenuto. Un esempio di struttura sarà spiegatonel dettaglio nel prossimo capitolo. 55

56 56

57 Capitolo 4 Esempio di implementazione Data quindi l interfaccia standard, vediamo le varie scelte implementative che sono state effettuate per la creazione di un servizio, per assicurarne una buona visibilità e comprensibilità, e soprattutto come strutturare le informazioni da visualizzare in modo che la navigazione risulti rapida e fluida all utente anche in presenza di un numero molto elevato di contenuti. 4.1 Accessibilità ed usabilità Essendo il target di utenza di LepidaTV l intera popolazione, compresi anziani e persone che non hanno alcun tipo di esperienza sul Web, ma conoscono solo l utilizzo del semplice telecomando televisivo analogico per reperire informazioni, risulta ovvio che l accessibilità e l usabilità sono stati parti fondamentali nello studio di questa applicazione. Per quanto riguarda l inserimento da parte dell utente di caratteri alfanumerici nelle caselle Username e Password, le opzioni erano tre: Utilizzo del telecomando visto come quello del cellulare, in cui a ogni numero sono associate 3 o 4 lettere alfabetiche a seconda del numero delle pressioni del tasto Implementazione grafica sull applicazione di una tastiera di tipo QWERTY navigabile Inserire una barra grafica, a due dimensioni quindi,dove semplicemente scorrendo a destra e sinistra, si può selezionare la lettera o il numero desiderato. La prima opzione è stata scartata in quanto non si può pensare che nel vasto target di utenza siano tutti in grado di usare il cellulare, inoltre la pressione dei tasti di un telecomando è più difficoltosa, e la scrittura con esso potrebbe risultare problematica anche a chi è abituato a mandare SMS, e quindi a questo metodo di scrittura. 57

58 Anche la seconda opzione può risultare poco intuitiva a chi, non avendo esperienze di lavoro con un Personal Computer, trovandosi di fronte ad una tastiera QWERTY si troverebbe spaesato e faticherebbe a trovare le lettere desiderate. Per questo si è adottata la terza soluzione, che ad un primo impatto può non sembrare la più ottimale dal punto di vista delle tempistiche, ma per i motivi sopra citati è senz altro la migliore dal punto di vista dell usabilità. Come si può infine notare dalla figura 4.1, la barra è stata corredata di due frecce all estrema destra e sinistra che segnalano quando sono present altri caratteri nelle due direzioni, e scompaiono quindi per esplicitare il focus sull ultimo carattere (freccia destra) e sul primo (freccia sinistra). Figura 4.1: Barra di navigazione alfanumerica Una ulteriore importante scelta di usabilità è collegata alla determinazione dei pulsanti del telecomando da usare per interagire con l applicazione. Infatti è risultato che per chi, soprattutto gli anziani, è abituato al normale telecomando della televisione analogica, trova difficoltà nell individuazione ed utilizzo di tasti nuovi come le frecce direzionali e l OK. Si è quindi deciso di utilizzare i tasti numerici, da sempre presenti. Più nello specifico i tasti 1 e 3 per scorrere a destra e sinistra i caratteri, per analogia i tasti subito sotto a questi, ovvero 4 e 6 per selezionare Username o Password, analogamente 7 e 9 per visualizzare la notizia precedente o quella successiva, nel caso ve ne siano più di una disponibile.infine il tasto centrale 5 per confermare l inserimento del carattere selezionato e 2 per cancellarlo. Le istruzioni consistono semplicemente nelle immagini dei tasti numerici con in testa la loro funzione, così da rendere tutto chiaro a prima vista, senza lunghi testi esplicativi da dover leggere. 58

59 Figura 4.2: Area delle istruzioni di navigazione Come si vede dalla figura 4.2, i tasti sono divisi a gruppi e sono associati ad un diverso colore di sfondo. Questo perché gli stessi colori sono riportati come sfondo nelle parti dell apllicazione in cui si interagisce con quel gruppo di tasti, così da renderne ancora più intuitivo il legame all utente. I colori sono stati scelti e testati tramite Contrast Analyzer, software che permette di determinare la corretta visibilità del colore basandosi su due algoritmi suggeriti per l accessibilità dal World Wide Web Consortium (W3C): Differenza di colore: data dalla seguente formula: (massimo (valore rosso 1, valore rosso 2) - minimo (valore rosso 1, valore rosso 2)) + (massimo (valore verde 1, valore verde 2) - minimo (valore verde 1, valore verde 2)) + (massimo (valore blu 1, valore blu 2) - minimo (valore blu 1, valore blu 2) Dovrebbe dare una differenza, tra colore di sfondo e colore delle scritte, superiore o uguale a 500; Differenza di luminosità: la formula per il calcolo della luminosità è: ((valore del colore rosso X 299) + (valore del colore verde X 587) + (valore del colore blue X 114)) / 1000 La differenza fra la luminosità dello sfondo e quella del colore principale dovrebbe essere in questo caso superiore a 125. Contrast Ratio: misura la luminanza relativa ed è dato dalla seguente formula: L = * R * G * B Il rapporto minimo di contrasto di luminosità deve essere pari a 5:1 per font di dimensione normale e 3:1 per lettere grandi nel caso del livello AA corrispondente al contrasto minimo, mentre i valori sono, 59

60 per caratteri normali 7:1 e nel caso di font di grande dimensione 5:1 per il livello AAA del contrasto esteso. La figura 4.3 mostra i risultati ottenuti con lo sfondo predominante da noi scelto: Figura 4.3: Area delle istruzioni di navigazione Contrast analyzer provvede infine ad emulare la visione di un daltonico, suddividendo i risultati in tre esempi corrispondenti a tre patologie: Protanopia: Cecità per il colore rosso Deuteranopia: Cecità per il colore verde Tritanopia: Cecità per il colore giallo e blu Come si vede dalla figura 4.4, per tutti i casi i colori scelti soddisfano i requisiti proposti dal W3C: Figura 4.4: Analisi nei casi di daltonismo 60

61 Anche per gli altri due colori di sfondo sono state ovviamente fatte scelte di colore in grado di rispettare tutte le specifiche spiegate. 4.2 Implementazione della grafica Ricordando il ciclo di vita di un Xlet, il primo metodo che andiamo ad analizzare è startxlet() che, venendo lanciato sulla piattaforma MHP alla richiesta dell esecuzione dell applicazione, contiene l implementazione di tutta la grafica statica necessaria alla sua visualizzazione. Per prima cosa ci preoccupiamo di creare un istanza di UserEventRepository su cui chiamare i metodi che abilitano il ricevitore alla ricezione alla ricezione di eventi dai tasti colorati e dai tasti numerici, per poi aggiungerli come ascoltatori : repository = new UserEventRepository("UserRepository"); repository.addallcolourkeys(); repository.addallnumerickeys(); manager = EventManager.getInstance(); manager.addusereventlistener(this, repository); Per definire poi l HScene, per prima cosa istanziamo un HSceneFactory attraverso il suo costruttore di default, poi utilizziamo un suo metodo per creare un HScene a schermo pieno, indirizzando l HScreen e la periferica grafica di default. Per ultima cosa si setta il formato dell HScene, il suo layout e la sua visibilità: HSceneFactory hsf = HSceneFactory.getInstance(); scene = hsf.getfullscreenscene( HScreen.getDefaultHScreen().getDefaultHGraphicsDevice()); scene.setsize(720,576); scene.setlayout(null); scene.setvisible(true); 61

62 Aggiungiamo quindi due HContainer che serviranno da contenitori: il primo per l immagine di background e il secondo per i componenti della classe HAVi: contbg = new HContainer(0,0,710,567); cont = new HContainer(0,0,710,567); Potendo infatti lavorare su più livelli di grafica, aggiungendo alla scene i vari HContainer in un determinato ordine, potremo sovrapporli nella visualizzazione: scene.add(cont); scene.add(contbg); scene.setvisible(true); scene.repaint(); Nel resto del metodo vengono dimensionati e posizionati tutte le immagini, i pulsanti (HgraphicButton) e le aree testo (Htext) necessarie alla grafica di base, seguento il layout descritto al paragrafo precedente. Le variazioni di grafica dovute alle interazioni con l utente vengono specificate, suddivise per tasti, nel metodo usereventreceived, di cui ne vediamo la prima parte: public void usereventreceived(userevent event){ switch (event.getcode()){ case HRcEvent.VK_7: if(pressed==true) {<istruzioni> pressed=false;} else { pressed=true; } scene.repaint(); break; [.<implementazione case degli altri tasti>.] } La presenza dell if-else è dovuta al fatto che le istruzioni del case verrebbero altrimenti eseguite due volte: all evento di pressed e all evento di release. La grafica finale è quella presentata in figura 4.5: 62

63 Figura 4.5: Interfaccia grafica dell applicazione Per quanto riguarda gli altri due importanti stati del ciclo di vita della nostra applicazione dobbiamo ricordarci che, nel metodo pausexlet(), di rimuovere tutti i tasti dallo userrepository e tuttii listener dall EventManager, così se un altro applicativo entra in esecuzione ed inoltra la richiesta di ricezione di eventi, non vi saranno conflitti. Inoltre si notifica alla piattaforma che l applicazione è in pausa, tramite il metodo notifypaused() chiamato sull oggetto context: public void pausexlet(){ repository.removeallcolourkeys(); repository.removeallarrowkeys(); repository.removeallnumerickeys(); manager.removeusereventlistener(this); context.notifypaused(); } 63

64 Nel caso invece sia richiesta la distruzione dell applicazione, il metodo destroyxlet() compie le stesse azioni di pausexlet() ed in più pone l HScene a null in modo che venga collezionato dal garbage collector: public void destroyxlet(boolean unconditional) throws XletStateChangeException{ if (unconditional) { repository.removeallcolourkeys(); repository.removeallarrowkeys(); repository.removeallnumerickeys(); manager.removeusereventlistener(this); if(scene!= null) { scene.setvisible(false); scene.removeall(); HSceneFactory.getInstance().dispose(scene); scene = null; } context.notifydestroyed(); }else {System.out.println(this.getClass().getName() +" : Richiesta di destroy rifiutata!"); } } 4.3 Struttura dei file Come anticipato nel paragrafo 3.3, per ottimizzare i tempi di navigazioe, i contenuti sono stati inseriti in file binari. Non avendo ancora a disposizione contenuti realistici per questa applicazione, si è supposto di scaricare da un database nel server di LepidaTV la lista di tutti gli Username degli utenti iscritti, la Password associate, e per ciascuno di essi le notizie disponibili, Si sono creati quindi, con uno script in Java, due file: uno contenente una lista ordinata di 1000 Username e l altro contenente la lista di Password, ordinate secondo lo Username corrispondente con, di seguito ad ognuna di esse, un numero randomico di notizie (da nessuna a 5 notizie). 64

65 int NumLettereLogin=3; int NumLetterePass=5; String alfabeto="abcdefghijklmnopqrstuvwxyz"; String Login="", Pass=""; int ind=0; Integer puntint; try{ String[] Notizie={"Questa e' la notizia uno.","invece questa e' la seconda.","ora la terza.","ma di piu', quarta.","infine quinta."}; RandomAccessFile flogin = new RandomAccessFile("username.txt","rw"); RandomAccessFile fpass = new RandomAccessFile("notizie.txt","rw"); for(int i=0; i<1000; i++) { } Login=""; int resto=0; resto=i; for(int w=numletterelogin-1; w>=0; w--) { } Pass=""; resto=i; ind=(int)(resto/math.pow(26, w)); Login=Login+alfabeto.charAt(ind); resto=(int)(resto%math.pow(26, w)); for(int w=numletterepass-1; w>=0; w--) { } ind=(int)(resto/math.pow(26, w)); Pass=Pass+alfabeto.charAt(ind); resto=(int)(resto%math.pow(26, w)); flogin.write(login.getbytes()); flogin.write(inttobytearray((int)fpass.getfilepointer())); fpass.write(pass.getbytes()); int random = (int)(math.random()*5); fpass.write(inttobytearray(random)); for(int z=0; z<random; z++){ fpass.write(inttobytearray((int)(notizie[z].getbytes()).length)); fpass.write(notizie[z].getbytes()); } flogin.close(); fpass.close(); } 65

66 Questi file binari sono in seguito creati secondo la seguente struttura: Figura 4.6: Struttura file binari Supponiamo allora che la struttura di sinistra sia del file username.txt, e la struttura di destra quella del file notizie.txt. Quando un utente inserisce Username e Password, vengono eseguiti i seguenti passi: 1. Si compie una ricerca dicotomica nel file username.txt per trovare il nome utente inserito. L algoritmo per la ricerca dicotomica che ottimizza le tempistiche di recupero dello Username inserito è il seguente: private static int ricercadicotomica(string user, int cardine1, int cardine2, RandomAccessFile f){ int righe=0; int medio=-1; int result=-1; String AppString; byte[] AppByte= new byte[3]; try{ if(cardine1<cardine2){ medio=(cardine1+cardine2)/2; f.seek(medio*(3+4)); //f.seek(medio*(4)); f.read(appbyte); AppString=new String(AppByte); System.out.println("AppString: "+AppString); if(user.compareto(appstring)<0){ 66

67 } result=ricercadicotomica(user, cardine1, medio-1, f); } else if(user.compareto(appstring)>0){ result= ricercadicotomica(user, medio+1, cardine2, f); } else if(user.compareto(appstring)==0){result=medio;} } if(cardine1==cardine2){ f.seek(cardine1*(3+4)); f.read(appbyte); AppString=new String(AppByte); if(user.compareto(appstring)==0){result=cardine1;} else{result=-1;} } if(cardine1>cardine2){result=-1;} return result; 2. Si leggono i 4 byte successivi e con il metodo seek() si comincia a leggere nel file notizie.txt al punto in cui si trova la password corrispondente a quel nome utente (che si suppone unico, come potrebbe ad esempio essere il codice fiscale) 3. Si controlla se la password immessa dall utente corrisponte e in quel caso si leggono i 4 byte successivi che contengono il numero di notizie associate a quelle credenziali 4. Si leggeranno poi i primi 4 byte che ci indicheranno la lunghezza in byte del titolo, che ci dirà quindi quanti dei seguenti byte leggere e inserire nel titolo, e si compie la stessa operazione per il testo descrittivo della notizia. 5. Si tiene in memoria il puntatore all inizio di ogni notizia man mano l utente le scorre in avanti, in un vettore grande quanto il numero di notizie letto al passo 3, così da poterle immediatamente scorrere all indietro. Nel caso della lettura della notizia successiva infatti, associata alla pressione del tasto 9 dovremo semplicemente ripetere il passo 4: case HRcEvent.VK_9: if(pressed==true){ try { RandomAccessFile fin = new RandomAccessFile("notizie.txt","r"); if(numnotizia<numnotizie-1){ numnotizia++; fin.seek(currentnews); byte[] dimnews = new byte[4]; fin.read(dimnews); 67

68 newslength[numnotizia]=bytearraytoint(dimnews); byte[] News = new byte[bytearraytoint(dimnews)]; fin.read(news); String appnews = new String(News); descr.settextcontent(appnews,h Visible.NORMAL_STATE); currentnews=(int)fin.getfilepointer(); } fin.close(); } catch(exception e) { e.printstacktrace();} pagenumber.settextcontent((numnotizia+1)+"/"+numnotizie, HVisible.NORMAL_STATE); pressed=false; } else{pressed=true;} scene.repaint(); break; Per la lettura della notizia precendente invece sfrutteremo le informazioni dei puntatori memorizzati dipo ogni lettura in avanti: case HRcEvent.VK_7: if(pressed==true){ try{ RandomAccessFile fin = new RandomAccessFile("pass.txt","r"); if(numnotizia>0){ numnotizia--; fin.seek(currentnews-newslength[numnotizia+1]- newslength[numnotizia]-8); byte[] dimnews = new byte[4]; fin.read(dimnews); byte[] News = new byte[bytearraytoint(dimnews)]; fin.read(news); String appnews = new String(News); descr.settextcontent(appnews, HVisible.NORMAL_STATE); currentnews=(int)fin.getfilepointer(); } fin.close(); } catch(exception e){ e.printstacktrace(); } pagenumber.settextcontent((numnotizia+1)+"/"+numnotizie, HVisible.NORMAL_STATE); pressed=false; } else{pressed=true;} scene.repaint(); break; Le prove fatte con questa struttura, ed un file quindi di circa 2500 contenuti, hanno permesso una navigazione istantanea delle notizie una volta effettuato il login. 68

69 Capitolo 5 Funzionamento su LepidaTV Con i file strutturati nel modo appena spiegato e la grafica illustrata precedentemente, non resta che passare all ultimo passo: la messa in onda del servizio sul canale televisivo. 5.1 OpenCaster Nel lavoro effettuato per questa tesi è stato utilizzato il software open source di Avalpa, OpenCaster, rilasciato appena il 20 giugno del OpenCaster è un generatore di transport stream MPEG-2 e manipolatore di pacchetti che permette di creare le tabelle SI che abbiamo prima spiegato, trasformare un filesystem in un DSM-CC carousel e multipexare transport stream a bit-rate costante. Vediamo quali sono i passaggi necessari per trasmettere un servizio interattivo PMT e AIT Tables OpenCaster offre file in linguaggio python in grado di generare le tabelle SI necessarie da inserire nel transport stream, che devono ovviamente essere precedentemente configurati. Per quanto riguarda strettamente le applicazioni interattive, le SI tables da generare saranno due: PMT ed AIT. Per la tabella PMT si ha una prima parte, qui non riportata, di descrizione di uno stream_loop_item per la tipologia di stream MPEG-2 video, uno per MPEG-2 video ed uno per AIT. In seguito a questi vi sarà uno stream_loop_item per ogni applicazione che si vuole trasmettere, con la seguente sintassi: stream_loop_item( stream_type = 11, elementary_pid = 2003, element_info_descriptor_loop = [ association_tag_descriptor( association_tag = 0xB, use = 0, selector_lenght = 0, transaction_id = 0x , timeout = 0xFFFFFFFF, private_data = "", 69

70 ], I parametri più importanti sono i seguenti: ) ), stream_identifier_descriptor( component_tag = 0xB, ), carousel_identifier_descriptor( carousel_id = 1, format_id = 0, private_data = "", ), data_broadcast_id_descriptor( data_broadcast_id = 240, ID_selector_bytes = "", ), ] stream_type = 11 dove 11 è l identificativo della tipologia DSMCC. elementary_pid: identificativo del DSMCC. association_tag: identifica il carousel, è referenziato nella AIT ed è usato nella generazione del DSMCC tramite oc-update.sh come vedremo nel paragrafo component_tag: identico all association_tag, necessario in quanto a seconda della tipologia del decoder, alcuni cercheranno il campo association_tag e altri il component_tag: il valore deve essere quindi lo stesso. carousel_id: diverso da association/component tag ma con lo stesso proposito di identificare il carousel. Per l AIT invece si avrà all interno di application_loop un application_loop_item per ogni applicazione presente del transport stream: ait = application_information_section( application_type = DVB_J_application_type, common_descriptor_loop = [], application_loop = [ application_loop_item( organisation_id = 10, application_id = 1001, application_control_code = 2, application_descriptors_loop = [ transport_protocol_descriptor( protocol_id = MHP_OC_protocol_id, transport_protocol_label = 1, remote_connection = 0, component_tag = 0xB, ), application_descriptor( application_profile = 0x0001, version_major = 1, version_minor = 0, version_micro = 2, service_bound_flag = 1, 70

71 ) ], ), ], application_priority = 1, transport_protocol_labels = [1], ), application_name_descriptor(application_name = "Esempio"), dvb_j_application_descriptor(parameters = ["dvb://1/sample8"]), dvb_j_application_location_descriptor( base_directory = "/", class_path_extension = "", initial_class = "EsempioMainClass", ), In questo caso invece i parametri più importanti sono: application_control_code: 1 indica autostart, ovvero l applicazione parte immediatamente con la sua esecuzione, 2 indica present, ed il decoder in questo caso aggiunge l applicazione alla lista di scelta delle applicazioni per l utente, 3 indica destroy e segnala di fermare l esecuzione dell applicazione, 4 è kill e ferma l esecuzione. component_tag: ha lo stesso significato del caso PMT e deve essere coerente con quello che lì è stato indicato. Application_name_descriptor: nome dell applicazione che l utente vedrà nella lista standard delle applicazioni che si apre premendo il tasto app del telecomando. Initial_class: classe iniziale da eseguire Generazione di uno stream DSM-CC Per implementare un carousel in OpenCaster ci deve essere una directory contenente tutti i file necessari al funzionamento dell applicazione, come ad esempio i file grafici ed i file di testo con i contenuti, per poterla inserire poi in un transport stream, che va ricreato ogni volta che vi è un cambiamento nella directory. Il comando che genera il transport stream è il seguente: oc-update.sh [object_carousel_directory] [association_tag] [module_version] [dsmcc_pid] [carousel_id][compress_on] [padding_on] [clean_off] I significati dei vari parametri sono i seguenti: carousel_directory: la directory da inserire nel transport stream. Il suo nome sarà quello che verrà dato al file.ts di uscita. 71

72 association_tag: dve essere quello referenziato nella PMT ed AIT. Modules_version: intero che va da 0 a 15 e deve essere lo stesso per tutti i moduli. dsmcc_pid: pid del transport stream che verrà generato. Anche questo dovrà corrispondere a quello associato in PMT. carousel_id: Identificativa di ogni carousel che viene generato, è referenziato in PMT. compress_on, padding_on, clean_off: booleani che indicano rispettivamente se il carousel va compresso, se deve essere inserito del padding nelle varie sezioni e se devono essere eliminati i file temporanei. Un esempio di utilizzo può essere il seguente: oc-update.sh XletTest 0xB Che dalla cartella XletTest genererà il file XletTest.ts con 0xB come association tag da inserire in PMT ed AIT, 2003 come pid e 1 come identificativo del carousel Multiplexing Per trasmettere audio, video ed applicazioni, i transport stream generati andranno infine multiplexati. In Opencaster questo viene fatto tramite il seguente comando: tscbrmuxer [bitrate_ts1][ts1_name] [bitrate_ts1][ts1_name ] > muxed.ts Dove per ogni transport stream da trasmettere si specifica prima il suo bit rate poi il suo nome. Il file in uscita avrà bitrate pari alla somma dei bitrate dei vari transport stream multiplexati. Un esempio di transport stream con bit rate tipici da multiplexare per avere audio, video, una applicazione e le SI tables necessarie, è il seguente: tscbrmuxer b: firstvideo.ts b: firstaudio.ts b:3008 firstpat.ts b:3008 firstpmt.ts b:1500 firstsdt.ts b:1400 firstnit.ts b: XletTest.ts b:2000 firstait.ts > myfirsmuxed.ts 72

73 Con transport stream video firstvideo.ts, transport stream audio firstaudio.ts, applicazione XletTest.ts e le seguenti tabelle SI: PAT, PMT, SDT, NIT e AIT. 5.2 Messa in onda su LepidaTV Nello specifico del nostro caso quindi, dovremo effettuare le seguenti operazioni: Creare sul server di LepidaTV una cartella chiamata SecondaInterfaccia con al suo interno il file SecondXlet.class, che contiene il codice vero e proprio dell applicazione, i file username.txt e notizie.txt che contengono tutti gli utenti e le notizie aggiornate, e le immagini necessarie alla visualizzazione dell Xlet, come lo sfondo e i pulsanti delle istruzioni. Supponendo di avere già un altro servizio in onda con i parametri 0xB association tag, 2003 pid, 1 identificativo del carousel, modificare il file in python di OpenCaster che permette di creare le SI Tables nei seguenti modi: a. Nella parte di creazione della PMT aggiungere un secondo stream_loop_item: stream_loop_item( stream_type = 11, elementary_pid = 2004, element_info_descriptor_loop = [ association_tag_descriptor( association_tag = 0xC, use = 0, selector_lenght = 0, transaction_id = 0x , timeout = 0xFFFFFFFF, private_data = "", ), stream_identifier_descriptor( component_tag = 0xC, ), carousel_identifier_descriptor( carousel_id = 2, format_id = 0, private_data = "", ), data_broadcast_id_descriptor( data_broadcast_id = 240, ID_selector_bytes = "", ), ] ) 73

74 Così da assegnare association tag, pid e carousel id corrispondenti. b. Analogamente nella parte riguardante l AIT aggiungere un application loop item come segue: application_loop_item( organisation_id = 10, application_id = 1001, application_control_code = 2, application_descriptors_loop = [ transport_protocol_descriptor( protocol_id = MHP_OC_protocol_id, transport_protocol_label = 1, remote_connection = 0, component_tag = 0xC, ), application_descriptor( application_profile = 0x0001, version_major = 1, version_minor = 0, version_micro = 2, service_bound_flag = 1, application_priority = 1, transport_protocol_labels = [1], ), application_name_descriptor(application_name = "Test di Autenticazione"), dvb_j_application_descriptor(parameters = ["dvb://1/sample8"]), dvb_j_application_location_descriptor( base_directory = "/", class_path_extension = "", initial_class = "SecondXlet", ), ], ), Viene così indicato che la classe da eseguire è SecondXlet, e nella lista standard delle applicazioni che compare all utente alla pressione del tasto APP, apparirà in posizione 2 il nome di questo servizio: Test di Autenticazione. Eseguire il file in python e sostituire i file creati firstpmt.ts e firstait.ts ai transport stream che in precedenza contenevano queste due SI tables Dalla directory contenente la cartella SecondaInterfaccia generare lo stream DSMCC tramite il comando: oc-update.sh SecondaInterfaccia 0xC che crea il file SecondaInterfaccia.ts con associati i parametri indicati. 74

75 Seguendo il palinsesto, ad ogni cambio dell audio-video, verrà eseguito un multiplexing simile al seguente, per creare il transport stream finale da trasmettere: tscbrmuxer b: nuovovideo.ts b: nuovoaudio.ts b:3008 firstpat.ts b:3008 firstpmt.ts b:1500 firstsdt.ts b:1400 firstnit.ts b:2000 firstait.ts b: PrimaInterfaccia.ts b: SecondaInterfaccia.ts Come si può notare si possono associare bitrate differenti alle varie applicazioni, se ne può quindi assegnare una maggiore alla prima che, ad esempio ha già contenuti reali ed è già utilizzata, e assegnarne invece una minore alla seconda che è al momento in fase di test in attesa di dati non fittizi da mostrare. L utente quindi, una volta sul canale di LepidaTV, premerà il tasto APP, selezionerà la seconda applicazione, ovvero il nostro Test di Autenticazione, e verrà caricata la seguente Xlet, attualmente on-air: Figura 5.1: L applicazione in onda 75

76 Per arrivare a questa schermata sono stati inseriti dai file di esempio lo Username BAA e la rispettiva Password AABAA, a cui corrispondono 4 notizie, come si può notare nella parte in basso a destra dell area del contenuto, nella quale viene visualizzata la seconda di queste notizie. 5.3 Adattamento Web parallelo LepidaTV ha infine scelto di rendere disponibili anche sul suo sito web i servizi implementati per il canale televisivo, al fine di fornire gli stessi contenuti su entrambi i mezzi di comunicazione. Sempre seguendo il suo obiettivo di usabilità ha lasciato volutamente l interfaccia grafica identica a quella che si può vedere sulla tv, con l unica differenza che i tasti del telecomando saranno invece i numeri della tastiera del pc, o in alternativa possono essere semplicemente cliccate le immagini dei tasti dell area delle istruzioni di navigazione: Figura 5.2: L applicazione sul Web L applicazione è stata graficamente adattata per essere visualizzata correttamente su qualsiasi tipo di browser attualmente esistente. 76