UNIVERSIDAD POLITÉCNICA DE MADRID

Escuela Técnica Superior de Ingeniería y Sistemas de

Telecomunicación

Proyecto Fin de Carrera

Análisis y desarrollo de aplicaciones de VOD para

múltiples dispositivos

Autor: Ignacio López Gómez

Tutor: Danilo Simón Zorita
Madrid, 2017

I
II
 PROYECTO FIN DE CARRERA
PLAN 2000
ETSIS TELECOMUNICACIÓN

TEMA: Aplicaciones de vídeo bajo demanda (VOD)

TÍTULO: Análisis y desarrollo de aplicaciones de VOD para múltiples dispositivos.

AUTOR: Ignacio López Gómez

TUTOR: Danilo Simón Zorita Vº Bº.

DEPARTAMENTO: TEORÍA DE LA SEÑAL Y COMUNICACIONES

Miembros del Tribunal Calificador:

PRESIDENTE: José Luis López Presa

VOCAL: Danilo Simón Zorita

VOCAL SECRETARIO: Martina Eckert
DIRECTOR:
Fecha de lectura:

Calificación: El Secretario,

RESUMEN DEL PROYECTO:

Con este proyecto fin de carrera quiero profundizar en el mercado del consumo de vídeo en el hogar,
analizando la evolución que ha sufrido desde un modelo de distribución lineal por aire o cable,
mayoritariamente sobre dispositivos de televisión, hacia un modelo de distribución sobre internet con
aplicaciones de video bajo demanda que pueden ser ejecutadas sobre cualquier dispositivo que tenga
conectividad a internet.

En la memoria primero realizo un análisis de la arquitectura de este modelo de distribución de contenido,

de forma que podamos entender los retos a los que hay que enfrentarse cuando se quiere llevar a cabo
una aplicación en dicho entorno.

En segundo lugar profundizo en los dispositivos y tecnologias que tienen mayor presencia en el mercado,
de forma que las herramientas a desarrollar abarquen el mayor número de casos posibles.

En la parte final deasarrollo una herramienta que permite generar el esqueleto de una aplicación con un
minimo esfuerzo. Asi mismo el esqueleto se ha creado teniendo en mente los posibles casos de uso y
retos que nos podemos encontrar cuando desarrollamos este tipo de aplicaciones.

III
IV
Resumen

Este proyecto de fin de carrera tiene como objetivo profundizar en el ecosistema de las
aplicaciones de vídeo bajo demanda (Video On Demand, VOD por sus siglas en inglés),
entendiendo todos los retos a los que nos tenemos que enfrentar y enumerando las
herramientas con las que contamos actualmente en el mundo del código abierto (Open
Source Software, OSS por sus siglas en inglés), para finalmente desarrollar una serie de
utilidades que puedan ser aprovechadas por cualquier desarrollador que quiera introducirse
en él.

Para poder cumplir con el objetivo dividiremos el proyecto en dos partes, una primera
de análisis y otra de implementación y desarrollo.

La primera parte del análisis se centra en la evolución del mercado de aplicaciones de

vídeo desde un modelo de distribución por el aire (Over The Air, OTA por sus siglas en
inglés) o de televisión por internet (IPTV, por sus siglas en inglés) hacia un modelo de
distribución por internet (Over The Top, OTT por sus siglas en inglés) y que es lo que lo
ha motivado.

En la segunda parte analizo el ecosistema OTT necesario para que las aplicaciones VOD
existan, entendiendo con cuales de estos actores nos tendremos que comunicar desde
nuestra aplicación, los problemas que tenemos que afrontar y las posibles soluciones de
software de código abierto de las que nos podemos beneficiar a la hora de abordar un
desarrollo.

La implementación y desarrollo de las herramientas se ha realizado para dispositivos que

soporten HTML y JavaScript (JS en adelante). La solución se basa en la creación de un
generador de aplicaciones para dispositivos conectados (Connected TV, CTV por sus siglas
en inglés) así como una estructura base que sirva para organizar el código, dando orden a
todos los componentes del framework elegido.

La solución se ha desarrollado teniendo en mente la diversidad que existe en la actualizad

de sistemas operativos y herramientas al alcance de los desarrolladores de aplicaciones
HTML JavaScript, de forma que cualquier persona, relacionada o no con dicho mundo,
pueda introducirse en el desarrollo de aplicaciones VOD de la forma más sencilla posible.

Para alcanzar este objetivo en esta memoria se incluye un manual de usuario con todos
los detalles necesarios para dejar listo el entorno de desarrollo, así como todas las
consideraciones a tener en cuenta antes de empezar a programar.

V
Abstract

The aim of this project is to deeply explore the ecosystem of the video on demand
applications (VOD from now on) and the challenges that developers reviewing the existing
open source software (OSS from now on) frameworks face when creating a series of tools
applicable to their needs.

In order to fulfill my project’s proposed objectives, I have divided my paper into two
sections, the first part focused on analysis and the second one on the implementation and
development of the tool and an example application.

In terms of analysis, this paper will center on how the market has evolved from an Over-
the-Air broadcasting to IPTV platforms, and finally to an Over-the-Top (OTT from now
on) distribution, utilizing the internet for it.

For the second half of my paper, I have researched the OTT ecosystem and all necessary
requirements from an application perspective in order to better understand the challenges
that developers encounter when developing said applications.

For the purposes of this project, distinct tool development comprising a code generator
and basic TAL BBC framework scaffolding has been implemented for HTML/JS enabled
devices. This was done in order to help developers understand how to best arrange coding
and application components.

Keeping in mind the diversity of the available operating systems and free tools in the
market, my aim has been to make the adoption of such technologies easier for any developer
to use.

In order to attain this objective, I have included a user manual as well listing all
requirements for using the generator tool.

VI
Agradecimientos
A María. Sin tu infinita paciencia, tu ilusión y tu amor esto no sería posible. Te pondría
de coautora solo por las veces que me has escuchado hablar de este proyecto mostrando
todo tu interés.

A Rubén por todos estos años demostrándome que siempre tienes razón. Míranos,
ingenieros después de tantos años. Te voy a tener que dar las gracias una vez más por estar
ahí siempre para darme un empujón cuando lo necesito.

A Tania, Alberto y Bea. Habéis hecho que mi paso por la universidad sea mucho más
que conocimiento. Gracias por todas esas risas y horas de estudio en la biblioteca.

A Danilo por la paciencia, además de su apoyo, optimismo y confianza mostrada desde

el principio. Sin ti esto no sería posible.

A mi familia. No habéis perdido la fe en mí en ningún momento y siempre me habéis

apoyado y ayudado a solucionar los problemas que se han planteado por el camino.

VII
VIII
Contenido
Resumen V
Abstract VI
Agradecimientos VII
Índice de figuras XI

1 Introducción y objetivos 13
1.1 Objetivos 15
1.2 Organización de la memoria 16
2 OTT. Distribución de vídeo sobre internet 17
2.1 Tipos de contenido 17
2.1.1 Contenido en directo 17
2.1.2 Contenido bajo demanda 18
2.2 Autor del contenido 18
2.2.1 Contenido propio 18
2.2.2 Contenido generado por usuarios 19
2.3 Modelo de monetización 20
3 Ecosistema OTT 21
3.1 Plataformas de Vídeo Online 22
3.1.1 Gestores de identidad 22
3.1.2 Gestión de contenido 26
3.1.3 Infraestructura de vídeo 28
3.1.4 Gestión de derechos digitales 29
3.1.5 Analíticas 33
3.1.6 Monetización 35
3.2 RED 36
3.2.1 Web APIs 36
3.2.2 Redes de distribución de contenido 38
3.3 Aplicaciones cliente 39
3.3.1 Anatomía de las aplicaciones 40
3.3.2 Dispositivos 44
3.3.3 Fragmentación 49
3.4 Software 52
3.4.1 Conclusiones 54
3.5 Plataformas OTT 55
4 Streaming de contenido 57
4.1 Infraestructura 57
4.2 Anatomía del Stream 59
4.2.1 Protocolos de transmisión 59
4.2.2 Estrategias de transmisión 59
4.2.3 Pseudo-streaming 61
4.2.4 Descarga adaptativa 62
4.2.5 Contenedores 63
4.2.6 Encriptación y gestión de derechos digitales 64
4.2.7 Codecs 66
4.3 Procesado del contenido 66
4.3.1 Encoding 67
4.3.2 Generación de fragmentos 67
4.3.3 Encriptación 67
4.3.4 Generación de Índices 68

IX
5 Análisis de dispositivos HTML JS 69
5.1 Hardware y capacidades 69
5.1.1 Pantallas 69
5.1.2 Métodos de entrada 70
5.1.3 Aceleración y capacidades de CPU 71
5.2 Aplicaciones en pantallas grandes 72
5.3 JavaScript 74
5.3.1 Historia 74
5.3.2 JavaScript en dispositivos conectados 76
5.4 Frameworks JS 77
5.5 Conclusiones 81
6 Análisis TAL BBC 83
6.1 Fundamentos TAL 84
6.1.1 Módulos 84
6.1.2 Composición 86
6.1.3 Widgets 89
6.1.4 Componentes 90
6.1.5 Composición de pantallas 93
6.1.6 Navegación y gestión de foco automática 94
6.1.7 Dispositivo 95
6.2 Problemas detectados 96
6.3 Conclusiones 98
7 Aplicación - Generador Yeoman TAL 99
7.1 Retos 99
7.1.1 Estructura 99
7.1.2 Código de ejemplo 99
7.2 Entorno de desarrollo 100
7.2.1 Editor de código 100
7.2.2 Navegadores 101
7.2.3 Herramientas de desarrollo 101
7.2.4 Node.js 102
7.2.5 NPM 102
7.2.6 TAL 102
7.2.7 Gulp 102
7.2.8 Yeoman 103
7.3 Desarrollo de Generador TAL 103
7.3.1 Generador TAL 103
7.3.2 Aplicación TAL Ejemplo 104
7.3.3 Implementación generator-tal 108
8 Conclusiones 111
9 Líneas futuras de investigación 113
9.1 Desarrollo de un framework multiplataforma 113
9.2 Desarrollo de reproductor HTML5 114
10 Glosario 117
11 Bibliografía 119

Anexo A – Manual de usuario 121

Anexo B - Manual de referencia 122

X
Índice de figuras

Figura 2.1: Modelos de monetización............................................................................................. 20

Figura 3.1: Arquitectura entornos OTT .......................................................................................... 21
Figura 3.2: Plataforma de vídeo online. .......................................................................................... 22
Figura 3.3: Gestores de identidad ................................................................................................... 23
Figura 3.4: Netflix y SSO con Facebook ........................................................................................ 24
Figura 3.5: Teclado en pantalla. ...................................................................................................... 25
Figura 3.6: Código de conexión. ..................................................................................................... 25
Figura 3.7: Gestores de contenido .................................................................................................. 26
Figura 3.8: Modelo datos VCMS .................................................................................................... 27
Figura 3.9: Infraestructura de vídeo ................................................................................................ 28
Figura 3.10: Gestión de derechos digitales ..................................................................................... 29
Figura 3.11: Ejemplo DRM ............................................................................................................ 32
Figura 3.12: Gestión de Analíticas.................................................................................................. 33
Figura 3.13: Monetización .............................................................................................................. 35
Figura 3.14: Acciones Restful y verbos HTTP ............................................................................... 37
Figura 3.15: Red CDN .................................................................................................................... 38
Figura 3.16: Pantalla de inicio de Netflix ....................................................................................... 40
Figura 3.17: Pantalla de login de HULU ........................................................................................ 41
Figura 3.18: Pantalla principal de HBO.......................................................................................... 41
Figura 3.19: Pantalla de detalle de Amazon Prime ......................................................................... 42
Figura 3.20: EPG ............................................................................................................................ 42
Figura 3.21: Reproductor de vídeo de YouTube ............................................................................ 43
Figura 3.22: Devices Owned (IAB + Maru/Matchbox, 2017) ........................................................ 44
Figura 3.23: Devices Used to Stream Digital Video (IAB + Maru/Matchbox, 2017) .................... 45
Figura 3.24: Cardboard VR de Google .......................................................................................... 48
Figura 3.25: Tethered VR de Oculus ............................................................................................... 49
Figura 3.26: OTT Hardware (Accedo, 2017).................................................................................. 50
Figura 3.27: Versiones iOS (Apple, 2017) y Android. (Google, 2017).......................................... 53
Figura 3.28: Diagrama Plataforma OTT ......................................................................................... 55
Figura 4.1: Flujo streaming contenido ............................................................................................ 57
Figura 4.2: Anatomía del contenido de vídeo ................................................................................. 59
Figura 4.3: Descarga progresiva ..................................................................................................... 60
Figura 4.4: Pseudo-streaming ......................................................................................................... 61
Figura 4.5: Descarga adaptativa ...................................................................................................... 62
Figura 4.6: PlayReady Protection Header....................................................................................... 65
Figura 4.7: Procesado de vídeo ....................................................................................................... 66
Figura 5.1: Regla de los 3 metros (Samsung, 2017) ....................................................................... 72
Figura 5.2: Navegación y foco. (Samsung, 2017) .......................................................................... 73
Figura 5.3: Línea de tiempo estándar ECMAScript........................................................................ 76
Figura 6.1: Arquitectura TAL. ........................................................................................................ 83
Figura 6.2: Definición módulos Require.js ..................................................................................... 85
Figura 6.3: Carga de módulos directa ............................................................................................. 86
Figura 6.4: Recuperar instancia de módulo .................................................................................... 86
Figura 6.5: Herencia y sobre escritura. ........................................................................................... 87
Figura 6.6: Herencia de primer nivel .............................................................................................. 88
Figura 6.7: Ciclo de vida de un componente .................................................................................. 91

XI
Figura 6.8: TAL Composición de pantallas .................................................................................... 93
Figura 6.9: TAL Gestion del foco ................................................................................................... 94
Figura 6.10: Obtención del dispositivo. .......................................................................................... 95
Figura 6.11: Almacenamiento persistente....................................................................................... 95
Figura 6.12: XHR............................................................................................................................ 95
Figura 6.13: Reproducción de contenido. ....................................................................................... 96
Figura 7.1: Entorno de desarrollo ................................................................................................. 100
Figura 7.2: Estructura aplicación TAL Ejemplo ........................................................................... 104
Figura 7.3: Pantalla base ............................................................................................................... 105
Figura 7.4: Pantalla principal ........................................................................................................ 106
Figura 7.5: Lista de vídeos ............................................................................................................ 107
Figura 7.6: Detalle de vídeo .......................................................................................................... 107
Figura 7.7: Reproductor de vídeo ................................................................................................. 108
Figura 7.8: Estructura generador-tal ............................................................................................. 109

XII
1 Introducción y objetivos
Actualmente estamos viviendo un cambio en la forma de consumir vídeo por parte de
los usuarios. Este solo se puede llegar a entender si tenemos en cuenta la evolución que ha
sufrido este sector, junto con el de la electrónica de consumo y el acceso a internet. Todos
estos ingredientes han facilitado esta transición.

Antes de la distribución de contenido de vídeo a través de internet, si un usuario quería

ver la televisión las opciones eran pocas, pudiendo consumir contenido abierto en los canales
tradicionales, normalmente emitido por el aire (Over The Air, OTA por sus siglas en inglés)
de forma analógica o digital, mediante antenas terrestres o satelitales; o ver contenido
premium a través de modelos de suscripción, usando las mencionadas emisiones OTA o
cable.

Con la irrupción de internet, varias compañías ofrecieron un modelo IPTV de emisión

haciendo uso de conexiones dedicadas de internet, con un ancho de banda independiente
al de la velocidad contratada, para garantizar la calidad de la transmisión. A este modelo
se lo conoce como de distribución por internet (Over The Top, OTT por sus siglas en
inglés).

Al mismo tiempo que el consumo de contenido premium captaba cada vez más usuarios,
algunas compañías como BBC empezaron a crear los primeros servicios de prueba de
distribución de vídeo bajo demanda (Vídeo On Demand, VOD por sus siglas en inglés),
aunque no pasaron de pruebas de concepto ya que, entre otros motivos, la tecnología aún
no estaba lista e internet no estaba suficientemente implantado en los hogares.

La revolución de la electrónica de consumo en el sector de las pantallas de televisión y

de la telefonía móvil, junto con el aumento del ancho de banda en las redes móviles y el
hogar gracias al despliegue de kilómetros de fibra óptica como se puede observar en el
informe (Council, FTTH, 2011), propiciaron las condiciones necesarias para el comienzo de
la implantación del VOD.

En paralelo, el fenómeno de YouTube empezó a fraguarse. Creada en 2005 como una

plataforma de intercambio de vídeo entre usuarios, esta página sentó las bases de lo que
vendría a continuación. Con un interfaz sencillo, los usuarios empezaron a subir todo tipo
de contenido. Al poco tiempo Google compro la compañía e integró su servicio de
monetización por publicidad que resultó en millones de usuarios subiendo contenido para
poder monetizar el mismo. Con el tiempo Google ha evolucionado el servicio y los productos
asociados, siendo una de las páginas web más conocidas de todos los tiempos.

El éxito de YouTube no pasó desapercibido. Multitud de páginas imitadoras inundaron

internet, siendo mucho más laxos que Google a la hora de controlar el contenido subido
por sus usuarios, resultando en multitud de quebrantamientos de derechos de autor (o

13
copyright en inglés) de películas y series. Estas páginas sentaron la base de cómo se
consumiría vídeo de forma online en los siguientes años.

Además, la popularidad de YouTube hizo que varios fabricantes pusieran su foco en ella,
incluyendo aplicaciones con una funcionalidad muy básica en sus dispositivos a modo de
reclamo. La semilla de las aplicaciones en los dispositivos conectados estaba plantada.

Con todos estos eventos ocurriendo al mismo tiempo, Netflix, compañía de venta y
alquiler por correo de DVD, inició su negocio de VOD en el 2007, sufriendo un gran
crecimiento de usuarios, llegando a superar los 100 millones de clientes globales en el primer
cuatrimestre de 2017 (Netflix, 2017) y al conjunto de las compañías de cable más
importantes en USA en número de abonados (Tom Huddleston, 2017). Estos datos
confirman el desplazamiento que están sufriendo los modelos de consumo de vídeo más
tradicionales respecto a los nuevos.

Al igual que paso con YouTube, el éxito de Netflix ha movilizado a distintos tipos de
compañías que no quieren perder la oportunidad de entrar en un negocio que se prevé siga
creciendo en los próximos años.

Con una estimación de que en 2019 el 80% de tráfico en internet será vídeo (Cisco,
2015), empresas que tradicionalmente no han tenido relación con el mismo, como Amazon
o Apple, se han sumado a la creación de aplicaciones VOD, al igual que las compañías de
medios tradicionales como HBO y Sky.

Todo este crecimiento ha fomentado el desarrollo de un ecosistema propio en el que

nuevos formatos de vídeo, servicios en la nube y dispositivos capaces de ejecutar las
aplicaciones necesarias para ver el vídeo, han aparecido en el mercado en muy poco tiempo
conformando un ecosistema muy complejo, fragmentado y dinámico.

A lo largo de este proyecto fin de carrera profundizo en los retos que supone el
enfrentarse al desarrollo de una aplicación VOD en este sector, analizando todos los actores
involucrados de forma que podamos entender los retos que conlleva. Finalmente repaso las
distintas soluciones de desarrollo disponibles para hacer dichas aplicaciones en función de
los dispositivos existentes en el mercado, justificando de esta forma el uso de tecnologías
web, para analizar las soluciones de código abierto y poder plantear el desarrollo de una
herramienta que nos facilite el trabajo a la hora de empezar nuevos proyectos.

En los siguientes puntos podemos ver los objetivos que me he marcado en el ámbito de
este proyecto y la organización de la memoria.

14
1.1 Objetivos
Los objetivos de este proyecto de fin de carrera son:

• Profundizar en el mercado de las aplicaciones de vídeo bajo demanda,

entendiendo qué tipo de entornos nos vamos a encontrar y segmentando las
distintas aplicaciones en función del modelo de negocio.

• Ser capaz de visualizar todo el ecosistema que rodea a este mercado.

• Mejorar el conocimiento acerca de los distintos modelos de distribución de vídeo

en internet, entendiendo como se procesan los mismos antes de llegar al usuario
final.

• Desmitificar la gestión de derechos digitales (Digital Rights Management, DRM

por sus siglas en inglés), entendiendo como funciona y las ventajas que aporta.

• Analizar en profundidad un framework de código abierto (Open Source Software,

OSS por sus siglas en inglés), que nos permita introducirnos en el mundo de
desarrollo de aplicaciones de vídeo bajo demanda para el mayor número de
dispositivos posible.

• Diseñar y desarrollar una herramienta que simplifique el desarrollo de aplicaciones

de vídeo en entornos OTT

• Crear toda la documentación necesaria para simplificar al máximo la

configuración de los entornos de desarrollo a nuevos desarrolladores.

A nivel técnico y académico los objetivos son:

• Aunar el conocimiento adquirido, durante los estudios de la ingeniería de

telemática, con el sector de la distribución de vídeo mucho más relacionado con
la ingeniería técnica de imagen y sonido.

• Aplicar los conocimientos en programación y redes para entender cómo funciona

un mercado en constante crecimiento

• Plasmar el conocimiento obtenido creando una aplicación de base para futuros

desarrolladores.

15
1.2 Organización de la memoria
En los siguientes capítulos podemos ver un análisis de todos los actores que están
implicados en las aplicaciones de distribución de vídeo sobre internet.

El análisis empieza en el Capítulo 2 con un estudio de los distintos modelos de

distribución de vídeo que existen y como esta segmentación condiciona en gran medida la
infraestructura y aplicaciones finales.

Dentro del capítulo dedicado al ecosistema OTT (Capítulo 3) desgrano cada uno de los
bloques que componen estas aplicaciones, de forma que podamos entender la complejidad
y problemática existente.

El Capítulo 4 trata sobre los streams de vídeo, como se construyen, el procesado de los
mismos y los resultados finales que consumirán los clientes

Los Capítulos 5 y 6 están dedicados a analizar el ecosistema de dispositivos que soportan

HTML/JS, llegando a la conclusión de que el framework TAL BBC es el más adecuado
para realizar una aplicación de vídeo bajo demanda.

En el Capítulo 7 explico la solución que he desarrollado, mostrando los retos a los que
nos enfrentamos cuando queremos hacer una aplicación y como, gracias al generador,
podemos ahorrar mucho tiempo configurando el entorno.

Las conclusiones y futuras guías de actuación están detalladas en los Capítulos 8 y 9.

En los Capítulos 10 y 11 encontraremos las referencias bibliográficas y el glosario, con

gran cantidad de acrónimos debido a los componentes que engloban este proyecto.

Finalmente, en el Anexo, podemos encontrar las instrucciones detalladas para montar

un entorno de desarrollo de aplicaciones de vídeo usando el generador desarrollado para
este proyecto de fin de carrera.

16
2 OTT. Distribución de vídeo sobre internet
Como vimos en el resumen e introducción de este proyecto, el contenido de vídeo OTT
se distingue del habitual en la forma en la que es distribuido, aunque también existen
diferencias en sus tipos.

La distribución desde internet elimina las limitaciones del vídeo tradicional, lo que ha
permitido la aparición de nuevos actores en la creación de producciones originales, así como
la posibilidad de distribuir el contenido en tiempo real o bajo demanda y crear nuevos
modelos de negocio en torno a todas estas variables y las aplicaciones que permiten
visualizarlo.

A grandes rasgos podemos realizar una segmentación del contenido teniendo en cuenta
los siguientes parámetros:

• Tipo de contenido

• Autor del contenido

• Modelo de monetización

2.1 Tipos de contenido

La distribución de vídeo desde internet elimina la limitación de tener que estar delante
de una televisión para poder ver la programación cuando es emitida por las cadenas.

En este punto veremos los dos distintos modelos de OTT, así como nuevas formas de
disfrutar del contenido directo.

2.1.1 Contenido en directo

El contenido en directo es emitido desde el origen en tiempo real a todos los usuarios
que estén conectados a dicha transmisión.

