Está en la página 1de 59

Informe Preliminar: Estado del Arte de Receptores Set-Top-Box Aplicaciones

REA DE APLICACIONES TELEMTICAS

INVESTIGADORES

JUAN MAURICIO VILLANUEVA CHRISTIAN VELASQUEZ DIAZ

INICTEL-UNI Lima, Febrero de 2010

Contenido CAPITULO I ARQUITECTURA DE HARDWARE Y SOFTWARE DEL SET TOP BOX ............................................................................................................................... 3 1.1. Introduccin ........................................................................................................ 3 1.2. Set-Top-Box ........................................................................................................ 4 1.3. Arquitectura de Set-Top-Box .............................................................................. 5 1.4. Software del Set-Top-Box .................................................................................. 7 1.5. Conclusiones ....................................................................................................... 8 CAPITULO II ESTUDIO DE LOS APLICATIVOS EXISTENTES PARA SET-TOPBOX ............................................................................................................................... 9 2.1. Aplicativos Existentes para Set-Top-Box ........................................................... 9 2.1.1 Estdio de Caso 1: Guia de TV personalizada.............................................. 9 2.1.2 Estudio de Caso 2: Monitoreamiento y Control usando GINGA ............... 11 2.1.3 Estudio de Caso 3: Voto Electrnico T-Voto ............................................. 16 CAPITULO III SISTEMA OPERATIVO Y NIVELES DE PROGRAMACION PARA SET-TOP-BOX ................................................................................................ 18 3.1. Middleware ....................................................................................................... 18 3.1.1. MHP Multimedia Home Platform .......................................................... 18 3.1.2. DASE DTV Application Software Environment .................................... 19 3.1.3. ARIB Association of Radio Industries and Businesses .......................... 19 3.1.4. Middleware Ginga ..................................................................................... 20 3.2. Ginga-NCL ....................................................................................................... 22 3.3. Ginga-J .............................................................................................................. 23 3.3.1 API JavaTV ................................................................................................. 24 3.3.2. API DAVIC ............................................................................................... 26 3.3.3. API HAVi .................................................................................................. 26 3.3.4. API DVB .................................................................................................... 26 3.4. Ambientes de Emulacin para la Programacin de GINGA ............................ 27 3.4.1 Emulador GINGA-J: XLetView ................................................................. 30 3.4.2. Emulador GINGA-NCL: Set-Top-Box Virtual ......................................... 35 CAPITULO IV APLICACIONES ITERATIVAS - DEFINCIONES......................... 42 4.1. Introduccin ...................................................................................................... 42 4.2. Componentes de la TV Interactiva ................................................................... 43 4.3. Aplicaciones de Interactividad .......................................................................... 45 CAPITULO V STB COMERCIALES - ESPECIFICACIONES ................................ 46 5.1. Introduccin ...................................................................................................... 46 5.2. Receptores de TV digital Set-Top-Box en el Brasil ......................................... 46 5.2.1. Marca PROVIEW XPS1000 ...................................................................... 46 5.2.2. Marca PROVIEW XPS1000i Interactivo ................................................. 47 5.2.3. Marca INVIX ............................................................................................. 48 5.2.4. Marca MIXLASER .................................................................................... 48 REFERENCIAS ........................................................................................................... 50 ANEXO A APLICACIN XLETVIEW ..................................................................... 51 A.1 Cdigo de Programa Aplicacin XletView. ..................................................... 51 ANEXO B APLICACIN VIRTUAL SET-TOP-BOX ............................................. 53 B.1 Archivo: main.ncl .......................................................................................... 53 B.2. Archivo: hackerteen.lua ................................................................................ 54

CAPITULO I ARQUITECTURA DE HARDWARE Y SOFTWARE DEL SET TOP BOX 1.1. Introduccin En la prctica, el sistema de televisin digital se resume a una conversin de la seal de TV analgica para un formato digital que puede ser emitido por satlite, terrestre o cable, siendo posteriormente decodificado por el propio televisor (televisin digital) o a travs de un receptor llamado set-top-box [1]. As tambin, la Televisin Digital Interactiva es un desafo para los desarrolladores que investigan las potencialidades de los programas interactivos. Una gran diferencia es la posibilidad de comunicacin con los telespectadores va un canal de retorno. Actualmente, la televisin abierta utiliza los artificios de otros medios de comunicacin (telfono, Internet, fax, mensajes, SMS) con la finalidad de que el telespectador participe indirectamente de la programacin. Con la televisin digital interactiva se puede concretizar un dialogo del espectador con el programa a travs del canal de retorno o del acceso de datos recibido y almacenados en el set-top-box [1]. El set-top-box tiene un papel fundamental en la implementacin de nuevas funcionalidades de la Televisin Digital Interactiva. Este nuevo componente del sistema es responsable por mantener la compatibilidad con un parque instalado de televisores, adicionando nuevas funcionalidades: desde la transmisin de video de alta calidad hasta un nivel elevado de interactividad. Asociado al hardware del Set-Top-Box, se tiene el Middleware Ginga, una recomendacin ITU-T H.761, desarrollado para ser el modelo del Middleware para Televisin Digital del Brasil y que hoy en da es parte del estndar adoptado por el Per. La conjuncin entre el Set-Top-Box y el GINGA, permiten desarrollar componentes y aplicaciones para TV digital, adicionando servicios a los usuarios, con nuevas funcionalidades, muchas de estas ya disponibles comercialmente por las redes de TV a cable o satelitales, tales como [1]: Guas de Programacin Electrnica (Conocido como EPG), Email y mensajes de texto Juegos interactivos on-line Video sobre demanda 3

Sistema de pay-per-view.

En este panorama, en esta seccin se estudiara las arquitectura convencional del hardware y software, y como estas interactan durante la ejecucin de aplicaciones interactivas. 1.2. Set-Top-Box El set-top-box es un dispositivo externo, el cual viabiliza que un televisor convencional (Televisin analgica) pueda reproducir programas de televisin emitidos con tecnologa digital. Los componentes fsicos que constituyen un set-topbox son [1]: Placa del sistema Sintonizador Modulador/ demodulador Demultiplexador Decodificador Procesador grfico CPU (Central Processing unit) Memoria Disco Interfaces fsicas

As tambin, se pueden clasificar los Set-Top-Box en tres categoras [1]: Broadcast TV, Enhanced TV y Advanced Services. Estas clasificaciones sern descritas a seguir: a) Broadcast TV: Los set-top-box para difusin de TV (broadcast TV) son utilizados para los servicios tradicionales de TV, adicionado de un sistema pay-per-view e instrumentos bsicos de navegacin. Sin embargo, permiten la recepcin de datos en formato digital. Tambin disponen de una cantidad limitada de memoria, limitado nmero de puertos de interface y una capacidad de procesamiento limitada. Sin embargo, han sido proyectadas de forma a soportar algunos sistemas avanzados, tales como el servicio de mensajes y video-on-demand. b) Enhanced TV: La diferencia de los set-top-box de la categora Enhanced TV consiste en incluir un canal de retorno. Los Enhanced set-top-box soportan comercio electrnico, video sobre demanda, y un navegador para 4

conexin a Internet. La presencia del canal de retorno posibilita comunicaciones por e-mail y por chat. Estos set-top-box tienen una capacidad de procesamiento y una capacidad de memoria mayor en relacin a los set-top-box Broadcast TV. c) Advanced Services: Los set-top-box de servicios avanzados presentan una velocidad de procesamiento cerca de 10 veces superior a los set-top-box Broadcast TV. Las capacidades mejoradas de este tipo de set-top-box en conjunto con el canal de retorno de elevada velocidad, permiten que este tipo de set-top-box tenga acceso a una variedad de servicios de Internet e interactividad. Generalmente, este tipo de set-top-box viene asociado a un disco duro incorporado. 1.3. Arquitectura de Set-Top-Box Los set-top-box son sistemas embarcados proyectados para un propsito especfico: recepcin de seales de TV digital, recuperacin del video y exhibicin en una TV. La Figura 1.1 se ilustra la arquitectura en camadas de un set-top-box genrico.

Figura 1.1. Arquitectura general de un Set-Top-Box. Na camada superior, se tienen los servicios y contenidos que pueden ser producidos en una transmisin de TV digital. Ejemplos de estos servicios son las guas de programacin electrnica (EPG), sistema pay-per-view, juegos on-line, programas interactivos, etc. La segunda camada, se tienen las aplicaciones. Estas aplicaciones son responsables por promover el tipo de servicio de la camada superior. En la tercera camada, el Middleware, que bsicamente tiene como funcin realizar una interface entre el hardware del set-top-box y las aplicaciones. De esta forma, las aplicaciones pueden ejecutarse de forma transparente sin la preocupacin 5

con la forma de acceso al hardware de un set-top-box especfico [1]. De esta forma el desarrollo y portabilidad de las aplicaciones se torna ms simple, debido a que todas las aplicaciones usan una misma API en comn. En la cuarta camada, se tienen los componentes multimedia de decodificacin y codificacin, as como los otros mdulos multimedia. En la quinta camada, el sistema operacional, es responsable por el funcionamiento del hardware, proveyendo una camada de abstraccin al hardware del set-top-box. En la ltima camada tenemos el hardware de un set-top-box, que es constituido por una CPU, dispositivos de entrada y salida, almacenamiento, decodificacin, sintonizacin, etc. En la Figura 1.2, se ilustra la arquitectura del hardware de un set-top-box convencional [1], el cual puede ser dividido en tres etapas: Etapa Inicial (Front End): interfaces de sintonizacin de las seales. En esta primera etapa se realiza la recepcin de una seal provenientes de de tres posibles medios de transmisin: terrestre, clave o satlite. El sintonizador (tuner) selecciona la frecuencia de recepcin y modula en banda base la seal de entrada. La seal es muestreada para crear la representacin digital del mismo que es realizada por el conversor analgico/digital. Las prximas etapas son la demodulacin y la correccin de error de la seal, que luego enseguida es encaminado a la etapa intermediaria. Etapa intermedia: interfaces de transporte de control de sistemas. En la etapa intermediaria se tiene la demultiplexacin del flujo MPEG-2, que separa audio, video y datos contenidos en el flujo de transporte. La seleccin de los paquetes de audio, video o datos es realizado de acuerdo con las acciones del usuario, que son llevadas a la CPU por las interfaces de entrada y salida. Etapa final: decodificadores de audio y video y la etapa de salida de las seales para la TV. En la etapa final es realizada la decodificacin del flujo MPEG-2 que fue seleccionada en la etapa intermedia. Este flujo es convertido nuevamente

para una seal analgica, modulada en banda base y enviada para exhibicin en un equipo de TV convencional.

Figura 1.2. Arquitectura del hardware de un set-top-box convencional. Desde un punto de vista de hardware, los componentes de la arquitectura del Set-Top-Box que diferencian los diferentes estndares de Televisin Digital (ISDB-T, DBV, ATSC, etc), son los circuitos integrados demodulador y decodificador de video. 1.4. Software del Set-Top-Box Para la arquitectura del hardware descrito en la Figura 1.2, existen herramientas de software divididas en varias camadas, como se ilustra en la Figura 1.3. Estas herramientas de software hacen uso de las funcionalidades del hardware, para interactuar con el telespectador y entregarlo al contenido televisivo interactivo.

