ES2763998T3 - Procesado de datos multimedia - Google Patents

Abstract

Método para proporcionar contenido de medios que comprende segmentos de medios a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo, siendo el método ejecutable en un equipo de usuario y comprendiendo las etapas de: - recibir un primer segmento de medios (S21); - determinar el tiempo de recepción del primer segmento de medios (S22); caracterizado por - estimar un tiempo de disponibilidad de segmentos de medios para solicitar segmentos de medios sucesivos modificando el tiempo determinado de la recepción del primer segmento de medios con un valor de corrección que compensa una variación en los intervalos de recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante (S23); - señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo (S24).

Description

DESCRIPCIÓN

Procesado de datos multimedia

Campo técnico

La presente exposición se refiere a técnicas para proporcionar datos de medios a un usuario, los cuales se envían sobre un enlace de transmisión con retardos de transmisión variables.

Esta exposición se puede llevar a la práctica en soluciones de red que usan técnicas de transmisión de difusión general las cuales proporcionan una transmisión de segmentos de medios. En particular, las realizaciones descritas en la presente se pueden usar en un escenario que hace uso de una transmisión MBMS, eMBMS de segmentos de medios u otras técnicas de transmisión de difusión general, como la Multidifusión IP en el sistema de acceso DSL (IPTV) o el DVB-S.

Antecedentes

Las técnicas de transmisión adaptativa en flujo continuo de HTTP se basan en que el cliente seleccione la calidad de los medios. El servidor o proveedor de contenidos describe todas las representaciones de calidad disponibles y la manera de recuperarlas en un archivo denominado de manifiesto, por ejemplo, las representaciones del contenido de medios pueden diferir en relación con las diferentes velocidades de bits de los medios y la forma de acceder a las representaciones desde el servidor. El archivo de manifiesto se recupera por lo menos una vez en el inicio de una sesión de transmisión en flujo continuo, y se puede actualizar durante la sesión. La Transmisión adaptativa dinámica en flujo continuo sobre HTTP, DASH, es una técnica de transmisión adaptativa en flujo continuo, la cual ajusta el flujo continuo de medios a las velocidades de bits del enlace disponibles en ese momento, tal como se da a conocer en el documento “Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats”, ISO/IEC 23009-1:2012(E), versión 2.1c2.

El DASH está diseñado como un protocolo de transmisión adaptativa en flujo continuo de HTTP, controlado por el cliente. Esto significa que el servidor describe un conjunto de calidades de medios disponibles, por ejemplo, en un archivo de manifiesto, y el cliente, en función de la velocidad de bits del enlace, selecciona la representación de los medios (es decir, velocidad de bits de los medios) que se corresponde con la velocidad de bits del enlace. En general, la solución DASH comprende un servidor DASH que está adaptado para proporcionar contenido con diferentes calidades de medios, las denominadas representaciones, y, en el lado del cliente, un cliente DASH está adaptado para solicitar el contenido de medios con diferentes calidades.

La mayoría de las técnicas de Transmisión adaptativa en flujo continuo de HTTP requieren que un cliente recupere continuamente segmentos de medios de un servidor. En el segmento de medios se incluye una cierta magnitud de tiempo de medios (por ejemplo, 10 s de datos de medios). Cada segmento de una representación de medios particular se hace que esté disponible en el servidor en un tiempo particular indicado en el manifiesto. En el manifiesto se describe también la forma de creación de los URLs en el lado del cliente para descargar los segmentos de la representación de calidad diferente.

La Fig. 1 representa los fundamentos de la recuperación de segmentos en un entorno DASH. El cliente, un cliente DASH, se comunica con un servidor, un servidor DASH.

El archivo de manifiesto se recibe como una respuesta del mensaje HTTP GET archivo de manifiesto, 10, y se procesa para determinar las posibles calidades, 11. En la siguiente etapa, 12, el cliente solicita datos con la calidad más baja, HTTP GET Segmento n.° 1 de Calidad más Baja, y se lleva a cabo una medición de la velocidad de descarga, 13. El cliente mide continuamente la velocidad de bits del enlace mientras está recibiendo los segmentos de medios, 14, para determinar la calidad apropiada para la recepción de los datos del contenido. El cliente puede cambiar a otra representación de calidad en cualquier momento, si se toma la decisión de cambiar la representación, 15. En la realización de acuerdo con la Fig. 1, se decide solicitar datos de medios con una calidad media, HTTP GET Segmento n.° 2 de Calidad Media, 16, y continuar con la medición de la velocidad de descarga, 17.

Es necesario que el archivo de manifiesto esté disponible con el fin de procesar el contenido de medios que se está dividiendo en segmentos de medios. El archivo de manifiesto se puede distribuir por separado, opcionalmente dentro de la banda con el flujo continuo o a través de un método aparte de anuncio de servicios. En el caso de1HLS de Apple, el manifiesto se formatea como archivo de Lista de Reproducción en formato m3u8. En el caso del MPEG DASH/3GPP, el manifiesto es una estructura XML denominada archivo de Descripción de Presentación de Medios MPD. El MPD comprende listas o medios operativos para generar las listas de los URLs de todos los segmentos de medios, que pertenecen a la sesión de medios y que se usan para recuperar el siguiente segmento de medios. Existe también la posibilidad de entregar segmentos de medios DASH a través de sistemas de difusión general, tales como el eMBMS (Servicio de Difusión General y Multidifusión Multimedia del LTE). La difusión general es eficiente cuando muchos usuarios en una célula o cualquier área de difusión general usan la misma calidad del flujo continuo de bits. Así, es posible que el mismo servicio se difunda de forma general, por ejemplo, en áreas urbanas con una velocidad de bits más alta y en áreas suburbanas con una velocidad de bits inferior, simultáneamente a una serie de usuarios.

De este modo, el reproductor DASH puede recibir contenido por difusión general o unidifusión. No obstante, un Reproductor DASH no dispone de información sobre si el teléfono se encuentra dentro de una cobertura de difusión general y/o unidifusión. Un Codificador en Vivo (Live Encoder) LE en el lado del servidor genera un MPD, y tampoco tiene conocimiento sobre si este archivo se va a usar por unidifusión o difusión general, y, en muchos casos, el mismo contenido se distribuirá tanto por unidifusión como difusión general.

Además, el DASH funciona segmentando el flujo continuo de contenido de medios ininterrumpido en una secuencia de segmentos de medios. Típicamente, un segmento DASH es subdividido por el Codificador en Vivo LE o el Segmentador en múltiples segmentos de protocolo de transporte, como un TCP o segmentos de UDP, en donde los segmentos tienen una duración temporal aproximadamente constante, la denominada duración de segmento.

Se recupera un nuevo MPD del servidor cuando el tiempo de reproducción actual se aproxima al final de los medios descrito en el MPD, o llega un momento desde la última reproducción el cual es mayor que el tiempo de actualización mínimo señalizado en el MPD.

Los segmentos de medio tienen un tamaño, por término medio, de 100 kbytes, aunque algunos pueden ser mayores, por ejemplo, de hasta 130 kbytes, y otros menores, por ejemplo, de hasta 70 kbytes, con lo que, cuando se generan los segmentos de medios, cada uno de los segmentos que presenta una duración de segmento podría tener un número diferente de segmentos de TCP, o respectivamente, de UDP. El tamaño de los segmentos depende también de la representación seleccionada. El cliente puede seleccionar cambiar entre representaciones para adaptarse a la velocidad de bits. Finalmente, el cliente recupera la secuencia ordenada de archivos, y vuelve a concatenar los archivos en un flujo continuo de medios, ininterrumpido, y el contenido se reproduce y los segmentos se solicitan de manera continua.

Cuando se ejecuta el DASH sobre una Difusión General del LTE (eMBMS), el Codificador en Vivo carga los segmentos de medios en un Servidor de Difusión General y Multidifusión (BM-SC). El protocolo FLUTE en el BM-SC se ocupa de dividir el archivo de medios en una secuencia de segmentos de medios, en este caso de paquetes o segmentos de UDP. Cada paquete de UDP está señalado de forma exclusiva con un número de secuencia, de manera que el cliente puede volver a ensamblar el archivo.

El protocolo FLUTE del IETF (RFC 3926) se usa para la entrega de archivos a través de una transmisión de difusión general. La sesión de entrega FLUTE se define por medio de un archivo de SDP (Protocolo de Descripción de Sesión), el cual contiene todos los parámetros, tales como la dirección de Multidifusión IP, el puerto de UDP, aunque también una TMGI (Identidad Temporal de Grupo de Móviles) para que el MBMS permita que un cliente reciba una entrega de difusión general de archivos en móviles. Así, el FLUTE es un protocolo que permite la entrega de archivos a través de enlaces de difusión general usando el UDP como protocolo de transporte.

El Reproductor DASH recupera una secuencia de segmentos de medios como archivos independientes, usando el URL que se proporciona en el manifiesto (denominado MPD en el caso del DASH). Cuando se envía el DASH a través de MBMS, los segmentos no son recuperados por el cliente desde el servidor remoto. Por el contrario, los segmentos se envían sin solicitud previa (pushed) usando el FLUTE sobre difusión general.

