Sistemi efficienti con autenticazione per TV Digitale - tlc.unife.it

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
Anno Accademico 2007/2008
i
Relatore:
Prof. Ing. GIANLUCA MAZZINI

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

Indice
Introduzione 5
1. . TV digitale terrestre interattiva 7
1.1. Struttura trasmissiva ........................................................................ 7
1.2. Il Transport Stream .......................................................................... 8
1.3. Service Information Tables ........................................................... 11
1.3.1. Struttura delle tabelle SI ....................................................... 12
1.4. Il protocollo DSM-CC .................................................................. 13
1.5. Gli standard di trasmissione ........................................................... 16
1.6. Lo standard MHP ........................................................................... 17
1.6.1. Standard di base ................................................................... 17
1.6.2. Architettura .......................................................................... 18
1.6.3. Esecuzione delle applicazioni .............................................. 20
1.6.4. Pofili .................................................................................... 20
1.6.4.1. Enhanced Broadcasting ............................................ 21
1.6.4.2. Interactive Broadcasting .......................................... 22
1.6.4.3. Internet Access ......................................................... 23
1.6.5. Il decoder interattivo ............................................................ 23
1.6.6. Interattività forte e debole ................................................... 25
2. Xlet e piattaforme di emulazione 27
2.1. Il software stack ............................................................................ 27
2.2. Le API JavaTV ............................................................................. 28
2.2.1. Ciclo di vita di una Xlet ........................................................ 29
2.2.2. Contesto di applicazione ....................................................... 30
2.3. Interfaccia grafica ......................................................................... 33
2.3.1. HAVi level 2 GUI ................................................................. 33
2.3.1.1. Coordinate in MHP ................................................... 39
2.3.1.2. HScene e HsceneTemplate ....................................... 40
iii

2.3.1.3. ... Il set di widgets HAVi .............................................. 42
2.3.1.4. Il Controllo remoto ...................................................... 43
2.4. Emulatori Open-Source ................................................................. 44
2.4.1. XleTView ............................................................................ 45
2.4.1.1. Limiti riscontrati .......................................................... 48
3. Meccanismi di autenticazione con bassa interattivi 51
3.1. Modello standardizzato ................................................................. 52
3.2. Scelta della bassa interattività e sue problematiche ....................... 53
3.3. Ottimizzazioni ................................................................................ 54
4. Esempio di implementazione 57
4.1. Accessibilità ed usabilità ................................................................ 57
4.2. Implementazione della grafica ....................................................... 61
4.3. Struttura dei file ............................................................................. 64
5. Funzionamento su Lepida TV 69
5.1. OpenCaster ...................................................................................... 69
5.1.1. PMT e AIT Tables ................................................................ 69
5.1.2. Generazione di uno stream DSM-CC ................................... 71
5.1.3. Multiplexing ......................................................................... 72
5.2. Messa in onda su LepidaTV .......................................................... 73
5.3. Adattamento Web parallelo ........................................................... 76
6. Conclusioni e sviluppi futuri ............................................................. 79
7. Elenco delle figure .............................................................................. 81
8. Bibliografia e sitografia ..................................................................... 83
iv

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 2010.
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

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

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

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

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

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

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

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.
1.3.1 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

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

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

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

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 1997. 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

1.6 Lo standard MHP
MHP, ovvero Multimedia Home Platform è uno standard molto giovane
rilasciato dal DVB project nella sua prima versione nel 2000. 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.
1.6.1 Standard di base
Figura 1.8: Set top box MHP
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

oadcast 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.
1.6.2 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

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

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.
1.6.4 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

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
1.6.4.1 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

1.6.4.2 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, ecommerce).
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

1.6.4.3 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 e-mail.
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.
1.6.5 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

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

• 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.
1.6.6 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

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

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

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

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.
2.2.1 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

• 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.
2.2.2 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

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

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

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.
2.3.1 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

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

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

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

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

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

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().
2.3.1.1 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

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
2.3.1.2 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

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

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.
2.3.1.3 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

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.
2.3.1.4 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 48-57
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

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

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 2004. 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 http://xletview.sourceforge.net/status/statuscurrent.html,
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

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:
Nome del primo canale
defaultbg.jpg
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

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:
SecondXlet
/home/elisa/workspace/SecondXlet
SecondXlet
47

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 = F4
2.4.1.1 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

