2.4.1. Introducción
Como se ha comentado en el capítulo de introducción, en los últimos años se ha experimentado un notable aumento en el consumo de servicios de vídeo sobre Internet. Según datos de “The Diffusion Group (TDG) Research”, en enero de 2014 el 63 % de los hogares norteamericanos tenían al menos una televisión conectada a Internet (ya sea smart TV o una televisión conectada a través de otro dispositivo). Una encuesta realizada por GfK en septiembre de 2013 descubrió que el 51 % de la población de Estados Unidos, con edades comprendidas entre los 13 y los 54 años, veían programas de televisión o películas mediante streaming de vídeo, al menos una vez a la semana. Es especialmente interesante la evolución de estos datos, ya que la misma encuesta reveló que dicho porcentaje era del 37 % y del 48 % en 2010 y 2012 respectivamente.
Sin embargo, existen algunas razones que están impidiendo que los servicios de strea- ming de vídeo OTT alcancen todo su mercado potencial. Una de estas razones es que la mayoría de las plataformas comerciales de vídeo OTT que existen actualmente son sistemas cerrados, con sus propios protocolos, formatos de descripción y representación de contenidos, etc., es decir, no existe interoperabilidad entre servidores y dispositivos de distintos fabricantes u operadores.
Desde un punto de vista más técnico, se puede decir que desde sus inicios, en torno al año 1990, la distribución de vídeo a través de Internet se encontró con dos problemas principales:
1. La realización de la entrega de contenidos a tiempo. 2. El coste asociado al envío de grandes cantidades de datos.
Para intentar resolver el primer problema, el IETF diseñó el protocolo Real-time Transport Protocol (RTP), el cual define formatos de paquete y mecanismos de control de sesión para realizar streaming multimedia en redes IP. Aunque RTP funciona bien en redes IP gestionadas, presenta algunos problemas cuando se usa a través de Internet. En primer lugar, muchas CDN no soportan RTP, por lo que “acercar” físicamente el contenido a los usuarios se presenta como un reto. Por otro lado, los paquetes RTP no suelen ser aceptados por los firewalls. Además, el diseño de RTP hace que el servidor tenga que gestionar información de sesión para cada usuario de manera independiente.
2.4. MPEG-DASH 27
Todos estos problemas hace que desplegar una solución basada en RTP de manera masiva sea todo un reto tecnológico.
Con el paso de los años, el segundo problema se ha ido reduciendo, ya que el in- cremento de los anchos de banda ha reducido bastante el coste que supone el envío de información a través de Internet. Este hecho, junto con el enorme crecimiento de la World Wide Web, hace que la distribución de contenido multimedia pueda realizarse de manera eficaz enviando fragmentos de vídeo (segmentos) a través del protocolo Hy- pertext Transfer Protocol (HTTP). El streaming basado en HTTP tiene las siguientes ventajas:
La infraestructura de Internet ha evolucionado para adaptarse de manera eficaz al tráfico HTTP. El ejemplo más importante de esta adaptación son las CDN, que proporcionan réplicas del contenido en localizaciones cercanas al usuario para reducir el tráfico en las redes troncales.
HTTP atraviesa la mayor parte de firewalls ya que suelen estar configurados para soportar conexiones HTTP salientes.
La tecnología de servidores HTTP es muy barata.
Mediante streaming HTTP son los clientes los que mantienen la información de sesión, por lo que la escalabilidad de este tipo de servicios es muy alta.
Estas ventajas han propiciado la aparición de diferentes plataformas de streaming como HTTP Live Streaming (Apple), Smooth Streaming (Microsoft), HTTP Dynamic Streaming (Adobe), cada una con diferentes formatos de segmentos y diferentes ficheros de manifiesto, por lo que la interoperabilidad entre ellas no es inmediata.
Volviendo al punto anterior, esta falta de interoperabilidad entre plataformas es una de las principales motivaciones que han llevado al desarrollo del estándar que se describen a continuación, MPEG-DASH.
2.4.2. Streaming adaptativo
Antes de entrar en detalles concretos del estándar MPEG-DASH es importante tener una noción del concepto de streaming adaptativo sobre HTTP.
Como se comentó en la introducción, en los sistemas de streaming sobre HTTP es el cliente el que mantiene el control de la sesión. En este contexto, mantener la sesión significa, entre otras cosas, solicitar al servidor los fragmentos de vídeo necesarios para la reproducción del contenido. Para ello, es necesario algún mecanismo que permita a los clientes conocer qué fragmentos están disponibles en el servidor y cómo solicitarlos. En general, los sistemas de streaming de vídeo HTTP resuelven esta cuestión poniendo
en el servidor un fichero a disposición de los clientes con la información necesaria para que éste lleve a cabo las peticiones necesarias para obtener los fragmentos de vídeo. A estos ficheros se les suele conocer como ficheros manifest, aunque en MPEG-DASH se les denomina ficheros Media Presentation Description (MPD).
En los sistemas de streaming adaptativo, se incluye información en el fichero mani- fest sobre un catálogo de versiones disponibles en el servidor para un mismo contenido. Por ejemplo, diferentes representaciones del flujo de vídeo codificado a distintas tasas de bit, audio en diferentes idiomas, etc.. Una vez que el cliente conoce las distintas versiones del contenido nada le impide, en cada petición, conmutar entre ellas. Dicha conmutación puede realizarse como respuesta a una acción del usuario (por ejemplo, cambiar el idioma del audio) o bien, caso de uso típico de estos sistemas, como respues- ta a un cambio en las condiciones de la red (por ejemplo, si la tasa de bit disponible en la red se reduce, la aplicación cliente puede decidir conmutar a un nivel de calidad inferior, solicitando segmentos de vídeo codificado a menor tasa de bit que la actual).
2.4.3. Arquitectura de referencia y alcance del estándar
En la figura 2.3 se presenta la arquitectura general de un servicio basado en MPEG- DASH. Como se puede ver, los bloques que componen la figura implementan un servicio de streaming adaptativo, de acuerdo a la descripción del apartado anterior. El servi- dor HTTP almacena los segmentos de los distintos flujos de medios y el fichero de descripción MPD, mientras que el cliente consta de un motor encargado de realizar las peticiones de segmentos y de una serie de módulos que permiten decodificar y renderizar el contenido de cada segmento.
HTTP/server
Media Presentation Description Media Presentation Description
(MPD)
Segments MPD
DASH client
DASH access engine
Media engine Media/output
Application Event + timing MPEG format media/+ timing Segment Segment … … Segment Segment … Segment Segment … … Segment Segment … HTTP/1.1
2.4. MPEG-DASH 29
La última versión del estándar MPEG-DASH se denomina ISO/IEC 23009:2014 y está formado por cuatro partes, siendo la más relevante la primera de ellas:
1. Media presentation description and segment formats 2. Conformance and reference software
3. Implementation guidelines (Technical Report) 4. Segment encryption and authentication
En la primera parte del estándar (Media presentation description and segment for- mats) [ISO, 2014b] se establece el formato que deben seguir tanto el fichero MPD como los segmentos que en él se definen. El protocolo que el estándar propone para la trans- misión de segmentos es HTTP/1.1. Es importante destacar que el estándar solo define el formato del fichero MPD y el formato de los segmentos. La transmisión del MPD y el comportamiento del cliente en cuanto a reproducción y mecanismos de adaptación quedan fuera del estándar.
2.4.4. Estructura del fichero MPD
Como se ha comentando anteriormente, el estándar MPEG-DASH no se centra en procedimientos propios de cliente o servidor, sino que pone el foco en el formato de los segmentos y del fichero MPD que los describe. Este fichero está formateado en XML y describe el contenido que el servidor pone a disposición de los clientes, además de informales de cómo deben solicitar dicho contenido.
En la figura 2.4 se muestra de manera esquemática la estructura típica de un fichero MPD. MPD Period ID =1 Start = 0 s … Period ID =2 Start = 60 s … Period ID =3 Start = 120 s … … Period ID = 1 Adaptation set 0 Adaptation set 1 Adaptation set 2 Adaptation set 0 Representation 1 10 Mbps Representation 2 5 Mbps Representation 3 1 Mbps Representation 1 Initialization segment Segment 1 Segment n …
El contenido multimedia descrito por este MPD se compone de uno o variosperio- doscontiguos en el tiempo. Un periodo representa un intervalo de tiempo del contenido multimedia en el que el conjunto de versiones codificadas permanece constante. Dentro de un periodo, el contenido se organiza en conjuntos de adaptación o adaptation sets, los cuales representan un conjunto intercambiable de versiones codificadas de un componente (audio, vídeo, etc.) del contenido multimedia. Por ejemplo, un conjunto de adaptación puede contener diferentes versiones de la componente de vídeo codificada a varias tasas de bit, mientras que otro conjunto de adaptación puede estar formado por diferentes versiones de la componente de audio en diversas calidades.
Un conjunto de adaptación contiene un conjunto derepresentacionesque descri- ben una versión codificada de uno (o varios, si están multiplexados) componentes del contenido multimedia. Por tanto, los clientes puedes conmutar dinámicamente entre representaciones de un mismo conjunto de adaptación para adaptarse a las condiciones de la red o a otros factores.
En cada representación, el contenido se divide en el tiempo en forma desegmentos, los cuales están identificados por una URL. Los segmentos se puede dividir a su vez
en subsegmentos, cada uno de los cuales contiene un número entero de unidades de
acceso.
2.4.5. Formato de los segmentos
El estándar MPEG-DASH es independiente del tipo de codificación de los contenidos y define formatos para contenedores de segmentos ISO Base Media File Format [ISO, 2005b] y MPEG-2 Transport Stream [ISO, 2013a]. Además, ofrece recomendaciones para realizar extensiones a otros formatos.