En el escenario de difusión general, el cliente de eMBMS debe recibir en primer lugar un segmento de medios, antes de que se pueda hacer que el mismo esté disponible para el reproductor DASH. Esto constituye una penalización para las representaciones de difusión general con respecto a las representaciones de unidifusión. El reproductor DASH no sabe si el UE (Equipo de Usuario) está situado o no dentro de la cobertura de difusión general. El reproductor DASH ordena los segmentos de datos sucesivos en el tiempo según se establece en el archivo de MPD. No obstante, en el caso de la difusión general en el tiempo solicitado, el segmento de medios puede no estar disponible en el servidor, y puede no encontrarse en la memoria caché local en el UE. Por lo tanto, el reproductor DASH pide un segmento que no se ha recibido todavía.

Además, en el caso de la difusión general, los segmentos tienen, por término general, un tamaño de 100 kbytes, algunos son mayores, por ejemplo, de hasta 130 kbytes, y otros menores, por ejemplo, de hasta 70 kbytes, con lo que, cuando se generan los segmentos, cada segmento podría presentar un número diferente de segmentos de UDP. En el caso de la difusión general, existe un portador de velocidad de bits constante asignado para la transmisión de difusión general. Por ejemplo, la velocidad de bits asignada podría ser 1 Mbps lo cual significa que la transmisión de un segmento de 500 kb de tamaño tarda 0,5 s, y un segmento de 1.500 kb de tamaño necesita 1,5 s. El diferente tamaño de los segmentos de medios conduce a una duración variable de los segmentos durante la transmisión de estos últimos, y consecuentemente varía el intervalo de tiempo de recepción para conseguir una recepción completa de un segmento de medios. No obstante, el Reproductor DASH asume que los segmentos de medios se ponen a disposición con un intervalo fijo, concretamente, una duración de segmento. Además, el retardo de extremo a extremo entre el BM-SC hasta el UE difiere de un sistema a otro. Depende de cómo se han configurado ciertos parámetros en el Nodo B evolucionado, aunque también del despliegue de la red. La velocidad del hardware del BM-SC tiene también un impacto sobre un sistema de extremo-a-extremo. Por este motivo, el retardo de extremo-a-extremo puede diferir notablemente entre diferentes proveedores, e incluso entre dos sistemas a los que presta servicio un BM-SC diferente cuando se proporcionan segmentos de medios.

No obstante, a estos sistemas diferentes les presta servicio un codificador en vivo, para el cual los despliegues del sistema son completamente transparentes. Por lo tanto, el LE genera, por un lado, diferentes tamaños de segmento, cuya transmisión a través de una red tarda respectivamente un espacio de tiempo diferente, y, por otro lado, debido al retardo variable de extremo-a-extremo en la red, se intensifica la variación en la transmisión temporal de un segmento de medios. Además, los UEs no están siempre sincronizados en el tiempo con el sistema. Es necesaria alguna forma de sincronización en el tiempo de los relojes de los dispositivos móviles debido a que los relojes de hardware presentan una deriva mutua con el tiempo, de manera que relojes diferentes de plataformas diferentes presentan velocidades de deriva diferentes en función de las características del dispositivo y de efectos externos de variaciones en cuanto a temperatura, vibraciones y humedad. Existe un problema bien conocido por el que diversos dispositivos de operadores diferentes presentan problemas de precisión en el tiempo. Algunos solamente unos pocos segundos, otros unos cuantos minutos o más. Consecuentemente, las velocidades de deriva de los relojes influyen adicionalmente en el diferente tiempo de recepción de los segmentos correspondiente a los segmentos de medios.

Además, el DASH MPEG usa el tiempo transcurrido real para calcular la disponibilidad de los segmentos en el servidor. Eso requiere que los UEs estén sincronizados correctamente en el tiempo con el sistema, de manera que el UE pueda calcular de forma precisa la recepción de los medios más recientes. Así, todos los aspectos mencionados conducen a un aumento de la duración variable de transmisión de segmentos de medios a través del portador de velocidad de bits constante y, consecuentemente, de la variación de intervalos de tiempo en la recepción de segmentos de medios, lo cual conduce a una situación en la que el reproductor DASH, cuando ordena el segmento sucesivo, puede obtener de forma regular un mensaje de error, en caso de que el segmento de medios no esté disponible antes del tiempo solicitado.

THORSTEN LOHMAR ET AL: “Dynamic adaptive HTTP streaming of live content”, WORLD OF WIRELESS, MOBILE AND MULTIMEDIA NETWORKS (WOWMOM), 2011 IEEE INTERNATIONAL SYMPOSIUM ON A, IEEE, 20 de junio de 2011, describen métodos para la transmisión adaptativa y dinámica en flujo continuo de HTTP, de contenido en vivo. QUALCOMM INC^o R^pORATED: “MPD Profiling to Support DASH over MBMS”, 3GPP DRAFT; S4-120448 CR 26.346-0249 REV 1 MPD CHANGES TO SUPPORT DASH OVER MBMS (RELEASE 11), 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES; F-06921 SOPHIA-ANTIPOLIS CEDEX; FRANCIA, describe métodos de entrega de segmentos DASH a través del MBMS.

Sumario

Existe una demanda de una técnica para obtener una provisión eficiente de datos de medios a un usuario. En particular, existe una demanda de aumento del nivel de experiencia de los datos presentados.

La invención se materializa en las reivindicaciones independientes. En las reivindicaciones dependientes se describen realizaciones ventajosas.

La demanda se satisface con un método para proporcionar contenido de medios que comprende segmentos de medios, a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo. Preferentemente, la transmisión se realiza a través de una transmisión de difusión general. El método comprende la recepción de un primer segmento de medios y la determinación, en la siguiente etapa, del tiempo de recepción del primer segmento de medios. Además, se estima un tiempo de disponibilidad del segmento de medios para solicitar segmentos de medios sucesivos, modificando el tiempo determinado de la recepción del primer segmento de medios, con un valor de corrección que compensa una variación en intervalos de una recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante. Finalmente, el tiempo de disponibilidad estimado se señaliza al reproductor de flujo continuo.

Además, la demanda se satisface con un método para proporcionar contenido de medios que comprende segmentos de medios, a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo. Preferentemente, la transmisión se realiza a través de una transmisión de difusión general. En una primera etapa del método, se estima un tiempo de disponibilidad original de los segmentos de medios que indica el tiempo en el que se hace que esté disponible el segmento de medios para su transmisión en el dispositivo servidor. Seguidamente, se estima un tiempo de disponibilidad de los segmentos de medios para solicitar segmentos de medios sucesivos, modificando el tiempo de disponibilidad original de los segmentos de medios con un valor de corrección que compensa una variación en intervalos de una recepción de los segmentos de medios, de manera que se hace que los segmentos de medios estén disponibles en el reproductor de flujo continuo con un intervalo de tiempo constante y el tiempo de disponibilidad estimado se señaliza al reproductor de flujo continuo.

Además, la demanda se satisface con un equipo de usuario UE el cual está configurado para proporcionar un contenido de medios que comprende segmentos de medios, a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo, preferentemente a través de una transmisión de difusión general. El UE comprende un receptor adaptado para recibir un primer segmento de medios. Además, el UE comprende una unidad lógica de determinación adaptada para determinar el tiempo de recepción del primer segmento de medios. Además, el UE comprende una unidad lógica de estimación adaptada para estimar un tiempo de disponibilidad de los segmentos de medios con el fin de solicitar segmentos de medios sucesivos, modificando el tiempo determinado de la recepción del primer segmento de medios con un valor de corrección que compensa una variación en intervalos de una recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante. Por otra parte, se dispone de un emisor adaptado para señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo.

Además, la demanda se satisface con un dispositivo servidor el cual está configurado para proporcionar un contenido de medios que comprende segmentos de medios, a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo. Preferentemente, la transmisión se realiza a través de una transmisión de difusión general. El dispositivo servidor comprende un receptor adaptado para estimar un tiempo de disponibilidad original de segmentos de medios que indica el tiempo en el que se hace que esté disponible el segmento de medios para su transmisión en el dispositivo servidor. Además, el dispositivo servidor comprende un procesador adaptado para estimar un tiempo de disponibilidad de los segmentos de medios con el fin de solicitar segmentos de medios sucesivos, modificando el tiempo de disponibilidad original de los segmentos de medios con un valor de corrección que compensa una variación en intervalos de una recepción de segmentos de medios, de manera que se hace que los segmentos de medios estén disponibles en el reproductor de flujo continuo con un intervalo de tiempo constante. Por otra parte, se dispone de un emisor adaptado para señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo.

Breve descripción de los dibujos

En lo sucesivo, se describirá adicionalmente la invención en referencia a realizaciones ejemplificativas ilustradas en las figuras, en las cuales:

