Televisione Digitale Terrestre MHP

Transcript

1 Linguaggi & Tecnologie Multimediali: TV interattiva e mobile TV IconMediaLab Televisione Digitale Terrestre MHP Tesi di fine corso di Caretto Italo Alessandro Tutor del corso Tomeno Giuseppe Tutor aziendale Pocecai Gianfranco Milano 27/06/06

2 1. Digitale Terrestre - Mhp > Lo standard MHP Il Multimedia Home Platform è uno standard progettato dal DVB Project. Dopo anni di deliberazioni, DVB ha prodotto un insieme di specifiche che definiscono una piattaforma middleware. Partendo dal middleware, si è pensato di promuovere l'interoperabilità tra le applicazioni MHP ed i terminali, e tra i terminali stessi. Il risultato ottenuto è il pacchetto MHP, un insieme di misure centrate attorno alle specifiche MHP, basate su Java, ed un insieme di accordi stipulati per assicurare l'interoperabilità dei dispositivi presenti sul mercato. Nella sua concezione più semplice, MHP è un insieme di API Java che permettono la scrittura di applicazioni interoperabili. Queste vengono trasmesse come parte dello stream MPEG-2 che costituisce un segnale digitale televisivo, ed un ricevitore conforme a MHP può eseguire queste applicazioni sullo schermo. MHP definisce l'interfaccia tra le applicazioni interattive ed i terminali sui quali le applicazioni vengono eseguite; questa interfaccia separa le applicazioni dei diversi fornitori di servizi dagli specifici dettagli software e hardware dei terminali. MHP estende gli standard definiti da DVB che riguardano le trasmissioni televisive utilizzando segnali digitali, includendo i servizi interattivi, perciò le applicazioni DVB-MHP sono destinate alla tv digitale in tutte le sue versioni: satellitare, terrestre o via cavo, effettuando pochissimi cambiamenti all'hardware ed al software sottostante. MHP rappresenta un'apertura alla multimedialità attraverso il mezzo televisivo, poiché usa codici comuni a tantissime applicazioni. DVB-MHP risiede in cima al sistema operativo di un STB, e rappresenta il traduttore locale che permette al Set Top Box di capire quali applicazioni e servizi devono essere attivati. Durante la creazione di MHP, il DVB Project ha scelto di utilizzare Java per lo sviluppo del core del middleware. La sua realizzazionepermette ai produttori di contenuti di elaborare le proprie applicazioni indipendentemente dal sistema sottostante, sia esso presente nella versione di decoder satellitare, terrestre o via cavo. Alcuni elementi di MHP vengono forniti da altre organizzazioni: per esempio, le applicazioni Java si basano sulle API JavaTV, mentre vengono utilizzate le API HAVI per realizzare l'interfaccia grafica. L'architettura di MHP è definita su tre livelli: Resources: MPEG processing, dispositivi I/O, CPU, memoria e sistema grafico. System Software: usa le risorse con lo scopo di fornire una visione astratta della piattaforma alle applicazioni. Applications: le implementazioni di MHP includono un application manager per controllare le applicazioni che vengono eseguite.

3 MHP si basa sulla piattaforma DVB-J, che include una macchina virtuale definita nella Java Virtual Machine di Sun Microsystem. I pacchetti software forniscono l'application program interface (API), tra cui le JavaTV di Sun formano la parte principale. Le applicazioni accedono alla piattaforma tramite queste API; infatti l'implementazione del middleware MHP richiede la mappatura tra queste API e le risorse sottostanti. MHP permette l'implementazione di diverse applicazioni interattive. Alcuni esempi possono essere: EPG (Electronic Programme Guide), servizi informativi come il super teletext', applicazioni legate al contenuto televisivo, e-commerce, e-government, internet, servizi meteo, di traffico e di pubblica utilità, giochi stand-alone, pubblicità interattive. Nello standard MHP tali applicazioni vengono chiamate Xlet e possono essere composte solo da tipologie precise di dati: classi java, file xml o txt, immagini png, jpg o gif, audio mp2 e video mpg. Le Xlet per essere trasmesse necessitano di un preventivo impacchettamento in moduli di dimensione massima di 64Kbyte. La sequenza di moduli che compone un'applicazione di solito viene associata ad un particolare canale tv. Tale associazione avviene

4 nel Multiplexer, dove è possibile creare un'associazione per ogni Xlet trasmessa. A questo punto il flusso in uscita dal Multiplexer (il Transport Stream) viene modulato in una delle 3 tipologie possibili definite dal Digital Video Broadcasting: terrestre(dvb-t), satellitare (DVB-S) e cavo(dvb-c). Dopo la modulazione il segnale viene trasmesso e quindi ricevuto dai terminali. Il middleware del ricevitore contiene un componente, l'application manager, che è responsabile del monitoring dei servizi e della gestione delle applicazioni; segnala all'utente la lista delle applicazioni MHP disponibili sul canale televisivo. Prima che l'application manager possa eseguire un'applicazione MHP, devono accadere alcune cose: la prima è che il ricevitore deve sapere se esiste un'applicazione MHP; in seguito deve sapere se un utente ha il permesso di eseguirla in un dato momento; infine il decoder deve essere capace di accedere alle risorse necessarie per eseguire l'applicazione, come i file class ed i file data e asset. Quando l'utente effettua una selezione dalla lista delle applicazioni disponibili, l'application manager inizia la fase di download in memoria dei moduli relativi all'applicazione scelta. Non tutti i moduli che compongono l'applicazione vengono scaricati: il download avviene solo per quelli necessari alla partenza della Xlet. Successivamente, e solo se realmente necessari, verranno scaricati anche quelli rimanenti. Questo meccanismo somiglia al modello di caricamento delle pagine del televideo ed è pensato per ridurre i tempi di attesa del telespettatore. I soggetti attivi nella trasmissione dei segnali digitali e delle applicazioni MHP sono i seguenti: Content Producer, che elabora le applicazioni MHP, come giochi, EPG o servizi informativi. Broadcaster, che si occupano della diffusione dei canali televisivi e della aggregazione delle applicazioni interattive. Operatori di rete MHP. In alcuni casi, come nella trasmissione satellitare, l'operatore di rete non coincide con il broadcaster, perciò le applicazioni MHP vengono aggregate da un operatore di rete prima della trasmissione. Venditore dei terminali MHP: l'elemento più importante della catena MHP è il set top box, sul quale le applicazioni MHP vengono eseguite. All'interno dello standard vengono definiti 3 profili, per evidenziare i servizi che possono essere forniti in base alle tecnologie disponibili. Tale Profilo si riferisce ad un'area applicativa e, di conseguenza, alle capacità dei STB; quindi esiste un forte legame tra i profili e le release dello standard. Sebbene ci siano tre profili, le specifiche MHP rilasciate sono solamente due; il motivo è che le funzionalità dei primi due profili sono all'incirca le stesse, perciò sono stati incorporati in una sola specifica. I tre profili su cui si basa MHP sono: Enhanced Broadcast, definito nella specifica MHP 1.0 (ES ); Interactive TV, definito nella specifica MHP 1.0 (ES ); Internet Access, definito nella specifica MHP 1.1 (TS );

