Sistema de distribuição de notícias multimédia para dispositivos

UNIVERSIDADE TÉCNICA DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Sistema de distribuição de notícias multimédia para dispositivos
móveis
Carlos Bandeirinha, nº 49304, AE de Telecomunicações
Diogo Areia, nº49396, AE de Telecomunicações
LICENCIATURA EM ENGENHARIA ELECTROTÉCNICA E DE COMPUTADORES
Relatório de Trabalho Final de Curso
224/2006/L
Prof. Orientador: João Paulo Neto
Trabalho realizado no L2F , INESC-ID Lisboa
Junho 2006
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Agradecimentos
Gostaríamos de agradecer a todas as pessoas envolvidas no L2F e em especial ao nosso
orientador, o professor João Paulo Neto pela oportunidade que nos concedeu em trabalhar na
área do reconhecimento de fala e pelo apoio e colaboração prestados durante a realização
deste projecto.
Gostaríamos de dar um especial destaque:
•
•
•
•
ao Eng.º Renato Cassaca pela ajuda prestada nas mais diversas áreas deste projecto, o
seu apoio foi fundamental
ao Eng.º Márcio Viveiros principalmente pela ajuda concedida na elaboração da
interface gráfica
ao Eng.º. Hugo Meinedo pela sua constante disponibilidade em resolver os problemas
relativos ao SSNT
ao Doutor David Matos pelo auxilio prestado na resolução de alguns problemas
encontrados ao longo do projecto
Por fim, não nos podemos esquecer de todo apoio dado pelos nossos pais e amigos e ainda
pelos nossos colegas de trabalho, André Santos, Gustavo Coelho e Luís Figueira.
Carlos Bandeirinha, Diogo Areia
i
Resumo
Com este projecto desenvolvido no âmbito do trabalho de final do curso de
Engenharia Electrotécnica de Computadores, no ano 2006, foi criado um sistema de
distribuição de dados multimédia em plataformas wireless, direccionado para dispositivos
móveis (PDA’s, telemóveis para além de PC’s).
Para a implementação deste projecto foi construído um serviço que disponibiliza ao
utilizador, de uma forma simples e eficaz, informação multimédia proveniente do telejornal
da RTP (Rádio Televisão Portuguesa).
A sua realização implicou uma abordagem através de duas vertentes: servidor e
cliente.
Do lado do servidor foi desenvolvido um sistema capaz de disponibilizar os dados
multimédia ao utilizador sob a forma de vídeo, áudio e texto. Estes dados são obtidos
devidamente segmentados e categorizados, através de um sistema de reconhecimento de fala
de vocabulários largos, o ALERT, anteriormente desenvolvido nos Laboratórios de Sistemas
de Língua Falada (L2F). Criaram-se rotinas de pesquisa na base de dados para disponibilizar
o conteúdo pretendido pelas pesquisas dos utilizadores, implementou-se um servidor de vídeo
e disponibilizou-se um webserver capaz de comunicar com a aplicação do cliente.
Do lado do cliente desenvolveu-se uma interface para dispositivos móveis que garante
acessibilidade alternativa e aumentativa, ou seja, possibilita-se a navegação na aplicação com
fala e a visualização de texto e vídeo relativos aos telejornais. Criou-se então, uma interface
multimodal que usa um sistema de reconhecimento de fala independente do orador, o
AUDIMUS , previamente desenvolvido nos laboratórios do L2F.
Neste serviço são disponibilizados ao utilizador 3 tipos de pesquisas na base de dados:
livre, por datas e últimos títulos. Adicionalmente criou-se um sistema de matching capaz de
disponibilizar os dados multimédia ao utilizador de acordo com o perfil por si definido.
Sempre que desponte informação que corresponda a um perfil de utilizador, este será
notificado.
Palavras-chave
•
•
•
•
•
•
ii
Processamento de informação multimédia
Distribuição selectiva de dados multimédia
Dispositivos Móveis
Streaming
Interface Multimodal
Reconhecimento de fala
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Abstract
With this project developed in the scope of the Final Project towards the Bachelors
Degree in Computer and Electro-techniques Engineering, in the year of 2006, was created a
system of multimedia data distribution in wireless platforms, directed for mobile devices
(PDA’s, mobile phones and PC’s).
In the implementation of this project a system was created, that offers the user, in a
simple and efficient way, multimedia information proceeding from the RTP newscast.
It’s accomplishment implied an approach through two sides: server and client.
In the server side a system was created that is able to make the multimedia information
available to the user under the form of video, audio and text. This data is obtained in a
segmented and categorized way, through a system of speech recognition of wide vocabularies,
the ALERT, previously developed in the Spoken Language System Laboratories (L2F).
Several research routines in the database were created in order to deliver the desired contents
to the users. It was also integrated a video server and a web server capable of communicating
with the user’s application.
In the client side, an interface for mobile devices was created that guarantees
alternative accessibility, i.e., enables the navigation in the application with speech recognition
and enables the visualization of text and video from the newscasts. A multimodal interface
was created that uses a speaker-independent recognition system, the AUDIMUS, previously
developed in the L2F laboratories.
In this service the user is given 3 types of research methods in the database: free
search, by date and the last news titles. In addition, a matching system was created that is able
to provide multimedia data accordantly with the profile chosen by the user. Whenever there is
²F - Spoken
new information that corresponds with the user’s profile, he will be notified.
Language Systems Laboratory
Keywords
•
•
•
•
•
•
Processing of multimedia information
Multimedia selective data distribution
Mobile Devices
Streaming
Multimodal Interface
Speech Recognition
Carlos Bandeirinha, Diogo Areia iii
AGRADECIMENTOS...........................................................................................................................................I
RESUMO .............................................................................................................................................................. II
PALAVRAS-CHAVE .......................................................................................................................................... II
ABSTRACT.........................................................................................................................................................III
KEYWORDS.......................................................................................................................................................III
LISTA DE FIGURAS ......................................................................................................................................... VI
LISTA DE TABELAS ..................................................................................................................................... VIII
LISTA DE SIGLAS ............................................................................................................................................ IX
1
INTRODUÇÃO ........................................................................................................................................... 1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
2
SERVIDOR .................................................................................................................................................. 9
2.1
2.1.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
3
J2ME...................................................................................................................................................23
TELEMÓVEIS ........................................................................................................................................25
PDA´S .................................................................................................................................................30
JAVA NOS PDA´S .................................................................................................................................31
CONCLUSÃO/TOMADA DE DECISÃO .....................................................................................................32
CAP4 – A APLICAÇÃO NO PDA............................................................................................................35
4.1
4.2
4.3
4.4
4.4.1
4.4.2
4.4.3
4.5
4.6
4.7
4.8
4.9
iv
WEBSERVER ........................................................................................................................................... 9
Apache ou Jetty ............................................................................................................................... 9
O XML................................................................................................................................................10
SAX, DOM, BASE DE DADOS NATIVA XML........................................................................................11
ESCOLHA DA BASE DE DADOS NATIVA ................................................................................................12
BASE DE DADOS EXIST .........................................................................................................................13
XQUERY VS XPATH ..............................................................................................................................13
-IMPLEMENTAÇÃO INICIAL DO SERVIÇO ...............................................................................................14
DESEMPENHO DO SERVIÇO ...................................................................................................................15
O PROJECTO HIBERNATE .......................................................................................................................18
O TRABALHO DESENVOLVIDO ..............................................................................................................22
CAP.3- DISPOSITIVOS MÓVEIS ...........................................................................................................23
3.1
3.2
3.3
3.4
3.5
4
ÁREA DO TRABALHO ............................................................................................................................ 1
PROCESSAMENTO DE INFORMAÇÃO MULTIMÉDIA ................................................................................ 1
DISTRIBUIÇÃO SELECTIVA DE DADOS MULTIMÉDIA.............................................................................. 1
INTERFACES MULTIMODAIS .................................................................................................................. 2
DISPOSITIVOS MÓVEIS .......................................................................................................................... 2
TECNOLOGIAS WIRELESS (UMTS,GPRS, WIFI) .................................................................................... 3
CONCEITO DO SERVIÇO ......................................................................................................................... 3
RECONHECIMENTO DA FALA ................................................................................................................. 4
O PROJECTO ALERT E O SSNT-SERVICE ........................................................................................... 4
OBJECTIVOS PARA ESTE TRABALHO ...................................................................................................... 5
ARQUITECTURA DO SERVIÇO ................................................................................................................ 5
-FASES DO TRABALHO........................................................................................................................... 7
-ORGANIZAÇÃO DO RELATÓRIO ............................................................................................................ 7
VISÃO GERAL DO AWT (ABSTRACT WINDOW TOOLKIT) .......................................................................35
VISÃO GERAL DO SWING ......................................................................................................................37
O DESENVOLVIMENTO DA INTERFACE GRÁFICA NO PDA.....................................................................40
O VÍDEO NO PDA ................................................................................................................................43
Java Media Framework .................................................................................................................43
RealPlayer para PocketPC ............................................................................................................44
Desempenho do JMF vs RealPlayer ..............................................................................................44
BROWSER + REALPLAYER ...................................................................................................................47
JAVA + JMF.........................................................................................................................................47
JAVA + REALPLAYER ..........................................................................................................................48
HELIX STREAMING SERVER ..................................................................................................................49
INTEGRAÇÃO COM O PROJECTO SSNT-SERVICE ...................................................................................49
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
4.10
5
CAP.5 INTERFACE MULTIMODAL COM FALA ..............................................................................52
5.1
5.2
5.3
5.4
5.5
5.6
6
TECNOLOGIAS EXISTENTES ..................................................................................................................52
VOICEXML...........................................................................................................................................54
XHTML+VOICE ...................................................................................................................................56
AUDIMUS..........................................................................................................................................58
O RECONHECIMENTO DE FALA NO APLICAÇÃO DESENVOLVIDA ...........................................................58
TRABALHO REALIZADO ........................................................................................................................60
CAPITULO 6- DESCRIÇÃO DO SERVIÇO / TESTES........................................................................61
6.1
6.2
6.3
6.4
6.5
6.6
6.7
7
DESCRIÇÃO DO TRABALHO REALIZADO ...............................................................................................50
O SERVIÇO DE MATCHING .....................................................................................................................61
A PESQUISA DIRECTA NA BASE DE DADOS ............................................................................................64
COMANDOS DE VOZ .............................................................................................................................66
A CODIFICAÇÃO DO VÍDEO ...................................................................................................................67
TESTES DO RECONHECEDOR EM DIFERENTES AMBIENTES: ...................................................................67
TESTES COM VÁRIOS ORADORES ..........................................................................................................71
RESULTADOS ALCANÇADOS .................................................................................................................71
CONSIDERAÇÕES FINAIS.....................................................................................................................73
7.1
7.2
7.3
7.4
O PROJECTO REALIZADO ......................................................................................................................73
LIMITAÇÕES E TESTES AO SERVIÇO ......................................................................................................74
DESENVOLVIMENTOS FUTUROS ...........................................................................................................75
NOTA FINAL .........................................................................................................................................75
BIBLIOGRAFIA..................................................................................................................................................76
Carlos Bandeirinha, Diogo Areia
v
Lista de Figuras
FIGURA 1.1-BREVE DESCRIÇÃO DO PROJECTO ALERT............................................................................................ 4
FIGURA 1.2- ARQUITECTURA DO SERVIÇO ............................................................................................................... 6
FIGURA 2.1-ARQUITECTURA INICIAL DO SERVIÇO ................................................................................................... 9
FIGURA 2.2 -ESTRUTURA DO XML .........................................................................................................................10
FIGURA 2.3-EXEMPLO DE UM FICHEIRO XML.........................................................................................................12
FIGURA 2.4-SERVIÇO INICIALMENTE IMPLEMENTADO ............................................................................................14
FIGURA 2.5-XQUERY ...............................................................................................................................................15
FIGURA 2.6-RESULTADO OBTIDO NO BROWSER .......................................................................................................15
FIGURA 2.7- PERFORMANCE DO EXIST ....................................................................................................................16
FIGURA 2.8 PROBLEMAS DE MEMÓRIA DO EXIST ....................................................................................................17
FIGURA 2.9 RESULTADOS COM O XQUERY ..............................................................................................................17
FIGURA 2.10-DIAGRAMA UML DA BASE DE DADOS DO SSNT................................................................................19
FIGURA 2.11 ESTRUTURA DA CLASSE PROGRAM.JAVA ...........................................................................................20
FIGURA 2.12-ESTRUTURA DO FICHEIRO PROGRAM.HBM.JAVA................................................................................21
FIGURA 2.13- ESTRUTURA FINAL DO SERVIDOR ......................................................................................................21
FIGURA 3.1 DISPOSITIVOS ASSOCIADOS ÁS CONFIGURAÇÕES CDC E CLDC...........................................................23
FIGURA 3.2 RELAÇÃO ENTRE O CDC E CLDC ........................................................................................................24
FIGURA 3.3 - AS DIFERENTES PLATAFORMAS JAVA .................................................................................................24
FIGURA 3.4 API´S DO J2ME...................................................................................................................................25
FIGURA 3.5 MÉTODOS DE UMA MIDLET..................................................................................................................27
FIGURA 3.6 MMAPI ...............................................................................................................................................28
FIGURA 3.7 ARQUITECTURA DA MMAPI................................................................................................................29
FIGURA 3.8 INSTRUÇÕES PARA A REPRODUÇÃO DE VÍDEO ......................................................................................29
FIGURA 3.9 TELEMÓVEIS QUE SUPORTAM STREAMING VIA RTSP ............................................................................30
FIGURA 3.10- IPAQ H3870 ......................................................................................................................................31
FIGURA 3.11 –CONSOLA DO JEODE .........................................................................................................................33
FIGURA 3.12 CONSOLA DO CREME ..........................................................................................................................33
FIGURA 3.13- CONSOLA DO J9 ................................................................................................................................34
FIGURA 3.14 CONSOLA DO MYSAIFU .......................................................................................................................34
FIGURA 4.1-COMPONENTES DO AWT.....................................................................................................................36
FIGURA 4.2 LAYOUTS DO AWT ..............................................................................................................................36
FIGURA 4.3 EVENTOS DO AWT ..............................................................................................................................37
FIGURA 4.4 COMPONENTES DO SWING ....................................................................................................................38
FIGURA 4.5 LAYOUTS DO SWING .............................................................................................................................39
FIGURA 4.6 EVENTOS DO SWING .............................................................................................................................39
FIGURA 4.7- PAINEL PRINCIPAL DA APLICAÇÃO NAS DIFERENTES MÁQUINAS VIRTUAIS..........................................40
FIGURA 4.8 DIFERENÇA ENTRE AS VERSÕES DO MYSAIFU .......................................................................................41
FIGURA 4.9 ACTIVAÇÃO DO RECONHECIMENTO DE FALA NA APLICAÇÃO ...............................................................41
FIGURA 4.10 ACTIVAÇÃO DO RECONHECIMENTO DE FALA NO PDA .......................................................................41
FIGURA 4.11 APLICAÇÃO EM SWING NO PC E NO PDA...........................................................................................42
FIGURA 4.12 APLICAÇÃO EM SWING NO PC E PDA ................................................................................................42
FIGURA 4.13 JMSTUDIO ..........................................................................................................................................44
FIGURA 4.14 REALPLAYER PARA POCKET PC .........................................................................................................44
FIGURA 4.15- VÍDEO CODIFICADO COM O CINEPAK .................................................................................................46
FIGURA 4.16- RUNTIME.EXEC() ..............................................................................................................................48
FIGURA 4.17 SOLUÇÃO JAVA +REALP LAYER .........................................................................................................49
FIGURA 4.18 INTEGRAÇÃO COM O PROJECTO SSNT................................................................................................50
FIGURA 5.1- VOICE LOOKUP ...................................................................................................................................52
FIGURA 5.2 PDSAY .................................................................................................................................................53
FIGURA 5.3 VOICE XML.........................................................................................................................................54
FIGURA 5.4 REDE DE COMUNICAÇÃO DO VOICEXML ..............................................................................................55
FIGURA 5.5 OS COMPONENTES DA GATEWAY VOICEXML ......................................................................................55
FIGURA 5.6 DETALHES DA ARQUITECTURA .............................................................................................................56
FIGURA 5.7 TECNOLOGIA X+V ..............................................................................................................................57
FIGURA 5.8NETFRONT BROWSER –PIZZA DEMO ....................................................................................................57
FIGURA 5.9 O RECONHECIMENTO DE FALA NO AUDIMUS.....................................................................................58
vi
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
FIGURA 5.10 O PROCESSO DE RECONHECIMENTO DO AUDIMUS...........................................................................59
FIGURA 5.11 O VOCABULÁRIO ESCOLHIDO .............................................................................................................59
FIGURA 6.1 ARQUITECTURA DO APLICAÇÃO ...........................................................................................................61
FIGURA 6.2 A PÁGINA DE ENTRADA DO WEBSITE SSNT .........................................................................................62
FIGURA 6.3 A PÁGINA DE REGISTO DO UTILIZADOR ................................................................................................62
FIGURA 6.4 ALTERAÇÃO DE PERFIL/ DEFINIÇÃO DOS TÓPICOS ................................................................................63
FIGURA 6.5 O ESQUEMA DE MATCHING ...................................................................................................................63
FIGURA 6.6 XML COM OS ÚLTIMOS ACESSOS DO UTILIZADOR ................................................................................64
FIGURA 6.7 SERVIÇO DE MATCHING NO PDA ..........................................................................................................64
FIGURA 6.8 PAINEL DE PESQUISA LIVRE ..................................................................................................................64
FIGURA 6.9 PESQUISA LIVRE ...................................................................................................................................65
FIGURA 6.10 PESQUISA POR DATAS DE TELEJORNAL ...............................................................................................65
FIGURA 6.11-PESQUISA POR TÍTULOS .....................................................................................................................66
FIGURA 6.12 A CODIFICAÇÃO DO VÍDEO .................................................................................................................67
FIGURA 6.13 AMBIENTE SILENCIOSO ......................................................................................................................68
FIGURA 6.14 AMBIENTE COM MÚSICA ....................................................................................................................68
FIGURA 6.15 NO BAR DE ENGENHARIA CIVIL DO IST ..............................................................................................68
FIGURA 6.16 AUDIMUS.XML ..............................................................................................................................69
FIGURA 6.17-JANELA DE 150*10MS=1,5S ..............................................................................................................69
FIGURA 6.18 SILÊNCIO PROVOCADO PELO PDA ......................................................................................................70
FIGURA 6.19 NA VARANDA DO INESC ...................................................................................................................70
Carlos Bandeirinha, Diogo Areia vii
Lista de Tabelas
TABELA 3.1 TELEMÓVEIS COMPATÍVEIS COM JAVA [4]..........................................................................................26
TABELA 4.1 FORMATOS E CODECS SUPORTADOS PELO JMF....................................................................................45
TABELA 4.2 REQUISITOS DE CPU E LARGURA DE BANDA DOS CODECS ...................................................................46
TABELA 6.1 TESTES COM VÁRIOS ORADORES .........................................................................................................71
viii
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Lista de Siglas
AWT- Abstract Window Toolkit
API- Application Programming Interface
AVI- Audio Video Interleaved
CD- Compact Disc
CDC- Connected Device Configuration
CLDC- Connected Limited Device Configuration
CPU- Central Processing Unit
DOM- Document ObjectModel
EOS- End Of Sentence
FAQ- Frequently Asked Question(s), Frequently
FTP- File Transfer Protocol
GPRS- General Packet Radio SERVICE
GNU- GNU is Not Unix (acrónimo recursivo)
GPL- General Public License
GUI- Graphic User Interface
HTTP- HyperText Transfer Protocol
HTML- HyperText Markup Language
HQL- Hibernate Query Language
HMM- Hidden Markov Model
INESC-ID- Instituto de Engenharia de Sistemas e Computadores ID Lisboa
IST- Instituto Superior Técnico
J2ME- Java 2 platform Micro Edition
J2SE- Java 2 Standard Edition
JDBC- Java Database Connectivity
JDK- Java Development Kit
JFC- Java Foundation Classes
JMF- Java Media Framework
JNI- Java Native Interface
JPEG- Joint Photographic Experts Group
JSP- Java Server Pages
JSR- Java Specification Requests
L2F- Laboratório de língua Falada
MIDP- Mobile Information Device Profile
MIME- Multipurpose Internet Mail Extensions.
MLP- Multilayer Perceptron
MMAPI- MultiMedia API
MP3- MPEG-1/2 Audio Layer 3
MPEG- Motion Picture Experts Group
NXD- Native X ML databases
ORM- Object-Relational Mapping
PC- Personal Computer
PCM- Pulse Code Modulation
PDA- Personal Digital Assistant
PP- Personal Profile
RAM- Random Acess Memory
RM- Real Media
ROM- Read Only Memory
RPC- Remote Procedure Call
Carlos Bandeirinha, Diogo Areia ix
RTOS- Real Time Operating System
RTP- Real Time Protocol
RTSP- Real Time Streaming Protocol
SAX- Simple API for XML
SDK- Software Development Kit
SMIL- Synchronized Media Integration Language
SOAP- Simple Object Access Protocol
SQL- Structured Query Language
SSNT- Sumarização de Serviços Noticiosos de Telejornal
SWT- Standard Widget Toolkit
TTS- Text-to-Speech
UML- Unified Modeling Language
UMTS- Universal Mobile Telecommunications System
WIFI- Wireless Fidelity
WML- Wireless Markup Language
XHMTL- eXtensible Hypertext Markup Language
XML- eXtensible Markup Language
XSLT- eXtensible Stylesheet Language for Transformation
x
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
1
1.1
Introdução
Área do Trabalho
Na sociedade actual, o acesso à informação de uma forma rápida e simples torna-se
uma necessidade cada vez mais premente. Neste domínio, os computadores, PDA’s e
telemóveis são cada vez mais utilizados, proporcionando novas e diferentes formas de
interacção suportadas por inovações tecnológicas.
A informação que é disponibilizada pela televisão, rádio, jornais e web pode ser agora
acedida através dos dispositivos móveis, que continuam em evolução e poderão oferecer cada
vez melhores desempenhos. No entanto o valor dessa informação depende muito da facilidade
com que se consegue aceder, filtrar, procurar e interagir com os seus conteúdos. Hoje em dia
existe um número incalculável de informação multimédia (em arquivos digitais, na Web, em
bases de dados pessoais ou profissionais, etc.) e este número continua a aumentar
constantemente, tornando-se cada vez mais difícil de gerir estes recursos todos, uma vez que
em muitos casos esta informação não está devidamente estruturada e classificada. Para tal é
necessário a existência de tecnologias que façam a aquisição, armazenamento, indexação e
categorização da informação multimédia. Isto vai permitir que a informação esteja
organizada, facilitando deste modo qualquer tipo de acesso.
1.2
Processamento de informação Multimédia
Para organizar os conteúdos da informação multimédia recorre-se muitas vezes ao
processamento semântico dos conteúdos multimédia. Para isso é necessário capturar essa
informação através de sistemas automáticos que retiram os dados multimédia de emissões
televisivas, emissões de rádio e jornais fazendo então uma análise detalhada do seu conteúdo.
Estes sistemas baseiam-se em tecnologias avançadas de processamento que realizam a
filtragem e indexação dos conteúdos multimédia.
No contexto dos sistemas de língua falada o processamento de informação multimédia
é realizado através de tecnologias de reconhecimento de fala com vocabulários largos,
associados à segmentação e classificação de áudio. Para além disso têm técnicas automáticas
de indexação e sumarização de tópicos, por forma a gerar categorias de informação e marcas
semânticas nos dados multimédia.
Esta caracterização da informação através de diversas ferramentas computacionais
permite um acesso mais simples aos conteúdos multimédia.
No nosso projecto o processamento semântico de informação revelou-se importante
uma vez que foi possível receber os conteúdos desejados devidamente organizados.
1.3
Distribuição selectiva de dados Multimédia
O crescente e rápido desenvolvimento dos sistemas de aquisição, processamento,
armazenamento, transmissão e visualização de informação multimédia tem motivado cada vez
mais a sua difusão. Os Sistemas Multimédia garantem a transmissão dessa informação que
combina diferentes meios de comunicação (texto, áudio, vídeo, gráficos, animações e
Carlos Bandeirinha, Diogo Areia
1
interactividade). Para isso é necessário ter toda a informação disponível numa base de dados,
em diferentes formatos, para cumprir as necessidades de diferentes utilizadores em diferentes
condições. Nestes sistemas podem existir vários módulos de pesquisa à base de dados.
Adicionalmente podem definir-se ainda perfis de acordo com as preferências de cada
utilizador.
1.4 Interfaces Multimodais
As interfaces multimodais permitem ao utilizador interagir de diferentes modos com a
sua aplicação usando meios diferentes dos convencionais (teclado e rato). Estas interfaces
combinam os meios tradicionais de interacção com reconhecimento e síntese de fala e meios
visuais. A principal vantagem deste tipo de aplicações é o facto de serem mais fáceis de
utilizar. Num dispositivo móvel com ecrã reduzido e teclado limitado este tipo de interfaces
revelam-se ainda mais úteis pois uma palavra é fácil de dizer mas muitas vezes pode ser
difícil de escrever.
Neste contexto os sistemas de língua falada associados aos dispositivos móveis são um
tópico que cada vez mais atrai engenheiros e cientistas. Estes sistemas estão cada vez mais a
revelar-se uma necessidade. Permitem realizar interfaces mais atractivas, simples e mais
intuitivas para o utilizador comum, pois é possível realizar diferentes tarefas através de um
diálogo coerente e natural e não apenas através de comandos predefinidos.
1.5 Dispositivos móveis
Hoje em dia os dispositivos móveis assumem um papel fundamental no quotidiano das
pessoas. Dispositivos como telemóveis e PDA´s têm cada vez mais capacidade de
processamento e memória, que se traduz em melhores desempenhos e permite a utilização
nesses mesmos dispositivos de aplicações mais complexas, que outrora apenas poderiam ser
executadas em PC´s. No entanto, ainda apresentam limitações que foram levadas em conta na
realização deste projecto.
• Largura de banda limitada - A conectividade wireless tem diversos inconvenientes
como a quantidade de largura de banda disponível e a limitação de cobertura geográfica
existente.
• Estabilidade da ligação – A estabilidade da ligação nem sempre é ideal devido a
vários factores como o desvanecimento (fading), falta de cobertura de rede, ou à capacidade
deficiente, que tornam as redes wireless frequentemente inacessíveis por períodos de tempo.
• Dimensão do ecrã – Os dispositivos móveis têm ecrãs reduzidos. Os PDA’s têm 320
x 240 pixel, enquanto os telemóveis em média têm apenas 180 x 140 pixel. Isto vai limitar
muito a forma como se desenvolvem as aplicações para estes dispositivos, uma vez que tem
que se ter em conta este espaço reduzido para expor os conteúdos.
• Limitações de teclado - Estes dispositivos dispõem de teclados pequenos e muitas
vezes difíceis de utilizar. Escrever num PDA ou num telemóvel é sempre mais lento e
complicado do que escrever num PC, para não falar do facto de não se ter um “mouse” (como
nos PC’s).
2
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
• Memória e CPU limitados – Estes dispositivos não possuem o poder computacional
e a memória encontrados num PC. Dispositivos recentes, como os PocketPC são uma
excepção, com um processador (CPU) que pode ir dos 133 aos 206 MHz e com memória
interna de 64MB RAM, apresentando assim desempenhos aceitáveis.
• Limitações a nível da bateria – a limitação das baterias é um dos interesses
principais para os fabricantes destes dispositivos. A capacidade de uma bateria restringe as
operações a aproximadamente quatro ou cinco horas na maioria dos PDA’s.
1.6 Tecnologias wireless (UMTS,GPRS, WiFi)
Com o aparecimento das tecnologias wireless, através das redes móveis, mudou-se
radicalmente a maneira de comunicar. O utilizador deixou de ser um receptor passivo e
passou a poder interagir com uma disponibilidade de meios até agora impossíveis de
conjugar, independentemente do local em que se encontra. As comunicações passaram a
acompanhar o utilizador e não o contrário como antigamente.
O streaming de vídeo para dispositivos móveis não era encarado com grande
importância no passado uma vez que a segunda geração (2G, GPRS) destes dispositivos não
cumpriam os requisitos necessários em termos de débito binário.
Devido ao desenvolvimento drástico em termos de tecnologia wireless já é possível
realizar transferência de dados a um ritmo binário muito superior como é o caso das redes
wireless 2.5G e 3G (UMTS) que suportam ritmos desde os 64kbps até 2Mbps. As operadoras
passaram a dispor da possibilidade de oferecer aos seus clientes várias aplicações que podem
funcionar em tempo real, podendo assim fornecer serviços que vão para além dos simples
serviços de voz e texto. Estes serviços irão expandir-se por forma a abranger outros aspectos
como a transferências de dados e vídeos interactivos bi-direccionais, mensagens instantâneas,
transferência de imagens, clips de vídeo e clips de vídeo com áudio.
1.7 Conceito do serviço
Este serviço, projectado para dispositivos móveis dá a possibilidade aos seus
utilizadores de aceder de forma contínua a informação multimédia, sendo que o único
requisito é o dispositivo ter acesso a uma rede WiFi.
A informação disponibilizada por este serviço apenas abrange as notícias do telejornal
da RTP, sendo que futuramente poderá abranger outras áreas. Estas notícias já estão
devidamente organizadas por temas de acordo com o seu conteúdo devido ao processamento
semântico da informação multimédia, permitindo-nos realizar uma filtragem correcta de
acordo com os interesses do utilizador. Por outro lado também temos uma distribuição
selectiva do dados multimédia que nos permite efectuar a definição dos perfis do utilizador
para além de permitir a distribuição do vídeo já devidamente codificado de acordo com o
dispositivo.
O utilizador tem então ao seu dispor, uma interface multimodal que possibilita 3 tipos
diferentes de pesquisa:
• Pesquisa livre – permite ao utilizador pesquisar qualquer palavra que pretenda
• Pesquisar datas – permite ao utilizador pesquisar qualquer notícia por data
• Pesquisar títulos – permite ao utilizar pesquisar os títulos de noticias recentes
Carlos Bandeirinha, Diogo Areia
3
Para além disso pode ainda registar-se no serviço, através de uma página Web, onde
define os seus tópicos de interesse (política, desporto, economia, etc.), recebendo-os
posteriormente no seu dispositivo.
As notícias são apresentadas com um título e uma breve descrição, podendo o
utilizador através destes dados escolher se pretende visualizar o vídeo que contém essa
mesma notícia.
Este serviço é uma novidade uma vez que é direccionado para dispositivos móveis. As
principais vantagens deste tipo de dispositivos associados a este serviço são o facto de termos
sempre acesso à informação desde que se esteja numa área coberta por uma rede WiFi e o
facto de estes dispositivos garantirem uma maior mobilidade ao utilizador.
1.8 Reconhecimento da fala
Os sistemas de língua falada associados aos dispositivos móveis são um tópico que
cada vez mais atrai engenheiros e cientistas. Estes sistemas estão cada vez mais a revelar-se
uma necessidade. Permitem realizar interfaces mais atractivas, simples e intuitivas para o
utilizador comum, pois é possível realizar diferentes tarefas através de um diálogo coerente e
natural e não apenas através de comandos predefinidos.
No nosso caso foi criada uma aplicação onde é possível “navegar” através de fala uma
vez que temos disponível um reconhecedor, o AUDIMUS. Desta forma simplifica-se muito a
interacção com a interface, pois esta é uma solução que dispensa o uso tradicional dos
teclados dos dispositivos móveis que são bastante limitativos.
1.9 O projecto ALERT e o SSNT-SERVICE
O ponto de partida deste projecto consistiu em obter a informação proveniente das
noticias de telejornal resultantes do projecto ALERT desenvolvido pelo L2F (INESC-ID
Lisboa). O resultado deste projecto está condensado num ficheiro XML que contém a
transcrição, classificação acústica, categorização e indexação de cada telejornal capturado. Foi
a partir deste ficheiro que se começou a pensar numa forma de construir o nosso serviço. Uma
breve descrição deste projecto pode ser seguida na figura 1.1.
Na máquina CAPTURE é onde se captura o sinal de vídeo da emissão do programa em
captura. Terminada a captura do vídeo arranca na máquina PROCESS o processo de
reconhecimento e classificação acústica do ficheiro de vídeo recebido. È também aqui que
acontece a categorização e sumarização das noticias. O resultado deste processo está presente
no ficheiro XML.
Figura 1.1-Breve descrição do projecto ALERT
4
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
A máquina SERVICE encarrega-se de armazenar toda a informação contida no XML numa
base de dados (BD-SSNT). Importa também salientar que nesta máquina é armazenado o
ficheiro de vídeo (no formato RealVídeo) do programa processado. Nesta máquina existe
também um serviço , sob a forma de uma página Web, onde o utilizador se pode registar e
receber as noticias pretendidas de acordo com o perfil definido, serviço de matching. Estes
módulos foram criados no âmbito do projecto SSNT1, desenvolvido no L2F.
Depois de analisar o modo de funcionamento e as limitações destes dois projectos , o
ALERT e o SSNT-Service, começámos a pensar numa forma de disponibilizar o conteúdo
destes projectos em dispositivos móveis.
1.10 Objectivos para este trabalho
Para a realização deste projecto é necessário criar um sistema servidor/cliente para a
distribuição das notícias e respectivo vídeo. Será necessário criar e disponibilizar um servidor
que comunique com o cliente e que seja capaz de responder aos seus pedidos. É obrigatório
que este servidor faça a ligação à base de dados que contém a informação relativa aos
telejornais, e que disponibilize também o vídeo associado a cada telejornal. Neste contexto
será necessário ter em conta a largura de banda suportada por cada dispositivo móvel, a
capacidade de processamento , o tipo de codificação de vídeo usado e os protocolos usados na
comunicação entre o cliente e servidor. A base de dados terá que ser fiável, capaz de
responder a pedidos simultâneos e com tempos de resposta aceitáveis.
No lado do cliente é necessário criar uma interface gráfica em Java, perceptível e fácil
de utilizar, que comunique com o servidor de forma a apresentar todos os conteúdos
pretendidos pelo utilizador. Tendo em conta as limitações destes dispositivos e as restrições
ao nível de processamento gráfico será necessário arranjar soluções para a recepção e
visualização do vídeo das notícias.
Por forma a criar uma interface multimodal será necessário introduzir reconhecimento
de fala na aplicação. Dadas as limitações destes dispositivos será necessário criar um
reconhecedor que funcione em modo de servidor para evitar que o dispositivo seja
sobrecarregado com o processamento dos módulos de reconhecimento. O projecto
AUDIMUS criado no L2F será usado para efectuar este reconhecimento.
O objectivo deste trabalho é então criar um serviço que ofereça ao utilizador de um
dispositivo móvel um constante acesso a informação multimédia de uma forma simples,
prática e eficaz.
1.11 Arquitectura do Serviço
Neste projecto foi criada uma aplicação em J2ME para dispositivos móveis em que o
utilizador poderá registar-se através de um serviço já disponível (SSNT-SERVICE) e receber
as notícias no seu dispositivo de acordo as suas preferências, ou então realizar uma pesquisa
livre em que pode escolher qualquer tema que pretenda sem necessidade de registo prévio.
Esta aplicação permite ainda realizar pesquisas por datas ou por títulos.
A estrutura arquitectura geral do serviço está descrita na Figura-2 através de um
esquema por forma a simplificar a compreensão.
1
Sumarização de Serviços Noticiosos Televisivos
Carlos Bandeirinha, Diogo Areia
5
ALERT / SSNT-Service
Captura
Processamento
Clientes
registados
Base de
dados
SSNT
Web
Page
Servidor
Rede
WiFi
Web
Server
AUDIMUS
UMTS
Figura 1.2- Arquitectura do Serviço
Como se pode ver no esquema, o projecto criado será uma extensão do projecto
ALERT que realiza a captura e processamento das notícias. Aproveita-se também o projecto
SSNT-Service que disponibiliza as notícias numa base de dados, que é actualizada
diariamente.
O nosso projecto está fortemente ligado ao SSNT-Service uma vez que todos os
conteúdos são retirados da sua base de dados (utilizadores, vídeo, telejornais) e o
registo/alteração de perfil de utilizador é realizado na web page já existente do SSNT .
Nesta arquitectura, a aplicação disponível no terminal do utilizador liga-se a um
servidor que contém um web server e o reconhecedor de fala, o AUDIMUS. O web server é
responsável por comunicar com a base de dados do SSNT-Service e faz também a gestão do
envio dos pacotes de vídeo para o terminal do utilizador. O reconhecedor AUDIMUS
funciona em modo de servidor, ou seja , recebe o áudio capturado no terminal do utilizador ,
faz o reconhecimento e devolve o resultado.
6
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Neste arquitectura está implícito que o utilizador necessita de estar abrangido por uma
rede WiFi, no caso de usar um PDA ou por uma rede UMTS ou GPRS , no caso de usar um
telemóvel. No dispositivo móvel apenas é necessário estar instalada a aplicação desenvolvida
neste projecto que já está configurada para funcionar de acordo com esta arquitectura.
1.12 -Fases do trabalho
Ao longo da realização deste trabalho, podemos destacar 3 diferentes etapas.
•
•
•
Estruturação da informação, implementação do servidor e da base dados
Estabelecimento da ligação entre o terminal do utilizador e o servidor. A Escolha dos
protocolos de comunicação que melhor se adeqúem ao tipo de serviço.
Implementação de uma aplicação que seja atractiva e prática do ponto de vista do
utilizador.
Na primeira fase, foi necessário projectar o modo como o sistema iria funcionar, ou
seja projectar o servidor e o modo como este acede á informação armazenada. Foi necessário
compreender o modo de funcionamento do projecto SSNT-Service , a estrutura da sua base de
dados e o modo como a informação proveniente dos telejornais era tratada e armazenada.
Na segunda fase foi necessário criar rotinas de pesquisa para aceder aos pedidos do
cliente. Foi necessário escolher o tipo de comunicação entre servidor e cliente e escolher os
protocolos necessários para o envio dos dados multimédia(vídeo , áudio e texto).
Finalmente, na terceira fase foi necessário criar um ambiente gráfico de forma a ser o
mais fácil possível de manusear e navegar com comandos de voz , foi ainda necessário criar
uma solução para a apresentação do vídeo das notícias no dispositivo móvel. Tivemos que
fazer alguma investigação sobre as soluções existentes na criação de aplicações nos
dispositivos móveis, nomeadamente ao nível do software de desenvolvimento. Nesta fase
implementou-se o processo de reconhecimento de fala descrito anteriormente.
1.13 -Organização do relatório
Concluída a apresentação deste projecto, no capítulo 2 abordamos o servidor, a
escolha do webserver , a escolha da base de dados e as alternativas ás soluções inicialmente
consideradas com o objectivo de melhorar o desempenho das pesquisas.
No capitulo 3 abordamos os dispositivos móveis a que se destina este trabalho.
Apresentamos uma visão geral do J2ME , que é um sub-domínio do Java, neste tipo de
dispositivos (telemóveis e PDA´s). Dadas as limitações destes dispositivos escolhemos aquele
que nos proporciona mais soluções ao nível de ambiente de testes e compatibilidades.
No capitulo 4 abordamos a aplicação no PDA, a escolha do toolkit, o AWT ou Swing ,
e qual a melhor solução. Descrevemos a interface gráfica criada e o modo como
disponibilizamos o vídeo neste dispositivo.
No capitulo 5 abordamos o conceito de interface multimodal. Tivemos em conta as
tecnologias existentes na criação de uma interface multimodal. Neste capitulo descrevemos
ainda o modo como introduzimos o reconhecimento de fala na nossa aplicação.
No capitulo 6 apresentamos uma descrição do serviço , especificando o conceito de
serviço de matching e os tipos de pesquisas fornecidos. Apresentamos também os testes
Carlos Bandeirinha, Diogo Areia
7
realizados ás codificações do vídeo ,os testes realizados no reconhecedor em diferentes
ambientes e os resultados do reconhecimento de diferentes oradores.
Finalmente no capitulo 7 são descritas as considerações finais relativamente ao
projecto realizado.
8
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
2
Servidor
A função principal do servidor é estabelecer um meio de comunicação entre o
equipamento terminal do utilizador e a base de dados. Neste capítulo está descrita a
investigação realizada na escolha do webserver , o modo como se estruturou e armazenou a
informação proveniente do XML , os tipos de pesquisas criados e apresentam-se as soluções
inicialmente propostas , os testes realizados e os problemas que surgiram. Finalmente
apresentam-se as soluções a estes problemas.
Na fase inicial do projecto tentámos implementar um sistema constituído por uma
base de dados nativa em XML e um servidor Web para receber pedidos dos utilizadores. A
figura 2.1 apresenta de forma simplificada o que foi atrás referido.
Figura 2.1-Arquitectura inicial do serviço
2.1 webserver
A função do webserver é receber pedidos por parte do utilizador e devolver os
resultados obtidos. A função principal deste webserver é gerar conteúdo dinâmico através de
rotinas de pesquisa na base de dados desenvolvidas em Java e disponibilizar essas pesquisas
ao utilizador. Como se trata de um webserver o protocolo usado na comunicação com o
cliente é o HTTP . Existem algumas soluções disponíveis no mercado, a investigação que
realizámos levou-nos a consideras duas alternativas, o Apache/Tomcat ou o Jetty.
2.1.1 Apache ou Jetty
Na escolha do servidor Web considerámos duas soluções : Apache/Tomcat HTTP
Server1 e Jetty HTTP Server2. Embora o Apache seja um servidor com bastantes
funcionalidades é necessário dispender algum tempo na sua configuração, e é necessário uma
máquina dedicada para correr o este servidor. Ao invés o Jetty HTTP Server é um servidor
bastante mais simples de usar, é totalmente implementado em Java e pode integrar-se
directamente no contexto da nossa aplicação. A escolha, portanto ,caiu sobre o Jetty.
Jetty é um servidor HTTP e um servlet container 100 % Java. Isto significa que não
necessitamos de configurar e executar um Web server separado ( como o apache) por forma a
usar Java , servlets e JSP´s para gerar conteúdo dinâmico. O Jetty pode gerar tanto conteúdo
1
2
http://httpd.apache.org/
http://www.mortbay.org/jetty/index.html
Carlos Bandeirinha, Diogo Areia
9
estático como dinâmico. Tem a vantagem de se poder executar o servidor Web e a aplicação
no mesmo processo , sem grandes complicações a nível de overheads .Mais uma vez este
software é Open Source ,sob a Apache 2.0 license1, o que constitui uma mais valia.
2.2 O XML
Dado que na fase inicial do nosso projecto centrámos as nossas atenções no ficheiro
XML proveniente da máquina PROCESS para criar a base de dados, foi necessário
compreender a forma como estava organizada a informação dentro do XML. A Figura 2.2
representa de uma forma simplificada a estrutura/Hierarquia do XML2:
Figura 2.2 -Estrutura do XML
1
2
http://www.apache.org/licenses/
O DTD deste ficheiro encontra-se no anexo A
10
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Em cada XML existe um elemento Transcript com os sub-domínios VersionGUID e
StorySegment. O elemento VersionGUID contém a data e a hora da emissão gravada e o
elemento StorySegment representa cada notícia detectada.
Dentro de cada StorySegment podem existir vários TranscriptSegments, existe também
um elemento ThematicDescriptorList, GeographicDescriptorList, OnomasticDescriptorList,
Title, Abstract e StoryRepresentation. O elemento TranscriptSegments contém todas as frases
contidas na noticia. ThematicDescriptorList representa a área temática de cada noticia,
GeographicDescriptorList contém todas as referências geográficas contidas em cada notícia e
OnomasticDescriptorList contém todos os nomes contidos na notícia , sejam eles nomes de
pessoas, empresas, instituições, siglas, etc. O elemento Title apresenta um título para a notícia
(StorySegment) , o elemento Abstract apresenta uma descrição um pouco mais pormenorizada
do conteúdo da noticia e finalmente o elemento StoryRepresentation contém todas as palavras
relevantes da noticia.
2.3 SAX, DOM, Base de dados nativa XML
De forma a aceder ao conteúdo do XML, fomos tentados a usar um parser de XML
em Java. Explorámos duas API´s , o SAX ( “Simple Api for XML”)1 e o DOM2 ( “Document
Oject Model”).
O SAX é uma API de XML orientada ao tratamento de eventos e faz o parsing do
XML sem necessitar de ter acesso ao documento como um todo. Tem a vantagem de ser uma
API rápida mas é sensível a qualquer alteração na estrutura do XML.
O DOM é também uma API de XML que , ao contrário do SAX, carrega toda a
estrutura do XML para memória permitindo navegar e extrair dados dessa estrutura em
árvore. O DOM permite que seja usada uma linguagem de pesquisa de nós numa árvore , o
XPath .
A vantagem duma base de dados nativa XML quando comparada com o SAX e o
DOM é o facto de podermos armazenar nesta base de dados vários documentos XML
enquanto se usássemos o SAX ou DOM teríamos que nos preocupar com a manipulação de
cada XML.
Uma base de dados nativa XML , “Native XML Database ( NXD )”, define um
modelo lógico para o documento XML o qual deve incluir elementos , atributos , PCDATA e
manter a ordem da informação. Exemplos destes modelos são o XPath ,o DOM e o SAX.
Este tipo de base de dados tem como unidade fundamental de armazenamento lógico um
documento XML tal como uma base de dados relacional tem como unidade fundamental uma
linha numa tabela.
Estas bases de dados são uma ferramenta simples para manipulação de documentos
XML pois mantêm o modelo do XML intacto ao mesmo tempo que permitem um
armazenamento bastante robusto e eficaz.
As bases de dados NXD permitem-nos fazer queries a colecções de documentos mesmo que
nem todos esses documentos possuam a mesma estrutura, esta propriedade é conhecida como
schema-independent.
A linguagem mais utilizada para fazer queries á base de dados NXD é o XPath3 pois permite
fazer queries simultaneamente a várias colecções e a sua sintaxe é relativamente simples e
intuitiva. Por exemplo se considerarmos o XML da figura 2.3:
1
http://www.saxproject.org/
http://www.w3.org/DOM/
3
http://www.w3.org/TR/xpath
2
Carlos Bandeirinha, Diogo Areia 11
Figura 2.3-Exemplo de um ficheiro XML
A expressão em XPath /bookstore/book[1], selecciona o primeiro elemento <book>
que é filho do elemento <bookstore>.Convém referir que o XPath possui algumas
limitações, estando a ser desenvolvida uma linguagem mais apropriada , o XQuery .
De forma a aumentar a performance das queries, estas bases de dados suportam a
criação de índices referentes aos dados armazenados nas colecções. Estes índices podem ser
usados de forma a aumentar a velocidade das queries.
2.4 Escolha da Base de Dados nativa
De entre as bases de dados nativas disponíveis no mercado e dando especial atenção
aquelas que são livres de qualquer custo, obtivemos as seguintes possibilidades:
•
•
•
•
•
•
•
•
•
•
•
•
1
4Suite, 4Suite Server1
Berkeley DB XML2
DBDOM3
dbXML
eXist4
myXMLDB5
Ozone6
XDBM7
XDB8
Xindice9
XpSQL10
Sedna XML DBMS1
, http://4suite.org/index.xhtml
http://www.sleepycat.com/products/bdbxml.html
3
http://dbdom.sourceforge.net/
4
http://exist.sourceforge.net
5
http://sourceforge.net/projects/myxmldb/
6
http://ozone-db.org/frames/home/what.html
7
http ://sourceforge.net/projects/xdbm/
8
http://zvon.org/index.php?nav_id=61
9
http://xml.apache.org/xindice/
10
http://gborg.postgresql.org/project/xpsql/projdisplay.php
2
12
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Dado que as possibilidades eram muitas, usámos alguns critérios de selecção, entre os
quais a data do lançamento da ultima versão do software. Assim sendo, eliminámos as bases
de dados que tinham a versão mais recente anterior a 2004. Eliminámos também as bases de
dados que não tinham API´s em Java e procurámos usar uma base de dados que nos
concedesse algumas facilidades, tais como bom apoio ao programador, fóruns , FAQ´s e
documentação técnica. Eliminámos algumas hipóteses, mas mesmo assim ainda ficámos com
bastantes opções acabando por optar pela base de dados eXist por ser a base de dados que
oferecia maior documentação e suporte.
2.5 Base de Dados eXist
Esta base de dados open source ,sob a licença GNU PGPL, totalmente implementada
em Java, apresenta bons tempos de resposta, apresenta uma boa interface gráfica e é bastante
user friendly. Como foi totalmente implementada em Java pode ser executada em qualquer
máquina, platform independent.
Requerimentos:
Necessita do Java Runtime Environment (JRE) 1.4 ou superior.
Características:
-Suporta várias linguagens de queries a XML como o XQuery , XPath ,
XUpdate e XSLT .
-Possui mecanismos de indexação automáticos que permitem aumentar a
performance das queries.
-Suporta actualização de dados
-Suporta os protocolos SOAP e XML-RPC
-Permite que sejam armazenados dados binários, por exemplo imagens, além
de ficheiros XML.
-Pode usada como uma base de dados embebida , embedded database, ou com
um servlet numa aplicação Web.
-Dispõe de drivers para acesso remoto á base de dados.
-Possui API´s para acesso aos documentos através de DOM ou SAX.
-Suporta os protocolos HTTP/Rest , XML-RPC, SOAP, WebDav
-Limitações:
-Número máximo de documentos que podem ser armazenados é 231
-Tamanho máximo de cada documento armazenado depende do número
de nós que este possui , no máximo pode ter 263 nós.
2.6 XQuery vs XPath
O XPath é uma linguagem bastante simples e directa para manipulação de
documentos XML, possui a sua própria sintaxe para selecção de nós , elementos e atributos.
O XQuery engloba todas as funcionalidades do XPath e ainda suporta expressões
condicionais, construtores de elementos e expressões FLOWR ( For , Let ,Order, Where,
Return). O XQuery partilha alguns conceitos do SQL.O equivalente ao SELECT do SQL é o
1
http://www.modis.ispras.ru/Development/sedna.htm
Carlos Bandeirinha, Diogo Areia 13
RETURN do XQuery , o equivalente ao WHERE do SQL é o ORDER BY do XQuery , etc.
Tanto o SQL como o XQuery permitem a chamada de funções já existentes ou criadas pelo
utilizador. Com o XQuery é possível criar várias queries apenas num acesso á base de dados.
Verificámos então que o XQuery é uma linguagem mais completa quando comparada
com o XPath . Embora com, permite mais regras de sintaxe aumentar bastante a performance
do sistema.
2.7 -Implementação inicial do serviço
Para testar o desempenho do webserver escolhido e da base de dados nativa em XML
criámos um esboço inicial do serviço para realizar alguns testes. A figura 2.4 mostra o modo
como foi implementado este serviço.
Figura 2.4-Serviço inicialmente implementado
Usámos um browser por forma a comunicar com o servlet desenvolvido em Java. O
servlet quando recebe os primeiros pedidos do browser gera HTML que indica ao utilizador
os tipos de pesquisa disponíveis. No caso do utilizador usar um dispositivo móvel (PDA,
Telemóvel) a interacção com o servidor já não será a mesma. Este assunto será abordado mais
tarde , pois por agora só nos interessava testar o desempenho das rotinas de pesquisa na base
de dados.
Implementámos 3 tipos de pesquisa na base de dados:
-Pesquisa Livre
-Pesquisar notícia por data de emissão
-Pesquisar últimas noticias
A pesquisa livre ,como o próprio nome indica, possibilita a pesquisa em noticias que
contenham a palavra ou as palavras pretendidas. Por exemplo, se introduzirmos no campo da
pesquisa livre as palavras “José Sócrates” iremos obter como resultado , todas as notícias que
contenham esse texto. A pesquisa por data de emissão de telejornal permite ao utilizador
visualizar as noticias referentes á data seleccionada. Finalmente, existe também a
possibilidade de se visualizar as noticias mais recentes que foram adicionadas na base de
dados.
Descrevemos de seguida o processo que ocorre numa pesquisa livre. Quando o se
insere na barra de endereços do browser o caminho para o servlet , este gera código HTML
14
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
para possibilitar a inserção da pesquisa pretendida. Após a introdução dos dados da pesquisa
pretendida, o servidor encarrega-se de processar o pedido à base de dados criando uma
expressão XPath . No caso do exemplo anterior, a expressão correspondente seria:
//TranscriptWordList[Word=”josé” and Word=”sócrates”]/../../../VersionGUID
A query
acima indicada, vai retornar a hora e a data de emissão de todos os
telejornais onde as palavras “José Sócrates” existam. Como foi referenciado anteriormente, é
possível escrever a mesma expressão , mas desta vez utilizando a linguagem XQuery1 .(Figura
2.5).
Figura 2.5-XQuery
Depois da pesquisa na base de dados , o servlet encarrega-se novamente de gerar
HTML para mostrar os resultados obtidos, evidencia-se aqui a vantagem de se usar um servlet
porque assim consegue-se gerar conteúdo dinâmico. A figura 2.6 mostra o resultado do que
foi atrás descrito.
Figura 2.6-Resultado obtido no browser
2.8 Desempenho do serviço
Com a implementação descrita anteriormente, conseguimos testar a performance do
serviço criado. A comunicação com o webserver não constitui nenhum problema mas a
performance da base de dados nativa em XML deixou algo a desejar.
Nos primeiros testes realizados , os pedidos à base de dados foram feitos em XPath e
não tivemos qualquer tipo de problema pois na base de dados apenas estavam guardados 3
ficheiros XML. Os problemas começaram a surgir quando se começou a “carregar” a base de
1
http://www.w3.org/TR/xquery/
Carlos Bandeirinha, Diogo Areia 15
dados com mais ficheiros XML. Importa referir que em média cada ficheiro XML ocupa
cerca de 1,5 Mb o que é bastante informação. Quando a base de dados foi carregada com
cerca de 30 ficheiros XML o desempenho do servidor foi completamente desastroso , pois
cada “querie” á base de dados demorava bastante tempo e ao nível de memória tínhamos
problemas de out of memory. Por exemplo, com 35 documentos XML armazenados na base
de dados , uma pesquisa em XPath por forma a encontrar a versão do telejornal , o titulo , o
inicio e o fim da noticia , onde o texto “José Sócrates” se encontrava demorava cerca de 6 s
(Figura 2.7).
Figura 2.7- Performance do eXist
Se quiséssemos encontrar também o sumário da referida pesquisa então já tínhamos
problemas a nível da memória, como mostra a figura 2.8.
16
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 2.8 Problemas de memória do eXist
Noutra abordagem ao problema tentámos usar o XQuery numa tentativa de solucionar estes
problemas de memória. Assim, numa pesquisa á base de dados nos mesmos moldes dos
exemplos anteriores obtivemos os seguintes resultados(Figura 2.9):
figura 2.9 Resultados com o XQuery
Carlos Bandeirinha, Diogo Areia 17
A performance da pesquisa aumentou substancialmente ( tempo de resposta ~ 1s ). A
mesma query , agora escrita em XQuery já não apresentava problemas ao nível de memória e
era cerca de 5 vezes mais rápida do que a mesma query em XPath . Na figura é notório que o
XQuery tem uma sintaxe mais complexa quando comparado com o XPath .
O problema da base de dados parecia solucionado com a utilização do XQuery mas
testes posteriores revelaram que se continuássemos a carregar a base de dados com
documentos XML (realizámos testes com cerca de 100 XML) iríamos continuar a ter
problemas de memória. Outro aspecto problemático foi o acesso simultâneo de vários
utilizadores á base de dados, bastaram 2 utilizadores usar o serviço ao mesmo tempo para que
o sistema falhar.
A solução encontrada foi usar a base de dados em MySQL1 (“ssnt-db”) do projecto
SSNT-Service. Esta base de dados, como descrito no capitulo 1 ,é actualizada com a
informação contida no ficheiro XML sempre que se captura um telejornal. Salientamos que
esta base de dados contém informação de cerca de 2 anos de telejornais e portanto quando
comparada com a base de dados nativa em XML é superior em todos os aspectos (
performance , capacidade de armazenamento , gestão de memória ,..).
Uma vez que o servidor foi totalmente escrito em Java tivemos que arranjar uma
solução por forma a reduzir o mais possível o impacto na mudança da base de dados. A
solução passou pelo projecto Hibernate2, que nos possibilitou aproveitar a maior parte do
código do servidor já escrito.
2.9 O projecto Hibernate
O projecto Hibernate é um software open source que facilita a interacção para entre
linguagens orientadas a objectos, como o Java, e bases de dados relacionais , como o MySQL .
Esta funcionalidade é conhecida na literatura inglesa como Object Relational Mapping
(ORM). O ORM é uma técnica que consiste em mapear um modelo de objectos para um
modelo relacional (usualmente representado por uma base de dados em SQL) . Esta técnica
surge como solução para os casos em que se pretende tornar os objectos persistentes numa
base de dados relacional.
Com o Hibernate não nos temos de preocupar em configurar o JDBC , podemos usar
domínios de objectos (POJOs) e de forma simples criar ficheiros de mapeamento baseados
em XML. Estes ficheiros indicam quais os campos dos objectos que serão mapeados nas
respectivas colunas da base de dados ( na tabela). O Hibernate também possui uma poderosa
linguagem de pesquisa chamada Hibernate Query Language (HQL).
Para integrarmos o Hibernate com o nosso serviço, tivemos que criar os objectos de
acordo com as tabelas da base de dados “ssnt-db”. A figura 2.10, representa um esquema
UML desta base de dados:
1
2
http://www.mysql.com/
http://www.hibernate.org
18
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 2.10-Diagrama UML da base de dados do SSNT
Carlos Bandeirinha, Diogo Areia 19
Depois de analisar o diagrama criámos os objectos necessários para o nosso serviço,
por exemplo, para mapear a tabela “Program” tivemos que criar a classe Program.Java com os
campos ProgramID (Long), Name (String),Sourcename(String) e Signature (String). Foi
necessário criar os construtores adequados e métodos, “get” e “set”, para aceder e modificar
respectivamente os conteúdos destes campos, foi também necessário estabelecer relações de
dependência entre tabelas. A figura 2.11 mostra a estrutura da classe referida:
Figura 2.11 Estrutura da classe Program.java
20
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
As tabelas e os objectos mapeadas da base de dados ssnt-db foram : Program, Episode,
Story, TranscriptSegment, StoryAndDescriptor, Descriptor,User, UserAndDescriptor
,UserTopic e Category. Além das classes criadas, o Hibernate gerou ficheiros de mapeamento
para cada uma das classes, por exemplo para a classe Program.Java o ficheiro de mapeamento
Program.hbm.Java gerado tem a seguinte estrutura(figura 2.12):
Figura 2.12-Estrutura do ficheiro Program.hbm.Java
Os testes realizados foram bastante satisfatórios, considerando o exemplo da pesquisa
por “José Sócrates” o tempo de resposta foi de cerca de 1,5 s ,não esquecendo que esta base
de dados contém 2 anos de telejornais. Se considerarmos que a base de dados em XML teve
um tempo de resposta de cerca de 1 s com 35 telejornais, concluímos que a opção de
implementar o servidor com o Hibernate foi acertada.
A figura 2.13 representa a estrutura final do servidor:
Figura 2.13- Estrutura final do servidor
O webserver recebe pedidos HTTP vindos da Web, os módulos correspondentes ás
rotinas de pesquisa são implementados com o Hibernate que se encarrega de processar os
Carlos Bandeirinha, Diogo Areia 21
pedidos á base de dados. Os resultados da pesquisa são devolvidos ao cliente outra vez via
HTTP.
2.10 O trabalho desenvolvido
A arquitectura inicialmente proposta na fig. 2.1 demonstrou ser funcional á excepção
da utilização de uma base de dados nativa em XML. O tempo que se despendeu na
aprendizagem de linguagens para manipulação de ficheiros XML, e na investigação de bases
de dados de XML , acabou por ser fútil uma vez que este tipo de base de dados não estão ao
nível das bases de dados em SQL. O arquitectura inicialmente proposta na figura 2.4 acabou
por ser extremamente útil pois permitiu-nos testar o serviço criado e assim encontrar
alternativas aos problemas encontrados , nomeadamente ao nível da performance da base de
dados. A alternativa encontrada foi o projecto Hibernate que nos permitiu reaproveitar grande
parte do código escrito em Java e usar uma base de dados em SQL muito mais fiável e
completa. Deste modo criaram-se 3 tipos de pesquisa na base de dados do SSNT-Service e foi
logo possível disponibilizá-las ao utilizador ainda que por intermédio de um browser.
22
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
3 Cap.3- Dispositivos Móveis
Visto que existem inúmeros dispositivos móveis no mercado tivemos que escolher
quais os dispositivos móveis para os quais iríamos desenvolver a nossa aplicação. Decidimos
desenvolver tal aplicação em PDA´s e em telemóveis com tecnologia Java, pois cada vez mais
estes possuem maiores capacidades de processamento e memória. Decidimos desenvolver
maior parte dos dispositivos móveis este serviço em Java , dada a sua universalidade, o que
nos garante a compatibilidade com a existentes no mercado.
3.1 J2ME
O J2ME1 é uma plataforma em Java para dispositivos móveis (embedded devices)
como por exemplo, telemóveis, PDA´s , TV Box´s, etc. O J2ME é constituído por uma
máquina virtual e algumas API´s já definidas pelo Java Community Process2 (JCP), podendo
assim alargar-se a tecnologia Javva a todo o tipo de dispositivos móveis. A grande vantagem é
o facto de se escrever o código apenas uma vez e correr as aplicações em qualquer tipo de
dispositivo que suporte Java. (Write Once , Run Everywhere). Existem duas configurações
para o J2ME:
- Connected Limited Device Configuration (CLDC).
- Connected Device Configuration (CDC).
O CLDC é a mais pequena das duas configurações, concebida para dispositivos com
processadores lentos, e memória limitada (telemóveis, pagers, PDA´s).Estes dispositivos têm
processadores entre 16 e 32 bits e um mínimo de 128kb a 512kb de memória disponível para
a implementação da plataforma Java.
Figura 3.1 Dispositivos associados ás configurações CDC e CLDC
1
2
Java 2 Platform Micro Edition
http://jcp.org/en/home/index
Carlos Bandeirinha, Diogo Areia 23
O CDC é destinado a dispositivos que têm maior memória , processadores mais
rápidos e acesso a redes com grandes larguras de banda.(TV Box´s, Gateway s, PDA´s). O
CDC inclui quase todas as implementações do J2SE quando comparadas com o CLDC. Como
tal , a maior parte destes dispositivos possuem processadores de 32 bits e um mínimo de 2MB
de memória.(Figura 3.1)
A figura (3.2) descreve o que foi dito
anteriormente. Podemos observar que a configuração
CLDC está completamente contida no CDC.
Figura 3.2 Relação entre o CDC e CLDC
Além destas configurações existem também os Perfis (Profiles). Estes perfis
completam o Runtime Environment de acordo com a categoria do dispositivo. Estende-se
assim a funcionalidade das configurações acima descritas. Entre vários perfis destacam-se:
-Mobile Information Device Profile (MIDP). Destinado a telefones móveis , fornece as
funcionalidades básicas a aplicações para dispositivos móveis, inclui interfaces para o
utilizador, configurações de rede, configurações para armazenamento local, etc. Quando
combinada com o CLDC fornece um ambiente de trabalho completo ,reduzindo-se assim a
utilização da memória e o consumo de energia.
-Personal Profile1 (PP). È um perfil usado pela configuração CDC destinado a
dispositivos que requerem uma interface gráfica complexa, Applets, etc. Dispositivos deste
tipo são PDA´s de ultima geração, e consolas de jogos. Inclui uma API completa de AWT (
Abstract Window Toolkit), Api´s para a Web , manipulação de ficheiros , etc.
Figura 3.3 - As diferentes plataformas Java
A figura 3.3 representa de uma forma gráfica a estrutura das máquinas virtuais de
Java de acordo com o dispositivo a que se destina. Podemos ver que a máquina virtual para
PDA´s e Tv Box´s é mais completa que a máquina virtual para telefones móveis.
1
http://java.sun.com/products/personalprofile/
24
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Os blocos Optional Packages, presentes na figura permitem estender ainda mais a
plataforma Java. Estes pacotes são criados para responder a um mercado especifico, ou seja,
existem pacotes para a utilização de bluetooth, Web services, wireless messaging, multimédia
e acesso a bases de dados.
O esquema da figura 3.4 resume tudo o que foi dito anteriormente:
Figura 3.4 API´s do J2ME
Resumindo, o Java Micro Edition tem duas configurações base: O CLDC e o CDC. O
Mobile Information Device Profile1 (MIDP) baseado na configuração CLCD, foi o primeiro
profile em J2ME a aparecer. As aplicações em J2ME são escritas e desenvolvidas apenas
uma vez para vários tipos de dispositivos móveis, fazendo uso das capacidades nativas com o
mínimo uso de memória e consumo de memória.
Existem já espalhados pelo mundo bastantes dispositivos compatíveis com o MIDP,
como é o caso dos telefones móveis de segunda e terceira geração
3.2 Telemóveis
Efectuámos algumas pesquisas de modo a ter a noção da quantidade de telemóveis
que possuíam a tecnologia Java. A primeiro problema com que nos deparámos foi a
quantidade de marcas e modelos existentes no mercado. Como é óbvio não foi possível
1
http://java.sun.com/products/midp/
Carlos Bandeirinha, Diogo Areia 25
analisar todos os modelos e marcas, apresentamos na tabela 3.1 alguns telemóveis
compatíveis com a tecnologia Java.
Tabela 3.1 Telemóveis compatíveis com Java [4]
Podemos verificar que ao nível do software todos eles possuem a configuração CLDC
(Connected Limited Device Configuration ) e o profile MIDP (Mobile Information Device
Profile ). Estas duas configurações suportam as funcionalidades necessárias à criação de
26
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
aplicações para dispositivos móveis, por exemplo a configuração CLDC possui os pacotes
Java.io, Java.Lang, Java.util e Javax.microedition.io( conexão e interfaces). Não tem suporte
de vírgula flutuante, suporte completo da classe Error do J2SE, verificação de ficheiros de
classes, finalização - Object.finalize() e Java Native Interface (JNI). O profile MIDP define
tudo o que há no CLDC com a adição aos pacotes Javax.microedition.lcdui ( interface com o
utilizador), Javax.microedition.rms (sistema de gestão de registos para persistência de
informação), Javax.microedition.MIDlet (suporte para aplicações MIDP, os chamados
MIDlet ´s). Os programadores que usem esta configuração podem escrever estas aplicações
apenas uma vez e depois distribui-las para uma vasta gama de dispositivos móveis pois o
MIDP foi adoptado como a plataforma base para bastantes fabricantes de telemóveis.
Uma das ferramentas necessárias para se trabalhar com o J2ME é o J2ME wireless
Toolkit. Este Toolkit1 vem com um emulador e vários skins que permite a escolha de qual o
dispositivo (PDA/Telemóvel) a ser emulado, além de acompanhar vários exemplos com
código fonte.
Uma MIDlet é uma aplicação Java desenvolvida para ser executada num dispositivo
móvel, baseado na tecnologia J2ME, que estende a classe MIDlet . A forma como se constrói
uma aplicação é um pouco diferente da estrutura usada em J2SE. A classe MIDlet tem 3
métodos abstractos que são usados pela aplicação. Estes métodos são chamados a partir do
gestor de aplicações do dispositivo. Ele é usado para comunicar com as aplicações que estão
em execução, e é responsável por instalar, executar e, se necessário, eliminar uma aplicação
de um dispositivo móvel. O método startApp é chamado imediatamente depois do construtor
e cada vez que uma aplicação é iniciada.(Figura 3.5)
Figura 3.5 Métodos de uma MIDlet
O método destroyApp é chamado pelo gestor de aplicações para indicar que uma
aplicação está prestes a terminar. Diferente do método startApp, este será chamado uma única
vez durante o tempo de execução de uma aplicação. Como o MIDP não inclui a capacidade de
finalizar objectos, é aconselhado que o programador o faça neste método. O método
pauseApp é utilizado para notificar uma pausa na aplicação que está a ser executada. Isto pode
acontecer quando o utilizador iniciar uma outra aplicação ou utilizar uma função do
dispositivo que inviabilizará a execução do seu aplicação. Pelo facto da maioria dos
dispositivos móveis não serem multitasking (executam várias tarefas ao mesmo tempo), este
método provavelmente será chamado com uma certa frequência.
Alguns dos telemóveis apresentados na tabela 3.1 possuem também a Mobile Media
2
API (MMAPI).A MMAPI, que está actualmente na versão 1.1 é um pacote opcional que dá
suporte a recursos multimédia, tais como a reprodução, edição, e captura de áudio e vídeo a
1
2
http://java.sun.com/products/sjwtoolkit/
http://java.sun.com/products/mmapi/
Carlos Bandeirinha, Diogo Areia 27
partir de diversas origens. A MMAPI já é suportada pela maioria dos dispositivos que
suportam a MIDP. A MMAPI, definida pela JSR1 135, não depende de protocolos ou
formatos de arquivos, o suporte a diferentes formatos é da responsabilidade do fabricante.
Essa flexibilidade permite que seja possível reproduzir qualquer formato de arquivo
especificado pelo fabricante que implementar esta API. A figura 3.6 representa graficamente a
posição que a MMAPI na estrutura de uma aplicação Java para telemóveis.
Figura 3.6 MMAPI
Basicamente
o
processo
de
funcionamento
consiste
em
duas
partes:
• Protocol handling - é responsável pela captura de áudio e vídeo, seja de um arquivo local,
captura
(câmera
ou
microfone)
ou
de
Streaming
(RTSP).
• Content handling - processa os dados recebidos, ou seja, descodifica e renderiza enviando
para os dispositivos de saída como alto-falante e display.
Na arquitectura da MMAPI são utilizados dois tipos de objectos de alto nível:
•DataSource, que recebe a informação multimédia e faz um encapsulamento do
processo de controle do protocolo.
•Player, que controla o conteúdo fornecido por DataSource e, além disso, processa e
envia para o dispositivo de saída adequado, display ou alto-falante.
Vale a pena salientar que o DataSource não deixa visível ao programador o processo
de captura de informação. Além destes objectos, existe o Manager, que cria uma instância do
Player utilizado em diferentes tipos de media, que são especificados pelo DataSource. Após
criado, o Player fornece à interface Control, através do método getControl(), os controles
necessários para manipular o media de áudio ou de vídeo, possibilitando alternar os estados
do ciclo de vida do Player. A figura 3.7 exemplifica o que foi dito anteriormente.
1
http://www.jcp.org/en/jsr/detail?id=135
28
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 3.7 Arquitectura da MMAPI
Para exemplificar aquilo que foi dito anteriormente a seguinte linha comandos
faz tocar um vídeo em qualquer telemóvel(Figura 3.8)
public void run()
{
try
{
String url = "HTTP://server/video-mpeg.mpg";
Player p = Manager.createPlayer(url);
p.realize();
//Obtém o controle do video
VideoControl video = (VideoControl) p.getControl("VideoControl");
//Obtém a GUI
Item videoItem = (Item)video.initDisplayMode(
VideoControl.USE_GUI_PRIMITIVE, null);
// Adiciona a GUI ao form
videoForm.append(videoItem);
//Inicia o video
p.start();
}
catch(Exception e)
{}
}
Figura 3.8 Instruções para a reprodução de vídeo
Após estudarmos a tecnologia Java nos telemóveis concluímos que para o
nosso serviço vamos necessitar de dispositivos que já suportem a MIDP e a MMAPI. Para
implementar a parte gráfica podemos usar a interface gráfica disponível da MIDP ou então
usar o WML1 para apresentar o conteúdo do serviço no browser incluído no telemóvel. O
1
Wireless Markup Language
Carlos Bandeirinha, Diogo Areia 29
problema surge na parte do vídeo pois é necessário fazer o streaming do vídeo da noticia
seleccionada via RTSP (Real Time Streaming Protocol) e nem todos os telemóveis possuem
essa capacidade. Até ao momento, apenas os telemóveis mais recentes, como o Sony
Ericsson Z800/V800/W800/K750/Z520 , alguns Motorola 3G (V 980 e E1000) e os Nokias
Série 60 , 3ª edição. é que suportam streaming na versão 2.0 da MIDP e MMAPI versão 1.1.
A figura 3.9 apresenta o aspecto de alguns desses telemóveis.
Figura 3.9 Telemóveis que suportam streaming via RTSP
Uma solução para resolver o problema da falta de suporte do RTSP é fazer
streaming de vídeo com HTTP, no entanto sempre que o utilizador quiser visualizar o vídeo
da noticia vai ter que esperar que o vídeo seja descarregado para o telemóvel antes de iniciar a
sua visualização. Esta solução não parece ser a mais correcta pois o download do vídeo pode
demorar bastante tempo e a memória do telemóvel pode não ser suficiente para armazenar a
totalidade do vídeo.
3.3 PDA´s
Os PDA´s ( Personal Digital Assistants) são computadores de dimensões reduzidas
(aproximadamente o tamanho A6) dotados de grande capacidade computacional, com funções
de agenda e funcionalidades elementares de um computador normal de escritório. Têm a
possibilidade de interconexão com um computador pessoal e muitos deles já possuem redes
sem fios (WiFi / bluetooth) para acesso a correio electrónico e Internet. Existem duas famílias
principais de PDA´s no mercado de hoje: Os PalmOne e os PocketPC. Os PalmOne utilizam
o sistema operativo Palm OS da PalmSource , este sistema operativo é bastante rápido e
bastante fiável, embora haja poucos fabricantes a produzir esta família de PDA´s estes são
actualmente os mais utilizados no mundo. Os PocketPC utilizam o sistema operativo
Windows Mobile (anteriormente conhecido por Windows CE) da Microsoft, que é compatível
com o Windows e foi adoptado por uma vasta gama de fabricantes. Hoje em dia com o PDA
já é possível navegar na Internet , ver o correio electrónico , ouvir música em MP3 , tirar
fotos, ver vídeos e até servir de controlo remoto para os aparelhos domésticos.
30
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Para testarmos o serviço usámos um PDA Ipaq H3870 da Compaq (Figura 3.10). Este
PDA possui o processador “intel ARM S110” ,32 Mb RAM ,64 Mb ROM e o sistema
operativo Windows Mobile 2003. Possui bluetooth integrado, o ecrã tem uma resolução de
240 x 320 pixel e 16 bits, microfone, altifalante, entrada para auscultadores, porta de
infravermelhos, slot para SD card e um módulo de expansão. Este módulo de expansão pode
ser usado para integrar uma placa de rede wireless. Este placa de rede foi usada para conectar
o PDA á rede do L2F e do IST.
Figura 3.10- Ipaq H3870
3.4 Java nos PDA´s
Há 3 maneiras de desenvolver aplicações para os PDA´s , conhecidos também como
PocketPc, com Java: usando a MIDP, o Personal Java1 da Sun MicroSystems e usando
máquinas virtuais de Java desenvolvidas por companhias privadas.
É possível executar MIDlet s em PocketPc´s com uma máquina virtual de Java
previamente instalada. O IBM WebShpere Studio Device Developer2 é um software que
integra todas as ferramentas necessárias para desenvolver aplicações em J2ME para múltiplas
plataformas, e que traz a máquina virtual de Java (IBM-J9-MIDP) para instalar nos PocketPc
e assim executar as MIDlet s. Este software traz também uma outra máquina virtual de Java
(IBM-J9-PP) que possibilita execução de programas escritos em Java mas desta vez usa o
Personal Profile em vez da MIDP. A API do personal profile é mais completa do que a
MIDP. O preço para distribuir esta máquina virtual é de cerca de 6 dólares por unidade, mas
se o objectivo do programador for apenas desenvolver uma aplicação em Java a máquina é
grátis. Saliente-se o facto de haver uma grande comunidade a suportar esta maquina, bem
como uma grande quantidade de documentação técnica.
O Personal Java pode ser considerado como um sub-domínio do Java SE , o que
obriga a que se desenvolvam as aplicações com o JDK 1.1.8. O Personal Java tem API´s
melhores , nomeadamente ao nível da interface gráfica, do que a MIDP. Infelizmente este
projecto está ultrapassado (Sun´s End of Life) o que significa que vai deixar de ser suportado
pela Sun. Este projecto no entanto é grátis.
1
2
http://java.sun.com/products/personaljava/
http://www.ibm.com/software/wireless/wsdd/
Carlos Bandeirinha, Diogo Areia 31
Existe também máquinas virtuais de Java desenvolvidas por empresas privadas. O
cReme da NSICom1 é uma máquina virtual que implementa a configuração CDC, possui
plugins de Java que possibilita a visualização de applets no pocket Internet Explorer, é
compatível com o JDK 1.3.1. Esta máquina virtual custa cerca de 1000 doláres por cada 40
unidades compradas, no entanto é possível testá-la pois tem um trial period de um mês.
O Jeode é outra máquina virtual de Java compatível com o JDK 1.1.8. Este produto
chegou a ser grátis e era incluído no CD de suporte dos Ipaq´s. Recentemente a companhia
que produzia o Jeode foi comprada pela Esmertec2 e o nome da máquina mudou para JBED.
Actualmente este produto não é vendido directamente ao publico mas apenas a empresas.
O Mysaifu3 é uma máquina virtual compatível com o J2SE , o que permite execução
de aplicações desenvolvidas com a ultima versão do Java (actualmente a versão 5.0). Este
projecto é relativamente recente, tem cerca de um ano, a primeira versão foi lançada no dia 16
Abril de 2005. É um projecto que é grátis ( licença GNU/GPL) no entanto ainda há alguma
falta de documentação e não existe uma grande comunidade de suporte. Algumas classes
ainda não estão implementadas mas praticamente todos os meses é lançada uma nova versão
da máquina virtual com melhoramentos.
3.5 Conclusão/Tomada de decisão
Concluímos que os telemóveis e PDA´s hoje em dia apresentam mais soluções ao
nível das capacidades de processamento e ao nível do software. No entanto devido ao elevado
número de fabricantes , principalmente de telemóveis, é necessário desenvolver aplicações
que sejam compatíveis com todos estes dispositivos. A solução naturalmente, está no Java ,
mais propriamente no J2ME. Em relação aos telemóveis notámos que todos eles possuem as
API´s mais elementares para a execução de pequenos programas , mas ao nível de gestão de
conteúdo multimédia ainda existem algumas discrepâncias , principalmente ao nível do
streaming de conteúdo multimédia e sua reprodução. Apenas alguns modelos de telemóveis
mais recentes é que suportam o protocolo RTSP, algumas pesquisas pela Internet revelaram
que houve alguns investigadores que solucionaram este problema implementando eles
próprios o seu protocolo, que consistia basicamente em construir pequenos pacotes do vídeo e
enviá-los para a rede de forma a que MIDlet (aplicação Java no telemóvel) possa interpretálos e tocar o vídeo. No entanto como este problema sai fora do âmbito deste projecto optámos
por não ir mais fundo nesta questão. Outro problema que existe é o formato do vídeo. Vimos
que a MMAPI usa o player nativo do telemóvel e como tal a MMAPI é condicionada nos
formatos compatíveis de vídeo. Assim nem todos os telemóveis com tecnologia Java
suportam o mesmo tipo de formato de vídeo: Por exemplo o Motorola E1000 pode suportar o
formato 3GPP mas o SonyEricsson Z800 já não. Por outro lado o SonyEricsson pode suportar
o formato RM (RealMedia) e o Motorola não. A acrescentar a isto tivemos bastantes
dificuldades em encontrar um ambiente de testes, ou seja , para testar o desempenho dos
telemóveis iríamos obviamente necessitar de uma rede GSM ou UMTS bem como de
telemóveis desta gama. Adicionalmente ainda teríamos que usar os SDK´s destes telemóveis
que são completamente diferentes de marca para marca.
Depois de reflectir um pouco com o professor João Paulo Neto decidimos não
implementar o serviço nos telemóveis, mas ficando com a sensação que já dispomos de toda a
tecnologia e conhecimento necessários para o fazer.
1
http://www.nscicom.com
HTTP://www.esmertec.com
3
http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html
2
32
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Nos PDA´s a análise que foi feita acerca das máquinas virtuais para Java revela que as
soluções existentes no mercado são bastante heterogéneas entre si e são quase todas pagas,
exceptuando o Mysaifu e o Personal Java, o que pode ser um entrave a este tipo de
tecnologia. Existem alguns rumores1 que a Sun já desenvolveu uma máquina virtual Java para
o PocketPc chamada Captain America e que não a distribui porque não existe mercado
suficiente que justifique o seu lançamento e suporte.
Após alguma reflexão decidimos realizar testes nas máquinas virtuais Jeode , cReme,
Mysaifu e IBM-J9 de forma a decidir qual a máquina a ser usada. Excluímos o Personal Java
da SUN por estar em fim de vida.
A aplicação a ser desenvolvida tem obrigatoriamente que ter uma interface gráfica
amigável, com caixas de texto, botões e labels . É necessário ainda que haja captura de áudio
para o reconhecimento de fala e é necessário também adicionar vídeo no caso do utilizador
desejar ver vídeo da noticia.
Os testes efectuados no Jeode revelaram que esta é
uma máquina bastante completa, estável e com bom suporte ao
nível de documentação. Conseguimos executar o JMF (Java
Media FrameWork) que é uma API que possibilita que se
adicione áudio e vídeo a aplicações Java , este assunto será
abordado no capitulo seguinte. Ao nível gráfico o Jeode
suporta o AWT (Abstract Window ToolKit) mas não suporta o
Swing que é uma API gráfica mais completa mas também mais
exigente ao nível de processamento. O Jeode não possui
nenhuma API destinada á captura de áudio e também não
suporta o JNI (Java Native Interface) que possibilitaria a
eventual implementação da captura de áudio de forma nativa.
A figura 3.11 mostra a consola do Jeode .
Figura 3.11 –Consola do Jeode
O cReme é uma máquina bastante rápida ao nível de
processamento, com bom suporte técnico, e faz a gestão da
memória melhor que o Jeode . Suporta o AWT e tem uma
interface bastante amigável para execução das nossas
aplicações. Nesta máquina não foi possível executar o JMF ,
não suporta a captura de áudio mas suporta o JNI. Só
dispusemos de um mês para testar esta máquina pois no final
deste tempo chegámos ao fim do trial period. A figura 3.12
mostra o aspecto da consola do cReme.
Figura 3.12 Consola do creme
1
Informação obtida em fóruns , para mais informação ,
http://forum.java.sun.com/thread.jspa?threadID=408223&start=75
Carlos Bandeirinha, Diogo Areia 33
O IBM-J9 é também uma máquina bastante rápida que
vem juntamente com um software próprio para desenvolvimento
de aplicações em J2ME (WebShpere Studio Device Developer ).
Não foi possível executar o JMF nesta máquina, suporta o AWT
e também o SWT (Standard Widget Toolkit), não suporta a
captura de áudio e suporta o JNI. (Figura 3.13)
Figura 3.13- Consola do J9
O Mysaifu mesmo não sendo uma máquina muito estável
revelou estar sempre em constante actualização e os responsáveis
pelo projecto revelaram serem bastante receptivos aos bugs e à
falta de funcionalidades da máquina. Os mails que enviámos a
pedir que fossem implementadas certas funcionalidades foram
sempre correspondidos com o lançamento de novas versões da
maquina virtual. Quando começámos a desenvolver este projecto
a máquina virtual não fazia a captura de áudio e agora já existe
uma versão que faz essa mesma captura. Com esta máquina não
foi possível executar o JMF, suporta o AWT e o Swing (bastante
instável) e suporta JNI.(Figura 3.14)
Figura 3.14 Consola do Mysaifu
Decidimos então integrar o serviço na máquina virtual Mysaifu sobretudo por ser um
projecto grátis e por estar em constante actualização. No entanto, durante a realização deste
projecto fomos sempre testando o comportamento das outras máquinas na aplicação
desenvolvida.
34
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
4 Cap4 – A aplicação no PDA
Para saber desenhar e implementar boas interfaces, o primeiro passo consiste em
aprender uma linguagem de construção de interfaces gráficas. Para isso é importante
seleccionar os componentes gráficos apropriados para a interface gráfica do utilizador,
Graphical User Interface, (GUI). No nosso projecto abordámos duas hipóteses diferentes de
conjuntos de componentes, sendo elas o AWT e o Swing . Ambos os conjuntos de
componentes fazem parte das classes fundadoras de Java, Java Foudation Classes1 (JFC). As
JFC são um conjunto de bibliotecas de classes fornecidas como parte do Java 2 Platform,
Standard Edition (J2SE) por forma a suportar as GUI e as funcionalidades gráficas para as
aplicações dos utilizadores, que podem correr em plataformas populares como o Microsoft
Windows, Linus e Mac OSX.
4.1 Visão Geral do AWT (Abstract Window Toolkit)
O AWT é o toolkit original criado para realizar interfaces gráficas em Java,
estabelecendo uma ligação entre a aplicação do utilizador e a GUI nativa, isto é permite ao
utilizador realizar a sua aplicação num nível superior de abstracção em que não precisa de se
preocupar com os pormenores que estão por trás da GUI em que o programa irá correr.
Muitas vezes é designado como “o menor denominador comum de todas as plataformas”.
Disponibiliza muitos componentes padrão à GUI tais como botões, listas, menus, áreas
de texto, etc. Inclui também recipientes (tais como janelas e barras de menu) e componentes
de níveis superiores (tais como uma caixa de diálogo para gravar ou abrir ficheiros). Existem
ainda classes que permitem trabalhar em contextos gráficos, incluindo operações básicas de
desenho, imagens, letras e cores. Um outro grupo importante de classes do AWT são os
layout managers, que controlam o tamanho e a posição dos componentes, mantendo-os
sempre ordenados. Por fim temos que tornar a aplicação interactiva, ou seja, é preciso criar
rotinas que lidem com os eventos que ocorrem quando o utilizador realiza uma acção. Tudo o
que o utilizador faz ao nível da aplicação é representado pela classe abstracta AWTEvent. Os
componentes geram subclasses AWTEvent, sempre que algo ocorre. Essas subclasses são
designadas Listeners, que por sua vez realizam o processamento dos eventos. A cada evento
corresponde um determinado grupo de Listeners que por sua vez tem um determinado número
de métodos associados ao tipo de acções que queremos detectar.
Desta forma é possível ter controlo da aplicação e de cada um dos componentes, como
por exemplo, saber se um botão foi pressionado, ou se a caneta do PDA entrou numa
determinada área e desta forma desencadear as acções que queremos realizar.
De seguida podemos ver a listagem detalhada dos diferentes componentes existentes
no AWT(fig. 4.1), assim como a listagem dos layoutmanagers (fig. 4.2) e dos eventos (fig.
4.3) e as suas subclasses.
1
http://java.sun.com/products/jfc/index.jsp
Carlos Bandeirinha, Diogo Areia 35
Figura 4.1-Componentes do AWT
Figura 4.2 Layouts do AWT
36
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 4.3 Eventos do AWT
As principais vantagens de AWT são que este vem em modo padrão com cada versão
de Java. Isto significa que não é necessário a sua instalação, pois está disponível em qualquer
ambiente runtime de Java, e terá sempre as características esperadas. O AWT é também muito
simples e estável uma vez que por opção da Sun Mycrosystems são usados somente
componentes válidos para todos os ambientes Java.
Em consequência, e infelizmente, alguns componentes geralmente usados, tais como
tabelas, árvores, barras de progresso, e outras, não são suportados. Para as aplicações que
necessitam este tipo de componentes é necessário criá-los, que acaba por ser uma solução
bastante complicada. A fim de resolver as limitações e os problemas a nível de desempenho
do AWT, a Sun Microsystems criou uma estrutura nova que usasse componentes emulados em
vez dos componentes nativos, o Swing .
4.2 Visão Geral do Swing
O Swing implementa um conjunto de componentes GUI baseados na tecnologia do
AWT por forma a tentar resolver a maioria das falhas e problemas encontrados. Os objectos
do Swing são escritos em Java puro e apresentam o mesmo look and feel em todas as
plataformas. No entanto, podem ser adaptados pelo programador para estilos particulares.
Com o Swing , a Sun Mycrosystems criou um toolkit muito bem projectado, flexível e
poderoso, tornando-o mais robusto mas ao mesmo tempo mais complexo e complicado de
aprender, o que por vezes não é necessário para situações mais comuns e simples.
O Swing
não só disponibiliza muitos componentes novos como apresenta
componentes já existentes no AWT mas com melhor funcionalidade. No Swing temos
também disponíveis alguns “extras” para facilitar e melhorar a interacção do utilizador com a
Carlos Bandeirinha, Diogo Areia 37
aplicação, assim como os tooltips (pequenas instruções para o uso de cada componente), ou a
possibilidade de colocar Icons em alguns componentes.
Os componentes do Swing (fig 4.4), os layout managers (fig 4.5) e os eventos (fig
4.6) são sumarizados nas listas seguintes.
Figura 4.4 Componentes do Swing
38
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 4.5 Layouts do Swing
Figura 4.6 Eventos do Swing
Como se pode ver, estes conjuntos são mais extensos do que aqueles fornecidos pelo
AWT. Temos disponível alguns componentes que poderiam ser interessantes para a aplicação,
mas os essenciais estão também presentes no AWT.
Inicialmente o AWT e o Swing não funcionavam bem nas máquinas virtuais testadas,
incluindo o Mysaifu , pelo que tentámos ainda uma terceira hipótese, o SWT.
O SWT é uma plataforma cruzada criada para a realização de GUI’s desenvolvida pela
IBM. A IBM criou um conjunto de componentes na tentativa de resolver os problemas vistos
no AWT e nas estruturas do Swing . A estrutura do SWT alcança componentes nativos com
JNI (Java Native Interface). Se um componente não estiver disponível na plataforma do
utilizador, o SWT emula-o. Com o aparecimento de novas versões do Mysaifu , o AWT
começou a revelar-se o toolkit que tinha melhores desempenhos, pelo que a nossa escolha
acabou por ser mesmo esta.
O AWT revela-se suficiente em termos de componentes para a nossa GUI e é bastante
mais simples que as outras duas hipóteses. Apesar de algumas máquinas virtuais funcionarem
com o Swing e SWT verificámos que a maioria das aplicações, mesmo as mais simples,
acabavam por ter falhas. Além disso, as aplicações do Swing consomem demasiada memória,
o que não é apropriado para dispositivos pequenos tais como PDAs e telemóveis.
De futuro achamos que esta aplicação pode ter melhorias significativas uma vez que
estão sempre a sair mais e melhores máquinas virtuais para os PDA’s que irão permitir a
introdução de alguns componentes interessantes do Swing .
É de notar que a aplicação foi toda construída por forma a permitir uma navegação
através da fala. Para além disso é capaz de detectar o botão de gravar dos PDA’s tornando a
navegação ainda mais simples.
Carlos Bandeirinha, Diogo Areia 39
4.3 O desenvolvimento da interface gráfica no PDA
Depois de termos analisado as diferentes opções (AWT, Swing , SWT) para construir
a interface gráfica em Java no PDA decidimos implementar a parte gráfica em AWT. Uma
das razões porque escolhemos o AWT foi porque esta API está presente em todas as
máquinas virtuais testadas, é mais simples de trabalhar e embora tenha menos componentes
gráficos estes são suficientes para a nossa aplicação. Outra razão tem a ver com o facto de o
desempenho do AWT no PDA ser muito melhor do que o desempenho do Swing no PDA
pois o Swing consome mais memória.
O primeiro problema com que nos deparámos foi o facto da aparência duma aplicação
em AWT ter aspectos distintos de máquina virtual para máquina virtual, ou seja, o mesmo
código executado no Jeode tinha um aspecto diferente do J9 e um aspecto diferente do
Mysaifu . Vejamos o caso do painel principal da nossa aplicação nas diferentes máquinas
virtuais (Figura 4.7)
Figura 4.7- Painel principal da aplicação nas diferentes máquinas virtuais
Embora á primeira vista o aspecto seja o mesmo para todas as máquinas virtuais isso
não é verdade, senão vejamos o tipo e o tamanho das letras. Podemos verificar que o tamanho
das letras diferem de máquina para máquina, no caso do Mysaifu existe algum texto que sai
fora dos limites do visor do PDA. No caso do J9 da IBM as letras eram demasiado pequenas ,
enquanto que nas restantes máquinas este problema já não existia. Podemos ver que as
máquinas são heterogéneas entre si e portanto é praticamente impossível estar a desenvolver
uma aplicação gráfica para todas as máquinas pois ao optimizar o código para uma dada
máquina estávamos a estragar a disposição gráfica noutras máquinas. Tivemos então que
tomar uma decisão. Novamente escolhemos o Mysaifu como plataforma preferencial. Embora
o problema das letras continuasse a existir entrámos em contacto com o responsáveis do
Mysaifu e semanas mais tarde saiu uma versão melhorada a nível gráfico e já com os tipos e
tamanhos de letra correctos. Vejamos as diferenças da fig.4.8:
40
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 4.8 Diferença entre as versões do Mysaifu
Com esta nova versão do Mysaifu , podemos ver que o tamanho e o tipo de letras
foram corrigidos. Estávamos então em condições de avançar na implementação gráfica do
serviço no PDA.
Um dos principais condicionantes na disposição gráfica dos menus, caixas de texto ,
botões , labels , etc , era a questão da navegação por fala. Dado que esta interface gráfica
poderia ter a funcionalidade de navegação por fala foi necessário desenvolver esta mesma
aplicação de forma a que possa ser totalmente controlada por fala. Neste contexto criámos
duas possibilidade: o utilizador usa a caneta para carregar no botão de reconhecimento de fala
da aplicação ou então o utilizador pressiona num botão predefinido do PDA para iniciar o
processo de reconhecimento, vejamos as figuras 4.9 e 4.10 .
Figura 4.9 Activação do reconhecimento de fala na aplicação
Figura 4.10 Activação do reconhecimento de fala no PDA
Carlos Bandeirinha, Diogo Areia 41
Sempre que é accionado o processo de reconhecimento (passo 1) a aplicação liga-se ao
reconhecedor de fala onde são carregadas as gramáticas (passo 2) e finalmente começa a
captura de áudio e respectivo reconhecimento (passo 3). No passo 2 é necessário aguardar
algum tempo para que as gramáticas sejam carregadas para a memória do reconhecedor. A
vantagem de usar o botão presente na estrutura do PDA é o facto de não se usar a caneta para
navegar nos conteúdos e portanto facilitar bastante o uso desta aplicação, libertando o
utilizador do enfadonho processo de usar o teclado virtual do PDA. Este processo foi
implementado usando os listeners do AWT, mais propriamente o keylistener. Assim é
possível saber qual foi a tecla pressionada e executar as operações inerentes a este evento.
O AWT revela-se suficiente em termos de componentes para a nossa GUI e é bastante
mais simples que o Swing . No entanto o Swing é uma API que apresenta muitas mais
soluções para a construção da GUI, por exemplo, permite que o texto apresentado esteja
escrito em HTML ,permitindo que o texto tenha diferentes estilos e cor. Com o Swing é
possível adicionar num scroll pane vários componentes como texto , áudio e imagens, é
possível criar caixas de diálogo , labels com imagens, separadores, tooltips , barras de
progresso , Jtrees , etc. Apesar do Mysaifu ser compatível com o Swing verificámos que a
maioria das aplicações , mesmo as mais simples, acabavam por ter falhas e aquelas que
funcionavam eram demasiado lentas. Além disso as aplicações em Swing consomem
demasiada memória o que não é apropriado para dispositivos móveis , como PDA´S e
telemóveis. Vejamos a figura 4.11
Figura 4.11 Aplicação em Swing no PC e no PDA
Como foi dito, algumas aplicações em Swing não funcionam no PDA , de futuro com
o lançamento de novas versões da máquina virtual Mysaifu estes problemas poderão ser
resolvidos. Na figura acima a aplicação Converter funciona no PC mas no PDA tem
problemas a nível de memória (JVM Heap error).
Figura 4.12 Aplicação em Swing no PC e PDA
42
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
No exemplo da figura 4.12, a aplicação ListDemo funcionava no PDA mas a
performance era muito lenta.
Concluindo, o AWT revelou ser a melhor solução para desenvolvermos a GUI, a
máquina Virtual Mysaifu foi a plataforma alvo escolhida por estar em constante
desenvolvimento e ser grátis. O Swing revelou ser uma API muito completa , mas é bastante
instável no PDA, apresenta mais soluções a nível gráfico ,o que pode tornar a aplicação mais
agradável e mais funcional , no entanto o AWT possui os componentes básicos para a
construção da GUI. O modo como foi projectada a GUI teve em conta o facto de esta poder
ser controlada por fala.
4.4 O Vídeo no PDA
As máquinas virtuais testadas não possuem API´s para a visualização de vídeo. Foi
preciso recorrer a API´s externas como o Java Media Framework (JMF) e a aplicações
externas como o RealPlayer for PocketPc1. Estas aplicações suportam o protocolo RTSP. Este
protocolo é direccionado especialmente para o streaming de áudio e vídeo pois funciona em
cima do protocolo UDP2 , ao contrário do HTTP que funciona em cima do TCP3. Não se
garante a entrega de todos os pacotes, mas consegue-se receber um fluxo de pacotes contínuo,
assegurando-se assim que o utilizador visualize um vídeo sem interrupções e fluído. A
vantagem entre o protocolo RTSP e o protocolo RTP ( Real Time Protocol) é que no RTSP
temos uma ligação bidireccional, podendo o utilizador dar alguns comandos ao servidor, tais
como retroceder o filme, mudar de capitulo, etc.
4.4.1 Java Media Framework
O Java Media Framework4 é um pacote opcional do Java 2 Standard Edition que
adiciona a funcionalidade de mostrar vídeo e áudio em aplicações Java e applets. Com o JMF
é possível controlar a aquisição e o processamento de informação multimédia em tempo real
ou em modo offline. Este pacote permite que as aplicações em Java desempenhem novas
funções como :
• Playback de conteúdo multimédia
• Captura de áudio através de microfone e através de uma câmara
• Fazer streaming de media para a Internet
• Fazer conversão e manipulação de formatos multimédia
• Guardar conteúdo multimédia num ficheiro
O JMF suporta os vários formatos multimédia mais comuns como o JPEG, MPEG-1, MPEG2, QuickTime, AVI, WAV, MP3, GSM, G723, H263 e MIDI. Suporta também os protocolos
mais populares como o HTTP, HTTPS, FTP, RTP e RTSP. Assim, com o JMF é possível
enviar e receber streams de conteúdo multimédia o que nos interessa bastante. Existe também
a possibilidade de adicionar o suporte de formatos multimédia adicionais através de uma
ferramenta de configuração existente neste pacote.
1
http://www.realnetworks.com/industries/serviceproviders/mobile/products/player/ppc/install.html
User Datagram Protocol
3
Transmission Control Protocol
4
http://java.sun.com/products/java-media/jmf/
2
Carlos Bandeirinha, Diogo Areia 43
Existem 4 versões disponíveis para o JMF: a versão
optimizada para Windows, a versão para o Linux , para o Solaris
Sparc e finalmente existe uma versão cross platform que permite
que se use o JMF em qualquer máquina que disponha de uma
plataforma Java. Naturalmente, foi esta a versão escolhida para
realizar os nossos testes. O JMF vem acompanhado com uma
interface gráfica , o JMStudio (Fig 4.13), que permite aceder a todas
as funcionalidades do JMF de forma fácil e simples.
Figura 4.13 JMStudio
4.4.2 RealPlayer para PocketPC
O RealPlayer para o PocketPc (fig. 4.14) é uma aplicação grátis para o PDA que
permite aos utilizadores aceder a conteúdo multimédia através de redes WiFi ou através de
redes móveis celulares. O RealPlayer permite o playback de ficheiros em formato RealAudio,
RealVideo e 3GPP via streaming ou download . Permite ainda a sincronização com o
RealPlayer instalado num PC.
Esta aplicação está disponível para vários sistemas operativos entre os quais o
Symbian OS, Palm OS e PocketPC. Está disponível também para alguns telemóveis como o
Nokia 9200 Communicator e os Nokias série 60 (7650 e 3650).
Figura 4.14 RealPlayer para Pocket Pc
•
•
•
•
Para instalar o RealPlayer em qualquer PocketPc os requisitos mínimos são:
Processador intel StrongARM ou XScale (200 MHz ou superior)
32 MB ROM
32 MB RAM
Ecrã 240 x 320 pixel
4.4.3 Desempenho do JMF vs RealPlayer
Como foi referido no capitulo anterior a única máquina virtual Java onde se conseguiu
executar o JMF foi no Jeode . Mesmo assim foi necessário fazer algumas modificações na
API do JMF de modo a conseguirmos executar o JMF.
44
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
O desempenho do JMF deixou bastante a desejar, pois revelou ser muito lento e pouco
fluido na visualização do vídeo. Testámos também o desempenho do JMF num PDA mais
recente (Qtek S110 ,Processador intel PXA272 417Mhz, 128 MB RAM) mas os resultados
acabaram por ser os mesmos. Tentámos ainda codificar o vídeo com diferentes codecs e
formatos de vídeo , a tabela 4.1 mostra os codecs e os formatos suportados pelo JMF e a
tabela 4.2 mostra os requisitos em termos de largura de banda e CPU de alguns codecs
testados.
Tabela 4.1 Formatos e codecs suportados pelo JMF
Formato
JMF 2.1.1
Cross Platform Version
AVI(.avi)
Read/Write
Audio: A-law
D
Audio:DVI ADPCM
D/E
compressed
Video:Cinepak
D
QuickTime (.mov)
read/write
Audio: A-law
D
Audio: IMA4 ADPCM
D,E
Video:Cinepak
D
Video: H.261
-
Video: H.263
D
Legenda:
read- significa que o tipo de média pode ser usado como input (ler de um ficheiro)
write- significa que este tipo de média pode ser gravado em ficheiro
D- significa que o codec pode ser descodificado e reproduzido
E- significa que o codec pode ser codificado numa stream .
Carlos Bandeirinha, Diogo Areia 45
tabela 4.2 Requisitos de CPU e largura de banda dos codecs
Codec
Format
Quality
CPU
Bandwidth
Requirements Requirements
Cinepak
AVI
Medium
QuickTime
Low
High
H.263
QuickTime
AVI
Medium
RTP
Medium
Low
PCM
AVI
QuickTime
WAV
Low
High
High
Mesmo codificando o vídeo com o codec que requer menos utilização do CPU , o
Cinepak, ver tabela 4.2 o desempenho do JMF no PocketPc ficava muito aquém das
expectativas. O vídeo ficava bastante pixelizado e com pouca fluidez (fig. 4.15).
Figura 4.15- vídeo codificado com o cinepak
A própria máquina virtual onde é executado o JMF já está obsoleta e o JMF não está
optimizado para o PocketPC, pois é a versão Cross Platform e assim os recursos nativos do
PDA não são utilizados como acontece com o RealPlayer. Nesta versão também não é
possível a captura de áudio e vídeo.
46
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
A vantagem de trabalhar com esta API é ter o controlo completo do streaming de
vídeo, ou seja , o JMF pode ser configurado para funcionar como servidor de streaming de
vídeo via RTP (Real Time Protocol) e também pode ser usado como cliente de uma sessão
RTP e receber o stream vídeo.
O desempenho do RealPlayer foi muito melhor do que o do JMF , conseguimos
receber uma transmissão de vídeo de uma forma fluida , com boa qualidade e sem
interrupções, tivemos apenas de codificar o vídeo a enviar para o formato RealMedia (.rm) e
usar o Helix Streaming Server como servidor do vídeo via RTSP. Actualmente os codecs
suportados por este Player são o realvideo 8 e realvideo 9 , ao contrário da versão para PC
que já suporta o realvideo 10. Codificámos os vídeos do telejornal de forma a serem
compatíveis com a capacidade de processamento do PDA. Esta versão do RealPlayer não
suporta SMIL1 , tentámos entrar em contacto com a RealNetworks2 para saber para quando
está previsto o lançamento duma versão que suporte o SMIL mas não obtivemos resposta.
Nesta fase do projecto deparámo-nos com 3 hipóteses para implementar o serviço no
PDA: 1-Utilizar a aplicação desenvolvida em Java conjuntamente com o JMF para visualizar
o vídeo; 2- Utilizar a aplicação desenvolvida em JAVA conjuntamente com o RealPlayer para
a visualização do vídeo; 3-Utilizar um browser (Internet Explorer for pocket pc) para
introduzir a pesquisa e navegar nos conteúdos disponibilizados pelo servidor conjuntamente
com o RealPlayer para visualizar o vídeo. Perante estas 3 possibilidades apresenta-se de
seguida os prós e contras de cada uma dessas opções.
4.5 Browser + RealPlayer
A vantagem de usar esta opção é o facto de ser relativamente fácil criar uma página
Web em HTML para navegar no serviço. Esta técnica já foi implementada para testar o
servidor , como foi referido no capítulo 2. É também trivial usar-se o RealPlayer para
visualizar o vídeo, bastando para tal criar uma hiperligação com o MIME Type
correspondente (application / real vídeo).
A desvantagem desta solução é o facto de não podermos capturar voz e assim estamos
impossibilitados de criar um serviço multimodal. Existe no entanto, um novo tipo de browser
(XHTML+Voice) que permitem a interacção com o utilizador de uma forma multimodal ,
fazendo o reconhecimento de fala . Este assunto será abordado no capitulo 6.
Esta opção não foi levada em conta por não se adequar ao tipo de aplicação pretendida
no dispositivo móvel,
4.6 Java + JMF
A vantagem de usar esta solução é o facto de termos o controlo total da aplicação no
pocket PC. Tanto a visualização do vídeo como a GUI são inteiramente escritas em Java e
portanto , completamente portáveis para vários sistemas operativos que tenham uma máquina
virtual de Java. Com esta solução é ainda possível fazer a captura de áudio permitindo que se
construa um serviço multimodal.
A desvantagem desta solução é o desempenho do JMF ser medíocre, o vídeo é pouco
fluido e com baixa qualidade, ainda por mais apenas funcionou numa máquina virtual, que foi
1
2
Synchronized Multimedia Integration Language (http://www.w3.org/TR/REC-smil/)
http://www.realnetworks.com/
Carlos Bandeirinha, Diogo Areia 47
o Jeode . Futuramente, se o desempenho do JMF for melhor nos PDA´s esta será a melhor
opção mas como o desempenho do vídeo é mau esta opção não foi considerada.
4.7 Java + RealPlayer
A vantagem de usar esta solução é o facto da visualização do vídeo ser bastante boa.
Outra vantagem é poder aproveitar-se alguns módulos do projecto SSNT , como é o caso do
servidor de streaming , o Helix Streaming Server e também aproveitámos o facto da
codificação do vídeo das noticias no projecto SSNT ser em RealVideo. Com esta solução é
também possível construir um sistema multimodal com o Java.
A desvantagem é dependermos de uma aplicação externa para fazer o tratamento do
vídeo. A partir da aplicação em Java é necessário lançar o RealPlayer. Existe em Java uma
classe chamada Runtime com os métodos getRuntime () e exec () que permite que sejam
executadas aplicações externas com apenas algumas linha de código (fig. 4.16):
Figura 4.16- Runtime.exec()
Estas instruções lançam o RealPlayer para fazer o streaming e playback do ficheiro
Telejornal.rm que está na máquina local. Na implementação desta classe tivemos bastantes
problemas pois nas máquinas virtuais que testámos só o Mysaifu possuía esta classe, e
mesmo assim esta classe não funcionava como era devido. Para solucionar este problema ,
implementou-se esta classe de forma nativa e integrou-se com o Java através do JNI (Java
Native Interface).Só depois de entrarmos em contacto com os responsáveis desta máquina é
que o problema foi solucionado com o lançamento de uma nova versão do Mysaifu .
Esta foi a solução adoptada para o projecto por nos parecer aquela a que conduz a uma
melhor qualidade de serviço. A figura 4.17 mostra de uma forma simplificada o que foi atrás
descrito.
48
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 4.17 Solução Java +RealPlayer
Na aplicação desenvolvida inteiramente em Java existe a possibilidade de efectuar 3
tipos de pesquisas. O resultado dessa pesquisa é mostrada ao utilizador e se este pretender
visualizar o conteúdo da notícia é lançada uma aplicação externa, o RealPlayer que permite
que seja visualizado o vídeo no dispositivo. Do lado do servidor foi necessário incluir o Helix
streaming server para fazer a distribuição do vídeo.
4.8
Helix Streaming Server
Uma vez que a maior parte dos vídeos exigem recursos muito significativos do ponto
de vista de capacidade de armazenamento no PDA é necessário que as suas reproduções
ocorram de forma imediata, sem necessidade de aguardar a transferência completa do arquivo.
Esta é uma potencialidade associada à técnica de media streaming.
Para o servidor de vídeo optar-se-á pelo Helix Universal Server1, que suporta os três
principais formatos de streaming: Windows Media, QuickTime, Real vídeo, MPEG-1, MPEG2, MP3 e MPEG-4.O Helix Streaming Server é um servidor de media , multiformato,
compatível com vários tipos de sistemas operativos. Suporta os formatos RealAudio,
RealVideo, Windows Media , QuickTime, entre outros. O streaming é efectuado usando o
protocolo RTSP.
4.9 Integração com o projecto SSNT-Service
No projecto SSNT a emissão televisiva do telejornal é gravada para um ficheiro de
vídeo em formato AVI. Posteriormente é feita uma conversão de formatos (Avi para
Realvídeo) para se integrar o vídeo com o Helix Streaming Server e para se construir um
ficheiro SMIL (Synchronized Multimedia Integration Language) o que possibilita a inclusão
de legendas na altura da visualização do vídeo. No âmbito desse projecto se o utilizador
1
https://helix-server.helixcommunity.org/
Carlos Bandeirinha, Diogo Areia 49
desejar ver o vídeo necessita de ter instalado no seu PC o RealPlayer para PC. O vídeo
codificado para este tipo de audiência tem um bit rate de 450kbps , 25 imagens por segundo e
a dimensão da imagem é de 284 x 288 pixel, o codec utilizado é o RealVídeo 9. No projecto
SSNT existe apenas um único ficheiro de vídeo com todas as noticias do telejornal sendo
depois gerados vários ficheiros SMIL de acordo com o número de noticias contida nesse
telejornal.
Os testes que efectuamos revelaram que o RealPlayer para o PocketPc não possui
suporte para SMIL. Tal facto obrigou-nos a gerar um ficheiro de vídeo distinto para cada
noticia em cada telejornal gravado. Ao invés, no projecto SSNT existe apenas um ficheiro de
vídeo por cada telejornal gravado e vários ficheiros SMIL. Outro factor a ter em conta é o
facto de não se poder adicionar legendas na visualização do vídeo no PDA. Também foi
necessário modificar as características da codificação do vídeo pois naturalmente a
capacidade de processamento do PDA não é igual à de um PC. Criámos então uma audiência
especifica para o PDA com um bit rate de 50 Kbps , tamanho da imagem de 224 x 168 e o
codec utilizado foi o RealVideo 8 (não suporta versões posteriores).
Na fase final ainda tentámos encontrar SMIL players para o PocketPC, mas as
soluções que encontrámos na Internet revelaram ser bastante instáveis e sem possibilidades de
realizar streaming. A figura 4.18 mostra o que foi dito anteriormente.
Figura 4.18 Integração com o projecto SSNT
4.10
Descrição do trabalho realizado
Nesta fase do projecto abordou-se a implementação gráfica da aplicação no PDA ,
investigámos as vantagens e desvantagens dos toolkits disponíveis em Java , o AWT e Swing.
O toolkit escolhido foi o AWT como se refere nas secções 4.2 e 4.3. Tivemos alguns
50
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
problemas na portagem desta interface para as diferentes máquinas virtuais, uma vez que o
aspecto gráfico variou de máquina para máquina. O Mysaifu apresentou alguns problemas
nesta implementação mas contactos posteriores com os responsáveis desta máquina surtiram
efeito e foi lançada uma nova versão do Mysaifu com estes problemas resolvidos.
Foi necessário arranjar uma solução para a visualização do vídeo, das 3 escolhas com
que nos deparámos escolhemos aquela que apresentava uma melhor qualidade na reprodução
do vídeo, a solução escolhida foi desenvolver a aplicação em Java conjuntamente com o
RealPlayer. Com esta solução, apenas foi necessário criar um processo paralelo na
codificação e armazenamento de vídeo do projecto SSNT-Service (fig. 4.18).
Nesta altura já tínhamos criado a maior parte do serviço proposto inicialmente faltando
somente a inclusão de reconhecimento de fala na interface. Este assunto será analisado no
capítulo seguinte.
Carlos Bandeirinha, Diogo Areia 51
5 Cap.5 Interface Multimodal com fala
5.1 Tecnologias existentes
Existem inúmeras tecnologias de reconhecimento de fala no mercado. A maior parte
delas são para PC mas cada vez mais começam a aparecer aplicações para reconhecimento de
fala em dispositivos móveis (telemóveis e PDAs ) , em automóveis, electrodomésticos e
mesmo em nossa casa (dispositivos para acender lâmpadas, ligar a televisão ,etc.).
Naturalmente a capacidade de processamento e a memória dos dispositivos móveis
não é a mesma dos computadores de secretária e como tal, os programas de reconhecimento
de fala para os dispositivos móveis têm vocabulários limitados. Por exemplo, um PDA , iPaq
3800 com um processador Intel StrongARM a 200Mhz e 64MB de RAM , apenas consegue
reconhecer alguns milhares de palavras enquanto um telemóvel activado por fala apenas
consegue trabalhar com poucas centenas de palavras.
É necessário então adaptar os motores de reconhecimento de fala , limitando o
tamanho do vocabulário de forma a optimizar a memória consumida e o tempo de
processamento nos dispositivos móveis.
Existem 2 tipos de programas de reconhecimento:
• Dependentes do orador
• Independentes do orador
Os programas de reconhecimento de fala dependentes do orador normalmente são mais
rápidos, mas pequenos e com maiores taxas de sucesso. Estes programas ajustam-se ao modo
como falamos mas requerem mais tempo de aprendizagem pois é necessário treinar o
programa às nossas características de fala. Um desses programas é o Voice lookUp.
O Voice LookUp 1(fig. 5.1) da HandHeld Speech é uma aplicação
para procurar contactos e lançar aplicações usando comando de
voz. O programa necessita de ser treinado para a nossa voz. Uma
das particularidades deste programa é o facto de podermos mudar e
melhorar o reconhecimento. Por exemplo, se o programa encontrar
um contacto que não souber pronunciar vai pedir que o utilizador
treine o programa para aquele contacto.
Figura 5.1- Voice Lookup
Os programas de reconhecimento de fala independentes do orador, reconhecem a fala
de qualquer utilizador sem ser necessário o treino. São programas mais fáceis de aprender a
usar mas têm tendência em ser programas que ocupam mais espaço e portanto requerem mais
recursos do dispositivo a que se destina. O PDsay2 da ScanSoft é um desses programas.
1
2
http://www.handheldspeech.com/
http://developer.scansoft.com/
52
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
O PDsay (Fig.5.2) à semelhança do Voice LookUp permite
ao utilizador que se usem comandos de voz para procurar
contactos e lançar aplicações. A propriedade mais
interessante é o motor de TTS, quando é encontrado o
contacto pretendido a aplicação “lê-nos” esse contacto
através dos altifalantes embutidos no PDA. Este programa
tem a particularidade de procurar contactos sem nunca ser
necessário olhar para o visor do dispositivo.
Figura 5.2 PDSay
Concluindo, ambos os programas para funcionar num PDA ou num dispositivo móvel
têm que ter comandos de voz em numero limitado de forma a poupar a memoria disponível.
Mesmo assim ainda existem algumas limitações:
• O software de reconhecimento de fala requer uma grande quantidade de
espaço.
• A qualidade dos microfones integrados não é suficiente boa.
Estes programas armazenados ocupam cerca de 4Mb e podem requerer mais 4 a 5 Mb
de RAM para serem executados.
Os microfones incluídos nos PocketPc´s não são projectados para gravação de alta –
fidelidade. Como tal, os programas vão ter mais “dificuldade” em reconhecer o discurso, é
necessário falar claramente e manter a boca perto do microfone.
A IBM desenvolveu o embedded ViaVoice1, que é uma edição multiplataforma que
permite que se use a tecnologia desenvolvida pela IBM em dispositivos móveis como smartphones , PDA´s e componentes automóveis. Suporta uma grande variedade de sistemas
operativos em tempo real ,Real Time Operating Systems (RTOS), e microprocessadores. As
aplicações que usem o embedded ViaVoice podem usar esta tecnologia em duas formas:
• Comando e controlo (Command and Control) em que se utiliza o
reconhecimento automático de fala para receber comandos do utilizador
para navegar no dispositivo móvel.
• TTS (Text To Speech) – é usado para sintetizar a fala humana a partir de
texto. O TTS da IBM pode ser usado para sintetizar palavras em várias
línguas distintas.
Finalmente, existem alguns SDKs (Software Development Kits) que podem ser usados
para construir aplicações com suporte para fala. Entre os vários SDKs existentes no mercado
destacam-se o IBM Embedded ViaVoice Enterprise Edition Software Developers Kit 2para o
iPaq com o PocketPc2002 e o Fonix da Voiceln3.
1
http://www.ibm.com/software/pervasive/embedded_viavoice_enterprise/
http://www-306.ibm.com/software/pervasive/embedded_viavoice_enterprise/about/
3
http://www.softplatz.com/software/fonix/
2
Carlos Bandeirinha, Diogo Areia 53
5.2 VoiceXML
O VoiceXML1 é o nome da tecnologia standard desenvolvida e controlada pelo Fórum
VoiceXML2 .Esta tecnologia foi construída na sequencia de outros projectos como o VoXML
3
da Motorola e o SpeechML 4da IBM, com o objectivo de criar um standard para interagir
com serviços através da interface de voz. O acesso à informação disponível na Web é feito,
tradicionalmente, através de programas de visualização (browser s) que interpretam uma
linguagem de marcas - como a Hyper Text Markup Language (HTML), para depois
apresentarem a informação aos diversos utilizadores. O objectivo foi pois criar um conjunto
de regras para os browser s operados por voz, que deram origem a uma linguagem de marcas
mais rica, baseada numa linguagem de marcas estendida (eXtended Markup Language XML), o VoiceXML (fig. 5.3).
O VoiceXML é uma linguagem de programação que integra a síntese e o
reconhecimento de fala, com o objectivo de representar diálogos pessoa-máquina, à
semelhança da linguagem HTML. No entanto, esta última assume a existência de um browser
para a visualização gráfica dos conteúdos, enquanto que o VoiceXML assume a existência de
um browser VoiceXML com saída e entrada de áudio.
Figura 5.3 Voice XML
Assim sendo, o principal objectivo desta linguagem é o de permitir que os conteúdos
disponibilizados na Internet sejam acedidos pela aplicação de voz, permitindo a integração de
serviços de voz e dados. As sequências de diálogos interactivos entre o utilizador e a interface
vocal são convertidos em comandos HTTP e vice-versa por um gateway VoiceXML . A rede
de comunicação (fig. 5.4) é composta pela: rede de telefone, um gateway VoiceXML e a rede
Internet.
1
http://www.voicexml.org/
http://www.VoiceXML .org
3
http://voxml.mot.com/
4
http://www.alphaworks.ibm.com/formula/speechml
2
54
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 5.4 Rede de comunicação do VoiceXML
A utilização do VoiceXML pressupõe sempre um gateway VoiceXML especializado
que está ligado, tanto à rede pública de telefones, como à Internet
De forma sucinta vamos explicar o modo como se processa a transferência de
informação num sistema que implementa esta tecnologia. Primeiro, o utilizador faz uma
chamada para um determinado número através do seu telefone. O atendimento é feito por uma
entidade computacional que é o VoiceXML gateway . Depois, este faz um pedido ao servidor
de documentos (o servidor pode estar em qualquer lugar da rede da Internet) que lhe vai
devolver o documento pedido na chamada .Uma parte constituinte do gateway chamado
VoiceXML interpreter , executa os comandos para que os conteúdos sejam “falados” pelo
sistema, ouve as resposta e passa-as ao motor de reconhecimento de fala que também faz
parte da gateway (fig. 5.5 e 5.6).
Figura 5.5 Os componentes da gateway VOICEXML
Carlos Bandeirinha, Diogo Areia 55
Figura 5.6 Detalhes da arquitectura
Não há limites para as aplicações que usam o VoiceXML , seja por meio de telefone
fixo ou móvel. Alguns exemplos: serviços bancários, reservas de voos, programação de lazer,
comércio electrónico e acesso ao e-mail pelo sistema de voz.
5.3 XHTML+Voice
O XHtml+Voice 1(X+V) é uma linguagem de marcas para o desenvolvimento de
aplicações multimodais. Como o VoiceXML , o X+V aparece como resultado da crescente
procura de aplicações baseadas em voz em dispositivos móveis. Ao contrário do VoiceXML ,
o X+V usa elementos visuais e a voz , trazendo uma nova perspectiva na construção de
aplicações para dispositivos móveis, as aplicações multimodais. Ferramentas como o IBM
Multimodal toolkit2 possibilitam a inclusão de controlo por fala em páginas Web, por sua vez
browser s multimédia (Multimédia Browser s) como o Access3 e o Opera4 possibilitam ao
utilizador a navegação nesse tipo de páginas.
O X+V (fig. 5.7) surgiu devido ao facto de os dispositivos móveis serem cada vez mais
pequenos e portanto os modos de interacção com o utilizador, o teclado e a caneta começarem
a estar obsoletos. Criou-se assim o acesso multimodal, que combina vários tipos de input no
dispositivo (voz, keyboard e caneta) de forma a facilitar a interacção com o dispositivo móvel.
Por exemplo, num browser X+V no PDA é possível seleccionar items com a caneta ou com
voz, é possível preencher formulários com voz , etc. Com esta tecnologia a informação no
PDA pode ser visualizada ou falada.
1
http://www.w3.org/TR/xhtml+voice/
http://www-306.ibm.com/software/pervasive/multimodal/
3
http://www.access-us-inc.com/Products/client-side/Prod_NetFront_nf_xhtml.html
4
http://www.opera.com/products/devices/multimodal/
2
56
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 5.7 Tecnologia X+V
O NetFront Browser para o PocketPc suporta a tecnologia de reconhecimento de fala
baseada no XHTML + Voice. Este browser usa o embedded ViaVoice da IBM suportando
assim o reconhecimento e síntese de fala de dados possibilitando a introdução de dados em
páginas Web com este tipo de suporte.
Uma das aplicações de teste mais conhecidas é a encomenda de uma pizza (fig. 5.8):
Figura 5.8NetFront Browser –Pizza Demo
Concluindo, estes tipo de tecnologia introduz o conceito de aplicações multimodais
que possibilitam a interacção com vários serviços usando a voz, teclado ou caneta. No
exemplo da encomenda de uma pizza é possível introduzir o pedido usando a caneta ou a voz
para preencher formulários ou para mudar de campo, é o utilizador que escolhe. De notar que
o reconhecimento de fala neste browser é independente do orador, mas só está disponível
para a língua inglesa. Os testes que realizamos com este programa foram bastante satisfatórios
e com altas taxas de reconhecimento. Pensamos que no futuro este tipo de aplicações serão as
mais utilizadas em dispositivos móveis de pequenas dimensões , comos os telemóveis e
PDAs.
Carlos Bandeirinha, Diogo Areia 57
5.4 AUDIMUS
O AUDIMUS é um sistema de reconhecimento de fala contínua, independente do
orador , para vocabulários largos do português europeu. O AUDIMUS usa um sistema de
reconhecimento híbrido MLP/HMM no qual se usa um processo de Markov não-observável
(Hidden Markov model –HMM) para modelar a natureza temporal do sinal de fala. O MLP é
usado como modelo acústico no âmbito dos HMMs e estima a probabilidade a posteriori dos
fones independentes do contexto que será utilizada no processo de Markov.
Este reconhecedor foi usado em modo servidor, ou seja, recebe o áudio capturado no
PDA e efectua o reconhecimento numa máquina dedicada devolvendo o resultado deste
reconhecimento. Este reconhecedor é constituído por vários módulos: detecção do endpoint
do sinal de fala, extracção de características, modelo acústico e descodificador. É possível
definir o modelo linguístico deste reconhecedor, facto que se tornou bastante útil no
desenvolvimento deste projecto. O modelo linguístico que usámos apenas continha os
comandos de voz necessários para a navegação com fala o que permitiu obter boas taxas de
reconhecimento.
O modelo acústico usado no reconhecedor é o SpeechDat treinado com fala telefónica
gravada a 800hz e 8 bits por amostra.
O servidor do AUDIMUS foi implementado em Java, o que permitiu a fácil integração
com a interface desenvolvida.
5.5 O reconhecimento de fala no aplicação desenvolvida
Depois de analisarmos as tecnologias existentes ao nível do reconhecimento de fala e
de fazer uma pesquisa das tecnologias desenvolvidas no INESC-L2F decidimos adicionar a
funcionalidade de reconhecimento de fala na nossa aplicação usando o projecto AUDIMUS.
O modo como foi implementado o reconhecimento de fala na nossa aplicação não se
assemelha nem ao VoiceXML nem ao XHTML+Voice. No VoiceXML pressupõe-se a
existência de um gateway onde é reconhecido o pedido de fala do utilizador. De seguida esse
gateway faz uma busca numa base de dados e devolve o documento pretendido sob a forma
de fala. O XHTML+Voice é uma tecnologia que pressupõe a construção de páginas web com
sintaxe especifica e o uso de browsers multimodais. No nosso projecto usámos o AUDIMUS
como a entidade que reconhece a fala, a aplicação desenvolvida no PDA recebe esse
resultado, interpreta-o e obedece ao comando “falado”. Desta forma é possível navegar pelos
menus da nossa aplicação somente com fala. Criámos assim uma aplicação multimodal. Este
processo está descrito graficamente na figura 5.9.
Figura 5.9 O reconhecimento de fala no AUDIMUS
58
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Quando o utilizador carrega no botão de reconhecimento da aplicação e diz “Pesquisa
Livre”, é capturado e enviado o sinal de fala para o AUDIMUS, este detecta o final da palavra
(EOS1) , extrai as características do sinal , compara-as com o modelo acústico e linguístico e
devolve o resultado sob a forma de texto. A figura 5.10 seguinte exemplifica este processo.
Figura 5.10 O processo de reconhecimento do AUDIMUS
Foi necessário definir o vocabulário a ser reconhecido pelo AUDIMUS, no contexto
da nossa aplicação criámos um vocabulário que servisse para navegar pela totalidade deste
serviço, para tal usámos uma ferramenta especifica, o XML2FST, que a partir de um ficheiro
XML cria o modelo linguístico e o léxico usados no reconhecimentos. A figura 5.11 mostra o
XML com o vocabulário definido :
Figura 5.11 O vocabulário escolhido
Na implementação desta arquitectura no PDA tivemos alguns problemas com a
máquina virtual usada, o Mysaifu . Inicialmente esta máquina não possuía API´s para a
captura de áudio e portanto foi necessário implementar essas API´s de forma nativa. Após
alguns contactos por correio electrónico com os responsáveis desta máquina virtual saiu uma
nova versão que já permitia a captura de áudio. O áudio é capturado no PDA a 16 bits por
amostra, a uma frequência de 8000hz e com apenas 1 canal. Sempre que se inicia o processo
1
End Of Sentence
Carlos Bandeirinha, Diogo Areia 59
de reconhecimento, é aberto um canal de comunicação com o AUDIMUS e de seguida iniciase o envio do áudio para o AUDIMUS em tempo real.
5.6 Trabalho realizado
Nesta fase do projecto começámos por estudar as tecnologias existentes ao nível do
reconhecimento de fala em aplicações multimodais. De seguida centrámos as nossas atenções
nas tecnologias existentes em dispositivos móveis , mas especificamente nos PDA´s. Para
termos uma ideia do modo de funcionamento de uma interface multimodal instalámos no
PDA o Acess Browser que contém o motor de reconhecimento da IBM, o ViaVoice. Testámos
este serviço usando a demo que vem com este browser, “pizza order”. Os testes realizados
mostraram que este tipo de aplicações podem ser bastante úteis pois é possível preencher
formulários e navegar através de conteúdo somente com voz. O motor de TTS presente neste
browser é uma mais valia. Um dos defeitos encontrados neste browser é o espaço que este
ocupa na memória do PDA , tivemos inclusivamente que apagar alguns programas para
instalar este browser.
Na aplicação desenvolvida neste projecto, tivemos que criar rotinas para a inclusão do
reconhecimento da fala. Na fase inicial apenas nos preocupámos em saber se era possível
realizar a captura de áudio com o Java. De seguida centrámos as nossas atenções na ligação ao
servidor do AUDIMUS, esta fase decorreu sem problemas. Na fase seguinte testámos o
desempenho do reconhecimento da fala capturada no PDA, que nos surpreendeu bastante
pelas elevadas taxas de sucesso no reconhecimento. Por último, incluímos todos estes
processos na nossa interface. Com o objectivo de garantir um fácil acesso ao reconhecimento,
incluímos um botão para o reconhecimento de fala na aplicação e criámos também um
processo que detecta se o botão de gravação do PDA é premido e que inicia também o
processo de reconhecimento.
O vocabulário escolhido por nós foi o que nos pareceu ser o mais adequado á interface
criada para a navegação entre os conteúdos, este vocabulário escolhido apenas tinha 12
palavras. Nos testes realizados no reconhecedor com um modelo de linguagem maior (64 mil
palavras usado no projecto ALERT para o reconhecimento das notícias televisivas) houve
uma diminuição da taxa de reconhecimento
Desta forma torna-se bastante fácil manusear e navegar na aplicação ,com a inclusão
da interface de voz ,o utilizador dispensa a utilização da caneta para inserir os dados no
teclado virtual , tarefa que muita vezes se torna aborrecida.
60
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
6 Capitulo 6- Descrição do Serviço / Testes
De uma forma global, a aplicação desenvolvida tem a seguinte arquitectura (fig. 6.1):
Figura 6.1 Arquitectura do aplicação
No menu inicial da aplicação criada para o PDA foram disponibilizados 2 tipos de
serviço: Serviço de matching e a pesquisa directa na base de dados. O serviço de matching
serve para o utilizador consultar a existência de notícias, que ainda não tenham sido
visualizadas, de acordo com o perfil definido por si. A pesquisa directa na base de dados dá a
liberdade ao utilizador de pesquisar um tema á sua escolha (pesquisa livre), pesquisar
telejornais por datas ou últimos títulos. Nas secções seguintes explicamos detalhadamente
cada um destes serviços bem como os testes efectuados no reconhecimento de fala no PDA.
6.1 O serviço de matching
O serviço de matching é o serviço em que o utilizador escolhe o tipo de notícias que
deseja receber sempre que sejam processados novos telejornais. Por exemplo, pode definir o
tema das notícias que deseja receber, pode ainda definir os índices geográficos e onomásticos
das noticias. Esse registo é feito usando o website do serviço SSNT1. As figuras 6.2, 6.3 e 6.4
mostram o aspecto deste website..
1
http://ssnt.l2f.inesc-id.pt
Carlos Bandeirinha, Diogo Areia 61
Figura 6.2 A página de entrada do Website SSNT
Figura 6.3 A página de registo do utilizador
62
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Figura 6.4 Alteração de perfil/ Definição dos tópicos
Este serviço de matching podia ser implementado de duas maneiras no PDA:
A primeira era usar o Pocket Outlook1, para receber os emails com a descrição das
noticias encontradas de acordo com o perfil desejado, no entanto, os emails recebidos no
Pocket Outlook não permitem seguir as hiper ligações presentes no texto e portanto não é
possível disponibilizar o vídeo da noticia , através de um link. Nesta solução não estamos a
usar a aplicação desenvolvida em Java e não temos também a possibilidade de navegação por
fala.
A solução utilizada foi aproveitar alguma informação da base de dados SSNT-DB e
implementar o seguinte esquema de matching (fig 6.5):
Figura 6.5 O esquema de matching
1
Software para a recepção e envio de e-mails presente no Windows Mobile,
Carlos Bandeirinha, Diogo Areia 63
O utilizador ao introduzir o username e a password envia essa informação ao Web
Server. De seguida este encarrega-se de ir á base de dados (tabela User) obter o UserID, que é
usado internamente na base de dados para identificar o utilizador. A seguir obtemos de um
ficheiro XML o último acesso á base de dados deste utilizador e obtemos as noticias do seu
perfil que tenham ocorrido depois do ultimo acesso á base de dados. O ficheiro XML(fig. 6.6)
é simplesmente um ficheiro de propriedades criado especificamente para o serviço de
matching no PDA. Tem a seguinte estrutura:
Figura 6.6 XML com os últimos acessos do utilizador
Cada utilizador é descrito por uma chave, o userID, e por uma propriedade, a última
data de acesso á base de dados.
Eis o que acontece do ponto de vista do utilizador(fig. 6.7):
Figura 6.7 Serviço de matching no PDA
No painel principal o utilizador pode introduzir o Username e a Password, o painel
seguinte indica o número de notícias não lidas e o painel seguinte mostra essas notícias.
6.2 A pesquisa directa na base de dados
A pesquisa directa na base de dados permite ao utilizador
escolher entre uma de 3 opções: Pesquisa livre, Pesquisar datas de
telejornais, Pesquisar títulos de telejornal. O aspecto do painel de
pesquisa livre está demonstrado na figura 6.8.
Figura 6.8 Painel de pesquisa livre
64
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
A pesquisa livre , como o nome indica , permite ao utilizador pesquisar o texto
pretendido, na base de dados. Se houver alguma noticia onde esse mesmo texto tenha ocorrido
é devolvido o titulo desta noticia , o contexto onde o texto foi encontrado e claro, o vídeo
desta notícia.
Figura 6.9 Pesquisa livre
O texto introduzido no textfield é enviado ao Web Server que por sua vez faz um
pedido à base de dados. Este pedido é feito usando o projecto Hibernate, como já foi
referenciado nos capítulos anteriores. O resultado é retornado e o utilizador tem a
possibilidade de escolher qual a noticia que deseja. Na figura 6.9 podemos ver que aparece o
titulo da noticia e também o contexto onde foi encontrada. O contexto é nada mais, do que a
frase anterior , a frase onde foi encontrado o texto e a frase posterior. Deste modo é possível
perceber se esta é a noticia que desejamos. O botão “ver notícia” possibilita a visualização do
vídeo desta notícia. Outro aspecto que importa referir é o facto de esta busca estar limitada a
50 ocorrências para impedir que pesquisas com palavras muito comuns possam sobrecarregar
a memória do PDA. Por exemplo se pesquisarmos as palavras “de”, “com”, “e”, etc. , o
resultado vai ser praticamente todos os telejornais disponíveis na base de dados, o que irá
sobrecarregar não só o PDA como a rede, para evitar tal facto limitámos o numero de
ocorrências para 50.
A pesquisa por datas de telejornal , permite ao utilizador escolher as notícias pelas
datas de emissão desse telejornal (fig. 6.10).
Figura 6.10 Pesquisa por datas de telejornal
Mais uma vez limitamos esta busca a apenas 50 telejornais. A escolha do telejornal
pretendido é feita numa primeira instância, de seguida visualiza-se todas as notícias do
telejornal escolhido e mais tarde o vídeo.
A pesquisa por títulos de telejornal permite ao utilizador visualizar as noticias mais
recentes que foram capturadas(figura 6.11):
Carlos Bandeirinha, Diogo Areia 65
Figura 6.11-Pesquisa por títulos
6.3 Comandos de voz
A funcionalidade de reconhecimento de fala no PDA , permite ao utilizador dar ordens
á aplicação. Naturalmente restringimos o vocabulário de forma a diminuir a ambiguidade no
reconhecimento de palavras e assim aumentar as taxas de reconhecimento. O vocabulário é o
seguinte:
•
•
•
•
•
•
•
•
•
•
•
“Pesquisa livre”
“Pesquisar datas”
“Pesquisar títulos”
“ Pesquisar”
“ menu inicial”
“voltar”
“próximo” / ”próxima”
“anterior”
“ver noticia”
“ver notícias”
“Seleccionar data”
As palavras “pesquisa livre”, “pesquisar datas”, “pesquisar títulos”, podem ser
utilizadas no contexto do painel de pesquisa directa (escolha do tipo de pesquisa). No
painel de pesquisa livre a palavra “pesquisar” serve para iniciar a procura na base de dados
do texto pretendido. As palavras “menu inicial” e “voltar” servem para regressar ao painel
anterior. “Próximo”/ “Próxima” e “anterior” são os comandos usados para alternar entre as
notícias quando o resultado das pesquisas são obtidos, servem igualmente para escolher a data
do telejornal no painel de pesquisa de datas. “Seleccionar data” server para escolher a data
no contexto do painel de pesquisa de datas. O comando de voz “ver noticia” serve para ver
o vídeo da noticia escolhida e finalmente o comando “ver noticias” serve para ter acesso ás
noticias obtidas de acordo com o perfil do utilizador no painel de matching.
66
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
6.4 A codificação do vídeo
Por forma a optimizar a visualização do vídeo no PDA , testámos algumas
codificações diferentes para os ficheiros de vídeo. Tivemos em conta o espaço em disco que o
ficheiro ocupa bem como a qualidade do vídeo no PDA na reprodução via streaming. Assim,
dado que a emissão é gravada num ficheiro Avi com 384x288 pixel e 1500Kbps é necessário
codificar este ficheiro para o formato RealVídeo de forma a ser compatível com o RealPlayer
do pocket PC. Testámos codificações diferentes com tamanhos de imagem de 192x144 e
224x168, pois como o PDA tem o visor com dimensões reduzidas não é necessário ter um
tamanho de imagem de vídeo tão grande ( 384x288 pixel). Usámos vídeos de teste com
50Kbps e 70 Kbps e com 15 e 25 imagens por segundo. A escolha recaiu sobre a codificação
do vídeo com 50 Kbps , tamanho de imagem de 224x168 e 15 imagens por segundo , pois
garante-se uma boa qualidade de imagem no PDA e simultaneamente garantimos que o
ficheiro não é demasiado grande para ser reproduzido via streaming, por exemplo, um
ficheiro de 1 minuto apenas ocupa 384 Kb enquanto que no formato Avi ocupa cerca de 20
Mb! A figura 6.12 mostra a diferença entre o vídeo no formato Avi e o vídeo no formato
RealMedia
Figura 6.12 A codificação do vídeo
6.5 Testes do reconhecedor em diferentes ambientes:
De forma a testar o desempenho da aplicação desenvolvida numa situação real de
utilização realizámos alguns testes em diferentes ambientes. O único requisito necessário para
realização destes testes é ter acesso a uma rede WiFi. Os testes foram real em ambiente
silencioso, na rua, com música e em ambientes com elevado número de pessoas, como é o
caso de bares e cafés.
Os testes realizados revelaram que existem alguns problemas relativamente ao
desempenho do reconhecedor em ambientes com ruído, os restantes módulos do serviço
funcionam sem qualquer tipo de problema (ligação à base de dados, streaming de vídeo).
A figura 6.13 mostra a forma de onda que chega ao reconhecedor num ambiente
silencioso, este teste foi realizado na sala de alunos do INESC-L2F.
Carlos Bandeirinha, Diogo Areia 67
Figura 6.13 Ambiente silencioso
Verifica-se que neste ambiente não existem problemas relativamente á detecção do
comando de voz falado no PDA e respectivo reconhecimento de fala. Neste ambiente a taxa
de sucesso do reconhecimento foi perto dos 100%.
Noutra situação, a figura 6.14 mostra a forma de onda que chega ao reconhecedor num
ambiente com música.
Figura 6.14 Ambiente com música
Neste caso tivemos grandes problemas ao nível do reconhecimento pois o
reconhecedor nunca conseguiu detectar o “End Of Sentence” (EOS) necessário para a
detecção do fim das palavras. A taxa de reconhecimento nesta situação foi praticamente nula
pois no reconhecedor nunca foi possível detectar e seccionar e reconhecer os comandos de
voz.
.
A figura 6.15 ilustra forma de onda adquirida num ambiente ruidoso , como é o caso
do bar de Engenharia Civil do Instituto Superior Técnico.
Figura 6.15 No bar de engenharia civil do IST
68
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
Nesta situação mais uma vez houve problemas na detecção do fim das palavras pois a
energia do ruído confunde-se com a energia do sinal de voz. Ouve alturas em que foi possível
obter bons resultados mas quando o ruído de fundo aumentava o reconhecedor deixava de
funcionar.
Por forma a solucionar o problema da detecção de EOS ajustámos alguns parâmetros
no reconhecedor, um desses parâmetros é o backgroundtime. Este parâmetro é usado para
estimar o EOS tendo em conta o ruído de fundo, mais concretamente, durante o intervalo de
tempo estipulado pelo backgroundtime são usadas janelas de 10ms para calcular o valor
médio do ruído ,valor este que é usado nos cálculos efectuados na detecção do EOS. Este
parâmetro é modificado no ficheiro AUDIMUS.XML do reconhecedor(fig. 6.16).
Figura 6.16 AUDIMUS.XML
No exemplo da figura 6.16 ,o valor apresentado pelo backgroundtime é 150 , cada
unidade corresponde a uma janela de 10 ms , portanto para um backgroundtime de 150 são
estimados 1,5 segundos de ruído de fundo(fig. 6.17).
Figura 6.17-Janela de 150*10ms=1,5s
Por forma a estimar o valor adequado para o backgroundtime tivemos que ter em conta
um pequeno pormenor que é o facto do PDA nos primeiros 0,3 s não enviar qualquer tipo de
sinal ao reconhecedor, como se pode verificar na forma de onda representada na figura 6.18.
Carlos Bandeirinha, Diogo Areia 69
Figura 6.18 silêncio provocado pelo PDA
Assim, de forma empírica e após alguns testes, definimos um valor para o
backgroundtime de 100, ou seja 1s.
Com este parâmetro reajustado procedemos a novos testes. A forma de onda do sinal
recebido não se altera, o que se altera é a precisão com que se detecta o endpoint. Com o
reconhecedor optimizado , conseguiu-se obter boas taxas de reconhecimento. A detecção de
EOS foi melhorada , no entanto em situações de ruído extremamente elevado (sirenes, apitos ,
ruído dos automóveis , vento , pessoas a falar, etc.) o reconhecedor continuou com os mesmos
problemas. Ilustramos estes facto na fig. 6.19, em que se realizaram testes na varanda do L2F
, situado no 2º andar do edifício do INESC .
Figura 6.19 Na varanda do INESC
Nesta situação , o reconhecedor teve um desempenho desastroso devido á interferência
do vento no microfone.
Embora tenham sido feitos alguns ajustes no reconhecedor existem situações muito
difíceis de controlar e prever, como é o caso do vento a bater no microfone do PDA. No
entanto em ambientes controlados o desempenho de reconhecedor foi bastante bom.
70
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
6.6 Testes com vários oradores
Realizaram-se testes com diferentes oradores a fim de testar o desempenho do
reconhecedor, estes testes foram realizados nas mesmas condições (sala de alunos do INESCL2F). Os resultados obtidos foram os seguintes:
Tabela 6.1 Testes com vários Oradores
Comando de voz
Pesquisa livre
Pesquisar datas
Pesquisar títulos
Taxa de reconhecimento(%)
100
80
60
Pesquisar
Menu inicial
100
100
Menu anterior
Voltar
100
100
Próximo
Próxima
Anterior
80
60
80
Ver notícia
Ver notícias
100
100
Seleccionar data
Pesquisa directa
Entrar
100
80
80
Nestes testes foram utilizados 5 oradores diferentes, todos do sexo masculino.
Comprava-se que o reconhecedor é independente do orador dadas as taxas de reconhecimento
tão elevadas. Os testes decorreram como esperado, conclui-se que qualquer pessoa pode usar
o reconhecedor na aplicação desenvolvida.
h
6.7 Resultados alcançados
Relativamente ao serviço criado para a distribuição de conteúdo multimédia podemos
dizer que os objectivos foram alcançados. Disponibiliza-se ao utilizador um serviço que
possibilita vários tipos de pesquisa e um serviço de matching.
Os testes realizados na codificação do vídeo indicaram que já é possível visualizar
clips de vídeo com qualidade bastante boa, sem qualquer limitação ao nível da fluidez do
vídeo e na qualidade do áudio. Para optimizarmos este aspecto codificámos o vídeo com
diferentes parâmetros para escolher aquela configuração que melhor se adaptava ao PDA
testado.
No lado do utilizador, criámos uma interface multimodal que permite ao utilizador
alternar entre conteúdos somente com voz. Os testes realizados no reconhecimento revelaram
que ainda existem alguns pontos que necessitam de melhoramento , nomeadamente na
Carlos Bandeirinha, Diogo Areia 71
detecção de endpoints. Preocupámo-nos em realizar o maior número de testes no
reconhecimento da fala em diferentes ambientes e com diferentes utilizadores para avaliar a
“usabilidade” desta aplicação. Houve situações que demonstraram ser favoráveis mas houve
outras bastante adversas que impossibilitaram o reconhecimento da fala. Será necessário
realizar uma investigação mais exaustiva nestes ambientes por forma a solucionar estes
problemas , por exemplo a introdução de controlo de ganho poderá aumentar a taxa de
reconhecimento. No entanto estes aspectos saem fora do âmbito do nosso trabalho pelo que
não faz sentido abordarmos estes aspectos inerentes aos problemas de reconhecimento de fala
no projecto AUDIMUS.
72
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
7 Considerações finais
7.1 O projecto realizado
O objectivo proposto para este trabalho era a realização de um serviço para
distribuição de notícias multimédia para dispositivos móveis. Ao longo da realização deste
projecto, fomos verificando que o conceito da segmentação, categorização e distribuição de
conteúdos multimédia ainda é uma área recente mas que cada vez mais suscita interesse, uma
vez que é indispensável para tornar a informação facilmente acessível. Embora este projecto
tenha sido implementado somente para notícias do telejornal da RTP este serviço poderá ser
facilmente aplicado a outras áreas como a meteorologia, trânsito, cinema , desporto, etc.
Numa primeira abordagem, a base de dados do servidor lidava com documentos XML
que continham a informação relativa aos telejornais. Os testes realizados revelaram que este
tipo de base de dados (nativa em XML) apresentava bastantes limitações, nomeadamente ao
nível da capacidade de armazenamento e tempos de resposta. Por forma a resolver problema
concluímos que uma base de dados em SQL seria a opção mais correcta. Para realizar a
comunicação com o software do cliente foi usado um servidor Web (Jetty) que desde o inicio
se mostrou adequado para a arquitectura deste sistema.
O Java foi a linguagem de programação escolhida para implementar este serviço, quer
do lado do cliente quer do lado do servidor. Esta escolha deveu-se ao facto do Java ser uma
linguagem multiplataforma e portanto ser facilmente portável para diferentes dispositivos e
sistemas operativos. A maior parte dos telemóveis e PDA´s já possuem máquinas virtuais de
Java que permitem a execução de programas escritos nesta linguagem, no entanto essas
máquinas ainda são bastante heterogéneas entre si. Alguns telemóveis mais recentes já
possuem API`s para a manipulação de conteúdo multimédia e API´s para controlo de fluxos
de streaming enquanto que os mais antigos ainda não possuem essa capacidade. Tal facto
associado também á falta de ambiente de testes para os telemóveis inviabilizou a hipótese de
aplicar este serviço para os mesmos.
Nos PDA´s a maioria das máquinas virtuais Java são pertencentes a empresas privadas
como a (nscicom e esmertec). No entanto uma nova máquina virtual Java, o Mysaifu , grátis
sobre a licença GPLv2(GNU Public License Version 2) revelou ser uma boa alternativa. O
serviço foi testado num PDA ipaq h3870 da compaq , com o PocketPc 2002. Este sistema
operativo já está obsoleto, apresentando algumas limitações, por exemplo, não suporta o
protocolo 802.1x necessário para fazer a ligação ao WiFi do Instituto Superior Técnico.
O serviço acabou por ser apenas direccionado para PDA´s e foi necessário construir
uma interface gráfica para este dispositivo. As soluções encontradas na linguagem Java foram
o AWT e o Swing . Embora o AWT tenha menos componentes gráficos do que o Swing , é
mais estável e requer menos recursos ao PDA, este toolkit foi o escolhido para realizar a
interface gráfica.
A distribuição e visualização do vídeo foi um problema que não foi fácil de resolver
pois as máquinas virtuais Java testadas não apresentavam soluções ao nível da reprodução do
vídeo. Foi ainda testada uma API externa , o JMF, criada especificamente para a distribuição
e reprodução de conteúdo multimédia mas o seu desempenho foi medíocre no PDA. A
solução escolhida foi usar o RealPlayer para o PocketPc conjuntamente com o Helix
Streaming Server para o envio dos pacotes de vídeo.
A introdução de reconhecimento de fala na interface criada permitiu criar uma
interface multimodal, que facilita bastante o manuseamento da aplicação, pois permite o
preenchimento de campos e mudar entre menus somente com a fala. Outra das vantagens
Carlos Bandeirinha, Diogo Areia 73
deste tipo de aplicações baseadas no reconhecimento de voz é que podem ser bastante
interessantes para pessoas com certos tipos de deficiências, facilitando-lhes a vida em
proporcionando-lhes experiências que até então eram completamente impossíveis. Para tal
usámos um reconhecedor “externo” o AUDIMUS para fazer este reconhecimento.
7.2 Limitações e testes ao serviço
Atendendo a que, este projecto, se direccionou para PDA’s, o utilizador necessita
apenas de uma rede WiFi para utilizar o serviço. Hoje em dia, com a difusão deste tipo de
redes este aspecto não constitui problema.
O desempenho do serviço cumpriu com as expectativas, os testes efectuados na rede
WiFi demonstraram que a ligação ao servidor e as pesquisas na base de dados eram feitas
sem qualquer tipo de problemas, verificando-se o mesmo para o streaming de vídeo.
Ao nível do reconhecimento de voz existiram alguns problemas relativamente a certas
palavras quando se utilizou o modelo de linguagem das noticias televisivas. Quando se
utilizou um modelo de linguagem mais pequeno esse problema deixou de existir, atendo a que
o modelo que usámos para mudar de menus e navegar pelo conteúdo das noticias apenas tinha
12 palavras.
O modelo acústico utilizado no AUDIMUS é o SpeechDat, treinado com fala
telefónica 8000hz e 8bits. No contexto da nossa aplicação usou-se o microfone do PDA para
capturar o áudio e enviar o sinal de fala a 8000hz e 16 bits. Embora as condições não sejam
as mesmas do modelo acústico o reconhecedor funcionou bem, no entanto se tivéssemos
construído um modelo acústico para este projecto poderíamos obter melhores resultados, uma
vez que as características do microfone do PDA não são as mesmas de um telefone. Achámos
que não seria necessário construir esse modelo porque as taxas de reconhecimento usando o
SpeechDat foram muito boas, preferimos centrar as nossas atenções noutros problemas ,
nomeadamente ao nível da detecção de endpoints.
No processo de reconhecimento de voz, o áudio é enviado para um reconhecedor
externo via streaming. Este processo pode ter implicações, pois se não houver largura de
banda suficiente os resultados do reconhecimento podem ser desastrosos. A introdução de
codecs de modo a diminuir o tamanho do sinal de áudio seria uma boa abordagem, embora
fosse tornar o aplicação mais pesada computacionalmente. Depois de alguns testes
concluímos que não era necessário introduzir codecs, pois um sinal de áudio com 10s de fala
apenas ocupava 170 Kb e numa rede WiFi a transmissão deste sinal apenas demorava umas
fracções de segundo.
De modo a aumentar a rapidez do processo de reconhecimento uma solução possível
seria implementar os módulos de extracção de características e detecção de endpoints
directamente no PDA, no entanto devidos a limitações no hardware e software deste tipo de
dispositivos, este processo seria bastante complicado de implementar. No futuro esta solução
será viável devido ao aparecimento de novos dispositivos com maiores capacidades de
processamento.
Os testes realizados no exterior apresentaram alguns problemas no reconhecimento da
fala, mais especificamente na detecção de endpoints. Este problema tem a ver com a energia e
nível de ruído elevados, principalmente em ambientes bastante barulhentos, falhando na
maior parte das situações a detecção de endpoints. Sem este parâmetro a detecção do final de
palavra não é estimada correctamente e o reconhecimento falha. Tentámos solucionar o
problema estimando previamente o nível de ruído , mas mesmo assim ainda houve algumas
situações impossíveis de solucionar (vento, ruído de automóveis, bares, discotecas, etc.).
74
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
7.3 Desenvolvimentos Futuros
Futuramente, por forma a melhorar as funcionalidades da interface multimodal poderá
ser adicionado um módulo de TTS1 no PDA, com uma base de dados suficientemente
pequena para não haver demasiados requisitos ao nível do processamento no dispositivo, e
assim criar um sistema de diálogo básico que permita ao PDA “falar” com o utilizador.
Por forma a aumentar a performance do reconhecimento e diminuir os tempos de
reconhecimento poder-se-á incluir os módulos de reconhecimento directamente no PDA, ou
então introduzir apenas os módulos mais importantes. Esta nova funcionalidade irá depender
fortemente do modo como irão evoluir as capacidades computacionais dos dispositivos
móveis.
Ao nível do desenvolvimento da interface gráfica no PDA, com futuro lançamento de
novas plataformas Java nestes dispositivos, já será possível usar o Swing que é um toolkit
gráfico bastante mais completo que o AWT. Neste contexto poderão criar-se novos tipos de
pesquisa e novas funcionalidades inerentes á utilização deste toolkit. Nestas novas
plataformas poderá ser possível também integrar o vídeo na interface Java sem ter que se
recorrer a aplicações externas , como foi o caso do RealPlayer.
7.4 Nota final
Dado que os dispositivos móveis, sejam eles PDA’s ou telemóveis, estão em constante
evolução tecnológica, caminhando-se para a integração destes dois tipos de dispositivos num
único que se chamará terminal multimédia móvel, a sua importância no quotidiano de uma
grande parte da população será crescente e decisiva. O conceito de terminal multimédia só
terá plena abrangência se, para além das funcionalidades básicas actuais , se adicionalmente
existirem tecnologias paralelas que façam a recolha, a segmentação e a categorização da
informação, disponibilizando-a de uma forma simples e automática para o utilizador.
Num futuro próximo as redes interactivas fornecerão um acesso fácil à informação e
aos serviços, disponibilizando aos utilizadores todo um conjunto variado de informação que
terá enormes repercussões no dia à dia das populações.
1
Text To Speech
Carlos Bandeirinha, Diogo Areia 75
Bibliografia
[1] Pereira , Gaspar, Sumarização de Serviços Noticiosos Televisivos, Tese de final de curso ,
Laboratório de língua falada , INESC-ID,Lisboa,2002.
[2] Neto, Martins, Meinedo, Almeida, AUDIMUS. Sistema de reconhecimento de fala
contínua para o português europeu, Proceedings PROPOR IV, Évora, Portugal, 1999
[3] A. Hagen , J. Neto, HMM/MLP Hybrid Speech Recognizer for the Portuguese Telephone
SpeechDat Corpus, Proceedings PROPOR'03, Faro, Portugal, 2003
[4] Ali A., Arshad A, Bakar F., Video Transmission to Mobile Phones Over Wireless
Networks, Multimedia communication unit , telekom Research&Development sdn.Bhd,
Malásia.
[5] Staken, Introduction to Native XML Databases, 31 de Outubro de 2001,
(http://www.xml.com/pub/a/2001/10/31/nativexmldb.html)
[6] Bourret , Ronald, XML Database Products, 5 de Junho de 2006 ,
(http://www.rpbourret.com/xml/XMLDatabaseProds.htm)
[7] Exist database documentation, (http://exist.sourceforge.net/documentation.html)
[8] Nic, Jirat , XPath Tutorial, 2000,
(http://www.zvon.org/xxl/XPathTutorial/General/examples.html)
[9] Hunter , Crawford, Java Servlet Programming, O´Reilly & Associates, USA, Outubro de
1998.
[10] Riggs, Taivalsaari, Van Peursem, Programming Wireless Devices with the Java 2
Platform , Micro Edition, Addison Wesley, Second Edition, 13 de Junho de 2003.
[11] Xquery Tutorial, (http://www.w3schools.com/xquery/xquery_intro.asp)
[12] http://www.mysql.com/
[13] Hibernate reference documentation,
http://www.hibernate.org/hib_docs/v3/reference/en/html/
[14] Java Platform , Micro Edition, (http://java.sun.com/javame/)
[15] Topley, J2ME in a Nutshell, O’Reilly, Março de 2002
[16] Eckel B., Thinking in Java, 3 rd edition, Prentice Hall, New Jersey, 2003
[17] Eckstein R., Loy M., Wood D., Java Swing, O’Reilly , USA, 1998
[18] Topic M., Streaming Media Demystified, Mcgraw-Hill, USA, 2002
[19] Zukowski J., Java AWT reference, O’Reilly , Março 1997
76
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
[20] Helix Universal Server Administration Guide, Maio 2003
http://service.real.com/help/library/guides/helixuniversalserver/realsrvr.htm
[21] http://portal.ua.pt/bibliotecad/default1.asp?OP2=0&Serie=0&Obra=31&H1=5&H2=1
[22] http://www-306.ibm.com/software/pervasive/embedded_viavoice_multiplatform/
[23] http://www-306.ibm.com/software/pervasive/embedded_viavoice_enterprise/about/
[24] http://www.windowsfordevices.com/news/NS9104815983.html
[25] http://www.speechware.be/english/Tips.php#b
[26] http://www.voicesignal.com/news/articles/articles_09_00_02.htm
[27] Pereira F., Bernett I, Universal Multimedia Experiences for Tomorrow, IEEE Signal
Processing Magazine , Março de 2003.
Carlos Bandeirinha, Diogo Areia 77
ANEXO A
(Alert-pt.dtd)
78
Relatório de TFC nº224 – Sistemas de distribuição de notícias multimédia para dispositivos móveis
<?xml version="1.0" encoding="UTF-8"?>
<!--Based on the DTD of the ECHO project-->
<!--Adapted by the ALERT project for additional data handling
- 6/03/02-->
<!--Portuguese Extension -->
<!ELEMENT Transcript (VersionGUID, StorySegment*)>
<!ELEMENT StorySegment (StoryType?, (TranscriptSegment |
VideoClass)+, (UserProfileList? | (ThematicDescriptorList?,
GeographicDescriptorList?, OnomasticDescriptorList?, Title?,
Abstract?, StoryRepresentation?)))>
<!ELEMENT TranscriptSegment (TranscriptGUID, AudioType+,
Speaker?, Bandwidth?, SpeakerLanguage?, Time,
TranscriptWordList?)>
<!--#################### Start GUID Declarations
###################-->
<!ELEMENT VersionGUID (#PCDATA)>
<!ELEMENT TranscriptGUID (#PCDATA)>
<!--#################### End GUID Declarations
####################-->
<!ELEMENT StoryType (#PCDATA)>
<!-- report,
filler, nontrans -->
<!ELEMENT UserProfileList (UserProfile*)>
<!ELEMENT ThematicDescriptorList (Descriptor*)>
<!ELEMENT OnomasticDescriptorList (Descriptor*)>
<!ELEMENT GeographicDescriptorList (Descriptor*)>
<!ELEMENT TranscriptWordList (Word*)>
<!ELEMENT StoryRepresentation (RelevantWord*)>
<!ELEMENT Time EMPTY>
<!ATTLIST Time
start CDATA #REQUIRED
end CDATA #REQUIRED
reasons CDATA #REQUIRED
>
<!-- music, speech, noise, ... -->
<!ELEMENT AudioType (#PCDATA)>
<!ATTLIST AudioType
start CDATA #REQUIRED
end CDATA #REQUIRED
>
<!-- known: T | F -->
<!ELEMENT Speaker EMPTY>
<!ATTLIST Speaker
id CDATA #IMPLIED
name CDATA #IMPLIED
Carlos Bandeirinha, Diogo Areia 79
gender CDATA #IMPLIED
known CDATA #IMPLIED
>
<!-- PT / EN / FR / ... -->
<!-- native: T | F -->
<!ELEMENT SpeakerLanguage (#PCDATA)>
<!ATTLIST SpeakerLanguage
native CDATA #IMPLIED
>
<!-- type: Report, Cut, PivotOn, ... -->
<!ELEMENT VideoClass EMPTY>
<!ATTLIST VideoClass
start CDATA #REQUIRED
end CDATA #REQUIRED
type CDATA #REQUIRED
>
<!ELEMENT UserProfile (#PCDATA)>
<!ATTLIST UserProfile
id CDATA #IMPLIED
>
<!ELEMENT Descriptor (#PCDATA)>
<!ATTLIST Descriptor
id CDATA #IMPLIED
conf CDATA #IMPLIED
>
<!ELEMENT Word (#PCDATA)>
<!ATTLIST Word
start CDATA #IMPLIED
end CDATA #IMPLIED
conf CDATA #IMPLIED
>
<!-- ocurrTranscList: string with list of transcriptsegments
order number in story: "0,1,5" -->
<!ELEMENT RelevantWord (#PCDATA)>
<!ATTLIST RelevantWord
id CDATA #REQUIRED
ocurr CDATA #REQUIRED
ocurrTranscList CDATA #REQUIRED
>
<!ELEMENT
<!ELEMENT
<!ELEMENT
-->
<!ELEMENT
80
Title (#PCDATA)>
Abstract (#PCDATA)>
Bandwidth (#PCDATA)>
Gender (#PCDATA)>
<!-- Studio, Telephone
<!-- M, F -->