la Fig. 1 muestra una realización para recuperar segmentos en un cliente de transmisión adaptativa de flujo continuo de HTTP;

la Fig. 2 muestra una realización para usar un archivo de MPD;

la Fig. 3 muestra un diagrama de flujo de un método en un equipo de usuario de acuerdo con una realización; la Fig. 4 muestra un diagrama de flujo de un método en un dispositivo servidor de acuerdo con una realización; la Fig. 5 muestra esquemáticamente un equipo de usuario según una realización;

la Fig. 6 muestra esquemáticamente un dispositivo servidor según una realización.

Descripción detallada

En la siguiente descripción, con fines explicativos y no limitativos, se exponen detalles específicos, tales como entornos de red y normativas de comunicación particulares, etcétera, con el fin de facilitar una comprensión minuciosa de la presente invención. Se pondrá de manifiesto para aquellos versados en la materia, que la presente invención se puede llevar a la práctica en otras realizaciones que se desvían con respecto a estos detalles específicos. Por ejemplo, los profesionales expertos apreciarán que la presente invención se puede llevar a la práctica con cualquier red inalámbrica, como, por ejemplo, redes UMTS, GSM o LTE. Como ejemplo alternativo, la invención también se puede implementar en redes inalámbricas de corto alcance, tales como sistemas de WLAN o Blue-tooth, o en redes por cable, por ejemplo en cualquier red basada en IP, tal como una red de IMS.

La invención se puede llevar a la práctica con ciertas redes de difusión general, por ejemplo TV o con redes híbridas que comprenden una red de difusión general y una red móvil, por ejemplo, una DVB-H (Radiodifusión de Vídeo Digital-Portátil) y una red móvil 3GPP. Básicamente, la invención se puede llevar a la práctica dentro de cualquier entorno de red en el cual se pueda distribuir contenido de vídeo.

El contenido de medios puede comprender datos de vídeo, datos de audio, o cualquier otro tipo de datos de medios (multimedia), tales como, por ejemplo, una combinación de datos de vídeo y de audio. El contenido se puede proporcionar dentro del marco de un servicio multimedia, tal como TV, TV para móviles o un servicio de IPTV. En lo sucesivo, las expresiones datos de medios, contenido de medios, datos de contenido se usan como sinónimos. Un segmento de medios se genera a partir de unos datos de medios continuos, como, por ejemplo, un fragmento de vídeo, y el mismo comprende una cierta cantidad de datos de un contenido de medios. Un segmento puede ser, por ejemplo, un segmento DASH.

Las expresiones Codificador en Vivo LE, Segmentador en Vivo, Transcodificador en Vivo se utilizan como sinónimos y significan un dispositivo que comprende cualquier equipo de Cabecera de Vídeo necesario para crear un contenido En Vivo DASH. En particular, el LE está adaptado para generar segmentos de medios a partir de un contenido de medios continuo.

Cuando se proporcionan servicios, o una aplicación o contenido de medios nuevos, entonces se generan los correspondientes atributos del Anuncio de Servicio (SA) y archivos de descripción, como una Descripción de Servicio de Usuario (USD) o el correspondiente Protocolo de Descripción de Sesión (SDP) o la correspondiente Descripción de Presentación de Medios (MPD) que proporciona información para solicitar el contenido de medios disponible. El archivo de USD es un fragmento progenitor del SDP y el MPD, que contiene parámetros de servicio adicionales para Servicios de Usuario MBMS (3GPP TS 26.346 Versión 11). En lo sucesivo, se usa el archivo de manifiesto de MPD, lo cual no debe considerarse sin embargo como una limitación de la presente invención.

La Transmisión adaptativa y dinámica en flujo continuo sobre HTTP, DASH, es un protocolo usado para la provisión de contenido de medios. Dicho contenido se puede proporcionar a través del protocolo FLUTE en caso de la transmisión de difusión general. Tal como ya se ha mencionado, el protocolo DASH proporciona, en el comienzo de una sesión, un archivo de MPD el cual comprende información sobre cómo solicitar segmentos de medios sucesivos. Entre otras informaciones, se proporciona el URL de un segmento de medios en un contenido de medios que se va a solicitar de forma sucesiva.

Un reproductor de flujo continuo es un reproductor en el lado del cliente, adaptado para proporcionar al usuario los datos de flujo continuo recibidos. Preferentemente, el reproductor de flujo continuo es un reproductor de flujo continuo adaptativo HTTP que está dispuesto para adaptar la velocidad de recepción de datos de medios o contenido de medios a la velocidad disponible del enlace de radiocomunicaciones. Además, el reproductor de flujo continuo está adaptado para solicitar de un servidor segmentos de medios. En una realización, se propone que el reproductor de flujo continuo sea un reproductor DASH, en particular, un reproductor MPEG-DASH. Así mismo, pueden soportarse otros esquemas de flujo continuo adaptativo HTTP, tales como el Flujo Continuo en Vivo (Uve Streaming) HTTP de Apple.

Un cliente podría ser cualquier dispositivo de cliente, tal como un dispositivo terminal o Equipo de Usuario (UE). En una realización, el cliente comprende un reproductor de flujo continuo, tal como un reproductor DASH, y un procesador para llevar a cabo la invención. No obstante, también puede ocurrir que el reproductor de flujo continuo no forme parte del equipo de usuario. En lo sucesivo, las expresiones cliente y equipo de usuario UE se usan como sinónimos. Si no se menciona explícitamente, el término cliente o UE se utiliza en el sentido de un procesador que lleva a cabo la invención y que proporciona el resultado al reproductor de flujo continuo.

El dispositivo servidor puede ser cualquier dispositivo que proporcione funcionalidad del servidor en el sistema y que esté adaptado para llevar a cabo la modificación de un tiempo de disponibilidad de los segmentos, por ejemplo, modificando el MPD. En una realización, el MPD puede ser modificado por una entidad que esté actuando como interfaz entre el LE y un UE. También puede disponerse de una entidad de aprovisionamiento de servicios, dedicada, para esta finalidad. En una realización adicional, el MPD es modificado directamente por el BM-SC, puesto que cada BM-SC conoce el retardo de extremo-a-extremo del sistema que está gestionando.

El BM-SC es un servidor de difusión general responsable de envolver el segmento de medios DASH en un formato adecuado de difusión general. Los segmentos de medios DASH son típicamente mayores que un único paquete de IP. En el caso de la unidifusión, es necesario que el segmento se envíe utilizando múltiples segmentos de TCP, tal como ya se ha mencionado. En el caso de la difusión general, un segmento se divide en múltiples paquetes de FLUTE/UDP. Opcionalmente, se calcula una redundancia de FEC y la misma se añade como tara a la transmisión del segmento. El BM-SC repite el procedimiento para cada segmento. Cuando se ejecuta el DASH sobre una Difusión General de LTE (eMBMS), el Codificador en Vivo carga segmentos de medios utilizando, por ejemplo, WebDAV, en el BM-SC. WebDAV es un protocolo definido por la RFC, para cargar archivos en servidores de HTTP. La disponibilidad de los segmentos se define aquí como “el segmento está preparado ahora” para ser proporcionado al reproductor de flujo continuo. Otra definición es que el contenido de medios para el segmento de medios está disponible en este momento para el codificador en vivo, y el segmento resulta disponible para su distribución en el “tiempo de disponibilidad del segmento más la duración del segmento”.

El valor de corrección puede depender de la variabilidad del tamaño del segmento correspondiente a los segmentos de medios.

La variabilidad del tamaño del segmento ya viene provocada por el Codificador en Vivo LE. Los segmentos de medios según son generados por el LE tienen diferentes tamaños, en el sentido de que comprenden un número diferente de paquetes de datos, como paquetes de datos de UDP o TCP. Los LEs son específicos de cada proveedor. Cada proveedor de codificadores en vivo tiene sus propios algoritmos para aumentar la eficiencia de compresión, al mismo tiempo que manteniendo un bajo retardo de extremo-a-extremo. Además, se tiene en consideración el perfil usado, como por ejemplo el bajo retardo de extremo-a-extremo fijado o excluido. Esto da como resultado que el codificador en vivo proporcione una variabilidad en el tamaño de los segmentos. Además, en el caso de la difusión general, se proporciona un portador de velocidad de bits constante sobre un enlace de transmisión, para transmitir los datos emitidos por difusión general. Los segmentos de datos con diferentes tamaños de segmento necesitan un tiempo diferente para su transmisión a través de un enlace de transmisión, lo cual conduce a una variación de los intervalos de recepción de los segmentos de medios. El LE, basándose en la velocidad de bits de los medios y en la Memoria Intermedia de Imágenes Codificadas, sabe durante cuánto tiempo debería almacenar temporalmente el UE el contenido antes de comenzar la reproducción con el fin de evitar cualquier subdesbordamiento. Así, se utiliza un almacenamiento temporal adicional de datos en el lado del cliente para compensar los efectos de tamaños cambiantes de los segmentos.

Además, el valor de corrección también puede considerar el retardo del sistema de extremo-a-extremo y el tiempo de deriva hacia delante.

