 |
 |
Gli obiettivi che hanno fatto da riferimento per la realizzazione del Multimedia Level, sono i seguenti:
|
 |
Lo scenario attuale prefigura un futuro radioso per i servizi on demand. Sono molti i possibili campi di applicazione e varie le loro possibili tipologie:
|
|
 |
Come si evince i servizi On Demand, pur coprendo varie tipologie, devono rispettare ed adempiere a requisiti comuni:
|
|
 |
Il modello deve contemperare sia le problematiche della sorgente che dell'utilizzatore, e cioè problemi di codifica, decodifica, compressione, decompressione, trasmissione e ricezione di pacchetti in rete. Il sistema di distribuzione deve garantire il corretto indirizzamento verso l'utente dei contenuti multimediali.
|
|
 |
Una breve panoramica su quelli che al giorno d'oggi sono i mezzi trasmissivi più utilizzati è d'obbligo
|
|
 |
La linea di sviluppo del modello ML è stata rivolta alla gestione dei flussi multimediali sulla rete Internet. Internet nasce 20 anni fa per gestire traffico di tipo "a raffica" come il trasferimento di file fra due macchine remote, quindi il modello ML ha dovuto mediare questa caratteristica con la necessità di sostenere un flusso "continuo" di dati. C'è da osservare che Internet si sta evolvendo in questa direzione, ne sono una dimostrazione il protocollo IPv6 e altri protocolli specifici quali RTP e RTCP che gestiscono sistemi tempo reali ed RSVP (Protocollo per riservare risorse sui router, il quale prevede di ritagliare una parte di banda per trasmissioni punto-punto e punto-multipunto).
|
|
 |
Il modello ML, come abbiamo detto in precedenza estende le capacità multimediali del sistema operativo. Lo scopo è porre l'applicazione finale ad un livello più alto rispetto alla veicolazione delle informazioni, in modo da rendere efficiente il trasferimento dei flussi di dati tra i vari dispositivi hardware all'interno del sistema. Occorre infine gestire le comunicazioni fra sistemi remoti così da rendere unica la trattazione sia della voce che delle immagini.
Il modello ML introduce tre nuovi elementi:
|
|
 |
L'architettura del modello ML è composta di due blocchi: uno di alto livello indipendente dalla rete ed uno di basso livello per la gestione dei driver dei vari dispositivi di acquisizione dei flussi multimediali. Nella figura sono raffigurati in turchese i nuovi elementi introdotti dal modello ML. Dal basso troviamo il Multimedia driver che gestisce la migrazione dei flussi tra i driver dei vari dispositivi; il Multimedia Level che va ad integrare il sistema operativo (è stato adottato Windows 3.1 a causa dell'incompatibilità del Multimedia Driver con sistemi più evoluti come Windows 95 o Windows NT); infine il Multimedia Application a livello più alto che usufruisce dei servizi messi a disposizione dai livelli sottostanti.
|
|
 |
Il Multimedia Driver, è da considerarsi un po' come il motore dell'intera struttura, riceve comandi dal Multimedia Level e consente l'apertura dei canali tra i vari driver a basso livello (canali audio, canali video). La scheda di Overlay acquisisce l'immagine e la sovrappone alla finestra corrente. Nella figura sono agganciati i contenuti audio e video, provenienti da una scheda di acquisizione verso una scheda di rete. La versione attuale del Multimedia driver è sviluppato per il sistema operativo Windows 3.1.
|
|
 |
All'interno della struttura ML si individuano due tipi di percorsi per i dati. Un primo percorso riguarda la negoziazione di eventi fra due stazioni remote inerconnesse, nel quale la Multimedia Application invia la propria richiesta al modulo ML, quest'ultimo attraverso uno specifico protocollo, la traduce in una sequenza di pacchetti che verranno a loro volta inviati in rete tramite il Network Driver. Una volta arrivata all'utente remoto, la richiesta seguirà esattamente il percorso inverso. Sulla destra viene descritto il traffico dei flusso audiovisivo. Come si può osservare, il traffico impegna solo la parte bassa e non obera di lavoro il sistema operativo, aumentando sensibilmente l'efficienza. Nell'esempio una sorgente video (come ad esempio una telecamera) indirizza il flusso dati all'MD che, in precedenza, ha chiuso un canale sul network out e attraverso questo viene distribuito in rete. La stessa cosa si può fare con tutti gli altri driver a disposizione.
|
|
 |
