Especificación de una plataforma para la evaluación y programación de aplicaciones interactivas multimedia

Transcripción

1 1 Especificación de una plataforma para la evaluación y programación de aplicaciones interactivas multimedia José Luis Redondo García y José Luis González Sánchez Resumen 1 - La nueva televisión digital interactiva, apoyada en estándares de transmisión como DVB-T, ofrece cabida a una gran variedad de servicios interesantes para productores y consumidores. Esta tecnología requiere de unos STB s o decodificadores que se puedan programar y actualizar dinámicamente. Para ello implementan una capa de software intermediario sobre el que se ejecutan las aplicaciones transmitidas junto con las señales audiovisuales. En este aspecto nosotros hemos elegido MHP, un estándar abierto, diseñado por el proyecto DVB y estandarizado por la ETSI, no sin antes haberlo comparado con otras opciones como OpenTV y MHEG. Además, para conseguir la interactividad el STB debe contar con lo que se conoce como Canal de Retorno, una interfaz que permita el envío de información de vuelta al proveedor de servicios. Las tecnologías para implementarlo son variadas y serán analizadas en este documento: línea telefónica, ADSL, WiFi, WiMaX Para poner en práctica todo el contenido teórico, se ha creado un escenario de pruebas de aplicaciones interactivas en MHP, acorde con nuestras posibilidades económicas, que permite la ejecución de las mismas en el decodificador Strong SRT Con esta infraestructura se ha desarrollado la aplicación UEX-TVi que ofrece la posibilidad de que los alumnos de la universidad accedan a temarios de asignaturas, realicen concursos y cuestionarios y vean páginas Web desde el televisor, quedando de manifiesto el potencial de esta tecnología. También se han probado ejemplos creados con el entorno de desarrollo profesional idesigner. A modo de conclusión se verán posibles mejoras para MHP, el papel que jugará en el futuro, y la importancia de la entrada en juego de la televisión IP. Índice de términos Televisión Digital Interactiva, Televisión digital Terrestre, DVB, DVB-H, MHP, Canal de retorno, Decodificador, OpenTV, Televisión IP, MHEG, idesigner, Osmosys. I. INTRODUCCIÓN El sector audiovisual en general y el de la televisión en particular ocupan un lugar preferente en la llamada sociedad de la información», no resulta necesario destacar la enorme 1 El autor J. L pertenece al Departamento de Informática, Universidad de Extremadura. Avda. de la Universidad s/n. CP: Tlf: Fax: jlgs@unex.es. DOI (Digital Object Identifier) Pendiente importancia política, económica y social de este sector, que además constituye una de las tres grandes industrias del conocimiento en la construcción de la sociedad de la información junto con las telecomunicaciones y la informática dentro del proceso de convergencia tecnológica. En la actualidad la televisión es el medio de comunicación que más impacto ha conseguido en la sociedad menos tiempo y el más importante de los que utilizamos. Ver la televisión se ha convertido en la segunda actividad a la que dedicamos mayor número de horas en nuestra vida después del sueño. Todo ello, está convirtiendo a la televisión, según gran parte de los investigadores, en el tercer factor socialización, junto a los más tradicionales, familia y escuela. Esto hace de la televisión un soporte privilegiado para desarrollo efectivo de la sociedad de la información. Los cambios y avances que se están produciendo en el terreno de las telecomunicaciones, avances en el mundo de los satélites, las redes, la TV interactiva digital, la televisión por cable, un panorama en constante evolución, están haciendo que no podamos entender en los mismo términos que hasta ahora lo hemos hecho, las distintas maneras de hacer televisión. La televisión generalista está dejando paso a la televisión especializada, un proceso fundamental para el desarrollo de la televisión cultural, con unas audiencias muy concretas. Pero de todos los avances de las tecnologías de comunicación que se están produciendo, quizás los que más impacto puedan tener en esta sociedad globalizada, sean la televisión Interactiva Navegar por Internet a través de la televisión o ver la televisión en el ordenador serán la misma cosa, y, además tendremos acceso a los programas bajo demanda on-line (VOD), que va a permitir al usuario que elija lo que quiere ver en cada momento. Este rápido avance de las tecnologías nos sitúa ante un universo de posibilidades cada vez más amplio, con un gran potencial de interactividad y participación. Ahora bien, debemos andar con cuidado para que esta evolución tecnológica no nos encuentre desprevenidos, y poder aprovechar al máximo las posibilidades que nos ofrece. II. ESTADO DEL ARTE A. La televisión digital terrestre (TDT). El medio de expansión más vanguardista y con mayores posibilidades para la televisión interactiva en nuestro país es la Televisión Digital Terrestre. Se trata de la aplicación de las tecnologías del medio digital a la transmisión de contenidos a través de una antena convencional (aérea) o de conexión por cable o satélite. Aplicando la tecnología digital se consiguen mayores posibilidades, como proveer de un mayor número de

2 2 canales, mejor calidad de imagen (o imagen en alta definición) y mejor calidad de sonido. La TDT presenta tres principales ventajas frente a la televisión analógica actual: información por parte del usuario es posible gracias a las diversas aplicaciones de que dispone el receptor TDT, en general conformes al estándar de que ya hemos hablado en el resumen de este documento: MHP 1. Mayor calidad de imagen y sonido. La transmisión terrestre de televisión se ve afectada por dispersión de energía, zonas de sombra y reflexiones que provocan ecos. En transmisión analógica esos problemas se manifiestan como nieve, ruido en la imagen, dobles imágenes, colores deficientes y sonido de baja calidad. En transmisión digital, al estar la señal codificada, recibimos una imagen siempre íntegra. El único problema es el denominado abismo digital: cuando la señal no es suficiente para los circuitos decodificadores se pierde completamente la recepción. Aún así, una recepción óptima suele necesitar menor potencia de señal que una transmisión analógica de calidad normal. La imagen, sonido y datos asociados a una emisión de televisión se codifican en formato MPEG Mayor número de emisiones de televisión. La tecnología de televisión analógica actual sólo permite la transmisión de un único programa de televisión por cada canal UHF (ya sea de 6MHz, 7Mhz u 8MHz de ancho de banda). Además, los canales adyacentes al que tiene lugar una emisión han de estar libres para evitar las interferencias. La digitalización de los programas permite que, en el ancho de banda disponible en un solo canal UHF (unos 20 Mbps en la actual configuración de TDT en España), se puedan transmitir varios programas con calidad digital similar a la de un DVD. El número de programas simultáneos depende de la calidad de imagen y sonido deseados. En la actualidad es de cinco programas, con un uso habitual de cuatro. Sin embargo, la gran flexibilidad de la codificación MPEG-2 permite cambiar estos parámetros en cualquier momento, de manera transparente a los usuarios. El bloque de cuatro o cinco canales de emisión que se emite por un canal habitual de UHF recibe el nombre de MUX (múltiplex). Un sistema inteligente estima el flujo de cada canal que compone en MUX en cada momento y va asignando mayor o menor ancho de banda según la necesidad detectada. 3. Mayor flexibilidad de las emisiones y servicios adicionales. En cada canal de radio se emite un único flujo MPEG-2, que puede contener un número arbitrario de flujos de vídeo, audio y datos. Aunque varios operadores compartan el uso de un canal multiplexado (múltiplex), cada uno puede gestionar el ancho de banda que le corresponde para ofrecer los contenidos que desee. Puede (por ejemplo) emitir un flujo de vídeo, dos de audio (por ejemplo, en dos idiomas a la vez), varios de datos (subtítulos en tres idiomas, subtítulos para sordos, en un partido información con las estadísticas de los jugadores, o en una carrera automovilística información de tiempos y posiciones, etc.). El aprovechamiento de toda esta Figura 1: Cadena de Transmisión para la TDT B. DVB: Digital Video Broadcasting. El DVB es un organismo encargado de regular y proponer los procedimientos para la transmisión de señales de televisión digitales compatibles. Está constituido por más de 220 instituciones y empresas de todo el mundo y los estándares propuestos han sido ampliamente aceptados en Europa y en casi todos los continentes, con la excepción de Estados Unidos y Japón donde coexisten con otros sistemas propietarios. Las más reconocidas entidades a nivel mundial participan en DVB, entre otros JVC, Sanyo, Panasonic, Sony, Samsung, Toshiba, Hyundai, Broadcom, CableLabs, DirecTV, Dolby, Harmonic, Intel, Intelsat, Macrovision, MPEG, Motorola, Microsoft, OpenTV, Sun, Texas, Time Warner, Walt Disney Promueve estándares aceptados internacionalmente de televisión digital, en especial para HDTV y televisión vía satélite, así como para comunicaciones de datos vía satélite (unidireccionales, denominado sdvb-ip, y bidireccionales, llamados DVB-RCS). Todos los procedimientos de codificación de las fuentes de vídeo y audio están basados en los estándares definidos por MPEG. No obstante, los estándares MPEG sólo cubren los aspectos y metodologías utilizados en la compresión de las señales de audio y vídeo y los procedimientos de multiplexación y sincronización de estas señales en tramas de programa o de transporte. Una vez definida la trama de transporte es necesario definir los sistemas de modulación de señal que se utilizarán para los distintos tipos de radiodifusión (satélite, cable y terrenal), los tipos de códigos de protección frente a errores y los mecanismos de acceso condicional a los servicios y programas. El sistema DVB se ha concebido flexible para dar respuesta eficiente a las singularidades y necesidades de cada país, de tal manera que permite la transmisión de televisión con definición estándar, televisión de alta definición, televisión en movilidad, servicios telemáticos, etc. Igualmente permite la transmisión de televisión digital terrestre a receptores independientes o vía otras redes de cable o vía sistemas de antenas colectivas. Asimismo, permite la transmisión de televisión gratuita, televisión de pago, sistemas de bajo coste para células de