Figura 1.3. Arquitectura del hardware de un set-top-box convencional. La camada inferior del software es formada por un conjunto de controladores de dispositivos necesarios para que un sistema operativo de tiempo real ejecutado en

la camada adyacente pueda controlar el hardware. A diferencia de los sistemas operativos de computadoras personales, el sistema operativo del set-top-box dispone de recursos ms escasos que un micro-computador, como una memoria menor y procesadores con menor velocidad. En la camada del sistema operativo, se encuentra el Middleware, que es la camada responsable por proporcionar una interface de programacin de aplicacin (API Application Programming Interface) a los desarrolladores de aplicaciones. Esta interface es independiente del hardware y de las tecnologas de comunicacin, facilitando el desarrollo de aplicaciones de software. Entre los estndares de middleware, estn el estndar Europeo MHP (Multimedia Home Plataform) de la DVB (Digital Video Broadcasting), el americano DASE (DTV Application Software Environment) de la ATSC (Advanced Television Systems Committee), el estndar ARIB de la ISDB-T de Japn, y el GINGA del estndar brasileo ISDB-Tb. Finalmente, la camada de aplicacin, donde residen los aplicativos producidos que permiten realizar la interactividad con los diversos servicios, entregando as al telespectador el contenido digital en la televisin. 1.5. Conclusiones Los Set-Top-Box permiten la decodificacin de seales obtenidas a partir de televisin digital terrestre, cable o satelital, para reproducirlo en una televisin analgica. Los Set-Top-Box se encuentran asociados a un software denomina de Middleware, que permite ejecutar aplicaciones interactivas en el set-top-box. Para el caso particular del estndar brasileiro ISDB-Tb es el Middleware Ginga y para el estndar Japons ISDB-T es el Middleware BML. Para los diferentes estndares de televisin digital en el mundo (ISDB-T, DBV, ATSC, etc), las arquitecturas de hardware de los set-top-boxes se diferencian principalmente por el tipo de demodulador y el decodificador MPEG-2/MPEG-4.

CAPITULO II ESTUDIO DE LOS APLICATIVOS EXISTENTES PARA SET-TOP-BOX 2.1. Aplicativos Existentes para Set-Top-Box En esta seccin se estudiaran algunas de las principales aplicaciones en Televisin Digital, tales como: Gua de TV personalizada Monitoreamiendo y Control: Aplicaciones en Domtica. Voto electrnico T-Voto.

2.1.1 Estdio de Caso 1: Guia de TV personalizada El cambio del sistema analgico al sistema digital ha trado consigo dos consecuencias principales: el aumento en la transmisin de nuevos canales con el mismo ancho de banda y la posibilidad de enviar aplicaciones multiplexadas con contenido audiovisual. Ya que nuevos canales emergen debido al aumento de la transmisin, es necesario crear nuevos mecanismos que permitan que los televidentes puedan interactuar con ellos. La gua electrnica de programacin (EPG) son de gran ayuda al espectador de TV, sin embargo como nuevos canales estn disponibles, una sobrecarga de informacin es inevitable, por lo cual el EPG es inapropiado. Las EPG tradicionales se convirtieron poco atractivas, debido a que toma demasiado tiempo para que los espectadores busquen entre cientos de opciones su programa favorito, ante esta situacin, los sistemas de recomendacin personalizados son necesarios. Diferente de las funciones de EPG que permiten la bsqueda bsica, un sistema de TV personalizado puede crear un perfil para cada espectador de TV y recomendar programas que mejor se adapten a este perfil, evitando la bsqueda en muchas opciones EPG para encontrar el programa favorito. El perfil del espectador de TV, puede ser interpretado de un modo explicito donde el sistema recibe la informacin sobre sus preferencias o puede ser interpretado de un modo implcito donde el sistema puede deducir las preferencias de los espectadores de TV al analizar sus antecedentes de comportamiento [2]. Con la finalidad de aprovechar las funcionalidades ofrecidas por el sistema digital (nuevos canales, aplicaciones interactivas), los espectadores de TV con sistema analgico necesitan de un nuevo equipo llamado SET TOP BOX, el cual es un 9

dispositivo que trabaja conectado a la TV y convierte la seal digital recibida del proveedor a audio/video que la TV analgico debe presentar. El SET TOP BOX, necesariamente necesita de una capa de software que permita conectar el hardware a las aplicaciones interactivas llamada Middleware. El middleware del sistema brasileo de DTV es GINGA [2]. En este trabajo se ha desarrollado una extensin al middleware Ginga-NCL a travs de la aplicacin de un nuevo mdulo incorporado al ncleo comn Ginga llamado Recommender. El mdulo Recommender es responsable de recopilar, almacenar, procesar y recomendar los programas de televisin a los espectadores de la televisin. Para desarrollar el mdulo Recommender, se utiliz el middleware GingaNCL desarrollado por la PUC-Rio (Pontificia Catlica Universidad de Ro de Janeiro, Brasil), implementado en C / C + +. El cdigo fuente est disponible bajo la licencia GPLv2 y de acuerdo con los patrones definidos por el sistema brasileo de televisin digital. En este sistema de recomendacin las solicitudes de procedimiento son desarrollados usando le lenguaje Java y las aplicaciones declarativas en NCL [2]. La Figura 2.1 se ilustra la representacin del middleware Ginga, que consta de tres etapas capas: Resident Applications: Responsable de la exposicin (frecuentemente llamado capa de presentacin). Ginga Common Core: Conjunto de mdulos responsables del procesamiento de datos, filtrado de informacin en el flujo de transporte, estabilidad de datos. Stack Protocol Layer: Responsable de apoyar la comunicacin de protocolos tales como: HTTP, RTP y TS.

Figura 2.1. Arquitectura del Middleware Ginga-RECOMMENDER. 10

En la Figura 2.2, se ilustra la arquitectura del mdulo RECOMMENDER, el cual se encuentra dividido en dos parte: La primera parte describe los componentes integrados al cdigo fuente del middleware tales como el Agent Local, el Agent Schedule, el Agent Filter y el Agent Data. La segunda parte describe los componentes aadidos al Set Top Box: Sqlite, una libreria C que implementa la conexin de una base de datos SQL y Weka (Waikato Environment for Knowledge Analysis), el cdigo fuente que provee un conjunto de algoritmos para aprender sobre la mquina y el data mining [2].

Figura 2.2. Arquitectura del modulo Recommender. 2.1.2 Estudio de Caso 2: Monitoreamiento y Control usando GINGA El proyecto DIGA (Automatizacin digital en monitoreo y control usando tecnologa Ginga), es un sistema innovador en la domtica y la automatizacin del hogar. Domtica se puede definir como la integracin de la tecnologa en el diseo inteligente de un recinto. Esto es, un conjunto de sistemas capaces de automatizar una vivienda, aportando servicios de gestin energtica, seguridad, bienestar y comunicacin, y que pueden estar integrados por medio de redes interiores y exteriores de comunicacin, cableadas o inalmbricas, y cuyo control goza de cierta ubicuidad, desde dentro y fuera del hogar [3]. Se propone agregar funcionalidades al Middleware Ginga, como las aplicaciones en el seguimiento y control en la automatizacin del hogar, optimizando de esta manera el uso del Set top Box. Con este fin DIGA hace uso de los dispositivos 11

(sensores, tecnologa RFID, etc.) que accesan al Set Top Box de la TV digital a travs de la red inalmbrica (IEEE 802.11x) dentro del hogar. Estos servicios agregados a los set top box (software y contenidos) tambin podran ser accedidos externamente a travs de Internet o la tecnologa celular (EDGE, GSM, GPRS, etc). Por tanto la idea central del proyecto es compartir la estructura computacional del set top box, agregando servicios para el cuidado de su hogar, tal como el monitoreo del ambiente fsico (seguridad del hogar y de empresas), monitoreo personal (signos vitales de salud), automatizacin residencial y aplicaciones que estimulan la produccin de contenidos entre usuarios, como por ejemplos, aplicaciones P2P entre comunidades con intereses comunes en los mbitos del proyecto. Dadas sus limitaciones parte de los servicios agregados serian ejecutados en el propio Set Top Box, en cuanto a las tareas que exijan mayor poder y/o solicitudes de mayor espacio de memoria, como aplicaciones de salud, sern ejecutadas en una base de datos centralizada, especificadas para algunas funcionalidades del DIGA. (para especificar las caractersticas de DIGA.) Por tanto el Set Top Box tambin funcionaria como una especie de Gateway entre los dispositivos de monitoreo y contrlenla Base de datos DIGABEM (DIGital Automation Monitoring Based in Embedded Model) que integra el proyecto. Aunque son compatibles con cualquier modelo de set-top-box (Zapper, por ejemplo), el DIGA est orientado para el GINGA, el middleware de televisin digital de Brasil, resultado de la investigacin llevada a cabo por el SBTVD (Estndar Brasileo de Televisin Digital), establecido por el Decreto 4901 de noviembre 26 de 2003. El desarrollo de este proyecto tiene como objetivo la implementacin de cuatro componentes: a) DIGA SALUD: Software que integra dispositivos de monitoreo de seales vitales de salud personal (SVSP), tales como el oximetra de pulso, tensimetro, medidor de glucosa, etc. Como se ilustra en Figura 2.3, el DIGA SALUD, puede ser colocado, si el caso, junto al cuerpo del paciente para que este pueda moverse con normalidad. La informacin de estas seales puede ser proporcionada por el usuario a cualquier institucin o profesional de salud.

12

Figura 2.3.Contexto de accin de DIGA SAUDE. b) DIGA CASA: Integra dispositivos de monitoreo fsico, tales como: sensores de temperatura, sensores de presencia, sensores para detectar la apertura de puertas y ventanas, etc. Su primera funcin es monitorear el ambiente y enviar las seales de los sensores y las cmaras al Set Top Box, parte de estas seales sern procesadas localmente, generando o no procedimientos inmediatos (envio de SMS urgentes, emails, etc.).

Figura 2.4. Contexto de accin de DIGA CASA c) DIGA MUNDO: El propsito de este componente es expandir el concepto de DIGA SAUDE, agregando una estructura de control basada en software que permita al usuario ser tambin monitoreado permanentemente, por una central de atendimiento (DIGA - CA). DIGA MUNDO podr anticiparse a algunas situaciones de riesgo al cruzar datos on-line (DIGA SAUDE) con datos offline (consultas y exmenes) y alertar al usuario para los procedimientos preventivos en situaciones de riesgos.

13

d) DIGAM AQUI: Software de interaccin (Applying Quality to Universal Interfaces), el cual es un conjunto de APIs (Application Programming Interfaces), que permiten al usuario de DIGA MUNDO, crear y accesar comunidades de intereses comunes, por ejemplo, una comunidad de personas diabticas. Para el control de seguridad del hogar y de los signos vitales de salud personal, en este trabajo, se implementaron los siguientes prototipos: DIGA Security Center e o DIGA Doctor, como se ilustra en la Figura 2.5, teniendo como centro un monitor de pantalla ancha y un set-top box.

