MX2012015001A - Sistema y metodo para adaptar la transmision discontinua en un entorno de multiples rutas de transmision. - Google Patents

Abstract

La invención se refiere a un sistema para la transmisión discontinua adaptable en un entorno de múltiples rutas que comprende una multitud de servidores (14, 16, 18) que son respectivamente capaces de transmitir contenido multi-media en un entorno RTP/RTSP a través de una respectiva ruta de datos (20, 22, 24) a un cliente (12), en donde el cliente (12) incluye un medio controlador (40) capaz de verificar cada una de estas rutas de datos (20, 22 y 24) con el fin de determinar una respectiva anchura de banda asociada a cada una de estas rutas de datos (20, 22 y 24) y solicitar un cúmulo de este contenido multimedia para cada uno de los servidores (14, 16, 18) de acuerdo a una respectiva anchura de banda. Adicionalmente la invención se refiere a un método para la transmisión discontinua adaptable en un entorno de múltiples rutas.

Description

SISTEMA Y METODO PARA ADAPTAR LA TRANSMISION DISCONTINUA EN UN ENTORNO DE MULTIPLES RUTAS DE TRANSMISION CAMPO DE LA INVENCION La invención se refiere a un sistema para adaptar la transmisión discontinua en un entorno de múltiples rutas de transmisión. Más en particular, este sistema se refiere a un sistema para adaptar la transmisión discontinua en un entorno de múltiples rutas de transmisión en el cual no se garantizan las condiciones de anchura de banda de la red y por lo tanto fluctuantes para mejorar el transmisión discontinua de audio/video. Además la invención se refiere a un método para adaptar la transmisión discontinua en un entorno de múltiples rutas de transmisión.

ANTECEDENTES DE LA INVENCION El transmisión discontinua es el proceso en que el contenido consumido por un cliente se envía en cúmulos pequeños al cliente en oposición a descargar, en donde todo el archivo multimedia se transfiere al cliente antes de que juegue/reproduzca. Los protocolos de transmisión discontinua existentes incluyen un Protocolo de Transporte en Tiempo Real (RTP por sus siglas en inglés) o un protocolo de transmisión de transporte MPEG con datagrama de usuario (MPEG TS/UDP por sus siglas en inglés). Por otra parte, la descarga usualmente se lleva a cabo utilizando un protocolo de transferencia de hipertexto (HTTP protocol según se conoce en inglés).

En los sistemas de entretenimiento y comunicaciones se proporciona el protocolo RTSP (Transmisión discontinua de Transporte en Tiempo Real) como un protocolo de control de red para controlar servidores de medios de transmisión discontinua. La transmisión de los datos de transmisión discontinua mediante los servidores RTSP se efectúa por vía del Protocolo de Transporte en Tiempo Real (RTP). RTSP define secuencias de control útiles en controlar la reproducción de datos de la transmisión discontinua. Las secuencias de control se definen en la norma RFC 2326 de la Internet Engineering Task Forcé (IETF).

La sesión de transmisión discontinua es iniciada por el cliente hacia el servidor de transmisión discontinua. El servidor de transmisión discontinua entrega el vidrio solicitado por un enlace unicast hacia el cliente. El establecimiento de la sesión de flujo de la transmisión discontinua involucra varios mensajes RTSP entre el cliente y el servidor de transmisión discontinua, que típicamente involucran selección del contenido e indicación de las características del cliente, tales como tamaño de pantalla, promedio de bits o tamaño máximo de la memoria temporal. La sesión de transmisión discontinua unicast RTP se establece finalmente utilizando parámetros previamente inegociados. Los parámetros de la sesión de transmisión discontinua generalmente permanecen invariables hasta que el cliente selecciona contenido adicional o termina la sesión de transmisión discontinua. Obviamente este tipo de entorno no se adapta bien a características de red variables. Para evitar problemas, algunos operadores simplemente eligen restringir el acceso a determinados servicios a los clientes que tienen suficiente anchura de banda adicional por encima de la anchura de banda realmente requerida.

La transmisión discontinua en tiempo real se ha vuelto más popular para transmitir canales de televisión por vía del Internet (IPTV según sus siglas en inglés). Sin embargo, es necesario proporcionar medios para hacer frente a las proporciones de variación de anchura de banda entre los proveedores de multimedia y el cliente. De otra manera ocurriría un "congelamiento" de los flujos de multimedia, lo cual es considerado generalmente como una molestia por el usuario.

Se han hecho varios intentos con respecto a resolver el problema precedentemente mencionado de cambios de gamas de anchura de banda.

En el documento WO 2002/073441 Al un archivo sencillo se divide en múltiples sub-archivos que subsiguientemente se distribuyen y almacenan en uno o varios servidores. Los sub-archivos se pueden transmitir en paralelo y simultáneamente desde uno o más servidores, lo cual incrementa la velocidad a la cual se pueden suministrar los datos. Además, al menos uno de los sub-archivos se puede almacenar en más de un servidor para proporcionar redundancia. Si no está disponible un servidor, o si el enlace de transmisión es lento o no está disponible, el sub-archivo se puede transmitir desde otro servidor.

En el documento US 2009/0259762 Al se muestra una estructura de transmisión discontinua distribuida y escalable que incluye una multitud de controladores y una multitud de servidores. Los controladores se pueden operar para establecer sesiones de Protocolo de Transmisión discontinua en Tiempo Real (RTSP) con dispositivos individuales. Un controlador selecciona un servidor para proporcionar un flujo de medio solicitado a un dispositivo. El servidor se puede seleccionar con fundamento en su proximidad al dispositivo, disponibilidad de anchura de banda o características de latencia. Es posible agregar servidores adicionales a un sistema sin desorganizar la operación del sistema.

El documento WO 2010/111261 Al muestra un sistema de transmisión discontinua de medios que utiliza adaptación dinámica de velocidad. Esto incluye un formato de archivo compatible con la infraestructura HTTP legada (legacy según se conoce en inglés) para suministrar medios por via de una conexión persistente. Los aparatos reproductores de medios de clientes de legacy son capaces de cambiar dinámicamente la velocidad de entrega codificada de los medios por via de una conexión persistente.

