ES2704625T3 - Sistema y procedimiento para transferencia de flujo adaptativa en un entorno multicamino - Google Patents

Sistema y procedimiento para transferencia de flujo adaptativa en un entorno multicamino Download PDF

Info

Publication number
ES2704625T3
ES2704625T3 ES12196438T ES12196438T ES2704625T3 ES 2704625 T3 ES2704625 T3 ES 2704625T3 ES 12196438 T ES12196438 T ES 12196438T ES 12196438 T ES12196438 T ES 12196438T ES 2704625 T3 ES2704625 T3 ES 2704625T3
Authority
ES
Spain
Prior art keywords
client
servers
server
controller
bit rate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12196438T
Other languages
English (en)
Inventor
Stephane Gouache
Guillaume Bichot
Amine Bsila
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Madison Patent Holdings SAS
Original Assignee
InterDigital Madison Patent Holdings SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by InterDigital Madison Patent Holdings SAS filed Critical InterDigital Madison Patent Holdings SAS
Application granted granted Critical
Publication of ES2704625T3 publication Critical patent/ES2704625T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2665—Gathering content from different sources, e.g. Internet and satellite
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

Un cliente para obtener un contenido audiovisual por medio de una técnica de transferencia de flujo adaptativa multicamino en un entorno de red que comprende una serie de servidores (14, 16, 18), estando adaptado cada uno de dichos servidores para la transmisión de dicho contenido multimedia en base a un protocolo de comunicación compatible con RTP/RTSP a través de respectivos caminos de datos (20, 22, 24) a dicho cliente (12), en el que el cliente (12) incluye un controlador (40) que sondea cada uno de dichos caminos de datos (20, 22, 24) para determinar un respectivo ancho de banda asociado con cada uno de dichos caminos de datos (20, 22, 24) y solicita diferentes porciones de dicho contenido multimedia desde cada uno de dichos servidores (14, 16, 18) de acuerdo con el respectivo ancho de banda determinado y con un tiempo de reproducción de dichas porciones solicitadas.

Description

