Especificación de una plataforma para la evaluación y

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
Resumen1 - 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 5510. 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: 10071. Tlf:
+34 927 257 195. Fax: +34 927 257 202. e-mail: [email protected].
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
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:
1.
2.
3.
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-2.
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.
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
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
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
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 23.75 Mbps @ 6 MHz)
•
Gran robustez (frente a multitrayecto y ruido impulsivo).
•
Despliegue Escalable
o
Tamaño de la célula hasta 100 km (típico 60 km)
o
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
o
o
o
o
Formato Panorámico 16:9
Imagen calidad similar a DVD
Sonido Digital Multicanal Dolby 5.1
Difusión sin interferencias
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 2000.
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 1.0.1. 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
2002. En junio del 2002, se introdujo la versión 1.0.2. Esta, a
su vez, fue seguida por la versión 1.0.3.
1.
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
•
2.
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.
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 2001. 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
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 (300-3.400 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
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 802.11. 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 802.11.
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
802.11i. 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 1.0.2 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
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 802.16 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
• 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 802.16.
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 802.162004 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.
.
IV. COMPARATIVAS DE MIDDLEWARES
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.
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
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
Figura 8:Esquema de emisión de MHP
Arquitectura 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.
1
0
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
1
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 MPEG2 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].
Figura 11: Comparativa temporal entre MHP y OpenTV
. Conclusión.
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
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.
1
3
2.
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 MHEG6 directamente a las JVM (Máquina virtual de Java).
Figura 13: Arquitectura MHEG-6.
3.
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.
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.
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.
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 RS232, 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.
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.
1
6
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
7
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 01-12-2007, 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, 17-12-2007.
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 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:
o
2ºFase: Del mes de julio al mes de
septiembre. (3 meses). Con ninguna
asignatura más que el propio proyecto de fin
1
8
de carrera, se aumenta el número de horas
diarias dedicado hasta llegar a las 5. Por
tanto:
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.
.
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 UEXTVi, 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
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
2
1
VII. ENTORNOS PROFESIONALES: IDESIGNER.
MIT-xperts iDesigner es una aplicación que permite
crear aplicaciones MHP. Es una herramienta profesional para
crear servicios de televisión interactiva eficientemente y está
dirigida a los emisores, diseñadores y creadores de contenidos.
Su intuitiva interfaz de usuario es tan simple como una
aplicación de dibujo y permite que cualquiera cree una
aplicación MHP interactiva sin necesitar conocimientos de
programación. Con un simple clic se puede subir una
aplicación al entorno de transmisión.
A. Ejemplo de aplicación – El tiempo
La finalidad de esta aplicación de ejemplo es demostrar
la funcionalidad de iDesigner, de ver como se trabaja con él, la
facilidad con que se puede crear una aplicación, etc. Se trata
de una aplicación sobre la predicción meteorológica en la
comunidad de Extremadura, que permite acceder a sus dos
provincias, Cáceres y Badajoz, y ver el tiempo que va hacer
en las principales localidades de cada una. A continuación se
explica cómo se ha realizado
La aplicación consta de tres páginas, la principal, una
para la provincia de Cáceres y otra para la de Badajoz, y una
plantilla o template.
Figura 30: Página principal
El funcionamiento de la página principal debe ser el de
poder seleccionar una de las dos provincias y al pulsar el
botón OK acceder a la página de la provincia seleccionada.
Esta página está formada por un mensaje de bienvenida,
el logotipo de la universidad de Extremadura, y un mapa de la
comunidad.
VIII. EL FUTURO:TELEVISIÓN IP + MHP.
En los últimos años, las siglas IPTV están comenzando a
aparecer por doquier. El aumento del ancho de banda y la
aparición de nuevas tecnologías han permitido el despliegue
de servicios, que hasta ahora estaban reservados para otros
medios. Hoy en día, el servicio de televisión es el caballo por
el que todos están apostando.
IPTV responde a las siglas Internet Protocol Television.
Esta definición hace referencia únicamente al mecanismo de
transmisión del servicio de la televisión IP, el protocolo para
la transmisión de paquetes usado en Internet. Sin embargo,
cuando se mencionan los términos IPTV o Internet Televisión,
no se hace referencia al modo de transmisión de estos
servicios, sino al modelo de explotación y negocio de los
mismos.
IPTV
Los entornos IPTV son los más parecidos a los entornos de
televisión más convencionales como el cable o el satélite. El
servicio es controlado por el operador de la red, empleada para
hacer llegar la señal hasta el usuario final. Esto permite que el
proveedor del servicio pueda controlar la calidad de la señal,
la oferta de contenidos o el acceso a los mismos.
El hecho de tener el control sobre la calidad de la señal se
convierte en uno de los elementos más importantes que
diferencian a los entornos IPTV e Internet Television. Por un
lado, esta diferencia permite al operador garantizar la calidad
de señal y ancho de banda mínimos para ofrecer el servicio sin
problemas de cortes, pixelados, etc. Sin embargo, para
garantizar esta calidad de señal, el operador utiliza una
infraestructura de red cerrada. La preparación de una red de
estas magnitudes supone una fuerte inversión tanto de capital
como de tiempo.
Internet Television
El modelo de televisión por Internet se basa en muchas
de las tecnologías empleadas en entornos IPTV (MPEG4,
WMV, etc.), pero su orientación es completamente distinta. La
gran diferencia radica en que el contenido es emitido desde el
proveedor de servicios al usuario final a través de Internet. Por
lo tanto, éste no tiene ningún control sobre la red de
transporte. Esta diferencia limita la libertad en cuanto al
desarrollo del negocio si tratamos de seguir el mismo camino
que en el mundo IPTV y por lo tanto, el enfoque de los
entornos de Internet Television es completamente distinto.
Internet Television se basa en un modelo abierto en el que el
control del contenido está delegado en el proveedor de dicho
contenido. Cualquiera puede generar un contenido (película,
vídeo doméstico, spot publicitario, etc.) y ponerlo a
disposición de los usuarios bajo el modelo que desee.
MHP en todo esto.
MHP sigue siendo importante para ofrecer toda la información
de servicios disponibles y para crear un entorno de ejecución
adecuado para los protocolos de internet en los que se sustenta
IPTV. Tras la carga de unos parámetros iniciales y de
información relevante por un canal tan común como la TDT,
las aplicaciones MHP pueden conectarse por el canal de
retorno TCP/IP a cualquiera de los proveedores de televisión
digital sobre IP.
Figura 31: propuesta IPTV y MHP.
2
2
34.
http://streamtel.com/index.html
35.
http://www.grassvalley.com/
36.
http://www.omb.com/es/index.php?option=com_frontpage&Itemid=1
37.
http://www.mit-xperts.com/
C. Herrero, P. Cesar and P. Vuorimaa "Delivering MHP applications
into a real DVB-T network, Otadigi" TELESIKS, 2003.
38.
http://www.screen.it/espanol/index.html
39.
http://www.advanceddigital.ca/products/dvb/tvb590.php
3.
C. Peng and P. Vuorimaa "Digital Television Application Manager"
Conferencia para IEEE en 2001
40.
http://www.sunsiberica.com/productos.php?id_producto=541&listar_pro
ducto=2&cat2=2&cat=5
4.
H. Fotschl and R. Plosch "Interactive Applications for the Multimedia
HomePlatform". Conferencia de IEEE sobre software multimedia, 2002.
41.
http://www.mundoplus.tv/noticias.php?seccion=tv_digital&relacionadas
=varios/tdt&id=2448
5.
F. Bouilhaguet, J. C. Dufourd, S. Boughoufalah and C. Havet
"Interactive Broadcast Digital Television, The OpenTV Platform versus
the MPEG-4 Standard Framework" Conferencia de 2000 para IEEE.
42.
http://www.computermodules.com/broadcast/dvb-asi-pci.shtml
43.
http://www.osmosys.tv/
44.
http://www.cesnavarra.net/cesdigital/Lists/Noticias%20CESDigital/Disp
FormCES.aspx?List=5ec0dfc7%2D7911%2D470b%2D8b6b%2D71ba7
2783fdd&ID=12
BIBLIOGRAFÍA
1.
2.
6.
J.Jones "DVB-MHP / Java TV Data Transport Mechanisms”
Conferencia Internacional del Pacífico, volumen 10, 2002.
7.
C. Peng and P. Vuorimaa "A Digital Television Navigator" Conferencia
Internacional IASTED, Noviembre 2000.
45.
http://www.aefol.com/8/entradasdetalle.asp?key=2242
8.
C. Peng "Digital television applications", trabajo Doctoral para la
Universidad
de
Helsinki
2002
Online:
http://lib.hut.fi/Diss/2002/isbn9512261723.
46.
http://www.impulsatdt.es/home/agentes/plan-de-transicion/legislacion/
47.
http://www.elcorteingles.es/tiendas_e/cda/investronica/scd/0,5631,PD16
774!INVESTRON,FF.html
9.
[21] C. Herrero, P. Cesar and P. Vuorimaa "Delivering MHP
applications into a real
48.
MHEG-5, international standard, ISO/IEC 13522-5
49.
MPEG-2, ivnternational standard, ISO/IEC 13818-(1 a 7).
10.
DVB-T network, Otadigi" TELESIKS, 2003 .
50.
DSMCC, international standard, ISO/IEC 13818-6.
11.
Tang "A comparison of Ada and C++" en la conferencia TRI-Ada
'92,1992.
51.
MHEG-6, international standard, ISO/IEC 13522-6
52.
MHP, international standard, ETSI TS 101 812 V1.2.1 (2002-06).
12.
A. R. Feuer and N. H. Gehani "Comparison of the Programming
Languages C and Pascal" Conferencia de 1982.
53.
EuroMHEG, MHEG-5 extensions, DTG 1999.
13.
J. Whitaker "Interactive Television Demystified" McGraw-Hill, 2001.
14.
B. M. Brosgol "A comparison of Ada and Java as a Foundation
TeachingLanguage" revista SIGAda Ada Letters Volumen XVII, 1998.
15.
M. Fagerqvist and A. Marcussen "Application and System Migration
fromOpenTV to DVB-MHP” Tesis doctoral, 2000.
16.
A. Hartman "Producing Interactive Television" Charles River Media,
2002.
17.
http://es.wikipedia.org/wiki/TDT
18.
http://es.wikipedia.org/wiki/DVB-T
19.
http://es.wikipedia.org/wiki/MHP
20.
http://en.wikipedia.org/wiki/WiMAX
21.
http://www.mhp-knowledgebase.org/publ/mhp-guide.pdf
22.
http://www.mhproject.org/
23.
http://www.wimaxforum.org/home/
24.
http://www.itu.int/osg/spu/tnt/Documents/DTT_AND_WIMAX_WIRE
LESS_INTEGRATED_TECHNOLOGIES_FOR_DIGITAL_DIVIDE_I
SSUE.pdf
25.
http://www.wimaxforum.org/technology/downloads/Applications_for_8
02.16-2004_and_802.16e_WiMAX_networks_final.pdf
26.
http://www.ieeexplore.ieee.org/iel5/4433229/4433230/04433361.pdf?tp
=&isnumber=4433230&arnumber=4433361
27.
http://interactivetvweb.org/tutorial/mhp/xletintro.shtml
28.
http://www.eleconomista.es/empresasfinanzas/noticias/344955/01/08/Gemalto-and-Nagravision-Achieve-AWorlds-First-By-Demonstrating-An-EndtoEnd-OMA-BCASTSmartcard-Profile-Interoperability-Solution.html
29.
http://mmc06.hhi.de/Downloads/G.%20Martinetz%20(Motorola)%20%20MobileTVStandards.pdf
30.
http://www.nabanet.com/agm07_presentations/P5_ACaruso.pdf
31.
http://www.tvwithoutborders.com/
32.
http://www2.scielo.org.ve/scielo.php?script=sci_arttext&pid=S131648212005000200007&lng=es&nrm=iso
33.
http://www.adtecinc.com/