Figura 2.5. Prototipos implementados de DIGA Descripcin de DIGA Security Center Las Figuras 2.6 y 2.7 ilustran un ambiente residencial siendo monitoreada por DIGA Security Center, el cual se encuentra alojado en el set-top-box. El medio ambiente contiene sensores y cmaras distribuidas por toda la casa, y el estado de los sensores y las imgenes generadas por cada cmara puede ser visto desde cualquier TV integrada al sistema, va web.

14

Figura 2.6. Control residencial realizado por DIGA Security Center. Con la ayuda del control remoto el usuario de DIGA, pueda escoger con que cmara deseara recibir las imgenes (garaje, puerta principal, habitaciones, jardines, etc.), lo que permite una mayor seguridad en la vivienda. Adems de las cmaras de control, DIGA realiza un control de electrodomsticos, puertas de accesos u otros productos electrnicos. Una vez que el set-top box si est conectado a la Internet, es posible supervisar en tiempo real, desde cualquier habitacin de la persona que se encuentre en el hogar y el manejo de sensores y alarmas a travs de la web. Por ejemplo, las cmaras distribuidas por la residencia para vigilar a los nios que requieren una vigilancia intensiva.

Figura 2.7. Escenario de control residencial. Descripcin de DIGA Doctor La Figura 2.8 ilustra un escenario tpico de aplicacin DIGA Doctor. Esto surge como premisa de proporcionar un control y apoyo a las personas que se encuentran en mal estado de salud o con enfermedades que requieren de supervisin mdica intensiva. 15

Imaginemos a una mujer de edad avanzada, recibiendo a travs de un terminal mvil de TV, un asesoramiento profesional de cmo medir la presin arterial.

Figura 2.8. Ejemplo de escenario de una aplicacin DIGA doctor. En el caso de la ciruga, la necesidad postoperatoria atencin con respecto a la recuperacin y el control de determinadas variables para la evaluacin de su estado (fsico o psicolgico). En la actualidad, las personas en estas situaciones, generalmente ingresan a los centros de salud (con altos costos) [4]. 2.1.3 Estudio de Caso 3: Voto Electrnico T-Voto La T-Voto es una aplicacin que provee al espectador interactividad con el programa que est siendo transmitido. Durante la exhibicin de un programa de televisin se le pide al espectador que revele su opinin a travs de una votacin como se ilustra en la Figura 2.9. De forma similar a los programas de Reality Shows, en la cual se tiene la posibilidad de realizar una votacin para eliminar o apoyar a un participante del programa, o una encuesta que se realiza durante la presentacin de un programa [5]. El espectador manifestara su opinin directamente con el control remoto, donde informara cual es su opcin y enviar su voto por el emisor de la TV.

16

Figura 2.9. Aplicacin T-Voto. Una estacin de televisin (Servidor de Generacin de Contenido) transmitir (va satelital, terrestre o portable) la seal de vdeo, para los receptores de televisin digital interactiva, que durante el tiempo de duracin del programa, se ejecutara la aplicacin interactiva en la cual el espectador podr votar, y por medio de un canal de retorno (p.e. conexin a Internet) ser capaz de registrar su voto en el.

17

CAPITULO III SISTEMA OPERATIVO Y NIVELES DE PROGRAMACION PARA SETTOP-BOX 3.1. Middleware Para evitar la proliferacin de estndares para middleware, los principales sistemas existentes para la televisin digital terrestre - americano, europeo y japons han adoptado un middleware estndar en sus receptores digitales. Estos son Middleware diferentes, aunque con caractersticas especficas, los cuales siguen las recomendaciones de la norma GEM (UIT-T J.201) (UIT-T, 2001). 3.1.1. MHP Multimedia Home Platform MHP, es el middleware desarrollado, para el estndar DVB, adoptado por Europa [ETSI TS 102 B12 2004]. MHP tiene por objeto proporcionar un entorno para la televisin interactiva, independiente de hardware y software especficos, abiertos e interoperables para los receptores y decodificadores para TV digital. Su entorno de ejecucin se basa en el uso de una mquina virtual de Java y un conjunto de interfaces de programacin (API). Estas API permiten a los programas escritos en Java el acceso a los recursos y las instalaciones del receptor digital de una manera estandarizada. Una aplicacin DVB usando API de Java se llama aplicacin DVB-J [6]. Adems del uso del API Java, el MHP introduce la posibilidad de usar un lenguaje de programacin semejante a HTML (utilizada en internet para la programacin de pginas Web), denominada DVB-HTML. En la Figura 3.1, muestra la arquitectura del estndar europeo DVB

Figura 3.1. Estndar de televisin digital DVB MHP. 18

3.1.2. DASE DTV Application Software Environment La DASE fue desarrollado por el ATSC como estndar de los EE.UU. para la capa de middleware de set top boxes de TV digital [DASE de 2003]. Al igual que en el MHP, la DASE adopta una mquina virtual de Java como un mecanismo que facilita la ejecucin de aplicaciones que permite la interactividad. Tambin de forma similar a MHP, la DASE permite el uso de lenguajes declarativos, usadas en web como HTML y JavaScript. El middleware MHP y DASE no fueron diseados para ser compatibles entre s. Esto significa que un servicio desarrollado en una de estas estndares no funcionar con otro. La figura 2 muestra la arquitectura de capas de la estndar ATSC [6].

Figura 3.2. Estndar de televisin digita ATSC -DASE 3.1.3. ARIB Association of Radio Industries and Businesses El middleware de ISDB (Integrated Services Digital Broadcasting) est estandarizado por la organizacin japonesa ARIB. Este middleware est compuesto por algunas normas, como ARIB STD-B24 (Data Coding and Transmission Specification for Digital Broadcasting) que define un lenguaje declarativo llamado BML (Broadcast Markup Language) [ARIB B-24, 2004]. Este lenguaje, basado en el lenguaje estndar de servicios Web XML (Extensible Markup Language), es utilizado para la especificacin de los servicios multimedia para TV digital [6]. Otra especificacin del middleware es la ARIB STD-B23 (Application Execution Engine Platform for Digital Broadcasting), que se basa en la especificacin DVB-MHP. Este ltimo estndar refleja una tendencia de ARIB intentar establecer una base comn entre los estndares de middleware MHP y DASE. La Figura 3.3 ilustra la estndar japons ISDB-T [6].

19

Figura 3.3.Estndar de televisin digital ISDB -ARIB 3.1.4. Middleware Ginga Proyectando el desarrollo de aplicaciones interactivas para la televisin digital terrestre en el Per, a continuacin se desarrollara un estudio detallado del middleware Ginga , el cual fue adoptado en el ao 2009. Para el sistema brasileo de TV digital (SBTVD), basado en el estndar japons, fue definido un middleware propio denominado GINGA. En la Figura 3.4 se muestra el estndar SBTVD, incluido su middleware.

Figura 3.4. Arquitectura en capas del estndar SBTVD. Ginga es la capa de software intermedio (middleware) que permite el desarrollo de aplicaciones interactivas para televisin digital, independientemente de la plataforma de hardware de fabricantes de terminales de acceso (set top boxes) [7]. Este middleware puede dividirse en un conjunto de aplicaciones declarativas y aplicaciones procedurales. Para ello, Ginga se divide en dos grandes subsistemas 20

interconectados, Ginga-J (para las aplicaciones procedurales Java) y Ginga-NCL (para aplicaciones declarativas NCL). Dependiendo de la funcionalidad del diseo de cada aplicacin, un paradigma de programacin es ms adecuado que el otro [6]. En particular, las aplicaciones declarativas frecuentemente hacen uso de scripts, cuyo contenido es de naturaleza procedural. Por otra parte, una aplicacin declarativa puede hacer referencia a una aplicacin procedural, de la misma forma, una aplicacin procedural puede hacer referencia a una aplicacin declarativa, que contiene, por ejemplo, contenido grfico, o puede construir y comenzar una presentacin de aplicaciones con contenido declarativo. Por lo tanto, ambos tipos de aplicaciones Ginga pueden utilizar los beneficios que brindan los ambientes para las aplicaciones declarativos y procedurales [6]. La arquitectura de implementacin de referencia del middleware Ginga, puede ser dividida en tres mdulos: Ginga-CC (Common Core), el entorno de presentacin Ginga-NCL (declarativo) y el entorno de ejecucin Ginga-J (procedural) [7]. La arquitectura del middleware GINGA se ilustrada en la Figura 3.5.

Figura 3.5.Arquitectura del middleware Ginga. La Figura 3.6 presenta un ambiente de ejecucin comn a las propuestas del middleware para la televisin digital. El Ambiente presenta una mquina de ejecucin para las aplicaciones procedurales, una mquina de presentacin para las aplicaciones declarativas y elemento-puente, que hace el mapeamiento bidireccional entre objetos procedurales y declarativos. [6].

21

Interacciones con Usuarios Aplicacin Aplicacin Aplicacin Elementos Puente Maquina de Ejecucin Monitor de Ciclo de Vida API Servicio de Interface Eventos y Video Digital Otras Informacin Grafica Datos Difusin (MPEG) Midia Sistema Operacional Hardware Maquina de Presentacin Aplicacin Aplicacin Software Nativo

Rede

Acceso Condicional

Figura 3.6. Arquitectura del ambiente de ejecucin de las aplicaciones para TV digital. Recomendaciones ITU-T J.2000 3.2. Ginga-NCL Ginga-NCL fue desarrollado por la PUC Rio, destinadas a proporcionar una infraestructura para la presentacin de las solicitudes declarativa escrito en el lenguaje de NCL (Nested contexto lingstico). NCL es una aplicacin XML (eXtensible Markup Language), con facilidades para especificar los aspectos de la interactividad, en tiempo-espacio entre los objetos de los medios de comunicacin, la adaptabilidad, soporte a mltiples dispositivos y produccin en vivo de programas interactivo no lineares. [7] Siendo una aplicacin XML, el lenguaje de NCL posee una estricta separacin entre el contenido y la estructura, NCL no define los medios de comunicacin por s mismos. En cambio, mantiene los medios de comunicacin, junto con una presentacin multimedia. Sin embargo, un documento de NCL slo define cmo los objetos de los medios de comunicacin estn estructurados y relacionados en el tiempo y el espacio. [8]. El video (MPEG, etc.), audio (AAC, etc.), imagen (JPEG, GIF, etc.) y texto (TXT, HTML, etc.), son ejemplos de objetos de medios de comunicacin. Entre estos objetos se destacan los objetos de vdeo y audio en SBTVD [9]. Otro objeto importante es aquel basado en XHTML. NCL no sustituye a XHTML sino que complementa lo que es incapaz de cumplir como un lenguaje declarativo. A diferencia de XHTML el lenguaje NCL no mezcla la definicin de contenido de un documento con su estructura. [9]. El ambiente declarativo es en s muy limitado. Las aplicaciones que utilizan un lenguaje declarativo debe tener su enfoque sobre el sincronismo, siendo el foco de la 22

