APLICACIONES INTERACTIVAS PARA TELEVISION DIGITAL

UNIVERSIDAD MAYOR DE SAN SIMÓN FACULTAD DE CIENCIAS Y TECNOLOGÍA

DEPARTAMENTO INFORMÁTICA – SISTEMAS CENTRO M.E.M.I.

APLICACIONES INTERACTIVAS PARA TELEVISION DIGITAL

Jorge Walter Orellana Araoz

2016 – 2021

INDICE

Tema I - Televisión Digital

1.1. De la TV analógica a la TV digital 1 1.2. Sistema de TV digital: Visión general 9 1.2.1. Codificación de audio 11 1.2.2. Codificación de vídeo 12 1.2.3. Sistema de Transporte 14 1.2.3.1. Multiplexación de datos 14 1.2.3.2. Flujo elemental de datos 16 1.2.3.3. Flujo de transporte 17 1.2.4. Modulación 18 1.2.5. Canal de retorno o canal de interactividad 20 Tema II Arquitecturas Modernas de la Televisión Digital (Hardware) 2.1. Estándares de Transmisión de Televisión Digital 22 2.1.1. ATSC Advance Television System Committee 23 2.1.2. DVB-T Digital Video Broadcasting Terrestrial 25 2.1.3. ISDB-T Integrated Service Digital Broadcasting 27 2.1.4. SBTVD-T Sistema Brasileño de Televisión Digital Terrestre 28 2.1.5. DTMB Digital Terrestrial Multimedia Broadcasting 28

Tema III Middlewares para Interactividad con Televisión Digital 3.1. Middleware 29 3.1.1. Multimedia Home Platform. 30 3.1.2. ARIB -Association of Radio Industries Businesses (ARIB) 31 3.1.3. DASE- DTV Applications Software Environment 32 3.1.4. ACAP- Advanced Common Application Platform 33 3.1.5. GEM Globally Executable MHP 34 3.1.6. Middleware Ginga 34 3.2. Arquitectura del middleware ginga 35 3.2.1. Núcleo Común de Ginga (Ginga Common - Core) 37

Tema IV Herramientas de Programación y Emulación 4.1. Ambientes de Programación 39 4.2. Ambientes de emulación para la programación de Ginga 39 4.2.1. Herramientas GINGA NCL. 39 4.2.1.1. Herramientas de desarrollo (Autoria). 40 4.2.1.2. Herramientas de presentación 45 4.2.2. Herramientas GINGA Java. 47 4.2.2.1. Emulador Ginga-J: XleTView. 47 4.2.2.2. Emulador Ginga-J: OPENGINGA. 47 Tema V Desarrollo de Aplicaciones Declarativas (Ginga-NCL) 5.1. Modelo de contexto anidado (NCM) 48 5.2. Estructura de un documento Hipermedia. 49 5.2.1. ¿Qué vamos a mostrar? - Objetos Hipermedia (Media) 49 5.2.2. ¿Dónde los vamos a mostrar? - Regiones 50 5.2.3. ¿Cómo los vamos a mostrar? - Descriptores. 50

5.2.4. ¿Cuándo los vamos a mostrar? - Links y Conectores 51 5.3. Lenguaje de marcado extensible (XML). 51 5.3.1. NCL (Nested Contrext Language) 52 5.3.2. Lua. 54 5.3.2.1. Extensiones de NCLua 54 5.4. Estructura de un documento NCL. 55 5.4.1. Regiones 57 5.4.2. Descriptores 58 5.4.3. Nodo Multimedia (o Nodo de Contenido) 62 5.4.4. Contextos 64 5.4.5. Puertas 64 5.4.6. Base de Conectores 65 5.4.7. Conectores 65 5.4.8. Enlaces 68 5.4.9. Anclas 69 5.4.10. Reglas 70 5.4.11. Switch 71 Tema VI Desarrollo de Aplicaciones Procedurales (Ginga-J) 6.1. Ginga-J. 72 6.2. Arquitectura de Ginga-J. 73 6.3. El API de Ginga-J 73 6.3.1. API JavaTV. 74 6.3.1.1. Librerías del API JavaTV 75 6.3.2. API DAVIC (Digital Audio Visual Council) 75 6.3.3. API HAVi (Home Audio Video Interoperability). 75 6.3.4. API DVB. 75 6.3.5. API JavaDTV 76 6.3.5.1. Descripción de la arquitectura 76 6.4. Modelo Gráfico JavaDTV 77 6.4.1. Ciclo de vida Xlet 78 6.4.2. Vision General de los componentes 79 6.5. Lista de paquetes mínimos de Ginga-J. 86 Tema VII Lenguaje procedural LUA 7.1. Eventos LUA (API – NCLua) 90 7.2. Clases de eventos 90 7.3. Módulo event 91 7.3.1. Eventos ncl 91 7.3.2. Eventos key (Selection) 93 7.3.3. Eventos user 93 7.3.4. Eventos tcp 93 7.4. Módulo canvas 95 7.5. Módulo Settings 97 Bibliografia 98

Aplicaciones Interactivas para Televisión Digital

Ing. Jorge Orellana A.

1

Tema I

Televisión Digital 1.1. De la TV analógica a la TV digital

Al igual que en las películas, las primeras emisiones de televisión se hicieron en blanco y negro. En la norma americana (serie M), también adoptado en Bolivia, la relación de aspecto de la imagen (ancho/alto) es de 4:3, que utilizan 525 líneas por cuadro y se transmiten 30 cuadros por segundo. Cada cuadro se compone de dos líneas intercaladas campos consecutivos, es decir, hay 60 campos por segundo. La TV B&N sólo fue posible gracias a la curva de luminosidad relativa del ojo humano, que se muestra en la siguiente figura. La cámara de TV B&N ve la imagen como esta curva y crea una señal eléctrica conocida como la señal de luminancia (Y) con el rango de frecuencia de 4,2 MHz en el tubo de rayos catódicos TRC B&N, la Y reproduce las sensaciones de "oscuro" y "claro". En la norma M, el canal de RF que se utiliza para transmitir la señal Y, tiene un ancho de banda de 6 MHz.



2

La televisión en color sólo fue posible debido a que el ojo humano tiene sensores (conos) donde predominan tres colores primarios: rojo (R). verde (G) y azul (B). Los otros colores son un resultado de las excitaciones proporcionales de los tres colores primarios. Por lo tanto, tenemos: (R + G) = (amarillo), (G + B) = (cian), (R + B) = (magenta) y (R + G+ B) = (blanco). La cámara crea tres señales de color tricromática: R, G y B, cada uno con un rango de frecuencia de 4,2 MHz y el TRC en color tiene tres cañones que se excitan por las respectivas señales R, G y B.

Un gran número de equipos que se utilizan actualmente para la creación de programas televisivos son digitales, a pesar de que en nuestros hogares todavía recibimos señales analógicas de televisión, pero su calidad y disponibilidad no serian posibles sin una producción y distribución digital. Una emisora de TV, en un instante de tiempo, envía por el canal de frecuencia:

• en la TV analógica una única señal (un único programa).

• en la TV digital más de una señal (más de un programa).

La TV Digital se resume a la conversión de la señal de TV analógica a un formato binario, que puede ser emitido de diferentes maneras; por satélite, terrestre o cable, para posteriormente ser decodificado por el propio televisor a través de un set-top-box.

El set-top-box es un hardware o dispositivo externo, que permite, que un televisor convencional, (TV analógica), como los que tenemos en los hogares pueda reproducir las señales televisivas producidas con tecnología digital, a los cuales se les dota de un middleware, para que puedan soportar características de interactividad con los usuarios y por ende adicionen muchas funcionalidades a estos.



3

La televisión digital interactiva, funciona a partir de la difusión de la televisión directa, junto con datos y servicios interactivos, consiente de llegar a conseguir una mejor calidad HDTV en la recepción y visualización de las señales en dispositivos fijos, móviles y portátiles, además se logra una mayor eficiencia en el aprovechamiento del espectro radioeléctrico, lo que conduce a la posibilidad de ofrecer más canales al usuario; un punto en contra de este tipo de televisión es que al digitalizar la señal de televisión se produce una cantidad de bits enorme, que sin la utilización de la compresión, harían muy difícil su transporte y almacenamiento.

La televisión de alta definición es sólo una de las opciones entre los muchos avances tecnológicos que proporciona la plataforma de transmisión digital, el sistema de televisión digital permite la transmisión de programas en resoluciones superiores, aumentando considerablemente la calidad de la imagen de la televisión. Actualmente los espectros de televisión son de formato 4:3, en HDTV el formato es 16:9, esto representa una imagen 33 % mas larga que la anterior. La idea es simular el ambiente de cinema, mejorando el uso da visión periférica, lo que permite una mayor experiencia sensorial. Como se puede observar en la siguiente figura, se puede observar mucha mas información en el formato 16:9.

El comité de normas de televisión avanzada (ATSC) ha establecido las normas voluntarias para la televisión digital, incluida la manera en que sonido y vídeo son codificados y transmitidos, así como proporcionar las directrices para los diferentes niveles de calidad. De esta manera, se crearon 18 formatos para la transmisión de vídeo digital, destacando las siguientes diferencias entre formato de pantalla, resolución y tasa de exhibición de cuadros.

Las 18 normas para la televisión digital puede ser organizado como se muestra en el



4

siguiente cuadro, en donde la gran diferencia es la tasa de exhibición de cuadros. Es fácil ver que se establecieron seis tipos HDTV y doce SDTV, en la resolución SDTV sube a 480, mientras que la HDTV va hasta 1080.

Sin embargo, a pesar que la señal digital es de una calidad superior a la señal analógica, no necesariamente es alta definición. Para ver una imagen de televisión de alta definición y escuchar el sonido Dolby Surround, existe la necesidad de que la estación transmita una señal de alta definición y el espectador cuente con una televisión de alta definición. Aunque los televisores analógicos son capaces de sintonizar canales del sistema digital utilizando los receptores convertidores Sept-top-box, al convertir la señal digital se pierde la calidad de visualización de la misma.

Por otra parte, en un sistema de transmisión no guiado (caso de TV terrestre analógica o digital), el canal de transmisión introduce varias interferencias y ruidos en la señal original, limitando la capacidad del sistema.

El ruido aleatorio está presente en todo el espectro de frecuencia y no se puede evitar. En la transmisión analógica, causa una disminución en la calidad de la señal recibida, provocando la aparición de "llovizna" en la imagen. La caída de la calidad depende de la relación entre los potencias de la señal y el ruido (S/N). A medida que la relación disminuye (y esto puede suceder por la atenuación de la señal cuando nos alejamos de la fuente) que también reduce la calidad de la señal recibida. En los sistemas digitales, el



5

ruido puede modificar un nivel digital de la señal transmitida al punto donde podría llegar a confundirse con otro nivel. Una baja relación S/N puede así aumentar la probabilidad de error de bit. Para evitar el problema, todas las normas para la transmisión de los sistemas de televisión digital terrestre utilizan códigos de corrección de errores. Si la tasa de error está por debajo de un umbral, el código corredor es capaz de corregir todos los errores introducidos por el canal y no habrá caída de la calidad de imagen. Sin embargo, si la tasa de error es superior al umbral, el sistema no será capaz de corregir el código transmitido e incluso puede introducir errores en lugar de corregirlos. Por lo que es habitual decir que, en la televisión digital, tenemos una señal perfecta, sin "ruido" no deseado o no hay señal.

A medida que la relación S/N disminuye con la distancia desde el transmisor, si el sistema no está dimensionado adecuadamente, pueden tener problemas de cobertura, con la introducción de las llamadas "zonas de sombra".

El deterioro de una señal recibida también se puede administrar por trayectos múltiples seguido de su origen, como es habitual en los sistemas de transmisión de radio. Cada uno de los caminos pueden tener diferentes atenuación y retardo de la otra, de modo que la señal recibida está formada por la superposición de las diferentes señales de los diferentes caminos. El efecto de una televisión analógica es la aparición de "fantasmas".

En la TV digital, múltiples rutas de señal pueden producir una interferencia entre símbolos (ISI - Inter-Symbol Interference), es decir, la superposición entre los bits transmitidos, como se muestra en la señal recibida en la casa receptora de la figura. Si el intervalo de tiempo de un símbolo (un símbolo es un patrón de bits) de transmisión es demasiado pequeño, y el intervalo de guarda entre los símbolos, el punto de la diferencia de retardo entre múltiples rutas de señal causa de la superposición de diferentes símbolos, la tasa de errores de recepción puede aumentar. Si no se tomaron medidas contra el ISI, puede descarrilar la recepción. Como siempre, la televisión digital, es todo o nada.

El ruido impulsivo es otra fuente de la degeneración de una señal, por ejemplo, motores eléctricos de interferencia (aparatos eléctricos, motores industriales, ascensores, etc.), vehículos de motor, transformadores de distribución de energía, rayos, etc. Como el ruido aleatorio, el ruido impulsivo provoca en la transmisión analógica, la caída de la calidad de la señal (apariencia de "llovizna" en la imagen). En el caso de sistemas de televisión digital si el ruido permanece el tiempo suficiente para causar una ráfaga de errores en símbolos consecutivos de la señal, el sistema de corrección de error no puede ser capaz de corregir el código transmitido, lo que lleva a la caída de recepción. Los sistemas de televisión digital deben ser lo suficientemente robustos como para evitar el problema.



6

De todos modos, tan mala como la señal analógica llega a la televisión, el espectador puede recibirla. En el caso de la señal digital, llega perfecta o no será recibida. Por lo tanto, es importante evaluar que la red de transporte es la más robusta, adecuada para asegurar la llegada de la señal digital en los hogares. Tener en cuenta también que algunas de estas interferencias siempre presentes en la televisión digital terrestre puede no ser significativas en medios de transmisión guiados, por ejemplo, los medios utilizados en el cable. Mejor calidad de imagen y sonido se sienten también mediante la aplicación de técnicas de compresión de datos en señales digitales, lo que permite la producción de señales de mayor resolución en la fuente, es decir, mejores señales.

La TV analógica tiene una calidad de imagen similar a la de TV digital estándar (SDTV), es decir, 30 cuadros por segundo, con cada cuadro que se compone de 480 líneas activas entrelazadas, en un televisor con relación de aspecto igual a 4 × 3. Los criterios para el diseño de estos parámetros de la imagen siempre se encuentran con el de la agudeza visual (lo que el ojo humano puede discernir) dentro de las limitaciones tecnológicas. Como se muestra en la siguiente figura, la calidad SDTV fue diseñada con un tamaño de píxel de tal manera que la agudeza visual de un minuto de grado fuese respetada, a una distancia de siete veces la altura de la pantalla. A esta distancia, el ángulo de visión horizontal es de 10 grados (lo suficientemente para que el ser humano capture información).

En la calidad SDTV recomendada por BT 601-4 [ITU-R BT.601-4, 1994], se generan aproximadamente 162 Mbps (29,97 cuadros/seg × 480 líneas/cuadro × 704 píxeles/línea × (8 bits de luminancia + 8 bits de crominancia)). Esta tasa de bits debe ser capaz de ser transmitida en un canal de televisión de 6 MHz, que soporta una velocidad del orden de 19,3 Mbps. Las técnicas de compresión actuales permiten esta relación de compresión (162: 19,3) y más. Por lo que tenemos, con la tecnología digital, la capacidad de tener una mejor calidad de imagen que la obtenida en SDTV.

De hecho, la televisión digital terrestre ofrece en el mismo canal de 6 MHz, una transmisión de calidad, llamada de alta definición (HDTV) con los siguientes parámetros: 30 cuadros por segundo, 1.920 píxeles por línea, 1080 líneas, con la agudeza visual de un minuto de grado obtenido a una distancia de aproximadamente tres veces la altura de la pantalla, que pasa a tener una relación de aspecto de 16 x 9. A esta distancia, y esta relación de aspecto, el ángulo de visión horizontal es de 30 grados, lo que permite al espectador una mayor sensación de presencia en la escena (inmersión).



7

Gracias a las técnicas de compresión de datos, la mejora en un sistema de TV digital también se siente en la calidad de audio. Dentro de la misma gama de 6 MHz de un sistema terrestre también se puede transmitir audio en el estándar 5,1 (multi-canal), dando al espectador, bajo el aspecto de la sensibilidad, mayor sensación de inmersión en la escena auditiva. Las técnicas de compresión digital también permiten la opción de tener varios programas de menor calidad de definición en la televisión digital terrestre; por ejemplo, tener múltiples programas de calidad SDTV, en lugar de tener un único programa (audio principal y el vídeo principal) de mayor calidad (HDTV) que ocupa toda la banda de 6 MHz. Esta nueva posibilidad resultante de la utilización de la tecnología digital es lo que llamamos la multiprogramación.

Todos los programas en el mismo canal de 6 MHz pueden estar relacionados con el mismo contenido o no. Un ejemplo sería la relación de transmisión de un partido de fútbol en el que una cámara puede ser colocado detrás de uno de los arcos, también capturar el sonido que proviene de la hinchada del lugar, otra cámara podría ser colocada en el otro arco, otro en el centro del estadio, etc. El espectador se le daría la opción de elegir qué vista de la cámara en un momento dado o incluso ver todo al mismo tiempo. Cuando el contenido de multiprogramación se relaciona, a menudo el proceso se llama multi cámara.

En multiprogramación, sin embargo, los diferentes programas pueden ser completamente independientes, lo que nos lleva a revisar el concepto de canal. En la televisión analógica, el canal de 6 MHz (es decir, canal de frecuencia) es confundido con el canal del programa (por lo general asociados con una emisora). Ahora es necesario que haya más. En el mismo canal de frecuencia podemos tener varios programas diferentes. Un canal de televisión digital tiene un ancho de banda de 6 MHz (igual a la analógica), por ejemplo, el canal 14 se inicia con una frecuencia de 470MHz y va hasta 476MHz. El canal está dividido en 14 segmentos de 428,57KHz pero un segmento no se usa para la transmisión, siendo solamente 13. Por lo tanto, el ancho de banda de transmisión de un canal de DTV es 13x428,57 = 5, 57MHz, pero para mayor seguridad se expande a 5,7MHz.

El segmento 01, que está justo en el centro, ya que es más fácil su recepción, está destinado a receptores portátiles y móviles. Ya que se emitirá un sólo segmento se conoce como One Seg o 1 seg.



8

La ventaja del sistema es poder aprovechar las capas jerárquicas, por ejemplo, si una capa está transmitiendo un programa SD y la segunda capa, el mismo programa en HD, la segunda aprovecha también la información que tiene la primera capa para formar HD. Un receptor móvil que sólo pueden recibir SD, toma la primera capa y descarta la segunda. Cada capa puede transmitir un programa diferente, y, finalmente, se convierte en un canal lógico. Además de la transmisión en One Segment, en Full Segment se puede tener hasta 6 programas en definición estándar (SD), pero en Full HD (1920x1080), que utiliza los 12 segmentos, sólo se puede transmitir dos programas.

El impacto de la televisión digital es mucho más significativo, que el simple cambio de un sistema de transmisión analógica a la digital, y más de una mejora en la calidad de imagen y sonido. Más que eso, un sistema de televisión digital permite un nivel de flexibilidad inalcanzable con la radiodifusión analógica. Un componente importante de esta flexibilidad es la capacidad de expandir las funciones del sistema para las aplicaciones construidas sobre la base de un sistema de referencia estándar. Este tipo de aplicaciones son programas de computadora que residen en un dispositivo de recepción o de los datos enviados juntos (multiplexado) con el audio principal y el video de un programa televisivo. Por lo tanto, una de las características más importantes de la televisión digital es la integración de una importante capacidad computacional en el dispositivo receptor, lo que permite la aparición de una amplia gama de nuevos servicios tales como el suministro de guías electrónicas de programas, control de acceso y protección de contenido, distribución de juegos electrónicos, el acceso a los servicios bancarios (T-banca), los servicios de salud (T-salud), servicios educativos (T-aprendizaje), servicios de gobierno (T-gobierno) y, en particular, programas no lineales.

Un programa no lineal es un programa de televisión compuesto no sólo por el audio principal y el vídeo principal, sino también por otros datos transmitidos en conjunto. Estos datos representan otro tipo de audio y vídeo, además del principal, imágenes, texto, etc., y una aplicación software relacionando temporal y espacialmente todos estos objetos multimedia, incluyendo el vídeo y el audio principal. Estas relaciones pueden ser guiados por las interacciones del usuario espectador, que pueden controlar el flujo de un programa de televisión, la determinación de si un determinado contenido se debe mostrar o no, y como será exhibido. A medida que el flujo de un programa televisivo deja de ser continuo en su diseño y con varios modos alternativos de exhibición, este programa se llama no lineal.

En resumen, en la TV analógica, vídeo, audio y alguna información de datos limitada



9

(como subtítulos) se transmiten multiplexados de tal manera que un receptor de diseño relativamente simple, puede descodificar y volver a montar los diversos elementos de señal para producir un programa. En un sistema de televisión digital, sin embargo, se requieren niveles de procesamiento adicionales. El receptor procesa el flujo digital extrayendo de la señal recibida, una colección de elementos de programa (video principal, audio principal, otros videos y audios, imágenes, textos, etc), anteriormente denominado objetos multimedia que integran el servicio seleccionado por el consumidor. Esta selección se realiza utilizando la información del sistema y de servicio, que también se transmite. Una vez que se hayan recibido los objetos multimedia, estos se muestran de acuerdo con un documento de especificación (parte de la aplicación), también recibida junto con los datos, que al ser procesada se encarga de la exhibición final. La capacidad computacional necesaria para el nuevo sistema puede ser integrado en el propio dispositivo de exhibición: un aparato de TV digital, un teléfono móvil, PDA, etc. Como un gran legado de los televisores analógicos, una solución simple para ofrecer estos nuevos servicios en estos sistemas de recepción es utilizar junto al televisor, un "sistema de procesamiento" capaz de manejar adecuadamente la señal, decodificarlo y mostrarlo consistentemente: no sólo el video y audio principal, sino las aplicaciones y servicios avanzados. Este sistema de procesamiento se llama convertidor digital (o set top box).