En el documento US 2010/0094955 Al se muestra un almacenamiento distribuido en el cual para cada grupo de al menos un dispositivo de ensamble se selecciona un sub-grupo de servidores CDN de almacenamiento fraccional de acuerdo a al menos un criterio. Una multitud de sub-grupos de servidores se selecciona de una multitud de grupos de dispositivo de ensamble. Los fragmentos codificados por supresión asociados con múltiples segmentos de contenidos son retirados por los dispositivos de ensamble de los sub grupos de servidores hasta que la anchura de banda agregada utilizada para recuperar los fragmentos se acerca a la anchura de banda agregada de los servidores incluidos en los sub-grupos, y mientras la anchura de banda agregada utilizada para suministrar cada segmento no excede la anchura de banda agregada de los servidores que almacenan los segmentos generados del segmento.

En el documento US 2006/0215596 Al se muestran ajustes de velocidad de transferencia para un dispositivo, por ejemplo un servidor multimedia. Estos ajustes de velocidad se, basan en determinar mediante el servidor multimedia varios parámetros de calidad de servicio de un enlace inalámbrico entre dos otros nudos de red, que puede comprender un punto de acceso y un reproductor de video, respectivamente.

En el documento US6405256B1 se revela la transmisión discontinua de datos con un servidor de red conectado al dispositivo de cliente mediante una red de comunicación con uno o varios servidores de almacenamiento en caché. El servidor de red tiene una aplicación de transmisión discontinua de datos y una memoria para almacenar datos. Los servidores de almacenamiento en caché forman una serie de conexiones, cada una de las cuales utiliza una disposición de transmisión discontinua de datos en la ruta entre la red de origen y el dispositivo del cliente. Cada servidor de almacenamiento en caché puede absorber congestión de red en su conexión corriente abajo utilizando una memoria intermedia expansible para almacenar segmentos adicionales de los datos transmitidos y variar la velocidad de transmisión de datos en la conexión corriente abajo.

Además, el 3rd Generation Partnership Project (3GPP) (Proyecto de Asociación de 3ra. Generación) ha estandarizado un marco de suministro que incluye un formato de contenedor capaz de almacenar múltiples versiones (que deben tener diferentes promedios de bits de codificación) de un mismo contenido que, asociados con una lógica inteligente en el lado del servidor de transmisión discontinua se pueden enfrentar con variaciones de las condiciones de red. Sin embargo, la asociación 3GPP no especificado ésta lógica de control.

La transmisión discontinua HTTP es una teenología recientemente publicada por Apple con su iPhone, por Microsoft con Smoothstreaming o por 3GPP con su transmisión discontinua adaptable a HTTP.

Las técnicas recientes usan el protocolo HTTP para proporcionar periódicamente retroalimentación del cliente al servidor sobre las condiciones reales de la red. El contenido de adaptación, que son pequeños cúmulos de contenido multimedia de duración fija pero con promedio de bits variable se le sirve al cliente de conformidad, en tanto que se adapta constantemente a las condiciones de la red.

La desventaja obvia es que la calidad percibida por el cliente se puede degradar severamente al variar la anchura de banda. Además, estas técnicas no pueden potenciar los equipos IPTV existentes que trabajan con protocolos RTP / RTSP.

Por lo tanto existe una necesidad en la téenica de proporcionar un método y un sistema para la transmisión discontinua adaptable en un entorno de múltiples rutas que respectivamente resuelven - al menos parcialmente - el problema asociado con los sistemas de la técnica anterior.

LA INVENCION De conformidad con la invención se proporciona un sistema para la transmisión discontinua adaptable en un entorno de múltiples rutas que comprende una multitud de servidores que son respectivamente capaces de transmitir a un cliente contenido multimedia en un entorno RTP/RTSP a través de respectivas rutas de datos, en donde el cliente incluye un medio de control que es capaz de verificar cada una de estas rutas de datos con el fin de determinar una respectiva anchura de banda asociada a cada una de estas rutas de datos y de solicitar un cúmulo de dicho contenido multimedia para cada uno de los servidores de acuerdo a la respectiva anchura de banda.

De conformidad con una forma de realización de la invención, el medio de control incluye medios para la estimación de régimen de ruta que son capaces de llevar a cabo control de velocidad del servidor, medición de anchura de banda y estimación de anchura de banda para cada respectivo servidor y ruta de datos.

De conformidad con otra forma de realización de la invención, el medio de control incluye medios para programar cúmulos que son capaces de llevar a cabo una selección de promedio de bits para el siguiente cúmulo que deberá ser entregado por el respectivo servidor.

De conformidad con otra forma de realización de la invención el medio de control incluye medios para asignación de depósito que son capaces de enlazar un cúmulo especifico de uno de los servidores a un depósito asignado de una lista enlazada con el fin de obtener un orden de consumo correcto.

De conformidad con otra forma de realización de la invención, el medio de control incluye medios para renumerar RTP y remarcar tiempo que son capaces de actualizar marcas de tiempo RTP y números de secuencia de manera que un decodificador no puede distinguir una transmisión discontinua recibida de múltiples servidores de una transmisión discontinua de la recibida de un solo servidor.

Dentro de un aspecto adicional de la invención se proporciona un método para la transmisión discontinua adaptable en un entorno de múltiples rutas que comprende proveer un cliente y proveer una multitud de servidores que son respectivamente capaces de transmitirle al cliente contenido multimedia en un entorno RTP/RTSP a través de una respectiva ruta de datos, en donde el cliente incluye un medio de control que es capaz de verificar cada una de estas rutas de,datos para determinar una respectiva anchura de banda asociada a cada una de estas rutas de datos y para solicitar un cúmulo de dicho contenido multimedia para cada uno de los servidores de acuerdo a la respectiva anchura de banda.

De conformidad con una forma de realización de la invención, el medio de control incluye medios para la estimación de régimen de ruta para llevar a cabo control de velocidad de servidor, medición de anchura de banda y estimación de anchura de banda en paralelo para cada uno de los servidores que se usan en la sesión de transmisión discontinua multi-rutas.

De conformidad con una forma de realización de la invención, la estimación del régimen de ruta se repite periódicamente.

De conformidad con una forma de realización de la invención, la estimación de régimen de ruta controla la velocidad de cada servidor mediante la adición de un atributo estándar RTS de velocidad a una solicitud para reproducir/jugar para determinar si la respectiva ruta de datos puede sostener la transmisión a una velocidad más alta que la velocidad actual.

De conformidad con una forma de realización de la invención, la velocidad actual para cada servidor entonces es usada por un algoritmo nivelador para determinar de manera iterativa un estimado confiable para inferir el promedio de bits obtenible del promedio de bits medido durante las iteraciones previas.

De conformidad con una forma de realización de la invención, para cada servidor se computa una variante para la velocidad actual.