3 3 cobertura pequeñas, sistemas redes de frecuencia única o multifrecuencia, sistemas interactivos, etc. Figura 2: Estándares creados por DVB C. Estándar para la televisión terrestre: DVB-T Es el estándar utilizado por la Televisión Digital Terrestre y por muchas otras televisiones digitales del mundo para la transmisión de la señal. Este estándar permite, gracias a sus características, una emisión flexible de TV digital, salvando muchos de los obstáculos que se pueden presentar a la hora de transmitir señales de vídeo y de audio para que lleguen a los hogares. Vamos a ver alguna de esas ventajas y algunas especificaciones para comprender mejor como funciona: Canalización: 6 MHz, 7 MHz, 8 MHz Video (flujo MPEG-2/4/ ), audio, datos y paquetes Calidad SD y HD Gran Capacidad (hasta MHz) Gran robustez (frente a multitrayecto y ruido impulsivo). Despliegue Escalable o o Tamaño de la célula hasta 100 km (típico 60 km) Despliegue: Multifrecuencia: Redes MFN Frecuencia Única: Redes SFN Algunos datos estadísticos interesantes sobre el uso de este estándar pueden ser extraídos de las figuras 22 y 23. Se puede concluir que es el más utilizado respecto a las otras alternativas existente. Figura 3: Población potencial del uso de los distintos estándares. Beneficios y cualidades que proporciona DVB-T y que merecen mención aparte son: Calidad. La señal llega en unas condiciones mucho mejores. o Formato Panorámico 16:9 o Imagen calidad similar a DVD o Sonido Digital Multicanal Dolby 5.1 o Difusión sin interferencias o Alta Definición Mayor eficiencia espectral. o Más posibilidades para la gestión del espectro o Flexibilidad en el uso del espectro o Rentabilidad de un recurso escaso. Soporte adecuado para la INTERACTIVIDAD o Guía Electrónica de Programas o Servicios de Bolsa, Tráfico, Meteorología o Servicios de T-Administración o Concursos, encuestas, votaciones, etc. o Posibilidad de acceso condicional o Publicidad interactiva o PPV D. El estándar usado como middleware: DVB-MHP MHP define una plataforma común para las aplicaciones interactivas de la televisión digital, independiente, tanto del proveedor de servicios interactivos, como del receptor de televisión utilizado. De este modo, MHP favorece la creación de un mercado horizontal donde aplicaciones, red de transmisión y terminales MHP pueden ser suministrados por proveedores o fabricantes independientes. Este estándar se basa en otros que ya han sido probados y desarrollados (por ejemplo, DAVIC). Una primera versión ETSI del estándar (DVB-MHP 1.0) apareció en Julio de Ya en Agosto de 1999, en la IFA (Exhibición Internacional de Broadcasting) desarrollada en Berlín, se realizaron demostraciones de aplicaciones MHP y de decodificadores. La primera versión del estándar MHP tenía una serie de inconvenientes, por ejemplo, ciertos aspectos técnicos no habían sido resueltos de manera lo suficientemente precisa. Por ello se creó la siguiente versión, la Fue publicada por la ETSI en octubre del 2001 y fue publicada por la Comisión como un Estándar Europeo el 31 de diciembre del En junio del 2002, se introdujo la versión Esta, a su vez, fue seguida por la versión Arquitectura. MHP define tres capas: Recursos: Procesador MPEG, dispositivos E/S, CPU, memoria, sistema de gráficos, etc. Sistema de software: Las aplicaciones no acceden de manera directa a los recursos, sino que lo hacen a través del sistema de software, que hace de capa intermedia. El objetivo de esta capa intermedia es el de proporcionar portabilidad para las aplicaciones, de manera que su utilización no dependa de los recursos a utilizar. El sistema de software incluye un administrador de aplicaciones (Navigator) para el control de las aplicaciones que se ejecutan.

4 4 Aplicaciones: Aplicaciones interactivas (también conocidas como Xlets) recibidas a través del canal de broadcast, junto con las señales de audio y vídeo convencionales. 2. Aplicaciones MHP Una Aplicación MHP es un programa interactivo escrito en Java. Las aplicaciones Java de MHP se llaman Xlets ; éstas corren sobre la capa MHP que abstrae el programa en cuestión de la máquina en la que se ejecuta. Los Xlets tienen un ciclo de vida específico y están controlados por el emisor de los servicios o por el usuario a través de la capa MHP, que facilita poder usar una amplia gama de dispositivos de entrada de datos.al igual que los Applets, los Xlets están controlados por un software que los ejecuta. En el caso de un Applets, el software subyacente es un navegador o la herramienta Appletviewer. En el caso de un Xlet, el software subyacente es el receptor de televisión o decodificador que contiene la plataforma Java TV. No existe un método principal y los Xlets siempre implementan la interfaz "Xlet". Las cabeceras de los métodos del ciclo de vida están definidas por la interfaz Xlet que todas las clases implementan: Creación Inicialización Comienzo Pausado Destrucción 3. Perfiles de MHP. Mientras el proyecto fue evolucionando y se mejoró el perfil básico del nuevo estándar, un nuevo perfil con características adicionales como HTML, mejor uso de los canales de retorno o soporte para nuevas API s, fue publicado por la ETSI. Esta nueva versión, la MHP 1.1 salió en Noviembre del El mayor cambio respecto a la versión anterior es la inclusión del DVB-HTML, basado en la especificación W3C. DVB-HTML es opcional con el Perfil Mejorado de Broadcasting y con el Perfil Interactivo de Broadcasting, pero es imprescindible en el Perfil de Acceso a Internet. MHP 1.1 también proporciona un modelo de ciclo de vida para Plug-ins e incluye soporte para la descarga de aplicaciones a través del canal de retorno. Todos los estándares DVB-MHP pueden obtenerse de la página Web de ETSI. Desde el punto de vista de aplicaciones y servicios se han definido tres perfiles y una opción llamada DVB-HTML, permitiendo a los fabricantes desarrollar un rango de productos que proporcionan diferentes funcionalidades. Cada perfil puede coexistir con otros que se ofrezcan en el mercado. El Perfil de Broadcasting mejorado combina la emisión digital de servicios de audio y de video con la descarga de aplicaciones, que permite la interactividad local. Este perfil no soporta un canal de interacción. El perfil de Broadcasting Interactivo habilita un conjunto de servicios asociados o independientes de los servicios de emisión. Este perfil requiere un canal de retorno. Perfil de acceso a Internet. Ha sido diseñado para dar soporte a los servicios de Internet. Incluye también enlaces entre esos servicios de Internet y los servicios de Emisión o broadcasting. Figura 4: Ciclo de vida de un Xlet Todas las implementaciones de Java TV tienen a un gestor de aplicaciones que llama a los métodos del ciclo de vida para mover a uno o varios Xlets a través de sus estados de aplicación. La interfaz Xlet no proporciona ninguna implementación para los métodos del ciclo de vida. Los desarrolladores proporcionaran implementaciones dependientes de la aplicación para esos métodos, definiendo lo que ocurre en cada punto del ciclo de vida de un Xlet. Por ejemplo, el método initxlet de un juego Xlet debería de crear los componentes de la interfaz de usuario. Un Xlet puede forzar algunos cambios de estado por sí mismo e informar al gestor de aplicaciones de éstos invocando a los métodos de la interfaz XletContext. Cuando se inicializa un Xlet, se le pasa un objeto XletContext para darle una forma de solicitar propiedades y notificar cambios de estados internos. Figura 5: Perfiles de DVB.

5 5 III. EL CANAL DE RETORNO El canal de retorno es, ante todo, un mecanismo para permitir mejorar la experiencia de usuario que la televisión digital puede ofrecernos. Haciendo uso del canal de retorno es posible construir verdaderas aplicaciones interactivas, en las que las que la persona que disponga de un terminal adecuado pueda enviar información al proveedor (o servidor) de las aplicaciones que esté ejecutando. Un ejemplo inmediato de los usos de este canal pueden ser las aplicaciones orientadas a votos y encuestas o los canales de televisión en los que la programación se ajusta a las demandas de los televidentes. Con MHP 1.1 además el canal de retorno puede ser usado para tareas relacionadas con la descarga de aplicaciones y la visualización de contenidos web. Adicionalmente, este canal puede ser usado para cargar de forma más rápida los programas convencionales; es decir, consigue aumentar el ancho de banda inicial del que disponíamos para ejecutar un cierto programa que llega el receptor, aunque este no es el objetivo primordial para el que el canal de retorno ha sido especificado dentro de la plataforma. La forma más primitiva de implementar este canal sería usar un módem que se conecte a la red telefónica. La ventaja de este canal de retorno es que está disponible en casi todos los hogares. La desventaja es que el proceso de conexión es lento, se ocupa la línea telefónica, y los operadores cobran por tiempo de conexión por lo que estas conexiones deben ser lo más breves posibles. Pero hoy en día no podemos pensar en implementar el canal de retorno usando este tipo de tecnologías, casi obsoletas. Deben entrar en juego nuevos métodos de intercambio de información, sobre todo los inalámbricos, que permitan obtener una calidad de contenidos acorde a lo que se espera de la televisión del futuro. Estudiar las variantes disponibles y sus ventajas e inconvenientes es uno de los principales objetivos de este apartado. Figura 6: El canal de retorno dentro del esquema TDT A. Aspectos teóricos del Canal de retorno. Hay básicamente dos tipos de canales de retorno; los permanentes y los basados en conexión. Dependiendo del tipo de canal de retorno, el terminal o las aplicaciones tienen que ajustar sus funcionalidades para ajustarse a los requerimientos del mismo y a la vez dar solución a los requerimientos del usuario. De acuerdo con lo definido en MHP, cada interfaz asociada a un canal de retorno se instancia por medio de una clase RCInterface. Las características del mismo en cuanto a ancho de banda y tiempos de respuesta están modeladas en esta clase.por otro lado, la clase RCInterfaceManagers proporciona funciones y métodos para controlar el acceso al canal de retorno. En cuanto a la realidad actual, encontramos algunos terminales que soportan MHP que llevan módem integrado, o una tarjeta Ethernet; aunque debido a la ausencia de proveedores que hagan uso de estas tecnologías en nuestro país, la mayor parte de los receptores TDT no llevan ningún dispositivo que permita funcionar como canal de retorno. B. Tecnologías disponibles actualmente para implementar el canal de retorno. 1. ADSL Asymmetric Digital Subscriber Line ("Línea de Abonado Digital Asimétrica") o como se conoce comúnmente, ADSL, es un tipo de línea DSL consistente en una línea digital de alta velocidad basada en el par simétrico de cobre que soporta la línea telefónica convencional o línea de abonado, siempre y cuando la distancia medida desde la Central Telefónica no sea superior a los 5,5 km. Se trata de una tecnología para acceder a Internet mediante banda ancha, por lo que se consigue una capacidad para transmitir más datos, lo que a su vez significa conseguir una mayor velocidad. Esto se logra utilizando una banda de frecuencias más alta que la usada en las conversaciones telefónicas convencionales ( Hz) y por ello, para poder tener ADSL, se hace necesario instalar un filtro (llamado discriminador o splitter) encargado de separar la señal convencional del teléfono de la que se utilizará para la conexión mediante ADSL. Ventajas: Ofrece la posibilidad de hablar por teléfono mientras se navega mediante la Red. Usa la infraestructura de la red telefónica básica. De este modo la implantación de esta tecnología no supone grandes gastos para los operadores, el coste y el tiempo que se tarda para que el servicio esté disponible es menor que si el operador tuviera que realizar las obras necesarias para crear una nueva infraestructura. Los usuarios no tienen que establecer una conexión mediante marcación o señalización hacia la red, sino que poseen una conexión a Internet permanente Con ADSL se consigue un velocidad de conexión mucho mayor que mediante una conexión estándar de marcación telefónica a Internet. Para los usuarios esta es la característica que más les interesa.