En general se propone proporcionar un valor de corrección, de tal manera que el reproductor de flujo continuo encuentre los segmentos disponibles con un intervalo de recepción constante, por ejemplo, según la duración de los segmentos. Habitualmente, se espera recibir segmentos de medios con un intervalo de recepción constante, por ejemplo, según la duración de los segmentos. No obstante, debido a la duración variable de la transmisión de los segmentos de medios, por ejemplo, debido al tamaño variable de los segmentos, el intervalo de recepción, definido como la diferencia de reloj entre la recepción de segmentos consecutivos, no es constante sino que varía. La función del valor de corrección es compensar la variación en la recepción de los segmentos de medios.

A continuación, se presentan algunas observaciones del comportamiento durante la descarga de un contenido en el caso de la unidifusión UC y la difusión general BC.

Seguidamente, se presenta una distribución del MPD de acuerdo con la Fig. 2. El MPD consta de tres componentes principales, a saber, periodos, representaciones y segmentos. Tal como se representa en la Fig. 2, los componentes de periodo son la parte más externa del MPD. Los periodos son típicamente trozos más grandes de medios que se reproducen secuencialmente. Dentro de un periodo, pueden producirse múltiples codificaciones diferentes del contenido. A cada alternativa se le denomina representación. Estas representaciones alternativas pueden tener, por ejemplo, diferentes velocidades de bits, frecuencias de cuadro o resoluciones de vídeo. Finalmente, cada representación describe una serie de segmentos mediante URLs HTTP. Dichos URLs o bien se describen explícitamente en la representación, por ejemplo, en forma de una lista de reproducción, o bien se describen a través de una construcción con plantilla, que permite que el cliente obtenga un URL válido para cada segmento de una representación. El formato del MPD es flexible y puede soportar otros formatos de contenedores de medios, tales como el TS MPEG-2.

En forma de una plantilla, tal como se muestra en la tercera caja de la Fig. 2, el URL se construye sustituyendo una cierta parte de la plantilla por el índice i. La forma de una plantilla puede tener la siguiente forma en el formato printf de C:

http://ex.com/path/media-segment-0/od.3gs

donde %d se sustituye por el valor de i para dar como resultado el URL que se usará para solicitar los segmentos de medios sucesivos

Si va a solicitarse un segmento con el índice 10, por lo tanto cuando i == 10, entonces el URL tiene la forma: “http://ex.com/path/media-segment-10.3gs”, y cuando i ==11 entonces la dirección es: http://ex.com/path/mediasegment-11.3gs.

Cuando los URLs se proporcionan en forma de una lista de reproducción, el receptor puede considerar la lista de URLs como una matriz, e i como el índice de la matriz que apunta al segmento de medios pertinente, en donde la matriz comienza habitualmente con el valor uno.

El MPD puede contener además información sobre el almacenamiento temporal en el lado del UE. El LE, basándose en la velocidad de bits de los medios y la Memoria Intermedia de Imágenes codificadas, sabe durante cuánto tiempo el UE debería almacenar temporalmente el contenido, antes de comenzar la reproducción, para evitar cualquier subdesbordamiento, de manera que el LE determina el denominado minBufferTime. El minBufferTime informa al UE de que se supone que dicho UE almacena temporalmente el contenido mientras dure minBufferTime, después de la recepción de los primeros bits, con el fin de compensar la variación en un intervalo de recepción de segmentos de medios. Suponiendo que los segmentos de la representación se entregan continuamente con una velocidad de bits constante hipotética, en bits por segundo (bps), entonces, si la representación se entrega continuamente con esta velocidad de bits, comenzando en cualquier Punto de Acceso al Servicio (SAP), que es un punto desde el cual un UE puede comenzar a representar el contenido, que se indica o bien por un atributo de MPD @startWithSAP o bien con cualquier caja de Índice de Segmento (caja “sidx”), se le puede garantizar a un cliente que dispone de datos suficientes para una reproducción continua proporcionando una reproducción que comienza después de que se hayan recibido minBufferTime * ancho de banda bits.

El MPD también puede contener un availabilityStartTime, que es el tiempo en el cual se hace que esté disponible el primer segmento de flujo continuo para su descarga en el servidor. El cliente lee a partir del archivo de manifiesto, el tiempo de inicio del flujo continuo en vivo, especialmente, el availabilityStartTime. Si el cliente está sincronizado apropiadamente en el tiempo, el mismo puede calcular el último segmento de medios disponible en el servidor, concretamente cada tiempo de duración de un segmento de medios. Eso significa que el cliente, cuando se sintoniza, puede solicitar el segmento de medios i, el cual se calcula a partir del availabilityStartTime y la duración de segmento que se envía en el MPD, con lo que availabilityStartTime + i* duración de segmento es el tiempo para solicitar el siguiente segmento de medios.

De manera resumida en un escenario simplificado, en el caso de la unidifusión, el servidor hace que el primer segmento de medios N esté disponible en el tiempo t, y proporciona un archivo de MPD al cliente, que declara el availabilityStartTime de dicho segmento. A partir del tiempo t en adelante, los UEs pueden comenzar a descargar los segmentos solicitando los segmentos sucesivos, en donde el cliente selecciona una (o más) representaciones adecuadas y solicita segmentos correspondientes al tiempo local actual en el lado del cliente. Cuando se solicita antes del tiempo t, el servidor responde con un mensaje de error (mensaje de estado HTTP 404-file-not-found). La descarga del segmento ocupa cierto tiempo, al menos la duración del segmento. Por lo tanto, el cliente almacena temporalmente el contenido recibido de por lo menos minBufferTime antes de dar inicio a la presentación. El minBufferTime proporciona concretamente el margen necesario para que el cliente finalice la descarga. Compensa la duración de la descarga y sus variaciones, por ejemplo, debido a tamaños cambiantes de los segmentos.

En caso de la difusión general, el servidor hace que el primer segmento de medios N esté disponible en el BM_SC en el tiempo t. A partir del tiempo t en adelante, el BM_Sc envía (pushes) los segmentos hacia el cliente sin esperar ninguna solicitud. Después de cierto tiempo, el segmento N llega a estar disponible en el UE, en particular en la memoria caché del cliente. Durante la descarga del segmento, el reproductor DASH obtendría del cliente, un mensaje de error cuando solicita el segmento, puesto que dicho segmento no está totalmente disponible en la memoria caché en este momento. El availabilityStartTime según se declara en el archivo de MPD y se proporciona al reproductor DASH, describe concretamente el tiempo en el que el primer segmento está disponible en el BM-SC. De acuerdo con las realizaciones de la invención, se propone la modificación del tiempo de disponibilidad de los segmentos. La realización considera que el valor del availabilityStartTime en el MPD es diferente para la unidifusión y la difusión general.

Se propone que, basándose en el tiempo de disponibilidad de los segmentos, el reproductor DASH sintonice su proceso de recuperación de segmentos. Para el DASH a través de unidifusión, esta disponibilidad de los segmentos es igual al tiempo en el que se hace que los segmentos estén disponibles en el servidor para su transmisión. En el caso del DASH a través de difusión general, la disponibilidad de los segmentos es igual al tiempo en el que se hace que los segmentos estén disponibles en el UE para el reproductor DASH.

Así, para compensar un problema de tamaños cambiantes de los segmentos, lo cual conduce a la variación de los intervalos de recepción de los segmentos de medios, se propone estimar el tiempo de disponibilidad de los segmentos con vistas a solicitar segmentos de medios sucesivos. La estimación considera un valor de corrección que compensa la variación de intervalos de una recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante, concretamente con la duración del segmento.

En una realización se propone utilizar el valor del minBufferTime del archivo de MPD. El minBufferTime es concretamente una indicación del tamaño variable de los segmentos del contenido de medios. El minBufferTime indica el tiempo necesario para almacenar temporalmente un contenido de medios antes de dar inicio a la reproducción de dicho contenido de medios. Si el UE está corrigiendo la disponibilidad de los segmentos, entonces el UE utiliza como base el tiempo de la recepción de un primer segmento. Si el dispositivo servidor está corrigiendo la disponibilidad de los segmentos, entonces utiliza como base el tiempo de disponibilidad de segmentos original en el servidor.

A continuación se presenta una realización de la presente exposición con respecto a la Fig. 3, que muestra un diagrama de flujo con etapas de acuerdo con una realización para llevarse a cabo en el lado del usuario.

En la etapa S21, un UE recibe un primer segmento de medios. La recepción del primer segmento significa que el UE sintoniza un flujo continuo de difusión general que está en curso. Al sintonizar un flujo continuo de DASH en vivo por difusión general, el cliente espera a la recepción de un primer segmento completo. Así, los segmentos de medios recibidos se almacenan en el lado del UE antes de reproducir dichos segmentos, lo cual significa su provisión al reproductor DASH.

En la siguiente etapa, el UE determina el tiempo de recepción completa del primer segmento de medios, S22.

