Introduzione
L'attenzione alla multimedialità su piattaforma J2ME nasce con le MMAPI 1.0. Infatti né le configurazioni CDC o CLDC né il profilo MIDP 1.0 implementavano funzionalità di tipo multimediale.
Con il MIDP 2.0 una parte delle MMAPI sono migrate all'interno del profilo, permettendo anche ai dispositivi che non supportavano le MMAPI di aver a disposizione un set, seppur ridotto, di media API.
Le MMAPI 1.1 vanno a fissare problemi di documentazione, aggiungono alcune definizioni e rivedono la documentazione relativa al MIDP 2.0 security framework. Non implementano cambiamenti a classi, interfacce o metodi.
Dalla necessità di sfruttare e combinare le innovative feautures dei dispositivi mobili più recenti (v. UMTS), nascono le Advanced Multimedia Supplements (AMMS).
In questo articolo descriveremo e confronteremo tutte queste soluzioni al fine di dare una panoramica completa delle potenzialità multimediali dei diversi dispositivi mobili Java.

MMAPI
Iniziamo la nostra analisi dalle Mobile Media API che, come già detto, rappresentano il primo, e il più utilizzato dagli sviluppatori, strumento per la realizzazione di applicazioni multimediali.
Si tratta di un package opzionale pensato per funzionare su dispositivi J2ME abilitati.
Riportiamo di seguito le caratteristiche rese disponibili dalle MMAPI 1.0, secondo le idee che hanno dato vita alla relativa JSR:

• Support for Tone Generation, Playback, and Recording of Time-Based Media: il package supporta la fruizione di qualsiasi contenuto audio o video time-based.
• Small Footprint: le MMAPI hanno a disposizione una memoria limitata, secondo quanto previsto dalla configurazione CDC o CLDC.
• Protocol- and Content-Agnostic: le API non si basano su specifici protocolli o tipologie di contenuto.
• Subsettable: gli sviluppatori possono limitare il supporto a particolari tipologie di contenuto.
• Extensible: le nuove caratteristiche possono essere facilmente aggiunte, in particolare i formati addizionali possono essere resi facilmente supportabili.
• Options for Implementers: le API offrono funzionalità per diversi scopi. Esse sono realizzate in modo da permettere agli sviluppatori di lasciare non implementate funzionalità che non intendono fornire o che il terminale non supporta.

Le modalità per l'elaborazione di dati multimediali sono due:

• Protocol Handling: lettura di dati da una sorgente quale un file o uno streaming server e inserimento in un sistema di processamento.
• Content Handling: manipolazione o decodifica di dati multimediali al fine di renderizzarli per dispositivi quali un audio speaker o un display video.

Per facilitare queste operazioni le API forniscono due tipologie di oggetti di alto livello:

• DataSource: incapsula il meccanismo di protocol handling nascondendo i dettagli su come i dati vengono letti dalla sorgente. I metodi di questo oggetto rendono possibile la manipolazione del contenuto da parte dell'oggetto Player.
• Player: legge i dati dal DataSource, gli elabora e li renderizza per dispositivi di output. Questo oggetto fornisce i metodi per la riproduzione di dati multimediali e una serie di controlli per poter disporre delle caratterische specifiche dei dati stessi.

Le MMAPI forniscono un terzo oggetto, un meccanismo di costruzione noto come Manager, necessario per la creazione di Player a partire da DataSource o da InputStream.
L'architettura delle MMAPI è mostrata nella Fig. 1:

Figura 1 - L'architettura MMAPI

Il Manager dispone del metodo createPlayer():

Player player = Manager.createPlayer(String url);

dove url specifica protocollo e contenuto, nel formato <protocol>:<content location>.

I metodi del Player così creato vengono utilizzati per controllare la riproduzione e l'accesso ai dati multimediali.

Il ciclo di vita del Player è costituito da cinque stati: UNREALIZED, REALIZED, PREFETCHED, STARTED e CLOSED.

