El estándar MHP: interactividad en la televisión digital
El concepto de servicio interactivo es muy amplio y complejo, pero podría definirse como aquellos contenidos/aplicaciones diseñadas para que el usuario pueda establecer algún tipo de relación con ellas. De esta forma el usuario tiene la capacidad de influir en los programas a los que va a recibir o en los servicios a los que va a acceder, de modo que pueda personalizar dichos contenidos.
La interactividad por sí sola no elimina la recepción pasiva de los programas o contenidos, pero sí que nos aporta determinados momentos de implicación y/o participación activa. No nos olvidemos que todos estos desarrollos pueden formar parte del entretenimiento de los usuarios, pero a su vez, puede permitir dotar a un medio tan común y tan accesible como es la televisión de servicios al ciudadano que ayuden al desarrollo de la sociedad de la información.
Hasta ahora, cada uno de los operadores ha optado por un tipo de sistema operativo diferente. El hecho de que cada proveedor desarrolle su propia plataforma de forma independiente, genera múltiples desventajas adquiriendo el mercado una estructura vertical:
– Se hace imposible ejecutar las mismas aplicaciones en diferentes plataformas generando un aumento del coste de este tipo de servicios.
– Se hace obligatorio el uso del STB propietario en cada plataforma preparado para el sistema que ha implantado cada una.
– Falta de interoperabilidad entre las distintas plataformas.
Esta estructura, perjudica a todos los miembros que forman parte de la cadena, que se caracteriza por la falta de un lenguaje único. El siguiente paso a un estándar único en TD será el de la convergencia tecnológica, con lo que se impondría una plataforma interactiva única para el hogar.
Ventajas de un middleware estándar
La utilización de un middleware estándar, presenta ventajas para todos los actores implicados en el proceso:
Usuarios
– Tienen disponibles aplicaciones de todos los proveedores en un mismo receptor.
– Pueden adquirir el receptor que quieran, en lugar de conformarse con el impuesto por el operador.
Desarrolladores de servicios interactivos
– Sólo necesitan desarrollar una vez el servicio para vendérselo a varias plataformas. En cambio, con sistemas propietarios, los costes de desarrollo se multiplican.
Operadores
– Tienen la certeza de que los servicios que difundan estarán disponibles para todos los usuarios ya que independientemente del receptor que posea el usuario, la aplicación va a ejecutarse sin problema.
Con una estructura horizontal del mercado, conseguimos que desde todos los ámbitos, se produzca un fuerte impulso y se favorezca la penetración en el mercado de la Televisión Digital, que como ya hemos visto acabaría beneficiando a todos, ya que permitirá que un usuario pueda acceder a los contenidos y servicios interactivos de todos los operadores de TV, así mismo también podrá comprar el receptor digital en la tienda que quiera siempre que sea compatible con el estándar adoptado, pudiendo elegir cualquier marca o modelo.
En estas circunstancias, es ne-cesario un middleware estándar abierto e interoperable que nos garantice el funcionamiento conjunto. Este estándar es el MHP.
MHP (DVB-MHP) es el estándar abierto que se ha desarrollado a partir del foro europeo DVB (1996-2000) para la ejecución de aplicaciones interactivas. Las siglas significan Multi-media Home Platform cuyo origen viene de la idea de convergencia tecnológica del mundo de la televisión y de la informática, en el que se planteaba convertir el televisor en la plataforma multimedia del hogar. Defi-ne un interfaz genérico que incluye todas las aplicaciones de vídeo y TV Digital, que nos permita una elevada portabilidad e interoperabilidad entre decodificadores y plataformas.
El 15 de Febrero de 2002 se firmó el acuerdo de intenciones sobre la TDT con el objetivo de usar MHP como estándar para desarrollar servicios interactivos de la TDT en España. Todos los actores que forman parte en el desarrollo e implantación de TDT acuerdan apoyar MHP como interfaz abierto y estandarizado para el desarrollo de aplicaciones interactivas y multimedia en TDT. Además, para que estas aplicaciones puedan ser desarrolladas e implementadas por todos los receptores, éstos deben pasar previamente un test de conformidad, y una vez pasado podrán estampar el logo MHP para certificar la compatibilidad e interoperabilidad entre fabricantes.
Descripción Técnica
Las especificaciones MHP definen una arquitectura del receptor, los protocolos de transporte y señalización para los canales de difusión e interacción, así como aquellos tipos de aplicaciones que pueden ser distribuidas.
En definitiva una plataforma con MHP está compuesta y debe ser capaz de gestionar los siguientes elementos:
– Navegador: Aplicación que siempre esté presente y que el usuario pueda lanzar en cualquier mo-mento, donde pueda se-leccionar servicios, aplicaciones, etc.
– «Object Carrousel»: Si queremos enviar una aplicación asociada a un programa ésta tiene que viajar en el flujo MPEG-2. Pero no basta con enviarla una sola vez, sino que tiene que ser posible que cada receptor la obtenga en el momento de sintonizar el programa en cuestión. Esto se consigue creando un flujo de datos que se repiten una y otra vez, de ahí el nombre de carrusel.
– DSM-CC: Los datos enviados en carrusel, se organizan como un sistema de ficheros y se empaquetan usando un formato denominado «DSM-CC». No es más que el protocolo de envío de datos.
– Perfil: Descripción de varias configuraciones mí-nimas para ejecutar diferentes servicios MHP, cada uno de los perfiles se define a través de un conjunto de funciones que caracterizan el alcance de los servicios.
Los principios de funcionamiento del MHP se basan en la definición de unos perfiles que marcan la evolución y la arquitectura de la plataforma, y procesos orientados fundamentalmente a proveer de portabilidad e interoperabilidad de aplicaciones, con un ciclo de vida muy definido.
Durante la especificación de MHP se ha tenido muy en cuenta la posible evolución, por lo que se ha definido un conjunto de perfiles que indican una serie de características que vienen marcadas por diferentes áreas de actuación o «profiles» que van incorporando mayores y mejores prestaciones.
Un «profile» hace referencia a un área de aplicación, o como consecuencia a un conjunto de prestación. En este sentido se definen tres áreas de aplicación o «profiles»:
– Enhanced Broadcasting o Interactividad local – Combina la transmisión digital de los servicios de vídeo y audio del operador con las aplicaciones que pueden ser descargadas para ser ejecutadas en el descodificador ofreciendo interactividad local; es decir, estas aplicaciones no incorporan canal de retorno y la única interactividad que ofrece es aquella que se desarrolla en el propio descodificador del usuario. Algunas aplicaciones que contienen este nivel de interactividad son por ejemplo: los servicios de información meteorológica o de tráfico, las EPG´s, teletexto. Estas aplicaciones no aportan beneficios económicos al proveedor de contenidos, pero sí permiten la fidelización de los usuarios ya que añaden un valor al programa.
– Interactive Broadcasting o Interactividad Remota: En este caso los servicios pueden estar o no asociados a los servicios de vídeo y audio ofrecidos por el operador. En este caso sí disponen de canal de retorno, y nos permite realizar la comunicación entre cada uno de los decodificadores y la cabecera. En este grupo podríamos tener tipos de aplicaciones como apuestas, votaciones, etc. Una de las desventajas que presenta este tipo de interactividad es que el canal de retorno es compartido, por lo que si hay mucha demanda de envío de información al mismo tiempo es relativamente fácil que el sistema se colapse.
– Internet Access o In-teractividad real: Engloba los otros dos niveles y obliga que el receptor disponga de un navegador. El objetivo es proveer a los usuarios de servicios de Internet, y como nota destacada contiene un elemento HTML opcional denominado DVB-HTML. Algunas de las aplicaciones que contienen este nivel de interactividad serían: consulta de correo, navegación por web, telebanca, etc. El usuario puede interactuar con la aplicación, con un proveedor de servicios externos, con otros usuarios y con el propio emisor.
La tecnología MHP se ha ido desarrollando y mejorando a partir de la implantación en varios mercados. Fruto de este proceso de mejora existen diferentes versiones de MHP:
– MHP 1.0 – Se ejecutan las aplicaciones recibidas vía broadcast en cada canal de TV. Para establecer una comunicación bidireccional la mayoría de receptores incorporan módem.
– MHP 1.1 – Es la versión que los operadores de TV de pago escogen si deciden utilizar la tecnología MHP para sus servicios interactivos. Está mejor preparado para beneficiarse del uso intensivo del canal de retorno ya que se pueden descargar aplicaciones con el protocolo http, y en algunos modelos incorpora un navegador preparado para descargar contenidos HTML, optimizados para ser vistos en la TV. Para minimizar los tiempos de carga de las aplicaciones se permite almacenar aplicaciones en la caché del receptor. Se incorpora además, el soporte para gestionar «smart card» tales como DNI electrónico. Se ha definido también el soporte para crear las interfaces de usuario en alta definición.
– MHP 1.2 – Está inspirado en la tecnología del cable digital americano y especialmente pensado para satisfacer las necesidades de las TV de pago que quieran tener más control sobre la experiencia del usuario con el receptor. También se ha añadido soporte para recibir TV sobre IP con un alto grado de flexibilidad.
El trabajo con MHP, incluye la definición del Global Executable MHP (GEM) que permite reutilizar gran parte de la misma tecnología que no cumple con las normativas de TV digital del DVB. Esto ha permitido definir estándares muy similares para:
– OCAP – usada en la TV Interactiva en los operadores de cable de Estados Unidos.
– BD-Java (BD-J) – que se usa para la interactividad avanzada en el nuevo formato Blu-Ray. Ya hay diversas películas con este tipo de interactividad.
Arquitectura MHP
Cualquier equipo MHP tiene acceso a distintos flujos de información que además debe procesar para poder presentarlo de forma adecuada. Básicamente gestiona flujos de entrada y/o salida de datos, vídeo, audio, pero además procesará eventos de entrada del usuario y los presentará de forma adecuada en el medio (normalmente un televisor).
En un sistema básico para el procesado de esta información, podemos distinguir tres capas claramente diferenciadas:
– Capa de Recursos – Esta capa hace referencia a la capa de recursos del decodificador, procesador MPEG, o cualquier dispositivo de E/S.
– Capa de Software de Sistema – que se encargará de aislar las aplicaciones de los recursos del decodificador, de modo que éstas no accedan de manera directa a los recursos. En esta capa se implementa la JVM (Java Virtual Machine) que ofrecerá las diferentes bibliotecas que conformarán el API a usar en los desarrollos de las aplicaciones interactivas. Es en esta API donde el DVB-MHP centra máximos esfuerzos de especificación.
Pero a su vez, el MHP también se encarga de definir el comportamiento de las aplicaciones (ciclo de vida) permitiendo incluso al operador controlarlo desde la cabecera. Con este objetivo se define un elemento más denominado «Application Manager» que se incluye en esta capa.
– Capa de Aplicaciones – Es la parte superior de la arquitectura donde se sitúan las diversas aplicaciones (también conocidas como Xlets), que hacen uso de los servicios ofrecidos por las capas inferiores.
La estructura de capas descrita lo que aporta es una relación jerárquica entre el usuario que a través de la capa de aplicación controla la ejecución de una determinada aplicación interactiva y es ésta la que a través del uso de la API acaba utilizando los recursos disponibles del decodificador.
El DVB-MHP no sólo estandariza la API, sino que además, como se ha comentado antes, define el ciclo de vida de las aplicaciones, de modo que se puedan controlar los diferentes estados por los que puede pasar una aplicación durante su ejecución. Esto evita que la aplicación se comporte de forma no deseada.
Además esta arquitectura se complementa con la capacidad de admitir plug-ins. Es decir, se hace posible añadir nuevas funcionalidades a la plataforma de forma que sea capaz de interpretar aplicaciones y formatos no definidos en la especificación.
En este sentido hacemos compatible la plataforma con otras aplicaciones desarrolladas y definidas hasta ahora sobre otras plataformas haciendo que puedan funcionar en el entorno MHP. Así mismo, se está abriendo una puerta a la diferenciación entre plataformas permitiendo incluir funcionalidades que otros operadores no incluyen.
Modelos de aplicaciones
Para conseguir ofrecer un entorno de ejecución apartado de las aplicaciones que acompañan a los programas de televisión, se ha optado por convertir el terminal en una máquina virtual en lenguaje JAVA. Esto quiere decir que las aplicaciones no estarán desarrolladas en código nativo del procesador de la plataforma, sino que estarán compiladas en un código intermedio que, en el momento de la ejecución, se interpreta por una máquina virtual.
En el estándar están definidos dos modelos de aplicaciones claramente diferenciados.
– DVB-J (Xlets) – Que son aplicaciones basadas en JAVA (se compilan) y que se especifican en MHP 1.0.x y que pueden ser descargadas, lanzadas, interrumpidas y destruidas por el usuario desde el receptor. MHP en su especificación permite la coexistencia de múltiples aplicaciones en el receptor.
– DVB-HTML – Se trata de una especificación para preparar contenidos similares al HTML para la televisión digital. Es un lenguaje declarativo que se interpreta y que está basado en estándares de Internet. No son más que páginas en formato XHTML que se presentan en el receptor del usuario de forma muy similar a como lo realiza un navegador de internet. Se especifican en MHP 1.1.x. A priori esta opción es una solución más sencilla para desarrollar aplicaciones interactivas.
El agente desarrollador de aplicaciones sólo tiene que usar las API´s disponibles para implementar cualquier servicio interactivo. En el caso de aplicaciones DVB-J se trataría de interfaces Java (DAVIC, HAVI, JavaTV, org.dvb.si), mientras que para aplicaciones DVB-HTML utilizaríamos tecnología HTML, ECMAScript.
Las aplicaciones suelen ir asociadas a un servicio, por lo que será necesario que MHP suministre algún mecanismo que nos permita realizar dicha asociación, y sepa en todo momento que aplicaciones debe ejecutar en función del servicio en el que nos encontremos.
En este sentido MHP especifica un mecanismo de Señalización de Aplicaciones con varios objetivos, entre los que se encuentran identificar y localizar las aplicaciones asociadas a un servicio en concreto, control del ciclo de vida de dicha aplicación y la identificación de fuentes de datos requeridos por las aplicaciones de dicho servicio.
Como es conocido, todo flujo de transporte en TV Digital contiene unas tablas denominadas PSI (Program Specific Information) que permite a los decodificadores identificar y conocer los stream de vídeo y audio que tienen que decodificar para conformar un programa concreto.
Una de las tablas que contienen esta información y que es primordial es la PAT (Program Association Ta-ble), que identifica la tabla donde son descritos los componentes de un programa en concreto (vídeo, audio, datos) como es la PMT (Program Map Table). En este sentido MHP introduce un nuevo descriptor en esta tabla denominado «application_signalling_descriptor» que contiene el identificador (PID) que nos indica la referencia de una nueva tabla AIT (Application Information Table).
En este sentido, existe una AIT por cada servicio emitido en un Transport Stream en concreto. En esta tabla se define la lista de aplicaciones que están asociadas a dicho servicio, y también se definen unos códigos de control (application_control_code) cuyo valor indica la transición al estado indicado. Así mismo, y con el objetivo de identificar las fuentes de datos que las aplicaciones necesitan, también se incluye un nuevo descriptor «transport_protocol_descriptor» que identifica el protocolo de transporte utilizado. El descriptor «dvb_html_application_boundary» identifica los límites de una aplicación DVB-HTML,. Esta descripción no es necesaria en los casos de aplicaciones DVB-J ya que estos límites quedan definidos a través de la variable de entorno CLASSPATH.
Penetración de la TDT y servicios interactivos
A fecha de hoy, cuando la TDT es una realidad, la penetración de este tipo de equipos no es nada significativa. Las razones por las que todavía este tipo de receptores con MHP no es adquirido por los usuarios pueden ser las siguientes:
· Gran despliegue de «zappers», decodificadores mucho más baratos sin MHP. El menor coste de estos equipos viene dado por la no incorporación del módem, que es necesario para implementar el canal de retorno en las aplicaciones interactivas, y también por el gran stock que existe de este tipo de equipos. Así mis-mo, la ejecución de la má-quina virtual Java impone la necesidad de unas ca-racterísticas en el receptor como más memoria RAM, más capacidad de procesador, etc, que en-carecen el precio de los receptores.
· Desconocimiento de las posibilidades de interactividad. Todavía tanto el usuario como el comercializador de equipos desconocen las posibilidades de las TDT.
· Actualmente no existe una oferta atractiva de servicios interactivos. Al no existir gran distribución de equipos dotados de MHP, los potenciales usuarios/clientes de estas aplicaciones son pocos todavía y los proveedores no invierten en el desarrollo de este tipo de servicios.
Referencias:
– http://www.mhp.org – Pagina oficial MHP
– Cuadernos de Tecnología -Fundación Auna
– http://www.mhproject.org
