Televisión Digital Terrestre, Middleware Ginga

por | agosto 25, 2014

En el anterior artículo repasamos brevemente que constituye la Televisión Digital Terrestre y mencionamos ciertas características del estándar ISDB-T, estándar escogido en nuestro país.

Es el momento de adentrarnos al componente que nos permite desarrollar aplicaciones interactivas, ambientes de programación, lenguajes de programación NCL, Lua y Java.

En este artículo una introducción a Ginga y sus componentes.

2 MIDDLEWARE GINGA

Un middleware para aplicaciones de televisión digital consiste principalmente en un conjunto de librerías, métodos y funciones que permiten desarrollar aplicaciones de manera fácil y rápida.

Ginga es el middleware de desarrollo de aplicaciones interactivas del estándar SBTVD. Su nombre se basa en un término usado en un fundamental movimiento de capoeira. Ginga es una especificación abierta liberada bajo licencia GPLv2 libre de regalías, brindado la posibilidad a cualquier persona de crear contenido interactivo.

En definitiva, este componente es el responsable de ejecutar las aplicaciones interactivas que son enviadas en el flujo de difusión de la empresa de televisión.

2.1 AMBIENTES DE PROGRAMACIÓN

Las aplicaciones de televisión digital se pueden encontrar en aplicaciones declarativas o aplicaciones imperativas, dependiendo del lenguaje de programación en que estén codificadas, también se pueden construir aplicaciones híbridas, con parte de su código declarativo y parte de su código imperativo.

  • Ambientes declarativos: En un ambiente declarativo los lenguajes de programación se especializan en describir el problema y detallar su solución a alguna tarea, sin especificar exactamente como hacerlo, por esta razón son mucho más fáciles de ser concebidos y entendidos, lo que exime la presencia de un programador especialista. Ginga da soporte para aplicaciones en el ámbito declarativo mediante el lenguaje NCL que puede hacer uso de contenido en script mediante el lenguaje Lua. Dentro del estándar este subsistema lógico toma el nombre de Ginga-NCL.
  • Ambientes imperativos: En un ambiente imperativo los lenguajes de programación describen un conjunto de instrucciones que se ejecutan paso a paso, es decir mediante el desarrollo de un algoritmo que cambia el estado del programa para permitir encontrar su solución, esto al contrario de los ambientes declarativos exige la presencia de un programador especialista. Para aplicaciones en el ámbito imperativo el soporte viene dado mediante el lenguaje Java y toma el nombre de Ginga-J.
  • Ambientes híbridos: En el ambiente híbrido las aplicaciones puedan ser escritas en NCL, Lua y Java, ya que, en ciertos casos para la Televisión Digital se necesitarán que se desarrolle aplicaciones interactivas con los paradigmas declarativos e imperativos, mediante las APIs contenidas en el middleware se logra juntar ambos entornos, para lograrlo existe el subsistema lógico        Ginga-CC. La arquitectura de referencia de Ginga se puede apreciar en la siguiente figura.
Arquitectura Ginga

Arquitectura Ginga

2.1.1 Ginga-NCL

Ginga-NCL es el ambiente de middleware Ginga responsable del procesamiento de las aplicaciones declarativas que utilizan el lenguaje NCL. Esta especificación está basada en el estándar XML, puede usar el lenguaje script Lua para aprovechar las propiedades del paradigma imperativo y ampliar las capacidades de la aplicación.

NCL define la forma en que los objetos de media están organizados en tiempo y espacio, lo que aporta un mayor control sobre el contenido. Los documentos pueden importar los elementos declarados en otros documentos. NCL también es una mejor opción en el desarrollo de aplicaciones no lineales ya que es un lenguaje para la integración de los objetos de media, es decir, facilita la sincronización en tiempo y espacio, haciendo prescindibles muchas de las veces del uso de estrategias de programación o la implementación de algoritmos.

Ginga-NCL separa el contenido de la estructura de presentación, en definitiva los lenguajes declarativos permiten al desarrollador proporcionar en conjunto las tareas a realizar sin definir una gran cantidad de código para hacer las mismas tareas, en comparación con las implementaciones algorítmicas, a fin de cuentas, los lenguajes declarativos centran su uso en la adaptabilidad, edición y producción de contenido y el soporte a múltiples dispositivos.

Cuando se necesita ampliar las capacidades de la aplicación con el uso de lenguajes de script, Lua puede simplificar las tareas de manipulación de variables de forma rápida y ligera, lo que sería realmente difícil si únicamente se hiciera uso del lenguaje NCL.
En la siguiente figura se detalla los componentes más importantes del subsistema Ginga-NCL que son:

Subsistema Ginga-NCL

Subsistema Ginga-NCL

  • Formatter (Formateador): Recibe de Ginga-CC el documento NCL y se encarga de controlar su presentación, intentando garantizar que las relaciones entre los objetos de media especificados por el autor sean correctos.
  • XML Parser (Analizador XML), Converter (Convertidor): se encarga de realizar la traducción de la aplicación NCL en la estructura interna de datos que Ginga-NCL maneja.
  • Scheduler (Programador): se encarga de ordenar los documentos NCL que tienen que ser cargados basados en la programación que indique que objetos de media se iniciarán dependiendo del flujo de la aplicación.
  • Player Manager (Administrador de reproducción): recibe del programador la orden en el momento indicado para la exhibición del tipo de contenido de la media solicitada.
  • Private Base Manager (Administrador de Base Privada): se encarga de recibir los comandos de edición de los documentos NCL y de darle mantenimiento a los documentos NCL presentados.
  • Layout Manager (Administrador de Diseño): es el responsable de mapear todas las regiones definidas en un documento NCL.

