MPEG-J Application. java.lang java.io java.util MPEG-J APIs. Application Engine JVM BIFS, Presentation Engine. Áudio, visual, MPEG-J...

Transcrição

1 MPEG-J e JMF Resumo MPEG-J é um sistema MPEG-4 programável. Prove a possibilidade de adaptação da aplicação de acordo com a capacidade computacional e os recursos disponíveis no terminal. O objetivo do MPEG-J é definir um motor de aplicação Java (complementando o motor de apresentação) que especifica como as aplicações estarão contidas nos fluxos de bits (enviadas ao terminal MPEGlets - ou presentes no mesmo) e serão executadas nos terminais. Para possibilitar a comunicação com o MPEG-4 player, novas APIs especificas para MPEG-4 são definidas: Terminal, Scene, Resource, Decoder e Network. MPEG-J é também utilizado em ambientes interativos. O JMF é um conjunto de três novas API s co-definidas pelo JMF Working Group Sun, Silicon Graphics, e Intel. Esses API s incluem o Java Media Player, Capture, e Conferencing. A API especificada para o Player fornece um arcabouço para desenvolvedores construírem media players sob a forma de plataformas Java padronizadas. A especificação JMF é flexível o suficiente para permitir aos desenvolvedores estenderem seus players adicionando suas próprias características (como filtros de imagem, efeitos de áudio reverb, e outros) ou para usarem os players padrões já disponíveis sem fazer maiores adições. 1

2 MPEG-J 1 Introdução A capacidade computacional e recursos (de rede ou outros) disponíveis nos terminais MPEG-4 pode diferir consideravelmente. Com o uso do MPEG-J é possível abstrair as diferenças existentes através da criação de uma única aplicação, tornando difícil a percepção das limitações de um terminal que decodifica áudio e vídeo e um terminal que processa um programa computacional. Esse é o objetivo do MPEG-J; prover uma oportunidade para controlar apresentações audiovisuais através de programas que podem tomar decisões complexas e modificar a forma de apresentação baseada nas condições dos terminais dos clientes. Podemos citar, por exemplo, a associação do comportamento de uma cena baseada em algoritmos complexos relacionando partes da mesma a rotinas escritas em linguagem programável. A utilização de programas computacionais permite que lógicas complexas sejam utilizadas para detectar condições estáticas e dinâmicas (temporais) em cada terminal. Por exemplo, o programa é capaz de discernir a capacidade de um PDA e um Desktop e detectar condições extremas, tais como problemas de retardo na rede ou declínio da disponibilidade computacional. O sistema MPEG-4 especifica ferramentas de codificação para objetos de áudio e vídeo. A parte padrão do sistema MPEG-4 [1] especifica como esses objetos, codificados em fluxo de bits elementares, estão posicionados e sincronizados com outros objetos, chamada de motor de apresentação no MPEG-4. O objetivo do MPEG-J é adicionar ao motor de apresentação um motor de aplicação que possa associar comportamentos complexos baseados nas condições do terminal do usuário. Os principais requerimentos para esse motor de aplicação seriam: 1. Habilidade para executar programas ou aplicações computacionais de códigos compilados; 2. Habilidade para rodar o mesmo código em diferentes plataformas de hardwares e softwares disponíveis no terminal; 2

