MX2013013373A - Metodo para adaptacion dinamica de la tasa de bits recibida y receptor asociado. - Google Patents

Abstract

Método para recepción de un programa audiovisual transmitido por medio de porciones por una red, el método usa un protocolo de transporte en tiempo real y un protocolo de control en tiempo real entre un servidor y un receptor, el programa audiovisual está disponible en el servidor en una pluralidad de versiones correspondientes al programa codificado en diferentes resoluciones y permite su transmisión en diferentes tasas de bits de acuerdo con solicitudes del receptor. El método comprende una medición regular del ancho de banda de la red por el receptor para ajustar la tasa de bits de transmisión de acuerdo con el estado de la red.

Description

MÉTODO PARA ADAPTACIÓN DINÁMICA DE LA TASA DE BITS RECIBIDA Y RECEPTOR ASOCIADO CAMPO DE LA INVENCIÓN La invención se relaciona con el dominio de receptores de programa audiovisual y más específicamente con la adaptación dinámica del programa de acuerdo con el ancho de banda disponible en la red durante la transmisión de un programa por medio de un protocolo de transmisión en tiempo real y un protocolo de control de servidor en tiempo real asociado con el protocolo de transmisión de tiempo real para una transmisión en directo.

ANTECEDENTES DE LA INVENCIÓN La descarga de un programa para su visualización impone la transferencia completa del programa audiovisual al receptor antes de la recuperación. Para evitar las limitaciones asociadas, como el requerimiento para esperar el final de la descarga o la necesidad de tener suficiente espacio de almacenamiento para todo el programa, el uso de la transmisión en directo (trasmisión continua del programa durante su visualización) es ampliamente común.

Protocolos de transmisión en directo conocidos incluyen RTP (RFC3550 y RFC asociado de acuerdo con el formato de datos transportados), asociado con el protocolo de control de servidor (RFC2326) y MPEG TS/UDP (Flujo de Transporte de Grupo de Expertos en Películas / Protocolo de Datagrama de Usuario) mientras que la descarga usa generalmente el protocolo HTTP (Protocolo de Transferencia de Hipertexto).

Redes de comunicación modernas ofrecen capacidades de ancho de banda que permiten la transmisión de programas audiovisuales en directo. La transmisión se puede llevar a cabo por medio de redes como la Internet, entre un servidor y un cliente. La transmisión en directo es un método de transmisión en el cual el programa audiovisual transmitido se desglosa en porciones temporales (porciones sucesivas para mostrarse en secuencia) transmitidas una tras otras en la red a través de transmisión y recuperación. La transmisión y recuperación son simultáneas, con la agregación de un ligero retraso debido al uso de una memoria buffer en el receptor.