I metodi utilizzati per le transizioni di stato sono invece sei:

realize ( )
prefetch ( )
start ( )
stop ( )
deallocate ( )
close ( )

Figura 2 - Gli stati di un Player MMAPI

Come si vede nella Fig. 2, quando il Player viene creato è nello stato UNREALIZED.
Chiamando realize ( ) il Player transita nello stato REALIZED e vengono inizializzate le informazioni di cui esso ha bisogno per acquisire le risorse multimediali.
Dopo che è stato invocato il metodo realize ( ) il solo modo per tornare nello stato UNREALIZED è chiamare il metodo deallocate ( ); ciò può essere utile nel caso in cui il Player resta bloccato durante la fase di "realizzazione".
Chiamando prefetch ( ) il Player transita nello stato PREFETCHED, stabilisce le connessioni di rete nel caso di streaming ed effettua altre azioni preliminari.
Si può tornare dallo stato PREFETCHED allo stato REALIZED invocando deallocate ( ).
La chiamata start ( ) provoca il passaggio allo stato STARTED, nel quale il Player è in grado di processare i dati. Quando termina la fase di gestione dei dati il Player ritorna nello stato PREFETCHED.
Infine, chiamando close ( ) il Player passa allo stato CLOSED in cui ha rilasciato la maggior parte delle risorse.

Il quarto componente principale delle MMAPI è il Control, il quale controlla varie caratteristiche del Player e le operazioni di riproduzione. Un'applicazione usando il metodo getControl ( ) ottiene un singolo controllo mentre con getControls ( ) ottiene un array contenente tutti i controlli supportati.

Nel package javax.microedition.control le MMAPI dispongono di dodici controlli:

• MetaDataControl: ottiene informazioni "metadata" dai dati multimediali.
• MIDIControl: fornisce l'accesso ai dispositivi per la trasmissione e la renderizzazione di dati MIDI.
• GUIControl: rappresenta un controllo che fornisce una componente UI.
• PitchControl: aumenta o diminuisce il pitch di riproduzione senza cambiarne la velocità.
• RateControl: controlla la velocità di riproduzione.
• TempoControl: controlla il "tempo" di una canzone MIDI.
• VolumeControl: controlla il volume.
• VideoControl: controlla il contenuto visivo del display.
• FramePositioningControl: abilita il posizionamento su un preciso video frame.
• RecordControl: registra quello che viene mostrato dal Player.
• StopTimeControl: abilita l'applicazione a definire un tempo presettato di stop per il Player.
• ToneControl: è un'interfaccia che abilita la riproduzione di sequenze di toni definite dall'utente.

Ovviamente non tutti i device supportano tutti i controlli. Si può verificare quali siano i controlli supportati tramite la chiamata System.getProperty(String key), dove, secondo le specifiche, le stringhe da utilizzare per ottenere le proprietà sono:

• microedition.media.version restituisce una stringa che rappresenta la versione di MMAPI implementata: "1.0", "1.1" oppure "null".
• supports.mixing restituisce "true" se il mixing è supportato altrimenti "false".
• supports.audio.capture restituisce "true" se la cattura audio è supportata altrimenti "false".
• supports.video.capture restituisce "true" se la cattura video è supportata altrimenti "false".
• supports.recording restituisce "true" se la registrazione è supportata altrimenti "false".
• audio.encodings restituisce una stringa che rappresenta i formati di cattura audio supportati o "null" se la cattura audio non è supportata.
• video.encodings restituisce una stringa che rappresenta i formati di cattura video supportati o "null" se la cattura video non è supportata.
• video.snapshot.encodings restituisce una stringa che rappresenta i formati di cattura immagini supportati o "null" se la cattura immagini non è supportata.
• streamable.contents restituisce una stringa che rappresenta le tipologie di contenuti di streaming supportati utilizzando la sintassi MIME.

Oltre alle proprietà che resituisce System.getProperty(), il Manager dispone anche di due utili metodi statici:

• String[] getSupportedContentTypes(String protocol) prende un protocollo come "http" e restituisce le tipologie di contenuto supportate da quel protocollo.
• String[] getSupportedProtocols(String contentType) prende una tipologia di contenuto in sintassi MIME, come "video/mpeg" e restituisce i protocolli che possono essere utilizzati per trasportarlo.

MIDP 2.0 Media API
Le MIDP 2.0 Media API sono un sottoinsieme delle MMAPI pensare per dispositivi che dispongono del profilo MIDP 2.0 ma non hanno strumenti multimediali adeguatamente estesi.
In particolare le MIDP 2.0 Media API differiscono dalle MMAPI in quanto:

• supportano soltanto funzionalità legate all'audio: riproduzione ed eventualmente registrazione;
• tutti i controlli connessi al video o alla grafica sono esclusi;
• non è supportata la sincronizzazione nella riproduzione simultanea di più pacchetti audio;
• il package javax.microedition.media.protocol è escluso;
• viene utilizzata una versione semplificata del Manager.

In pratica il MIDP 2.0 include il cosiddetto Audio Building Block (ABB) che permette di utilizzare toni, sequenze di toni e file WAV all'interno di applicazioni MIDP. Gli unici controlli presenti sono ToneControl e VolumeControl.

Advanced Multimedia Supplements
AMMS, che al momento ancora non è stato rilasciato, implementerà la JSR 234. Si tratterà di un package opzionale dedicato a funzionalità multimediali avanzate connesse alle recenti innovazioni nell'hardware dei dispositivi mobili.
Le AMMS andranno ad estendere le potenzialità delle MMAPI.
L'obiettivo è offrire un miglior supporto per la camera e la radio e la possibilità di elaborazioni avanzate sull'audio.
Alcune delle migliorie descritte nelle specifiche delle AMMS sono:

• accesso a specifici controlli della camera come luminosità e contrasto, flash, modalità lampeggiante e zoom;
• accesso alla radio e ad altri canali e sorgenti frequency-based, compreso l'RDS (Radio Data System);
• accesso a particolari funzionalità di elaborazione audio come equalizzatore, effetti audio, riverbero artificiale, audio 3D;
  
• possibilità di direzionare l'uscita, ad esempio smistare l'audio a casse, microfono o cuffie.

Essendo le AMMS basate sulle MMAPI ereditano i concetti di Player, per riprodurre audio e video; Manager per creare Player; Control per interagire con i Player. In più, AMMS aggiunge altri controlli ad un GlobalManager, che viene utilizzato per creare nuovi oggetti per gli effetti di rete e l'elaborazione delle immagini.

A livello funzionale, l'implementazione delle AMMS consiste di cinque blocchi:

• Camera;
• Image Effect;
• Tuner;
• Audio Effect;
• 3D Audio

Almeno uno di questi macrorequisiti deve essere supportato da un dispositivo perché esso sia "AMMS-compliant". Ognuno di questi blocchi definisce una serie di funzionalità, raggruppate in uno specifico package, e implementate sotto forma di controlli.
Oltre ai controlli specifici per ogni macrorequisito, ci sono dei controlli generali, contenuti nel package javax.microedition.amms.control:

• AudioFormatControl: controlla i settaggi relativi al formato audio.
• ContainerFormatControl: controlla i settaggi dei formati "container" (audio + video)
• EffectControl: interfaccia per il controllo di un filtro astratto con varie impostazioni presettate.
• EffectOrderControl: interfaccia utilizzata per specificare l'ordine degli effetti rappresentati da EffectControl.
• FormatControl: controlla il formato utilizzato nel salvataggio di dati multimediali.
• ImageFormatControl: controlla i settaggi relativi al formato delle immagini.
• MIDIChannelControl: controllo che dà accesso a risorse di tipo MIDI.
• PanControl: interfaccio per la manipolazione del "panning" di un Player in modalità stereo. Il pannin consiste nel posizionamento del suono in una determinata posizione spaziale su due o più canali.
  