DESCRIPCIÓN
Sistema y procedimiento para transferencia de flujo adaptativa en un entorno multicamino
Introducción
Esta invención se refiere a un sistema para transferencia de flujo adaptativa en un entorno multicamino. Más particularmente, esta invención se refiere a un sistema para transferencia de flujo adaptativa en un entorno multicamino en el que no se garantizan condiciones de ancho de banda de la red y por lo tanto fluctúan, para mejorar la transferencia de flujo de audio/video. Además, la invención se refiere a un procedimiento para transferencia de flujo adaptativa en un entorno multicamino.
Antecedentes de la invención
La transferencia de flujo es el proceso en que el contenido consumido por un cliente es enviado en pequeñas piezas al cliente, a diferencia de la descarga, donde el archivo multimedia íntegro es transferido al cliente antes de su reproducción. Los protocolos existentes de transferencia de flujo incluyen un protocolo de transporte en tiempo real (RTP) o un flujo de transporte MPEG bajo el protocolo de datagramas de usuario (MPEG TS/UDP). Por otra parte, la descarga se realiza generalmente utilizando un protocolo de transferencia de hipertexto (protocolo HTTP).
En sistemas de entretenimiento y comunicaciones, el protocolo RTSP (transferencia de flujo de transporte en tiempo real) está dispuesto como un protocolo de control de red para controlar servidores de medios de transferencia de flujo. La transmisión de datos de transferencia de flujo mediante servidores RTSP se realiza mediante el protocolo de transporte en tiempo real (RTP). El RTSP define secuencias de control útiles para controlar la reproducción de datos de transferencia de flujo. Las secuencias de control se definen en el estándar RFC 2326 mediante el grupo de trabajo de ingeniería de internet (IETF, Internet Engineering Task Force).
La sesión de transferencia de flujo es iniciada por el cliente hacia el servidor de transferencia de flujo. El servidor de transferencia de flujo suministra el video solicitado sobre un enlace de unidifusión hacia el cliente. El establecimiento de la sesión de transferencia de flujo implica varios mensajes RTSP entre el cliente y el servidor de transferencia de flujo, que involucran habitualmente selección de contenido e indicación de características del cliente tales como el tamaño de la pantalla, la tasa de bits o el tamaño máximo de la memoria tampón. La sesión de transferencia de flujo RTP de unidifusión se establece finalmente utilizando parámetros negociados previamente. Los parámetros de sesión de transferencia de flujo permanecen generalmente sin cambios hasta que el cliente selecciona otro contenido o finaliza la sesión de transferencia de flujo. Obviamente, este tipo de entorno no está bien adaptado a características de red variables. Algunos operadores simplemente eligen limitar el acceso a determinados servicios, a clientes que tienen suficiente ancho de banda extra por encima del ancho de banda requerido real para evitar problemas.
La transferencia de flujo en tiempo real se ha hecho cada vez más popular para transmitir canales de TV por medio de internet (IPTV). No obstante, se han proporcionado medios para hacer frente a tasas de ancho de banda cambiantes entre el proveedor de multimedia y el cliente. De lo contrario, se produciría la "congelación" de los flujos de multimedia, lo que generalmente es considerado como una molestia por el abonado.
Se han realizado varios intentos para resolver el problema mencionado anteriormente de cambiar las tasas de ancho de banda.
El documento "Distributed and Adaptive HTTP Streaming" de S. Gouache et al., 2011 IEEE International Conference on multimedia and Expo (ICME), de julio de 2011, da a conocer un procedimiento de transferencia de flujo adaptativa HTTP que explota simultáneamente múltiples caminos en un entorno distribuido de transferencia de flujo.
En el documento WO 2002/073441 A1, un único archivo se divide en múltiples sub-archivos que a continuación son distribuidos y almacenados en uno o varios servidores. Los sub-archivos pueden ser transmitidos en paralelo y simultáneamente desde uno o varios servidores, lo que aumenta la velocidad a la que se pueden suministrar los datos. Además, por lo menos uno de los sub-archivos se puede almacenar en más de un servidor para proporcionar redundancia. Si un servidor no está disponible, o si el enlace de transmisión es lento o no está disponible, el sub­ archivo se puede transferir en flujo continuo desde otro servidor.
En el documento US 2009/0259762 A1, se muestra una arquitectura de transferencia de flujo de contenidos distribuida y escalable que incluye una serie de controladores y una serie de servidores. Los controladores pueden funcionar para establecer sesiones de protocolo de transferencia de flujo en tiempo real (RTSP) con dispositivos individuales. Un controlador selecciona un servidor para proporcionar un flujo de medios solicitado a un dispositivo. El servidor se puede seleccionar en base a su proximidad al dispositivo, a la disponibilidad de ancho de banda o a características de latencia. Se pueden añadir servidores adicionales a un sistema sin perturbar el funcionamiento del sistema.
El documento WO 2010/111261 A1 muestra un sistema de medios de transferencia de flujo, que utiliza adaptación dinámica de la velocidad. Esto incluye un formato de archivo compatible con infraestructura HTTP heredada para suministrar medios sobre una conexión persistente. Los reproductores de medios del cliente heredados pueden cambiar dinámicamente la tasa de suministro codificado de los medios sobre una conexión persistente.
En el documento US 2010/0094955 A1 se muestra un almacenamiento distribuido en el que para cada grupo de por lo menos un dispositivo de ensamblaje, se selecciona un subgrupo de servidores CDN de almacenamiento fraccional, según por lo menos un criterio. Se selecciona una serie de subgrupos de servidores para una serie de grupos de dispositivos de ensamblaje. Se recuperan fragmentos de código de borrado asociados con múltiples segmentos de contenidos, mediante los dispositivos de ensamblaje, desde los subgrupos de servidores, hasta que el ancho de banda agregado utilizado para recuperar los fragmentos se aproxima al ancho de banda agregado de los servidores incluidos en los subgrupos, y siempre que el ancho de banda agregado utilizado para suministrar cada segmento no supere el ancho de banda agregado de los servidores que almacenan los fragmentos generados a partir del segmento.
US 2006/0215596 A1 muestra ajustes de la velocidad de transferencia para un dispositivo, por ejemplo un servidor multimedia. Estos ajustes de la velocidad se basan en la determinación, mediante un servidor multimedia, de varios parámetros de calidad de servicio a partir de un enlace inalámbrico entre otros dos nodos de red, que pueden comprender un punto de acceso y un reproductor de video, respectivamente.
Se da a conocer la transmisión de transferencia de flujo de datos del documento US6405256B1, con un servidor de red conectado a un dispositivo cliente a través de una red de comunicación con uno o varios servidores de almacenamiento en caché. El servidor de red tiene una aplicación de transferencia de flujo de datos y una memoria para almacenar datos. Se forman una serie de conexiones, cada una de las cuales utiliza una disposición de transferencia de flujo de datos, en el camino entre la red de origen y el dispositivo cliente, mediante los servidores de almacenamiento en caché. Cada servidor de almacenamiento en caché puede absorber congestión de la red en su conexión descendente utilizando una memoria tampón expandible para almacenar segmentos adicionales de los datos en flujo continuo y variar la velocidad de transmisión de los datos en la conexión descendente.
Además, el proyecto de asociación de tercera generación (3GPP, 3rd Generation Partnership Project) ha estandarizado un marco de suministro que incluye un formato de recipiente que puede almacenar múltiples versiones (que deberían tener diferentes tasas de bits de codificación) de un mismo contenido que, asociado a una lógica de control inteligente en el lado del servidor de transferencia de flujo, puede hacer frente a variaciones en las condiciones de la red. Sin embargo, esta lógica de control no ha sido especificada por 3GPP.
La transferencia de flujo HTTP es una tecnología anunciada recientemente por Apple con su iPhone, por Microsoft con Smoothstreaming o por 3GPP con su transferencia de flujo adaptativa HTTP.
Las técnicas recientes utilizan el protocolo HTTP para proporcionar periódicamente retroalimentación del cliente al servidor sobre las condiciones actuales de la red. El contenido adaptativo, que son pequeñas porciones del contenido multimedia de duración fija pero con tasa de bits variable, se sirve al cliente adaptándose al mismo tiempo constantemente las condiciones de la red.
El inconveniente obvio es que la calidad percibida por el cliente se puede degradar seriamente cuando el ancho de banda varía. Además, estas técnicas no aprovechan los equipos IPTV existentes que dependen de protocolos RTP/RTSP.
Por consiguiente, existe una necesidad en la técnica de proporcionar un procedimiento y un sistema para transferencia de flujo adaptativa en un entorno multicamino que supere respectivamente -por lo menos parcialmentelos problemas asociados con los sistemas de la técnica anterior.
Compendio de la invención
La invención propone un mecanismo que ofrece control inmediato sobre la tasa de transferencia de flujo al cliente, aprovechando al mismo tiempo una infraestructura IPTV existente que utiliza protocolo RTSP/RTP. RTSP (RFC 2326) es un protocolo para establecer y controlar la transferencia de flujo de medios. No cubre el protocolo de transporte para los propios datos, que normalmente es RTP. Además, compensa las fluctuaciones de la red mediante la utilización simultánea de múltiples caminos de comunicación, suavizando la tasa de recepción global y la experiencia del usuario asociada.
La invención propone un formato de archivo, que permite una conmutación sin discontinuidades entre las versiones a diferentes tasas de bits, de manera similar a la transferencia de flujo adaptativa HTTP.
Una utilización inteligente del protocolo RTSP permite sondear el estado de la red y controlar la velocidad del flujo mediante el cliente sin modificar la infraestructura existente de servidores, aprovechando al mismo tiempo la comunicación multicamino. En lugar de solicitar un flujo entero tal como con en IPTV heredado, el cliente recibe fragmentos independientes de flujos procedentes de múltiples servidores para beneficiarse de la comunicación multicamino. La velocidad de transmisión se ajusta individualmente para cada servidor con el objeto de minimizar el riesgo de congestión de la red.
Además, el cliente solicita periódicamente a los servidores que transfieran continuamente pequeños fragmentos del flujo a una velocidad mayor que la velocidad nominal con el fin de evaluar la capacidad de la red entre sí mismos y el servidor para suministrar una parte más importante del contenido. Cuando la capacidad agregada de todos los caminos de la red es suficiente para un flujo a tasa de bits mayor, el cliente envía una solicitud diferente a todos los servidores para seleccionar una versión de tasa de bits mayor del flujo. Cuando la velocidad de recepción del flujo es demasiado lenta para la velocidad de emisión actual, el cliente solicita a los servidores seleccionar una versión de tasa de bits menor del contenido.
La invención añade la capacidad de adaptar las variaciones de la red en el denominado entorno IPTV (administrado) al ser completamente compatible con el conjunto asociado de protocolos, basado en RTSP/RTP, sin requerir sustitución de los equipos. Además, tiende a suavizar las variaciones rápidas de ancho de banda de un único camino de la red mediante distribuir la comunicación sobre múltiples caminos de red.
Descripción detallada de la invención
La invención se describirá a continuación en mayor detalle a modo de ejemplo haciendo referencia a los siguientes dibujos, en los cuales:
la figura 1 muestra una vista esquemática de un sistema para transferencia de flujo adaptativa en un entorno multicamino, de acuerdo con una realización de la invención;
la figura 2 muestra otra vista esquemática de un sistema para transferencia de flujo adaptativa en un entorno multicamino, de acuerdo con una realización de la invención;
la figura 3 muestra una vista esquemática de comunicación cliente-servidor, de acuerdo con una realización de la invención;
la figura 4 muestra otra vista esquemática de comunicación cliente-servidor, de acuerdo con una realización de la invención;
la figura 5 muestra otra vista esquemática de comunicación cliente-servidor, de acuerdo con una realización de la invención;
la figura 6 muestra otra vista esquemática de comunicación cliente-servidor, de acuerdo con una realización de la invención; y
la figura 7 muestra otra vista esquemática de un cliente, de acuerdo con una realización de la invención.
En los dibujos, los numerales de referencia similares se refieren a partes similares, salvo que se indique lo contrario. Haciendo referencia a continuación a la figura 1 en particular, la invención realizada en la misma comprende un sistema 10 para transferencia de flujo adaptativa en un entorno multicamino que comprende un cliente 12 y una serie de servidores que pueden respectivamente transmitir contenido multimedia en un entorno RTP/RTSP a través del respectivo camino de datos hasta el cliente 12. El cliente 12 se representa como un descodificador junto con una pantalla. En la figura 1, se muestra como un ejemplo un primer servidor 14, un segundo servidor 16 y un tercer servidor 18, que están respectivamente conectados al cliente a través de un primer camino 20, un segundo camino 22 y un tercer camino 24.
De manera similar a la mayor parte de las técnicas de transferencia de flujo adaptativa, el contenido tiene que ser codificado previamente a múltiples tasas de bits para soportar suministro adaptativo. Además, las diferentes versiones de los flujos están "alineadas GOP", lo que significa que las posiciones de las tramas de referencia, que permiten el acceso aleatorio a los flujos, están situadas en los mismos instantes de tiempo para todos los flujos de tasas de bits diferentes. Esta propiedad permite que un descodificador conmute entre diferentes flujos en algunas posiciones precisas (las tramas de referencia) sin ningún artefacto visual. A continuación se permite al cliente 12 solicitar/descargar una porción de cualquiera de estas versiones de flujo, donde la porción es un conjunto de GOP y tiene una duración constante, por ejemplo, 2 s.
Este contenido de múltiples tasas de bits se distribuye a continuación a los servidores 14, 16, 18, junto con un archivo de descripción que enumera las tasas de bits disponibles. Este archivo de descripción es similar al archivo de manifiesto utilizado en típicas implementaciones de transferencia de flujo adaptativa. En esta realización, el archivo de descripción se implementa como un archivo SDP.
La figura 2 representa preparación de contenido: un contenido multimedia 30 es codificado por un codificador 32 a múltiples tasas de bits con la restricción adicional de que todas las tramas de referencia aparecen en el mismo instante en cada flujo codificado. Considerando que la transición de una tasa de bits a otra se puede producir menos frecuentemente que en cada GOP, el alineamiento de las tramas de referencia se puede requerir periódicamente cada decenas de milisegundos (2 segundos en el ejemplo). En la realización, el contenido se codifica utilizando los códecs H.264 y AAC en relación con tramas que aparecen cada 2 segundos y a continuación son encapsuladas en un flujo de transporte MPEG. El contenido de ejemplo utilizado para describir la realización se codifica en el siguiente conjunto de tasas de bits totales: 500 kbps, 1000 kbps, 1500 kbps y 2000 kbps. La descripción del flujo se puede expresar utilizando el protocolo SDP.
En este ejemplo, se transmiten 4 pistas MPEG TS y sus tasas de bits se anuncian utilizando el atributo b=TIAS en el protocolo SDP. Además, el tributo "X-altservers" proporciona al cliente 12 una lista de localizaciones alternativas desde las que se puede recibir el contenido 30. Se podrían utilizar estas localizaciones alternativas en lugar de la localización principal dado que contienen exactamente lo mismo.
El funcionamiento RTSP normal para controlar una sesión de transferencia de flujo se representa en la figura 3. El primer mensaje permite al cliente 12 descubrir las propiedades del flujo. El segundo mensaje denominado CONFIGURAR ("SETUP") prepara la sesión de transferencia de flujo, y finalmente el mensaje REPRODUCIR ("PLAY") hace que servidor 14 comience a enviar el flujo multimedia.
En la invención, el cliente conmuta de un flujo a otro durante la sesión de transferencia de flujo. En esta realización, para mayor claridad, el cliente emite varios mensajes SETUP al inicio de la sesión de transferencia de flujo. Se realiza una configuración para cada pista disponible. Sin embargo, es obvio que el mensaje SETUP para cada pista podría asimismo ser emitido por el cliente inmediatamente antes de que el cliente necesite de hecho recibir dicha pista.
Esta fase de configuración de múltiples pistas se muestra en la figura 4. Como una optimización, el cliente 12 puede asimismo configurar todas las pistas al mismo tiempo emitiendo un mensaje SETUP para el URL de la sesión en lugar de mensajes SETUP independientes para las pistas individuales de la sesión. Para soportar funcionamiento de múltiples servidores, el cliente 12 lleva a cabo esta fase de inicialización para cada servidor enumerado en el atributo X-altservers.
Una vez se han configurado todas las pistas, el cliente 12 solicita pequeñas porciones del contenido multimedia emitiendo solicitudes de REPRODUCIR para el intervalo de tiempo deseado desde la pista deseada, tal como se muestra en la figura 5.
La pista se selecciona utilizando el ID de pista encontrado en el SDP. El intervalo de tiempo se indica al servidor utilizando el Rango: cabecera. Por ejemplo, para seleccionar el intervalo de tiempo de 2 a 4 s, el cliente añadiría la siguiente cabecera a su solicitud de reproducir:
Reproducir rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0 Rango: npt=2-4
Para evitar interrupciones en la emisión entre las porciones de flujo, el cliente emite por adelantado una nueva solicitud RTSP REPRODUCIR para la siguiente porción, con el fin de mantener datos suficientes en la memoria tampón de emisión. En esta realización, la memoria tampón de emisión contiene 2 segundos del flujo multimedia descargados por adelantado.
Para funcionamiento multicamino con múltiples servidores, el cliente 12 solicita diferentes porciones para su transferencia en flujo desde cada servidor 14, 16 y 18 en paralelo a una tasa correspondiente a la estimación del cliente de la capacidad de dicho camino de red, tal como se muestra en la figura 6.
La figura 7 muestra un diagrama esquemático de un controlador 40 adecuado para funcionamiento multicamino y con múltiples servidores del cliente 12. El controlador 40 incluye un medio para la estimación de la tasa de camino 42, que puede realizar control de velocidad del servidor, medición del ancho de banda y estimación del ancho de banda para cada respectivo servidor y camino de datos.
Además, el controlador 40 incluye medios para la planificación de porciones 44 que pueden realizar una selección de tasa de bits para la siguiente porción que tiene que se suministrada por el servidor respectivo. El controlador 40 incluye además medios para la asignación de recipientes 46, que pueden enlazar una porción específica de uno de los servidores a un recipiente asignado desde una lista enlazada, con el fin de conseguir un orden de utilización correcto. El controlador 40 incluye un medio para renumeración RTP y para volver a realizar marcas de tiempo 48. Además, está presente una unidad de utilización 50 que permite visualizar el flujo recibido.
El cliente 12 agrega estos flujos recibidos en un único flujo, de tal modo que éste es idéntico a un flujo que hubiera sido recibido desde un solo servidor, es decir, el número de secuencia y las marcas de tiempo RTP se incrementan de manera monótona. Esta tarea involucra almacenamiento en memoria tampón y renumeración de los paquetes RTP recibidos desde los diferentes servidores. Esto se resuelve mediante la etapa de asignación de recipientes y renumeración RTP mostrada en la figura 7. Finalmente, este flujo agregado se inyecta en la memoria tampón de descodificación del cliente.
La tasa de camino (tasa de bits disponible para un camino) es estimada mediante los medios para la estimación de la tasa de camino 42, independientemente para cada servidor 14, 16 y 18 y el camino de red asociado 20, 22 y 24. Por lo tanto, el proceso descrito a continuación se realiza en paralelo para cada uno de los servidores que se utilizan en la sesión de transferencia de flujo multicamino.
El proceso de estimación del ancho de banda se compone de las etapas siguientes. En primer lugar, se realiza un control de la velocidad del servidor. A continuación, la velocidad de envío del servidor 14, 16 y 18 es gestionada por el cliente 12 para medir la tasa de bits disponible real del camino de red 20, 22 y 24. En segundo lugar, tiene lugar la medición del ancho de banda. Por consiguiente, se determinan las características del flujo recibido por el cliente 12 comparado con la velocidad de envío del servidor 14, 16 y 18 para determinar la tasa de bits de red actual para la porción actual. En tercer lugar, se realiza la estimación del ancho de banda. Las mediciones de ancho de banda individuales se suavizan para producir un valor preciso que se puede utilizar para seleccionar las siguientes porciones.
De este modo, la velocidad de envío del servidor es gestionada por el cliente para medir la tasa de bits disponible real de la red.
La medición del ancho de banda consiste en determinar las características del flujo recibido por un cliente en comparación con la velocidad de envío del servidor para determinar la tasa de bits actual de la red para la porción actual.
La estimación del ancho de banda consiste en suavizar la estimación de ancho de banda individual para producir un valor preciso que se puede utilizar para seleccionar las porciones siguientes.
Todo el proceso de estimación del ancho de banda se repite periódicamente pero no necesariamente para cada porción, en situaciones en las que las condiciones de la red varían lentamente.
Ventajosamente, es posible utilizar a continuación los caminos más lentos para obtener las porciones que tienen que ser representadas "lejos" en el tiempo, y utilizar los caminos más rápidos para obtener las porciones que tienen que ser representadas "en breve".
La velocidad del servidor 14, 16 y 18 se controla añadiendo un atributo ya estándar "velocidad" a la solicitud de REPRODUCIR. La idea tras modificar la velocidad del servidor es determinar si la red mantendría la transmisión a una tasa mayor que la tasa actual.. En la realización de las figuras 6 y 7, el cliente 12 sondea periódicamente la capacidad de la red para transmitir un 20 % más rápido, mediante solicitar al servidor enviar una porción a 1,2 veces la velocidad actual.
Una solicitud RTSP de ejemplo sería:
REPRODUCIR rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0
CSeq: 833
Rango: npt = 2-4
Velocidad: 1,2
El servidor respondería a la solicitud anterior como sigue:
RTSP/1.0200 OK
CSeq: 834
Rango: npt=2-4
RTP
Info: url=rtsp://multimedia.example.com/stream/trackID=1;s eq = 45102; rtptime = 12345678
Un parámetro denominado rtptime indica la marca de tiempo RTP correspondiente al inicio del rango npt seleccionado. Dada una velocidad de reloj determinada, el cliente determina el rango rtptime correspondiente a la porción solicitada. Para calcular la tasa de bits actual Bi, el cliente 12 suma los octetos de paquetes RTP recibidos en el intervalo rtptime anterior. Divide esto por la duración de transmisión de estos octetos (medida entre el primero octeto recibido y el último octeto recibido):
Bi = Octetos-8/duraciónTransmisión
Esta tasa de bits actual es utilizada a continuación por un algoritmo de suavizado para determinar una estimación fiable. El algoritmo utilizado en esta realización es iterativo e intenta deducir la tasa de bits que se puede conseguir, a partir de la tasa de bits medida durante las iteraciones anteriores.
La tasa de bits promedio para la siguiente iteración se calcula como el promedio ponderado del promedio de la tasa de bits actual y la medida actual, tal como se muestra en la fórmula siguiente:
Donde Bi es la tasa de bits medida, avgi es la tasa de bits promedio calculada para la iteración actual y a es la ponderación proporcionada a la medición de tasa de bits actual. En un ejemplo, la ponderación se ha elegido como a=1/16.
Además de la tasa de bits promedio, el algoritmo estima la varianza de la tasa de bits. La varianza se suaviza del mismo modo que la tasa de bits, tal como se muestra a continuación:
Figure imgf000007_0001
Donde Ai es la diferencia entre la tasa de bits medida y la tasa de bits promedio para la iteración actual, vari es la varianza calculada para la estimación actual y p es la ponderación proporcionada a la medición de la varianza actual. En una implementación prototipo, p se ha elegido con el valor de 1/8.
Para cada iteración, la estimación actual (o la tasa de bits que se puede conseguir) se calcula como sigue:
Esto significa que si la varianza es grande, entonces el cliente 12 utiliza mucho menos que el ancho de banda promedio. Por otra parte, cuando el ancho de banda es estable y la varianza es baja, el cliente 12 converge para utilizar el ancho de banda total disponible en el enlace.
Se consideran dos casos excepcionales en los que se restablece la estimación: cuando la varianza es demasiado grande (por ejemplo, mayor que la mitad de la tasa de bits promedio) o cuando existe una discontinuidad en los números de secuencia RTP, lo que significa que se han perdido paquetes RTP.
En los casos anteriores, las estimaciones del promedio y de la varianza se restablecen como sigue:
Figure imgf000007_0002
El evento de una discontinuidad RTP desencadena una nueva estimación de la tasa de bits para el camino/servidor en cuestión y/o una replanificación de todas las porciones anteriormente planificadas.
La planificación de servidores y de porciones es realizada por los medios para planificación de servidores y de porciones 44. Cada vez que el cliente 12 finaliza la recepción de la porción solicitada para un servidor determinado (el servidor queda inactivo), actualiza la estimación del ancho de banda para dicho servidor y utiliza de nuevo la conexión para recuperar otra porción. Dependiendo de la disponibilidad y de las tasas de bits relativas de todos los caminos de servidor, la conexión del servidor puede ser utilizada para recuperar la siguiente porción que tiene que ser emitida o bien una porción puede ser emitida posteriormente, es decir, esto se denomina planificación de porciones. El algoritmo de planificación se describe a continuación.
En primer lugar, los medios para planificación de servidores y de porciones 44 seleccionan la tasa de bits de la siguiente porción. Para ello, los medios para planificación de servidores y de porciones 44 suman las estimaciones de tasa de bits individuales (ver más abajo) de todos los servidores 14, 16 y 18 para obtener la tasa de bits agregada, dado que todos los servidores se utilizan en paralelo. La tasa de emisión de porciones seleccionada es la tasa de bits de codificación inmediatamente inferior a la tasa de bits agregada.
En el tiempo te cuando la memoria tampón del descodificador está vacía, se calcula primero el tiempo de llegada de la porción para cada servidor 14, 16 y 18 utilizando los parámetros actuales de emisión y de transferencia de flujo: ak es el tiempo en que el camino k queda inactivo (se finaliza la recepción de la porción última o planificada), d la duración de la porción, B la tasa de bits de emisión y Bk la estimación de la tasa de bits actual para el servidor/camino k. El tiempo que se tardaría en descargar la siguiente porción desde el servidor k se denomina Dk, con Dk = d • B / Bk. El tiempo de llegada de la porción si se utiliza el servidor k pasa a ser: Rk = ak + Dk.
El algoritmo selecciona el servidor que proporciona la Rk mínima. Además, el tiempo de llegada de la porción debe ser anterior al tiempo en que la memoria tampón del descodificador esté vacía (te), es decir, se tiene que cumplir Rk < te. Si no, la memoria tampón funcionará en vacío y se producirá una interrupción visible en la emisión. En tal caso, las tasas de bits de emisión se reducirán hasta la siguiente tasa de bits menor. Si se cumple la condición del tiempo de llegada, se planifica la recuperación de porciones en el servidor k. La tasa de transmisión se tiene que ajustar para corresponderse con la estimación actual de la tasa de bits para servidor/camino k. Esto se realiza utilizando la Velocidad:cabecera de la solicitud RTSP REPRODUCIR con velocidad = Bk / B.
Por ejemplo, suponiendo que la tasa de emisión B es 1 Mbps (se está reproduciendo trackID 1), la estimación de tasa de bits actual es de 400 kbps, se tendría una velocidad = 0,4. Como comentario adicional, si el proceso de estimación del ancho de banda periódico se ha desencadenado para la porción actual, se multiplicaría la velocidad resultante por 1,2.
Sigue la correspondiente solicitud que se enviaría al servidor k (suponiendo que no se realiza estimación de ancho de banda para porción actual):
REPRODUCIR rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0
CSeq: 838
Rango: npt=40-42
Velocidad: 0,4
Si el servidor está actualmente inactivo, entonces la siguiente solicitud RTSP se emite inmediatamente. De lo contrario, si se sigue utilizando el servidor, entonces la solicitud RTSP se retardará hasta que el servidor quede inactivo.
Finalmente, se añade una nueva porción en la memoria tampón, y por lo tanto el valor te se incrementa en la duración de la porción (d) : te = te d. Si alguno de los servidores está inactivo, las etapas anteriores se realizan hasta que todos los servidores 14, 16 y 18 están ocupados. De lo contrario, los medios para planificación de servidores y de porciones 44 esperan a que vuelva a quedar inactivo un servidor.
La asignación de recipientes se realiza por medio de la asignación de recipientes 46. Cada vez que se envía una solicitud hacia un servidor 14, 16 y 18 para una determinada porción, la respuesta se enlaza a un recipiente asignado desde la lista enlazada que garantiza el orden de utilización correcto. Es decir, la cabecera de la lista es el recipiente que contiene los siguientes paquetes que se tiene que proporcionan al descodificador. La cola de la lista es el recipiente que contiene el último paquete que se tiene que descodificar.
La renumeración RTP y la nueva marca de tiempo se realizan por medio de la renumeración RTP y nueva marca de tiempo 48. Es necesario normalizar el flujo RTP final suministrado al descodificador/desmultiplexor de video. Para cada solicitud enviada a un determinado servidor 14, 16 y 18, ha sido asignado un recipiente de recepción con el orden de utilización correcto. Una vez que se han recibido todos los paquetes RTP correspondientes a dicha solicitud, se actualizan las marcas de tiempo RTP y los números de secuencia, de tal modo que el descodificador no puede distinguir un flujo recibido desde múltiples servidores de un flujo recibido de un único servidor.
En la práctica, el número de secuencia y el tiempo RTP de todos los paquetes son renumerados comenzando con el último número de secuencia y la última marca de tiempo RTP utilizados para alimentar la memoria tampón de descodificación.
Por consiguiente, la invención permite transferencia de flujo adaptativa multicamino aplicada al conjunto de protocolos RTSP/RTP. Una utilización inteligente del parámetro velocidad en el protocolo RTSP permite la utilización paralela de múltiples servidores así como el sondeo del estado de la red. La utilización paralela de múltiples servidores RTSP por el cliente permite racionar rápidamente a condiciones cambiantes de la red y maximizar la experiencia del usuario. La invención aplica al RTSP/RTP existente que se utiliza en la infraestructura IPTV.
En otras palabras, el sistema correspondiente a la realización preferida de la invención es un sistema para transmitir un contenido audiovisual utilizando una técnica de transferencia de flujo adaptativa multicamino en un entorno de red que comprende la serie de servidores 14, 16, 18; estando cada uno de los servidores configurado para la transmisión del contenido multimedia en base a un protocolo de comunicación compatible con RTP/RTSP a través de los respectivos caminos de datos 20, 22, 24 al cliente 12, donde el cliente 12 incluye un controlador 40 que puede sondear cada uno de dichos caminos de datos 20, 22 y 24 para determinar un respectivo ancho de banda asociado a cada uno de los caminos de datos 20, 22 y 24 y para solicitar una porción de dicho contenido multimedia desde cada uno de los servidores 14, 16 y 18 de acuerdo con el respectivo ancho de banda determinado.
El controlador 40 incluye medios para la estimación 42 de la tasa de bits disponible para cada uno de los caminos de datos 20, 22 y 24 entre cada uno de los respectivos servidores 14, 16, 18 y el cliente 12, y está configurado para realizar un control de velocidad de servidores, en los servidores 14, 16 y 18.
El controlador 40 incluye asimismo medios para la selección de porciones 44 de acuerdo con la tasa de bits disponible, para seleccionar la siguiente porción a suministrar mediante el respectivo servidor 14, 16, 18.
El controlador 40 incluye además medios para la asignación de recipientes 46, configurados para enlazar una porción específica de uno de los servidores 14, 16, 18 con un recipiente asignado desde una lista enlazada, con el fin de conseguir un orden de utilización correcto en el lado del cliente (receptor).
Para proceder a la construcción de (formar) un único flujo coherente, el controlador 40 incluye medios para una renumeración RTP y una nueva marca de tiempo 48 para actualizar marcas de tiempo RTP y números de secuencia. Esto permite formar un único flujo coherente en el lado del cliente, tal como si se hubiera recibido, por ejemplo, desde un único servidor.
El procedimiento utilizado de acuerdo con la realización preferida de la invención es, por lo tanto, un procedimiento para transferencia de flujo adaptativa en un entorno multicamino, que comprende:
- disponer un cliente; y
- disponer una serie de servidores 14, 16, 18 que están configurados respectivamente para transmitir al cliente contenido multimedia en un entorno RTP/RTSP a través de un respectivo camino de datos 20, 22, 24, en el que el cliente 12 incluye un controlador 40 para sondear cada uno de los caminos de datos 20, 22, 24, con el fin de determinar un respectivo ancho de banda asociado a cada uno de dichos caminos de datos 20, 22 y 24, y para solicitar una porción del contenido multimedia de cualquiera de los servidores 14, 16, 18, de acuerdo con el respectivo ancho de banda determinado.
El controlador incluye medios para la estimación de la tasa de bits de un camino 42 con el fin de llevar a cabo un control de velocidad de los servidores, en los servidores 14, 16, 18, la medición de ancho de banda y la estimación de ancho de banda en paralelo para cada uno de los servidores 14, 16, 18 que se utilizan en la sesión de transferencia de flujo multicamino.
De acuerdo con una realización preferida, la estimación de la tasa de bits de un camino se repite periódicamente. La estimación de la tasa de bits de un camino 42 comprende una etapa de control de la velocidad del correspondiente servidor 14, 16, 18, mediante añadir un atributo estándar RTS de velocidad a una solicitud de reproducir.
Para cada servidor 14, 16, 18, la tasa actual es utilizada a continuación por un algoritmo de suavizado para determinar iterativamente una estimación con el fin de deducir la tasa de bits que se puede conseguir, a partir de la tasa de bits medida durante las situaciones anteriores.
Para cada servidor 14, 16, 18, se calcula una varianza para la tasa actual.
Los medios de controlador 40 incluyen medios para la planificación de porciones 44 (o selección de porciones) con el fin de realizar una selección de tasa de bits para la siguiente porción que tiene que ser suministrada por el respectivo servidor 14, 16, 18.
Se suman las estimaciones de tasa de bits individuales para todos los servidores 14, 16, 18 con el fin de obtener la tasa de bits agregada, y se selecciona una tasa de emisión de una porción, a la tasa de bits de codificación inmediatamente inferior a la tasa de bits agregada.
Los elementos clave de la invención son protocolo RTSP estándar (frente a transferencia de flujo HTTP) y por lo tanto reutilización del ecosistema existente, señalización de las múltiples versiones del contenido con DSP estándar, con un nuevo atributo para indicar la disponibilidad del contenido en múltiples servidores, funcionamiento simultáneo de múltiples servidores/múltiples caminos de red por medio de señalización RTSP continua, evaluación del ancho de banda disponible en los caminos de red individuales en base al protocolo RTSP, y compensación continua de la tasa de datos en múltiples caminos en base a un esquema de suministro con anticipación.
El alcance de la invención se define mediante el alcance de las siguientes reivindicaciones.
Todos los ejemplos y el vocabulario condicional que se exponen en la presente memoria están previstos con propósitos pedagógicos para ayudar a la lectura en la compresión de los principios de la invención y los conceptos aportados por el inventor para hacer avanzar la técnica, y se deben considerar sin limitarse a dichos ejemplos y condiciones expuestos explícitamente.
Además, todas las afirmaciones de la presente memoria que enuncian principios, aspectos y realizaciones de los presentes principios, así como ejemplos específicos de las mismas, están destinadas a abarcar los equivalentes tanto estructurales como funcionales de las mismas. Adicionalmente, se prevé que dichos equivalentes incluyen tanto equivalentes conocidos actualmente como equivalentes desarrollados en el futuro, es decir, cualesquiera elementos desarrollados que desempeñan la misma función, independientemente de la estructura.
De este modo, por ejemplo, los expertos en la materia apreciarán que los diagramas de bloques presentados en la presente memoria representan visiones conceptuales de circuitos ilustrativos que realizan los presentes principios. Análogamente, se apreciará que cualesquiera gráficos de flujo, diagramas de flujo, diagramas de transición de estado, pseudocódigo y similares, representan varios procesos que se pueden representar sustancialmente en medios legibles por ordenador y, por lo tanto, ejecutar por un ordenador o procesador, se muestre o no explícitamente dicho ordenador o procesador.
Las funciones de los diversos elementos mostrados en las figuras se pueden proporcionar mediante la utilización de hardware dedicado, así como de hardware que puede ejecutar software, en asociación con el software apropiado.
Cuando son proporcionadas por un procesador, las funciones pueden ser proporcionadas por un único procesador dedicado, por un único procesador compartido o por una serie de procesadores individuales, algunos de los cuales pueden ser compartidos. Además, no se deberá interpretar que la utilización explícita de la expresión "descodificador", "controlador", "planificador", "estimador" o sus respectivos medios equivalentes que realizan funciones correspondientes, se refiere exclusivamente a hardware que pueda ejecutar software, y puede incluir explícitamente, de forma no limitativa, hardware de procesador de señal digital ("DSP", digital signal processor), memoria de sólo lectura ("ROM", read only memory) para almacenar software, memoria de acceso aleatorio ("RAM", random access memory) y almacenamiento no volátil.
Puede estar incluido asimismo otro hardware, convencional y/o personalizado. Análogamente, cualquier conmutación expuesta en la memoria descriptiva se puede llevar a cabo por medio del funcionamiento de lógica de programa, por medio de lógica dedicada, por medio de la interacción de control de programa y lógica dedicada, siendo la técnica particular seleccionable por el implementador, tal como se comprende más específicamente a partir del contexto.
En las reivindicaciones adjuntas, se prevé que cualquier elemento expresado como un medio para llevar a cabo una función específica abarque cualquier modo de realizar dicha función incluyendo, por ejemplo, a) una combinación de elementos de circuito que lleva a cabo dicha función o b) software en cualquier forma incluyendo, por lo tanto, software inalterable, microcódigo o similares, combinado con circuitos apropiados para la ejecución de software con el fin de realizar la invención. Los presentes principios, tal como se define mediante dichas reivindicaciones, residen en el hecho de que las funcionalidades proporcionadas por los diversos medios enumerados se combinan e integran de la manera que requieren las reivindicaciones. Se considera por lo tanto que cualesquiera medios que puedan proporcionar dichas funcionalidades son equivalentes a los mostrados en la presente memoria.
La referencia en la memoria descriptiva a "una realización" de los presentes principios, así como otras variaciones de la misma, significa que un aspecto, estructura, característica y similar, particular, descrito en relación con la invención, está incluido en, por lo menos, una realización de los presentes principios. Por lo tanto, las apariciones de la expresión "en una realización", así como otras variaciones, que aparecen en diversos lugares a lo largo de toda la memoria descriptiva, no todas se refieren necesariamente a la misma realización.
Se debe entender que los presentes principios se pueden implementar en varias formas de hardware, software, software inalterable, procesadores de propósito especial o una combinación de los mismos. Preferentemente, los presentes principios se pueden implementar como una combinación de hardware y software. Además, el software se implementa preferentemente como un programa de aplicación realizado de manera tangible en un dispositivo de almacenamiento de programas. El programa de aplicación puede ser cargado en una máquina que comprende cualquier estructura adecuada, y ejecutado por la misma. Preferentemente, la máquina se implementa en una plataforma informática que tiene hardware, tal como una o varias unidades centrales de proceso (CPU, central processing unit), una memoria de acceso aleatorio (RAM) y una o varias interfaces de entrada/salida (I/O). La plataforma informática incluye asimismo un sistema operativo y código de microinstrucciones. Los diversos procesos y funciones descritos en la presente memoria pueden ser parte del código de microinstrucciones o parte del programa de aplicación (o una combinación de los mismos) que se ejecuta por medio del sistema operativo. Además, algunos otros dispositivos periféricos se pueden conectar a la plataforma informática, tales como un dispositivo adicional de almacenamiento de datos y un dispositivo de impresión.
Se debe comprender además que, debido a que algunos de los componentes constituyentes del sistema y etapas de procedimiento representadas en las figuras adjuntas se implementan preferentemente en software, las conexiones reales entre los componentes de sistema (o las etapas de proceso) pueden diferir en función del modo en el que se programan los presentes principios. Dadas las explicaciones de la presente memoria, un experto en la técnica relacionada puede ser capaz de contemplar estas implementaciones o configuraciones de los presentes principios, y otras similares.

