Middleware Ginga

Ginga es el nombre del middleware abierto del Sistema Brasileño de TV Digital (SBTVD). El nombre fue escogido en reconocimiento a la cultura, arte y continua lucha por libertad e igualdad del pueblo brasileño.

Ginga es una capa de software intermedio (middleware), entre el hardware/Sistema Operativo y las aplicaciones, que ofrece una serie de facilidades para el desenvolvimiento de contenidos y aplicaciones para TV Digital, permitiendo la posibilidad de poder presentar los contenidos en distintos receptores independientemente de la plataforma de hardware del fabricante y el tipo de receptor (TV, celular, PDAs, etc.).

Las aplicaciones ejecutadas sobre Ginga son clasificadas en dos categorías, dependiendo de la forma en la que son escritas. Las Aplicaciones de Procedimiento son escritas usando el lenguaje Java y las Aplicaciones Declarativas son escritas usando el lenguaje NCL.

Una arquitectura de implementación de referencia del middleware Ginga puede ser divida en tres grandes módulos: Ginga-CC (Common Core), el ambiente de presentación Ginga-NCL (declarativo) y el ambiente de ejecución Ginga-J (de procedimiento); esta arquitectura se muestra en la figura 1.

Figura 1. Arquitectura de Ginga

1. Ginga - NCL

El Ginga-NCL fue desarrollado por la Pontificia Universidad Católica de Rio de Janeiro – PUC- Rio, provee una infraestructura de presentación para aplicaciones declarativas escritas en el lenguaje NCL (Nested Context Languaje). NCL es una aplicación XML (eXtensible Markup Language) con facilidades para los aspectos de interactividad, sincronismo, espacio-temporal entre objetos de mídia, adaptabilidad, soporte a múltiplos dispositivos y soporte a la producción de programas interactivos en vivo no-lineares. 

La especificación de este subsistema se base en las normas ABNT NBR 15606-2 y ABNT NBR 15606-5.
Los componentes de este subsistema son (figura 2):

Figura 2. Subsistema Ginga-NCL

A continuación se define los elementos principales de Ginga-NCL:

Formateador (Formatter):  Quien se encarga de recibir y controlar las aplicaciones multimedia escritas en NCL. Dichas aplicaciones son entregadas al Formateador por el Ginga-CC.

Analizador de XML (XML Parser), Convertidor (Converter): Realizan la traducción de la aplicación NCL en la estructura interna de datos de Ginga-NCL para controlar la aplicación. Estos componentes son solicitados por el Formateador.

Programador (Scheduler): es iniciado para organizar el orden de la presentación del documento NCL (antes que inicie los objetos de media, se evalúan las condiciones de los enlaces y la programación correspondiente a las relaciones de las acciones que guiaran el flujo de la presentación). El componente Programador es responsable para dar la orden al componente Administrador de la Reproducción (Player Manager) para iniciar la reproducción apropiada del tipo de contenido de media para exhibirlo en el momento indicado.

Base Privada (Private Base): El Motor de Presentación (Presentation Engine) lidia con un
conjunto de aplicaciones NCL que están dentro de una estructura conocida como Base Privada.

Administrador de la Base Privada (Private Base Manager): Este componente está a cargo
de recibir los comandos de edición de los documentos NCL y el darle mantenimiento a los documentos NCL presentados. Estos comandos de edición están divididos en tres subgrupos:

• 1er Grupo de Comandos, responsable por la activación y desactivación de una      base privada, o sea, la habilitación de una determinada aplicación NCL.
• 2do Grupo de Comandos, responsable de iniciar, pausar, resumir, detener, remover las aplicaciones NCL.
• 3er Grupo de Comandos, responsable de la actualización de aplicaciones en iempo real, permitiendo el agregar o remover elementos NCL y permite que se asignen valores a las propiedades de los objetos de media.

Administrador del Diseño (Layout Manager): El Motor de Presentación soporta múltiples dispositivos de presentaciones a través del componente Administrador del Diseño, el cual es responsable de mapear todas las regiones definidas en una aplicación NCL.

1.1. El Lenguaje NCL

NCL es una aplicación XML que permite un acceso por módulos. El acceso por módulos se ha usado en varias recomendaciones de lenguaje W3C. Un módulo es la colección de relaciones semánticas de elementos XML, atributos y valores de atributos que presentan una unidad de funcionalidad.

Los módulos son definidos en conjuntos coherentes. Un perfil del lenguaje es una combinación de módulos, para el estándar Brasileño de TVD, Ginga-NCL define dos perfiles de lenguaje: el Perfil EDTV (Enhanced Digital TV Profile) y el Perfil BDTV (Basic Digital TV Profile).