lengua NCL exactamente eso, no la interactividad, ya que la interaccin es tratada como resultado de la sincronizacin [8]. En NCL, un documento XHTML es un tipo de elemento de los medios de comunicacin. De forma semejante, lenguajes imperativos pueden ser adicionados y utilizados como medios de comunicacin. En concreto, el Ginga-NCL, debe ofrecer soporte a dos lenguajes procedurales, como son LUA y JAVA. Lua es el lenguaje script de NCL, y Java debe seguir las especificaciones de Ginga-J. [10]. LUA es un lenguaje de programacin extensible diseado para una programacin procedimental general con utilidades para la descripcin de datos. Tambin ofrece un buen soporte para la programacin orientada a objetos, programacin funcional y programacin orientada a datos. Se pretende que Lua sea usado como un lenguaje de script potente y ligero para cualquier programa que lo necesite. [11]. Siendo un lenguaje de extensin, Lua no tiene nocin de programa principal (main): slo funciona embebido en un cliente anfitrin, denominado programa contenedor o simplemente anfitrin (host). ste puede invocar funciones para ejecutar un segmento de cdigo Lua, puede escribir y leer variables de Lua y puede registrar funciones C para que sean llamadas por el cdigo Lua. [11]. La utilizacin de LUA ofrece algunas ventajas, como: adems de ser un proyecto de cdigo abierto y desarrollado en C, LUA combina la programacin procedural con poderosas construcciones para descripcin de datos, basadas en tablas asociativas y semntica extensibles. Es notable por su alto rendimiento y bajo consumo de recursos, en comparacin con otros lenguajes interpretados [12]. 3.3. Ginga-J Ginga-J fue desarrollado por la Universidad Federal de Paraiba (UFPb), para proveer una infraestructura de ejecucin de aplicaciones basadas en lenguaje Java, llamadas Xlet, con funcionalidades orientadas especficamente al medio ambiente de la televisin digital [7]. El Xlets no necesita ser previamente almacenados en el STB, pues puede ser enviado por el canal de distribucin. Es decir, el modelo Xlet se basa en la transferencia de cdigo ejecutable por el canal de distribucin para el STB y posterior carga y ejecucin del mismo, de forma automtica o manual. Un Xlet es muy similar a un applet web o MIDlet en celulares u otros dispositivos mviles [13]. 23

El entorno de ejecucin Ginga-J define un conjunto de APIs, los cuales pueden ser divididos en tres partes, como se ilustra en la Figura 3.7. El API (1), innovaciones que dan soporte a las aplicaciones brasileas, en especial a la de contenido social; el API (2), tambin innovaciones brasileas, pero que pueden ser exportadas para otros sistemas; y el API (3), que sigue el ncleo comn del patrn GEM.

Figura 3.7. Representacin de los APIs de Ginga-J. En su versin actual el Ginga-J sigue las especificacin del GEM (Globally Executable MHP) e ITU J.200, J.201 y J.202, siendo por lo tanto compatible con los dems middlewares de TV digital que siguen estas especificaciones. El GEM est basado en el middleware MHP y especifica un conjunto de APIs, para ser usadas en el desarrollo de aplicaciones para la TV digital, incluyendo las APIs provenientes de los paquetes de Sun JavaTV, DAVIC [DAVIC, 1999] e HAVI [HAVi, 2001]. A continuacin se presenta un resumen de los APIS ms usados: 3.3.1 API JavaTV El API JavaTV es una extensin de la plataforma Java que sirve para apoyar la produccin de contenidos interactivos de forma procedural para la televisin digital. El objetivo principal de la API JavaTV es proporcionar un conjunto de mtodos, clases e interfaces para facilitar la creacin de aplicaciones diseadas para ejecutarse en distintas plataformas para la recepcin de televisin digital independiente de las tecnologas utilizadas en la red de transmisin [14]. JavaTv soporta un alto nivel de interactividad, calidad grafica y de procesamiento para ser ejecutado dentro de un set top box, siempre y cuando este equipada con la maquina virtual de Java, necesaria para interpretar los bytecodes generados. Utilizando su arquitectura la API JavaTV es capaz de realizar funcionalidades tales como: 24

Streaming de audio y vdeo: Adems de la streaming de vdeo y audio procedente de la estacin, es posible generar otras aplicaciones con otros flujos.

Acceso a datos en el canal de transmisin: JavaTV pueden recibir datos para las aplicaciones. Aplicaciones con interactividad: Las aplicaciones que pueden utilizar esta API pueden procesar datos y devolverlos a travs de un canal de retorno.

Gestin del Ciclo de vida de las aplicaciones: permitiendo que las aplicaciones coexistan con el contenido de TV convencional y que permite el intercambio de canal sin que la aplicacin deje de existir.

La API JavaTv tiene varias libreras, que son responsables de proveer una estructura bsica del sistema. Las libreras estn dispuestas de la siguiente forma: javax.tv.carousel: proporciona acceso a archivos broadcast y directorio de datos a travs de APIs que trabajan con el paquete java.io; javax.tv.graphics: permite que los Xlets, puedan obtener su repositorio principal; javax.tv.locator: proporciona una forma para referenciar datos en programas accesibles por la API JavaTV; javax.tv.media: define una extensin para JMF (Java Media Framework) con la finalidad de gestionar los medios de comunicacin en tiempo real; javax.tv.media.protocol: proporciona acceso a un flujo de datos broadcast genrico; javax.tv.net: permite acceso a datagramas IP (Internet Protocol) transmitidos en un stream broadcast; javax.tv.service: proporciona mecanismos para accesar a la base de datos; javax.tv.util: soporta la creacin y gestion de eventos del temporizador; javax.tv.xlet: proporciona interfaces para el desarrollo de aplicaciones y la comunicacin entre las aplicaciones y el administrador.

25

3.3.2. API DAVIC El sistema DAVIC (Digital Audio Visual Council) es un conjunto de especificaciones que presenta algunos requisitos de sistemas audiovisuales para proporcionar interoperabilidad de extremo a extremo. As, estos patrones se pueden utilizar en sistemas de televisin digital para proporcionar contenido al usuario final y tambin para permitir la interactividad con el mismo usuario [14]. El sistema DAVIC tiene su propio API, y por lo tanto puede ser considerado middleware como de alto nivel (aunque es comn que empiecen a operar en conjunto con un middleware de bajo nivel). A continuacin se enumeran los paquetes que forman parte de la API DAVIC incluido en el Ginga-J [14]: org.davic.media org.davic.resources org.davic.mpeg org.davic.mpeg.sections org.davic.net org.davic.net.dvb org.davic.net.tuning

3.3.3. API HAVi HAVi (Home Audio Video Interoperability) es un API que permite al programador crear elementos, como la interfaz del usuario. Provee una extensin del paquete java.awt, permitiendo, asimismo, soporte de control remoto, transparencia, entre otros. El objetivo principal de una interfaz de usuario es proporcionar un entorno operativo fcil de usar. La arquitectura HAVi permite que los usuarios controlen dispositivos de forma familiar a travs de un control remoto o delante de una pantalla. A continuacin se enumeran los paquetes que forman parte de la API HAVi incluido en la Ginga-J [14]: org.havi.ui org.havi.ui.event

3.3.4. API DVB En el desarrollo del middleware patron MHP, el DVB incluye algunos paquetes para extender la funcionalidad ofrecida por JavaTV, HAVi y DAVIC. Estas 26

caractersticas incluyen API de informacin de servicio, de intercomunicacin entre Xlets, persistencia, etc. Algunas de las caractersticas tambin se incluyeron en el GEM. A continuacin se enumeran los paquetes que forman parte de la API DVB incluida en la Ginga-J [14]: org.dvb.application org.dvb.dsmcc org.dvb.event org.dvb.io.ixc org.dvb.io.persistent org.dvb.lang org.dvb.media org.dvb.net org.dvb.net.tuning org.dvb.net.rc org.dvb.test org.dvb.ui

3.4. Ambientes de Emulacin para la Programacin de GINGA En la Figura 3.8 se ilustran las opciones para el desarrollo de aplicativos, los cuales pueden ser: Nivel de interactividad (interactividad local o remota). Desarrollador (emisora o usuario). Ambiente de ejecucin.

Figura 3.8. Directrices principales para el desarrollo de aplicativos para TV digital 27

Las aplicaciones pueden ser desarrolladas tanto por emisoras de televisin como por los usuarios. En el caso que sea desarrollada por una emisora, la aplicacin ser enviada al Set Top Box, a travs de un canal de transmisin. En el caso de ser desarrollada por el usuario esta tendr que ser enviada al Set Top Box a travs de una entrada externa (USB portable, puerta de red, tarjeta de memoria, etc.) Una vez definido el nivel de interactividad y de desarrollo, se debe definir, el ambiente de ejecucin. Ginga ofrece dos ambientes de ejecucin: para aplicaciones declarativas Ginga-NCL y para aplicaciones no-declarativas Ginga-J. El lenguaje de programacin declarativo son lenguajes de alto nivel de abstraccin, usualmente ligada a un dominio u objetivo especfico. All, el programador slo proporciona el conjunto de tareas a realizar, no se ocupa de los detalles de cmo el ejecutor (intrprete, compilador u otra mquina virtual de ejecucin) realmente implementara esas tareas. En una programacin no declarativa, debemos informar cada paso a ser ejecutado. Se puede afirmar que el programador posee un nivel alto de conocimiento sobre el cdigo, siendo capaz de establecer todo el flujo de control y ejecucin de su programa. Con el desarrollo de aplicaciones, nivel de interactividad y el ambiente de ejecucin definidas, se puede, definir los pasos siguientes para crear estos aplicativos. El diagrama de la Figura 3.9 se ilustra las opciones que el desarrollador tiene disponible en cada ambiente para implementar los niveles de interactividad.

Figura 3.9. Diagrama con las opciones de desarrollo 28

En el ambiente Ginga-NCL, podemos crear objetos que sern exhibidos a travs del Formateador NCL, estos objetos tambin son llamados Nodo de contenido, estos pueden ser: Objetos de Mdia: que hace referencia a un elemento de comunicacin como video, audio, imagen, texto, etc. Objetos XHTML: que hace referencia a un elemento XHTML. Objetos Lua: que referencia un elemento para dar soporte a la programacin no declarativa utilizando script Lua. En el ambiente de ejecucin de Xlets, o Ginga-J, se define la cantidad de Xlets necesarios. Esta cantidad depende del nmero de caractersticas distintivas que se llevarn a cabo para resolver el problema. Se recomienda crear un Xlet para cada funcin especfica, por ejemplo, en la Figura 3.10 se ilustra una aplicacin interactiva de un programa deportivo, para el cual se han desarrollado los siguientes Xlets: xlet1: Visin de la cmara xlet2: Propaganda xlet3: 100 m planos xlet4: Salto con garrocha xlet5: Lanzamiento de Martillo xlet6: Salto alto xlet7: Lanzamiento de dardo xlet8: Seleccin de cmaras