5 Oltre alla definizione dei profili, gli standard MHP si occupano di altre questioni, come la piattaforma DVB-J (Java), i meccanismi MHP di sicurezza, i protocolli di download delle applicazioni. Il profilo Enhanced Broadcast è il profilo base ed è stato progettato per mostrare le funzionalità del sistema middleware esistente e le applicazioni possibili da eseguire. Come suggerisce il nome, questo profilo è adatto per Set Top Box con nessuna o poca capacità del canale di ritorno e rappresenta il più semplice dei tre profili in termini di prestazioni. Permette solamente l'arricchimento del contenuto audio-video con informazioni e immagini visualizzabili e navigabili sullo schermo tv. Per questo profilo non sono richieste performance particolari dei set-top box. Comprende la Java virtual machine, le API Java DVB, i protocolli di trasporto broadcast e le opzioni HTML. Il profilo Interactive TV è il profilo intermedio che permette di utilizzare il canale di ritorno per fornire servizi multimediali interattivi più complessi rispetto al profilo base; contiene estensioni di API Java più appropriate per l'interattività ed il supporto al canale di ritorno, nonché protocolli di trasporto migliori. Infine il profilo Internet Access considera STB ancora più sofisticati, con un potere di elaborazione ed una memoria maggiori. Permette, tramite il canale di ritorno, di accedere ai contenuti di Internet. Questo profilo necessita di performance di alto livello essendo obbligatoria l'adozione di un browser internet e di un client di embedded nel set-top box. Contiene le API Java per l'accesso ad internet, nonché un elemento HTML opzionale chiamato DVB-HTML. Lo standard di base è costituito dalla specifica MHP 1.0 (ES ). La specifica 1.0.X contiene: l'architettura base di MHP; informazioni dettagliate sui profili Enhanced Broadcasting ed Interactive TV ; diversi formati contenuti in MHP, che includono JPEG, MPEG-2 video e audio;

6 protocolli di trasporto, che includono DSM-CC per la trasmissione broadcast e IP per il canale di ritorno; modelli di applicazione DVB-J; modelli di applicazione DVB-HTML; allegati al profilo DSM-CC, una presentazione testuale e varie API; MHP 1.0.X specifica l'ambiente dove si possono eseguire le applicazioni per la tv interattiva digitale, indipendentemente dall'hardware e dal software sottostante, che sono specifici del produttore di STB. La specifica MHP 1.0 fornisce un insieme di caratteristiche e funzioni richieste dai profili enhanced broadcasting' ed interactive broadcasting'. In seguito è stata emanata la specifica MHP 1.1 (TS ) per implementare il profilo Internet Access. MHP 1.1.X contiene: informazioni dettagliate sui profili Interactive TV ed Internet Access ; la disponibilità per l'immagazzinamento delle 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; specifiche di DVB-HTML; supporta la gestione di plug-in interoperabili (per il supporto di formati di applicazioni non conformi); supporto per i riferimenti bidirezionali tra il contenuto di MHP ed il contenuto internet; MHP 1.1 è stata sviluppata basandosi sulla specifica MHP 1.0 con lo scopo di supportare meglio l'uso del canale di interazione e per specificare gli elementi che promuovono l'interoperabilità con il contenuto internet. Infatti MHP 1.1 è semplicemente un'altra versione della specifica MHP 1.0, basata sugli stessi file sorgente. Perciò in gran parte il contenuto di MHP 1.0 è ripetuto in MHP 1.1. Con MHP 1.1, grazie al profilo Internet Access, le applicazioni possono controllare le operazioni basilari dei client residenti su internet (web browser, ). Per aggiungere queste funzionalità ed integrare il formato applicativo DVB-J, MHP 1.1 ha definito un nuovo tipo di applicazione opzionale: DVB-HTML, che è un linguaggio di mark-up basato su HTML; permette ad un ricevitore di presentare le applicazioni della tv interattiva digitale in HTML. Le specifiche DVB-HTML presentano le stesse estensioni e restrizioni delle specifiche del linguaggio W3C esistente. Il software stack MHP è un progetto complicato. L'approccio a livelli utilizzato da MHP, con la possibilità di costruire API MHP sopra altre API MHP, rende possibile un approccio modulare nella costruzione del software.