El contenido que podemos encontrar pasa por la distribución de los distintos canales
lineales por internet, eventos deportivos de cualquier rincón del mundo, conciertos de
música y recientemente infinidad de contenido creado por usuarios desde redes sociales
como YouTube, Facebook o Snapchat entre otras.

Sobre este fenómeno es interesante destacar como la irrupción y creciente popularidad

de los e-sports ha repercutido en la creación de nuevas plataformas de distribución de
contenido en directo como Twitch, YouTube Gaming o las plataformas propias de
Microsoft, Sony PlayStation y Nintendo, que permiten compartir a los usuarios de una
forma sencilla la señal de vídeo de las partidas a las que están jugando en ese momento, o
almacenar, editar y publicarlo posteriormente.

17
 En las transmisiones en directo por internet siempre existe cierto retraso si se compara
con la emisión por satélite o radio, ya que se debe descodificar esa misma señal, codificarla
y transmitirla por internet, de forma que la inversión en infraestructuras para minimizar
estos efectos es muy importante e incluso crítica en el caso de la transmisión de eventos
deportivos.

2.1.2 Contenido bajo demanda

El vídeo bajo demanda es contenido al que el usuario final accede cuando quiere, ya que
está disponible para su visualización en cualquier momento.

Puede ser contenido creado con este fin o contenido ya emitido (catch-up content, en
inglés) puesto a disposición del público.

Gracias al catch-up content se elimina la necesidad de estar presente en el momento de

inicio de emisión de un programa o la incapacidad de pausar el mismo, ya que, si se ofrece
este modelo de distribución, siempre podremos saltar al comienzo del contenido usando el
stream online, y de la misma forma hacer pausa sobre el mismo.

2.2 Autor del contenido

El contenido es el valor más diferenciado que tienen las distintas empresas. En este
punto veremos la importancia de crear contenido propio para no depender del de terceros.

2.2.1 Contenido propio

En este grupo se agrupan todas las empresas que generan su propio contenido.

Nos encontramos con empresas del sector de la comunicación con una gran historia a
sus espaldas como Disney, Comcast o HBO; compañías de telecomunicaciones como
Telefónica; grupos con derechos de retransmisión de eventos deportivos como NBA o
beINSPORTS; empresas que han crecido directamente gracias a esta tecnología, como
puede ser Netflix, Amazon o Hulu y grupos empresariales o universidades que ofrecen
cursos online (Massive Online Open Course, MOOC por sus siglas en inglés).

La irrupción de Netflix y su popularidad ha suscitado cierto recelo entre los distintos

creadores de contenido, generando tensiones a la hora de negociar los derechos de su
contenido original con terceros.

Esta situación ha propiciado que se empiece a invertir dinero en producciones originales

orientadas a distintos tipos de usuarios.

Empresas como Amazon que compiten directamente con Netflix y otras como Telefónica
Movistar se han sumado a esta corriente para no quedarse fuera del sector, atrayendo o
reteniendo a más usuarios con contenido inédito, exclusivo y de calidad.

18
 Actualmente pocas empresas pueden vivir exclusivamente de la distribución de su
producción, pero cada vez más han encontrado en internet una vía perfecta para ampliar
su negocio, al no depender de terceros para poder llegar a los usuarios, maximizando los
beneficios. HBO es un claro ejemplo, ya que cuenta con un catálogo muy atractivo que
hace que la gente se subscriba a su servicio para poder disfrutarlo. Contenido de terceros

En este grupo nos encontramos a casi todas las compañías que distribuyen contenido de
vídeo bajo demanda como series o películas, que combinan el contenido generado de forma
propia con el de terceras empresas sobre el que tienen derechos de distribución.

2.2.2 Contenido generado por usuarios

Dentro de este grupo nos encontramos generalmente el contenido que se distribuye en
casi todas las redes sociales, generado por parte de los usuarios.

El ejemplo más claro que tenemos de plataforma que nació para permitir compartir
vídeos entre usuarios es YouTube.

Este contenido está en constante crecimiento, lo que ha propiciado la aparición de nuevas

RRSS como Twitch, ligada al mundo de los vídeojuegos; SnapChat, red social para
adolescentes que se basa en la capacidad de compartir vídeo e imágenes con caducidad, o
la expansión de Twitter y Facebook hacia este sector.

El contenido ha evolucionado de ser casi exclusivamente para ser visualizado bajo

demanda, a poder ser partícipe de las emisiones en directo, ya que casi la totalidad de las
plataformas permiten la interacción entre los usuarios y los creadores en tiempo real.

Es un modelo muy ligado a la monetización por publicidad, aunque como podremos ver
se están intentando implantar más modelos.

19
2.3 Modelo de monetización

La razón de ser de cualquier negocio es la capacidad del mismo de generar ingresos

suficientes para que sea sostenible, existiendo en el sector del OTT varias formas de
monetizar la distribución del contenido.

Figura 2.1: Modelos de monetización

2.3.1.1 Compra o renta

En este modelo el usuario paga por la compra o alquiler de un contenido, dándole derecho
a acceder al mismo por un tiempo limitado, un número máximo de reproducciones o una
combinación de ambas.

2.3.1.2 Subscripción
Un modelo de subscripción permite que el usuario pague una cuota fija habitualmente
mensual que le da permisos para reproducir todo el catálogo de la plataforma que quiera
mientras dicha subscripción siga teniendo validez. Normalmente las subscripciones solo
permiten usar un número máximo de dispositivos al mismo tiempo para evitar usos
fraudulentos de las cuentas.

2.3.1.3 Publicidad
Es un modelo muy asociado a la distribución de vídeo en las redes sociales, pero también
se usa como complemento a las otras vías de monetización en países donde modelos
puramente transaccionales o de subscripción no son viables económicamente.

2.3.1.4 Comentarios destacados

Otro modelo de monetización se basa en la interacción existente entre los creadores de
contenido y los consumidores en tiempo real. Partiendo de esta base, Barbara MacDonald
ha anunciado en el reciente Google I/O ’17 la posibilidad de pagar para destacar
comentarios (McDonal., 2017) como además podemos ver en su página de respuestas
(Google, 2017), de forma similar a la que Twitch ofrece con el servicio de Cheer (Fontaine.,
2016).

20
3 Ecosistema OTT
El ecosistema OTT y más concretamente el centrado en la distribución de vídeo está
formado por un entramado de empresas muy diversas, así que es importante entender
cuáles son los factores diferenciadores entre ellas y cuáles son las partes que todas tienen
en común, de forma que seamos capaces de tener una visión más clara de los retos a los
que se enfrentan.

En la siguiente figura podemos ver las grandes piezas que conforman la arquitectura de
una aplicación OTT, los dispositivos cliente, la infraestructura de red y la plataforma de
vídeo online (Online Video Platform, OVP por sus siglas en inglés):

Figura 3.1: Arquitectura entornos OTT

En los siguientes puntos pasaremos a analizar todos estos bloques, explicando las
particularidades de cada uno y los retos a los que nos enfrentamos cuando nos integramos
con ellos.

21
3.1 Plataformas de Vídeo Online
Las plataformas de vídeo online u OVP como se les conoce habitualmente, engloban a
todos los servicios requeridos para que los usuarios sean capaces de consumir el contenido
de vídeo desde sus aplicaciones.

Algunos de estos servicios son comunes si los comparamos con otros productos, pero
muchos otros son específicos del mundo OTT, y en particular de las aplicaciones
relacionadas con la distribución de vídeo.

En la siguiente figura podemos ver el diagrama de un ecosistema OTT típico, mostrando

los bloques más habituales de un OVP:

Figura 3.2: Plataforma de vídeo online.

La mayoría de los distintos servicios son consultados desde las aplicaciones cliente
usando un interfaz de acceso a aplicación (Application Programming Interface, API por
sus siglas en inglés) directamente, ya sea de forma unificada bajo el mismo servicio o
accediendo a cada parte de manera independiente.

A continuación, vamos a repasar los bloques más interesantes para entender su

importancia y cómo se relacionan con el resto de los mismos.

3.1.1 Gestores de identidad

Dentro de este bloque encontraremos todos los servicios relacionados con la gestión de
los usuarios que conforman una aplicación VOD.

A nivel de infraestructura la gestión de usuarios requiere de una base de datos y los

servicios necesarios para poder garantizar su correcta gestión, tales como APIs de acceso o
paneles web para que los clientes puedan cursar las altas, bajas y modificación de datos.

22
 Desde un punto de vista de negocio los datos que podemos obtener de la gestión de
usuarios son muy diversos, como por ejemplo la edad media de los clientes, el sexo
mayoritario, el tiempo medio entre cada acceso a la aplicación, horas de entrada, etc. Todos
estos datos son utilizados para segmentar los usuarios y poder dirigir campañas de
marketing más eficientes.

En la siguiente figura podemos ver los servicios asociados a la gestión de identidad:

Identity Management

User User User

Sign in Log in Data

Figura 3.3: Gestores de identidad

3.1.1.1 Registro de usuarios

La mayoría de modelos de negocio de aplicaciones de vídeo requieren de un registro de
usuarios para poder dar acceso al catálogo disponible, ya sea de forma gratuita, con un
modelo de suscripción o mediante un pago puntual.

El registro puede realizarse desde las aplicaciones o de forma automática en los sistemas
del proveedor, como veremos a continuación.

El registro desde las aplicaciones es el modelo más habitual en los clientes OTT. En las
pantallas grandes es un proceso tedioso, de forma que se ha creado una forma distinta de
poder introducir los datos en dichos dispositivos. En el punto 3.1.5 explico este modelo de
alta de usuario.

Los proveedores de servicio como las compañías telefónicas pueden entregar

directamente dispositivos que están asociados a un usuario final, evitando el proceso de
registro. Estos dispositivos solo pueden ser usados habitualmente en la red personal del
cliente, y solo requieren de una pequeña configuración que garantice por ejemplo la
restricción de acceso a contenido de pago o para adultos.

3.1.1.2 Autenticación de usuarios

Como he mencionado anteriormente la mayoría de las aplicaciones requieren de un
registro de usuario y de la autenticación de los mismos para poder acceder a parte o la
totalidad del servicio.

Hay varias estrategias que son comúnmente utilizadas en este tipo de aplicaciones
23
Acceso unificado
El acceso unificado (Single Sign On, SSO por sus siglas en inglés) permite que un usuario
pueda usar una única cuenta para acceder a múltiples aplicaciones.

La aplicación que hace uso del mecanismo de SSO debe de comunicarse con la cuenta
externa para obtener la autorización por parte de la misma, y si es necesario los datos que
requiera del usuario.

Un caso muy habitual es el acceso a aplicaciones como Netflix mediante el uso de cuentas
en distintas RRSS como Facebook o Twitter.

Figura 3.4: Netflix y SSO con Facebook

Connect Code
En dispositivos donde la introducción de caracteres es lenta, introducir el usuario y
contraseña puede ser tedioso o incluso poco recomendable por motivos de privacidad, ya
que los dispositivos de gran pantalla suelen estar ubicados en espacios comunes dentro de
las viviendas, siendo muy fácil el exponer datos privados ante miradas indiscretas. Una
solución a estos problemas es permitir asociar dicho dispositivo a una cuenta ya existente
mediante un código único que se muestra en la pantalla del mismo.

24
 Figura 3.5: Teclado en pantalla.
Figura 3.6: Código de conexión.

En las figuras anteriores podemos ver el modelo tradicional y el modelo basado en código
de conexión instándonos a ir a una URL para autenticarnos con nuestras credenciales he
introducir el código mostrado en pantalla.

Este mecanismo se puede implementar en la solución del OVP o utilizar un servicio SSO
de terceros, como login for devices de Facebook, que hemos podido ver en la figura 3.4.

TV Everywhere
TV Everywhere hace referencia a la posibilidad de ver nuestros canales lineales allá
donde estemos, gracias a múltiples servicios OTT.

Este modelo de autenticación permite que usuarios que ya están pagando por una
subscripción a un canal lineal puedan acceder al contenido OTT del mismo a través de
aplicaciones que tengan implementado esta forma de autenticación. De esta forma con las
credenciales de un operador de cable, el usuario puede acceder al contenido online de los
distintos canales que engloba dicho operador. Las aplicaciones que usan este mecanismo de
autorización normalmente permiten seleccionar distintos operadores, dando la opción de
usar múltiples mecanismos para identificar a un usuario, desde un código postal junto con
un número de teléfono a los más clásicos usuario y contraseña.

A nivel de infraestructura los servidores de autenticación deberán de comprobar contra

el suscriptor original si el usuario tiene derechos para acceder al contenido de forma
periódica, para poder ofrecer o restringir el acceso en función del estado de su suscripción
original. Esto añade más complejidad y la necesidad de servidores que realicen las
comprobaciones de forma periódica o APIs que permitan recibir notificaciones con los
cambios de estado de las suscripciones.

25
3.1.1.3 Gestión de datos de usuario
Dado que la mayoría de las aplicaciones VOD pueden ser accedidas con una misma
cuenta desde múltiples dispositivos, no es raro encontrar que se puedan almacenar datos
de usuario de forma remota para que se compartan entre los mismos.

Los datos que se suelen almacenar en estas soluciones suelen ser aquellos que no están
soportados por otros servicios, como preferencias específicas de la aplicación, listas de
favoritos, etc.

3.1.2 Gestión de contenido

Los gestores de contenido (Content Management System, CMS por sus siglas en inglés)
son los responsables de permitir la creación, edición, revisión, y acceso del contenido con el
que se construyen las aplicaciones finales.

En los CMS habituales (Wordpress, Drupal) la información introducida siempre es

accesible mediante el acceso a páginas web, de forma que podemos decir que está ligada a
la representación web de dichas plataformas.

Cuando hablamos de CMS dentro de aplicaciones OTT, este contenido debe de poder
accederse desde cualquier aplicación cliente independientemente de la tecnología que se use
para representar los datos.

Así nace la necesidad de crear headless CMS, es decir, gestores en los que la estructura
de los datos y la representación de los mismos no está predefinida ni ligada a un formato
de representación. Como ejemplos comerciales encontramos los servicios Contentfull,
Prismic y AppGrid.

Con un CMS headless los datos son configurables, permitiendo la definición de nuevos
modelos de objetos con lo que poder crear entradas.

Los datos se recuperarán de forma agnóstica a los dispositivos en JSON (JavaScript

Object Notation en inglés) o XML (Extensible Markup Language en inglés) entre otros.

En la siguiente figura podemos ver los servicios asociados a la gestión de contenido:

Content Management

Search VCMS ECMS

Figura 3.7: Gestores de contenido

26
 Habitualmente nos encontramos con sistemas de gestión de metadatos de vídeo y de
contenido editorial

3.1.2.1 Gestión de contenido editorial

En el mundo del OTT los CMS son usados también para gestionar el contenido editorial
de las distintas aplicaciones, siendo muy parecido a lo que nos pueden ofrecer plataformas
como WordPress o Drupal, pero ciñéndose a los modelos de datos anteriormente descritos.

3.1.2.2 Gestión de contenido de vídeo

Los gestores de contenido de vídeo (Vídeo Content Management System, VCMS por sus
siglas en inglés) se encargan de crear entradas de datos que relacionan los distintos streams
de vídeo con todos los metadatos que conciernen al mismo.

Suelen estar relacionados con las plataformas de gestión de vídeo encargadas de procesar
las fuentes originales, así como con otros proveedores de contenido que se ocupan de tener
los metadatos actualizados.

Los metadatos más habituales son los siguientes:

{
"type": "list",
"name": "Ejemplo Memoria",
"data": [{
"title": "",
"description": "",
"releaseDate": 1500502452,
"humanReleaseDate": "",
"direction": [
"Director #0"
],
"actors": [
"Actor #0",
"Actric #1"
],
"type": "film",
"vídeo": {
"url": "",
"duration": 3600,
"startOver": 1200
}
}, {
"same" : "here"
}]
}
Figura 3.8: Modelo datos VCMS

27
3.1.3 Infraestructura de vídeo
En este bloque incluyo todos los servicios relacionados con el procesado que se realiza a
los contenidos originales ya sean bajo descarga o en directo para poder ser distribuidos por
internet a los dispositivos requeridos.

Los servicios que nos encontraremos son de codificación, grabación en la nube y

encriptación, como podemos ver en la siguiente figura:

Video Infrastructure

Video
PVR Encryption
Encoder

Figura 3.9: Infraestructura de vídeo

3.1.3.1 Procesado de vídeo

Como reflejaré más adelante, los vídeos proceden de distintos orígenes, que pueden ser
fuentes live o archivos maestros alojados en internet.

Los servicios de codificación de vídeo (vídeo encoders en inglés) procesan estos orígenes
para adaptarlos a las necesidades de los clientes, ya sea por cuestiones de negocio o por
especificaciones técnicas.

3.1.3.2 Encriptación
El servicio de encriptación es necesario para añadir seguridad a la transmisión de los
datos, codificándolos mediante el estándar AES usando una clave compartida que se
obtiene de los servidores de licencia relacionados con el DRM.

3.1.3.3 Grabaciones personales de vídeo

En IPTV y OTA es muy habitual encontrarse con la capacidad de grabar el contenido
mediante lo que se conoce como grabaciones personales (Private Vídeo Recording, PvR por
sus siglas en inglés) usando el almacenamiento disponible por el dispositivo que corre la
aplicación.

Estos servicios permiten al usuario grabar el contenido que se está emitiendo por
streaming en tiempo real, o programar la grabación de distintos programas. Estas
programaciones pueden ser configuradas mediante filtros personalizados, dando la
posibilidad, por ejemplo, de grabar todos los episodios de una serie o los documentales
sobre un tema elegido.

28
 De igual modo, las grabaciones personales en la nube (Network Private Vídeo Recording,
nPvR por sus siglas en inglés) nos permiten disponer de esta capacidad eliminando la
necesidad de tener almacenamiento físico para la grabación, extendiendo virtualmente esta
funcionalidad a todos los dispositivos siempre que tengan acceso a internet.

A nivel de arquitectura existen varias opciones a la hora de implementar estas soluciones.

Una de las formas se basa en reservar espacio de disco en la nube, creando copias digitales
independientes del contenido en ese espacio de usuario. Esta aproximación es cara y tiene
muchas limitaciones para los usuarios finales, ya que el espacio suele ser muy limitado, no
permitiendo grabar programas largos o gran cantidad de los mismos.

Para evitar este problema hay soluciones que almacenan una única copia de la
distribución en directo como si fuera un vídeo VOD común para todos los clientes, de forma
que por cada grabación de usuario lo único que se guarda en la nube es una URL apuntando
a un stream con un marcado de tiempo de inicio y de final sobre dicha copia. De esta forma
solamente se generan estos índices por cada grabación, reduciendo el almacenamiento total
requerido para ofrecer dicho servicio, lo que conlleva una disminución sustancial al no
necesitar almacenar una gran cantidad de datos en los servidores.

3.1.4 Gestión de derechos digitales

La gestión de derechos en los entornos OTT engloba a múltiples servicios encargados de
proporcionar una capa de seguridad que intenta evitar usos fraudulentos del contenido.

Dichas medidas se aplican sobre varios actores de la arquitectura OTT, como puede ser
la transmisión de los datos, protocolos de verificación del usuario que comprueban si está
autorizado para acceder a un contenido dado, restricciones por localización y finalmente
estrategias disuasorias como los marcados de los streams identificando al cliente.

En la siguiente figura podemos ver todos los servicios que se aplican para implementar
medidas de seguridad en las aplicaciones:

Rights Management

Concurrence Entitlement Geoblocking

License
Tokens Signing
Server

Figura 3.10: Gestión de derechos digitales

29
3.1.4.1 Control de concurrencia
La concurrencia en el contexto de vídeo OTT se refiere al número máximo de dispositivos
que pueden reproducir contenido al mismo tiempo usando una misma cuenta.

De forma adicional se pueden limitar la cantidad de dispositivos concurrentes asociados

a una cuenta dada, de forma que, si el usuario final quiere añadir más, deba de eliminar
previamente algunos de los registrados.

En las condiciones de las subscripciones se indica siempre el número máximo de

dispositivos que se pueden vincular a una cuenta, así como de cuántos de éstos pueden
reproducir contenido de forma simultánea.

3.1.4.2 Autorización de acceso

La autorización de acceso a contenidos (o entitlement en inglés) debe de permitir
discriminar qué usuarios pueden visualizar un contenido o no, ya sea porque están
autorizados en la plataforma, porque tienen un modelo de suscripción que permite la
reproducción o porque tienen licencias válidas para el mismo.

Este servicio está íntimamente relacionado con el modelo de negocio y otros bloques
funcionales del OVP, por ejemplo, las pasarelas de pago, que deberán de notificar a los
servidores de acceso a contenido si un usuario ha realizado una transacción correcta o si
una subscripción se ha caducado.

Idealmente un usuario que no tiene autorización para acceder a un contenido no debería

de ser capaz de recuperar los metadatos relacionados con el mismo, como puede ser la URL
o los necesarios para obtener una licencia de reproducción en el caso de que esté
implementada cualquier medida DRM.

3.1.4.3 Geo bloqueo

Las compañías que ofrecen los servicios de vídeo online gestionan los derechos del
contenido para países o regiones específicos, de forma que no pueden ofrecer el mismo fuera
de la zona establecida.

Para evitar que el contenido sea accedido desde regiones no permitidas se realizan
múltiples comprobaciones en toda la infraestructura del OVP, desde las DNS a los
servidores CDN involucrados.

Existen múltiples estrategias para intentar evitar esto, como pueden ser DNS
modificadas o el uso de redes privadas virtuales (Virtual Private Network, VPN por sus
siglas en inglés), pero recientemente han surgido contramedidas que permiten detectar estos
comportamientos y bloquear la reproducción de contenido.

30
 Recientemente se ha aprobado en Europa el roaming de subscripciones OTT (Digital
TV News , 2017), de forma que al menos dentro de la Comunidad Económica Europea los
usuarios de servicios OTT deberían de ser capaces de acceder a su contenido sin necesidad
de usar una VPN u otras medidas.

3.1.4.4 Tokens
Uno de los problemas que nos encontramos al transmitir todo el tráfico sobre el protocolo
HTTP es que existen múltiples herramientas de análisis que nos permiten capturarlo y
obtener las URLs a las que se realizan peticiones para acceder al contenido.

Para evitar que estas URLs se publiquen en internet se crean enlaces únicos mediante
el uso de tokens.

Usualmente estos tokens tienen una ventana de validez reducida, de forma que por
mucho que la gente obtenga los enlaces, no pueda acceder al contenido.

3.1.4.5 Servidores de licencia

La gestión de derechos se encarga de comprobar si un usuario y su dispositivo actual
están autorizados a reproducir el contenido que reclaman.

Los servidores DRM son una de las piezas más delicadas dentro del mundo OTT, ya
que son los guardianes de la integridad del contenido. Si uno de estos servidores es
vulnerable se podría romper la cadena de seguridad y el contenido protegido por el mismo
quedaría expuesto. Esto hace que la información existente sobre los DRM y las
implementaciones de los servidores no pase de parámetros de configuración.

En la siguiente figura podemos ver un flujo completo de DRM que sigue los siguientes
pasos:

1. . La aplicación cliente obtiene todos los datos necesarios del VCMS para poder
verificar contra el servidor de licencias que está autorizado a reproducir un
contenido.

2. El cliente obtiene de la CDN el stream de vídeo y sus datos asociados.

3. A continuación, pedimos al servidor de licencias una licencia valida enviando los

datos obtenidos en el VCMS.

4. El servidor de licencias verifica contra el VCMS y otros actores si estamos

autorizados.

5. En el caso de estarlo nos devuelve una licencia valida.

6. El cliente puede reproducir el contenido al poder obtener la clave AES necesaria.

31
 License
Client CDN Server
VCMS Entitlement

getContent (userId, contentId)

isEntitled (userId, contentId)

entitlement
content (entitlement, challenge, urls, metadata)

Opt
getStream ()

streamUrl

getLicense (streamUrl, challenge, userId)

checkChallenge (streamUrl, challenge, userId)

challengeState
license

Opt

getAESFromLicense ()