De conformidad con una forma de realización de la invención, el medio de control incluye medios para programar cúmulos capaces de llevar a cabo una selección de promedio de bits para el siguiente cúmulo que deberá suministrar el servidor respectivo.

De conformidad con una forma de realización de la invención, los estimados de promedio de bits individuales se suman para todos los servidores para obtener el promedio de bits agregado y se selecciona una velocidad de reproducción/juego del cúmulo al promedio de bits de codificación inmediatamente inferior al promedio de bits agregado.

De conformidad con una forma de realización de la invención, el medio de control incluye medios para asignar depósitos que son capaces de enlazar un cúmulo especifico de uno de los servidores a un depósito asignado de una lista enlazada con el fin de obtener un orden de consumo correcto.

De conformidad con una forma de realización de la invención, el medio de control incluye medios para la renumeración y la remarcación de tiempo que son capaces de actualizar marcas de tiempo RTP y secuencias de números de manera que un decodificador no puede distinguir una transmisión recibida de múltiples servidores de una transmisión recibida de un solo servidor.

La invención propone un mecanismo que ofrece el control inmediato sobre la velocidad de transmisión discontinua al cliente en tanto que aprovecha una infraestructura IPTV existente utilizando el protocolo RTSP/RTP. RTSP (RFC 2326) es un protocolo para establecer y controlar transmisión discontinua de medios. No cubre el protocolo de transporte para los datos mismos, el cual comúnmente es RTP. Además, compensa las fluctuaciones de red mediante el uso concurrente de múltiples rutas de comunicación, uniformando mediante ello la velocidad de recepción global y la experiencia de usuario.

La invención propone un formato de archivo que permite la conmutación sin costura entre las versiones a diferentes promedios de bits, de manera similar a la transmisión discontinua adaptable a HTTP.

Un uso inteligente del protocolo RTSP permite verificar el estado de la red y controlar la velocidad de transmisión por el cliente sin modificar la infraestructura de servidor existente en tanto que aprovecha la comunicación multi-rutas. En lugar de solicitar una transmisión completa como con IPTV legacy, el cliente recibe fragmentos independientes de las transmisiones de múltiples servidores para beneficiarse de la comunicación multi-rutas. La velocidad de transmisión se ajusta individualmente para cada servidor para minimizar el riesgo de congestión de red.

Además, el cliente periódicamente solicita los servidores transmitir pequeños fragmentos de la transmisión a una velocidad más alta que la velocidad nominal para evaluar la capacidad de la red entre él y el servidor de suministrar una proporción más importante del contenido. Si la capacidad agregada de todas las rutas de red es suficiente para una transmisión con promedio más alto de bits, el cliente envía una solicitud diferente a todos los servidores para seleccionar una versión de la transmisión con promedio de bits más alto. Si la velocidad de recepción de la transmisión es demasiado lenta para la velocidad real de reproducción/juego, el cliente solicita a los servidores seleccionar una versión del contenido con promedio de bits más bajo.

La invención agrega la capacidad de adaptarse a variaciones de red en lo que se conoce como el entorno (manejado por) IPTV siendo que es completamente compatible con el protocolo asociado que se funda en RTSP/RTP sin que se requiera sustituir los equipos. Además, tiende a uniformar variaciones rápidas de anchura de banda de una sola ruta de red al distribuir la comunicación sobre múltiples rutas de red.

BREVE DESCRIPCION DE LAS FIGURAS La invención se describirá ahora con mayor detalle a modo de ejemplo con referencia a la figura siguiente, en la cual: Figura 1 muestra una vista esquemática de un sistema para la transmisión discontinua adaptable en un entorno de múltiples rutas de conformidad con una forma de realización de la invención; Figura 2 muestra otra vista esquemática de un sistema para la transmisión discontinua adaptable en un entorno de múltiples rutas de conformidad con una forma de realización de la invención; Figura 3 muestra una vista esquemática de una comunicación cliente-servidor de conformidad con una forma de realización de la invención; Figura 4 muestra otra vista esquemática de una comunicación cliente-servidor de conformidad con una forma de realización de la invención Figura 5 muestra otra vista esquemática de una comunicación cliente-servidor de conformidad con una forma de realización de la invención; Figura 6 muestra otra vista esquemática de una comunicación cliente-servidor de conformidad con una forma de realización de la invención; y Figura 7 muestra otra vista esquemática de un cliente de conformidad con una forma de realización de la invención.

DESCRIPCION DETALLADA DE LA INVENCION En la figura, los números de referencia iguales se refieren a partes iguales a menos que se indique otra cosa.

Con referencia ahora en particular a la figura 1, la invención incluida en ella comprende un sistema 10 para la transmisión discontinua adaptable en un entorno de múltiples rutas que comprende un cliente 12, una multitud de servidores que son respectivamente capaces de transmitir contenido multimedia en un entorno RTP/RTSP a través de una respectiva ruta de datos al cliente 12. El cliente 12 se dibuja como la caja superior del conjunto junto con una pantalla. En la figura 1 se muestran como un ejemplo un primer servidor 14, un segundo servidor 16 y un tercer servidor 18, los cuales están respectivamente conectados al cliente por vía de una primera ruta 20, una segunda ruta 22 y una tercera ruta 24.

De manera similar a la mayoría de las téenicas de transmisión discontinua adaptable, el contenido se debe codificar previamente a múltiples promedios de bits para soportar el suministro adaptable. Adicionalmente, las diferentes versiones de las transmisiones discontinuas están "alineadas en forma GOP" (GOP aligned según se conoce en inglés), lo cual significa que las posiciones de las ventanas de referencia, las cuales permiten acceso aleatorio a las transmisiones discontinuas se localizan en los mismos instantes de tiempo para todas las transmisiones de diferente promedio de bits. Esta propiedad le permite a un decodificador conmutar entre diferentes transmisiones en algunas localidades precisas (las ventanas de referencia) sin algún artefacto visual. Entonces se le permite al cliente 12 solicitar/descargar un cúmulo de cualquiera de estas versiones de transmisión en que el cúmulo es un conjunto de GOPs y tiene una duración constante, por ejemplo 2 s.

Este contenido de promedio de multi bits se distribuye entonces a los servidores 14, 16, 18 junto con un archivo de descripción que lista los promedios de bits disponibles. Este archivo de descripción es similar al archivo de manifiesto utilizado en implementaciones típicas de transmisión discontinua adaptable. En esta forma de realización, el archivo de descripción se implementa como un archivo SDP.