Para que el desarrollador pueda crear las ocho (8), este debe definir que API es la ms adecuada y que soporte las caractersticas que se requieren implementar.

Figura 3.10. Pantalla exhibiendo varias Xlets. 29

Como suele ser difcil para un desarrollador de tener una red de televisin digital experimental, disponible en la mayora de los casos, el medio ambiente es simulado con el uso de las estaciones de prueba o con emuladores de software. Para el desarrollo de aplicaciones existen varios emuladores, que simulan el papel del middleware, entre ellos el ms utilizado para el ambiente Ginga-J es el XleTView,y para el ambiente Ginga-NCL.el Virtual Set Top Box. 3.4.1 Emulador GINGA-J: XLetView XletView, es un emulador usado para ejecutar Xlets en una PC, es de cdigo abierto, y esta bajo la licencia de software libre GPL (General Public License), adems de tener una implementacin de referencia a la API JavaTV, trae consigo implementaciones de otras APIs especificadas en el estndar MHP (Multimedia Home Platform), como HAVI (Home Audio Video Interoperability), DAVIC (Digital Audio Video Council) e implementaciones especificadas por la propia DVB ( Digital Video Broadcasting), adems de las bibliotecas de PersonalJava. Versiones actualizadas del XletView puede ser descargado libremente en la direccin electrnica: http://www.xletview.org/. XletView est desarrollado en Java y para su ejecucin independientemente del sistema operativo, es necesario utilizar el Java 2 Standard Development Kit para compilar Xlets y ejecutar el XletView. Este emulador utiliza la JMF (Java Media Framework) 2.1.1, pero con algunas deficiencias, como la incapacidad de exhibir video MPEG (Moving Picture Grupo de expertos) relacionados o controlados por un Xlet. Un Xlet, es una aplicacin Java que proporciona interactividad para la TV digital. Es similar a un applet, que es adicionado en paginas HTML, el Xlet es incluido en un servicio de TV digital. El middleware identifica un puente de entrada a la aplicacin y ejecuta la aplicacin utilizando la maquina virtual de Java. En la Figura 3.11 se ilustra la interface del XletView.

30

Figura 3.11. Interface XletView. Con el propsito de utilizar el Emulador de Set-Top-Box para Ginga-J, usando la interface XletView, a continuacin se desarrollara un aplicativo para TV digital utilizando el API JavaTV, el cual introduce el concepto de Xlet, que son aplicaciones en Java. La aplicacin consiste en utilizar el Emulador del Set-Top-Box para Ginga-J, para ejecutar una aplicacin, la cual mostrara en la pantalla un texto inicial, y enseguida este texto, cambiara para otro, equivalente al botn presionado por el control remoto. Para la ejecucin de un aplicativo Xlet, es necesario tener instalado los siguientes programas y libreras: Java 2 Standard Development Kit (jdk-6u2-windos-i586-p): el cual se puede descargar de: http://java.sun.com/j2e/index.jsp. Ambiente de ejecucin para el desarrollo Java. IDE (Integrated Development Enviroment): es un ambiente integrado de desarrollo, y un programa de computador que rene las caractersticas y herramientas de apoyo al desarrollo de software con el objetivo de agilizar este proceso. El IDE a utilizar es el Eclipse, el cual puede ser descargado de: http://eclipse.org JavaTV Api (api_itv-1_o-src): se descarga del siguiente link: http://java.sun.com/products/javatv/index.jsp, JavaTv es un Api que nos ofrece un conjunto de clases e interfaces a fin de proveer funcionalidades y servicios interactivos de TV para el Set Top Box.

31

XletView

(xletview-o.3.6):

descargar

del

siguiente

link:

http://www.xletview.org/ , Emulador para las aplicaciones Xlet.

El

cdigo

fuente

para

esta

aplicacin,

se

nombrado

como

ExemploXlet.java, el cual se encuentra en el ANEXO A. Debido a que el XletView solo acepta archivos .class (Xlets), para ser ejecutados, se utilizara la librera XletView.jar, que incluye recursos de la plataforma HAVi (Home Audio Video Interoperability). El XletView.jar es una librera Java de componentes grficos desarrollados especialmente para la creacin de interfaces para ambientes de TV. Para testear las aplicaciones haremos uso de la clase HscenseFactory y Hscene del API HAVi. El IDE Eclipse convierte los archivos .java en archivos .class, que son lo que van a utilizar. En la Figura 3.12 se ilustra, como los archivos .class y las libreras javatv.jar y xletview.jar son incluidas en el Build Path de Java.

Figura 312. IDE Eclipse: Java Build Path para incluir las libreras javav.jar y xletview.jar. Para realizar el teste con el emulador, se ejecuta el XletView.jar, que se encuentra en el directorio donde fue descargado, haciendo doble click sobre el archivo. En la Figura 3.13 se ilustra la pantalla inicial del XletView.

32

Figura 3.13. Pantalla inicial del XletView Enseguida, se ejecutara el archivo que contiene nuestro programa ExemploXlet.class. Para este propsito, en la interface de la Figura 3.13, ir al men Applications, luego a Manager applications, como ilustrado en la Figura 3.14.

Figura 3.14. Pantalla del Administrador de aplicaciones. Para cargar un Xlet en el Emulador del Set-Top-Box, se debe llamarlo dentro de la carpeta Default Group, un directorio nativo de XletView. As tambin, se puede crear otro subdirectorio haciendo click en New Group, construyendo un grupo particular de xlets. Enseguida, se cargar la xlet, dentro del Default Group, haciendo click en New Application, luego en new app 1, con lo que aparecer en el lado derecho tres cajas de texto, como se ilustra en la Figura 3.15, las cuales deben ser editadas para la ejecucin del xlet. Name: Nombre del proyecto, con que la Xlet se mostrara en el men aplicaciones. Path (ruta): Directorio donde se encuentra la Xlet. 33

Xlet: Archivo .class de la aplicacin que ser cargada.

Figura 3.15. Introducir informacin en una Xlet. Enseguida, se procede a cambiar el nombre del proyecto si es necesario, indicar la ruta donde se encuentra el archivo .class y por ltimo el nombre del archivo. Finalmente, hacer click en el botn save & close. En la Figura 3.16, se ilustran las cajas de texto editadas.

Figura 3.16. Pantalla con el nombre, ruta y nombre del archivo editados. Luego de realizar la configuracin, se procede a ejecutar la aplicacin, haciendo click en el men Applications, el cual despliega una lista de las aplicaciones cargadas. Enseguida hacer click en la aplicacin escogida, en este caso la aplicacin con el nombre Hola Mundo, como se ilustra en la Figura 3.17.

34

Figura 3.17. Eleccin de la aplicacin de nombre Hola Mundo. En la Figura 3.18 se ilustra la pantalla inicial de la aplicacin, en la cual muestran dos textos Hola Mundo Java y Control Remoto. En esta aplicacin, el texto Control Remoto, cambiara a otro texto conforme se presione un botn del control remoto. Por ejemplo, si se presiona el botn nmero 2 del control remoto, el nuevo texto, ser: Boton Numerico: 2, como ilustrado en la Figura 3.19. Para regresar a la pantalla inicial de la aplicacin, hacer click en Applications, y escoger la opcin Reload Current, reiniciando la aplicacin a su estado inicial. Para cerrar el emulador haga click en Men y luego escoger Exit Alt+F4.

Figura 3.18. Visualizacin inicial de la aplicacin al ser ejecutada.

Figura 3.19. Pantalla en que aparece el nombre del botn clicleado. En este caso, el botn nmero 2.

3.4.2. Emulador GINGA-NCL: Set-Top-Box Virtual Set Top Box Virtual Ginga-NCL es una mquina virtual construida para facilitar el proceso de distribucin e implantacin de Ginga-NCL versin C++, en versin del reproductor del NCL, que consta con las caractersticas ms avanzadas de

35

presentacin de aplicaciones declarativas, mejor rendimiento y mayor proximidad a una aplicacin real embebida en un Set Top Box. El Emulador Set Top Box Virtual Ginga-NCL puede ser descargado de la direccin electrnica: http://elclub.ncl.org.br/node/36. La mquina virtual fedora-fc7-ginga-i386 Set Top Box Virtual fue creada y configurada por el equipo de Laboratorio TeleMdia de la Pontificia Universidad Catlica de Rio de Janeiro (PUC-Rio, Brasil), utilizando el software VMWare Workstation 6. El VMvare Workstation puede ser descargado de la siguiente direccin electrnica: http://www.vmware.com/products/workstation/index.html. La maquina virtual, presenta como principales ventajas: Fcil instalacin, no se requiere realiza configuraciones de kernel, ni de boot. Portabilidad entre diferentes sistemas operativos. Optimo ambiente de pruebas de aplicaciones NCL/NCLua Ambiente completo para los desarrolladores del propio middleware.

Para simular una aplicacin en el Set Top Box Virtual, es necesario tener instalado los siguientes programas Software de virtualizacin: VMWare Player (Windows Linux). VMWare Workstation (Windows Linux) VMWare Fusion (Mac OS X) Maquina Virtual fedora-fc7-ginga-i386.zip

Despus de descargar la maquina virtual fedora-fc7-ginga-i386.zip, descomprimir el archivo en un directorio del disco duro, ejecutar el VMware Worstation, y hacer click en Open Existing VM or Team, y escoger el archivo fedora-fc7-ginga-i386.vmx, inicindose la instalacin, como se ilustra en la Figura 3.20.

36

Figura 3.20. Archivo para instalacin del Set Top Box virtual en el VMware. Al ejecutar la mquina virtual, se iniciara un proceso de arranque. No modifique la seleccin predeterminada en el gestor de arranque (GRUB). As, el ncleo y toda la configuracin grafica del Set Top Box sern cargados. La opcin por defecto es Ginga-NCL Development Set-Top-Box v.x.x.xx. En la Figura 3.21 se ilustra la aplicacin cargando el Grub por defecto.

Figura 3.21. Cargando el Ginga-NCL Development Set-Top-Box v.8.9.28. Enseguida, aparecer la pantalla con la inicializacin del Ginga-NCL Set Top Box, como ilustrado en la Figura 3.22. En esta pantalla se proporciona informacin referente a: Cul es el mapeamiento usado por Ginga-NCL para las teclas de control remoto sobre el teclado de la PC. Cul es la direccin IP automticamente asociado al Set Top Box. El usuario y password con el que se podr conectar va ssh y SCP. La direccin del directorio donde se cargaran las aplicaciones, etc.

37