La siguiente figura muestra el diagrama de bloques de un receptor de televisión digital terrestre, que puede estar embebido o ser externo al aparato exhibidor, como se ha mencionado. La señal recibida después de ser sintonizada y demodulada (retirada del canal de frecuencia) es separa (demultiplexada) y entregada a los decodificadores de audio y vídeo, y para el procesamiento en una CPU. Obsérvese en la figura que el receptor tiene acceso a otra red (red externa en la figura) a través del cual se puede recibir o enviar datos según lo ordenado por la aplicación recibida. El acceso a este canal de red se llama canal de retorno o canal de interactividad. En un sistema de IPTV o P2PTV, por lo general la señal no se modula, directa ingresa en un módulo demultiplexor después de haber sido sintonizada; Además, también es habitual que el canal de retorno está constituido por la misma red de transmisión donde vienen los datos multiplexados procedentes de un transmisor.

1.2. Sistema de TV digital: Visión general

Un sistema de televisión digital es un sistema típico de cliente / servidor. En un sistema de televisión digital terrestre, el servidor hace de una radiodifusora (parte izquierda de la siguiente figura) o de un proveedor de contenido, o cliente, o usuario espectador (lado derecho de la figura).



10

Un programa esta compuesto de un video y audio principal, capturado en directo desde una cámara o desde un servidor de vídeo (lado izquierdo de la anterior figura). Un programa también puede contener datos adicionales, incluyendo la aplicación que define la relación entre los diversos objetos de medios definidos en estos datos. Los datos adicionales pueden venir encapsulado en formato IP o en otro formato. El vídeo y el audio se entregan a los codificadores digitales, responsables de la generación de los respectivos flujos de audio y video principal comprimidos. Estos flujos, más otros flujos de datos de otros, son multiplexados en una única señal, llamada flujo de transporte (TS - Transport Stream). Luego, en el caso de un sistema terrestre, el flujo de transporte se modula a un canal de frecuencia y se transmite en el aire. Ya en un servicio de IPTV, en general, el flujo de transporte se transmite directamente a los paquetes IP sin ninguna modulación.

Del lado de la recepción (lado derecho de la anterior figura), la señal es recibida y demodulada (retirada del canal de frecuencia sintonizada) en el caso de la televisión terrestre, se entrega al demultiplexador, que separa los principales flujos de audio y video principal (entregándolos a los decodificadores adecuados) de los flujos de datos, que se entregan para su procesamiento. El procesamiento de los datos recibidos puede requerir nuevos datos obtenidos del canal interactivo. Los datos también pueden ser enviados por la aplicación a la emisora o cualquier otro destino en la red del canal interactivo. Un sistema de televisión digital comprende un conjunto de normas que rigen cada uno de los procedimientos descritos en la anterior figura, llamados normas de referencia, como muestra la siguiente figura.



11

1.2.1. Codificación de audio

Una señal digital lleva en general, mucha información redundante. Si eliminamos esta redundancia, podemos reducir en gran medida la cantidad de bits generados.

Cuando solo se elimina la redundancia de la señal, no hay pérdida de información, y se dice que hay una compactación o compresión sin pérdida. Sin embargo, también disminuye una cantidad de bits con cierta pérdida de información. Dependiendo de quién es el usuario de una información, parte de esta puede ser considerada poco útil. Rara vez es necesario mantener la señal original 100% intacta, en el caso de los medios de vídeo, audio e imágenes fijas, ya que el usuario final perdería de cualquier forma parte de la información por limitaciones físicas; por ejemplo, las limitaciones del oído y de los ojos humanos. Una cantidad de información que podemos perder puede ser dependiente del usuario, pero también puede depender de la tarea en desarrollo: por ejemplo, perder un poco de nitidez de una vídeotelefonía puede ser perfectamente aceptable, mientras que la pérdida de la calidad de vídeo puede ser inadmisible en una aplicación médica. Cuando en la reducción de los datos generados hay pérdida de información, se dice que hubo una compresión con pérdidas o simplemente compresión. Cuando esta pérdida no es perceptible por el ser humano, se dice que hubo una compresión perceptualmente sin pérdidas.

En un sistema de televisión digital, las técnicas de compresión perceptualmente sin pérdidas se emplean en el audio generado, teniendo en cuenta el modelo psicoacústico humano. El modelo divide el dominio de la frecuencia audible en varias bandas, y sobre ellas aplicar filtros, teniendo en cuenta la sensibilidad del oído humano, la frecuencia de enmascaramiento, el enmascaramiento temporal y cómo el ser humano percibe el audio multicanal. El resultado es un audio de alta calidad y con baja tasa de bits generados. El sistema americano de televisión digital terrestre utiliza la norma de codificación AC3/ATSC, antiguo nombre de codificación hoy llamada Dolby Digital (DD). Una codificación, propietaria de la empresa Dolby, que utiliza seis canales de audio, incluyendo cinco con alta calidad (20-20 KHz) y una para las frecuencias bajas (20-120 Hz). El sistema europeo de televisión digital terrestre utiliza la norma MP2 (MPEG-1 Layer 2) [ISO/IEC 11172-3 ES, 1993], pero algunas implementaciones siguen el estándar MPEG-2 Advanced Audio Coding (AAC) [ISO/IEC 13818 -7, 1997], también adoptado por el sistema terrestre japonés. La AAC MPEG-2, también conocido como MPEG-2 Parte 7 o MPEG-4 Parte 3, fue diseñado como un codec (codificador / decodificador), de mejor rendimiento en relación a MP3 (MPEG-1 Layer 3) [ISO/IEC IS 11172-3 1993], para codificación de audio en tasas de bits medias a altas. La AAC se considera estado de arte para audio de alta calidad en una tasa de bits típica de 128 Kbps. Por debajo de esta tasa, la calidad de audio



12

comienza a degradarse, lo que puede ser compensado por las técnicas de mejora como SBR (Spectral Band Replication) y PS (Parametric Stereo). El SBR es una técnica de extensión que permite la misma calidad de sonido de AAC aproximadamente a la mitad de la tasa de bits. La combinación de SBR y AAC se llama HE-AAC (High-Efficiency AAC) Versión 1 [ISO/IEC 14496-3, 2004], también conocido como "AACPlus v1". PS aumenta la eficiencia de codificación aun más, a través de una representación paramétrica de la imagen estéreo de una señal de entrada. La combinación de AAC, SBR y PS se llama HE-AAC (AAC de alta eficiencia-) versión 2 [ISO/IEC 14496-3, 2004]. HE-AAC, definido en el estándar MPEG-4, es un superconjunto del núcleo AAC, que extiende la alta calidad de audio AAC a tasas de bits más bajas. Los decodificadores HE-AAC v2 son capaces de decodificar HE-AAC v1 y flujos ACC. A su vez, los decodificadores HE-AAC v1 también son capaces de decodificar flujos AAC. El sistema brasileño de televisión digital terrestre adoptó el estándar MPEG-4 para codificar el audio principal de un programa [ABNT NBR 15602-2, 2011], con las características que se indican en la siguiente tabla:

1.2.2. Codificación de vídeo Una señal de vídeo digital lleva mucha información redundante, espacialmente (redundancia intra cuadros) y temporalmente (redundancia entre cuadros). En un cuadro de vídeo no se produce, en general, cambios bruscos de un pixel para un píxel consecutivo, a excepción de los contornos de los objetos. En particular, podemos utilizar codificación JPEG [ISO/IEC 10918-1, 1994] en cada cuadro de vídeo para aprovechar esa redundancia espacial. Esta técnica, aplicada cuadro a cuadro, constituye la base de la codificación llamada MJPEG (Motion JPEG). Sin embargo, para emplear esta codificación, se toma en cuenta sólo la redundancia intra cuadros, cuando la mayoría de redundancia puede estar en la información contenida en cuadros consecutivos (redundancia entre cuadros), que es explorada en el estándar de vídeo MPEG. En el estándar de vídeo MPEG-2 [ISO / IEC 13818-2, 2000], cada bloque (conjunto de 8 x 8 pixels) puede codificarse utilizando sólo información intra cuadros. Los cuadros que en todos los bloques se codifican de esta manera se denominan cuadros I. Un macrobloque (un conjunto de 16 x 16 píxeles) también puede ser codificada de manera predictiva. Una predicción MPEG puede hacerse en base a cuadros pasados y futuros de una secuencia de vídeo. Cuando una predicción se realiza en base a un cuadro



13

pasado, se codifica un error de predicción (diferencia de macrobloque que se quiere codificar y un macrobloque de referencia del cuadro pasado) utilizando los mismos procedimientos usados para los bloques intra cuadros y el vector de movimiento (que da la posición relativa del macrobloque que se quiere codificar para un macrobloque de referencia cuadro pasado). Los cuadros codificados utilizando este tipo de predicción se denominan cuadros P. En vídeo MPEG-2, la predicción se basa siempre en el primer cuadro de tipo I o P anterior. También se pueden codificar macrobloques en base al primer cuadro I o P, anterior o posterior. En este caso tenemos dos cuadros de referencia para la búsqueda del mejor emparejamiento. La codificación puede realizarse sobre la base del cuadro anterior, el cuadro posterior, o incluso la interpolación de los cuadros anterior y posterior. Los cuadros codificados utilizando este tipo de predicción se denominan cuadros B. El estándar de vídeo MPEG-2 es compatible con varios formatos de cuadros y diferentes resoluciones para los componentes de crominancia (submuestreo de crominancia). De hecho, el MPEG-2 especifica varios conjuntos de parámetros de restricción, que se definen en sus perfiles y niveles. Un perfil especifica las características de codificación que serán utilizados (por ejemplo, los tipos de cuadros, submuestreo ,etc.). Un nivel especifica la resolución de los cuadros, las tasas de bits, etc. Para la televisión digital, el vídeo MPEG-2 establece el perfil principal (usa los cuadros I, P y B y un sub-muestreo de color 4: 2: 0), los niveles principales (720 píxeles/línea x 480 líneas x 30 cuadros/seg) y alto (1.920 píxeles/línea x 1080 líneas x 30 cuadros/seg), respectivamente, para SDTV y HDTV. El sistema americano, europeo y japonés de televisión digital terrestre adoptan vídeo MPEG-2 como su estándar para la codificación de vídeo. La televisión digital terrestre brasileña emplea una técnica de codificación más reciente: H.264 [ISO/IEC 14496-10, 2005], también conocido como MPEG-4 Parte 10, o MPEG-4 AVC (Advanced Video Coding). El objetivo del proyecto H.264/AVC fue crear una norma capaz de proporcionar una buena calidad de vídeo a una velocidad sustancialmente más baja que los estándares anteriores (MPEG-2 entre ellos), sin aumentar mucho su complejidad, para facilitar una implementación barata y eficiente. Un objetivo adicional era proporcionar flexibilidad suficiente para permitir su aplicación en una variedad de sistemas de tasas de transmisión altas y bajas, así como las resoluciones de vídeo altas y bajas. H.264 contiene varias características nuevas que permiten una compresión de vídeo mucho más eficiente y flexible. Las técnicas empleadas, hacen de H.264 una norma significativamente mejor que las normas anteriores, bajo una variedad de circunstancias y entornos de aplicación, en particular el ambiente de televisión digital, en el que ofrece un rendimiento mucho mejor que video MPEG-2. En particular, en los casos de alta resolución y alta tasa de bits, la norma H.264 para la misma calidad de vídeo, genera una tasa de 50% o menos que la tasa generada por la norma MPEG-2. Al igual que la norma de vídeo MPEG-2, H.264 se divide en perfiles y niveles. En el caso de la televisión digital terrestre de Brasil, se utiliza el perfil alto (HP) para receptores fijos y móviles y el perfil base (BP) para receptores portátiles [ABNT NBR 15602- 1, 2007], como se muestra en la siguiente tabla:



14

1.2.3. Sistema de Transporte Los sistemas americanos, europeos y japoneses de televisión digital terrestre estandarizar la forma en que la información audiovisual, junto con los datos, deben ser multiplexados en un solo flujo. Todos los sistemas mencionados adoptan el mismo sistema de multiplexación, MPEG-2 [ISO/IEC 13818-1, 2000], con algunas variaciones. Muchos sistemas de IPTV también adoptan el sistema MPEG-2. El sistema MPEG-2 suma a los flujos elementales de audio y video principales, información para sus exhibiciones sincronizadas. La sincronización se lleva a cabo siguiendo el paradigma de eje de tiempo (timeline) mediante la adición de marcas de tiempo (time stamp) a conjuntos de muestras codificadas de video y audio, en base a un reloj común.

La generación y la multiplexación de flujos de datos (los datos que no sean audio y vídeo principal) también están determinadas por la norma. 1.2.3.1. Multiplexación de datos Los flujos de datos pueden ser transportados a través de servicios síncronos (débilmente acoplados), sincronizados (estrechamente acoplados) o asíncronos (desacoplados). El servicio de transporte síncrona supone que los flujos de datos se sincronizan entre sí, siguiendo el paradigma eje de tiempo (timeline) mediante la adición de marca de tiempo (timestamp). Los flujos de datos, sin embargo, no están relacionados con el temporizador de los flujos de vídeo y audio principales. La siguiente figura ilustra el procedimiento. Tenga en cuenta que las marcas de tiempo asociadas con los flujos de datos son diferentes de los asociados a los flujos de audio y vídeo principal.



15

La exhibición de comerciales, estadísticas deportivas, sistemas de ayuda, entre muchos otros, son ejemplos de aplicaciones que sólo tienen significado en el contexto de la exhibicion del vídeo principal. Por lo tanto, con la posibilidad de enviar dichos datos por difusión, los estándares de televisión digital deben establecer mecanismos que permitan la sincronización de los datos con los flujos de audio y vídeo principal. El servicio de transporte sincronizado supone que los flujos de datos están sincronizados entre sí y con los flujos de audio y video principal, siempre siguiendo el paradigma de eje de tiempo (línea de tiempo), mediante la adición de marcas de tiempo. La siguiente figura ilustra el procedimiento. Tenga en cuenta que las marcas de tiempo asociadas con los flujos de datos son los mismos que los asociados con los flujos de audio y vídeo principal.

Los flujos de datos en el transporte síncrono y sincronizado sólo permiten el sincronismo cuando el instante de tiempo de sincronización es determinístico. Las aplicaciones interactivas, en las que la sincronización se da en un tiempo aleatorio determinado por el usuario telespectador donde se genera el contenido en tiempo de visualización y no se puede determinar el tiempo exacto en que se producen eventos y aplicaciones cuyo contenido se determina en tiempo real (el tiempo de visualización) no se puede sincronizar el servicio síncrono o servicio sincronizado. El apoyo en este caso viene dada por las transferencias asíncronas. Los servicios asíncronos implican que ninguna marca de tiempo (timestamp) esta asociada con los datos. Sin embargo, puede haber sincronismo entre los diversos objetos transportados; y entre estos objetos y los flujos de audio y/o vídeo principal. De este modo, el paradigma de sincronización de línea de tiempo es abandonado, siendo sustituido por el paradigma de la causalidad/restricción (también llamado orientado a eventos). En los servicios asíncronos, junto con los datos se envía la aplicación (sombreada en la siguiente figura), que especifica en un lenguaje de programación especifico, el comportamiento relativo de los datos, del audio principal y del vídeo principal, en tiempo y espacio.



16

El servicio asíncrono es la única forma de sincronización de objetos con tiempo de sincronización indeterminado. Sin embargo, requiere un lenguaje para la especificación del sincronismo y en el receptor, una máquina capaz de interpretar y ejecutar comandos de sincronización especificados en el lenguaje. El estándar MPEG-2 especifica los diferentes tipos de servicio, pero no especifica el lenguaje utilizado para la sincronización del servicio asíncrono. Tenga en cuenta también que es posible que en una transmisión que parte de los datos sigan un servicio y otra parte otros. 1.2.3.2. Flujo elemental de datos Hasta ahora partimos del supuesto que los flujos de datos que ya estaban generados y empaquetados. El estándar MPEG-2 también especifica varias maneras en que estos datos pueden ser transportados y las opciones para el proceso de generación de estos flujos. Los flujos de audio y vídeo se transportan usando servicios síncronos y sincronizados que se generan de una manera similar a la generación de los flujos de audio y vídeo principal. Cada flujo elemental debe ser dividido en paquetes de forma que se puedan multiplexar en el flujo de transporte. Para ayudar a resolver este problema, MPEG define un concepto llamado secciones privadas, o simplemente secciones, que se utilizan para empaquetar los datos a ser transportados en el servicio asíncrono para posteriormente ser multiplexados. Las secciones siguen un formato estandarizado [ISO/IEC 10918-1, 1994]. Cada sección puede contener hasta 4.096 bytes de datos y una cabecera que indica al receptor cuantas secciones están siendo usadas para transportar un flujo de datos especifico y cómo los datos deben armados.

Así como sintonizar un canal de televisión en particular (y por lo tanto un flujo multiplexado del sistema MPEG-2) puede realizarse en cualquier momento, los datos sin solicitud (datos empujados) que no tengan relación temporal especifica por medio de marcas de tiempo, deben ser enviados de forma cíclica. Si es hecho así, la recepción de dichos datos será independiente del instante de la sintonía.

Para apoyar el envío cíclico de datos, prevalece en los sistemas de televisión digital terrestre el uso de protocolos de carrusel de datos y carrusel de objetos, especificados en la norma DSM-CC (Digital Storage Media – Command and Control) [ISO/IEC 13818-6 1998]. Los carruseles de datos y objetos son transportados en secciones privadas especificas MPEG-2. Debe tenerse en cuenta que otros protocolos para difusión de datos sin solicitud (pushed data-datos empujados) se utilizan principalmente en los sistemas IPTV y P2PTV.

Un carrusel de datos DSM-CC permite el envío de datos no estructurados. La estructura es para el sistema de televisión digital que lo utiliza. El sistema japonés de televisión



17

digital utiliza esta norma. Un carrusel de objetos permite el envío cíclico de un sistema de archivos. Así que, para sintonizar un determinado canal, el receptor debe ser capaz de decodificar los datos recibidos y ponerlos en un área de memoria para que puedan ser utilizados, manteniendo la estructura de archivos y directorios enviada. Los datos enviados tanto en el sistema americano y europeo como en el sistema de televisión digital terrestre de Brasil utilizan el carrusel de objetos.

Debe tenerse en cuenta que más de un carrusel puede transmitirse de manera simultánea y un carrusel de objetos puede hacer uso de los recursos (archivos, directorios, y otros objetos [ISO/IEC 13818-6, 1998]) que están siendo transferidos en otros carruseles. Por otra parte, las aplicaciones transferidas en archivos de un carrusel pueden hacer referencia a los recursos presentes en el mismo carrusel o recursos de otros carruseles. Por ejemplo, una página HTML transmitida en un carrusel puede hacer referencia a una imagen cuyo contenido se transmite en otro carrusel de objetos.

El carrusel de objetos es en realidad un protocolo de transmisión cíclica de datos. El resultado es un flujo elemental de datos que contiene el sistema de archivos transmitido cíclicamente. Por lo tanto, si un receptor particular no ha recibido un bloque de datos en particular (debido a un fallo en la transmisión o por haber sintonizado el canal después de la transmisión de ese bloque), sólo tiene que esperar por su retransmisión correcta.

Como se mencionó anteriormente, en el transporte de datos asíncrono, todas las especificaciones de sincronismo entre los datos, audio principal, video principal y otros datos enviados por los servicios síncronos o síncronizados se envía en un documento de especificación de la aplicación (bloque sombreada en la anterior figura). Este documento también puede ser transportado en una sección privada MPEG (por ejemplo, un carrusel DSM-CC). Para que la aplicación entre en ejecución, un comando debe ser enviado al receptor. La norma MPEG-2 también especifica cómo esto se puede lograr mediante el envío de eventos de sincronismo DSM-CC de (o simplemente eventos DSM-CC).

1.2.3.3. Flujo de transporte

Cada flujo elemental MPEG-2 (audio principal, vídeo principal, flujo del carrusel, etc.) tiene un identificador único. La especificación del sistema MPEG-2 define aún más el termino programa, llamado servicio en el contexto de la televisión digital, como un grupo que consiste en uno o más flujos elementales con una misma base temporal. El flujo de transporte multiplexado puede contener múltiples servicios (programas) simultáneamente, cada uno de los cuales puede tener una base de tiempo diferente.

En resumen, múltiplexar servicios en un flujo de transporte significa organizar los paquetes de varios flujos elementales que pertenecen a los servicios incluidos en un único flujo. Para ello, es necesario introducir en el flujo de transporte, informaciones que permitan al decodificador MPEG-2 pueda identificar a qué servicio pertenece un determinado flujo elemental. Esta información se presenta como un conjunto de tablas de información específica de programa (PSI – Program Specific Table). Un PSI en particular, llamada PMT (Program Map Table), contiene la lista de identificadores de flujos elementales que componen un servicio. Cada PMT encontrado representa un servicio disponible. Los PMTs se localizan a través de otro PSI, llamado PAT (Program Association Table), que contiene identificadores de los flujos elementales contenidos en los PMTs. El flujo elemental que tiene el PAT posee un identificador fijo con el valor



18

hexadecimal 0x00. La siguiente figura ilustra una multiplexación del sistema MPEG-2, incluyendo flujos elementales de las tablas PSI.

1.2.4. Modulación

Una de las normas más importantes de un sistema de televisión digital terrestre es la que establece el proceso de modulación, responsable de recibir un flujo de transporte y posicionarlo en un canal de frecuencia.