loop

getChunks

Figura 3.11: Ejemplo DRM

3.1.4.6 Firmado de contenido

Con el objetivo de añadir una capa más de seguridad el contenido puede ser firmado, de
forma que se pueda identificar de forma inequívoca al usuario o plataforma que ha
permitido el fraude.

En el caso de que aparezca una brecha de seguridad que permita romper todas las
medidas de protección anteriormente mencionadas, las compañías podrán investigar en qué
punto se ha roto la cadena de confianza, para abrir diligencias contra los usos fraudulentos.

Alguna de las estrategias de firma de contenido con la que nos encontramos son:

• Marcas de agua superpuestas a los streams de vídeo desde el origen.

• Marcas de agua superpuestas en aplicación especificas por usuario y

dispositivo

• Firmas estenográficas de audio y vídeo

A diferencia de las marcas de agua, apreciables por los usuarios finales, las firmas
estenográficas son mucho más complejas y están diseñadas para que pasen desapercibidas.

32
 La recuperación de la información de estas firmas necesita el análisis del stream durante
un tiempo mínimo que variará dependiendo de la complejidad de la técnica. Normalmente
los distintos fabricantes incluyen corrección de errores, de forma que se puede recuperar la
firma incluso en condiciones de grabación poco favorables, como por ejemplo codificación
del contenido o incluso retransmisión mediante una captura en tiempo real mediante un
dispositivo destinado a tal objetivo (como una cámara de vídeo).

A nivel de análisis de contenido con un fin puramente comercial existen empresas como
Shazam que usan firmas de audio, mientras que Verimatrix se ha especializado en el
firmado de vídeo, de forma que se disuada a los infractores de un uso fraudulento, ya que
con la información añadida se puede identificar la fuente de la filtración y tomar las
pertinentes acciones legales.

3.1.5 Analíticas
Actualmente la estrategia es la de capturar el mayor número de eventos que ocurren
dentro de las aplicaciones de los clientes finales, enviándolas a uno o varios servidores. De
esta forma se pueden definir múltiples reglas para buscar los indicadores claves de
rendimiento (Key Performance Indicator, KPI por sus siglas en inglés) más significativos,
incluso una vez que ya se han recibido los datos.

En el mundo de la distribución de vídeo los KPI más importantes son los relacionados
con la calidad en la transmisión del vídeo, los índices de audiencia por contenido, la
valoración de los usuarios para un contenido y finalmente el uso general de la aplicación.
Analytics Management

Network
Performance Usage
Quality
Metrics Metrics
Metrics

IA
Ratings
Engines

Figura 3.12: Gestión de Analíticas

3.1.5.1 Métricas de rendimiento

Las métricas de rendimiento de las aplicaciones son las encargadas de tomar medidas
sobre el comportamiento de la aplicación a lo largo de su vida, marcando cuando se generan
nuevas versiones de la misma para comparar el rendimiento y hacer informes con su
evolución.

New Relic y Datadog son empresas que ofrecen SDK para múltiples plataformas,
permitiendo su rápida integración en cualquier dispositivo.

33
3.1.5.2 Métricas de calidad de red
En las métricas de calidad de red se engloban todos los eventos relacionados con los
streams de vídeo, de forma que se pueda detectar el ancho de banda disponible para el
usuario, que CDNs son las que mejor funcionan, si han existido problemas puntuales o
generalizados de red que repercutan en la experiencia de uso, etc. Conviva, Nice People at
Work, Edgeware realizan estos análisis de calidad de red.

3.1.5.3 Métricas de uso

Dentro de esta categoría de estadísticas se encuentran datos como el tiempo que pasa
un usuario en la aplicación, el que invierte en buscar un contenido antes de iniciar una
reproducción o cerrar la aplicación, el tiempo de reproducción de vídeo, contenidos
favoritos, etc.

A partir de todos los eventos capturados podemos definir los distintos KPIs que servirán
para realizar análisis en profundidad que ayuden a comprender el comportamiento de los
clientes, intentando prever a partir de los mismos si van a seguir utilizando el servicio o
por el contrario van a abandonarlo en el futuro inmediato. Esta situación recibe el nombre
en la industria de churn.

Existen multitud de soluciones de analíticas sobre las que se pueden definir dichos KPIs,
siendo las más conocidas Adobe Omniture y Google Analytics.

3.1.5.4 Puntuaciones de contenido

Los servicios de puntuación o reseñas han tomado un gran protagonismo en el mundo
del OTT. Cada vez más gente acude a páginas como IMDB, Rotten Tomatoes o Metacritic
para ver que opinan otros usuarios de sus series y películas favoritas, así como para dejar
su opinión.

Gracias a su creciente base de usuarios, estos servicios están empezando a analizar todos
los datos para poder ofrecer contenido relacionado afín a los gustos del cliente.

Igualmente ofrecen servicios que pueden ser consumidos desde las aplicaciones de
terceros para poder mostrar las puntuaciones en las mismas.

3.1.5.5 Motores de Inteligencia Artificial

Al disponer de una gran variedad de datos analíticos y estadísticos, se está empezando
a desarrollar un nuevo negocio orientado a la predicción de abandono de usuarios.

Estos motores tienen una gran relevancia, ya que intentan no solo predecir estos
abandonos, sino qué medidas hay que tomar desde una perspectiva de negocio para retener
el máximo tiempo posible a los usuarios, ofreciendo una experiencia más interesante para
ellos.

34
3.1.6 Monetización
Cuando hablamos de aplicaciones de distribución de vídeo encontramos distintos
modelos de monetización, como apuntamos en el punto 2.3.

Esta monetización la podemos dividir entre los ingresos por publicidad o las actividades
transnacionales, entre los usuarios finales y la plataforma de distribución de vídeo tal y
como podemos observar en la siguiente figura:

Monetization

Payment Ad
Gateway Servers

Figura 3.13: Monetización

3.1.6.1 Pasarelas de pago

En las aplicaciones que requieren pagos para obtener una subscripción o la compra/renta
de un contenido habitualmente hacen uso de una pasarela de pago.

Este servicio permite configurar las distintas ofertas disponibles, de forma que cuando
una aplicación cliente quiera realizar la transacción solo tenga que enviar un identificador,
de esta manera el servicio puede realizar el cobro por el importe adecuado y notificar a las
distintas partes que ha sido ejecutado de forma correcta. Finalmente, el usuario podrá
acceder al producto.

Los métodos de pago más habituales son los siguientes:

• Tarjetas de crédito o débito

• Paypal u otras plataformas independientes.

• Códigos o cupones

• Cargo a operadores de telefonía móvil

• Cargo a cuenta de telefonía fija

3.1.6.2 Ad Servers
Para contenido AVOD son necesarios servidores que gestionen la publicidad, encargados
de todo el proceso de subasta de la misma, así como de la recepción y captura de los eventos
y de reproducción de la publicidad para validarla.

35
 El Interactive Advertising Bureau (IAB por sus siglas en inglés) se ha encargado de
crear unas guías abiertas que especifican el protocolo de comunicación entre los clientes y
servidores, definiendo el formato de los ficheros, las características y capacidades de los
mismos, así como los mecanismos para hacer seguimiento de las visualizaciones con el fin
de poder obtener analíticas de uso y porcentajes de conversión.

Las especificaciones actuales son VAST (de Vídeo Ad Serving Template en inglés),
VPAID (de Vídeo Player-Ad Definition en inglés) y VMAP (de Vídeo Multiple Ad Playlist
en inglés). Las versiones actuales de estas especificaciones y su alcance se definen en los
siguientes documentos:

• VAST 4.0 - Especifica el esquema XML con la información necesaria para

mostrar vídeos de publicidad

• VPAID 2.0 - Extiende VAST añadiendo la posibilidad de añadir anuncios

interactivos

• VMAP 1.0.1 - Extiende VAST creando listas de anuncios que deben de ser
procesaras por las aplicaciones cliente.

3.2 RED
Las aplicaciones clientes en el mundo OTT no son más que meros esqueletos que poco
pueden hacer sin una conexión a internet al depender casi totalmente de los datos que
obtienen de los distintos servicios anteriormente descritos.

Toda la infraestructura de red se sustenta sobre el protocolo HTTP y servidores

dedicados al acceso y manipulación de los datos.

En los siguientes puntos vamos a profundizar sobre esto, analizaremos el acceso a los
datos y que infraestructura de red nos vamos a encontrar de forma habitual.

3.2.1 Web APIs

Una condición necesaria para que se considere a una aplicación OTT es que esta esté
construida sobre servicios en internet.

Como hemos visto en el análisis de los OVP, las aplicaciones necesitan una gran cantidad
de datos que son ofrecidos por los múltiples servicios que exponen estas plataformas. Sin
estos datos normalmente las aplicaciones no disponen de toda la información que requieren
para su correcto funcionamiento, impidiendo su uso.

La forma más habitual de acceder a dichas entidades remotas es mediante el protocolo

HTTP, de forma que los clientes realicen peticiones a los distintos servidores mediante
interfaces web que exponen mecanismos para manipular estos datos (Web Application
Programming Interface, Web API por sus siglas en inglés).

36
 Existen gran variedad de estándares Web APIs como RPC, SOAP o WSDL, pero la
más común hoy en día es Restful (Representational State Transfer).

Restful

Restful está pensado para funcionar sobre el protocolo HTTP, exponiendo los datos y
las operaciones mediante URLs HTTP, conocidas como endpoints.

Dichos endpoints son manipulados mediante acciones CRUD (Create, Read, Update and
Delete) que tienen una relación uno a uno con distintos verbos del protocolo HTTP.

En la siguiente tabla podemos ver la acción CRUD, el verbo HTTP y la acción que
realiza:

Accion CRUD Verbo HTTP Descripcion URL Ejemplo

CREATE POST Crea un nuevo /user/
contenido
READ GET Lee un contenido /user/:id
UPDATE PUT Actualiza un /user/:id
contenido
DELETE DELETE Borra un contenido /user/:id
Figura 3.14: Acciones Restful y verbos HTTP

Además, Restful especifica que no se debe de guardar el estado en el servidor, de forma

que las peticiones deben de ser independientes las unas de las otras y las acciones atómicas.

Esto permite que las implementaciones en los servidores sean más sencillas, y al no
existir dependencias entre peticiones se puedan escalar los servicios de una forma más
directa, no teniendo que compartir datos entre servidores.

Definición de APIs

Dado que es tan importante disponer de APIs claros y accesibles, existen multitud de
herramientas que facilitan la definición y las pruebas de los endpoints.

Es muy habitual que las empresas faciliten aplicaciones de prueba que exponen los
métodos, de forma que cualquier desarrollador sea capaz de realizar los test necesarios para
obtener los datos, verificando que los flujos de trabajo son los correctos.

Las herramientas de definición de APIs más habituales son Apiary y Swagger, que
permiten documentar y exponer los endpoints y sus parámetros al mismo tiempo, siendo
de gran utilidad.

37
3.2.2 Redes de distribución de contenido
Las redes de distribución de contenido (Content Distribution Network, CDN por sus
siglas en inglés) se encargan de acercar el contenido a los usuarios finales, convirtiéndose
en una pieza fundamental del mundo OTT.

Las CDNs no son más que un conjunto de servidores que funcionan a modo de cache
entre el origen de los datos y los usuarios finales, a los que acceden los clientes según a
distintas reglas que determinan los DNS (Domain Name System) o los balanceados de red.

En la siguiente figura podemos observar como las aplicaciones finales acceden a sus
nodos más próximos y como la CDN se relaciona con un origen de datos:

Figura 3.15: Red CDN

Los datos accesibles en los distintos nodos de la red CDN lo son bajo demanda, de forma
que la primera vez que se accede a un contenido en dichos nodos, los tiempos de respuesta
pueden ser parecidos a los que nos encontraríamos en un escenario sin CDN.

Estas redes de servidores tienen a su disposición conexiones de red propias que les
proveen de unos anchos de banda muy elevados. Esto es necesario, ya que cuando un cliente
final accede a un fichero que no está disponible en uno de los servidores extremo, los datos
tienen que viajar por su red privada a la mayor velocidad posible para servir el fichero en
el menor tiempo posible.

Es importante que los servidores se encuentren geográficamente próximos a los

dispositivos cliente, ya que de esta forma se reducirán los saltos de red necesarios para
obtener los datos, bajando los tiempos de respuesta y aumentando el ancho de banda
disponible.

38
 Los clientes accederán a los distintos nodos de forma automática gracias a la propia
infraestructura de la red CDN, que gracias a los DNS puede determinar que nodos son los
que tienen menor tiempo de respuesta para dirigir el tráfico a los mismos.

La cache de estos nodos debe de poder configurarse con un tiempo de vida, y al mismo
tiempo ofrecer mecanismos para poder invalidar la misma. Esto es de vital importancia, ya
que se puede dar el caso de que la CDN haya cacheado contenido inapropiado y es necesario
eliminarlo para que los usuarios puedan pedir el contenido correcto.

En resumen, las redes CDN son imprescindibles al reducir el ancho de banda entre el
origen y los clientes finales, entregando los datos de una forma más eficiente y a mayor
velocidad, mejorando la experiencia de uso.

3.3 Aplicaciones cliente

Como hemos visto, toda la infraestructura del ecosistema OTT está montada en base a
una gran variedad de servicios que controlan la lógica de negocio de cara las aplicaciones
cliente. De esta forma las aplicaciones solo deben implementar una mínima lógica que
permite procesar los datos y representarlos de una forma atractiva frente al usuario final.
Esto ayuda a reducir el tiempo de desarrollo de las aplicaciones. A pesar de esto, tener
presencia en todos los dispositivos supone un gran esfuerzo, debido a la amplia variedad de
los mismos.

Primero vamos a revisar cual es la anatomía de las aplicaciones que corren en los
distintos dispositivos para poder enfrentarnos al desarrollo con una idea clara de que es lo
que se espera cuando abrimos una aplicación de vídeo bajo demanda.

Esta gran diversidad de dispositivos hace que debamos entender las características y
limitaciones que los definen y buscar soluciones a los múltiples problemas que nos vamos
encontrar cuando planteemos el diseño de las aplicaciones.

Según profundicemos en las capacidades, las diferencias entre los distintos dispositivos
dejarán salir a flote la fragmentación de la que he hablado.

En los siguientes puntos repasaremos las plataformas mayoritarias desde las que se
consume vídeo, las nuevas plataformas emergentes, los distintos tipos de fragmentación y
las conclusiones.

39
3.3.1 Anatomía de las aplicaciones
A lo largo de este proyecto fin de carrera he mencionado en varias ocasiones aplicaciones
que han marcado un antes y un después en la forma de entender la distribución de vídeo
a través de internet, como son YouTube y Netflix.

En su gran mayoría todas las aplicaciones de vídeo en streaming imitan a estas

plataformas, personalizando la experiencia de usuario, así como el interfaz, y añadiendo
secciones que no tienen cabida en las anteriores.

A grandes rasgos podemos generalizar que estas aplicaciones están compuestas por unas
pantallas y elementos gráficos fijos, que podemos resumir en:

Pantalla de inicio

Esta pantalla se caracteriza por mostrar un logo estático de la marca, o bien una imagen
grande con algún botón que nos inste a realizar la acción de entrar en la aplicación con
nuestro usuario y contraseña.

Figura 3.16: Pantalla de inicio de Netflix

40
 Pantalla de login/selección de perfil

En las aplicaciones que requieren de usuario y contraseña, esta pantalla nos permite
introducirlos, he incluso seleccionar entre varios perfiles posibles para disfrutar de una
experiencia más personalizada.

Figura 3.17: Pantalla de login de HULU

Pantalla principal

La pantalla principal suele constar de un menú que nos da accedo a las distintas
secciones de contenido y de configuración, así como directamente contenido destacado y
varias listas con distintos contenidos.

Figura 3.18: Pantalla principal de HBO

41
 Pantalla de detalle

Una vez que hemos seleccionado un contenido, la pantalla de detalle nos da información
extra sobre el mismo, como pueden ser las puntuaciones recibidas en distintas páginas web,
información sobre los directores y/o actores, duración de la película y opciones de renta o
compra del contenido.
Figura 3.19: Pantalla de detalle de Amazon Prime

Pantalla de programación

Las guías de programación digitales (Electronic Program Guide o EPG por sus siglas en
ingles) son muy comunes gracias al Teletexto y la TDT.

Las aplicaciones que emiten canales en directo suelen contar con este tipo de pantallas,
en las que se nos muestra el tiempo actual y la ventana de emisión de los programas. ROVI
tiene la patente sobre estas pantallas en EEUU.

Figura 3.20: EPG

42
 Reproductor de vídeo

Las aplicaciones de vídeo se caracterizan por el reproductor. Anque han ido

evolucionando con el tiempo y cada vez muestran mas informacion al usuario,
habitualmente se componen de botones que nos permiten manipular la repruduccion en si
misma (pausa, reaundar reproduccion, salto de capitulo/en el tiempo), indicadores
numericos y visuales de la posicion donde nos encontramos y la duraccion total del
contenido, asi como botones extra para habilitar/deshabilitar los subtitulos, el modo a
pantalla completa, etc.

Figura 3.21: Reproductor de vídeo de YouTube

Basándonos en las pantallas que hemos analizado podemos resumir los elementos más
comunes en: Lista de elementos e ítems:

Lista de elementos

La forma en la que el usuario interactúa con las distintas aplicaciones es a través de

listas de ítems que nos permiten seleccionar el contenido.

Estas listas pueden ser muy distintas entre sí, por ejemplo, con imágenes grandes para
el contenido destacado, o con caratulas pequeñas cuando mostramos vídeos de una sección
dentro de una pantalla.

Por regla general las listas son horizontales y permiten hacer scroll horizontal, aunque
nos encontramos variaciones con listas de dos dimensiones con las que hacemos scroll
vertical.

En las pantallas anteriores podemos ver ejemplos de distintos tipos de listas.

43
 Ítems

Las listas de elementos anteriormente descriptas están compuestas de ítems, que suelen
ser las caratulas de los distintos vídeos que están a disposición del usuario. Estos ítems
pueden incluir información adicional, como puede ser el título del vídeo, iconos para resaltar
los idiomas de audio/subtítulos, la calidad del vídeo, etc.

3.3.2 Dispositivos
En este punto vamos a analizar los grandes grupos de dispositivos para los que se
desarrollan aplicaciones de distribución de vídeo bajo demanda.

En la siguiente figura podemos ver el porcentaje de dispositivos que los usuarios adultos
poseen en EE. UU.:

Figura 3.22: Devices Owned (IAB + Maru/Matchbox, 2017)

La conclusión que podemos sacar de esta figura es que existe una base de equipos sin
conectividad a internet, como son las televisiones tradicionales. Además, vemos como
dispositivos accesorios para estas televisiones y dispositivos móviles tienen una presencia
más que notable. Observamos un gran crecimiento, durante los dos últimos años, de
dispositivos multimedia y conectados, así como de los móviles, los Smart TV junto con
otros dispositivos de streaming, estando estos últimos plenamente orientados al consumo
de contenido online.

44
 En esta otra figura podemos ver el porcentaje de clientes que hace uso de alguno de los
grandes grupos de dispositivos de forma diaria para visualizar contenido de vídeo:

Figura 3.23: Devices Used to Stream Digital Video (IAB + Maru/Matchbox, 2017)

Gracias a estas gráficas podemos saber que existe una gran variedad de dispositivos
disponibles en el mercado y que la base existente en los hogares de los mismos se renueva
cada cierto tiempo, pero no es un proceso inmediato. Esto resulta en una fragmentación de
las capacidades y de las características de dichos dispositivos.

En el siguiente punto analizaremos en profundidad los distintos escenarios en los que la

fragmentación aparece.

A continuación, vamos a profundizar sobre cada grupo de dispositivos.

Ordenadores personales

La base existente de ordenadores personales sigue siendo la mayor si la comparamos con

la del resto de dispositivos que pueden ser usados para visualizar vídeo online.

Esto hace que, aunque poco a poco esté perdiendo presencia en los hogares, siga siendo
un medio mayoritario muy a tener en cuenta a la hora de crear aplicaciones.

El auge de las aplicaciones web y de los nuevos estándares permite que el ecosistema de
aplicaciones disfrute de una buena salud.

En este contexto es importante puntualizar que casi todas las aplicaciones de VOD para
PC son aplicaciones web, o al menos están basadas en esta tecnología, por ejemplo, las

45
basadas en las herramientas proporcionadas por Windows Universal Platform o las creadas
mediante navegadores en modo headless como Electron.

La fragmentación en PC viene por la diversidad de potencia existente entre los

dispositivos y las versiones de los navegadores, que puede ocasionar que en las versiones no
actualizadas existan contenidos que no se puedan visualizar por no ser capaz de gestionar
los derechos de usuario o de soportar los codecs de los streams.

Móviles y tabletas

Los móviles y tabletas se encuentran en el segundo puesto de los dispositivos que pueden
consumir directamente contenido de internet.

La evolución de estos dispositivos y su naturaleza inalámbrica orientada a la

conectividad ha propiciado que las aplicaciones de vídeo bajo demanda tengan un gran
arraigo, siendo la plataforma en la que más vídeo se consume.

Los usuarios de contenido en streaming en estas plataformas las prefieren para ver vídeos
de mediana o corta duración (IAB + Maru/Matchbox, 2017).

Las plataformas dominantes de este segmento del mercado son Android, con gran
variedad de dispositivos móviles y tabletas e iOS con la familia iPhone e iPad por bandera.

La fragmentación existente viene dada por la gran diversidad de hardware que hay en
el mercado, así como por las diferentes versiones de los sistemas operativos, incluso cuando
hablamos de una plataforma en concreto.

Dispositivos Conectados

Entendemos por dispositivos conectados a cualquiera cuya principal función es la de

poder consumir contenido desde internet, pudiendo diferenciar entre los siguientes
subconjuntos: Set Top Boxes, Smart TV y Dispositivos de streaming.

• Set Top Box

Los dispositivos Set Top Box (STB por sus siglas en inglés) son accesorios que se
conectan a las televisiones, conocidos por este nombre ya que históricamente se situaban
encima de los mismos, cuando estos no eran planos. Los primeros dispositivos de uso
generalizado relacionado con el consumo de vídeo fueron los reproductores de cintas vídeo
y posteriormente decodificadores de televisión digital por antena terrestre, satélite o cable.

Con el tiempo todos estos aparatos han dejado paso a nuevas cajas ofrecidas por las
compañías de telefonía, así como por proveedores de contenido, para que los usuarios

46
puedan acceder al contenido usando internet, primero en redes privadas para garantizar la
calidad del servicio (Quality of Service, QoS por sus siglas en inglés) bajo IPTV y
posteriormente, al abrir su contenido a todo el mundo, a los servicios OTT.

A nivel de hardware, el mundo de los STB es muy diverso, ya que existen múltiples
fabricantes (Sagemcom, Broadcom, Apple, Google, Amazon, Huawei; siendo ejemplos de
empresas europeas, americanas y chinas) usando arquitecturas completamente distintas
que sirven como motor de las aplicaciones OTT.

Dentro de las distintas soluciones de STB OTT podemos encontrar Android TV, basado
en el mismo sistema operativo que los móviles; Apple con su tvOS para la familia de
dispositivos Apple TV, y Amazon TV que está basado en Android, pero eliminando las
dependencias existentes con los servicios de Google.

A todas ellas se suma un grupo más heterogéneo de fabricantes que aportan soluciones
basadas en el SO Linux junto con navegadores web en modo headless. Estos fabricantes
han extendido el estándar del W3C para poder dar acceso a todas las capacidades del
hardware a los desarrolladores desde el navegador, de forma que las aplicaciones que corran
sobre el mismo puedan usar los distintos DRM implementados, entre otros extras.

• Smart TV

Las Smart TV son la evolución de las televisiones tradicionales, a las que los fabricantes
les han añadido, a modo de factor diferenciador, capacidades de ejecutar aplicaciones
directamente sin la necesidad de comprar otros dispositivos extra. De esta forma son más
atractivas para el usuario final, ya que no tienen la necesidad de comprar otro dispositivo
(STB) para poder disfrutar del contenido en línea.