3 3. Um modelo de segurança bem definido; 4. Habilidade para rodar múltiplas aplicações simultaneamente sem conflitos; 5. Mecanismo para notificar e manusear, se necessário, condições drásticas ou excepcionais; 6. Disponibilidade de interfaces para detectar informações estáticas e dinâmicas com relação ao ambiente do terminal, capacidade computacional e largura de banda da rede. 7. Disponibilidade de interfaces para obter informação sobre a apresentação: objetos nas cenas, fluxos elementares, decodificadores, entre outros; 8. Disponibilidade de interfaces que possam ser usadas pelo programa para acessar, modificar ou, até mesmo, criar partes da apresentação; 9. Facilidade de escrita. A linguagem de programação Java satisfaz esses requerimentos, além de ser orientada a objetos e amplamente divulgada, disponibilizando recursos que facilitam a criação da aplicação. Estas foram as principais razões que levaram a escolha de Java no MPEG e da Máquina Virtual Java (JVM) como plataforma para executar as aplicações Java mos terminais MPEG-J. Para rodar as aplicações escritas em Java, é necessário que terminais possuam uma implementação de JVM. O byte code Java compilado será interpretado pela JVM, possibilitando a execução da aplicação sem a necessidade de uma nova recompilação ou qualquer mudança específica na plataforma. O objetivo do MPEG-J é definir um motor de aplicação Java (complementando o motor de apresentação) que especifica como as aplicações estarão contidas nos fluxos de bits e serão executadas nos terminais. Para isso, MPEG-J define um conjunto de APIs (Application Programming Interface) que permitem a interação da aplicação com o terminal e seu ambiente. MPEG-J também define a forma de distribuição da aplicação no terminal, seu escopo, ciclo de vida e restrições de segurança. Deve-se notar que a linguagem Java é composta de um conjunto de classes que são compiladas para uma linguagem intermediária denominada byte code e que cada classe tem uma ou mais instancias denominadas objetos. Um mecanismo de distribuição é definido pelo MPEG-J para carregar o Java byte code (classes) e objetos Java (esses objetos são diferentes dos 3

4 objetos audiovisuais nos grafos das cenas) que faz uma aplicação MPEG-J. O ciclo de vida e escopo de uma aplicação MPEG-J são definidos dentro de um padrão junto com rígidos modelos de segurança, que protegem os terminais MPEG-4 de aplicações maliciosas. Conforme dito anteriormente, MPEG-J define um conjunto de APIs Java para acessar e controlar a base do terminal MPEG-4 que reproduz uma sessão audiovisual. Nesse caso, uma interface é uma função ou chamada a um procedimento que possa ser feito pelo programa. Aplicações MPEG-J que usam essas APIs podem estar embutidas no conteúdo como um fluxo elementar MPEG-J similar aos fluxos de áudio e vídeo. Essas aplicações transportadas com o fluxo de dados são denominadas MPEGlet. A figura 1 mostra o diagrama de uma MPEG-J num terminal MPEG-4. MPEG-J Application java.lang java.io java.util MPEG-J APIs Application Engine JVM BIFS, Áudio, visual, MPEG-J... Presentation Engine Execution Engine Fig. 1.1 MPEG-J application Engine BIFS define o formato binário para a descrição da cena. Isso é usado para a construção e apresentação da cena, uma vez que BIFS descreve o relacionamento espaçotemporal dos objetos audiovisuais nas cenas. A parte do terminal que interpreta BIFS, seus fluxos e sua composição e os apresenta é denominada motor de apresentação. O motor de execução descomprime os fluxos audiovisuais codificados. MPEG-J define o motor de aplicação, o qual oferece acesso programático e controle dos motores de apresentação e execução. Especificamente, MPEG-J permite a uma aplicação acessar e modificar uma 4

5 cena e, numa extensão limitada, os recursos de rede e do decodificador do terminal. As APIs MPEG-J, juntamente com a JVM formam o motor de aplicação que facilitam a execução e distribuição de aplicações. Este motor permite a inclusão de programas por desenvolvedores, que inteligentemente controlam o terminal MPEG-4 de acordo com as condições do mesmo. Uma vez que os programas MPEG-J (MPEGlets) são geralmente transportados separadamente, eles podem ser reutilizados por outras cenas audiovisuais. Isso também é possível para programas residentes no terminal, contanto que eles sejam escritos de forma independente da cena e dos fluxos elementares associados com ele. Alguns exemplos de adaptação da cena aos recursos do terminal conforme suas condições são: 1. Ao invés de degradar uma cena inteira quando os recursos estão baixos, um objeto de vídeo de menor prioridade pode ser substituído por um retrato; 2. Qualquer que seja o terminal (um PDA, um telefone móvel, um PC antigo ou um top de linha), o vídeo ao ser reproduzido adapta-se as condições do ambiente. Por exemplo, o mesmo conteúdo usa cinco canais estéreos de áudio de alta qualidade ou um único canal de baixa qualidade mono de áudio conforme o dispositivo de recepção. Essa adaptação também pode ser realizada baseada nas preferências do usuário. 3. Um vídeo educacional é transmitido para usuários de PC ou handhelds. Após a conclusão de cada capítulo, perguntas são administradas. O nível de dificuldade varia baseada nas respostas dos participantes. 2- Arquitetura MPEG-J A figura 2 mostra uma arquitetura simplificada de um player MPEG-4 como especificado no MPEG-4 Systems, Versão 1 [1]. Os dados BIFS contidos no fluxo elementar BIFS juntamente com os descritores de objetos (OD) nos fluxos OD são usados para construir o grafo das cenas a associar os nós dos grafos com os correspondentes fluxos audiovisuais. O decodificador BIFS é usado para decodificar a informação de descrição da 5

