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
Links
- 230000005540 biological transmission Effects 0.000 claims description 28
- 238000000034 method Methods 0.000 claims description 24
- 238000004891 communication Methods 0.000 claims description 12
- 238000013479 data entry Methods 0.000 claims description 2
- 238000004806 packaging method and process Methods 0.000 claims 1
- 238000012545 processing Methods 0.000 description 11
- 238000012546 transfer Methods 0.000 description 8
- 238000005457 optimization Methods 0.000 description 4
- JBJSVEVEEGOEBZ-SCZZXKLOSA-N coenzyme B Chemical compound OP(=O)(O)O[C@H](C)[C@@H](C(O)=O)NC(=O)CCCCCCS JBJSVEVEEGOEBZ-SCZZXKLOSA-N 0.000 description 3
- 238000009792 diffusion process Methods 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing 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/234327—Processing 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management 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/462—Content 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/4621—Controlling 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/326—Intralayer 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.
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.
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)
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)
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 |
-
1999
- 1999-10-15 WO PCT/GB1999/003416 patent/WO2000027087A1/en active IP Right Grant
- 1999-10-15 EP EP99949236A patent/EP1125413B1/en not_active Expired - Lifetime
- 1999-10-15 ES ES99949236T patent/ES2264584T3/es not_active Expired - Lifetime
- 1999-10-15 JP JP2000580351A patent/JP4373012B2/ja not_active Expired - Lifetime
- 1999-10-15 AT AT99949236T patent/ATE327625T1/de not_active IP Right Cessation
- 1999-10-15 CA CA002347871A patent/CA2347871C/en not_active Expired - Lifetime
- 1999-10-15 AU AU62210/99A patent/AU6221099A/en not_active Abandoned
- 1999-10-15 DE DE69931513T patent/DE69931513T2/de not_active Expired - Lifetime
- 1999-10-15 US US09/806,576 patent/US6977934B1/en not_active Expired - Lifetime
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 |