Existen multitud de plataformas como Samsung Tizen y LG WebOS, que ofrecen las
mismas capacidades, pero de una forma no estándar, dificultando la creación de
aplicaciones compatibles con múltiples dispositivos.

• Dispositivos de streaming

En esta categoría englobamos a una nueva familia de dispositivos. Tienen cierta similitud
con los STB OTT, ya que son usados para ver contenido OTT, pero a diferencia de estos,
suelen ser muy pequeños, se conectan directamente a un puerto HDMI de la televisión y el
usuario no interactúa con ellos, ya que solo reciben los streams a reproducir.

De esta forma los dispositivos se comportan como clientes accesorios a las aplicaciones
móviles, de tableta o PC, y es a través de las aplicaciones desde donde el usuario elije y
envía el contenido.

47
 Existen varias plataformas que incluyen esta funcionalidad, como Google Chromecast,
Amazon Fire TV Stick y Roku Stick, siendo incompatibles entre sí.

Dispositivos VR

Este es el grupo más reciente, ya se ha desarrollado a partir del nuevo boom de la

realidad virtual (VR por sus siglas en inglés). Esta tecnología está creciendo bajo un fuerte
hype, ( The Economist, 2017), pero aun así no deja de tener previsiones de crecimiento
cercanas al 100% para este 2017 si tenemos en cuenta la venta de todos los dispositivos.

En el mercado existen distintos modelos de gafas de realidad virtual, que pasaremos a

describir a continuación:

• Cardboards

Se conocen como dispositivos VR Cardboards a todos los accesorios para los móviles que
soportan la tecnología VR mediante la introducción de un móvil en la carcasa, permitiendo
usar este conjunto como un casco VR. Google popularizó el sistema regalando una caja
plegable de cartón, de ahí el nombre.

Figura 3.24: Cardboard VR de Google

Dado que los dispositivos que corren las aplicaciones son móviles, la potencia es limitada,
pero suficiente para tener una experiencia de VR respecto a contenidos de vídeo.

• Tethered Headsets

Los dispositivos tethered son accesorios de PCs (usualmente de gama alta). Están
pensados sobre todo para VR de juegos o diseño profesional. Al igual que en el anterior
caso, estos dispositivos no tienen problema a la hora de ejecutar aplicaciones VR de vídeo.

48
 Los fabricantes de estos dispositivos han creado plataformas propietarias incompatibles
entre sí, de forma que el software que se construye para HTC Vive u Oculus (Facebook)
no es compatible de forma directa, requiriendo modificaciones en el mismo.

Figura 3.25: Tethered VR de Oculus

• Dispositivos de control

Los dispositivos VR cambian la forma de control, no solo el usuario puede desplazarse

de forma virtual por su entorno, sino que además los mandos tradicionales no permiten el
nivel de inmersión que necesita este nuevo paradigma.

Por esta misma razón cada fabricante ha incorporado nuevos mandos, como los de HTC
Vive u Oculus, que traen sensores suficientes como para saber dónde están los mandos a
nivel espacial y poder ver una representación de tus extremidades en la pantalla.

Otras soluciones hacen uso de ultra sonidos o cámaras de infrarrojos para que podamos
interactuar con nuestras manos sin necesidad de sostener ningún dispositivo. En esta
categoría podemos encontrar el sensor LEAP Motion.

3.3.3 Fragmentación
Cuando hablamos de fragmentación de mercado, hacemos referencia a las diferencias
que nos encontramos en los dispositivos.

Estas diferencias se pueden dividir entre las que están puramente relacionadas con el
hardware del dispositivo (diferentes fabricantes usan distintos componentes) y las que

49
tienen que ver con el software que se ejecuta en los mismos (diferentes versiones de un
sistema operativo, por ejemplo)

En un mercado de consumo, como es el de la distribución de vídeo por internet, vemos

como año tras año se renuevan todos los modelos de los fabricantes, aumentando aún más
las diferencias y la diversidad de dispositivos existentes cada año.

Ferias como el Mobile World Congress y el E3 de las Vegas cada vez tienen más
presentaciones de novedades relacionadas con el mundo OTT.

En los siguientes puntos analizo los distintos tipos de fragmentación y como se puede
intentar sortear los problemas asociados de cara al desarrollo de aplicaciones.

3.3.3.1 Hardware
La fragmentación por hardware es con diferencia la más difícil de solventar, ya que es
muy complicado poder adaptar las experiencias de usuario a pantallas de distintos tamaños
con las que se interactúa de forma completamente distinta

En la siguiente figura podemos hacernos una idea de la diversidad de dispositivos y las

grandes diferencias existentes en términos de componentes usados en cada uno de ellos:

Figura 3.26: OTT Hardware (Accedo, 2017)

• Tamaño de pantalla

Algo que a priori no puede parecer un problema torna otra dimensión cuando hay que
crear aplicaciones con dispositivos que parten de pantallas de 3” pulgadas a dispositivos
con más de 100”.

Este problema no se puede resolver de una forma directa, así que lo más habitual es
crear distintas versiones de las aplicaciones adaptándose a la experiencia de uso y pantalla.

50
 • Relación de aspecto de pantalla

La relación de aspecto de pantalla es un problema menor, pero no por ello debemos de

menospreciarlo. Diferentes ratios de pantalla en los dispositivos pueden cambiar el aspecto
de la aplicación, de forma que deben de ser capaces de adaptar la visualización del
contenido a todos los casos posibles.

En el desarrollo web se han adoptado estrategias de diseño fluido o reactivo a los cambios
de pantalla, de forma que usando buenas prácticas podemos olvidarnos de este problema.

• Resolución de pantalla

Al igual que con el tamaño de la pantalla, las resoluciones que se manejan en estas
aplicaciones varían mucho de un dispositivo a otro.

La solución más directa implica el disponer de todos los recursos gráficos que son
utilizados en la aplicación (imágenes, tipografías) en distintos tamaños, de forma que se
use siempre el más adecuado para un dispositivo dado.

• Periféricos de entrada

Es un problema mucho más obvio, ya que los métodos de entrada de los móviles y
tabletas son gestuales, mientras que en PC disponemos de teclado y ratón, mientras que
en TV, reproductores y consolas de vídeojuegos se interactúa con la aplicación usando un
mando a distancia o controlador.

Realmente podemos diferenciar entre métodos de entrada gestuales, ratón y teclado, y

finalmente flechas de control.

Al igual que con el tamaño de pantalla, lo más normal es adaptar la aplicación a la

experiencia de usuario que se espera para cada dispositivo, agregando compatibilidad a
todos los métodos de entrada siempre que sea posible para simplificar el proceso de
desarrollo.

• Instrucciones CPU

Muchos dispositivos traen hardware asociado que permite acelerar ciertas operaciones
que son usadas de forma intensiva, como la decodificación de vídeo con codec H264 y H265,
así como el proceso de encriptado y desencriptado AES.

Dado que hacer estas operaciones a nivel de software requiere a su vez de un incremento
de las prestaciones de la CPU principal del dispositivo, este problema se soluciona
ofreciendo a los distintos dispositivos los streams de vídeo en el formato adecuado para
cada uno de ellos, usando por ejemplo streams adaptativos.

51
 Estas capacidades determinan, por ejemplo, que formatos de vídeo puede reproducir o
no un dispositivo. La solución que se aplica en estos casos es la de disponer de formatos de
vídeo alternativos, así como flujos de trabajo que no requieran ciertas operaciones. Las
aplicaciones cliente serán las que determinen cuando deben de aplicarse unos u otros en
función del modelo del dispositivo.

3.4 Software
La fragmentación por software existe por múltiples motivos, siendo el principal la
existencia de muchos dispositivos que corren sobre sistemas operativos distintos, ofreciendo
SDK basados en tecnologías diferentes.

Una solución es la de hacer aplicaciones web o aplicaciones híbridas. Por aplicación

híbrida se conocen a las que corren sobre un navegador en modo headless dentro de un
dispositivo que ofrece una tecnología distinta de forma principal para desarrollar. Después
este navegador accede a las partes específicas del SO mediante un framework propio. De
esta manera se pueden saltar las limitaciones del navegador web.

Apache Cordoba es un framework que soporta las distintas plataformas móviles,

permitiendo hacer un único desarrollo para todas las plataformas.

Con un modelo de aplicación web obtendremos un resultado muy cercano al de las

aplicaciones híbridas, pero en este caso las aplicaciones correrán sobre un navegador
normal, usando todas las capacidades que este ofrece a la hora de acceder al
almacenamiento del dispositivo, los sensores y el reproductor multimedia. Con los últimos
avances que está ofreciendo el organismo de estandarización de la web (W3C) esta opción
cada vez toma más sentido.

En los siguientes puntos vamos a repasar los distintos tipos de fragmentación

relacionados con el software de los dispositivos.

• Lenguajes de programación

Cada plataforma ofrece distintos entornos de desarrollo (Software Development Kit,

SDK por sus siglas en inglés) para facilitar la creación de aplicaciones a los desarrolladores.

Los dispositivos Android disponen te entornos basados en Java o Kotlin de forma oficial,
junto con el Android API que da acceso a todas las capacidades de los dispositivos.

Apple ofrece Objective-C, Swift y TVMLKit (basado en XML y JavaScript) para los
suyos.

Los dispositivos conectados habitualmente aportan soluciones basadas en HTML/JS

además de sus APIs propios, aunque en algunos casos el lenguaje C es soportado, ya sea

52
desde el browser (NaCL o WebAssembly) o directamente compilando el código para el
dispositivo.

Con un escenario tan heterogéneo la única solución es crear aplicaciones híbridas o

directamente programar con las herramientas que ofrece cada fabricante para ofrecer el
mayor rendimiento posible.

• Versiones de SO

Otro de los vectores de fragmentación viene dado por las distintas versiones de un
sistema operativo que hay funcionando al mismo tiempo. Usualmente cuando un fabricante
de hardware desarrolla una nueva versión del mismo, los usuarios actualizan sus sistemas,
pero siempre hay un porcentaje de usuarios que no lo hace. Igualmente hay usuarios que
no renuevan sus dispositivos según dicta el mercado, de forma que en algunos casos no
pueden aplicar a dichas actualizaciones.

Como podemos ver en las siguientes figuras, la mayoría de los dispositivos activos
siempre usan las últimas versiones de los SO, aunque en el caso de Android existe más
fragmentación:

Figura 3.27: Versiones iOS (Apple, 2017) y Android. (Google, 2017)

Además, hay plataformas, como es el caso de las Smart TVs, que históricamente han
sufrido de una falta de actualizaciones de sus sistemas, aunque en los últimos modelos
parece que si se están ofreciendo de forma regular para ofrecer nuevas características y
parches de seguridad.

La fragmentación en este escenario tiene que ver con los APIs que ofrece el fabricante
en las distintas versiones de los sistemas operativos y los SDK asociados, ya que
normalmente discontinúan algunos métodos y agregan otros que los reemplazan. La única
forma de solucionar este problema es usando librerías de compatibilidad con las versiones
nuevas de los SDK, y en un caso más extremo, mantener dos bases de código para distintas
versiones.

53
 • APIs privativos

Todas las plataformas tienen sus propios APIs independientes para poder acceder a los
recursos del sistema.

La fragmentación de APIs impacta en una misma familia de dispositivos, cuando hay

dos formas o más incompatibles entre si para realizar una misma acción. Por ejemplo, en
algunos dispositivos Smart TV, para reproducir vídeo podemos usar la etiqueta vídeo de
HTML, mientras que en los dispositivos Samsung hay que usar su propio API bajo el
nombre de AVPlay. El código de un dispositivo no será compatible con el de otro,
obligándonos a adoptar estrategias para solucionar estas diferencias.

En este caso nos encontramos que al no seguir los estándares HTML/JS que dicta el
W3C, al no cubrir históricamente gran parte de las necesidades que tienen las aplicaciones
de distribución de vídeo, los fabricantes se las han arreglado para dar soporte a dichas
necesidades implementando cada uno sus propios APIs. De esta forma es imposible ejecutar
la misma base de código entre dispositivos, ya que cada uno necesita inicializar las distintas
partes del sistema de una forma completamente distinta.

La única solución posible es el uso de una librería que nos abstraiga de los métodos
privados, implementándolos directamente, y que exponga métodos comunes fáciles de usar.

TAL BBC es un ejemplo de framework que usa este concepto para solucionar dicho
problema.

3.4.1 Conclusiones
Como hemos podido comprobar, existen una gran cantidad de dispositivos muy diversos
con unas características muy dispares. Si queremos desarrollar una aplicación de vídeo bajo
demanda debemos de evaluar si queremos desarrollarla para una plataforma específica o si
por el contrario queremos llegar al mayor número de dispositivos posibles.

Igualmente, siempre vamos a encontrar una mayor o menor fragmentación en la

plataforma o tecnología elegida, de forma que tendremos que intentar solucionar los
problemas que se nos van a plantear debido a las diferencias entre dispositivos.

Analizando las figuras 3.3.1 Devices used y la figura 3.3.1 Devices owned podemos
observar que los dispositivos conectados son los más usados para ver vídeo. Estos
dispositivos soportan en su mayoría HTML/JS para el desarrollo de sus aplicaciones.
Además, las plataformas móviles y los ordenadores también soportan esta tecnología, de
forma que en una primera aproximación sería interesante desarrollar la aplicación para la
misma, y solucionar los problemas relacionados a la gran fragmentación existente.

54
 En el Capítulo 5 realizo un análisis del ecosistema HTML/JS y todas las herramientas
que nos ofrece su ecosistema a la hora de desarrollar una aplicación.

3.5 Plataformas OTT

Como hemos visto, la arquitectura de una aplicación de distribución de vídeo por
internet es realmente compleja, teniendo que integrar un gran número de servicios con
proveedores de contenido y las aplicaciones finales.

Las empresas que quieren entrar en el sector se pueden sentir apabulladas ante este
escenario, encontrando muchas dificultades cuando quieren crear una aplicación ante la
gran cantidad de proveedores que existen para todos los servicios y la cantidad de horas
de integración que hay que invertir para poder comunicarlos entre ellos.

Todo esto repercute a estas empresas de dos formas

• Tiempo de salida a mercado muy elevados

• Inversión inicial alta

Los tiempos de salida están motivados por todas las horas de integración, test de
integración para comprobar que todo está en orden, desarrollo de aplicaciones cliente, etc.

La inversión inicial es elevada tanto por la necesidad de invertir las horas anteriormente
mencionadas junto con el pago de los derechos de emisión, campañas de marketing,
comisiones por pasarelas de pago, etc.

A raíz de la problemática han surgido las plataformas OTT.

Estas plataformas atacan la problemática de un desarrollo desde cero gracias a que

ofrecen toda su infraestructura cerrada a los proveedores de contenido.

De esta forma lo único que se necesita es proveer el contenido y los metadatos a la

plataforma para que esta los procese y los publique, reduciendo a casi cero el tiempo de
salida al mercado y la inversión inicial no relacionada con la compra de derechos.

En el siguiente diagrama podemos ver la simplificación respecto al escenario previo:

OTT Platform

Clients Network Online

devices Video
Platform

Video
Origins

Figura 3.28: Diagrama Plataforma OTT

55
 En resumen, las plataformas OTT se vuelven responsables de todas las partes
involucradas, incluida la monetización y las analíticas, a excepción de los orígenes de vídeo,
que será lo único que necesite proveer un cliente que haga uso de ellas.

Los problemas que tienen estas plataformas es que existe una nula capacidad de
personalización del servicio, los menores beneficios al existir un intermediario y la realidad
de compartir un espacio de distribución con tu competencia, sin la posibilidad de cambiar
la experiencia de uso, ya que todos comparten la misma.

Alguna de las compañías que están ofreciendo servicios bajo su plataforma OTT son
Amazon Prime, YouTube TV o Now TV.

56
4 Streaming de contenido
Las aplicaciones de vídeo OTT basan todo su potencial en la posibilidad de reproducir
los vídeos en las aplicaciones finales.

Para hacer esto posible, desde el origen del vídeo al stream final que es consumido
ocurren una serie de transformaciones, que pasan desde adaptar la fuente del vídeo original
a streams que pueden ser consumidos, a securizar dichos streams mediante diversas
técnicas.

Es además importante entender la anatomía de los streams de vídeo, ya que cambiará

mucho en función del tipo de contenido (live o VOD), así como de los dispositivos que lo
van a consumir.

En los siguientes puntos analizaremos las acciones que se llevan a cabo en la

infraestructura del OVP relacionadas con el consumo de vídeo, así como todas las partes
que conforman a los streams.

4.1 Infraestructura
La siguiente figura nos muestra un escenario típico de procesado y consumo de streams
de vídeo, señalando con un número la acción que se realiza en cada parte de forma
secuenciada para poder detallar más adelante que es lo que sucede.

Figura 4.1: Flujo streaming contenido

1. Adquisición de datos desde los orígenes

Las fuentes de vídeo se encuentran en los orígenes, que pueden provenir de distintas
fuentes. Habitualmente los vídeos a procesar se obtienen de servidores FTP o carpetas en
la nube, pero también podemos encontrar señales digitales emitidas en directo ya sean
satelitales o locales.

57
 2. Procesado de los orígenes

Una vez que se dispone de los streams originales, cada OVP transformará el formato al
más apropiado según sus necesidades.

3. Obtención de claves de licencia

En el caso de querer segurizar el contenido, lo más habitual es encriptarlo. Para poder

realizar esta acción primero necesitamos obtener la clave AES que será compartida con las
aplicaciones clientes mediante los servidores de licencia.

4. Encriptado de vídeo

Una vez el OVP dispone de las claves AES, lo único que tiene que hacer es encriptar los
streams de una forma conocida para que las aplicaciones cliente sean capaces de hacer el
proceso inverso.

5. Almacenado de vídeo

Cuando se ha terminado el procesado de los vídeos, estos se almacenan en las CDN

esperando a que las aplicaciones cliente los consuman.

6. Autorización de aplicaciones cliente

Cuando una aplicación cliente quiere reproducir un contenido primero tiene que verificar
que tiene los privilegios suficientes y obtener las claves AES para el contenido.

7. Obtención de ficheros de vídeo

Finalmente, las aplicaciones cliente descargarán los streams de la CDN y gracias a las
claves AES podrán desencriptar el contenido además de ser capaces de reproducirlo.

58
4.2 Anatomía del Stream
Cuando hablamos de streaming nos referimos a la acción de transferir un vídeo, en
cualquier formato, a través de internet desde un servidor a un cliente final.

Es importante tener en mente la infraestructura (visto en el punto anterior) y todas las

partes que conforman un stream de vídeo, ya que cada capa puede variar mucho en función
de las necesidades de cada cliente final.

Los distintos streams finales varían tanto que en muchos casos un stream solo es
compatible para ciertos dispositivos, de forma que existe una fragmentación de los mismos
en función de las capacidades de reproducción que tienen.

En la siguiente figura podemos ver las características que determinan cada tipo de
stream, que serán descritas en los siguientes puntos:

Application Protocol - HTTP, RTMP, RTSP, RTP

Transmission Technique - Progressive, Adaptive

Container - TS, MP4

DRM | Encryption

Codec - H264, HEV

Figura 4.2: Anatomía del contenido de vídeo

4.2.1 Protocolos de transmisión

El protocolo usado en el mayor número de casos en las aplicaciones OTT es HTTP, ya
que es el standard de facto en internet.

Algunos agentes como los operadores de cable, continúan usando protocolos como
RTMP, RTSP, RTP usando conexiones a internet dedicadas para emitir en IPTV.

4.2.2 Estrategias de transmisión

Se han desarrollado múltiples estrategias de transmisión que permiten a los clientes
finales consumir el contenido de una forma cada vez más compleja y eficiente, de forma
que se reduzca el ancho de banda requerido, reduciendo costes y mejorando la experiencia
de usuario, al evitar eventos de buffering y pausas en las aplicaciones cliente.
59
4.2.2.1 Descarga progresiva
El modelo de descarga progresiva (o progressive download en inglés) hace referencia al
funcionamiento del protocolo HTTP por defecto, en el cual un cliente realiza una petición
al servidor HTTP y este envía dicho fichero de forma ordenada en múltiples segmentos
TCP.

Es un modelo simple pero muy poco eficiente, ya que, si un usuario quiere saltar a una
parte determinada del vídeo, este debe de estar descargado en el cliente.

Figura 4.3: Descarga progresiva

La ventaja más grande que tiene este formato es que funciona bajo un servidor HTTP
sin ninguna modificación como Apache o Nginx, y además esta soportado por todos los
reproductores de vídeo, de forma que es muy fácil de implementar.

Como inconvenientes tenemos el ya mencionado problema con los saltos temporales, a

lo que hay que sumar la necesidad de procesar los orígenes a múltiples vídeos progresivos
usando todas las combinaciones de resolución y bitrate necesarias.

Por este motivo normalmente solo se utiliza para contenido en el que la calidad no es
determinante, y en el que no está permitido hacer saltos en el tiempo, como es la publicidad
o los tráileres de películas.

60
4.2.3 Pseudo-streaming
El modelo de pseudo-streaming es una mejora de la descarga progresiva. En este
escenario el servidor HTTP permite que el cliente realice peticiones apuntando a una marca
de tiempo en particular.

De esta forma se soluciona el problema que nos encontramos en la descarga progresiva

con los saltos a distintas posiciones temporales del vídeo que estamos reproduciendo (trick
play en inglés), ya que no hace falta que se descargue todo el fichero para ir a un punto
futuro. Esto supone un incremento en la eficiencia del uso del ancho de banda con respecto
a la descarga progresiva.

Figura 4.4: Pseudo-streaming

El problema que tiene este mecanismo de transmisión es que no es HTTP estándar, de

forma que los servidores deben de aceptar dichos parámetros para ser capaces de enviar la
parte del stream que nos está pidiendo la aplicación cliente.

61
4.2.4 Descarga adaptativa
En esta estrategia (conocida como Adaptive Streaming en inglés) en lugar de tener un
stream formado por un único fichero, contamos con un índice de segmentos de vídeo
disponibles en el servidor, especificando las calidades de los mismos y las pistas de audio.

Los reproductores incluyen algoritmos de QoS que ayudan a elegir los fragmentos más
interesantes para ser descargados, usando por ejemplo criterios de ancho de banda
disponible o de capacidades físicas del dispositivo.

Este formato sigue permitiendo el uso de servidores HTTP sin modificar, optimizando
la utilización del ancho de banda sin salirnos del estándar.

En la siguiente figura podemos ver como las aplicaciones cliente piden de forma activa
los distintos fragmentos de vídeo:

Figura 4.5: Descarga adaptativa

En el punto de procesado de vídeo veremos cómo se generan este tipo de streams a partir
de un origen.

Los formatos adaptativos usados en el mundo OTT son los siguientes

62
 Apple HLS

HLS (HTTP Live Streaming) es un formato de transmisión desarrollado por Apple que
actualmente se encuentra publicado como RFC no estándar.

El índice de este formato es un fichero de texto plano (m3u8) que contiene etiquetas
para hacer referencia a las pistas que conforman el stream

Microsoft Smooth Streaming

Es un formato adaptativo privativo de Microsoft. Esta soportado por la totalidad de los

productos de Microsoft, Smart TVs y dispositivos móviles.

Internamente tiene un índice (fichero Manifest en este caso) que indica las pistas de
audio, vídeo y subtítulos disponibles, así como el orden de preferencia, idioma, calidades y
codecs usados en cada caso. Este formato solo soporta el DRM Microsoft PlayReady.

MPEG-DASH

MPEG-DASH es un formato estándar de transmisión totalmente agnóstico a nivel de

codec, tipo de vídeo (soporta VOD y live) y DRMs.

Está ampliamente aceptado en múltiples dispositivos e incluso en los navegadores web

gracias a un reproductor de referencia creado por el consorcio DASH-IF (DASH Industry
Forum), soportando DRM incluso en este escenario.

4.2.5 Contenedores
Los streams de vídeo se encapsulan en distintos contenedores para su transporte,
soportando distintas características y metadatos

Transport Stream