Claims (17)

REIVINDICACIONES
1. Un cliente para obtener un contenido audiovisual por medio de una técnica de transferencia de flujo adaptativa multicamino en un entorno de red que comprende una serie de servidores (14, 16, 18), estando adaptado cada uno de dichos servidores para la transmisión de dicho contenido multimedia en base a un protocolo de comunicación compatible con RTP/RTSP a través de respectivos caminos de datos (20, 22, 24) a dicho cliente (12), en el que el cliente (12) incluye un controlador (40) que sondea cada uno de dichos caminos de datos (20, 22, 24) para determinar un respectivo ancho de banda asociado con cada uno de dichos caminos de datos (20, 22, 24) y solicita diferentes porciones de dicho contenido multimedia desde cada uno de dichos servidores (14, 16, 18) de acuerdo con el respectivo ancho de banda determinado y con un tiempo de reproducción de dichas porciones solicitadas.
2. El cliente según la reivindicación 1, caracterizado por que el controlador (40) incluye medios para la estimación (42) de la tasa de bits disponible para cada uno de dichos caminos de datos (20, 22, 24) entre cada uno de dichos servidores respectivos (14, 16, 18) y dicho cliente (12), y está configurado para llevar a cabo un control de velocidad de envío de los servidores (14, 16, 18).
3. El cliente según la reivindicación 1 o 2, caracterizado por que el controlador (40) incluye medios para planificación de porciones (44) que pueden llevar a cabo una selección de tasa de bits para la siguiente porción que tiene que ser suministrada por el servidor respectivo (14, 16, 18).
4. El cliente según cualquiera de las reivindicaciones 1 a 3, caracterizado por que el controlador (40) incluye medios para la asignación de recipientes (46), que pueden enlazar una porción específica de uno de los servidores (14, 16, 18) a un recipiente asignado desde una lista enlazada, con el fin de conseguir un orden de utilización correcto.
5. El cliente según cualquiera de las reivindicaciones 1 a 4, caracterizado por que el controlador (40) incluye medios para una renumeración RTP y una nueva marca de tiempo (48) que pueden actualizar marcas de tiempo RTP y números de secuencia para formar un único flujo coherente.
6. Un procedimiento para transferencia de flujo adaptativa en un entorno multicamino, comprendiendo dicho entorno multicamino
un cliente y una serie de servidores (14, 16, 18) que pueden respectivamente transmitir al cliente contenido multimedia en un entorno RTP/RTSP a través de un respectivo camino de datos (20, 22, 24), en el que el cliente (12) incluye un controlador (40) que sondea cada uno de dichos caminos de datos (20, 22, 24) para determinar un respectivo ancho de banda asociado con cada uno de dichos caminos de datos (20, 22, 24) y solicita diferentes porciones de dicho contenido multimedia desde cada uno de dichos servidores (14, 16, 18), en el que el controlador selecciona cada una de las porciones solicitadas, de acuerdo con el ancho de banda respectivo y el tiempo de representación de dichas porciones solicitadas.
7. El procedimiento según la reivindicación 6, caracterizado por que el controlador incluye medios para la estimación de la tasa de camino (42) para controlar de velocidad de envío de los servidores (14, 16, 18), medir el ancho de banda y estimar el ancho de banda en paralelo para cada uno de los servidores (14, 16, 18) que están siendo utilizados en la sesión de transferencia de flujo multicamino.
8. El procedimiento según la reivindicación 7, caracterizado por que la estimación de la tasa de camino se repite periódicamente.
9. El procedimiento según la reivindicación 7 u 8, caracterizado por que la estimación de la tasa de bits de un camino (42) controla la velocidad de envío del correspondiente servidor (14, 16, 18) añadiendo un parámetro de velocidad de envío a una solicitud de reproducir, siendo dicho parámetro de velocidad de envío utilizado por el servidor correspondiente.
10. El procedimiento según la reivindicación 9, caracterizado por que para cada servidor (14, 16, 18), la tasa actual es utilizada a continuación por un algoritmo de suavizado para determinar iterativamente una estimación con el fin de deducir la tasa de bits que se puede conseguir, a partir de la tasa de bits medida durante las iteraciones anteriores.
11. El procedimiento según la reivindicación 9, caracterizado por que para cada servidor (14, 16, 18) se calcula una varianza para la tasa actual.
12. El procedimiento según cualquiera de las reivindicaciones 6 a 11, caracterizado por que el controlador (40) incluye medios para planificación de porciones (44) que pueden llevar a cabo una selección de tasa de bits para la siguiente porción que tiene que ser suministrada por el servidor respectivo (14, 16, 18).
13. El procedimiento según la reivindicación 12, caracterizado por que se suman las estimaciones de tasa de bits individuales para todos los servidores (14, 16, 18) con el fin de obtener la tasa de bits agregada, y se selecciona una tasa de emisión de una porción como la tasa de bits de codificación inmediatamente inferior a la tasa de bits agregada.
14. El procedimiento según cualquiera de las reivindicaciones 6 a 11, caracterizado por que el controlador (40) incluye medios para la asignación de recipientes (46), que pueden enlazar una porción específica de uno de los servidores (14, 16, 18) con un recipiente asignado desde una lista enlazada, con el fin de conseguir un orden de utilización correcto.
15. El procedimiento según cualquiera de las reivindicaciones 6 a 9, caracterizado por que el controlador (40) incluye medios para una renumeración RTP y una nueva marca de tiempo (48) que pueden actualizar marcas de tiempo RTP y números de secuencia para formar un único flujo coherente.
16. El procedimiento según cualquiera de las reivindicaciones 6 a 7, caracterizado por que el cliente utiliza los caminos más lentos para obtener las porciones que tienen que ser representadas más lejos en el tiempo y utiliza los caminos más rápidos para obtener las porciones que tienen que ser representadas en breve.
17. El cliente según cualquiera de las reivindicaciones 1 a 2, caracterizado por que el cliente utiliza los caminos más lentos para obtener las porciones que tienen que ser representadas más lejos en el tiempo y utiliza los caminos más rápidos para obtener las porciones que tienen que ser representadas en breve.
ES12196438T 2011-12-22 2012-12-11 Sistema y procedimiento para transferencia de flujo adaptativa en un entorno multicamino Active ES2704625T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP11306744.1A EP2608558A1 (en) 2011-12-22 2011-12-22 System and method for adaptive streaming in a multipath environment

