ES2264584T3 - Transporte de datos. - Google Patents

Transporte de datos.

Info

Publication number
ES2264584T3
ES2264584T3 ES99949236T ES99949236T ES2264584T3 ES 2264584 T3 ES2264584 T3 ES 2264584T3 ES 99949236 T ES99949236 T ES 99949236T ES 99949236 T ES99949236 T ES 99949236T ES 2264584 T3 ES2264584 T3 ES 2264584T3
Authority
ES
Spain
Prior art keywords
data
sequence
package
packet
packages
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES99949236T
Other languages
English (en)
Inventor
David Dalby
John Martin O'donnell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Application granted granted Critical
Publication of ES2264584T3 publication Critical patent/ES2264584T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Photoreceptors In Electrophotography (AREA)
  • Magnetically Actuated Valves (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)
  • Time-Division Multiplex Systems (AREA)

Abstract

Aparato de transmisión de datos que comprende: (a) una entrada de datos (115) dispuesta para recibir unas tramas de datos codificadas por un algoritmo de codificación estratificada; (b) unos medios de paquetización (120) para insertar las tramas de datos recibidas, así codificadas, en una o más estructuras de paquetes predeterminadas, estando insertadas las tramas de datos asociadas con cada capa codificada en una secuencia de paquetes respectiva diferente; y (c) una interfaz de red (135) dispuesta para trasmitir, en uso, los paquetes así creados; caracterizado porque presenta (d) unos medios de numeración de paquetes (125) para asignar un número de secuencia de datos (XSEQ) a cada paquete generado por los medios de paquetización, estando asignados los números de secuencia de datos a los paquetes indicativos del orden de recepción, en la entrada de datos, de datos codificados insertados en el paquete; estando dispuesta la interfaz de red (135) para transmitir, en uso, los números de secuencia de datos asignados junto con dichos paquetes.

Description