El estándar MPEG Transport Stream (TS por sus siglas en inglés) especifica un
contenedor pensado para almacenar información de audio, vídeo y datos asociados a
programas.

Es utilizado en la emisión digital de vídeo (Digital Vídeo Broadcast, DVB por sus siglas
en inglés), IPTV y en el mundo OTT sobre el formato HLS, aunque poco a poco los
fabricantes están adoptando otros contenedores y está perdiendo protagonismo.

63
 MP4

Al igual que MPEG-TS, MP4 es un contenedor que almacena audio, vídeo y datos
asociados, como pueden ser subtítulos, meta información de las pistas de datos, etc.

fMP4

Con la llegada de los formatos adaptativos el contenedor MP4 ha evolucionado, creando

el nuevo estándar fragmented MP4 (Wolenetz, Smith, Watson, Colwell, & Bateman, 2016)
que permite acceder a distintos streams con distintas calidades dentro del contenedor.

4.2.6 Encriptación y gestión de derechos digitales

Como ya hemos visto, si queremos agregar una capa extra de seguridad podemos
encriptar el contenido para que sea necesario el uso de una clave AES compartida para
poder reproducir el mismo.

AES-128 es el estándar de facto para encriptar ficheros en el mundo OTT existiendo dos
modos, Counter Mode (CRM por sus siglas en inglés) o Cipher Block Chaining (CBC por
sus siglas en inglés) siendo cada uno usado por distintos DRMs e incompatibles entre sí.

Microsoft PlayReady

Microsoft PlayReady es un DRM propietario de Microsoft asociado al formato de

transmisión Smooth Streaming, aunque también puede ser usado con otros formatos
adaptativos como es MPEG-DASH.

Smooth Streaming soporta este DRM gracias a la etiqueta XML Protection Header
presente en el fichero Manifest. Dicha etiqueta contiene toda la información necesaria, de
forma que los reproductores de los clientes puedan localizar a los servidores de licencia,
pedir la autorización para acceder a un contenido dado, y de esta forma obtener las claves
AES necesarias para reproducir el mismo.

Desde el lado del cliente se pueden modificar parámetros para aumentar la seguridad,
como por ejemplo agregar datos que puedan ser comprobados desde el otro extremo y así
poder validar que el usuario es legítimo. Igualmente, de esta forma podemos usar
parámetros obtenidos del VCMS, como por ejemplo una URL actualizada del servidor de
licencias.

A nivel público no existe mucha documentación sobre cómo funciona esta tecnología,
pero gracias a que podemos capturar el tráfico y analizarlo sabemos que internamente usa
SOAP para intercambiar mensajes entre el cliente y el servidor.

En la siguiente figura podemos ver el XML que contiene la etiqueta Protection Header:

64
 <WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader"
version="4.0.0.0">
<DATA>
<PROTECTINFO>
<KEYLEN>16</KEYLEN>
<ALGID>AESCTR</ALGID>
</PROTECTINFO>
<KID>wFMbdsgMMEGWaBGS/3TrWQ==</KID>
<CHECKSUM>ytTI/KiC60I=</CHECKSUM>
<LA_URL>http://playready.directtaps.net/pr/svc/rightsmanager.asmx</LA_URL>
<CUSTOMATTRIBUTES>
<IIS_DRM_VERSION>7.1.1565.18</IIS_DRM_VERSION>
</CUSTOMATTRIBUTES>
</DATA>
</WRMHEADER>
Figura 4.6: PlayReady Protection Header

Apple FairPlay

Existe poca información sobre cómo funciona este formato creado por Apple, pero como
podemos ver en la página oficial de la compañía, está basado en HLS (Apple, 2016).

Dado que HLS permite definir los servidores de licencias de los que se pueden obtener
las claves AES, este DRM debe de actuar como barrera sobre dichas ubicaciones,
permitiendo solo a los usuarios legítimos acceder a las mismas.

Verimatrix

Verimatrix es otro DRM que actúa a nivel de cliente instalando el certificado con una
validez temporal limitada del servidor que contiene las claves AES, de forma que, si un
usuario no autorizado intenta acceder, la conexión al servidor fallará siendo imposible
recuperar las claves e impidiendo la reproducción del contenido.

Google Widevine

Google compro a Widevine, empresa especializada en seguridad, para proveer a sus

dispositivos Android de una solución DRM. Existen dos versiones de Widevine, Classic y
Modular, y al ser un DRM privativo conocemos poco sobre su comportamiento.

La versión de Widevine Classic hace uso de un formato propio de streaming, siendo muy
cerrado y difícil de implementar, estando solamente presente en versiones de Android 4.4
o inferiores.

La versión actual de este DRM es conocida como Widevine Modular. Siendo agnóstica
al tipo de stream se usa sobre múltiples formatos de streaming, sobre todo sobre MPEG-
Dash.

65
4.2.7 Codecs
Finalmente, el contenido que viaja dentro de los contenedores está codificado con alguno
de los codecs utilizados por la industria, reduciendo el peso del fichero final.

Los codecs más usados a día de hoy son:

• H.264 MP4

• H.265 – HEVC

4.3 Procesado del contenido

Como he señalado a lo largo de todo este proyecto, los streams de vídeo que se enredan
a las aplicaciones en los dispositivos finales no son los streams que obtenemos en origen,
ya que se realizan una serie de conversiones para adaptarlos de la forma más eficiente y
añadir distintas medidas de seguridad.

En la siguiente figura podemos ver dicha transformación:

Master Stream

Recodificación a
distintas calidades.

Low BR Stream

Medium BR Stream Linear streams

High BR Stream

Separación de los
streams en múltiples
fragmentos de igual
duración.

Low BR Low BR Low BR Low BR Low BR

Chunk Chunk Chunk Chunk Chunk

Adaptative
Medium Medium Medium Medium Medium
streams BR Chunk BR Chunk BR Chunk BR Chunk BR Chunk Adaptative streams
indexes
High BR High BR High BR High BR High BR
Chunk Chunk Chunk Chunk Chunk

Encriptado opcional de
los fragmentos.
Creación de los ficheros
de índice que hacen
referencia a los mismos.
Encrypted Encrypted Encrypted Encrypted Encrypted
Low BR Low BR Low BR Low BR Low BR
Adaptative Chunk Chunk Chunk Chunk Chunk

streams Encrypted Encrypted Encrypted Encrypted Encrypted

indexes Medium BR Medium BR Medium BR Medium BR Medium BR Encrypted streams
Chunk Chunk Chunk Chunk Chunk
+
DRM Encrypted Encrypted Encrypted Encrypted Encrypted
High BR High BR High BR High BR High BR
Chunk Chunk Chunk Chunk Chunk

Figura 4.7: Procesado de vídeo

66
 Los pasos mostrados son los siguientes:

● Recodificación en distintas calidades del contenido.

● Separación de los contenidos de distintas calidades en fragmentos de tiempo fijo.

● Generación de fichero índice o manifiesto con toda la información requerida.

4.3.1 Encoding
Por regla general los orígenes suelen ser las versiones maestras digitales del contenido
que se va a enviar a las aplicaciones finales.

Dichas versiones suelen tener una calidad demasiado elevada como para poder enviarlos
a todos los dispositivos ya que la mayoría de ellos no disponen del hardware adecuado para
disfrutar de dicha calidad.

En este primer paso se generarán múltiples streams progresivos con distintas calidades,
listos para ser consumidos directamente en el caso de ser streams progresivos, o ser
procesados en los siguientes pasos si son adaptativos o hay que aplicar medidas de
seguridad.

Con esto conseguimos tener streams específicos por cada dispositivo, adecuando la
resolución, la ratio de transferencia y los codecs de audio y vídeo.

4.3.2 Generación de fragmentos

Una vez que disponemos de los vídeos codificados a las distintas resoluciones objetivo
en formato lineal, el siguiente paso es transformarlos a formatos adaptativos mucho más
eficientes en términos de ancho de banda.

Para ello procesaremos cada una de las calidades, partiéndola en fragmentos de una
duración determinada, introduciendo el contenido en los contenedores ya descritos.

Habitualmente las pistas de vídeo y de audio en este punto se separan, generando pistas
independientes de fragmentos para cada una de ellas.

4.3.3 Encriptación
Como medida opcional de seguridad se pueden cifrar los distintos fragmentos de vídeo
mediante diferentes técnicas, siendo la más habitual AES usando una clave compartida.
De esta forma resulta imposible poder reproducir el contenido sin conocer previamente
dicha clave.

La clave AES debe de obtenerse, como vimos en el diagrama de infraestructura de

streaming, (Figura 4.1: Streaming de contenido) de un servidor de licencias. Dicho servidor

67
puede realizar validaciones contra otros servicios para decidir si el cliente puede o no
acceder a la clave. En este contexto el servidor de licencias se comporta como un DRM ya
que autoriza al cliente final.

4.3.4 Generación de Índices

Finalmente, en este paso se generarán uno o más ficheros que indican las calidades
disponibles de vídeo definiendo el ratio de transmisión necesario, la resolución y encoding
utilizado, pistas de audio indicando los idiomas y otros extras como pueden ser las pistas
de subtítulos, los tipos de DRM, donde encontrar la licencia, etc.

Estos índices serán peticionados por los reproductores cuando quieran reproducir un
stream adaptativo, obteniendo la información necesaria del mismo para poder determinar
que fragmentos deben consumir.

68
5 Análisis de dispositivos HTML JS
Como vimos en las conclusiones del punto 3.3, si queremos hacer una aplicación de
distribución de vídeo y llegar al mayor número de usuarios, es una muy buena idea centrase
en las aplicaciones de Smart TV y dispositivos conectados.

En su mayoría todos ejecutan las aplicaciones sobre navegadores web en modo headless,
de forma que en este capítulo voy a analizar las capacidades hardware de los dispositivos,
las particularidades que tienen estas aplicaciones, así como el ecosistema HTML/JS, para
finalmente realizar un análisis de frameworks que usan esta tecnología y que nos pueden
ayudar con nuestro desarrollo.

En las conclusiones expongo las razones por las que he elegido TAL BBC como
framework de desarrollo, dando paso al siguiente capítulo en el que realizo un análisis para
entender sus puntos fuertes y las partes que podemos mejorar.

5.1 Hardware y capacidades

Antes de poder profundizar en el ecosistema de las aplicaciones para Smart TV y
dispositivos conectados es conveniente pararse a analizar las características en común que
tienen todos los dispositivos, lo cual derivará en como las aplicaciones son construidas y
consumidas por parte de los usuarios finales.

En los siguientes puntos revisaremos los tamaños y resoluciones de las pantallas, la

potencia de los dispositivos y los métodos de entrada disponibles.

5.1.1 Pantallas
En 2016 el tamaño medio de las pantallas superó las 40 pulgadas y en este 2017 se espera
que alcance las 42.6 pulgadas (Kang, 2017).

Además, existe una tendencia a aumentar la resolución de las mismas, de forma que la
base de dispositivos existentes, compuesta por paneles HD (High Definition, 720 pixeles
verticales) y FHD (Full HD, 1080 pixeles verticales), verá como se incorpora una mayor
cantidad de paneles UHD (Ultra HD, 2160 pixeles verticales).

A nivel de aplicación el interfaz de usuario suele funcionar a distintas resoluciones, siendo

la más habitual HD (720p), pero con la inclusión de los paneles UHD los fabricantes
permiten usar el estándar FHD para las aplicaciones.

Según las recomendaciones de Samsung (Samsung, 2017) y LG (LG, 2017) , la resolución

recomendada ha pasado a ser FHD, aunque se sigue permitiendo el uso de HD, de forma
que nuestra aplicación pueda ser compatible con más dispositivos.

69
5.1.2 Métodos de entrada
Como ya hemos visto, existe una fragmentación respecto a los distintos métodos de
entrada disponibles en las aplicaciones.

Si nos centramos en Smart TV y dispositivos conectados, veremos que hay una gran
variedad de opciones para usar las aplicaciones, enumerándolos todos en los siguientes
puntos:

Mandos a distancia

Es el control que todo el mundo asocia a una televisión, sin necesidad de que tenga
capacidades de conexión o visualización de vídeo a través de internet. Los mandos han
evolucionado, introduciendo nuevas capacidades que veremos en los siguientes puntos, pero
todos incorporan botones direccionales, un botón de ok y finalmente un botón de volver.

Dentro de esta categoría y por similitud en la forma de interactuar con las aplicaciones
podemos incluir los mandos de consolas de videojuegos y de STB, además de teclados, ya
que, aunque tengan una configuración distinta todos incluyen botones direccionales y de
ok/volver.

Como veremos cuando profundicemos en la anatomía de las aplicaciones para estos

dispositivos, todos estamos acostumbrados a manejar un mando a distancia, pero moverse
por una aplicación pulsación a pulsación puede ser frustrante por el tiempo que toma el
realizar cualquier acción.

Ratón

Con motivo de agilizar la navegación en las aplicaciones y acercar la experiencia a una

con la que los usuarios se desenvuelven realmente bien, como puede ser la navegación con
ratón en los ordenadores personales, los distintos fabricantes han introducido esta opción
en sus dispositivos.

Si tenemos en cuenta el contexto en el cual una persona hace uso de su televisión,

normalmente desde el salón de su casa, a varios metros del dispositivo, se hace un poco
difícil el uso de un ratón tradicional que necesita ser utilizado sobre una superficie regular
para que detecte de forma correcta el movimiento.

Por este motivo los fabricantes han optado por incluir ratones al aire, que hacen uso de
acelerómetros, para calcular el movimiento que queremos dar, mostrándolo en la pantalla
para que veamos donde estamos situados.

Con la irrupción de los dispositivos móviles, los fabricantes han lanzado aplicaciones
accesorio que permiten utilizar un ratón virtual usando la pantalla táctil.

70
 Gestual

Es una variante del ratón, pero se merece un punto propio al hacer uso de cámaras que
captan el movimiento del usuario, permitiendo que con sus extremidades maneje un
puntero virtual en la pantalla, pudiendo hacer clic mediante distintos gestos.

Samsung con su Smart Interaction y Microsoft Xbox con Kinect son dos de los mayores
impulsores de esta tecnología, que actualmente se encuentra en desuso.

Voz

El control mediante voz es una de las apuestas más interesantes gracias a la buena
aceptación que tienen los asistentes virtuales controlados por voz como Siri de Apple,
Google Assistant de Google o Alexa de Amazon.

Este método de entrada está disponible en los dispositivos conectados y Smart TV desde
el año 2012, cuando Samsung la introdujo en sus modelos. Sony, Samsung, LG y Microsoft
son algunas de las marcas que ofrecen el control mediante comandos de voz de sus
dispositivos.

Normalmente el micrófono usado para capturar los comandos de voz se encuentra en el

mando a distancia, ofreciendo un botón que ha de ser pulsado para que la televisión empiece
a reconocer los comandos de voz.

Las aplicaciones deben diseñarse para ser utilizadas mediante comandos de voz. El caso
de uso que podemos encontrar en distintas aplicaciones consta de una pantalla que solo se
muestra cuando se activa el modo de voz, la cual se superpone al contenido que está viendo
el usuario, mostrando las palabras clave que puede utilizar para navegar. Por ejemplo,
podremos decir el nombre de una categoría, indicar el nombre de un contenido que
queremos reproducir o el comando “volver” para ir a la pantalla anterior.

Es importante tener en cuenta que las distintas plataformas permiten configurar los
comandos que la persona debe pronunciar, así como indicar el porcentaje de coincidencia
detectado para que se ejecute dicho comando.

5.1.3 Aceleración y capacidades de CPU

El mercado de las Smart TV, dispositivos conectados y en general el de la electrónica
de consumo se ha visto beneficiado por la escalada de potencia que se ha vivido gracias a
la alta competitividad en el mercado de teléfonos móviles.

De esta forma se ha pasado de dispositivos con poca memoria y CPUs de gama baja, a
dispositivos con 4 núcleos. Esto se ha visto reflejado en el rendimiento de las aplicaciones,
que con el paso de los años han visto mejorado el mismo, obteniendo respuestas más fluidas
y en general, una mejor apariencia.

71
 A pesar de esto, no podemos olvidar que el mercado es muy dispar, y a día de hoy se
venden también dispositivos dentro de las categorías de gama media y baja, por lo que es
muy importante optimizar las aplicaciones y tener en cuenta posibles problemas que puedan
aparecer por rendimiento a la hora de desarrollar una aplicación.

5.2 Aplicaciones en pantallas grandes

Partiendo de las características que hemos analizado en el punto anterior, es importante
realizar un análisis de la anatomía de las aplicaciones que ejecutan los dispositivos de
pantalla grande.

Lo primero que tenemos que tener en cuenta es como se consume el contenido a través
de estos dispositivos. Por regla general todo el mundo ve la televisión en el salón de su casa
a varios metros de distancia. De aquí nace la regla de los 3 metros o “10-Foot interface
rule”, como se le conoce en inglés, que vemos plasmada en la siguiente figura:

Figura 5.1: Regla de los 3 metros (Samsung, 2017)

Esta regla nos dice que hay que diseñar las aplicaciones teniendo en cuenta que el usuario
va a visualizarlas a 3 metros de distancia, lo cual implica las siguientes particularidades:

• El tamaño mínimo de la letra debe de ser suficientemente grande como para leerse
en la distancia.

• La tipografía elegida tiene que estar bien definida y no ser confusa.

• Los colores que resaltan el contenido seleccionado deben de hacer contraste con
el resto de la pantalla para indicar al usuario donde está situado.

A nivel de interacción con el dispositivo, hay que tener en cuenta que el control principal
siempre va a ser el mando a distancia. Cuando desarrollamos nuestras aplicaciones debemos
ser conscientes de que el usuario tiene que saber qué elemento de la pantalla está
seleccionado. De esta forma podrá deducir que tecla direccional del mando a distancia debe
pulsar para navegar.

72
 Desde el punto de vista de diseño tendremos que respetar los siguientes principios:

• Mapa de navegación claro. Filas y columnas alineadas.

• Elementos seleccionados (con foco) que deben de resaltar sobre el resto de

elementos.

• El usuario debe de ser capaz siempre de recuperar el control. No se puede perder

el foco.

En la siguiente figura podemos ver como se recomienda mostrar el contenido a los

usuarios finales y como resaltar el mismo para facilitar el uso de la aplicación:

Figura 5.2: Navegación y foco. (Samsung, 2017)

Dado que los dispositivos pueden incorporar múltiples mecanismos de entrada de forma
simultánea, cuando desarrollamos una aplicación debemos contemplar que una persona
pueda usar cualquiera de los mismos en cualquier momento. Esta circunstancia no debe de
romper la navegación en la aplicación.

Desde un punto de vista del desarrollo es importante pensar cómo vamos a gestionar
este control del foco, su navegación y los cambios entre distintos métodos de entrada, ya
que es un problema no trivial. Esto es debido a que en HTML/JS, como veremos en el
análisis de los distintos frameworks, el control de foco se tiene que hacer de forma manual,
es decir, hay que mantener el estado de quien tienen el foco, y cada vez que se recibe un
evento a tratar, modificar las clases CSS del elemento que pierde el foco y de los que lo
ganan. Existen dos aproximaciones, que son la implementación de una solución específica
para nuestra aplicación, o por el contrario hacer uso o crear un framework que ofrezca las
herramientas necesarias que permitan al desarrollador el abstraerse de la implementación.

73
5.3 JavaScript
JavaScript es un lenguaje que hoy cumple 20 años, desde que se aprobó el primer
estándar ECMAScript en 1997.

JavaScript es un lenguaje de programación interpretado que se ejecuta sobre un único

hilo. Es un lenguaje con tipado dinámico, herencia basada en prototipado y con un fuerte
componente funcional y eventual.

Este lenguaje puede ser ejecutado por interpretes en los navegadores web y en servidores,
gracias a Node.js.

Durante estos 20 años ha sufrido una constante evolución, problemas de

incompatibilidad de implementaciones y en los últimos años un crecimiento exponencial en
el número de desarrolladores que programan con él.

Si atendemos a los últimos informes de Stack Overflow, página de referencia de millones

de desarrolladores en todo el mundo, veremos que desde 2014 es el lenguaje más popular
en dicha página (Stack Overflow, 2017) y (Stack Overflow, 2016). Si analizamos el informe
de GitHub, el repositorio Git más usado para proyectos Open Source, veremos que
JavaScript es el lenguaje más utilizado en esta plataforma, duplicando en número de
proyectos a Java, que es el siguiente lenguaje en la lista (Github, 2016).

Todo este volumen de usuarios y de aplicaciones ha impulsado la creación de un

ecosistema propio de herramientas, frameworks y personas de interés que hacen que todo
sea extremadamente dinámico y por momentos pueda ser apabullante para cualquier
desarrollador que quiera empezar a programar (Aguinaga, 2016).

Por eso mismo, y más teniendo en cuenta el propio ecosistema de dispositivos de

aplicaciones para OTT, en este punto voy a repasar la historia de este lenguaje, así como
el estado del mismo en dichos dispositivos.

5.3.1 Historia
El origen de este lenguaje se remonta a 1995 de la mano de Brendan Eich (cuyo trabajo
en Netscape posibilitó su nacimiento) (Eich, Mills, & User:Sneethli2, 2012), para mejorar
la forma en la que se interactuaba con la web.

El lenguaje se creó solo en 10 días como una prueba de concepto y se introdujo en la

versión Netscape Navigator 2 Beta. Microsoft no quiso quedarse atrás y creó su propia
versión del lenguaje realizando ingeniería inversa sobre la versión de Netscape, liberando
JScript en 1996 para Internet Explorer 5 (Microsoft, 1996) .

Para evitar que cada fabricante implementara su propia versión del lenguaje, Netscape
envió a ECMA una propuesta para trabajar en una versión estándar del mismo, que
finalmente se aprobó en 1997 bajo el nombre de ECMAScript (ECMA, 1997).

74
 En 1999 el estándar alcanza su tercera versión, siendo la base de lo que conocemos como
JS moderno. Tras esta versión el comité tardó 10 años en liberar una nueva versión del
estándar.

En paralelo a los estándares, el lenguaje fue extendiendo su funcionalidad gracias a la

inclusión de distintas mejoras por parte de los navegadores, así como por soluciones creadas
por usuarios expertos. Algunas de estas incorporaciones fueron la inclusión de peticiones
web asíncronas mediante el objeto XMLHttpRequest en 1998 y el desarrollo del formato
JSON (Crockford, 2001) y (ECMA, 2013). Como nota curiosa, resaltar que el formato
JSON ha desplazado notablemente al XML en el intercambio de mensajes entre
aplicaciones cliente y servidores, pasando la frontera de JavaScript y existiendo intérpretes
para cualquier lenguaje en uso.

Todas estas mejoras ayudaron a desarrollar una nueva forma de crear aplicaciones web,
permitiendo hacer peticiones de datos de forma asíncrona y renderizarlos en el lado del
cliente sin tener que recargar la página entera. Este nuevo paradigma se definió en un
artículo que explica cómo aplicar esta técnica usando las tecnologías anteriormente citadas
(Garrett, 2005).

ECMAScript 5 fue liberado en 2009, e incluyó las mejoras que se desarrollaron en

paralelo, además de ser la primera versión con soporte en todos los navegadores
mayoritarios. La siguiente actualización fue ECMAScript 5.1, (ECMA, 2011).

Estas dos versiones son muy relevantes para este proyecto, ya que la mayoría
dispositivos conectados soportan como máximo estas versiones, limitando los frameworks
que podemos usar en el desarrollo de nuestras aplicaciones.

A partir de este punto, el comité de ECMA decidió publicar versiones anuales con las
nuevas características del lenguaje, dinamizando todo el ecosistema de frameworks
existente.

ECMAScript 6, liberada en 2015 (ECMA, 2015) incluye por primera vez en mucho
tiempo grandes cambios sobre el lenguaje, como el uso de funciones lambda con las “fat
arrow functions”, y la introducción de las “promises” para mejorar la legibilidad del código
asíncrono, así como de las clases y otras muchas características.

ECMAScript 7 (ECMA, 2016) y 8 (ECMA, 2017) han sido publicados como borradores
y continúan introduciendo un subconjunto de mejoras que poco a poco se están viendo
implementadas en los intérpretes JS.