Aquí  se  describirán las principales definiciones hechas por Ginga-NCL. La estructura básica de un módulo NCL lo definen el elemento raíz, llamado <ncl>, y sus elementos hijo, el elemento <head> y el elemento <body>, siguiendo la terminología adoptada por otro estándar W3C.

El elemento <head> puede contener los siguientes elementos hijo: <importedDocumentBase>, <ruleBase>, <transitionBase>, <regionBase>, <descriptorBase>, <connectorBase>, <meta> y <metadata>.

El elemento <body> puede contener los elementos hijo <port>, <attribute>, <media>, <context>, <switch> y <link>. El elemento <body> es tratado como un nodo de contexto NCM. NCM, es el modelo conceptual de NCL, donde un nodo puede ser un contexto, un switch o un objeto multimedia. Los nodos de contexto pueden contener otros nodos NCM y enlaces (links).Un nodo switch contiene otros nodos NCM, los nodos NCM están representados por sus correspondiente elementos NCL.

El elemento <media> define un objeto multimedia específico, su tipo y su localización. Otros tipos de elementos <media> son las de tipo “application/x-ginga-settings”, que especifica un objeto cuyos atributos son variables globales definidas por el documento original o son variables de ambiente reservadas que pueden ser manipuladas por el procesamiento del documento NCL; y las de tipo “application/x-ginga-time”, que especifican un elemento <media> especial cuyo contenido es el Tiempo del Meridiano de Greenwich (GTM).

El elemento <context> es el responsable de la definición de nodos de contexto. Un nodo de contexto NCM es un tipo particular de un nodo compuesto NCM y este define como será contenido un grupo de nodos y un grupo de enlaces como ya se menciono. Al igual que el elemento <body>, un elemento <context> puede tener elementos hijo <port>, <attribute>, <media>, <context>, <switch>, y <link>.

El elemento <switch> permite la definición de nodos de documentos alternativos (representados por los elementos <media>, <context> y <switch>) para ser escogidos durante su tiempo de presentación. La reglas de prueba utilizadas en la selección del componente switch a ser presentadas se definen por el elemento <rule> o <compositeRule>, los que son agrupados por el elemento <ruleBase>, definido como un elemento hijo del elemento <head>.

Las interfaces NCL funcionalmente permiten la definición de nodos de interface a ser utilizado en relación con otras interfaces. El elemento <area> permite la definición de anclas de contenidos representando porciones espaciales, opciones temporales, u opciones temporales y espaciales de un objeto multimedia (<media>).

El elemento <port> especifica un nodo puerta compuesto (<context>, <body> o <switch>) con su respectivo mapeo a una interface de uno sus componentes hijo. El elemento <attribute> es usado para definir un nodo de atributo o un grupo de nodos de atributo como uno de los nodos de interface. El elemento <switchPort> permite la creación de interfaces de elementos <switch> que son mapeadas para un grupo de interfaces alternativas de nodos de switchs internos.

El elemento <descriptor> especifica la información temporal y espacial necesaria para presentar cada componente del documento. El elemento puede referirse a un elemento <region> en el caso que se quiera definir su la posición inicial de la presentación de un elemento <media> en algún dispositivo de salida. Los elementos <descriptor> deben ser definidos dentro del elemento <head> del documento, el elemento <regionBase> define un grupo de elementos <region>, cada uno de los cuales puede contener anidados otros elementos <region>, y así sucesivamente, las regiones definen las áreas de presentación que se utilizaran en el dispositivo y son referenciadas por los descriptores, como ya se mencionó.

Un elemento <causalConnector> representa una relación que puede ser usada para la creación de elementos <link> en el documento. En una relación causal, una condición debe ser satisfecha para activar una acción. Un elemento <link> enlaza (a través de los elementos <bind>) un nodo de interface con los roles del conector, defiendo una relación espacio-temporal entre los objetos NCL.

El elemento <descriptorSwitch> contiene un grupo de descriptores alternativos para ser asociados con un objeto NCL. Similar al elemento <switch>, un <descriptorSwitch> la selección se realiza durante la presentación del documento, utilizando las reglas de prueba definidas por el elemento <rule> o <compositeRule>.

Con el fin de permitir una entidad base para incorporar otra base ya definida, se puede utilizar el elemento <importBase>. Adicionalmente, un documento NCL puede ser importado a través del elemento <importNCL>. El elemento <importedDocumentBase> especifica un grupo de documento NCL importados, y debe también ser definido como un elemento hijo del elemento <head>.