Transporte de datos.
La presente invención se refiere al transporte de datos a través de redes de comunicaciones, en particular a la transferencia de datos codificados mediante algoritmos de codificación estratificada.
Las redes basadas en el Protocolo Internet (IP) están siendo utilizadas de forma creciente para canalizar transmisiones de datos multimedia, permitidas mediante la utilización de algoritmos de compresión para reducir los volúmenes de datos a niveles suficientemente bajos para transportarlos a través de conexiones de red de velocidades de transferencia de datos relativamente bajas. No obstante, siguen existiendo problemas que deben superarse para conseguir la distribución de servicios multimedia, por ejemplo servicios audiovisuales, a un gran número de terminales de clientes que presentan una variedad de capacidades diferentes para recibir tales servicios. En particular, algunos clientes pueden disponer de acceso únicamente a conexiones de red de velocidad de transferencia de datos limitada, que sólo permiten la recepción de vídeo de baja resolución y de baja velocidad de transmisión de imágenes. Otros usuarios pueden conectarse a redes de área local (LAN) corporativas de anchos de banda relativamente elevados y piden una recepción de calidad superior. Los procedimientos conocidos para suministrar diferentes niveles de servicio a usuarios distintos comprenden servicios punto a punto mediante los cuales se transmite una versión adaptada de una sesión directamente a cada usuario por separado, a su dirección de red, y técnicas de "difusión simultánea" en las cuales se difunden varias transmisiones a diferentes velocidades de transferencia de datos y los usuarios pueden seleccionar y compartir la más adecuada a sus necesidades. No obstante, tanto las técnicas punto a punto como las de difusión simultánea implican una superposición y duplicación de datos importante entre los flujos de datos transmitidos y son claramente ineficaces en lo que se refiere a su consumo y capacidad de red.
Las técnicas de codificación estratificada tales como la implementada, por ejemplo, bajo el estándar H.263 para compresión de datos de vídeo, definida en "Video Coding for Low Bit Rate Communications", International Telecommunication Union (ITU) - Recomendación T H.263, Enero 1998, permite codificar datos que representan diferentes resoluciones de vídeo como capas separadas de tramas de datos. En la capa inferior, capa 0, puede disponerse una codificación de "mínimo común denominador". Las tramas comprendidas en la capa 0 pueden proporcionar una representación de las imágenes originales de resolución relativamente baja, no necesariamente de todas las imágenes originales. Las tramas de datos de las capas superiores pueden añadir niveles crecientes de detalle a las representaciones de las tramas de la capa inferior o pueden codificar imágenes omitidas por las capas inferiores en conjunto. Cada capa de tramas de datos codificadas puede ser difundida separadamente por un servidor, cada capa a una dirección de red multidistribución diferente. Se pretende que la mayoría de equipos de usuarios puedan ser capaces de recibir la capa inferior 0 accediendo a la dirección multidistribución adecuada para la capa 0. Los usuarios que lo selecciona, o que disponen de capacidad de equipo para recibir las capas superiores pueden acceder a una o más de las direcciones de red correspondientes, para gozar de una mayor calidad del servicio audiovisual. Des este modo, pueden satisfacerse necesidades de clientes dispares mediante una única difusión de cada capa sin una duplicación innecesaria de datos.
Cuando se utilizan técnicas multidistribución en relación con redes IP, un protocolo actualmente preferido para transportar capas de tramas de datos codificadas es el Protocolo de Datagramas de Usuario (UDP) tal como se define en "User Datagram Protocol", Internet RFC768, J.Postel, Agosto 1980, publicado en Internet por e Internet Engineering Task Force (IETF). No obstante, aunque el UDP ofrece un procedimiento más rápido para enviar mensajes con un mínimo de mecanismo de protocolo, en comparación con el Protocolo de Control de Transmisión (TCP), por ejemplo, esto se consigue a expensas de la garantía de recepción. Pueden perderse datos, a lo mejor en una extensión tal, que una capa puede perderse durante la transferencia a través de una red, o por lo menos demorarse respecto a otras capas. Por lo tanto, además de efectuar la opción de no recibir una capa superior de datos codificados, existen motivos involuntarios por lo cuales un aparato cliente puede no recibir toda la difusión de datos codificados en una sesión. En ambas circunstancias, pueden surgir problemas para el aparato del cliente al presentar los datos recibidos a un descodificador en el orden correcto de descodificación.
En Jau-Shiung Huang et al.: "MHTP - A Multimedia High-Speed Transport Protocol", de GLOBECOM '92, Orlando-Communication for Global Users, Dic 6-9, 1992, Volumen 3, 6 de Diciembre de 1992, páginas 1364-1368, XP000390432IEEE, se describe un protocolo (MHTP) que permite gestionar la numeración de secuencias de paquetes y la ordenación de paquetes dentro de cada uno de diversos subprotocolos, cada uno de los cuales puede utilizarse para transferir una capa separada de datos codificados multicapa. No obstante, el MHTP no resuelve el problema de cómo presentar al descodificador en el orden correcto para descodificación paquetes recibidos, seleccionados a través de diversas capas de subprotocolos.
En "An Efficient Loss-Priority Scheme for MPEG-2 Variable Bit Rate Video for ATM Networks", Wilson, D. y Ghanbari, M., IEEE 1996, Essex University, se describe una técnica para generar una capa de optimización que comprende sólo tramas B, aunque dependiendo de la coordinación relativamente correcta de la capa base y la capa de optimización mantenida durante la transmisión para asegurar el orden correcto de presentación de tramas codificadas al descodificador. Cualquier variación de la demora esperada entre la recepción de una primera trama codificada de la capa base y la primera de la capa de optimización, por ejemplo, no podría corregirse antes de la descodificación.
En el RFC 1693 de Internet: "An Extension to TCP: Partial Order Service", Noviembre 1994, se describe una extensión del TCP para transmitir un perfil de servicio durante el establecimiento de la conexión, definiendo un orden aceptable de recepción de los objetos transmitidos. El perfil del servicio comprende una matriz de ordenación parcial que define un orden aceptable para objetos numerados, permitiendo que un receptor ordene tales objetos en la extensión definida en el perfil, aunque pueda producirse una pérdida o demora excesiva en la recepción de determinados objetos. No obstante, la sobrecarga de definir y transmitir perfiles de servicio antes de enviar datos incrementa la complejidad del aparato de transmisión y recepción e introduce una demora adicional.
Según una primera forma de realización de la presente invención, se dispone un aparato de transmisión de datos que presenta:
una entrada de datos dispuesta para recibir tramas de datos codificadas por un algoritmo de codificación estratificada;
unos medios de paquetización para insertar las tramas de datos recibidas, así codificadas, en una o más estructuras de paquetes predeterminadas, estando insertadas las tramas de datos asociadas con cada capa codificada en una secuencia de paquetes respectiva diferente;
unos medios de numeración de paquetes para asignar un número de secuencia de datos a cada paquete generado por los medios de paquetización, siendo los números de secuencia de datos asignados a los paquetes indicativos del orden de recepción, en la entrada de datos, de datos codificados insertados en el paquete;
estando dispuesta la interfaz para transmitir, en uso, los números de secuencia de datos asignados junto con dichos paquetes; y
una interfaz de red dispuesta para trasmitir, en uso, los paquetes así creados;
La presente invención permite la asignación de un número de secuencia a cada paquete de datos que transporta datos codificados, representativo del orden correcto de la posterior presentación de los datos codificados a un descodificador. Este número de secuencia permite ordenar correctamente los paquetes recibidos en un aparato cliente, aunque el aparato cliente no reciba todas las capas transmitidas de paquetes o se pierdan paquetes individuales. Esto es particularmente importante cuando se utilizan algoritmos de codificación diferenciales tales como los definidos en el estándar H.263.
Los codificadores diferenciales tales como los que implementa el estándar H.263 generan flujos de datos estratificados que presentan cada uno una velocidad de transmisión de datos muy variable. La cantidad de datos requeridos para codificar cada una de las secuencias de imágenes difiere según el grado de variación entre imágenes sucesivas. En general, el orden de salida de tramas codificadas por un codificador es el orden requerido para entrar en el descodificador. No obstante, si durante el transporte del codificador al descodificador una capa se pierde o se retrasa de forma importante respecto a otra, o si se pierden paquetes específicos, surgen problemas en el equipo de recepción al presentar los datos recibidos para un descodificador en el orden de descodificación correcto. Por lo tanto, aunque la utilización de codificación multiestratificada parece solucionar el problema de adaptación a las diferentes necesidades de los clientes, surgen nuevos problemas al descodificar transmisiones multiestratificadas.
Preferentemente, puede asignarse otro número de secuencia a cada paquete que presente el orden de transmisión del paquete, bajo control de un protocolo seleccionado, dentro de una secuencia de paquetes que transportan una capa específica de tramas de datos codificadas. Este número de secuencia puede utilizarse para mejorar la eficacia de ordenación de los paquetes al identificar si se han recibido todos los paquetes esperados dentro de una secuencia de paquetes específica y si el siguiente paquete para descodificar se encuentra en otra secuencia de paquetes.
Según un segundo aspecto de la invención, se dispone un aparato cliente que presenta:
una interfaz de red;
unos medios de recepción de paquetes para recibir una o más secuencias de paquetes de datos de la interfaz de red, presentando cada paquete de datos una estructura de paquetes predeterminada, transportando cada una de dichas una o más secuencias de paquetes de datos una capa respectiva diferente de tramas de datos codificadas generadas por un algoritmo de codificación estratificada y habiendo sido asignada a cada paquete de datos un número de secuencia de datos indicativo del orden de salida de datos codificados, transportados por el paquete de datos a partir de dicho algoritmo de codificación;
unos medios de ordenación de paquetes para colocar dichos paquetes de datos recibidos en un orden de descodificación utilizando dichos números de secuencias de datos; y
unos medios de emisión para emitir los paquetes así ordenados.
Según un tercer aspecto de la presente invención, se dispone un procedimiento de generación de paquetes de datos para transportar tramas de datos codificadas mediante un algoritmo de codificación estratificada para transmisión a través de una red de comunicaciones, siendo transportada cada capa de tramas de datos codificadas por una secuencia diferente respectiva de paquetes de datos, comprendiendo las etapas siguientes:
(1) recibir una trama de datos codificada;
(2) insertar datos de dicha trama de datos en uno o más paquetes de datos generados según una estructura de paquetes predeterminada;
(3) asignar, con respecto a uno de dichos uno o más paquetes de datos, un número de secuencia de datos indicativo del orden de recepción de los datos codificados insertados en dicho paquete;
(4) inscribir dicho número de secuencia de datos en una posición predeterminada dentro de dicho paquete; y
(5) realizar las etapas (3) y (4) respecto de cada uno de dichos uno o más paquetes de datos generados en la etapa (2).
Según un cuarto aspecto de la presente invención, se dispone un procedimiento de ordenación de los paquetes de datos recibidos en una o más secuencias de paquetes de datos accesibles separadamente generadas según el procedimiento de la reivindicación 5, incluyendo las etapas siguientes:
(1) recibir uno o más paquetes de datos en una o más de dichas secuencias de paquetes de datos accesibles separadamente;
(2) seleccionar, entre los paquetes de datos recibidos en la etapa (1), el paquete de datos que presenta el número menor de secuencia de datos asignado entre los paquetes de datos no seleccionados;
(3) emitir dicho paquete de datos seleccionado;
(4) repetir las etapas (1) a (3).
A continuación se describirá la invención con mayor detalle, únicamente a título de ejemplo, con consideración conjunta de los dibujos adjuntos, en los cuales:
la figura 1 muestra un aparato de transmisión de vídeo según formas de realización preferidas de la presente invención;
la figura 2 muestra un aparato cliente dispuesto para recibir señales transmitidas por el aparato de la figura 1;
la figura 3 muestra una jerarquía corriente de tramas de datos estratificadas, codificadas a partir de una pequeña secuencia de imágenes de vídeo, para transmisión mediante el aparato de la figura 1;
la figura 4 muestra el resultado de la aplicación de un algoritmo de numeración de paquetes, según una forma de realización preferida de la presente invención, a paquetes generados para transportar tramas de datos codificadas mostradas en la figura 3;
la figura 5 muestra la estructura de una cabecera de paquete según el Protocolo de Transporte en Tiempo Real (RTP) utilizado en una forma de realización preferida de la presente invención; y
la figura 6 es un diagrama de flujo que muestra las etapas operativas en un aparato cliente preferido, particularmente respecto a la ordenación de paquetes difundidos por el aparato de la figura 1.
A continuación se describen formas de realización preferidas de la presente invención en el contexto particular de un aparato de flujo de vídeo, aunque la presente invención puede aplicarse a otras formas de aparatos de difusión y recepción de datos, no necesariamente en una disposición de servidor cliente, implicadas en una sesión individual o multimedia con datos codificados por técnicas de codificación estratificada.
Con referencia a la figura 1, se muestra un aparto de flujo de vídeo 100, según formas de realización preferidas de la presente invención, para utilización en la difusión de datos audiovisuales codificados multicapa desde una fuente de datos de audio/vídeo 105 a un sistema cliente a través de una red de comunicaciones 110. La fuente de datos de audio/vídeo 105 puede ser, por ejemplo, una base de datos de datos de vídeo codificados para su utilización en un sistema de "vídeo a la carta", o puede ser un flujo de datos audiovisuales en tiempo real codificados multicapa que deben transmitirse como retransmisión en directo. El aparato de flujo de vídeo 100 acepta capas de datos codificados de la fuente 105 en una entrada 115 antes de pasarlos al paquetizador 120. El paquetizador 120 puede implementar un algoritmo conocido para incorporar separadamente datos de cada capa de datos codificados en un flujo respectivo diferente de paquetes según una o más estructuras de paquetes predeterminadas. Por ejemplo, pueden incorporarse una o más capas en paquetes que presentan una estructura definida por la utilización con el Protocolo de Transporte en Tiempo Real (RTP) descrito por Internet Request for Comment (RFC) 1889, Enero 1996 - RTP: A Transport Protocol for Real-Time Applications'' de H.Schulzrinne, S.Casner, R.Frederick y V.Jacobson, y publicado en Internet por Internet Engineering Task Force (IETF). Una vez dispuestos según su respectiva estructura de paquetes predeterminada, las capas de paquetes pasan a un módulo de numeración de paquetes 125 para ser numeradas por un procedimiento de numeración de paquetes según una forma de realización preferida de la presente invención. A continuación, los paquetes numerados pasan a fases del manejador de sesiones 130 por capa de paquetes. Cada fase del manejador de sesiones 130 puede implementar un protocolo adecuado para controlar la transferencia de la capa de paquetes respectiva a través de la red de comunicaciones 110, por una interfaz de red 135, a una o más direcciones de red predeterminada, por ejemplo direcciones multidistribución. Los protocolos que operan a niveles inferiores en una jerarquía de protocolo pueden ser implementados por la interfaz de red 135 en una forma adecuada a la red de comunicaciones 110. Por ejemplo, en el nivel debajo del RTP, el Protocolo de Datagramas de Usuario (UDP) referenciado anteriormente puede ser implementado por la interfaz de red 135 para operar en conjunción con el Protocolo Internet (IP).
Preferentemente, por razones de simplicidad, todas las capas de datos codificados pueden difundirse bajo el control, en el nivel de sesión por lo menos, de fases respectivas del mismo protocolo utilizando la misma estructura de paquetes. No obstante, el ámbito de la presente invención prevé rodear estas situaciones en las cuales se utiliza más de un tipo de protocolo para difundir capas de datos codificados recibidos en la entrada 115.
Con referencia a la figura 2, se muestra un aparato cliente corriente 200 para utilización en la recepción, a través de la red de comunicaciones 110, de transmisiones de audio y/o vídeo por una o más fuentes que presentan características comunes con el aparato de flujo de vídeo 100 de la figura 1. El aparato cliente 200 puede crear fases de un manejador de sesión 210, "escuchando" cada fase del manejador de sesiones 210 los datos recibidos en una dirección de red específica, correspondiendo una fase a cada capa de paquetes recibidos a través de la red por una interfaz de red 205. Las capas de paquetes recibidas pasan desde sus respectivos manejadores de sesiones 210 a un desmultiplexor de fuentes 215. En el caso de que transmisores de vídeo múltiples u otros tipos de fuente se transmitan en la misma sesión, cada fuente puede preferentemente ser identificable separadamente por el desmultiplexor de fuentes 215 utilizando información insertada en cabeceras de paquete por el transmisor fuente respectivo. Para cada fuente distinta identificada, el desmultiplexor puede crear una fase de un mezclador 220, recopilando todos los paquetes recibidos a través de los manejadores de sesión 210 que llevan el mismo identificador de fuente, y pasando los paquetes recopilados al mezclador 220. El mezclador 220 puede implementar un algoritmo, según formas de realización preferidas de la presente invención, para ordenar paquetes recibidos de la fuente específica que utiliza la información de numeración de paquetes insertada por el módulo de numeración de paquetes 125 de la fuente respectiva, por ejemplo el transmisor de vídeo 100. Una vez establecido el orden de paquetes correcto, teniendo en cuenta cualesquiera paquetes y capas perdidos o inaccesibles, el mezclador 220 puede pasar los paquetes ordenados a un despaquetizador 225 para recuperar las capas de datos codificados de la estructura de paquetes predeterminada respectiva utilizada por la fuente transmisión específica, por el paquetizador 120 en el caso de un transmisor de vídeo 100.El despaquetizador 225 pasa los datos codificados recuperados, ahora en la secuencia correcta para la descodificación, a una salida 230. La salida de datos ordenados del aparato cliente 200 puede ser recogida por un descodificador adecuado u, después de la descodificación, reproducida en una pantalla y/o en un aparato con salida de audio
adecuado.
Con referencia a la figura 3, se muestra una jerarquía corriente de tramas de datos estratificadas, codificadas a partir de una pequeña secuencia de imágenes de vídeo, como podría presentarse en la entrada 115 de un transmisor de vídeo 100. Las tramas codificadas 340 se muestran dispuestas en tres capas, 300, 305 y 310 correspondientes a la capa inferior, una capa media y una capa superior respectivamente. Pueden generarse otras capas según un algoritmo específico implementado por la fuente 105. Cada trama codificada 340 de la figura 3 se muestra con un número de un rango entre 1 y 10, que indica el orden de salida de la fuente de datos codificados 105 y, por lo tanto, el orden requerido para la posterior presentación de tramas al descodificador. Las tramas 340 de la figura 3 se muestran agrupadas dentro de cinco columnas, estando codificada cada columna de tramas para representar una imagen original respectiva 315-335. Por ejemplo, la imagen original "A" 315 se muestra codificada como un número de trama "1" en la capa inferior 300, una trama "2" en la capa media 305 y una trama 3 en la capa superior 310. La imagen original "B" 320 está representada solamente en la capa superior 310 por una trama generada con un número "4". Los datos de la imagen original 315-335 normalmente no se presentarían en la entrada 115 de un aparato de transmisión de vídeo 100.
La secuencia de tramas codificadas 1-10 de la figura 3 puede, por ejemplo, generarse según un algoritmo de codificación de vídeo tal como H.263, citado anteriormente. Si se utiliza la técnica de codificación H.263 para codificar las imágenes 315-335 de la figura 3, cada trama 340 de la capa inferior 300 puede representar una versión de baja resolución de la imagen original respectiva y puede codificarse utilizando el algoritmo H.263 básico a la resolución QCIF, como se describe en la sección 4.1 de la especificación citada. Las tramas de las capas 305 y 310 representan optimizaciones cada vez más detalladas de la imagen de baja resolución representada por la trama respectiva en una capa 300. Bajo H.263, pueden codificarse las capas media y superior según la definición del Anexo O, "Temporal, SNR and Spatial Scalability Mode", de la especificación H.263 anteriormente citada.
No todas las imágenes originales pueden representarse en las capas inferiores 300, 305. En la secuencia particular mostrada en la figura 3, en la capa inferior 300 sólo se representa una de cada cuatro imágenes, y en la capa media 305 una de cada dos. Por lo tanto, un aparato cliente capaz de seleccionar la descodificación de sólo la capa inferior de tramas visualizará una representación de la secuencia original de imágenes con una resolución relativamente baja y una velocidad de transmisión de imágenes relativamente reducida, en comparación con un aparato cliente capaz de seleccionar la descodificación de ambas capas, media e inferior, Los aparatos capaces de recibir y descodificar las tres capas de difusión 300-310 podrán visualizar todas las imágenes originales (315-335) a la máxima resolución disponible. Se pretende que pueda utilizarse una conexión de red de baja velocidad de transmisión de datos para recibir tramas de datos en la capa inferior, haciendo esta capa accesible a la mayoría de los equipos cliente.
Con referencia a la figura 4, se presenta un diagrama que muestra una descomposición habitual de estas tramas codificadas 340, que representa las tres primeras imágenes originales 315, 320 y 325 de la figura 3, a través de la secuencias correspondientes de paquetes 400 estratificadas por el paquetizador 120. La figura 4 también muestra el resultado de la aplicación de un esquema de numeración de paquetes a esos paquetes que tal como puede ser implementado por el módulo de numeración de paquetes 125 según formas de realización preferidas de la invención. Un paquetizador corriente 120 puede paquetizar cada capa de tramas codificadas separadamente, generando, como en el ejemplo presente, tres flujos de paquetes separados, uno para cada trama. Como se ha mencionado en relación con la figura 1 anteriormente, el paquetizador 120 puede disponerse para implementar una o más estructuras de paquetes adecuadas a un protocolo específico seleccionado en el nivel de sesión para controlar el transporte de cada capa e datos codificados. Preferentemente, cada capa de datos codificados puede transportarse a través de una red que utiliza una fase respectiva diferente de un Protocolo de transporte en Tiempo Real (RTP) citado anteriormente. El paquetizador 120¸ en este caso, dividiría los datos del interior de una capa de tramas codificadas 340 a través de las partes de carga útil de una secuencia de paquetes RTP, según la definición de estructura de paquetes RTP. Convenientemente, si se paquetizan datos utilizando el algoritmo H.263 citado anteriormente, se encuentra disponible una definición específica de una cabecera de carga útil H.263 para inclusión en paquetes RTP tal como se define en "RTP Payload Format for H.263 Video Streams", Internet RFC 2190, Septiembre 1997, publicado en Internet por IETF, Pueden seleccionarse protocolos a nivel de sesión alternativos e igualmente satisfactorios para su implementación por el paquetizador 120, utilizando sus propias estructuras de paquetes respectivas para transportar las capas codificadas 300-310 de tramas de datos 340.
Con referencia a la figura 4, como se ha indicado anteriormente, cada uno de los paquetes 400 se muestra etiquetado con números de secuencia aplicados por un módulo de numeración de paquetes 125. Un procedimiento preferido de numeración implica la asignación de dos números de secuencia a cada paquete 400. El número que se muestra en la mitad superior de cada paquete 400 de la figura 4 puede denominarse "número de secuencia de capa" LSEQ, mientras que el número que aparece en la mitad inferior de cada paquete puede denominarse "Número de secuencia de capa cruzada" XSEQ. La secuencia de números LSEQ indica el orden de transmisión de paquetes dentro de una capa específica. Los números XSEQ pretenden representar el orden global correcto para la presentación de los datos codificados transportados por esos paquetes a un descodificador 225 de un aparato cliente 200. La secuencia XSEQ refleja, en particular, el orden en que los datos codificados salen de la fuente 105.
Los protocolos tales como el RTP proporcionan una herramienta para asignar números de secuencia a paquetes dentro de un flujo de paquetes RTP particular. En este caso, cada capa de datos codificados puede difundirse como flujo de paquetes RTP separado bajo el control de una sesión RTP diferente. Por lo tanto, dentro de una capa, el manejador de sesiones respectivo (RTP) 130 puede asignar automáticamente un número de secuencia LSEQ a cada paquete antes de su transmisión y escribir el número de secuencia en una posición predeterminada con el paquete. Otros tipos de protocolos no pueden proporcionar una herramienta de esta clase para asignar números de secuencia de capa. Por lo tanto, el módulo de numeración de paquetes 125 puede implementar tanto la asignación de números de secuencia de capa como la asignación de números de secuencia de capa cruzada si es necesario.
Con capas diferentes difundidas normalmente bajo el control de sesiones de protocolo separadas, como con RTP, no existe ningún mecanismo global para asignar número XSEQ a través de capas. Para asignar una secuencia de números XSEQ en particular, el módulo de numeración de paquetes 125 puede disponerse en un punto inmediatamente siguiente al paquetizador 120 e inmediatamente antes de que los flujos de paquetes individuales vayan a sus respectivos manejadores de sesiones 130 para su difusión. Si en necesario, el módulo de numeración de paquetes 125 puede retener el acceso a la información sobre el orden de recepción de las tramas de datos codificadas en la entrada 115 para asignar correctamente los números XSEQ a los paquetes que salen del paquetizador 120. Es particularmente importante, cuando se codifican datos utilizando un algoritmo de codificación diferencial tal como el definido por H.263, descodificar posteriormente estos datos en la secuencia correcta. La asignación de un número XSEQ por el módulo de numeración de paquetes 125 proporciona un procedimiento especialmente adecuado de registro de la secuencia de datos correcta e nivel de paquetes. La pérdida de datos o la reordenación de datos se producen normalmente a nivel de paquetes. Como se mencionará más adelante, el registro de un número de secuencia de capa LSEQ y, en particular, de un número de secuencia de capa cruzada XSEQ, permite al aparato cliente 200, según formas de realización preferidas de la presente invención, reordenar paquetes recibidos fuera de secuencia y tomar en consideración los paquetes perdidos y las capas de datos codificados perdidas o inaccesibles.
Con referencia a la figura 5, se muestra la estructura de encabezamiento de paquete definida para su utilización en RTP. La estructura de paquetes RTP puede utilizarse mediante formas de realización preferidas de la presente invención para registrar números de secuencia de paquetes. La figura 5a muestra la estructura de cabecera RTP, incluyendo una Extensión de Cabecera RTP opcional, mientras que la figura 5b muestra la estructura de la propia extensión de cabecera, todos los detalles de la cual se describen en el documento de definición RTP citado anteriormente. La cabecera de paquete RTP de la figura 5a comprende un campo de Número de Secuencia que ocupa el tercer y cuarto octetos. Este campo se utiliza dentro el protocolo RTP para registrar el orden de transmisión de los paquetes dentro del flujo específico de paquetes y por lo tanto puede desempeñar la función del número de secuencia de capa LSEQ.
Para alojar el número de secuencia cruzada XSEQ, el módulo de numeración de paquetes 125 puede utilizar preferentemente la extensión de cabecera RTP opcional mostrada en la figura 5a en una posición inmediatamente siguiente a los "identificadores de Fuentes Contribuyentes (CSRC)". Con esta intención, el paquetizador 120 puede ajustar el bit de extensión "X" -bit 4 de la cabecera RTP- e incluir una extensión de Cabecera de Paquete RTP, que presenta la estructura mostrada en la figura 5b, dentro de cada paquete generado. Con cada paquete, el paquetizador 120 puede registrar un único identificador de perfil específico dentro del campo "perfil" de la extensión de cabecera y puede ajustar el campo "longitud" a 1, incluyendo un campo de "extensión de cabecera" de 32 bits. Esta longitud de extensión sería adecuada para utilizarla para registrar números XSEQ generados dentro de una sesión multimedia habitual. El módulo de numeración de paquetes 125 puede escribir a continuación un número XSEQ adecuado dentro del campo de extensión de cada paquete recibido del paquetizador 120.
Mientras que la estructura de paquetes RTP comprende campos adecuados para registrar números de secuencia asignados, otros protocolos y estructuras de paquetes no pueden disponer posiciones predeterminadas dentro de sus paquetes para llevar información de números de secuencia. En caso necesario, el paquetizador 120 debe generar uno o más flujos de datos de paquete adicionales para transmitirlos aproximadamente en sincronización con otros flujos de paquetes, para transportar información de numeración de secuencias asignada por el módulo de numeración de paquetes 125 y enlazada, por ejemplo mediante un identificador de paquetes, con paquetes que llevan datos codificados. Al recibir el "flujo de paquetes de números de secuencia", un aparato cliente puede extraer y utilizar la información de numeración de secuencias en gran parte del mismo modo descrito a continuación.
Como se ha mencionado anteriormente en relación con la identificación de una fuente transmisora por el desmultiplexor de fuentes 215 de un aparato cliente 200, por ejemplo cuando múltiples transmisores de vídeo 100 están transmitiendo paquetes RTP a través de la red de comunicaciones 110, el campo "SSCR" de la cabecera RTP de la figura 5a puede ser utilizado por un manejador de sesiones RTP 130 para registrar dentro de cada paquete RTP un identificador para el transmisor de vídeo específico 100 que genera el paquete. El desmultiplexor de fuentes 215 de un aparato cliente 200 puede leer a continuación el campo SSCR en los paquetes recibidos para distinguir entre paquetes de un transmisor de vídeo y de otro.
Con referencia a la figura 6, se presenta un diagrama de flujo que muestra una secuencia de etapas de funcionamiento de una fase de un mezclador 220 referida a la ordenación de paquetes, recibidos de un transmisor específico 100, numerados por un módulo de numeración de paquetes 125, según formas de realización preferidas de la presente invención. Preferentemente puede ajustarse un valor "CAPA_SUPERIOR" a un valor predeterminado en un aparato cliente específico 200, para registrar la capa con la numeración superior que el aparato específico está ajustado para recibir y descodificar, ya sea por selección o limitada por la capacidad del equipo o ancho de banda de la conexión de red. El valor "CAPA_SUPERIOR" puede ajustarse dentro del rango de 0 a n, siendo n la capa con numeración superior transmitida por las fuentes de transmisión de datos accesibles a través de la red 110.
Con referencia a la figura 6, puede apreciarse que el procesamiento con el mezclador 220 empieza en la Etapa 600. En la Etapa 602, se realiza una etapa de procesamiento previo en los paquetes ya recibidos para colocarlos en el orden de número de secuencia (LSEQ) dentro de su capa respectiva. La ordenación de los paquetes por el número LSEQ puede implementarse mediante un algoritmo sencillo y conocido y, por lo tanto, en esta memoria no se especificarán detalles adicionales de la Etapa 602.
En la Etapa 605, el mezclador 220 lee el paquete recibido en la capa 0 (PKT[0]) y utiliza el número de secuencia de capa (LSEQ) y el número de secuencia de capa cruzada (XSEQ) contenidos en el paquete para inicializar los contadores LPROG[] y XPROG respectivamente para utilizarlos en la determinación del siguiente número esperado en cada una de las secuencias de numeración de paquetes. En la Etapa 610, se inicializan variables preparadas para procesar paquetes de la capa seleccionada actualmente, inicialmente la capa 0. En la Etapa 615, se realiza un intento de leer el paquete que presenta el número de secuencia de capa inferior (LSEQ) de la capa (L) que esta siendo procesada actualmente (inicialmente capa L = 0). Los paquetes ya recibidos, a tiempo para la operación de la Etapa 602, habrán sido ordenados por número de secuencia de capa de modo que, entre los ya recibidos, pueda suponerse que el paquete siguiente leído de la capa L presenta el número LSEQ inferior. Si en la Etapa 620, en la capa L se encuentra disponible un paquete, en la Etapa 625, el número de secuencia de capa cruzada (XSEQ) de este paquete se compara con el número de secuencia de capa cruzada siguiente esperado. Si en la Etapa 625, el paquete actual es el siguiente de la secuencia de capa cruzada, en la Etapa 660, los números de secuencia del paquete actual se utilizan para ajustar las variables de contador XPROG y LPROG[L] antes de que, en la Etapa 665, este paquete sea reenviado al descodificador 225.
Si en la Etapa 620, no existen ningún paquete disponible en la capa actual, en la Etapa 675 se coloca un señalizador para indicar que no hay paquetes disponibles en una capa y el procesamiento pasa a la Etapa 640 para permitir el acceso a capas superiores para buscar paquetes.
Si en la Etapa 625 el paquete actual no es el siguiente de la secuencia de capa cruzada, o bien el paquete siguiente esperado se ha perdido dentro de la capa actual, o está en otra capa. La secuencia de etapas siguiente intenta establecer si el paquete esperado para descodificar siguiente se encuentra actualmente perdido -posiblemente en demora- dentro de la capa actual o si puede encontrarse en otra capa accesible. Por lo tanto, en la Etapa 630, el mezclador 220 primero comprueba si el paquete actual es el paquete siguiente esperado dentro de la capa actual (L). En caso contrario, en la Etapa 670 se coloca un señalizador para indicar que el paquete actual se encuentra fuera de secuencia en sus capas antes de que el procesamiento continúe con la Etapa 635. Si en la Etapa 630 el paquete actual era el próximo paquete esperado en su capa, el paquete que presenta el número XSEQ siguiente esperado debe encontrarse en otra capa. No obstante, en el caso de que se descubra pronto que el paquete no se encuentra en una capa accesible por el aparato cliente 200, o que se ha perdido de otro modo (en la Etapa 670), en la Etapa una variable que registra el número XSEQ inferior encontrado recientemente se actualiza junto con la capa en la cual se encontró el paquete respectivo. Este será el punto de continuación del procesamiento si el paquete con el número XSEQ siguiente esperado no se encuentra en ninguna de las capas accesibles. Pero primero se comprueban todas las demás capas accesibles.
El número de capa se incrementa en la Etapa 640. Si la nueva capa actual se encuentra en le número de capa máximo accesible al aparato cliente en la Etapa 645 o por debajo de él, el procesamiento vuelve a la Etapa 615 y se succiona el paquete siguiente esperado al interior de esta capa tal como se ha descrito anteriormente. No obstante, si en la Etapa 645, la nueva capa actual es inaccesible, en la Etapa 650, se realiza una comprobación para determinar si actualmente hay paquetes no disponibles en alguna capa. Si en la Etapa 650 una o más capas no han recibido paquetes disponibles, el procesamiento vuelve a iniciarse en la Etapa 610, volviendo a buscar el paquete siguiente esperado, empezando en la capa 0. Si en la Etapa 650 todas las capas presentan por lo menos un paquete disponible, en la Etapa 652 se determina si el paquete actual es o no el paquete siguiente esperado dentro de su capa. Si en la Etapa 652 el paquete actual está ordenado correctamente dentro de su capa, el paquete siguiente esperado en el orden XSEQ debe encontrarse en una capa superior, una capa que no es accesible al aparato cliente específico 200. Por lo tanto, lo mejor que puede hacerse es seleccionar el paquete con el número XSEQ inferior de cualquier capa. Por lo tanto, en la Etapa 655, se selecciona la capa que presenta el paquete con el número XSEQ inferior como nueva capa actual, y este paquete seleccionado se trata como siguiente paquete disponible para descodificar. Los contadores de números de secuencia XPROGR y LPROG[L] se ponen a cero para los valores de paquete actual en la Etapa 660 y en la Etapa 665 se envía el paquete selecciona para descodificación.
Si en la Etapa 652 el paquete actual estaba fuera de secuencia dentro de su capa, en la Etapa 680, el mezclador 220 puede elegir opcionalmente esperar que llegue el paquete o los dos paquetes siguientes a esta capa por ejemplo, en el caso de que el paquete siguiente esperado dentro de la capa llegue (en cuyo caso el procesamiento se reiniciará en la Etapa 610) o continuar sin más demora con la Etapa 685 y seleccionar la capa que presenta el paquete con el número XSEQ inferior como nueva capa actual, y seleccionar este paquete como siguiente paquete disponible para descodificación, procediendo a la Etapa 660.
Después de enviar un paquete para descodificación en la Etapa 665, el procesamiento vuelve a la etapa 610, restaurando las variables relacionadas con el procesamiento fuera de secuencia y restaurando el número de capa L a 0, antes de continuar como se ha descrito anteriormente.
Resulta evidente que pueden incluirse etapas de procesamiento más sofisticadas para implementar diferentes estrategias en el caso de que, en la Etapa 652, los paquetes recibidos dentro de una capa se encuentren fuera de secuencia dentro de esta capa. Si la clase de red de comunicaciones 110, o los protocolos seleccionados para la transferencia de paquetes a través de la misma son tales que paquetes individuales pueden demorarse dentro de una capa, puede ser conveniente implementar algoritmos de espera más sofisticados, si es posible que el paquete esperado pueda llegar tarde. Esta estrategia se sugiere en la Etapa 680 de la figura 6 sin entrar en detalles. Alternativamente, en el caso de datos de audio puros, por ejemplo, el efecto de un paquete perdido puede superarse parcialmente mediante la inserción de un duplicado del paquete inmediatamente anterior, antes que dejar un hueco o arriesgarse a una demora adicional. Una estrategia equivalente puede estar disponible con los datos de vídeo codificados, si pueden manejarse con el algoritmo de codificación/descodificación seleccionado.
Preferentemente, puede implementarse un algoritmo más sofisticado para combinar la ordenación de los paquetes de datos recibidos dentro de una capa con las etapas de procesamiento indicadas en la figura 6, desde la Etapa 605 hacia adelante, antes que efectuar un procesamiento previo para ordenar los paquetes de datos recibidos por número LSEQ dentro de cada capa.