7 Le API possono essere divise in due parti. Una parte si occupa dei servizi relativi agli stream MPEG, l'altra permette la costruzione di applicazioni direttamente sopra le API pjava. Le API principali che si occupano di MPEG sono le API section filtering; le altre API che riguardano MPEG sono costruite sopra di esse. Le API service information analizzano le sezioni, che contengono le tabelle Service Information, per costruire il database Service Information che costituisce il nucleo delle API SI. Le API DSM-CC analizzano le sezioni DSM-CC direttamente, ed utilizzano le API service information per cercare quali stream in un servizio contengono gli object carousel DSM-CC. Le API tuner control si affidano alle API SI per individuare il transport stream che deve essere sintonizzato. Una volta che si hanno le informazioni sulla frequenza e sulla polarità, si può accedere al tuner hardware per sintonizzarsi sul corretto transport stream. Le API JavaTV service selection utilizzano le API SI con lo scopo di trovare il servizio che deve essere sintonizzato. Fatto questo, si usano le API tuning e JMF per sintonizzare il transport stream corretto e visualizzare il servizio. Le API application management si affidano alle API service selection (poiché ogni applicazione è associata ad un servizio), quindi c'è una relazione importante tra API service selection ed application manager. Le API service selection utilizzano le API application management per terminare le applicazioni quando viene selezionato un nuovo servizio o quando viene distrutto un service context. DVB ha incominciato ad occuparsi di MHP dal Considerando il lavoro compiuto dal DVB nella produzione di specifiche per la trasmissione televisiva digitale, lo sviluppo di uno standard per l'utilizzo di applicazioni interattive rappresenta un aspetto chiave per la transizione dalla tv analogica a quella digitale. 2. Digitale Terrestre - Mhp > Trasmissione digitale e transport stream

8 In un sistema broadcast digitale, una tipica struttura trasmissiva potrebbe essere la seguente: In questa struttura, l'encoder viene usato per convertire il segnale analogico in ingresso in uno digitale con formato MPEG-2. Un encoder può generare due tipi di stream MPEG. Il primo tipo di stream è il constant bit rate; questi stream hanno sempre il solito bit rate, non interessandosi della complessità del segnale. Se il segnale è troppo complesso per essere codificato nel bit rate specifico, la qualità viene ridotta; d'altra parte, se vengono utilizzati meno dati rispetto al bit rate specificato, lo stream viene riempito con pacchetti nulli fino al raggiungimento del bit rate corretto. Questo codifica rende l'elaborazione semplice, ma viene sprecata della banda. L'altro tipo di stream che può essere generato è quello a bit rate variabile. In questo caso il bit rate dello stream può essere modificato dinamicamente, così la banda utilizzata varia in base alla complessità del segnale. Poiché alcune immagini hanno bisogno di maggiore banda per la codifica rispetto ad altre, la qualità viene mantenuta costante mentre l'occupazione di banda cambia. Lo stream a bit rate variabile comporta una elaborazione un po' più complessa, ma fornisce maggiori vantaggi quando diversi stream MPEG vengono multiplexati insieme. Il multiplexer prende uno o più stream MPEG e li associa in un singolo transport stream. Gli stream in ingresso possono essere elementary stream, altri transport stream oppure dati MPEG semplici. Ogni transport stream di solito ha a disposizione una larghezza di banda prefissata, che dipende dal mezzo di trasmissione e dalla rete trasmissiva. Il compito del multiplexer è inserire un insieme di servizi in questa banda. Il modo più facile per farlo è usare uno stream MPEG a bit rate costante, poiché si sa esattamente quanta banda utilizza lo stream, quindi configurare un multiplexer risulta semplice. Questa soluzione è però inefficiente, poiché non è detto che tutti gli stream usino tutta la banda a disposizione: il problema dello spreco della banda è molto

9 importante, in quanto i costi per la trasmissione sono alti, specialmente per quella satellitare, perciò è consigliabile trasmettere meno pacchetti nulli possibile. Per questo motivo è meglio utilizzare stream MPEG a bit rate variabile, insieme ad una tecnica chiamata statistical multiplexing. Mentre il bit rate di ciascuno stream può variare considerevolmente, queste variazioni sono minori considerando diversi stream multiplexati insieme. In questo modo il problema del bit rate variabile è più facile da trattare: riservando un buffer separato per ogni stream, il multiplexer può disporre i pacchetti nel modo più efficiente. I segnali digitali non possono essere trasmessi direttamente: prima devono essere modulati, quindi convertiti in segnali analogici per trasmetterli utilizzando segnali radio o segnali elettrici su cavo. Le trasmissioni satellitare, terrestre e cablata possiedono caratteristiche differenti, perciò utilizzano modulazioni diverse. Il modulation scheme è il modo in cui viene convertita l'informazione digitale in un segnale analogico trasmissibile. Il meccanismo di trasmissione satellitare utilizza la modulazione QPSK, il cavo la QAM, la trasmissione terrestre l'ofdm. Cavo e satellite utilizzano uno schema di modulazione simile; la trasmissione terrestre utilizza invece uno schema differente per fornire una maggiore resistenza agli errori causati dai segnali riflessi. La modulazione viene effettuata dal modulatore, che prende un transport stream in ingresso e produce una uscita analogica passata al dispositivo di trasmissione. Dopo l'utilizzo del modulatore, i segnali trattati sono analogici e riguardano le trasmissioni radio. I segnali vengono modulati alle basse frequenze, quindi vengono trasmessi. Le frequenze di trasmissione in realtà sono molto più alte, e potrebbe essere difficile modulare direttamente i segnali a tali frequenze. Per questo i segnali vengono modulati a bassa frequenza, quindi vengono convertiti ad alta frequenza prima della loro trasmissione. Questo processo viene effettuato utilizzando un upconverter, che non fa altro che convertire il segnale ad una frequenza più alta. Ogni transport stream viene trasmesso ad una frequenza diversa, così l'upconverter avrà impostazioni diverse per ogni transport stream gestito. Alla fine del processo il segnale è pronto per la trasmissione, perciò c'è bisogno di un trasmettitore e di un'antenna. Il segnale televisivo digitale viene trasmesso come uno stream di dati MPEG-2, detto transport stream. Il data rate di un transport stream è di circa 40 Mb/s, sufficiente per sette/otto canali televisivi distinti. Un transport stream è composto da un insieme di sotto-stream', gli elementary stream, dove ciascuno può contenere o una traccia audio codificata MPEG-2, o una traccia video MPEG-2, o alcuni dati incapsulati in uno stream MPEG-2. Ogni elementary stream possiede un PID che agisce da identificatore di pacchetto unico per quel dato elementary stream all'interno di un transport stream. Di seguito viene mostrato il processo di costruzione di un transport stream. Si consideri un transport stream che contenga un singolo canale TV, supponendo di avere una sola traccia video ed una sola traccia audio. La prima cosa da fare è codificare il video e l'audio nel formato MPEG-2 utilizzando un