En la etapa S23, se determina un tiempo de disponibilidad de segmentos para un segmento de medios sucesivo modificando el tiempo de recepción completa del primer segmento de medios con un valor de corrección que compensa una variación en los intervalos de una recepción de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante.

En la siguiente etapa S24, se señaliza el tiempo de disponibilidad estimado a un reproductor, por ejemplo, al reproductor DASH, o bien actualizando directamente el archivo de MPD o bien añadiendo un nuevo encabezamiento de HTTP a la respuesta de HTTP y enviándola de vuelta al servidor para actualizar el archivo de MPD.

A continuación se explican de forma más detallada algunas etapas de la Fig. 3.

La etapa de determinación del tiempo, S22 de acuerdo con la Fig. 3, comprende determinar un tiempo local en el equipo de usuario a la recepción de un segmento de medios completo. El UE mide el tiempo de recepción completa del segmento de medios. El UE captura el tiempo del evento de recepción usando el tiempo de su propio dispositivo. Así, el UE recibe una señal, por ejemplo 13,05, de que el segmento se ha recibido.

La etapa de determinación del tiempo, S22, comprende también una estimación del número de segmento correspondiente al primer segmento recibido. El número de segmento se determina a partir de una forma de plantilla o a partir de una lista de reproducción incluida en el archivo de manifiesto recibido.

Así, cada segmento queda identificado exclusivamente, por ejemplo, por un URL de segmento. Junto con el archivo de MPD, el cliente encuentra el número de segmento. En caso de que se utilice un URL basado en plantillas, el número de segmento se codifica dentro del URL, tal como se ha descrito con respecto a la Fig. 2. En caso de que se utilice un URL basado en listas de reproducción, es necesario que el cliente encuentre la entrada de URL coincidente en el MPD, y el mismo utiliza el índice de entrada de URL de la tabla de lista de reproducción para encontrar el número del segmento recibido.

En la siguiente etapa, S23, se determina un tiempo de disponibilidad de segmentos correspondiente a los siguientes segmentos. Esto se realiza estimando un nuevo availabilityStartTime mediante la consideración del tiempo medido de la recepción del primer segmento de medios con un valor de corrección que compensa una variación de intervalos de una recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante.

En una realización, se propone que el intervalo de tiempo constante sea la duración de un segmento, puesto que es necesaria al menos la duración de un segmento para solicitar el siguiente segmento de medios.

En una realización, se propone que el valor de corrección compense un tamaño variable de segmento correspondiente a los segmentos de medios, en donde el tamaño variable de segmento deriva en la variación de los intervalos de recepción de los segmentos de medios.

En una realización preferida, el minBufferTime se toma como base para la corrección del tiempo de disponibilidad del siguiente segmento. Así, el valor de corrección comprende un minBufferTime que es una indicación del tamaño variable de segmento indicando el tiempo para almacenar temporalmente el contenido de medios, antes de dar inicio a la reproducción, con el fin de evitar cualquier subdesbordamiento, en donde el minBufferTime se recibe en un archivo de manifiesto.

El minBufferTime se lee del archivo de MPD DASH. Cuando se genera el minBufferTime, se tiene en consideración el tamaño cambiante del segmento. Así, el LE, cuando fija el minBufferTime, tiene información sobre la variabilidad de los segmentos de medios generados. El minBufferTime se fija a un valor que evita un subdesbordamiento de la memoria intermedia, con lo que se garantiza que hay disponibles datos suficientes en la memoria intermedia antes de reproducir el contenido. Además, cuando se genera el archivo de MPD también se conoce la duración de un segmento. La duración se tiene en consideración también cuando se genera el minBufferTime, y a continuación el reproductor DASH debe esperar al menos mientras dure un segmento antes de reproducir un segmento. Por lo tanto, en una realización, se propone restar la duración del segmento con respecto a minBufferTime, en caso de que la duración del segmento esté incluida en el minBufferTime. Además, se propone que el minBufferTime se modifique fijándolo a cero, y el minBufferTime modificado se proporciona al reproductor de flujo continuo.

No obstante, el uso del minBufferTime no debería considerarse como una limitación. Alternativamente, puede disponerse de un valor explícito de corrección del tamaño cambiante del segmento que compense el tamaño variable del segmento correspondiente a los segmentos de medios. El valor lo puede proporcionar, por ejemplo, el MPD DASH o se puede proporcionar incluso en el fragmento de Descripción de Servicio de Usuario (USD). En la presente, la estimación de la disponibilidad del segmento correspondiente al tiempo del siguiente segmento se realiza corrigiendo el tiempo de recepción completo del primer segmento con un valor de corrección proporcionado explícitamente.

A continuación se muestra un ejemplo. En este ejemplo, se propone estimar el nuevo tiempo de inicio de disponibilidad (NewAvst) sumando el minBufferTime al tiempo medido de la recepción de un primer segmento, en donde el primer segmento de medios es el segmento de medios actual en el contenido de medios, y restando del valor la duración del segmento. Este ejemplo debería considerarse como ilustrativo y no limitativo. El minBufferTime y la duración del segmento se pueden escalar con un coeficiente (a, p) para reducir el retardo de extremo-a-extremo, aunque cumpliendo todavía el requisito de que no se produzca subdesbordamiento por la recepción de los datos. La realización se basa en una estimación del tiempo de disponibilidad del primer segmento recibido, que es el segmento actual en la transmisión del contenido de medios. La estimación se basa en una determinación de un número de segmento correspondiente al segmento de medios. El número de segmentos se determina a partir de una forma de plantilla o a partir de una lista de reproducción incluida en el archivo de manifiesto recibido.

Así, en la siguiente realización el cálculo es:

NewAvst =time_of_first_seg_received minbufferTime - segment_duration

set minbuffertime=0

startNumber=current_index

De este modo, el cliente suma el valor de minBufferTime y resta del MinBufferTime la duración del segmento, en caso de que la duración del segmento esté incluida en el MinBufferTime.

Además, se propone modificar el minBufferTime fijándolo a cero y modificar el número de segmento fijándolo al número de segmento del segmento de medios actual en el contenido de medios. Puesto que los segmentos se reproducen en caso de difusión general únicamente cuando los segmentos ya se han recibido en el lado del UE, el minBufferTime se puede fijar a cero, y entonces, en caso de difusión general, no es necesario esperar a una recepción completa de un segmento tras reproducirlo, puesto que el segmento ya está allí. El current_index es el número del segmento actual que se puede obtener a partir de la forma de plantilla o, alternativamente, a partir de una lista de reproducción recibida con el archivo de manifiesto. En el caso de una lista de reproducción, deben extraerse todos los elementos de la lista que preceden al número actual.

A continuación, se explica más detalladamente, de acuerdo con un ejemplo, la corrección del tiempo medido.

Suponiendo que el MPD original contiene los siguientes valores, en donde solamente se muestran los parámetros relevantes de un archivo de MPD:

availabilityStartTime= 1300h

startNumber = 1

Duration =10sec

minBufferTime=15 sec

Así, el tiempo en el cual el segmento estaba disponible en el servidor es 1300h, availabilityStartTime. Debe observarse que en este tiempo estaba disponible el primer segmento, startNumber 1. Los siguientes segmentos se generan cada 10 s, y entonces la duración del segmento Duration es 10 s. Además, el minBufferTime se fija a 15 s. Supóngase que un cliente sintoniza en un tiempo particular y mide que el tiempo de la recepción del primer segmento en el cliente es 13:01:10, lo cual significa 70 s después de iniciar la transmisión.

El cliente determina a partir del URL recibido, http//hhhh/seg-8.3gs, que el segmento recibido tiene el índice de segmento 8. En el caso de una lista de reproducción, el índice del URL del segmento se determina de forma correspondiente.

En la siguiente etapa, el cliente crea un MPD nuevo con los siguientes valores

availabilityStartTime: 13:01:10 15sec -10sec = 13:01:15

startNumber = 8

Duration =10sec

minBufferTime=0 sec

De este modo, el tiempo de recepción completa del primer segmento, concretamente el segmento número 8, es 13:01:10, al cual se suma el minBufferTime obtenido a partir del mensaje de MPD original, para compensar la variabilidad de los segmentos, y adicionalmente se resta la duración, puesto que el segmento ya está disponible en la memoria caché del cliente, y por lo tanto no hay necesidad de considerar la duración de transmisión del segmento. La duración de los segmentos sigue siendo 10 s, y el minBufferTime se fija a cero, puesto que el valor ya se considera en el availabilityStartTime.

En la siguiente etapa, se proporciona el tiempo de disponibilidad generado nuevo al reproductor DASH. De este modo, el reproductor DASH toma el archivo de MPD modificado para ordenar los siguientes segmentos.

En este ejemplo, el siguiente segmento se ordenará después de la duración hipotética del segmento de 10 s, por lo tanto en 13:01:25. En este tiempo, el siguiente segmento está disponible y se almacena en la memoria intermedia, y a continuación es la función del LE proporcionar datos de tal manera que estén disponibles en el lado del usuario, por ejemplo, teniendo en consideración el minBufferTime.