2.1.2 Ginga-J

Los lenguajes imperativos se caracterizan por ofrecer mayor control del código a los desarrolladores, además de ser menos abstractos en comparación con los lenguajes declarativos. De este modo la aplicación puede ser capaz de manejar todo el control y ejecución del flujo de la aplicación. Sin embargo, el coste de diseño se incrementa en gran medida debido a la complejidad de su código fuente y no son la mejor opción al momento de desarrollar aplicaciones no lineales.

Ginga-J es el responsable del procesamiento de aplicaciones procedurales escritas en lenguaje Java, que a su vez son llamadas Xlets. Estas aplicaciones tiene una interfaz que permite que un agente externo las inicie, pare y controle su ejecución de varias formas.  Además se dividen en tres componentes: Máquina Virtual Java, el núcleo, y sus APIs.

La implementación que Sun propone a través de su lenguaje de programación Java para las aplicaciones de Televisión Digital se llama Java-DTV, que posee las siguientes funcionalidades.

  • Streaming de audio y video;
  • Acceso a los datos en los canales de transmisión;
  • Acceso a los datos en el servicio de información;
  • Control de sintonizador de canales;
  • Sincronización de objetos de media; y
  • Administración del ciclo de vida de la aplicación.

El API se divide en tres categorías, como se aprecia en la siguiente figura:

Subsistema Ginga-J

Subsistema Ginga-J

  • API Verde: mantiene compatibilidad con el estándar americano y europeo. Esta API está compuesto por los paquetes Sun JavaTV, DAVIC[1], HAVi y DVB.
  • API Amarilla: proporciona soporte a múltiples usuarios, dispositivos y redes. Esta API está compuesto por el API JMF 2.1, el cual es necesario para desarrollar aplicaciones avanzadas, con captura de sonido al instante, con extensión para API de Presentación GEM, con funcionalidades de soporte para las especificaciones de video stream, el canal de retorno, que permite el envío asincrónico de mensajes, y extensión para los Servicios de Información.
  • API Roja: proporciona soporte a aplicaciones que pueden ser recibidas, almacenadas y ejecutadas.

2.1.3 Ginga-CC

Ginga Common Core, es el subsistema lógico que provee toda funcionalidad común al soporte de los ambientes de programación declarativos, GINGA-NCL, e imperativo, GINGA-J. La arquitectura del sistema permite que únicamente el módulo Ginga-CC deba ser adaptado a la plataforma donde será implementado.

Ginga-CC provee un nivel de abstracción de la plataforma de hardware y del sistema operativo, accesible a través de las APIs. Esto le permite interactuar con el acceso al sintonizador de canal, con el sistema de archivos, el terminal gráfico entre otros.

En la siguiente figura se puede ver los diferentes componentes que conforman el Gina-CC

Subsistema Ginga-CC

Subsistema Ginga-CC

  • Sintonizador: Este módulo es el responsable de “sintonizar” un canal, seleccionando un canal físico dentro de los flujos de transporte que están siendo enviados por ese canal.
  • Filtro de secciones: Una vez sintonizado, el middleware debe ser capaz de acceder a partes específicas del flujo de transporte. Para lograr este objetivo, existe el Filtro de Secciones, que es capaz de buscar en un flujo la parte exacta que las APIs necesitan para su ejecución, de ésta manera solo permite el paso de la información requerida por la API.
  • Procesador de datos: Es el elemento responsable de acceder, procesar y reenviar los datos recibidos por la capa física. También es el encargado de notificar a los otros componentes, sobre cualquier evento que se reciba.
  • Persistencia: El middleware tiene la capacidad de almacenar y guardar archivos una vez finalizado el proceso para que luego pueda ser abierto o utilizado posteriormente.
  • Iniciador de aplicaciones: El módulo responsable de gestionar las aplicaciones, cargar, configurar e inicializar y ejecutar cualquier aplicación tanto declarativa como imperativa. Controla el ciclo de vida de las aplicaciones, terminándolas cuando sea necesario además de controlar los recursos utilizados por las APIs.
  • Adaptador de audio video principal: Con el adaptador de audio y video, las aplicaciones consiguen entregar un flujo de audio y video. Esto se hace necesario cuando una aplicación necesita controlar sus acciones, de acuerdo a como están siendo transmitida.
  • Gestor de gráficos: Los estándares del middleware definen como deben ser mostrados al usuario las imágenes, los videos, los datos, etc. Gestionando las presentaciones.
  • Gestor de actualizaciones: Componente que se encarga de gestionar las actualizaciones del sistema, verificando, y bajando las actualizaciones del middleware cuando sea necesario, para corregir los posibles errores de las versiones, ésta tarea debe realizarse en tiempo de ejecución sin incomodar el uso normal de la TV por el usuario.
  • Visualizador de medios: Proporciona las herramientas necesarias para visualizar los archivos multimedia recibidos, como por ejemplo archivos tipo JPEG, MPEG, MP3, HTML, etc.

Referencias:

[1] Digital Audio Visual Council. Fue una asociación que acogía a diversas empresas de la industria audiovisual, el estándar ISO-IEC 16500 es una de las normas más importantes en el campo de las aplicaciones interactivas y sus servicios.


Siguiente Artículo: Televisión Digital Terrestre, Utilizando la Interactividad

EOF