ES2811769T3 - Suministro de contenido - Google Patents

Abstract

Sistema para suministrar contenido con calidades variables desde un servidor a múltiples clientes a través de una red, estando el contenido dispuesto en representaciones de calidades diferentes, comprendiendo cada representación unos segmentos direccionables por solicitudes de cliente, que comprende: un conversor de lado de servidor (6) dispuesto para - emitir solicitudes de unidifusión al servidor para segmentos de múltiples representaciones del contenido; - convertir cada una de entre las múltiples representaciones del contenido en unos respectivos flujos de datagramas de multidifusión, siendo cada representación asignada a una dirección IP de multidifusión correspondiente; y - suministrar los flujos de datagramas de multidifusión sobre la red; un conversor de lado de cliente (8) dispuesto para - recibir solicitudes de contenido de los clientes; - determinar una representación del contenido que se va a obtener sobre la base de las condiciones de monitorización de la red; - suscribirse al flujo de datagramas de multidifusión que comprende la representación determinada del contenido; - convertir el flujo de datagramas de multidifusión de nuevo en segmentos disponibles para el cliente por solicitud de unidifusión; y - conmutar entre diferentes representaciones del contenido cuando el conversor de lado de cliente detecte la necesidad de cambiar de una representación a otra sobre la base de las condiciones de la red, conmutando el conversor del lado de cliente entre diferentes representaciones del contenido mediante la conmutación entre flujos de datagramas de multidifusión.

Description

DESCRIPCIÓN

Suministro de contenido

Antecedentes de la invención

La presente invención se refiere a un sistema y a un método para la transmisión adaptativa, en continuo, de datos (del inglés “streaming”).

Se conoce el suministro en línea de contenido de audio-vídeo, que gira en torno a la transmisión en continuo por unidifusión IP y a la descarga a clientes basados en la web, a aparatos telefónicos móviles de mano, a unidades de adaptación del televisor y a aparatos de televisión conectados. Los avances recientes en esta área han visto la sustitución de protocolos privativos de transmisión en continuo, de primera generación, por una multitud de planteamientos (todavía privativos) para emitir por unidifusión de flujo desde diferentes proveedores que convergen en el protocolo de aplicación HTTP. Estos incluyen el Smooth Streaming de Microsoft, e1HTTP Live Streaming de Apple y el HTTP Dynamic Streaming de Adobe. Otro punto de convergencia es que estas tecnologías de suministro de segunda generación introducen el concepto de Transmisión Adaptativa Dinámica en Flujo por la cual los mismos medios de una fuente se codifican con una serie de velocidades de bit y calidades diferentes. A continuación, el cliente conmuta dinámicamente entre estos flujos de medios diferentes a medida que avanza la presentación de los medios de acuerdo con las condiciones disponibles de reproducción y de velocidad de bits de la red, minimizando, así, los efectos visibles o audibles adversos.

Se ha sugerido la transmisión en continuo por multidifusión como medios para reducir el ancho de banda tanto a través de los ISP como sobre el acceso a la memoria caché y al origen. Debido a su similitud lógica con la emisión por difusión (transmisión unidireccional desde la fuente al espectador), resulta menos adecuada para la transmisión en flujo bajo demanda, la descarga en tiempo no real o el concepto, recientemente introducido, de “rebobinado en vivo”. No obstante, para flujos lineales en vivo (por ejemplo, un canal de noticias) y para grandes eventos con cifras altas de visionado (y, por lo tanto, costes altos de suministro por unidifusión), la multidifusión ofrece una solución técnica atractiva para escalar la provisión con el fin de adaptarse a la demanda de audiencia. Los documentos US 2013/246578, u S 2006/047845 y WO 2012/000165 describen sistemas relacionados de la técnica anterior.

Sumario de la invención

Hemos apreciado la necesidad de proporcionar un suministro adaptativo de contenido a múltiples usuarios al tiempo que proporcionando un uso eficiente de recursos de la red.

En términos generales la invención proporciona componentes funcionales adicionales en una red con el fin de realizar conversiones de unidifusión a multidifusión y, nuevamente, a unidifusión, con el fin de proporcionar un suministro sin fisuras a un cliente que solicita contenido por unidifusión, aunque proporcionando eficiencias del transporte por multidifusión. Los sistemas y métodos que materializan la invención pueden ser transparentes en el sentido de que, entre un servidor y un cliente convencionales, se interponen un conversor en el lado del servidor y un conversor en el lado del cliente, de tal manera que el cliente y el servidor no tienen conocimiento, ninguno de ellos, de la conversión que tiene lugar, ni se deben modificar con el fin de sacar provecho de las eficiencias que se obtienen.

La invención se define en las reivindicaciones a las cuales se hace referencia a continuación.