• 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

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

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

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(" ",
"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

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

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

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

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

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 = 0.2126 * R + 0.7152 * G + 0.0722 * 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

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

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

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) {…pressed=false;}
else { pressed=true; }
scene.repaint();
break;
[….….]
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

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

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:
4.3 Struttura dei file
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!");
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

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=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

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

}
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

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

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 2008.
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.
5.1.1 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 = 0x80000000,
timeout = 0xFFFFFFFF,
private_data = "",
69

],
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 1.5.2.
• 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

)
],
),
],
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.
5.1.2 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

• 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 5 2003 1 1 0 0
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.
5.1.3 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:2300000 firstvideo.ts b:188000 firstaudio.ts b:3008 firstpat.ts
b:3008 firstpmt.ts b:1500 firstsdt.ts b:1400 firstnit.ts b:1000000 XletTest.ts
b:2000 firstait.ts > myfirsmuxed.ts
72

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 = 0x80000000,
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

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 5 2004 2 1 0 0
che crea il file SecondaInterfaccia.ts con associati i parametri
indicati.
74

• 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:2500000 nuovovideo.ts b:188000 nuovoaudio.ts
b:3008 firstpat.ts b:3008 firstpmt.ts b:1500 firstsdt.ts b:1400
firstnit.ts b:2000 firstait.ts b:1000000 PrimaInterfaccia.ts b:200000
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

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
http://www.lepida.tv/ 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

Infatti, all’ apertura del file index.html, viene per prima cosa effettato il
controllo sul browser in uso dall’ utente che vuole vedere l’ applicazione,
più nello specifico controlla se il browser è Internet Explorer, e in caso
contrario chiama un diverso file sul server, /FireFox/Xlet.html, che si adatta
benissimo graficamente anche in altri browser quali Opera, Safari e Google
Chrome:
Reindirizzamento in base al browser
if (document.all){ // Explorer
document.write("");
}
else { // FireFox
document.write("");
}
Questa distinzione in due file .html è stata effettuata in quanto Internet
Explorer interpreta diversamente i .css rispetto alla maggioranza dei
browser, ad esempio:
• Line-height: nel caso di Internet Explorer è intesa come l’altezza di
ogni linea all’ interno del box di riferimento, negli altri browser è
intesa come altezza totale del DIV.
• Bordi: In Internet Explorer ci sono di default, negli altri casi no.
• Overflow: nel caso di FireFox l’ overflow è hidden, ovvero se in un
DIV abbiamo del testo troppo grande, il DIV resterà della
dimensione specificata e non si vedrà il testo nella sua interezza. In
Internet Explorer invece è non hidden, e quindi il DIV si adatta
ingrandendosi, per visualizzare il testo interamente.
Il funzionamento dell’ applicazione per il Web segue i seguenti step:
1. Creare sul server una cartella Web con all’ interno il file index
spiegato prima che discrimina i browser, e due cartelle distinte, una
per FireFox ( e altri compatibili) e una per Internet Explorer. In
77

ognuna di esse vi sarà il relativo file HTML, il foglio di stile
associato .css, con le modifiche del caso a seconda del browser,
come accennato prima, e tutte le immagini necessarie alla
visualizzazione dell’ applicazione.
2. Si esegue un programma scritto in Java che crea i file di testo
contenenti le notizie da rendere disponibili all’ utente. In questo caso
specifico crea, come visto, file con notizie e credenziali fittizie, se si
avessero invece notizie disponibili su Web, scaricherebbe gli RSS
formattandoli in modo opportuno nei file.
3. Da questi file, tramite l’ esecuzione di un secondo programma scritto
in Java, viene creato un file javascript con tutte le notizie embedded
in array. Infatti adesso, essendo un’ applicazione Web, non abbiamo
più problemi di memoria o processori limitati, e si possono quindi
effettuare scelte implementative diverse e più semplici rispetto al
caso MHP.
4. Aggingere questo file .js in entrambe le cartelle Internet Explorer e
Firefox.
Con questo metodo quindi risulterà facile un aggiornamento dei contenuti,
che si presuppone giornaliero per i servizi offerti da Lepida, rendendoli
subito disponibili per essere navigati sia sul Web, che sul digitale terrestre,
dove verrà infatti eseguito sempre giornalmente lo stesso aggiornamento
per poi ricreare il nuovo Transport Stream dell’ applicazione interattiva.
78