• PriorityControl: interfaccia per il controllo delle priorità tra diversi Player.
  
• VideoFormatControl: controlla i settaggi relativi al formato video.

Andiamo ora ad analizzare i singoli macroblocchi.

Camera
Cominciamo dalla funzionalità "Camera". Il relativo package è javax.microedition.amms.control.camera. Esso contiene sei controlli:

• CameraControl: controlla le caratteristiche della camera del telefono; ad esempio si può abilitare lo shutter (otturatore) audio/video; si può controllare se la camera è ruotata per essere in modalità "portrait", si può scegliere la modalità di esposizione e la risoluzione delle immagini.
  
• ExposureControl: per settare le impostazioni relative all'esposizione, quali l'apertura e la velocità dello shutter e la sensibilità.
  
• FlashControl: per settare le impostazioni relative al flah, quali la riduzione dell'effetto "occhi rossi" (red-eye reduction).
  
• FocusControl: fornisce un controllo sul focus.
  
• SnapshotControl: fornisce un controllo sulla cattura delle immagini, mettendo a disposizione "modalità sequenza", autoscatto, ecc.
  
• ZoomControl: fornisce un controllo sullo zoom, ottico o digitale

Image Effect
Questa funzionalità permette di manipolare le immagini dopo che sono state catturate. Prima di utilizzare un controllo bisogna usare un GlobalManager per creare un MediaProcessor.
I possibili controlli sono:

• ImageEffectControl: contiene una serie di filtri quali ad esempio quello per rendere l'immagine monocromatica o farne il negativo.
  
• ImageTonalityControl: permette di cambiare alcune impostazioni delle immagini, quali luminosità e contrasto.
  
• ImageTransformControl: implementa una serie di trasformazioni sulle immagini: rotazione, crop, zoom, mirror, flip, stretch.
  
• OverlayControl: fornisce una serie di settaggi per gestire le immagini in sovraimpressione sullo schermo.
  
• WhiteBalanceControl: permette di cambiare il bilanciamento del bianco in immagini e video.

Tuner
Si tratta di una serie di funzionalità legate alla radio. Il relativo package è javax.microedition.amms.control.tuner. I controlli sono due:

• TunerControl: interfaccia per controllare le impostazioni del radio player, ad esempio per trovare una stazione radio FM e memorizzarla.
  
• RDSControl: interfaccia per accedere ai dati RDS (Radio Data System) di una stazione: ad esempio si può accedere ad informazioni di tipo TA (Traffic Anouncement).

Audio Effect
Questo requisito prevede a livello realizzativo una serie di controlli per cambiare le impostazioni dell'audio, in particolare durante l'ascolto di musica. Il relativo package è: javax.microedition.amms.control.audioeffect.
I controlli sono:

• AudioVirtualizerControl: è un effetto utilizzano per rendere virtuali i canali audio. Il comportamento esatto di questo effetto dipende dal numero e dal tipo di canali audio che il Player ha a disposizione. Un Player dotato di 5.1 utilizza un algoritmo di surround virtuale.
  
• ChorusControl: interfaccia per settare le impostazioni relative agli effetti "chorus" e "flanger".
  Il chorus è un effetto sonoro che simula la presenza di più fonti sonore, lievemente differenti tra loro per quanto riguarda l'intonazione e lo sviluppo temporale, creando l'effetto di un coro. Si utilizza per dare corpo al suono.
  Il flanger è un effetto sonoro che sovrappone al segnale originale un segnale identico ma rallentato, ottenendo una modulazione costante.
  
• EqualizerControl: interfaccia per settare le impostazioni relative all'equalizzatore. L'equilizzatore solitamente viene utilizzato per due motivi: compensare la risposta in frequenza non ideale del sistema al fine di rendere il suono più naturale oppure per creare effetti modificando in modo innaturale il suono.
  