Il modello ML è stato descritto secondo una macchina a stati finiti. Esso comunica ad alto livello con una Multimedia Application attraverso una Multimedia Level Interface (MLI). La sintassi dell'interfaccia MLI è definita attraverso le API di Windows, per cui sono state create specifiche funzioni allo scopo di creare ed abbattere Tube, Stream ed altre entità, funzioni che servono per la negoziazione sui parametri del media trasportato ed altre ancora. A basso livello c'è la Device Drive Interface (DDI). ML colloquia a livello paritario anche con il sistema operativo. Questa interfaccia serve ad esempio per inizailizzare un timer oppure per richiedere un buffer su cui appoggiare momentaneamente dei dati.
|
|
 |
Fino a questo momento si è analizzata solo la comunicazione fra due livelli ML paritari, ma per come è stata concepita l'architettura di ML, la Multimedia Application può essere anche in un luogo distinto da quello dove si trova ML. Nel primo caso il sistema operativo ha la possibilità di ospitare il livello ML, questo attraverso un RAL comunicherà con una Proxy mApplication che a sua volta comunicherà nella maniera canonica con il livello ML sottostante. Quindi è possibile da remoto istanziare per esempio un Tube fra due elementi distinti da quello che effettua la chiamata, per cui in generale posso gestire da remoto la comunicazione fra due utenti realizzando una sorta di "regia". Nella parte bassa della figura, troviamo un'altra soluzione per la regia, è il caso di una applet che gira in un browser. Questa soluzione è ottimale nei casi in cui il sistema operativo non possieda ML. Dovrà essere definito un protocollo di comunicazione con una Proxy mApplication (ad esempio un protocollo di tipo Telnet).
|
|
 |
Sulla sinistra è riportato lo schema classico di distribuzione del segnale televisivo via satellite. Si possono distinguere due fasi: una fase di UPLINK dove un broadcast televisivo trasmette il proprio segnale al satellite, ed una fase di DOWNLIK dove il segnale ritrasmesso dal satellite arriva capillarmente a tutti gli utenti, che singolarmente provvederanno alla ricezione e alla decodifica del segnale. A destra si può osservare la struttura realizzata. La fase di UPLINK è la stessa, mentre nella fase di DOWNLINK è stato inserito un ServerTV, che riceve il segnale televisivo attraverso un'antenna parabolica e lo distribuisce in rete agli utenti ad esso collegati. Affinché un sistema come questo possa raggiungere le stesse prestazioni del classico sistema di distribuzione del segnale televisivo, occorre una grande disponibilità, per quanto riguarda la larghezza della banda messa a disposizione dalle linee, che aumenta con il numero delle emittenti televisive. Basti pensare che per fornire 10 diverse possibilità di scelta, sarebbe richiesta una banda di almeno 15 Mbps, anche usando efficienti tecniche di compressione, come MPEG.
|
|
 |
Nella figura sono riportate le limitazioni fissate per la realizzazione del progetto. Per quanto riguarda la banda c'è da dire che è molto legata allo stato del traffico sulla rete, in quanto le situazioni di sovraccarico influiscono sulla fluidità della riproduzione audio e video. La numerosità del bacino di utenza è ridotta all'unità per limiti di disponibilità delle stazioni client, mentre quella dei canali televisivi è stata posta a 24, in accordo con la capacità dell'impianto di ricezione da satellite (l'antenna parabolica era a puntamento fisso per cui è stato deciso di puntarla verso Eutelsat 2, con un'antenna motorizzata sarebbe stato possibile aumentare questo numero). Per motivi di costi e di disponibilità di apparecchiature, le codifiche impiegate sono l'H.261 per il video e il G.711 per l'audio, anche se sarebbero più adatte per sistemi di videoconferenza dove il movimento d'immagine è limitato. Per la realizzazione del sistema ML sarebbero state più convenienti codifiche MPEG. Il sistema prevede la diffusione di tipo multicast, quindi più utenti potrebbero essere serviti contemporaneamente con lo stesso programma.
|
|
 |