Figura 3.22. Inicializacin del Set Top Box virtual Ginga-NCL. Enseguida, se construyen dos archivos para implementar una aplicacin de un juego llamado HACKERTEEN PROTOTYPE [15], como se ilustra en la Figura 3.23, que tiene las siguientes reglas: El juego tiene reglas sencillas. Se compone de una baraja de 25 cartas (5 copias de las 5 cartas numeradas del 1 al 5). Cada jugador empieza con 5 tarjetas aleatorias. El espectador asume el papel de Yago y slo puede ver las 5 cartas de el hroe. l juega contra la computadora, que controla Impius. Los personajes se colocan en la pantalla en un tablero con 23 posiciones. Yago es el primero en jugar, y, posteriormente, Impius y as sucesivamente. En su turno de juego, un personaje que usa una tarjeta y se desplaza al nmero de las posiciones indicadas por la tarjeta elegida. Cuando un jugador utiliza una tarjeta que indica el nmero exacto de las posiciones para llegar a su rival, est actuando como un atacante de un duelo. Un duelo es un desafo intelectual en el mbito de Internet. El atacante muestra todas las cartas que posee con la distancia exacta a la rival. Si tiene ms cartas del mismo valor que el defensor, gana el duelo. Para evitar la prdida, el defensor debe mostrar el mismo nmero de tarjetas que el atacante mostr. En este caso, el defensor es el siguiente en el juego y ambos jugadores reciben cartas de la baraja para completar nuevamente una mano de 5 cartas. 38

Hay algunas reglas adicionales. Un personaje no puede utilizar una tarjeta con un valor mayor que su distancia al rival. Si un personaje no puede usar las cartas de su mano, pierde automticamente. Cuando la cubierta se vace (el nmero de cartas en la baraja se muestra en la esquina inferior derecha de la pantalla), el jugador con ms posiciones gana. En caso de un empate, Impius gana.

El ganador del juego es quien gana tres desafos. Los puntos se muestran en la pantalla.

Los archivos que contienen los cdigo fuente para implementar esta aplicacin se encuentran en el ANEXO B y sern ejecutados en el Set Top Box Virtual: main.ncl hackerteen.lua

Figura 3.23. Juego HACKERTEEN PROTOTYPE ejecutndose en el Set-TopBox Virtual usando Ginga-NCL. Para poder cargar una aplicacin en el Set Top Box Virtual, se tendr que contar con el WinSCP, al ejecutar lo aparecer la pantalla que aparece en el Figura 3.24, en la cual se tendr que colocar la direccin IP, del Set Top Box virtual, luego hacer un click en el botn Login.

39

Figura 3.24. Pantalla de conexin al Set Top Box Virtual. Enseguida, aparecer una pantalla en la cual se solicitara el nombre de usuario y el password, para poder logearse e ingresar al Set Top Box Virtual. Username: root Password: telemidia

Con los permisos respectivos, enseguida, se tiene una nueva interface, como ilustrado en la Figura 3.25, en la cual se pueden cargar las aplicaciones NCL, que se encuentran en el lado izquierdo de la interfaz (el cual por defecto hace referencia a la unidad C de la PC). En el lado derecho de esta interface, se tiene el directorio del Set Top Box Virtual. Las aplicaciones desarrolladas, deben ser copiadas en el directorio del Set-Top-Box virtual /misc/ncl30.

Figura 3.25. Interface en la que se muestra el directorio de la PC y el directorio del Set Top Box Virtual. Una vez copiado la aplicacin en el directorio del Set Top Box Virtual, se proceder a ejecutarlo. Para este propsito, se utilizara la herramienta llamada Putty, el cual tambin se conectara al Set Top Box Virtual, del mismo modo como se 40

conecto con el WinSCP, con la misma IP, usuario y password. En la Figura 3.26 se ilustra el programa putty conectado con el Set Top Box Virtual.

Figura 3.26. Putty conectado al Set Top Box Virtual. Enseguida, se proceder a colocar los comandos necesarios para ejecutar la aplicacin, como se ilustra en la Figura 3.27.

Figura 3.27. Comando para ejecutar la aplicacin: /misc/launcher.sh /misc/ncl30/carpeta del archivo/archivo.ncl. En la Figura 3.28 se ilustra la aplicacin ejecutndose dentro del Set top Box Virtual.

Figura 3.28. Aplicacin ejecutndose dentro del Set Top Box Virtual.

41

CAPITULO IV APLICACIONES ITERATIVAS - DEFINCIONES 4.1. Introduccin La televisin digital es hoy uno de los mayores medios de comunicacin del mundo, proporcionando para el espectador fuente de informacin, entretenimiento y cultura. Siguiendo la tendencia mundial del movimiento de digitalizacin como en los diversos medios de comunicacin, la televisin est pasando por un proceso de substitucin de sus plataformas analgicas por plataformas y tecnologas digitales. Este cambio est provocando una onda de impacto en todo el mundo, as como tambin en el Per. Con la tecnologa de TV Digital, hay una ganancia considerable en trminos de resolucin de la imagen (alta definicin) y calidad del sonido adems de la posibilidad de transmisin de varios programas en un nico canal. Entretanto, la principal caractersticas de la TV Digital es la capacidad de permitir interactividad entre el usuario telespectador y la emisora de programacin. Actividades como el acceso al men de programacin de la emisora, realizar compras de productos (t-commerce), acceso a cuentas bancarias, participar en encuestas, votar, escoger un mejor ngulo de visin en transmisiones de eventos deportivos, ver nuevamente las pelculas y programas, seleccionar msica para escuchar, enviar y recibir e-mails, etc, pasan a hacer parte del conjunto de recursos interactivos posibles. El desarrollo de todas esas aplicaciones solo es posible gracias a una camada de software intermedio presente en la arquitectura de los padrones de los sistemas de televisin digital llamada middleware. El middleware, tiene como finalidad ofrecer un servicio personalizado para las aplicaciones, escondiendo las peculariedades y heterogeneidades de las camadas inferiores (tecnologas de compresin, de transporte y de modulacin) viabilizan as el desarrollo de las aplicaciones de forma independiente del hardware de los fabricantes de los terminales de acceso a la seal digital (set-top-box). El SBTDV posee como middleware, el Ginga, que permite el desarrollo de aplicaciones digitales interactivas tanto en el lenguaje declarativo NCL (Nested Context Language) como procedural como el lenguaje Java a travs de dos subsistemas lgicos denominados, respectivamente, de Ginga-NCL y Ginga-J.

42

4.2. Componentes de la TV Interactiva Segn STEUER [1992], interactividad mide cuanto un usuario puede influenciar en la modificacin inmediata, en la forma y el contenido de un ambiente computacional. El termino es conceptuado como una variable basada en el tiempo de respuesta del estimulo. Por lo tanto, libros, revistas y TV abierta son caracterizados como medios poco interactivos, al contrario de teleconferencia, e-mail y videogame. La interactividad es el intercambio entre el usuario y un sistema computacional por medio de un terminal dotado de pantalla de visualizacin [KOOGAN & HOUAISS, 1999]. De esta forma, el usuario puede interactuar alterando la forma y el contenido del ambiente mediado en el tiempo. EL sistema de televisin brasileo que conocemos hoy es meramente reactivo, pues los tele-espectadores apenas reaccionan a los estmulos ofrecidos por la emisora. En la TV verdaderamente interactiva, el telespectador se comunica con la emisora a travs de un canal de interactividad (canal de retorno). En la TV digital, el concepto de interactividad se define como la posibilidad que el usuario tiene para influenciar en la forma y en el contenido de lo que est asistiendo, pudiendo comunicarse y realizar intervenciones a travs de los servicios y aplicaciones disponibles. Para tener una visin general del proceso de interactividad, en la Figura 4.1 se ilustra un modelo genrico de un sistema de televisin digital, el cual est compuesto por tres componentes: Un transmisor o difusor que es responsable por proveer servicios de entretenimiento e interaccin para los usuarios Un canal de difusin que es responsable por la entrega correcta de los datos y Un receptor que recibe el contenido televisivo y posibilita la interaccin con el transmisor [SOUZA, 2004].

43

Figura 4.1. Componentes de la TV Digital Interactiva El contenido televisivo que pueden ser flujos de audio, video o datos son transmitidos por millares de estaciones y recibidos por aparatos digitales de televisin o por los STB (Set-Top-Box). El STB es responsable por hacer la conversin de seal digitalizada para TV analgica adems de poseer un canal de retorno para ofrecer la interactividad entre el emisor y telespectador. Es constituida por componentes de software (sistema operacional y ambiente que ejecuta los programas interactivos) y hardware especifico [13]. El canal de retorno (canal de interaccin) es quien posibilita la comunicacin entre el receptor y el difusor. De acuerdo con la existencia o no del canal de retorno, los niveles de interactividad son clasificados en: a) Interactividad Local: no utiliza el canal de retorno. Pueden ser realizadas interacciones como: configuracin de leyendas, juegos residentes y acceso a la gua de programacin electrnica. b) Interactividad Remota: utiliza el canal de retorno. Pueden ser realizadas interacciones como: comercio electrnico, acceso a cuentas bancarias, servicios de salud y aplicaciones para educacin a distancia. Unidireccional: permite al receptor apenas el envi de datos (upload). Por ejemplo: la compra de un determinado producto, votacin e investigacin de opinin. Bidireccional: adems de enviar datos, permite al receptor realizar la carga de datos (download) utilizados por los aplicativos. Por ejemplo: navegacin en internet, e-mail, chat, juegos online y la comunicacin entre los usuarios.

44

4.3. Aplicaciones de Interactividad En la camada de interactividad, se realiza la captura y formatacin de las seales de audio y video, as como la ejecucin de los aplicativos multimedios desarrollados. En este panorama, a continuacin se tiene una lista de aplicaciones que se pueden dar en televisin digital iterativa: EPG (Electronic Program Guide): programa de gua para contenidos digitales. Con esta gua, el telespectador puede navegar por el conjunto de programas y servicios ofrecidos y escoger el que ms le agrada. Se puede seleccionar un canal convencional o comprar un video prealmacenado para asistir. T-GOVERN: son servicios gubernamentales via TV. Ofrece servicios importantes, evitando el deplazamiento a notarios o puestos de informacin, y consultas sobre la disponibilidad de programas del gobierno, T-COMMERCE O COMERCIO TELEVISIVO: el consumidor tiene la oportunidad de adquirir productos anunciados directamente por la TV, sin la necesidad de accesar a la pgina web de la empresa o desplazarse hasta las tiendas. INTERNET: Aplicacin que permite acelerar el proceso de inclusin digital.

45

CAPITULO V STB COMERCIALES - ESPECIFICACIONES 5.1. Introduccin En esta seccin se han identificado algunos de los Set-Top-Box Comerciales en el BRASIL, para televisin digital terrestre usando el estndar ISDB-T. Se debe destacar que en el Per, hasta la fecha aun no se estn comercializando set-top-box. 5.2. Receptores de TV digital Set-Top-Box en el Brasil Entre las marcas de receptores de TV digital en el Brasil estn: Set Top Box para Televisin Fija Set Top Box para aplicaciones vehiculares DVD Receptores USB