La figura 2 ilustra la preparación del contenido: un contenido 30 multimedia se codifica con un codificador 32 a múltiples promedios de bits, con la constricción adicional de que todas las ventanas de referencia aparecen en el mismo instante en cada transmisión codificada. Considerando que la transición de un promedio de bits a otro puede ocurrir menos frecuentemente que en cada GOP, la alineación de las ventanas de referencia se puede requerir en una base periódica de decenas de milisegundos (2 segundos en el ejemplo). En la forma de realización, el contenido se codifica utilizando los CODECS H.264 y AAC con ventanas de referencia que aparecen cada dos segundos y luego se encapsula en una transmisión de transporte MPEG. El contenido ejemplar utilizado para describir'la forma de realización se codifica en el conjunto siguiente de promedios de bits totales: 500 kbps, 1000 kbps, 1500 kbps y 2000 kbps. La descripción de la transmisión se puede expresar usando el protocolo SDP.

En este ejemplo se transmiten cuatro pistas MPEG TS y sus promedios de bits se avisan utilizando el atributo b=TIAS en el protocolo SDP. Adicionalmente, el atributo "X-altservers" le proporciona el cliente 12 una lista de localizaciones alternativas desde las cuales el contenido 30 se puede recibir. Estas localizaciones alternativas se podrían usar en lugar de la localización principal en virtud de que tienen exactamente lo mismo.

La operación RTSP normal para controlar una sesión de transmisión discontinua se ilustra en la figura 3. El primer mensaje le permite al cliente 12 descubrir las propiedades de la transmisión. El segundo mensaje llamado SETUP prepara la sesión de transmisión discontinua, y finalmente el mensaje PLAY hace que el servidor 14 comience a enviar la transmisión multimedia.

En la invención, el cliente conmuta de una transmisión a la otra durante la sesión de transmisión discontinua. En esta forma de realización, por motivos de claridad, el cliente emite varios mensajes SETUP al principio de la sesión de transmisión discontinua. Se hace una preparación para cada pista disponible. Sin embargo es obvio que el mensaje SETUP para cada pista también podría ser emitido por el cliente justo antes de que el cliente realmente necesite recibir esa pista.

Esta fase de preparación multi-pistas se muestra en la figura 4. Como una optimización, el cliente también puede preparar todas las pistas a la vez emitiendo un mensaje SETUP para el URL de la sesión en lugar de mensajes SETUP separados para las pistas individuales de la sesión.

Para soportar la operación de mult-servidores, el cliente 12 efectúa esta fase de inicialización para cada servidor listado en el atributo X-altservers.

Una vez que todas las pistas se han preparado, el cliente 12 solicita pequeños cúmulos de contenido multimedia emitiendo solicitudes PLAY para el intervalo de tiempo deseado de la pista deseada, como se muestra en la figura 5.

La pista se selecciona usando la trackID que se encuentra en el SDP. El intervalo de tiempo se le indica al servidor utilizando Rangecheader. Por ejemplo, para seleccionar el intervalo de tiempo 2-4s, el cliente le agregaría el siguiente encabezado a su solicitud de play: PLAY rtsp://multimedia.example.com/stream/trackID=l RTSP/1.0 Range: npt=2-4 Para evitar interrupciones sin reproducción/juego entre los cúmulos de transmisión, el cliente emite por adelantado una nueva solicitud RTSP PLAY para el siguiente cúmulo para mantener suficientes datos en la memoria intermedia playout (sin reproducción/juego). En nuestra forma de realización, la memoria intermedia playout contiene dos segundos de la transmisión multimedia descargada de antemano.

Para la operación multi-rutas, multi-servidores, el cliente solicita que cada servidor 14, 16 y 18 transmita diferentes cúmulos en paralelo a una velocidad que corresponde a la estimación del cliente de la capacidad de ruta de la red como se muestra en la figura 6.

La figura 7 muestra un diagrama esquemático de un controlador 40 adecuado para la operación multi-pistas y multi-servidores del cliente 12. El controlador 40 incluye un medio para una estimación 42 de velocidad de ruta que es capaz de llevar a cabo control de velocidad del servidor, medición de anchura de banda y estimación de anchura de banda para cada respectivo servidor y ruta de datos.

Además, el controlador 40 incluye medios para programar 44 cúmulos que son capaces de efectuar una selección de promedio de bits para el siguiente cúmulo que debe ser suministrado por el servidor respectivo. El controlador 40 incluye además medios para asignar 46 depósitos siendo capaz de enlazar un cúmulo especifico de uno de los servidores a un depósito asignado de una lista enlazada con el fin de obtener un orden de consumo correcto. El controlador 40 incluye un medio para renumerar RTP y para remarcar tiempo 48. En adición está presente una unidad 50 de consumo que permite que la transmisión recibida sea exhibida visualmente.

El cliente 12 combina estas transmisiones recibidas en una sola transmisión de manera que es idéntica a una transmisión que hubiera sido recibida de un solo servidor, es decir, el número de secuencia y las marcas de tiempo RTP se incrementan en forma monotónica. Esta tarea involucra el almacenamiento intermedio y la renumeración de los paquetes RTP recibidos de los diferentes servidores. Esto se resuelve mediante la etapa de asignación de depósito y renumeración RTP mostrada en la figura 7. Finalmente, esta transmisión combinada se inyecta en la memoria intermedia decodificadora del cliente.

La velocidad de ruta (promedio de bits disponible para una ruta) se estima mediante el medio para la estimación 42 de velocidad de ruta independientemente para cada servidor 14, 16 y 18 y la ruta de red 20, 22 y 24 asociada. Asi el proceso que se describe a continuación se lleva a cabo en paralelo para cada uno de los servidores que se usan en la sesión de transmisión discontinua multi-rutas.

El proceso de estimación de anchura de banda se compone de las etapas siguientes. Primero se lleva a cabo el control de la velocidad del servidor. De conformidad, la velocidad de transmisión del servidor 14, 16 y 18 es controlada por el cliente 12 para medir el promedio de bits actual disponible de la ruta 20, 22 y 24 de red. En segundo lugar se efectúa la medición de anchura de banda. De conformidad, se determina las características de la transmisión recibida por el cliente 12 en comparación con la velocidad de transmisión del servidor 14, 16 y 18 para determinar el actual promedio de bits de la red para el cúmulo actual. En tercer lugar se lleva a cabo la estimación de anchura de banda. Las mediciones de anchura de banda individuales se uniforman para producir un valor correcto útil para seleccionar los cúmulos siguientes.

Asi, la velocidad de transmisión del servidor es controlada por el cliente para medir el promedio de bits de la red disponible actualmente.