• ReverbControl: interfaccia per settare le impostazioni relative all'effetto riverbero.
  Il riverbero è un effetto sonoro che simula un ambiente acustico in cui si sviluppa il suono, mediante la sovrapposizione di numerose linee di ritardo, opportunamente filtrate e sfasate rispetto all'originale. Il riverbero è essenziale per percepire le proprietà dell'ambiente circostante, dalle dimensioni ai materiali delle pareti.
  
• ReverbSourceControl: interfaccia per settare le impostazioni relative alle sorgenti di riverbero.

3D audio
Le funzionalità 3D audio sono probabilmente le meno comprensibili in quanto non di uso comune per l'utente e comunque abbastanza complicate anche dal punto di vista implementativo. Le API permettono allo sviluppatore di costruire una rete di Player che possono essere combinati e ai quali si possono applicare degli effetti audio. I tradizionali effetti 2D sono estesi con gli effetti 3D che mirano a localizzare le sorgenti sonore in uno spazio virtuale tridimensionale intorno all'ascoltatore.
Il package utilizzato è javax.microedition.amms.control.audio3d.
I controlli sono:

• CommitControl: fornisce un meccanismo per fare in modo che alcuni parametri audio vengano aggiornati simultaneamente.
  
• DirectivityControl: aggiunge a OrientationControl un metodo per settare il modello di direttività di una sorgente sonora.
  
• DistanceAttenuationControl: interfaccia per controllare l'attenuazione del suono proveniente da una data sorgente al variare della sua distanza dall'ascoltatore.
  
• DopplerControl: interfaccia per settare le impostazioni relative all'effetto Doppler.
  L'effetto Doppler è il cambio di frequenza percepito dall'ascoltatore nel suono emesso da una sorgente sonora quando la distanza tra di loro varia rapidamente.
  
• LocationControl: interfaccia per manipolare la posizione virtuale di un oggetto nello spazio acustico virtuale.
  
• MacroscopicControl: interfaccia per manipolare il comportamento macroscopico di una sorgente sonora quando si usa il 3D audio. Di default le sorgenti sonore sono considerante come punti di dimensione zero. Questo controllo va a specificare una dimensione finita per le sorgenti sonore. Ciò può essere utile nel caso di sorgenti sonore di grandi dimensioni come le cascate.
  
• ObstructionControl: fornisce un meccanismo di controllo sui livelli generali del segnale audio che fluisce direttamente dalla sorgente verso l'ascoltatore. Inoltre permette di filtrare (attenuare) le componenti ad alta frequenza del segnale ad uno specifico livello.
  
• OrientationControl: interfaccia per manipolare l'orientamento virtuale di un oggetto nello spazio acustico virtuale.

Conclusioni
Le MMAPI forniscono alcune interessanti funzionalità multimediali. Le MIDP Media API fondamentalmente forniscono soltanto un minimo supporto audio. Le AMMS integrate con le MMAPI permettono invece di realizzare applicazioni davvero avanzate, che addirittura presumono delle conoscenze tecniche non comuni.
Il boom multimediale che ha investito il mondo mobile sia a livello hardware che software non ha lasciato indifferente la comunità tecnologica internazionale, che mette a disposizione su una piattaforma flessibile come Java funzionalità sempre più innovative ed aggiornate con le tecnologie in uso.

Bibliografia
[1] http://jcp.org/en/jsr/detail?id=234
[2] http://java.sun.com/products/mmapi/index.jsp
[3] http://java.sun.com/products/midp/index.jsp
[4] http://java.sun.com/products/cldc/index.jsp
[5] http://java.sun.com/j2me/index.jsp

Vincenzo Viola è nato a Formia (LT) il 03/11/1977, laureato in Ingegneria delle Telecomunicazioni presso l'Università Federico II di Napoli con una tesi sulla segmentazione automatica di video digitali in scene, con sviluppo software implementato su piattaforma Java - Oracle.
Lavora come progettista software per una Mobile Company che offre la sua consulenza ai gestori di telefonia e alle major del settore ICT.