Le limitazioni precedentemente descritte, hanno condotto alla scelta di una architettura di tipo Client-Server. I dati vengono scambiati a livello MD, dalle due stazioni Client e Server ed inoltre viene usato un canale in più per il controllo di sintonia, che permette di pilotare il ricevitore direttamente dall'applicazione. Questo avviene attraverso la porta seriale della stazione ServerTV e tramite un protocollo opportuno fornito dalla casa produttrice del ricevitore.
Lo scambio di messaggi fra le due stazioni si sviluppa attraverso due fasi:
|
|
 |
Nella figura sono riprodotte le interfaccia grafiche così come appaiono al gestore del servizio. La prima finestra riporta i canali televisivi messi a disposizione del Client, il comando che disconnette tutti i Client connessi, quello per uscire dal programma ed il comando che richiama le funzioni del ricevitore visualizzate grazie alla seconda finestra. In quest'ultima sono riportati la lista dei satelliti captabili dal ricevitore (nella parte superiore), i comandi per il suo aggiornamento e un campo (nella parte inferiore) che permette la visione in locale del programma TV selezionato. Tali canali possono essere aggiunti e rimossi, tramite opportuni tasti.
|
|
 |
Nella figura sono riportate due finestre richiamabili da quelle precedenti. La prima permette a chi gestisce la stazione la regolazione di molti parametri, quali ad esempio la sintonia, i livelli audio di ingresso e uscita, il livello di luminosità. La seconda finestra permette la selezione del satellite.
|
|
 |
Nella SLIDE è riportata l'applicazione mClient. Come si può osservare è stata scelta la veste grafica molto familiare di un telecomando. Questo è diviso in tre campi, quello che non è riscontrabile in un normale telecomando è il campo relativo alla regolazione del bit-rate della trasmissione. Quest'ultima viene fatta prima della instaurazione della connessione, dopo non è possibile intervenire in alcun modo. E' importante sottolineare che le altre regolazioni rimangono in locale, cioè l'utente agisce sul segnale che gli arriva tramite la propria scheda Codec, il che non influenza in modo assoluto il Server. Il comando Menù consente di aprire un'altra finestra per la scelta del canale fra quelli messi a disposizione dal ServerTV (vedi SLIDE successiva).
|
|
 |
Alcune emittenti, come EuroNews o EuroSport, trasmettono contemporaneamente in più lingue. Il programma riconosce queste emittenti e automaticamente mostra la piccola finestra a destra che permette all'utente di cambiare la lingua in tempo reale.
|
|
 |
Il progetto è stato sperimentato sulla MAN Toscana, un anello a 140 Mbps. La stazione ServerTV è stata allestita presso la sede del Centro Didattico Televisivo dell'Università di Firenze, dove si trova il sistema di ricezione, gli altri due nodi interessati alla sperimentazione sono stati due stazioni Client, una allestita presso il laboratorio di Tecnologie della Telematica del Dipartimento di Ingegneria Elettronica e l'altra presso il PIN di Prato, quest'ultima collegata alla MAN tramite ponte radio a 2 Mbps.
La sperimentazione ha mostrato la validità del sistema, aldilà delle limitazioni della rete Internet, poco adatta alla trasmissione di flussi real-time.
|
 |
Il sistema ML è stato sviluppato per l'integrazione di servizi diversi, basti osservare il fatto che tratta allo stesso modo sia flussi audio che video. Per la sua struttura modulare si presta molto bene agli aggiornamenti. Le interfaccia sono state progettate per minimizzare il numero delle finestre e disegnate secondo forme il più possibile familiari all'utente.
Il modello è già stato potenziato grazie all'introduzione di nuove funzionalità per la regolazione dei parametri a distanza, cosa che nel modello visto fino ad ora era possibile solo in locale.