Propuesta de una arquitectura que implemente el estándar ...
76
, Junio 2019 Departamento de Computación Propuesta de una arquitectura que implemente el estándar HbbTV en los receptores de televisión digital terrestre que operan en Cuba. Autor: Yasiel Cabrera Alonso Tutor: Ing. Roberto Vicente Rodríguez
Transcript of Propuesta de una arquitectura que implemente el estándar ...
, Junio 2019
Departamento de Computación
Propuesta de una arquitectura que implemente el estándar HbbTV en los
receptores de televisión digital terrestre que operan en Cuba.
Autor: Yasiel Cabrera Alonso
Tutor: Ing. Roberto Vicente Rodríguez
, June, 2019
Departament of Informatics
Proposal of an architecture that implements the HbbTV standard in
digital terrestrial television receivers that operate in Cuba.
Author: Yasiel Cabrera Alonso
Thesis Director: Ing. Roberto Vicente Rodríguez
Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu” de Las
Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria “Chiqui Gómez
Lubian” subordinada a la Dirección de Información Científico Técnica de la mencionada casa
de altos estudios.
Se autoriza su utilización bajo la licencia siguiente:
Atribución- No Comercial- Compartir Igual
Para cualquier información contacte con:
Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de Las
Villas. Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830
Teléfonos.: +53 01 42281503-1419
i
PENSAMIENTO
“Todas las piezas deben unirse sin ser forzadas. Debe recordar que los componentes que está
reensamblando fueron desmontados por usted, por lo que si no puede unirlos debe existir una
razón. Pero sobre todo, no use un martillo”
Manual de mantenimiento de IBM, año 1925
ii
DEDICATORIA
A mi mamá, por darme la vida, por quererme tanto, por creer en mi siempre y por apoyarme
incondicionalmente. Gracias por darme una carrera para mi futuro, todo esto te lo debo a ti.
iii
AGRADECIMIENTOS
A mi familia, por todo el esfuerzo y tiempo que me han dedicado para que pueda cumplir parte de
mis sueños.
A mi tutor, por todo el increíble apoyo y tiempo que me dedicó; sobre todo por creer en mi cuando
otros se negaron.
A Reinier Millo, mi antiguo tutor y profesor, y más que eso un amigo, por todo el apoyo y
confianza que me ha dado.
A Beatriz Cabrera, la única amiga en la que he podido confiar plenamente, por escucharme,
apoyarme, aconsejarme, soportarme… por hacer recíproca la confianza y más.
A todos mis profesores por contribuir en mi formación y compartir conmigo parte de sus saberes.
A Abel, Victor, Ruddy, Rafael, Arian Mariano, Orestes, Jerry, Rene, Adnier, Bety, Nedelsy,
Alejandro, Roberto, María Karla, Giselle, Andrés, El Tato, Miguel Ángel, Manuel y Leygui por
hacer esta travesía de 5 años realmente inolvidable y divertida.
A todos los que creyeron en mi y siempre me apoyaron.
A Serguei Brin y Larry Page por crear el buscador que ha hecho más fácil mi vida durante toda la
universidad y en especial en mi etapa de investigador y desarrollador.
A todos,
¡Gracias!
iv
RESUMEN
En la actualidad, la televisión digital va más allá de los contenidos televisivos, pues proporciona
servicios multimedia que pueden ser interactivos, lo que implica que los usuarios finales han de
tener la capacidad de interactuar con la transmisión y requiere el empleo de dispositivos de
hardware y software diseñados específicamente con estos fines.
Desde el año 2013 se comenzó a desplegar en Cuba la televisión digital terrestre. En dicho
despliegue se ha utilizado la norma china GB 20600-2006 o DTMB, utilizando dispositivos con
software de fabricación china para la recepción de la misma. Al no disponer del código fuente del
software de estos dispositivos, o la documentación del hardware de los mismos se imposibilita el
desarrollo de elementos que aporten valor agregado a la televisión digital cubana.
Como parte de la informatización del país y de la filosofía y necesidad de lograr mayor
independencia tecnológica es necesario que los propios desarrolladores cubanos creen una
solución de software y hardware para recibir la señal digital con contenidos interactivos usando el
estándar HbbTV. En varias universidades del país se han hecho avances con este fin, en especial
en la Universidad Central Marta Abreu de Las Villas, donde desde hace unos años se desarrolla
un set-top box utilizando un sistema operativo de propósito general.
Debido a la necesidad del desarrollo de un sistema de software para un set-top box, en el presente
trabajo se hace un estudio del estándar HbbTV y se propone una arquitectura de software, lo que
permitirá tener una base para su posterior implementación y de este modo, lograr mayor
independencia tecnológica y alcanzar la posibilidad de agregar cuantos servicios necesite la
sociedad cubana.
Palabras Clave: HbbTV, interactividad, set-top box, arquitectura, televisión digital
v
ABSTRACT
Currently, digital television goes beyond television content, because it provides multimedia
services that can be interactive, which implies that end users must have the ability to interact with
the transmission and requires the use of hardware devices and software designed specifically for
these purposes.
Since 2013, digital terrestrial television began to be deployed in Cuba. In this deployment has been
used the Chinese standard GB 20600-2006 or DTMB, using devices with Chinese-made software
for the reception of it. By not having the source code of the software of these devices, or the
documentation of their hardware, it is impossible to develop elements that add value to Cuban
digital television.
As part of the computerization of the country and the philosophy and need to achieve greater
technological independence it is necessary that the Cuban developers themselves create a software
and hardware solution to receive the digital signal with interactive content using the HbbTV
standard. Advances have been made in this regard for several universities in the country, especially
at the Marta Abreu Central University in Las Villas, where a set-top box has been developed for a
few years using a general-purpose operating system.
Due to the need for the development of a software system for a set-top box, in the present work a
study of the HbbTV standard is made and a software architecture is proposed, which will allow to
have a base for its later implementation and of this way, achieve greater technological
independence and achieve the possibility of adding as many services as Cuban society needs.
Key words: HbbTV, interactivity, set-top box, architecture, digital television
vi
ÍNDICE
Pensamiento ....................................................................................................................... i
Dedicatoria ........................................................................................................................ii
Agradecimientos ................................................................................................................ iii
Resumen ...........................................................................................................................iv
Abstract ............................................................................................................................ v
Introducción ...................................................................................................................... 1
Capítulo 1: La Televisión Digital Terrestre, su interactividad ................................................. 4
1.1 Televisión Digital Terrestre ................................................................................... 4
1.2 Estándares de televisión digital .............................................................................. 6
1.2.1 DVB-T.......................................................................................................... 8
1.2.2 ATSC ........................................................................................................... 9
1.2.3 ISDB-T ....................................................................................................... 10
1.2.4 DTMB ........................................................................................................ 11
1.3 Televisión Interactiva .......................................................................................... 12
1.4 Estándares de televisión interactiva....................................................................... 15
1.4.1 Smart TV .................................................................................................... 15
1.4.2 MHP ........................................................................................................... 16
1.4.3 Ginga .......................................................................................................... 17
1.4.4 MHEG ........................................................................................................ 18
1.4.5 HbbTV........................................................................................................ 19
1.5 Conclusiones Parciales ........................................................................................ 21
Capítulo 2: Descripción del estándar HbbTV ...................................................................... 22
2.1 Introducción al estándar HbbTV ........................................................................... 22
2.2 Plataforma HbbTV.............................................................................................. 23
vii
2.3 Visión general .................................................................................................... 24
2.4 Arquitectura de la plataforma HbbTV ................................................................... 26
2.4.1 Sistema ....................................................................................................... 26
2.4.2 Terminal ..................................................................................................... 27
2.4.3 Capacidades mínimas y opcionales del terminal .............................................. 30
2.5 Fundamentos tecnológicos del estándar HbbTV ..................................................... 30
2.6 Señalización de aplicaciones ................................................................................ 32
2.6.1 Señalización AIT ......................................................................................... 36
2.6.2 DSM-CC ..................................................................................................... 40
2.6.3 Stream Events .............................................................................................. 42
2.7 Conclusiones Parciales ........................................................................................ 44
Capítulo 3: Propuesta de la Arquitectura ............................................................................ 45
3.1 Soluciones de Pago ............................................................................................. 47
3.1.1 Tara Systems ............................................................................................... 48
3.1.2 Ocean Blue Software .................................................................................... 49
3.1.3 Vewd .......................................................................................................... 50
3.2 Arquitectura propuesta ........................................................................................ 51
3.2.1 Capa de Servicios ......................................................................................... 53
3.2.2 Entorno de Ejecución.................................................................................... 56
3.3 Propuesta de Tecnologías que se pueden utilizar para la implementación. ................. 57
3.3.1 Sistema Operativo ........................................................................................ 57
3.3.2 TVHeadend ................................................................................................. 57
3.3.3 Chromium ................................................................................................... 58
3.4 Conclusiones Parciales ........................................................................................ 58
Conclusiones ................................................................................................................... 60
viii
Recomendaciones ............................................................................................................ 61
Bibliografía ..................................................................................................................... 62
1
INTRODUCCIÓN
En la actualidad existen varias tecnologías que añade interactividad en la transmisión de video, ya
sean estos por un medio de difusión como la televisión digital terrestre (TDT) con los diferentes
estándares a nivel mundial, o por multidifusión (multicast) con la televisión bajo un protocolo de
internet (IPTV). Es por eso que hoy en día es común escuchar el concepto de televisión híbrida o
televisión conectada, que no es más que un sistema que une lo mejor de la televisión tradicional,
ahora en formato digital, con lo mejor de internet.
Dentro de las diferentes plataformas para generar y exhibir interactividad en la televisión existen
unas abiertas y/o libres y otras cerradas o propietarias. Por ejemplo, las diferentes marcas de
fabricantes de televisores o receptores de televisión han creado y adaptado sistemas de
interactividad propietarias, comúnmente conocidas como Smart TV. Ejemplo de estas plataformas
interactivas propietarias tenemos a Samsung Smart TV, Sony Smart TV, Apple TV, Google TV,
entre otras.
Un problema que siempre han tenido estas plataformas propietarias es que son cerradas y cada
fabricante crea su propio estándar, esto conlleva a que para desarrollar una aplicación compatible
con estas plataformas hay que desarrollarla para cada una de ellas por separado.
Para solucionar este problema de compatibilidad, y otros existentes en estas plataformas
propietarias, y que todas estas tecnologías puedan converger en un mismo estándar y facilitar su
desarrollo, así como abaratar el costo de desarrollo de aplicaciones, en Europa se creó el estándar
HbbTV (Hybrid Broadcast Broadband TV, por sus siglas en inglés). Este estándar es una
plataforma de emisión de contenidos bajo demanda, combinando los servicios clásicos de
radiodifusión (broadcast) y banda ancha (broadband). Se trata de una iniciativa de la industria para
armonizar la emisión de contenido interactivo por radiodifusión y por banda ancha, y la entrega
de entretenimiento gratuito para el consumidor a través de televisores inteligentes (Smart TV) o
televisores conectados a cajas decodificadoras (set-top boxes STB). A través de la adopción de
HbbTV, los consumidores son capaces de acceder a nuevos servicios de entretenimiento, que
pueden ser brindados por las estaciones de televisión, por servidores de internet o por los
fabricantes de televisores o set-top boxes, los servicios de entretenimiento incluyen: video bajo
demanda (VoD), publicidad interactiva, personalización, votaciones, juegos y redes sociales, así
2
como servicios relacionados con la programación, como el teletexto digital y las guías de
programación electrónica (EPG).
En la televisión digital terrestre (TDT) el panorama es similar, existen varios sistemas de
interactividad de acuerdo a cada estándar algunos quizás más desarrollados y explotados que otros,
uno de ellos que quizás no tuvo tanta difusión y que actualmente se está dejando de utilizar es
MHP (Multimedia Home Platform) adoptado como sistema de interactividad por el estándar de
televisión digital europeo DVB (Digital Video Broadcasting). En América Latina, tenemos al
sistema de interactividad de la norma japonesa-brasileña ISDB-Tb (International System Digital
Broadcasting, Terrestrial, Brazilian version) denominado Ginga.
Desde el año 2013 se ha venido desplegando en Cuba la TDT, para ello se ha implementado la
norma GB 20600-2006 o DTMB y se ha incorporado un nivel muy básico de interactividad para
la difusión de información. Sin embargo, esta interactividad no sigue ningún estándar conocido
que permita el enriquecimiento de la televisión digital (DTV) en Cuba.
En Cuba no existe un sistema tecnológico que permita la implementación de la interactividad en
la televisión digital terrestre. En tal sentido se hace necesario la determinación de un estándar que
ordene la implementación de la interactividad, y una plataforma de hardware y software que la
implemente, tanto en la transmisión como en la recepción.
Los órganos directivos de las telecomunicaciones en Cuba han dado ya serios pasos en cuanto al
establecimiento de una norma que ordene la implementación de la interactividad en la televisión
digital. Al respecto parece ser una tendencia que se acepte el estándar HbbTV (estándar europeo)
con las adaptaciones que sean necesarias de acuerdo a las exigencias del país.
Sin embargo, no se ha avanzado con igual velocidad en el desarrollo de las tecnologías que
permitan la implementación de esta norma en los equipos transmisores y receptores de la señal
televisiva.
A partir de lo anterior podemos expresar el siguiente Problema de Investigación que justifica
este trabajo de diploma:
No existe en Cuba un equipo receptor de la señal de Televisión Digital Terrestre con la
norma DTMB que soporte la norma de interactividad HbbTV.
3
Partiendo del problema anteriormente expuesto podemos definir los siguientes objetivos general y
específicos:
Objetivo General:
Proponer una arquitectura para un receptor de Televisión Digital Terrestre (DTMB) que
soporte el estándar de interactividad HbbTV.
Objetivos específicos:
1. Revisar el estado actual de la TDT a nivel internacional y los estándares de
interactividad más utilizados.
2. Estudiar el estándar de interactividad HbbTV.
3. Proponer una arquitectura de receptor de TV digital que soporte HbbTV.
4. Proponer algunas tecnologías que pudiesen ser usadas en la implementación de la
arquitectura.
Para dar cumplimiento a nuestros objetivos, el presente trabajo de divide en los tres capítulos
siguientes:
• Capítulo 1: Se hace un estudio del funcionamiento de la televisión digital terrestre y se
detalla a grandes rasgos los principales estándares de televisión utilizados en el mundo, así
como la distribución de los mismos. De igual forma, se investiga sobre las características
del funcionamiento de los estándares de interactividad más utilizados.
• Capítulo 2: Se describe el estándar hibrido de televisión interactiva HbbTV. Se estudia de
forma general como funciona el mismo, así como los requerimientos mínimos que debe
tener un terminal hibrido. Se mencionan los fundamentos tecnológicos con los que está
conformado el estándar y la forma de señalizar las aplicaciones interactivas.
• Capítulo 3: En este último capítulo se exponen soluciones de software para dispositivos
receptores, aunque los encontrados son de pago. Se propone una arquitectura de software
para un dispositivo receptor de televisión digital con soporte para el estándar HbbTV y se
detalla las funciones de cada componente de la misma. Además, se proponen algunos
softwares que con algunas modificaciones pueden ser parte de la solución.
4
CAPÍTULO 1: LA TELEVISIÓN DIGITAL TERRESTRE, SU
INTERACTIVIDAD
Con el avance acelerado de las tecnologías en los últimos años se ha aumentado el uso de los
ordenadores y teléfonos inteligentes, sobre todo, para navegar en internet, por lo que estos equipos
han sido una amenaza real para el mercado del entretenimiento audiovisual (Morante, 2011). Todo
el mundo relacionado con la venta de televisores ve necesaria una medida para poder seguir
viviendo de su trabajo. La solución tomada es la de la convergencia.
Dicha convergencia consistiría en combinar la experiencia multimedia, introduciendo tanto
contenido de radiodifusión como hasta la fecha y añadiéndole contenido en internet de forma que
se pudiera producir una interactividad con el televisor demandado por el propio usuario.
Esta interacción se realizaría con el propio mando de televisión, y se trataría de realizar mediante
una interfaz unificada. El objetivo sería convertir la televisión en un ordenador de propósito
específico.
En el presente capítulo se hace una revisión de los principales estándares de televisión digital
terrestre utilizados en el mundo, así como los estándares de interactividad más utilizados.
1.1 TELEVISIÓN DIGITAL TERRESTRE
La televisión digital terrestre TDT transmite su señal íntegramente con tecnología digital, lo que
mejora la calidad tanto de audio como de vídeo y posibilita incorporar servicios interactivos,
permitiendo al usuario interactuar con la programación ya sea en equipos receptores fijos,
portátiles o móviles; con la característica que el televidente ahora puede disfrutar de una señal
mucho más robusta, sin ruidos, sin interferencias, ni doble imagen, perfeccionando de este modo
los contenidos que el espectador está visualizando.
La TDT permite hacer un uso más eficiente del espectro radioeléctrico al transmitir mediante el
proceso de multiplexación más de una señal televisiva. El espacio antes empleado por una sola
señal de televisión (canal) pasa a llamarse canal múltiple digital o múltiplex. El número de
programas transmitidos en cada canal múltiple dependerá de la relación de compresión empleada.
5
La compresión también ha hecho viable la transmisión de señales en alta definición, que requiere
un ancho de banda mayor que la televisión estándar.
Pese a las ventajas de la TDT, la señal digital no es más resistente que la analógica a posibles
interferencias en el medio de transmisión, debido a su naturaleza de señal electromagnética. La
diferencia radica en la manera de codificar la información siguiendo algoritmos lógicos que
permiten posteriormente identificar y corregir errores. Pero no siempre esto es posible, cuando la
perdida de información es muy grande, con la televisión analógica apenas se veía la imagen o se
escuchaba el audio; con la TDT simplemente no se verá o escuchará nada.
Figura 0.1 Funcionamiento de la TDT
La figura 1.1 refleja el esquema de funcionamiento de la televisión digital terrestre. Los contenidos
audiovisuales se generan en la etapa de producción y postproducción, a lo que sigue la etapa de
empaquetado de los contenidos por parte de los radiodifusores.
A continuación, se llevan a cabo las actividades de gestión del multiplexado (múltiplex) siguiendo
el estándar ISO/IEC 13818-1 como muestra la figura 1.2 (Standard, 2000), donde se combinan los
programas y servicios que integran cada uno de los canales múltiples reservados a las
transmisiones de TDT (Villamarín et al., 2013). Una vez integrado cada uno de los canales
múltiples, la señal es transmitida por el operador de red.
6
Figura 0.2 Combinando dos TS mediante multiplexación
La recepción de la señal de TDT se realiza en los hogares que dispongan de una antena, individual
o colectiva, adaptada a este tipo de transmisiones. Finalmente, la señal recibida pasa por el equipo
de descodificación para que pueda ser interpretada por un televisor convencional.
Adicionalmente, para lograr la prestación de servicios interactivos, el sistema de TDT puede
dotarse de un canal de retorno que permita la comunicación en sentido ascendente (desde el usuario
al radiodifusor). A modo de ejemplo, pueden utilizarse como canal de retorno la red telefónica
convencional, la red de telefonía móvil 3G, 4G, la Wifi o una conexión ADSL.
1.2 ESTÁNDARES DE TELEVISIÓN DIGITAL
En todo el mundo se han desarrollado varios estándares de televisión digital, los cuales son
básicamente cinco (ver Figura 1.3).
7
Figura 0.3 Distribución de los Estándares de TV Digital en el mundo (“Digital Terrestrial Television (DTT) - World Map (high
resolution),” 2019.)
Los cinco estándares más predominantes en el mundo son los siguientes:
• Estándar Americano, ATSC (Advanced Television Systems Committee).
• Estándar Europeo, DVB (Digital Video Broadcasting).
• Estándar Europeo, DVB-T2 (Digital Video Broadcasting, II version.).
• Estándar Japonés, ISDB-T (Integrated Services Digital Broadcasting).
• Estándar Chino, DTMB (Digital Terrestrial / Television Multimedia Broadcasting).
La televisión digital terrestre está operando mundialmente con cinco estándares. La plataforma
usada en Norteamérica y algunos países centroamericanos es ATSC; ISDB-T en Japón y Filipinas.
ISDB-Tb (variante del ISDB-T) en Brasil y la mayoría de los países latinoamericanos: Perú,
Argentina, Chile, Venezuela, Ecuador, Costa Rica, Paraguay, Bolivia, Uruguay, Nicaragua y
Guatemala, con la excepción de Colombia, Guyana, Surinam, Panamá, Honduras, El Salvador y
México (Zapata, 2014). DTMB en la República Popular China, Hong Kong, Macao y Cuba. DVB-
T en los países europeos, Australia, partes de África y países de América Latina: Colombia, y
Panamá, también algunos países que utilizan este estándar están comenzando hacer pruebas y han
8
adoptado oficialmente DVB-T2, que es un estándar más robusto que su anterior versión. El resto
del mundo aún no se ha decidido (Villamarín et al., 2013).
1.2.1 DVB-T
En la década de los ochenta, una organización internacional conjunta de varias empresas en Europa
realizó varios proyectos para hacer mejoras a la televisión analógica, lo que eventualmente llevó a
la formación del proyecto DVB (Digital Video Broadcasting). Este proyecto desarrolló varias
normas para transmisión digital terrestre, satelital, por cable y portátil, las cuales se categorizan en
dos generaciones. Durante los años noventa y principios del 2000, el DVB desarrolló la primera
generación de estándares de difusión digital para televisión.
En concreto, el estándar DVB-T para transmisión digital terrestre se desarrolló en el año 2000
(ETSI, 2009). En este estándar se permite la transmisión de televisión en alta definición como
también televisión convencional por canales terrestres. Además, se pueden difundir programas de
radio, así como transmisión de datos para diferentes fines, ya sea entretenimiento o negocios. Para
la difusión terrestre el sistema fue diseñado para operar dentro del espectro UHF utilizado para
transmisión analógica. Aunque el sistema fue desarrollado para canales de 8 MHz, se pueden
utilizar canales de 6 y 7 MHz con sus correspondientes capacidades de datos (El-Hajjar and Hanzo,
2013).
El sistema es robusto a interferencia de señales con retrasos, a ecos resultantes de reflexiones
causadas por el terreno o edificios, y a señales provenientes de transmisores del arreglo de red de
frecuencia única (SFN por sus siglas en inglés) (Ladebusch and Liss, 2006).
Una red SFN permite obtener gran eficiencia en el uso del espectro, ya que todos los transmisores
pueden operar en la misma frecuencia sin causar interferencia. Esto significa que transmisores
adyacentes pueden operar utilizando la misma frecuencia, lo que conlleva que estos deben estar
sincronizados en la frecuencia y utilizar el mismo tamaño del símbolo OFDM (modulación
ortogonal por división de frecuencias), que es la modulación utilizada por este estándar.
La segunda generación de este estándar es llamado Difusión de Video Digital - Terrestre de
segunda generación (DVB-T2), el cual fue publicado en el 2008. Los cambios más significativos
con respecto a la primera generación son: mejora de la eficiencia (tiene un 97 % más de capacidad),
9
cambio al formato MPEG-4 AVC, llamado también H.264; permite modulación en 256QAM y
tiene más opciones para el intervalo de guarda (Chie, Zambrano and Medina, 2015).
Las dos generaciones de estos estándares se pueden implementar a la vez, como lo han hecho
varios países incluyendo Colombia, España y Francia.
1.2.2 ATSC
El estándar de televisión digital ATSC fue desarrollado por el Comité de Sistemas Avanzados de
Televisión en los Estados Unidos. Este sistema fue diseñado para transmitir video y audio en alta
definición y datos secundarios dentro de un solo canal de 6 MHz. El sistema fue desarrollado
para difusión terrestre y para distribución por cable (Richer et al., 2006). Este tiene un
rendimiento de datos de 19.4 Mbit/s en un canal de televisión por cable. Se tienen dos modelos
de operación: el modo 8-VSB de difusión terrestre que es más inmune a interferencias con el
sistema NTSC de televisión analógica y el modo 16-VSB de mayor cantidad de datos
desarrollado para distribución en canales por cable.
El estándar ATSC utiliza video en formato MPEG y el estándar ATSC AC-3, compresión digital
de audio, para la codificación del audio (Whitaker, 2012). El flujo de bits está constituido por
paquetes multiplexados de flujo de bits de video, audio y datos. La estructura de estos flujos de
bits también contiene información de señalización que se emplea para paquetizar el video, audio,
e información de servicio en diferentes servicios dentro del mismo formato multiplexado.
Aunque el sistema fue desarrollado y probado para canales de 6 MHz, se puede elegir entre canales
con un ancho de banda de 6, 7 y 8 MHz, con su correspondiente capacidad de datos.
Para la difusión terrestre, el sistema fue diseñado para permitir la asignación de transmisores
digitales adicionales para cada transmisor NTSC con una cobertura parecida, y con mínima
perturbación en el servicio NTSC en cobertura. Esta capacidad es alcanzada y excedida cuando se
eligen cuidadosamente las características de transmisión del sistema en un ambiente que contiene
transmisiones en el sistema NTSC.
El sistema ATSC es eficiente y capaz de operar bajo varias condiciones, como por ejemplo se
diseñó para resistir varios tipos de interferencia: sistemas existentes de televisión analógica NTSC,
ruido blanco, ruido de fase y reflexiones continuas por multitrayectorias (Velásquez l., Zambrano
10
M. and Medina C., 2014). El sistema también fue diseñado para ofrecer eficiencia en el uso del
espectro y facilidad en la planificación de frecuencias.
Esta norma utiliza un esquema de modulación de una sola portadora llamado modulación 8-VSB
(modulación de banda vestigial de nivel 8). Además, el sistema fue diseñado para implementarse
en redes de frecuencias múltiples o MFN (Bretl et al., 2006).
Este estándar es utilizado en los Estados Unidos y todos sus territorios, es además utilizado en
Canadá, México, El Salvador y Corea del Sur.
1.2.3 ISDB-T
En Japón, la ARIB (Asociación de Industrias y Empresas de Radio) aprobó las especificaciones
para el sistema de difusión digital terrestre llamado ISB-T (Difusión Digital de Sistemas Terrestres
Integrados) en 1998 (Fay, Kutzner and Pizzi, 2014).
Este estándar fue diseñado para proveer audio, video y servicios multimedia. Para integrar
diferentes requerimientos de servicios, el sistema de transmisión ofrece una selección de esquemas
de modulación y protección a errores que pueden ser seleccionados y combinados para cumplir
con los requerimientos que se establezcan.
Para la difusión terrestre, el sistema fue diseñado para brindar televisión digital, programas de
audio y ofrecer servicios multimedia en los que varios tipos de información digital como video,
audio, texto y programas de computadora se integran. También se busca proveer una recepción
estable a través de receptores móviles compactos, ligeros y económicos, en adición a los receptores
integrados utilizados en el hogar.
El sistema ISDB-T utiliza MPEG-2 como codificación de video y la codificación avanzada de
audio MPEG-2 (ACC). También utiliza un flujo de transporte MPEG-2 para encapsular los datos.
El sistema fue desarrollado y probado para canales de 6 MHz, pero se pueden elegir diferentes
anchos de banda de canal con su correspondiente capacidad de datos.
ISDB-T es un sistema basado en modulación OFDM, pero utiliza una transmisión de banda
segmentada OFDM (BST-OFDM), la cual divide el ancho de banda disponible en bloques de
frecuencia llamados segmentos (Takada and Saito, 2006). Cada segmento tiene un ancho de banda
correspondiente a 1/14 del canal de televisión terrestre disponible.
11
Una característica fundamental de BST-OFDM es la habilidad de utilizar diferentes modulaciones
y parámetros de codificación en uno o más segmentos OFDM. Esto lleva a la idea de transmisiones
jerárquicas. ISDB-T utiliza transmisiones jerárquicas, donde los parámetros de transmisión
incluyen el esquema de modulación de las portadoras OFDM, la razón de codificación del código
interno y la duración intercalada del tiempo, la cual puede ser especificada para cada segmento de
datos OFDM. ISDB-T define el máximo de tres capas o tres grupos de segmentos diferentes
conocidos como capa A, B y C, para transmitir en el mismo canal al mismo tiempo. Los bits de
video codificado normalmente tienen diferente sensitividad de error, ya que son resultado de
diferentes efectos. Por lo tanto, los bits más sensitivos son normalmente codificados por códigos
FEC más fuertes y pueden ser mapeados a esquemas de modulación con menos errores.
Cada segmento de datos tiene su propia protección de error y tipo de modulación (QPSK, DQPSK,
16-QAM o 64-QAM). Cada segmento posee sus propios requerimientos de sistema. Un número
de segmentos pueden ser combinados para proveer servicios de banda ancha.
Este estándar de televisión digital fue tomado como base para elaborar un estándar nuevo en Brasil,
el cual se utiliza en varios países de América del Sur. Este estándar llamado ISDTV, por Sistema
Internacional de Televisión Digital, utiliza la misma tecnología de transmisión que el estándar
ISDB-T.
La diferencia ente ISDTV y el ISDB-T radica en el uso de H.264 como codificación del video en
vez del MPEG-2 utilizado en el ISDB-T. Adicionalmente, ISDTV introdujo una plataforma
interactiva conocida como Ginga, y se especificó la tecnología WiMAX como el estándar para el
canal de retorno de los servicios interactivos.
Este estándar fue elegido en algunos países de Asia y en muchos de Centro y Suramérica,
incluyendo Brasil y Argentina.
1.2.4 DTMB
En China, el desarrollo de la televisión digital comenzó en el año 1992 cuando el gobierno chino
emitió una iniciativa para este estudio. En el 2006 se anunció el estándar de televisión para
terminales fijos y móviles llamado DTMB (Digital Terrestrial Multimedia Broadcast), luego de
extensivas pruebas en campo y laboratorio (Standard, 2007).
12
El DTMB surge de la fusión entre los estándares ADTB-T (desarrollado por la Universidad de
Shanghai JiaoTong, Shanghai), DMB-T (desarrollado por la Universidad Tsinghua, Beijing) y el
TiMi (Terrestrial Interactive Multiservice Infrastructure), que es el estándar que propuso la
Academia de Ciencias de Radiodifusión en el año 2002. Además, se hizo un estudio profundo de
los estándares DVB y ATSC para tomar los mejores aspectos de estos. En china la utilización del
estándar se hizo obligatoria en el año 2007.
El estándar DTMB fue diseñado para soportar tanto recepción fija como móvil. Por lo tanto, fue
desarrollado un sistema flexible capaz de difundir un número de programas en alta definición
combinados con varios canales convencionales SD y otro contenido multimedia.
Además de las funciones básicas del servicio de televisión tradicional, el DTMB da cabida a
nuevos servicios adicionales utilizando el sistema de radiodifusión de televisión. El sistema DTMB
es compatible con la recepción fija (cubierta y al aire libre) y móvil de la Televisión Digital
Terrestre.
Este estándar utiliza tecnologías que mejoran su rendimiento, como por ejemplo: un código
pseudo-aleatorio de ruido (PN- Pseudo-randomNoise) como intervalo de guarda que permite una
sincronización más rápida del sistema y una estimación de canal más precisa; codificación LDPC
(Low-Density Parity- Check) como protección contra errores; modulación TDS-OFDM (Time
Domain Synchronization - Orthogonal Frequency Division Multiplexing) que permite la
combinación de radiodifusión en SD, HD y servicios multimedia, etc. (Standard, 2007).
Este sistema da flexibilidad a los servicios que se ofrecen, al soportar la combinación de Redes de
Frecuencia Única (SFN) y Redes de Frecuencias Múltiples (MFN). Los diferentes modos y
parámetros pueden ser escogidos en base al tipo de servicio y el entorno de la red (Song et al.,
2007). La tasa de transmisión de bits se encuentra entre 4.8 Mbit/s hasta 32.5 Mbit/s.
1.3 TELEVISIÓN INTERACTIVA
Podemos definir la TV interactiva (iTV por sus siglas en inglés) como una forma de ver la
televisión en la cual el usuario puede disfrutar de contenidos y servicios adicionales sumados a los
contenidos de la televisión convencional, que tradicionalmente ha sido un medio de comunicación
unidireccional. Estos contenidos y servicios adicionales venían siendo ofrecidos por el
radiodifusor, pero hoy día también pueden ser ofrecidos por los fabricantes de los terminales o por
13
terceros. El verdadero valor de la iTV reside en darle al usuario la oportunidad de participar y de
interactuar con los contenidos que está recibiendo. (Tomasi, 2012)
La televisión interactiva permite al televidente ver informaciones asociadas al contenido
audiovisual, la programación de los canales, participar en concursos, votaciones, comprar
productos a través de propio televisor e incluso participar en los propios programas de televisión
con el mando a distancia. La interactividad es posible gracias a aplicaciones que complementan la
programación, siendo el usuario el que decide si quiere o no verlos, y cuándo verlos.
La interactividad ofrece al espectador la posibilidad de personalizar el contenido que muestra su
televisor, bien sea accediendo a información enviada durante el proceso de emisión pero que sólo
se hace visible si el espectador lo desea, o bien accediendo a servidores con los que puede
intercambiar información, a través de un canal de retorno utilizando el televisor como interfaz de
salida.
La principal ventaja de la televisión interactiva, radica en la posibilidad de acceder a un amplio
conjunto de servicios públicos o privados a través del televisor, con un único terminal y un mando
a distancia. Otra ventaja de la interactividad radica en que es el propio usuario el que decide si
quiere o no ver los servicios interactivos y los contenidos asociados a la interactividad (por
ejemplo, si quiere o no ver los mensajes que los usuarios envían a los programas tipo SMS).
El grado de interactividad dependerá de las posibilidades que ofrezcan los contenidos adicionales
que hacen que la TV sea interactiva y de las características del sistema, así como de la terminal
del usuario. En dependencia de las características y capacidades de la iTV se pueden clasificar en
tres tipos o niveles:
1. Interactividad básica o local: El televidente solo puede interactuar con el contenido que
recibe a través de la transmisión por difusión o que se encuentra almacenado de alguna
manera en el receptor (Ej: aplicaciones propias del fabricante del receptor). El contenido
multimedia se procesa de forma local y no hay ninguna vía de comunicación entre el
receptor y el radiodifusor o un terceo. Su ejemplificación más sencilla es la Guía
Electrónica de Programas (EPG por sus siglas en inglés) o conocida comúnmente como
“cartelera”. También pertenecen a este nivel de interactividad otros servicios como: el
14
teletexto digital o closed caption, servicios de noticias, estado del tiempo, entre otros. Este
nivel está fuertemente ligado a los servicios de televisión públicos.
2. Interactividad con canal de retorno o interactividad remota: Requiere la existencia de un
canal de retorno, que no necesariamente debe ser de banda ancha, se usa exclusivamente
para enviar información de retroalimentación (Sánchez Millo et al., 2018). Este nivel de
interactividad incorpora información ligada a contenidos de los programas que se están
emitiendo, con los cuales el televidente es capaz de interactuar, pero a diferencia de la
interactividad local, puede enviar información a través del canal de retorno. Este nivel de
interactividad es muy usado por las cadenas de televisión para medir el índice de audiencia,
realizar encuestas, permitir la participación en concursos, votar en shows televisivos,
enviar información estadística de programas deportivos, entre otros (Pafundi, Debora G.
Kantor, Mariana r. Marcalettu, 2013).
3. Interactividad avanzada o interactividad completa: Este nivel de interactividad es la que le
permite al televidente disfrutar de una iTV plena. Es imprescindible contar con un canal de
retorno de banda ancha. Este canal es bidireccional por lo que el televidente podrá enviar
y recibir información personalizada, entre ellas se pueden enviar aplicaciones interactivas.
Esta interactividad es la más compleja y permite la inserción en la televisión de todos los
servicios que se desee agregar. Es posible agregar servicios de mensajería, video bajo
demanda (VoD por sus siglas en inglés), comercio electrónico, entre otros. En este caso las
aplicaciones no tienen necesariamente que pertenecer a las cadenas de televisión, sino que
pueden pertenecer a terceros y operar exclusivamente por el canal de retorno o por ambos
canales en caso de asociaciones entre terceros y el radiodifusor.
Desde la creación del Teletexto por la BBC (British Broadcasting Company) en el año 1973 (López
de Zuazo Algar, 2000), los radiodifusores siempre han intentado desarrollar nuevas formas de
llegar a los tele-espectadores. La gran oportunidad se produce con la llegada de la televisión digital.
Al transformar la señal de televisión analógica en una señal digital ya es posible incorporar
fácilmente flujos de datos en la señal de radiodifusión (Standard, 2000). Estos flujos de datos son
recibidos, decodificados e interpretados en los receptores. Lo que se hacía necesario eran
estándares que definieran los sistemas a utilizar para poder definir la parte de televisión interactiva.
15
1.4 ESTÁNDARES DE TELEVISIÓN INTERACTIVA
Para normalizar el desarrollo de la televisión interactiva se han creado varios estándares, para así,
de esta forma, mejorar y hacer viable el desarrollo de esta tecnología.
1.4.1 Smart TV
La televisión inteligente (traducido del inglés "Smart TV") en si no es un estándar, sino que así se
les conocen a aquellos televisores que integran Internet y la televisión digital (en especial, a la
televisión 3D) y al set-top box (STB), permitiendo así la convergencia tecnológica entre los
ordenadores, estos televisores y el STB. Estos dispositivos se centran en los medios interactivos
en línea, en la televisión por Internet y en otros servicios como el vídeo a la carta.
Un dispositivo de Smart TV puede hacer referencia a dos conceptos diferentes; por un lado, puede
referirse a un televisor que cuenta con la integración de Internet, pero por el otro, también puede
hacer referencia a un set-top box para la televisión que ofrece una capacidad de computación más
avanzada y una mayor conectividad que un conjunto básico de televisión contemporánea. (Arce,
2014)
Un televisor inteligente permite instalar y ejecutar aplicaciones avanzadas o plugins basados en
una plataforma específica, tal como haría el sistema informático de un ordenador integrado en el
televisor o una PC con pantalla "grande". Los televisores inteligentes ejecutan un sistema operativo
o el software completo de un sistema operativo móvil, ofreciendo una plataforma para el
desarrollador de software.
En la mayoría de los casos, los dispositivos Smart TV permiten al usuario:
• Entregar contenidos de otros equipos o dispositivos de almacenamiento a la red, como
fotografías, películas y música utilizando un programa de servicio DLNA (Digital Living
Network Alliance), como Windows Media Player en el ordenador o NAS (Network
Attached Storage), o a través de iTunes.
• Proporcionar acceso a servicios basados en Internet, mediante IPTV, así como buscar y
navegar por Internet, por los servicios de vídeo a la carta, EPG, personalización de
contenidos, redes sociales y otras aplicaciones multimedia.
• Visualizar los contenidos en alta definición.
16
• Lanzar aplicaciones asociadas en un canal concreto, como vídeos relacionados con el
contenido, sistemas de votaciones, sistemas de apuestas y participación en concursos,
publicidad interactiva.
• Grabar en disco duro interno o externo USB los servicios que se están emitiendo en un
momento determinado o copiarlos de Internet.
• Reproducir el contenido de vídeos o música almacenado en un dispositivo USB.
• Instalar aplicaciones sobre la plataforma, como por ejemplo juegos, que se pueden hacer
correr en cualquier momento.
• Facilitar las compras realizadas en Internet.
• Controlar de forma remota el televisor con el móvil del usuario, mediante aplicaciones
desarrolladas por los dispositivos que cuentan con Android y iPhone.
El principal problema de las Smart TV, al no ser un estándar único, reside en que se basa en un
modelo cerrado de aplicaciones. Es decir, cada marca crea su propio “estándar” por lo que una
misma aplicación tiene que ser creada de diferente forma en función de la marca en la que va a ser
ofrecida.
1.4.2 MHP
MHP es un estándar desarrollado por el proyecto DVB y estandarizado por la ETSI, que determina
una plataforma común para aplicaciones interactivas a través de televisión digital (Middleware and
Tv, 2011)
La solución aportada por MHP es independiente del proveedor de servicios interactivos y del
receptor de televisión digital utilizado (obviamente, ha de ser compatible con el estándar). De este
modo se fomenta la aparición de un mercado horizontal en el que aplicaciones, red de transmisión
y receptores MHP puedan ser proporcionados por proveedores y fabricantes independientes. El
sistema MHP, de código abierto, utiliza el lenguaje de programación Java para sus aplicaciones y
define las aplicaciones DVB-J, también denominadas Xlets, basadas en la Máquina Virtual de Java
(Muñoz, 2010).
DVB-MHP especificó una plataforma estándar basándose en el conocimiento acumulado de
experiencias anteriores y tratando de proveer mecanismos que faciliten su adopción en el mercado
de la forma menos traumática posible. Para ello, sus principios de funcionamiento se basan en la
17
definición de unos perfiles que marcan la evolución de la plataforma, junto una arquitectura y unos
procesos flexibles pensados para facilitar la portabilidad e interoperabilidad de aplicaciones, que
están sometidas a un ciclo de vida muy definido.
MHP consta de una serie de estándares que describen completamente el sistema de middleware
abierto de DVB. Se define el concepto de “perfil” como un área de aplicación y, como
consecuencia, con una serie de capacidades determinadas.
La mayoría de los países han abandonado este estándar, entre otras razones, porque algunas
empresas que participaron en la elaboración del estándar comenzaron a reclamar “royalties” por
las tecnologías que consiguieron introducir en el estándar y que tienen patentadas. En su momento
no reclamaron estos derechos, por lo que se habla de “patentes submarinas”. Algunos expertos
consideraron que, en estas condiciones, MHP no era viable (Suárez, 2009).
1.4.3 Ginga
En Brasil, a pesar de tener la norma de TVD ISDB-Tb, decidieron desarrollar un estándar propio
que dirigiera la implementación de la interactividad en su TDT. Dicho estándar es basado en MHP,
por lo que soporta los contenidos interactivos desarrollados mediante Xlets, aunque en este se
adiciona el lenguaje declarativo NCL (Nested Context Language) y el lenguaje procedimental
LUA (Sánchez Millo et al., 2018).
La incorporación de NCL a Ginga trae consigo la ventaja de incorporar servicios IPTV, televisión
bajo demanda y otros servicios broadcast-related para los cuales es necesario un canal de retorno.
Además, se puede destacar que los contenidos desarrollados con NCL pueden ser modificados en
tiempo de ejecución, lo que brinda dinamismo a todos los contenidos presentados. En Brasil se ha
desarrollado grandemente la cantidad de contenidos interactivos, especialmente los de comercio
electrónico, la salud y la educación entre otros (Sánchez Millo et al., 2018).
Desde su concepción, Ginga tuvo en consideración la necesidad de la inclusión social/digital y la
obligación de compartir el conocimiento de forma libre, por lo que “Ginga es una especificación
abierta, de fácil aprendizaje y “libre de royalties” y así lo declara en su sitio web oficial (Sobre
Ginga | Ginga, no date). El estándar adopta la licencia GPL versión 2 y el laboratorio TeleMídia
garantiza el acceso permanente a toda la evolución del código publicado en la comunidad Ginga.
18
1.4.4 MHEG
MHEG es un estándar abierto de middleware diseñado específicamente para poder desarrollar
servicios de iTV digital. La ISO lo desarrolló y estandarizó a mediados de los años 90 como parte
del esfuerzo de la DAVIC por estandarizar, proporcionar interactividad y navegación para
servicios de video bajo demanda.
MHEG es un estándar público que no está gravado con ningún tipo de derechos de uso, lo que
significa que ninguna organización reclamará royalties a quien lo use.
Conceptualmente MHEG quiso ser a las aplicaciones multimedia interactivas lo que el HTML a
las páginas web, es decir, un lenguaje común que permitiese la ejecución y presentación de
contenidos en cualquier receptor.
Se crearon varias versiones:
• MHEG-1: Esta es la original. Usa la notación ASN.1 (Abstract Syntax Notation One) para
definir las aplicaciones multimedia basadas en objetos. ASN.1 permite describir
estructuras de datos complejas con una sintaxis no ligada a ningún lenguaje de
programación. Después el compilador de ASN.1 traduce a un lenguaje particular (C, C++,
Java...)
• MHEG-3: Con esta versión se definió una máquina virtual estandarizada y la
representación de las aplicaciones de tal forma que era posible portarlas entre las distintas
plataformas (muy similar al funcionamiento de Java).
• MHEG-5: MHEG-1 y MHEG-3 eran conceptualmente algo complicados y la industria no
estaba preparada para implementar las características que ofrecían. MHEG-5 fue
publicado en 1997 como una versión simplificada de MHEG-1. Aun siendo una versión
simplificada, en la práctica fue tratada como un estándar independiente.
• MHEG-6: En 1998 se creó MHEG-6, que no era más que MHEG-5 con soporte Java para
el desarrollo de objetos de scripting. Se hizo creando un API de Java específico que era
capaz de manejar objetos MHEG. MHEG-6 no tuvo popularidad, pero fue la base de las
especificaciones publicadas por la DAVIC.
De todas las versiones de MHEG, la única que ha tenido éxito es MHEG-5, siendo éste el estándar
actual de iTV en el Reino Unido. Es una tecnología ya madura que cuenta con un mercado
19
desarrollado decenas de millones de receptores. El estándar ha sido adaptado al mercado del Reino
Unido por el DTG dando lugar al “MHEG-5 UK Profile version 1.06” (actualmente ETSI ES 202
184 v2.1.1), que es la base del servicio de televisión digital terrestre Freeview. MHEG también es
el estándar elegido en Freesat (Satélite, UK), Freeview Nueva Zelanda, Freeview Australia y TVB
Hong Kong (Tomasi, 2012).
Los perfiles broadcast de MHEG tienen un ciclo de vida de aplicación bastante simple ya que solo
puede haber una aplicación en ejecución. Una aplicación MHEG puede lanzar otras, pero al hacerlo
la aplicación “lanzadora” se finaliza. También puede haber aplicaciones de tipo auto arranque
(autostart), que se inician sin intervención del usuario al seleccionar un servicio (sintonizar un
canal).
Las aplicaciones se cargan en el aparato a través de un carrusel de objetos que se recibe por el
canal broadcast. La información a la que accede la aplicación es de tipo “incluido” cuando un texto
o gráfico forma parte de la aplicación o “referenciado” cuando el contenido es releído del carrusel.
Los datos cargados del carrusel pueden ir cambiando en determinados momentos lo que permite
aplicaciones mucho más dinámicas.
1.4.5 HbbTV
HbbTV (Hybrid Broadcast Broadband TV) es un proyecto paneuropeo de televisión híbrida que
ofrece a los usuarios un servicio de entretenimiento con la televisión, en la que es posible combinar
las emisiones de difusión (broadcast) de televisión con contenido de Internet mediante redes de
banda ancha (broadband). De esta manera los radiodifusores pueden proporcionar a los
espectadores vídeo bajo demanda, publicidad personalizada, juegos, información personalizada,
aplicaciones, etc.
El consorcio de HbbTV es una iniciativa lanzada por la Unión Europea de Radiodifusión (UER)
en el año 2009 y que proporciona una plataforma abierta para que los radiodifusores puedan ofrecer
sus servicios. Este consorcio está formado por radiodifusores y por otras muchas empresas del
sector como Sony, Samsung, Philips o Astra, entre otras.
El funcionamiento de HbbTV es sencillo y puede ejecutarse en todos los estándares de transmisión
del DVB (satélite, cable y terrestre), aunque se puede adaptar a otros estándares, como es el
ejemplo de ATSC (Chie, Zambrano and Medina, 2015). A partir de la señal transmitida, el receptor
20
obtiene el enlace con la dirección web donde se encuentra alojada la aplicación HbbTV, y accede
a ella a través de Internet. El usuario es el que decide si quiere acceder o no a la aplicación. En el
flujo de transporte, la dirección URL (Uniform Resource Locator) de la aplicación se transmite en
una tabla del MPEG 2 TS (MPEG 2 Transport Stream) llamada AIT (Application Information
Table).
Desde el punto de vista de las aplicaciones HbbTV existen dos tipos diferenciados (ETSI, 2018):
• Non-broadcast related: se trata de aplicaciones que no tienen una conexión directa (o
acceso) a los canales emitidos por las redes broadcast.
• Broadcast related: en este tipo, las aplicaciones sí que mantienen una relación y pueden
acceder al canal broadcast.
La primera versión de HbbTV, la versión 1.1, fue publicada por la ETSI (ETSI TS 102 796) en
junio del año 2010. Esta especificación se basa en normas ya existentes de otras entidades, como
OIPF (Open IPTV Forum), CEA (Consumer Electronics Association), DVB y W3C. Permite la
construcción de páginas web compatibles con los navegadores de los televisores, ya que se
construyen sobre el lenguaje CE-HTML (Consumer Electronic HTML), un estándar desarrollado
para los equipos de electrónica de consumo y que fue aprobado por el organismo W3C. También
se hace uso de JavaScript y CSS (Cascading Style Sheets).
La versión 1.5 se publicó en el año 2012. Esta nueva versión presentaba, como principales
novedades, el uso del estándar de streaming adaptativo MPEG DASH, la capacidad para poder
acceder a la EPG desde la propia aplicación interactiva, y mejoras en la integración de los servicios
de protección de contenidos (DRM, Digital Rights Management). También proporciona una mejor
experiencia con menos tiempos de espera y una mayor calidad en los vídeos a la carta.
En ese mismo año en España, el Foro Técnico de la Televisión Digital publicó la especificación
sobre los receptores de televisión digital terrestre para aplicaciones interactivas (Julia et al., 2017).
La redacción de este documento fue coordinada por la Asociación Española de Empresas de TV
Interactiva (AEDETI) y contó también con la participación de radiodifusores, empresas relevantes
del sector y fabricantes de receptores. En el documento se especifica también la utilización del
estándar HbbTV versión 1.5 para el desarrollo de Televisión Híbrida sobre TDT, así como las
cuestiones técnicas que deben cumplir los receptores para ser compatibles con el estándar.
21
En los años 2015 y 2016 se publicaron las versiones 2.0 y 2.0.1 respectivamente (la versión 2.0.1
es una versión corregida de la versión 2.0). Entre las novedades que introducen estas nuevas
especificaciones se encuentra la interoperabilidad con el lenguaje HTML5, la conexión del
terminal híbrido con los dispositivos de segundas pantallas, mejores gráficos, mejores servicios de
accesibilidad, contenido con resolución de Ultra Alta Definición (UHD, Ultra High Definition), y
protocolos para la sincronización de contenido multimedia en diferentes dispositivos con la norma
DVB-CSS.
1.5 CONCLUSIONES PARCIALES
Mediante el estudio del estado de la TDT se puede notar fácilmente que el estándar europeo DVB
es el más usado actualmente, no solo por Europa, sino también por África y parte de Asia.
Muchos países u organizaciones han desarrollado sus propias normas específicamente para el
estándar de TDT que utilizan, por ejemplo, se ha desarrollado estándares como MHP, MHEG y
HbbTV para DVB; o ARIB para el estándar ISDB-T.
En el caso de HbbTV, aunque ya es un estándar maduro de más de 10 años de creado, aún se está
desarrollando e implementando en la mayoría de los países europeos; aunque expertos afirman en
varias fuentes internacionales que este estándar puede marcar la diferencia en el futuro por la fácil
y rápida implementación de aplicaciones para esta plataforma.
La mayoría de los fabricantes de televisores o de dispositivos receptores de televisión digital están
optando por sistemas híbridos, dotando a sus equipos no solo de la televisión convencional con
componentes de interactividad, sino dándole acceso a internet y fusionando los servicios más
utilizados en la vida cotidiana con los servicios de televisión; incluso, haciendo más énfasis en
contenidos transmitidos por internet que por la propia televisión.
22
CAPÍTULO 2: DESCRIPCIÓN DEL ESTÁNDAR HBBTV
En este capítulo desarrollaremos, a nivel técnico, la especificación HbbTV v2.0.2, presentada en
2018 y oficialmente publicado por la ETSI en septiembre del mismo año bajo el nombre ETSI TS
102 796 V1.5.1 (ETSI, 2018). Trataremos los elementos que componen la tecnología, así como
qué porta cada uno de ellos. También veremos las incorporaciones más importantes que incluye
esta última versión de HbbTV.
El estándar HbbTV define una plataforma para la señalización, transporte y presentación de
aplicaciones interactivas cuyo entorno de ejecución son terminales híbridos que incluyen una
conexión a un canal broadcast compatible con DVB y una conexión de banda ancha para internet.
2.1 INTRODUCCIÓN AL ESTÁNDAR HBBTV
Al ser este estándar creado por la ETSI para su utilización en Europa, asume que el canal broadcast
usa el estándar de DTV DVB, pero HbbTV ha sido adaptado en otros estándares como ATSC y
actualmente está siendo combinado por los fabricantes de televisiones con Smart TV. Esta
adaptación a otros estándares es posible debido al medio transporte utilizado para distribuir el
contenido relacionado con el broadcast, siendo este medio el estándar ISO/IEC 13818-1 (Standard,
2000), o mejor conocido como MPEG-2. Los estándares de TDT se enfocan en transmitir
correctamente y con la menor perdida posible el contenido televisivo, mientras que el estándar
MPEG-2 o MPEG-4, también soportado por el estándar de TDT utilizado en Cuba (DTMB), se
enfoca en cómo codificar y empaquetar la información, así cómo recuperarse de errores de
transmisión.
Las funciones asociadas al canal de radiodifusión son:
• La recepción de la señal de TV, radio y servicios de datos.
• La señalización de las aplicaciones ligadas a la transmisión, llamadas: broadcast-related.
• El transporte de las aplicaciones broadcast-related y datos asociados.
• La sincronización de las aplicaciones interactivas con los servicios de TV, radio y datos
asociados.
Las funciones asociadas a la conexión a la banda ancha son:
23
• El transporte de contenidos bajo demanda.
• El transporte de aplicaciones broadcast-related y broadcast-independent y sus datos
asociados (las aplicaciones broadcast-independent son aquellas que no están ligadas al
canal broadcast, sino a internet).
• El intercambio de información entre aplicaciones y servidores.
• Declaración de aplicaciones broadcast-independent.
Las aplicaciones se presentan al usuario en el televisor mediante un navegador HTML/JavaScript
cuyas funcionalidades vienen definidas en su mayor parte por los requisitos de varios de los
estándares que componen la especificación HbbTV, es decir:
• W3C (HTML5, DOM 3, CSS TV 1.0, EcmaScript)
• OIPF DAE. Formalmente conocida como Open IPTV Forum Release 2 Volume 5
• OIPF Formatos Audio y Video
2.2 PLATAFORMA HBBTV
En el capítulo 1 de este documento hemos adelantado ciertas características del HbbTV como
estándar, desde el ángulo que al mercado le puede resultar interesante o ventajoso para tomar la
decisión de adoptarlo o no. A nivel más funcional la plataforma HbbTV tiene las siguientes
características:
• Es abierta y no depende de una sola autoridad central.
• Desde un mismo terminal se puede acceder al contenido y a los servicios de cualquier
proveedor independiente.
• Las funciones básicas o “estándar” del terminal pueden ser utilizadas por cualquier
aplicación, pero las funcionalidades más sensibles del terminal solo pueden usarlas las
aplicaciones de confianza por cuestiones de seguridad para mantener la integridad de los
terminales.
• Tanto los servicios como los contenidos pueden protegerse.
• Los terminales pueden mostrar aplicaciones broadcast, aunque no estén conectados al canal
broadband. Independientemente de que el terminal no haya sido conectado nunca a la red
broadband o de que directamente no la tenga disponible.
24
• Las aplicaciones pueden ejecutarse en diferentes tipos de terminal: TV conectadas, set top
boxes (sintonizador híbrido externo), PVR (Personal Video Recorder), etc.
• El estándar soporta tanto las aplicaciones broadcast-related como las broadcast-
independent.
Lo que no cubre el estándar son:
• Las aplicaciones o servicios que proporciona el fabricante del dispositivo, aunque para su
ejecución utilicen el navegador y las funciones que se describen en el estándar.
• Los formatos de audio, video y transporte del canal broadcast. Estos formatos y esquema
de transporte son definidos por el estándar de DTV utilizado.
• Los protocolos utilizados en el canal broadcast, excepto los que estén relacionados con las
aplicaciones interactivas (DSM-CC).
La plataforma combina un perfil tomado de las especificaciones del OIPF (Open IPTV Forum)
con el estándar DVB para la señalización y transporte de aplicaciones interactivas en entornos
HbbTV. En el estándar, además, se definen los formatos multimedia soportados (para el canal
broadband), el conjunto mínimo de funcionalidad del terminal y el ciclo de vida que debe seguir
una aplicación.
Como ya hemos comentado anteriormente, la definición del estándar se ha hecho en base a un
conjunto de características mínimo en cuanto a funcionalidades requeridas, esto hace que sea
posible combinar el estándar europeo con especificaciones nacionales que lo adapten de la mejor
manera posible al territorio de adopción. Esto quizá pueda ir en detrimento de la economía de
escala, pero claramente la intención es la de dar la posibilidad de reforzar los mercados nacionales.
2.3 VISIÓN GENERAL
Tal cual está definido en el estándar, el terminal híbrido con funcionalidades web permite la
descarga y ejecución de aplicaciones. Las aplicaciones están definidas como un conjunto de
documentos que constituyen por si mismos un servicio interactivo o “mejorado”. Individualmente,
el tipo de documentos que componen la aplicación son HTML, JavaScript, CSS, XML y archivos
multimedia.
25
Los servicios “mejorados” (del inglés “enhanced”), son servicios cuya función es añadir contenido
al programa o al servicio de TV/radio. Por ejemplo, un servicio mejorado sería la EPG (Guía
Electrónica de Programas), información de programa con imágenes. Es lo que mencionábamos
como servicios interactivos locales en el capítulo 1.
El estándar HbbTV define dos tipos de aplicaciones:
Broadcast-related:
Son aplicaciones asociadas a uno o más programas o a uno o más eventos dentro de un programa.
Decimos que pueden estar asociados a uno o más programas porque al cambiar de servicio
(normalmente dentro del mismo multiplex), la aplicación podría seguir activa o destruirse.
Las aplicaciones pueden arrancarse automáticamente (autostart) o pueden ser arrancadas
voluntariamente por el usuario.
Las aplicaciones broadcast-related pueden descargarse al receptor por cualquiera de los dos
canales del terminal híbrido y puede acceder a sus datos también por cualquiera de las dos vías.
Broadcast-independent:
No están asociadas a ningún servicio de radiodifusión. Esta aplicación descarga y accede a sus
datos exclusivamente por el canal de banda ancha.
El estándar HbbTV no especifica nada en cuanto a los siguientes posibles usos del entorno del
navegador compatible:
• Las aplicaciones que incorporen los proveedores de servicios (fabricantes, operadores de
cable, terceros).
• El uso que se pueda hacer del navegador para ejecutar aplicaciones específicas del terminal,
por ejemplo, el menú de cambio de canales, el menú de configuración del TV.
• Usar el navegador para navegar por cualquier página web.
• Que el navegador tenga implementadas otras especificaciones como CEA-2014 o todo el
paquete de especificaciones del OIPF.
26
2.4 ARQUITECTURA DE LA PLATAFORMA HBBTV
Se presenta la arquitectura del sistema y se explican los componentes funcionales necesarios dentro
del terminal. El nivel de detalles de esta sección es general y abstracto. No se va a detallar la
estructura interna de los componentes, como deben implementarse en la práctica o la forma de
comunicarse entre ellos. Esto es así porque HbbTV promueve que el estándar incluya solo las
características mínimas de lo que debe soportar el terminal y no promueve ni exige ninguna
tecnología de implementación en concreto facilitando así la economía de escala y el time-to-
market.
2.4.1 Sistema
Un terminal híbrido tiene la cualidad de poder estar conectado a dos redes en paralelo. Por un lado,
puede estar conectado a una red de radiodifusión. Por la vía del canal de radiodifusión el terminal
puede recibir emisiones de audio y video (A/V) lineal, datos de aplicaciones y señalización de
aplicaciones. Aunque no esté conectado a otra red, su conexión a la red de radiodifusión le permite
recibir aplicaciones ligadas a la emisión (broadcast-related). También es posible enviar “Stream
events” a las aplicaciones desde el canal de radiodifusión.
Si el terminal además está conectado a la red de banda ancha, entonces es posible la comunicación
bidireccional con el proveedor de aplicaciones (el radiodifusor o un tercero que proporcione
contenidos al radiodifusor). Por este interfaz el terminal puede recibir los datos de las aplicaciones
y contenidos A/V no lineales (streaming). El terminal también podría soportar (ya que no es un
requisito mínimo) la descarga de contenido A/V en tiempo no real (descarga HTTP no streaming).
La imagen 2.1 muestra un esquema con un terminal conectado a ambas redes, siendo una de ellas
la red DVB-S (Satélite), además, muestra como con esta versión del estándar HbbTV es posible la
incorporación de “pantallas acompañantes”.
27
Imagen 0.1 Esquema de un terminal hibrido conectado a una red broadcast mediante el estándar de DTV DVB-S y a una red
broadband (ETSI, 2018)
2.4.2 Terminal
El siguiente esquema muestra los componentes más relevantes de un terminal híbrido:
28
Imagen 0.2 Componentes funcionales de un terminal hibrido (ETSI, 2018)
El terminal recibe datos de la AIT (Application Information Table), contenido TV lineal, datos de
las aplicaciones y stream events por el interfaz de broadcast. Los datos de la aplicación y los stream
events los recibe empaquetados en un carrusel de objetos DSM-CC. El contenido no lineal se
transfiere mediante el protocolo FDP (File Download Protocol). Por lo tanto, tanto un cliente
DSM-CC como un decodificador de protocolo de descarga de archivos son necesarios para
recuperar los datos del carrusel de objetos y el flujo de datos FDP, estos datos recuperados se
proporcionan al Entorno de Ejecución (Runtime Environment) que puede verse como un
componente muy abstracto donde se presenta y ejecuta la aplicación interactiva. El navegador, un
administrador de aplicaciones y la interfaz de pantalla complementaria forman este entorno de
ejecución. Se puede entender el entorno de ejecución como un componente abstracto en el que se
presentan y ejecutan las aplicaciones interactivas. El gestor de aplicaciones evalúa la AIT para
poder controlar el ciclo de vida de la aplicación interactiva y el navegador se encarga de ejecutar
y presentar las aplicaciones interactivas.
El contenido A/V lineal se procesa exactamente igual que en un terminal no híbrido. Este
procesamiento se lleva a cabo en el procesador de señal DVB que incorpora las mismas funciones
29
que los procesadores de un terminal no híbrido tradicional. El entorno de ejecución puede acceder
a algunos datos del procesador DVB (información del canal, EIT p/f (EPG), y funciones que
permitan cambiar de canal). Estos datos están clasificados como “other data” en la figura 2.2.
Además de acceder a los datos del procesador DVB, las aplicaciones del entorno de ejecución
pueden incorporar la señal A/V lineal a su interfaz y redimensionarla mediante el reproductor de
medios (Meida Player). El reproductor de medios representa cualquier función relacionado con el
procesamiento del contenido A/V (lineal o no).
Por el interfaz de banda ancha conectado a internet, el terminal tiene una segunda vía por la cual
recibir de los servidores los datos de las aplicaciones de los proveedores de aplicaciones. Esta
conexión se utiliza además para recibir contenido A/V no lineal (streaming, VoD). El procesador
IP lleva a cabo todas las funciones necesarias para que el terminal pueda gestionar los datos que
le llegan por internet. El procesador IP es quien entrega los datos de internet al entorno de
ejecución. El contenido A/V no lineal recibido por internet se reenvía al Reproductor de Medios
que a su vez es controlado por el entorno de ejecución Y puede hacer lo mismo que en el caso del
contenido A/V lineal, es decir, incorporarlo al interfaz del programa y controlar su reproducción
y redimensionarlo.
La interfaz de pantalla complementaria permite al terminal híbrido descubrir dispositivos de
pantalla complementarios y otros terminales híbridos y ser descubiertos por dispositivos de
pantalla complementarios. A través de él, las aplicaciones interactivas que se ejecutan en el
navegador pueden solicitar que una aplicación se instale o inicie en un dispositivo de pantalla
complementario y una aplicación que se ejecuta en un dispositivo de pantalla complementario
puede solicitar que el navegador inicie una aplicación interactiva. Proporciona un servidor
WebSocket para habilitar una aplicación interactiva en el terminal híbrido y una aplicación
interactiva en un dispositivo de pantalla complementario o un terminal híbrido diferente para
comunicarse. En combinación, la Interfaz de pantalla complementaria y el Reproductor de medios
juntos permiten la sincronización del contenido entregado al terminal híbrido a través de una
interfaz con contenido entregado a un Dispositivo de pantalla complementario u otro terminal
híbrido.
A través de la interfaz CI Plus, el terminal híbrido solicita datos de aplicación del Sistema de
archivos auxiliar ofrecido por el CICAM (Módulo de Acceso Condicional de Interfaz Común).
30
2.4.3 Capacidades mínimas y opcionales del terminal
En cuanto a las capacidades mínimas que se exigen al terminal, el estándar incluye que debe
soportar los siguientes tipos de aplicaciones interactivas:
• Aplicaciones que no usen vídeo como parte del interfaz.
• Aplicaciones que usan el vídeo como parte del interfaz.
• Aplicaciones que usan contenido bajo demanda en streaming unicast como parte de su
interfaz. Este streaming unicast al que se refiere es al streaming HTTP, ya que el RTSP es
opcional.
Si analizamos esto detenidamente vemos que para poder implementarlo en el terminal al menos
necesitamos:
• Sintonizador.
• Conexión a internet.
• Navegador capaz de mostrar aplicaciones interactivas.
• Que el navegador tenga capacidad para mostrar y redimensionar el video.
• Que el navegador tenga capacidad de reproducir streaming de contenido de internet.
Esta es la base que HbbTV determina que debe incorporar un terminal híbrido. Opcionalmente,
hay otras funciones que pueden ser soportadas por el terminal:
• La descarga de contenido A/V en una memoria local en el terminal. Se podrá descargar
contenido (un archivo de vídeo, podcast, etc.) y contenido progresivo (un streaming de
video). Esta función es denominada “función de descarga”.
• La programación de grabaciones y su reproducción y el “timeshifting” del contenido lineal
DVB usando el almacenamiento que tenga disponible el terminal (interno o externo). Esta
función es denominada “función PVR”.
• Soporte para streaming usando los protocolos de flujo en tiempo real RTSP / RTP. Esta
función es denominada “función RTSP”.
• El contenido protegido por el interfaz de banda ancha.
2.5 FUNDAMENTOS TECNOLÓGICOS DEL ESTÁNDAR HBBTV
HbbTV se basa en los siguientes estándares/especificaciones:
31
• W3C HTML5 (HTML5, no date), tal como se describe en el perfil de TV de los estándares
web de OIPF (OIPF - Release 2 Specification - Volume 5a, Web Standards TV Profile,
V2.3, no date)
• OIPF DAE. Formalmente conocidal como Open IPTV Forum Release 2 Volume 5 (OIPF,
2014)
• DVB hybrid application signalling specification – Formalmente conocido como ETSI TS
102 809 (Institute European Telecommunications Standards, 2017)
• MPEG DASH – Formalmente conocido como ISO/IEC 23009-1 (ISO, 2015)
• MPEG CENC - Formalmente conocido como ISO/IEC 23001-7 (ISO, 2016)
De cada una de ellos HbbTV toma ciertas funcionalidades y perfila (particulariza) ciertos
elementos para que sean específicos para HbbTV. En la figura 2.3 se muestra la relación que existe
entre los diferentes estándares utilizados por HbbTV.
32
Imagen 0.3 Resumen de especificaciones (ETSI, 2018)
2.6 SEÑALIZACIÓN DE APLICACIONES
El estándar HbbTV no solo describe las funciones relativas al navegador y a la presentación de
las aplicaciones interactivas, sino que también aborda temas como la señalización de las
aplicaciones, aunque para ello se refiere al estándar ETSI TS 102 809 “Signalling and carriage of
interactive applications and services in HbbTV environments” (Institute European
Telecommunications Standards, 2017). Este estándar fue creado por DVB en marzo del 2009 y
publicado por la ETSI como estándar en febrero del 2004, aunque la última versión publicada por
la ETSI data de junio del 2017.
33
Este estándar define cómo tienen que señalizarse las aplicaciones que se ejecutan en el contexto
de un programa de TV/radio que viaja en su correspondiente Transport Stream (TS). Al igual que
se hacía en MHP, la señalización de aplicaciones interactivas se hace usando una tabla creada para
tal efecto: la AIT (Application Information Table) que va incluida en el servicio DVB y que está
listada en el PMT (Program Map Table).
La AIT incluye la señalización de todas las aplicaciones que se quieran ejecutar en el contexto de
ese programa. Dicho de otro modo, las aplicaciones solo se ejecutarán si se encuentran señalizadas
en la AIT. Gracias a esto, se puede evitar que una aplicación de terceros “secuestre” la señal de
programa. El estándar OIPF permite que desde una aplicación interactiva ejecutándose en el
contexto de un programa A se pueda sintonizar otro programa B. Pero si en la AIT del programa
B no está señalizada la aplicación, ésta será detenida y no podrá llevar a cabo el cambio de
programa. Con esto se pretende que no haya overlays no autorizados, preservando la integridad de
la señal. Una de las aplicaciones señalizadas en la AIT puede ser marcada como “autostart”. Esto
significa que la aplicación se ejecutará automáticamente al sintonizar el servicio siempre y cuando
en la configuración del terminal no se haya determinado lo contrario, es decir, no iniciar
automáticamente las aplicaciones “autostart”.
Respecto a las aplicaciones “autostart”, se ha llegado a un acuerdo por el cual lo único que hacen
es dibujar un pequeño icono en el que se muestra un botón rojo (denominado “gancho” o “hook”)
invitando al usuario a usar el servicio y que desaparece tras unos segundos. Esto se hace para no
molestar a los usuarios con sobreimpresiones no deseadas y por homogeneizar la presentación de
la aplicación “autostart”. Tras la desaparición del icono con el botón rojo, el usuario puede seguir
arrancando la aplicación en cualquier momento ya que la aplicación está ejecutándose en modo
transparente, pero reaccionará al keyevent de pulsar el botón rojo en cuanto este se produzca.
El AIT también incorpora una opción por la cual una aplicación HbbTV puede ser marcada como
“digital teletext application”, de esta forma una aplicación HbbTV puede sustituir al teletexto
tradicional. El comportamiento definido para el caso en que haya presente una aplicación de
teletexto HbbTV y el teletexto tradicional es que tras una primera pulsación del botón “TXT” (o
similar) del mando se iniciará el teletexto HbbTV, tras una segunda pulsación se presentará el
teletexto tradicional. Si no hay teletexto HbbTV se iniciará directamente el teletexto tradicional.
34
Además de la señalización de aplicaciones, el ETSI TS 1102 809 especifica el transporte de
aplicaciones mediante el canal broadcast, siendo esta una opción interesante para los terminales
que no tengan conexión a banda ancha. Al igual que en MHP, para transmitir las aplicaciones se
usa el carrusel de objetos del protocolo DSM-CC. La cantidad de datos que es posible transmitir
por este medio es claramente inferior a lo que permite el canal broadband, pero aun así es suficiente
para transmitir aplicaciones con poco peso como pueda ser el teletexto digital, EPGs o pequeñas
aplicaciones relacionadas a los programas para así enriquecerlos.
Una parte del sistema DSM-CC son los “stream events” que ya hemos mencionado varias veces a
lo largo de este texto. Los stream events son pequeños paquete de datos que se pueden transmitir
sincronizados con la señal de programa. Permiten que la aplicación interactiva muestre
informaciones o datos en un momento preciso sin retardo. Es por ello que a los stream events
también se les conoce como “Do it now” events: eventos de “Hazlo ya”. La capacidad de enviar
eventos de forma inmediata y síncrona con lo que está pasando en el programa da lugar a
aplicaciones tipo televoto, o encuesta. El canal broadband no es válido para este tipo de
aplicaciones porque tiene retardos variables, además de que necesitaría que los servidores web
estuviesen dimensionados de tal forma que fuesen capaces de enviar información a millones de
conexiones de forma simultánea. El uso del canal broadcast es mucho más eficiente.
Por tanto, este estándar aporta lo siguiente a HbbTV:
• Señalización de aplicaciones en el flujo del canal broadcast (AIT).
• Capacidad para iniciar y detener las aplicaciones en el contexto de un programa de
TV/radio (usando la AIT).
• Señalización de Teletexto Digital HbbTV (en la AIT).
• Transmisión de los datos de las aplicaciones en el canal de radiodifusión (mediante
DSM-CC).
• Transmisión de stream events síncronos con la señal de TV/radio (con DSM-CC).
Vamos a analizar un poco más en profundidad estos tres conceptos: AIT, DSM-CC y stream
events. Pero previamente vamos a dibujar el escenario sobre el que nos estamos moviendo, el TS
del canal broadcast, que sigue el estándar ISO/IEC 13818-1 (Standard, 2000).
35
Cada flujo elemental (Elementary Stream) de video, audio o datos que viaja dentro del TS tiene
asociado un identificador único (PID, 13 bits). El TS tiene que multiplexar los flujos elementales
de audio, video y datos. Para hacer el proceso de multiplexación más eficiente, se divide cada flujo
en paquetes dando lugar a unos flujos elementales divididos en paquetes (PES, packetized
elementary stream). Para poder transmitir esos PES, hay que volver a dividirlos en paquetes de un
tamaño óptimo para la transmisión. El tamaño del paquete para transporte es de 188 bytes
(Standard, 2000), que es bastante más pequeño que el tamaño de un PES. Por ello, cada PES se
transmite utilizando varios paquetes de transporte. Cada uno de esos paquetes de 188 bytes
empieza siempre con un byte de sincronismo (0x47). El TS provee de mecanismos de corrección
de errores y sincronización para evitar la degradación de la señal.
El TS proporciona una representación lógica del contenido que transporta, girando en torno al
concepto de programas/servicios. Para ello utiliza la tabla PMT (Program Map Table) que lista
todos los PIDs que forman un programa. El PMT también tiene su propio PID. Por ejemplo, un
TS usado en televisión digital puede transportar 3 programas que representarían 3 canales de
televisión. Cada uno de esos canales está compuesto por un flujo de vídeo, uno o dos flujos de
audio y otros flujos con metadatos. Para que el terminal pueda presentar cualquiera de esos 3
canales mira el PMT para saber exactamente que PIDs tiene que decodificar y cuales tiene que
descartar. Y después tenemos la PAT (Program Association Table) que es un índice de todos los
servicios/programas que se encuentran en el TS. El siguiente gráfico lo ilustra todo:
36
Figura 0.4 Representación de los distintos TS y su organización en PMT y PAT (“An Introduction To Digital TV Technology –
TV Without Borders,” 2018)
En conjunto todos los tipos de Tabla que acabamos de mencionar reciben el nombre de “SI table”
(Service Information Table). Hay más además de las mencionadas:
• PAT: Program Association Table (siempre con PID 0).
• PMT: Program Map Table.
• CAT: Conditional Access Table
• NIT: Network Information Table.
• SDT: Service Description Table.
• EIT: Event Information Table (EPG)
• BAT: Bouquet Association Table
• TDT: Time and Date Table
• TOT: Time Offset Table
Las tablas PAT + PMT + CAT son conocidas como PSI (Program Specific Information).
2.6.1 Señalización AIT
Antes de que el gestor de aplicaciones del navegador HbbTV pueda ejecutar cualquier aplicación,
el receptor debe saber que tal aplicación existe. Después debe saber si el usuario puede ejecutarla
o no es ese momento y finalmente debe saber si dispone de todo lo necesario para poder ejecutarla.
37
Las dos primeras premisas y parte de la tercera se controlan con una tabla SI extra creada para este
propósito, la AIT (Application Information Table). Esta tabla contiene una entrada por aplicación
y se difunde con cada servicio que contenga una aplicación interactiva. Va listada en la tabla PMT
del servicio correspondiente. La AIT contendrá toda la información necesaria para que el receptor
pueda ejecutar la aplicación y que el usuario sepa que aplicaciones tiene disponibles en cada
momento. Entre esta información se cuenta el nombre de la aplicación, la ubicación de sus archivos
y cualquier dato que deba ser pasado a la aplicación al arrancarla.
Cada aplicación tiene asignado un identificador único que es almacenado en la AIT. Esto permite
que otras partes del sistema puedan acceder a la aplicación de forma unívoca. Este identificador se
compone de dos campos: un campo de 32 bits para identificar la organización que realiza la
aplicación y que debe ser único y un campo de 16 bits que identifica la aplicación. El campo de 16
bits no tiene por qué ser único, pero en caso de que la misma AIT señalice más de una aplicación
no deben coincidir. El terminal puede arrancar o parar automáticamente las aplicaciones en función
del código de control señalizado en la AIT. Los códigos de control dicen cuando una aplicación
puede arrancarse automáticamente (“AUTOSTART”), cuando debe finalizar si está en ejecución
y cuando puede ser iniciada manualmente. Así el radiodifusor puede, por ejemplo, activar una
aplicación durante un intervalo de tiempo determinado.
A continuación, listamos los descriptores y entidades de señalización cuya codificación MPEG-2
debe ser soportada por HbbTV:
• Application type: Sirve para saber si el terminal es compatible con el tipo de aplicación.
En el caso de HbbTV se señalizará con el código 0x0010.
• Application ID: Aquí es donde se identificad a la organización responsable de la aplicación
(organisation_id) y a la aplicación (application_id). Para el application_id hay varios
códigos que indican si la aplicación está firmada o si no lo está. En HbbTV las aplicaciones
firmadas podrás ser ejecutadas como de confianza. Las aplicaciones marcadas como no
firmadas podrás ser ejecutadas, pero no como aplicaciones de confianza (no tendrán acceso
a recursos privilegiados del terminal) Las aplicaciones que estén marcadas como algo que
no sea firmado o no firmado, a no ser que sean requeridas por otra especificación, no
deberán iniciarse y serán descartadas por el terminal.
• Código de control de las aplicaciones:
38
o 0x01: AUTOSTART → Si el terminal lo permite se iniciará sola.
o 0x02: PRESENT → Está presente pero no se ejecuta sola.
o 0x04: KILL → En cuanto aparezca este código en la AIT la aplicación morirá.
o 0x07: DISABLED → La aplicación no se puede ejecutar.
o Del estándar DVB se heredan los estados DESTROY, PREFETCH, REMOTE y
PLAYBACK_AUTOSTART. El flujo entre estos estados viene definido por el
ciclo de vida de la aplicación.
• Perfiles de la plataforma:
o 0x0000: Para aplicaciones que no necesiten más que el perfil básico.
o 0x0001: La aplicación requiere la funcionalidad de Descargas.
o 0x0002: La aplicación requiere la funcionalidad PVR.
o 0x0004: La aplicación requiere la funcionalidad RTSP.
• Visibilidad de la aplicación: Solo es válido el código VISIBLE_ALL. Aplicación visible a
los usuarios y a otras aplicaciones mediante un API.
• Prioridad de la aplicación: Que aplicación se inicia primero, en caso de quedarse sin
recursos cual se cierra primero, cual se inicia si tienen el mismo id....
• Uso de la aplicación: Código para identificar si es un servicio conocido como Teletexto,
EPG o Chat. Se usará el código 0x01 → Teletexto.
• Program Specific Information: El PMT de un servicio DVB que incluya una o más
aplicaciones interactivas deberá incluir la localización del TS que lleve la tabla AIT y la
ubicación de los TS que lleven los datos de la aplicación.
• Application Information Table: La AIT está compuesta por distintas subtablas que llevan
la información de los datos de la aplicación, de los códigos de estado, etc... Para el
application_type se transmitirá un máximo de una subtabla (se usará un solo PID) HbbTV
por servicio. Todas las secciones de las subtablas AIT HbbTV se transmitirán 1 vez por
segundo.
• Application Signalling Descriptor: El application_signalling_descriptor se usa dentro del
loop del flujo elemental de la PMT donde el stream_type del flujo elemental es 0x05
indicando así que el flujo elemental es un AIT.
39
• Application Descriptor: Debe haber al menos un application_descriptor dentro de cada loop
de descripción de la AIT.
• Application usage descriptor: Esto sirve para el caso en el que el mando a distancia no tiene
ningún botón específico para acceder a servicios de los denominados “well known” como
el Teletexto o el EPG. En este caso se da la opción de usar este identificador para que desde
la aplicación pueda lanzarse dicho servicio. Se utilizará únicamente el código 0x01 como
antes para identificar el servicio de Teletexto.
• User information descriptor: Se pueden usar para mostrar información que se considere útil
para el usuario.
• Transport Protocol Descriptors: Se usarán los siguientes:
o 0x0001: Carrusel de objetos sobre el canal broadcast.
o 0x0003: HTTP sobre el canal broadband.
• Simple aplication location descriptor: El bucle AIT deberá contener siempre uno. Consta
de dos etiquetas → descriptor_tag: 15 bits con valor 0x15 e initial_path_bytes: Que
contienen una cadena especificando la URL del documento raíz de entrada. Este es el
descriptor HbbTV que se usará para lanzar aplicaciones por el canal broadband.
• Simple application boundary descriptor: Solo de admiten los prefijos “dvb://”, “http://” o
“https://”. Y solo se soportarán prefijos que hagan referencia a dominios de segundo nivel,
se ignorarán los elementos en la raíz.
También es posible señalizar aplicaciones por el canal broadband usando la llamada codificación
XML del AIT. Significa que se podría leer un archivo XML del canal broadband para señalizar
artificialmente una aplicación. Esto se puede usar para señalizar aplicaciones broadcast-
independent o para señalizar aplicaciones interactivas en entornos de televisión analógica, algo
que se cubre en el Anexo C del estándar HbbTV. Señalizar aplicaciones interactivas en entornos
de televisión analógica tiene aplicación en mercados donde aún no ha llegado la televisión digital
y se prevé que no vaya a hacerlo a corto plazo. A continuación, a continuación se muestra un
bloque de código en Python donde muestra cómo se señaliza una aplicación HbbTV en el software
Opencaster de Avalpa:
40
Figura 2.5 Señalización de una aplicación HbbTV utilizando Python y OpenCaster
2.6.2 DSM-CC
DSM-CC (Digital Storage Media – Command and Control) en su origen fue diseñado para el
control de VTRs (Video Tape Recorder) conectados en red. Desde su creación ha sido extendido
y ahora es capaz de controlar servidores de video MPEG en red (reproducir, parar y pausar).
También soporta la transmisión de datos usando MPEG-2, códigos de tiempos para video MPEG-
2, broadcast de datos y de sistemas de archivos (Standard, 2000). Estas dos últimas funciones son
las que nos interesan en HbbTV.
Para transmitir los datos en el canal broadcast el radiodifusor transmite periódicamente cada
archivo del sistema de archivos y el receptor espera a que aparezca el archivo que necesita. Son
41
las operaciones llevadas al cabo en el reproductor las que determinan qué archivos son necesarios.
A esta forma de enviar y recibir datos se le denomina carrusel. En DSM-CC los datos a transmitir
se dividen en módulos, a cada módulo se le añade información y luego se transmiten siguiendo un
orden.
DSM-CC soporta dos tipos de carrusel: el carrusel de datos y el carrusel de objetos. El carrusel de
datos es más sencillo, permite al radiodifusor enviar bloques de datos al receptor, pero lo hace sin
ningún tipo de indicación acerca del tipo de datos que son y es el receptor el que debe darle sentido
a lo que ha recibido. Los carruseles de objetos son bastante más complejos y por tanto ofrecen una
solución a escenarios más complejos. El carrusel de objetos se construye sobre el carrusel de datos
y ofrece prácticamente las mismas funciones que un sistema de archivos. HbbTV usa el carrusel
de objetos (ETSI, 2018).
Cada carrusel de objetos está formado por un directorio raíz que se divide en distintos módulos,
cada uno de los módulos transportará uno o más archivos/directorios. Los archivos contenidos en
un módulo pueden pertenecer a cualquier parte de la estructura de directorios, no tienen por qué
pertenecer al mismo directorio. Cuando ya están todos los datos dentro de los módulos se empiezan
a transmitir una tras otro hasta que todos han sido transmitidos, al llegar al último se comienza a
transmitir de nuevo el primero (de ahí que se le denomine carrusel). Cuando el volumen de datos
es relativamente grande este sistema puede ser poco eficiente, por eso los receptores pueden
guardar datos en caché. Los receptores pueden hacer caché a nivel de módulo o a nivel de archivo.
HbbTV impone algunas condiciones de uso a la hora de montar y actualizar un carrusel.
• El terminal montará como máximo un solo carrusel y pondrá a disposición de la aplicación
la última versión de los archivos del carrusel. Normalmente para montar un carrusel habrá
que cachear los datos y luego monitorizar los cambios.
• Para una aplicación broadcast-related cuya página inicial provenga del broadcast se deberá
montar el carrusel, a no ser que para poder montar el carrusel haya que sintonizar otro
servicio, en cuyo caso no se cargará la página. Si la página de inicio de la aplicación
broadcast-related no se obtiene del carrusel, pero algún elemento de la página si debe ser
descargado del carrusel (con un XMLHttpRequest por ejemplo) se montará el carrusel para
que esto pueda llevarse a cabo. Una aplicación broadcast-independent no podrá montar un
carrusel sin convertirse antes en broadcast-related.
42
• Durante el ciclo de vida de la aplicación, para una aplicación broadcast-related, cuando un
carrusel haya sido montado cualquier petición que implique montar otro carrusel distinto
se realizará desmontando previamente el primer carrusel y cancelar las operaciones
pendientes.
2.6.3 Stream Events
Para el radiodifusor el carrusel de objetos DSM-CC es un componente que le permite el envío de
aplicaciones y datos independientemente de si el terminal está conectado a la red de banda ancha.
Este método de transporte de datos va a ser generalmente la segunda opción de transporte para las
aplicaciones interactivas, aunque no debería ser dado de lado pues ofrece todo un canal de
comunicaciones que, aunque limitado, es inmediato y puede servir para el transporte de
aplicaciones más básicas. Pero es un componente que no ofrece ninguna característica especial en
cuanto a la generación de contenido o experiencia especialmente interactiva.
Para conseguir eso DSM-CC pone a disposición del radiodifusor los denominados stream events.
Los stream events son unos descriptores embebidos en un flujo elemental DSM-CC de un stream
MPEG-2. Con ellos es posible que el receptor se sincronice con el contenido en distintos puntos
decididos por el radiodifusor. Por ejemplo, el radiodifusor podría usar un stream event para avisar
de que está empezando un programa en otro canal de su múltiplex.
Los stream events se clasifican en dos grupos: los objetos y descriptores. Veamos las definiciones
para cada uno de ellos:
• Stream event: Es el evento que se dispara en el receptor (el acto) cuando se recibe un
descriptor de stream event.
• Objeto Stream event: Es el objeto de Stream event que se transporta en el carrusel DSM-
CC. Es como si fuese un descriptor de alto nivel.
• Descriptor de Stream event: Son los descriptores transportados por el flujo DSM-CC que
disparan los stream event en la práctica.
Los stream event se almacenan en un carrusel de objetos al igual que cualquier otro objeto DSM-
CC. El objeto stream event da información general acerca del stream event: un ID de evento que
debe ser único y un nombre para el stream event.
43
Por su parte, el descriptor del stream event le dice al receptor que se ha generado un evento. El
descriptor contiene información más detallada acerca del stream event. La información que
contiene un descriptor es: el ID del evento, información temporal acerca de cuándo debe dispararse
el evento y, la más importante para HbbTV, la capacidad de decirle al receptor que ejecute el
evento inmediatamente (“do it now”).
Esta última propiedad de los descriptores de stream event es la que permitirá señalizar eventos
inmediatos en programas en directo, o señalizar los goles de un partido de fútbol, o dar la respuesta
a una pregunta de un concurso interactivo a la vez que en el programa, etc.
Los descriptores de stream event que usan el campo “hazlo ahora” solo se transmiten una vez por
evento así que el receptor tiene que encargarse de recibirlos correctamente.
Cada vez que el terminal recibe un descriptor de stream event lleva a cabo los siguientes pasos:
1. Comprueba que haya un objeto de stream event con el mismo ID presente en el carrusel.
Si no lo hay descarta el descriptor de stream event.
2. Si se detecta que el descriptor es del tipo “hazlo ahora” se dispara inmediatamente.
3. Si el evento no es del tipo “hazlo ahora” se comprueba la referencia temporal para ver
cuándo debe ser disparado. Si ya existe un evento con el mismo ID listo para ser disparado
o si la referencia temporal se ha quedado desfasada, se descarta el descriptor.
4. Cuando la referencia temporal del descriptor alcanza el valor programado se dispara el
stream event.
La separación de Stream Events entre objetos y descriptores permite, como hemos dicho antes, la
reutilización de los eventos. Es decir, distintos descriptores de eventos con un mismo ID podrían
hacer referencia al mismo tipo de evento. Así, siguiendo con el ejemplo del fútbol, un radiodifusor
podría decidir usar un mismo ID para lanzar stream events de goles, otro ID para penaltis y otro
para finales de partido. Utilizado de esta forma el ID de evento sería el equivalente a una clase de
evento.
Al igual que con DSM-CC HbbTV adopta solo ciertas cosas de los Stream Events. Concretamente
HbbTV incorpora la funcionalidad “hazlo ahora” de los Stream Event y la que no incorpora es la
de sincronizar el Stream Event con un punto temporal predefinido. El estándar ETSI TS 102 809
se refiere a estos últimos como DVB Timeline Stream events. Los radiodifusores deberán ubicar
44
todos los descriptores de stream event de tal forma que puedan ser monitorizados simultáneamente
por la aplicación en el mismo PID. Este PID será el mismo que se use para otras secciones DSM-
CC.
2.7 CONCLUSIONES PARCIALES
Al estudiar detenidamente el estándar HbbTV se puede concluir que:
• El estándar fue concebido haciendo uso de algunas de las tecnologías existentes más
populares; tal es el caso del conjunto de tecnologías pertenecientes al W3C: HTML5, CSS3
y JavaScript; o al estándar OIPF para el manejo desde las aplicaciones de componentes
nativos relacionadas al dispositivo receptor.
• El desarrollo de aplicaciones para el estándar HbbTV no es solo rápido, sino que es muy
fácil y barato ya que es semejante a crear aplicaciones Web.
• A pesar de que el estándar se autodefine como un estándar hibrido ya que utiliza tanto la
señal de radiodifusión como la señal de banda ancha, se puede comenzar implementando
solo alguna de las dos variantes. Es decir, implementar todo lo relacionado con el canal de
radiodifusión sin tocar ningún componente relacionado al canal de banda ancha, o al revés.
• La cantidad de aplicaciones que se pueden enviar utilizando el protocolo DSM-CC es
directamente proporcional al tamaño de las mismas y al ancho de banda del canal de
radiodifusión ya que estas se deben enviar de forma cíclica en el menor tiempo posible.
45
CAPÍTULO 3: PROPUESTA DE LA ARQUITECTURA
Tras consultar el estado del arte y cavar en busca de una solución al menos medianamente completa
y de software libre para la implementación del receptor de televisión digital con soporte para el
estándar HbbTV no se logró encontrar ninguna, ni siquiera alguno de los componentes esenciales.
Dado que no se encontró una solución que nos permita lograr la independencia tecnológica que
deseamos surge la necesidad de crear desde cero una solución. Aunque teniendo en cuenta que ya
existen componentes que podemos modificar para crear nuestra solución.
Crear prácticamente de cero una solución, que puede ser realmente grande en términos de líneas
de código, esfuerzo y tiempo de desarrollo debe ser bien pensada y correctamente diseñada. Violar
una etapa de diseño o apurar el mismo puede producir un producto mediocre, inmantenible y
probablemente disfuncional.
El desarrollo del proyecto se deberá dividir, al menos, en las siguientes fases:
1. Diseño de la arquitectura
2. Diseño individual de cada uno de los componentes definidos en dicha arquitectura y
especificación de las interacciones entre estos.
3. Implementación de cada componente, así como de sus respectivos tests.
Durante el presente trabajo nos limitaremos a abordar solamente el proceso de diseño de la
arquitectura propuesta para la implementación de la solución de software/hardware.
El proceso de arquitectura de software toma los requisitos de los clientes, los analiza y produce un
diseño para obtener un software que satisfará sus necesidades. Los diseños exitosos de software
deben sopesar las disyuntivas inevitables que surgen debido a requisitos conflictivos; cumplir con
los principios de diseño y las buenas técnicas de procedimiento que han evolucionado con el
tiempo; y complementar el hardware moderno, las redes y los sistemas de administración. Una
arquitectura contundente de software implica tener mucha experiencia en temas teóricos y
prácticos, así como la visión necesaria para convertir lo que al parecer son escenarios y requisitos
comerciales imprecisos en diseños de trabajo sólidos y prácticos.
46
La arquitectura de software implica definir una solución estructurada que satisfaga todos los
requisitos técnicos y operacionales y, a la vez, optimizar los atributos comunes de calidad como
rendimiento, seguridad y capacidad de administración. Además, implica una serie de decisiones
basadas en una amplia gama de factores, y cada una de esas decisiones puede tener un considerable
impacto sobre la calidad, rendimiento, mantenimiento y éxito general de ese software.
El software moderno rara vez es independiente. Por lo menos, en la mayoría de los casos,
interactuará con un origen de datos como una base de datos corporativa que expone la información
con la que trabajan los usuarios del software. Habitualmente, el software moderno debe también
interactuar con otros servicios y funciones de red. Si no se cuenta con una arquitectura adecuada,
puede que sea difícil o incluso imposible implementar, operar, mantener e integrar el software
correctamente con otros sistemas, y no podrá cumplir los requisitos del usuario.
La arquitectura de software se puede considerar como un mapeo entre lo que un software debe
lograr y los detalles de la implementación como código. Al obtener la arquitectura correcta se
garantizará la coincidencia óptima entre requisitos y resultados. El software con buena arquitectura
llevará a cabo las tareas especificadas dentro de los parámetros de los requisitos originales y lo
hará de una forma que maximice el rendimiento, la seguridad, confiabilidad y muchos otros
factores.
En su máximo nivel, el diseño arquitectónico debe exponer la estructura del sistema, pero ocultar
los detalles de implementación; percatarse de todos los casos y escenarios de uso; intentar abordar
los requisitos de todas las partes interesadas; y satisfacer lo más posible todos los requisitos
funcionales y de calidad.
Los requerimientos del software moderno son cada vez más complejos puesto que los usuarios
esperan más de sus aplicaciones. Las aplicaciones de escritorio independientes y sencillas ya no
son lo suficientemente buenas en la mayoría de los escenarios comerciales y empresariales. En
nuestro mundo conectado, la aplicación debe interactuar con otras aplicaciones y servicios y
ejecutarse en una serie de entornos. Los diseños monolíticos comunes en el pasado se han
reemplazado por software componentizado orientado al servicio, que utiliza marcos, sistemas
operativos, hosts en tiempo de ejecución y redes para implementar características que eran insólitas
hasta hace unos pocos años.
47
Esta complejidad afecta no sólo al diseño, sino también a la implementación, mantenimiento y
administración del software. El costo total de propiedad (TCO) del software ahora se compone
predominantemente de costos posteriores a la implementación. Una aplicación con buena
arquitectura minimizará el TCO al reducir el costo y tiempo requeridos para implementar la
aplicación, mantenerla en ejecución, actualizarla para cumplir con los requisitos cambiantes y
solucionar problemas. Además, simplificará el soporte técnico y la administración por parte del
usuario.
El software también debe cumplir varios criterios fundamentales para tener éxito. Debe
proporcionar seguridad de manera que la aplicación y sus datos estén protegidos contra ataques
malintencionados y errores accidentales. Debe ser robusto y confiable para minimizar los errores
y los costos asociados. Debe ejecutarse dentro de los parámetros requeridos para satisfacer las
necesidades del cliente, como un tiempo de respuesta máximo o una capacidad de carga de trabajo
específica. Debe ser sostenible para poder minimizar los costos de administración y soporte técnico
y suficientemente extensible para permitir los cambios y actualizaciones inevitables que se
requerirán con el tiempo.
Todos estos factores implican algunas desventajas. Por ejemplo, la implementación de los
mecanismos más seguros mediante un cifrado complejo afectará el rendimiento. La
implementación de opciones de configuración y actualización de amplio rango puede hacer que la
implementación y administración sean más complicadas. Además, cuanto más complejo sea el
diseño, más costará implementarlo. Una buena arquitectura tendrá como objetivo equilibrar estos
factores para producir el resultado óptimo en el escenario específico.
3.1 SOLUCIONES DE PAGO
Actualmente, a varios años de publicado el estándar HbbTV ya varias organizaciones han creado
sus soluciones para, generalmente, integrarlas con sus productos de hardware. Tal es el caso de
Samsung, LG, Sony, entre otros que han combinado sus sistemas de Smart TV con HbbTV.
Muchos proveedores de televisión, sobre todo en Europa (la cuna de HbbTV), han comenzado a
transmitir contenidos bajo el estándar HbbTV y organizaciones gubernamentales, en conjunto con
estos proveedores, han creado recomendaciones y especificaciones con las características que
deben tener los equipos receptores para ser vendidos en sus países.
48
La competencia en el mundo de las ventas de equipos de recepción de televisión digital es bastante
alta y aquellos receptores que brinden la mayor cantidad de servicios serán los más vendidos, por
esta y otras razones los fabricantes de equipos de recepción prefieren mantener sus soluciones de
HbbTV protegidas con propiedad industrial y ni siquiera comercializan su software.
Existen otras organizaciones que han preferido tomar el rol de “proveedor de servicios” y han
creado sus soluciones de software para venderlas. Por lo general este tipo de soluciones tienen la
bondad de ser independientes de la arquitectura de hardware y multiplataforma, pero los precios
no suelen ser tan bondadosos.
3.1.1 Tara Systems
Alemania es uno de los países que va en la cabeza cuando hablamos de televisión interactiva, por
lo que no es sorpresa que exista es ese país un alto nivel de interactividad y de soluciones de
software y hardware.
TARA Systems es una empresa ubicada en Múnich, Alemania que brinda soluciones de software
para la recepción de contenidos interactivos y cuenta con la experiencia de pertenecer a la
asociación HbbTV. Brindan una gran variedad de servicios relacionados con la televisión
interactiva, entre ellos se encuentran los siguientes:
• Soporte para Android TV
• Aplicaciones TV en vivo
• Middleware IPTV
• Solución HbbTV
• Decodificador de subtítulos
La solución más interesante, en términos de nuestra investigación, fue el Middleware Inaris. Esta
solución provee todos los componentes de software como una extensión de DVB/IPTV y soporta
aplicaciones HbbTV. Es una plataforma independiente de hardware y multiplataforma, lo que
permite una buena integración con cualquier plataforma de TV o STB gracias a que brinda un
SDK.
Inaris es completamente compatible con el estándar 1.5 de HbbTV, así como con todas sus
funcionalidades o características. Tiene un soporte completo para la sincronización de medios y
49
para las pantallas acompañantes. Además, permite la integración con cualquier navegador que se
desee escoger para presentar las aplicaciones.
En la Figura 3.1 se muestra la arquitectura utilizada por TARA System en su solución para HbbTV.
Brindan un API ara una mejor integración entre sus componentes y componentes de terceros como:
Sistema Operativo, DVB/IPTV middleware, reproductor multimedia y navegador web.
Imagen 0.1 Arquitectura de software utilizada por TARA Systems
3.1.2 Ocean Blue Software
Ocean Blue Software (OBS) es una organización que brinda servicios de soporte a las industrias
de televisión digital y semiconductores, incluida la provisión de soporte de ingeniería, integración
de sistemas y capacitación. Tiene más de 10 años de experiencia en el mercado y ha desarrollado
soluciones de software para soportar HbbTV, MHEG, DVB-T/T2/C/S/S2 Y CI Plus.
El modelo de negocios de esta compañía se basa en brindas servicios de entrenamiento, soporte,
desarrollo de software para televisión digital, específicamente, para set-top boxes, de colaboración,
de pruebas de software, de consulta y diseño de interfaces de usuarios.
50
OBS ha dedicado especial interés por el estándar HbbTV justo antes de la Eurocopa del 2012 y ha
dedicado parte de su esfuerzo en desarrollar una solución para este estándar. Ha incorporado
extensiones HbbTV para proveer los siguientes componentes a navegadores de terceros:
• Herramientas para recibir contenidos enviados por el canal de radiodifusión del estándar
de TDT DVB.
• DSM-CC para transmisión de aplicaciones.
• Navegador compatible con HbbTV 1.5
Figura 3.2 Componentes brindados por OBS
3.1.3 Vewd
Opera TV, el líder del mercado mundial en habilitación de servicios OTT (Over the Top), presentó
el 15 de septiembre del 2017 su nueva identidad, incluido un logotipo y sitio web; ahora llamada
Vewd (Opera TV is Now Vewd - Vewd, 2019). El núcleo de Opera TV siempre se llamó Vewd,
pero hasta la mencionada fecha se comercializaba con el nombre de Opera TV. Vewd con más de
15 años de experiencia ha sido uno de los primeros pioneros de la industria de productos para
Smart TV, set-top boxes y proveedores de contenidos.
Vewd Core, formalmente conocido como Opera TV SDK ha sido el SDK de HTML5 más
desplegado en la industria, vendiendo más de 50 millones de dispositivos cada año y
51
monopolizando el 70% de mercado de los Smart TV. Trabaja con compañías como: Sony, Verizon,
Samsung y TiVo.
Vewd ofrece mucho más que un SDK, también tiene entre su larga lista de productos, su sistema
operativo: Vewd OS. Su sistema operativo puede ser instalado en los casi cualquier dispositivo y,
además, puede ejecutarse sobre Android. Además, ofrece Vewd Atom para dotar set-top boxes
antiguos con las más modernas tecnologías; Vewd App Store, Vewd TV Emulator, un potente
emulador para testear y desarrollar apps para la televisión, y entre otros productos, brinda un
potente navegador basado en Opera.
3.2 ARQUITECTURA PROPUESTA
En nuestra etapa de investigación nos percatamos que algunas de las soluciones de pago existentes
exponen públicamente parte de su arquitectura. Si bien estos diseños no están completos, si nos
dan una idea de cómo funcionan estas plataformas y nos permite adquirir experiencia de softwares
que están bien posicionados en el mercado.
La arquitectura que más nos llamó la atención fue la propia arquitectura propuesta por el estándar
HbbTV, principalmente por su diseño modular. Esta es la característica que más buscamos para
nuestra arquitectura, pues cuando se desarrolla un software grande en términos de complejidad y
líneas de código es buena idea separar la solución en pequeñas partes funcionales y así aplicar la
filosofía “divide y vencerás”.
Un software modular bien diseñado es más fácil de implementar y de testear, ya que la mayor
complejidad recae en el diseño en sí. Dado que el equipo que desarrollara el proyecto puede ser
pequeño y puede tener miembros intermitentes o que solo contribuyan en ciertas partes, una
solución de software de este tipo suele ser ideal.
En la figura 3.2 se presente la arquitectura propuesta. Esta es una arquitectura basada en capas
donde se contará con 6 capas: capa de hardware; capa de drivers; capa de Sistema Operativo; capa
de servicios; capa del entorno de ejecución y capa de aplicaciones.
52
Figura 0.3 Arquitectura para un receptor de DTV con soporte para HbbTV
Como la mayoría de las arquitecturas de este tipo, las tres capas base del diseño son las clásicas.
La capa de hardware que representa el hardware del dispositivo receptor en sí, que tendrá todos
los componentes necesarios para la recepción de la señal de televisión, así como los puertos de
entrada/salida necesarios para acceder a un canal broadband, conectarse con otros dispositivos,
etc.; la capa de drives contendrá todos los drives que permitirán la comunicación y manipulación
del hardware por la tercera capa: la capa del Sistema Operativo.
La cuarta capa o capa de servicios, será la que contendrá todos los “servicios” que permitirán
recibir y procesar tanto la señal proveniente del canal de radiodifusión como del canal de banda
ancha. Como la arquitectura está basada en capas, la capa de servicios solo deberá ser explotada
por la capa superior: la capa de ejecución o “Entorno de Ejecución”. Los componentes de esta capa
serán detallados más adelante.
53
La capa de ejecución o “Entorno de Ejecución” es la responsable de mostrar las aplicaciones de
iTV, así como permitir la comunicación entre el receptor y todas las pantallas acompañantes
conectadas al mismo. Además, tiene la responsabilidad de servir de “puente” entre las aplicaciones
(capa superior) y la capa de servicios, agregando medidas de seguridad que permitirán ejecutar
aplicaciones de terceros sin comprometer la seguridad y estabilidad del sistema. Esta capa brindara
las funcionalidades de la capa inferior (y de la propia capa) mediante una API (Application
Programming Interface) en lenguaje JavaScript.
La sexta capa es la capa de aplicaciones, será aquí donde estarán alojadas todas las aplicaciones
propias del fabricante del receptor, del proveedor de servicios de radiodifusión o de terceros. Estas
aplicaciones deberán seguir el estándar HbbTV (ETSI, 2018) y su ciclo de vida será controlado
por el Manejador de Aplicaciones del Entorno de Ejecución.
3.2.1 Capa de Servicios
Por la importancia de esta capa, le dedicaremos especial atención pues acá coexistirán los
principales procesos del receptor en cuanto a recibir y procesar la señal digital nos referimos.
Podemos ver esta capa como una adición de servicios a un receptor de DTV clásico, para de esta
forma agregarle la capacidad de recibir y procesar contenidos interactivos enviados bajo el
estándar HbbTV. Con los componentes “Interfaz Broadcast”, “Demodulador”, “Demux”,
“Procesador Broadcasting” y “Media Player” es suficiente para recibir, procesar y presentar
contenido de televisión digital, por lo que estos componentes serán fundamentales para, al menos,
entregar contenido de televisión a los usuarios. La “Interfaz broadband” y el “Procesador IP” serán
solo necesarios si se quiere hacer uso del canal de banda ancha para recibir y enviar contenido,
como Video bajo demanda (VoD), contenido adicional para las aplicaciones relacionadas al canal
de radiodifusión, aplicaciones broadcast-independent, etc. Aunque hay que tener en cuenta que los
componentes fundamentales del entorno de ejecución serán necesarios para mostrar cualquier
aplicación interactiva. El “Filtro AIT”, el “Cliente DSM-CC” y el “Decodificador FDP” serán
necesarios para reconocer y descargar aplicaciones broadcast-related y otros servicios relacionados
al canal de radiodifusión.
Tanto la Interfaz Broadcast como la Interfaz Broadband son componentes abstractos para
representar la interfaz por donde se reciben los contenidos enviados por la red de radiodifusión y
54
de banda ancha respectivamente. Estas interfaces son compuestas tanto por hardware como por
software (controladores de dispositivos o drivers).
A diferencia de la Interfaz Broadcast, que deberá ser usada alguna herramienta, existente o de
desarrollo propio, la Interfaz Broadband es soportada, por lo general, por el propio sistema
operativo utilizado ya que está compuesta por los protocolos de red e internet, etc.
El Demodulador es un componente de software, hardware, o una combinación de ambos que se
encarga de recuperar la información enviada a través de la red de radiodifusión, que una vez
recibida por la Interfaz Broadcast pasa a este módulo. Este componente es capaz de convertir la
señal analógica a digital, para así poder ser procesada por el resto del sistema (Pérez, 2015). Una
vez que va convirtiendo la señal, la entrega al Demux.
En la figura 1.2 se muestra como se combinan varios canales de audio, video y datos para así poder
ser enviados en un solo flujo. Una vez recibida la señal, si en esta se transmite, por ejemplo, tres
programas: A, B y C; para poder ver el programa B, hay que separarlo del resto, este procedimiento
se hace tomando solo “las partes” de la transmisión correspondientes al programa B. Como
combinar estos programas en un solo flujo lo especifica el estándar ISO/IEC 13818-1 (Standard,
2000) y separarlos es el proceso inverso. La función de separar los programas enviados en el flujo
de transmisión pertenece al Demultiplexor o Demux, para simplificar.
El contenido A/V lineal es procesado como en cualquier otro receptor clásico no hibrido. Todas
las funciones relativas al manejo de este tipo de contenido será responsabilidad del Procesador
Broadcast que recibirá el contenido proveniente del Demux haciendo peticiones a este sobre que
flujos elementales necesita. Entre las funciones más destacadas están las relativas a la
sintonización, a la información de la lista de canales y a aquellas que involucran la EIT (Event
Information Table).
Muchas aplicaciones querrán incrustar audio, video o ambos como parte de su interfaz de usuario;
de reproducir estos contenidos se encargará el Media Player. Afortunadamente la mayoría de los
navegadores modernos poseen reproductores de contenidos, pero en caso esto no suceda, se deberá
dotar al navegador con uno.
El control del ciclo de vida de las aplicaciones, así como el comportamiento de que deben tener
estas es especificadas en un manifiesto, que conocemos como AIT (Application Information
55
Table). Estas tablas pueden ser enviadas a través del canal de radiodifusión o mediante el canal de
banda ancha. Para los casos en los que se utiliza el canal de radiodifusión, estas son enviadas en
un flujo elemental específico para ellas. Como una aplicación interactiva es un servicio, el flujo
elemental donde es transmitido estará representado en la PMT, y esta a su vez en la PAT como se
representa en la figura 2.1. El filtro AIT es el encargado de extraer la tabla en cuestión relacionada
a un programa o general, siempre que esta sea enviada por el canal de radiodifusión. Cuando la
AIT es enviada por medio del canal de banda ancha el Procesador IP será el encargado de
recuperarla y servirla a cualquier otro módulo que la necesite.
Los Stream Events y algunas aplicaciones broadcast-related pueden ser enviadas parcial o
totalmente por el canal de radiodifusión, para ello utilizan carruseles de objetos usando el protocolo
DSM-CC definido en el estándar ISO/IEC 13818-6 (Standard, 1995). El Cliente DSM-CC y el
Decodificador FDP (File Download Protocol) tienen la responsabilidad de recibir los datos
enviados y servirlos al Entorno de Ejecución o a cualquier otro componente que los necesite.
Todo el contenido entregado al Media Player puede ser sincronizado por el Manejador de
Sincronización con contenido adicional recibido a través del canal de radiodifusión o de banda
ancha. Además, el Manejador de Sincronización puede encargarse de sincronizar el contenido del
terminal y el de las pantallas acompañantes para amortiguar la latencia de la transmisión entre los
dispositivos y el tiempo de envío y procesamiento.
El componente “Procesador IP” comprende todas las funcionalidades proporcionadas por el
terminal para manejar los datos provenientes de internet. A través de este componente los datos de
las aplicaciones se proporcionan al entorno de ejecución, ya sean aplicaciones, contenido bajo
demanda, las tablas AIT en formato XML entre otros tipos de contenidos.
El “Updater” es un componente, que en cualquiera de los casos es opcional. La función de este
componente es simple: ¡Mantener el software actualizado! Para lograr su objetivo tiene que tener
en cuenta el uso del canal de banda ancha para no saturar el mismo descargando datos de
actualizaciones mientras se descarga otro tipo de contenido crítico para no arruinar la experiencia
de usuario.
56
3.2.2 Entorno de Ejecución
El Entorno de Ejecución es el encargado de comunicarse con la capa de servicios y proporcionar
un API para que las aplicaciones puedan reproducir contenido transmitido por el canal de
radiodifusión o por el canal de banda ancha. Esta capa contara con tres componentes, aunque
pueden agregarse más en caso que sea necesario para separar aún más las responsabilidades; estos
componentes son: un navegador web, un manejador de aplicaciones y una interfaz para pantallas
acompañantes.
Los datos de aplicaciones serán entregados a estas por medio del Entorno de Ejecución y del
navegador. El Entorno de Ejecución también será responsable de recibir e interpretar los Stream
Events y trabajar como un “director de orquesta” controlando el navegador, el manejador de
aplicaciones y las pantallas acompañantes.
El navegador web debe ser capaz de soportar HTML 5, CSS, JavaScript, y debe ser compatible
con la especificación de Open IPTV Forum (OIPF), brindando su API para que pueda ser
consumida por las aplicaciones que se ejecuten en él. Además, debe ser compatible y capaz de
integrarse con el Media Player utilizado, o tener uno propio capaz de reproducir contenido en
streaming.
Las aplicaciones se inician o se destruyen según el ciclo de vida de estas, especificado por el
estándar HbbTV y reflejado en la AIT cuando es recibida. El Manejador de Aplicaciones es el
responsable de controlar este ciclo de vida, así como el encargado de interpretar las tablas AIT
recibidas del canal de radiodifusión o de banda ancha.
La característica de “pantalla acompañante” fue introducido en HbbTV en la versión 1.4 del
estándar. Este componente solo es necesario si se desea que otros dispositivos se conecten al
terminal para reproducir contenido o ejecutar las aplicaciones interactivas desde otro dispositivo.
Gracias a esta característica con un solo terminal se puede reproducir contenidos transmitidos
distintos en diferentes dispositivos que estén conectados al terminal. El Trabajo de fin de Máster
“Desarrollo de servicios OTT síncronos mediante el estándar HbbTV 2.0.1 para TV digital”
(Gómez, 2018) puede servir de base para comprender este componente, así como las tecnologías
involucradas para que una pantalla acompañante funcione correctamente.
57
3.3 PROPUESTA DE TECNOLOGÍAS QUE SE PUEDEN UTILIZAR PARA LA
IMPLEMENTACIÓN.
Si bien no hay soluciones libres de alguno de los componentes para implementar el sistema de
software necesario para el funcionamiento de un receptor de televisión interactiva bajo el estándar
HbbTV, si hay softwares libres que permiten tanto la modificación como la comercialización de
los mismos sin coste alguno. Es insensato construir de cero, por ejemplo, un sistema operativo o
un navegador; dado la complejidad de los softwares de este tipo, el desarrollo requeriría
probablemente, docenas de desarrolladores, un tiempo considerable, así como un presupuesto no
demasiado modesto. Para resolver este problema es más económico modificar algún software
existente que permita tanto modificaciones como comercialización en su licencia.
3.3.1 Sistema Operativo
Actualmente muchos STB emplean software baremetal que ejecuta directamente sobre el
hardware, sobre todo en dispositivos de bajas prestaciones, así pueden aprovechar mejor los
recursos y explotarlos sabiamente; el principal problema de este tipo de software es que suele ser
muy complicado su modificación ya que pueden tener un gran porciento de su código base en
código ensamblador. Los STB de mayores prestaciones han optado por usar sistemas operativos
de propósito general para hacer uso de las facilidades que estos brindan. Uno de los sistemas más
utilizados con estos fines es GNU\Linux (Millo et al., 2016).
El kernel de los sistemas GNU\Linux brinda un conjunto de bibliotecas de programación API para
DVB (Comunity, 2019). Aunque el API se nombre DVB, no está restringido a este estándar,
soporta varios estándares de televisión y es fácilmente extensible a otros estándares.
3.3.2 TVHeadend
TVHeadend es un servidor de streaming de código abierto que puede leer secuencias de video
desde fuentes de LinuxTV y publicarlos como transmisiones de video visibles en dispositivos
como televisores inteligentes a través de una conexión de internet IP (IPTV). Se puede usar
también como grabadora. Las fuentes de entrada pueden incluir: DVB-S, DVB-C / T, ATSC, IPTV
y SAT> IP, por nombrar algunas. Ofrece servicio de streaming sobre HTTP, HTSP y SAT> IP.
Soporta múltiples fuentes para la EPG directamente transmitida mediante los estándares DVB o
ATSC.
58
3.3.3 Chromium
Chromium es un proyecto de código abierto de navegador web del que Google Chrome obtiene su
código fuente. Ambos navegadores comparten la mayoría del código y características, aunque hay
algunas diferencias menores en las características y poseen diferentes licencias.
El navegador es liberado y distribuido por Google y la comunidad Chromium bajo licencia BSD;
esta licencia permisiva permite el uso del código fuente en software no libres, lo que permite la
comercialización de los mismos (Comunity, 2018).
Al permitir modificaciones en el código fuente y comercialización es ideal para adoptarlo en
soluciones de software. Tal es el caso, que actualmente se ha utilizado en varios proyectos, tanto
libres como de pago. Ejemplo de esto es Electron, un framework para desarrollo de aplicaciones
multiplataforma que utiliza Chromium como entorno de ejecución de las aplicaciones; otro
ejemplo es el anteriormente mencionado: Tara Systems que lo utiliza en su solución de HbbTV.
Uno de los principales retos es agregar el API de OIPF al navegador, para ello se puede tomar
como punto de partida el proyecto de código abierto en GitHub “HybridTvViewer”.
3.4 CONCLUSIONES PARCIALES
Para lograr una completa independencia tecnológica en Cuba debemos desarrollar nosotros
mismos nuestras propias soluciones de software.
Crear una solución completa para un receptor de transmisión digital es costosa y requiere de un
grupo grande de desarrolladores talentosos, por lo que se deben utilizar software de código abierto
que con las modificaciones mínimas se adapten a nuestros requerimientos.
Los softwares que se seleccionen para usarse en la solución que de desarrolle deben no solo ser de
código abierto, sino que deben tener licencias permisivas que permitan la modificación y
comercialización del mismo. Si es posible, que no sea necesario publicar el código fuente de las
modificaciones realizadas.
A pesar que se piensa en la seguridad del software desde el momento del diseño de la arquitectura,
esta es solo una abstracción de la realidad, por lo que debe concretarse en el momento de diseño
de cada componente a detalle y, más concretamente, en el momento de implementación de los
mismos.
59
60
CONCLUSIONES
• A pesar que el estándar de TDT DTMB es uno de los estándares más recientes fue bien
pensado y tuvo en cuenta las mejores características de otros estándares como DVB y
ATSC en su implementación.
• HbbTV se ha convertido en objetivo de implementación de varios países e instituciones;
tal es el caso que, prácticamente toda Europa ya ha comenzado a implementarlo y
compañías multinacionales como Samsung, LG o Sony han comenzado a integrar sus
sistemas de Smart TV con el estándar HbbTV en sus televisores inteligentes.
• MHP fue uno de los estándares más utilizados en Europa y aún continúa siendo un estándar
muy potente; pero una de las principales razones de su desuso ha sido la reclamación de
royalties por alguna de las compañías de las que se tomaron tecnologías para su
implementación.
• Aunque HbbTV fue creado en Europa y la descripción de la norma toma como estándar de
transmisión el DVB, puede y ha sido adaptada a otros estándares de transmisión; teniendo
en cuenta que los estándares de transmisión actuales utilizan MPEG-2 o MPEG-4 para
transmitir el contenido televisivo y es acá donde se inserta el contenido HbbTV.
• El desarrollo de la interactividad depende en gran medida del desarrollo de sistemas de
software para facilitar la creación de contenidos interactivos en las instituciones encargadas
de crear y gestionar los contenidos televisivos que se transmiten.
• A pesar de que no se encontró una solución de software libre para la implementación del
receptor de televisión interactiva con soporte para HbbTV, existen tecnologías libres que
pueden, con algunas modificaciones integrarse con otras y crear una solución completa.
61
RECOMENDACIONES
• Crear un grupo de trabajo para la estudiar cómo implementar el estándar HbbTV en los
transmisores de contenidos televisivos; así como la implementación de tecnologías que
faciliten el proceso de creación de aplicaciones broadcast-related para la asociación con
programas televisivos transmitidos.
• Crear un grupo de trabajo para el desarrollo de equipos receptores de televisión digital
terrestre con soporte para el estándar HbbTV.
• Dedicar el tiempo que sea necesario para realizar un buen diseño de todos los componentes
de la arquitectura presentada en el presente trabajo de Diploma para su posterior
implementación.
• Para diseñar un software es necesario tener profundos conocimientos teóricos y prácticos
del hardware objetivo y de desarrollo de software. Por lo que se recomienda que el grupo
encargado del diseño de los componentes de la arquitectura presentada en el presente
trabajo de diploma, o cualquier otra arquitectura, conozcan profundamente el
funcionamiento del estándar HbbTV y DTMB con todos los componentes que conforman
a estos antes de comenzar el diseño.
• En los grupos de desarrollo creados en la Universidad Central se aprovecha el potencial de
los estudiantes que se vinculan a los grupos de investigación. Para una mejor integración
de estos en los grupos de desarrollo, se debe documentar todos los avances que se realicen
de la forma más sencilla posible para que sea más fácil el entrenamiento de los estos nuevos
miembros que se incorporan.
• En el 2019 se habla con bases teóricas que las aplicaciones son el futuro de la televisión,
sobre todo, por el valor agregado que aportan estas. Por lo que el desarrollo de estas es de
vital importancia, se recomienda crear una asignatura optativa para las carreras de
Ingeniería Informática y Ciencias de la Computación donde se enseñe cómo desarrollar
aplicaciones para la plataforma HbbTV.
62
BIBLIOGRAFÍA
An Introduction To Digital TV Technology – TV Without Borders (no date). Available at:
http://www.tvwithoutborders.com/tutorials/dtv_intro/dtv_intro/ (Accessed: 4 June 2019).
Arce, I. E. (2014) ‘Estudio del estándar de televisión digital interactiva HbbTV e
implementación de aplicación final Proyecto final de carrera’.
Bretl, W. et al. (2006) ‘ATSC RF, Modulation, and Transmission’, Proceedings of the IEEE,
94(1), pp. 44–59. doi: 10.1109/JPROC.2005.861018.
Chie, S., Zambrano, M. and Medina, C. (2015) ‘Actualidad Tecnológica Estándares actuales de
televisión digital : Actualidad Tecnológica’, 6, pp. 19–23.
Comunity (2018) ‘Licencia BSD’, pp. 1–5.
Comunity, L. D. (2019) ‘Linux Media Subsystem Documentation’.
Digital Terrestrial Television (DTT) - World Map (high resolution) (no date). Available at:
http://www.dtvstatus.net/map/map.html (Accessed: 1 June 2019).
El-Hajjar, M. and Hanzo, L. (2013) A Survey of Digital Television Broadcast Transmission
Techniques, Communications Surveys & Tutorials, IEEE. doi:
10.1109/SURV.2013.030713.00220.
ETSI (2009) ‘EN 300 744 - V1.6.1 - Digital Video Broadcasting (DVB); Framing structure,
channel coding and modulation for digital terrestrial television’, European Broadcasting Union,
1, pp. 1–66.
ETSI (2018) ‘HbbTV - Hybrid Broadcast Broadband TV (TS 102 796 v1.5.1)’, 1, pp. 1–316.
Fay, L., Kutzner, J. and Pizzi, S. (2014) ‘The Next Generation Broadcast Television System’, pp.
0–3.
Gómez, A. L. (2018) ‘Desarrollo de servicios OTT síncronos mediante el estándar HbbTV 2.0.1
para TV digital’.
HTML5 (no date). Available at: https://www.w3.org/TR/2014/REC-html5-20141028/ (Accessed:
3 June 2019).
63
Institute European Telecommunications Standards (2017) ‘Digital Video Broadcasting;
Signalling and carriage of interactive applications and services in Hybrid broadcast/broadband
environments’, 1, pp. 1–149.
ISO (2015) ‘ISO/IEC IS 23009-1: 2014 (E) “Information technology - Dynamic adaptive
streaming over HTTP (DASH) – Part 1: Media presentation description and segment formats,”
May, 2014’.
ISO (2016) ‘INTERNATIONAL STANDARD ISO / IEC systems technologies — transport
streams’.
Julia, A. et al. (2017) Especificación de receptores de televisión digital terrestre para
aplicaciones interactivas.
Ladebusch, U. and Liss, C. A. (2006) ‘Terrestrial DVB (DVB-T): A Broadcast Technology for
Stationary Portable and Mobile Use’, Proceedings of the IEEE, 94(1), pp. 183–193. doi:
10.1109/JPROC.2005.861009.
López de Zuazo Algar, A. (2000) ‘Teletexto y el pensamiento divergente’, Estudios sobre el
mensaje periodístico, (6), pp. 259–271. Available at:
http://dialnet.unirioja.es/servlet/articulo?codigo=184781&orden=1&info=link.
Middleware, O. and Tv, I. (2011) ‘Multimedia Home Platform: Open Middleware for Interactive
TV’, DVB Fact Sheet, (May).
Millo, R. et al. (2016) ‘Propuesta de set-top box cubano empleando alternativas de software
libre’, (December).
Morante, M. (2011) ‘Entre La Tdt Y El Ordenador : Nuevas Tendencias Tecnológicas ,
Empresariales Y De Consumo Alrededor De La Ficción Audiovisual En España 1 Tdt Between
and the Computer : Technology Trends , Consumer and Business Around the Audiovisual
Fiction in Spain’, pp. 72–98.
Muñoz, E. M. (2010) ‘Plataforma TDT interactiva. Servicios municipales para la provincia de
Sevilla’, pp. 25–40.
OIPF (2014) OIPF - Release 2 Specification - Volume 5a, Web Standards TV Profile, V2.3.
64
Available at: http://www.oipf.tv/web-spec/volume5a.html (Accessed: 3 June 2019).
OIPF - Release 2 Specification - Volume 5a, Web Standards TV Profile, V2.3 (no date).
Available at: http://www.oipf.tv/web-spec/volume5a.html (Accessed: 3 June 2019).
Opera TV is Now Vewd - Vewd (2019). Available at: https://www.vewd.com/news/opera-tv-is-
now-vewd/ (Accessed: 12 June 2019).
Pafundi, Debora G. Kantor, Mariana r. Marcalettu, L. (2013) ‘Buenos Aires 2013’.
Pérez, C. (2015) ‘Transmision De Television Digital’, Universidad de Cantabria, Dpto. de
Ingeniería de Comunicaciones, (February), p. 1. Available at:
http://personales.unican.es/perezvr/pdf/estandares de transmision digital.pdf.
Richer, M. S. et al. (2006) ‘The ATSC Digital Television System’, Proceedings of the IEEE,
94(1), pp. 37–43. doi: 10.1109/JPROC.2005.861714.
Sánchez Millo, R. et al. (2018) ‘La interactividad en la Televisión Digital: su desarrollo en Cuba
Interactivity in Digital Television : its development in Cuba’, 1(1), p. 15.
Sobre Ginga | Ginga (no date). Available at: http://www.ginga.org.br/es/sobre (Accessed: 27
May 2019).
Song, J. et al. (2007) ‘Technical review on Chinese digital terrestrial television broadcasting
standard and measurements on some working modes’, IEEE Transactions on Broadcasting,
53(1), pp. 1–7. doi: 10.1109/TBC.2007.891835.
Standard, C. N. (2007) ‘Framing Structure, Channel Coding and Modulation for Digital
Television Terrestrial Broadcasting System (DTMB)’.
Standard, I. (1995) ‘INTERNATIONAL lSO / lEC’, 1995.
Standard, I. (2000) ‘Iso13818-1(Mpeg2Ts).Pdf’, 2000.
Suárez (2009) ‘Las Políticas Públicas de la Televisión Digital Terrestre en la Unión Europea
Estudio comparado de Suecia y España Roberto Suárez Candel’, p. 625.
Takada, M. and Saito, M. (2006) Transmission system for ISDB-T, Proceedings of the IEEE. doi:
10.1109/JPROC.2005.859692.
65
Tomasi, J. D. G. (2012) ‘DESARROLLO DE UN SERVICIO DE TELEVISIÓN
INTERACTIVA HbbTV SEGÚN EL ESTÁNDAR ETSI TS 102 796 v1.1.1’.
Velásquez l., Zambrano M. and Medina C. (2014) ‘Redes eléctricas de interiores como canal de
comunicación’, Prisma Tecnológico, 5, pp. 39–42. Available at:
http://www.utp.ac.pa/documentos/2015/pdf/10-
TECNOLOGIA_A_FONDO_REDES_ELECT._39-42pdf_0.pdf.
Villamarín, D. et al. (2013) ‘Generating a transport stream for digital terrestrial television system
in conformance with ISDB-Tb standard’, 2013 IEEE Colombian Conference on Communications
and Computing, COLCOM 2013 - Conference Proceedings, (May). doi:
10.1109/ColComCon.2013.6564814.
Whitaker, J. C. (2012) ‘Advanced Television Systems Committee Standards Update’, SMPTE
Motion Imaging Journal, 116(9), pp. 359–363. doi: 10.5594/j16079.
Zapata, D. F. V. (2014) ‘Estudio comparativo y de integración para las plataformas de televisión
interactiva europea HbbTV y lationoamericana Ginga’.
