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

Transcrição

1 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

2

3 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

4 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 Processamento de informação multimédia Distribuição selectiva de dados multimédia Dispositivos Móveis Streaming Interface Multimodal Reconhecimento de fala ii

5 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 new information that corresponds with the user s profile, he will be notified. ²F - Spoken Language Systems Laboratory Keywords Processing of multimedia information Multimedia selective data distribution Mobile Devices Streaming Multimodal Interface Speech Recognition Carlos Bandeirinha, Diogo Areia iii

6 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 ÁREA DO TRABALHO PROCESSAMENTO DE INFORMAÇÃO MULTIMÉDIA DISTRIBUIÇÃO SELECTIVA DE DADOS MULTIMÉDIA INTERFACES MULTIMODAIS DISPOSITIVOS MÓVEIS TECNOLOGIAS WIRELESS (UMTS,GPRS, WIFI) CONCEITO DO SERVIÇO RECONHECIMENTO DA FALA O PROJECTO ALERT E O SSNT-SERVICE OBJECTIVOS PARA ESTE TRABALHO ARQUITECTURA DO SERVIÇO FASES DO TRABALHO ORGANIZAÇÃO DO RELATÓRIO SERVIDOR WEBSERVER Apache ou Jetty O XML SAX, DOM, BASE DE DADOS NATIVA XML ESCOLHA DA BASE DE DADOS NATIVA BASE DE DADOS EXIST XQUERY VS XPATH IMPLEMENTAÇÃO INICIAL DO SERVIÇO DESEMPENHO DO SERVIÇO O PROJECTO HIBERNATE O TRABALHO DESENVOLVIDO CAP.3- DISPOSITIVOS MÓVEIS J2ME TELEMÓVEIS PDA S JAVA NOS PDA S CONCLUSÃO/TOMADA DE DECISÃO CAP4 A APLICAÇÃO NO PDA VISÃO GERAL DO AWT (ABSTRACT WINDOW TOOLKIT) VISÃO GERAL DO SWING O DESENVOLVIMENTO DA INTERFACE GRÁFICA NO PDA O VÍDEO NO PDA Java Media Framework RealPlayer para PocketPC Desempenho do JMF vs RealPlayer BROWSER + REALPLAYER JAVA + JMF JAVA + REALPLAYER HELIX STREAMING SERVER INTEGRAÇÃO COM O PROJECTO SSNT-SERVICE...49 iv

7 Relatório de TFC nº224 Sistemas de distribuição de notícias multimédia para dispositivos móveis 4.10 DESCRIÇÃO DO TRABALHO REALIZADO CAP.5 INTERFACE MULTIMODAL COM FALA TECNOLOGIAS EXISTENTES VOICEXML XHTML+VOICE AUDIMUS O RECONHECIMENTO DE FALA NO APLICAÇÃO DESENVOLVIDA TRABALHO REALIZADO CAPITULO 6- DESCRIÇÃO DO SERVIÇO / TESTES O SERVIÇO DE MATCHING A PESQUISA DIRECTA NA BASE DE DADOS COMANDOS DE VOZ A CODIFICAÇÃO DO VÍDEO TESTES DO RECONHECEDOR EM DIFERENTES AMBIENTES: TESTES COM VÁRIOS ORADORES RESULTADOS ALCANÇADOS CONSIDERAÇÕES FINAIS O PROJECTO REALIZADO LIMITAÇÕES E TESTES AO SERVIÇO DESENVOLVIMENTOS FUTUROS NOTA FINAL...75 BIBLIOGRAFIA...76 Carlos Bandeirinha, Diogo Areia v

8 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 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 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 IPAQ H FIGURA 3.11 CONSOLA DO JEODE...33 FIGURA 3.12 CONSOLA DO CREME...33 FIGURA CONSOLA DO J 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 VÍDEO CODIFICADO COM O CINEPAK...46 FIGURA RUNTIME.EXEC()...48 FIGURA 4.17 SOLUÇÃO JAVA +REALPLAYER...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

9 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

10 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

11 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

12 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

13 Relatório de TFC nº224 Sistemas de distribuição de notícias multimédia para dispositivos móveis 1 Introdução 1.1 Á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

14 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

15 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

16 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

17 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 SSNT 1, 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 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 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

18 ALERT / SSNT-Service Clientes registados Captura Processamento 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

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

20 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

21 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 Apache ou Jetty Na escolha do servidor Web considerámos duas soluções : Apache/Tomcat HTTP Server 1 e Jetty HTTP Server 2. 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 Carlos Bandeirinha, Diogo Areia 9

22 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 license 1, 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 XML 2 : Figura 2.2 -Estrutura do XML O DTD deste ficheiro encontra-se no anexo A 10