Es también importante detenernos en los proyectos basados en JS fuera del navegador.

El primero de ellos fue CouchDB, una base de datos que usa el formato JSON para
almacenar las entidades y JavaScript para hacer operaciones map y reduce.

En 2009 se liberó la primera versión de Node.js, y con ella llegó la revolución de

JavaScript. Node.js usa el intérprete de JavaScript de Google (V8), y lo extiende siguiendo

75
la especificación CommonJS, creada para permitir usar JavaScript fuera de los
navegadores, extendiendo el lenguaje con mecanismos de lectura y escritura desde disco,
buffers de bytes, manejo de sockets, organización del código en módulos, etc.

Node.js permite que, con un único lenguaje, los desarrolladores puedan programar tanto
las aplicaciones cliente en los navegadores, como los servicios en los servidores, lo cual ha
hecho que JavaScript se convierta en el lenguaje mayoritario con un uso exponencial, como
vimos en la introducción.

En la siguiente figura podemos observar una línea de tiempo con los eventos más
relevantes en el desarrollo del estándar ECMAScript:

Mocha. JavaScript. ECMAScript ECMAScript ECMAScript

Netscape, Netscape, v1. ECMA, v3. ECMA, 5. ECMA,
1995 1995 1997 1999 2009

LiveScript. JScript. ECMAScript ECMAScript ECMAScript

Netscape, Microsoft, v2. ECMA, v3.1 & v5. 5.1. ECMA,
1995 1996 1998 ECMA, 2008 2011

Figura 5.3: Línea de tiempo estándar ECMAScript.

5.3.2 JavaScript en dispositivos conectados

Como hemos visto en el punto anterior, en estos 20 años de JavaScript el lenguaje ha
ido evolucionando de forma muy irregular, con periodos completamente en blanco, y a
partir del año 2011, con el lanzamiento de ECMAScript 5.1, la introducción de versiones
más regulares contando con una nueva del estándar por año a partir del 2015 con la
liberación de ECMAScript 6.

El desarrollo de las Smart TV y los dispositivos conectados empieza a surgir entre 2011
y 2012, justo con la aparición de la versión ECMAScript 5.1.

Por este motivo, y dada la base de dispositivos que actualmente están en los hogares de
los usuarios, esta versión es la que tenemos que usar como referencia, aunque podamos
encontrarnos con bastantes problemas durante el desarrollo, ya que las implantaciones son
irregulares.

La realidad es que varios de los fabricantes no han implementado todas las características
de la versión 5.1 del estándar en sus dispositivos, sobre todo cuando hacemos referencia a
los dispositivos conectados. Esto hace que debamos de adoptar estrategias defensivas a la
hora de afrontar un desarrollo sobre los mismos, como puede ser el uso de librerías que

76
provean de polyfills, es decir, implementaciones software de las especificaciones para
soportarlas en dispositivos antiguos, y ceñirnos a las versiones menos actuales del estándar.

Con el desarrollo de los nuevos estándares y viendo que aportan nuevas estructuras de
sintaxis que clarifican mucho el código, han aparecido proyectos como BabelJS que
permiten transpilar el código de versiones superiores del estándar a inferiores, pudiendo
elegir sobre que versión de JavaScript queremos ejecutar el código.

Los últimos dispositivos tienden a implementar las nuevas especificaciones, e incluso en

algunos casos, como puede ser en LG, han incluido intérpretes de Node.js en las televisiones
para que se puedan realizar servicios muy complejos ejecutándose de forma oculta al
usuario.

Teniendo en cuenta todas las dificultades (dispositivos sobre los que queremos
desarrollar, limitaciones de los mismos y herramientas existentes) podremos hacer un
análisis y seleccionar el mejor camino para implementar nuestra aplicación.

5.4 Frameworks JS
Como hemos visto, el ecosistema de JavaScript está salpicado de multitud de proyectos,
herramientas y frameworks que nos pueden ayudar en el desarrollo de nuestras aplicaciones.

En el caso de desarrollo de aplicaciones de vídeo es difícil poder decantarse por un

framework en detrimento de otro, ya que normalmente cada uno cubre unas necesidades
muy específicas, que pueden no ser las que nosotros vamos a necesitar.

A partir del análisis previo que hemos realizado sobre las aplicaciones de vídeo bajo
demanda, los dispositivos conectados y Smart TV, así como las particularidades del
lenguaje, tendremos que constatar cuales de los siguientes puntos cumplen los frameworks
que vamos a analizar:

• Soporte para versiones antiguas de JS.

• Soporte para manejar el foco.

• Soporte para manejar eventos de dispositivos de entrada.

• Capacidad de crear componentes visuales reutilizables.

• Abstracción de los APIs privativos de los distintos dispositivos.

• Comunidad de desarrolladores.

Versiones de JavaScript soportadas

JavaScript es un lenguaje que está en una constante evolución. Estos continuos cambios
son un poco contrarios a la naturaleza de los dispositivos conectados, ya que raras veces

77
los fabricantes actualizan los navegadores que llevan integrados, impidiendo el uso de todas
las facilidades que nos otorgan las sucesivas evoluciones del lenguaje. Por ello es importante
que el framework funcione al menos con versiones de ES5, o que se pueda transpirar el
mismo a dicha versión.

Manejo de foco

Como hemos visto el manejo del foco es un problema no trivial al que nos vamos a
enfrentar. Analizaremos si el framework es capaz de manejar de forma automática dicho
foco, o si en el caso contrario es posible implementarlo apoyándonos en la arquitectura que
este nos expone. Un punto a favor en este escenario es la inclusión de Virtual DOM, ya
que nos permite manipular el código HTML desde JavaScript.

Eventos de dispositivos de entrada

JavaScript es un lenguaje muy eventual, de forma que analizaremos si el framework es

capaz de manejar los eventos de forma nativa, o si por el contrario deberemos de
implementar en la librería de abstracción de hardware los eventos que producen los
distintos dispositivos accesorios de entrada.

Creación de componentes

Dado que las aplicaciones OTT son muy visuales y dichos elementos suelen ser
constantes, he evaluado si el framework permite generar componentes para que sean
reutilizados de una forma sencilla.

Abstracción de hardware de dispositivos

Como hemos visto, el mundo de los dispositivos conectados está altamente fragmentado
a nivel de capacidades y APIs soportados. Una correcta abstracción de dispositivos facilita
el desarrollo de las aplicaciones, ya que nos permite centrarnos simplemente en la parte
más visual y no en tener que consumir APIs distintos cada vez que queramos realizar una
acción común en múltiples dispositivos.

Comunidad

Actualmente JS es un lenguaje con una gran comunidad detrás que sigue muy de cerca
y de forma muy proactiva todas las novedades que nacen alrededor del mismo.

Disponer de una comunidad es muy ventajoso para poder reusar componentes o código.

78
 Siguiendo estos criterios he analizado los siguientes frameworks: React.js, Angular.js 1.x
y TAL BBC.

React.js

He decidido analizar React.js, ya que actualmente es uno de los frameworks más

utilizados para hacer aplicaciones web, y posiblemente el que ha tenido un crecimiento de
usuarios más pronunciado en los últimos años.

React.js ha sido desarrollado por Facebook para agilizar la creación de los interfaces
gráficos, de forma que este framework se encarga puramente de la composición de las vistas
de las aplicaciones web.

Este framework requiere al menos un intérprete que soporte ECMAScript 5, pudiendo

usar polyfills si queremos ejecutarlo en navegadores más antiguos.

A nivel de gestión de foco, el framework no lo soporta por defecto ni hay módulos

disponibles que nos simplifiquen la tarea. React.js gestiona el renderizado de los
componentes mediante un VDOM (Virtual DOM por sus siglas en inglés), de forma que
no es imposible gestionar el foco de forma automática desde el código, pero requeriría
implementarlo de cero.

No soporta por defecto la gestión de otro dispositivo de entrada que no sea un ratón.

La abstracción de hardware es posible, pero al ser un framework generalista no hay nada

implementado y todo depende de nosotros, al igual que con los dispositivos de entrada.

Su comunidad es muy activa y entusiasta, podemos encontrar multitud de módulos en

NPM incluyendo patrones de rutas, componentes visuales, etc.

Angular.js 1.x

Fue posiblemente el primer framework que implemento el patrón Modelo Vista

Controlador (Model View Controller, MVC por sus siglas en inglés) con una gran acogida
dentro de la comunidad JS.

Actualmente existe una versión de Angular.js basada en TypeScript, que he obviado por
los posibles problemas que nos podemos encontrar al transpilar el código de este lenguaje
a JavaScript.

Angular.js ha sido desarrollado y es mantenido por Google. Incluye muy buenas ideas
como es el uso de plantillas (templates en inglés) para crear las distintas partes de la
aplicación y conceptos de la programación reactiva, gracias a los objetos observables y el
data-binding. Esto permite que, si dentro de una plantilla estamos usando un objeto y este

79
cambia, veamos reflejada la variación sin tener que escribir la lógica necesaria para escuchar
los cambios en el objeto para reaccionar cuando esto sucede, y así poder modificar la vista.

Angular.js necesita ES5 al igual que React.js.

Permite crear componentes mediante sus directivas, existiendo repositorios públicos y

multitud de módulos listos para ser usados.

Cuando analizamos como podemos usarlo en aplicaciones sobre dispositivos conectados

nos encontramos que realmente es difícil gestionar el foco, ya que el framework no tiene un
VDOM y esto complica la implementación del mismo.

No está preparado para gestionar dispositivos de entrada distintos al ratón.

La abstracción de dispositivos, al igual que en React.js es posible y fácilmente integrable,

pero al no ser un framework pensado para ser utilizado con los dispositivos conectados,
costaría mucho trabajo al tener que implementar esta abstracción de cero.

TAL

TAL (TV Application Layer) es un framework desarrollado por la cadena BBC para
crear sus aplicaciones de vídeo en dispositivos conectados.

Dado que es un framework orientado a ser compatible con el mayor número de

dispositivos posibles, soporta dispositivos con versiones anteriores a ECMAScript 5, pero
esto hace que no podamos usar la sintaxis nueva que nos ofrece el lenguaje.

TAL es un framework basado en componentes los cuales deben de incluir en su código

la representación visual y la lógica necesaria para reaccionar a las acciones de los usuarios.
Además, está pensado para facilitar la composición de pantallas, pudiendo crear las mismas
a partir de múltiples componentes.

Además, nos ofrece componentes “tontos” que tienen una relación uno a uno con los
elementos visuales. Son conocidos como widgets y nos permiten organizar jerárquicamente
nuestras aplicaciones de una forma visual, simplificando aún más la gestión del foco.

En relación a las capacidades de los dispositivos conectados que el resto de frameworks

no soporta, TAL incluye por defecto gestión de los eventos de los mandos a distancia.

Igualmente, como ya he mencionad, la gestión del foco es un punto que hace que nos
decantemos por este framework, ya que sus widgets la soportan por defecto. Además, se
incluye un Virtual DOM que nos permite aplicar patrones modernos siempre que lo
requiramos.

80
 La comunidad es casi inexistente si lo comparamos con los otros dos frameworks
analizados, por tanto, no existen casi aportaciones fuera del repositorio original y la
documentación, aunque bastante completa, no se detiene en explicar en profundidad todas
las capacidades que nos ofrece.

5.5 Conclusiones
Como hemos visto, JavaScript y el ecosistema que lo rodea es muy activo e interesante,
con una trayectoria un tanto irregular, pero con una comunidad impresionante que hace
que este lenguaje tenga mucho futuro por delante.

Si ponemos nuestro objetivo en los dispositivos conectados, hemos visto que las
decisiones de los fabricantes respecto a las versiones implementadas del estándar y los APIs
privados implementados para dar acceso a todo el hardware, nos van a suponer más de un
quebradero de cabeza cuando afrontemos el desarrollo de aplicaciones de vídeo en
streaming.

Lo más importante es que podemos partir de una base común para una gran cantidad
de dispositivos, pudiendo llegar a un mayor número de usuarios, y poco a poco expandir la
aplicación según nuestras necesidades.

A la hora de enfrentarnos a un nuevo desarrollo, lo más inmediato es usar el framework

TAL de BBC, ya que nos aporta todos los ingredientes necesarios para poder ver resultados
en el menor tiempo posible.

En el análisis del framework y el desarrollo de la aplicación de este proyecto repasaremos

todas las virtudes y asperezas que tiene TAL desde mi punto de vista, intentando potenciar
sus puntos fuertes y limar los negativos. De esta forma intentaré crear una aplicación lo
más útil posible.

81
82
 6 Análisis TAL BBC
Como hemos visto en el análisis de las distintas soluciones basadas en JavaScript, TAL
BBC es el framework que cumple con más requisitos para poder ser usado en nuestras
aplicaciones de vídeo.

A lo largo de este análisis repasaré todas las piezas que componen esta herramienta,
mostrando los puntos de interés a la hora de entenderla.

En la siguiente figura podemos ver cómo se organiza el framework a nivel interno, y

como hacemos uso del mismo desde las aplicaciones:

Compon
Badges Input API Image Views
App App ents Modulos de
Application App
Layer
Custom Integrations
Logic Aplicación
Widgets
l18n etc Label etc Utils etc

List Grid requirejs css Button Image

Framework Framework Framework
Navigation Basic Basic
Widgets Widgets Widgets
Carousel etc cache etc Label etc
Componentes de
Framework TAL
Layer
device documen
Storage Network Logger Player DRM
HW Device objects t type
Abstraction Specific
Layer HTTP Key Animatio App mimetyp depende
Broadcast ID
Requests Events ns e ncies

Devices

NodeJS Server
Game
Smart TVs Browsers STB Sticks
Consoles

Figura 6.1: Arquitectura TAL.

Como podemos observar, gracias a como se compone esta herramienta, podemos

construir una aplicación sobre la misma y acceder a todas las capacidades de los dispositivos
sin la necesidad de conocer cómo se comportan o como se accede a las mismas. Además
podemos sobrescribir gran parte de la funcionalidad de TAL en el contexto de aplicación,
lo que nos permite extender al mismo sin romper el principio de separación de
responsabilidades.

83
6.1 Fundamentos TAL
Como vimos en el diagrama de la introducción, TAL está compuesto por muchas piezas,
pero además de estos componentes, debemos de tener en cuenta las convenciones y patrones
que son utilizados, ya que intentaré no salirme de los mismos a la hora de crear la
aplicación.

Las bases sobre las que se construye TAL son las siguientes: patrón AMD, patrón de
composición, uso de componentes y widgets, y, para terminar, el patrón facade para la
abstracción del hardware de los dispositivos. Todos los patrones pueden ser consultados en
el libro (Osmani, Learning Javascript Design Patterns, 2012).

6.1.1 Módulos
JavaScript en los navegadores, y por consiguiente en los dispositivos conectados, tiene
ciertas limitaciones para cargar ficheros de script de forma remota.

Dichos ficheros se cargan mediante la etiqueta HTML script. A partir de ese momento
el navegador descarga los archivos, el intérprete JavaScript lo procesa, descartando
ficheros, verificando si la sintaxis es correcta y segura, optimizando las instrucciones, y
finalmente ejecutando el código.

Al no existir una separación en librerías de código, por defecto el intérprete pondrá todas
las variables en el espacio de nombres global. Esto hace que sea necesario usar algún patrón
que nos permita separar nuestro código en módulos, de forma que no encontremos colisiones
entre los mismos.

Existen varias formas de solucionar este problema, como es aplicar cualquiera de los
patrones módulo que podemos encontrar en el libro (Osmani, Learning Javascript Design
Patterns, 2012).

TAL usa la librería Require.js, que implementa el patrón de definición de módulos

asíncronos (Asynchronous Module Definition, AMD por sus siglas en inglés), y que permite
separar el código en ficheros individuales que pueden ser cargados de forma asíncrona.

Require.js necesita que la librería se cargue en el documento, siendo opcional definir una
configuración para la misma y un punto de entrada a la aplicación.

Los módulos deben de estar encapsulados dentro de la palabra reservada “define” por la
librería, o por el método require.def de la misma.

84
 Cada módulo cuenta con las siguientes partes

• Nombre Opcional. Cadena de texto que debe que coincidir con la ruta
usada para cargarlo

• Dependencias Opcional. Array de cadenas de texto con las dependencias que

queremos cargar

• Módulo Obligatorio. Puede ser un objeto válido JavaScript o una

función que instancia las dependencias como parámetros. Esta función debe de
retornar cualquier valor valido de JavaScript, que será el módulo instanciado.

En la siguiente figura podemos ver los distintos modos de los que disponemos para
instanciar los módulos:
/**
* confA module.
* Object module without name
*/
define({foo: 'bar'});
/**
* confB module.
* Object module with name
*/
define('confB',{foo: 'bar'});
/**
* confC module.
* Function module with name
*/
define('confC', function (){
return {foo: 'bar'};
});
/**
* confD module.
* Function module with name and dependencies
*/
define('confD', ['confB'], function (confB){
return confB;
});
Figura 6.2: Definición módulos Require.js

Como hemos visto, podemos definir las dependencias dentro de cada módulo, si usamos
una función para poder instanciarlas y hacer uso de ellas.

Require.js permite cargar módulos mediante la función “require”. Esta función puede ser
usada de dos formas, la primera para cargar dependencias de cero, y la segunda para
recuperar las instancias que la librería ha cargado previamente.

85
 En el siguiente ejemplo vemos como se cargan dependencias de cero. Como parámetros
