Executando Aplicac¸˜oes em um Receptor Interativo de TV Digital

Vamos agora descrever em mais detalhes como os aplicativos s˜ao transmitidos e executados no receptor de um sistema de TVDI. Como explicado anteriormente, a transmiss˜ao de dados da emissora para um receptor ´e realizada usando carross´eis de dados DSM-CC. Um carros- sel de dados consiste em uma s´erie de m´odulos, onde cada m´odulo pode, por sua vez, ser dividido em blocos para facilitar a transmiss˜ao. Carross´eis de objetos s˜ao constru´ıdos em cima do modelo de carrossel de dados. Eles estendem o carrossel de dados para adicionar o conceito de arquivos, diret´orios e fluxos (streams). Isso permite que o carrossel possa conter um conjunto de diret´orios e arquivos organizados em um sistema de arquivos tradicional.

Utilizando a abstrac¸˜ao de um sistema de arquivos fornecido pelo carrossel de objetos, as aplicac¸˜oes e seus dados s˜ao continuamente transmitidos, multiplexados com ´audio e v´ıdeo e informac¸˜oes adicionais de controle (metadados). Esta informac¸˜ao ´e separada (demultiplexed) no receptor e adequadamente tratada pelo middleware e outros componentes.

Para sinalizar a um receptor que aplicac¸˜oes est˜ao dispon´ıveis, padr˜oes de TVDI como o DVB e SBTVD definem uma tabela de informac¸˜oes de servic¸o chamada Application In- formation Table (AIT) [Morris e Chaigneau 2005; ETSI 2004; Eduardo, Leite e Rodrigues 2005]. A AIT cont´em todas as informac¸˜oes que o receptor precisa para executar a aplicac¸˜ao, como o nome, o identificador e o controle do ciclo de vida da aplicac¸˜ao. Este ´ultimo ´e sina- lizado pelo campo da AIT application control code, que permite que a emissora sinalize ao receptor o que fazer com a aplicac¸˜ao com relac¸˜ao `a sua inicializac¸˜ao.

Aplicac¸˜oes com c´odigo de controle setado para AUTOSTART, tamb´em chamadas trigger applications, s˜ao carregadas e iniciadas automaticamente, sempre que o receptor est´a sinto- nizado em um canal de TV que est´a transmitindo essa aplicac¸˜ao. Assim, quando uma trigger application ´e transmitida no carrossel, ela ´e carregada por cada receptor que est´a (ou estar´a) sintonizado no canal associado. Um trigger application executar´a at´e o seu t´ermino ou at´e que outra trigger application seja transmitida no carrossel para o mesmo canal. Quando o receptor ´e desligado ou muda de canal, a execuc¸˜ao da aplicac¸˜ao ´e interrompida.

Em um receptor de TV Digital, v´arias aplicac¸˜oes podem estar executando ao mesmo tempo e h´a, portanto, uma necessidade de impor uma separac¸˜ao entre as aplicac¸˜oes. Os Xlets s˜ao um conceito similar ao de Applets [Arnold e Gosling 1996]. Eles foram introduzidos pela Sun na especificac¸˜ao JavaTV e adotados como o formato de aplicac¸˜ao Java para o padr˜ao

MHP e outros padr˜oes relacionados com DTV. Como os Applets, a interface Xlet permite que um agente externo (o gerenciador de aplicac¸˜oes ou Application Manager, no caso de um receptor de TV digital) possa iniciar e parar uma aplicac¸˜ao, bem como control´a-la de outras maneiras.

Uma Xlet [Morris e Chaigneau 2005; ITVW 2011] deve estar, em todo o seu ciclo de vida, em um dos seguintes estados1_{: Loaded, Paused, Started e Destroyed. O diagrama de}

transic¸˜ao ´e mostrado na Figura 6.3:

Figura 6.3: Diagrama de Estados de uma Xlet

O gerenciador de aplicac¸˜oes do middleware carrega a classe main do Xlet (conforme as- sinalada pela emissora) e cria uma instˆancia da aplicac¸˜ao chamando o construtor default. Isto pode acontecer em qualquer momento ap´os a aplicac¸˜ao ser recebida pelo receptor. Uma vez carregado, o Xlet fica no estado Loaded. Quando o usu´ario decide iniciar a aplicac¸˜ao (ou quando a emissora indica que o Xlet deve iniciar automaticamente - recurso usado no caso do PNA), o gerenciador de aplicac¸˜oes chama o m´etodo initXlet(), passando um novo objeto XletContext para o Xlet. O Xlet pode usar este XletContext para se inicializar e para carre- gar previamente qualquer recurso grande, como imagens, que demandem tempo para serem obtidas do carrosel de objetos que ´e continuamente transmitido pelo canal de broadcast. Quando a inicializac¸˜ao ´e finalizada, o Xlet fica no estado Paused e est´a pronto para iniciar a sua execuc¸˜ao. Ap´os receber o retorno do m´etodo initXlet, o gerenciador de aplicac¸˜oes do middlewarechama o m´etodo startXlet(). Isto move o Xlet do estado Paused para o estado Started e o Xlet estar´a apto para interagir com o usu´ario, se for programada para fazer isto.

Durante a execuc¸˜ao do Xlet, o gerenciador de aplicac¸˜oes pode chamar o m´etodo pauseX- let(). Isto faz com a aplicac¸˜ao seja movida de volta do estado Started para o estado Paused.

6.2 OddCI-DTV: Um Sistema OddCI sobre uma Rede de TV Digital 113

A aplicac¸˜ao voltar´a para o estado Started novamente quando o gerenciador invocar nova- mente o m´etodo startXlet(). Isto pode acontecer v´arias vezes durante o ciclo de vida do Xlet. No final da execuc¸˜ao do Xlet, o gerenciador de aplicac¸˜oes ir´a chamar o m´etodo destroyXlet(), o que levar´a o Xlet para o estado Destroyed e implicar´a na liberac¸˜ao de todos os recursos que foram alocados pela aplicac¸˜ao. Ap´os este ponto, esta instˆancia do Xlet n˜ao pode mais ser iniciada novamente [ITVW 2011].

6.2

OddCI-DTV: Um Sistema OddCI sobre uma Rede de

TV Digital

Atualmente, diversas tecnologias j´a podem ser utilizadas para tornar poss´ıvel a comunicac¸˜ao simultˆanea e unidireccional entre dispositivos digitais no modelo de um-para-muitos, ca- racter´ıstica do conceito de rede de broadcast evocado neste trabalho. Al´em da tradicional difus˜ao de TV, em sua nova vers˜ao digital e em suas diferentes modalidades (sat´elite, ter- restre, cabo, m´ovel etc) [Morris e Chaigneau 2005], tamb´em podemos citar a transmiss˜ao multicast por redes de banda larga, BitTorrent, redes de telefonia m´ovel e transmiss˜ao de v´ıdeo (VoD, WebTV, IPTV etc). Ao tirar vantagem das funcionalidades j´a disponibiliza- das em dispositivos que implementam tais tecnologias, ou complementando e/ou adaptando estas funcionalidades, ´e poss´ıvel construir implementac¸˜oes de OddCI para v´arios contextos. Da mesma forma, tamb´em ´e bastante ampla a diversidade de dispositivos que podem ser alcanc¸ados atrav´es de uma ou mais das tecnologias de transmiss˜ao mencionadas, de com- putadores a equipamentos com prop´ositos mais espec´ıficos, tais como consoles de jogos, telefones celulares e receptores de TV digital. Alguns destes dispositivos menos tradicio- nais j´a provaram o seu potencial de utilizac¸˜ao para processamento distribu´ıdo em projetos de computac¸˜ao volunt´aria [Stanford 2011; Boincoid 2011].

Para demonstrar a viabilidade da arquitetura OddCI, n´os constru´ımos um prot´otipo base- ado na tecnologia correntemente usada em redes de TV Digital (DTV). N´os chamamos esta implementac¸˜ao de OddCI-DTV e a Fig. 6.4 traz uma vis˜ao geral do seu funcionamento, o qual ´e aderente ao fluxo geral OddCI descrito na Sec¸˜ao 5.2.1.