El estándar 3GPP (3GPP, TSGS-SA, servicio en directo de interruptor de paquete de extremo a extremo (PSS), formato de archivo 3GPP (3GP), TS (26.244, V6.3.0, 2005-03) define un formato para la organización de datos y almacenamiento que comprende varias versiones de un mismo programa que corresponde a diferentes tasas de bits. Este formato, asociado con un control lógico en un servidor de programa, permite la adaptación de las condiciones y particularmente a variaciones en ancho de banda relacionada al uso de red. El control lógico incorporado en el servidor, sin embargo, no se especifica en el estándar 3GPP.

En los datos de formato 3GPP se codifican para ajustarse a una limitación de tasa de bits en un enlace de transmisión para una tasa de transmisión fijada: cuando los datos son imágenes, la codificación consiste en adaptar la resolución de imágenes para permitir su transporte en un enlace con más o menos ancho de banda. Pero 3GPP, sin embargo, no define medios de interruptor que permitan la resolución de imágenes transmitidas para modificarse para ajustar la recepción de datos a las variaciones en ancho de banda. Algunos métodos se conocen para resolver este problema: dependen en datos transmitidos del cliente al servidor, como los RRs (Reportes de Receptor) definidos en el protocolo RTCP (Protocolo de Control en Tiempo Real) y que requieren pasos de procesamiento e interpretación por el servidor para definir si la transmisión se debería llevar a cabo a otra tasa de bits.

La tecnología de transmisión en directo HTTP llamó reciente la atención del público en general por medio de Apple por su ¡Phone y por medio de Microsoft por su Smooth Streaming. La tecnología de transmisión en directo HTTP sólo se usa en receptores IPTV para los cuales el funcionamiento depende de protocolos RTP y RTSP.

Los métodos de transmisión usados actualmente en IPTV no permiten la adaptación dinámica de la tasa de bits de acuerdo con el ancho de banda disponible en la red sin usar un servidor específico. También, cuando las condiciones de acceso al servidor se deterioran, un riesgo de interrupción al servicio ocurre en el receptor.

El protocolo de transferencia en tiempo real RTP, por ejemplo, es un protocolo usado para la encapsulación y transmisión en tiempo real de datos que codifican un programa audiovisual. La codificación usada para los datos es generalmente de tipo MPEG-TS o un formato equivalente.

RTSP es un ejemplo de protocolo de comunicación que permite el control de un servidor de medio remoto. Tal protocolo ofrece las funcionalidades comunes de un reproductor de video, como "PLAY" y "PAUSE" y permite la reproducción de una porción del programa audiovisual de la posición temporal de la porción de programa en el programa (por ejemplo, un índice de tiempo o una posición correspondiente en un archivo).

Durante las transmisiones de programas audiovisuales en directo por medio de protocolos como RTP y RTSP, por ejemplo, modificaciones significativas en disponibilidad de red tienen una incidencia muy significativa en la recuperación de programas. Cuando la tasa de bits no se ajusta de forma dinámica entre el inicio y el final de una transmisión, ocurren interrupciones, que son un inconveniente significativo para el usuario.

El protocolo de transporte RTP depende del protocolo UDP y el protocolo HTTP depende del protocolo TCP conectado.

TCP es conocido como un protocolo "conectado" que responde a limitaciones de conf labilidad, permite que se transmitan datos sin errores de paquete de un servidor a un receptor. Para hacer esto, el receptor se comunica con el servidor que le indica los datos recibidos. Además de ser dependiente a datos perdidos y retransmitidos, la tasa de bits promedio se enlaza al enrutamiento de reconocimientos. Mientras más rápido es el tiempo de enrutamiento, más disminuye la tasa de bits máxima.

UDP es un protocolo que no responde a las mismas limitaciones de confiabilidad. Se llama "no confiable" y "sin conexión". No tiene sistema de reconocimiento y su tasa de bits promedio no se enlaza a la distancia entre el servidor y el receptor. Por esta razón el protocolo UDP se usa con aplicaciones RTP en IPTV.

El documento US2010/161716A1 (KAJOS GEORGE W[US] ET AL), 24 de junio de 2010 (2010-06-24) describe un método para enviar contenido a un dispositivo de cliente por una red, donde un mensaje que indica las capacidades de interpretación del cliente se recibe por el servidor que entonces transmite el contenido en un formato que se puede decodlficar completamente por el cliente, de acuerdo con sus capacidades de interpretación.

Uno de los propósitos de la invención es combinar las ventajas de UDP mientras se puede adaptar de forma dinámica la tasa de bits a las condiciones de red.

BREVE DESCRIPCIÓN DE LA INVENCIÓN El propósito de la invención es superar por lo menos una de las desventajas de la técnica anterior y más específicamente permitir un control dinámico del ancho de banda usado durante una transmisión de programas audiovisuales para infraestructuras IPTV estándares que usan algún protocolo de control/transferencia en tiempo real como, por ejemplo, los protocolos RTP y RTSP.

Un uso de un protocolo de control de servidor en tiempo real adaptado de acuerdo con la invención permite al receptor solicitar del servidor la transmisión del programa audiovisual en porciones sucesivas. El receptor periódicamente mide, para cada una de las porciones transmitidas, las condiciones de transmisión de la red y ajusta la tasa de bits de transmisión como consecuencia. El ajuste de la tasa de bits de transmisión se lleva a cabo por el receptor al seleccionar, para cada porción del programa sucesivamente solicitado por el servidor, una versión de programa de entre varias versiones codificadas en diferentes tasas de bits y disponibles en el servidor. La selección de la versión por el receptor se hace de acuerdo con la tasa de bits de transmisión medida durante la transmisión de la porción anterior. De esta manera, el ajuste de la tasa de bits no requiere modificación del servidor de programas.

La invención se relaciona con un método para la recepción de un programa audiovisual almacenado en un servidor para reproducirse en un dispositivo de visualización conectado a un receptor, el programa audiovisual está disponible en el servidor en por lo menos dos versiones, cada una de las versiones que comprende una sucesión temporal de bloques de datos que codifican partes del programa (y por lo tanto una sucesión de bloque de datos que se interpretarán en secuencia), las versiones comprenden cada una un mismo número de bloques, cada uno de los bloques inicia con una imagen codificada sin referencia a una imagen anterior. De acuerdo con la invención, el método comprende pasos, en el nivel del receptor, de recepción, de acuerdo con un protocolo de transporte en tiempo real, de una primera porción del programa audiovisual que comprende por lo menos un bloque de datos de una primera de las versiones transmitidas por el servidor en una primera tasa de bits, de determinación del ancho de banda después de la recepción de la primera porción del programa audiovisual transmitido por dicho servidor en la primera tasa de bits, de transmisión de una solicitud al servidor, de acuerdo con un protocolo de control de servidor en tiempo real, la solicitud que comprende información de identificación de una segunda porción del programa audiovisual en una de las versiones del programa de acuerdo con el valor determinado del ancho de banda entre el servidor y el receptor y un parámetro de velocidad de transmisión, la información de identificación que comprende marcadores temporales del inicio y final de la segunda porción.

De acuerdo con una modalidad de la invención, los pasos de recepción, determinación del ancho de banda y transmisión de una solicitud por el receptor se reproducen iterativamente durante la recepción del programa audiovisual.

De acuerdo con una modalidad de la invención, las versiones del programa audiovisual se comprenden de un solo archivo almacenado en el servidor.

De acuerdo con una modalidad de la invención, el programa audiovisual se asocia en el servidor con un archivo descriptivo que comprende información relacionada con la localización de versiones del programa audiovisual en el mismo archivo.

De acuerdo con una modalidad de la invención, la determinación del ancho de banda disponible entre el servidor y el receptor comprende un análisis de por lo menos una característica de las porciones del programa audiovisual recibido en la primera tasa de bits.

De acuerdo con una modalidad de la invención, por lo menos una característica de porciones es el número de bits transmitidos.

De acuerdo con una modalidad de la invención, el paso de transmisión de una solicitud usa el comando PLAY del protocolo RSTP.

La invención también se relaciona con un dispositivo de recepción para un programa audiovisual difundido por un servidor, el programa está disponible en el servidor en por lo menos dos versiones, cada una de las versiones correspondientes con una resolución de imagen del programa audiovisual y que comprenden una sucesión de porciones, cada una de las versiones que comprenden un mismo número de porciones y cada una de las porciones inicia con una intra-imagen. De acuerdo con la invención, el dispositivo comprende medios de recepción, de acuerdo con un protocolo de transporte en tiempo real, de una primera porción del programa audiovisual en una primera de las versiones transmitidas por dicho servidor en una primera tasa de bits, medios para la determinación del ancho de banda después de la recepción de la primera porción de dicho programa audiovisual transmitido por dicho servidor en la primera tasa de bits y medios para la transmisión de una solicitud al servidor, de acuerdo a un protocolo de control real, la solicitud que comprende información de identificación de una segunda porción del programa audiovisual en una de las versiones del programa de acuerdo con el valor determinado del ancho de banda entre el servidor y el receptor y un parámetro de velocidad de transmisión, la información de identificación que comprende marcadores temporales del inicio y final de la segunda porción.

La tasa de bits de transmisión por lo tanto se ajusta para adaptarse al ancho de banda disponible en la red y para evitar interrupciones durante la recuperación del programa audiovisual, aún si significa recuperar el programa con un nivel más bajo de calidad.

Obviamente, la invención no se limita al uso de protocolos RTP y RTSP y concierne cualquier protocolo de transferencia en tiempo real y protocolo de control de servidor correspondiente con características similares que el RTP y RTSP, respectivamente, y particularmente proporciona comandos de control como un comando PLAY con parámetros que permiten seleccionar una versión, un tiempo de inicio y una longitud (o un tiempo de parada) para la parte del programa audiovisual que se reproducirá (interpretará).

BREVE DESCRIPCIÓN DE LAS FIGURAS La invención se entenderá mejor, y otras características y ventajas específicas surgirán al leer la siguiente descripción, la descripción hace referencia a las figuras anexas donde: - La figura 1 muestra un sistema para recepción de programas audiovisuales por medio de un receptor/decodificador de acuerdo con una modalidad de la invención.

- La figura 2 muestra un método para permitir la codificación de la creación de un archivo que contiene varias versiones de un mismo programa.

- La figura 3 muestra un archivo del servidor que comprende varias versiones de un mismo programa audiovisual codificado para difundirse a diferentes tasas de bits de acuerdo con una modalidad de la invención.

- La figura 4 muestra en diagrama una secuencia de mensajes de inicialización entre un receptor y un servidor para transmisión de una corriente de acuerdo con el protocolo de transmisión RTP.

- La figura 5 muestra una secuencia de mensajes de inicialización entre un receptor y un servidor para transmisión de una corriente de acuerdo con una modalidad de la invención.

- La figura 6 es un diagrama que muestra el método incorporado en un receptor, que comprende una evaluación regular del ancho de banda de la red y la transmisión de solicitudes que comprenden un parámetro de tasa de bits y un parámetro de velocidad de transmisión adaptados al estado de la red.

- La figura 7 es un diagrama funcional de un receptor de acuerdo con una modalidad de la invención.

- La figura 8 es un diagrama funcional que muestra la unidad de control del receptor descrito en la figura 7.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN De manera general pero no limitada, la invención se relaciona con un método para recepción de un programa audiovisual en transmisión en directo, que permite una adaptación dinámica de la tasa de bits usada para la transmisión del programa de acuerdo con la congestión de la red determinada por una medición regular del ancho de banda.

La figura 1 muestra un sistema para la recepción de programas audiovisuales por un receptor 2 por medio de una red 3. Durante la recepción, el receptor procesa el programa audiovisual y transmite señales al dispositivo de visualización 4 para su visualización. Los programas están codificados y disponibles en el servidor de programas 1. Los programas se almacenan en forma de archivos digitales. Las técnicas de transmisión que autorizan la transmisión de programas a tasas de bits variables durante la recuperación requieren una codificación específica para hacer disponible en el servidor el programa audiovisual en diferentes versiones correspondientes a diferentes tasas de bits durante la transmisión de datos que codifica el programa. Las diferentes versiones del mismo programa audiovisual se almacenan en el servidor de programa 1. Las diferentes versiones se pueden almacenar en distintos archivos o reunir en un solo archivo e identificarse por sus posiciones respectivas en el archivo. Un archivo de descripción asociado con cada uno de los programas contiene información relativa a las diferentes versiones, sus tasas de bits respectivas y sus locaciones. Esta información se transmite al receptor durante una fase de inicialización de la transmisión del programa desde el servidor al receptor.

La figura 2 muestra la codificación de un programa audiovisual para transmitirse con un ajuste de tasa de bits de acuerdo con las condiciones de transmisión en la red. El programa audiovisual se codifica en varias versiones. Cada una de las versiones corresponde a una resolución de imagen y por lo tanto a una tasa de bits de transmisión. En cada una de las versiones, el programa se constituye por una sucesión de bloques o grupos de imágenes. Todos los bloques corresponden a una duración de recuperación (o reproducción) primaria del programa, por ejemplo, dos segundos. Estos bloques primarios se llaman comúnmente trozos, por ejemplo, en el caso de tecnología de transmisión en directo adaptable HTTP. La primera imagen de cada bloque es una intra-imagen. Una intra-imagen se define como codificada sin referencia a una imagen anterior. La posición de intra-imágenes en el inicio del bloque es la misma en cada una de las versiones. Por lo tanto, si un receptor solicita que el servidor envíe el siguiente bloque en la continuidad del programa en términos de contenido visto, pero en otra versión y por lo tanto con otra tasa de bits de transmisión, el decodificador integrado en el receptor puede llevar a cabo la decodificación del bloque sin problemas de referencia a imágenes anteriores. La figura 2 describe la codificación de un programa en versiones correspondientes respectivamente a tasas de bits en recepción (y por lo tanto en transmisión) de 500 Kbits/s, 1 Mbits/s, 1.5 Mbit/s y 2 Mbit/s.

La figura 3 muestra un archivo 30 que contiene varias versiones 31 , 32, 33, 34 de un mismo programa audiovisual desde, por ejemplo, un método de codificación mostrado en la figura 2. Las diferentes versiones se colocan en un mismo archivo con diferentes índices. El pasaje desde una versión a la otra durante transmisión de un programa entonces corresponde a la adición de un índice al indicador de reproducción. Una versión del programa audiovisual corresponde a cada uno de los valores de índice posibles agregados al indicador. El indicador identifica la posición temporal de la porción del programa que se recuperará.

La figura 4 muestra el establecimiento de comunicación entre un receptor y un servidor de difusión de acuerdo con una modalidad de la invención por medio del estándar de transmisión RTP. Durante la inicialización de una difusión que usa el protocolo RTP, el receptor se encarga de un primer mensaje titulado RTSP DESCRIBE que incluye un url al servidor para obtener información del servidor relacionada con el programa que se visualizará en un dispositivo de visualización conectado al receptor. El término url (localizador de recursos uniforme) describe aquí la dirección de red que indica al programa que se visualizará. Esta dirección tiene, por ejemplo, la sintaxis "multimedia.example.com". El servidor se encarga de información al receptor en un mensaje de respuesta titulado RTSP DESCRIBE RESPONSE. El mensaje RTSP DESCRIBE RESPONSE indica al receptor si las versiones de programa se almacenan en el servidor en archivos separados o se concatenan en un solo archivo. Una segunda solicitud titulada RTSP SETUP entonces se dirige al servidor por medio del receptor para preparar la sesión de transmisión en directo del programa. Si las versiones diferentes del programa se almacenan en archivos separados en el servidor, el receptor entonces inicializará con el servidor tantas sesiones de transmisión como haya versiones disponibles. Si las diferentes versiones se concatenan en un mismo archivo en el servidor, el receptor inicializa una sola sesión de transmisión. En el caso donde las diferentes versiones del programa se concatenan en un mismo archivo, el receptor agregará un índice al indicador de reproducción para moverse desde una versión a otra del programa y por lo tanto ajustar la tasa de bits de transmisión de la porción de programa reproducida. Para cada solicitud de inicialización de una sesión por el receptor, el servidor responde con un mensaje titulado RTSP SETUP RESPONSE. Un tercer mensaje titulado RTSP PLAY enviado por el receptor inicia la transmisión del programa por el servidor. El mensaje RTSP PLAY aún se llama una solicitud y comprende un parámetro de marcador temporal de la porción del programa para transmitirse con una visualización a su recuperación. El mensaje de PLAY también comprende un parámetro de velocidad que indica al servidor la velocidad a la cual transmitir los datos que corresponden a la porción de programa que se transmitirá.

De acuerdo con una modalidad de la invención, el contenido del programa audiovisual se codifica de acuerdo con codees H.264 para el video y codees AAC para el audio, el tamaño de un bloque de datos primarios que empieza con una intra-imagen que corresponde a dos segundos de duración en la recuperación, la encapsulación de datos se realiza de acuerdo con un formato de corriente de transporte MPEG, y tasas de bits asociadas con las versiones diferentes son de 500 Kbits/s, 1 Mbits/s, 1.5 Mbits/s y 2 Mbits/s. El archivo de descripción asociado en el servidor con el archivo de contenido de programa audiovisual y que contiene información de diferentes versiones del programa y de diferentes tasas de bits asociadas es un archivo de formato SDP que tiene por ejemplo la siguiente forma: v=0 o= - 1 1 IN IP4 192.168.1.33 s= Example of multimedia stream b=RR:0 a=X-keyframe-period=2 a=control:* a=range:npt=0-300 m=video 0 RTP/AVP 33 b=TIAS:500000 a=control:tracklD=0 m=video 0 RTP/AVP 33 b=TIAS: 1000000 a=control:tracklD=1 m=video 0 RTP/AVP 33 b=TIAS: 1500000 a=control:tracklD=2 m=video 0 RTP/AVP 33 b=TIAS:2000000 a=control:tracklD=3 En este ejemplo de archivo SDP, las cuatro corrientes (corrientes de transporte MPEG) se notan y asocian con sus respectivas tasas de bits al usar el parámetro b=TIAS que corresponde a una tasa de bits expresada en Mbit/s.

La figura 5 muestra el establecimiento de comunicación entre un receptor y un servidor de difusión de acuerdo con una modalidad de la invención y donde diferentes versiones del programa que se visualizará se almacenan en distintos archivos en el servidor. El receptor inicializa la recepción de porción de programa audiovisual que se recuperará desde corrientes diferentes. Durante la restitución, y para cada porción de programa solicitada de forma sucesiva, el receptor indica en el servidor la versión adaptada a la condición de ancho de banda en la red y recibe los datos de la corriente correspondiente. Cada corriente corresponde a la transmisión de datos desde una misma versión. De acuerdo con una modalidad, el receptor se encarga de tantos mensajes de inicialización como hay versiones disponibles, antes de la transmisión.

Una vez que la fase de inicialización (SETUP) se ha completado para cada una de las versiones, el receptor puede pasar desde una versión a otra al enviar una solicitud de PLAY que especifica la versión e intervalo temporal (al usar marcadores temporales) correspondiente al bloque requerido, así como a la velocidad de transmisión. De acuerdo con otras modalidades, el receptor se puede encargar de solicitudes de inicialización de PLAY antes del primer acceso a una versión, durante la transmisión.

La figura 6 es un diagrama de bloque que muestra el método usado por el receptor, de acuerdo con una modalidad de la invención. El paso S1 es el paso inicial en el cual el receptor no ha inicializado recepción de un programa en transmisión en directo. En este paso, el receptor está en espera para un comando desde un usuario que controla el receptor. En el paso S2, el receptor inicializa una sesión de difusión en directo. Envía un primer mensaje RTSP DESCRIBE que especifica la dirección url meta del programa audiovisual que se recibirá desde el servidor para restitución. Esta dirección url puede ser por ejemplo rtsp://example.com/movie/. Esta dirección meta sirve como referencia para el control de la difusión. El servidor se encarga de un mensaje de tipo RTSP DESCRIBE RESPONSE que indica al receptor las propiedades de corriente de transmisión correspondientes a las diferentes versiones del programa audiovisual, codificadas para difundirse con diferentes tasas de bits. Esta información comprende el número de versiones, sus identificadores respectivos, las tasas de bits de codificación y el tamaño de bloques de datos. El siguiente mensaje se intercambia, RTSP SETUP transmitido desde el receptor y RTSP SETUP RESPONSE transmitido desde el servidor, prepara la sesión de difusión en directo. El receptor almacena la información recibida en la fase de inicialización S2 y es capaz de encargarse de solicitudes RTSP PLAY sucesivas para la difusión y la recepción de porciones (que comprende uno o más bloques de datos) del programa audiovisual. En el paso S3, el receptor transmite una solicitud RTSP PLAY que contiene parámetros específicos a la difusión de la porción de programas que se recibirán (y por lo tanto se difundirán por el servidor).

La estructura de una solicitud RTSP PLAY de acuerdo con una modalidad de la invención es: PLAY rtsp://multimedia.exemple.com/stream/tracklD=1 RTSP/1.0 Cseq: 833 Range: npt=0-2 Speed: 1 Donde PLAY indica que la solicitud es un mensaje que pide la difusión de un bloque de datos con una vista a su restitución.

Cseq indica el número de secuencia indicado por el servidor en el paso de inicialización S2, Range indica la porción de programa correspondiente a la posición temporal de 0 a 2 segundos desde el inicio de la difusión y Speed indica la velocidad de difusión.

Para evitar interrupciones durante la restitución del programa audiovisual, el receptor se encarga de las solicitudes RTSP PLAY para la siguiente porción de programa en anticipación para mantener una cantidad suficiente de datos en el buffer de recepción. De preferencia, el buffer de recepción contiene dos segundos de programa recibido y disponible antes de decodificarse. Favorablemente, y para absorber fluctuaciones en ancho de banda disponible en la red, el buffer de recepción puede contener un número de artículos de datos correspondientes a varios segundos de restitución del programa audiovisual transmitido.

De acuerdo con una modalidad de la invención y para los propósitos de simplificación, la difusión de bloques de datos de diferentes versiones se hace durante una sola sesión RTSP. Por lo tanto es favorable concatenar las diferentes versiones del programa codificado en un solo archivo en el servidor.

Si se considera que un programa audiovisual de una duración d codificada con la tasa de bits B0= 500 Kbps, B1 = 1 Mbps, B2 = 1 ,5 Mbps and B3 = 2 Mbps, el acceso a la versión i del programa codificado con la tasa de bits B¡ desde la posición temporal t, el parámetro de Range de la solicitud RTSP PLAY correspondiente se definirá de la siguiente forma: Range = i x d + t En el paso S4, el receptor recibe el bloque de datos que codifica la porción del programa meta en el servidor. El receptor almacena este bloque de datos en el buffer de recepción donde se leerá por el módulo de decodificación de audio/video del receptor.

El paso S5 define si la porción previamente recibida en S4 fue la última del programa, si este es el caso la difusión acaba.

En el paso S6 y en el caso donde la porción de datos recibida en S4 no es la última del programa audiovisual, en términos de posición temporal, el receptor lleva a cabo una estimación del ancho de banda disponible en la red.

La estimación de ancho de banda comprende, de acuerdo con una modalidad de la invención, pasos por definición de la tasa de bits de difusión posible desde el servidor y pasos para la medición de la tasa de bits por un período predefinido. Favorablemente, la estimación del ancho de banda puede comprender un paso de ponderación. De acuerdo con una modalidad de la invención, el paso de ponderación comprende un paso de facilitación o integración que permite obtener un valor promedio que supera variaciones rápidas en el ancho de banda alrededor de este valor. El receptor comprende una memoria buffer (buffer de recepción) capaz de absorber variaciones rápidas en el ancho de banda de la red.

De acuerdo con la invención, la estimación del ancho de banda se puede repetir para cada uno de los bloques de datos primarios o para la porción del programa que comprende un número predefinido de bloques de datos primarios.

La respuesta transmitida por el servidor a una solicitud RTSP PLAY tiene la siguiente forma: RTSP/1.0 200 OK Cseq: 834 Range: npt=0-2 RTP-Info: url=rtsp://multimedia.exemple.com/stream/tracklD=1 ; seq=45102; rtptime = 12345678 Donde rtptime es un marcador temporal que indica el inicio de la porción del programa indicado por el intervalo npt.

Si por ejemplo un programa de reloj se considera de una corriente codificada en formato MPEG-2 TS que tiene un valor de 9000, comunicado al receptor en el paso de inicialización de la sesión de transmisión, el receptor puede calcular un intervalo de tiempo rangeduration correspondiente al tiempo de recepción del bloque de datos.

Rangeduration - rtptime end - rtptime start Cuando rtptime start es el valor del parámetro rtptime indicado en el campo de información RTP-Info de la respuesta del servidor, y rtptime end = rtptime del campo RTP-Info + 90000 Donde 90000 es el reloj RTP indicado durante la fase de ¡nicialización de la sesión de difusión.

La tasa de bits instantánea por el período de recepción del bloque de datos entonces se calcula al agregar el número de bytes de datos recibidos por el intervalo de tiempo (bytes que constituyen los paquetes de datos de la difusión de acuerdo con el protocolo RTP), que multiplica el número de bytes por 8 para obtener el número de bits (elementos binarios) y divide el resultado del producto por la duración de recepción.

Concretamente, una expresión de la tasa de bits instantánea: B¡ = Bytes x 8 / rangeduration De acuerdo con una modalidad de la invención, el valor de la tasa de bits instantánea por lo tanto calculada entonces se usa en un algoritmo facilitador para definir un valor de tasa de bits más preciso.

El algoritmo usa un proceso iterativo para determinar la tasa de bits que se podría obtener en consideración con los valores de tasas de bits instantáneas calculadas en las iteraciones anteriores. i es un índice que se refiere a la iteración i del cálculo de tasa de bits útil y su variante durante la transmisión de datos recibidos.

Una estimación de tasa de bits futura para la siguiente iteración entonces se calcula: avg¡+1 = (1 - a) x avg¡ + a x B¡ donde B¡ es la tasa de bits medida, avg¡ es el promedio calculado para la iteración actual, a es un factor de ponderación atribuido al valor medido de tasa de bits instantánea.

Preferiblemente, el valor de a es igual a 1/16.

Además del valor promedio ponderado, el algoritmo usado por la invención estima la variación en la tasa de bits. La variación se facilita de la misma manera que la tasa de bits: A¡ = I B¡ - avg¡ | var¡+i = ( 1 - ß ) x var¡ + ß x A¡ donde A¡ es la diferencia entre la tasa de bits medida y la tasa de bits promedio para la iteración actual del cálculo. var¡ es la variación calculada para la iteración actual, ß es un factor de ponderación para el valor de variación de la estimación actual.

Preferiblemente, el valor de ß es igual a 1/8.

Para cada una de las iteraciones del algoritmo, la estimación de la tasa de bits que se puede obtener de la difusión del programa audiovisual se calcula como sigue: B¡max = avg¡ - 4 x van Entonces, si la variación es mayor, esto significa que el receptor usa menos del promedio del ancho de banda disponible. Además, cuando el ancho de banda es estable y la variación es baja, el receptor usa todo el ancho de banda disponible entre el servidor y sí mismo.

Favorablemente, en el caso donde el receptor usa todo el ancho de banda disponible, se encarga de las solicitudes RTSP PLAY del servidor cuyo objetivo es agrupar juntas varias porciones primarias del programa recibido, esto para evitar sobrecargar el servidor con varias solicitudes regulares. El receptor puede por ejemplo solicitar, con la misma solicitud al servidor, dos o cuatro bloques de datos principales.

De acuerdo con una modalidad de la invención, donde la variación es muy grande, por ejemplo, si su valor es mayor que la mitad del valor de la tasa de bits, las estimaciones de tasa de bits y variación se calculan como sigue: avgi+i = (avg¡ + B¡} / 2 y var¡+1 = avg¡+ / 10 De acuerdo con una variación de la invención, el receptor determina si la red permite la difusión de una tasa de bits mayor que la tasa de bits actual al indicar la misma versión del programa audiovisual y modificar el parámetro de velocidad definido en el protocolo de control RTSP. Si la tasa de bits actual es, por ejemplo, 1.5 Mbits/s, el receptor evalúa la capacidad de la red de transmitir a 2 Mbits/s al enviar una solicitud al servidor que especifica un parámetro de "Velocidad" con el valor Speed=1.34.

Una solicitud RTSP transmitida para recibir el bloque de datos correspondiente al intervalo de tiempo entre el segundo y cuarto segundo del programa audiovisual localizado por medio del url "multimedia.exemple.com/stream" tiene una tasa de bits de 2 Mbits/s mientras que la tasa de bits de difusión de corriente es de 1.5 Mbits/s tiene por ejemplo la siguiente forma: PLAY rtsp://multimedia.exemple.com/stream/tracklD=1 RTSP/1.0 Cseq: 833 Range: npt=2-4 Speed: 1.34 En el paso S7, el receptor define los parámetros de la solicitud para que se encargue el servidor tomando en cuenta el resultado del cálculo del ancho de banda disponible y la variación de ancho de banda. De acuerdo con una modalidad de la invención, el receptor modifica el parámetro de velocidad de la solicitud RTSP de acuerdo con combinaciones de valores calculados del ancho de banda y variación. Por ejemplo, de acuerdo con una variante de la invención y en el caso de congestión de la red que puede llevar no sólo a una disminución en velocidad de transmisión, sino a pérdida de datos, el receptor lleva a cabo un nueva solicitud para recibir los datos perdidos en una versión correspondiente a una tasa de bits menor y una velocidad de transmisión aumentada. El uso de una tasa de bits menor y una velocidad de transmisión aumentada permite por un lado disminuir la cantidad de datos que transitan entre el servidor y el receptor, pero también compensa rápidamente la pérdida de tiempo que deriva de la perdida de datos previamente transmitidos por el servidor. De acuerdo con una modalidad de la invención, el receptor usa el número de secuencia del encabezado del paquete RTP que transporta datos para detectar la perdida de datos durante la transmisión de una porción del programa. La pérdida de datos y la obligación de retransmitir los datos tiene la consecuencia de disminuir la tasa de relleno del buffer de recepción y aumentar el riesgo de artefactos enlazados a una pérdida de datos en el buffer durante la restitución del programa. Favorablemente, el receptor entonces se encarga de una solicitud RTSP PLAY que indica una tasa de bits menor y un parámetro de velocidad mayor a 1 antes de reincorporar el algoritmo anteriormente descrito.

La figura 7 muestra un dispositivo de recepción 2 adaptado para la recepción y visualización de un programa audiovisual de acuerdo con una modalidad de la invención. Una interfaz de red bidireccional 201 permite la recepción que codifica el programa audiovisual recuperarse. La interfaz 201 también permite la transmisión y recepción de mensajes de control al y del servidor de difusión. Un demultiplexor 202 filtra los datos relacionados con la recepción de un programa desde el flujo de recepción así como mensajes de control y los almacena en un buffer de recepción 203. Los datos que codifican el programa audiovisual se leen por el decodificador de Audio/Video 204 que los decodifica y transmite las señales correspondientes a la interfaz de salida 205. Un dispositivo de visualización (no mostrado) y conectado a la interfaz de salida 205 permite la visualización del programa para el usuario. El conjunto de elementos 201 , 202, 203, 204 y 205 se controlan por la unidad de control 200 que contiene de acuerdo con una modalidad de la invención un microcontrolador y memorias asociadas que permiten la ejecución de rutinas de software así como el procesamiento de datos. La unidad de control 200 analiza además los mensajes de control en recepción desde el servidor y genera los mensajes de control transmitidos al servidor.

La figura 8 muestra la unidad de control 200 de acuerdo con una modalidad de la invención. La unidad de control comprende un microcontrolador 210 responsable para la ejecución de aplicaciones de software. El código ejecutable de aplicaciones se almacena en la memoria no volátil 21 1 en el inicio del receptor 2 y se puede copiar en la memoria de trabajo 212 cuando el receptor 2 es operacional. La memoria de trabajo 212 comprende una memoria de acceso aleatoria para el almacenamiento de datos específicos a la ejecución de aplicaciones de software y el almacenamiento de datos recibidos. La unidad de control 200 también comprende un módulo para la estimación de ancho de banda 213. El módulo de estimación de ancho de banda 213 calcula el ancho de banda disponible en el enlace entre el servidor y el receptor 2 por medio de datos leídos desde el buffer de recepción. El módulo de control RTSP 214 se compone de solicitud RTSP de acuerdo con el valor del ancho de banda calculado y disponible en el módulo de estimación 213. El módulo de control RTSP lee los datos que constituyen la respuesta a la solicitud RTSP PLAY en el buffer de recepción y comunica el marcador temporal rtptime al módulo de estimación 213. Los datos intercambiados entre los diferentes módulos de la unidad de control 200 transitan por medio del bus interno 216. El conjunto de datos se intercambia con los otros módulos funcionales del receptor se llevan a cabo por medio del módulo de interfaz 215.

La invención se describe aquí con una modalidad basada en los protocolos RTP y RTSP, pero la invención obviamente no se limita al uso de protocolos RTP y RTSP. La invención también concierne cualquier protocolo de transferencia en tiempo real y protocolo de control de servidor correspondiente con características similares que el RTP y RTSP respectivos y particularmente proporciona comandos de control como un comando PLAY con parámetros que permiten definir (seleccionar) una versión, un tiempo de inicio y una longitud (o un tiempo de detención) para la parte del programa audiovisual que se reproducirá (interpretará).

Claims (12)

REIVINDICACIONES

1. Método para la recepción de un programa audiovisual almacenado en un servidor para reproducirse en un dispositivo de visualización conectado a un receptor, dicho programa audiovisual está disponible en dicho servidor en por lo menos dos versiones, cada una de las versiones que comprende una sucesión de bloques de datos que representan partes de dicho programa audiovisual para que se interpreten en forma sucesiva, dichas versiones comprenden cada una un mismo número de bloques, los bloques inician cada uno con una imagen codificada sin referencia a una imagen previa, dicho método que comprende un paso de recepción en dicho nivel de receptor, de acuerdo con un protocolo de transporte, una primera porción de dicho programa audiovisual que comprende por lo menos un bloque de datos desde una primera de dichas versiones transmitida por dicho servidor en una primera tasa de bits, dicha primera porción es un subconjunto de un archivo en dicho servidor, dicho archivo que contiene una pluralidad de porciones, la posición de cada una de las porciones se indica en el archivo al indexarse, dicho método está caracterizado porque además comprende, en dicho nivel de receptor, los pasos de: determinar el ancho de banda después de la recepción de dicha primera porción de dicho programa audiovisual transmitido por el servidor en la primera tasa de bits, transmitir una solicitud, de acuerdo con un protocolo de control, al servidor, dicho protocolo de control se adapta al control de transmisión en tiempo real de un contenido por el uso de comandos y adaptado a la identificación en un archivo de una porción de datos que se transmitirán desde entre varias porciones de datos, dicha identificación se logra por medio de indexar, la solicitud comprende: información de identificación de una segunda porción de dicho programa audiovisual en una de las versiones de dicho programa de acuerdo con el valor determinado del ancho de banda entre el servidor y el receptor, dicha información de identificación que comprende marcadores temporales del inicio y fin de dicha segunda porción.

2. Método de conformidad con la reivindicación 1 , caracterizado porque dicha solicitud además comprende un parámetro de velocidad de transmisión.

3. Método para recepción de un programa audiovisual de conformidad con la reivindicación 1 o 2, caracterizado porque el paso de recepción usa el protocolo de transmisión RTP.

4. Método para recepción de un programa audiovisual de conformidad con cualquiera de las reivindicaciones de la 1 a la 3, caracterizado porque el paso de transmisión de una solicitud usa el protocolo de control RTSP.

5. Método para recepción de un programa audiovisual de conformidad con cualquiera de las reivindicaciones de la 1 a la 4, caracterizado porque las versiones de dicho programa audiovisual se comprenden en un mismo archivo almacenado en dicho servidor.

6. Método de conformidad con una de las reivindicaciones anteriores, caracterizado porque dicho programa audiovisual se asocia en dicho servidor con un archivo descriptivo que comprende información relacionada con la localización de dichas versiones de dicho programa audiovisual en el mismo archivo.

7. Método de conformidad con una de las reivindicaciones anteriores, caracterizado porque la determinación del ancho de banda disponible entre dicho servidor y dicho receptor comprende un análisis de por lo menos una característica de las porciones del programa audiovisual recibido en la primera tasa de bits.

8. Método de conformidad con la reivindicación 7, caracterizado porque por lo menos una característica de dichas porciones es el número de bits transmitido.

9. Método de conformidad con una de las reivindicaciones anteriores, caracterizado porque el paso de transmisión de una solicitud usa el comando PLAY del protocolo RTSP.

10. Método de conformidad con una de las reivindicaciones anteriores, caracterizado porque el paso de determinación del ancho de banda entre dicho servidor y dicho receptor usa la respuesta del servidor al comando PLAY del protocolo RSTP.

11. Dispositivo para recepción de un programa audiovisual difundido por un servidor, dicho programa está disponible en dicho servidor en por lo menos dos versiones, cada una de las versiones correspondientes a una resolución de imagen de dicho programa audiovisual y que comprende una sucesión de porciones, dichas versiones empiezan cada una con una intra-imagen, dicho dispositivo está caracterizado porque comprende; una interfaz de red para recepción, de acuerdo con un protocolo de transporte, de una primera porción de dicho programa audiovisual en una primera de dichas versiones difundida por dicho servidor en una tasa de bits; una unidad de control para determinar el ancho de banda después de la recepción de la primera porción de dicho programa audiovisual difundido por el servidor en una tasa de bits; una interfaz de red para transmitir una solicitud al servidor, de acuerdo con un protocolo de control, dicho protocolo de control se adapta al control de transmisión en tiempo real de un contenido por medio de comandos y adaptados a la identificación en un archivo de una porción de datos que se transmitirán de entre varias porciones de datos, dicha identificación se logra por medio de indexar, dicha solicitud comprende; información de identificación de una segunda porción de dicho programa audiovisual en una de las versiones de dicho programa de acuerdo con el valor determinado del ancho de banda entre dicho servidor y dicho receptor, dicha información de identificación que comprende marcadores temporales del inicio y final de la segunda porción.

12. Dispositivo de conformidad con la reivindicación 11, caracterizado porque la solicitud además comprende un parámetro de velocidad de transmisión.