6 6 Inconvenientes: A diferencia de otros países, en España no es posible dar de alta una línea ADSL de forma independiente a la línea del teléfono fijo. Dado que estas líneas necesitan de un buen cuidado, en países con malas o pocas infraestructuras no resulta económico este servicio, sobre todo en comparación con los precios de otros países que poseen mejores infraestructuras. Para disponer de la conexión a Internet es necesario un router, o un módem ADSL en su defecto, que suelen ser caros (el módem no tanto), aunque en España los proveedores del servicio suelen subvencionar tanto el router como el módem ADSL. Para su funcionamiento se necesita una línea telefónica, aunque puede usarse para realizar llamadas. Conclusión: Es una tecnología con unas características de ancho de banda y de velocidad de transmisión muy aceptables. La disponibilidad es también relativamente alta en los hogares españoles; sin embargo, elimina completamente el concepto que tenemos de movilidad, y reduce su uso exclusivamente a terminales situados como fijos en el hogar y nunca a terminales móviles como los PDA. 2. WIFI Wi-Fi (siglas del inglés Wireless-Fidelity) es un conjunto de estándares para redes inalámbricas basados en las especificaciones IEEE Fue creado para ser utilizado en redes locales inalámbricas. Wi-Fi es una marca de la Wi-Fi Alliance (anteriormente la WECA: Wireless Ethernet Compatibility Alliance), la organización comercial que adopta, prueba y certifica que los equipos cumplen los estándares Ventajas. Ofrecen una comodidad bastante mayor que las redes mediante cables ya que permite que cualquiera con posibilidad de acceso a la red se pueda conectar desde diferentes puntos dentro del alcance de la misma. Una vez que la red Wi-Fi está configurada, múltiples ordenadores pueden acceder sin ningún problema y sin tener que gastar en infraestructuras. La Wi-Fi Alliance asegura una compatibilidad total entre dispositivos con la marca Wi-Fi. Inconveniente: Una desventaja del sistema Wi-Fi es que comparándolo con una conexión mediante cables, se produce una pérdida de velocidad, causada por las interferencias y pérdidas de señal que puede provocar el ambiente. La principal desventaja de las redes Wi-Fi reside en el ámbito de la seguridad. Mediante algunos programas, y con una tarjeta Wi-Fi en modo promiscuo, es posible capturar paquetes y calcular la contraseña de la red para poder acceder a ella. Las claves de tipo WEP se pueden conseguir de esta forma con relativa facilidad. Para solucionar estos problemas la alianza Wi-Fi sacó el estándar WPA y más tarde WPA2, basados en el grupo de trabajo i. WPA2 proporciona muy buena seguridad y se consiguen redes que se consideran robustas. También hay que destacar que Wi-Fi no es compatible con otra clase de conexiones inalámbricas como Bluetooth, GPRS, UMTS, etc. Conclusión: Si lo comparamos con ADSL, perdemos algo de velocidad y ancho de banda pero siguen siendo perfectamente suficientes. Sin embargo, aún no podemos aceptar su radio de acción para dispositivos y terminales TDT que sean móviles, porque la cobertura se limita prácticamente a la superficie del propio hogar. Es decir, eliminamos cables dentro de casa pero realmente si queremos un dispositivo que funcione fuera de ella esta tecnología no nos sirve. 3. BLUETOOTH/UMTS. Usando estas tecnologías, el canal de retorno sería el propio teléfono móvil del usuario, utilizando GPRS o UTMS. El receptor de TDT se conectaría automáticamente a Internet a través de una interfaz Bluetooth. La tecnología Bluetooth se utiliza en la actualidad de forma mayoritaria para hablar por teléfono con manos libres en el automóvil. El 70% de los teléfonos móviles desplegados en España dispone ya de Bluetooth y GPRS (47%) o UTMS (53%), por ello servicio de canal de retorno tendría una cobertura amplísima en España. La estrategia de implantación debería acordarse con las operadoras de telefonía móvil, interesadas en la activación y uso de sus servicios de datos y GPRS y UTMS.El servicio se prestaría a través de receptores MHP estándar con interfaz Bluetooth. El valor de este tipo de receptores para el usuario sería: Ver en el televisor las fotos almacenadas en el teléfono móvil. Votar e interactuar en los programas de TV. Acceder a servicios interactivos y a Internet. La interfaz Bluetooth podría estar incorporada en el propio receptor, y el coste del receptor rondaría los 100. También sería posible incluirse la interfaz Bluetooth a través de un puerto USB. El coste de los receptores, por tanto, no se vería incrementado y sólo deberíamos comprar el dispositivo USB que suele tener un coste de unos 10. La manera más sencilla de implantar esta tecnología es esta última, utilizando un pequeño dispositivo Bluetooth que se conecte al aparato MHP por el puerto USB. Conclusión: Es una tecnología que soluciona los problemas de movilidad de las anteriores propuestas. Los terminales móviles usan 3G para conectarse, y los terminales fijos que disponemos en casa pueden conectarse a los móviles por medio de Bluetooth. Sin

7 7 embargo, este tipo de tecnologías tiene su debilidad en la calidad de las conexiones. Sobre todo en el caso de que usemos Bluetooth por medio pues la tasa de transferencia de este protocolo no es suficiente, sobre todo si estamos trabajando con aplicaciones multimedia. 4. PLC Power Line Communications (Comunicaciones mediante línea de energía) abreviada en inglés PLC es un término que describe diferentes tecnologías que utilizan las líneas de energía eléctrica convencionales para transmitir señales de radio para propósitos de comunicación. Este sistema tiene una serie de problemas algo complicados. El primero de ellos es que las propias líneas de energía forman ambientes con mucho ruidos. Cuando un dispositivo se enciende o se apaga, éste introduce en la línea voltajes transitorios. Además los aparatos que ahorran energía con frecuencia introducen en el canal algunos armónicos ruidosos. Habría que diseñar el sistema para solucionar estas interrupciones naturales de las señales y poder trabajar con ellas. El segundo gran problema está relacionado con la intensidad de la señal junto con la frecuencia de operación. Se espera que las frecuencias usadas por PLB estén en la banda de 10 a 30 MHz, que ha sido usada por los radio aficionados durante décadas, al igual que por distintos sistemas de comunicación (militar, aeronáutico, etc.) y por emisoras de radio internacionales de onda corta. Las líneas de energía no tienen blindaje y pueden actuar como antenas para las señales que transportan, y tienen el potencial de eliminar la utilidad de la banda de 10 a 30 MHz para los propósitos de las comunicaciones en onda corta. Conclusión: Esta alternativa tiene la clara ventaja de que cualquier hogar dispone de la infraestructura básica de la red eléctrica que es la que se usa como canal de información para esta alternativa. Los anchos de banda teóricos y las capacidades del medio son adecuados y suficientes. Sin embargo, nos encontramos ante el mismo problema que en el caso anterior, la movilidad, a la que se suma además el inconveniente de ser una tecnología todavía poco fiable y algo más cara que el ADSL. 5. WiMAX WiMAX es una tecnología de telecomunicaciones basada en el estándar IEEE que permite ofrecer servicios de banda ancha inalámbricos como una alternativa al cable y DSL. WiMAX puede proporcionar conectividad fija, nómada, portátil y móvil de banda ancha e inalámbrica sin la necesidad de tener una línea de visión directa con la estación base. WiMAX proporcionará conectividad de banda ancha en cualquier sitio, en cualquier momento y para cualquier dispositivo en cualquier red. Mediante WiMAX se puede conseguir: Conectar puntos Wi-Fi entre sí y a otras partes de Internet. Alta velocidad de acceso a Internet donde actualmente no está disponible. Un incremento considerable de la velocidad de datos para aplicaciones como juegos online, descarga de vídeo, video conferencia, VoIP y servicios basados en localización. Conducir los equipos de Internet inalámbrico y el acceso a precios competitivos comparables a servicios de Internet mediante fibra, cable o DSL. Una conectividad móvil. Muchas compañías están examinando de cerca WiMAX para una conectividad entre el usuario y la central de comunicación de alta velocidad. La competencia resultante podría traer precios más bajos para los compradores, ya sean negocios o particulares, o traer acceso de banda ancha a lugares donde no estaba disponible económicamente. Antes de WiMAX, muchos operadores han estado usando sus propias tecnologías inalámbricas fijas para servicios de banda ancha. Aspectos claves de WiMAX Una de las claves principales de WiMAX es la interoperabilidad de equipos certificados por el WiMAX Forum (es decir, la capacidad de dos ordenadores de funcionar conjuntamente y de comunicarse), dando lugar a un mayor ahorro y asegurando a los proveedores de servicios que cuando se compren equipos de distintas compañías, las tecnologías sean interoperables. El WiMAX Forum ha creado una alianza de las industrias líderes en comunicaciones y ordenadores para conseguir una plataforma común para el despliegue global de servicios inalámbricos de banda ancha basados en IP. Otros elementos clave incluyen el coste, la cobertura, la capacidad y los estándares, tanto para uso fijo como para móvil. Menor coste: Una plataforma basada en estándares para la tecnología WiMAX conduce a la disminución de los precios de los equipos WiMAX. Mayor cobertura: La tecnología detrás de WiMAX ha sido optimizada para proporcionar una cobertura excelente sin tener línea de visión (NLoS: non-lineof-sight). Las ventajas de NLoS son mayores áreas de cobertura, mejor predecidibilidad de la misma y menor coste pues significa que habrá menos estaciones base y menos redes de interconexión, una planificación de radio frecuencias más simple, torres más cortas y menores tiempos de instalación de los CPE (Equipos locales de los clientes). Mayor capacidad: Una ventaja clave de la tecnología WiMAX es el uso de OFDM (Orthogonal Frequency-Division Multiplexing) para lograr una mayor eficiencia en el ancho de banda y, por lo tanto, un mayor throughput. La modulación adaptativa también incrementa la fiabilidad de los enlaces para las operaciones con las portadoras, y la posibilidad de mantener una modulación de mayor orden en distancias mayores extiende la capacidad completa en grandes distancias.