Algunos atributos de elementos NCL importantes son definidos en otros módulos NCL. El modulo de entidad de reúso (EntityReuse) permite la reutilización de un documento NCL. Este módulo define al atributo refer, el que hace referencia a un elemento URI que puede ser reutilizado. Solo los elementos <media>, <context>, <body> y <switch> pueden ser reutilizados. El módulo de navegación por teclas (KeyNavigation) provee las extensiones necesarias para describir las operaciones de movimientos de foco utilizando un dispositivo de control como el control remoto. Básicamente, este módulo define atributos que pueden ser incorporados por elementos <descriptor>.

Algunas funcionalidades de SMIL son también incorporadas por NCL. El elemento <transition> y algunos atributos de transición son definidos en el modulo de Transiciones Básicas (BasicTransitions) y el módulo de Modificación de Transiciones (TransitionModifiers) del SMIL. El elemento <transitionBase> de NCL especifica un grupo de efectos de transición, definidos por el elemento <transition>, y debe ser definido como un elemento hijo del elemento <head>.

Finalmente, el módulo SMIL de Meta Información (MetaInformation) es también incorporado. Este módulo no contiene información que sea usada o mostrada durante la presentación. En cambio, este contiene información sobre contenidos que son usados o mostrados. El módulo de Meta Información posee dos elementos que permiten describir documentos NCL.

El elemento <meta> especifica un solo par de propiedades o valores. El elemento <metadata> contiene información que es también relacionado a la meta información del documento. Esto actúa como el elemento ruta de un árbol RDF: el elemento RDF y su subsistema de elementos.

2. Ginga-J

Ginga-J es el subsistema lógico del sistema Ginga que procesa el contenido de los objetos Xlet. Un componente clave del ambiente de aplicaciones de procedimiento es el motor de ejecución de contenidos de procedimiento, compuesta pos la máquina virtual de Java. La especificación de este subsistema se basa en la norma ABNT NBR 15606-4.

Por otro lado, ya que algunos requisitos importantes identificados en el contexto Brasileño no cumplían algunas de las funciones correspondientes a las definiciones de middleware internacionales establecidas. Con el fin de satisfacer los requerimientos específicos de Brasil y al mismo tiempo mantener la compatibilidad internacional con el API de GEM, Ginga se basa en tres grupos de APIs llamados: Verde, Amarillo y Azul (Figura 3). Las APIs Verde de Ginga son las APIs compatibles con GEM, Las APIs Amarillo fueron aplicaciones compuestas para cumplir los requisitos específicos de Brasil que pueden ser implementadas mediante el uso de un software de adaptación utilizando las APIs Verde. Las APIs Azul no son compatibles con las APIs de GEM. De esta manera, las aplicaciones que solo utilizan las APIs Verde pueden ser ejecutadas en los middlewares Ginga, MHP, OCAP, ACAP y ARIB SDT-23. Las aplicaciones que utilizan las APIs Verde y Amarillo solo pueden ser ejecutadas en MHP, ACAP, OCAP y ARIB SDT-23, si el software de adaptación es transmitido y ejecutado conjuntamente a la aplicación. Las aplicaciones que utilizan las APIs Azul solo se ejecutarán en ambientes del middleware Ginga.

El conjunto de APIs Verde, está compuesto por los paquetes Sun JavaTV, DAVIC, HAVi y DVB, todos incluidos en el marco de especificaciones GEM. El conjunto de APIs Amarillo está conformado por el API JMF 2.1, que es necesario para el desarrollo de aplicaciones avanzadas, con captura de sonido por ejemplo, una extensión de la API de Presentación de GEM, con funcionalidades para soportar las especificaciones de flujo de video definidas en el estándar Ginga-J, una extensión para la API del canal de retorno de GEM, que permite el envío de mensajes asíncronos; y una extensión de la API de Servicios de Información del ISDB ARIB SDT-23. El conjunto de APIs Azul está compuesto por un API de integración de dispositivos, que permite al receptor de TV digital la comunicación con cualquier dispositivo con una interfaz compatible (conexión por cable, como Ethernet o PLC, o redes inalámbricas como infrarrojo o Bluetooth), que puede ser utilizada como un dispositivo de entrada o de salida, una API multiusuario, que utiliza la API de integración de dispositivos para permitir que varios usuarios puedan interactuar simultáneamente con aplicaciones de TV digital; una API puente a NCL, que permite el desarrollo de aplicaciones Java que contengan aplicaciones NCL. 

 Figura 3. APIs de Ginga-J

3. Núcleo Común de Ginga (Comon-Core)

El núcleo común de Ginga concentra servicios necesarios tanto para Motor de Presentación (declarativo) como para el Motor de Ejecución (de procedimiento). Este subsistema es la interfaz directa con el sistema operativo, haciendo un puente estrecho con el hardware. Aquí es donde se accede al sintonizador de canales, sistema de archivos, terminal gráfico, entre otros.