En otro ejemplo, se propone corregir el tiempo estimado de disponibilidad del segmento con el availabilityStartTime de un primer segmento del contenido de medios, como el primer segmento del flujo continuo DASH sintonizado. La estimación se basa en la determinación del primer número de segmento en el contenido de medios, habitualmente numerado con 1.

Así, la recepción de un primer segmento de un flujo continuo de medios completos se usa para la corrección de la disponibilidad del primer segmento del flujo continuo DASH real. Esta solución es ventajosa cuando el MPD contiene un valor presentationTimeOffset, el cual evita la modificación del startNumber en el archivo de MPD. El presentationTimeOffset describe la posición del segmento en la línea temporal de los medios.

En este caso, el valor de corrección se actualiza restando del minBufferTime la duración de segmento transcurrida entre el primer segmento de medios del contenido de medios y el segmento de medios actual del contenido de medios (SegmentIndex). Este ejemplo debería considerarse como ilustrativo y no limitativo. El minBufferTime y la duración de segmento se pueden escalar con un coeficiente (a, p) para reducir el retardo de extremo-a-extremo, aunque cumpliendo todavía el requisito de que no se produzca un subdesbordamiento por la recepción de datos. Así, el UE recibe un primer segmento cuando se sintoniza. Además, el UE dispone de un archivo de MPD disponible. El UE lee el número de segmento correspondiente al segmento recibido, y lleva a cabo el siguiente cálculo:

NewAvst= time_of_first_seg_received min_buffer -((SegmentIndex-startNumber) * SegDuration)

set minbuffertime=0

En este caso, el NewAvst es el nuevo tiempo de disponibilidad calculado, el time_of_first_seg_received es el tiempo de recepción del primer segmento, SegmentIndex es el número del primer segmento recibido o, en otras palabras, del segmento actual, y el startNumber es el número del primer segmento de la sesión de contenido de medios, el cual preferentemente se fija con 1. Así, si el índice de segmento determinado es 8 y el primer segmento se indexó con 1, el segmento de medios recibido actual es 7.

Dicho cálculo se explica a continuación basándose en un ejemplo. Supóngase que el MPD original contiene la siguiente información:

availabilityStartTime= 1300h

startNumber = 1

Duration =10sec

minBufferTime=15sec

y el tiempo de recepción del primer segmento es 13:01:10, por lo tanto 70 s después del inicio de la sesión completa de contenido de medios, como una sesión DASH. Además, el UE está adaptado para leer el número del segmento recibido, por ejemplo, a partir del mensaje de solicitud de URL recibido.

La solicitud HTTP recibida del primer segmento recibido puede tener el siguiente formato:

http//hhhh/seg-8.3gs

Así, tal como se ha explicado anteriormente, el número de segmento determinado es por consiguiente 8. Basándose en la determinación del número de segmento, el cliente calcula el nuevo valor de MPD de la siguiente manera: availabilityStartTime 13:01:10 15sec -((8-1) * 10) = 13:00:15

startNumber = 1

Duration =10sec

minBufferTime=0 sec

Se propone modificar el minBufferTime fijándolo a cero, y fijar el número de segmento startNumber al número de segmento del primer segmento del contenido de medios.

La finalidad de la determinación del tiempo de disponibilidad de los segmentos correspondiente al primer segmento es también, en este ejemplo, determinar los tiempos de disponibilidad de segmentos correspondientes a todos los segmentos sucesivos. Debido a las correcciones, el cliente puede usar este tiempo de disponibilidad de segmentos del primer segmento recibido para determinar los tiempos de disponibilidad de segmentos correspondientes a todos los segmentos sucesivos.

Volviendo a la Fig. 3, en la etapa S23 se determina un tiempo de disponibilidad de segmento correspondiente a un segmento de medios sucesivo, modificando el tiempo de la recepción completa del primer segmento de medios con un valor de corrección, en donde el tiempo de disponibilidad de segmento correspondiente a un segmento de medios sucesivo se puede basar o bien en la estimación del tiempo de disponibilidad del primer segmento recibido (segmento de medios actual) o bien del tiempo de disponibilidad estimado para el primer segmento en el flujo continuo DASH. Comúnmente, con independencia de la estimación del índice de segmento, el valor del tiempo de la recepción completa del primer segmento de medios se modifica con un valor de corrección que compensa la variación del intervalo de recepción de los segmentos de medios, por ejemplo, debido al tamaño variable de los segmentos.

En la siguiente etapa de la Fig. 3, S24, se señaliza el tiempo de disponibilidad estimado a un reproductor, tal como, por ejemplo, al reproductor DASH, o bien actualizando directamente el archivo MPD o bien añadiendo un nuevo encabezamiento de HTTP a la respuesta de HTTP y devolviéndola al servidor para actualizar el archivo de MPD. Así, se propone que la etapa de señalización del tiempo de disponibilidad estimado al reproductor de flujo continuo S24 comprenda la actualización del archivo de manifiesto con el tiempo de disponibilidad estimado y la provisión del manifiesto al reproductor de flujo continuo.

Alternativamente, se propone que la etapa de señalización del tiempo de disponibilidad estimado al reproductor de flujo continuo S24 comprenda la adición de un nuevo encabezamiento de HTTP a una respuesta de HTTP, y su devolución al dispositivo servidor para actualizar el archivo de manifiesto y proporcionar dicho archivo de manifiesto al reproductor de flujo continuo.

Debe decirse que el MPD, con independencia de cómo se haya modificado, se puede recuperar usando unidifusión o se puede enviar a través de un canal de anuncio de servicio, por ejemplo, cualquier canal de difusión general adecuado. Además, debe indicarse que el MPD se puede generar de antemano.

Además, se propone que la etapa de señalización del tiempo de disponibilidad estimado al reproductor de flujo continuo, S24, comprenda señalizar el minBufferTime modificado y el número de segmento, por ejemplo, modificando el archivo de MPD.

En otra realización, se propone modificar la disponibilidad del segmento en el lado del servidor.

A continuación se presenta la realización según la Fig. 4.

En una primera etapa, S31, el servidor toma un availabilityStartTime original para una sesión de contenido de medios particular, como un flujo continuo DASH. availabilityStartTime original significa el tiempo en el cual está disponible un segmento para la transmisión en el servidor y según es calculado por el dispositivo servidor.

En la siguiente etapa S32, se propone que la entidad del lado del servidor modifique el availabilityStartTime para cumplir con la regla “un segmento nuevo resulta disponible cada duración de segmento en el lado del UE”. Así, se propone el uso de un valor de corrección que compensa una variación en los intervalos de una recepción de segmentos de medios, de manera que se hace que los segmentos de medios estén disponibles en el reproductor de flujo continuo con un intervalo de tiempo constante.

En una realización se propone que el valor de corrección considere un tamaño variable de los segmentos correspondiente a los segmentos de medios y un retardo del sistema de extremo-a-extremo, en donde el retardo del sistema de extremo-a-extremo es el tiempo necesario para transportar un segmento de medios desde un dispositivo servidor a un equipo de usuario a través del enlace de transmisión.

En una realización, se propone que el valor de corrección considere un tamaño variable de los segmentos correspondiente a los segmentos de medios. Preferentemente, el valor de corrección comprende un minBufferTime, que es una indicación del tamaño variable de los segmentos, indicando el tiempo para almacenar temporalmente el contenido de los medios antes de dar inicio a la reproducción de dicho contenido de medios. Puesto que los segmentos podrían tener un tamaño diferente, el valor de minBufferTime se incluye en el availabilityStartTime para evitar que el UE solicite un segmento no existente. Tal como ya se ha mencionado, con la generación del minBufferTime, el Codificador en Vivo tiene en consideración la variación del tamaño de los segmentos, y suma dicho valor al availabilityStartTime. Así, el tamaño del minBufferTime compensa al menor la variación de los tamaños de los segmentos que son conocidos para el codificador en vivo. Por lo tanto, se propone el uso del minBufferTime para garantizar que un segmento de medios sucesivo resulta disponible cada duración de segmento en el lado del UE.

Además, se propone que el valor de corrección comprenda un retardo del sistema de extremo-a-extremo (max_offset).

Así, se propone que el servidor añada al availabilityStartTime un valor de corrección que tiene en consideración un retardo del sistema de extremo-a-extremo y la variabilidad del tamaño de los segmentos. El tiempo de retardo de extremo-a-extremo es el tiempo necesario para transportar un segmento desde el BM-SC hasta el UE, el cual es conocido para el servidor. No obstante, cada codificador en vivo tiene su propia regla de “velocidad de bits objetivo”, que controla los diferentes tamaños de los segmentos y su variabilidad. Por lo tanto, el valor añadido depende preferentemente de la implementación del Codificador en Vivo y del perfil de retardo usado, por ejemplo, el bajo retardo de extremo-a-extremo fijado o excluido.