Las técnicas de modulación digital se pueden dividir en dos grupos: los que tienen una sola portadora como el sistema americano 8-VSB (Vestigial Side Band)/ATSC [ATSC A-53, 2007] y el sistema chino 4-16 o 64-OQAM (Quadrature Amplitude Modulation))/ADTB [ADTB 2001], y uno con múltiples portadoras, como en el sistema europeo COFDM/DVB-T [ETSI EN 300 744 V1.1.2, 1997] y el sistema japonés BST-OFDM/ISDB-T [ISDB-T, 1998], que también puede ser modulada en fase (QPSK, 16QAM y 64QAM). En el caso del sistema japonés, las portadoras también pueden ser moduladas con DQPSK. El sistema brasileño BST-OFDM/SBTVD-T [ABNT NBR 15601, 2007] utiliza la misma modulación del sistema japonés.

Para el alojamiento de un canal de televisión de alta definición en una banda de 6 MHz requiere no sólo de las técnicas de compresión eficiente, sino también de técnicas de modulación con múltiples niveles. Algunos sistemas de modulación digital simples sólo trasportan un bit de información por símbolo. En otras palabras, cada símbolo debe ser representado por uno de dos estados posibles (niveles) que representa el bit 1 ó 0. En este caso, la tasa de bit de sistema es la misma que la velocidad de símbolos. Sin embargo, otros sistemas pueden tener muchos estados posibles para cada símbolo. En general, el número de estados es una potencia de dos y por tanto la tasa de bits del sistema es un múltiplo entero de la tasa de símbolos. Los sistemas de modulación digital a menudo se indican con el tipo de modulación precedido por un número que representa el número de estados para cada símbolo. Por ejemplo, 4QAM describe una modulación con cuatro estados posibles para cada símbolo. Cuatro estados puedan ser portadores de dos bits de información (00, 01, 10 y 11); Por lo tanto, la tasa de bits de un sistema 4QAM es el doble de la tasa de símbolos.

Aunque es tentador, no podemos aumentar impunemente el número de niveles, aumentando una tasa de transmisión posible, porque al aumentar el número de niveles, disminuye la sensibilidad al ruido, aumentando la probabilidad de interferencia entre



19

símbolos, lo que reduce el rendimiento del sistema en cuanto a la tasa de error de bits (BER).

En las técnicas de portadora única, los símbolos digitales se transmiten en serie, lo que significa que el intervalo de señalización (ventana de tiempo) asociado a cada símbolo es muy pequeño cuando las tasas de transmisión son altos. Las propuestas actuales para la televisión de alta definición HDTV, que usan aproximadamente tasas de 19,3 Mbps, traen problemas técnicos difíciles de resolver para la radiodifusión, siendo inevitables fenómenos de trayectos múltiples. Ya que, un intervalo de señalización pequeño, aumenta la probabilidad de interferencia entre símbolos, que causa errores de recepción de la señal. Cuando el intervalo de señalización es muy pequeño, también aumenta la sensibilidad al ruido impulsivo, ya que los errores pueden ser causados en secuencias de bits consecutivos. La resolución de estos problemas requiere el uso de ecualizadores adaptables muy complejos. El rendimiento de estos ecualizadores es esencial para que el sistema funcione correctamente. Si el número de trayectos existentes es mayor que la capacidad de actuación del ecualizador, la tasa de error se vuelve lo suficientemente alta para poner el sistema fuera de servicio.

Por otro lado, las técnicas con multiples portadoras prometen un rendimiento mucho mejor contra el ruido impulsivo y multi trayecto ya que cada símbolo puede tener su mayor periodo de transmisión de tal manera que sea mucho mayor que la duración del impulso de ruido e intervalo de dispersión de propagación. Por lo tanto, un flujo digital de alta tasa de bits se divide en un gran número de canales con tasa de bits baja. Estos canales se utilizan para modular las subportadoras individuales y se transmiten en paralelo (simultáneamente), a diferencia de la técnica de portadora unica, en donde los datos se envían en serie. Esta diferencia clave permite extender el tiempo de transmisión de cada dato para combatir los efectos de la dispersión temporal y el ruido impulsivo.

La técnica utilizada para la modulación de las subportadoras es una variación de la multiplexación por división de frecuencia (FDM). En un sistema FDM, las portadoras están espaciadas suficientemente para que puedan ser recibidas utilizando filtros convencionales. Para hacer posible el filtrado, intervalos de guarda deben insertarse entre dichas portadoras, lo que resulta en una disminución en la eficiencia espectral. En la técnica utilizada para la modulación de las subportadoras (OFDM - Orthogonal Frequency Division Multiplexing), en lugar de utilizar un intervalo de guarda entre subportadoras, ellas se sobreponen, pero sin que haya interferencia entre ellas Para que esto sea posible, las subportadoras debe ser matemáticamente ortogonales (linealmente independientes), de ahí el nombre de OFDM que resulta en una ganancia espectral de hasta un 50% en comparación con la técnica de FDM.

Para llegar a ser menos sensible a un problema de trayectos múltiples, la modulación OFDM adopta un intervalo de guarda con una duración superior que la dispersión producida en los múltiples trayectos. Satisfecha esta condición, no habrá interferencia entre símbolos. Por lo tanto, la modulación OFDM no requiere ecualizadores complejos para que tenga éxito en la recepción de canales con múltiples trayectos.

Veamos un ejemplo sencillo. Si enviamos un millón de símbolos por segundo utilizando una modulación de portadora única, la duración de cada símbolo seria de 1 microsegundo, imponiendo severas restricciones a la interferencia de trayectos múltiples. Si los mismos símbolos se envían en mil subcanales, en paralelo, la duración de cada símbolo será de 1 milisegundo. Supongamos ahora que se introduce un intervalo de



20

guarda de 1/8 de símbolo entre cada símbolo. Las interferencias entre símbolos se puede evitar si el tiempo de recepción entre el primer y último eco es menor que el intervalo de guarda, o 125 microsegundos, lo que equivale a una diferencia de trayectoria de propagación de aproximadamente 37,5 kilómetros. Como se menciono, todos los estándares de transmisión para la televisión digital terrestre usan códigos de corrección de errores. La modulación OFDM se usa siempre en combinación con la codificación de canal, de ahí el nombre de COFDM. Tanto el sistema DVB-T y el ISDB-T, la codificación de canal implica la codificación de Reed-Solomon y Trellis. La técnica de modulación BST-OFDM (Band Segmented Transmission Orthogonal Frequency Division Multiplexing) propuesto en el sistema japonés (ISDB-T, ISDB-TSB e ISDB-C) mejora la técnica COFDM en dos direcciones mediante la introducción de la segmentación de banda y el intercalado de tiempo (time interleaving).

La intercalacion de tiempo se extiende sobre una señal transmitiendo símbolos consecutivos generados en la señal original. Por lo tanto, cuando se producen errores, no afectan símbolos consecutivos, pero en realidad están repartidas con la señal original. Evitando la concentración de errores, se evita que los correctores de errores no sean capaces de recuperarlos.

La segmentación de la banda explora el hecho de que algunas portadoras pueden ser moduladas de forma diferente de los demás. Por lo tanto, un canal de televisión de 6 MHz puede ser segmentado y modulado con una técnica más adecuada para cada servicio. Es posible, por ejemplo, enviar señales de vídeo en un solo canal con modulación optimizado para la recepción móvil, enviar otras señales de vídeo en otro canal optimizado para la recepción fija, etc.

1.2.5. Canal de retorno o canal de interactividad

Un sistema de televisión digital terrestre puede funcionar sin canal de retorno (o canal de interactividad). En este caso, las aplicaciones pueden utilizar (o navegar por semejanza con la Web) sólo los datos transmitidos por difusión. Si las aplicaciones permiten la interacción del usuario, el servicio ofrecido se llama interactividad local.

Las normas de referencia de un sistema de televisión digital pueden incluir, sin embargo, el uso de un canal de retorno.

• El canal de retorno puede ser unidireccional, permitiendo simplemente que el receptor pueda enviar datos. El nivel de interactividad, permite al espectador el envío de datos, por ejemplo, solicitando la compra de un producto en particular, votando sobre un tema determinado, etc.

• El canal de retorno también puede ser bidireccional asimétrico, permitiendo que el receptor pueda cargar datos (descarga) utilizados por las aplicaciones. En este caso, una aplicación puede recibir datos por difusión o por la red de retorno.

• Un tercer nivel de interactividad, permite al usuario el acceso a datos no provenientes de la difusión, por ejemplo, permitiendo navegar por la web.

• Un canal de retorno bidireccional también puede permitir el envío de datos en banda ancha (de subida). En este caso, el receptor puede pasar a actuar como una pequeña emisora. Este nivel de interactividad, llamada interactividad total, permite, entre otras cosas, lo que se ha llamado "televisión social (social TV)" o



21

"comunidad TV (community TV)", que se caracteriza porque un grupo de espectadores del mismo programa puedan intercambiar datos entre sí.

La televisión digital terrestre brasileña permite, en su reglamento, los cuatro niveles de interactividad, así como los sistemas americanos, la televisión digital terrestre de Europa y Japón.



22

Tema II Arquitecturas Modernas de la Televisión Digital (Hardware)

Un sistema de televisión digital consiste en un conjunto de normas representados en la figura siguiente.

Este conjunto de normas consisten en modelos: digitalización de vídeo y audio; middleware responsable de implementar la interactividad y nuevos servicios; multiplexación y transmisión de señal (modulación).

2.1. Estándares de Transmisión de Televisión Digital Los estándares de transmisión digital que están en uso o en proceso de adopción en algunos países, pueden resumirse en cinco:

• El estándar Americano, ATSC • El estándar Europeo, DVB • El estándar Japonés, ISDB-T • El estándar Brasileño SBTVD-Tb • El estándar DTMB, que es la norma china.



23

La inclusión de los estándares a nivel mundial dependen de la ubicación geográfica de los países así como de el estándar mas factible según la geografía del país que lo va a implementar.

2.1.1. ATSC Advance Television System Committee

Es una organización sin ánimo de lucro que fue creada en el año de 1982 para la estandarización de soluciones tecnológicas que respecta la TV Digital Terrestre, que inicialmente fueron requeridas por los radiodifusores de TV abierta, libre y gratuita del mercado de los Estados Unidos y que posteriormente fue extendida hasta Canadá, México, Corea del Sur, Honduras y a otros países que están deseosos de mantener un modelo de servicio de TV Digital Terrestre abierta. El estándar ATSC fue creado principalmente para la TV libre y gratuita, en donde se utiliza el mismo ancho de banda (6 MHz) que se utilizaba en la TV Análoga, todo ello con el fin de brindar al usuario final una calidad de señal en HD con multiprogramación,



24

comunicación interactiva entre otras características. Este Estándar se creó para remplazar el sistema de televisión analógica NTSC. El método de modulación utilizado en el sistema ATSC es conocido por el acrónimo 8VSB (Eight-Vestigial Side Band). La velocidad de bits en la entrada de modulador 8VSB es fijo (19,39 Mbit /s). La siguiente figura muestra un diagrama de bloques simplificado del modulador 8VSB.

El "codificador Reed Solomon" es una FEC ( "forward error corrector" = corrector de error posterior). Añade 20 bytes en el "paquete" MPEG-2, con el fin de corregir errores en la señal que llegará al receptor. El "Reed-Solomon" no corrige los errores concentrados, tales como el ruido impulsivo. El "Interleaver" baraja los bits de tal manera que si en la trayectoria de la señal entre el transmisor y el receptor, hay una interferencia, el receptor realiza el desbarajamiento, y los errores se distribuyen. El "codificador Trellis" es un FEC convolucional. A cada 2 bits se le añade 1 bit con el fin de corregir posibles errores en el receptor. Por lo tanto, tenemos: tasa de código = (CR) C = 2/3. El " Modulador 8 VSB " modula una portadora situada a 310 kHz del comienzo del ancho de banda de 6 MHz en AM-VSB/SC (amplitud modulada con portadora suprimida y banda vestigial). En la modulación 8VSB, hay 8 niveles bien definidos: 4 positivos y 4 negativos. Estos niveles son tales que cada conjunto de tres bits consecutivos de la señal se corresponderá con un nivel. En consecuencia, la tasa de bits se divide entre 3 y por lo tanto la frecuencia de la señal de modulación resultante se hace compatible con la banda de 6 MHz, como en la modulación VSB. La siguiente figura muestra la apariencia del espectro de la señal ATSC de un canal con ancho de banda de 6 MHz (canal 14 UHF). El papel de "piloto" (7%) es el envío de una pequeña porción de la señal portadora para sincronizar el oscilador del receptor, lo que permitirá la recuperación de la señal enviada desde el proceso de "portadora suprimida".



25

2.1.2. DVB-T Digital Video Broadcasting Terrestrial

Este sistema nace de una gran alianza entre más de 280 compañías de difusión, fabricantes, operadores de red, desarrolladores de software, entidades reguladoras y entre otras instituciones en más de 35 países que están comprometidos con el diseño de estándares a nivel mundial, el suministro de televisión digital y servicios de datos. DVB es uno de los estándares más completos ya que abarca los aspectos de difusión y los estandariza, desde las transmisiones hasta las interfaces, el acceso condicional y la interactividad del video, audio y datos. Los estándares que propuso este sistema han sido aceptados en Europa y en casi todos los continentes. Este sistema se basa en el estándar MPEG en donde se cubren aspectos y metodologías que se utilizan en la compresión de las señales de audio, video y datos y en los procedimientos de multiplicación y sincronización de estas señales en tramas de transporte. Pero también es necesario la definición del sistema de modulación de la señal que es utilizada en los distintos tipos de radiodifusión: DVB-C (Cable), DVB-S (Satélite) y DVB-T (Terrestre). Actualmente, el estudio e implementación de este sistema ya están consolidados, y sus especificaciones dan lugar a productos que se están fabricando y usando en el mundo entero. La figura muestra el diagrama de bloques simplificado del sistema DVB-T.

El "Codificador Outer" realiza una función similar a "Reed-Solomon" del sistema ATSC. La única diferencia es que en el sistema DVB-T se añaden sólo 16 bytes en el "paquete" que



26

contendrá 204 bytes en la salida. En el "outer interleaver" los bits se barajan de la misma manera que en el "interleaver" del sistema ATSC. El "Inner Coder" es similar al "Tellis Encoder" del sistema ATSC. La diferencia es que en el sistema de ATSC, el valor (CR) C se fija en 2/3, y en el sistema DVB-T se puede programar para diversos valores (1/2; 2/3; 3/4; 5 / 6 o 7/8). El sistema DVB-T posee dos métodos de multiportadora: 2K y 8K. En el "Modulador OFDM" se crean 1705 portadoras ortogonales simultáneas para el modo 2k o 6734 portadoras ortogonales simultáneas para el modo 8K. Esto se logra mediante DSP ("Digital Signal Processing" = Procesamiento Digital de Señal), mediante el uso de una IFFT ("Inverse Fast Fourier Transform " = Transformada inversa rápida de Fourier) y un convertidor D/A (digital/analógico). En el estándar M (ancho de banda de 6 MHz), la separación entre portadoras es fx = 3348,1 Hz para el modo 2K y fx = 837.025 Hz para el modo 8K. El sistema DVB-T puede ser programado para modulación QPSK ("Quaternary Phase Shift Keying" = 2 flujos digitales), 16QAM ("16 Quadrature Amplitude Modulation" = 4 flujos digitales) o 64QAM ("64 Quadrature Amplitude Modulation" = 6 flujos digitales ). En el " Inner Interleaver " la señal se convierte en 2, 4 o 6 flujos digitales (en función del tipo de modulación elegido) y a través del "Mapper", estos flujos se asignan consecutivamente, a las 1705 portadoras en el modo 2k o a las 6734 portadoras del modo 8K. En la salida de " OFDM Modulator" aparecen bloques estáticos de portadoras simultáneas moduladas en QPSK, 16QAM o 64QAM. El tiempo util de cada bloque, también conocido como "símbolo" es Tu = 1 / fx. Por lo tanto, se tiene: Tu= 298,67ms para el modo 2k, y Tu = 1,1947ms para el modo 8K. Después de cada símbolo, un intervalo de tiempo se deja sin ninguna información, conocido como "intervalo de guarda" (Delta t = kTu). Para el sistema DVB-T, el factor k se puede ajustar a 1/4, 1/8, 1/16 o 1/32. La introducción del "intervalo de guarda" da al sistema DVB-T una protección natural contra interferencias de "trayectoria múltiple" o "fantasmas". Suponga, como ejemplo una transmision en el modo 8K con k = 1/32 y que, en la señal principal, está llegando al receptor una señal retardada 20 us. Como Delta t = kTu = (1/32) *1,1947ms = 37,3ms, se concluye que la señal retardada no invadirá el siguiente símbolo.



27

2.1.3. ISDB-T Integrated Service Digital Broadcasting

El sistema fue desarrollado en Japón donde actualmente está en operación además de la adopción en Brasil entre otros países. Es promovido por Digital Broadcasting Experts Group (DIGEB) de Japón, grupo que fue creado en 1997 conformado por los principales operadores y fabricantes que trabajan en el medio de radiodifusión con el fin de promover el sistema por todo el mundo. El ISDB se empezó a desarrollar en 1980, pero finalmente fue estandarizado en los años 90. Al igual que el sistema europeo este sistema de radiodifusión de video digital está definido por ISDB-S (Satélite), ISDB-C (Cable) e ISDB-T (Terrestre) que hace la inclusión de canales móviles. Fue diseñado bajo la norma MPEG-2 y específica para su transmisión la resolución estándar en modo multiplexado y de alta definición (HDTV). El servicio de ISDB se inició en Japón en Diciembre de 2003 y gracias a sus nuevos servicios como “One-Seg”, que es el servicio de recepción portátil en el mismo canal de transmisión muestra un gran avance tecnológico en cuanto a la forma de ver televisión. El sistema ISDB-T es una evolución del sistema DVB-T, a la que se han añadido las siguientes implementaciones:

• Se ha añadido un tiempo de "interleaver" para mejorar el rendimiento en presencia de interferencias concentrado tal como ruido de impulso;

• El ancho de banda RF de 6 MHz se divide en 13 segmentos independientes, con la posibilidad de 3 ajustes diferentes se puede enviar al mismo tiempo, por ejemplo, un QPSK, 16QAM, y otro en otro en 64QAM;

• Se añade el modo 4K; • Se añadió a la modulación DQPSK método " Differential Quaternary Phase Shift

Keying ".



28

2.1.4. SBTVD-T Sistema Brasileño de Televisión Digital Terrestre

En Brasil, han implementado su propio sistema de televisión digital, pues se hizo un llamado a las universidades e investigadores para pensar en el desarrollo de proyectos de TV digital, así como para el estudio de los sistemas actuales. Entre 2004 y 2006 se discutió el estándar que sería adoptado por el país con una variable que fuese un sistema con características brasileñas. El sistema elegido de TDT en 2006 es una mezcla de las tecnologías japonesas como lo es el IDSDB-T y la tecnología brasileña, básicamente la diferencia radica en que el estándar SBTVD-T utiliza el códec de video H.264/MPEG-4 en ves del MPEG-2 usado por los japoneses. El inicio de las transmisiones de TV Digital tiene su inicio en la ciudad de Sao Paulo y ahora se hace la extensión a las demás capitales y principales ciudades, hasta lograr un cubrimiento del 100% en el país. 2.1.5. DTMB Digital Terrestrial Multimedia Broadcasting El Gobierno Chino fundó en 1994 el grupo Expertos Ejecutivos Técnicos de Televisión de Alta Definición (TEEG), donde sus miembros son seleccionados de universidades e institutos de investigación que trabajan con el desarrollo de televisión digital. Alrededor de 1999 y tras años de estudio y esfuerzo, el grupo desarrolló la primera transmisión de alta definición de tipo prototipo (DTTB) y fue para el cincuentavo aniversario del Día Nacional en China. En 2001 china realizó un llamado para la estandarización de la televisión digital entre los que se encontraban, DMBT (Digital Multimedia Broadcasting Terrestrial), ADBT (Advanced Digital Television Broadcasting Terrestrial) y TIMI (Terrestrial Interactive Multirervice Infraestructure). La norma fue definida finalmente en 2006 como DTMB y recibió la aprobación de la República Popular de China en Agosto de 2007.Comenzaron sus primeras transmisiones en Hong Kung el 31 de Diciembre de 2007. Todo ello estuvo a cargo de la Universidad de Jiaotong en Shanghai y la Universidad Tsinghua en Beijing, donde describieron el sistema como la fusión de varias tecnologías que incluyen las derivaciones de la norteamericana ATSC y la europea DVB-T.



29

Tema III

Middlewares para Interactividad con Televisión Digital

3.1. Middleware

Para la ejecución de aplicaciones interactivas en televisión Digital, es necesario el uso de un terminal de acceso conocido con el nombre de Set-Top-Box; este permite que los usuarios puedan controlar y manejar dichas aplicaciones.

Esto es posible gracias a la capa de software implementada en este terminal, permitiendo abstraer la complejidad del hardware, es aquí donde los componentes son los responsables de la ejecución de las aplicaciones, dibujarlas en la pantalla del televisor, gestionar los eventos capturados por ellos y supervisar todas las etapas de su ciclo de vida .

Por lo tanto el middleware es una capa intermedia o API genérico, que admite el acceso a las aplicaciones y servicios interactivos siempre que sea de la misma manera, independientemente de la plataforma de hardware o de software donde se están ejecutando.

Estructura general de un terminal de acceso



30

Hasta la actualidad, para evitar la proliferación de estándares se han creado varios tipos de middlewares para la Televisión Digital como el americano europeo y japonés, éstos han optado por un middleware estándar en sus receptores digitales. Son middlewares diferentes, aunque con características específicas, los cuales siguen las recomendaciones de la norma GEM(ITU-T J.201) (ITU-T, 2001).

3.1.1. Multimedia Home Platform.

Este middleware fue desarrollado para el estándar DVB y es adoptado por Europa. MHP proporciona un entorno para televisión interactiva, independientemente de hardware y software específicos, abiertos e interoperables para los receptores y decodificadores para TV Digital. Su entorno de ejecución está basado en el uso de una máquina virtual de Java y un conjunto de interfaces de programación (API). Estas API permiten a los programas escritos en Java el acceso a los recursos y las instalaciones del receptor digital de una manera estandarizada. A las aplicaciones DVB que usan el API de Java comúnmente se les llama aplicaciones DVB-J o Xlet.