Una forma de realización de la invención combina eficazmente la técnica de la Transmisión Adaptativa Dinámica en continuo con el suministro por multidifusión. Uno de los motivos para adoptar la multidifusión en esta arquitectura es aliviar la carga de la red tanto en los Proveedores de Servicios de Internet como en una infraestructura de memoria caché de frontera HTTP en momentos de máximo tráfico en vivo. La forma de realización aplica una función de conmutación adaptativa que conmuta sin fisuras entre flujos de medios por multidifusión de calidades diferentes (y, por lo tanto, velocidades de bit diferentes) para adaptarse a la capacidad dinámicamente variable de la red de suministro, de una manera similar a los planteamientos existentes de transmisión adaptativa en flujo por unidifusión. Además, la forma de realización prevé un repliegue automático y sin fisuras a un funcionamiento por unidifusión en casos en los que la recepción de los flujos de medios por multidifusión resulte poco fiable o irregular. Preferentemente, la arquitectura proporciona los medios para “enchufar” (“plug in") una serie de diferentes algoritmos de conmutación de flujos del lado cliente con el fin de facilitar la conmutación dinámica y de optimizar la presentación de medios resultante.

Breve descripción de los dibujos

A continuación, se describirá más detalladamente una forma de realización de la invención a título de ejemplo en referencia a los dibujos, en los cuales:

la figura 1 : es un diagrama esquemático que proporciona una visión general de un sistema de extremo a extremo que materializa la invención;

la figura 2: muestra una Descripción de Presentación de Medios (MPD) de ejemplo;

la figura 3: es un diagrama esquemático que muestra el conversor de lado del cliente de la figura 1 con mayor detalle;

la figura 4: muestra el flujo de mensajes según es gestionado por el conversor de lado del cliente;

la figura 5: muestra una implementación del conversor de lado del cliente en un dispositivo de cliente; la figura 6: muestra una implementación del conversor de lado del cliente en un dispositivo de pasarela residencial;

la figura 7: muestra una implementación del conversor de lado del cliente en un dispositivo de suministro de red;

la figura 8: muestra la velocidad de bits con respecto al tiempo cuando se conmuta a una representación de mayor calidad;

la figura 9: muestra una solicitud de unidifusión usada cuando se conmuta como en la figura 8;

la figura 10 : ilustra la velocidad de bits ligeramente mayor generada durante la recuperación de unidifusión de la figura 9;

la figura 11 : muestra la velocidad de bits con respecto al tiempo cuando se conmuta a una representación de menor calidad;

la figura 12 : muestra una solicitud de unidifusión usada cuando se conmuta como en la figura 11 ;

la figura 13: ilustra la velocidad de bits generada durante la recuperación de unidifusión de la figura 12; la figura 14: es un diagrama esquemático del conversor de lado del servidor de la figura 1;

la figura 15: resume la recopilación y el procesado de los datos de velocidad de bits y los datos de pérdidas de paquetes en relación con decisiones de conmutación; y

la figura 16: muestra un formato de carga útil RTP de ejemplo.

Descripción detallada de las formas de realización preferidas

La invención se puede materializar en un método y un sistema para procesar contenido de vídeo y audio y para suministro a través de una red.

Con el fin de aportar contexto, en primer lugar, se describirán algunos protocolos existentes.

DASH MPEG

Uno de los estándares tecnológicos emergentes para la siguiente generación de servicios de transmisión en continuo de medios IP es el DASH MPEG. Dicho estándar se ha desarrollado bajo el auspicio del Grupo de Expertos en Imágenes en Movimiento (MPEG) con contribuciones de Microsoft, Apple, Adobe y 3GPP La especificación publicada [ISO/IEC 23009-1:2012] incorpora los mejores aspectos técnicos de las tecnologías privativas de las cuales se deriva, pero, como resultado, ofrece una serie de perfiles opciones diferentes. La variante de esta tecnología que se usa en la presente divulgación usa el suministro, basado en HTTP, de contenido MPEG-4 fragmentado [ISO/IEC 14496-14].

La Transmisión Adaptativa Dinámica en Continuo sobre HTTP (DASH) funciona de una manera similar al Smooth Streaming de Microsoft y al HTTP Live Streaming de Apple, presentando el contenido de medios como una secuencia de Segmentos de corta dirección sobre HTTP (sin flujo). El contenido de medios de origen se codifica con una variedad de diferentes velocidades de bits - denominadas Representaciones - y estas se alojan en un servidor HTTP denominado servidor DASH. A continuación, un cliente DASH puede conmutar dinámicamente entre Representaciones al nivel de los límites de los Segmentos solicitando Segmentos de una Representación diferente. El DASH MPEG es indiferente ante el CODEC y los Segmentos pueden contener medios en cualquier formato, aunque los Perfiles DASH MPEG admiten explícitamente tanto el Formato de Archivos de Medios de Base ISO [ISO/IEC 14496-12] como el Flujo de Transporte MPEG-2 [ISO/IEC 13818-1].

Una presentación de medios DASH se describe mediante un “manifiesto” denominado Descripción de Presentación de Medios (MPD), que se representa en la figura 2. La presentación de medios se divide en Periodos de tiempo. En un momento dado o cualquiera, solamente está activo un Periodo en la presentación de medios y esto se indica con un tiempo de inicio absoluto y/o una duración. Cada Periodo contiene uno o más Conjuntos de Adaptación, cada uno de los cuales define versiones, codificadas de forma diferente, de los mismos medios de origen, denominadas Representaciones. En algunos perfiles DASH MPEG (por ejemplo, los perfiles del Formato de Archivos de Medios de Base ISO), hay un Conjunto de Adaptación para cada flujo de medios lógico de la presentación (por ejemplo, descripción de audio, audio principal, vídeo). En otros perfiles DASH MPEG (por ejemplo, los perfiles del Flujo de Transporte MPEG-2), los flujos de medios lógicos se multiplexan juntos en Conjuntos de Adaptación correspondientes a permutaciones fijas de los flujos de medios disponibles. Por lo tanto, una Representación puede contener un flujo de medios o, en el caso de medios multiplexados, muchos.

En funcionamiento, un cliente DASH en primer selecciona qué Conjuntos de Adaptación del Periodo en curso está interesado en reproducir (por ejemplo, escogiendo entre un Conjunto de Adaptación de audio de programa Principal y un Conjunto de Adaptación de descripción de audio). A medida que la presentación de medios avanza, el cliente conmuta entonces entre las Representaciones disponibles en sus Conjuntos de Adaptación escogidos.

Cada Representación se divide en una secuencia de Segmentos temporales. Los Segmentos DASH son puestos a disposición por el servidor DASH en forma de recursos HTTP, cada uno con su propio Localizador Uniforme de Recursos exclusivo. De este modo, el cliente DASH puede recuperar cualquier Segmento Disponible por medio de una simple solicitud GET HTTP. Los Segmentos se pueden solicitar completos. Alternativamente, se pueden solicitar parcialmente usando una solicitud denominada “ intervalo de bytes” (“byte range”). Con el fin de admitir la conmutación de Representaciones por parte del cliente DASH, los límites de los Segmentos en todas las Representaciones pertenecientes al mismo Conjunto de Adaptación están preferentemente alineados. No obstante, no es necesario que los límites de los Segmentos de Conjuntos de Adaptación diferentes estén alineados. Típicamente, todos los Segmentos de una Representación particular tienen la misma duración, que se puede extender desde unos pocos segundos a la duración completa del Periodo.

En el Inicio de la recepción de cada Representación, se descarga típicamente un Segmento de Inicialización. Este puede considerarse como un encabezamiento, que contiene información sobre la codificación, tamaños de tramos, etcétera. Un cliente DASH necesita obtener esto para una Representación dada antes de que pueda descodificar Segmentos de medios de esa Representación.

Típicamente, los perfiles en el DASH MPEG imponen restricciones sobre características de la Descripción de Presentación de Medios y sobre formatos de los Segmentos, aunque también pueden controlar formatos de medios y CÓDECS o parámetros de codificación, tales como la velocidad de bits y la resolución de las muestras. El perfil preferido que se usa en esta divulgación es el Perfil en Vivo de Formatos de Archivos de Medios de Base ISO. Este perfil está destinado a la codificación en vivo y puede alcanzar una latencia de solamente unos pocos segundos mediante el uso de Segmentos de corta duración. Los URLs de los Segmentos se especifican en la MPD usando un formato de plantilla simple por lo que no es necesario que el Servidor DASH añada entradas nuevas a la MPD a medida que avance la presentación de medios en vivo, y no necesario que el Cliente DASH recupere una copia nueva de la MPD antes de solicitar el siguiente Segmento. Los Segmentos están restringidos de manera que el cliente siempre puede conmutar Representaciones en los límites de los Segmentos y, por lo tanto, es posible una conmutación sin fisuras siempre que un cliente haya descargado, descodificado y presentado la Representación de “come-from” antes de procesar la Representación de “go-to”.

Visión general del sistema

En primer lugar, se describirá un sistema que materializa la invención en relación con la figura 1, seguido por detalles más exhaustivos de flujos de mensajes en relación con figuras subsiguientes.

Una de las ventajas proporcionadas por el sistema de la figura 1 es que puede suministrar contenido DASH en vivo sobre flujos de multidifusión, y mantener la naturaleza adaptativa del sistema DASH. Nos referiremos a esta técnica como Transmisión Adaptativa Dinámica en Flujo sobre Multidifusión (DASM). El sistema de materialización suministra contenido a través de una red usando flujos de multidifusión a los que se hará referencia como flujos de datagramas, usando el vocablo “datagrama”, en su sentido genérico convencional.

El sistema está diseñado principalmente para flujos en vivo, más que contenido bajo demanda, y, preferentemente, el sistema usa una MPD que describe contenido usando el Perfil Dinámico en Vivo BMFF iSo . Además, los Segmentos se empaquetan preferentemente de tal manera que la mayor parte de la información de inicialización del descodificador se repiten en el inicio de cada Segmento de medios, y todas las Representaciones que comparten un Conjunto de Adaptación particular comparten un Segmento de Inicialización común que contiene información de inicialización vestigial. Un ejemplo de esto es el formato de entrada de muestra “avc3” [ISO/IEC 14496-15:2008 Amd 2] aplicado al vídeo H.264 [ISO/IEC 14496-10]. Este planteamiento para el empaquetamiento de medios permite la técnica de “dilución” que se describe posteriormente, en la cual un proxy presenta una única Representación al descodificador, que comprende Segmentos seleccionados de las diferentes Representaciones que ha puesto a disposición el Servidor DASh .

La figura 1 muestra los bloques lógicos de sistema de una cadena DASM de extremo-a-extremo, pasando desde los flujos de medios de origen hasta el descodificador de cliente. En este ejemplo se representan tres flujos de medios de origen 2: vídeo, audio principal y audio alternativo. (Por motivos de claridad, la figura solamente muestra la distribución en curso del Conjunto de Adaptación de vídeo desde el Servidor de Origen, aunque, en realidad, se distribuirán todos los Conjuntos de Adaptación).

La cadena comienza con la codificación, la fragmentación y el empaquetamiento de los flujos de medios de origen usando un codificador y fragmentador 5 dentro de un servidor DASh 4, por ejemplo, usando el formato de entrada de muestra “avc3” MPEG-4 y el perfil En Vivo ISO DASH MPEG. Cada flujo de medios de origen se codifica con un intervalo de velocidades de bits (vídeo de velocidad de bits “alta”, “media” y “baja” tal como se muestra en la figura 1) y las Representaciones que surgen de ese flujo de medios de origen se agrupan en un Conjunto de Adaptación. Los Segmentos DASH MPEG codificados se alojan en un servidor HTTP 7 estándar dentro del servidor DASH 4, tal vez con alimentación a una infraestructura HTTP de Red de Distribución de Contenidos (CDN) 12. Este es un sistema de Servidor DASH estándar. En el extremo más alejado de la cadena, un Descodificador DASH estándar consume estos Segmentos DASH estándar dentro de un cliente DASH 10.

Entre los componentes estándar del servidor DASH y del cliente DASH se interponen un conversor de lado de servidor 6 al que se hace referencia como sistema de Cabecera DASM y uno o más conversores de lado de cliente 8 a los que se hace referencia como sistemas Proxy de Cliente DASM. El conversor de lado de servidor 6 y el conversor de lado de cliente 8 proporcionan juntos la disposición nueva por medio de la cual se logra la conversión entre unidifusión y multidifusión.

El sistema de Cabecera DASM 6 implementa un cliente DASH MPEG 13 simplificado que recupera simultáneamente Segmentos de todas las Representaciones de todos los Conjuntos de Adaptación del Periodo en Curso en el momento adecuado. Estos se trasladan a un conjunto de componentes de serialización 15 (Módulos de Carga de RTP), uno por Representación, que fragmentan cada Segmento DASH en una secuencia de paquetes RTP A continuación, los paquetes producidos por cada Módulo de Carga de RTP se transmiten en datagramas UDP/IP de multidifusión, extendiéndose uniformemente la transmisión de estos datagramas a través del espacio de tiempo del Segmento (un valor de tiempo definido dentro de la MPD). Esto garantiza una velocidad de bits razonablemente uniforme para el flujo de multidifusión resultante. La dirección de destino de multidifusión a la que apunta cada Módulo de Carga de r Tp se especifica por separado para cada Representación en la Descripción de Presentación de Medios usando las extensiones del esquema de XML representado en la figura 2. A continuación, esta MPD mejorada se pone a disposición para instancias del Proxy de Cliente DASM publicándola, por ejemplo, en un servidor HTTP Posteriormente se describe de manera adicional la implementación de la Cabecera DASM.

El sistema Proxy de Cliente DASM 8 combina una función de deserialización 9 para recibir paquetes de multidifusión RTP formateados en DASM con un cliente HTTP 11 para recuperar Segmentos DASH directamente del Servidor DASH usando el método estándar de recuperación de unidifusión DASH. Más adelante se describe el funcionamiento detallado del Proxy de Cliente DASM. Una característica importante a señalar es que no hay ninguna adaptación de velocidad en los flujos de multidifusión a la salida de la cabecera - esto se lleva a cabo por completo en el extremo de cliente.

Protocolo de transporte

Los Módulos de Carga de RTP 15 y la función de deserialización 9 usan un protocolo de transporte de ejemplo basado en el Perfil de Vídeo Avanzado de RTP Los Segmentos DASH se dividen en fragmentos de un tamaño adecuado para su inclusión en las cargas útiles de paquetes RTP Se transportan metadatos de reensamblaje perfilando el uso de campos específicos en el encabezamiento de los paquetes RTP para indicar el primer y el último paquetes correspondientes a un Segmento DASH particular. La presencia del bit de encabezamiento de extensión de RTP (“X”) indica el inicio de una transmisión de Segmento y el bit marcador (“M”) indica el final. En el encabezamiento de los paquetes RTP se transporta también la ordenación de los paquetes con el fin de facilitar el reensamblaje del Segmento DASH original en caso de que los paquetes RTP lleguen desordenados a su destino debido a que hayan seguido diferentes trayectos de red. En el encabezamiento de extensión RTP se transportan metadatos sobre el Segmento DASH, tales como su número. En el Apéndice A se especifica en su totalidad el formato de la carga útil RTP

Corrección de errores hacia delante

Una de las ventajas adicionales proporcionada en el sistema es la capacidad de usar una Corrección de Errores hacia Delante (^f E^c ) adaptativa. El sistema de Cabecera DASM 6 puede generar flujos de multidifusión adicionales que transporten información de FEC (por ejemplo, Pro-MPEG COP3) como protección contra errores de bits aleatorios persistentes. Estos flujos de FEC se anuncian en la Descripción de Presentación de Medios (MPD) junto con los flujos de multidifusión de RTP, y el Proxy de Cliente se puede suscribir a los mismos además de al grupo de multidifusión de RTP.

Esta técnica es especialmente útil para protocolos, tales como el RTP, en el que el protocolo de transporte subyacente (en este caso UDP) ofrece una protección limitada de la integridad de la carga útil de los datagramas. En última instancia, se puede configurar un esquema de FEC bidimensional para permitir la reconstitución de paquetes de RTP completos tras una pérdida en la red. El uso de la Corrección de Errores hacia Delante es un compromiso entre la tara de FEC y evitar la necesidad de recuperación (fetching) de unidifusión.

Arquitectura del cliente

La figura 3 muestra los bloques de software que constituyen el sistema de extremo-a-extremo DASM materializador, poniendo énfasis particularmente en el extremo receptor de la cadena. El sistema de extremo-aextremo comprende un servidor DASH 4 que se puede hacer funcionar para proporcionar contenido de unidifusión tal como se ha mencionado previamente. Este proporciona contenido en forma de segmentos DASH a un servidor DASM 6 que los formatea en paquetes de RTP adecuados para su distribución de multidifusión por parte de una red 12.

En el lado receptor, un Descodificador DASH 17 convencional está dispuesto para recuperar y descodificar segmentos DASH. El Proxy de Cliente DASM 8 es el componente que se describirá a continuación de forma más detallada. El Sistema Proxy de Cliente DASM 8 consiste, principalmente, en un proxy HTTP 20 que intercepta todas las solicitudes de contenido del Descodificador DASH 17. Obsérvese que el Proxy de Cliente DASM 8 es un bloque de sistema lógico que se asienta entre el Servidor DASH 4 (en la parte de más a la izquierda) y el Descodificador DASH (en la parte de más a la derecha); cuando no hay contenido de flujos DASH En Vivo de multidifusión, el Proxy de Cliente DASM está inactivo y efectivamente “fuera del circuito”.

El funcionamiento del Proxy de Cliente es el siguiente.

En primer lugar, el Proxy de Cliente 8 intercepta todas las solicitudes de recursos de MPD realizadas por el Descodificador DASH 17. Si la MPD devuelta por el servidor de origen 7 no contiene ninguna dirección de multidifusión (en el formato descrito en el Apéndice B), la misma se devuelve al Descodificador sin modificar por medio de un módulo de reescritura de MPD 21. El sistema DASM permanece inactivo, funcionando el Descodificador 17 en modo DASH de unidifusión adaptativo según la manera normal. No obstante, si la MPD contiene extensiones de direccionamiento de multidifusión DASM, el Proxy de Cliente 8 reescribe (o “diluye”) la MPD en el módulo de reescritura de MPD 21 de tal manera que haya solamente una Representación por Conjunto de Adaptación. El proceso de dilución racionaliza los elementos y atributos de la MPD original para eliminar duplicaciones e insertar de manera intencionada ambigüedades. (En el Apéndice B se enumeran las reglas de transformación para reescribir la MPD).

El Descodificador 17 “ve” solamente una Representación para cada Conjunto de Adaptación en la MPD diluida que recibe, aunque los Segmentos suministrados posteriormente al Descodificador por el Proxy de Cliente 8 podrían ser de cualquiera de las Representaciones disponibles en la MPD original, con cualquier velocidad de bits o resolución. Este aspecto de la forma de realización se basa en el uso de un Segmento de Inicialización que es común para todas las Representaciones, lo cual se corresponde con el caso del formato de entrada de muestra “avc3” del vídeo H.264, por ejemplo.

En segundo lugar, para cada Conjunto de Adaptación en el Periodo activo en ese momento, el Proxy de Cliente se suscribe a la dirección de multidifusión de la Representación más adecuada para las condiciones de red en curso, y reensambla las cargas útiles de los paquetes RTP recibidos de nuevo en los Segmentos DASH 29 originales usando un módulo Deserializador 24. La suscripción a una dirección de multidifusión la lleva a cabo un componente receptor de multidifusión 22. El receptor de multidifusión 22 incluye un módulo de gestión de suscripciones 23 y un módulo selector de Representaciones 27 que, juntos, permiten que el receptor de multidifusión 22 seleccione y se suscriba a la Representación de multidifusión más adecuada para cada Conjunto de Adaptación basándose en las condiciones de red prevalentes experimentadas por el Proxy de Cliente 8. Un módulo de monitorización de red 28 recibe una retroalimentación analizando el rendimiento de un módulo de recuperación de segmentos de unidifusión 26 así como información recibida del Deserializador 24 que recibe los paquetes RTP del(de los) grupo(s) de multidifusión con el(los) que se tiene suscripción en ese momento. Los Segmentos 29 completados que se han presentado en la salida del módulo Deserializador 24 se almacenan en una Memoria Caché de Segmentos que forma parte del componente Proxy HTTP 17 desde donde se pone a disposición para el Descodificador 17. Puesto que la recepción de datagramas de multidifusión puede que no se inicie inmediatamente, puede que se requiera una recuperación (fetching) de unidifusión para poblar la Memoria Caché de Segmentos con Segmentos completos en el mismo inicio de la sesión de presentación de medios y cuando el Proxy de Cliente decide conmutar a una Representación Diferente. Los Segmentos 14 de inicialización se recuperan siempre por medio de unidifusión. Además, cualquier pérdida de paquetes RTP detectada por el módulo Deserializador 24 durante una recepción de multidifusión se “parchea” por medio de solicitudes GET HTTP de intervalo de bytes, de unidifusión, usando un módulo parcheador de segmentos de unidifusión 25. Este parcheo se describe de forma más detallada posteriormente.

En tercer lugar, el Proxy de Cliente configura un conjunto de reglas de remapeo de URL en el módulo de reescritura URL 15 del componente Proxy HTTP 11 para la sesión de presentación de medios en cuestión. Las plantillas de URL en la MPD devuelta al Descodificador se manipulan de tal manera que la parte del anfitrión se convierte en un nombre de anfitrión local (por ejemplo, http://dasm.local/...) correspondiente con la Memoria Caché de Segmentos 20 del Proxy de Cliente. Esta disposición permite que el Proxy de Cliente garantice que los Segmentos se sirvan preferentemente al Descodificador desde la memoria caché local (alimentados por multidifusión) y la recuperación de unidifusión se utiliza únicamente como mecanismo de repliegue en caso de un error de memoria caché debido, por ejemplo, a un fallo en la recepción de multidifusión. Los URL locales trasladados al Descodificador 17 mantienen un contexto suficiente para permitir que el Proxy de Cliente identifique la presentación de medios, la Sesión y el Conjunto de Adaptación particulares, de interés para el Descodificador. Esto permite que un único Proxy de Cliente gestione simultáneamente múltiples sesiones de presentación de medios, diferentes. También permite que el Proxy de Cliente preste servicio a múltiples Descodificadores que solicitan al mismo tiempo la misma presentación de medios con una tara reducida. El módulo selector de Representaciones 27 mantiene el estado de qué Representación está en curso para cada Conjunto de Adaptación y, de este modo, puede reconstruir el URL DASH original para cualquier Segmento solicitado que no se pueda localizar en la Memoria Caché de segmentos del Proxy HTTP 11. A continuación, se pueden recuperar segmentos ausentes, del Servidor DASH 4, usando el módulo recuperador de segmentos de Unidifusión 26 bajo la dirección del Módulo de Control de recuperación de Unidifusión 19.

En cuarto lugar, el Módulo de Reescritura de MPD 21 manipula el tiempo de inicio de la presentación de medios señalizado en la MPD original (el “tiempo de inicio de disponibilidad”) a medida que pasa a través del Proxy de Cliente en su camino al Descodificador. Esto da al Proxy de Cliente la oportunidad de introducir un retardo artificial en la presentación de medios. Esto es importante a la hora de conceder al Proxy de Cliente 8 tiempo adicional para recibir y reensamblar paquetes RTP de multidifusión en los Segmentos DASH originales antes de que el Descodificador lo solicite. El retardo adicional que introduce esta manipulación de tiempo en el sistema de extremoa extremo es un precio que se paga por el aumento de la escalabilidad.

Secuencia de funcionamiento del proxy de cliente

La figura 4 muestra el flujo de mensajes según es gestionado por el Proxy de Cliente 8.

Etapa 1. Recuperación de MPD: el Descodificador DASH solicita una MPD 40, y el Proxy de Cliente DASM traslada la solicitud al Servidor DASH. No obstante, la Descripción de Presentación de Medios (MPD) devuelta es interceptada por el Proxy de Cliente y analizada por el “proceso de dilución” 41. Si hay presencia de direcciones de puntos extremos de multidifusión, la MPD se “diluye” antes de devolverla al Descodificador 42. Cada Conjunto de Adaptación se reduce a una única Representación Sintética con una plantilla de URL de la forma http://dasm.local/<sessionID>/<availabilityStartTime>/<AdaptationSetID><Segment ID> en lugar de apuntar al Servidor DASH original. La información contenida en la m Pd se almacena también en el Proxy de Cliente como configuración de multidifusión 50 para la sesión de presentación de medios y configuración de mapeo para el Periodo 51 en curso. En caso contrario, el recurso de MPD se devuelve sin modificar al Descodificador DASH.

Etapa 2: Recuperación de Segmento de Inicialización Común: cuando el Descodificador solicita el Segmento de Inicialización para la Representación Sintética de un Conjunto de Adaptación dentro de la MPD “diluida”, el Proxy de Cliente interpreta 52 esto como el inicio de la Sesión de presentación de medios y ordena al componente Receptor de Multidifusión 22 que se suscriba al flujo de multidifusión correspondiente a la Representación seleccionada en ese momento para el Conjunto de Adaptación en cuestión. El Segmento de Inicialización Común se devuelve sin modificar al Descodificador 53.

Etapa 3. Recuperación de Segmento de Medios: puesto que la MPD modificada que se ha trasladado al Descodificador se ha reescrito para que contenga solamente URLs locales de la forma http://dasm.local/..., todas las solicitudes de Segmento 49 son interceptadas por el Proxy de Cliente 8.

Etapa 3a. Recuperación de Segmento de Medios (Caso correspondiente a error de memoria caché): si el Segmento solicitado no está presente en la Memoria Caché de segmentos del Proxy HTTP debido a que el Segmento no se ha recibido por multidifusión (por ejemplo, en caso de que el Proxy de Cliente esté esperando a que aparezca el primer Segmento de multidifusión en el inicio de una sesión de presentación de medios, o inmediatamente después de conmutar a una Representación de multidifusión diferente), el módulo de reescritura de URL 54 usa la identidad de la Representación seleccionada en ese momento combinada con la configuración de mapeo 51 almacenada previamente para mapear el URL local con el URL de origen del Segmento original. A continuación, este URL externo es usado por el Proxy de Cliente en una recuperación de unidifusión del Segmento DASH completo, que se devuelve al descodificador, y se almacena también en la Memoria Caché de segmentos del Proxy HTTP 11.

Dentro del Proxy de Cliente 8 hay un reloj (el “Reloj de Segmentos”) que controla el plazo límite para la disponibilidad de Segmentos. Se deriva del Receptor de Multidifusión para cada Representación (el Deserializador 24) y la duración de Segmentos dentro de cada Representación (transportada en forma de metadatos en la MPD). Si se alcanza un plazo límite definido (antes de cuando se espera que el descodificador pida un Segmento) sin que el Receptor de Multidifusión suministre al siguiente Segmento, el módulo de control de recuperación de unidifusión 19 solicitará el Segmento completo por medio del módulo de recuperación de segmentos de unidifusión 26 para evitar este caso de error de memoria caché.

Etapa 3b. Recuperación de Segmento de Medios (Caso de acierto de memoria caché): este es el caso en el que, desde la Memoria Caché de Segmentos del Proxy HTTP 11, se puede servir una solicitud del Descodificador en relación con un Segmento DASH 49. En este, el caso preferible, el Segmento Solicitado ya se ha colocado en la memoria caché por parte del Receptor de Multidifusión 22 según se ha descrito anteriormente, con todas las partes ausentes del Segmento parcheadas por medio de una solicitud GET HTTP de unidifusión de intervalo de bytes 47.

El Descodificador DASH ve solamente una Representación para cada Conjunto de adaptación en la MPD manipulada. En función de las elecciones realizadas por el módulo selector de representaciones 27, cada Segmento suministrado al Descodificador podría ser de una Representación diferente con una resolución o velocidad de bits diferente. Para lograr una experiencia de visionado uniforme y consistente, el sistema confía en que el Descodificador pueda descodificar cada Segmento como una entidad individual, y no confiando en los metadatos proporcionados por un archivo de MPD. Una forma de lograr esto en el caso del vídeo H.264 es el uso del formato de entrada de muestra “avc3” y de un Segmento de Inicialización Común que es el mismo para todas las Representaciones en un Conjunto de Adaptación dado.

Política de conservación de la memoria caché de segmentos

A medida que una sesión de presentación de medios particular progresa, la Memoria Caché de Segmentos del Proxy HTTP 11 tenderá a llenarse con Segmentos. El Proxy de Cliente DASM puede proporcionar un Módulo Recolector de Basura que limite automáticamente el tamaño de la Memoria Caché de segmentos borrando Segmentos antiguos. Típicamente, los Segmentos se borrarán en el mismo orden en el que se recibieron, aunque no es necesario que sea así. Este Recolector de Basura puede ser agresivo, eliminando Segmentos poco tiempo después de su tiempo de presentación, o puede permitir deliberadamente que los Segmentos permanezcan en la memoria caché durante un periodo prolongado. Al conservar Segmentos durante un tiempo breve, el Proxy de Cliente puede prestar servicio eficientemente a varios Descodificadores que están consumiendo, todos ellos, la misma presentación de medios aproximadamente al mismo tiempo. Típicamente, este escenario es el caso correspondiente a un visionado en vivo. Conservando Segmentos durante un periodo mayor, el Proxy de Cliente puede prestar servicio a solicitudes de “rebobinar” los medios sin recurrir al Servidor DASH como resultado de un error de memoria caché. Cuanto mayor sea el periodo de conservación de los Segmentos, más tiempo estará disponible la memoria intermedia de rebobinado para una presentación de medios particular.

Despliegue del conversor de lado del cliente

El conversor de lado del cliente en forma del Proxy de Cliente DASM 8 se podría desplegar en al menos tres formas diferentes, todas ellas dentro del alcance de la forma de realización, según se muestra en las figuras 5, 6 y 7.

La figura 5 muestra una variante en la que el Proxy de Cliente está ubicado conjuntamente con el Descodificador. En este escenario de despliegue, el Proxy de Cliente se asienta junto al Descodificador en forma de un módulo lógico incorporado dentro de una unidad de adaptación del televisor, un receptor de televisión integrado o un dispositivo similar. El Descodificador se debe configurar explícitamente para usar el Proxy de Cliente para todas las solicitudes HTTP, de manera que se puedan interceptar solicitudes de MPD y la MPD “diluida” se pueda devolver al Descodificador, y de manera que todas las solicitudes de Segmentos se redirijan también al Proxy de Cliente.

La figura 6 muestra una variante en la que el Proxy de Cliente está integrado con un dispositivo de Pasarela Residencial. Para propiedades domésticas y oficinas en las que hay, potencialmente, muchos dispositivos de visionado que acceden simultáneamente a diferentes presentaciones de medios, pueden resultar apropiado desplegar el Proxy de Cliente en el dispositivo de Pasarela Residencial. Algunos dispositivos de encaminamiento de Pasarelas Residenciales no trasladan, por defecto, el tráfico de multidifusión a la red doméstica, ya sea por diseño o ya sea a través de una configuración por parte del Proveedor de Servicios de Internet que ha suministrado y aprovisionado la Pasarela Residencial. Esta variante suministra datagramas de multidifusión a un sitio tan lejano como la Pasarela Residencial, pero no directamente a dispositivos en la red doméstica.

La Pasarela Residencial está ubicada idealmente para interceptar solicitudes de Descodificadores DASH individuales e implementar la función de Proxy de Cliente DASM de forma transparente para todos ellos. La pérdida de eficiencia por no transportar tráfico de multidifusión dentro de la red doméstica se puede compensar con el aumento de la comodidad de funcionamiento para el ISP Al conservar Segmentos en una pequeña memoria caché ubicada en el Proxy de Cliente durante un periodo de tiempo breve, múltiples Descodificadores pueden visionar casi simultáneamente la misma presentación de medios en vivo con una tara muy reducida.

La figura 7 muestra una variante en la que la función de Proxy de Cliente se implementa dentro de un dispositivo de red ISP De manera similar a la variante previamente descrita, el Proveedor de Servicios de Internet podría no habilitar tráfico de multidifusión sobre líneas de abonado entre el DSLAM y la Pasarela Residencial. En este caso, o en casos similares, la función de Proxy de Cliente DASM se podría desplegar dentro de la red del Proveedor de Servicios de Internet en un punto que resulte más idóneo para los Requisitos de gestión de Tráfico del Proveedor de Servicios de Internet. La figura 7 ilustra un despliegue del Proxy de Cliente DASM del tipo mencionado en el borde de la red, para aprovechar de manera óptima la transmisión de multidifusión a través de la red central del ISP En otras variantes, el Proxy de Cliente se despliega progresivamente más cerca del sistema de Cabecera, reduciéndose de manera correspondiente, como consecuencia, la región de la red que transporta tráfico de multidifusión.

Funcionamiento de recepción

La suscripción a un flujo de multidifusión se logra por parte del subsistema de recepción, por ejemplo, el módulo Deserializador 9 dentro del Proxy de Cliente DASM 8, emitiendo un mensaje de Incorporación IGM^p [IETF RFC 3376] hacia el rúter de su pasarela. Puesto que es necesario que el mensaje IGMP se propague a través de la red 12 hacia el punto de encuentro de multidifusión más cercano, no hay ninguna garantía de cuándo se encaminarán de vuelta los primeros paquetes RTP a través de la red y los mismos serán recibidos por el Proxy de Cliente. Además, el primer paquete RTP recibido tiene solamente una posibilidad de 1 entre N (donde N es el número de paquetes RTP que constituyen el Segmento DASH original) de transportar el inicio de un Segmento nuevo, y, por lo tanto, de contener los campos de encabezamiento RTP esenciales para iniciar el reensamblaje de paquetes RTP en Segmentos DASH. Por lo tanto, la primera parte de la estrategia de recepción de multidifusión es esperar que al menos el primer Segmento sea suministrado a la Memoria Caché de Segmentos mediante una recuperación de unidifusión. Esto se produce para todos los Conjuntos de Adaptación seleccionados en el inicio de una sesión de presentación de medios nueva y, posteriormente, siempre que se cambia la Representación para un Conjunto de Adaptación particular durante la sesión.

Cuando el módulo selector de Representaciones 27 decide terminar la recepción de un flujo de multidifusión particular, se emite un mensaje de Abandono IGMP hacia el rúter de la pasarela y, entonces, prosigue un periodo desconocido entre la emisión de la solicitud y el cese real de la recepción RTP sobre el enlace de la red. Para evitar un solapamiento de datagramas que forman parte del flujo previo y los correspondientes del siguiente flujo (y, por lo tanto, la saturación del enlace de red), la segunda parte de la estrategia de recepción de multidifusión es incorporar un retardo artificial entre los dos flujos de multidifusión (del orden de unos pocos segundos, lo cual equivalente a uno o más Segmentos DASH). Este espacio se rellenará usando parcheo y recuperación de unidifusión según resulte adecuado. El Proxy de Cliente DASM puede precisar la longitud de este retardo durante el transcurso de una sesión de presentación de medios para adecuarse a la configuración de la red informándose sobre la latencia con la que se actúa sobre los mensajes IGMP

Cambio de representación

Una característica particular de una forma de realización de la invención es la capacidad de detectar la necesidad de cambiar de una Representación a otra en función de las condiciones prevalentes de la red. En referencia nuevamente a la figura 1 con vistas a una ejemplificación más sencilla, el Proxy de Cliente 8 puede detectar que hay condiciones de red adversas y, así, seleccionar una Representación de multidifusión inferior para su presentación al cliente final 10. Esto se realiza de una manera que es transparente para el cliente final 10. El Cliente DASH 10 simplemente recibe Segmentos de la Representación seleccionada en ese momento desde el Proxy de Cliente 8 usando solicitudes y respuestas de unidifusión, y, por lo tanto, no tiene conocimiento de que se produzcan cambios en la Representación.

El cambio de una Representación a otra se entiende mejor con respecto a las figuras 8 a 13 que muestran esquemáticamente Segmentos de multidifusión y unidifusión en relación con el tiempo.

La responsabilidad de cambiar de Representación reside en un componente lógico del Proxy de Cliente 8 denominado selector de Representaciones 27, cuya implementación se describe de forma más exhaustiva posteriormente.

Las figuras 8 a 13 muestran las ventajas proporcionadas por el Proxy de Cliente 8 que gestiona la conversión entre la unidifusión solicitada por el cliente y la multidifusión recibida a través de la red. Además, se describen procesos mediante los cuales pueden usarse segmentos de unidifusión cuando se comienza o finaliza una suscripción a un flujo de multidifusión, o cuando se conmuta entre flujos de multidifusión de calidades diferentes. Los procesos expuestos en relación con las figuras 8 a 13 son llevados a cabo por el selector de Representaciones 27.

La decisión de cambiar aumentando a una representación con velocidad de bits más alta puede ser tomada por el selector de Representaciones si condiciones detalladas de la red sugieren que no hay ningún problema con el encaje del flujo de multidifusión previamente seleccionado en la capacidad disponible de la red. Una situación de este tipo se muestra con la recepción plana y uniforme del Segmento 1 en el lado izquierdo de la figura 8. Consecuentemente, después de abandonar el grupo de multidifusión en curso, todos los paquetes RTP recibidos hasta el momento para el siguiente Segmento son utilizables, y si los paquetes RTP es interrumpen antes de que se haya completado el último paquete de este Segmento (Segmento 2 en la figura), la disposición completa las partes ausentes por medio de un parche de intervalo de bytes de unidifusión (la sección restante del Segmento 2 en la figura 9). Por lo tanto, el proceso para abandonar sin discontinuidades un flujo de multidifusión se puede resumir como la emisión de una solicitud de Abandono IGMP, la determinación de si se han recibido Segmentos Completos y, si se interrumpe el suministro de paquetes antes de que se haya completado el último paquete, la emisión de una solicitud específica de la parte ausente de ese Segmento, en este ejemplo usando una solicitud de intervalo de bytes. De esta manera, el Proxy de Cliente puede abandonar de manera limpia un flujo de multidifusión.

El selector de Representaciones 27 determina un flujo adecuado de velocidad de bits más alta al que incorporarse y emite una solicitud de Incorporación IGMP. Por lo tanto, el proceso de incorporación al grupo de multidifusión nuevo se puede resumir con las etapas llevadas a cabo por el Proxy de Cliente, consistentes en emitir una solicitud de Incorporación para incorporarse a un flujo de multidifusión, determinar si cualquier Segmento recibido inicialmente está incompleto y, en caso afirmativo, descartar paquetes de un Segmento incompleto y, en su lugar, recuperar los mismos por medio de una solicitud de unidifusión. Tal como se observa en la figura 9, el resultado es que un Segmento recibido parcialmente (Segmento 2) recibido mediante multidifusión se completa con una solicitud de parche de manera que se solicitan partes ausentes por unidifusión para completar ese Segmento. Obsérvese que el Segmento de unidifusión se solicita con la velocidad de bits original (inferior) con el fin de minimizar cualquier congestión que pueda surgir de la red. Los Segmentos subsiguientes que no se reciben (en su totalidad o parcialmente) se recuperan por unidifusión hasta que se establezca el flujo de multidifusión nuevo. Se produce una incorporación al grupo de multidifusión nuevo (en este caso usando una Incorporación IGMP) pero, en este ejemplo, no comienzan a llegar paquetes RTP hasta que se está a medio camino del Segmento 5 (véase nuevamente la figura 8). Consecuentemente, faltan los Segmentos 3, 4 y 5. El receptor de Multidifusión 22 determina este hecho y capta los segmentos ausentes correspondientes al Proxy de Cliente DASM usando una recuperación de unidifusión DASH. Los paquetes finales del Segmento 5 que llegan por multidifusión (zona sombreada del Segmento 5 en la figura 8) se deben descartar ya que los metadatos iniciales no se han recibido por multidifusión.

La figura 10 ilustra la velocidad de bits ligeramente más alta generada por el Proxy de Cliente durante la recuperación (fetching) de unidifusión de los Segmentos 3 y 4, y también el inicio del Segmento 5 debido a un enventanado TCP que, típicamente, se disparará hasta la velocidad de línea disponible. Es necesario que el suministro de multidifusión (Segmentos 6 en adelante) se acomode ligeramente por debajo de esta velocidad de línea para garantizar un suministro eficiente por medio de multidifusión únicamente. (En realidad, la diferencia entre la velocidad de unidifusión de pico y la velocidad de multidifusión alcanzable puede ser mucho menor que lo mostrado, o incluso insignificante, en función de las condiciones reales de la red).

Obsérvese también que la compleción del Segmento 2 se logra por medio de “ráfagas” de unidifusión - esto también puede ocurrir a la misma velocidad que el 3, 4 y el 5 y únicamente se muestra a una velocidad ligeramente inferior en la figura para diferenciar entre el parcheo de un Segmento que ya se ha recibido parcialmente por medio de multidifusión (Segmento 2) y la recuperación de un Segmento completo (Segmentos 3 y 4).

En las figuras 12 y 13 se muestra el proceso de cambio de una representación de mayor calidad a una Representación de menor calidad (y, por lo tanto, menor velocidad de bits). Nuevamente, el selector de Representaciones 27 del Proxy de Cliente 8 puede determinar que las condiciones de la red son tales que la transmisión de multidifusión recibida en ese momento no se puede recibir adecuadamente con una velocidad suficiente o sin errores. Por lo tanto, el selector de Representaciones puede determinar una suscripción a un flujo de multidifusión de menor calidad. Un cambio bajando a una Representación de velocidad de bits menor se activa, por lo tanto, por cuestiones tales como una capacidad de red reducida (es decir, congestión) o un aumento de la tasa de errores. Esto se indica con la región quebrada de la izquierda de la figura 13. Por ello, no se puede completar ningún Segmento Incompleto por multidifusión con la velocidad requerida y, en circunstancias extremas, incluso puede que no sea posible rellenar las partes ausentes del Segmento antes del plazo o límite requerido usando un parche de unidifusión. Para cumplir el plazo límite de disponibilidad del Segmento en la Memoria Caché de Segmentos, el Proxy de Cliente puede solicitar, por lo tanto, un segmento de una Representación de velocidad de bits mucho menor en una ráfaga (obsérvese la Representación de velocidad de bits inferior indicada con el Segmento 2 en la figura 12, y el suministro, con velocidad en ráfaga, del mismo Segmento en la figura 13).

Preferentemente, el sistema no permitiría que la Representación alcanzase dicho estado de desadaptación con la velocidad de bits disponible de la red, reaccionando antes, en cambio, para bajar a una Representación de velocidad menor, y repetir esta etapa hasta que el sistema se asiente en un mínimo de uso de unidifusión. La utilización de este planteamiento debería evitar la necesidad de una solicitud de unidifusión de un Segmento de calidad Inferior a la deseada.

Obsérvese también, en la figura 13, cómo la recuperación por unidifusión del Segmento 5 (el Segmento de relleno final suministrado por unidifusión antes de que el flujo de multidifusión tome el mando) puede solaparse potencialmente con los Segmentos RTP descartados del Segmento 5 (figura 11) para crear un pico de velocidad de línea claramente por encima de la velocidad de bits inferior de la siguiente Representación seleccionada.

Por lo tanto, el proceso de cambio de una representación de multidifusión de alta calidad a una calidad inferior se puede resumir como la determinación, dentro del Proxy de Cliente, de que la representación en curso que se está recibiendo no se puede mantener debido a las condiciones prevalentes de la red, la emisión de una solicitud para interrumpir la recepción de una representación y la emisión de una solicitud para incorporarse a una Representación de velocidad de bits inferior, la determinación de si se han recibido segmentos completos de la Representación nueva, y la emisión de una solicitud de unidifusión, desde el Proxy de Cliente, en relación con cualesquiera segmentos que no se hayan recibido de manera completa entre el abandono de un flujo de multidifusión y la incorporación al flujo de multidifusión nuevo.

Terminación de una presentación de medios

No hay ninguna señal explícita especificada por el DASH MPEG para terminar una sesión de presentación de medios. El cliente simplemente deja de solicitar Segmentos del Servidor DASH y esto, implícitamente, marca el final de la sesión. Por lo tanto, el Proxy de Cliente DASM 8 debe utilizar una heurística adecuada para determinar que un Descodificador 17 particular ya no desea continuar con una sesión de presentación de medios, por ejemplo, registrando el tiempo de la solicitud de Segmento de unidifusión más reciente desde el Descodificador. Después de que haya transcurrido un periodo adecuado de inactividad del cliente en relación con una presentación de medios (el “periodo de temporización”), el receptor de Multidifusión 23 puede darse de baja, de manera segura, de cualesquiera flujos de multidifusión y dejar de solicitar Segmentos del Servidor DASH 4. Si más de un Descodificador está consumiendo la misma presentación de medios al mismo tiempo, todas las sesiones activas referentes a la misma MPD deben alcanzar este periodo de temporización antes de que el Proxy de Cliente pueda terminar la presentación.

Implementación de la cabecera de ASM

La Cabecera DASM es un conversor que emite solicitudes, por unidifusión, de contenido y pone las mismas a disposición a través de multidifusión para la red. En referencia, de nuevo, brevemente, a la figura 1, el conversor de lado del servidor en forma de la Cabecera DASM 6, según se ha descrito previamente, comprende un Cliente DASH modificado 13 que solicita, mediante solicitudes de unidifusión, contenido de un servidor 4 y presenta las mismas, en forma de paquetes de multidifusión RTP, a una red 12. A continuación se describe una implementación de esta Cabecera.

La Cabecera DASM puesta en práctica se basa en el marco de medios de código abierto GStreamer. Un módulo de GStreamer personalizado y que se denomina “dash_client”, basado en el módulo “dashdemux”, implementa una función de Cliente DASH simple. Esta módulo lee un recurso de MPD y crea una canalización (pipeline) de medios interna para cada Representación enumerada para cada Conjunto de Adaptación en el Periodo en curso. La cabecera vuelve a leer la MPD hacia el final del periodo en curso y ajusta el número de canalizaciones para adaptarse al siguiente periodo en caso de que haya habido un cambio. La figura 14 ilustra una sesión de presentación de medios de ejemplo con un Conjunto de Adaptación de vídeo que comprende tres Representaciones codificadas y un Conjunto de Adaptación de audio que comprende dos Representaciones. Esto da como resultado la creación, por parte del dash_client, de un total de cinco canalizaciones de medios de GStreamer.

Cada canalización de medios es responsable de recuperar Segmentos DASH para la Representación apropiada, de fragmentarlos en cargas útiles de paquetes RTP, y de proporcionar un flujo regulado de datagramas Ud P a un socket de red con la dirección IP de destino de Multidifusión y el número de puerto de destino correspondientes. A continuación, la información de direccionamiento de punto extremo de multidifusión para cada Representación se inserta en la MPD original según se muestra en la figura 2 (usando extensiones DASM del esquema XML MPD) y, a continuación, esta MPD extendida se publica por medio de un servidor HTTP. (Este podría ser, por ejemplo, el mismo servidor HTTP que el Servidor DASH). La “dosificación” de los paquetes RTP se logra tomando el atributo Duración del Segmento (señalizado en la MPD) y dividiendo el tamaño total del Segmento por el tamaño máximo de la carga útil RTP permitido por la red. A continuación, el número resultante de paquetes RTP se reparte uniformemente en el tiempo a lo largo de la Duración pretendida del Segmento, con lo cual se minimizan las ráfagas globales de la transmisión por multidifusión.

Funcionamiento del Proxy de Cliente DASM

Se ha diseñado una forma de realización del Proxy de Cliente DASM 8 descrito en relación con la figura 3, usando técnicas orientadas a objetos UML, y la misma se ha implementado usando el lenguaje de programación Python.

A continuación, se describirá el funcionamiento del Proxy de Cliente 8 en relación con el diagrama de mensajes mostrado en la figura 4. Este diagrama muestra el flujo de mensajes de un Descodificador 17 que está citando contenido de un Servidor de Origen mostrado aquí como Servidor de Origen4. Para facilitar la descripción del flujo de mensajes, se observa que la figura 4 muestra los componentes en el orden opuesto a las figuras restantes, mostrándose el Descodificador de Cliente 17 a la izquierda y mostrándose el Servidor de Origen 4 a la derecha de manera que las solicitudes se desplazan de izquierda a derecha y las respuestas del Servidor de Origen se desplazan de derecha a izquierda. La Cabecera 6 se omite en su totalidad de la figura 4.

En primer lugar, el Descodificador 17 solicita una MPD y esta solicitud 40 es interceptada por el Proxy de Cliente DASM 8 el cual, a continuación, realiza la solicitud de la MPD al Servidor DASH 4 en nombre del Descodificador. Si la MPD recibida contiene información de direccionamiento de punto extremo de multidifusión, entonces la misma se reescribe en un “formato de Representación única indiferente a la velocidad de bits, por Conjunto de Adaptación” por parte del módulo de reescritura de MPD 21, y esta versión “diluida” 42 se devuelve al descodificador. Como efecto secundario de esta “dilución” de la MPD, se almacena en el Proxy de Cliente DASM un mapeo de Representación-a-multidifusión 51. De lo contrario, si no hay puntos extremos de multidifusión, entonces la MPD se devuelve sin modificar al descodificador.

El Descodificador 17 solamente verá, en cada momento, una MPD por solicitud, y, por lo tanto, podrá funcionar sin fisuras en modo de perfil Bajo Demanda o En Vivo sin modificaciones. El receptor de Multidifusión 22 selecciona el flujo de multidifusión de partida 44 apropiado al que suscribirse, sobre la base de información anterior de la condición de red 45 y una estimación de una tasa de errores baja sostenible y una velocidad de bits exenta de contiendas. El Proxy de Cliente emite un mensaje de Incorporación IGMP para cada Representación a la que se incorpora (uno para cada Conjunto de Adaptación seleccionado para la presentación). Esta solicitud IGMP se envía al rúter de la pasarela local que, a su vez, establece la ruta para recibir el flujo de multidifusión.

El Proxy de Cliente recupera Segmentos DASH completos mediante unidifusión 46 hasta que recibe un paquete RTP con el conjunto de bits de encabezamiento de extensión, que indica el inicio de una secuencia de paquetes que contienen un Segmento DASH completo.

El módulo receptor de Multidifusión 22 del Proxy de Cliente es responsable de reensamblar los paquetes RTP recibidos en el Segmento DASH original. Si algunos paquetes faltan o están dañados, se emite una solicitud GET HTTP de intervalo de bytes 47 para parchear el agujero en la recepción.

El Segmento DASH completo se traslada al Proxy HTTP 20 donde se almacena en una Memoria Caché de segmentos, disponible para ser recuperado por el Descodificador usando una GET HTTP de unidifusión 49 convencional.

A continuación, el Proxy de Cliente evalúa si las condiciones de la red siguen siendo apropiadas para el flujo de Representación de multidifusión recibido en ese momento. En caso afirmativo, el proceso continúa reensamblando Segmentos DASH a partir de paquetes RTP. El caso negativo, entonces emite una solicitud de Abandono IGMP hacia el rúter local, y una Incorporación IGMP para el flujo de Representación de multidifusión más apropiado (velocidad de bits mayor o menor). A continuación, el Proxy de Cliente recupera Segmentos DASH por medio de la GET HTTP de unidifusión 46 hasta que recibe un paquete RTP 44 que contiene el inicio de un Segmento DASH (y repite el proceso anterior).

Respaldando el diseño del Proxy de Cliente se encuentra un impulso de reloj (el Reloj de Segmentos) controlado por el tiempo en el que se debe suministrar el siguiente Segmento DASH al Descodificador para su presentación. En otras palabras, sobre la base del atributo Duración de cada Conjunto de Adaptación, existe un plazo límite de suministro y este dirige la toma de decisiones del Proxy de Cliente, incluyendo si completar un Segmento usando unidifusión, o adicionalmente como entrada a los algoritmos de cambio de Representación. Existe un Reloj de Segmentos para cada Conjunto de Adaptación.

Deserializador

En referencia a la figura 3, el Deserializador 24 es el módulo receptor de Multidifusión responsable de abrir un socket de red, de suscribirse al flujo de multidifusión, de recopilar los paquetes RTP recibidos, de reensamblarlos en el Segmento DASH 29 original y de colocar los mismos en la Memoria Caché de segmentos del Proxy HTTP 20. El Deserializador también inicia solicitudes hacia el módulo parcheador de Segmentos 25 para emitir solicitudes de intervalos de bytes GET HTTP de unidifusión con vistas a parchear las partes ausentes de cualesquiera paquetes RTP ausentes o erróneos. El Deserializador inicia también solicitudes hacia el módulo de control de recuperación de Unidifusión 19 cuando no se ha recibido un Segmento antes del plazo límite fijado por el Reloj de Segmentos. El Segmento ausente se recupera directamente del Servidor DASH 4 por parte del módulo de recuperación de segmentos de Unidifusión 26.

El Deserializador emite eventos de notificación cuando recibe un paquete RTP con los marcadores de inicio en los encabezamientos, un paquete RTP con el marcador de fin en los encabezamientos o cuando emite una solicitud HTTP-GET de intervalo de bytes (para indicarlo a módulos de recogida de estadísticas cuando ha encontrado un error). Esta información es usada por el Módulo de monitorización de red 28 que se describe a continuación.

Monitorización de la red

El Proxy de Cliente 8 monitoriza condiciones prevalentes de la red usando un módulo de monitorización de red 28 (mostrado en la figura 3) para determinar la Representación apropiada a seleccionar. A continuación, se describirá el funcionamiento de esta monitorización de la red.

El Módulo de monitorización de red recopila estadísticas sobre velocidades de recepción para paquetes TCP y UDP, así como tasas de error sobre la recepción RTP (por medio de los eventos de Deserializador antes descritos). El módulo monitoriza las condiciones prevalentes de la red, tales como la pérdida de paquetes y la velocidad de bits, tomando tantos estadísticos de la red como sea posible tanto de los ficheros registro del sistema operativo como de bloques funcionales dentro del propio Proxy de Cliente DASM. El Módulo de monitorización de red da salida a una “previsión de red” hacia el selector de Representaciones 27 que tomará decisiones sobre la repartición apropiada de la velocidad de bits predicha entre los Conjuntos de Adaptación requeridos.

Posibles entradas para el Módulo de monitorización de red incluyen estadísticos de la pila de red del sistema operativo, tales como la tasa de pérdida de paquetes y cualquier cosa relacionada con la tasa de errores de bit. En este contexto pueden resultar útiles tanto el historial reciente como las tendencias a largo plazo. Entradas adicionales podrían incluir estadísticos de recepción de paquetes del Deserializador, tales como la tasa de pérdida de paquetes, la velocidad de bits medida para la recuperación y el parcheo de Segmentos por unidifusión, y el tamaño y la frecuencia de esos parches.

Además de poner a disposición estos estadísticos sin tratar, el Módulo de monitorización de red también expone un resumen agregado de condición de la red en forma de una velocidad de bits de red predicha.

Manteniendo un registro de qué velocidad de bits se logra en ranuras de tiempo diarias particulares (por ejemplo, durante la parte central de la mañana cuando las contiendas se situarán en su punto más bajo, de las 3 a las 5 pm cuando los niños han vuelto a casa o el tradicional pico de la tarde a partir de la 7 pm), el Proxy de Cliente puede realizar una estimación de cuál es la velocidad más probable “partiendo de cero”. Esto es particularmente útil para estimar la velocidad de bits alcanzable cuando se cambia de Representaciones.

Selector de representaciones

La función principal llevada a cabo por el módulo selector de Representaciones 27 es determinar el flujo de multidifusión de velocidad de bits más alta que se puede recibir desde el Servidor de cabecera DASM 6 sin una pérdida apreciable de paquetes. Como ya se ha explicado, la forma de realización supera el problema de no disponer de un control directo sobre la Calidad de Servicio dentro de la capa de red observando el comportamiento de la red y reaccionando al mismo.

Preferentemente, el módulo selector de Representaciones se puede hacer funcionar para implementar un algoritmo configurable que selecciona una Representación apropiada sobre la base de condiciones prevalentes de la red. Al facilitar una experimentación con una pluralidad de estrategias de selección de Representaciones, este planteamiento de diseño permite comparar en paralelo el rendimiento de diferentes algoritmos bajo condiciones controladas de prueba de la red y seleccionar los mejores para el despliegue.

Preferentemente, el algoritmo configurable es modular en el sentido de que el algoritmo se puede sustituir fácilmente, tal como mediante la descarga de un algoritmo nuevo al Proxy de Cliente. Un ejemplo particular de esto sería implementar el Proxy de Cliente en una unidad de adaptación del televisor y proporcionar la capacidad de instalar de manera remota algoritmos de selección de Representaciones en la unidad de adaptación del televisor.

El objetivo del selector de Representaciones es maximizar la calidad de audio/vídeo presentada al espectador dentro de las restricciones de la velocidad de bits disponible, aunque, al mismo tiempo, minimizando la frecuencia de cambios de la Representación y el tamaño del espacio entre Representaciones seleccionadas de manera que el espectador no perciba cambios repentinos y regulares en la calidad del audio/vídeo.

El funcionamiento práctico del sistema DASM indica que se logra una mejor experiencia de visionado con cambios más pequeños por incrementos en la Representación que con grandes saltos en la calidad. Además, se ha apreciado que algunos cambios por incrementos entre la Representación pueden ser percibidos por el espectador como “grandes” particularmente si los mismos se implican un aumento o una reducción de la resolución de vídeo, o entre audio estéreo y 5.1; la reducción al mínimo de dichos saltos puede tenerse en cuenta de manera provechosa en las decisiones sobre la velocidad de aumentar y rebajar las Representaciones.

Las entradas para el selector de Representaciones incluyen notificaciones recibidas de otros módulos en el Proxy de Cliente en forma de eventos asíncronos, más particularmente:

• Evento de Cambio de Velocidad de Bits recibido del módulo de monitorización de Red, que indica cambios en la velocidad de bits de red. El cálculo de esto tiene en cuenta velocidades de recepción de datagramas UDP para todos los grupos de multidifusión suscritos en ese momento y la velocidad del caudal TCP para la recuperación por unidifusión y el parcheo por unidifusión.

• Evento de Deserializador recibido del módulo de Deserializador, que indica el tiempo de recepción para paquetes RTP, y el tamaño y la frecuencia de pérdida de paquetes.

El selector de Representaciones también sondeará el módulo de monitorización de Red para averiguar la velocidad de bits estimada en curso para el Proxy de Cliente en conjunto o para determinar la velocidad de bits medida promedio sobre una ventana de tiempo especificada (dada en parámetros).

Adicionalmente, el módulo selector de Representaciones puede descubrir las Representaciones disponibles en el Periodo en curso para cada Conjunto de adaptación.

Consideraciones en el diseño de un algoritmo de selección de representaciones

A continuación, se describen algunas consideraciones en el proceso de toma de decisiones del algoritmo de selección de Representaciones.

A partir de las entradas disponibles hay dos conjuntos de estadísticos: en primer lugar, estadísticos de pérdida de paquetes promediados tanto a través de un periodo de tiempo como sobre sus características de frecuencia (bloques de datos “por ráfagas”, contiguos, perdidos, o patrones regulares/aleatorios). En segundo lugar, estadísticos de velocidad de bits promedio a través de una ventana de tiempo definida (almacenada como un valor interno, por ejemplo, “ventana de interés”).

Hay más respuestas de realimentación negativas que positivas y revelan cuándo la Representación en curso es demasiado alta para las características en curso de la red. El caso en el que hay capacidad para una Representación de velocidad de bits mayor resulta más difícil de predecir y puede implicar aumentos exploratorios por incrementos en el uso de la velocidad de bits, por ejemplo, desplazándose en sentido ascendente hasta que se observe una pérdida de paquetes correlacionada. Una de las alternativas consiste en usar las estrategias preexistentes en clientes DASH para predecir un aumento de la disponibilidad del ancho de banda de la red.

La figura 15 resume un planteamiento para recopilar y procesar los datos de velocidad de bits y los datos de pérdida de paquetes a través de dos motores de procesado diferentes y alimentar los datos procesados a un módulo de toma de decisiones. Para ello, ilustra el esquema generalizado para un algoritmo de selección de Representaciones. El módulo de toma de decisiones debería incluir un procesado de optimización y equidad para garantizar una compartición equitativa de la velocidad de bits disponible entre los Conjuntos de Adaptación seleccionados y funciones de estabilidad (por ejemplo, histéresis) con el fin de evitar que el sistema suba y baje entre Representaciones de manera demasiado rápida o de manera demasiado agresiva.

Obteniendo la velocidad, la frecuencia y el tamaño promedio de la pérdida de paquetes por multidifusión a partir de los estadísticos sin procesar que están a su disposición, el algoritmo de selección de Representaciones puede deducir si se está produciendo una pérdida de paquetes en bloques contiguos (a partir de conexiones de datos interferentes que discurren en paralelo en el mismo enlace) o de una forma más aleatoria. Esto podría indicar características de red diferentes, cierta congestión de la red (la pérdida de bloques) puede ser temporal, por ejemplo, y podría no resultar apropiado cambiar de Representación para hacer frente a la misma, quedando cubierta la pérdida por un parcheo/recuperación de unidifusión.

La decisión de cambiar de Representación se toma por separado para cada Conjunto de Adaptación, pero obsérvese que, en la práctica, todos los Conjuntos de Adaptación están compitiendo por la misma capacidad en la red de suministro. Por lo tanto, además de decidir si la velocidad de bits total disponible ha cambiado, el módulo de toma de decisiones también necesita repartir la velocidad de bits entre Conjuntos de Adaptación. Esto se podría lograr por medio de una escala lineal o podría implicar cierta ponderación hacia, por ejemplo, una mejor calidad de audio que la calidad de vídeo.

Una ventaja adicional de desvincular los cambios de las Representaciones de audio y vídeo es que podrían usarse pequeños aumentos por incrementos en el audio (o incluso en el vídeo si se dispone de una suficiente granularidad entre velocidades de bit de Representaciones) para “tantear el terreno”, y ver, por experimentación, si se dispone de capacidad para incrementar la velocidad de bits.

Si hay simultáneamente activa más de una sesión de presentación de medios, el selector de Representaciones también debe garantizar equidad cuando se reparte la velocidad de bits disponible entre estas sesiones activas.

En despliegues que admiten números elevados de sesiones de presentación de medios simultáneamente, el Proxy de Cliente puede confiar, por ejemplo, en el mecanismo de recuperación por unidifusión para sesiones con números reducidos de clientes, reservando el modo de recepción por multidifusión para sesiones con números de clientes mayores. Este concepto de umbral de sesión de cliente puede resultar útil en redes en las que la capacidad de transmisión por multidifusión es limitada.

Descripción de los apéndices

Se describen ejemplos específicos de los protocolos usados en relación con el Apéndice A y el Apéndice B, junto con la figura 16 de las figuras. El Apéndice A describe la Carga Útil RTP. El Apéndice B describe Reglas de Reescritura de MPD. Ambos son ejemplos particulares no limitativos que se pueden usar en formas de realización de la invención.

Apéndice A

Formato de carga útil RTP para transmitir en continuo segmentos DASH MPEG y fragmentos BMFF ISO

El formato de carga útil RTP descrito en este Apéndice especifica cómo fragmentos de Formato de Archivo de Medios de base (BMFF) ISO formateados como Segmentos DASH MPEG se descompondrán adicionalmente y se mapearán de manera directa en paquetes de datos RTP. El formato de la carga útil se construye sobre el “perfil de audio-vídeo RTP (RTP/AVP)” descrito en [IETF RFC 35511. el cual es un perfil del Protocolo de Transporte en Tiempo Real genérico especificado en [IETF RFC 35501. El formato de carga útil especificado en este caso adopta conceptos de otros formatos similares de carga útil RTP/AVP, tales como [IETF RFC 30161, el formato de carga útil para flujos audiovisuales MPEG-4.

Uso de los campos de encabezamiento RTP para la carga útil de Fragmentos BMFF ISO

1 v ~2 ! P | x j c c | M j pt | número de secuencia Encabezamiento RTP

sello de tiempo

I identificador de fuente de sincronización (SSRC)

| identificadores de fuentes contribuyentes (CSRC)

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

! definido por perfil I longitud Extensión de Encabezamiento ! extensión de encabezamiento RTP

Carga Útil j parte de Segmento DASH MPEG o Fragmento BMFF ISO (alineada por bytes) RTP

| - H- - - -i- - - - - - - - - - - - - - -i : . , . relleno RTP OPCIONAL

-- - --+--1 - --+--1 --+-+--+-- - --+-- • - --+--1 - --+--+-+-+--+-- -+--+-- - --+--1 - -- -

• Bit de extensión (X): fijado a 1 para indicar el primer (o único) paquete de datos RTP de un Fragmento BMFF ISO o Segmento DASH MPEG particular. Si está fijado a 1, la Extensión de Encabezamiento RTP opcional ESTARÁ presente en el paquete de datos. De lo contrario, estará fijado a 0, y la Extensión de Encabezamiento RTP opcional NO ESTARÁ presente.

• Recuento de fuentes contribuyentes (CC): fijado siempre a 0000.

• Bit Marcador (M): El bit marcador se fija a 1 para indicar el último (o único) paquete de datos RTP de un Fragmento BMFF ISO o Segmento DASH particular.

• Tipo de Carga Útil (PT): se asignará un valor de tipo de carga útil en el rango dinámico de 96 a 127 según la [IETF RFC 3551 Sección 31. (El valor usado debe señalizarse al cliente fuera de banda, por ejemplo, en un recurso SDP o equivalente).

• Número de Secuencia (16 bits): incrementado en uno para cada paquete de datos RTP enviado desde una Fuente de Sincronización dada, comenzando en un valor aleatorio y reiniciándose de nuevo a 0 después de 65535.

• Sello de tiempo (32 bits): indica el sello de tiempo de codificación de la primera trama en el Segmento DASH que se está transmitiendo. Será el mismo para cada paquete de datos RTP que surja de un Segmento de origen particular. La resolución del sello de tiempo será 1 Hz, medido en segundos desde la medianoche UTC el 01-01-1970. (La resolución del sello de tiempo se señalizará fuera de banda, por ejemplo, en un recurso SDP o equivalente).

• Identificador de Fuente de Sincronización (SSRC): un valor sin signo de 32 bits asignado aleatoriamente.

• Identificadores de Fuentes Contribuyentes (CSRC): no estarán presentes.

El uso de la extensión de encabezamiento RTP opcional se especifica a continuación.

Indicación del primer paquete de datos RTP en un Fragmento BMFF ISO

El bit de extensión X SERÁ 1 indicando la presencia de la extensión de encabezamiento RTP.

Habrá presencia de la Extensión de Encabezamiento RTP y el elemento de extensión de recuento-bytes-fragmento indicará a la longitud del Fragmento BMFF ISO.

Los datos del Fragmento BMFF ISO vendrán a continuación inmediatamente en el campo de Carga útil RTP. Indicación del primer paquete de datos RTP en un Segmento DASH MPEG.

En el caso más específico de un Segmento DASH MPEG, es necesario incluir más información con el fin de reconstruir y volver a referenciar el contenido con el URL del fragmento. Esta información ESTARÁ presente en el primer paquete de datos RTP que surja de cada Segmento DASH MPEG. La información SE TRANSPORTARÁ en la extensión de encabezamiento r Tp según especifica la [IETF RFC 3500].

El bit de extensión de encabezamiento X SERÁ 1 indicando la presencia de la extensión de encabezamiento RTP. La extensión de encabezamiento RTP ESTARÁ presente y se formateará según se especifica en la [IETF RFC 5285]. El encabezamiento de dos bytes especificado en la [IETF RFC 5285 Sección 4.3] se USARÁ para llenar el campo “definido por perfil”:

El campo appbits no se usa y se fijará a 0x0.

El campo de longitud del Encabezamiento RTP INDICARÁ el número total de palabras de 32 bits de los datos de extensión del encabezamiento que vienen a continuación (es decir, excluyendo los campos “definido por perfil” y “longitud”).

Cuando los datos en la extensión del encabezamiento RTP no sean un múltiplo exacto de palabras de 32 bits, los mismos SE EXTENDERÁN hasta el límite de palabra más cercana usando bytes de relleno con el valor 0. Cualesquiera bytes de relleno añadidos por este motivo SE INCLUIRÁN en el valor de longitud del Encabezamiento RTP.

Cada elemento de extensión comienzo con un byte que contiene un ID y un byte que contiene una longitud: nU - 1i

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

H ! I ¡ ! i ¡ ! ! i ¡ ! i ¡ ! i r

longitud !

¡--!------1---- ¡---1------ 1--- ^1-

El campo de longitud de 8 bits es la longitud de los datos de extensión en bytes, excluyendo los campos de ID y longitud y excluyendo cualesquiera bytes de relleno que sucedan al elemento de extensión. Un valor de longitud de 0 indica que no hay datos sucesivos, en cuyo caso el elemento de extensión juega el papel de una etiqueta marcadora de dos bytes sin información adicional.

Elementos de extensión

La siguiente tabla especifica los elementos de extensión definidos por este Formato de Carga Útil. Obsérvese que el URI de elemento de extensión (indicado en la primera columna de la tabla) no aparece directamente en el flujo de datos RTP: los elementos de extensión se indican en el flujo únicamente usando su identificador local (indicado en la segunda columna). El mapeo entre identificadores locales y URIs se logra usando un mecanismo fuera de banda. Si la sesión de medios se describe usando una descripción de sesión de [IETF RFC 4566], el atributo extmap especificado en [IETF RFC 5285] se USARÁ para esta finalidad utilizando la siguiente sintaxis:

a=extmap:<value>["/"<direction>] <URI> <extensionattributes>

[IETF RFC 5285] especifica que estos mapeos pueden manifestarse por separado para cada flujo de medios (Representación DASh MPEG) descrito por la sesión, o de manera global para todos los flujos de medios de la sesión (Presentación DASH MPEG), pero los dos planteamientos no pueden combinarse en la misma descripción de sesión.

Ejemplo desarrollado

El siguiente ejemplo ilustra un paquete de datos RTP que incluye la extensión de encabezamiento RTP opcional ya que su carga útil contiene el inicio de un nuevo Segmento DASH MPEG. Por lo tanto, el bit marcador X se fija a 1.

í I Carga Útil

! Inicio de Segmento DASH MPEG (alineado por bytes) I RTP

I I

|

í : , . . relleno RTP OPCIONAL !

- - ■ - - - - - - - - - - - I - - - - - - - - - - - - -

La Extensión de Encabezamiento RTP tiene una longitud de 10 palabras (40 bytes) (longitud=10). Viene inmediatamente a continuación del campo de SSRC ya que no se permiten identificadores de CSRC. La Extensión de Encabezamiento RTP contiene tres elementos de extensión, que son los siguientes:

1. recuento-bytes-fragmento (ID=1). La longitud del Segmento DASH MPEG (Fragmento BMFF ISO) en este ejemplo particular (26510 bytes) se puede expresar como un entero sin signo de dos bytes, y, por tanto, L=2 y el valor de longitud del Segmento viene a continuación en los siguientes dos bytes.

2. url-base-segmento (ID=3). El URL de base del Segmento DASH MPEG (http://url.bbc.co.uk/) tiene una longitud de 21 bytes. Se añade un byte de relleno adicional con valor 0 para alinear el campo con el siguiente límite de palabra, pero este relleno no se incluye en el campo de longitud de elemento de extensión (L=21).

3. url-relativo-segmento (ID=4). El URL relativo del Segmento DASH MPEG (hi.mp4/21) tiene una longitud de 9 bytes. Se añade un byte de relleno adicional con valor 0 para alinear el campo con el siguiente límite de palabra, pero este relleno no se incluye en el campo de longitud de elemento de extensión (L=9).

La descripción de sesión asociada contendría mapeos para los tres elementos de extensión anteriores de la manera siguiente:

a=extmap:1 /sendonly http://bbc.co.uk/refdata/rtp-hdrext/iso-bmff#fragment-byte-count a=extmap:3/sendonly http://bbc.co.uk/refdata/rtp-hdrext/nipeg-dash#segrnent-base-url

a=extmap : 4/sendonly http://bbc.co.uk/refdata/rtp-hdrext/mpeg--dash#segment-relative-url

Indicación del paquete de datos RTP final en un Segmento DASH MPEG o Fragmento BMFF ISO

En el datagrama RTP final de la secuencia correspondiente a un Segmento DASH MPEG o Fragmento BMFF ISO particular, el bit marcador (B) se FIJARÁ a 1 para indicar el final de la secuencia.

Claims (13)

REIVINDICACIONES

1. Sistema para suministrar contenido con calidades variables desde un servidor a múltiples clientes a través de una red, estando el contenido dispuesto en representaciones de calidades diferentes, comprendiendo cada representación unos segmentos direccionables por solicitudes de cliente, que comprende:

un conversor de lado de servidor (6) dispuesto para

- emitir solicitudes de unidifusión al servidor para segmentos de múltiples representaciones del contenido; - convertir cada una de entre las múltiples representaciones del contenido en unos respectivos flujos de datagramas de multidifusión, siendo cada representación asignada a una dirección IP de multidifusión correspondiente; y

- suministrar los flujos de datagramas de multidifusión sobre la red;

un conversor de lado de cliente (8) dispuesto para

- recibir solicitudes de contenido de los clientes;

- determinar una representación del contenido que se va a obtener sobre la base de las condiciones de monitorización de la red;

- suscribirse al flujo de datagramas de multidifusión que comprende la representación determinada del contenido;

- convertir el flujo de datagramas de multidifusión de nuevo en segmentos disponibles para el cliente por solicitud de unidifusión; y

- conmutar entre diferentes representaciones del contenido cuando el conversor de lado de cliente detecte la necesidad de cambiar de una representación a otra sobre la base de las condiciones de la red, conmutando el conversor del lado de cliente entre diferentes representaciones del contenido mediante la conmutación entre flujos de datagramas de multidifusión.

2. Sistema según la reivindicación 1, en el que el conversor de lado del cliente está dispuesto para interceptar solicitudes de contenido del cliente, para interceptar mensajes de respuesta del servidor, y para modificar los mensajes de respuesta que se van a enviar al cliente, comprendiendo la modificación, preferentemente, alterar una descripción en el mensaje de respuesta para presentar solamente una representación como aparentemente disponible para el cliente.

3. Sistema según la reivindicación 2, en el que la modificación comprende alterar una dirección en el mensaje de respuesta de manera que las solicitudes de contenido del cliente sean redirigidas al conversor del lado de cliente.

4. Sistema según cualquiera de las reivindicaciones 2 o 3, en el que las solicitudes de contenido del cliente comprenden unas solicitudes de manifiesto de contenido.

5. Sistema según cualquiera de las reivindicaciones anteriores, en el que el conversor de lado del cliente está dispuesto para determinar la representación del contenido que se va a obtener mediante la selección de la representación de calidad máxima soportable por las condiciones en la red.

6. Sistema según cualquiera de las reivindicaciones anteriores, en el que el conversor de lado del cliente está dispuesto para seleccionar una calidad de representación de contenido para cada uno de entre una pluralidad de diferentes componentes de contenido.

7. Sistema según cualquiera de las reivindicaciones 1 a 6, en el que el conversor de lado del cliente está dispuesto para minimizar los efectos perceptibles de la conmutación entre representaciones mediante una o más de entre minimizar la frecuencia de conmutación entre representaciones o minimizar la diferencia en la calidad de representaciones al conmutar entre representaciones.

8. Sistema según cualquiera de las reivindicaciones anteriores, en el que el conversor de lado del cliente está dispuesto para obtener una representación de calidad mayor o menor de acuerdo con criterios seleccionables, que incluyen obtener una representación de calidad menor si las condiciones de la red no permiten que una representación de calidad mayor sea suministrada.

9. Sistema según cualquiera de las reivindicaciones anteriores, en el que el conversor de lado del cliente está dispuesto para determinar si faltan cualesquiera segmentos cuando al conmutar entre flujos de datagramas de multidifusión y para recuperar cualesquiera de estos segmentos que faltan mediante la emisión de una solicitud de unidifusión al servidor.

10. Sistema según cualquiera de las reivindicaciones anteriores, en el que el conversor de lado del cliente está dispuesto para determinar si cualesquiera segmentos reensamblados a partir de un flujo de datagramas de multidifusión están incompletos y para recuperar las partes ausentes de dichos segmentos, realizándose la recuperación de las partes ausentes preferentemente solicitando uno o más intervalos de bytes dentro del segmento incompleto.

11. Sistema según cualquiera de las reivindicaciones 1 a 10, en el que el conversor de lado del cliente forma parte de un dispositivo de pasarela dispuesto para proporcionar contenido a múltiples dispositivos de cliente.

12. Sistema según cualquiera de las reivindicaciones anteriores, en el que la conversión de cada una de entre las múltiples representaciones del contenido en unos respectivos flujos de datagramas de multidifusión comprende convertir los segmentos en un flujo de datagramas, estando los datagramas de los flujos de datagramas preferentemente separados de manera uniforme en el tiempo.

13. Método para suministrar contenido con calidades variables a través de un servidor a múltiples clientes a través de una red, estando el contenido dispuesto en representaciones de calidades diferentes, comprendiendo cada representación unos segmentos direccionables por solicitudes de cliente, que comprende:

en un conversor de lado de servidor

- emitir solicitudes de unidifusión al servidor para los segmentos de múltiples representaciones del contenido;

- convertir cada una de entre las múltiples representaciones del contenido en unos respectivos flujos de datagramas de multidifusión, siendo cada representación asignada a una dirección IP de multidifusión correspondiente; y

- suministrar los flujos de datagramas de multidifusión sobre la red;

en un conversor de lado de cliente

- recibir solicitudes de contenido de los clientes;

- determinar una representación del contenido que se va a obtener sobre la base de condiciones de monitorización de la red;

- suscribirse al flujo de datagramas de multidifusión que comprende la representación determinada del contenido;

- convertir el flujo de datagramas de multidifusión de nuevo en segmentos disponibles para el cliente por solicitud de unidifusión; y

- conmutar entre diferentes representaciones del contenido cuando el conversor de lado de cliente detecte la necesidad de cambiar de una representación a otra sobre la base de las condiciones de la red, conmutando el conversor del lado de cliente entre diferentes representaciones del contenido mediante la conmutación entre flujos de datagramas de multidifusión.