Además, se propone que el valor de corrección comprenda un valor de deriva hacia delante (maxdriftahead) que indica una deriva máxima del reloj hacia delante. El valor de maxdriftahead representa la deriva máxima del reloj que es aceptable. En otros términos, si el reloj de un UE se deriva en más de este valor máximo, el UE no tendrá la capacidad de reproducir el contenido de medios y será necesaria una sincronización del reloj del UE.

Así, el nuevo tiempo de inicio de disponibilidad New Avst se calcula tomando el tiempo de inicio de disponibilidad original avst_^org según es determinado por el servidor y sumando el MinBufferTime, min_buffer con el fin incluir el minBufferTime para evitar que se solicite un segmento no existente. Además, también se suma el valor de max_offset, que es el retardo máximo de extremo-a-extremo. Dicho valor es conocido también para el dispositivo servidor. El LE puede prestar servicio a diferentes sistemas con diferentes retardos de extremo-a-extremo, y el valor de max_offset proporciona el retardo posible máximo en la entrega de segmentos. Además, se suma el valor de maxdriftahead.

New Avst =avst_^org+min_buffer+max_offset+maxdriftahead

Además, debe indicarse que el valor de corrección depende de una implementación del Codificador en Vivo y de un perfil de retardo.

En la siguiente etapa, S33, se propone el envío del availabilityStartTime modificado hacia el reproductor de flujo continuo. En particular, se propone que la etapa de señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo comprenda sustituir el tiempo original de disponibilidad de los segmentos de medios, availabilityStartTime, en un archivo de manifiesto, por el tiempo estimado de disponibilidad de los segmentos de medios, y enviar dicho archivo de manifiesto al reproductor de flujo continuo.

En una realización, se propone modificar el availabilityStartTime en el archivo de MPD en el lado del servidor, en donde el MPD recién creado contiene el valor de Avst modificado. En una realización, se propone que el minBufferTime se pueda fijar a cero (min-buffertime=0), en particular en el caso en el que al cliente no se le permite cambiar dicho temporizador. En una realización preferida, el minBufferTime se proporciona al reproductor de flujo continuo con el archivo de manifiesto.

La Fig. 5 ilustra esquemáticamente estructuras ejemplificativas para implementar los conceptos antes descritos en un equipo de usuario UE 41, que está configurado para proporcionar un contenido de medios que comprende segmentos de medios a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo a través de una transmisión de difusión general.

El UE comprende un receptor 42 adaptado para recibir un primer segmento de medios. Además, el UE 41 comprende una unidad lógica 44 de determinación, adaptada para determinar el tiempo de recepción del primer segmento de medios. Además, el UE comprende una unidad lógica 45 de estimación, adaptada para estimar un tiempo de disponibilidad de los segmentos de medios con el fin de solicitar segmentos de medios sucesivos, modificando el tiempo de la recepción del primer segmento de medios con un valor de corrección que compensa una variación en los intervalos de una recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante. Por otra parte, se dispone de un emisor 46 adaptado para señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo.

Además, el UE puede comprender una unidad lógica de modificación (no mostrada) para modificar el archivo de manifiesto. La modificación se puede realizar según cualquier forma preferible, por ejemplo, modificando un encabezamiento de HTTP o añadiendo un encabezamiento de HTTP nuevo para enviarlo al reproductor de flujo continuo. En una solución preferida, el archivo de manifiesto, tal como el archivo MPD, se modifica directamente y se proporciona al reproductor de flujo continuo.

Debe indicarse que la Fig. 5 ilustra varias unidades funcionales en el equipo 41 de usuario, y los expertos pueden implementar estas unidades funcionales en la práctica usando software y hardware adecuados. Así, la solución no se limita de manera general a las estructuras mostradas del equipo de usuario, y las unidades funcionales 42 a 46 se pueden configurar para funcionar de acuerdo con cualquiera de las características descritas en esta exposición, cuando ello resulte adecuado.

Las unidades funcionales 42 a 46 antes descritas se pueden implementar en el UE 41 por medio de módulos de programa de un programa de ordenador respectivo que comprende medios de código los cuales, cuando son ejecutados por un procesador, consiguen que el UE 41 lleve a cabo las acciones y procedimientos antes descritos. El procesador puede comprender una sola Unidad de Procesado Central (CPU), o podría comprender dos o más unidades de procesado. Por ejemplo, el procesador puede incluir un microprocesador de propósito general, un procesador con conjunto de instrucciones y/o conjuntos de chips (chips sets) relacionados y/o un microprocesador de propósito especial, tal como un Circuito Integrado de Aplicación Específica (ASIC). El procesador también puede comprender unos medios de almacenamiento con fines relacionados con el almacenamiento en memoria caché.

Cada programa de ordenador puede estar contenido en un producto de programa de ordenador en el UE 41 en forma de una memoria que tiene un soporte legible por ordenador y que está conectada al procesador. Así, el producto de programa de ordenador o memoria comprende un soporte legible por ordenador en el cual se almacena el programa de ordenador, por ejemplo, en forma de módulos de programa de ordenador. Por ejemplo, la memoria puede ser una memoria flash, una Memoria de Acceso Aleatorio (RAM), una Memoria de Solo Lectura (ROM) o una ROM Programable y Borrable Eléctricamente (EEPROM), y los módulos de programa, en realizaciones alternativas, se podrían distribuir en diferentes productos de programa de ordenador en forma de memorias dentro del UE 41. La Fig. 6 ilustra esquemáticamente estructuras ejemplificativas para implementar los conceptos antes descritos, en un dispositivo servidor 51 el cual está configurado para proporcionar un contenido de medios que comprende segmentos de medios a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten a través de una emisión de difusión general. El dispositivo servidor 51 comprende un receptor 54 adaptado para estimar un tiempo original de disponibilidad de segmentos de medios que indica el tiempo en el que se hace que esté disponible el segmento de medios para su descarga en el dispositivo servidor, de ahí availabilityStartTime original. Además, el dispositivo servidor 51 comprende un procesador 53 adaptado para estimar un tiempo de disponibilidad de segmentos de medios con el fin de solicitar segmentos de medios sucesivos modificando el tiempo original de disponibilidad de segmentos de medios, availabilityStartTime original, con un valor de corrección que compensa una variación en los intervalos de una recepción de segmentos de medios, de manera que se hace que los segmentos de medios estén disponibles en el reproductor de flujo continuo con un intervalo de tiempo constante. Por otra parte, se dispone de un emisor 52 adaptado para señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo.

Debe indicarse que la Fig. 6 ilustra varias unidades funcionales en el dispositivo servidor 51, y aquellos versados en la materia pueden implementar estas unidades funcionales en la práctica usando software y hardware adecuados. Así, la solución no se limita de manera general a las estructuras mostradas del equipo de usuario, y las unidades funcionales 52 a 54 se pueden configurar para funcionar de acuerdo con cualquiera de las características descritas en esta exposición, cuando ello resulte apropiado.

Las unidades funcionales 52 a 54 antes descritas se pueden implementar en el dispositivo servidor 51 por medio de módulos de programa de un programa de ordenador respectivo que comprende medios de código los cuales, cuando son ejecutados por un procesador, consiguen que el dispositivo servidor 51 lleve a cabo las acciones y procedimientos antes descritos. El procesador puede comprender una sola Unidad de Procesado Central (CPU), o podría comprender dos o más unidades de procesado. Por ejemplo, el procesador puede incluir un microprocesador de propósito general, un procesador con conjunto de instrucciones y/o conjuntos de chips (chips sets) relacionados y/o un microprocesador de propósito especial, tal como un Circuito Integrado de Aplicación Específica (ASIC). El procesador también puede comprender unos medios de almacenamiento con fines relacionados con el almacenamiento en memoria caché.

Cada programa de ordenador puede estar contenido en un producto de programa de ordenador en el dispositivo servidor 51 en forma de una memoria que tiene un soporte legible por ordenador y que está conectada al procesador. Así, el producto de programa de ordenador o memoria comprende un soporte legible por ordenador en el cual se almacena el programa de ordenador, por ejemplo, en forma de módulos de programa de ordenador. Por ejemplo, la memoria puede ser una memoria flash, una Memoria de Acceso Aleatorio (RAM), una Memoria de Solo Lectura (ROM) o una ROM Programable y Borrable Eléctricamente (EEPROM), y los módulos de programa, en realizaciones alternativas, se podrían distribuir en diferentes productos de programa de ordenador en forma de memorias dentro del dispositivo servidor 51.

Debe entenderse que los ejemplos y realizaciones que se han explicado antes son meramente ilustrativos y susceptibles de experimentar varias modificaciones. Por ejemplo, los conceptos se podrían usar en otros tipos de redes de comunicaciones de móviles, no mencionadas explícitamente hasta el momento. Además, debe entenderse que los conceptos anteriores se pueden implementar usando software diseñado de manera correspondiente en nodos existentes, o usando hardware dedicado en los nodos respectivos.

Claims (30)

REIVINDICACIONES