5.2.1. Marca PROVIEW XPS1000 Comercializado en el Brasil Receptor TV Digital Proview Xps1000 Set Top Box Compatible con el estndar ISDB-Tb Alta definicin de decodificacin de audio AAC/WE AAC video H.264 Salida HDMI 1080i Salida de video analgica de alta definicin video componente 1080i Salida de video analgica video compuesto 480p/480i Salida de audio digital SPDIF Coaxial OSD (On Screen Display) en portugus con interface grafica Interface de Ethernet 100Mbs Actualizacin de software va USB EPG (Gua de programacin electrnica) Control remoto Puerta USB compatible con teclado y mouse Navegacin en la internet con mini-browser y acceso remoto a cliente/servidor va VNC.

46

Figura 5.1. Receptor de TV digital PROVIEW. 5.2.2. Marca PROVIEW XPS1000i Interactivo Comercializado en el Brasil Receptor TV Digital Proview Xps1000i Set Top Box Interactivo Compatible con el estndar ISDB-Tb Nivel de salida de entrada: -75dBm~-20dBm HDMI: 1080i Y/Pb/Pr: 1080i Interface Ethernet: 100Mb Puerto USB 2.0 Recepcin de antena UHF Banda de transmisin 6MHz Aspecto 16:9/4:3 EPG (Guia de Programacin Electronica) Interactividad

Figura 5.2. Receptor de TV digital PROVIEW con Interactividad.

47

5.2.3. Marca INVIX Comercializado en el Brasil Receptor de TV digital Vehicular INVIX ISC-150B para DVD Utilizado en todas las marcas y modelos de DVDs o pantallas LCD entre 3.5 y 14 pulgadas. Imagen con calidad de DVD con vehculo en movimiento Modulacin ISDB-T (1-seg) Frecuencia: UHF: 470 MHz ~ 806 MHz Canales: 14 ~ 69 Formato de video: MPEG-4 AVC/H.264@1.3 Relacin de Aspecto (Vertical/Horizontal): 16:9 o 4:3 5, 10, 12, 15, 24, 30 cuadros por segundo Formato de audio: MPEG4 AAC Canales de audio / Multi-idioma: estreo/ multi-idiomas

5.3. Receptor de TV digital vehicular INVIX 5.2.4. Marca MIXLASER Comercializado en el Brasil Receptor TV Digital USB Antena telescpica para ambientes externos e internos Modulacin de RF: BST-OFDM em QPSK, 16 QAM Canales 1 seg UHF Sensibilidad -98dBm (QPSK, CD1/2) Formatos de compresin H.264/AVC Baseline Profile nvel 1.3 Razn de aspecto: 4:3 o 16:9 Decodificacin de audio: MPEG4 HE-AAC+SBR+SP v.2 L2 estreo 48

Figura 5.4. Receptor de TV Digital MIXLASER USB.

49

REFERENCIAS [1] [2] Silveira Dias C.E., Cunha L.L.E, Lemos G.S.F., A implementao de SetTop-Box para TVI, Paulo Muniz de vila, Sergio Donizetti Zorzo. A personalized TV Guide System - An Approach to Interactive Digital Television, Proceedings of the 2009 IEEE International Conference on Systems, Man, and Cybernetics San Antonio, TX, USA - October 2009. Moreno, Jos; Comunicaciones aplicadas a la domotica, 2008. Disponible en internet, en: http://www.utm.mx/~edith/070808.pdf y accesado el 28/01/2010. Oliveira, Mauro; Gonalves, C.H.; Figueiredo, M.V.C.; Tonieto, Mrcia. DIGA GINGA-Digital Automation in Monitoring and Control using GINGA technology 2008. OLIVEIRA, Mauro; HIRON, Carlos; VINICIUS, Marcos; TONIETO, Marcia.Implementing Applications for the Brazilian Digital TV, Disponible en internet, en http://mauro.cefetce.br/Premios/2009%20Implementing%20Brasilian%20DT V.pdf , y accesado el 03/02/2010 RIBEIRO, Jean. Middleware Ginga, Escola de Engenharia Universidade Federal Fluminense (UFF), Rua Passo da Ptria, 156 Niteri RJ Brasil. Disponible en internet, en : http://www.midiacom.uff.br/~debora/fsmm/trab2008-2/middleware.pdf y accesado el 01/02/2010. ALBUQUERQUE, Antonio; LOPES, Joo. A TV Digital no Brasil e o Desenvolvimento de Aplicaes Interativas para o Middleware Ginga, Departamento de Computao, Universidade Federal de Sergipe, 2008. SOARES, Luiz; RODRIGUES, Rogrio; MORENO, Mrcio. Ginga-NCL: the Declarative Environment of the Brazilian Digital TV System. JCBS. N. 1; Vol. 13; Mar. 2007. Laboratrio de Telemdia. Ambiente para Desenvolvimento de Aplicaes Declarativas para a TV Digital. Laboratrio Telemdia. Departamento de Informtica. PUC-RIO. Disponible en Internet, en: http://www.ncl.org.br/documentos/MDIC2007.pdf (acessado el 29/01/2010) CRUZ, Vitor Medina; MORENO, Marcio Ferreira; SOARES, Luis Fernando Gomes. TV Digital para Dispositivos Portteis Middlewares. PUC-RIO. Janeiro 2008. Disponible en internet, en: http://www.ncl.org.br/documentos/TVDigitalParaDispositivosPortateis.pdf (accesado el 29/01/2010). IERUSALIMSCHY, Roberto; FIQUEREIDO, Luiz; CELES, Waldemar. Manual de Referncia de Lua 5.1. PUC-Rio, 2008. Disponible en internet, en: http://www.lua.org/manual/5.1/es/ (accesado el 28/01/2010). MORENO, Mrcio Ferreira. Um Middleware Declarativo para Sistemas de TV Digital Interativa. Dissertao de Mestrado. abr. 2006. Rio de Janeiro: PUC-Rio. FERNANDEZ, J.; LEMOS, Guido.; SILVEIRA, G. Introduo Televiso Digital Interativa: Arquitetura, Protocolos, Padres e Prticas. In JAI-SBC. Salvador, 2004. Projeto de Norma ABNT 00:001.85-006/4 - Televiso digital terrestre Codificao de dados e especificaes de transmisso para transmisso digital Parte 4: Ginga-J - Ambiente para a execuo de aplicaes procedurais. Club NCL, http://elclub.ncl.org.br/taxonomy/term/12 (accesado 10/02/2010). 50