Publications (1)

Publication Number Publication Date
ES2704625T3 true ES2704625T3 (es) 2019-03-19

Family

ID=47290841

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12196438T Active ES2704625T3 (es) 2011-12-22 2012-12-11 Sistema y procedimiento para transferencia de flujo adaptativa en un entorno multicamino

Country Status (13)

Country Link
US (1) US9374409B2 (es)
EP (2) EP2608558A1 (es)
JP (1) JP6308718B2 (es)
KR (1) KR102048898B1 (es)
CN (1) CN103179107B (es)
CA (1) CA2797895C (es)
ES (1) ES2704625T3 (es)
MX (1) MX349401B (es)
MY (1) MY161489A (es)
PL (1) PL2608559T3 (es)
RU (1) RU2627303C2 (es)
TR (1) TR201820876T4 (es)
TW (1) TWI561071B (es)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
IL210169A0 (en) * 2010-12-22 2011-03-31 Yehuda Binder System and method for routing-based internet security
US9571827B2 (en) * 2012-06-08 2017-02-14 Apple Inc. Techniques for adaptive video streaming
US9654533B2 (en) * 2013-01-17 2017-05-16 Electronics And Telecommunications Research Institute Method of adaptively delivering media based on reception status information from media client and apparatus using the same
US9485289B2 (en) * 2013-08-28 2016-11-01 Cisco Technology, Inc. HTTP streaming client adaptation algorithm based on proportional-integral control
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US9401944B2 (en) 2013-10-22 2016-07-26 Qualcomm Incorporated Layered adaptive HTTP streaming
JP6305738B2 (ja) * 2013-11-27 2018-04-04 エヌ・ティ・ティ・コミュニケーションズ株式会社 メディア再生制御装置、メディア再生制御方法、及びプログラム
CN104735115A (zh) * 2013-12-24 2015-06-24 乐视网信息技术（北京）股份有限公司 一种p2p下载方法及装置
US9887914B2 (en) * 2014-02-04 2018-02-06 Fastly, Inc. Communication path selection for content delivery
US9680685B2 (en) * 2014-05-08 2017-06-13 Spb Tv Ag System and method for managing video content feeds
US10045367B2 (en) 2014-10-03 2018-08-07 Qualcomm Incorporated Uplink data fragmentation for multi-user networks
JP6342839B2 (ja) * 2015-04-20 2018-06-13 西日本電信電話株式会社 受信端末及び映像視聴システム
US11057446B2 (en) * 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
US10003357B2 (en) * 2015-08-28 2018-06-19 Qualcomm Incorporated Systems and methods for verification of code resiliency for data storage
CN105430533B (zh) * 2015-12-31 2018-09-11 武汉鸿瑞达信息技术有限公司 Hls视频点播加速方法及系统
US20180205802A1 (en) * 2017-01-13 2018-07-19 Cisco Technology, Inc. Cache Aware Streaming
US11190374B2 (en) 2017-08-28 2021-11-30 Bright Data Ltd. System and method for improving content fetching by selecting tunnel devices
EP4187881A1 (en) 2017-08-28 2023-05-31 Bright Data Ltd. Improving content fetching by selecting tunnel devices grouped according to geographic location
US11622020B2 (en) 2017-08-31 2023-04-04 Micro Focus Llc Push control
JP6471252B1 (ja) * 2018-03-20 2019-02-13 株式会社Ｊストリーム 再生装置及びプログラム
WO2020055333A1 (en) * 2018-09-14 2020-03-19 National University Of Singapore Method and device for streaming content
KR102195516B1 (ko) * 2018-11-01 2020-12-29 카테노이드 주식회사 방송 서비스 제공 장치, 방송 서비스 수신 장치 및 이를 이용한 방송 서비스 송수신 시스템
JP7222748B2 (ja) * 2019-02-13 2023-02-15 日本放送協会 受信装置及び配信サーバ
LT3780557T (lt) 2019-02-25 2023-03-10 Bright Data Ltd. Turinio parsisiuntimo, naudojant url bandymų mechanizmą, sistema ir būdas
EP3935792A4 (en) 2019-04-02 2022-11-30 Bright Data Ltd. SYSTEM AND METHOD FOR MANAGING A NON-DIRECT URL RETRACTION SERVICE
US11343551B1 (en) * 2019-07-23 2022-05-24 Amazon Technologies, Inc. Bandwidth estimation for video streams
EP3902275A1 (en) * 2020-04-21 2021-10-27 THEO Technologies A method for estimating bandwidth between a video server and a video client
CN117151440B (zh) * 2023-10-31 2024-02-09 合肥综合性国家科学中心人工智能研究院(安徽省人工智能实验室) 一种机器组策略选择的仓储分配方法及系统

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6405256B1 (en) 1999-03-31 2002-06-11 Lucent Technologies Inc. Data streaming using caching servers with expandable buffers and adjustable rate of data transmission to absorb network congestion
EP1181648A1 (en) * 1999-04-09 2002-02-27 Clearspeed Technology Limited Parallel data processing apparatus
JP2002176609A (ja) * 2000-08-25 2002-06-21 Matsushita Electric Ind Co Ltd データ受信再生方法及びデータ受信再生装置
WO2002025878A1 (fr) * 2000-09-22 2002-03-28 Matsushita Electric Industrial Co., Ltd. Procede de transmission/reception de donnees, dispositif de transmission, dispositif de reception, systeme de transmission/reception et programme
FI118830B (fi) * 2001-02-08 2008-03-31 Nokia Corp Tietovirran toisto
WO2002073441A1 (en) 2001-03-12 2002-09-19 Edgestream, Inc. Splitting and redundant storage on multiple servers
US8077679B2 (en) * 2001-03-28 2011-12-13 Qualcomm Incorporated Method and apparatus for providing protocol options in a wireless communication system
US6862028B2 (en) * 2002-02-14 2005-03-01 Intel Corporation Bin pointer and state caching apparatus and method
US7231442B2 (en) * 2002-04-03 2007-06-12 Tonic Software, Inc. Global network monitoring system
DE60208474T2 (de) * 2002-08-27 2006-07-13 Matsushita Electric Industrial Co., Ltd., Kadoma Verfahren zur Übertragung von Datenströmen abhängig vom überwachten Zustand des Anwendungsspeichers des Nutzers
US7483532B2 (en) * 2003-07-03 2009-01-27 Microsoft Corporation RTP payload format
US7342968B2 (en) * 2003-08-13 2008-03-11 Skystream Networks Inc. Method and system for modeling the relationship of the bit rate of a transport stream and the bit rate of an elementary stream carried therein
US20060215596A1 (en) 2005-03-23 2006-09-28 Intel Corporation Network aware cross-layer protocol methods and apparatus
JP4706908B2 (ja) * 2005-06-30 2011-06-22 ソニー株式会社 同時再生システム、情報処理装置、途中参加方法及び途中参加プログラム
US9124357B2 (en) * 2006-04-20 2015-09-01 Qualcomm Incorporated Media access control for ultra-wide band communication
US7899137B2 (en) 2006-10-12 2011-03-01 Mediatek Inc. Mobile communication system with integrated GPS receiver
US20080163056A1 (en) * 2006-12-28 2008-07-03 Thibaut Lamadon Method and apparatus for providing a graphical representation of content
JP4809256B2 (ja) * 2007-01-31 2011-11-09 ヒューレット−パッカード デベロップメント カンパニー エル．ピー． データストリーミング方法
US20080189429A1 (en) * 2007-02-02 2008-08-07 Sony Corporation Apparatus and method for peer-to-peer streaming
US8194657B2 (en) * 2007-05-22 2012-06-05 Actiontec Electronics, Inc. Systems and methods for dynamic quality of service
US20080291916A1 (en) * 2007-05-22 2008-11-27 Bo Xiong Systems and methods for dynamic quality of service
US20100268761A1 (en) * 2007-06-05 2010-10-21 Steve Masson Methods and systems for delivery of media over a network
US8346959B2 (en) * 2007-09-28 2013-01-01 Sharp Laboratories Of America, Inc. Client-controlled adaptive streaming
CN101198016A (zh) * 2007-12-05 2008-06-11 中兴通讯股份有限公司 交互式个人电视媒体交付系统的内容发布和存储方法
KR101003103B1 (ko) * 2008-04-11 2010-12-21 한국전자통신연구원 네트워크에서 파일을 분배하는 방법
US9003050B2 (en) 2008-04-11 2015-04-07 Mobitv, Inc. Distributed and scalable content streaming architecture
US20100153578A1 (en) * 2008-07-16 2010-06-17 Nokia Corporation Method and Apparatus for Peer to Peer Streaming
US20100094972A1 (en) * 2008-10-15 2010-04-15 Patentvc Ltd. Hybrid distributed streaming system comprising high-bandwidth servers and peer-to-peer devices
US8825894B2 (en) 2008-10-15 2014-09-02 Aster Risk Management Llc Receiving streaming content from servers located around the globe
JP4934660B2 (ja) * 2008-11-28 2012-05-16 日本電信電話株式会社 通信帯域算出方法、装置、およびトラヒック管理方法
WO2010111261A1 (en) 2009-03-23 2010-09-30 Azuki Systems, Inc. Method and system for efficient streaming video dynamic rate adaptation
WO2010138972A2 (en) * 2009-05-29 2010-12-02 Abacast, Inc. Selective access of multi-rate data from a server and/or peer
CN102006217A (zh) * 2009-08-28 2011-04-06 青岛海信传媒网络技术有限公司 内容分发带宽控制方法
EP2491715B1 (en) * 2009-10-21 2018-03-07 Telefonaktiebolaget LM Ericsson (publ) Method and system for media play position control
US10003851B2 (en) * 2009-11-24 2018-06-19 Imagine Communications Corp. Managed multiplexing of video in an adaptive bit rate environment
EP2362651A1 (en) * 2010-02-19 2011-08-31 Thomson Licensing Multipath delivery for adaptive streaming
JP2013521743A (ja) * 2010-03-05 2013-06-10 トムソン ライセンシング 適応型ストリーミングシステムにおけるビットレート調整
US8335172B2 (en) * 2010-06-10 2012-12-18 Cisco Technology, Inc. Switchable conference multicast streaming with dynamic asymmetry
US8935508B1 (en) * 2010-08-30 2015-01-13 Qualcomm Incorporated Implementing pseudo content access memory
US8589583B2 (en) * 2010-09-08 2013-11-19 Hulu, Inc. Method and apparatus for adaptive bit rate switching
CN102088620B (zh) * 2010-12-01 2014-06-18 中兴通讯股份有限公司南京分公司 一种内容分发网络中媒体文件下载方法及客户端
CN102123303B (zh) * 2011-03-25 2012-10-24 天脉聚源(北京)传媒科技有限公司 一种音视频文件播放方法、系统及传输控制装置