23 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 DOM 2 ( 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 XPath 3 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: Carlos Bandeirinha, Diogo Areia 11

24 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: 4Suite, 4Suite Server 1 Berkeley DB XML 2 DBDOM 3 dbxml exist 4 myxmldb 5 Ozone 6 XDBM 7 XDB 8 Xindice 9 XpSQL 10 Sedna XML DBMS 1 1, http ://sourceforge.net/projects/xdbm/

25 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 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 é Tamanho máximo de cada documento armazenado depende do número de nós que este possui, no máximo pode ter 2 63 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 Carlos Bandeirinha, Diogo Areia 13

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

27 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 XQuery 1.(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 Carlos Bandeirinha, Diogo Areia 15

28 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

29 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

30 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 MySQL 1 ( 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 Hibernate 2, 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:

31 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

32 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

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

34 pedidos á base de dados. Os resultados da pesquisa são devolvidos ao cliente outra vez via HTTP 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

35 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 J2ME 1 é 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 Process 2 (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 Java 2 Platform Micro Edition 2 Carlos Bandeirinha, Diogo Areia 23

36 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 Profile 1 (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 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

37 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 Profile 1 (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 Carlos Bandeirinha, Diogo Areia 25

38 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

39 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 Toolkit 1 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 API 2 (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 Carlos Bandeirinha, Diogo Areia 27

40 partir de diversas origens. A MMAPI já é suportada pela maioria dos dispositivos que suportam a MIDP. A MMAPI, definida pela JSR 1 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

41 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 = " 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 WML 1 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

42 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

43 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 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 Ipaq H 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 Java 1 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 Developer 2 é 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 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 Carlos Bandeirinha, Diogo Areia 31

44 Existe também máquinas virtuais de Java desenvolvidas por empresas privadas. O creme da NSICom 1 é 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 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 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 Esmertec 2 e o nome da máquina mudou para JBED. Actualmente este produto não é vendido directamente ao publico mas apenas a empresas. O Mysaifu 3 é 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 É 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

45 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 rumores 1 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, Carlos Bandeirinha, Diogo Areia 33

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

47 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 Classes 1 (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 Carlos Bandeirinha, Diogo Areia 35

48 Figura 4.1-Componentes do AWT Figura 4.2 Layouts do AWT 36

49 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

50 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

51 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

52 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

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

54 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

55 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 PocketPc 1. 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 UDP 2, ao contrário do HTTP que funciona em cima do TCP 3. 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 Java Media Framework O Java Media Framework 4 é 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, MPEG- 2, 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 User Datagram Protocol 3 Transmission Control Protocol 4 Carlos Bandeirinha, Diogo Areia 43

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

57 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 PXA Mhz, 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 Cross Platform Version AVI(.avi) Read/Write Audio: A-law D Audio:DVI ADPCM compressed D/E Video:Cinepak D QuickTime (.mov) read/write Audio: A-law D Audio: IMA4 ADPCM D,E Video:Cinepak D Video: H 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

58 tabela 4.2 Requisitos de CPU e largura de banda dos codecs Codec Format Quality CPU Requirements Bandwidth Requirements Cinepak AVI QuickTime Medium Low High H.263 QuickTime AVI RTP Medium Medium Low PCM AVI QuickTime WAV High Low 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 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

59 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 SMIL 1, tentámos entrar em contacto com a RealNetworks 2 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 Synchronized Multimedia Integration Language ( 2 Carlos Bandeirinha, Diogo Areia 47

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

61 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 Server 1, que suporta os três principais formatos de streaming: Windows Media, QuickTime, Real vídeo, MPEG-1, MPEG- 2, 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 Carlos Bandeirinha, Diogo Areia 49

62 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

63 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

64 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 PDsay 2 da ScanSoft é um desses programas

65 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 ViaVoice 1, 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 2 para o ipaq com o PocketPc2002 e o Fonix da Voiceln Carlos Bandeirinha, Diogo Areia 53

66 5.2 VoiceXML O VoiceXML 1 é o nome da tecnologia standard desenvolvida e controlada pelo Fórum VoiceXML 2.Esta tecnologia foi construída na sequencia de outros projectos como o VoXML 3 da Motorola e o SpeechML 4 da 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

67 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

68 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 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 toolkit 2 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 Access 3 e o Opera 4 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

69 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

70 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

71 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 (EOS 1 ), 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

72 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

73 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 SSNT 1. As figuras 6.2, 6.3 e 6.4 mostram o aspecto deste website Carlos Bandeirinha, Diogo Areia 61

74 Figura 6.2 A página de entrada do Website SSNT Figura 6.3 A página de registo do utilizador 62

75 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 Outlook 1, para receber os s com a descrição das noticias encontradas de acordo com o perfil desejado, no entanto, os s 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 s presente no Windows Mobile, Carlos Bandeirinha, Diogo Areia 63

76 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

77 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

78 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

79 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

80 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

81 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 Carlos Bandeirinha, Diogo Areia 69

82 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