10 codificatore MPEG-2, hardware oppure software. Alla fine della codifica si ottengono due elementary stream, uno contenente la traccia audio codificata MPEG-2 ed uno contenente la traccia video. Questi due stream dovrebbero avere entrambi la stessa lunghezza, con le tracce contenute che iniziano dal solito istante, in modo che audio e video risultino sincronizzati. Quindi è possibile codificare i dati in uno stream MPEG-2, utilizzando un tool che genera uno stream MPEG-2 da una directory gerarchica; questo processo produce un altro elementary stream. In questo caso non sussistono problemi temporali, poiché i dati vengono semplicemente ripetuti nello stream e non devono essere perfettamente sincronizzati con gli altri stream, a differenza di audio e video. A questo punto sono state ottenute tutte le parti del canale TV, detto anche servizio, codificate in stream MPEG-2 separati. Adesso bisogna multiplexare i vari stream in un singolo stream più grande, il transport stream, utilizzando un multiplexer MPEG-2. Questo tool assegna un Packet Identifier (PID) ad ogni stream; gli elementary stream vengono suddivisi in transport packet, dove ogni pacchetto è lungo 188 byte e viene identificato tramite il PID. Il multiplexer prende questi transport packet e li inserisce nel transport stream. Ogni stream avrà un bit rate differente: ad esempio sono necessari più dati per codificare un secondo di video piuttosto che un secondo di audio, quindi lo stream audio conterrà meno dati. Gli stream a bit rate più alto, come quelli video, avranno più pacchetti inseriti dentro il transport stream finale per ogni pacchetto audio o dati che viene aggiunto. Non è insolito che per ogni pacchetto di uno stream audio inserito, vengano inseriti due pacchetti dati e circa dieci pacchetti per il video. Tramite questo meccanismo si otterrebbe un transport stream che contiene un certo numero di elementary stream, senza indicare quali tipi di dati vengono trasportati, e come ricostruire tali stream nel ricevitore. Per risolvere questo problema, devono essere aggiunte altre informazioni al transport stream; questi dati vengono codificati in alcuni elementary stream che vengono aggiunti al transport stream durante la fase di multiplexing, detti service information. Il service information è un semplice database che descrive la struttura del transport stream. Contiene un certo numero di tabelle: ognuna descrive un servizio contenuto nel transport stream; tali tabelle elencano gli elementary stream che formano un servizio, evidenziano i PID degli stream ed i tipi di dati contenuti. Effettuando la descrizione di un transport stream tramite un service information piuttosto che includendo le informazioni all'interno di un elementary stream comporta un grande vantaggio: è possibile riutilizzare uno stesso elementary stream in diversi servizi. Se un transport stream contiene più servizi, si deve multiplexare tutti gli stream audio, video e dati di tutti i servizi presenti. Il service information descriverà quali elementary stream appartengono ai diversi servizi.

11 Alcune tabelle descrivono i servizi specifici contenuti in un transport stream, mentre altre sono più generali e descrivono la struttura del transport stream stesso. In alcuni casi gli elementary stream contenenti le service information vengono trasmessi con un PID fissato per rendere più facile la loro ricerca ai decoder, mentre, in altri casi, i PID delle SI vengono memorizzati in un'altra tabella SI. Le tabelle SI più importanti che si trovano in un transport stream DVB sono il Program Association Table (PAT) ed il Program Map Table (PMT). Il PAT è la tabella fondamentale per SI; è l'unica tabella che viene trasmessa con un PID fisso e mostra il PID dell'elementary stream che contiene il PMT di un servizio. Il PMT è la tabella che descrive come è composto un servizio. Questa tabella descrive tutti gli elementary stream di un servizio e notifica al ricevitore quale stream contiene il Program Clock Reference (PCR) MPEG per il servizio. Il PMT non viene trasmesso con un PID prefissato, ed esiste un PMT per ogni servizio contenuto nel transport stream. MHP definisce una tabella extra service information (SI) chiamata Application Information Table (AIT). Questa tabella viene trasmessa come qualsiasi altro servizio contenente un'applicazione MHP, e contiene la descrizione delle applicazioni MHP associate a quel servizio; ad esempio, se un servizio è associato a due applicazioni, questa tabella conterrà due voci. L'AIT contiene tutte le informazioni di cui un ricevitore ha bisogno per eseguire l'applicazione e per dire all'utente quali applicazioni sono disponibili. Include elementi come il nome dell'applicazione, la locazione dei file e qualsiasi argomento che deve essere passato

12 all'applicazione quando viene avviata. Ad ogni applicazione trasmessa è associato un identificatore memorizzato nell'ait. Questo identificatore permette alle altre parti del sistema di riferirsi all'applicazione univocamente. Ogni identificatore consiste di due parti, un organization ID a 32 bit, unico per ogni organizzazione che produce applicazioni MHP, ed un application ID a 16 bit. Quindi due applicazioni segnalate nello stesso AIT non possono avere i soliti organization ID e application ID. Le applicazioni possono essere avviate o fermate automaticamente dal ricevitore, in base all'indicatore di stato presente nell'ait. Questo status indicator dice 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. Le applicazioni vengono trasmesse come parte di un transport stream MPEG-2 in un Object Carousel DSM-CC. L'AIT contiene un application location descriptor che identifica l'object carousel che contiene l'applicazione, nonché il path dentro l'object carousel, poiché un object carousel può contenere più applicazioni. Quando viene selezionato un nuovo servizio che contiene un'applicazione MHP, il ricevitore cerca l'ait di quel servizio. Se ne trova uno, confronta l'elenco delle applicazioni segnalate con quelle attualmente in esecuzione. Le applicazioni che stanno girando ma che non sono segnalate nel nuovo AIT vengono terminate, mentre ogni applicazione segnalata nel nuovo AIT viene avviata automaticamente. In AIT è presente un external application authorization descriptor che permette ad un broadcaster di indicare se un'applicazione precedentemente avviata può continuare ad essere eseguita. Nel linguaggio adottato da DVB, un transport stream viene detto anche multiplex, poiché consiste di un insieme di servizi multiplexati insieme. Su una frequenza di trasmissione può essere trasmesso uno ed un solo multiplex. Ogni multiplex di solito viene trasmesso con un data rate di circa 40 Mb/s; la scelta di questo data rate è dovuta alle limitazioni di banda del mezzo trasmissivo. All'interno del multiplex, un gruppo di elementary stream che costituisce un singolo canale televisivo viene chiamato service. Il numero di elementary stream che compongono un servizio non è detto che rimanga costante: può variare tra i diversi programmi di un particolare servizio (ad esempio, alcuni programmi possono essere trasmessi in più lingue o con più angoli di ripresa), o addirittura potrebbe cambiare all'interno dello stesso programma televisivo. Un programma televisivo viene detto event. Da un certo punto di vista, un servizio consiste di un numero di elementary stream che vengono trasmessi simultaneamente, ma da un altro punto di vista, il servizio consiste di una serie di eventi individuali trasmessi uno dopo l'altro. L'immagine seguente illustra un transport stream reale, ripreso da un transport stream analyzer.