La medición de anchura de banda consiste en determinar las características de la transmisión recibida por un cliente en comparación a la velocidad de transmisión del servidor para determinar el promedio de bits real de la red para el cúmulo actual.

La estimación de la anchura de banda consiste en uniformar la estimación de anchura de banda individual con el fin de producir un valor correcto útil para seleccionar los cúmulos siguientes.

Todo el proceso de estimación de anchura de banda se repite periódicamente, pero no necesariamente para cada cúmulo, en situaciones en que las condiciones de red varían con lentitud.

Ventajosamente es entonces posible usar la ruta más lenta para recibir los cúmulos que se deben considerar "lejanos" en el tiempo y usar las rutas más rápidas para recibir los cúmulos que se deben considerar "prontos".

La velocidad del servidor 14, 16 y 18 se controla agregando un atributo "velocidad" ya estándar a la solicitud de PLAY. La idea en que se funda modificar la velocidad del servidor es el de terminar si la red podría sostener la transmisión a una tasa más alta que la tasa actual. En la forma de realización de la figura 6 y 7, el cliente 12 periódicamente verifica la capacidad de la red para transmitir 20% más rápido al solicitarle al servidor que envíe un cúmulo a 1.2 veces la velocidad actual.

Una solicitud RTSP ejemplar sería: PLAY rtsp://multimedia.example.com/stream/trackID=l RTSP/1.0 CSEQ: 833 Range: npt=2-4 Speed: 1.2 El servidor le respondería a la solicitud precedente como sigue: RTSP/1.0 200 OK CSeq: 834 Range: npt=2-4 RTP Info:url=rtsp://multimedia.example.com/stream/trackID=l;s eq=45102;rtptime=12345678 Un parámetro llamado rtptime indica la marca de tiempo RTP que corresponde al inicio del intervalo npt seleccionado. Con una velocidad de reloj dada, el cliente determina el intervalo rtptime que corresponde al cúmulo solicitado. Para computar el promedio de bits Bi actual, el cliente 12 suma los bits del paquete RTP recibidos en el intervalo previo rtptime. Divide esta por la duración de transmisión de estos bits (medida entre el primer bit recibido y el último bit recibido): B± = Bytes· 8/transmitDuration Este promedio de bits actual es usado entonces por un algoritmo uniformador para determinar un estimado confiable. El algoritmo utilizado en esta forma de realización es iterativo e intenta inferir el promedio de bits que se puede lograr a partir del promedio de bits medida durante las iteraciones previas.

El promedio de bits promedio para la siguiente iteración se computa como el promedio ponderado del actual promedio de bits y la medida actual como se muestra en la fórmula siguiente: avg =(l-a)avgi + a·B¿ en donde B es el promedio de bits medido, avgi es el promedio de bits promediado computado para la iteración actual, y a es el peso que se le da a la medición del promedio de bits actual. En un ejemplo, el peso se seleccionó como a=l/16.

Adicionalmente al promedio de bits promediado, el algoritmo estima la variación del promedio de bits. La variación se uniforma de la misma manera que el promedio de bits, como se muestra a continuación: Ai = |Bi- avgi| vari+1 = (1-/?)·vari+i+p-Ai en donde Aj es la diferencia entre el promedio de bits medido y el promedio de bits promediado para la iteración actual, vari es la variación computada para la estimación actual, y b es el peso que se le da a la medida de variación actual. En una implementación prototipo b se seleccionó para ser 1/8.

Para cada iteración, el estimado actual (o el promedio de bits obtenible) se computa como sigue: Bi = avgi - 4-vari Esto significa si la variación es grande, entonces el cliente 12 utiliza mucho menos que la anchura de banda promedio. Por otra parte, si la anchura de banda es estable y la variación es baja, el cliente 12 converge a usar toda la anchura de banda disponible en el enlace.

Se consideran dos casos excepcionales en que la estimación se reajusta: si la variación es demasiado larga (por ejemplo mayor que la mitad promediada del promedio de bits) o si existió una discontinuidad en los números de secuencia RTP, lo que significa que se perdieron paquetes RTP.

En los dos casos precedentes, los estimados de promedio y variación se reajustan como sigue: vari+ = avgi+i ÷ 10 El evento de una discontinuidad RTP inicia una nueva estimación de promedio de bits para el trayecto/servidor referido y/o una reprogramación de todos los cúmulos previamente programados.

La programación de servidor y cúmulo se lleva a cabo por el medio para programación 44 de servidor y cúmulo. Cada vez que el cliente 12 termina de recibir el cúmulo solicitado para un servidor dado (el servidor se vuelve inactivo), actualiza la estimación de anchura de banda para ese servidor y utiliza la conexión nuevamente para bajar otro cúmulo. Dependiendo de la disponibilidad y promedios de bits relativos de todas las rutas de servidor, la conexión de servidor se puede usar ya sea para bajar el siguiente cúmulo que se deberá reproducir/jugar o un cúmulo que se deberá reproducir/jugar más tarde, es decir, esto se llama programar cúmulos. El algoritmo de programación se describe a continuación.

Primero el medio para programación 44 de servidor y cúmulo selecciona el promedio de bits del cúmulo siguiente. Para hacer esto, el medio para programación 44 de servidor y cúmulo suma los estimados de promedios de bits individuales (ver lo siguiente) de todos los servidores 14, 16 y 18 con el fin de obtener el promedio de bits agregado en virtud de que todos los servidores se usan en paralelo. La tasa de reproducción/juego de cúmulo seleccionada es el promedio de bits de codificación inmediatamente inferior al promedio de bits agregado.

En el momento te en que la memoria intermedia del codificador estará vacia, primero se computa el tiempo de llegada del cúmulo para cada servidor 14, 16 y 18 utilizando los parámetros actuales de reproducción/juego y transmisión discontinua: ak es el momento en que la ruta k se vuelve inactiva (la recepción del cúmulo último o programado terminó), d duración de cúmulo, B promedio de bits de reproducción/juego y Bk el estimado de promedio de bits actual para servidor/ruta k. El tiempo que tomaría descargar el siguiente cúmulo del servidor k se designa Dk con Dk = d · B / Bk. El tiempo de llegada del cúmulo si se usa el servidor k se vuelve: Rk = ak * Dk El algoritmo selecciona el servidor que rinde el Rk más bajo. Adicionalmente el tiempo de llegada del cúmulo debe ser más temprano que el momento en que la memoria intermedia del decodificador estará vacia (te), es decir se debe satisfacer Rk < te. Si no se satisface, la memoria intermedia se vaciará y habrá una interrupción visible en la reproducción/juego. En un caso asi el promedio de bits de reproducción/juego se reducirá al promedio de bits siguiente inferior. Si se satisface la condición de tiempo de llegada, la recuperación de cúmulo se programa en el servidor k. La velocidad de transmisión se debe ajustar para coincidir con el estimado de promedio de bits actual para servidor/ruta k. Esto se hace utilizando el Speedrheader de la solicitud RTSP PLAY con velocidad = Bk / B.