Por lo tanto se pude decir que el núcleo de la norma MHP está basado en una plataforma conocida como DVB-J, que incluye la máquina virtual Java. Una entidad del software de sistema, denominada Gestor de Aplicaciones, la que se encarga de coordinar la ejecución de las aplicaciones y las comunicaciones con su entorno. Un conjunto de paquetes Java que proveen los interfaces entre las aplicaciones, las funciones de un receptor DVB y las redes de comunicación a las que está conectado. De igual forma, también se define en la norma, los formatos de los contenidos que el receptor debe poder gestionar, la torre de protocolos que debe implementar y la señalización adecuada para coordinar el correcto funcionamiento del conjunto.

Arquitectura de un receptor MHP

Con la aparición de nuevas redes de banda ancha y con el transcurso de los años, se ha realizado mejoras para este middleware, se ha llegado a crear versiones nuevas de MHP, cada una con nuevas características de interactividad para los usuarios. Las versiones generadas son MHP 1.0, MHP 1.1 y MHP 1.2, las innovaciones que presenta cada una de estos son los que se presentan en la siguiente figura.



31

Versiones de MHP

Las versiones de MHP, no son comunes entre ellas en lo referente al soporte de aplicaciones; el proyecto DVB introdujo el concepto de perfiles de soporte a la aplicación de las normas. Cada perfil hace referencia a áreas de aplicación especificas y define los requisitos necesarios que deben tener los STB. Los perfiles de soporte creados son: Enhanced Broadcast, Interactive Broadcast y el Internet Access.

El middleware MHP, además del uso del API de Java, posibilita usar lenguajes de programación semejantes al HTML (Utilizado para la programación de páginas web), a éste se le denomina DVB-HTML.

3.1.2. ARIB -Association of Radio Industries Businesses (ARIB)

El middleware de ISDB-T, está estandarizado por la organización japonesa ARIB, entidad que crea y mantiene el estándar de TV Digital ISDB-T .

ARIB ha definido dos estándares principales y cada uno tiene las normativas necesarias para regular, manejar y controlar este proceso, siendo éstas: ARIB STD-B24 y ARIB STD-23.

ARIB STD-B23: Se ha desarrollado en base al estándar DVB-MHP, que define una plataforma para el motor ejecutor de aplicaciones interactivas, ARIB STD-B23 busca establecer una base común entre los estándares MHP, ACAP y actualmente con GEM, encaminado para que en el futuro se pueda compartir información y ejecutar aplicaciones entre estos estándares.

ARIB STD-24: este estándar define un lenguaje declarativo BML, desarrollado por la propia ARIB. El lenguaje BML se basa en XML, y es utilizado para la especificación de los servicios multimedia interactivos .

El middleware ARIB consta de una arquitectura formada por dos partes: presentación y ejecución. El modelo de ejecución utiliza la máquina virtual Java para la interpretación de los bytecodes, que representan los procedimientos y/o funciones relacionadas con el contenido que se transmite. A su vez, la plantilla de presentación especifica la sintaxis del lenguaje de marcado BML, en el cual se incluye etiquetas y atributos utilizados para la autoría del contenido declarativo de TV Digital. La codificación BML se le define como un lenguaje que está basado en XML. La arquitectura del middleware japonés es la que se presenta en la Figura 1.8, aquí se muestra de forma separada, la parte responsable de la presentación y la parte responsable de la ejecución.



32

Arquitectura ARIB

3.1.3. DASE- DTV Applications Software Environment

Es el estándar americano, que fue desarrollado por el ATSC para la capa de middleware de set top boxes de TV Digital, inicialmente fue diseñado como DASE nivel 1, éste se limitaba a un nivel de interactividad local, porque no contemplaba la existencia de un canal de retorno. Actualmente existe la versión DASE nivel 3, que a más de contemplar sólo la interactividad, tiene la finalidad de integrar la televisión con el Internet, permitiendo ofrecer opciones de navegadores web y manejo de correo electrónico en el terminal de acceso . Las aplicaciones DASE pueden ser declarativas y de procedimiento. Las aplicaciones declarativas están representadas por documentos hipermedia y multimedia escritos por medio de un lenguaje de marcado basado en XHTML, de forma similar a MHP. En lo que se refiere a las aplicaciones de procedimiento utilizan una máquina virtual Java como un mecanismo que facilita la ejecución de instrucciones, igualmente de manera similar a MHP.

Cabe mencionar que una aplicación DASE no es exclusivamente declarativa o de procedimiento, en virtud que una aplicación de procedimiento puede hacer referencia a un contenido declarativo y viceversa. En la Figura siguiente se muestra la arquitectura general de DASE, en ésta, la capa superior representa las aplicaciones que pueden ser declarativas o de procedimiento.

Arquitectura DASE



33

El sistema DASE está formado por los módulos de Ambiente de Aplicación Declarativo o DAE y el Ambiente de Aplicación de Procedimiento o PAE. Un DAE es un subsistema lógico que procesa lenguajes de marcado, hojas de estilos y scripts. Su componente principal es el DCDE, cuya finalidad es hacer un análisis sintáctico del documento. Por otro lado, un PAE es el módulo encargado de procesar el contenido de los objetos activos o ejecutables, su componente principal es el PCDE, que por ejemplo, contiene la máquina virtual Java.

3.1.4. ACAP- Advanced Common Application Platform

Estándar creado por el Comité de Sistemas Avanzados de Television (ATSC), como base común para todos los sistemas de TV Digital interactivos de Estados Unidos, ya sean por cable, terrestres o por satélite; está basado en GEM y añade algunos elementos de OCAP que son adecuados para el mercado de USA. El estándar OCAP, desarrollado por CableLabs, se deriva de MHP, es adaptado a las características técnicas y de negocios de las empresas de difusión por cable en los Estados Unidos.

ACAP sigue las especificaciones del estándar GEM y utiliza el mismo conjunto de APIs de Java y el modelo de aplicación que se utiliza en MHP. Las diferencias entre MHP y ACAP, es que este último tiene obligado un canal de retorno, el soporte a las aplicaciones almacenadas y la versión del carrusel de objetos de DSM-CC. El estándar ACAP divide las aplicaciones en declarativas y de procedimiento. Las aplicaciones que tengan contenido sólo de procedimiento, que sean desarrolladas en Java y que permitan combinar gráficos, videos e imágenes, son denominadas aplicaciones ACAP-J; mientras que las aplicaciones declarativas se las conoce como ACAP-X, y son representadas por documentos multimedia escritos en un lenguaje de marcas como XHTML, reglas de estilo, scripts. Cabe mencionar que una aplicación ACAP, no tiene que ser completamente de procedimiento o declarativa, de ahí que una aplicación ACAP-J puede hacer referencia a un contenido declarativo, así como una aplicación ACAP-X puede hacer referencia a aplicaciones de procedimiento . En la siguiente figura se presenta la arquitectura del middleware ACAP, para los sistemas de aplicaciones declarativas y de procedimiento. El entorno ACAP-X, es responsable de interpretar el contenido de una aplicación declarativa ACAP, el entorno ACAP-J, es el responsable del tratamiento de los contenidos de procedimiento a través de la máquina virtual Java y de los APIs de extensión .

Arquitectura ACAP



34

3.1.5. GEM Globally Executable MHP

El estándar GEM es considerado como un estándar de armonización entre plataformas internacionales de middleware existentes, tales como CableLabs (EE.UU), ARIB (Japón), con la finalidad de que todas las aplicaciones puedan ser utilizadas y presentadas en los terminales de acceso de estos estándares. Por ello el grupo DVB decidió crear la especificación denominada GEM. La especificación GEM, formalmente no puede considerarse como una especificación completa para terminales de acceso, lo correcto es decir que GEM es un framework a partir del cual la implementación del middleware de un terminal de acceso puede ser instanciada, o todavía que GEM es un estándar al cual las implementaciones existentes deben ser adaptadas para obtener una conformidad que garantice la ejecución global de aplicaciones.

El GEM y su relación con los middlewares de otros estándares de TV Digital son los que se listan a continuación:

• Multimedia Home Platform (MHP), multiplataforma de middleware, desarrollada por el proyecto DVB.

• OpenCable Application Platform (OCAP), que es la capa de middleware de TV Digital para los sistemas de cable americanos.

• ARIB B.23, la especificación de la Asociación de Industrias y Negocios de radiodifusión de Japón.

• Advanced Common Application Platform (ACAP), el estándar de middleware de ATSC para televisión terrestre.

• BD-J, la plataforma Java para discos Blu-ray. Ginga-J, framework del middleware Brasileño.

Concepto de GEM.

3.1.6. Middleware Ginga

El middleware Ginga fue definido para el sistema brasileño de TV Digital, está basado en el estándar japonés.



35

Cuando se trabaja con un sistema complejo, como lo es la TV Digital interactiva, la mejor forma para entenderlo es a través de su arquitectura, que es la mejor manera de mostrar los principales elementos de un sistema, expresando claramente sus interacciones y ocultando los detalles menos importantes bajo el punto de vista adoptado. En la siguiente figura se muestra la arquitectura de TV Digital, incluido su middleware.

La idea central de la arquitectura en capas, consiste en que cada una ofrezca servicios para la capa superior y use los servicios ofrecidos por la inferior. De esta manera, las aplicaciones que se ejecutan en TV Digital interactiva usen la capa del middleware, que intermedia toda la comunicación entre las aplicaciones y el resto de los servicios ofrecidos por las capas inferiores .

Arquitectura en capas del estándar SBTVD.

Ginga es la capa de software intermedio (middleware), permite el desarrollo de aplicaciones interactivas para TV Digital, independientemente de la plataforma de hardware de fabricantes de terminales de acceso (STB) .

El middleware Ginga se divide en dos subsistemas interconectados, Ginga-J (para aplicaciones de procedimiento Java) y Ginga-NCL (para aplicaciones declarativas NCL). Dependiendo de la funcionalidad del diseño de cada aplicación, un paradigma de programación es más adecuado que el otro .

En particular, las aplicaciones declarativas frecuentemente hacen uso de scripts, cuyo contenido es de naturaleza procedural. En el middleware Ginga una aplicación declarativa puede hacer referencia a una aplicación procedural, de la misma manera, una aplicación procedural puede hacer referencia a una aplicación declarativa. Por lo tanto, ambos tipos de aplicaciones Ginga pueden utilizar los beneficios que brindan los ambientes para las aplicaciones declarativas o procedurales.

3.2. Arquitectura del middleware ginga

Este middleware está formado por un conjunto de tecnologías estandarizadas e innovaciones brasileñas que lo convierten en la especificación de middleware más avanzada y la mejor solución para las necesidades de TV Digital de Brasil y otros países que recién están iniciando en el mundo de la TV Digital.

Ginga a diferencia de los sistemas hipermedia convencionales, en donde prevalece el modelo de “servicio tipo pull”, aquí el navegador o programa intérprete solicita un nuevo documento y se procede con la búsqueda del contenido, como generalmente ocurre con



36

los navegadores web. En TV prevalece el modelo de “servicio tipo push”, en este caso el canal o emisora ofrece para la difusión flujos de audio, vídeo y datos multiplexados con otros datos, pudiendo ser recibidos algunos de ellos por demanda, pero siendo predominante el “tipo de servicio push”. Por lo tanto además de cambiar el drásticamente el paradigma de servicio, el usuario puede comenzar a ver un programa ya iniciado, cambiar de canal y consecuentemente salir y entrar en otros programas en curso.

Otro aspecto interesante, es que permite realizar la edición de documentos durante su exhibición en los programas en vivo y en programas modificados por retransmisoras.

La arquitectura del middleware Ginga, puede ser dividida en tres módulos: Ginga-CC (Common Core), el entorno de presentación Ginga-NCL (declarativo) y el entorno de ejecución Ginga-J (procedural). La arquitectura del middleware Ginga es la que se ilustra en la siguiente figura:

Arquitectura del middleware Ginga.

Ginga-NCL y Ginga-J tienen la característica de ser construidos sobre los servicios ofrecidos por el módulo de núcleo común (Ginga Common-Core), el Ginga CC está constituido por diversos módulos o componentes que facilitan la interacción del Hardware con las necesidades de las aplicaciones tanto declarativas como las de procedimiento. La composición de módulo común se muestra en la siguiente figura.



37

Ginga Common Core

Ginga-NCL fue desarrollado por la Pontificia Universidad Católica de Río de Janeiro (PUC), provee un entorno de presentación multimedia para aplicaciones declarativas escritas en el lenguaje NCL . Este lenguaje es una aplicación XML con facilidades para los aspectos de interactividad.

En síntesis Ginga-NCL, debe permitir el soporte a dos lenguajes procedurales, como LUA y JAVA. Lua es un lenguaje script de NCL diseñado para una programación procedimental con utilidades para la descripción de datos, brindando además soporte para la programación orientada a objetos, programación funcional y programación orientada a datos. Java debe tener las especificaciones de Ginga-J.

Ginga-J fue desarrollado por la Universidad Federal de Paraiba (UFPb), para proveer una infraestructura de ejecución de aplicaciones basadas en lenguaje Java, conocidas con el nombre de Xlet, con facilidades específicamente para el ambiente de interactividad en TV Digital.

Ginga-J es un subsistema lógico del Sistema Ginga que procesa aplicaciones procedimentales Xlets Java. El Xlets no necesita ser previamente almacenado en el STB, puede ser enviado por el canal de distribución. Es decir, el modelo Xlet se basa en la transferencia de código ejecutable por el canal de distribución para el STB y posterior carga y ejecución del mismo, de forma automática o manual.

3.2.1. Núcleo Común de Ginga (Ginga Common - Core)

Este subsistema es la interfaz directa con el sistema operativo, haciendo un puente estrecho con el hardware. El núcleo común de Ginga ofrece servicios tanto para el ambiente de presentación (declarativo) como para el de ejecución (procedimiento). Aquí es donde se accede al sintonizador de canales, sistema de archivos, entre otros.

Está formado por los decodificadores de contenido común, que sirven tanto a las aplicaciones de procedimiento como a las declarativas que necesiten decodificar y presentar tipos comunes de contenidos como PNG, JPEG, MPEG, etc; y por procedimientos para obtener contenidos transportados en flujo de transporte MPEG-2 y a través del canal de interactividad.

Los componentes básicos del Núcleo Común se describen a continuación:

• El sintonizador: Sintoniza 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 se utilizan los filtros de selección, que buscan en el flujo, la parte exacta que las APIs necesitan para su ejecución. Funciona como un filtro, sólo deja pasar la información que es



38

requerida por la API. • Procesador de Datos: Accede, procesa y transfiere los datos recibidos por la

capa física, además notifica a los otros componentes sobre cualquier evento que se ha recibido.

• Persistencia: Ginga es capaz de guardar archivos, incluso luego que haya finalizado el proceso que los creó, para que pueda ser abierto en otra ocasión.

• Administrador de Aplicaciones: Carga, configura, inicializa y ejecuta cualquier aplicación ya sea de un entorno declarativo o de procedimiento. También controla 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 éste las aplicaciones pueden ver el flujo de audio y video. 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.

• Administrador de Actualizaciones: Gestiona las actualizaciones del sistema, controlando, descargando las actualizaciones del middleware siempre que sea necesario para corregir los errores que puedan existir en versiones anteriores.

• Reproductor de archivos multimedia: Presentan los archivos multimedia recibidos, como por ejemplo archivos de tipo MPEG, JPEG, TXT, GIF, etc..

• Interface de usuario: Capta e interpreta los eventos generados por los usuarios, como por ejemplo comandos de control remoto; y notifica a los otros módulos interesados.

• Administrador de Contextos: Capta las preferencias del usuario, notificando a los otros componentes interesados esas preferencias, como por ejemplo horario en el que el usuario mira la TV o el bloquear o desbloquear canales.

• 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 transmisión en caso de que el usuario o una aplicación tengan definido un horario exacto.

• Acceso Condicional: Restringe contenidos inapropiados recibidos por los canales de programación, brindando así seguridad para el middleware.



39

Tema IV

Herramientas de Programación y Emulación

4.1. Ambientes de Programación

Ambientes de programación en el ámbito de las aplicaciones para la TV Digital, existen tres posibles clasificaciones para el tipo de ejecución del software:

• Procedural, necesita de una plataforma de ejecución (máquina virtual) y en el caso del middleware Ginga este módulo es denominado Ginga-J. Por utilizar el lenguaje de programación Java, posibilita que el programador sea capaz de establecer todo el flujo de control y ejecución de su programa;

• Declarativo, necesita de un Browser y se presenta semejante como una página HTML (HyperText Markup Language) que puede contener scripts y hojas de estilo. En el middleware Ginga, este módulo es se llama Ginga- NCL, que utiliza como base el lenguaje NCL, que define como una separación entre la estructura y el contenido. Generalmente las aplicaciones declarativas hacen uso de contenidos en script, que en el caso del NCL hay soporte del lenguaje Lua.

• Híbrido, representa la unión de los dos grupos, procedural y declarativo. Esta arquitectura se hace necesaria, pues las aplicaciones de TV Digital son usualmente desarrolladas utilizando estos dos paradigmas de programación. Sin embargo, estos ambientes de programación no están precisamente disjuntos, o sea, uno puede utilizar las facilidades del otro a través de las API contenidas en el middleware. Esta característica posibilita la creación de aplicaciones híbridas, que son soportadas por la arquitectura del Ginga.

4.2. Ambientes de emulación para la programación de Ginga

Las aplicaciones pueden ser desarrolladas por los canales de televisión como por los televidentes. En caso de ser desarrollada por una emisora de televisión, la aplicación será enviada al SetTopBox a través de un canal de transmisión. En el caso de ser desarrollado por un usuario ésta tendrá que ser enviado al SetTopBox a través de una entrada externa como un USB portable, puerta de red, tarjeta de memoria, etc.

Para un desarrollador de aplicaciones de televisión digital interactiva es difícil disponer de una red experimental para realizar las pruebas correspondientes de las mismas, en la mayoría de los casos el medio ambiente es simulado con el uso de estaciones de prueba o con emuladores de software. Para el desarrollo de aplicaciones interactivas existen varios emuladores, que simulan el papel del middleware; los más utilizados para el ambiente Ginga-J son: el XleTView y el OpenGinga y para el ambiente Ginga-NCL el Virtual SetTopBox y el Emulador.

4.2.1. Herramientas GINGA NCL.

Todas las herramientas exploradas en esta sección son gratuitas y de código abierto que evolucionan constantemente. El objetivo de utilizar las mismas para el desarrollo de aplicaciones interactivas Ginga-NCL en una PC es poder disponer de un entorno similar al middleware Ginga, que se encontrará habitualmente ya instalado en los receptores, pudiendo ser estos adaptadores Set Top Boxes o televisores integrados, obteniendo así una plataforma de simulación del funcionamiento real de dichas aplicaciones.



40

Hay dos formas de usar Ginga en una PC: realizando una instalación nativa o levantando una máquina virtual con Ginga pre-instalado. La diferencia entre las dos formas de ejecución se encuentra en que con una máquina virtual se puede simular un sistema mediante un software de virtualización dentro del sistema ya existente (Windows, Linux, MacOS), la ventaja de esta forma de ejecución es su facilidad para poner a funcionar el ambiente, pero presenta un inconveniente ya que es mucho más difícil manejar archivos entre dos sistemas operativos.

La instalación de forma nativa permite ejecutar Ginga en el sistema operativo existente, esta implementación mejora la velocidad de la PC, y ofrece una simplicidad en el manejo de archivos. La desventaja es que el proceso de instalación es mucho más complicado en relación al método de la máquina virtual ya que se requieren conocimientos de Linux y aún no posee automatización.

Para el desarrollo de aplicaciones interactivas Ginga-NCL se utilizan dos tipos de herramientas:

1. De desarrollo (Autoria) 2. De presentación o exhibicion

4.2.1.1. Herramientas de desarrollo (Autoria).

En la actualidad existe un gran número de herramientas para desarrollar aplicaciones interactivas en el entorno Ginga-NCL. Es posible crear programas interactivos en cualquier editor XML (puede usarse hasta el mismo bloc de notas). Esta sección se centrara en las herramientas de libre distribución, que soportan plataformas Windows y Linux, además de ser las más utilizadas para la generación de aplicaciones interactivas, diferenciándose entre sí por el nivel de conocimientos de programación que debe aplicarse para su manejo, además de la complejidad de la aplicación interactiva que se desea crear:

• NCL COMPOSER. Herramienta multiplataforma para el desarrollo de aplicaciones interactivas en NCL

• NCL ECLIPSE Plug-in para Suporte a NCL en ambiente Eclipse • NCL Validation Service: NCL-VS Herramienta para validacion de aplicaciones NCL • Framework RyF. framework para el desarrollo de aplicaciones Ginga NCL

• Composer.

Es una herramienta de software libre diseñada para la autoría hipermedia que facilita y agiliza la construcción de documentos NCL para TV digital interactiva, fue desarrollada por el Laboratorio de Telemidia del departamento de informática de la PUC-Rio. Es de edición gráfica, las abstracciones se definen en diversos tipos de visiones que permiten simular un tipo específico de edición, la versión actual de composer permite al usuario trabajar con 4 tipos de visiones:

• Visión Estructural (1) • Visión Temporal (2) • Visión Textual (3) • Visión de Diseño o Esquema (4)



41

La figura siguiente representa el entorno Composer en las diversas visiones en las que el usuario puede trabajar.

Herramientas de autoría Composer

Visión Estructural: Permite al usuario crear una estructura lógica de los aplicativos NCL, tiene sus objetos de multimedia conectadas entre sí por enlaces que responden a eventos y se asocia a los estados. El programador puede crear, editar y eliminar composiciones, objetos de medios y enlaces. En la siguiente figura, se muestra la visión estructural, donde se crean los nodos de media, enlaces y sus propiedades.

Visión Estructural