1. Método para proporcionar contenido de medios que comprende segmentos de medios a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo, siendo el método ejecutable en un equipo de usuario y comprendiendo las etapas de:

- recibir un primer segmento de medios (S21);

- determinar el tiempo de recepción del primer segmento de medios (S22);

caracterizado por

- estimar un tiempo de disponibilidad de segmentos de medios para solicitar segmentos de medios sucesivos modificando el tiempo determinado de la recepción del primer segmento de medios con un valor de corrección que compensa una variación en los intervalos de recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante (S23);

- señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo (S24).

2. Método según la reivindicación 1,

en el que la etapa de determinación (S22) del tiempo de recepción del primer segmento de medios comprende determinar un tiempo local en el equipo de usuario en la recepción del primer segmento de medios completamente.

3. Método según la reivindicación 1,

en el que la etapa de determinación (S22) del tiempo de recepción del primer segmento de medios comprende una estimación de un número de segmento del primer segmento recibido.

4. Método según una de las reivindicaciones 1 a 3, en el que el número de segmento se determina a partir de una forma de plantilla o a partir de una lista de reproducción incluida en el archivo de manifiesto recibido.

5. Método según la reivindicación 1, en el que el intervalo de tiempo constante es la duración del segmento.

6. Método según la reivindicación 1, en el que el valor de corrección tiene en consideración un tamaño de segmento variable de los segmentos de medios, en donde el tamaño de segmento variable conduce a la variación de los intervalos de recepción de los segmentos de medios.

7. Método según la reivindicación 6, en el que el valor de corrección comprende un minBufferTime, que es una indicación del tamaño de segmento variable, indicando el tiempo para almacenar temporalmente el contenido de medios antes de dar inicio a la reproducción de dicho contenido de medios.

8. Método según la reivindicación 5 o 6, en el que el minBufferTime se recibe en un archivo de manifiesto recibido desde el dispositivo servidor.

9. Método según una de las reivindicaciones 1 a 8, en el que la etapa de estimación del tiempo de disponibilidad de segmentos de medios, Avst, se basa en la estimación del tiempo de disponibilidad del primer segmento de medios recibido, time_of_first_seg_received, en donde el primer segmento de medios es el segmento de medios actual en el contenido de medios.

10. Método según la reivindicación 9, en el que el valor de corrección se actualiza restando del minBufferTime la duración del segmento,

NewAvst=time_of_first_seg_received minbufferTime - segment_duration.

11. Método según una de las reivindicaciones 7 a 10, en el que el minBufferTime se modifica fijándolo a cero y el número de segmentos se fija al número de segmento del segmento de medios actual en el contenido de medios.

12. Método según una de las reivindicaciones 1 a 8, en el que la etapa de estimación del tiempo de disponibilidad de segmentos de medios se basa en una estimación del tiempo de disponibilidad del primer segmento de medios recibido, time_of_first_seg_received, y en un primer segmento de medios del contenido de medios, startNumber.

13. Método según la reivindicación 12, en el que el valor de corrección se actualiza restando la duración segmental transcurrida entre el primer segmento de medios en el contenido de medios y el segmento de medios actual en el contenido de medios, SegmentIndex, del minBufferTime,

NewAvst=time_of_first_seg_received minbufferTime -((SegmentIndex-startNumber) * duración de segmento).

14. Método según la reivindicación 13, en el que el minBufferTime se modifica fijándolo a cero, y el número de segmentos se fija al número de segmento del primer segmento en el contenido de medios.

15. Método según la reivindicación 5, en el que el valor de corrección es un valor de tamaño de segmento cambiante explícito que compensa el tamaño de segmento variable de los segmentos de medios.

16. Método según la reivindicación 1, en el que la etapa de señalización del tiempo de disponibilidad estimado al reproductor de flujo continuo (S24) comprende actualizar el archivo de manifiesto con el tiempo de disponibilidad estimado y proporcionar el manifiesto al reproductor de flujo continuo.

17. Método según la reivindicación 1, en el que la etapa de señalización del tiempo de disponibilidad estimado al reproductor de flujo continuo (S24) comprende modificar un encabezamiento de HTTP o añadir un encabezamiento de HTTP nuevo a una respuesta de HTTP y enviarla al reproductor de flujo continuo.

18. Método según una de las reivindicaciones 1, 11, 14, en el que la etapa de señalización del tiempo de disponibilidad estimado al reproductor de flujo continuo (S24) comprende además señalizar el minBufferTime modificado y el número de segmento.

19. Método para proporcionar contenido de medios que comprende segmento de medios, a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo, comprendiendo el método las etapas de, y siendo ejecutable en un servidor:

- estimar un tiempo de disponibilidad de segmentos de medios original que indica el tiempo en el que se hace que el segmento de medios esté disponible para su transmisión en el dispositivo servidor (S31);

caracterizado por

- estimar un tiempo de disponibilidad de segmentos de medios para solicitar segmentos de medios sucesivos modificando el tiempo de disponibilidad original de segmentos de medios con un valor de corrección que compensa una variación en los intervalos de una recepción de segmentos de medios, de manera que se hace que los segmentos de medios estén disponibles en el reproductor de flujo continuo con un intervalo de tiempo constante (532) ;

- señalizar el tiempo estimado de disponibilidad de los segmentos de medios al reproductor de flujo continuo (533) .

20. Método según la reivindicación 19, en el que el valor de corrección tiene en consideración un tamaño de segmento variable de los segmentos de medios.

21. Método según la reivindicación 19 o 20, en el que el valor de corrección comprende un minBufferTime, que es una indicación del tamaño de segmento variable, indicando el tiempo para almacenar temporalmente el contenido de medios antes de dar inicio a la reproducción de dicho contenido de medios.

22. Método según una de las reivindicaciones 19 a 21, en el que el valor de corrección comprende un retardo del sistema de extremo-a-extremo, max_offset.

23. Método según una de las reivindicaciones 19 a 22, en el que el valor de corrección comprende además un valor de deriva hacia delante, maxdriftahead, que indica una deriva máxima del reloj hacia delante.

24. Método según una de las reivindicaciones 19 a 21, en el que el valor de corrección depende de una implementación del Codificador en Vivo y de un perfil de retardo.

25. Método según la reivindicación 19, en el que la etapa de señalización del tiempo de disponibilidad estimado al reproductor de flujo continuo (S33) comprende sustituir el tiempo original de disponibilidad de los segmentos de medios, availabilityStartTime, en un archivo de manifiesto, por el tiempo estimado de disponibilidad de los segmentos de medios, y enviar dicho archivo de manifiesto al reproductor de flujo continuo.

26. Método según la reivindicación 24, en el que además el minBufferTime se modifica fijándolo a cero, y en donde el minBufferTime modificado se proporciona al reproductor de flujo continuo con el archivo de manifiesto.

27. Dispositivo (41) de equipo de usuario adaptado para proporcionar un contenido de medios que comprende segmentos de medios, a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo, comprendiendo el dispositivo:

- un receptor (42) adaptado para recibir un primer segmento de medios;

- una unidad lógica (44) de determinación, adaptada para determinar el tiempo de recepción del primer segmento de medios;

caracterizado por

- una unidad lógica (45) de estimación adaptada para estimar un tiempo de disponibilidad de segmentos de medios con el fin de solicitar segmentos de medios sucesivos modificando el tiempo determinado de la recepción del primer segmento de medios con un valor de corrección que compensa una variación en los intervalos de una recepción de segmentos de medios, de manera que el reproductor de flujo continuo recibe los segmentos de medios con un intervalo de tiempo constante;

- un emisor (46) adaptado para señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo.

28. Dispositivo según la reivindicación 27, en el que el dispositivo comprende además una unidad lógica de modificación para modificar un archivo de manifiesto con el tiempo estimado de disponibilidad de los segmentos de medios.

29. Dispositivo según la reivindicación 28, en el que la unidad lógica de modificación está adaptada para modificar un encabezamiento de HTTP o para añadir un encabezamiento de HTTP nuevo para enviarla al reproductor de flujo continuo.

30. Dispositivo servidor (51) adaptado para proporcionar un contenido de medios que comprende segmentos de medios, a un reproductor de flujo continuo, en donde los segmentos de medios se transmiten desde un dispositivo servidor a un reproductor de flujo continuo, comprendiendo el dispositivo:

- un receptor (54) adaptado para estimar un tiempo original de disponibilidad de los segmentos de medios que indica el tiempo en el que se hace que el segmento de medios esté disponible para su transmisión en el dispositivo servidor;

caracterizado por

- un procesador (53) adaptado para estimar un tiempo de disponibilidad de segmentos de medios con el fin de solicitar segmentos de medios sucesivos modificando el tiempo original de disponibilidad de los segmentos de medios con un valor de corrección que compensa una variación en los intervalos de una recepción de segmentos de medios, de manera que se hace que los segmentos de medios estén disponibles en el reproductor de flujo continuo con un intervalo de tiempo constante;

- un emisor (52) adaptado para señalizar el tiempo de disponibilidad estimado al reproductor de flujo continuo.