Está compuesto por los decodificadores de contenido común y por procedimientos para obtener contenidos transportados en flujos de transporte MPEG-2 y a través del canal de interactividad. Los Decodificadores de contenido común sirven tanto a las aplicaciones de procedimiento como a las declarativas que necesiten decodificar y presentar tipos comunes de contenidos como PNG, JPEG, MPEG y otros formatos. El núcleo común de Ginga debe obligatoriamente también ser compatible con el modelo conceptual de exhibición, como se describe en la norma ABNT NBR 15606-1. 

 Figura 4. Componentes de Ginga - Common Core

En la Figura 4, se muestran los componentes básicos del Núcleo Común descritos a continuación:

• El Sintonizador: Es el modulo responsable de sintonizar un canal, seleccionando un canal físico y los flujos de transporte que están siendo enviados por este canal.
• Filtros de Selección: Una vez sintonizado el canal, el middleware debe ser capaz de acceder a partes específicas del flujo de transporte. Para esto, existe un Filtro de Selección, el mismo que es capaz de buscar en el flujo, la parte exacta que las APIs necesitan para su ejecución. Funcionando exactamente como un filtro, dejando pasar apenas la información requerida por la API.
• Procesador de Datos: Es el elemento responsable de acceder, procesar y transferir los datos recibidos por la capa física. También es responsable de notificar a los otros componentes, sobre cualquier evento que se ha recibido.
• Persistencia: Ginga es capaz de guardar archivos, incluso después que ha finalizado el proceso que los creó, para que este pueda ser abierto en otra ocasión.
• Administrador de Aplicaciones: Es el módulo responsable de cargar, configurar, inicializar y ejecutar cualquier aplicación en cualquier entorno ya sea declarativo o de procedimiento. También es responsable de controlar el ciclo de vida de las aplicaciones, eliminarlas cuando sea necesario, además de controlar los recursos utilizados por esas APIs.
• Adaptador Principal de A/V: Con el Adaptador Principal de A/V, las aplicaciones consiguen ver el flujo de audio y vídeo. Esto es necesario cuando una aplicación necesita controlar sus acciones, de acuerdo con lo que se está transmitiendo.
• Administrador de Gráficos: Las normas del middleware definen como se presentan al usuario las imágenes, videos, datos, etc., administrando las presentaciones de la misma manera que está definida en el estándar ARIB [ARIB B-24, 2004].
• Administrador de Actualizaciones: Es el componente que gestiona las actualizaciones del sistema controlando, descargando las actualizaciones del middleware siempre que sea necesario, para corregir los errores encontrados en versiones anteriores. Esto de ser hecho en tiempo de ejecución, sin perturbar el uso normal de la TV por parte del usuario.
• Reproductor de Archivos Multimedia: Son las herramientas necesarias para presentar los archivos multimedia recibidos, como por ejemplo archivos de tipo MPEG, JPEG, TXT, MP3, GIF, HTML, etc.
• Interface de Usuario: Este módulo es responsable de captar e interpretar los eventos generados por los usuarios, tales como, comandos del control remoto y notificar a los otros módulos interesados.
• Administrador de Contextos: Es el responsable de captar las preferencias del usuario, notificando a los otros componentes interesados esas preferencias. Esta información puede ser por ejemplo el horario en que el usuario mira la TV, o el bloquear y desbloquear canales, entre otros.
• Canal de Retorno: Proporciona la interfaz de las capas superiores con el canal de interacción (o canal de retorno). Además, debe gestionar el canal de retorno de modo que los datos sean transmitidos cuando el canal esté disponible o forzar la trasmisión en caso de que el usuario o una aplicación tengan definido un horario exacto.
• Acceso Condicional: Este componente está encargado de restringir contenidos inapropiados recibidos por los canales de programación, proporcionando así seguridad para el middleware.

4. El Puente entre Ginga-NCL y Ginga-J

El puente bidireccional entre Ginga-NCL y Ginga-J se hace:

• En un sentido, a través de relaciones NCL, definidas en los elementos <link> que hacen referencia a elementos <media> que representan a códigos Xlet (de tipo “application/x-ginga-NCLet”) soportados por Ginga-J, y a través de scripts Lua (elementos <media> de tipo “application/xginga-NCLua”) que hace referencia a métodos Ginga-J;
• En sentido contrario, a través de funciones Ginga-J que pueden monitorear cualquier evento NCL y también pueden ordenar cambios en los elementos NCL, a través de las relaciones definidas en los elementos <link> o a través de comandos de edición NCL, similar a lo que hace por los objetos NCLua.