8 8 Estándar para todos los modos de uso (de fijo a móvil): Haciendo hincapié en redes con la misma tecnología, la tecnología WiMAX llegará a ser la solución más efectiva, económicamente hablando, para cualquier uso, desde fijo hasta móvil. El WiMAX Forum certifica los productos, con los que están conformes y son interoperables, basados en los estándares IEEE Conclusión: Las características técnicas de WiMAX lo convierten en la solución óptima para construir un canal de retorno para redes DVB-T y crear sistemas realmente interactivos. De momento, los STB DVB-T están usando módems en la red telefónica para crear enlaces para el canal de retorno; este enlace se necesita para varias aplicaciones, por ejemplo para votar, responder a concursos de preguntas, etc. Una estación cliente de WiMAX se podría usar como un dispositivo siempre conectado, preparado para enviar datos a la red cuando un usuario pulse una tecla en el mando a distancia. WiMAX también ofrece una gran oportunidad para simplificar la instalación en los hogares de los usuarios: la próxima generación de estaciones cliente están diseñadas como equipos interiores solamente, lo que conduce a un único dispositivo que se podría colocar en cualquier sitio de la casa, conectado a un ordenador o a un STB y encendido, sin ninguna necesidad de colocar una antena. Los sistemas WiMAX de acuerdo al estándar IEEE ofrecen un canal de retorno de banda ancha, ya que la capacidad de una celda WiMAX puede lograr varios Mbit/s repartidos entre los usuarios activos. Considerando un ejemplo real, podríamos elegir los despliegues experimentales de WiMAX en Italia, donde las celdas estarán basadas en uno o dos canales de 1,75 MHz y el ancho de banda máximo disponible en condiciones óptimas es aproximadamente de 5 Mbit/s. Este valor es muy interesante porque permite aplicaciones de descarga de vídeo: WiMAX se podría integrar en un sistema DVB-T como un canal de unidifusión para enviar datos al usuario final así como cualquier contenido multimedia elegido mediante una aplicación MHP. Por ejemplo, un usuario que esté viendo una película puede activar una aplicación MHP que ofrezca otros contenidos multimedia unidos a la transmisión DVB-T. El usuario puede seleccionar un contenido, por ejemplo, el trailer de la última película del protagonista, y se puede recibir como una transmisión de unidifusión entre el canal WiMAX. Las estaciones base WiMAX pueden garantizar los parámetros de red requeridos (ancho de banda, retardo, paquetes perdidos) para asegurar una buena experiencia al usuario con el flujo basado en un enlace de unidifusión. En este apartado del documento vamos a realizar un estudio que nos sirva para mostrar las diferencias existentes entre los distintos sistemas que hoy por hoy destacan en el mercado de la televisión digital interactiva. El interés de comparar unas plataformas con otras radica en el hecho de saber cuál elegir en un momento dado. Tanto si somos programadores que estamos iniciándonos en el proceso de desarrollo de una aplicación para televisión, o bien somos proveedores de contenidos que necesitamos que éstos se divulguen de forma conveniente entre los televidentes, la primera pregunta a la que nos enfrentamos es sin lugar a dudas: Qué plataforma de entre las existentes actualmente elijo para trabajar? Además, es importante es saber Porqué estoy eligiendo esta plataforma? En este documento no podemos dar una respuesta exacta estas cuestiones, porque todo dependería de los requisitos particulares del programador o del proveedor pero se puede conseguir ofrecer una visión general de las alternativas para que la elección sea mucho más fácil. A. Comparativa MHP vs OpenTV 1. OPEN TV OpenTV es una plataforma para televisión digital interactiva que surgió en 1994 como resultado del trabajo conjunto de la compañía Thomson y Sun Microsystems. Este proyecto saco a la luz el primer Middleware en 1996 [12]. Desde entonces, OpenTV se ha convertido en uno de las plataformas más usadas para la Televisión Digital Interactiva de los últimos años, habiendo sido implantado en más receptores que ninguna otra especificación. Sin embargo, en la actualidad ha ido perdiendo fuerza respecto a MHP, que se encuentra en alza, aunque todavía no ha acabado de despegar. Descripción. El sistema OpenTV fue diseñado para ser ejecutado sobre un tipo de receptor específico compatible. Las aplicaciones están escritas específicamente para el sistema OpenTV y no se pueden ejecutar en otro Middleware. Ante la llegada de MHP, OpenTV reconoció la necesidad de convertirse en compatible con el de alguna manera, cambiando partes de su arquitectura. En este punto, OpenTV optó por proporcionar un plug-in para los receptores MHP, que permitía a sus aplicaciones ser ejecutadas en ellos. Las aplicaciones de OpenTV están escritas en ANSI-C y usan la API de este mismo fabricante (OpenTV API). El código es compilado a O-Code usando el compilador gcco[12], incluido en el kit de desarrollo de OpenTV. Estas herramientas están disponibles a través de Internet de forma gratuita junto con documentación.. IV. COMPARATIVAS DE MIDDLEWARES Arquitectura. La arquitectura diseñada para OpenTV está bien clara para sus autores, y lo que sabemos sobre ella se entra en forma de documentos técnicos hechos públicos por la propia organización. OpenTV, en su implementación compatible con MHP, está compuesto por cuatro capas principalmente. Estas

9 9 son: la capa de controladores (Driver Layer), la capa del sistema operativo (Operating System Layer), la capa de librerías para la televisión interactiva (Interactive TV Libraries Layer) y la capa de ejecución (Execution Layer) [35],tal y como vemos en el la figura que se muestra a continuación: un estándar, permite desarrollos compatibles paralelos. Así cualquier fabricante puede desarrollar un STB siguiendo el estándar y conseguir la certificación de ser un STB compatible con MHP. Figura 7:Arquitectura OpenTV La capa de controladores proporciona la interfaz con el hardware, y de esta manera OpenTV consigue ser consecuente con la premisa de MHP de permitir que las implementaciones sean independientes del funcionamiento del hardware de la máquina en la que se ejecute. La capa del sistema operativo proporciona la interfaz para procesar los recursos disponibles. Las librerías de televisión interactiva es la capa en la que encontramos las mayores diferencias entre la especificación MHP y las implementaciones OpenTV. Dentro de ella encontramos las librerías para O-Code (la API nativa de OpenTV) para Java y para HTML. La capa de ejecución permite que las aplicaciones compiladas se ejecuten en el STB. Open TV permite ejecutar O-Code, Java y HTML en el mismo STB. 2. Multimedia Home Platform (MHP). MHP ha sido creado por la asociación Digital Video Broadcasters (DVB). En fases anteriores de este documento ya hemos hablado de este estándar, pero contaremos un poco más sobre él y repasaremos algunos datos para dar coherencia a la comparativa. El proyecto comenzó en 1997 y proviene del proyecto UNITEL. Hay dos grupos de trabajo en DVB formados para este proyecto: uno orientado al mercado, que define los requisitos que usuarios y compradores establecen, y un grupo técnico que trabaja en la especificación de la interfaz de programación de aplicaciones para DVB. Descripción. Posiblemente una de las descripciones más concisas de lo que es MHP fue dada por Piesing, que explica que el proyecto MHP consiste en buscar una API común para permitir que las aplicaciones sean descargadas de las redes de emisión y ejecutadas en los receptores de cualquier fabricante. Es importante darse cuenta que MHP no es un lenguaje de programación, sino un estándar para asegurar la compatibilidad entre programas funcionando en receptores que tienen diferentes arquitecturas: lo que se trata es separar la tecnología de la implementación. MHP promueve el uso de programación Java y más concretamente el uso de DVB-J, tema del que se hablará un poco más en partes posteriores de este análisis. Como MHP es Arquitectura MHP. Figura 8:Esquema de emisión de MHP Generalmente, los expertos coinciden en que la arquitectura MHP está formada por tres capas, aunque algunos autores reconocen cuatro. Dos de las referencias que se han revisado apuestan por la existencia de la capa de Recursos, la del Sistema, y la de las Aplicaciones. La capa de los recursos, incluye todos los elementos hardware, por ejemplo los chips que procesan MPEG, o dispositivos de entrada y salida, de memoria, y de CPU. La capa de Sistema se asemeja a lo que sería el sistema operativo, y está formada por la máquina virtual Java, y los controladores de los dispositivos de la capa inferior. La capa de Aplicaciones es un conjunto de funciones de alto nivel, de estructuras de datos y de protocolos que permiten a las aplicaciones MHP funcionar correctamente. La totalidad de los expertos coinciden en la existencia de estas tres capas, sin embargo el tema no está tan claro en cuanto a la existencia de una cuarta capa. La cuarta capa, llamada monitor de aplicaciones (Manager Layer), también conocida como Navigator por Piesing y Plosh, es una capa situada en el mismo nivel que la capa de sistema. Incluso entre los que apoyan esta existencia de una cuarta capa, existe una controversia a la hora de elegir con qué capa de las tres ya establecidas se conecta esta nueva. Piesing cree que está unida a la capa de Aplicación, mientras que Plosh sugiere que interactúa con la capa de Sistema para gobernar el ciclo de vida de las aplicaciones. Figura 9: Arquitectura MHP.