13 Un program è sinonimo di service nella terminologia MPEG. Come illustrato dall'immagine, il multiplex contiene diversi servizi, dove ciascun servizio contiene almeno uno stream audio, uno stream video e di solito alcuni stream dati. La prima colonna indica il tipo di stream; i numeri che precedono il tipo rappresentano il particolare servizio. La seconda colonna mostra i valori PID di ogni elementary stream. Di solito gli elementary stream che appartengono allo stesso servizio possiedono valori PID simili. Le ultime due colonne mostrano, graficamente e numericamente, il bit rate di ogni elementary stream espresso in Mb/s. La traccia video digitale viene codificata con un bit rate di circa 3-5 Mb/s; il data rate totale di un servizio di solito è di 4-6 Mb/s. Questo bit rate comporta una qualità inferiore a quella di un DVD, ma permette ad un broadcaster di inserire più servizi all'interno di un multiplex. Ovviamente i broadcaster desiderano inserire più servizi possibili all'interno di un multiplex, con lo scopo di trasmettere più canali utilizzando la stessa banda di frequenza (infatti un multiplex occupa una banda di frequenza in modo esclusivo). Un transport stream riunisce fisicamente un insieme di servizi, ma tali servizi possono essere raggruppati anche logicamente. Un gruppo logico di servizi viene chiamato bouquet. Si consideri il caso in cui un broadcaster deve trasmettere 50 canali; la trasmissione avviene attraverso il satellite, ed il transport stream è limitato a 40 Mb/s (copre all'incirca 8 canali),

14 perciò c'è bisogno di 7 transport stream per trasmettere tutti i servizi. Si assuma di vendere l'accesso a questi servizi in pacchetti differenziati, così un utente può scegliere di acquistare il pacchetto base (che contiene 13 canali), il pacchetto per lo sport (8 canali sportivi) o il pacchetto per i film (5 canali). Per identificare quali canali appartengono ad un certo pacchetto, si potrebbe raggrupparli in un unico transport stream, ma, in questo caso, il pacchetto base è troppo grande per essere contenuto in un unico multiplex. Assegnando un bouquet ad ogni pacchetto, è possibile raggruppare i servizi nei transport stream in un modo efficiente, tramite un meccanismo di raggruppamento logico. Infine, un broadcaster viene detto anche network, e può trasmettere diversi transport stream. Riassumendo: Un network è un'azienda che trasmette uno o più transport stream. Un transport stream è uno stream MPEG-2 contenente diversi servizi. Un servizio è un canale TV e consiste di una serie di eventi consecutivi. Un evento è un singolo programma televisivo e comprende diversi elementary stream. Un elementary stream è uno stream MPEG-2, diviso in pacchetti, contenente tracce audio, video o dati binari codificati in MPEG-2. I servizi contenuti in diversi transport stream, possono essere raggruppati logicamente in un bouquet. Un servizio può essere identificato tramite tre valori, che sono: l'original network ID, identificatore del network che trasmette il servizio; il transport stream ID, per identificare un transport stream di un particolare network; il service ID, per identificare un servizio all'interno del transport stream. Per identificare un elementary stream si utilizza un component tag, che viene usato dai ricevitori per decidere quale servizio eseguire. 3. Digitale Terrestre - Mhp > Il protocollo DSM-CC DSM-CC è uno standard per la trasmissione di dati basato sullo stream MPEG; è uno dei metodi principali per trasmettere le applicazioni ai ricevitori. DSM-CC è l'acronimo di Digital Storage Media Command e Control. Le specifiche dello standard includono il controllo dei server video MPEG in una rete (play, stop e pausa di un video o di un audio), il supporto per la trasmissione di dati utilizzando MPEG-2, codici temporali per video MPEG-2, semplice trasmissione di dati e trasmissione di file system. DSM- CC si occupa di svariati argomenti, e ci sono diverse parti delle specifiche DSM-CC che non sono direttamente collegate alle specifiche MHP. I sistemi broadcast sono per loro natura unidirezionali. I dati vengono trasmessi da un trasmettitore ad un set top box, ed il ricevitore non può richiedere dati specifici al trasmettitore. Questo significa che un ricevitore non può richiedere un file specifico dal server, come avviene