Also Published As

Publication number Publication date
PL2608559T3 (pl) 2019-03-29
JP6308718B2 (ja) 2018-04-11
MY161489A (en) 2017-04-14
MX2012015001A (es) 2015-06-01
EP2608559B1 (en) 2018-11-21
US20130166768A1 (en) 2013-06-27
RU2012152900A (ru) 2014-06-20
TR201820876T4 (tr) 2019-01-21
KR102048898B1 (ko) 2020-01-08
CN103179107B (zh) 2019-06-28
KR20130079212A (ko) 2013-07-10
TWI561071B (en) 2016-12-01
RU2627303C2 (ru) 2017-08-07
JP2013135471A (ja) 2013-07-08
TW201332342A (zh) 2013-08-01
EP2608559A1 (en) 2013-06-26
EP2608558A1 (en) 2013-06-26
CN103179107A (zh) 2013-06-26
CA2797895C (en) 2020-01-14
CA2797895A1 (en) 2013-06-22
MX349401B (es) 2017-07-27
US9374409B2 (en) 2016-06-21

Similar Documents

Publication Publication Date Title
ES2704625T3 (es) Sistema y procedimiento para transferencia de flujo adaptativa en un entorno multicamino
US11038944B2 (en) Client/server signaling commands for dash
Jarnikov et al. Client intelligence for adaptive streaming solutions
CN108600789B (zh) 用于多媒体自适应流传输的装置和机器可读存储介质
JP6337350B2 (ja) ビデオ品質向上
CN104604263B (zh) 用于dash格式化的内容流送期间的无缝单播－广播切换的方法
TWI580237B (zh) 單一播放適應性位元率串流
TWI574531B (zh) 於相同視訊傳送管線內之客戶前提元件中將多重播放適應性位元率及單一播放適應性位元率與累進下載適應性位元率合併之技術
KR20170101193A (ko) 미디어 콘텐츠 스트리밍
CN108494454A (zh) 链路感知流传输自适应
US20150326868A1 (en) System and method for managing video content feeds
JP2014090419A (ja) 通信パラメータに従ってコンテンツをダウンロードするための方法、および、関連するコンテンツ受信機