Capitolo 6
Conclusioni e sviluppi futuri
Il lavoro svolto in questa tesi è stato quindi per prima cosa un analisi
approfondita degli standard e delle soluzioni tecnologiche per comprendere
le basi su cui si fonda la televisione digitale terrestre.
All’ interno di LepidaTV si è quindi proceduto con un’ analisi di modelli
standard di navigazione da poter applicare alle Xlet, seguendo una linea
guida all’ insegna dell’ usabilità ed accessibilità per quanto riguarda la
parte grafica.
Importante notare che la materia trattata è ancora in fase sperimentale ed
essendo pochissime le aziende e strutture che utilizzano questa tecnologia,
le conoscenze da loro acquisite nello sviluppo di applicazioni MHP non
sono divulgate sul Web.
Si sono scoperti quindi passo a passo durante lo sviluppo i limiti degli
emulatori esistenti, le loro differenze con i decoder reali, cercando di
superare le varie problematiche riscontrate.
Una parte molto importante in questa tesi è senz’ altro l’ utilizzo di
strutture di file innovative che permettano di navigare una grande quantità
di contenuti senza alcun tipo di ritardo: scopo diverso da quello per cui è
nata l’interattività del digitale terrestre, più improntata ad offrire una
versione di teletext avanzata, contenente poche informazioni e riguardanti
quasi esclusivamente il palinsesto televisivo ed i suoi approfondimenti.
La scelta di Lepida di offrire ai cittadini servizi di pubblica utilità è senz’
altro una novità in quest’ambito, ed offre non pochi ulteriori sviluppi.
La seconda parte di questo studio, che l’ha reso per me davvero
soddisfacente e stimolante, è stato invece l’esame della struttura
trasmissiva e di come effettuare una messa in onda dell’ applicazione,
potendo così, una volta finita la programmazione dell’ Xlet sul pc, vederla
subito funzionante su qualunque televisore collegato ad un decoder MHP.
Riassumendo: per questa tesi è stata creata un’ applicazione con lo scopo
di fornire notizie a seguito di una autenticazione, senz’ altro il passo
79

successivo sarà quello di adattarla a notizie e contenuti reali forniti da
diversi enti.
Si possono pensare ovviamente ulteriori modelli atti ad offrire tipologie di
servizi nettamente diversi.
Un altro modello già esistente e attualmente on-air prevede la navigazione
di contenuti basati su un filtro singolo o multiplo selezionato dall’ utente:
ad esempio, l’ ultimo sviluppo in atto al momento consiste nell’ anagrafica
canina di un canile dove l’ utente può visualizzare le caratteristiche dei cani
disponibili all’ adozione selezionandoli in base alla taglia.
Un modello non ancora sviluppato invece è quello di un test di autoverifica
da effettuare in seguito a lezioni trasmesse sul canale televisivo che si basi
su un modello senza più filtri né tastiere alfanumeriche, ma incentrato alla
navigazione di varie domande e alla scelta delle corrispondenti risposte.
Infine un ulteriore studio da completare è sicuramente quello riguardante i
dvb locator, per saper così come manipolare i transport stream in
trasmissione e poter quindi visualizzare nello spazio riservato il resize dell’
audio-video in onda mentre si utilizza l’ applicazione.
80