Por ejemplo, suponiendo que la velocidad de reproducción/juego B es IMbps (se reproduce/juega trackID 1), el estimado de promedio de bits actual Bk es 400 kbps, tendríamos velocidad = 0.4. Como una nota colateral, si el proceso periódico de estimación de anchura de banda fue iniciado para el cúmulo actual, multiplicaríamos la velocidad resultante por 1.2.

Abajo está la solicitud correspondiente que se enviaría al servidor k (suponiendo que no se lleva a cabo un estimado de anchura de banda para el cúmulo actual): PLAY rtsp://multimedia.example.com/stream/trackID=l RTSP/1.0 CSeq: 838 Range: npt=40-42 Speed: 0.4 Si el servidor está actualmente inactivo, entonces la siguiente solicitud RTSP se hace inmediatamente. De otra manera, si el servidor todavía se está usando, entonces la solicitud RTSP se retardará hasta que el servidor se torne inactivo.

Finalmente un nuevo cúmulo será empujado sobre la memoria intermedia y por lo tanto el valor te se incrementa por la duración del cúmulo (d): te = te + d. Si cualquiera de los servidores está inactivo, los pasos precedentes se repiten hasta que todos los servidores 14, 16 y 18 están activos. De otra manera el medio para programación 44 de servidor y cúmulo espera a que un servidor esté nuevamente inactivo.

La asignación de depósito se lleva a cabo mediante el medio para asignación 46 de depósito. Cada vez que se envía una solicitud a un servidor 14, 16 y 18 por un cúmulo dado, la respuesta se enlaza a un depósito asignado de una lista enlazada que garantiza el. orden de consumo correcto. Es decir, la cabeza de la lista es el depósito que contiene los siguientes paquetes que se darán al decodificador. La cola de la lista es el depósito que contiene los paquetes que se decodificarán al último.

La renumeración y remarcación de tiempo RTP se lleva a cabo mediante el medio 48 para renumeración y remarcación de tiempo RTP. Es necesario normalizar la transmisión RTP final suministrada al decodificador/desmultiplexador de video. Para cada solicitud enviada a un servidor 14, 16 y 18 dado se asignó un depósito de recepción con el orden de consumo correcto. Una vez que se recibieron todos los paquetes RTP que corresponden a esa solicitud, las marcas de tiempo y números de secuencia RTP se actualizan de manera que el decodificador no puede distinguir una transmisión recibida de múltiples servidores de una transmisión recibida de un solo servidor.

En la práctica, el número de secuencia y tiempo RTP de todos los paquetes se renumeran comenzando con el último número de secuencia y marca de tiempo RTP utilizados para alimentar la memoria intermedia de decodificación.

De conformidad, la invención permite la transmisión discontinua adaptable multi-rutas aplicada al conjunto de protocolo RTSP/RTP. Un uso inteligente del parámetro velocidad (Speed) en el protocolo RTSP permite el uso paralelo de múltiples servidores asi como también verificar el estado de la red. El uso paralelo de múltiples servidores RTSP mediante el cliente permite reaccionar rápido a condiciones de red cambiantes y maximizar la experiencia del usuario. La invención se aplica al RTSP/RTP existente como se usa en la infraestructura IPTV.

Con otras palabras, el sistema que corresponde a la forma de realización preferida de la invención es un sistema para transmitir un contenido audiovisual mediante el uso de una téenica de transmisión discontinua multi-rutas adaptable en un entorno de red que comprende una multitud de servidores 14, 16, 18; cada uno de los servidores configurado para la transmisión del contenido multi-media con fundamento en un protocolo de comunicación de acuerdo con RTP/RTSP a través de respectivas rutas de datos 20, 22, 24 al cliente 12, en donde el cliente 12 incluye un controlador 40 capaz de verificar cada una de estas rutas de datos 20, 22 y 24 con el fin de determinar una respectiva anchura de banda asociada a cada una de las rutas de datos 20, 22 y 24 y solicitar un cúmulo de este contenido multimedia de cada uno de los servidores 14, 16 y 18 de acuerdo a una respectiva anchura de banda determinada.

El controlador 40 incluye medios para la estimación 42 de un promedio de bits disponible para cada una de las rutas de datos 20, 22 y 24 entre cada uno de los respectivos servidores 14, 16, 18 y el cliente 12, y se configura para efectuar control de velocidad de servidor en los servidores 14, 16 y 18.

El controlador 40 también incluye medios para la selección 44 de cúmulos de acuerdo al promedio de bits disponible, para seleccionar el siguiente cúmulo que deberá ser suministrado por el respectivo servidor 14, 16, 18.

El controlador incluye además medios para asignación 46 de depósito, configurados para enlazar un cúmulo especifico de uno de los servidores 14, 16, 18 a un depósito asignado de una lista enlazada con el fin de obtener un orden de consumo correcto en el lado del cliente (receptor).

Para proceder a la construcción de (formar) una sola transmisión coherente, el controlador 40 incluye medios para renumeración y remarcado de tiempo 48 RTP para actualizar marcas de tiempo y números de secuencia RTP. Esto permite formar una sola transmisión coherente en el lado del cliente como si hubiera sido recibida, por ejemplo, desde un solo servidor.

El método utilizado de conformidad con la forma de realización preferida de la invención es por lo tanto un método para la transmisión adaptable en un entorno de rutas múltiples que comprende: - proporcionar un cliente; y - proporcionar una multitud de servidores 14, 16, 18 que se configuran respectivamente para transmitir contenido multimedia en un entorno RTP/RTSP a través de una respectiva ruta de datos 20, 22, 24 al cliente, en donde el cliente 12 incluye un controlador 40 para verificar cada una de las rutas de datos 20, 22, 24 con el fin de determinar una respectiva anchura de banda asociada a cada una de estas rutas de datos 20, 22, 24, y solicitar un cúmulo del contenido multimedia de cualquiera de los servidores 14, 16, 18 de acuerdo a la respectiva anchura de banda determinada.