6 cena. Os dados da mídia decodificados são armazenados nos composition buffers que alimentam o compositor e renderizador. Composition é a ato de reconstruir espacialmente a cena dos objetos usando a informação de descrição da cena. Rendering é o ato de desenhar / apresentar uma cena. Control Data DMIF BIFS/OD Decoder Scene Graph Back Channel D E M U X BIFS and OD Streams Decoding Buffers 1...n Media Decoders Composition Buffers 1...n Compositor and Renderer Channel Figura 1.2 Arquitetura MPEG-4 player simplificada A arquitetura do MPEG-J para MPEG-4 player é mostrada na figura 3 [2], abaixo. Net API Scene API Resource API MPEG-J Stream Fig.1.3 Arquitetura MPEG-J 6

7 O motor de apresentação do Sistema MPEG-4, versão 1, corresponde a parte mais baixa da figura 3. O motor de aplicação do MPEG-J (parte superior da figura) é usada para controlar ao motor de apresentação através da execução de aplicações bem definidas e mecanismos de distribuição [3]. A aplicação MPEG-J usa as MPEG-J APIs para esse controle. As aplicações podem ser locais ao terminal ou transportadas no fluxo MPEG-J e executadas no terminal. Enquanto o termo MPEGlet faz referência ao programa MPEG-J enviado ao terminal, um programa local é genericamente chamado aplicação MPEG-J [2]. MPEGlets são requeridos para implementar a interface MPEGlet definida na especificação MPEG-J [2]. As MPEGlets e todas as classes e objetos MPEG-J são transportados no fluxo elementar MPEG-J. Cada MPEGlet recebido é carregado pelo class loader (vide figura 3) e iniciado em instantes de tempo prescritos pelo time stamps do fluxo MPEG-J. A aplicação MPEG-J utiliza os gerenciadores de cena, rede e recursos para controlar a cena, rede e recursos do terminal, respectivamente, além de decodificadores. Na figura 3, os fluxos de dados são as linhas contínuas e os de controle as tracejadas. Uma sessão MPEG-J é iniciada quando um player MPEG-4 recebe um MPEG-J OD. O decodificador MPEG-J (composto pelo buffer, class loader e implementações de APIs) manuseia as classes e objetos que chegam. Pode haver mais de um MPEGlet em um fluxo MPEG-J. Cada classe recebida é carregada em instantes de tempo especificados pelos seus time stamps. Quando um MPEGlet é recebido pelo decodificador, ele realiza as iniciações prescritas e o executa como uma thread separada no terminal MPEGlets Particularmente, o termo MPEGlet é utilizado para aplicações que são enviadas ao terminal. Entretanto, a maioria dos conceitos definidos nesta parte são aplicados tanto para os MPEGlets como às aplicações locais. Como MPEG-J permite aos programas serem enviados e executados num terminal MPEG-4, se torna necessário definir um conjunto de regras para a execução dos programas: MPEGlets, no caso. 7

8 2.1.1 Life Cycle Depois que um MPEGlet é recebido, o terminal precisa saber exatamente como ele tem que executá-lo. Para esse propósito, a especificação MPEG-J define o life cycle de um MPEGlet. A interface MPEGlet define quatro métodos (funções), nomeadas de: init(), run(), stop(), e destroy(). O life cycle e os estados dos MPEGlets estão implicitamente definidos por esses métodos dentro da interface. O autor de um MPEGlet deve escrever o código apropriado para todos os métodos definidos numa interface MPEGlet. Todos os recursos de inicialização formam o método init(), enquanto a recuperação dos mesmos recursos formam o método destroy(). O método run() será executado como uma nova thread e conterá todos os mecanismos de controle de algoritmos para controlar o terminal MPEG-4. Além disso, o autor deve colocar todos os códigos para parar o MPEGlet mo método stop(). Uma vez construído os códigos, o autor deve compilá-lo para gerar uma classe (Java class) de saída do MPEGlet. Essa classe seria então distribuída para o terminal. Quando recebida por este, será carregada conforme seu time stamp. Adicionalmente, o terminal pode determinar se a classe implementa a interface MPEGlet através de chamadas de funções primitivas. Isso determina se uma dada classe é uma aplicação MPEG-J ou uma classe suportada Name Scope Para garantir eu não hajam conflitos de nomes nas aplicações MPEG-J, o escopo do nome tem que ser definido. Por exemplo, duas classe usando o mesmo nome ou duas MPEGlets com o mesmo nome causariam problemas de execução. O OD define o escopo do nome de objetos audiovisuais numa cena MPEG-4. Isso também se aplica as classes e objetos MPEG-J. Todos os identificadores são interpretados no escopo de nomes dos fluxos MPEG-J e seus OD.Os gerenciadores mostrados na figura 3 estabelecem o nome de MPEGlet pela identificação do seu descritor de objeto. Na prática, isso é feito usando a referência do MPEGlet passada no construtor 1 do terminal MpegjTerminal, uma classe específica definida entre as APIs MPEG-J. 8