la función “require” espera un array de dependencias y de una función que tiene como
argumentos las instancias de las mismas:
/**
* Require modules directly
*/
require([
'confA',
'confB'
], function (
confA,
confB
){
// operate with dependencies
}

Figura 6.3: Carga de módulos directa

La segunda forma de usar la función “require” es pasando como parámetro le nombre

del módulo a recuperar, de forma que el resultado lo podamos asignar a una variable. En
el siguiente ejemplo podemos ver su uso:
/**
* get module instance
*/
var confA = require(‘confA’);
Figura 6.4: Recuperar instancia de módulo

Require.js es una librería más extensa que permite modificar el comportamiento de la

misma, usar extensiones para cargar otro tipo de ficheros y crear atajos para acceder a los
módulos. (Require.js, 2017).

6.1.2 Composición
TAL provee su propio mecanismo de composición, que junto con los módulos AMD de
Require.js, otorga al framework las herramientas necesarias para que podamos separar
nuestros módulos en unidades lógicas bien aisladas, permitiendo eliminar la redundancia
de código (patrón Don’t Repeat Yourself, DRY por sus siglas en inglés).

TAL ofrece el módulo “antie/class”, que devuelve una pseudo-clase, implementando un

modelo de herencia basado en el de programación orientada a objetos tradicional.

86
 Estas clases además incluyen un constructor, que en el caso de TAL tiene un nombre
fijo “init”. Dicho constructor se llama cuando ejecutamos la pseudo-clase con la palabra
reservada “new”, ejecutándose solo en ese momento.

El patrón de composición lo ofrece el método “extend”, el cual obtiene como único

parámetro un objeto JavaScript con los atributos y las funciones que queremos agregar.

En el caso de que el método exista en la clase superior, este será sobrescrito, y podremos
invocarlo con la palabra reservada “super”.

En la siguiente figura podemos ver cómo podemos crear una clase a partir de
“antie/class”, cómo podemos extenderla y finalmente cómo llamar a los métodos propios y
los de la clase superior:
// defines a class
define('myClass', ['antie/class'], function (Class){
return Class.extend({
init: function () {
// call the parent init function
this._super();
},
myMethod: function (bar, foo) {
return bar + foo;
}
});
});
// defines a subclass
define('mySubClass', ['myClass'], function (MyClass) {
return MyClass.extend({
myMethod: function (bar, foo, poo) {
// overrides the parents method behaviour
return 'salt' + poo;
}
})
});
// load the dependencie, create a instance of the class
// and calls the myMethod method
require(['mySubClass'], function(MySubClass){
var mySubClass = new MySubClass();
mySubClass.myMethod(1,2,3); // outputs 'salt3'
});

Figura 6.5: Herencia y sobre escritura.

87
 Todo TAL está construido siguiendo esta arquitectura. En la siguiente figura podemos
ver los grupos de módulos de primer orden que heredan de “antie/class”:

Figura 6.6: Herencia de primer nivel

Devices

Los módulos que se encuentran agrupados en este directorio se relacionan de forma

directa con la clase “antie/device”.

Incluye las distintas estrategias de animación, el acceso al almacenamiento del

dispositivo, reproducción de vídeo y gestión de exit.

RuntimeContext

Super clase que contiene la aplicación actual y el dispositivo que nos abstrae del
hardware dándonos acceso al almacenamiento y otros subsistemas. En el punto 6.1.7 los
mismos.

Application

Aplicación TAL en ejecución.

Widgets

Todos los widgets y sus composiciones

Others

Implementación de patrones, módulos sin relación entre sí, fuentes de datos, etc.

88
6.1.3 Widgets
Los widgets en TAL son la base de organización visual/lógica más básica, aunque pueden
obtener una gran complejidad como veremos.

Estos widgets normalmente se comportan como elementos “tontos”, es decir, aunque

puedan almacenar su propio estado y reaccionar ante los distintos eventos que el framework
eleva cuando el usuario interactúa con la aplicación, no deben tomar decisiones complejas
más allá de gestionar el foco en el caso de que puedan y elevar eventos si se cumple alguna
condición.

Casi todos los widgets heredan sus métodos de “antie/widgets/widget”, siendo de especial
relevancia los métodos “setDataItem” y “getDataItem”, que nos permiten almacenar un
objeto JavaScript en él. Dicho objeto podremos recuperarlo en los eventos que disparan los
widgets, ampliando la versatilidad del framework.

Podemos clasificar los widgets en las siguientes categorías: organizativos, básicos y

avanzados.

Widgets organizativos

Estos widgets nos facilitan la creación de las vistas, dándonos una jerarquía y navegación
automática. TAL nos ofrece listas y contenedores. Los métodos que exponen suelen ser
relativos a agregación y eliminación de hijos, para poder construir la jerarquía antes
mencionada.

Las listas pueden ser horizontales y verticales, y ellas mismas se encargan de gestionar
el foco si reciben un evento de teclado.

Jugando con los distintos widgets seremos capaces de crear aplicaciones completas.

Widgets básicos

Los botones, imágenes, textos o barras de progreso nos permiten agregar funcionalidad
básica a la aplicación, como puede ser mostrar texto e imágenes o escuchar eventos cuando
un usuario selecciona un botón. Todos incluyen métodos que nos permiten modificar su
apariencia en tiempo de ejecución y no solo desde el constructor.

Widgets avanzados

Los widgets que hemos visto anteriormente son, desde un punto de vista lógico, estáticos.
Podemos agregar y eliminar a sus hijos, pero están orientados a ser posicionados en la
pantalla y modificar sus valores, no a sus descendientes.

89
 Cuando desarrollamos aplicaciones de vídeo en línea los datos los obtenemos de internet,
así que no los conocemos con antelación.

Los widgets avanzados son puntos fijos de las vistas que proporcionan mecanismos para,
una vez que hemos obtenido los datos dinámicos, facilitar la creación de los hijos,
agregándolos de forma automática.

Los carruseles de TAL nos ofrecen toda esta funcionalidad, como podemos ver en la
aplicación de ejemplo.

Composición de widgets

Si con los widgets con los que nos provee el framework no son suficientes siempre
podemos componerlos de forma que se ajusten a nuestras necesidades. Un caso típico sería
una portada de una película, a la que podemos agregar un botón, una imagen y un texto.
De esta forma no habrá caso que no esté cubierto por TAL.

6.1.4 Componentes
Los componentes en TAL son un caso especial de widget que se encarga de controlar el
ciclo de vida de la aplicación.

Muchas veces es difícil distinguir dónde está la diferencia entre un widget y un

componente. La forma más sencilla es ver si las acciones del usuario impactan en el ciclo
de vida de la aplicación o en múltiples al mismo tiempo. De ser así estamos hablando de
un componente.

Los componentes se encuentran en el módulo “antie/widgets/component”. Heredan de

“antie/widgets/container” y éste a su vez de “antie/widgets/widget”.

Tienen una relación uno a uno con los Component Containers, ya que es el punto de
anclaje donde se introducen y es quien gestiona la apertura, cierre e historia de los mismos.

Los componentes son los encargados de crear y agregar los distintos widgets que
formarán nuestra aplicación, así como escuchar a los eventos de los usuarios para que estos
puedan interactuar con la misma.

En la siguiente figura vemos el ciclo de vida de un componente, en el cual observamos

los métodos que son ejecutados directamente como “init” o “getCurrentState”, o eventos que
reciben el contexto pasado al Component Container cuando lo abrimos:

90
 Component
show

init()

load event

beforerender
Antes de que el
event
usuario tenga el
control
beforeshow
event
container.back()

aftershow
event

Container Component
history stack running

Un componente
nuevo entra en el
Component
Container

beforehide
getCurrentState()
event
Después de la
afterhide acción de usuario
event

Component
shut down
Figura 6.7: Ciclo de vida de un componente

TAL no especifica para qué debe de ser usado cada evento, así que propongo la siguiente
organización del código aprovechándonos de este ciclo de vida:

91
 Método init

Es el constructor del componente. Se ejecuta una única vez, por lo que es interesante
para realizar acciones que deban de perdurar durante todo el ciclo de vida del componente,
como asignar un contexto de ejecución a las funciones de callback.

Evento load

Evento que es lanzado cuando se carga el módulo por primera vez. Puede ser usado para
construir la vista. Al ser un evento del ciclo de vida del componente, dentro del mismo
recibimos los argumentos que se le han pasado. Dichos argumentos pueden ser utilizados
para configurar la vista según nuestras necesidades.

Evento beforerender

Este evento es lanzado antes de que los widgets llamen al método “render”, en el cual
obtenemos el DOM real que es agregado a la página web. Por este motivo no podemos
ejecutar funciones que intenten manipular el DOM. Podemos usar este evento para
configurar los listeners sobre los widgets.

Evento afterender

Este evento es disparado inmediatamente después de que la vista esté disponible.

Podemos usarlo para configurar los widgets, ya que ahora no darán error.

Si tenemos que realizar llamadas asíncronas basándonos en el contexto que recibimos

dentro del evento, es un buen lugar para lanzarlas y capturar todos los posibles resultados.

Evento aftershow

En este punto tenemos la vista disponible y el DOM está en la página web. En este
punto podemos manipular nuestros widgets incluso con métodos que manipulen el DOM.

Evento beforehide

Evento que debe de eliminar los listeners previamente puestos a escuchar.

Evento afterhide

Evento en el que podemos resetear la vista en caso de ser necesario.

92
 Método getCurrentState

El objeto que retornemos en este método estará disponible si hacemos back dentro del
contexto del componente. Interesante si queremos hacer reset al estado del componente y
guardar solo la información imprescindible, ya que podemos ahorrar memoria con el
proceso.

6.1.5 Composición de pantallas

Gracias a los principios que hemos visto en los puntos anteriores, sobre todo a los
componentes y los widgets, se pueden crear distintas pantallas mediante la agrupación de
estos elementos.

TAL BBC nos ofrece distintos tipos de widget a la hora de componer las pantallas, pero
como hemos visto, si queremos tener un control del histórico de nuestra aplicación, debemos
de tener una relación uno a uno entre los component container y los componentes.

En la siguiente figura podemos ver como a partir de un contenedor principal, podemos

agregar distintos hijos, ya sean widgets o subcomponentes, y tener un árbol virtual con
todos los componentes que conforman nuestra aplicación:

Figura 6.8: TAL Composición de pantallas

93
6.1.6 Navegación y gestión de foco automática
Una de las características que hizo que me decantara por TAL es la gestión de foco que
incorpora gracias al uso de un VDOM y de una estrategia de propagación del foco muy
eficiente.

La gestión del foco y la navegación son componentes independientes, pero están

íntimamente relacionados.

En un primer lugar tenemos la gestión del foco. Los botones son los únicos widgets
capaces de obtener el foco. Cuando ponemos el foco en un botón, el widget notifica a la
aplicación de que va a obtener el foco. El contexto de aplicación entonces quitara el foco
al widget anterior en el caso de existir agregándose la clase CSS focus al nuevo widget.

La navegación automática consiste en un proceso de captura de eventos de teclado junto

con la estrategia de gestión de foco anteriormente descrita.

En la siguiente figura podemos ver un árbol de widgets, en este caso tendremos una lista
horizontal que contiene cuatro botones como hijos, estando el último en posesión del foco:

Figura 6.9: TAL Gestion del foco

Las acciones que ocurren son las siguiente:

1. Recibimos el evento elevado por pulsar la tecla izquierda. Como el ítem no tiene
más hijos y no puede gestionar por si mismo el evento, lo eleva a su padre.

2. La lista horizontal recibe el evento.

3. La lista horizontal puede gestionar los botones derecho e izquierdo. En este punto
consultara a sus hijos para ver si alguno de ellos puede obtener el foco

4. Al encontrar que el ítem anterior al que poseía el foco puede obtenerlo, se lo

asigna, parando el evento y quedando el foco asignado al tercer ítem.

De esta forma TAL permite gestionar el foco de forma automática, permitiéndonos

construir aplicaciones con los widgets disponibles que ofrezcan una navegación automática.

94
6.1.7 Dispositivo
La abstracción del dispositivo solo puede ser accedida desde el módulo RuntimeContext:
var runtimeContext = require('antie/runtimecontext');
var device = runtimeContext.getDevice();

Figura 6.10: Obtención del dispositivo.

Una vez que hemos recuperado la instancia del mismo, podemos acceder entre otros, a
los siguientes subsistemas:

Storage

Gracias a este subsistema podemos disponer de almacenamiento persistente o de un

espacio común a toda la aplicación en el que compartir datos.

Internamente cada dispositivo escoge la estrategia de almacenamiento persistente, ya

sea usando cookies, el objeto LocalStorage o APIs privados.

En la siguiente figura podemos ver como recuperamos el almacenamiento persistente:

var storageProvider = require('antie/storageprovider');
var type = StorageProvider.STORAGE_TYPE_PERSISTENT;
var namespace = 'ns';
var opts = {};
var storage = device.getStorage(type, namespace, opts);
storage.setItem('key', 'value');
storage.getItem('key'); // gets 'value'

Figura 6.11: Almacenamiento persistente

XMLHttpRequest

Desde el dispositivo podemos acceder directamente al método “loadURL”, al que le

podemos pasar como parámetros dos funciones de callback dentro de un objeto, una en el
caso de que la petición se resuelva bien y otra para el caso contrario.

En la siguiente figura podemos ver como se realizan las llamadas y gestionan los callback:
var handlers = {
onLoad: function(response){
console.log('okcb '+response);
},
onError: function (response){
console.log('nokcb '+response);
}
};
device.loadURL('https://httpbin.org/get', handlers); // will log the ok response
device.loadURL('https://httpbin.org/status/400', handlers); // will log the nok
Figura 6.12: XHR

95
 Media

Una vez que accedemos al objeto media, podemos iniciar la reproducción del contenido.
Hay que prestar especial atención a como se reproduce.

En el siguiente ejemplo observamos como recuperamos el objeto media player e

inicializamos la reproducción, especificando todos los parámetros necesarios:

var runtimeContext = require('antie/runtimecontext');

var MediaPlayer = require('antie/devices/mediaplayer/mediaplayer');
var device = runtimeContext.getDevice();
var mediaPlayer = device.getMediaplayer();
var type = MediaPlayer.TYPE.VIDEO; // or LIVE
var url = 'url/to/video';
var mimetype = 'mimetype';
mediaPlayer.setSource(type, url, mimetype);
mediaPlayer.beginPlayback();
Figura 6.13: Reproducción de contenido.

Config

Desde el subsistema de configuración tenemos la posibilidad de acceder a todos los

parámetros que se han cargado para un dispositivo dado. De esta forma podemos, desde el
contexto de aplicación, saber de una forma directa en qué dispositivo nos encontramos y
las capacidades del mismo.

6.2 Problemas detectados

Después de analizar el framework para poder plantear la aplicación de ejemplo que
acompañará al generador de aplicaciones he podido detectar lo que considero errores en el
diseño de TAL, aunque en su gran mayoría podremos sortearlos para crear una base de
código lo más limpia posible.

Los problemas detectados son visibles en la aplicación de ejemplo de TAL BBC, así
como cuando empezamos a trabajar con el mismo.

Aplicación de ejemplo no funcional

La aplicación de ejemplo que ofrece TAL BBC no funciona, partes enteras de la misma
están desactualizadas y rompen sin ninguna explicación. Esto hace que empezar a trabajar
con la herramienta sea complicado y tedioso.

96
 Código susceptible a errores

Este punto puede parecer poco importante o que saca a la luz malas prácticas por parte
del desarrollador, pero no es así.

El problema con TAL es que los métodos que expone, así como la gestión de los eventos,
no es siempre clara. Esto junto a que el framework tiende a ocultar los errores en tiempo
de ejecución, hace que sea complicado el darse cuenta de donde se están cometiendo los
errores de implementación.

Separación entre contexto de framework y de aplicación

El primer problema que he notado es que no existe una separación clara entre el contexto
de TAL y el contexto de aplicación, ya que podemos encontrar dependencias dentro de las
definiciones de los dispositivos a la estructura de directorios de la aplicación. Un framework
debería de estar auto contenido, permitiendo ser configurado mediante ficheros creados
para tal efecto, pero en ningún caso debería de forzar una estructura determinada de la
aplicación.

Dependencias poco actualizadas

Las dependencias en las que se basa el framework están totalmente desactualizadas,

como es el caso de Require.js. Esto hace que buscar documentación o intentar ceñirse a la
existente sea contraproducente. Un caso muy evidente es la gestión de errores de la librería
Require.js cuando cargamos módulos de forma programática, que ha cambiado
completamente de una versión a otra.

Auto detección de dispositivos

Respecto al soporte de múltiples dispositivos, TAL no soporta la auto detección de los

mismos, de forma que hay que especificar qué dependencias quiere que cargue.

Peticiones XHR

El subsistema de peticiones XHR es incorrecto, ya que la respuesta que recibimos desde

la aplicación es imcompleta y no podemos, por ejemplo, acceder a los headers que responde
el servidor.

97
 Creación de vistas

A lo largo del análisis he puesto el foco en las facilidades que nos da TAL respecto a la
composición de pantallas y la navegación automática. La realidad es que si queremos
obtener todos los beneficios debemos de agregar muchas capas a dichas pantallas,
entorpeciendo el desarrollo y haciendo difícil el poder abstraerse para poder pensar en el
VDOM que nos ofrece el framework.

Versión de ECMAScript

Todo el código está escrito siguiendo el estándar ECMAScript v3 garantizando la

compatibilidad con el mayor número de dispositivos posible, pero no se han incluido
librerías que nos permitan usar las novedades en esta versión del estándar, ralentizando en
parte el desarrollo.

6.3 Conclusiones
El equipo de desarrolladores de BBC ha realizado un gran trabajo con TAL, ofreciendo
una base de código clara y bien documentada. Usando patrones de desarrollo bien conocidos
e intentado hacer lo más accesible posible su herramienta.

La solución que ofrecen para organizar las vistas y navegación de nuestra aplicación
mediante widgets es muy elegante y sofisticada, los componentes y su ciclo de vida permiten
estructurar nuestro código de una forma limpia aun sin ser un framework MVC.

La abstracción del hardware de los dispositivos que ofrece es suficiente, permitiéndonos

hacer uso de todas las capacidades, incluyendo las animaciones. El punto negativo
relacionado con esta parte es que no soporta DRM. Llegado el caso podríamos modificar el
módulo.

Para concluir creo que con TAL BBC se pueden hacer aplicaciones de una complejidad
media o baja, pero es suficiente para iniciarse en el mundo del desarrollo de aplicaciones
de vídeo en streaming.

98
7 Aplicación - Generador Yeoman TAL
Ahora que entendemos el complicado ecosistema de las aplicaciones OTT vamos a
analizar un posible entorno de desarrollo para poder afrontar los retos que se nos plantean
de una forma más sencilla, mejorándolo en los puntos que considero más críticos.

7.1 Retos
Los retos que nos encontramos cuando queremos empezar a desarrollar una aplicación
en cualquier lenguaje y framework nuevo son comunes y se pueden resumir en: accesibilidad
de la documentación, estructura definida de código y aplicaciones de ejemplo.

A raíz de los problemas detectados con el framework voy a solucionar los relacionados
con los siguientes puntos: estructura y código de ejemplo:

7.1.1 Estructura
El primer paso que debemos dar es entender bien como tenemos que estructurar el
código, ya que si somos capaces de visualizar donde debemos de colocar cada una de las
piezas que conforman nuestra aplicación, será más fácil crear un código sencillo de mantener
y escalable en el tiempo.

La aplicación entregable está basada en Yeoman, un generador de código muy activo en

la comunidad JavaScript. La idea detrás de esta implementación es que un desarrollador
sin conocimiento no tenga que perder el tiempo pensando cual es la mejor manera de
organizar su código, pudiendo empezar a trabajar en cuestión de minutos al encargarse la
herramienta de instalar todas las dependencias necesarias.

7.1.2 Código de ejemplo

Desde mi punto de vista, es muy importante que un desarrollador disponga siempre de
aplicaciones funcionales basadas en el framework elegido, y que estas cubran el mayor
número de casos de uso posibles, siguiendo siempre buenas prácticas de programación e
incluyendo la documentación necesaria para poder entender el flujo del código aun sin
conocer en profundidad el framework.

En la aplicación entregable intento seguir estas consignas reinterpretando el ejemplo que

ofrece TAL BBC en su repositorio Git, limpiando el código y separando distintas
funcionalidades en módulos independientes, siendo desde mi punto de vista, más fácil
introducirse en el framework.

99
7.2 Entorno de desarrollo
Para el desarrollo de este proyecto vamos a necesitar un editor de texto, cualquier
navegador moderno, las herramientas de desarrollo incluidas en el navegador, Node.js y
NPM para poder usar módulos ya creados, y Yeoman como director, que gracias al
generador que vamos a desarrollar, se encargará de crear la base para nuestros futuros
proyectos.

En la siguiente figura podemos ver los logos de todos los componentes que forman parte
del entorno de desarrollo:

Figura 7.1: Entorno de desarrollo

En los proximos puntos detallo que aplicaciones y versiones de las mismas he usado, y
por qué recomiendo usar las mismas:

7.2.1 Editor de código

Aunque no es imprescindible usar ninguna herramienta específica que nos ayude a
agilizar el desarrollo, creo que es más que recomendable usar cualquiera de los IDE
modernos de los que disponemos.

Con la popularidad de las aplicaciones web han surgido multitud de editores que
permiten usar herramientas como validadores de código (linters como JSHint o ESLint),
transpiladores (Babel), y procesadores de código que nos permiten minimizar el tamaño del
mismo (Uglify).

Sublime Text fue el primer editor de texto ligero que introdujo nuevos flujos de trabajo,
incluyendo un gestor de dependencias que permite personalizar el editor de una forma
inmediata, ajustando el mismo a las necesidades de cada desarrollador. A su sombra han
aparecido muchos editores que, partiendo de todas las buenas ideas de Sublime, las han

100
ido perfeccionando, incorporando nuevos conceptos o eliminando la necesidad de pasar por
caja para poder hacer un uso legal del editor.

Podemos dividir los editores entre los que son de código abierto y gratuitos, como Atom
de GitHub, Visual Studio Code de Microsoft y Brackets de Adobe; y los que son de código
cerrado y de pago, como Sublime Text 2.x/3.x y WebStorm de Jetbrains. Existen muchos
más editores, pero creo que estos son los más relevantes cuando nos centramos en el
desarrollo web o de JavaScript.

Para este proyecto he usado Visual Studio Code (Microsoft, 2017) de Microsoft, ya que
se integra muy bien con las herramientas que he utilizado; además es libre y gratuito,
soporta extensiones y permite usar los atajos de teclado de Sublime y Emacs, editores de
texto que vengo usando desde 2010.

La versión de Visual Studio Code es 1.13.1.

7.2.2 Navegadores
Dado que las aplicaciones que corren en los dispositivos conectados y las Smart TV no
son más que aplicaciones web maquilladas para que no muestren la barra de herramientas
del mismo, la elección de un buen navegador es imprescindible para poder desempeñar
nuestro trabajo.

Hoy en día todos los navegadores web incluyen herramientas suficientes como para
ayudarnos en el proceso de desarrollo, así que no hay una elección clara al respecto.

Por costumbre yo he usado Google Chrome para realizar este proyecto de fin de carrera,
ya que suelen incorporar, versión tras versión, nuevas capacidades a las herramientas de
desarrollo.

La versión de Google Chrome es 59.0.3071.115.

7.2.3 Herramientas de desarrollo

Las herramientas del desarrollador vienen determinadas por el navegador elegido, así
que en mi caso uso las Chrome Dev Tools, incluidas en Google Chrome.

La importancia de estas herramientas es crítica, ya que nos facilitan un entorno sobre el

cual podemos hacer debug de nuestras aplicaciones, poner puntos de ruptura, analizar el
rendimiento de la aplicación, obtener volcados de la memoria para determinar si existen
fugas, leer la consola de salida o ejecutar código directamente desde la consola habilitada
para estas acciones.

Este último punto es muy importante, ya que desde dicha consola podemos tomar
control de la aplicación si sabemos, por ejemplo, recuperar el contexto de ejecución,
pudiendo modificar el comportamiento de la misma en tiempo real y siendo muy útil para

101
desarrollar nuevas características de nuestras aplicaciones o cerrar un bug que se está
resintiendo o que es difícil de ver.

Otra opción que nos ofrece esta herramienta de desarrollo es la posibilidad de crear
dispositivos virtuales, permitiendo modificar las resoluciones horizontales y verticales, así
como los userAgents. Esto será de especial interés para poder probar que nuestra aplicación
identifica a los dispositivos de forma correcta.

7.2.4 Node.js
Como hemos visto en el análisis de JavaScript, Node.js es un intérprete de este lenguaje
que no requiere de un navegador y que permite hacer operaciones de entrada y salida sobre
la máquina que se ejecuta.

Este proyecto se apoya en Node.js al usar Yeoman como framework de creación de

aplicaciones base.

La versión usada es Node.js v8.0.0, versión estable a la fecha de escribir esta memoria.

7.2.5 NPM
Node Package Manager (NPM por sus siglas en inglés) es una herramienta que nos
permite gestionar las dependencias de nuestros proyectos de una forma sencilla, al generar
un fichero (package.json) que contiene los paquetes instalados. Esto permite aligerar de
una forma considerable el tamaño de los repositorios, ya que solo debemos subir nuestro
código y no el de las dependencias. Además, hace que la tarea de administrar dichas
dependencias en el caso de que tengamos que actualizarlas, sea mucho más sencilla.

NPM es uno de los causantes del éxito de Node.js, ya que existen una cantidad de
paquetes disponibles que cubren casi cualquier necesidad que podamos tener.

La versión usada es NPM v5.0.0, la última en el momento de escribir esta memoria.

7.2.6 TAL
El framework que vamos a usar para desarrollar nuestra aplicación de ejemplo está en
constante desarrollo, incluyendo nuevos dispositivos y modificando la forma en la que se
comporta versión tras versión.

La versión usada en este proyecto es TAL 7.4.3

7.2.7 Gulp
Gulp es una herramienta que permite ejecutar tareas de mantenimiento o procesado de
código, así como lanzar servidores web, etc.

102
 Es interesante, ya que muchos de los módulos que pueden ser usados con ella simplifican
significativamente el flujo de trabajo de los desarrolladores, disminuyendo el tiempo de
configuración y acelerando el de desarrollo.

En este proyecto he usado la versión de Gulp 1.3.0.

7.2.8 Yeoman
Yeoman es un cliente basado en Node.js que facilita la creación de generadores de
aplicaciones.

Lo que nos ofrece esta herramienta es un entorno común para todos los generadores, así
como la posibilidad de buscar los mismos en su página web.

Gracias a los generadores, un usuario que sepa utilizar la herramienta puede, en cuestión
de minutos, empezar a desarrollar aplicaciones usando un framework nuevo, ya que el
generador se encargará de crear todos los ficheros necesarios, instalar las dependencias y
personalizar el proyecto en base a las preguntas que se le hacen al usuario.

Por la inmediatez de uso y lo extendido que está, he decidido usar esta herramienta para
desarrollar un generador TAL, ya que no existe ninguno para dicho framework, y puede
ser una buena oportunidad para acercar el desarrollo de aplicaciones en dispositivos
conectados al público general.

La versión actual del cliente es Yeoman v2.0.0.

7.3 Desarrollo de Generador TAL

Un generador de código está compuesto de dos partes inseparables, por un lado, el código
del generador, que determina el comportamiento del mismo, y por otro, la aplicación que
se usa como base o patrón para crear a partir de la misma.

7.3.1 Generador TAL

En este generador voy a cubrir los casos más simples, como es la creación de una
aplicación base, copiando el código de la aplicación de ejemplo, y personalizando los
distintos componentes con los datos del usuario.

El generador se encargará de instalar las dependencias necesarias y configurar el entorno

del usuario para que sea capaz de ejecutar la misma en el menor tiempo posible.

Para facilitar la ejecución de las aplicaciones he introducido Gulp, anteriormente

mencionado.

El generador se ha construido siguiendo la guía que ofrece la propia comunidad de

Yeoman (Osmani, et al., 2017) así como el generador de ejemplo (Yeoman, 2017).

103
 En el Anexo A podemos ver como configurar el sistema para ejecutar Yeoman junto con
“generator-tal” y así poder crear nuestra primera aplicación.

7.3.2 Aplicación TAL Ejemplo

La aplicación TAL base que planteo debe suplir los defectos que desde mi punto de vista
tiene la aplicación oficial de ejemplo.

Esta aplicación es muy básica, no define buenas prácticas, los espacios de nombre están
ligados al de la aplicación, no es fácil de configurar y no funciona sin modificar el código,
siendo frustrante como aplicación de inicio.

A nivel de librerías la versión de Require.JS incluida y que se usa por defecto es antigua,
no incluye ninguna librería que nos permita usar sintaxis moderna.

Creo que es importante el dar una buena organización a los ficheros, limpiar el código
separando la funcionalidad en los módulos necesarios y cubrir varios casos de uso
incluyendo los wireframes de los mismos.

7.3.2.1 Estructura
La estructura del ejemplo TAL usa como base el código ofrecido por BBC, pero
modificando el mismo para que sea más fácil el desarrollo.

Dado que, como vimos en el análisis del framework, toda la carga de módulos está basada
en Require.js. Gracias a ello he podido modificar los namespaces a mi gusto, simplificando
los mismos, facilitando la legibilidad y accesibilidad de los módulos creados por los usuarios.

Como primera medida he modificado el nombre de los directorios, siguiendo patrones

más actuales, de forma que cualquier desarrollador web sepa dónde deben de alojar según
que ficheros.

En la siguiente estructura podemos ver para que sirve cada directorio:

.
├── src
│ ├── img Imágenes y assets gráficos
│ ├── script Ficheros JS de la aplicación deben de estar
│ │ ├── appui
│ │ ├── components Componentes de aplicación
│ │ ├── config Ficheros JS de configuración
│ │ ├── datasources Módulo usado para obtener datos remotos
│ │ ├── formatters Módulo usado para transformar los datos remotos en widgets
│ │ ├── i18n Internacionalización de la aplicación
│ │ ├── útil Librerías de utilidad creadas en el framework
│ │ └── widgets Widgets propios de la aplicación
│ └── style Directorio con ficheros CSS
│ └── layouts
└── views Vistas de Express.js necesarias para devolver el documento
Figura 7.2: Estructura aplicación TAL Ejemplo

104
7.3.2.2 Aislar funcionalidad
En el ejemplo proporcionado por BBC (BBC, 2016) podemos observar como el
documento HTML que devuelve el servidor Node.js mezcla de una forma nada clara la
configuración de la librería Require.js junto con la configuración del framework y el punto
de entrada a la aplicación.

Como hemos visto en la estructura de la aplicación, hay directorios que no pueden ser
completamente eliminados, ya que TAL necesita leer ficheros desde el contexto de
aplicación para poder inicializarse.

La idea que quiero implementar es simplificar todo lo posible este punto de entrada,
cargando la librería de Require.js como una dependencia de Node.js en vez de TAL BBC
para poder disfrutar de los nuevos flujos que ofrece la librería. Así mismo la configuración
y punto de entrada quedarán fuera de dicho documento.

El objetivo de todos estos cambios es facilitar la lectura del código siguiendo las guías
de estilo que nos dicta la documentación de Require.js.

7.3.2.3 Casos de uso

La aplicación tiene una estructura base que nos permite evolucionarla según nuestras
necesidades.

Todas las pantallas se van a componer a partir de la siguiente figura, que analizo a
continuación:

Figura 7.3: Pantalla base

En esta pantalla podemos apreciar una lista horizontal que contiene dos elementos. El
primero de ellos es una lista vertical a modo de menú, y el segundo es un espacio reservado
para representar los distintos subcomponentes asociados a las opciones del menú.

105
 La vista vertical se configura a partir de un fichero externo. La acción predeterminada
es cargar un componente en la caja habilitada de forma dinámica. De este modo, editando
el fichero de configuración del menú, y añadiendo componentes en su directorio, podemos
evolucionar la aplicación según nuestras necesidades.

El componente padre se encargará de abrir los nuevos componentes en el espacio

reservado para ello.

En los siguientes puntos voy a comentar los casos de uso incluido y su importancia.

Pantalla Identificación de dispositivo

En esta pantalla el subcomponente crea una estructura sencilla no navegable en la que

simplemente visualiza información de interés al usuario en pantalla.

Su relevancia viene por ser la pantalla principal, pudiéndonos fijar en cómo se construyen
las vistas dentro de un componente, así como en las buenas prácticas a la hora de manejar
los estados de componente.

En la siguiente figura podemos ver la apariencia de esta pantalla:

Figura 7.4: Pantalla principal

Pantalla de lista de vídeos

Esta pantalla es interesante ya que muestro como se construyen vistas dinámicas

obteniendo datos remotos. En este subcomponente hago uso del widget carrusel, de uso
avanzado, que puede resultar muy confuso sin un ejemplo claro.

Como detalle final, los elementos son navegables y permiten interactuar con los mismos,
de forma que muestro como se usan los listeners de eventos en TAL y las buenas prácticas
asociadas a los mismos.

106
 En la siguiente figura podemos ver la composición de esta pantalla:

Figura 7.5: Lista de vídeos

Pantalla de detalle de vídeo

A esta pantalla accederemos desde la lista de vídeos. Cobra relevancia ver cómo podemos
pasar datos cuando cambiamos de un componente a otro, lo cual nos permite construir
vistas con los datos que ya disponemos, o pasar identificadores que nos sirven para obtener
los datos relacionados con los mismos.

Además, hacemos uso de el botón atrás, imprescindible para controlar el flujo de

navegación de la aplicación. Este evento utiliza los mecanismos internos del framework,
siendo complicado sin ejemplos.

En la siguiente figura podemos ver la composición de esta pantalla:

Figura 7.6: Detalle de vídeo

107
 Reproductor de vídeo

Finalmente muestro como debe de ser un reproductor de vídeo, enseñando los

controladores del mismo que nos permiten interactuar con la reproducción.

Es interesante ver como se tratan los eventos del reproductor, así como se pueden
actualizar los tiempos cuando recibimos los eventos pertinentes.

Esta pantalla es distinta al resto, ya que la reproducción funciona a pantalla completa.

En la figura siguiente podemos ver el diseño del reproductor:

Figura 7.7: Reproductor de vídeo

7.3.3 Implementación generator-tal

Para implementar el generator-tal voy a seguir el tutorial que nos provee la comunidad
de Yeoman, así como el generator-generator, que se usa como base de cualquier desarrollo.

En este punto explicaré el ciclo de vida del generador, la estructura que he adoptado.

7.3.3.1 Ciclo de vida del generador

Los generadores TAL tienen un ciclo de vida definido que se resume en los siguientes
estados:

• initializing Inicializa nuestro generador

• prompting Pregunta al usuario, pudiendo variar el resultado de la

aplicación base en función de sus respuestas

• configuring Configura el entorno

• default Todas las acciones que no van en el resto de métodos

• writing Escribe en el directorio que corresponde

108
 • conflicts Resolución de conflictos. Método interno de Yeoman

• install Instala las dependencias usando NPM y Bower

• end Se llama cuando se ha terminado de ejecutar el resto de

métodos

En el generador que he desarrollado solo hago uso de initializing, prompting, writing e

install.

7.3.3.2 Estructura
Como podemos ver en la siguiente figura, la estructura básica de un generador es muy
sencilla:
.
├── LICENSE
├── README.md
├── __tests__
│ └── app.js
├── generators
│ └── app
│ ├── index.js
│ └── templates
│ └── dummyfile.txt
├── package-lock.json
└── package.json
Figura 7.8: Estructura generador-tal
El trabajo realizado es sobre el fichero “generators/app/index.js”, donde se encuentra
toda la lógica necesaria para crear la aplicación base, y en templates, que es donde está
almacenada la aplicación TAL anteriormente descrita.

En el fichero index.js especifico las dependencias y agrego los valores que se ha

preguntado al usuario.

7.3.3.3 Conclusiones
Crear el generator-tal ha sido sencillo, ocupando todo el trabajo la organización del
código de ejemplo, ya que Yeoman facilita mucho, con su ciclo de vida, el realizar el proceso
de forma correcta.

109
110
8 Conclusiones
Gracias a este proyecto fin de carrera he podido profundizar en el ecosistema de las
aplicaciones OTT, permitiéndome entender con mayor claridad todos los actores
involucrados. De esta forma he conseguido tener una visión global de lo importante que es
este mercado, la proyección a futuro que tiene, y cuáles son las tendencias actuales del
mismo.

En un sector en el que se prevé que el 80% del tráfico en internet sea vídeo, creo que el
haber obtenido dicha visión puede prepararme para los retos con los que puedo encontrarme
en mi futuro profesional.

Espero haber plasmado la importancia que tiene este sector, así como su dinamismo
potenciado por los distintos fabricantes de dispositivos de consumo que están compitiendo
entre sí para obtener el mayor número de usuarios posibles y de JavaScript como lenguaje
de programación casi universal para las aplicaciones.

Como punto negativo he podido confirmar que la fragmentación es una gran lacra que
impide que los desarrolladores puedan incorporarse a este mercado de una forma sencilla,
lo que ha desembocado en un ecosistema de aplicaciones que aún no está maduro. Por otro
lado, esto brinda una oportunidad única a quien quiera introducirse en este mercado, ya
que no hay competencia real.

El análisis técnico de todos los actores de las plataformas de vídeo bajo demanda me ha
permitido ver que las aplicaciones de vídeo tienen detrás de sí una compleja infraestructura
altamente entrelazada.

Antes de realizar este proyecto fin de carrera no era consciente de la cantidad de servicios
que una aplicación es capaz de consumir, y tampoco entendía la complejidad de las
relaciones que hay entre cada una de las partes.

El detalle que me ha resultado más interesante es el relacionado con el vídeo y todos los
procesos que se llevan a cabo desde los orígenes hasta su distribución a los clientes finales.
Al no estar cubierta por la especialidad de Telemática, los distintos pasos a los que se
someten los vídeos y en especial la parte relacionada con la segurización de los mismos ha
sido completamente nueva para mí. Esto me ha ayudado a desmitificar tecnologías como
el DRM, entendiendo bien cómo funciona, visualizando donde están los problemas éticos
que pueden atentar contra nuestra libertad en el futuro, relacionados con las malas
prácticas de las compañías, no con la tecnología en sí misma.

En relación con los modelos de segurización me han resultado interesantes las distintas
estrategias que siguen los fabricantes para disuadir a los usuarios, en especial las firmas
estenográficas, ya que antes de este proyecto no conocía nada acerca de las mismas.

Con el análisis en profundidad de TAL BBC he podido aprender cómo está construido
un framework en constante desarrollo, estudiando mucho sobre cómo hay que plantear este

111
tipo de herramientas para que otros usuarios sean capaces de usarlas y extenderlas. El
resultado de este análisis se ha visto reflejado en la fase de desarrollo, en la cual he
intentado solucionar los problemas más evidentes que he identificado en TAL, como es la
falta de convenciones.

La fase de desarrollo de este proyecto me ha permitido conocer Yeoman y los generadores

de código. Creo que este tipo de herramientas van a ser imprescindibles en el futuro, ya
que el mercado demanda la creación de aplicaciones en el menor tiempo posible, y esto solo
lo podemos conseguir con ejemplos claros y concisos como los que nos ofrecen los
generadores.

Como conclusión final decir que he aprendido y disfrutado mucho según he escrito la
memoria. La visión más completa que ahora poseo del desarrollo de aplicaciones de VOD
en dispositivos conectados hace que me parezca un sector con muchísimo potencial y retos
por delante, lo cual me hace seguir queriendo trabajar e investigar más sobre él.

112
9 Líneas futuras de investigación
A lo largo de esta memoria hemos visto que el ecosistema OTT es muy amplio y
complejo, a la par que hermético al no existir mucha documentación sobre ninguno de los
actores y tecnologías involucradas para proteger el contenido de usos fraudulentos.

Del análisis realizado podemos determinar dos líneas futuras de investigación, una
relacionada con la creación de un framework que nos permita agilizar y unificar el desarrollo
de aplicaciones de VOD y otra relativa al desarrollo de un reproductor de vídeo que
solucione los problemas de incompatibilidad que existen con los distintos streams y
dispositivos.

9.1 Desarrollo de un framework multiplataforma

Una futura línea de investigación interesante es la idea de seguir explorando la
posibilidad de agilizar el desarrollo de este tipo de aplicaciones, marcándonos los siguientes
objetivos:

• Reducir el tiempo necesario para tener un entorno de desarrollo listo

• Dar soporte al mayor número de dispositivos posibles del mercado, siguiendo la

evolución de este para ver cuál es la tendencia del mercado

• Resolver los siguientes problemas

o Navegación con ratón y mandos a distancia.

o Abstracción de APIs privativas.

o Componentes visuales comunes para todos los dispositivos.

o Ser modular y fácilmente expandible.

En la fase de investigación tendríamos que evaluar los framework modernos, como

pueden ser ReactJS o VueJS, y analizar la viabilidad de añadir las piezas anteriormente
mencionadas.

Debemos de diferenciar el trabajo de adaptación del framework a nuestras necesidades

(creación de componentes, navegación) con la fase de creación de una librería abstracta
que simplifique el acceso a las capacidades de cada dispositivo mediante un patrón de
diseño de programación facade (Osmani, Learning Javascript Design Patterns, 2012) sin
tener que conocer la implementación original. TAL BBC sería un buen modelo a seguir,
usando tecnología más moderna y dando soporte a DRM y los últimos dispositivos.

113
9.2 Desarrollo de reproductor HTML5
Otra futura línea de investigación que puede desarrollarse en paralelo con la anterior es
la creación de un reproductor de vídeo multidisposivo que permita reproducir casi cualquier
formato de streaming, sea cual sea el codec y DRM asociado.

Dicho reproductor debería de cumplir los siguientes requisitos:

• Ser totalmente compatible con las tecnologías HTML JS sin requerir de ningún
motor o lenguaje externo al navegador para poder funcionar.

• Compatible en navegadores, dispositivos móviles y dispositivos conectados.

• Soporte de múltiples tecnologías de streaming.

• Soporte de múltiples codecs.

• Soporte de múltiples DRMs.

Como hemos visto en el Capítulo 5 “Análisis de dispositivos HTML JS”, los navegadores
están en una constante evolución, y gracias a las políticas de actualización de estas
aplicaciones en los PC, las últimas novedades están ampliamente implantadas.

La poca capacidad de actualización de los dispositivos conectados se solucionará por si

misma con el paso del tiempo, ya que como vimos los fabricantes están empezando a aplicar
políticas de actualización en los nuevos modelos, dando soporte a las últimas tecnologías
web.

El trabajo se centraría en el análisis de las siguientes tecnologías:

• Media Source Extensions – Tecnología web que abstrae la reproducción de vídeo,

de forma que cualquiera pueda generar un adaptador de cualquier stream de bytes
al reproductor interno de los navegadores web como podemos ver en la página
del borrador del W3C (A. Colwell, 2014). Esto permite que podamos procesar
cualquier stream en el lado del cliente, generar dichos streams de bytes y
alimentar al reproductor con los mismos.

• Encrypted Media Extensions – Tecnología web que permite usar e implementar

DRM en los navegadores estándar, como podemos ver en la página del borrador
en W3C (A. Colwell, 2014).

• WebAssembly – Tecnología web que permite compilar código en C u otro lenguaje

y ejecutarla en un navegador, como podemos ver en la página del grupo (W3C,
2015). Gracias a esta extensión vamos a ver un salto cualitativo den las
aplicaciones que se ejecutan en los navegadores web. En este escenario podemos
usar módulos de trasnscodificación desde la parte frontal para arreglar cualquier
problema relacionado con los codec de audio o vídeo.

114
 Trabajando en conjunto con dichas tecnologías deberíamos de ser capaces de tratar
cualquier stream de vídeo desde el navegador web, pudiendo recodificar el vídeo y audio
en el caso de que no esté soportado gracias a WebAssembly y las Media Source Extensions.

En el caso de que el contenido esté protegido con tecnologías DRM podríamos usar las
Encrypted Media Extensions junto con WebAssembly para hacer todas las operaciones de
autenticación y desencriptarlo de forma eficiente.

El reproductor se puede desarrollar a partir del trabajo que ha creado el consorcio de

DASH-IF (Dash-IF, 2014), que ya soporta varias de las características que son necesarias
para facilitar la implantación de reproductores compatibles en múltiples dispositivos o
alguno de sus forks como el HAS Player de Orange (Orange, 2017)

115
116
10 Glosario
AES Advanced Encryption Standard
ABR Average Bit Rate
API Application Programming Interface
AD Advertising
AMD Asynchronous module definition
AVOD Advertisement VoD

BBC British Broadcasting Corporation

BR Bit Rate

CBR Constant Bit Rate

CDN Content Distribution Network
CMS Content Management System

DRM Digital Rights Management

ES ECMA Script
ECMS Editorial CMS
EPG Electronic Program Guide

FLOSS Free Libre Open Source Software

HTML Hyper Text Mark Language

HLS HTTP Live Streaming
HDMI High-Definition Multimedia Interface
HTTP Hyper Text Transfer Protocol

I18n Internationalisation
ID Identifier
IPTV IP Television

JS JavaScript
JSON JavaScript Object Notation

KPI Key Performance Indicator

MOOC Masive online

NaCL Native Client

nPvR Network Private Víideo Recorder

OSS Open Source Software

OS Operating System
OVP Online Video Platform
OAuth Open Authorization

117
OTA Over The Air
OTT Over The Top

PVR Private Video Recorder

QoS Quality of Service

SOAP Simple Object Access Protocol

STB Set Top Box
SVOD Subscription VOD

TAL TV Application Layer

TS Transport Stream
TV Television
TVOD Transactional VOD

URL Uniform Resource Locator

VAST Video Ad Serving Template

VBR Variable Bit Rate
VCMS Video CMS
VOD Video On Demand
VR Virtual Reality
VMAP Video Multiple Ad Playlist
VPAID Video Player-Ad Definition
VPN Virtual Private Network
VDOM Virtual DOM

XML Extensible Markup Language

118
11 Bibliografía
LG. (2017). WebOSTV UX Checklist. Obtenido de http://webostv.developer.lge.com/design/ux-
checklist/)
Cisco. (2015). By 2019, 80% of the World’s Internet Traffic Will Be Video [Cisco Study]. (T.
Insights, Productor) Obtenido de http://tubularinsights.com/2019-internet-video-
traffic/#ixzz4fwgHOGvz
Council, FTTH. (2011). The Growth of Fiber to the Home. Obtenido de The Growth of Fiber to
the Home: https://toolkit.fiberbroadband.org/d/do/21
Crockford, D. (2001). JSON. Obtenido de http://www.json.org/
The Economist. (2017). VR Has been more about hype. Obtenido de
https://www.economist.com/news/business/21724863-vr-has-been-more-about-hype-
substance-will-change-reality-check-virtual
Accedo. (2017). Transforming the video experience. Obtenido de https://www.acccedo.tv)
A. Colwell, A. B. (2014). Media Source Extensions W3C Candidate Recommendation. Obtenido
de W3C: https://www.w3.org/TR/2014/CR-media-source-20140717
Aguinaga, J. (2016). How it feels to learn JavaScript in 2016. Obtenido de Hackernoon:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
Apple. (2016). Apple FairPlay Streaming. Obtenido de https://developer.apple.com/streaming/fps
Apple. (5 de July de 2017). Support. App Store. Obtenido de
https://developer.apple.com/support/app-store/
BBC. (2016). TAL Example. Obtenido de Github: https://github.com/bbc/talexample)
Dash-IF. (2014). DASH Industry Reference player. Obtenido de GitHub: https://github.com/Dash-
Industry-Forum/dash.js/
ECMA. (1997). ECMAScript: A general purpose, cross-platform programming language.
Obtenido de http://www.ecma-international.org/publications/files/ECMA-ST-
ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf)
ECMA. (2011). Standard ECMA-262 5.1 Edition. . Obtenido de https://www.ecma-
international.org/ecma-262/5.1/
ECMA. (2013). ECMA-404. The JSON Data Interchange Format. Obtenido de http://www.ecma-
international.org/publications/files/ECMA-ST/ECMA-404.pdf
ECMA. (2015). Standard ECMA-262 6th Edition. Obtenido de https://www.ecma-
international.org/ecma-262/6.0/
ECMA. (2016). Standard ECMA-262 7th Edition. Obtenido de https://www.ecma-
international.org/ecma-262/7.0/
ECMA. (2017). Standard ECMA-262 8th Edition. Obtenido de https://www.ecma-
international.org/ecma-262/8.0/
Eich, B., Mills, C., & User:Sneethli2. (2012). A Short History of JavaScript. (W3C) Obtenido de
W3C: https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript
Fontaine., R. (2016). Twitch Cheer. Obtenido de https://blog.twitch.tv/introducing-cheering-
celebrate-together-da62af41fac6
Garrett, J. J. (2005). Ajax: A New Approach to Web Applications. Obtenido de Adaptative path:
http://adaptivepath.org/ideas/ajax-new-approach-web-applications
Github. (2016). The estate of the Octoverse . Obtenido de https://octoverse.github.com
Google. (2017). Versiones de la plataforma. Obtenido de
https://developer.android.com/about/dashboards/index.html#Platform
Google. (2017). YouTube Super Chat. Obtenido de
https://support.google.com/youtube/answer/7277005