El controlador incluye medios para la estimación del promedio de bits de una ruta 42 con el fin de efectuar control de velocidad de servidor en los servidores 14, 16, 18, medición de anchura de banda y estimación de anchura de banda para cada uno de los servidores 14, 16, 18 que se usan en la sesión de transmisión discontinua multi-ruta.

De conformidad con la forma de realización preferida la estimación de promedio de bits de una ruta se repite periódicamente.

La estimación de promedio de bits de una ruta 42 comprende una etapa de controlar la velocidad del servidor 14, 16, 18 correspondiente mediante la adición de un atributo de velocidad estándar RTS a una solicitud de reproducción/juego.

Para cada servidor 14, 16, 18 el promedio actual es usado entonces por un algoritmo uniformador para determinar de manera iterativa un estimado para inferir el promedio de bits que se puede obtener del promedio de bits medido durante las iteraciones previas.

Para cada servidor 14, 16, 18 se computan una variación para el promedio actual.

El medio 40 controlador incluye medios para programación 44 de cúmulos (o selección de cúmulo) para llevar a cabo una selección de promedio de bits para el siguiente cúmulo que deberá ser suministrado por el respectivo servidor 14, 16, 18.

Los estimados de promedio de bits individuales se suman para todos los servidores 14, 16, 18 para obtener un promedio de bits agregado y una velocidad de reproducción/juego del cúmulo se selecciona el promedio de bits de codificación inmediatamente inferior al promedio de bits agregado.

Los elementos clave de la invención son el protocolo RTSP estándar (en oposición a la transmisión discontinua HTTP) y por lo tanto el nuevo uso de ecosistema existente, señalización de las múltiples versiones del contenido con SDP estándar, con un nuevo atributo para indicar la disponibilidad del contenido en múltiples servidores, operación concurrente de múltiples servidores y múltiples rutas de red mediante señalización RTSP, evaluación continua de la anchura de banda disponible en las rutas de red individuales con fundamento en el protocolo RTSP y el equilibrio continuo del promedio de datos en múltiples rutas con fundamento en esquema de suministro anticipado.

A pesar de que sólo se describieron en este documento determinadas formas de realización de la invención, cualquier persona experto en el ramo entenderá que son posibles otras modificaciones, variaciones y posibilidades de la invención. Por lo tanto, estas modificaciones, variaciones y posibilidades se consideran estar dentro del espíritu y alcance de la invención y por lo tanto forman parte de la invención según se describe y/o ejemplifica en este documento.

Siendo que esta invención se describió en su forma de realización preferida, está claro que es susceptible de numerosas modificaciones y formas de realización dentro de la habilidad de aquellos expertos en el ramo y sin incurrir en una actividad inventiva. De conformidad, el alcance de la invención es definido por el alcance de las reivindicaciones siguientes.

Todos los ejemplos y lenguaje condicional recitados en este documento tienen la intención de propósitos pedagógicos para ayudar a leer y entender los principios de la invención y los conceptos contribuidos por el inventor para desarrollar la téenica, y se deberán considerar como no limitativos a los ejemplos y condiciones específicamente recitados.

Además, todas las declaraciones en este documento que recitan principios, aspectos y formas de realización de los presentes principios, asi como también los ejemplos específicos de estos tienen la intención de abarcar.tanto equivalentes estructurales como funcionales de estos. Adicionalmente se pretende que estos equivalentes incluyan tanto los equivalentes actualmente conocidos así como los equivalentes que se desarrollarán en el futuro, es decir, cualesquiera elementos desarrollados que llevan a cabo la misma función, sin importar la estructura.

Así, por ejemplo, los expertos en la téenica apreciarán que los diagramas de bloques presentados en este documento representan vistas conceptuales de circuitos ilustrativos que incorporan los presentes principios. De manera similar se apreciará que cualesquiera mapas de flujo, diagramas de flujo, diagramas de transición de estado, seudo-códigos y lo similar representan varios procesos que sustancialmente se pueden representar en medios legibles por computadora y así ser ejecutados mediante una computadora o procesadora, ya sea que se muestre o no explícitamente este computador o procesador.

Las funciones de los varios elementos mostrados en las figuras se pueden proporcionar mediante el uso de equipo dedicado así como también de equipo capaz de ejecutar soporte lógico (software) en asociación con soporte lógico apropiado. Si son proporcionadas por un procesador, las funciones pueden ser proporcionadas por un solo procesador dedicado, por un solo procesador compartido, o por ,una multitud de procesadores individuales, algunos de los cuales pueden ser compartidos. Además, el uso explícito del término "decodificador", "controlador", "programador", "estimador" o su respectivo medio equivalente que efectúa las funciones correspondientes no se deberá considerar a que se refiere exclusivamente a equipo capaz de ejecutar soporte lógico, y puede incluir de manera implícita, sin limitación, equipo procesador de señales digitales ("DSP"), memoria de sólo lectura ("ROM") para almacenar soporte lógico, memoria de acceso aleatorio ("RAM") y almacenamiento no volátil.

Otro equipo, convencional y/o especial también se puede incluir. De manera similar, cualquier conmutación recitada en la especificación se puede llevar a cabo mediante la operación de lógica de programa, mediante lógica dedicada, mediante la interacción de control programado y lógica dedicada, siendo que la téenica particular puede ser seleccionada por la persona que lo instrumenta, como se entiende más explícitamente por el contexto.

En las reivindicaciones de este documento, se pretende que cualquier elemento expresado como un medio para llevar a cabo una función especificada abarque cualquier forma de efectuar la función, incluidos por ejemplo, a) una combinación de elementos de circuito que lleva a cabo esa función o b) soporte lógico de cualquier forma, incluyéndose por lo tanto soporte lógico inalterable, micro-codificación o lo similar, combinados con los circuitos apropiados para ejecutar ese soporte lógico para que lleve a cabo la función. Los presentes principios según se definen en estas reivindicaciones residen en el hecho de que las funcionalidades proporcionadas por los varios medios recitados se combinan o conjugan de la manera en que lo requieren las reivindicaciones. Por lo tanto se considera que cualesquiera medios que pueden proporcionar estas funcionalidades son equivalentes a los que se muestran en este documento.

La referencia en la especificación a "una forma de realización" o "una forma de realización" de los presentes principios, asi como otras variaciones de esta significa que una característica distintiva, estructura, característica etc. descritas en conexión con la forma de realización se incluye en al menos una forma de realización de los presentes principios. Por lo tanto, las apariciones de la frase "en una forma de realización" o "en una forma de realización", así como otras variaciones que aparecen en varios sitios a lo largo de la especificación no necesariamente se refieren todas a la misma forma de realización.