15 invece con i PC, che possono richiedere un file dalla rete o da un hard disk. Poiché un ricevitore non può accedere ai dati in questo modo, deve essere trovata un'altra soluzione. La soluzione è semplice: il broadcaster trasmette periodicamente ogni file del filesystem, ed il ricevitore rimane in attesa per quelli che gli interessa. Le elaborazioni eseguite sul ricevitore dicono quali file interessano per la trasmissione. Un esempio pratico di questo tipo di soluzione è il sistema teletext: ciascuna pagina ha un numero preciso, e viene trasmessa a turno. Quando un utente digita il numero di una pagina, la televisione aspetta che la pagina venga trasmessa, dopodichè viene decodificata e visualizzata. Questo tipo di soluzione viene detto carousel. Nel DSM-CC i dati vengono trasmessi in blocchi chiamati moduli piuttosto che in pagine, ma il principio è lo stesso: i dati vengono divisi in moduli, ai quali vengono aggiunte alcune descrizioni, ed infine ogni modulo viene trasmesso a rotazione. DSM-CC supporta due tipi di carousel. Nella TV interattiva, la semplice trasmissione dei dati da un broadcaster ad un ricevitore viene effettuata utilizzando i data carousel DSM-CC. Un data carousel consiste in una serie di moduli, dove ogni modulo contiene un dato come un file; questo modulo può essere diviso in blocchi per rendere la trasmissione più facile. Si considerino due moduli. Supponiamo che il modulo A sia piccolo e che possa essere inserito dentro un singolo blocco, mentre il modulo B sia più grande e necessiti di due blocchi per mantenere tutti i suoi dati. Un data carousel semplice trasmetterà prima il blocco contenente il modulo A, quindi la prima parte del modulo B, infine il blocco contenente la seconda parte del modulo B; quindi rincomincia a trasmettere il blocco contenente il modulo A. Come fa il ricevitore a sapere quando termina il modulo A ed inizia il modulo B? Gli elementi di un carousel DSM-CC sono contenuti in un insieme di messaggi DSM-CC. Questi si dividono in due categorie: DSM-CC Download Data Message, che contengono i dati appartenenti ai moduli del carousel, e DSM-CC Download Control Message, che dicono al ricevitore come sono organizzati i Download Data Message nei moduli. Il messaggio DownloadDataBlock è l'unico tipo di Download Data Message presente. Un messaggio DownloadDataBlock corrisponde ad un blocco di dati che viene trasmesso come singola unità. Ogni DownloadDataBlock ha anche la stessa grandezza, ad eccezione dell'ultimo blocco in un modulo, così si rende più facile l'analisi dei messaggi da parte del ricevitore. Tramite il messaggio DownloadDataBlock vengono trasportati i dati in un carousel, mentre la struttura di un modulo viene definita da uno o più Download Control Message. I data carousel funzionano bene per il sistema teletext o per una semplice applicazione, ma possiedono alcune limitazioni: il broadcaster trasmette blocchi di dati attraverso una connessione MPEG-2, ma questa soluzione non dice niente sulla natura dei dati. L'applicazione che legge il data carousel deve conoscere il formato del contenuto e come lo deve trattare. Per le applicazioni MHP è un grande problema, poiché è importante conoscere la struttura dei file e delle directory per distinguere il codice delle applicazioni dalle risorse. In situazioni complicate questo meccanismo non è molto utile, ed in questi casi l'object carousel fornisce una migliore soluzione. Gli object carousel sono costruiti in cima ad un modello data carousel, e lo estende

16 aggiungendo il concetto di file, directory e stream. Permette ad un carousel di contenere un vero filesystem, un insieme di directory e di file che formano una struttura a directory come in un PC. Oltre ad essere costruiti sopra i data carousel DSM-CC, gli object carousel sono costruiti anche in cima al framework Object Request Broker (ORB) definito da CORBA. Ogni oggetto all'interno dell'object carousel viene trasmesso come un messaggio BIOP (Broadcast Inter-ORB Protocol) definito da CORBA, ed ogni messaggio è contenuto dentro un modulo data carousel DSM-CC. In un object carousel possono essere trasportati i seguenti tipi di messaggi: File message, che rappresentano i file; contengono i dati che formano i file. Directory message, rappresentano i contenitori logici di un insieme di file message. Ciascuna directory DSM-CC contiene un certo numero di file (come le directory di un file system), ed un directory message contiene i riferimenti ai file che stanno dentro quella directory. Stream message sono riferimenti agli stream MPEG-2, che contengono i dati audio e video. Ogni stream message può riferirsi ad un singolo programma MPEG-2 oppure ad uno o più elementary stream. Stream Event message descrive un insieme di punti di sincronizzazione, chiamati stream event, che sono contenuti in uno stream. Questi messaggi dicono al ricevitore quali stream event sono presenti nello stream e li associa con un nome. Service Gateway message sono concettualmente simili ai Directory message. La differenza sta nel fatto che i Service Gateway message identificano la directory root dell'object carousel; questo significa che ciascun object carousel avrà un solo Service Gateway. Un object carousel è composto da una serie di messaggi BIOP trasportati in un data carousel DSM-CC. I tipi di messaggi rappresentano i differenti tipi di oggetti che si possono trovare in un object carousel. I messaggi DSM-CC contengono il payload all'interno dello stesso messaggio. Per esempio, un File message conterrà il contenuto completo di un file. Ogni object carousel consiste in un directory tree, diviso in una serie di moduli, che possono contenere uno o più file o directory. Ogni modulo può contenere diversi file, e la sua grandezza massima è di 64 KB: non è permesso inserire file in un modulo per una grandezza superiore a 64 KB. Inoltre non è permesso suddividere i file su più moduli, così i file più grandi di 64 KB devono essere inseriti in un proprio modulo, che conterrà solo quel file. I file contenuti in un modulo possono provenire da qualsiasi parte del directory tree, non è necessario che sia contenuta anche la loro directory. Questi moduli vengono trasmessi uno dopo l'altro fino a che non vengono trasmessi tutti; a quel punto il processo riparte dall'inizio e viene ritrasmesso il primo modulo. Per accedere ad un file, il ricevitore deve aspettare finché non riceve il modulo che lo contiene; quando lo riceve, analizza il modulo ed accede al file. Questo meccanismo potrebbe risultare inefficiente quando la quantità di dati trasmessa è piuttosto grande. Viene illustrato un esempio di object carousel, supponendo di voler trasmettere le seguenti directory:

17 index.html 1256 byte image1.jpg 4040 byte image2.jpg byte audio audio/clip1.aiff byte classes classes/main.class byte classes/big.class byte classes/other.class byte Vengono creati i moduli da trasmettere inserendoci i file. Per prima cosa, vengono inseriti in un modulo i primi due file: index.html e image1.jpg. Se venisse aggiunto il file image2.jpg, la grandezza del modulo supererebbe i 64 KB, perciò non è possibile. Comunque è possibile aggiungere il file clip1.aiff. Inoltre è possibile aggiungere l'annotazione della directory audio senza causare problemi. Infine sarebbe possibile aggiungere qualche file contenuto nella directory classes, ma questo non viene fatto per ottimizzare i tempi di caricamento. Questo modulo è definito, quindi si può proseguire con la creazione dei rimanenti. Il file image2.jpg è più grande di 64 KB, ma non è possibile dividerlo in più moduli, perciò costituirà un modulo a parte. Questo modulo sarà più grande di 64 KB, ma non si può fare altrimenti. Infine vengono aggiunti al carousel i file della directory classes. Questi file non possono essere inseriti tutti nello stesso modulo, ma vengono organizzati in modo che possano essere caricati il più velocemente possibile. La prima cosa che viene inserita al nuovo modulo è la registrazione della directory classes. Poiché la directory entry serve per accedere ai file contenuti in essa, si cerca di aggiungere a questo modulo più file classes possibili. In questo caso significa aggiungere i file Main.class e Other.class. L'ultimo file Big.class costituirà un modulo proprio. Questo esempio di spartizione dei file in moduli potrebbe non essere il più efficiente: dipende quali file sono necessari e la relazione tra essi, così in una implementazione reale è molto importante stare attenti a creare il carousel più efficiente. Quando si trasmette un DSM-CC carousel, questi moduli possono essere trasmessi più di una volta. Trasmettendo alcuni moduli più volte rispetto ad altri, la grandezza totale del carousel aumenta ma il tempo di accesso dei file più usati diminuisce, mentre quello dei file usati meno frequentemente aumenta. Questo scostamento deve essere considerato attentamente quando viene progettato un carousel, per ottimizzare la velocità di scaricamento. E' possibile che un file venga ripetuto in diversi moduli, così si fornisce un approccio granulato e si ottimizza l'object

18 carousel. La disposizione dei carousel è un arte piuttosto che una scienza, molto dipende dai dati utilizzati nei carousel, quando sono necessari e la grandezza dei file. Non si può dire quale disposizione dei carousel sia la più efficiente in un caso generale: bisogna conoscere la progettazione e la struttura dell'applicazione che utilizzerà i dati del carousel. 4. Digitale Terrestre - Mhp > L'ambiente Java delle Xlet Come già detto, il core di MHP si basa su Java: in particolare sono state adottate una Personal Java Virtual Machine ed una serie di API, tra cui le API Java TV di Sun ricoprono un ruolo fondamentale. Tali API forniscono la piattaforma di sviluppo per i servizi interattivi della televisione digitale, utilizzando il linguaggio di programmazione Java. Le API JavaTV sono state progettate per accedere alle funzionalità fornite dai ricevitori digitali, che comprendono lo streaming audio e video, l'accesso condizionato, l'accesso ai canali dati, i controlli per cambiare canale e quelli per l'interfaccia grafica sul televisore; per la gestione del media trasmesso in broadcast vengono sfruttate le API Java Media Framework (JMF 1.0). Inoltre, queste API definiscono funzionalità addizionali, come la sincronizzazione dei media ed il controllo del ciclo di vita delle applicazioni. La sincronizzazione dei media permette ai contenuti interattivi di sincronizzarsi con l'audio ed il video di un programma televisivo. L'ambiente hardware e software implementato in un ricevitore digitale include i seguenti livelli: Hardware Layer, definito dall'hardware del STB; Real Time Operative System (RTOS) Layer, il livello che include il sistema operativo real-time ed i vari driver; Java Technology Layer, che include la piattaforma Java con le relative API JavaTV; Application Layer, dove vengono eseguite le applicazioni. L'ambiente software comprende la piattaforma Java e le API JavaTV, eseguite sopra il sistema operativo real-time (RTOS). Al livello più basso, il RTOS e le relative librerie controllano l'hardware attraverso un insieme di driver. Il RTOS fornisce il supporto di sistema necessario per implementare la Java Virtual Machine e le librerie che compongono la piattaforma Java. Le API JavaTV forniscono un livello di astrazione che permette ai programmatori di non occuparsi dei dettagli specifici dell'hardware sottostante; queste API si differenziano dallo standard MHP, poiché non sono vincolate ai sistemi DVB per la TV digitale. Le applicazioni scritte usando le API JavaTV possono essere eseguite su qualsiasi tipo di piattaforma in grado di supportarle; tale portabilità è fondamentale per gli sviluppatori di applicazioni e di contenuti che vogliono vendere i loro prodotti su mercati differenti. Sebbene le API JavaTV non costituiscono lo standard per la TV interattiva, di fatto sono