9 O seguinte fragmento de código mostra um exemplo de um MPEGlet passando sua própria referência enquanto cria o objeto MpegjTerminal: public class SceneExample implements MPEGlet { MpegjTerminal mpegjterminal; Public void init() { mpegjterminal = new MpegjTerminal (this); [...] Embora o MPEGlet tenha que passar uma referência para si próprio no construtor, uma aplicação local pode usar o construtor de argumento zero do terminal para indicar a raiz do escopo do nome. Como no seguinte exemplo: public class AtlanticDemo extends WindowAdapter { MpegjTerminal MpegjTerminal = new MpegjTerminal (); [...] 2.2 Distribuição Tipicamente, os mecanismos pelo qual os programas são distribuídos para os terminais que os executam são muito diferentes da forma que isso é feito para os dados audiovisuais. A especificação MPEG-J define os mecanismos para transportar os dados MPEG-J usando os mecanismos de entrega definidos para os dados audiovisuais do MPEG Semântica Time Stamp Os dados audiovisuais MPEG-4 carregam dois tipos de marcas de tempo. Um deles é o tempo no qual o decodificador deve começar a decodificar uma unidade de acesso 9

10 chamado de Decoding Time Stamps (DTS). Similarmente, a Composition Time Stamps (CTS) é o instante de tempo no qual o dado descomprimido tem que ser formado na cena para apresentação. Para o MPEG-J, esse par de time stamp não tem um significado direto. Então, a especificação MPEG-J define novas semânticas para o DTS e CTS Dependência de classe MPEGlets podem usar chamadas (funções) APIs que estão definidas dentro de uma classe Java dentro da plataforma (java.io, Java.util, Java.lang) ou em uma especificação MPEG-J [AMD1-1]. Uma aplicação especifica uma classe que, por sua vez usa chamadas API definidas em classe aplicação específica. Um terminal deve iniciar uma classe somente depois que todas as classe que ela depende forem carregadas Fluxo Elementar MPEG-J O dado MPEG-J é enviado par o terminal MPEG-J como um fluxo elementar. Todos os arquivos de classes que dependem uns dos outros e constituem uma aplicação MPEG-J junto com os objetos de dados podem ser empacotados como uma unidade de acesso simples. O formato do pacote usado para isso é o formato zip ou o formato de pacote JAR suportado pelo Java. MPEG-J adiciona um pequeno cabeçalho às classes e objetos Java, além do pacote JAR que constituem uma simples unidade de acesso. Esse cabeçalho é usado para especificar a identificação, tipo, compressão, pacote e informação de dependência de classe. Todas essas informações são utilizadas pelo decodificador MPEG-J para a correta decodificação das classes e seu tempo correto de execução Segurança A especificação MPEG-J define um modelo de segurança para MPEGlets [2] que é similar ao modelo para JAVA applets. O modelo de segurança MPEG-J protege o terminal 10

11 MPEG-4 de programas maliciosos. Um gerenciador de segurança tem que ser implementado no terminal MPEG-J para assegurar as seguintes restrições de segurança: 1. MPEGlets são proibidos de carregarem bibliotecas ou definir métodos nativos; 2. MPEGlets não podem ler ou escrever arquivos no terminal; 3. Iniciar um programa e ler certas propriedades do sistema é proibido; 4. MPEGlets podem usar somente seu próprio código Java, APIs MPEG-J, APIs Java fornecidas pelo ambiente de execução e as classes que foram carregadas do fluxo MPEG-J. 3 APIs MPEG-J Foi visto que MPEGlets podem fazer chamadas API que estão definidas nos pacotes Java suportados pela plataforma. Para os familiarizados com pacotes Java, Java.io, Java.utils, e Java.lang são três pacotes Java que têm que ser suportados pela plataforma Java presente no terminal. Enquanto pacotes Java provêm algumas características genéricas, as APIs MPEG-J suportam as características que são especificas para as aplicações MPEG-J. As APIs MPEG-J complementam as APIs da plataforma Java para encontrar os requerimentos das aplicações MPEG-J. Os algoritmos embutidos nos MPEGlets são implementados usando as interfaces definidas pela especificação MPEG-J. Usando as APIs MPEG-J, as aplicações têm acesso programático às cenas, terminal, e recursos de rede. As MPEGlets usam as APIs MPEG-J para perceber o ambiente do terminal e modificar cenas audiovisuais. MPEG-J define uma variedade de categorias de APIs. Cada categoria prove uma funcionalidade especifica e é organizada como um pacote Java. Os seguintes pacotes são definidos na especificação MPEG-J [2]: org.iso.mpeg.mpegj org.iso.mpeg.mpegj.scene org.iso.mpeg.mpegj.resource org.iso.mpeg.mpegj.decoder 11

12 org.iso.mpeg.mpegj.net Além disso, MPEG-J faz referência apara algumas APIs já definidas nas especificações DAVIC (Digital Audiovisual Council), em outras palavras, Service Information and Section Filtering [4]. O pacote org.iso.mpeg.mpegj é uma coleção de todas as classes e interfaces necessárias ao desenvolvimento de uma sessão pelo MPEGlet. Essas classes e interfaces definidas pelo pacote acima são denominadas Terminal APIs. Este fornece um MPEGlet com um primeiro ponto de acesso para o terminal. As duas principais interfaces definidas neste pacote são: a MPEGlet e a MpegjTerminal. O pacote org.iso.mpeg.mpegj.scene é a coleção de todas as classes e interfaces definidas pela especificação MPEG-J através das quais os objetos audiovisuais da cena MPEG-4 podem ser acessados e modificados. Esse pacote contém interfaces de baixo nível para acessar e modificar os nós do grafo das cenas correspondentes a uma apresentação MPEG-4. Essas interfaces constituem as Scene SPIs. Através delas, as cenas podem ser alteradas baseado em algoritmos que podem reagir de forma complexa com o ambiente do terminal ou ações de usuários. O pacote org.iso.mpeg.mpegj.resource contém todas as classes e interfaces necessárias para monitorar os recursos estáticos e dinâmicos no terminal. Eles são referidos como Resource APIs. O pacote org.iso.mpeg.mpegj.decoder consiste de todas as classes e interfaces necessárias para controlar o recurso do decodificador no terminal. As Decoder APIs definem a interface decoder e provê o meio para controlar o decodificador. O pacote org.iso.mpeg.mpegj.net contém um conjunto de interfaces de alto nível, chamadas Net ou Network APIs, para um simples controle dos canais da rede associados ao terminal MPEG-J. Através dessa APIs, uma aplicação pode indagar ao terminal sobre sessões, canais, qualidade de serviço, entre outros. MPEG-J também faz referencia a Service Information, Section Filtering, Resource Notification e MPEG Component APIs especificadas por DAVIC [4]. Essas APIs são relevantes somente quando os dados MPEG-4 são transportados sobre sistemas MPEG-2 12

13 [5], uma vez que são usadas para acessar informação nos fluxos de transporte desses sistemas. O fluxo do sistema MPEG-2 podem conter as tabelas de Informação de Serviços definidas pelo Digital Vídeo Broadcasting (DVB) Consortium [6]. 4 Cenários de aplicação Como MPEG-J usa Java, as possíveis aplicações são limitadas apenas pelo desempenho dos desenvolvedores.o real desafio é o desenvolvimento de ferramentas inteligentes para a criação de conteúdo MPEG-J. Em ambientes no qual diferentes dispositivos, com diferentes capacidades, e redes sem fio (GSM, GPRS, UMTS) coexistem, os provedores de conteúdo podem querer decidir as partes essenciais das mensagens que querem transmitir. Sem MPEG-J, essa decisão teria que ser feita pelo terminal ou um gateway entre o servidor e o terminal. Muitos programas de TV que utilizam informação multimídia interativa podem se beneficiar de MPEG-J. Por exemplo, pode ser dados aos usuários de TV a possibilidade de resposta a questões mostradas na apresentação. No fim, as respostas podem ser avaliadas. Um ambiente seguro com autenticação (através de um cana de retorno), pode ser necessário para fazê-lo seguro. Podemos concluir que MPEG-J é o principal passo em direção à distribuição de conteúdo inteligente e interativo. MPEG-J fornece as ferramentas necessárias para produção pelos desenvolvedores de conteúdos MPEG-4 cada vez mais interessantes. 13

14 JMF Introdução O JMF (Java Media Framework) fornece uma arquitetura unificada e um protocolo de mensagens que controlam a aquisição, processamento e a entrega de dados multimídias. JMF é projetado suportar a maioria dos tipos de mídias padronizados, tais como o AIFF, AU, AVI, GSM, MIDI, MPEG, QuickTime, RMF e o WAV. Explorando as vantagens da plataforma Java, JMF promete, aos desenvolvedores que querem usar mídias como áudio e vídeo em seu programa Java, que "uma vez escrito o programa ele funcionará em qualquer lugar". JMF fornece uma Java API comum para estruturas de acesso básico as mídias. As implementações de JMF podem alavancar as potencialidades do sistema operacional, enquanto os desenvolvedores podem facilmente criar programas com portabilidade para mídias continuas escrevendo uma JMF API. Com o JMF, você pode facilmente criar applets e as aplicações que apresentam, capturam, manipulam e armazenam mídias continuas. O framework permite a desenvolvedores avançados e provedores de tecnologia a realizar o processamento de dados crus das midias e de estender ao JMF o suporte a tipos e formatos adicionais, otimizar a manipulação de formatos já suportados, e criar mecanismos novos da apresentação. JMF é uma API desenvolvida pela Sun Microsystems para incorporar multimídia em applets e aplicações Java. Com este pacote podemos capturar, gravar e apresentar arquivos multimídia, independentemente da plataforma usada. O JMF 2.0 define uma classe plugin que habilita desenvolvedores a estender a funcionalidade do JMF. A arquitetura do JMF esta dividida em: Data source Capture device Player Processor DataSink Format Manager 14

15 Data source é uma stream, que pode ser, somente de vídeo, somente de audio, ou a combinação dos dois. Depois de criado, você não precisa saber onde se encontra a mídia, nem qual é o protocolo usado, pois o data source cuida disto. Uma vez criado, este pode alimentar o player para ser renderizado, com o player não precisando saber qual é a forma da mídia. A mídia pode vir de varias fontes, como por exemplo arquivos de uma rede, ou arquivos de internet. Capture device representa o hardware de captura, como por exemplo microfone, ou câmera de vídeo. Um Player tem como entrada uma stream de audio ou vídeo e renderiza isto ou nos alto-falantes ou no vídeo, ou em ambos. Um player logicamente tem estados, por exemplo parado, ligado, etc. Processor é um tipo de player, na API do JMF, um processor estende o player. Assim o processor tem os mesmos controles que um player. Mas diferente de um player, o processor tem controle sobre qual processamento é feito na stream de entrada. Alem de renderizar o data source, o processor pode ter como saída uma media, que por sua vez pode entrar em outro player ou processor, assim por diante. O DataSink é a interface que lê a mídia do DataSource e renderiza em algum destino, por exemplo um arquivo. Format representa o exato formato da mídia, não carregando parâmetros específicos de codificação. Subclasses podem ser audioformat ou videoformat. Manager é um objeto intermediário, que interfaceia dois objetos diferentes, como por exemplo, com o manager você pode criar um player a partir de um DataSource. Depois de criado um player você já pode processar os dados deste, existe para este fim, uma classe plugin, que pode processar o dado de entrada e entregar o dado de saída modificado para ser renderizado no vídeo, ou então entregue para outro plugin. Arquitetura de Alto - Nível Dispositivos como fita cassete e VCRs fornecem um modelo familiar para a gravação, processamento e apresentação das mídias contínuas. Quando você reproduz um filme 15

16 usando um VCR, você fornece os fluxos de dados ao VCR introduzindo uma fita de vídeo. O VCR lê e interpreta os dados emite sinais apropriados à televisão e alto-falantes. Figura 1: Gravando, processando, e apresentando mídias temporais. JMF usa este mesmo modelo básico. Uma fonte de dados encapsula os mesmos como uma fita de vídeo, e um tocador fornece os mecanismos de processamento e controle similares a um VCR. Reprodutores de áudio e vídeo com JMF requerem dispositivos de entrada e saída apropriados, como microfones, câmeras, alto-falantes, e monitores. As origens dos dados e os reprodutores são partes integrais do API high-level de JMF para controlar a captação, apresentação e processamento das mídias contínuas. JMF fornece também um API lower-level que suporta a integração entre componentes de processamento e extensões. Essa estrutura em camadas permite aos desenvolvedores Java a incorporação de mídias contínuas em programas Java através de uma API simples ao mesmo tempo em que mantém a flexibilidade requerida para suportar aplicações multimídias avançadas e tecnologias futuras Figura 2: Arquitetura de alto Nivel do JMF. 16

17 Modelo Do Tempo JMF mantém a precisão do tempo em nanossegundo. Um ponto particular do tempo é representado tipicamente por um objeto Time, embora algumas classes suportem também a especificação de tempo em nanossegundos. Classes que suportam do modelo do tempo de JMF, implementam o instrumento Clock para se manter síncrono com a mídia. A interface Clock define o tempo básico e as operações de sincronismo que são requeridas para controlar a apresentação dos dados Figura 3: Modelo do tempo de JMF. O Clock usa uma base de tempo para manter-se síncrona conforme o fluxo de dados vai sendo apresentado. A única informação que o TimeBase fornece é seu tempo atual, que é consultado como tempo time-base. O tempo do time-base não pode ser parado ou reiniciado e é freqüentemente baseado no relógio do sistema. O media time representa a posição atual dos dados da mídia -- o começo do dado é o tempo mídia zero, e o fim do fluxo é o tempo máximo da mídia. A duração do fluxo de dados é o é o tempo decorrido do começo ao fim -- o intervalo de tempo que leva para apresentar a mídia. Para manter-se a par do tempo atual dos meios, o Clock usa: O início do tempo do time-base esse tempo usa relatórios TimeBase quando a apresentação começar. O início do tempo das mídias - a posição nos mídias onde a apresentação começa. 17

18 A taxa do playback -- como o clock está funcionando com relação ao seu TimeBase. A taxa é um fator de escala que deve ser aplicado se. Para o exemplo, uma taxa de 1.0 representa a taxa normal do playback para as mídias em apresentação. Quando uma taxa de 2.0 é requerida, isso indicará que a apresentação deverá funcionar duas vezes a mais que a taxa normal. Uma taxa negativa indica que o clock está funcionando no sentido contrário do seu time base. Por exemplo, uma taxa negativa pode ser usada para jogar o fluxo da mídia para trás. Quando a apresentação começa, o tempo dos midias mapeado para o time-base e o avanço do tempo dele é usado medir a passagem do tempo. Durante a apresentação, o tempo atual das mídias é calculado usando a seguinte fórmula: MediaTime = MediaStartTime + Rate(TimeBaseTime - TimeBaseStartTime) Quando a apresentação pára, o tempo dos midias pára, mas o tempo do time-base continua a avançar. Se a apresentação for reiniciada, o tempo das mídias é remapeado para o tempo atual do time-base. Gerenciadores O JMF API consiste principalmente de interfaces que definem o comportamento e a interação dos objetos usados para capturar, processar, e apresentar mídias temporais. As implementações dessas interfaces operam dentro da estrutura do framework. Por intermédio do uso de objetos chamados gerenciadores, JMF permite facilmente integrar novas implementações de interfaces que podem ser usadas com classes já existentes. JMF usa quatro gerentes: Manager - negocia a construção de Players Processors, DataSources, e DataSinks. Ele permite que novas implementações sejam integradas perfeitamente com JMF. Do ponto de vista do usuário, estes objetos são criados sempre da mesma maneira, quer o objeto pedido seja construído de uma implementação default ou qualquer outra. 18

19 PackageManager - mantém um registro dos pacotes que contêm classes de JMF, tais como Players habituais, Processors, DataSources e DataSinks. CaptureDeviceManager - mantém um registro de dispositivos disponíveis da captura. PlugInManager - mantém um registro de plug-in processadores de componentes JMF disponíveis, como Multiplexers Demultiplexers, Codecs Effects, e Renderers. Para escrever os programas baseados em JMF, você necessitará usar os métodos do Manager create para construir Players Processors, DataSources, e DataSinks para sua aplicação. Se você estiver capturando dados multimídia de um dispositivo de entrada, você deverá usar CaptureDeviceManager para descobrir quais dispositivos estão disponíveis e obter informação sobre eles. Se você estiver interessado em controlar o que o processador está realizando sobre os dados, você pode também pedir ao PlugInManager para determinar quais plug-ins foram registrados. Se você estender a funcionalidade de JMF para implementação de um novo plug-in, você pode registrá-lo com PlugInManager para torná-lo disponível os Processors que suportam o plug-in API. Para usá-lo um costume Player Processor, DataSource, ou DataSink com JMF, deve se registrar seu prefixo original de pacote com o PackageManager. Modelo Do Evento JMF usa um evento estruturado que relata o mecanismo de sustento aos programas, informando o estado atual do sistema de mídias, permitindo aos programas responderem às condições de erro provenientes das mídias. Como, por exemplo, dados mal estruturados e falta de recursos. Sempre que um objeto de JMF necessita relatar as circunstâncias atuais, ele afixa um MediaEvent. MediaEvent é uma subclasse criada para identificar tipos particulares de eventos. Esses objetos seguem as padronizações estabelecidas pelos eventos de Java beans. Para cada tipo de objeto do JMF que pode afixar MediaEvents, JMF define uma relação correspondente do listener. Para receber a notificação quando o MediaEvent é 19

20 afixado, deve-se executar a relação apropriada do listener e registrar a sua classe com o objeto que afixou o evento (isso é feito chamando seu método add). Figura 4: Modelo do evento de JMF. Modelo Dos Dados Os players da mídia de JMF usam geralmente DataSources para controlar a transferência do índice da media. Um DataSource encapsula a posição das mídias, o protocolo e o software usados entregá-las. Uma vez que acessada, a fonte não pode ser reutilizada. Um DataSource é identificado por um JMF MediaLocator ou por a URL (localizador universal do recurso). A MediaLocator é similar a uma URL e pode ser construído de uma URL, e pode ser construído mesmo se o alimentador correspondente do protocolo não é instalado no sistema. (em Java, a URL pode somente ser construído se o alimentador correspondente do protocolo for instalado no sistema.) Um DataSource controla o player SourceStream dos objetos. Uma origem dos dados de padrão usa uma disposição do byte como a unidade de transferência. Uma origem dos dados usa Buffer um objeto como sua unidade de transferência. JMF define diversos tipos DataSource de objetos: 20

21 Figura 5: Modelo dos dados de JMF. Entrada e saída dos dados Os dados das mídias podem ser obtidos de uma variedade de fontes, tais como mídias estáticas (gravadas em disco rígido, por exemplo) ou da rede através de transmissão de tempo real. A origens dos dados de JMF podem ser categorizadas de acordo como é iniciada a transferência de dados: Fonte de dados de tração-- o cliente inicia transferência de dados e controla o fluxo na origem. Os protocolos estabelecidos para este tipo de dados incluem o protocolo de transferência de hypertext (HTTP). JMF define dois tipos de origens para dados de tração: PullDataSource e PullBufferDataSource, que usam um objeto Buffer como unidade de transferência. 21

22 5 Bibliografia [1] ISO/IEC :2001. Coding of Audio-Visual Objects Part 1: Systems, 2 Edition, 2001 [2] ISSO/IEC :2001, Amendment1. Coding of Audio-Visual Objects Part 1:Systems, 2001 [3] Fernando, Gerard, Atul Puri, Viswanathan Swaminathan, Robert L Schimidt, Pallavi Shah, and Keith Deutsch, Architecture and API for MPEG-J. Doc. ISO/MPEG N3545, Dublin MPEG Meeting, July 1998 [4] DAVIC 1.4.1:1998. Part 9: Information Representation [5] ISO/IEC :2000. Generic Coding of Moving Pictures and Associated Audio Information Part 1: Systems, [6] ETSI. Specification for Service Information (SI) in DVB Systems. Doc. EN V1.3.1 Multimedia Fundamentals, Volume 1; Media Coding and Content Processing (2d Edition) 22