Se debe entender que los presentes principios se pueden instrumentar en varias formas de equipo, soporte lógico, soporte lógico inalterable, procesadores para propósitos especiales o una combinación de estos. Preferiblemente los presentes principios se pueden instrumentar como una combinación de equipo y soporte lógico. Además, el soporte lógico preferiblemente se implementa como un programa de aplicación incorporado de manera tangible en un dispositivo de almacenamiento de programa. El programa de aplicación se puede cargar, ejecutar en una máquina que tiene cualquier arquitectura adecuada. Preferiblemente la máquina se implementa en una plataforma de computadora que tiene equipo tal como una o varias unidades de procesamiento centrales (CPU), una memoria de acceso aleatorio (RAM) e interface (s) de entrada/salida (I/O). La plataforma de conmutadora también incluye un sistema operativo y un código de micro-instrucciones. Los varios procesos y funciones descritos en este documento pueden ser o bien parte del código de micro-instrucción o parte del programa de aplicación (o una combinación de estos) que se ejecuta por via del sistema operativo. Adicionalmente, se pueden conectar varios otros dispositivos periféricos a la plataforma de computadora, tales como un dispositivo de almacenamiento de datos adicional y un dispositivo de impresión.

Se debe entender además que debido a que algunos de los componentes que constituyen el sistema y de las etapas del método que se ilustran en las figuras anexas preferiblemente se incrementan en soporte lógico, las conexiones reales entre los componentes del sistema (o las etapas del proceso) pueden diferir en función de la manera en que se programan los presentes principios. Dadas las enseñanzas de este documento, cualquiera con una habilidad ordinaria en la téenica relacionada será capaz de contemplar estas e implementaciones o configuraciones similares de los presentes principios.

Claims (15)

REIVINDICACIONES

1. Un sistema para transmitir un contenido audiovisual mediante el uso de una téenica de transmisión discontinua multi-rutas adaptable en un entorno de red que comprende una multitud de servidores, siendo que cada uno de estos servidores está configurado para la transmisión de este contenido multi-media con fundamento en un protocolo de comunicación de acuerdo con RTP/RTSP a través de respectivas rutas de datos a un cliente, caracterizado porque el cliente incluye un controlador capaz de verificar cada una de estas rutas de datos con el fin de determinar una respectiva anchura de banda asociada a cada una de las rutas de datos y solicitar un cúmulo de este contenido multimedia de cada uno de los servidores de acuerdo a una respectiva anchura de banda determinada.

2. El sistema según se reclama en la reivindicación 1, caracterizado porque el controlador incluye medios para la estimación de un promedio de bits disponible para cada una de las rutas de datos entre cada uno de los respectivos servidores y el cliente, y se configura para efectuar control de velocidad de servidor.

3. El sistema según se reclama en cualquiera de las reivindicaciones 1 o 2, caracterizado porque el controlador incluye medios para la selección de cúmulos de acuerdo al promedio de bits disponible, para seleccionar el siguiente cúmulo que deberá ser suministrado por el respectivo servidor.

4. El sistema según se reclama en cualquiera de las reivindicaciones 1 a 3, caracterizado porque el controlador incluye medios para asignación de depósito, configurados para enlazar un cúmulo especifico de uno de los servidores a un depósito asignado de una lista enlazada con el fin de obtener un orden de consumo correcto.

5. El sistema según se reclama en cualquiera de las reivindicaciones 1 a 4, caracterizado porque el controlador incluye medios para renumeración y remarcado de tiempo RTP para actualizar marcas de tiempo y números de secuencia RTP para formar una sola transmisión coherente.

6. Un método para la transmisión discontinua adaptable en un entorno de múltiples rutas que comprende: -proporcionar un cliente; y - proporcionar una multitud de servidores que se configuran respectivamente para transmitir contenido multimedia en un entorno RTP/RTSP a través de una respectiva ruta de datos al cliente, caracterizado porque el cliente incluye un controlador para verificar cada una de las rutas de datos con el fin de determinar una respectiva anchura de banda asociada a cada una de estas rutas de datos y solicitar un cúmulo de este contenido multimedia de cualquiera de los servidores de acuerdo a la respectiva anchura de banda determinada.

7. El método según se reclama en la reivindicación 6, caracterizado porque el controlador incluye medios para la estimación del promedio de bits de una ruta con el fin de efectuar control de velocidad de servidor, medición de anchura de banda y estimación de anchura de banda en paralelo para cada uno de los servidores que se usan en la sesión de transmisión discontinua multi-ruta.

8. El método según se reclama en la reivindicación 7, caracterizado porque la estimación de promedio de bits de una ruta se repite periódicamente.

9. El método según se reclama en cualquiera de las reivindicaciones 7 u 8, caracterizado porque la estimación de promedio de bits de una ruta controla la velocidad del servidor correspondiente mediante la adición de un atributo estándar RTS de velocidad a una solicitud de reproducción/jugar.

10. El método según se reclama en la reivindicación 9, caracterizado porque para cada servidor el promedio actual es usado por un algoritmo uniformador para determinar de manera iterativa un estimado para inferir el promedio de bits que se puede obtener a partir del promedio de bits medido durante las iteraciones previas.

11. El método según se reclama en la reivindicación 9, caracterizado porque para cada servidor se computa una variación para el promedio actual.

12. El método según se reclama en cualquiera de las reivindicaciones 6 a 11, caracterizado porque el medio controlador incluye medios para programar cúmulos que son capaces de efectuar una selección de promedio de bits para el siguiente cúmulo que debe ser suministrado por el servidor respectivo.

13. El método según se reclama en la reivindicación 12, caracterizado porque en que los estimados de promedio de bits individuales se suman para todos los servidores para obtener el promedio de bits agregado y una velocidad de reproducción/juego de cúmulo se selecciona al promedio de bits codificado inmediatamente inferior al promedio de bits agregado.

14. El método según se reclama en cualquiera de las reivindicaciones 6 a 11, caracterizado porque el medio controlador incluye medios para asignación de depósito para enlazar un cúmulo especifico de uno de los servidores a un depósito asignado de una lista enlazada con el fin de obtener un orden de consumo correcto.

15. El método según se reclama en cualquiera de las reivindicaciones 6 a 9, caracterizado porque el medio controlador incluye medios para renumeración y remarcado de tiempo RTP que son capaces de actualizar marcas de tiempo y números de secuencia RTP para asi formar una sola transmisión coherente.