Claims (11)

1. Aparato de transmisión de datos que comprende:
(a) una entrada de datos (115) dispuesta para recibir unas tramas de datos codificadas por un algoritmo de codificación estratificada;
(b) unos medios de paquetización (120) para insertar las tramas de datos recibidas, así codificadas, en una o más estructuras de paquetes predeterminadas, estando insertadas las tramas de datos asociadas con cada capa codificada en una secuencia de paquetes respectiva diferente; y
(c) una interfaz de red (135) dispuesta para trasmitir, en uso, los paquetes así creados;
caracterizado porque presenta
(d) unos medios de numeración de paquetes (125) para asignar un número de secuencia de datos (XSEQ) a cada paquete generado por los medios de paquetización, estando asignados los números de secuencia de datos a los paquetes indicativos del orden de recepción, en la entrada de datos, de datos codificados insertados en el paquete;
estando dispuesta la interfaz de red (135) para transmitir, en uso, los números de secuencia de datos asignados junto con dichos paquetes.
2. Aparato de transmisión de datos según la reivindicación 1, en el que los medios de numeración de paquetes (125) están dispuestos para asignar un número de secuencia adicional (LSEQ) a cada paquete generado por los medios de paquetización, siendo indicativos los números de secuencia adicionales asignados a una secuencia de paquetes respectiva de la posición del paquete dentro de esta secuencia de paquetes.
3. Aparato de transmisión de datos según la reivindicación 1 ó 2, en el que los medios de paquetización están dispuestos para generar una o más secuencias adicionales de paquetes para utilizarlas en el transporte de dichos números de secuencia de datos.
4. Aparato de transmisión de datos según la reivindicación 1 ó 2, en el que los medios de paquetización (120) están dispuestos para generar una o más secuencias adicionales de paquetes para utilizarlas en el transporte de números de secuencia de datos asignados por los medios de numeración de paquetes.
5. Procedimiento de transmisión de tramas de datos codificadas por un algoritmo de codificación estratificada a través de una red de comunicaciones, que comprende las etapas siguientes:
(a) recibir tramas de datos codificadas;
(b) insertar datos de dichas tramas de datos en paquetes de datos generados según una estructura de paquetes predeterminada, siendo insertados los datos de cada capa en una secuencia separada de paquetes de datos; y
(c) transmitir los paquetes;
caracterizado porque presenta las etapas siguientes:
(d) asignar a cada paquete de datos de un número de secuencia de datos, siendo indicativos los números de secuencia del orden requerido para la posterior presentación de las tramas a un descodificador; y
(e) transmitir dichos números de secuencia junto con dichos paquetes.
6. Procedimiento según la reivindicación 5, en el que el algoritmo de codificación estratificada es un algoritmo de codificación de vídeo que emite tramas de vídeo no en el orden en el cual fueron muestreados sino en el orden en el cual deben descodificarse.
7. Procedimiento de generación de paquetes de datos según la reivindicación 5 ó 6, en el que la etapa (d) comprende la asignación de números de secuencia adicionales a cada paquete de datos, siendo indicativos los números de secuencia adicionales asignados a la secuencia de paquetes respectiva del orden de transmisión de los paquetes de datos dentro de esta secuencia de paquetes, y en el que la etapa (e) comprende la transmisión de dichos números de secuencia adicionales.
8. Procedimiento según la reivindicación 5, 6 ó 7, que comprende la escritura de cada uno de dichos números de secuencia de datos en una posición predeterminada dentro de su paquete.
9. Procedimiento según la reivindicación 5, 6 ó 7, que comprende la generación de una o más secuencias adicionales de paquetes para su utilización en el transporte de dichos números de secuencia de datos.
10. Procedimiento según la reivindicación 5, que además comprende recibir paquetes de datos por lo menos en dos de dichas una o más secuencias de paquetes de datos accesibles separadamente; y reordenar los paquetes de datos en el orden de los números de secuencia de datos asignados.
11. Procedimiento de ordenación de paquetes de datos recibidos dentro de una pluralidad de secuencias de paquetes de datos accesibles separadamente recibidas a través de una red de comunicaciones,
transportando cada secuencia de paquetes de datos tramas de datos relacionadas con una capa diferente de tramas de datos codificadas emitidas por un algoritmo de codificación estratificada,
presentando cada paquete de datos un número de secuencia de datos asignado al mismo, indicativo del orden de emisión de los datos codificados, transportados por dicho paquete de datos dentro de la secuencia de datos respectiva,
comprendiendo el procedimiento seleccionar paquetes de datos ordenados por número de secuencia adicional dentro de una primera secuencia de dichas secuencias de paquetes de datos accesibles,
emitiendo paquetes seleccionados de dicha primera secuencia ordenados por número de secuencia de datos asignado, y
al seleccionar un paquete de dicha primera secuencia que presenta un número de secuencia de datos fuera de secuencia, buscar otra de dichas secuencias de datos accesibles separadamente para el paquete siguiente esperado, según el número de secuencia de datos.
ES99949236T 1998-10-30 1999-10-15 Transporte de datos. Expired - Lifetime ES2264584T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP98308894 1998-10-30
EP98308894 1998-10-30