Visión Temporal: ilustra el sincronismo en el tiempo entre los nodos media y las oportunidades de interactividad. Esta visión establece relaciones temporales con anclas transitorias presentes en los medios (audio, vídeo e imágenes), que son las entidades claves para la presentación del documento en la línea del tiempo. La siguiente figura presenta la visión temporal de un documento hipermedia que exhibe una imagen iconeInteracao durante un determinado segmento de la presentación de la media videoPrinc.



42

Visión Temporal

Visión de Diseño o Esquema: permite la creación y configuración de zonas donde los medios serán presentados, facilitándole al autor crear, editar y eliminar algunas de ellas. Además permite crear sub-regiones o regiones superpuestas. Las regiones pueden ser definidas con un tamaño de pixel o de tamaños relativos o porcentaje con respecto a la pantalla completa. En la siguiente figura se muestra un ejemplo de la visión con dos regiones (rgVideo, rgTexto) creadas donde se presentaran los vídeos correspondientes.

Visión de Diseño o Esquema

Visión Textual: La vista textual, presenta el código NCL en sí, aquí el usuario puede crear directamente el código NCL como un editor de texto común. En la siguiente figura se observa la estructura del código NCL que está basado en el formato XML y también es considerado como un documento XHTML.

Estas visiones se sincronizan con el fin de ofrecer un entorno integrado de autoría, es



43

decir todas las secciones pueden ser editadas con actualización instantánea de las demás, por ejemplo una alteración en el código NCL es reflejada instantáneamente en la visión temporal, espacial y estructural del documento.

La presentación de diversas visiones fomenta a que el autor tenga una mayor intuición en el desenvolvimiento de las aplicaciones. En resumen, el sistema está diseñado para facilitar y acelerar la creación de aplicaciones interactivas centradas en la televisión digital, o al menos reducir parte de la complejidad de la programación en NCL a través de este medio ambiente de autoría que requiere un nivel de conocimientos del lenguaje NCL mínimo.

El entorno composer se encuentra todavía en la etapa de desarrollo y, como tal, es una herramienta muy inestable. Cuando se utiliza ésta es recomendable guardar el archivo del proyecto frecuentemente, ya que se han reportado problemas de deterioro del mismo. Además de esto, el composer no tiene soporte para todas las características de la norma ABNT NBR 15606-2 y utiliza Ginga Emulador para mostrar los documentos NCL, por lo tanto está sujeto a las mismas restricciones.

Otra de las deficiencias fundamentales del entorno composer es la falta de soporte para el lenguaje Lua, problemas con las disposiciones de los componentes de interfaz gráfica, poca especificación de los errores encontrados, poco poder de manipulación de los archivos del proyecto y bajo rendimiento.

El entorno composer es limitado y cuando se precisa desarrollar aplicaciones más complejas es necesario utilizar la herramienta Eclipse.

• Eclipse NCL.

Eclipse es un IDE de programación para desarrollar aplicaciones en varios lenguajes (C, java, php...). Esta plataforma es extremadamente modular ya que por medio de la adición de plugins se puede extender la funcionalidad, es decir provee la infraestructura para edición de productos a partir de estos. La característica fundamental que fomenta la adaptación de ésta a nuevos entornos de desarrollo es que posee una licencia de tipo EPL de código abierto que permite, usar, modificar, copiar y distribuir nuevas versiones del producto.

Para la creación del lenguaje NCL la Universidad Federal do Maranhão desarrollo NCL-Eclipse que es un editor XML/NCL creado como un plugin para la plataforma Eclipse, permite que todo este ambiente sea reutilizado y facilita la integración con otras herramientas de desenvolvimiento para la TV Digital, como, por ejemplo, Lua Eclipse.

Estos complementos auxilian y agilizan la creación de aplicaciones, permitiendo que facilidades extras de Eclipse sean reutilizadas e integradas con otras herramientas de desarrollo. De entre ellas se pueden citar:

• Soporte para navegación hipertextual. • Sugestion de parametros y auto-completar. • Sugestión en pop-up para selecionar archivos. • Cierre automático de los elementos. • Validación de la sintaxis y marcado de los errores en el documento. • Formateo e plantificación de código.



44

El NCL Eclipse reusa el NCL validator como un objetivo para idéntificar y marcar errores en documentos NCL, en tiempo de autoría. En la siguiente figura se muestra la pantalla de presentación del software Eclipse.

Pantalla de Eclipse

El entorno LuaEclipse es una colección de plugins desarrollados para Eclipse, que juntos forman un IDE para el desarrollo de aplicaciones Lua. Este entorno de programación, posibilita la edición scripts Lua con sintaxis resaltada, complementación código automático, recopilación de errores, la ejecución del script viene pre configurada, además de las herramientas disponibles para la plataforma Eclipse.

El principal objetivo del LuaEclipse es que las nuevas herramientas pueden ser desarrolladas a partir de la extensión de la arquitectura que forma la plataforma Eclipse y LuaEclipse, permitiendo la ampliación de sus capacidades.

Debido a la gran cantidad de desarrollo de plugins para Eclipse esta herramienta usualmente es utilizada como base para las demás soluciones que buscan facilitar el desarrollo de aplicaciones declarativas, ya que permiten la integración de lenguaje procedural al lenguaje declarativo NCL, convirtiéndose así en la herramienta con más potencia para el desarrollo de contenido interactivo en la actualidad.

• Framework RyF

RyF es un framework para el desarrollo de aplicaciones Ginga NCL que esta escrito en lua. El mismo se basa en la idea que las aplicaciones tienen stages y que dentro de cada stage se utilizan diferentes de "widgets". RyF trabaja con los modulos accesibles por programas lua según la especificación de Ginga, esto incluye el canvas, timers, sockets y otros.



45

4.2.1.2. Herramientas de presentación

Para la visualización de las aplicaciones en entorno Ginga-NCL, existen varios aplicativos más usados:

• GINGA-NCL VIRTUAL STB Maquina virtual Linux para VMWare, conteniendo Ginga-NCL C++ v. 0.12.4 (Universidad PUC-Rio) http://ncl.org.br/pt-br/ferramentas

• Ginga.ar Exhibidor Ginga (LIFIA - Universidad de La Plata) http://tvd.lifia.info.unlp.edu.ar/ginga.ar/index.php/download

• CHROME PLUGIN (En fase de pruebas) • FIREFOX PLUGIN (En fase de pruebas) • Ginga4Linux Paquetes binarios para Linux de implementación de Referencia ITU-

T de Ginga • Ginga4Windows Implementación de Referencia ITU-T de Exhibidor Ginga, con

interface gráfica para Windows.

• Emulador Ginga-NCL

Este software es la herramienta más fácil de usar y más accesible, por medio de ésta es posible abrir un archivo NCL, ejecutar acciones mediante el control remoto interactivo que es activado con el mouse. Para que el emulador pueda funcionar es necesario tener instalada la Máquina Virtual de Java (JVM), ya que está desarrollado sobre la misma, sin embargo por estar basada en Java posee una serie de limitaciones. Las principales son:

• La secuencia de los vídeos no es lineal. Cuando uno de estos se ve afectado del bucle o cuando varios de estos están vinculados, se ha producido una caída en la secuencia de los vídeos, ya que en la última parte del primero no se encuentra conectado perfectamente al primer fotograma del siguiente.

• No hay soporte para la transparencia. Algunas interfaces pueden ser desarrollados en software como Adobe Photoshop o GIMP y se guardan en el formato PNG, con niveles de transparencia. Estos parecen chapados, de color gris, en el emulador.

Además, el emulador no posee soporte para el lenguaje Lua.

El emulador de Ginga NCL está incrustado en la herramienta composer y puede ser instalado como plugin de Eclipse IDE, que facilita el desarrollo y prueba de aplicaciones.

• Virtual SetTopBox.

El Virtual SetTopBox (VSTB) es una implementación C++ del middleware Ginga emulada en una máquina virtual para VMWare que posee instalada una imagen de Fedora Linux. El VSTB simula fielmente el ambiente de presentación de aplicaciones declarativas, posee un mejor rendimiento y un entorno más parecido a una aplicación incrustado en las STB, que el que es producido por el emulador.

La máquina virtual de ubuntu-server10.10-ginga-i386 fue creado y configurado por el personal del Laboratorio de la PUC-Río de software TELEMIDIA utilizando VMWare Workstation 7. La instalación ha sido optimizada para incluir solamente los paquetes de software esenciales para el desarrollo del middleware Ginga y la ejecución de Ginga-NCL versión C++. Para ejecutar una aplicación sobre el VSTB, se debe abrir una conexión utilizando el protocolo SSH, por medio de un software de acceso remoto.



46

Como se muestra en la siguiente figura, después de cargar la imagen se tiene el VSTB listo para ser utilizado.

Los principales paquetes de software están instalados en la VSTB son: gingancl cpp-0.12.1Lua 5.1 / 2.0.2 luasocketkernel 2.6.35 cadena de herramientas GNU (gcc 4.4.4, glibc 2.12 a 1) directfb 1.4.11fusionsound 1.1.1 xine-lib 1.1.17

Ginga-NCL Emulator

Esta herramienta posee suporte de ejecución de los script en LUA y soporte a la transparencia. La máquina virtual tradicional está limitado a la resolución 640x480, lo cual impide probar sus aplicaciones para la alta definición, pero la nueva version ofrece ahora la posibilidad de elegir la resolución de la pantalla entre 6 opciones preconfiguradas. La elección de la misma se hace en el momento del arranque de la máquina virtual y debe decidirse en el segun la capacidad de procesamiento del CPU host de la estación receptora. La virtualización de las aplicaciones en VSTB es un poco mas demorada que en el emulador para Windows, pero su funcionamiento es muy superior.

Ginga-NCL VSTB



47

4.2.2. Herramientas GINGA Java.

4.2.2.1. Emulador Ginga-J: XleTView.

Este emulador es de código abierto y está bajo la licencia de software libre GPL (General Public License), es usado para ejecutar Xlets en una PC. Tiene una implementación de referencia a la API JavaTV, pero además trae consigo implementaciones de otras APIs especificadas en el estándar MHP, como HAVI, DAVIC e implementaciones especificaciones por la propia DVB, además de las bibliotecas de PersonalJava. La pantalla de ejecución del emulador se puede ver en la siguiente figura.

Interface del emulador XletView

XleTView, está desarrollado en Java y para su ejecución independientemente del sistema operativo, es necesario utilizar el Java 2 Estándar Development Kit para compilar Xlets y ejecutar el XletView.

4.2.2.2. Emulador Ginga-J: OPENGINGA.

Openginga es un proyecto open source que está siendo desarrollado por el laboratorio LAVID de la Universidad Federal de Paraiba.

En la actualidad existe la máquina virtual con el sistema operativo Ubuntu 10.04 el cual tiene la implementación del emulador Open Ginga. La pantalla de ejecución del emulador OpenGinga se muestra en la Figura OpenGinga.

Pantalla del emulador OpenGinga



48

Tema V

Desarrollo de Aplicaciones Declarativas (Ginga-NCL)

5.1. Modelo de contexto anidado (NCM)

NCM es un modelo conceptual, se centra en la representación y manipulación de documentos hipermedia. El modelo también debe definir las reglas que estructuran y las operaciones en los datos de la manipulación y la actualización de las estructuras.

Un documento hipermedia está compuesta por nodos y enlaces (links), donde cada nodo representa una media y cada enlace representa una relación entre medias, sin embargo, los enlaces no son la única entidad disponible para la definición de las relaciones. Un ejemplo para la mejor compresión es que en un determinado momento de la representación de una media otra debe ser inicializada, es decir que, los enlaces hacen el espacio de sincronización de tiempo entre los puntos que componen el documento.

Nodos y enlaces de un documento hipermedia común.

NCM va más allá de un documento hipermedia tradicional, ya que los gráficos se pueden anidar, lo que permite segmentación y la estructuración hipermedia como sea necesario o deseado, por lo que se extiende los conceptos sobre el aumento de la potencia y flexibilidad de un documento hipermedia.

Esto se hace a través de nodos de composición o también llamados de contexto, todo nodo media está definido dentro de un contexto, un ejemplo de estos se muestran en la siguiente figura:

Nodos, enlaces y nodos de composición (contexto).

NCM es el modelo subyacente al NCL, un idioma de aplicación de XML para la creación de documentos hipermedia. En NCM se extiende la definición de nodos en dos tipos, de contenido y nodos de composición.



49

Un nodo de contenido aporta información sobre una media usada por el documento, este es asociado a un elemento de media tales como vídeo, audio, imagen, texto, aplicación, etc.

Nodo de composición contiene otros nodos de composición y un conjunto de ellos, siendo utilizados para dar estructura y organización de un documento hipermedia.

Para facilitar la elaboración de un documento hipermedia siguiendo el modelo NCM se desarrolló el lenguaje NCL, que es el lenguaje de programación sobre el que se basa el presente capitulo.

5.2. Estructura de un documento Hipermedia.

Sobre la construcción de un documento hipermedia, algunas informaciones básicas son necesarias como se muestra en la siguiente figura.

Estructura de un documento hipermedia

5.2.1. ¿Qué vamos a mostrar? - Objetos Hipermedia (Media)

Al comenzar a diseñar un programa es el contenido audiovisual interactivo lo primero que se escoge; que vídeos, imágenes, textos y otros medios será presentados por el programa, este contenido esta representado por los nodos de media. Una media representa cada nodo de un documento que informa el descriptor cual está relacionado.

De acuerdo con el NCM, una media debe estar necesariamente dentro de un nodo de composición, llamada contexto, que es usado para representar un documento o parte de él. En NCL, el elemento body es el contexto que contiene todos los nodos del documento hipermedia, sean estos de media o de contextos.

La siguiente figura muestra el concepto de media y contextos, con cuatro nodos multimedia, tres de los cuales están dentro de un contexto (ctx1) anidado al cuerpo (body).



50

Representación de nodos multimedia y su composición

5.2.2. ¿Dónde los vamos a mostrar? - Regiones

Después de definir el contenido multimedia del programa, se debe definir el área en donde se va a mostrar cada elemento en la pantalla, por medio de elementos llamados regiones. Una región representa la posición y tamaño de la zona donde ciertos objetos media serán visualizados, es decir una región sirve para inicializar la posición de los medios en una ubicación específica.

Aunque una región representa el lugar en donde se podría presentar un nodo media, ésta no indica que nodo media será presentado en dicha región, esta asociación se realiza por medio de un descriptor.

Representación de una región

5.2.3. ¿Cómo los vamos a mostrar? - Descriptores.

La definición de una región debe ser complementada con otra información que indique cómo cada nodo será presentado. Esta descripción de las características de cada nodo se realiza a través de los elementos llamados descriptores. Un descriptor puede detallar parámetros de representación de los nodos, incluyendo a la región donde tendrá lugar la presentación de su volumen, su transparencia, y el tiempo de duración, entre otros.

Cuando se define un descriptor, es necesario definir la región a la que se asocia. Todos los medios que utilizan éste son asociados a la región correspondiente.



51

Representación de un descriptor

5.2.4. ¿Cuándo los vamos a mostrar? - Links y Conectores

Una vez que se hayan seleccionado los nodos que formaran parte del documento hipermedia, se hace necesario definir cuál será el primer nodo en ser presentado y el orden de ejecución de los demás. Está definición se hace con el elemento llamado puerto, estos definen los nodos que serán presentados cuando un nodo de contexto iniciara. Si hay más de un puerto en el contexto cuerpo, se abren todos en paralelo.

Los puertos son necesarios para dar acceso a los nodos (sean de media o de contexto) internos para cualquier contexto y no sólo al cuerpo. En la siguiente figura, el nodo video1 del contexto ctx1 sólo puede ser accedido fuera del contexto ctx1, a través de la puerta pVideo1, mientras que los nodos audio1 e imagen1 no pueden ser ingresados fuera del contexto ctx1.

Puertos de un nodo de composición

Los links no definen todas las relaciones de sincronización entre los nodos y la interactividad del programa, para eso requiere el uso de conectores.

5.3. Lenguaje de marcado extensible (XML).

Creado por el W3C a mediados de la década de 1990, el idioma XML es un formato textual simple y bastante flexible diseñado para estructurar, almacenar y representar información. Cómo XML no fue diseñado para una aplicación específica, puede ser



52

utilizado como una base (metalenguaje) para el desarrollo de lenguajes de marcado. En XML los documentos están organizados jerárquicamente en forma de árbol, donde cada elemento tiene un elemento principal y elementos secundarios. Esta estructura se asemeja a la distribución de un árbol genealógico de una familia donde cada uno sería un elemento XML, es decir posee una identificación y atributos.

En la definición del patrón textual XML de un elemento se inicia con el símbolo "<" y termina por medio de símbolos "/>", más la repetición del nombre entre los símbolos de terminación. Entre estos dos símbolos se definen el nombre del elemento y los atributos del mismo. Los atributos de un elemento XML se definen por un par (nombre, valor), el valor de cada atributo se indica después del símbolo "=" y entre comillas. Cabe señalar que el nombre del elemento, así como sus atributos, no tiene letras mayúsculas o acentos, esta es una buena práctica para evitar la aparición de errores en el uso de documento, ya que XML es sensitivo entre mayúsculas y minúsculas. Uno de los elementos, puede poseer otros elementos como hijos.

5.3.1. NCL (Nested Contrext Language)

NCL es un lenguaje declarativo XML basado en el modelo conceptual NCM. Además NCL tiene la facilidad para especificar los aspectos de la interactividad, en tiempo-espacio entre los objetos de medias, posee adaptabilidad, soporte a múltiples dispositivos y producción en vivo de programas interactivos no lineales. Tiene la ventaja adicional en el uso del lenguaje de script Lua, para la manipulación de sus variables, mediante la adopción del paradigma imperativo, siendo eficiente, rápido y ligero y diseñado para extender las aplicaciones.

Cada nodo posee un identificador, un contenido y un conjunto de anclas (sub- conjunto de unidades de información de un nodo).

Entidades básicas del modelo NCM

NCL a diferencia de XHTML o HTML tiene una separación estricta entre el contenido y la estructura de un documento, por lo tanto es una aplicación de TVD que puede ser generada o modificada en vivo, permitiendo definir objetos de media estructurados y relacionados tanto en tiempo y espacio. Los componentes de este subsistema se



53

muestran en la siguiente figura.

Subsistema Ginga-NCL

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

• Formateador (Formatter): recibe y controla las aplicaciones multimedias escritas en NCL, siendo éstas entregadas por el Ginga-CC.

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

• Programador (Scheduler): organiza 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:

o 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.

o 2do Grupo de Comandos, responsable de iniciar, pausar, resumir, detener, remover las aplicaciones NCL.

o 3er Grupo de Comandos, responsable de la actualización de aplicaciones en tiempo 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.

NCL no define ninguno de los archivos media en sí, por el contrario, especifica la ligadura que mantiene juntos las medias como en una presentación multimedia. Por lo tanto, un documento NCL sólo puntualiza cómo los objetos de las medias están estructurados y relacionados en tiempo y espacio. Como un lenguaje de pegamento, no restringe o prescribe el contenido de los objetos media. Entre los tipos de media usuales que soporta están los siguientes:



54

o Vídeo (MPEG, MOV, etc.) o Audio (MP3, WMA, etc.) o Imagen (GIF, JPEG, etc.) o Texto (TXT, PDF, etc.) o HTML o scripts LUA.

Ginga-NCL, debe ofrecer soporte a dos lenguajes procedurales, como son LUA y JAVA. Lua es el lenguaje script de NCL, y Java debe seguir las especificaciones de Ginga-J. Además de los formatos antes mencionados, Ginga-NCL también ofrece apoyo a los objetos de medias basados en XHTML, donde es tratado como un caso especial. De esta manera, NCL no reemplaza el XHTML, sino que los complementa. Los objetos basados en XHTML que apoyará la NCL varían dependiendo de la aplicación y el navegador incrustado en el formateador NCL. Según la ABNTNBR 15606-2 y ABNT NBR 15606 -5, se define como obligatoria sólo un conjunto de funcionalidades para XHTML y sus tecnologías resultantes, el resto de las funciones son opcionales. El ambiente declarativo es en sí muy limitado. Las aplicaciones que utilicen éste deben tener su enfoque sobre el sincronismo, siendo el foco del lenguaje NCL exactamente eso, no la interactividad, ya que la interacción es tratada como resultado de la sincronización.

5.3.2. Lua.

Desde sus inicios Lua fue diseñado para ser utilizado en conjunto con otros lenguajes, no es muy común que un programa sea escrito puramente en éste. Este lenguaje permite que una aplicación principal pueda ser ampliada o adaptada a través de scripts. Lua es un lenguaje que combina sintaxis procedural con declarativa, con pocos comandos primitivos. Por lo tanto, comparado con otros lenguajes, posee implementación ligera y extensible. Otra de las características es que posee un Garbage-collection, un sistema dinámico de tipos y un alto grado de portabilidad, pudiendo ser ejecutada en diversas plataformas, tales como computadores personales, celulares, consolas de videojuego, etc. El nombre del lenguaje, Lua, se remite a la idea de un lenguaje satélite.

Siendo un lenguaje de extensión, Lua no tiene noción del programa principal (main): sólo funciona como una extensión en un cliente anfitrión, denominado programa contenedor o simplemente anfitrión (host) que invoca funciones para ejecutar un segmento de código Lua, puede escribir y leer variables de Lua y puede registrar funciones C para que sean llamadas por el código Lua.

Las características de Lua aparte de su alto rendimiento, bajo consumo de recursos, simplicidad, eficiencia, portabilidad, además de su licencia libre de royalties que reduce el costo a cero de la adopción del interpretador por unidad producida, combinan a la perfección con el escenario de la TV Digital. La portabilidad es importante cuando el middleware sea desarrollado para dispositivos con características contradictorias como la telefonía celular y SetTopBoxes.

5.3.2.1. Extensiones de NCLua

Lua es el lenguaje de script adoptado por el módulo Ginga-NCL para implementar objetos imperativos en documentos NCL que son puramente declarativos.