10 3. Resultados. Este estudio ha sido enfocado desde la perspectiva de un desarrollador de software que se embarca en la creación de su primera aplicación de televisión digital interactiva. Lo primero es ver la rapidez con la que nos familiarizarnos con la API. Después pasamos a hacer lo propio con la funcionalidad de OpenTV y MHP. Para estas tareas es necesario consultar la documentación y las propias librerías de la API, y ver los ejemplos recogidos en los artículos científicos a los que hacemos referencia en la bibliografía. Concretamente, en varios de estos textos se recoge el desarrollo de componentes para crear una aplicación del Trivial. Primero veremos el código del componente en MHP y luego haremos lo mismo para OpenTV. Aunque queda un poco fuera del trabajo a realizar para este proyecto, por la falta de tiempo, el siguiente paso sería desarrollar nosotros esos componentes. Pero como no es posible realizaremos el estudio en base a los datos encontrados. Facilidad de aprendizaje y de uso. En cuanto a la facilidad de aprendizaje, hay un número considerable de diferencias entre MHP y OpenTV. Una de las diferencias principales es la documentación que acompaña a la API. En MHP casi todo está fragmentado. Como es un compendio de librerías bastante amplio, para informarnos bien sobre ellas tenemos que dirigirnos a varias fuentes y esto es muy engorroso. Por el contrario, la documentación para la API de OpenTV es una guía bien ordenada y concisa de cada una de las funciones de la arquitectura y de su uso. Como vemos, hay algunos puntos fuertes y otros débiles en cuanto a las guías para MHP o para OpenTV. El estándar MHP proporciona algunos ejemplos de uso pero no son particularmente concisos y no incluye ningún manual que sirva de referencia para crearlos, sólo en ciertos sitios Web de MHP existen tutoriales que explican con mayor o menor fortuna el proceso. En cuanto a libros no existe ninguno destacable porque lo que prevalecen son las guías y manuales. A OpenTV le pasa algo parecido, en su SDK vienen incluidos varios ejemplos de programas, pero no incluye un manual de referencia, aunque sí existen tutoriales para el manejo del entorno de desarrollo. No hay guías online independientes del organismo OpenTV ni tampoco libros, pero en cambio si organizan cursos de aprendizaje. Las implementaciones de las APIs OpenTV y MHP y sus librerías difieren bastante en cuanto a su disponibilidad. Por un lado, la plataforma propietaria OpenTV proporciona una implementación con licencia GNU. Sorprendentemente, DVB, que son los diseñadores del estándar MHO, no proporcionan directamente una copia del paquete MHP. Hay que recurrir a fuentes independientes para acceder a implementaciones de MHP, algunas de ellas propietarias, otras son gratuitas como el paquete mhpstubs que se ha utilizado para compilar las clases en este proyecto. Para el desarrollo y la compilación de aplicaciones MHP, podemos usar un entorno de desarrollo convencional como Eclipse o NetBeans. Para OpenTV también vale cualquier entorno de desarrollo de código C, como Visual C++, o incluso un editor de texto cualquiera y el compilador gcco (imprescindible en todos los casos). Este compilador lo podemos encontrar en la página Web de OpenTV con licencia pública GNU. Otro factor que contribuye en gran medida a la facilidad de aprendizaje es el modelo en el que se basa el lenguaje que utiliza. MHP usa Java estándar además de otros paquetes basados en el mismo lenguaje. Por eso nos encontramos ante un tipo de desarrollo orientado a objetos, porque Java lo es. Esto es muy interesante para todos aquellos que comiencen su andadura en la creación de aplicaciones interactivas para la televisión porque la manera de trabajar les resultará muy familiar si ya han creado contenidos Java para programas de ordenador. en cambio, OpenTV utiliza C, y si para imitar el modelo orientado a objetos hace uso de los llamados gadgets organizados en estructura de árbol. Cada Gadget realiza funciones similares a un objeto en MHP. A pesar de que esto puede incrementar inicialmente el tiempo que se tarda en aprender OpenTV, las librerías proporcionadas son bastante fáciles de usar. Por lo demás no se han encontrado mayores inconvenientes en el proceso de crear componentes para el juego del Trivial usando esta pseudo-orientación a objetos. Funcionalidad de la API. Realmente podemos encontrar algunas diferencias significativas entre la funcionalidad proporcionada por MHP y OpenTV. Por un lado, OpenTV y MHP trabajan con el mismo número de planos para formar la imagen final en pantalla. Hay uno de fondo, otro para el vídeo, y otro para los gráficos. La única diferencia es el nombre que se le da a cada plano;ya que por ejemplo OpenTV al plano de fondo le llama On Screen Display (OSD) y al plano dedicado a gráficos le llama Still Image Plane. Pero en el fondo estos planos tienen las mismas funciones aunque se llamen diferentes. Además las dos arquitecturas soportan planos adicionales para mostrar otros componentes, como por ejemplo subtítulos. Mientras que ha quedado claro que los planos son en esencia los mismos, hay una diferencia evidente en cuanto a la transparencia que podemos aplicar a cada uno de ellos. MHP dispone de un control total de la transparencia de los elementos del plano de gráficos situado sobre el plano de vídeo. Sin embargo OpenTV no soporta transparencia entre estos dos planos. Por lo tanto cualquier elemento de la capa del plano de gráficos que esté encima del video del plano inferior lo ocultará irremediablemente. Para finalizar este estudio de las transparencias, sólo añadir que ambas plataformas soportan transparencia entre el plano de fondo y los componentes gráficos y de video que estén situados por encima. Figura 10: Logotipos de las dos Plataformas. Los formatos de imagen disponibles para la capa de fondo también son distintos para cada arquitectura. OpenTV sólo permite mostrar imágenes en formato PIX o fondos planos. MHP en cambio soporta un mayor número de formatos, como 1 0

11 JPEG o PNG, sin embargo no permite imágenes PIX. En el plano de gráficos ambos sistemas soportan imágenes JPEG y MPEG, sin embargo OpenTV no acepta imágenes PNG. Otro punto de discrepancia lo encontramos a las fuentes de las que MHP y OpenTV disponen para cargar estas imágenes. OpenTV solo muestra aquellas que le llegan por la señal de entrada al STB, o las que están localmente almacenadas en él. OpenTV puede descargar archivos remotos, pero no puede mostrarlos o trabajar con ellos hasta que tiene una copia local de los mismos. Por el contrario, MHP es capaz de acceder a contenidos desde muy diversas fuentes, como por ejemplo desde la señal de entrada, desde el carrusel de datos de aplicaciones, o desde servidores remotos, sin tener la necesitad de descargar el archivo completo al STB para luego utilizarlo. Los métodos disponibles para mostrar video también cambian de un sistema a otro. OpenTV solo es capaz de reproducir flujos de video convencionales. MHP además de esto usa la técnica de drip feed, que reduce el uso de los recursos y del ancho de banda necesario, gracias a que los planos que forman el vídeo que son similares y van seguidos se superpongan y no sea necesario reemplazar completamente el antiguo por otro más nuevo continuamente. OpenTV solo accede al flujo de datos que llega hasta el STB por la señal convencional y no puede conectarse a servidores remotos para obtener los videos. MHP en cambio puede hacer las dos cosas. En cuanto a la opción del escalado, los dos sistemas la contemplan y el formato de los videos a reproducir es MPEG- 2 en ambos casos. No ocurre lo mismo en cuento a los formatos de audio. MHP viene preparado para reproducir MPEG-1 y MPEG-2 y OpenTV también, pero además este último soporta Dolby AC2 y AC3. El estándar MHP no menciona estos formatos por ningún lado. Para finalizar el apartado de audio, sólo añadir que los dos disponen de soporte para el códec PCM que se usa para archivos de tipo WAW. Las funcionalidades de visualización de texto son las mismas para ambas arquitecturas. Las dos permiten mostrarlo en el plano de los gráficos, tomando como fuente o el código embebido en la propia aplicación, o el contenido de un archivo. De igual manera en OpenTV y en MHP existen métodos de temporización que pueden servirnos para mostrar el tiempo en pantalla o crear elementos síncronos. En cuanto a los dispositivos de entrada los dos sistemas reconocen al mando a distancia como el principal dispositivo para controlar el comportamiento de una aplicación por parte del usuario. Sin embargo la lista de eventos de entrada que pueden ser reconocidos varía de una arquitectura a otra. OpenTV y MHP controlan las pulsaciones de los botones comunes de un mando de Televisión Digital, como son los números, los botones de navegación, y los cuatro botones de elección (verde, azul, amarillo, rojo). MHP también puede reconocer la entrada de un teclado estándar QUERTY, mientras que OpenTV no puede. En el proceso de captura y tratamiento de eventos también hay disimilitudes. En concreto, las aplicaciones de OpenTV crean mensajes, que se envían a un bucle infinito que los recibe. MHP en cambio usa el sistema estándar de Java de manejo de eventos, en las que ciertas clases lanzan señales y otras funciones están esperando a escucharlas. Los protocolos usados para conectarse a los servidores son básicamente los mismos para MHP y OpenTV. Ambos sistemas soportan TCP-IP y UDP y conexiones http. Además, MHP permite el acceso a objetos dentro del carrusel de objetos del flujo de emisión que llega al STB, con el protocolo DSM-CC U-U RPC (Digital Storage Media, Command and Control User-to-User Remote Procedure Call). Tamaño de los componentes. Un vistazo rápido al gráfico de líneas de código que mostraremos a continuación indica claramente que existen diferencias entre los tamaños de los bloques codificados en ambos sistemas. Como aspectos más destacables podemos decir que parece que los componentes de OpenTV que muestran gráficos o texto parecen tener más código que los similares en MHP. Sin embargo los componentes que reproducen audio o video son más pequeños en OpenTV que en MHP. Todo esto lo podemos comprobar más detenidamente en el gráfico que mostramos a continuación, que se ha elaborado en base a datos recogidos de los trabajos de codificación de componentes similares para otras investigaciones, como las de Vuorimaa [6].. Conclusión. Figura 11: Comparativa temporal entre MHP y OpenTV Este estudio ha servido para quedar de manifiesto varios puntos importantes que nos pueden ayudar a decantarnos por usar una u otra tecnología. El primero de ellos es que si nos ponemos en la piel de un programador que se embarca en su primera aplicación de televisión digital interactiva, OpenTV es la solución más sencilla. La calidad de su documentación es mayor que la que nos proporciona MHP por el momento. Sólo los inconvenientes que hemos encontrado para ejecutar una aplicación MHP en un 1 1