Publications (1)

Publication Number Publication Date
ES2264584T3 true ES2264584T3 (es) 2007-01-01

Family

ID=8235136

Family Applications (1)

Application Number Title Priority Date Filing Date
ES99949236T Expired - Lifetime ES2264584T3 (es) 1998-10-30 1999-10-15 Transporte de datos.

Country Status (9)

Country Link
US (1) US6977934B1 (es)
EP (1) EP1125413B1 (es)
JP (1) JP4373012B2 (es)
AT (1) ATE327625T1 (es)
AU (1) AU6221099A (es)
CA (1) CA2347871C (es)
DE (1) DE69931513T2 (es)
ES (1) ES2264584T3 (es)
WO (1) WO2000027087A1 (es)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7191242B1 (en) * 2000-06-22 2007-03-13 Apple, Inc. Methods and apparatuses for transferring data
JP4965059B2 (ja) * 2001-07-19 2012-07-04 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー ビデオストリームの切り替え
US6981110B1 (en) * 2001-10-23 2005-12-27 Stephen Waller Melvin Hardware enforced virtual sequentiality
JP2003224846A (ja) * 2002-01-29 2003-08-08 Matsushita Electric Ind Co Ltd 画像処理装置、復号化装置、符号化装置、画像処理システム、画像処理方法、及び、符号化方法
US7249264B2 (en) 2002-04-02 2007-07-24 International Business Machines Corporation Secure IP based streaming in a format independent manner
JP4406816B2 (ja) * 2002-12-11 2010-02-03 ソニー株式会社 受信装置および受信方法、記録媒体、並びにプログラム
US7792982B2 (en) * 2003-01-07 2010-09-07 Microsoft Corporation System and method for distributing streaming content through cooperative networking
JP4499489B2 (ja) * 2004-06-18 2010-07-07 株式会社エヌ・ティ・ティ・ドコモ 送信装置、受信装置、通信システム及び通信方法
EP1847071A4 (en) * 2005-01-26 2010-10-20 Internet Broadcasting Corp B V MULTI-DIFFUSION IN LAYERS AND EXACT ATTRIBUTION OF BANDWIDTH AND PRIORIZATION OF PACKETS
US9918218B2 (en) 2007-06-12 2018-03-13 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for a networked self-configuring communication device utilizing user preference information
WO2009114557A1 (en) * 2008-03-10 2009-09-17 Vidyo, Inc. System and method for recovering the decoding order of layered media in packet-based communication
KR20120084237A (ko) 2011-01-19 2012-07-27 삼성전자주식회사 엠엠티(mmt)에서 엠엠티 인캡슐레이터를 전송하는 방법
US9059932B2 (en) 2011-11-03 2015-06-16 Qualcomm Incorporated Packet ordering based on delivery route changes in communication networks
US8824477B2 (en) * 2011-11-03 2014-09-02 Qualcomm Incorporated Multiple delivery route packet ordering
CN103078811B (zh) * 2013-01-31 2015-12-09 北京金和软件股份有限公司 一种基于多线程环境网络数据包乱序控制方法
GB2533531A (en) 2013-09-13 2016-06-22 Smg Holdings-Anova Tech Llc Self-healing data transmission system to achieve lower latency
US9838729B2 (en) * 2013-11-06 2017-12-05 Avago Technologies General Ip (Singapore) Pte. Ltd. Recovering channel bonded program streams
US10101801B2 (en) * 2013-11-13 2018-10-16 Cisco Technology, Inc. Method and apparatus for prefetching content in a data stream
CN104219493B (zh) * 2013-11-14 2017-10-20 成都时代星光科技有限公司 密拍包式无线图像采集和传输系统
CN110582082B (zh) * 2018-06-08 2022-06-10 阿里巴巴集团控股有限公司 一种待配网设备接入网络热点设备的方法和装置
US11956081B2 (en) * 2019-08-14 2024-04-09 Nokia Technologies Oy Reliability of multi-connectivity

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5260783A (en) * 1991-02-21 1993-11-09 Gte Laboratories Incorporated Layered DCT video coder for packet switched ATM networks
US5533021A (en) 1995-02-03 1996-07-02 International Business Machines Corporation Apparatus and method for segmentation and time synchronization of the transmission of multimedia data
FR2736486B1 (fr) 1995-06-30 1997-08-08 Py Stephane Methode de transmission de donnees representatives de sequences d'images et de sons
US6148005A (en) * 1997-10-09 2000-11-14 Lucent Technologies Inc Layered video multicast transmission system with retransmission-based error recovery
US6275471B1 (en) * 1998-05-12 2001-08-14 Panasonic Technologies, Inc. Method for reliable real-time multimedia streaming
US6738379B1 (en) * 2000-03-30 2004-05-18 Telefonaktiebolaget Lm Ericsson (Publ) Method of preserving data packet sequencing