55

Para adecuar al ambiente de la televisión digital y que se integre a NCL, el lenguaje Lua se fue ampliando con nuevas funcionalidades generando así el plugin NCLua. Por ejemplo, este plugin necesita comunicarse con el documento NCL para saber cuándo su objeto <media> correspondiente es iniciado por un enlace. Un NCLua también puede responder a las claves en el control remoto, y realizar las operaciones dibujo o escritura libremente dentro de la región NCL que le está destinado. Estas características no son específicas del idioma NCL, por lo que no son parte de la biblioteca patrón. Lo que diferencia un NCLua de un programa Lua puro es el hecho de que es controlada por el documento NCL en la cual se inserta, y utilizar las extensiones descritas a continuación.

Además de la biblioteca estándar de Lua, cinco nuevos módulos están disponibles para los scripts NCLua:

Módulo NCLEdit: permite que scripts Lua manipulen objetos declarativos de documentos NCL, adicionando, modificando e removiendo informaciones; Módulo event: permite que objetos NCLua puedan comunicarse con el documento NCL y otras entidades externas (tales como control remoto y el canal de interactividad), a través de eventos de una forma asíncrona. Módulo canvas: ofrece elementos (API) para diseñar objetos gráficos en la región de NCLua. Módulo settings: exporta una tabla con variables definidas por el autor del documento NCL en variables de ambiente reservadas, contenidas en el nodo application/x-ginga-settings. Módulo persistent: exporta un cuadro con las variables persistentes entre ejecuciones de objetos imperativos, estos datos están guardados en un área restringida del middleware.

La norma ABNT NBR 15606-2:2007 y H. 761 lista en detalle todas las funciones soportadas por cada módulo.

Las siguientes funciones de la biblioteca de Lua son dependientes de la plataforma y por lo tanto no están disponibles para los scripts NCLua:

o En el módulo paquete: la función loadlib. o En el módulo io: todas las funciones. o En el módulo os: las funciones reloj, ejecutar, salida, getenv, quitar, cambiar tmpname

y setlocale. o En el módulo debug: todas las funciones.

5.4. Estructura de un documento NCL.

Todo contenido de un documento NCL está definido dentro del elemento <ncl> siendo su estructura dividida en dos grandes partes, la cabecera (head) y el cuerpo del texto (body).

o Archivo de encabezado NCL (líneas 1 y 2); o Una sección del encabezado (sección head, las líneas 3 a 13), que define las

regiones, los descriptores, los conectores y las reglas utilizadas por el programa; o El cuerpo del programa (sección body, líneas 14 a 17), donde se definen los

contextos, en los nodos de media, enlaces y otros elementos que describen el contenido y la estructura del programa;

o Al menos una de las puertas que indica dónde el programa comienza a ser exhibido



56

(puerto pInicio, línea 15); y o La terminación del documento (línea 18).

Estructura Básica de un documento NCL

El cuadro anterior presenta la estructura básica de un documento NCL.En un documento NCL se debe incluir obligatoriamente las instrucciones de procesamiento, es decir el encabezado básico del programa. Éstas identifican documentos NCL que contengan sólo los elementos definidos en esta Norma, y la versión NCL con la cual el documento está de acuerdo.

<?xml versión="1.0" encoding="ISO-8859-1 "?> <ncl id="qualquer string" xmlns="http://www.ncl.org.br/NCL3.0/profileName">

El atributo id del elemento <ncl> puede recibir cualquier cadena de caracteres como valor. El número de versión de una especificación NCL consiste en un número principal y otro secundario separados por un punto. Los números son representados como una cadena de caracteres formada por números decimales, en la cual los ceros a la izquierda se suprimen. El número de versión inicial del estándar es 3.0.

Generalmente, los pasos para construir un documento NCL deben definir: 1) Los encabezados básicos del archivo NCL y del Programa; 2) Las regiones de la pantalla en donde se presentaran los elementos visuales

(región Base); 3) Como y donde los nodos multimedia serán presentados, a través de descriptores

(descriptorBase); 4) El contenido (nodos multimedia - media) y la estructura (contextos - contex) del

documento (sección body), asociados a los descriptores;



57

5) La puerta de entrada al programa, apuntando al primer nodo que va a ser presentado, así como las puertas para los contextos, con el propósito de desarrollar enlaces entre contextos y nodos multimedia (port);

6) Anclas para los nodos multimedia, con el propósito de construir los enlaces entre nodos multimedia (area y atributte);

7) Enlaces para el sincronismo e interactividad entre los nodos multimedia y contextos (link); y

8) Los conectores que especifica el comportamiento de los enlaces del documento (connectorBase).

5.4.1. Regiones

Una región (region) se define como un área en el dispositivo de salida, donde un nodo multimedia puede ser presentado. Para organizar el diseño de las distintas partes del documento hipermedia, las regiones pueden estar anidadas. En NCL, las regiones son definidas en el encabezado de programa (<head>), en la sección de las regiones base (<regionBase>).

Todo documento NCL posee por lo menos una región, que define la dimensión y las características del dispositivo donde uno o más nodos multimedia serán presentados. Una región sirve para analizar la posición de los nodos multimedia en un lugar específico.

Por ejemplo si creamos dos regiones, a la primera la denominaremos rgTV, en la que definiremos las dimensiones de la pantalla de la TV, y la segunda rgVideo1, que no servirá para presentar un video en un lugar específico de la TV (asumiendo que las dimensiones del televisor son 1024x576 pixeles y vamos a reproducir un video de 640x480 pixeles de dimensión):

<region id="rgTV" width="1024" height="576"> <region id="rgVideo1" left="192" top="48" width="640" height="480" />

</region>

En NCL, para una región se definen los siguientes atributos:

• id*: es el identificador único, utilizado para referenciar una región (por ejemplo, los descriptores de los archivos multimedia que serán representados en la región).

• title (título): Es el título de una región. En caso de ser una región exhibida como una moldura, este título será el que aparece como titulo de la ventana correspondiente.

• left (izquierda): Hace referencia a la coordenada “x” del lado izquierdo de la región, con relación a la coordenada del lado izquierdo de la región principal (o al borde exterior de la pantalla, en caso de que la región no esté anidada a ninguna otra).

• top (tope): Hace referencia a la coordenada “y” del lado superior de la región, con relación a la coordenada del lado superior de la región (o al borde exterior de la pantalla, en caso de que la región no esté anidada a ninguna otra).

• right (derecha): Hace referencia a la coordenada “x” del lado derecho de la región, con relación al lado derecho de la región principal (o al borde exterior de la pantalla, en caso de que la región no esté anidada a ninguna otra).



58

• bottom (base): Hace referencia a la coordenada “y” del lado inferior de la región, con relación al lado inferior de la región principal (o al borde exterior de la pantalla, en caso de que la región no esté anidada a ninguna otra).

• width (anchura) y height (altura): Son las dimensiones horizontal y vertical de una región. Cabe observar que como autor se puede especificar las dimensiones de una región según su conveniencia. Por ejemplo, en ciertos casos puede ser mejor definir los atributos rigth, bottom, width y height. En otros casos, puede ser más apropiado especificar los atributos top, left, width y heigth

• zIndex: Indica la posición de una región en el eje “z” y es utilizado generalmente para indicar, en el caso de existir regiones sobrepuestas, que región se presenta sobre las otras. Las capas con índice mayor serán presentadas sobre las capas de índice menor. En la siguiente figura se ilustra los atributos top, left, right, bottom, width, height e zIndex:

Es importante señalar que si todos los atributos de posición y el tamaño se especifican, los atributos left (izquierda) y width (ancho) tienen prioridad sobre el atributo right (derecho), así como los atributos top (superior) y height (altura) tienen prioridad sobre el atributo bottom (fondo).

Por otra parte, cuando dos o más regiones tienen el mismo valor zIndex, y en cada región que se presenta un archivo multimedia, existen dos posibilidades: el caso que un archivo multimedia sea presentado antes que otro, un archivo multimedia que se ha iniciado después se va a sobreponer a la que fue iniciada anteriormente (orden temporal). En caso de que los dos archivos multimedia sean iniciados al mismo tiempo, el orden será seleccionado aleatoriamente por el programa interprete.

La base de regiones posee los siguientes atributos:

• id: identificador único de la base de regiones. • device: Define el dispositivo al cual la región está asociada. Puede ser de la

forma systemScreen(i), systemAudio(i), de acuerdo a los dispositivos disponibles.

5.4.2. Descriptores

Un descriptor es el elemento encargado de definir como será presentado un nodo multimedia, asociándolo a una región (region). En NCL, todos los descriptores deben ser definidos en el encabezado del programa (<head>), en la sección llamada base de descriptores (<descriptorBase>). Por lo tanto, todo nodo multimedia que será presentado,



59

debe tener asociado un descriptor.

En NCL se definen los siguientes atributos para un descriptor:

• id*: identificador único, empleado en las referencias de un descriptor (por ejemplo, los archivos multimedia/contenidos presentados por el descriptor).

• player: identifica la herramienta de presentación que se empleara para mostrar el objeto multimedia asociado al descriptor. Este atributo es opcional. Cuando se omite, el programa interprete procura buscar esta herramienta por defecto en función al tipo de objeto multimedia.

• explicitDur: determina la duración ideal de un objeto multimedia asociado a un descriptor. El valor de este atributo debe ser expresado en segundos, escribiendo primero el valor numérico seguido de la letra “s” (por ejemplo, 9.9s). Cuando el atributo explicitDur no se especifica, el objeto multimedia asociado a este descriptor será presentado con su duración por defecto. Los archivos multimedia como textos e imágenes estáticas poseen una duración infinita por defecto. Para el programa interprete, este atributo no se considera para archivos multimedia continuos; en un programa interprete con soporte de ajuste elástico del tiempo, el valor de ese atributo es usado como referencia para modificar el tiempo de duración del nodo (permitiendo, por ejemplo, que algunos cuadros de un video de 30s dejen de ser exhibidos para que solo dure 29s).

• region: Identifica la región asociada a un descriptor. Al utilizar un descriptor, el objeto multimedia será presentado en su región correspondiente. Este atributo solo precisa ser especificado para objetos que poseen un contenido visual a ser presentado.

• freeze: identifica lo que sucede después de la presentación del objeto multimedia asociado a un descriptor. En un video, el valor “true” indica que el último cuadro debe ser congelado.

• focusIndex: define un índice de navegación para un objeto multimedia asociado a un descriptor. En el caso de no ser definido un índice, el objeto multimedia no podrá recibir el foco de navegación. En un objeto, el foco inicial estará con el menor focusIndex. Cabe observar que el valor que se le asigna a un focusIndex no es necesariamente un número y en ese caso, “menor” significa lexicográficamente menor.

• focusBorderColor: define el color del rectángulo que debe aparecer sobrepuesto en la región de este descriptor cuando el objeto a él asociado recibe el foco. Puede ser uno de los siguientes valores: white, black, silver, gray, red, maroon, fuchsia, purple, lime, green, yellow, olive, blue, navy, aqua,o teal.

• focusBorderWidth: define el espesor en pixeles del rectángulo que debe aparecer sobrepuesto a la región de este descriptor cuando el elemento a él asociado recibe un foco. En caso de que este sea igual a 0, ningún borde será presentado. Un valor positivo indica que el borde estará fuera del contenido del objeto, mientras que un valor negativo indica que el borde se formara sobre el contenido del objeto.

• focusBorderTransparency: define el porcentaje de transparencia de un borde. Este recibe un valor real entre 0 y 1, donde 0 significa totalmente opaco y 1 significa totalmente transparente.

• focusSrc: define un archivo multimedia alternativo que debe ser presentado cuando el elemento asociado a este descriptor esté con el foco.

• focusSelSrc: define un archivo multimedia alternativo que debe ser presentad



60

cuando es presionado el botón “Ok” o “Enter” mientras el elemento asociado a este descriptor esté con el foco.

• selBorderColor: define un color de borde que debe ser exhibido cuando sea presionado el botón “Ok” o “Enter” mientras el elemento asociado a este descriptor ande con el foco.

• moveLeft: identifica el índice de navegación del elemento E que debe recibir el foco si es presionada la flecha para la izquierda del control remoto mientras el elemento asociado a este descriptor esté con el foco (definido por el atributo focusIndex del elemento E).

• moveRight: identifica el índice de navegación del elemento E que debe recibir el foco si es presionada la flecha para la derecha del control remoto mientras el elemento asociado a este descriptor esté con el foco (definido por el atributo focusIndex del elemento E)

• moveUp: identifica el índice de navegación del elemento E que debe recibir el foco si es presionada la flecha para arriba del control remoto mientras el elemento asociado a este descriptor esté con el foco (definido por el atributo focusIndex del elemento E).

• moveDown: identifica el índice de navegación del elemento E que debe recibir el foco si es presionada la flecha para abajo del control remoto mientras el elemento asociado a este descriptor esté con el foco (definido por el atributo focusIndex del elemento E).

• transIn: define la transición que será ejecutada al iniciar la presentación del objeto multimedia.

• transOut: define la transición que será ejecutada al terminar la presentación del objeto multimedia.

En NCL se define aún el siguiente elemento opcional contenido en un elemento descriptor:

• descriptorParam: define un parámetro del descriptor como un par <propiedad,valor>. Las propiedades y sus respectivos valores dependen del programa de presentación del archivo multimedia asociado al descriptor.

Cada descriptor puede contener diversos elementos descriptorParam, definidos en el formato:

<descriptorParam name="nome_do_parametro" value="valor_do_parametro" />

Para indicar que archivo multimedia correspondiente debe ser reproducido con un volumen del 90% del máximo:

<descriptor id="dVideo1" region="rgVideo1"> <descriptorParam name="soundLevel" value="0.9" /> </descriptor>

El uso de parámetros de un descriptor promueve un alto grado de flexibilidad. Le corresponde a cada programa de presentación de objetos multimedia (player) interpretar esas propiedades de la forma adecuada. Actualmente, no se puede definir parámetros de un descriptor en el Composer. En NCL, están reservados los parámetros que se



61

describen en la siguiente tabla:



62

Los descriptores no aparecen en las visiones estructural, de disposición o temporal en el Composer. Para verificar si un descriptor fue creado correctamente, se debe consultar la visión textual.

5.4.3. Nodo Multimedia (o Nodo de Contenido)

Un nodo multimedia o de contenido (media node o content node) define el objeto multimedia propiamente dicho: video, audio, texto, etc. Cada definición de un nodo multimedia debe presentar, además del archivo de origen, el descriptor que regulará la presentación de un objeto específico.

Un nodo multimedia posee los siguientes atributos:

• Id: identificador único del nodo multimedia, empleado para hacer referencia al nodo (por ejemplo, en las puertas de los nodos de contexto que se dirigen hacia los archivos multimedia)

• Type: tipo de archivo multimedia, especificado como MIME, según la siguiente tabla:



63

• Src: fuente del objeto multimedia. Se trata del camino para el archivo multimedia. Ese camino pude ser relativo, a partir del directorio donde se encuentra el archivo NCL, o absoluto, a través de una URI. Las URI válidas son las que se presentan en la siguiente tabla:

• Descriptor: identificador del descriptor que controla la presentación del objeto multimedia.

• Refer: referencia a otro nodo multimedia previamente definido, como forma de reutilización de nodo (utiliza los atributos del nodo multimedia referenciado, excepto el id)



64

• newInstance: establece si un nodo que se refiere a otro genera una nueva instancia del objeto en el programa intérprete o se reutiliza la instancia previamente creada.

5.4.4. Contextos

El elemento body es un caso particular de contexto, representando el documento como un todo. Los Contextos o nodos de composición son utilizados para estructurar un documento hipermedia, los mismos que pueden ser anidados, con el objetivo de reflejar la estructura del documento y ayudarle al autor a organizar de mejor manera los segmentos del programa audiovisual interactivo. Un contexto es definido de la siguiente forma:

<context id=” ctxNome”> .. . </context >

Los atributos de un contexto son:

• Id: identificador único de contexto • Refer: referencia a otro contexto previamente definido (utiliza los atributos del

contexto referenciado, excepto el id)El contexto body de un documento NCL hereda el id del propio documento.

5.4.5. Puertas

Una puerta (port) es un punto de interfaz (interface point) de un contexto, que ofrecen acceso externo al contenido (nodos internos) de un contexto. En otras palabras, para que un enlace apunte a un nodo interno al contexto, este contexto debe poseer una puerta que lo dirija hacia el nodo interno deseado.

En todo documento, debe haber por lo menos una puerta de entrada (port en la sección body) indicando cual es el nodo multimedia o contexto inicial.

<port id=”pInicio” componet=”video1” > Cabe observar que la puerta pInicio del body generalmente se asigna al video principal video1. Esto significa que, al iniciar el documento hipermedia, el programa intérprete



65

seguirá la puerta pInicio, la misma que se dirige hacia el nodo de contenido video1, que será entonces presentado. Una puerta posee los siguientes atributos:

• Id: identificador único de la puerta, utilizado en las referencias para la misma.

Component: nodo de media o contexto al cual la puerta se asigna.En caso de que el component sea un contexto, se debe definir el atributo

interface, haciendo la asignación a una puerta o ancla de aquel contexto. En caso de que el component sea un nodo multimedia, se puede definir el atributo interface como una ancla del nodo. Si el atributo interface fuera omitido, todo el nodo será considerado como asignado a aquella puerta.

• Interface: nombre del punto de interfaz (puerta) de destino en el contexto o nombre de la ancla de destino en el nodo multimedia o contexto.

5.4.6. Base de Conectores

