MPEG-J e JMF

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
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. 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
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
Application Engine
java.util
MPEG-J APIs
JVM
BIFS,
Presentation Engine
Áudio,
visual,
MPEG-J...
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
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
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
Back
Channel
Channel
D
E
M
U
X
BIFS/OD
Decoder
Scene
Graph
BIFS and OD
Streams
Decoding
Buffers 1...n
Media
Decoders
Composition
Buffers 1...n
Compositor
and Renderer
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
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.
2.1 - 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
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.
2.1.2 – 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 construtor1 do terminal
MpegjTerminal, uma classe específica definida entre as APIs MPEG-J.
8
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-4.
2.2.1 – 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
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.
2.2.2 – 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.
2.2.3 – 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.
2.2.4 – 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
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
•
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
[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
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
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
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
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
•
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
•
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
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
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
5 – Bibliografia
•
[1] ISO/IEC 14496-5:2001. Coding of Audio-Visual Objects – Part 1: Systems, 2
Edition, 2001
•
[2] ISSO/IEC 14496-1: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 13818-1:2000. Generic Coding of Moving Pictures and Associated
Audio Information – Part 1: Systems, 2000.
•
[6] ETSI. Specification for Service Information (SI) in DVB Systems. Doc. EN
300468 V1.3.1
•
Multimedia Fundamentals, Volume 1; Media Coding and Content Processing (2d
Edition)
•
http://java.sun.com/products/java-media/jmf/2.1.1/guide
22