19 incluse in moltissimi standard emanati. Le API JavaTV sono composte da un insieme di pacchetti Java; il package più importante è javax.tv.xlet, che contiene le classi che definiscono il ciclo di vita delle applicazioni. Alle JavaTV mancano alcune funzionalità fondamentali, che però vengono fornite da altre API; ad esempio, il supporto per il canale di ritorno viene fornito da java.net, mentre il supporto per il controllo dei contenuti audio e video viene fornito dal JMF. Le applicazioni sviluppate per MHP vengono chiamate applicazioni DVB-J. Sono scritte in Java e consistono in un insieme di classi trasmesse in broadcast. Spesso si fa riferimento a tali applicazioni con il nome di Xlet. In pratica, un'applicazione Java convenzionale non si adatta bene all'ambiente televisivo digitale. Questo modello presuppone l'esecuzione di una sola applicazione in una data macchina virtuale, e che l'applicazione stessa abbia il controllo completo del proprio ciclo di vita. In un ricevitore televisivo digitale, invece, è frequente che più applicazioni vengano eseguite nello stesso momento. A tal proposito viene considerato il funzionamento delle applet che, a differenza delle normali applicazioni, possono essere avviate da una sorgente esterna, il web browser, ed alcune di esse possono essere eseguite sulla stessa pagina web nello stesso momento. Ovviamente il sistema televisivo digitale è diverso dal Web, perciò devono essere adottati alcuni cambiamenti affinché questi concetti si adattino al ricevitore digitale. Una Xlet quindi non è un'applicazione Java standard: è una particolare applicazione concepita per essere scaricata ed eseguita sui decoder interattivi; esse sono state introdotte da Sun nella specifica JavaTV, ed adottate come formato applicativo Java per MHP. Sono molto simili ad applet: come nelle applet, l'interfaccia Xlet permette ad un software specifico esterno, l'application manager nel caso del ricevitore MHP, di controllarne il ciclo di vita, avviando o fermando l'applicazione. L'interfaccia Xlet si trova nel package javax.tv.xlet. Come le classi applet, l'interfaccia Xlet contiene i metodi che permettono all'application manager di inizializzare, avviare, mettere in pausa e distruggere una applicazione. Poiché potrebbero esserci più Xlet che vengono eseguite nello stesso momento, esse non possono effettuare alcuni compiti che potrebbero influenzare la Java Virtual Machine; in particolare, una Xlet non deve mai richiamare il metodo System.exit()' per terminare l'applicazione. La differenza più importante tra applet e Xlet è che una Xlet può essere messa in pausa ed essere riavviata in un secondo momento. La ragione è semplice: nel caso di un ricevitore digitale, diverse applicazioni potrebbero essere eseguite nello stesso momento, mentre le capacità dell'hardware permettono ad una sola applicazione di essere visibile; quelle non visibili perciò devono essere messe in pausa con lo scopo di mantenere le risorse libere per l'unica applicazione mostrata. Le interfacce fondamentali da utilizzare sono definite nelle API JavaTV. Le interfacce javax.tv.xlet.xlet e javax.tv.xlet.xletcontext servono per interagire con l'application manager in merito al ciclo di vita e al contesto in cui la Xlet viene eseguita. Una Xlet di fatto implementa i 4 metodi presenti nell'interfaccia javax.tv.xlet.xlet:

20 initxlet: questo metodo viene invocato dall'application manager per inizializzare l'xlet; startxlet: è la funzione che serve per eseguire l'xlet; pausexlet: usata per mettere in pausa l'xlet; destroyxlet: invocata quando l'application manager termina l'xlet. Il ciclo di vita di una Xlet è caratterizzato da 4 stati: Loaded: la Xlet viene creata ma non ancora inizializzata. Se durante questa fase viene rilevata un'eccezione, si passa direttamente allo stato Destroyed. Una Xlet può trovarsi in questo stato solo una volta durante tutto il suo ciclo di vita. Paused: la Xlet viene inizializzata, e può trovarsi in questo stato sia dopo che il metodo initxlet ritorna con successo dallo stato Loaded, oppure dopo che il metodo pausexlet ritorna con successo dallo stato Active. In questo stato, la Xlet deve limitare al massimo l'utilizzo delle risorse condivise e soprattutto non impegnare la GUI televisiva. Active: in questo stato la Xlet è attiva e utilizza le risorse necessarie per fornire i suoi servizi; se è dotata di GUI, allora dovrebbe essere l'unica applicazione abilitata a ricevere gli eventi dal telecomando. Destroyed: in questo stato la Xlet deve rilasciare tutte le risorse in uso per predisporsi alla terminazione. Una sequenza tipica del ciclo di vita può essere la seguente: 1. L'application manager carica la classe principale della Xlet, su segnalazione del broadcaster, e ne crea un'istanza: l'applicazione si trova nello stato Loaded. 2. Quando l'utente sceglie di avviare l'xlet, o un'altra applicazione segnala che l'xlet deve partire automaticamente, l'application manager invoca il metodo initxlet. L'Xlet usa il context' per inizializzarsi, ed eventualmente per richiedere alcune risorse, come le immagini. Quando l'inizializzazione è completata, l'xlet si trova nello stato Paused, ed è pronta per essere avviata. 3. Una volta che il metodo initxlet ritorna con successo, l'application manager richiama il metodo startxlet. Questo comporta il passaggio dallo stato Paused allo stato Active, così l'xlet sarà capace di interagire con l'utente ed utilizzare le risorse necessarie per fornire i servizi per cui è stata creata. 4. Durante l'esecuzione, l'application manager può invocare il metodo pausexlet; questo comporta il passaggio dell'applicazione dallo stato Active allo stato Paused.

21 L'applicazione potrà tornare nello stato Active richiamando il metodo startxlet: questa situazione può accadere svariate volte in tutta la vita di una Xlet. 5. Alla fine del ciclo di vita, l'application manager invoca il metodo destroyxlet, che comporta il passaggio allo stato Destroyed, liberando tutte le risorse. A seguito di questa operazione, l'istanza di questa Xlet non può essere più richiamata. Ogni Xlet ha a disposizione un contesto di applicazione, l'xletcontext, che è un'istanza della classe javax.tv.xlet.xletcontext. Questo context è simile alla classe AppletContext associata ad una applet: in entrambi i casi il contesto viene usato dall'applicazione per accedere alle proprietà dell'ambiente circostante e per comunicare i cambiamenti di stato all'application manager. L'interfaccia javax.tv.xlet.xletcontext prevede i seguenti metodi: notifydestroyed; notifypaused; getxletproperty; resumerequest. I metodi notifydestroyed e notifypaused permettono ad una Xlet di notificare al decoder che l'applicazione sta per terminare o per mettersi in pausa; in questo modo, il ricevitore conosce lo stato di ogni applicazione e può effettuare le azioni appropriate. Questi metodi devono essere richiamati immediatamente prima che l'xlet entri negli stati Paused o Destroyed, a causa del fatto che il ricevitore potrebbe effettuare alcune operazioni per le quali l'applicazione non è detto che sia pronta. Una Xlet può richiedere di passare dallo stato Paused allo stato Active usando il metodo resumerequest. Questo può accadere quando si verifica un certo evento, rilevato ad esempio nello stream MPEG. Questo metodo 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. Attualmente è 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. Di seguito viene mostrato cosa succede quando una Xlet chiede di cambiare il proprio stato tramite l'xlet context. Si consideri una Xlet che vuole mettersi in pausa e successivamente richiede di riavviarsi. 1. Per prima cosa, l'xlet notifica al suo Xlet context che si è messa in pausa, invocando il metodo XletContext.notifyPaused().