Todos los conectores son definidos en una base de conectores (elemento <connectorBase>, que posee como único atributo un identificador (id) de base. Una base de conectores contener los siguientes elementos hijos:

• <causalConnector>: define un conector propiamente. • <importBase>: permite importar una base de conectores de algún otro archivo.

Una base de conectores puede ser definida conforme las siguientes estructuras:

<connectorBase id=”menusConectores”> <importBase .../> <importBase .../> <causalConnector id=”onBeginStar”> ... </causalConnector> <causalConnector id=” ”> ... </causalConnector id=” ”> ... <causalConnector id=” ”>

</connectorBase>

5.4.7. Conectores

En NCM y en NCL, el sincronismo no está hecho por marcas de tiempo (timestamps), pero si por mecanismos de causalidad y restricción definidos en los conectores (connectors). El conector define los papeles (roles) que los nodos de origen y de destino ejercen en los enlaces que utiliza el conector. La figura siguiente ilustra un conector con tres nodos.



66

En NCL 3.0, existe apenas un tipo de conector: o conector causal (causal Connector). Un conector causal define las condiciones (condition) bajo las cuales el enlace <link> puede ser activado, y las acciones (action) que serán realizadas cuando el mismo sea activado. Un conector causal debe poseer por lo menos condición y una acción. Cada condición u acción está asociada a un papel (role), punto de interfaz que participa de las asignaciones del enlace.

El elemento <link> hace referencia a un <causalConnector> y define un conjunto de asignaciones (elementos <bind> hijos del elemnto <link>), que asocian cada extremo del enlace (interface de objeto) a un papel de conector utilizado, como ilustra la siguiente figura:

Los elementos hijo de un <causalConnector > son:



67

• <connectorParam>: define parámetros de conector cuyos valores deberían ser definidos por los enlaces que utilizan un conector.

• <simpleCondition> y <compoundCondition>: definen las condiciones simples o compuestas de activación de un enlace que utiliza un conector;

• <simpleAction> y <compundAction>: definen las acciones simples o compuestas que se realizaran cuando un enlace que utiliza un conector sea activado.

Los siguientes papeles de condición son predefinidos:

Los siguientes papeles de acción son predefinidos:

Tanto los papeles de condición como los de acción están asociados a transiciones de estados en una máquina de eventos, ilustrada en la siguiente figura.



68

Tanto los papeles de condición “onBegin”, “onEnd”, “onAbort”, “onPause” y “onResume”, así como los papeles de acción “start”, “stop”, “abort”, “pause” y “resume” están relacionados a posibles transiciones de estados de presentación de anclas de contenidos como se ilustra en la anterior figura.

Un papel de condición “onSelection” está relacionado a eventos de selección y ligado a interactividad a través de dispositivos de entrada, como el control remoto de la TV.

5.4.8. Enlaces

Los enlaces (links) asocian nodos a través de conectores (connectors), que definen la semántica de la asociación entre los nodos. NCL define los siguientes atributos:

• Id: identificador único de enlace • xconnector: identificador de conector asociado al enlace

NCL define los siguientes elementos contenidos en un elemento de tipo enlace:

• LinkParam: define un parámetro del enlace como un par <propiedad, valor>. Las propiedades y sus respectivos valores dependen de la definición del conector al cual el enlace está asociado. Un enlace puede contener diversos elementos linkParam.

• Bind: indica un componente (nodo multimedia o de contexto) involucrado en el enlace, indicando su papel (role) en el mismo, conforme la semántica del conector. En algunos casos se debe indicar también el punto de interfaz (interface) del nodo, al cual el enlace está ligado (puerta del contexto o ancla de un nodo multimedia). Un enlace puede contener diversos elementos bind, y debe contener por lo menos un bind para cada papel definido en el conector.

El elemento bind puede contener una o más instancias del siguiente elemento como elementos hijos:

• bindParam: define un parámetro específico del bind como un par <propiedad, valor>. Las propiedades y sus respectivos valores dependen de la definición del conector al cual el enlace está asociado.

A continuación se muestra el esquema básico de conformación de un enlace (<link>):



69

<link id=”nombre_de_link” xconnector=”id_de_Link”> <bind role=”id_del_papel_de_condicion” component=”id_de_un_objeto”

interface=”id_de_una_interface”/> <bind role=”id_del_papel_de_accion” component=”id_de_un_objeto”

interface=”id_de_una_interface”/> </link>

5.4.9. Anclas

Las anclas son puntos de entrada para los nodos multimedia o contextos. El objetivo de utilizar anclas es emplear segmentos o propiedades de un nodo multimedia o contexto, sea como origen o destino de los enlaces. Una ancla puede ser del tipo ancla de contenido (content anchor) o ancla de propiedad (property anchor).

Un ancla de contenido define un segmento multimedia (intervalo de tiempo y/o región en el espacio) que pudiera ser utilizado como punto de activación de los enlaces. Un segmento de multimedia es una selección contigua de unidades de información (information units) de un nodo. La definición de esas unidades de información depende del tipo de archivo multimedia presentado por el nodo. Las unidades de información de un video, por ejemplo, pueden ser los frames de video. Un ancla de contenido es definida como un elemento area dentro del elemento media. En el siguiente ejemplo, son definidas tres anclas de contenido para un nodo de video:

<media type=”video” id=”video1” src=”media/video1.mpg” descriptor=”dVideo1”> <area id=”a01” begin=”5s” end=”9s”/> <area id=”a02” begin=”10s” end=”14s”/> <area id=”a03” begin=”15s” end=”19s”/>

</media>

NCL define los siguientes atributos de ancla de contenido:

• id: identificador único de ancla • coords: coordenadas en pixeles del ancla espacial (atributo válido para archivos

multimedia visuales), en el formato “X,Y,width,height” • begin: inicio del ancla, en segundos, en el formato “99.9s” (atributo válido para

archivos multimedia continuos) • end: termino del ancla, en segundos, en el formato “99.9s” (atributo válido para

archivos multimedia continuos) • dur: duración del ancla, en segundos, en el formato “99.9s” (atributo válido para

archivos multimedia continuos) • first: cuadro/muestra del archivo multimedia definiendo el inicio del ancla (atributo

válido para archivos multimedia continuos) • last: cuadro/muestra del archivo multimedia definiendo el fin del ancla (atributo

válido para archivos multimedia continuos) • text: texto del ancla en el archivo de origen (atributo válido para archivos multimedia de texto)

• position: posición del texto del ancla en el archivo de origen (atributo válido para archivos multimedia de texto)



70

• anchorLabel: identificador del ancla en el archivo de origen, tal como es interpretado por la herramienta de exhibición.

Las anclas de propiedad se refieren a propiedades de un nodo de origen o de destino, que pueden ser manipuladas por los enlaces. Ejemplos de propiedades son: volumen del audio de un nodo de audio o video, coordenadas y dimensiones de exhibición de un nodo multimedia visual, entre otros.

Un ancla de propiedad es definida como un elemento property dentro del elemento media o context. En el siguiente ejemplo se definen cuatro anclas de propiedad para un nodo de video, además de un ancla de contenido:

<media type=” video” id=”video1” src=”media/video1.mpg” descriptor=”dVideo1”> <!—anclas de propiedad que seran manipuladas por los enlaces --> <property name=”top”/> <property name=”left”/> <property name=”width”/> <property name=”height”/> <!—anclas de contenido en el video que debe sincronizar la imagen -- > <area id=”aVideo1Imagem1” begin=”3s” end=”8s”/>

</media> 5.4.10. Reglas

Las reglas simples de un documento NCL son definidas en la sección ruleBase, con base en una propiedad, operador y valor, como en el ejemplo a continuación:

<ruleBase> <rule id=”rEn” var=”idioma” comparator=”eq” value=”en” /> <rule id=”rPt” var=”idioma” comparator=”eq” value=”pt” />

</ruleBase>

Los siguientes operadores pueden ser utilizados como comparador en la definición de reglas:

• eq (equal – igual a); • ne (not equal –diferente de); • gt (greater than – mayor que); • ge (greater than or equal to – mayor que o igual a); • lt (less than – menor que); • le (less than o equal to – menor que o igual a).

Una forma de almacenar las propiedades que serán utilizadas en las reglas es utilizar el nodo settings. Se trata de un nodo de propiedades globales, como en el siguiente ejemplo:

<media type=”application/x-ginga-settings” id=”nodeSettings”> <property name= “idioma” />

</media>



71

5.4.11. Switch

Un switch es un contexto con nodos alternativos, es decir, dentro de los cuales apenas uno será activado. La decisión acerca de que nodo será activado es dad por reglas. En la definición de un switch, además de los nodos que lo componen, deben ser definidas las asignaciones de las reglas para esos nodos y sus anclas, tal como se indica en el siguiente ejemplo:

<switch id=”switchAudioIdioma”> <bindRule rule=”rEn” constituent=”audioEn” /> <bindRule rule=”rPt” constituent=”audioPt” /> <media type=”audio” id=”audioEn” src=”media/audioEn.mp3” descriptor=”dAudio1” /> <media type=”audio” id=”audioPt” src=”media/audioPt.mp3” descriptor=”dAudio1” />

</switch>

En ese ejemplo, la media audioEn será reproducida en caso de que la regla rEn sea válida, es decir, en el caso de que idioma posea el valor “en”. Si esa regla no fuera válida, la próxima asignación es valorada, y así sucesivamente, hasta que una regla válida sea alcanzada o hasta terminar el conjunto de asignaciones de aquel switch. En el caso de que el switch sea compuesto de contextos, es necesario definir uno o más elementos switchPort para indicar la puerta de destino de cada asignación de las reglas, como en el siguiente ejemplo:

<switch id=”switchNivel”> <switchPort id=”pNivel”>

<mapping component=”ctxBasico” interface=”pBasico” /> <mapping component=”ctxAvancado” interface=”pAvancado” />

</switchPort> <bindRule rule=”rBasico” component=”ctxBasico” /> <bindRule rule=”rAvancado” component=”ctxAvancado” /> <context id=”ctxBasico”>

<port id=”pBasico” component=”videoBasico” /> <!—nodos e enlaces del context ctxBasico -->

</context> <context id=”ctxAvancado”>

<port id=”pAvancado” component=”videoAvancado” /> <!—nodos e enlaces del context ctxAvancado -- >

</context> </switch>



72

Tema VI

Desarrollo de Aplicaciones Procedurales (Ginga-J)

6.1. Ginga-J.

Como parte de la especificación Ginga fue ideado Ginga-J por el Laboratorio LAVID de UFPB (Universidad Federal de Paraiba - Brasil) en 2006. En 2008 se tuvieron problemas en relación a propiedad intelectual por parte de MHP (APIs HAVI y DAVIC). El foro de SBTVD y SUN Microsystems proponen la nueva especificación JavaDTV en diciembre 2008. Ginga-J está compuesto por un conjunto de APIs y su máquina virtual Java, que incorpora varias innovaciones para permitir la implementación de aplicaciones de TV Digital y satisfacer las necesidades especificas de TV Digital de Brasil, se puede realizar la manipulación desde datos multimedia hasta protocolos de acceso; que a su vez mantiene compatibilidad con la mayoría de middlewares de TV Digital desde que se unió a la norma GEM.

Ginga-J incluye soporte para la comunicación con dispositivos que utilizan tecnologías como son Bluetooth, Wi-Fi, infrarrojo, Power lines, Ethernet o cualquier tecnología de red utilizada. Las aplicaciones pueden tener soporte de interacción por múltiples usuarios. El contexto sobre el cual se ejecuta la pila de software de Ginga-J es el que se muestra en la siguiente figura. En ésta, la pila del software Ginga-J reside sobre el dispositivo Ginga, que puede ser por ejemplo un SetTopBox, un teléfono celular, etc .

Contexto de Ginga-J

El midlleware Ginga debe tener acceso a flujos de video, audio, datos y otros recursos multimedia, pudiendo ser transmitidos a través del aire, cable, satélite o través de redes IP. Las informaciones deben ser procesadas y presentadas a los espectadores, los mismos que interactúan con la aplicación a través de los dispositivos de interacción de entrada y salida adjuntos o asociados al dispositivo Ginga. El dispositivo Ginga recibirá acciones por parte de los televidentes a través del dispositivo de interacción como el control remoto o teclado.

El dispositivo Ginga en respuesta a la acción que realice el espectador, presentará una respuesta visual, así como salidas de audio utilizando su propia pantalla y altavoces o pantallas y altavoces de los dispositivos de interacción. Un solo dispositivo puede tener la capacidad de entrada y salida simultáneamente. La plataforma Ginga permite que varios espectadores puedan interactuar a la vez, para lo cual cada uno dispondrá de un dispositivo de interacción, y la plataforma debe distinguir los comandos enviados por y para cada dispositivo de interacción.



73

6.2. Arquitectura de Ginga-J.

El modelo de arquitectura y ambiente de ejecución de Ginga-J distingue entre entidades de hardware o de recursos, software del sistema, aplicaciones como las que se muestran en la siguiente figura.

Arquitectura y ambiente de ejecución de Ginga-J

Las aplicaciones nativas pueden ser implementadas usando funciones no estandarizadas, provistas por el sistema operativo del dispositivo Ginga, o por una implementación particular de Ginga. Las aplicaciones nativas también pueden incorporar funcionalidades provistas por las APIs estandarizadas Ginga-J. Las aplicaciones Xlets siempre deben utilizar APIs estandarizadas provistas por el Ginga-J.

6.3. El API de Ginga-J

Debido a que los middlewares existentes hasta ese entonces no cumplían con los requisitos identificados en el contexto brasileño sobre TV Digital, Ginga se basa en un conjunto de APIs que fueron creados para satisfacer las necesidades específicas de Brasil y al mismo tiempo mantener una compatibilidad internacional con el API de GEM. Ginga se basa en tres grupos de APIs que permiten cumplir con toda la funcionalidad necesaria para implementar aplicaciones de TV Digital, estos grupos de APIs se han denominado: Verde, Amarillo y Azul.

APIs Ginga-J



74

Los APIs Verde de Ginga son los APIs compatibles con GEM. Los APIs Amarillo son aplicaciones compuestas para satisfacer las necesidades específicas de Brasil que pueden ser implementadas mediante el uso de un software de adaptación utilizando los APIs Verde. Los APIs Azul no son compatibles con los APIs de GEM . De esta forma las aplicaciones que utilizan sólo los APIS Verde pueden ser ejecutadas en los midlewares Ginga, MHP, OCAP, ACAP y ARIB STD-23. Las aplicaciones que utilizan los APIs Verde y amarillo solamente podrán ser ejecutadas en MHP, OCAP, ACAP y ARIB STD-23, si el software de adaptación es transmitido y ejecutado conjuntamente a la aplicación. Y finalmente las aplicaciones que utilicen los APIs Azul solo podrán ser ejecutadas en ambientes del midleware Ginga.

Los APIs de Ginga-J son:

• Los APIs verde, están compuestos por los paquetes Sun JavaTV, DAVIC, HAVI y DVB, todos incluidos en el marco de especificaciones GEM.

• Los APIs Amarillo están conformados por el API JMF2.1, que es necesario para el desarrollo de aplicaciones avanzadas como captura de sonido por citar un 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; 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.

• Los APIs Azul están compuestos 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 utilizado 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 .

6.3.1. API JavaTV.

Es una extensión de la plataforma Java, ayuda en la producción de contenidos interactivos de manera procedural para la TV digital. El objetivo primordial de este API es proporcionar un conjunto de métodos, clases e interfaces facilitando la creación de aplicaciones desarrolladas ejecutables en diversas plataformas para la recepción de TV Digital independientemente de las tecnologías utilizadas en la red de transmisión.

JavaTV soporta un nivel alto de interactividad, calidad gráfica y de procesamiento para ser ejecutado dentro de un set top box, siempre y cuando este equipada con la máquina virtual java que permita interpretar los bytecodes generados.

El API JavaTV realiza funciones como:

• Streaming de audio y video: A más de la streaming de audio y video procedente de la estación, es factible generar otras aplicaciones con otros flujos.

• Acceso a datos en el canal de transmisión: JavaTV puede recibir datos para las aplicaciones.

• Aplicaciones con interactividad: Procesa datos y los reenvía a través de un canal de retorno.



75

• Gestión del ciclo de vida de las aplicaciones: Permite que las aplicaciones coexistan con el contenido de TV convencional facilitando el intercambio de canal sin que la aplicación deje de existir.

6.3.1.1. Librerías del API JavaTV

• javax.tvcarousel: Proporciona acceso a archivos broadcast y directorio de datos a través de APIs que trabajan con el paquete java.io.

• javax.tv.graphics: Permite que los Xlets, puedan obtener su repositorio principal. • javax.tv.locator: Proporciona una forma para referenciar datos en programas accesibles por

la API JavaTV. • javax.tv.media: Define una extensión para JMF (Java Media Framework) con la finalidad de

gestionar los medios de comunicación en tiempo real. • javax.tv.media.protocol: Proporciona acceso a un flujo de datos broadcast genérico. • javax.tv.net: Permite acceso a datagramas IP (Internet Protocol) transmitidos en un stream

broadcast. • javax.tv.service: Proporciona mecanismos para accesar a la base de datos. javax.tv.util:

Soporta la creación y gestión de eventos del temporizador. • javax.tv.xlet: Proporciona interfaces para el desarrollo de aplicaciones y la comunicación

entre las aplicaciones y el administrador.

6.3.2. API DAVIC (Digital Audio Visual Council)

Son especificaciones que presentan requisitos de sistemas audiovisuales que proporcionan interactividad de extremo a extremo. Se los puede utilizar en TV Digital con el fin de facilitar contenido al usuario final, también permite la interactividad con el mismo usuario.

A continuación listamos los paquetes que forman parte del API DAVIC:

• org.davic.media • org.davic.resources • org.davic.mpeg • org.davic.mpeg.sections • org.davic.net • org.davic.net.dvb • org.davic.net.tuning

6.3.3. API HAVi (Home Audio Video Interoperability).

Crea elementos, como la interfaz de usuario, cuyo objetivo es proporcionar un entorno fácil de usar para el espectador. Provee una extensión del paquete java.awt, permitiendo, asimismo, soporte de control remoto, transparencia entre otros.

Los paquetes que forman parte de la API HAVi incluidos en Ginga- J son:

• org.havi.ui • org.havi.ui.event

6.3.4. API DVB.

En el desarrollo del middleware patrón MHP, el DVB incluye algunos paquetes para



76

extender la funcionalidad ofrecida por JavaTV, HAVi y DAVIC. Estas características incluyen API de información de servicio, de intercomunicación entre Xlets, etc. Los paquetes que forman parte del API DVB, se mencionan a continuación.

• org.dvb.application • org.dvb.dsmcc • org.dvb.event • org.dvb.io.ixc • org.dvb.io.persistent • org.dvb.lang • org.dvb.media • org.dvb.net • org.dvb.net.tuning • org.dvb.net.rc • org.dvb.test • org.dvb.ui

6.3.5. API JavaDTV

Paquetes de especificación JavaDTV 1.3 (extiende los paquetes de JavaTV 1.1 para implementar funcionalidades especificas de TVD adicionales o de menor grado de abstracción). La especificación JavaDTV 1.3 esta disponible en el sitio del Foro de SBTVD http://forumsbtvd.org.br/acervo-online/javadtv-donwload

6.3.5.1. Descripción de la arquitectura

La especificación JavaDTV consta de APIs DTV Java y APIs Java TV, añadidas al conjunto básico de componentes comunes de Java Runtime. Las APIs Java DTV se ilustran a continuación:



77

6.4. Modelo Gráfico JavaDTV

En el mismo modo que el término :

• Applet refiere a una aplicación Java ejecutando en un Browser o PC • Midlet refiere a una aplicación Java ejecutando en un dispositivo JME • Servlet refiere a una aplicación Java ejecutando en un servidor JEE • … En el contexto DTV/iTV en general, la aplicación del término es usada

indistintamente con los términos JavaTV Xlet o simplemente Xlet.

Entonces el nombre para aplicaciones de televisión basadas en Java es Xlet. Al igual que los applets, los Xlet están controladas por el software que los ejecuta. En el caso de un applet, 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 digital o set-top box, que es compatible con la plataforma de televisión de Java.



78

6.4.1. Ciclo de vida Xlet

No hay un método principal (main) y Xlet siempre implementa la interfaz Xlet. Al igual que los applets, Xlets tienen un ciclo de vida, y los métodos de ciclo de vida se definen mediante la interfaz Xlet.

Todas las implementaciones Java de TV tienen un gestor de aplicaciones que llama a los métodos del ciclo de vida para mover uno o más Xlets a través de sus diferentes estados de aplicación. Por ejemplo, el espectador podría estar jugando un juego en un programa de juegos y decide comprobar los listados de programas. Si la lista de programas y juegos son Xlets, el software en el receptor señaliza que un Xlet está presente cuando el espectador selecciona la lista de programas. En este punto, el gestor de aplicaciones pausa el juego Xlet, y el receptor descarga el Xlet de la lista de programas en el receptor. El gestor de aplicaciones carga e inicia el Xlet de lista de programas. Si el espectador retorna al juego, el gestor de aplicaciones pausa el Xlet de lista de programas y comienza el Xlet del juego.

La interfaz Xlet no proporciona implementaciones para sus métodos de ciclo de vida. El desarrollador debe proveer aplicaciones específicas para implementar los métodos definiendo que sucede en cada punto del ciclo de vida Xlet. Por ejemplo, el método initXlet para el juego Xlet podría crear los componentes de interfaz de usuario.

Un Xlet puede iniciar algunos cambios de estado propios e informar al gestor de aplicaciones de esos cambios de estado invocando métodos en la interfaz XletContext. Un objeto XletContext se pasa a un Xlet Cuando el Xlet se inicializa para dar al Xlet la manera de recuperar las propiedades y señalar los cambios de estado internos.

Xlet es una interfaz y esta regido por cuatro métodos:

• initXlet() • startXlet() • pauseXlet() • destroyXlet()



79

La Interfaz Xlet (javax.tv.xlet.Xlet) está siempre lista para ser destruida o pausada. Cuando es Pausada, desecha los eventos del usuario y se remueve de la pantalla. Cuando es Destruida, para todas los Threads y cancela eventos asíncronos, ademas se remueve de la pantalla y libera recursos. No puede ejecutar System.exit (0)!

Cada Xlet tiene un contexto asociado (una instancia de la clase javax.tv.xlet.XletContext). Este contexto es similar a la clase AppletContext que es asociada a una applet; El contexto es usado para proveer un modo de la aplicación obtener informaciones sobre su ambiente y también para comunicar cambios de estado para su ambiente

6.4.2. Vision General de los componentes

Fundamentado en LWUIT (LightWeight User Interface Toolkit) – com.sun.dtv.lwuit. LWUIT es una biblioteca basada en Swing y permite crear GUIs bastante atrayentes en dispositivos que ejecutan las siguientes plataformas: JavaME (CLDC 1.1, MIDP 2.0/CDC, FP e PBP) o JavaSE. LWUIT ofrece, entre otros recursos: soporte a Touch Screen, animaciones, botones, fuentes, transiciones de pantalla, temas, layouts, dialogos, integracion 3D, etc. Cada componente visual de LWUIT posee una serie de propiedades, tales como: enfoque, navegabilidad y capacidad de recibir entradas de usuario. Cada componente visual de LWUIT está asociado a dos componentes: uno relacionado con la presentacion (look) y otro relacionado al comportamiento - behavior (feel). De esa forma, se separa la funcionalidad de la vista. Ademas paquetes, clases, métodos fueron adaptados a la realidad de TV Digital.



80

Contenedor - Containers

Container es un componente responsable de almacenar varios componentes através del método addComponent(…), que acepta componentes. Cada Container tiene su propio layout.

Formularios - Forms

Form es un contenedor y es de los principales componentes visuales que sirve como raíz para la interfaz de usuario.

El Form esta compuesto de Title, ContentPane y MenuBar. Manipula menús y título mientras posiciona el contenido entre ellos

Pueden ser adicionados otros componentes y los componentes adicionados son centralizados



81

Dialogos - Dialogs

Dialog es un Form que ocupa parte de la pantalla como componente principal; Dialog es, tambien, un “Top Component”; Un Dialog puede ser modal o modeless; posee los métodos show() y dispose(); Puede ser creado de dos formas:

Existen diferentes Tipos de Dialogs. El tipo indica un icono y sonido asociados:

ALARM CONFIRMATION ERROR INFO WARNING

Pestaña - TabbedPane TabbedPane es un contenedor de pestañas con títulos. Las imagenes tambien puede ser usadas como pestañas. Las pestañas pueden ser dispuestas en cualquier lado: cabecera, pie, izquierda o derecha. Se pasa un componente para el método addTab() y se especifica el título o imagen de la pestaña.

Etiqueta - Label

Label es un componente sin interaccion con el usuario y puede mostrar imágenes y textos. No puede recibir eventos y puede tener alinamiento horizontal o vertical.



82

Boton - Button

Button es un componente que hereda características de Label y que ademas de recibir el foco, puede recibir eventos de usuario. Puede tener texto o imagen. Se usa una tecla de seleccion o el puntero del raton para haer clic sobre el. Se usa un ActionListener para descubrir cuando un boton fue seleccionado. Posee tres estados: STATE_DEFAULT, STATE_PRESSED, STATE_ROLLOVER

• RadioButton

Hereda de Button. Posee un estado booleano. No hace mucho por si solo, debe ser agrupado con ButtonGroup.

• CheckBox

Hereda de Button. Posee un estado booleano. Se verifica una selección del mismo através del método isSelected().

Area de Texto - TextArea

Especifica líneas y columnas. Exhibe texto en la pantalla. TextArea de múltiples lineas pueden aumentar de tamaño en caso de ser necesario. No se pueden usar (Constraints): ANY, DECIMAL, EMAILADDR, INITIAL_CAPS_SENTENCE, INITIAL_CAPS_WORD, NON_PREDICTIVE, NUMERIC, PASSWORD, PHONENUMBER, SENSITIVE, UNEDITABLE, URL

• Campo de Texto - TextField

Hereda de TextArea. Representa un campo de texto (una única linea).



83

Listas - Lists

Crucial para aplicaciones interactivas. Modelo de separacion MVC (Model, View, Control) - (ListModel, ListCellRenderer e ListEvents, respectivamente). Muchos modos útiles

• FIXED_NONE • FIXED_NONE_CYCLE • FIXED_NONE_ONE_ELEMEN_

MARGIN_FROM_EDGE • FIXED_LEAD • FIXED_TRAIL • FIXED_CENTER

• ListModel

Representa una estrutura de datos de una Lista. El modelo permite que una lista muestre una cantidad ilimitada de datos. List tiene un modelo estandar, o DefaultModel.

• ListCellRenderer

Interface responsable de exhibir los datos del modelo. List tiene un modelo estandar, o DefaultListCellRenderer

• ListEvents

Los EVENTOS de List, pueden ser de tres tipos: • Action Events; • Selection Events; • Data Events.



84

ComboBox

Es un tipo de lista. Tiene un modelo. Puede usar un CellRenderer personalizado. Muestra la selección actual y muestra las opciones como un Pop-up.

Administrador de Layout

Permite administrar la disposición de los componentes de Container

• BorderLayout • BoxLayout • CoordinateLayout • FlowLayout • GridLayout • GroupLayout

JavaDTV añadió la interfaz TextLayoutManager y dos Text Layouts:

• DefaultTextLayoutManager, • SophisticatedTextLayoutManager

Permite definir funcionalidades para layout de Strings y su exhibición en la pantalla

• BorderLayout

Organiza y redimensiona los componentes en 5 regiones: norte, sud, este, oeste y central.



85

• BoxLayout

Organiza los componentes en líneas o columnas conforme a la orientacion

• CoordinateLayout

Utiliza coordenadas absolutas x e y para organizar y posicionar un componente en la TV

• FlowLayout

Administra los componentes de la TV a traves de flujo con orientación para la derecha, izquierda o centro.

• GridLayout

La TV es dividida en células del mismo tamaño y cada componente puede ser posicionado en una celula



86

6.5. Lista de paquetes mínimos de Ginga-J.

6.5.1. Paquetes de la plataforma Java.Los paquetes de la plataforma Java se listan a continuación:

• java.awt • java.awt.color • java.awt.event • java.awt.font • java.awt.im • java.awt.image • java.beans • java.iojava.lang • java.lang.ref • java.lang.reflect • java.math • java.net • java.rmi • java.rmi.registry • java.security • java.security.acl • java.security.cert • java.security.interfaces • java.security.spec • java.text • java.util • java.util.jar • java.util.zip • javax.microedition.io • javax.microedition.pki • javax.microedition.xlet • javax.microedition.xlet.ixc • javax.security.auth.x500

6.5.2. Paquetes de la especificación JavaTV 1.1 y JMF 1.0Los siguientes paquetes son incluidos por esta parte de la ABNT NBR 15606:

• javax.media • javax.media.protocol • javax.tv.graphics • javax.tv.locator • javax.tv.media • javax.tv.net • javax.tv.service • javax.tv.service.guide • javax.tv.service.navigation • javax.tv.service.selection • javax.tv.service.transport • javax.tv.util • javax.tv.xlet



87

6.5.3. Paquetes de la especificación JavaDTVLos siguientes paquetes son incluidos por esta parte de la ABNT NBR 15606:

• com.sun.dtv.application • com.sun.dtv.broadcast • com.sun.dtv.broadcast.event • com.sun.dtv.filtering • com.sun.dtv.io • com.sun.dtv.locator • com.sun.dtv.lwuit • com.sun.dtv.lwuit.animations • com.sun.dtv.lwuit.events • com.sun.dtv.lwuit.geom • com.sun.dtv.lwuit.layouts • com.sun.dtv.lwuit.list • com.sun.dtv.lwuit.painter • com.sun.dtv.lwuit.plaf • com.sun.dtv.lwuit.util • com.sun.dtv.media • com.sun.dtv.media.audio • com.sun.dtv.media.control • com.sun.dtv.media.dripfeed • com.sun.dtv.media.format • com.sun.dtv.media.language • com.sun.dtv.media.text • com.sun.dtv.media.timeline • com.sun.dtv.net • com.sun.dtv.platform • com.sun.dtv.resources • com.sun.dtv.security • com.sun.dtv.service • com.sun.dtv.smartcard • com.sun.dtv.test • com.sun.dtv.transport • com.sun.dtv.tuner • com.sun.dtv.ui • com.sun.dtv.ui.event.

6.5.4. Paquetes de la especificiación JSSE 1.0.1Los siguientes paquetes son incluidos por esta parte de la ABNT NBR 15606:

• com.sun.net.ssl • javax.net • javax.net.ssl • javax.security.cert

6.5.5. Paquetes de la especificación JCE 1.0.1Los siguientes paquetes son incluidos por esta parte de la ABNT NBR 15606:

• javax.crypto • javax.crypto.interfaces • javax.crypto.spec.



88

6.5.6. Paquetes de la especificación SATSA 1.0.1El siguiente paquete es incluido por esta parte de la ABNT NBR 15606:

• javax.microedition.apdu

6.5.7. Paquetes específicos de Ginga-JLos siguientes forman parte de esta plataforma:

• br.org.sbtvd.net • br.org.sbtvd.net.si • br.org.sbtvd.net.tuning • br.org.sbtvd.bridge • br.org.sbtvd.ui



89

Tema VII

Lenguaje procedural LUA Lua es un lenguaje multi-paradigma utilizado en forma integrada para interactuar con NCL, si se requiere implementar características fuera del alcance de NCL. Las siguientes funciones son dependientes de la plataforma y se han quitado del lenguaje lua:

• en el módulo package: loadlib; • en el módulo io: todas las funciones; • en el módulo os: clock, ejecute, exit, getenv, remove, rename, tmpname y setlocale; • en el módulo de depuración: todas las funciones

Se relaciona a NCL y GINGA-NCL mediante las librerías de NCLua. Además de la biblioteca estándar de Lua, los siguientes módulos deben ser obligatoriamente ofrecidos y automáticamente cargados:

• módulo canvas: ofrece una API para diseñar primitivas gráficas y manipular imágenes; • módulo event: permite que las aplicaciones NCLua se comuniquen con el middleware a

través de eventos (eventos NCL y de teclas); • módulo settings: exporta una tabla con variables definidas por el autor del documento NCL

y variables de entorno reservadas en un nodo "application / x-ginga- settings"; • módulo persistent: exporta una tabla con variables persistentes, que están disponibles

para manipulación sólo por objetos procedurales. El modelo de ejecución de un NCLua es orientado a eventos. Esto quiere decir que para todos los usos del control remoto, sincronismos en documentos NCL, etc, existen eventos asociados y es a través de ellos que toda dinámica de un documento NCLua se hace presente. El control sobre estos eventos es hecho por el formateador NCL que activa el NCLua (que a su vez recibe el evento y lo procesa, señalando algún cambio al formateador). Un elemento LUA se define en el archivo NCL como un archivo multimedia más, asignándole un descriptor de región, en donde, si se desea, se puede escribir o pintar.

<media id="lua1" src="archivo1.lua"/> Lua tiene un modelo de ejecución de NCLua orientado a eventos. Un script Lua para TVD solo es un tratador de eventos (handler). Durante la inicialización de la secuencia de comandos, antes de dirigirse a eventos, un NCLua debe registrar al menos una función de tratamiento de eventos. A partir de entonces, cualquier acción tomada por la aplicación es sólo en respuesta a un evento enviado por el formateador a esa función tratadora. ejemplo.lua

-- ... -- código de inicialización function handler (evt) ... -- código del handler end event.register(handler) -- registro del handler en el formateador



90

7.1. Eventos LUA (API – NCLua) • event.register (f: function)

Registra la función pasada como un listener de eventos, es decir, cada vez que ocurra un evento, f será llamada. La función f es así la función de tratamiento de eventos (function handler). Durante su ejecución, un NCLua también puede enviar eventos para comunicarse con el ambiente mediante event.post: canal de interactividad, NLC, o su terminacion.

• event.unregister (f: function) Quita del registro la función pasada como un listener, es decir, nuevos eventos ya no serán pasados a f.

• event.post ([dst: string]; evt: event) Postea el evento pasado.

• event.timer (time: number, f: function)

Crea un temporizador que expira después de time (en milisegundos) y luego llama a la función f.

• event.uptime ()

Devuelve el número de milisegundos transcurridos desde el inicio de la aplicación. 7.2. Clases de eventos • Tipo ‘presentation’:

evt={class='ncl',type='presentation',area='?', action='start'/'stop'/'abort'/'pause'/'resume' } • Tipo ‘attribution’:

evt={class='ncl',type='attribution',area='?', transition='stops' } • Tipo ‘selection’:

evt={class='ncl',type='selection',area='?', transition='stops' } • EventosKey:

evt = { class='key', type: string, key: string} type puede ser 'press' o 'release'. key es el valor de la tecla en cuestion.

evt = { class='key', type='press', key=’0’ }

• Clase TCP:

evt = { class = 'tcp', type = 'connect', host = <addr>, port = <number>, [timeout = <number>,] } Ejemplo de archivo con código Lua: function handler (evt)

event.timer(3000, function() -- espera 3 segundos, ... event.post { class = ’ncl’, type = ’presentation’, action = ’stop’, -- ... luego envía evento. end) end event.register(handler)



91

7.3. Módulo event El módulo event permite la conexión del código LUA con NCL. Define la estructura utilizada para acceder a los eventos que son manejados en el código NCL (los cuales pueden ser de tipo ncl, key, tcp, user, sms, si) y así rescatar por ejemplo, los valores de algun parámetro seteado en el archivo NCL.

n ncl: Se comunica con el documento en el que esta inserto mediante los eventos de condicion-accion.

n key: Utilizada para representar el uso del control remoto por el usuario. n tcp: Para el uso del canal de interactividad (retorno). n user: Aplicaciones pueden extender sus funcionalidades creando sus propios eventos.

Un evento se escribe por una tabla Lua simple, con campo class obligatorio que identifica la clase del evento. Ejemplo el evento para indicar que tecla ’0’ fue presionada:

{ class=’key’, type=’press’, key=’0’ } La siguiente figura muestra la relación entre un evento de tipo ncl con el archivo NCL y con el script LUA, generando un puente entre ambos para el traspaso de información de ejecución y de parámetros:

7.3.1. Eventos ncl Se comunica con el documento en el que esta inserto mediante los eventos de condicion-accion. Un NCLua interactúa con un documento a través de links en el que el objeto media esta asociado. Por lo tanto, no es posible que un NCLua interfiera directamente el comportamiento de otros media presentes en el documento.En los links que gatillan un NCLua (en la acción), cuando se satisface la condición, esto hace que NCLua reciba un evento describiendo la acción a ser tomada. Por ejemplo, si se cumple:

<link xconnector="onBeginStart"> <bind role="onBegin" component="videoId"/> <bind role="start" component="luaId"/> </link>

NCLua recibirá el evento:



92

{ class=’ncl’, type=’presentation’, action=’start’ } Este evento será recibido por la función registrada durante la inicialización del script. En los links condicionados por un NCLua (en la condición), la acción será gatillada cuando el NCLua señale el evento que calce con la condición esperada. Por ejemplo, en el siguiente link:

<link xconnector="onBeginStart"> <bind role="onEnd" component="luaId"/> <bind role="start" component="imageId"/> </link>

Si NCLua postea el evento:

event.post { class=’ncl’, type=’presentation’, action=’stop’ } El link gatillara la exhibición de la imagen asociada a el. Formalmente, existen tres tipos de eventos de la clase ncl soportados por NCLua: presentation, selection y attribution. • Presentation:

Los eventos de presentación, controlan la visualización del nodo de medio asociado con NCLua. Los eventos de presentación pueden estar asociados a áreas (o anclas) específicas o al nodo como un todo (<área id=”id área”>) especıficas, mediante campo label (si no esta definido, se iguala a nil)

En el caso de acciones generadas por el formateador, el campo action indica la acción a tomar por el NCLua.

{Class = 'ncl', type = 'presentation', area = 'intro', action = 'start'} donde action puede ser: start, stop, abort, pause, resume.

Para las transiciones generadas por NCLua, el campo de transición indica el cambio de estado de su evento de presentación.

{Class = 'ncl', type = 'presentation', area = 'intro', transition = 'stops')

• Attribution:

Las asignaciones siempre se asocian a las propiedades del nodo (En el documento NCL). Los eventos de asignación siempre deben tener el campo property con el nombre de la propiedad en cuestión. Ejemplo: {Class = 'ncl', type = 'atribución', property = 'counter', action = 'start', value = '2'}



93

Controlan las propiedades del nodo NCLua. Campo name del evento contiene el nombre de la propiedad afectada.La acción start en un evento attribution corresponde al role=”set” en un link NCL. Campo value tendrá el valor a ser asociado (string). Ejemplo: event.post { class = ’ncl’, type = ’attribution’, name = ’myProp’, action = ’start’, value = ’10’, }

7.3.2. Eventos key (Selection) Los eventos de selección no son tratados por la clase 'ncl', sino por la clase de eventos 'key'. Los usos del control remoto generan eventos de esta clase que son recibidos por NCLua. En este caso la comunicación es unidireccional, ya que el control remoto es un dispositivo sólo de entrada.Tiene solo sentido para captura y manejo de eventos. El campo type toma valores press (al presionar) o release (al soltar). El campo key toma el valor de la tecla. Ejemplo: { class=’key’, type=’press’, key=’RED’ } Los valores posibles para key (control remoto) son:

123456789ABCDE FGHIJKLMNOPQR STUVWXYZ*# MENU INFO GUIDE CURSOR_DOWN CURSOR_LEFT CURSOR_RIGHT CURSOR_UP CHANNEL_DOWN CHANNEL_UP VOLUME_DOWN VOLUME_UP RED GREEN YELLOW BLUE ENTER BACK EXIT POWER REWIND STOP EJECT PLAY RECORD PAUSE

7.3.3. Eventos user Creación de eventos propios.Solo campo class = ’user’.El resto es definido por el usuario (eventos de uso interno). Ejemplo: { class=’user’, data=’mydata’ } 7.3.4. Eventos tcp Eventos para manejar el uso del canal de interactividad (retorno). Primero que todo, es necesario establecer una conexión, con el siguiente evento:

event.post { class = ’tcp’, type = ’connect’, host = <addr>, port = <number>, -- opcional: -- timeout = <number>, }



94

El resultado de la conexión retorna un evento con la siguiente estructura:

evt = { class = ’tcp’, type = ’connect’, host = <addr>, port = <number>, connection = identifier, error = <err_msg>, }

Los campos error y connection son mutuamente exclusivos: problema de conexión carga mensaje de error, y conexión exitosa retorna un identificador de connection único. Eventos tcp - Envıo de Datos NCLua envía datos a través del canal de retorno, usando eventos así:

event.post { class = ’tcp’, type = ’data’, connection = <identifier>, value = <string>, [timeout = number,] }

Eventos tcp - Recepción de Datos Similarmente, NCLua recibe datos, con un evento:

evt = { class = ’tcp’, type = ’data’, value = <string>, connection = <identifier>, error = <err_msg>, }

Nuevamente, los campos error y connection son mutuamente exclusivos. Para cierre de conexión:

event.post { class = ’tcp’, type = ’disconnect’, connection = <identifier>, }

El Archivo tcp.lua es un utilitario a la hora de realizar conexiones tcp con algún servidor web. Permite la interacción del usuario, a través del código LUA, con un servidor web. Recibir información online en la aplicación interactiva, o enviar los resultados de alguna selección realizada por el usuario, son ejemplos típicos de los usos para una conexión tcp en una aplicación GINGA. La estructura básica para uso del archivo tcp.lua es la siguiente:

require 'tcp' tcp.execute( function() -- Usar funciones: connect, send, receive, disconnect end )



95

7.4. Módulo canvas El módulo canvas permite el dibujado de componentes en pantalla, de manera similar a las descripciones realizadas a través de NCL. Así, el lenguaje LUA consta con una poderosa herramienta para generar dinámicamente contenido en pantalla. El dibujado se realiza directamente sobre la región que fue asignada al código LUA en el archivo NCL. NCLua puede hacer operaciones graficas durante la presentación de una aplicación.Cuando se inicia NCLua, automáticamente se instancia un objeto grafico que es atribuido a la variable global canvas. Este objeto apunta a la región asociada al nodo de media NCLua, en el documento NCL y todas las operaciones graficas se hacen a través de el.Si el nodo de media NCLua no esta asociado a una región, el valor de canvas = nil. También se pueden construır nuevos canvas:

canvas:new(...). Algunas de las funciones disponibles son las siguientes:

-- en lua los comentarios se inician con doble barra. -- Nuevo canvas de dimensiones (width, height). -- Pıxeles inicialmente transparentes: canvas:new(width, height) -- Nuevo canvas desde imagen en ruta (image_path): canvas:new(image_path) -- Retorna dimensiones del canvas: w, h = canvas:attrSize () -- Retorna atributo de color del canvas. -- Se dibuja con el color activo: R, G, B, A = canvas:attrColor () -- Cambia atributo de color del canvas. -- Se dibuja con el color activo: canvas:attrColor (R, G, B, A) canvas:attrColor (nombre_color, A) -- Colores predefinidos: ’white’, ’aqua’, ’lime’, ’yellow’, ’red’, ’fuchsia’, ’purple’, ’maroon’, ’blue’, ’navy’, ’teal’, ’green’, ’olive’, ’silver’, ’gray’, ’black’ -- Acceso a parámetros de área del canvas: x, y, w, h = canvas:attrClip() -- Redefinición de parámetros de área del canvas: canvas:attrClip (x, y, w, h) -- Acceso al atributo de fuente del canvas: face, size, style = canvas:attrFont()



96

-- Redefinición del atributo de fuente del canvas: canvas:attrFont (face, size, style) -- Dibuja recta entre (x1,y1) y (x2,y2): canvas:drawLine (x1, y1, x2, y2) -- Dibuja rectangulo entre (x,y) y (x+w,y+h): canvas:drawRect (mode, x, y, w, h) -- mode: ’frame’ dibuja borde, ’fill’ completa área -- Dibuja texto desde (x,y): canvas:drawText (x, y, text) -- Retorna las dimensiones del texto: dx, dy = canvas:measureText(text) -- Composición pixel a pixel entre dos canvas. canvas:compose (x, y, canvas_src) canvas:compose (x, y, canvas_src, src_x, src_y, src_width, src_height) -- Primero copia canvas_src en canvas, desde (x, y). -- El segundo, además, solo considera la región de canvas_src -- desde (src_x, src_y) con dimensiones (src_width, src_height). -- permite limpiar los componentes dibujados canvas:clear() -- Actualiza el canvas en NCL. canvas:flush () -- actualiza el contenido en pantalla de acuerdo a los -- cambios generados en código. Siempre al modificar algo, se debe hacer flush -- al final.

La lista completa de comandos para canvas se puede revisar en http://www.telemidia.puc-rio.br/~francisco/nclua/referencia/canvas.html Manejo de strings Una de las características más potentes de este lenguaje es el manejo de strings. En la documentación se podrán encontrar una gran cantidad de funciones para el manejo de strings. Algunos ejemplos son:

-- algunas operaciones -- Asignaciones test = "hola" test2 = "10" test3 = "12"

-- tonumber convierte el string a un valor numérico) suma = tonumber(test2)+tonumber(test3) perc = tonumber(test2)/suma*100 -- concatenacion res = "el resultado es "..perc --declaracion de funciones function writeTitle(text)



97

canvas:attrColor(255,255,255,0) canvas:clear() canvas:attrFont("vera", 24) canvas:drawText(40, 10, text) canvas:flush() end -- recuperación de variables enviadas desde NCL. -- en este ejemplo, la variable voto fue seteada en el causalConnector asociado -- al objeto media con parámetro voto (revisar <media>) if evt.name == 'voto' then if evt.value == 'opt1' then resultado = resultado+1 end end

7.5. Módulo Settings Datos del propio set-top-box

Lang = settings.system.language age = settings.user.age location = settings.user.location



98

BIBLIOGRAFIA

• ABNT NBR 15606-1 2010. Televisión digital terrestre – Codificación de datos y especificaciones de transmisión para radiodifusión digital. Parte 1: Codificación de datos.

• ABNT NBR 15606-2 2011. Televisión digital terrestre — Codificación de datos y especificaciones de transmisión para radiodifusión digital Parte 2: Ginga-NCL para receptores fijos y móviles – Lenguaje de aplicación XML para codificación de aplicaciones

• ABNT NBR 15606-3 2010. Televisión digital terrestre Codificación de datos y especificaciones de transmisión para radiodifusión digital Parte 3: Especificación

• ABNT NBR 15606-4 2010. Televisión digital terrestre — Codificación de datos y especificaciones de transmisión para radiodifusión digital. Parte 4: Ginga-J — Ambiente para la ejecución de aplicaciones procedurales

• ABNT NBR 15606-5 2011. Televisión digital terrestre — Codificación de dados y especificaciones de transmisión para radiodifusión digital. Parte 5: Ginga-NCL para receptores transportables – Lenguaje de aplicación XML para codificación de aplicaciones

• Gomes Soares , Luiz Fernando & Junqueira Barbosa, Simone Diniz . (2011) Programando em NCL 3.0 2a. Edição Versão 2.1

• JavaDTV API 2009 ―Java DTV API 1.3 Specification. Sun Microsystems, disponible en URL: http://java.sun.com/javame/technology/javatv/

• Sant'Anna, Francisco et.al. (2009) Desenvolvimento de Aplicações Declarativas para TV Digital no Middleware Ginga com Objetos Imperativos Lua

• Saraiva Júnior, Erisvaldo Gadelha. Arquitetura de APIs Gráficas do JavaDTV LWUIT e DTV-UI. Laboratório de Aplicações de Vídeo Digital Departamento de Informática - UFPB

• Sun Microsystems, Inc. (2009) Developer’s Guide Lightweight UI Toolkit • Biswajit Sarkar (2009) LWUIT 1.1 for Java ME Developers

APLICACIONES INTERACTIVAS PARA TELEVISION DIGITAL

Documents

Transcript of APLICACIONES INTERACTIVAS PARA TELEVISION DIGITAL