12 1 2 decodificador con esta tecnología, puede ayudarnos a hacernos una idea de lo engorroso que es iniciar la andadura como programador MHP. MHP y OpenTV comparten muchas funcionalidades, con sólo algunas diferencias por ejemplo en los formatos de contenidos que pueden mostrar. Posiblemente la diferencia más notable la encontramos en el audio al no soportar Dolby AC2 y AC3. La longitud de código necesario para crear los mismos componentes en OpenTV y MHP no varía sustancialmente salvo en los casos que ya hemos señalado en fases anteriores del esta comparativa. Por eso ninguno de los dos sistemas parece ofrecer una ventaja en cuanto a al tamaño del código. Por otro lado está claro que la API de OpenTV ha sido diseñada específicamente para su uso en la televisión. Por el contrario la API MHP es el resultado de adaptar paquetes diseñados para ordenadores personales e Internet. DVB intentó orientar MHP al entorno de los STB y de la televisión, obteniendo unos resultados más que cuestionables. MHP tiene funcionalidades que hoy por hoy sólo tienen sentido en redes como Internet. En los años venideros posiblemente todas estas características tan potentes lo conviertan en la mejor opción, sobre todo si el Internet a través de la televisión finalmente despega. En definitiva es necesario que MHP siga mejorando, sobre todo intentando ser más accesible y fácil de usar y para que por fin acabe siendo adoptado cada vez en más lugares. Por eso, aunque esté siendo tan costosa nuestra familiarización con el estándar, debemos apostar finalmente apostar por él porque es positivo para la industria y necesario para dar soporte a los nuevos servicios que están por venir. B. Comparativa MHP vs MHEG Aparte de MHP, que ya vimos en la comparativa anterior, existe otro protocolo que puede ser una alternativa interesante para permitir que los receptores sean multimedia. Se trata de un sistema adoptado por ISO y conocido comúnmente como MHEG (Multimedia and Hypermedia Information Coding Expert Group), deriva en parte de las especificaciones DAVIC. Veamos una comparación entre estas especificaciones comenzando con un vistazo a la arquitectura MHEG-5. De MHP no hablaremos más porque ya lo hemos hecho en apartados anteriores de este documento 1. Arquitectura MHEG-5 ISO define una familia de estándares MHEG, desde MHEG-1 hasta MHEG-7, que permite distribuir objetos multimedia en una arquitectura cliente-servidor a través de una variedad de plataformas. MHEG-5 es una versión de MHEG-1 mejorada y específica para aplicaciones para receptores de bajo presupuesto que embebe una aplicación de arranque MHEG en el flujo MPEG-2. El nombre y la ubicación de la aplicación de arranque en el carrusel de objetos DSMC (Digital Storage Media Command and Control) está definido por parámetros en una tabla de información de servicios (SI). Figura 12: Arquitectura MHEG-5 La aplicación de arranque es un objeto independiente e interpretado que describe: La estructura del display en la pantalla del receptor (OSD: on-screen display); los hipervínculos a pantallas alternativas; la posición y los vínculos al contenido en los objetos embebidos, como los flujos de audio y video; el redimensionado, la resintonización, y la recolocación del plano de vídeo activo; y el playback de contenido que dependa del tiempo, tales como los datos audiovisuales multiplexados. Esta aplicación de arranque incluye un conjunto básico de clases MHEG-5. Estas clases son: Application (aplicación), que contiene una colección de escenas y componentes. Scene (escena), que contiene una colección de componentes descritos en términos de coordenadas de presentación (OSD). Ingredient (componente), una clase base abstracta para una serie de subclases. Presentable (presentable), que especifica los atributos comunes de información que se puede ver o escuchar. Visible (visible), que amplía la clase Presentable para describir el posicionamiento y el comportamiento de variables como bitmaps, círculos, rectángulos, líneas, texto, y colores de relleno. Stream (flujo), que controla la presentación y sincronización de los datos audiovisuales, como los flujos comprimidos MPEG-2. Link (enlace), que, en su forma más simple, proporciona una transición a otra escena. Interactable, que permite la interacción del usuario con objetos en las siguientes subclases: switchbutton, hotspot, y pushbutton; hypertext; y slider y entry field. Además, MHEG-5 define un conjunto de clases de programas residentes que incluyen día/fecha/hora DAVIC, manipulación de OctectString, ajuste de servicio, y comunicación ampliable y de interfaz común.