Also Published As

Publication number Publication date
CA2347871C (en) 2007-10-09
JP2002529966A (ja) 2002-09-10
US6977934B1 (en) 2005-12-20
JP4373012B2 (ja) 2009-11-25
AU6221099A (en) 2000-05-22
ATE327625T1 (de) 2006-06-15
CA2347871A1 (en) 2000-05-11
WO2000027087A1 (en) 2000-05-11
DE69931513D1 (de) 2006-06-29
EP1125413B1 (en) 2006-05-24
EP1125413A1 (en) 2001-08-22
DE69931513T2 (de) 2006-12-14

Similar Documents

Publication Publication Date Title
ES2264584T3 (es) Transporte de datos.
KR101029854B1 (ko) 스케일러블 비디오 코딩에서 픽쳐들의 역방향-호환 집합
ES2564802T3 (es) Sistema y método para transmitir archivos basados en medios
JP3766259B2 (ja) パケット転送装置
US7675939B2 (en) Transmission apparatus and method, reception apparatus and method, communication system, recording medium, and program
CN101523371B (zh) 用于具有可缩放视频编码服务和多播的多点会议的系统和方法
US7764708B2 (en) Data transmission system, header-information adding device, data-format converting device, and data transmission method
US6205140B1 (en) Communication of dynamic dependencies along media streams
KR20050052531A (ko) Ip 네트워크를 통해 스캐일 가능한 코드화된 비디오를전송하기 위한 시스템 및 방법
CN1802816A (zh) 一种涉及以太网接入系统的设备和方法
EP1601161A1 (en) Network interface card for supporting multi-streaming format and method thereof
JP2009512279A (ja) ストリーミングと制御処理に異なる素子を用いたメディアデータ処理
EP2478701B1 (en) Distribution of mpeg-2 ts multiplexed multimedia stream with selection of elementary packets of the stream
US20080123560A1 (en) Methods and devices for the dynamic management of transmission errors by network points of interconnections
JP2004038575A (ja) データ送受信システム及びデータ送受信方法、情報提供装置及び情報提供方法、並びにデータ受信装置及びデータ受信方法
JPH11313301A (ja) 番組配信システム、番組配信装置、番組品質変換装置、及び番組受信装置
WO2018121584A1 (zh) 一种数据流传输方法、装置、相关设备及存储介质
Deering SIP: Simple Internet Protocol
JP2001333394A (ja) 番組配信装置、複製転送装置及び番組データの複製転送方法
ES2353489T3 (es) Provisión de servicios con un servidor en una red tcp/ip.
JP5004956B2 (ja) 電気通信ネットワーク上でデータをトランスポートするアドレッシング方法、対応するアドレス構造信号、ゲートウェイ、及び、コンピュータプログラム
JP2006129514A (ja) パケットデータ複製配信方法及び装置
US20060087970A1 (en) Method for encoding a multimedia content
JP3914204B2 (ja) 画像伝送ネットワーク
Wang et al. A fragmentation scheme for multimedia traffic in active networks