Elenco delle figure
Figura 1.1: Struttura trasmissiva del sistema digitale terrestre .......................7
Figura 1.2: Struttura di un transport stream ....................................................9
Figura 1.3: Suddivisione del transport Stream in più servizi diversi ..............9
Figura 1.4: Esempio di Transport Stream Analyzer ..................................... 10
Figura 1.5: Esempio di file da trasmettere in un carousel ............................. 14
Figura 1.6: Trasmissione dei moduli ............................................................. 15
Figura 1.7: I tre standard DVB ...................................................................... 16
Figura 1.8: Set top box MHP ........................................................................ 17
Figura 1.9: I livelli dell’ architettura MHP ................................................... 18
Figura 1.10: L’ architettura MHP .................................................................. 19
Figura 1.11: I profili MHP ............................................................................ 21
Figura 1.12: Schematizzazione di una catena DTT interattiva ..................... 22
Figura 1.13: Schematizzazione della struttura di un Set Top Box ................ 24
Figura 1.14: Modello delle relazioni nella catena DTT ................................ 25
Figura 2.1: Schematizzazione API che compongono stack MHP ................ 27
Figura 2.2: Ciclo di vita di un’ Xlet .............................................................. 29
Figura 2.3: Dialogo tra applicazione e context per la messa in pausa .......... 31
Figura 2.4: Dialogo tra applicazione e context per il riavvio ....................... 32
Figura 2.5: I tre layers del display TV .......................................................... 34
Figura 2.6: Periferiche Video e Grafiche multiple ........................................ 35
Figura 2.7: Sistemi di coordinate MHP ........................................................ 40
Figura 2.8: Esempio di visibilità in Hscene .................................................. 41
Figura 2.9: Key event per il controllo remoto ............................................... 43
Figura 2.10: Esempio di Implementation status di XleTView ..................... 45
81

Figura 2.11: Interfaccia grafica iniziale di XleTView .................................. 46
Figura 2.12: Inserimento nuova applicazione in XleTView ......................... 48
Figura 3.1: Calendario grafico dello switch-off in Italia .............................. 51
Figura 3.2: Interfaccia Standardizzata........................................................... 52
Figura 3.3: Struttura file sequenziale ............................................................ 55
Figura 4.1: Barra di navigazione alfanumerica ............................................. 58
Figura 4.2: Area delle istruzioni di navigazione ........................................... 59
Figura 4.3: Area delle istruzioni di navigazione ........................................... 60
Figura 4.4: Analisi nei casi di daltonismo ..................................................... 60
Figura 4.5: Interfaccia grafica dell’ applicazione ......................................... 63
Figura 4.6: Struttura file binari ...................................................................... 66
Figura 5.1: L’ applicazione in onda ............................................................. 75
Figura 5.2: L’ applicazione sul Web ............................................................ 76
82

Bibliografia e sitografia
Per il capitolo riguardante il Digital Video Broadcasting Project, la struttura
trasmissiva ed il Multimedia Home Platform, le informazioni sono state
reperite dalle seguenti fonti:
• Davide Turi, Roberto Borroni, La tv digitale terrestre. Manuale per il
professionista della televisione, 1^ edizione 2007
Presente anche sul web all’ idirizzo http://www.manualepraticodtt.it
• DVB – Digital Video Broadcasting official site, http://www.dvb.org
• ETSI TS 101 812 V1.3.1 (2003-06) Technical Specification, Digital
Video Broadcasting (DVB) – Multimedia Home Platform (MHP)
Specification 1.0.3
• Il libro bianco sulla televisione digitale,
http://www.agcom.it/provv/libro_b_00/librobianco00.htm
• Per la televisione digitale:
o http://www.dgtvi.it
o http://www.digitale-terrestre.com
o http://www.digitaleterrestre.tv.it
• MHP – Multimedia Home Platform official site, http://www.mhp.org
• Tesi su Java Portal, www.javaportal.it/rw/27468/editorial.html
• Wikipedia, http://www.wikipedia.org/
Per il capitolo sulle Xlet e sull’ emulatore usato nello sviluppo dell’
applicazione, le informazioni sono state elaborate dai seguenti siti:
• The Java Technology homapage, http://java.sun.com
• Java TV: Specification and Technical Overview,
http://java.sun.com/products/JavaTV
• Moka Byte, http://mokabyte.it
• The Interactive Web, http://www.mhp-interactive.org
• TV Without Borders, http://www.interactivetvweb.org/
• XletView, http://sourceforge.net/project/xletview
83

Per I capitoli riguardanti lo sviluppo dell’ applicazione con autenticazione e
la messa in onda su LepidaTV, le informazioni sono state reperite dai
seguenti siti:
• LepidaTV, http://www.lepida.tv
• Contrast Analyzer, http://webaccessibile.org/articoli/contrast-analyserversione-20/
• World Wide Web Consortium (W3C), http://www.w3.org/
• OpenCaster, http://www.avalpa.com/the-key-values/15-freesoftware/33-opencaster
84