13 Extensiones de MHEG-5 MHEG-6 extiende MHEG-5 añadiendo una API de Java y la máquina virtual de Java (JVM) 4. Estos componentes realizan el procesamiento de los datos, tales como la interpretación y la presentación de los datos SI (información de un servicio) en una guía de programación electrónica (EPG), y se comunica con los controladores de los dispositivos locales (java.util y java.io). Un elemento clave de MHEG-6 es un mecanismo que permite que las aplicaciones descargadas se ejecuten en el receptor, en lugar de que un intérprete las procese, como un motor MHEG. Este mecanismo allana el camino a las aplicaciones que: Proporcionan un canal de retorno, a través de un módem serie IP de la línea telefónica de un cliente. Analizan sintácticamente, interpretan, y muestran los datos SI en varios formatos accediendo directamente a los flujos de datos del demultiplexor del sistema. Se comunican directamente con hardware de interfaz estándar para permitir, por ejemplo, módulos de acceso condicional de vendedores específicos. Proporcionan un sistema de ficheros de lectura/escritura y módulos de bases de datos para un almacenamiento eficiente. Como se muestra en la figura 2, MHEG-6 también es compatible con MHEG-5. Esta compatibilidad se logra mediante el motor MHEG, que pasa el Java byte code MHEG- 6 directamente a las JVM (Máquina virtual de Java). Figura 13: Arquitectura MHEG Coincidencias entre especificaciones A pesar de las dos posturas, realmente bastantes concordancias entre MHEG y MHP. Por ejemplo: Ambas usan MPEG-2 para codificar video, audio, y otra información para transportar sobre canales digitales terrestres. Ambas usan el protocolo abierto DSMCC, una subsección de MPEG-2, para entregar objetos multimedia sobre redes cliente-servidor distribuidas. Ambas describen clases Java soportadas por una maquina virtual de java residente. La clave para mostrar contenido multimedia en un STB es el mecanismo por el cual se transmiten y se reciben los objetos de datos. MHEG y MHP usan el protocolo DSMCC para realizar esta función. El DSMCC tiene un carrusel de objetos que proporciona un sistema de clasificación transmitiendo cíclicamente objetos como imágenes, aplicaciones de arranque, y diseños de páginas (por ejemplo documentos XML). Una API definida por DAVIC describe un formato URL para referenciar elementos en el carrusel, permitiendo direccionar un objeto de manera similar a como se referencias archivos o directorios en UNIX (por ejemplo //d/a es una aplicación de arranque típica en MHEG). Muchas implementaciones de MHP y MHEG mejoran la velocidad del carrusel de objetos DSMCC metiendo en caché la mayoría, si no todos, los datos para un flujo DSMCC particular. Además para soportar DSMCC, MHP y MEHG-6 requieren la ejecución de código en el STB receptor. Por esta razón, ambos especifican clases Java que deben ser soportadas por una máquina virtual de java residente. Por el contrario, MHEG-5 no usa una máquina virtual de java, ya que sus aplicaciones son documentos interpretados con hiperenlaces embebidos, que no necesitan ejecutar código. Para un objeto que venga del carrusel DSMCC a ejecutar, debe tener acceso limitado a una variedad de recursos del sistema, como los sistemas de fichero y las rutas de entrada/salida. El principal problema aquí, a parte de la seguridad, es que los emisores no tienen ni idea de en qué sistema operativo se ejecutarán esos objetos. Una maquina virtual de java resuelve este dilema proporcionando una capa de abstracción entre el sistema operativo a bajo nivel y el byte code en Java compilado de una aplicación MHEG-6 o MHP. El que más probabilidades tiene de ser usado en STBs de bajo coste es el J2ME CLDC (J2ME connected limited device configuration), que define una máquina virtual kilobyte (KVM), una versión de capacidad reducida de la máquina virtual de java que no soporta operaciones en coma flotante. La especificación CLDC define un conjunto de clases núcleo que deben de implementarse. Estas son extendidas por MHP y MHEG-6. MHP utiliza la plataforma DVB-J con APIs Java adicionales definidas por HAVi y DAVIC. MHEG-6 extiende un conjunto básico de APIs Java, incluyendo java.lang, java.util, y java.io, para permitir el acceso a recursos limitados del STB. La categoría de servicio MHP más avanzada, Internet Access, es donde las dos especificaciones comienzan a diferenciarse. MHP define extensiones adicionales para la navegación Web, clientes de correo, y correo Web. MHEG-6 anda corto en esto, cono extensiones IP para solo un canal de retorno. Sin embargo, MHEG-6 necesita solo un perfil alternativo para desarrollar esta capacidad. Por lo tanto, hay bastante en común entre MHP y MHEG. La diferencia está claramente en los detalles, más que en la aplicación. Últimamente ambos apuntan a transmitir datos multimedia mejorados a los telespectadores, con especificaciones adicionales para la interactividad.

14 1 4 V. ESCENARIO DE PRUEBAS Una vez sentados todos los aspectos teóricos necesarios para conseguir una visión válida de lo que es la televisión digital interactiva y de las tecnologías que lleva asociadas, en este apartado del documento vamos a mostrar la parte prácticadesarrollada para este trabajo de fin de carrera y que viene a ejemplificar todo lo aprendido anteriormente. En un primer momento, y en vista del análisis de escenarios posibles de pruebas que se llevó a cabo (sección 10 de este documento), la situación no era para nada esperanzadora. Si se pretendía ser estricto y realizar experimentos de emisión parecidos a los que llevan a cabo los emisores de cadenas digitales, los costes se disparaban, y desde luego no podemos asumir una inversión cercana a los 5000 para un proyecto de fin de carrera. Eso por no hablar de las licencias y permisos que son necesarios para usar el espectro radioeléctrico, y que en caso de solicitarse, podrían tardar meses en ser concedidas (con toda la burocracia y trámites administrativos asociados). Si se optaba por hardware más barato, como las tarjetas PCI moduladoras, no conseguíamos bajar de los 1500 que tampoco es una cifra aceptable. Parece que la única opción que quedaba era usar emuladores, y por supuesto, los gratuitos. Los de pago suelen venir junto con entornos de desarrollo privados que tienen licencias carísimas. Parece que lo único que nos quedaba era usar el emulador XletView, que a día de hoy es la única opción que cualquier persona que quiera iniciarse en la programación MHP y que no quiera arruinarse en el intento puede utilizar. Pero los primeros resultados fueron bastante desesperanzadores. El emulador tiene demasiadas carencias. Pero gracias a las conversaciones con otros grupos de desarrollo MHP en España y de muchas búsquedas, se ha conseguido una solución alternativa de bajo coste y que resuelve los problemas de los emuladores. A. Decodificador elegido. El decodificador elegido, como ya se ha adelantado anteriormente, es el modelo SRT 5510 comercializado por la marca Strong. Figura 14: Decodificador que hemos comprado para el escenario. Otra ventaja muy interesante de cara a futuros servicios que se espera estén disponibles pronto, es que tiene lector de tarjetas, por lo que podemos introducir el DNI electrónico y así acceder a aplicaciones de la administración como son la consulta de datos administrativos, declaración de la renta Además, el canal de retorno que posee es de tipo Ethernet, por lo que el ancho de banda y la calidad del enlace es mucho mayor que losque ofrecen los equipos con MODEM. Todo ello unido a que su precio no es excesivamente caro (85, gastos de envío incluidos) nos han llevado a apostar por adquirir uno de ellos para nuestras pruebas. B. Software de control del decodificador. El software parte del SDK de Osmosys y permite que todos los decodificadores que tengan una implementación interna compatible con sus librerías MHP puedan probar aplicaciones usando el puerto serie. Otros receptores como los ican permiten ejecutar programas de la misma manera pero hay muchos más problemas y el proceso de configuración es todavía más arduo. Está formado por dos programas independientes pero relacionados entre sí; ambos se ejecutan en modo consola: El primero de ellos, stbproxy crea un proxy sobre el puerto serie que sirve para enviar los datos del ordenador al STB de manera correcta. Necesita como parámetros únicamente el número de puerto al que hayamos conectado el receptor. El segundo, stbupload. Una vez que se ha creado el proxy, se encarga de enviar todos los archivos de la aplicación que queramos ejecutar, así como información para el STB de cuál es la clase principal a ejecutar. C. Otros componentes necesarios. Aparte del decodificador de pruebas, es evidente que hay otros componentes esenciales que forman parte del escenario de pruebas; el más evidente de todos ellos, es sin lugar a dudas, la televisión. Para estos propósitos se recomienda una tele con más de 20 pulgadas, y con entrada para euroconector. La televisión Sony Bravia disponible en el laboratorio es la elección perfecta, pero sirven otras. El segundo componente en importancia del que todavía no hemos hablado es el ordenador. El único requerimiento esencial del mismo es que debe contar con un puerto serie RS- 232, por eso hay que ir olvidándose de portátiles y ordenadores modernos que ya no lo llevan incorporado. En cuanto a especificaciones ténicas sólo decir que es suficiente con que sea capaz de correr Windows XP. No se ha probado a ejecutar la aplicación de envío de datos por el puerto serie en entornos Windows virtualizados, pero en un principio no parece que pueda haber demasiados problemas para que todo funcione según lo esperado. Las razones para haber apostado por esta marca y modelo son varias, la más importante de ellas es sin duda el hecho de ser de los pocos del mercado en incorporar MHP 1.1.X, por lo que ofrece un grado de interactividad mucho mayor que otras alternativas disponibles.

15 1 5 Figura 18:Conexión del STB para RS-232. Conectar el otro extremo del cable de serie cruzado al puerto RS-232 de nuestro ordenador. Figura 19: Conexión RS-232 del ordenador. Figura 15: Visión total del escenario. Para finalizar, necesitamos una aplicación que muestre datos que llegan al ordenador por alguno de los puertos serie. Como estamos trabajando en el sistema operativo Windows, disponemos por defecto de la aplicación Hyperterminal que permite conectarse a cualquiera de los puertos serie del ordenador, con diferentes configuraciones de velocidad de datos y corrección de errores, para mostrar lo que llega por él en pantalla D. Conexión de los componentes. Una vez que disponemos de todo lo necesario para tener nuestro escenario de pruebas, vamos a proceder a conectar todas las piezas de manera adecuada para tenerlo montarlo. No existe ningún paso demasiado complejo en este apartado, la interesante está más en la configuración sotware de comunicación entre el STB y el PC. No obstante, vamos enumerar las acciones a realizar: Conectar el cable entre el euroconector del STB y la entrada de la televisión. De esta forma, la imagen formada en el STB llegará a la televisión para ser mostrada en pantalla. Figura 16: Conexión del STB para euroconector. Conectar la el cable coaxial, desde el que recibimos señal analógica de televisión, en el puerto adecuado situado en la parte posterior del STB. Figura 17: Antena desde la que nos llega la señal TDT. Conectar el cable de serie cruzado en la parte trasera del STB. De forma opcional, si vamos a realizar pruebas con el canal de retorno, podemos conectar el STB a un router o directamente al PC de pruebas usando un cable Ethernet cruzado. E. Inconvenientes Propios del escenario. La elección de este escenario de pruebas, a la que nos han llevado las condiciones comentadas en la introducción de esta sección, acarrea una serie de inconvenientes que ya conocíamos de antemano: Ancho de banda limitado: el cable de modem nulo tiene una capacidad de transmisión de datos realmente poco atractiva. Lentitud de carga de las aplicaciones. Como consecuencia de la problemática del punto anterior, el dinamismo a la hora de enviar aplicaciones al STB y depurarlas (sabemos de sobra que cuando buscamos errores en una aplicación el ciclo corregir ejecutar de nuevo se repite constantemente) es un poco desesperanzador. Tienes que pensar bien los cambios de código que vas introduciendo y comprobarlos varias veces antes de volver a subir la aplicación al decodificador porque cada vez que lo hacemos perdemos bastante tiempo. Es imposible la sincronización de la aplicación con la imagen o el audio. Dado que el contenido multimedia viene a través de la señal convencional y la aplicación MHP lo hace por el puerto serie, no podemos sincronizar ambas partes. Hay que hacer uso de Software Privado. Los decodificadores que realmente soportan poder cargar aplicaciones por el puerto serie son los que incluyen implementaciones Osmosys. Por eso ellos mismos diseñan los programas de envío de datos por el puerto serie y si queremos hacer uso de esta alternativa debemos recurrir a los programas que ellos proporcionan, al no haber otra opción similar que sea libre. No se pueden hacer pruebas de ruido, de calidad de la señal, o de pérdida de información porque la aplicación la estamos enviando por un canal bien distinto al de la televisión digital terrestre que es el que se usará en pruebas reales y por tanto el que nos interesaría estudiar.

16 VI. IMPLEMENTACIÓN DE UEX-TVI. A. Definición del problema. Después de todo el trabajo y esfuerzo que ha sido necesario poner para llegar hasta aquí, parece un error no avanzar un poco más y aprovechar la infraestructura montada. Se cuenta con un decodificador MHP comprado específicamente para este proyecto, y parece una pena no aprovecharlo un poco más, no conocer de primera mano sus posibilidades, y quedarnos simplemente en que gracias a él tenemos operativo un escenario que puede ejecutar aplicaciones sencillas como la del punto anterior. Y sí, es cierto que a estas alturas podemos tener una idea bastante clara de cómo funcionan las cosas en el mundo de la televisión interactiva, de qué herramientas usar dependiendo de la situación... podemos decir que se han cumplido los objetivos en este aspecto. Pero si tuviéramos que enfrentarnos a un proyecto real de desarrollo de aplicaciones interactivas para la televisión, quizá esas nociones básicas sobre el manejo del estándar MHP y todo el bagaje teórico pudieran no ser suficientes. Para terminar, tener una aplicación de con entidad en un campo innovador como la televisión digital es ciertamente positivo para la universidad. Sobre todo teniendo en cuenta que en toda la UEx no existen otros investigadores o grupos de trabajo dedicados a esta tecnología. La temática de esta aplicación será una en concreto que expondremos en la sección de alcances y objetivos, pero lo importante es que puede convertirse en un esqueleto o modelo para que otras personas de la universidad la usen y puedan publicar sus contenidos utilizando la televisión digital interactiva, aprovechando así esta nueva manera de difusión de contenidos. Por esta importancia que tiene para el ámbito de nuestra universidad un desarrollo como este, el nombre elegido para la aplicación es UEX-TVi. B. Alcances y objetivos. En este apartado, como su propio nombre indica, vamos a enumerar las razones que han motivado iniciar el desarrollo de esta aplicación y los resultados que pretendemos obtener haciendo uso de ella una vez terminada. Por un lado existen una serie de intereses funcionales, es decir, útiles de cara a las personas que van a utilizar este programa; los enumeraremos a continuación: Conseguir una aplicación para que los alumnos de la Universidad de Extremadura puedan acceder a la teoría de una determinada asignatura o materia a través de la televisión digital interactiva en cualquier lugar, siempre que haya señal adecuada (es lo más normal, porque la cobertura es amplia) y contemos con un receptor adecuado. Para ello se tiene que recurrir a contenido multimedia: audio, video, imágenes Poder disponer de una herramienta para evaluar los conocimientos adquiridos de manera ágil y sencilla. Parece realmente útil que los alumnos que hayan estudiado unos ciertos contenidos teóricos puedan saber que lo han hecho de manera adecuada, mediante la realización de algún tipo de prueba, cuyos resultados puedan ser evaluados por un profesor de forma remota. Visionar páginas Web en el televisor. Aunque como explicaremos más adelante esta parte es demasiado profunda para abordarla en su totalidad en este proyecto, y realmente lo que se haga es implementar un navegador muy básica, es de gran importancia poder demostrar que tenemos las herramientas necesarias para que visitar páginas de Internet con el mando a distancia sea posible. Servir como base y ejemplo a seguir para otras posibles utilidades a encontrar en el ámbito de nuestra universidad. La persona que necesite publicar información mediante la televisión interactiva, tendrá buena parte del trabajo solucionado porque podrá tomar como referencia lo programado en este proyecto. Iniciar una línea de investigación prolongable en el futuro, es decir, promover que la universidad cree grupos de investigación que continúen con el trabajo realizado ya en este proyecto de fin de carrera y lo mejoren. Por otro lado existen otros intereses relacionados con aprender y ejemplificar la potencia del estándar MHP: Comprobar las funcionalidades del perfil de emisión estándar. Lo primero es demostrar que podemos realizar aplicaciones que siendo enviadas al receptor se ejecutarán correctamente en él. Esto lo confirmaremos implementado el temario, una parte de nuestra aplicación que simplemente muestra contenidos teóricos a los usuarios. Relacionado directamente con el punto anterior, comprobar la capacidad del estándar para traer contenidos multimedia a casa. Se trata de ver si somos capaces de manejar imágenes o reproducir videos y sonidos para que las aplicaciones sean realmente interesantes para el usuario (el temario será mucho más vistoso con imágenes y sonidos, por ejemplo). Comprobar de interactividad e interactividad mejorada. Se trata de que el usuario pueda enviar información de vuelta a la estación emisora (u otra máquina donde se requieran los datos). Si la interactividad mejorada, la estación emisora modificará los contenidos que difunde en función de los datos recibidos de los televidentes. Comprobar el perfil de internet. Lo haremos implementando el navegador Web. C. Estudio de viabilidad y análisis de costes. Antes de comenzar el diseño y la implementación, se ha realizado un estudio para determinar si es posible el desarrollo del proyecto que anteriormente hemos planteado. Separaremos este análisis en tres partes: 1 6

17 Viabilidad técnica Desde el punto de vista técnico se ha decidido abordar el proyecto de manera secuencial, de manera que se han planteado una serie de cuestiones a resolver, intentando que cada una sea lo más independiente de las otras que se pueda, y se han ido solucionando una tras otra. Estas partes ha sido por ejemplo: carga de imágenes, reproducción de sonidos, uso del canal de retorno El lenguaje a utilizar ya sabemos que es Java, por lo que no hay inconvenientes en cuanto a encontrar un entorno de programación libre y gratuito. En cuanto a las librerías a utilizar, usaremos la ya mencionada MHPstub. El resto vienen de serie con el compilador. El Sistema Operativo de la máquina donde se ha programado es Mac OSX Leopard, debido a que el proyectando cuenta con un portátil Macbook. No obstante se probado a compilar y escribir el código en entornos como Ubuntu 8.04 y evidentemente todo ha funcionado bien debido a que Java es multiplataforma. Viabilidad económica Claramente todo este trabajo se realiza con motivo de la realización de un Proyecto Final de Carrera, la persona que lo está elaborando no tiene que percibir ningún tipo de remuneración por realizar el trabajo. En cuanto a los entornos de desarrollo, y las librerías, son todas de uso libre y gratuito. Por ello, no invertiremos cantidad de dinero alguna en software, ni en esta parte del proyecto ni en las otras porque los entornos de desarrollo (idesigner) y la aplicación Osmosys de carga han sido cedidos amablemente por las empresas distribuidoras para ser probadas. Los ordenadores donde se lleva a cabo la programación y el envío de las aplicaciones al decodificador son uno propiedad del autor del proyecto (portátil Macbook) y otro de la universidad. La televisión pertenece al grupo de investigación GÍTACA, por lo que tampoco se necesitan desembolsos adicionales para este material. El decodificador sí es un coste a tener en cuenta pues no se posee uno con soporte para MHP y es necesario comprarlo. También hacen falta un cable RS-232 de módem nulo y un cable euroconector. El decodificador tiene un precio de 80 para estudiantes, el euroconector ronda los 3, mientras que el RS-232 cuesta sobre 10. En total unos 93 que es asumible para nuestro caso (recordemos que el resto de los escenarios de pruebas no bajaban de algunos miles de euros). Por tanto evidentemente el proyecto es correcto en lo que se refiere a términos económicos. Viabilidad operacional Este tipo de viabilidad en nuestro caso no requiere de demasiado tiempo de análisis, porque al traterse de un Proyecto Fin de Carrera no tiene como necesidad indispensable el desarrollo de un sistema totalmente funcional, puesto que se trata de dar a conocer una tecnología y aprender a aprovecharla y no de cumplir una serie de especificaciones impuestas por el comprador de un producto. La idea es evidentemente enfrentarnos a un proyecto lo más parecido posible a los que se afrontarán en el mundo laboral, pero sin unas restricciones operacionales tan fuertes. Una vez realizado cada uno de los estudios individuales de viabilidad, podemos decir a priori que el proyecto UEX-TVi es factible de llevar a cabo. D. Costes y beneficios. Como ya hemos comentado, para nuestro caso realizar un análisis de costes y beneficios no es estrictamente necesario, ya que al tratarse de un proyecto de fin de carrera, el proyectando no cobra por su trabajo (por lo que no se producen costes) y la aplicación no entra en explotación como tal (inexistencia de beneficios directos). No obstante, es de gran utilidad realizar un cálculo aproximado de estas cantidades. Lo primero que tenemos que calcular es el total de horas que hemos dedicado para que todos los resultados salgan finalmente a la luz y esta aplicación pueda ser presentada el día de la lectura del proyecto. Aquí podemos tomar dos posturas distintas que hacen variar el tiempo total empleado: Una postura que considera que durante los primeros meses del proyecto, únicamente se hizo una puesta en situación sobre el mundo de la televisión digital interactiva, que hay que separar del trabajo del diseño y de la implementación de la aplicación que se ha realizado durante los meses posteriores. Otra postura que considera que el proceso de codificación y de aplicación real una consecuencia directa de lo aprendido en el análisis y búsqueda de información, por lo que ambas fases deben ir ligadas. Nosotros adoptaremos la segunda opción. Pasemos a calcular el número de horas: Consideraremos como fecha de inicio del proyecto el día , pues debido a problemas con la asignación del proyecto y dudas con la nueva normativa, no se comenzó a trabajar hasta llegado ese tiempo. Consideramos la fecha de fin del proyecto como el día de presentación del proyecto, Durante este tiempo, no se ha trabajado con el mismo nivel de intensidad durante los primeros meses que en los últimos. En este sentido, podemos hacer distinción en tres fases distintas en cuanto al número de horas diarias que se ha trabajado: o o 1ºFase: Del mes de diciembre al mes de junio. (7 meses). Como todavía había que realizar las asignaturas del 5º curso la dedicación no fue tan completa como posteriormente. Se trabajaron dos horas por día, por tanto: 2ºFase: Del mes de julio al mes de septiembre. (3 meses). Con ninguna asignatura más que el propio proyecto de fin 1 7

18 de carrera, se aumenta el número de horas diarias dedicado hasta llegar a las 5. Por tanto: 1 8 o 3 Fase: del mes de octubre hasta mitad de diciembre (2 meses y medio). La entrega del proyecto se acerca y se ha dedicado el total de la jornada a trabajar en el proyecto, es decir, 8h al dia. Por tanto: En total, el número de horas es: Si establecemos que al investigador de este proyecto se le paga 20 / hora trabajada, podemos deducir de manera sencilla que en total al final del proyecto se le tendrían que abonar: Podemos sumar el precio del decodificador y los cables, que sí son reales, pero son insignificantes: Como vemos, se trata de una cifra bastante importante. Pero contratando a dos personas en lugar de a una, se conseguirán mejores resultados. Una persona es fácil que cometa errores y quede atascada en ciertas partes del desarrollo. Si hay más integrantes en el grupo, unos pueden sacar adelante la situación cuando lo otros no se vean capaces por lo que el tiempo total se reduce. Si realizamos proyectos parecidos, ya sabremos a priori como actuar y utilizaremos códigos y algoritmos que sabemos que funcionan. Cuando se hace una cosa por primera vez, no se sabe exactamente cómo abordar el problema, y hay que cometer muchos errores y hacer pruebas ensayo-error (recordemos lo costoso temporalmente que era hacer una traza con este escenario) que alargan mucho el proceso. Esto no ocurrirá si ya tenemos dominados los trucos de programación y localizados los recursos. El beneficio es una variable aún más difícil de calcular que la anterior aquí no se sabe a ciencia cierta quién va a utilizar la aplicación y si alguien va a pagar una cierta cantidad u otra para poder aprovecharla, por eso es casi imposible hablar de ganancias. No obstante, una cosa sí es clara: obtenemos un enorme ventaja para el conjunto de la universidad, porque proporcionamos a los profesores, investigadores y alumnos el poder hacer uso de un canal de comunicación que hoy por hoy no se está utilizando en estos ámbitos y que puede tener un potencial enorme..

19 1 9 E. Diagrama de clases de la solución buscada. Vamos a ver los diagramas de clases más importantes de la aplicación para ver las asociaciones y relaciones de herencia establecidas. Como muchas de las clases presentan gran cantidad de métodos, en el diagrama sólo mostraremos los públicos. El primero hace referencia a la clase principal del problema y muestra de que otras clases hereda. Esta es una de las que más funcionalidad tiene, pues implementa todos los menús de la aplicación, los cambios en el modo de vídeo, y el envio de los resultados del concurso. Figura 22: Diagrama de clases del teclado. Y el cuarto y último sirve para mostrar las dos clases que se encargan de realizar las peticiones HTTP por el canal de retorno: Figura 20: Diagrama de clases principal El segundo se refiere a los componentes utilizados para realizar la interfaz de usuario: botones, etiquetas, listas y también otra clase adicional para la reproducción del sonido, y una clase Navegador que interpreta el texto HTML y lo muestra por pantalla de manera adecuada: Figura 23: Diagrama de clases para peticiones HTTP F. Aspecto del producto final desarrollado. En este último apartado sobre la aplicación UEX- TVi, vamos a mostrar la apariencia de la aplicación creada de cara al usuario que vaya a utilizarla. Se trata de conocer la apariencia de los menús y las distintas opciones que cuando nos sentemos frente al televisor irán apareciendo en caso de que nuestro programa se estuviera difundiendo. Ahora mismo, dado que la aplicación está en fase de pruebas, lo primero que aparecerá será la consola de depuración, que nos permite ver que todo se ha cargado e inicializado correctamente y da la posibilidad de realizar una prueba con el canal de retorno para estar seguros de que posteriormente todo funcionará bien durante la ejecución de UEX-TVi. Figura 21: Diagrama de clases de componentes gráficos El tercer diagrama muestra las clases implicadas en la implementación del teclado virtual; hay una clase que representa una tecla, otra que es un teclado genérico (agrupación de teclas) y de esta última hereda nuestro teclado virtual que tiene la disposición de caracteres que nosotros queremos: Figura 24: Consola de depuración. Si pulsamos sobre el botón de cargar, aparece el menú principal, con el logo de MHP y el de la Universidad de

20 2 0 Extremadura. Ahora podemos elegir cargar la opción que consideremos más conveniente de entre la lista de servicios ofrecidos. Además, a la izquierda del menú hay un cuadro explicativo que muestra una descripción de cada una de esas opciones para saber en qué consisten antes de lanzarlas. Figura 28: Mensaje de respuesta correcta. Figura 25: Menú principal. En el menú del temario encontramos una serie de diapositivas, cada una sobre un determinado tema del mundo de la televisión interactiva (para futuras aplicaciones, es sencillo cambiar la temática manteniendo los componentes). El concurso presenta de manera secuencial una serie de preguntas relacionadas con el temario. A cada pregunta le acompaña una imagen aclaratoria o relacionada con eltema. Aparecen también los botones de respuesta posibles para que el usuario elija la opción que considere correcta, y pase a la siguiente pregunta una vez respondida la actual. Entre respuesta y respuesta además se muestra si se ha acertado o se ha fallado y se emite un sonido acorde con el resultado. Por último tenemos el navegador Web. Es más correcto llamarlo visor Web que navegador Web, porque no es capaz aún de mostrar los enlaces presentes en los documentos HTML por lo que no podemos saltar de un hipervínculo a otro. Sin embargo se permite visionar páginas sencillas y se interpretan saltos de línea, líneas horizontales, y etiquetas de encabezados. Cuando pulsamos sobre la opción que debe de abrir el navegador, primero de todo sale en la escena una casilla de texto y un teclado virtual. Se trata de usar este teclado (navegando por las teclas con los botones de dirección del mando a distancia) para introducir la dirección de la página web. Una vez que lo tenemos listo, pulsamos el botón 3 y aparece en pantalla una ventana con el contenido de la página Web. Figura 26: Pantalla del Temario modo normal Aparte de la vista estándar del temario, que deja que veamos el canal de televisión de fondo a pantalla completa, existe otra configuración que permite navegar por el mismo mientras vemos la cadena en el cuadrante superior izquiedo de la pantalla, sin ningún componente por encima. Esto ocurre también en el menú del concurso, que pasaremos a explicar a continuación. Figura 29: Teclado virtual para el navegador Web. Figura 27: Pantalla del concurso