119
IAB + Maru/Matchbox. (2017). The Changing TV Experience. Obtenido de
https://www.iab.com/insights/2017ChangingTVExperience
Kang, A. (23 de January de 2017). As Larger TVs Gain Popularity, TV Panel Area Demand to
Grow 8 Percent in 2017. (IHS Markit) Obtenido de https://technology.ihs.com/587999/as-
larger-tvs-gain-popularity-tv-panel-area-demand-to-grow-8-percent-in-2017-ihs-markit-
says
McDonal., B. (2017). Google, I/O 2017 Live Event Coverage. (Google) Obtenido de
https://youtu.be/lHQUQUotkQ0?t=1h46m49s
Microsoft. (1996). JScript (ECMAScript3). Obtenido de
http://msdn.microsoft.com/library/hbxc2t98.aspx
Microsoft. (2013). Microsoft Play Ready Header Object. Obtenido de
http://download.microsoft.com/download/2/0/2/202E5BD8-36C6-4DB8-9178-
12472F8B119E/PlayReady%20Header%20Object%204-15-2013.docx
Microsoft. (2017). Microsoft VSCode. Obtenido de Github: https://github.com/Microsoft/vscode
Movistar +. (2016). Comienza producción de series originales. Obtenido de
https://www.telefonica.com/documents/23283/4472063/NdP_produccion_original_La_Pes
te.pdf/8c4a7e02-de67-456e-bfac-4937adf0e824?version=1.0)
Netflix. (2017). Netflix Q1 Results and Q2 Forecast. Obtenido de
http://files.shareholder.com/downloads/NFLX/4303306568x0x937576/7DAD8A22-F8FE-
4339-A534-4A851A5C68E5/Q117ShareholderLetterV2FINAL.pdf
News, D. T. (2017). EU adopts rules to allow OTT roaming. . Obtenido de
http://www.digitaltvnews.net/?p=29216
Orange. (2017). HAS Player. Obtenido de Github: https://github.com/Orange-
OpenSource/hasplayer.js
Osmani, A. (2012). Learning Javascript Design Patterns. En O’Reilly Media. O’Reilly Media.
Obtenido de A. Osmani. Learning Javascript Design Patterns. O’Reilly Media 2012.
Capitulo Facade pattern.
(https://addyosmani.com/resources/essentialjsdesignpatterns/book/#facadepatternjavascrip
t)
Osmani, A., Sorhus, S., Hartig, P., Sawchuk, S., Boudrias, S., Ford, B., . . . Dara, M. (2017).
Writing your own yeoman generator. (Yeoman) Obtenido de http://yeoman.io/authoring/
Require.js. (2017). How to get started with RequireJS. (Require.js) Obtenido de
http://requirejs.org/docs/start.html
Samsung. (2017). Design Principles. Obtenido de Samsung Developers:
http://developer.samsung.com/tv/design/design-principles
Samsung. (2017). Smart TV Specifications. Obtenido de Samsung Developers:
http://developer.samsung.com/tv/develop/specifications/general-features
Stack Overflow. (2016). Developer Survey Results. Obtenido de Most Popular Technologies:
https://insights.stackoverflow.com/survey/2016#technology
Stack Overflow. (2017). Developer Survey Results. Obtenido de Most Popular Technologies:
https://insights.stackoverflow.com/survey/2017
Tom Huddleston, J. (2017). Obtenido de Fortune: http://fortune.com/2017/06/15/netflix-more-
subscribers-than-cable/
W3C. (2015). W3C Web Assembly Community Group. Obtenido de
https://www.w3.org/community/webassembly/
Wolenetz, M., Smith, J., Watson, M., Colwell, A., & Bateman, A. (10 de August de 2016). W3C
ISO BMFF Byte Stream. Obtenido de https://w3c.github.io/media-source/isobmff-byte-
stream-format.html
Yeoman. (2017). Generator-generator. Obtenido de GitHub: Generator-generator. Yeoman.,.
(https://github.com/yeoman/generator-generator)

120
Anexo A – Manual de usuario
En este apartado describiré los pasos que un usuario de Yeoman debe de seguir para
poder poner a punto un proyecto basado en el framework TAL.

TAL generator
El generador de TAL BBC nos permite crear un punto de partida para desarrollar
nuestras aplicaciones. Está basado en Yeoman.io.

Instalación
Para poder usar el generador primero debemos de tener instalado Node.js y NPM. En
el caso de no tenerlo instalado podemos seguir las instrucciones de https://nodejs.org/en/
para descargar la última versión.

A continuación, debemos de instalar las siguientes dependencias:

npm install –g yo

Ahora tendremos que instalar el generador desde la carpeta generator-tal que podemos
encontrar en el CD/USB:

cd /media/cdrom/generator-tal

npm link

Crearemos un directorio y haremos cd sobre el mismo:

mkdir tal-project && cd tal-project

Ejecutaremos yo tal, y de forma opcional le otorgaremos un nombre de Proyecto:

yo tal [nombre de aplicación]

Ejecutaremos el proyecto para empezar a servir la aplicación TAL.

node index.js

Ahora podremos acceder a nuestra aplicación de ejemplo usando la siguiente URL:

http://localhost:1337/

121
Anexo B - Manual de referencia
El código de este proyecto de fin de carrera puede encontrarse en el DVD y USB adjuntos a la
memoria.

122