[3] [4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

ANEXO A APLICACIN XLETVIEW A.1 Cdigo de Programa Aplicacin XletView.


import import import import import java.awt.*; java.awt.event.*; javax.tv.xlet.*; org.havi.ui.*; org.havi.ui.event.*;

public class ExemploXlet implements Xlet, KeyListener { private XletContext context; private HScene scene; private HStaticText label1, label2; public ExemploXlet() { /* Mtodo vacio */} public void initXlet(XletContext xletContext) throws XletStateChangeException { /* guardando el contexto... */ this.context = xletContext; } public void startXlet() throws XletStateChangeException { HSceneFactory hsceneFactory = HSceneFactory.getInstance(); scene=hsceneFactory.getFullScreenScene(HScreen.getDefaultHScreen(). getDefaultHGraphicsDevice()); scene.setSize(640, 480); scene.setLayout(null); scene.addKeyListener(this); //el prpio Xlet es el oyente label1 = new HStaticText("Hola Mundo Java", 35, 45, 660, 50, new Font("Tiresias", 1, 36), Color.red, Color.white, new HDefaultTextLayoutManager()); label2 = new HStaticText("Control Remoto", 100, 135, 500, 30, new Font("Tiresias", 1, 36), Color.red, Color.white, new HDefaultTextLayoutManager()); scene.add(label1); scene.add(label2); scene.setVisible(true); scene.requestFocus(); } public void pauseXlet() { /* Mtodo vacio */} public void destroyXlet(boolean unconditional) throws XletStateChangeException { if (scene!=null) { scene.setVisible(false); scene.removeAll(); scene = null; } context.notifyDestroyed(); } /* Mtodo de java.awt.event.KeyListener */ public void keyTyped(KeyEvent keyevent) { /* Mtodo vacio */ } /* Mtodo de java.awt.event.KeyListener */ public void keyReleased(KeyEvent keyevent) {

51

/* Mtodo vacio */} /* Mtodo de java.awt.event.KeyListener */ public void keyPressed(KeyEvent e) { String mensagem = ""; int codigo = e.getKeyCode(); switch (codigo) { case 48: case 49: case 50: case 51: case 52: case 53: case 54: case 55: case 56: case 57: mensagem += break; case 403: mensagem += break; case 404: mensagem += break; case 405: mensagem += break; case 406: mensagem += break; case 27: mensagem += break; case 10: mensagem += break; case 151: mensagem += break; case 520: mensagem += break; case 38: mensagem += break; case 40: mensagem += break; case 37: mensagem += break; case 39: mensagem += break; default: mensagem += }

"Bot\u00F4n num\u00E9rico: "+(codigo-48);

"Bot\u00F4n Rojo";

"Bot\u00F4n Verde";

"Bot\u00F4n Amarillo";

"Bot\u00F4n Azul";

"Bot\u00F4n EXIT";

"Bot\u00F4n OK";

"Bot\u00F4n Asterisco (*)";

"Bot\uu00F4n Michi (#)";

"Arriba";

"Abajo";

"Izquierda";

"Derecha";

"Hola Mundo Java";

label2 = new HStaticText(mensagem, 100, 135, 500, 30, new Font("Tiresias", 1, 36), Color.blue, Color.white, new HDefaultTextLayoutManager()); scene.removeAll(); scene.add(label1); scene.add(label2); label2.repaint(); scene.repaint(); } }

52

ANEXO B APLICACIN VIRTUAL SET-TOP-BOX B.1 Archivo: main.ncl


<?xml version="1.0" encoding="ISO-8859-1"?> <!-- Generated by NCL Eclipse --> <ncl id="main" xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"> <head> <regionBase> <region id="rgFullScreen"> <region id="rgVideo" zIndex="3" left="26" top="42" width="250" height="141"/> <region id="rgGame" width="640" height="480" zIndex="1"/> <region id="rgIntro" zIndex="2"/> </region> </regionBase> <transitionBase> <transition id="fadeOut" type="fade" dur="5s"/> </transitionBase> <descriptorBase> <descriptor id="dsHackerteen" region="rgGame" focusIndex="0"/> <descriptor id="dsVideo" region="rgVideo"/> <descriptor id="dsIntro" region="rgIntro" explicitDur="4s" transOut="fadeOut"/> </descriptorBase> <connectorBase> <causalConnector id="onBeginStart"> <simpleCondition role="onBegin"/> <simpleAction role="start"/> </causalConnector> <causalConnector id="onEndStart"> <simpleCondition role="onEnd"/> <simpleAction role="start"/> </causalConnector> </connectorBase> </head> <body> <port id="pIntro" component="intro"/> <media id="hackerteen" src="hackerteen.lua" descriptor="dsHackerteen"/> <media id="settings" type="application/x-ginga-settings"> <property name="currentKeyMaster" value="0"/> </media> <media id="video" src="videos/hackerteen.mp4" descriptor="dsVideo"/> <media id="intro" src="pictures/inicio.gif" descriptor="dsIntro"/> <link xconnector="onBeginStart"> <bind role="onBegin" component="intro"/> <bind role="start" component="video"/> </link> <link xconnector="onEndStart"> <bind role="onEnd" component="intro"/> <bind role="start" component="hackerteen"/> </link> </body> </ncl>

53

B.2. Archivo: hackerteen.lua


local deck, animation, player, cursor = {}, {}, {{},{}}, 1 -- draw card local function draw () return table.remove(deck) end -- game setup function setup() local W, H = canvas:attrSize() math.randomseed( os.time() ) player[1].hand = {} player[1].pos=1 player[1].x=(-10*W)/1024 player[1].y=(350*H)/768 player[1].pic=canvas:new("pictures/yago/Yago1.png") player[2].hand={} player[2].pos=23 player[2].x=(855*W)/1024 player[2].y=(350*H)/768 player[2].pic=canvas:new("pictures/impius/Impius1.png") -- deck building and shuffling deck = {} for i=1,5 do for j=1,5 do deck[ #deck+1 ] = j end end for i=1,300 do local j, k = math.random(#deck), math.random(#deck) deck[j], deck[k] = deck[k], deck[j] end -- draw starting hand for i=1,5 do player[1].hand[i], player[2].hand[i] = draw(), draw() end end -- draw screen function redraw() local W, H = canvas:attrSize() canvas:attrColor(0, 0, 0, 0) canvas:drawRect('fill', 0, 0, W, H) canvas:compose(0,0, canvas:new('pictures/fundo_final.gif') ) if player[1].score<3 and player[2].score<3 and player[1].hand[cursor] and player[1].pos + player[1].hand[cursor] <= player[2].pos then canvas:compose((player[1].pos + player[1].hand[cursor]1)*((43*W)/1024), (520*H)/768, canvas:new('pictures/estrela.png')) end if player[2].score<3 then canvas:compose(player[1].x, player[1].y, player[1].pic) end if player[1].score<3 then canvas:compose(player[2].x, player[2].y, player[2].pic) end canvas:compose((603*W)/1024, (159*H)/768, canvas:new( 'pictures/numbers/ponto' .. player[1].score .. '.gif' ) ) canvas:compose((710*W)/1024, (159*H)/768, canvas:new( 'pictures/numbers/ponto' .. player[2].score .. '.gif' ) ) if player[1].score<3 and player[2].score<3 then local fileName for i=1,5 do if player[1].hand[i] then fileName = 'pictures/carta' .. player[1].hand[i] .. '.png' canvas:compose( ((150*(i-1)+50)*W)/1024 , (635*H)/768, canvas:new(fileName) ) if cursor==i then if player[1].pos+player[1].hand[i]<=player[2].pos then fileName = 'pictures/C.png' else fileName = 'pictures/X.png' end

54

canvas:compose( ((150*(i-1)+50)*W)/1024, (630*H)/768, canvas:new(fileName) ) end end end fileName = 'pictures/deck2.png' canvas:compose((830*W)/1024, (630*H)/768 , canvas:new(fileName)) fileName = 'pictures/numbers/' .. #deck .. '.png' canvas:compose( (825*W)/1024, (580*H)/768, canvas:new(fileName)) end canvas:flush() end -- event handler function handler(evt) if evt.type=='presentation' and evt.class=='ncl' and evt.action=='start' then redraw() elseif evt.class=='user' then if player[1].lost then --print(' lost player 1 ') step(evt) setup() player[2].score = player[2].score + 1 player[1].lost = nil redraw() if player[2].score>=3 then createAnimation(typingAnimation) end elseif player[2].lost then --print(' lost player 2 ') step(evt) setup() player[1].score = player[1].score + 1 player[2].lost = nil redraw() if player[1].score>=3 then createAnimation(typingAnimation) end else step(evt) redraw() end elseif evt.class == 'key' and evt.type == 'press' then if player[1].score<3 and player[2].score<3 then if evt.key=='CURSOR_LEFT' then moveLeft() elseif evt.key=='CURSOR_RIGHT' then moveRight() elseif evt.key=='ENTER' then enter() elseif evt.key=='INFO' or evt.key=='RED' then event.post('out', {class='ncl', type='presentation', transition='stops'}) animation = {} end end redraw() end end -- starting function called once function start() setup() player[1].score = 0 player[2].score = 0 -- pictures moving player[1].moving = {} for i=1, 4 do player[1].moving[i] = 'pictures/yago/Yago' .. i .. '.png' end player[2].moving = {} for i=1, 4 do player[2].moving[i] = 'pictures/impius/Impius' .. i .. '.png' end -- pictures losing player[1].losing = {} for i=1, 13 do player[1].losing[i] = 'pictures/yago/YagoDuelo' .. i .. '.png' end player[2].losing = {} for i=1, 11 do player[2].losing[i] = 'pictures/impius/ImpiusDuelo' .. i .. '.png' end -- pictures running

55

player[1].running = {} for i=1, 11 do player[1].running[i] = 'pictures/yago/YagoCasas' .. i .. '.png' end player[2].running = {} for i=1, 11 do player[2].running[i] = 'pictures/impius/ImpiusCasas' .. i .. '.png' end -- pictures typing player[1].typing = {} for i=1, 21 do player[1].typing[i] = 'pictures/yago/YagoDigitando' .. i .. '.png' end player[2].typing = {} for i=1, 7 do player[2].typing[i] = 'pictures/impius/ImpiusDigitando' .. i .. '.png' end event.register( handler ) end -- moving animation function moving(pl, mv, timing, pics) local dt, finalPosition = 0, pl.x+mv local X, index = {}, 1 if pics==nil then pics = pl.moving end X[1] = pl.x + mv/#pics for i=2,#pics do X[i] = X[i-1] + mv/#pics end while true do pl.x = pl.x + (dt * mv) / timing pl.pic = canvas:new(pics[index]) if (mv>0 and pl.x > X[index]) or (mv<0 and pl.x < X[index]) then index = index + 1 end if index > #pics then pl.x = finalPosition pl.pic = canvas:new(pl.moving[1]) return true end dt = coroutine.yield() end end -- losing animation function losing(pl) local W, H = canvas:attrSize() player[1].x = player[1].x - (43*W)/1024 --if pl.x == player[2].x then player[2].x = player[2].x - (43*W)/1024 end for i=1,#pl.losing do pl.pic = canvas:new(pl.losing[i]) local totalTime = 0 while totalTime<300 do totalTime = totalTime + coroutine.yield() end end pl.pic = canvas:new(pl.moving[1]) pl.lost = true coroutine.yield() player[1].x = player[1].x + (43*W)/1024 return true end -- AI of Impius function chooseCard() local hand = {} for i=1,5 do if player[2].pos - player[2].hand[i] >= player[1].pos then hand[#hand+1] = player[2].hand[i] end end if #hand==0 then return nil else -- Impius always play the highest card local maxCard = hand[1] for i=2,#hand do maxCard = math.max(maxCard, hand[i]) end

56

return maxCard end end -- duell function function duell(atk, dfs) local card = math.abs(atk.pos-dfs.pos) local atkForce, dfsForce = 0, 0 for i=1,5 do atkForce = atkForce + ( (atk.hand[i]==card and 1) or 0 ) atk.hand[i] = draw() dfsForce = dfsForce + ( (dfs.hand[i]==card and 1) or 0 ) end if atkForce > dfsForce then return true end for i=1,5 do if dfs.hand[i]==card then dfs.hand[i] = draw() atkForce = atkForce - 1 if atkForce==0 then break end end end if #atk.hand~=5 or #dfs.hand~=5 then if math.abs(12-atk.pos) < math.abs(12-dfs.pos) then return true else return false end end return nil end -- typing animation in the game over function typingAnimation(pl) if not pl then return (player[1].score>=3 and typingAnimation(player[1])) or typingAnimation(player[2]) end for i=1,#pl.typing do pl.pic = canvas:new(pl.typing[i]) local totalTime = 0 while totalTime<200 do totalTime = totalTime + coroutine.yield() end end pl.pic = canvas:new(pl.moving[1]) return true end -- animation of both avatars typing function avatarsTyping() for i=1, math.min(#player[1].typing , #player[2].typing) do player[1].pic = canvas:new(player[1].typing[i]) player[2].pic = canvas:new(player[2].typing[i]) local totalTime = 0 while totalTime<200 do totalTime = totalTime + coroutine.yield() end end player[1].pic = canvas:new(player[1].moving[1]) player[2].pic = canvas:new(player[2].moving[1]) return true end -- basic cycle logics function run() local W, H = canvas:attrSize() local card = player[1].hand[ cursor ] if card + player[1].pos > player[2].pos then return true end if card + player[1].pos == player[2].pos then -- duelling avatarsTyping() local result = duell(player[1], player[2]) if result then return losing(player[2])

57

elseif result==false then return losing(player[1]) end else -- moving player[1] if card==1 then moving(player[1], (43*W)/1024, 800) else moving(player[1], ((43*card)*W)/1024, 400*card, player[1].running) end player[1].pos = player[1].pos + card --[[ for i=1,card do moving(player[1], (43*W)/1024, 1000) player[1].pos = player[1].pos+1 end --]] player[1].hand[ cursor ] = draw() if #player[1].hand~=5 then if player[1].pos > 22-player[2].pos then return losing(player[2]) else return losing(player[1]) end end end card = chooseCard() if not card then return losing(player[2]) end if player[2].pos - card == player[1].pos then -- duelling -- both avatars typing avatarsTyping() local result = duell(player[2], player[1]) if result then return losing(player[1]) elseif result==false then return losing(player[2]) end else -- moving player[2] if card==1 then moving(player[2], (-43*W)/1024, 800) else moving(player[2], ((-43*card)*W)/1024, 400*card, player[2].running) end player[2].pos = player[2].pos - card --[[ for i=1,card do moving(player[2], (-43*W)/1024, 1000) player[2].pos = player[2].pos-1 end --]] for i=1,5 do if player[2].hand[i]==card then player[2].hand[i] = draw() break end end if #player[2].hand~=5 then if player[1].pos > 22-player[2].pos then return losing(player[2]) else return losing(player[1]) end end end -- checking if player[1] has any card to play for i=1,5 do if player[1].pos + player[1].hand[i] <= player[2].pos then return false end end return losing(player[1]) end

58

-- function called when user presses LEFT function moveLeft() cursor = (cursor==1 and 5) or cursor-1 end -- function called when user presses RIGHT function moveRight() cursor = (cursor==5 and 1) or cursor+1 end -- function to register animation function createAnimation(f) local co = coroutine.create( f ) animation[co] = true coroutine.resume( co ) step{class='user', lastStep=event.uptime() } end -- basic step of animation function step(evt) local now = event.uptime() for co in pairs(animation) do coroutine.resume( co, (evt.lastStep and now-evt.lastStep) or 0 ) if coroutine.status( co )=='dead' then animation[co] = nil end end evt.lastStep = now if next(animation) then event.post('in', evt) end end -- function called when user presses ENTER function enter() if not next(animation) then createAnimation(run) end end start()

59