ES2354872T3 - Procedimiento de transmisión de flujos de datos dependientes. - Google Patents

Abstract

Procedimiento de transmisión de al menos un flujo de datos multimedia hacia al menos un terminal, estando dichos flujos organizados en unidades de acceso, caracterizado porque al menos algunas de dichas unidades de acceso comprenden al menos un puntero que designa al menos una unidad de acceso, anterior o posterior, de dicho flujo o de otro flujo de datos multimedia, la denominada unidad de dependencia, de forma que un tratamiento de dicha unidad de acceso no sea efectuado, en dicho terminal, si no se han recibido dichas unidades de dependencia.

Description

El campo de la invención es la transmisión de datos, bajo la forma de uno o varios flujos de datos constituidos cada uno por unidades de flujo elementales. Más concretamente, la invención se refiere a la optimización del tratamiento de estas unidades de flujo elementales, cuando estas últimas 5 son dependientes de, o están enlazadas con, una o varias otras unidades de flujo.

Cuando una señal, por ejemplo de tipo multimedia, se transmite a través de un canal único y de forma síncrona, el tratamiento de una unidad de flujo no plantea ningún problema o pocos problemas. Los datos necesarios se recibieron con anterioridad.

Lo anterior no sucede, por el contrario, en sistemas asíncronos, que pueden poner en práctica 10 varios canales de transmisión y/o varios servidores que distribuyen cada uno una parte de la señal útil. Es, por ejemplo, el caso de la transmisión, o de la difusión, en una red tipo IP.

En este caso, ocurre que se recibe una unidad de flujo que es detectada al completar otras, que no han sido recibidas. Puede tratarse, por ejemplo, de datos de enriquecimiento de datos de un nivel jerárquico superior, estando los datos codificados con la ayuda de una codificación jerárquica (un flujo 15 que puede entonces corresponder a un nivel jerárquico dado). El tratamiento de los datos de enriquecimiento proporcionará entonces un resultado aleatorio, que conduce, en general, a una fuerte degradación de la señal restituida e incluso a un bloqueo completo del decodificador.

La técnica anterior (ver, por ejemplo, el estudio ―MPEG-4 Systems: Elementary stream management‖, por C. Herbel, A. Eleftheriadis), en materia de sincronización multimedia está 20 representado esencialmente por los protocolos de transporte basados en RTP y por MPEG-4 (capa de sincronización). En el método utilizado, los mecanismos de sincronización fueron principalmente diseñados para sincronizar temporalmente un flujo de audio y un flujo de vídeo, con el fin de que sean presentados sin desplazamiento de fase. Estas informaciones eran transportadas por medio de un sistema de estampilla temporal (un reloj de referencia, estampillas de decodificación y de presentación). 25

Con la aparición de codificaciones jerárquicas, en donde se utilizan diferentes niveles de enriquecimiento temporal y espacial con el fin de obtener una trama presentable, el inventor ha constatado que aparece una nueva necesidad de sincronización.

En efecto, es necesario sincronizar los flujos antes de su decodificación (y no solamente en su presentación). Esta limitación se hace más compleja en el caso de la sincronización de presentación 30 porque es necesario identificar cuáles son las unidades necesarias para la decodificación de una unidad, con el fin de obtener una trama correcta. Un solo desfasaje puede hacer inútil un flujo así como todos los flujos basados en este último. Se trata de un nuevo problema, y no evidente, identificado por el inventor.

Un problema similar se plantea cuando una unidad de flujo recibida debe decodificarse, o desencriptarse, con la ayuda de informaciones (por ejemplo, una clave de decodificación) que el terminal 35 hubiera debido recibir, pero que no ha recibido. De nuevo, el resultado de la decodificación será como mínimo ineficaz, en general perjudicial (en términos de señal restituida) y puede conducir al bloqueo del terminal. En ambos casos, se hubiera efectuado un tratamiento inútil y nefasto.

Otro problema importante encontrado en los sistemas de difusión (―multicast‖ o ―broadcast‖) es que las mismas informaciones deben ser multidifundidas, para permitir a un usuario, que se conecta en 40 un instante cualquiera, recibir la integridad de los flujos que ha seleccionado. Este aspecto específico es ya examinado en la solicitud de patente EP-01 4600462, no todavía publicada, a los nombres de los titulares de la presente solicitud de patente. Según esta técnica, el tratamiento se realiza al nivel del transporte, lo que impone un tratamiento de cada unidad de flujo, teniendo en cuenta las especificidades de los diferentes tipos de transporte. 45

La técnica anterior, en materia de representación multimedia en escenarios operativos de ―broadcast‖ y ―multicast‖, se describe en la especificación del ―carrusel MPEG-4‖. Sin embargo, un determinado número de funcionalidades están prohibidas o se hacen extremadamente consumidoras del caudal de transmisión. En ambos escenarios de entrega considerados, se necesita señalar puntos de entrada a la presentación multimedia, en todo momento. Esto se traduce por una repetición de datos 50 relativos a la descripción de la escena: escena BIFS, texturas.

Desde el momento en que se enriquece el contenido multimedia, esta repetición simple no es admisible y da lugar a tiempos de telecarga excesivos. Por otro lado, esta especificación no permite

difundir algunos elementos multimedia (clips de audio/vídeo de corta duración).

En particular, la invención tiene por objetivo subsanar estos diferentes inconvenientes de la técnica anterior.

Más concretamente, un objetivo de la invención es proporcionar una técnica que permite gestionar eficazmente unidades de flujo, cuando estas últimas dependan de, o estén vinculadas con, una 5 o varias otras unidades de flujo.

En particular, un objetivo de la invención es proporcionar una tal técnica, que permita la gestión de flujos vinculados, en particular en el caso de datos codificados con la ayuda de una codificación jerárquica o una codificación que comprende una codificación que asocia datos de base y datos de enriquecimiento. 10

Otro objetivo de la invención es proporcionar una tal técnica, que permita garantizar eficazmente la gestión de la decodificación o de la desencriptación de unidades de flujo.

Otro objetivo de la invención es proporcionar una tal técnica, que permita optimizar la transmisión de escenarios multidifundidos y en particular, reducir la cantidad de recurso utilizada, sin reducir, por ello, la calidad de la recepción. 15

La invención tiene por objetivo, en otros términos, optimizar los tratamientos efectuados, en los terminales, tanto en cantidad como en calidad.

Estos objetivos, así como otros que se describirán más adelante, son conseguidos según la invención con la ayuda de un procedimiento de transmisión de al menos un flujo de datos hacia al menos un terminal, estando dichos flujos organizados en unidades de flujo. Según la invención, al menos 20 algunas de dichas unidades de flujo comprenden al menos un puntero dirigido hacia al menos una unidad de flujo de dicho flujo, o de otro flujo, susceptible de haber sido recibida anteriormente, en un terminal, denominada unidad anterior necesaria, de forma que un tratamiento de dicha unidad de flujo no sea efectuado, en dicho terminal, si no se recibieron dichas unidades anteriores necesarias.

De este modo, se dispone de un sistema de sincronización lógica, que permite facilitar la 25 gestión de las unidades de flujo, limitar los tratamientos en los terminales, mejorar la calidad de restitución, etc.

El formato de datos así definido, según la invención, puede ponerse en práctica no solamente para la transmisión y la recepción de flujos, sino también para su difusión, su registro y su almacenamiento. 30

Por lo tanto, la invención se basa, en particular, sobre la identificación del nuevo problema de la sincronización ―atrasada‖ de los flujos o de las unidades de flujo y sobre la observación, no evidente, de que la solución más eficaz es no tratar las unidades de flujo cuando no se disponga de todos los elementos para hacerlo. En efecto, parece preferible, en términos de restitución de la señal, ignorar una unidad de flujo en lugar de efectuar una decodificación que conducirá a un deterioro de la señal restituida 35 e incluso a un bloqueo completo del terminal.

De forma ventajosa, el procedimiento de la invención comprende la transmisión de al menos dos flujos de datos transmitidos por separado, apuntando una unidad de flujo de un primer flujo hacia al menos una unidad anterior necesaria de al menos un segundo flujo, comprendiendo dicha unidad de flujo del primer flujo datos de enriquecimiento de los datos contenidos en dichos segundos flujos. 40

En este caso, dichos flujos de datos pueden corresponder ventajosamente a niveles jerárquicos diferentes de una codificación jerárquica, siendo el tratamiento de una unidad de flujo de un nivel jerárquico efectuado solamente cuando se hayan recibido las unidades de flujo de los niveles jerárquicos inferiores correspondientes.

Dicha unidad de flujo puede apuntar hacia al menos una unidad anterior, definiendo una 45 secuencia de unidades anteriores necesarias.

Según una característica preferida de la invención, al menos uno de dichos punteros permite encontrar, de nuevo, al menos una unidad anterior necesaria, que comprende datos que permiten la decodificación y/o la desencriptación de la unidad de flujo considerada.

Preferentemente, dichas unidades anteriores necesarias comprenden datos que permiten a un 50 terminal decidir si los datos de una unidad de flujo considerada se deben decodificar y/o desencriptar y

luego presentarse visualmente después de la decodificación.

Según otra forma de realización preferida, al menos uno de dichos punteros se dirige hacia datos susceptibles de ser conocidos de dicho terminal, de forma que este último pueda decidir sobre su capacidad o su incapacidad para tratar la unidad de flujo correspondiente.

De forma ventajosa, según otro aspecto de la invención, al menos una de dichas unidades de 5 flujo comprende al menos un puntero dirigido hacia al menos una unidad de flujo de dicho flujo o de otro flujo, susceptible de recibirse en un momento próximo.

Preferentemente, dichas unidades de flujo susceptibles de recibirse próximamente disponen de un marcador, que permite establecer un vínculo con dichos punteros.

De este modo, de una forma ventajosa, los punteros de al menos dos unidades de flujo 10 similares, transmitidas en instantes distintos, pueden apuntar hacia una misma unidad de flujo susceptible de recibirse próximamente.

De forma preferente, el procedimiento de la invención pone en práctica un indicador que señala la función de los punteros, entre al menos dos de las funciones que pertenecen al grupo que comprende:

- designación de al menos una unidad de flujo anterior, que se debe decodificar para permitir 15 tener en cuenta a la unidad de flujo considerada;

- designación de al menos una unidad de flujo anterior, que comprende datos necesarios para la decodificación y/o desencriptación de la unidad de flujo considerada y/o de una referencia a un estado de un sistema de protección;

- designación de al menos una unidad de flujo posterior. 20

De forma ventajosa, al menos algunas de dichas de unidades de flujo comprenden un descriptor de dependencia que define dicha función.

De forma ventajosa, al menos algunas de dichas unidades de flujo comprenden un marcador de dependencia, que permite su identificación en tanto como unidad anterior necesaria y/o un marcador de identificación de dicha unidad de flujo en dicho flujo. 25

Preferentemente, el procedimiento de la invención se pone en práctica al nivel de sincronización, de forma que no se necesite ningún tratamiento previo de una unidad de flujo recibida.

La invención se refiere, además, a uno o varios flujos de datos transmitidos según el procedimiento de transmisión anteriormente descrito. Como ya fue indicado, un tal formato de datos se puede utilizar para la transmisión, la difusión, la recepción, el registro (por ejemplo mediante un 30 magnetoscopio o un dispositivo grabador de discos ópticos) y el almacenamiento de datos (por ejemplo, en un CD-ROM, una cinta magnética, un servidor distante, etc.).

Asimismo, se hace constar que la invención permite combinar fácilmente varios de estos aspectos. Por ejemplo, se pueden difundir algunos flujos y proporcionarse otros en un CD-ROM o un servidor, siendo el conocimiento de los segundos necesario para decodificar (u optimizar) los primeros. 35

Un tal flujo de datos está organizado en unidades de flujo transmitidas con independencia entre sí, comprendiendo al menos algunas de dichas unidades de flujo al menos un puntero dirigido hacia al menos una unidad de flujo de dicho flujo o de otro flujo susceptible de haber sido recibida con anterioridad, en un terminal, la denominada unidad anterior necesaria, de forma que no sea efectuado un tratamiento de dicha unidad de flujo, en dicho terminal, si no se recibieron dichas unidades anteriores 40 necesarias.

La invención se refiere, además, a los servidores de datos destinados a transmitirse hacia al menos un terminal, bajo la forma de al menos un flujo de datos organizado en unidades de flujo transmitidas de forma independiente entre sí, comprendiendo al menos algunas de dichas unidades de flujo al menos un puntero dirigido hacia al menos una unidad de flujo de dicho flujo o de otro flujo 45 susceptible de haber sido recibida con anterioridad, en un terminal, la denominada unidad anterior necesaria.

La invención se refiere, además, a los terminales adecuados para recibir al menos un flujo de datos organizado en unidades de flujo transmitidas con independencia entre sí, comprendiendo al menos algunas de dichas unidades de flujo al menos un puntero dirigido hacia al menos una unidad de flujo de 50

dicho flujo o de otro flujo susceptible de haber sido recibida con anterioridad, en un terminal, la denominada unidad anterior necesaria.

La invención se refiere, además, a la procedimientos de recepción de al menos un flujo de datos organizado en unidades de flujo transmitidas con independencia entre sí, comprendiendo al menos de dichas unidades de flujo al menos un puntero dirigido hacia al menos una unidad de flujo de dicho 5 flujo o de otro flujo susceptible de haber sido recibida con anterioridad, en un terminal, la denominada unidad anterior necesaria y el procedimiento de recepción comprende las etapas siguientes:

- análisis de dichos punteros de una unidad de flujo;

- tratamiento de dicha unidad de flujo si dichas unidades anteriores necesarias han sido recibidas. 10

La invención se refiere, por último, a las utilizaciones del procedimiento de transmisión, en particular para una de las aplicaciones que pertenecen al grupo que comprende:

- difusión sistemática de un mensaje antes del acceso a un programa seleccionado por un usuario;

- acceso condicional a un nivel de calidad particular y/o a una opción particular de un programa; 15

- televisión interactiva.

Otras características y ventajas de la invención aparecerán, de forma más evidente, en la lectura de la descripción siguiente de un modo de realización preferente de la invención, proporcionada a título de simple ejemplo ilustrativo, y los dibujos adjuntos, en los cuales:

- la Figura 1 ilustra el principio de la gestión de la dependencia de un flujo de datos con respecto 20 a otro, según la invención;

- la Figura 2 representa una puesta en práctica de la invención, en el caso de la difusión de un flujo (―broadcast‖) y de su recepción por dos terminales, bajo la forma de sesiones desplazadas en el tiempo;

- la Figura 3 ilustra el caso de una sincronización vinculada a la decodificación o a la 25 desencriptación, de una unidad de flujo (IPMP);

- la Figura 4 representa una variante del caso de la Figura 3, con dos puntos de protección (decodificación y presentación).

El modo de realización preferente, descrito a continuación, se refiere, en particular, a la transmisión de flujo, en un sistema multimedia, en particular del tipo MPEG4. 30

1. Antecedentes de la técnica anterior

La técnica anterior no permite tener en cuenta la transmisión eficaz (en términos de caudal de datos y de funcionalidad) de escenas multimedia en escenarios multicast o broadcast, ni la sincronización de flujos interdependientes de los elementos vinculados al contenido de tipo de claves de control de acceso. 35

1.1 Representación multimedia en escenarios broadcast y multicast

Se da a conocer una solución en la especificación del denominado ―carrusel MPEG-4‖. Sin embargo, un determinado número de funcionalidades están prohibidas o se hacen extremadamente consumidoras de caudal de transmisión. En ambos escenarios de entrega considerados, es necesario señalar puntos de entrada a la presentación multimedia, en todo momento. Esto se traduce por una 40 repetición de los datos relativos a la descripción de la escena: escena BIFS, texturas.

Desde el momento en que se enriquece el contenido multimedia, esta repetición simple no es admisible y conduce a tiempos de telecarga excesivos. Por otro lado, esta especificación no permite difundir algunos elementos multimedia (clips de audio/vídeo de corta duración).

Por otro lado, en la solicitud de patente no todavía publicada EP-01 4600462, los datos eran 45 transmitidos al nivel del transporte. Por el contrario, según la invención, la totalidad se encuentra al nivel de la capa denominada de sincronización, que es independiente del transporte.

Lo anterior tiene la ventaja de abstraerse de los diferentes tipos de transporte y de unificar las informaciones de sincronización temporal y lógicas así como los marcadores de acceso aleatorio en un mismo punto, lo que permite calcular, en un lugar único, la decisión de conservar, o no, la unidad. Asimismo, se conoce, por otro lado, que se dispone de más informaciones sobre el flujo, lo que permite especializar las decisiones por tipo de flujo (lo que es de interés para las transmisiones de vídeo/audio 5 con respecto a BIFS, etc.).

1.2 Sincronización multimedia

La técnica anterior, en materia de sincronización multimedia, se representa esencialmente por los protocolos de transporte basados en RTP y por MPEG-4 (capa de sincronización). En el método utilizado, los mecanismos de sincronización han sido principalmente diseñados para sincronizar 10 temporalmente un flujo de audio y un flujo de vídeo, con el fin de que sean presentados sin desfase. Estas informaciones fueron transmitidas por medio de un sistema de estampilla temporal (un reloj de referencia, estampillas de decodificación y de presentación).

Con la aparición de la codificación jerárquica, en donde se utilizan diferentes niveles de enriquecimiento temporal y espacial, con el fin de obtener una trama presentable, surge una nueva 15 necesidad de sincronización. En efecto, es necesario sincronizar los flujos antes de su decodificación (y no solamente en su presentación). Esta limitación hace más compleja la sincronización de presentación porque es necesario identificar cuáles son las unidades necesarias para la decodificación de una unidad, con el fin de obtener una trama correcta. Un solo desfasaje puede hacer inútil todo un flujo así como todos los flujos basados en este último. Como se constata, se trata de un problema de dependencia 20 lógica entre unidades a decodificar.

Un intervalo de tiempo reducido se tiene ya en cuenta en MPEG-4 vídeo, pero este último no es accesible a las capas del sistema.

1.3 Protección de los datos

Un tercer caso de sincronización no es abordado en la técnica anterior: el caso de la 25 sincronización de un flujo de protección de datos vinculado a un flujo multimedia.

En este caso, es necesario cerciorarse de que toda unidad de flujo multimedia será desencriptada con una clave correcta antes de ser decodificada (en tal caso, los resultados tienen todas las posibilidades de ser catastróficos). Desde el momento en que los flujos no estén asegurados de ser síncronos, las herramientas de sincronización ya no pueden asegurarlo. 30

En este caso, la entrada del decodificador y su salida son puntos de sincronización (a su vez, la trama decodificada puede ser encriptada).

2. Principios de la invención

Los objetos de la invención son, en particular, permitir:

- La difusión multicast y broadcast de escenas multimedia; 35

- La sincronización lógica de la decodificación multimedia.

Lo anterior se obtiene con la ayuda de mecanismos de señalización que permiten alcanzar estos dos objetivos:

- Mecanismo que permite configurar un flujo con el fin de que cada una de las unidades temporales que lo componen, se identifiquen de forma susceptible de definición de parámetros. 40

- Mecanismo de encadenamiento previo para los escenarios de difusión/broadcast.

Los elementos técnicos esenciales de la invención son, por lo tanto:

- Elementos de sincronización lógica entre elementos de varios flujos o dentro del mismo flujo (vídeo, audio y sistemas de protección de datos);

- La solución permite, para cada elemento de flujo, indicar de qué tipo de elementos depende y 45 de qué elementos, en particular, depende. Varias puestas en práctica son posibles.

Se utiliza, en particular, bajo cualquier forma de realización:

- Descriptor de dependencia: ―DependencyDescriptor‖;

- Marcador de dependencia: ―DependencyMarker‖ (como opción);

- Puntero en la unidad de la que se depende: ―DependencyPointer‖;

- Marcador (identifica una unidad de flujo): ―marker‖ (como opción).

3 Descripción detallada de al menos un modo particular de realización: 5

3.1 Especificación de MPEG-4

El anexo 1 presenta, de forma detallada, un ejemplo de puesta en práctica de la invención para normas de tipo MPEG, bajo la forma de una especificación MPEG-4.

3.2 Comportamiento del receptor

El terminal recibe un IOD (InitialObjectDescriptor) que hace referencia por intermedio de sus 10 descriptores (ObjectDescriptor) a por lo menos un objeto de descripción de la escena gráfica (flujo BIFS: F_BIFS) y opcionalmente, a por lo menos un objeto de descripción de objetos gráficos (flujo de OD: F_OD). El terminal realizará la apertura de estos flujos basándose en las informaciones presentadas a continuación.

Cada uno de estos descriptores de objeto contiene un descriptor mediante flujo elemental (ES) 15 que le compone (ESDescriptor). Cada ESDescriptor contiene un campo dependsOnESID y un SLConfigDescriptor.

El campo dependsOnESID permite construir el gráfico de las dependencias entre flujos identificados por su ESID.

El objeto SLConfigDescriptor permite configurar las herramientas de sincronización. 20

Se encontrará en el objeto SLConfigDescriptor la posibilidad de configurar el receptor con el fin de que compruebe las diferentes dependencias de la forma siguiente:

DependencyMarker //permite configurar el flujo con el fin de que identifique sus paquetes.

{ 25

int (5) markerLength;

}

DependencyDescriptor //permite describir los vínculos de dependencia.

{

int(2) mode; // 0: modo versión por DTS, 30

// 1: modo versión por ID,

// 2: modo escalable,

// 3: modo IPMP

// si modo=1 la dependencia se hace % como un marcador en el flujo. 35

// si modo=3 la dependencia se hace de forma opaca (el sistema IPMP debe

// comprender la dependencia y validar, o no, la decodificación/desencriptación.

// ocasionalmente utilizando un marcador. 40 Por lo tanto, se trata de un código

// que permite al sistema de protección saber si se trata, o no, de una

// unidad descriptable (o no)

// si modo=0 o modo=2, la dependencia se calcula sobre el DTS. 5

// Por consiguiente depLength=dtsLength en el SLConfig correspondiente.

int(5) depLength;

if (modo =1 || modo=0)

{ 10

int(depLength) value; //valor de la primera unidad a buscar.

}

}

De este modo, un flujo se puede declarar dependiente de otro flujo (él mismo, un medio normal o IPMP). En este caso, describe, en su configuración SL, cómo señalará esta dependencia (Dependency 15 descriptor) en cuatro modos distintos:

3.2.1 Modo versión por DTS y por ID (modos 0 y 1):

El flujo indicará, para cada una de estas AccessUnits (AU) una dependencia anterior en el propio flujo. En otros términos, la AU (n) precisa cuál es la próxima unidad de acceso (AccessUnit) a decodificar. Esta indicación se hace por medio de un marcador, en cada paquete, que describe o bien, 20 en el modo 0, el DTS de la próxima Access Unit (única) o bien el ID de la próxima Access Unit en el modo 1.

En este caso, se añade el valor del primer elemento que se va a recuperar.

Por ejemplo, puede tratarse de un flujo BIFS en modo broadcast/multicast.

3.2.2 Modo escalable (modo 2): 25

El flujo indicará, para cada una de estas unidades de acceso, una dependencia con respecto a un flujo del que depende. Este flujo se supone único.

Este principio se ilustra por la Figura 1. La unidad de flujo 11 de un flujo dependiente 10 comprende, de forma clásica una cabecera (SLHeader) 111 y un campo de datos (SL payload) 112. La cabecera 111 comprende, en particular, dos punteros Dep1 y Dep2, que definen vínculos de 30 dependencia 12 y 13 con unidades de flujo 141 y 142, respectivamente, de un flujo de base 14, cuyo conocimiento es necesario para tratar la unidad de flujo 11.

3.2.3 Modo IPMP (modo 3):

El flujo indicará, para cada una de estas unidades de acceso, un identificador que permite al sistema de protección de datos decodificar la unidad. Por supuesto, este marcador puede responder sí o 35 no sabe desencriptar la unidad.

El SLConfigDescriptor puede contener uno o varios descriptores DependencyDescriptor y uno o varios marcadores DependencyMarker, lo que permite ajustar los diferentes casos de dependencia en el flujo. (A priori, basta un solo DependencyMarker, pero se puede disponer de varios).

De este modo, si el SLConfig contiene DependencyMarker, indicará un ID de versión para cada 40 uno de sus paquetes (modos 1 y 3).

En la cabecera de un paquete SL, correspondiente a una unidad de acceso se encontrará, por lo tanto:

- Para cada dependencyMarker del SLConfigDescriptor, un marcador de longitud

markerLength.

- Para cada DependencyDescriptor un puntero dependencyPointer de longitud depLength.

Una vez realizados estos diferentes marcados, el sistema procederá a:

a) Funcionar en modo ―broadcast‖ gracias a los modelos 0 y 1.

b) Gestionar las dependencias de escalabilidad; 5

c) Gestionar las dependencias IPMP;

y las combinaciones de a), b), c).

3.3 Descripción del funcionamiento en modo IPMP

En el momento de la recepción del ObjectDescriptor relativo a un objeto, el terminal examina el SLConfigDescriptor para cada uno de los flujos asociados. Esto permitirá decodificar la cabecera de los 10 paquetes SL para cada uno de los flujos: en particular, decodificar los marcadores.

En el caso de IPMP tendrá DTS y/o dependencyPointer así como lo que se ilustra en la Figura 3.

Para cada AU del flujo, antes de que este último sea decodificado, se trata por el sistema IPMP 32, proporcionándole al menos los datos siguientes que identifican el flujo ESID, DTS, 15 dependencyPointer (IPM) 31. El sistema IPMP responde entonces (33) si está en condiciones de tratar (desencriptar) la AU, considerando la información 311 (Code Dec) relativa a la decodificación. Si éste no fuera el caso y cuando el DTS de la unidad llega a su madurez, la AU se destruye (34). Por lo tanto, no se trata de decodificar unidades AU no coherentes.

En el ejemplo ilustrado en la Figura 4, se encuentra, de una parte, los elementos de la Figura 3 20 y de otra parte, un tratamiento vinculado a la restitución de la imagen, después de su decodificación 41. En efecto, con la ayuda del campo 312 (CodeComp), se pueden transmitir datos relativos a la composición, tal como la adición de un tatuaje informático o de un mensaje a través de la imagen. Si el sistema de protección de datos 32 no sabe generar esta composición (no sabe mostrar la imagen (42)), por ejemplo porque el decodificador no dispone del tatuaje informático requerido, no se mostrará la 25 imagen (43).

Asimismo, se puede prever que la trama será marcada, por ejemplo, con un logotipo, que desaparece si el decodificador dispone de la clave adecuada.

3.4 Descripción del funcionamiento en el modo multicast/broadcast

Este funcionamiento se ilustra en la Figura 2, que presenta: 30

- el flujo emitido 21;

- el flujo recibido por un primer receptor (sesión 1), 22;

- el flujo recibido por un primer receptor (sesión 2), 23.

La sesión 1 se inicia con el paquete 211, teniendo luego en cuenta la unidad de flujo 213, al cual apunta (24) la unidad de flujo 211 y luego, la unidad de flujo 215, según el vínculo 25. 35

La sesión 2, que aparece poco después, se inicia con la unidad de flujo 212, que apunta (26) sobre la unidad de flujo 214.

Según la invención, dos (o más) unidades de flujo pueden apuntar sobre una misma unidad de flujo siguiente. Se trata del denominado mecanismo de fusión 27: las unidades de flujo 213 y 214 apuntan ambas sobre la unidad de flujo 215. De este modo, aunque habiéndose iniciado en instantes 40 distintos, las dos sesiones utilizan, después de una fase de recuperación, las mismas unidades de flujo 215. Ello permite claramente mejorar el rendimiento.

A continuación, se describe, de forma más precisa, este funcionamiento.

En el momento de la recepción del ObjectDescriptor, el terminal examina el SLConfigDescriptor para cada uno de los flujos asociados. Esto permitirá decodificar la cabecera de los paquetes SL para 45

cada uno de los flujos: en particular, decodificar los marcadores.

En el caso multicast/broadcast, habrá, por lo tanto, DTS, al menos un dependencyPointer en modo 0 o 1 y un marcador (modo 1 ―por ID‖). El terminal sabe, por lo tanto, cuál es la primera unidad a recuperar para cada uno de los flujos. Por lo tanto, intentará recuperar la primera unidad correspondiente a cada flujo. 5

Si recibe la primera unidad, entonces puede comenzar a mostrar el contenido.

Cada unidad describe, en el ―dependencyPointer‖, la próxima unidad a recibir y el DTS/marcador identifica cada unidad de forma única.

Si el terminal no recibe la primera unidad (puede hacerlo constar o bien, mediante un tiempo de espera time-out o desde que recibe una unidad para este flujo de tipo RAP=1 que no corresponde al 10 marcador deseado). Se desconecta (cierre completo de sesión) e intenta volverse a conectar.

Se observará que este mecanismo tiene en cuenta la fusión de sesiones.

Además, se observará que el modo por ID es necesario desde el momento en que no se sabe, con anticipación, el DTS de la próxima unidad.

Este mecanismo se utiliza, en particular, para BIFS, OD, Texturas, clips de audio, clips de vídeo 15 en MPEG-4. Para el flujo de vídeo/audio no será utilizado.

3.5 Descripción del funcionamiento en modo escalable

En el momento de la recepción del ObjectDescriptor, el terminal examina el SLConfigDescriptor para cada uno de los flujos asociados. Esto permitirá decodificar la cabecera de los paquetes SL para cada uno de los flujos. Para el vídeo escalable, un flujo servirá de base y uno o varios otros flujos 20 dependerán de este último. Cada flujo, dependiente del flujo de base, declarará un DependencyDescriptor.

Para cada unidad de acceso AU del flujo de mejora, se realizará una referencia gracias al dependencyPointer, de los DTS de las unidades AU del flujo de base del que depende.

En la mayor parte de los casos, se tendrá dos dependencyPointer en el flujo de mejora con el 25 fin de apuntar sobre las dos unidades AU de referencia del flujo de vídeo de base.

3.6 Descripción del funcionamiento en modo broadcast+IPMP

En este caso, el BIFS, por ejemplo contendrá dos DependencyDescriptor en la configuración SL. Uno para el modo broadcast, el otro para IPMP. Contendrá un marcador si el modo broadcast es por ID. 30

4. Ejemplos de aplicaciones

4.1 Difusión de una publicidad antes de comenzar un programa

En numerosos casos de streaming en Internet, los proveedores de contenido envían sistemáticamente una publicidad antes de enviar el propio contenido. Al ser los entornos Internet de tipo unicast (cliente-servidor), se realiza en dos fases: telecarga de la publicidad, el final de la publicidad inicia 35 el lanzamiento del streaming de vídeo.

En un escenario multicast o broadcast, en donde no se puede tener el recurso a un funcionamiento cliente–servidor, si no hay noción de demanda, por ello el usuario solamente suele tener acceso al estado corriente de la presentación.

Gracias al mecanismo de referencia anterior, este escenario se hace posible en multicast o bien 40 en broadcast.

En efecto, es posible enviar, de forma cíclica, la publicidad y realizar la fusión hacia el programa en curso al final de la publicidad.

Esto permite cerciorarse, de que, por ejemplo, cualquier usuario visualizará la publicidad al principio (durante este tiempo, se puede realizar la telecarga del contenido de forma eficaz e 45 incremental).

Aplicaciones del mismo tipo pueden ser, para cada película difundida, una notificación de la categoría de la película (convenio parental, menores de 16 años, etc.).

4.2 Acceso condicional escalable

En este caso, la idea consiste en enviar el mismo flujo (único) de vídeo y de audio que se pueda visualizar de forma diferente en función de los derechos de los usuarios. La señalización de las 5 dependencias de las tramas de vídeo con respecto a las claves de protección permite decodificar únicamente aquellas de las que se tenga la clave. Por lo tanto, se puede decodificar todas las imágenes para lo que se disponga de todas las claves, imágenes para un usuario que tenga menos derechos, etc. Esto permite realizar el acceso condicional de forma más escalonable (en este caso, escalonabilidad temporal). 10

El escenario, más complejo y más útil es aquel en el que se tiene varios flujos y en donde se puede disfrutar, a la vez, de la escalonabilidad temporal y de la resolución.

Con este sistema de dependencia por trama es por lo tanto, posible, modular de forma casi continua el acceso a los medios.

En consecuencia, se puede imaginar que algunos usuarios tendrían claves que permitan recibir 15 el sonido en 5 vías (sonido espacializado) y otros únicamente el sonido estéreo. Lo que permitiría, asimismo, una facturación más ajustada…

4.3 Televisión interactiva MPEG-4

En lugar de considerar que el programa de aplicación de la ―set-top box‖ es estático, se puede considerar que todo este programa de aplicación es una aplicación MPEG-4 que permite alcanzar las 20 diferentes cadenas (mecanismo de inline). Esta aplicación MPEG-4 sería activa, durante las 24 horas, y permitiría reconfigurar completamente las interfaces gráficas, etc.

La técnica de difusión de escena permitiría telecargar eficazmente la interfaz gráfica (BIFS/Texturas/OD) así como la parte aplicativa (MPEG-J).

Esto permite un despliegue/repliegue rápido. 25

ANEXO

EJEMPLO DE ESPECIFICACIÓN DE TIPO MPEG-4 SEGÚN LA INVENCIÓN

1. Definiciones

1.1 Unidad de flujo (AU: Access Unit) 30

Una unidad de datos accesible individualmente en un flujo elemental (elementary stream). Una unidad de flujo (o unidad de acceso) es la más pequeña entidad a la que se puede atribuir una información temporal.

1.2 Objeto audiovisual

Una representación de un objeto natural o sintetizado (virtual) que se manifiesta de forma 35 auditiva y/o visual. La representación corresponde a un nudo o a un grupo de nudos en la descripción de la secuencia BIFS. Cada objeto individual está asociado a cero, utilizando uno o varios flujos elementales (elementary streams) uno o varios descriptores de objetos (object descriptors).

1.3 Secuencia audiovisual (AV Scene)

Una serie de objetos audiovisuales con informaciones que describen la escena que definen sus 40 atributos espaciales y temporales, incluyendo los funcionamientos resultantes del objeto y de las interacciones del usuario.

1.4 Formato binario para la escena (BIFS)

Una representación codificada de un formato de descripción de escena paramétrica.

1.5 Terminal 45

Un sistema que envía o recibe y presenta la representación codificada de una escena audiovisual interactiva, según se define por la norma ISO/IEC 14496-1. Ello puede ser un sistema autónomo o parte de un sistema de aplicación que se somete a la norma ISO/IEC 14496.

2. Abreviaturas y símbolos

AU Unidad de Acceso o Unidad de Flujo (Access Unit). 5

AV Audiovisual (Audio-visual).

BIFS Formato Binario para la Escena (Binary Format for Scene).

CM Memoria de Composición (Composition Memory).

CTS Estampilla Temporal de Composición (Composition Time Stamp).

CU Unidad de Composición (Composition Unit). 10

DAI Interfaz de Aplicación DMIF (ver norma ISO/IEC 14496-6) (DMIF Application Interface).

DB Memoria Intermedia de Decodificación (Decoding Buffer).

DTS Estampilla Temporal de Decodificación (Decoding Time Stamp).

ES Flujo Elemental (Elementary Stream). 15

ESI Interfaz de Flujo Elemental (Elementary Stream Interface).

ESID Identificador de Flujo Elemental (Elementary Stream Identifier).

FAP Parámetros de Animación Facial (Facial Animation Parameters).

FAPU Unidades FAP (FAP Units).

NCT Tablas de Codificación de Nodos (Node Coding Tables). 20

NDT Nodo de Dato Tipo (Node Data Type).

OCI Informaciones sobre el Contenido del Objeto (Object Content Information).

OCR Referencia de Reloj Objeto (Object Clock Reference).

OD Descriptor de Objeto (Object Descriptor).

ODID Identificador de Descriptor de Objeto (Object Descriptor Identifier). 25

OTB Base de Tiempos Objeto (Object Time Base).

PLL Bucle de Enclavamiento de Fase (Phase Locked Loop).

QoS Calidad de Servicio (Quality of Service).

SDM Modelo de Decodificador de Sistema (System Decoder Model).

SL Capa de Sincronización (Synchronization Layer). 30

SL-Packet Paquete de la Capa de Sincronización (Synchronization Layer Packet).

SPS Flujo de SL-Packets (SL-Packetized Stream).

STB Base de tiempos de Sistema (System Time Base).

TTS Texto hacia Palabra (Text-To-Speech).

URL Localizador de Recursos Universales (Universal Resource Locator). 35

VOP Plan de Objetos Vídeo (Video Object Plane).

VRML Lenguaje de Modelización de Realidad Virtual (Virtual Reality Modeling Language).

3. Configuración de cabecera de paquete SL

3.1 Sintaxis

class SLConfigDescriptor extends BaseDescriptor: bit(8)

tag=SLConfigDescrTag { 5

bit(8) predefined;

if (predefined==0) {

bit (1) useAccessUnitStartFlag;

bit (1) useAccessUnitEndFlag;

bit (1) useRandomAccessPointFlag; 10

bit (1) hasRandomAccessUnitsOnlyFlag;

bit (1) usePaddingFlag;

bit (1) useTimeStampsFlag;

bit (1) useIdleFlag;

bit (1) durationFlag; 15

bit (32) timeStampResolution;

bit (32) OCRResolution;

bit (8) timeStampLength; // debe ser < 64

bit (8) OCRLength; // debe ser < 64

bit (8) AU_Length; // debe ser < 32 20

bit (8) instantBitrateLength;

bit (4) degradationPriorityLength;

bit (5) AU_seqNumLength; // debe ser < 16

bit (5) packetSeqNumLength; // debe ser < 16

bit (2) extension_field_control; 25

}

if (durationFlag) {

bit (32) timeScale;

bit (16) accessUnitDuration;

bit (16) compositionUnitDuration; 30

}

if (!useTimeStampsFlag) (

bit(timeStampLength) startDecodingTimeStamp;

bit(timeStampLength) startCompositionTimeStamp;

} 35

if (hasNextAU) {

bit(timeStampLength) nextDecodingTimeStamp;

}

if (extension_field_control==0b10)

{ 5

MarkerDescriptor [0..1] markerDescriptors;

DependencyDescriptor (0..255) dependencyDescriptors;

}

dependencyMarkersCount=0;

while (true) 10

{

bit(1) hasMoreMarkers;

if (!hasMoreMarkers) break;

DependencyMarker dependencyMarkers[dependencyMarkersCount++];

} 15

dependencyDescriptorCount =0;

while (true)

{

bit(1) hasMoreDependencyDescriptor;

if (!hasMoreDependencyDescriptor) break; 20

DependencyDescriptor dependencyDescriptor [dependencyDescriptorCount++];

}

}

3.2 Semántica

La cabecera de paquete SL se puede configurar según las necesidades de cada flujo elemental 25 individual. Los parámetros que se pueden seleccionar comprenden la presencia, la resolución y la precisión de las estampillas temporales y de las referencias de reloj. Esta flexibilidad permite, por ejemplo, un débil aumento del contenido de la cabecera de paquete SL.

Para cada flujo elemental, la configuración se transmite en un SLConfigDescriptor, que forma parte del ES_Descriptor asociado a un descriptor de objeto. 30

Los parámetros configurables, en la cabecera de paquete SL, pueden dividirse en dos clases: los que se aplican a cada paquete SL (por ejemplo, OCR, sequenceNumber) y los que son estrictamente visibles para las unidades de acceso (por ejemplo: estampillas temporales, accessUnitLength, instantBitrate, degradationPriority).

La columna – predefinidos – permite fijar, por defecto, los valores de un conjunto de 35 parámetros predefinidos según se detalla a continuación. Esta tabla podrá actualizarse mediante modificaciones en la norma ISO/IEC 14496 para incluir las configuraciones predefinidas según se exija para los futuros perfiles.

Tabla 1 – Vista de conjunto de los valores predefinidos

Campo de valor predefinido

Descripción

0x00

Clientela (custom)

0x01

Cabecera de paquete SL nula

0x02

Reservado para el uso en los ficheros MP4

0x03 — 0xFF

Reservado para el uso en ISO

Tabla 2 – Detalle de los valores SLConfigDescriptor predefinidos

Campo de valor predefinido

0x01 0x02

UseAccessUnitStartFlag

0 0

UseAccessUnitEndFlag

0 0

UseRandomAccessPointFlag

0 0

UsePaddingFlag

0 0

UseTimeStampsFlag

0 1

UseIdleFlag

0 0

DurationFlag

0 0

TimeStampResolution

1000 -

OCRResolution

- -

TimeStampLength

32 0

OCRlength

- 0

AU_length

0 0

InstantBitrateLength

- 0

DegradationPriorityLength

0 0

AU_seqNumLength

0 0

PacketSeqNumLength

0 0

5

Campo de valor predefinido

0x01 0x02

UseAccessUnitStartFlag

0 0

UseAccessUnitEndFlag

0 0

UseRandomAccessPointFlag

0 0

UsePaddingFlag

0 0

UseTimeStampsFlag

0 1

UseIdleFlag

0 0

DurationFlag

- 0

TimeStampResolution

1000 -

OCRResolution

- -

TimeStampLength

32 0

OCRlength

- 0

AU_length

0 0

InstantBitrateLength

- 0

DegradationPriorityLength

0 0

AU_seqNumLength

0 0

PacketSeqNumLength

0 0

TimeScale

- -

AccessUnitDuration

- -

CompositionUnitDuration

- -

StartDecodingTimeStamp

- -

StartCompositionTimeStamp

- -

useAccessUnitStartFlag — indica que el indicador accessUnitStartFlag está presente en cada cabecera de paquete SL de este flujo elemental.

useAccessUnitEndFlag — indica que el accessUnitEndFlag está presente en cada cabecera de 5 paquete SL de este flujo elemental.

Si no son activos ni useAccessUnitStartFlag ni useAccessUnitEndFlag, ello implica que cada paquete SL corresponde a una unidad de acceso completa.

useRandomAccessPointFlag indica que el RandomAccessPointFlag está presente en cada cabecera de paquete SL de este flujo elemental. 10

hasRandomAccessUnitsOnlyFlag — indica que cada paquete SL corresponde a un punto de acceso aleatorio. En este caso, el randomAccessPointFlag no tiene necesidad de utilizarse.

usePaddingFlag — indica que el paddingFlag está presente en cada cabecera de paquete SL

de ese flujo elemental.

useTimeStampsFlag — indica que las estampillas temporales se utilizan para la sincronización de este flujo elemental. Se transportan a la cabecera de paquete SL. Si no es así, los parámetros accessUnitRate, compositionUnitRate, startDecodingTimeStamp y startCompositionTimeStamp transportados en esta cabecera de paquete SL se deben utilizar para la sincronización. 5

La utilización de estampillas temporales de partida y de duración (useTimeStampsFlag=0) es factible solamente bajo determinadas condiciones, incluyendo un escena sin error. El acceso aleatorio no es fácil.

useIdleFlag — indica que idleFlag se utiliza dentro de este flujo elemental.

durationFlag — indica que la duración constante de las unidades de acceso y de las unidades 10 de composición, para este flujo elemental, se indican con posterioridad.

timeStampResolution — es la resolución de las estampillas temporales en impulsos por segundo.

OCRResolution — es la resolución de la base temporal del objeto en ciclos por segundo.

timeStampLength — es la longitud de los campos de estampilla temporal en la cabecera de 15 paquete SL. timeStampLength debe tomar valores entre cero y 64 bits.

OCRlength — es la longitud del campo objectClockReference en la cabecera de paquete SL. Una serie de ceros indica que algún objectClockReferences no está presente en este flujo elemental. Si OCRstreamFlag está activado, OCRLength debe ser cero. Si no es así, OCRlength debe tomar valores entre cero y 64 bits. 20

AU_Length — es la longitud de los campos accessUnitLength en la cabecera de paquete SL para este flujo elemental. AU_Length debe tomar un valor entre cero y 32 bits.

instantBitrateLength — es la longitud del campo instantBitrate en la cabecera de paquete SL, para este flujo elemental.

degradationPriorityLength — es la longitud del campo degradationPriority en la cabecera de 25 paquete SL para este flujo elemental.

AU_seqNumLength — es la longitud del campo AU_sequenceNumber en la cabecera de paquete SL para este flujo elemental.

packetSeqNumLength — es la longitud del campo packetSequenceNumber en la cabecera de paquete SL para este flujo elemental. 30

timeScale — se utiliza para expresar la duración de las unidades de acceso y de las unidades de composición. Un segundo está igualmente dividido en partes timeScale.

accessUnitDuration — la duración de una unidad de acceso en accessUnitDuration *1/timeScale segundos.

compositionUnitDuration — la duración de una unidad de composición es 35 compositionUnitDuration *1/timeScale segundos.

startDecodingTimeStamp — transporta el tiempo en el que se debe decodificar la primera unidad de acceso de este flujo elemental. Se transporta en la resolución especificada por timeStampResolution.

startCompositionTimeStamp — transporta el tiempo en el que se debe decodificar la unidad de 40 composición correspondiente a la primera unidad de acceso de este flujo elemental. Se transporta en la resolución especificada por timeStampResolution.

extension_field_control – este campo permite extender el SL. El valor 01b0 indica que los descriptores deben encontrarse al final de SLConfigDescriptor.

markerDescriptors — esta tabla indica una descripción de marcadores para identificar las 45 unidades de acceso siguientes en el flujo.

dependencyDescriptors — esta tabla indica los descriptores de dependencia que especifican cómo referenciar las unidades de acceso precedentes o las unidades a recibirse.

4. MarkerDescriptor

La sintaxis es la siguiente:

class MarkerDescriptor extends BaseDescriptor: bit(8) 5

tag=DependencyMarkerTag {

int(5) encodedMarkerLength;

MarkerLength= encodedMarkerLength + 1;

}

5. DependencyDescriptor 10

5.1 Sintaxis

abstract class DependencyDescriptor extends BaseDescriptor 

};

class SimpleDependencyDescriptor extends BaseDescriptor: bit(8) tag=SimpleDependencyTag { 15

bit(2) mode;

bit (5) dependencyLength;

if (mode==1 || mode==0)

{

bit (dependencyLength) firstvalue; 20

{

};

class CompleteDependencyDescriptor extends BaseDescriptor: bit(8) tag=CompleteDependencyTag {

bit (2) mode; 25

bit (16) ESID

bit (5) dependencyLength;

if (mode==1 || mode==0)

{

int (dependencyLength) firstvalue; 30

{

};

5.2 Semántica

5.2.1 Modo

Se definen cuatro modos: 35

- Modo 0: referencia hacia delante por DTS.

- Modo 1: referencia hacia delante por Marcador.

- Modo 2: referencia hacia atrás de escalabilidad.

- Modo 3: modo IPMP.

Los modos 0 y 1 obligan a cada unidad de acceso a hacer referencia a la próxima unidad de acceso. 5

El modo 2 obliga a cada unidad de acceso a hacer referencia a la unidad de acceso precedente, que se necesita para decodificar esta unidad de acceso. (Nota: En numerosos casos, se necesita más de dos dependencydescriptors, para referirse a dos unidades de acceso necesarias o más).

El modo 3 permite, a cada unidad de acceso, contener un identificador opaco, que se puede 10 utilizar por el sistema IPMP, con el fin de decidir si la decodificación y la composición de esta unidad de acceso es posible.

Los modos 1 y 3 requieren un MarkerDescriptor en el flujo.

5.2.2 ESID

Este campo opcional identifica el flujo a que hace referencia el DependencyDescriptor. 15

Para SimpleDependencyDescriptor, ESID se calcula de la manera siguiente:

- Modos 0 y 1 : el flujo corriente.

- Modo 2 : según dependsOnESID

- Modo 3 : no aplicable.

dependencyLength — es la longitud del marcador (si existe) o de la estampilla 20 decodingTimeStamp.

value — es el valor del primer marcador o DTS que identifica la próxima unidad de acceso a decodificar.

6. Especificación de la cabecera de paquete SL

6.1 Sintaxis 25

aligned(8) class SL_PacketHeader (SLConfigDescriptor SL) {

if (SL.useAccessUnitStartFlag)

bit (1) accessUnitStartFlag:

if (SL.useAccessUnitEndFlag)

bit(1) accessUnitEndFlag; 30

if (SL.OCRLength>0)

bit(1) OCRflag;

if (SL.useIdleFlag)

bit(1) idleFlag;

if (SL.usePaddingFlag) 35

bit (1) paddingFlag;

if (paddingFlag)

bit(3) paddingBits;

if (!idleFlag && (!paddingFlag || paddingBits!=0)) {

if (SL.packetSeqNumLength>0)

bit(SL.packetSeqNumLength) packetSeqpenceNumber;

if (SL.degradationPriorityLength>0)

bit (1) DegPrioflag;

if (DegPrioflag) 5

bit(SL.degradationPriorityLength) degradationPriority;

if (OCRflag)

bit(SL.OCRLength) objectClockReference;

if (accessUnitStartFlag) {

if (SL.useRandomAccessPointFlag) 10

bit (1) randomAccessPointFlag;

if (SL.AU_segNumLength >O)

bit(SL.AU_seqNumLength) AU_sequenceNumber;

if (SL.useTimeStampsFlag) {

bit (1) decodingTimeStampFlag; 15

bit (1) compositionTimeStampFlag;

}

if (SL.instantBitrateLength>0)

bit (1) instantBitrateFlag;

if (decodingTimeStampFlag) 20

bit(SL.timeStampLength) decodingTimeStamp;

if (compositionTimeStampFlag)

bit(SL.timeStampLength) compositionTimeStamp;

if (SL.AU_Length > O)

bit(SL.AU_Length) accessUnitLength; 25

if (instantBitrateFlag)

bit(SL.instantBitrateLength) instantBitrate;

}

}

if (SL.hasMarker && beginning0fAU()) 30

{

for (int 1=0; I< markerDescriptorCount;I++)

{

bit(marker.length) markerValue

} 35

}

for (int I=0; I< dependencyDescriptorCount;I++)

{

if (dependencyDescriptor.mode>>1 == O)

{ 5

bit (dependencyDescriptor[I].depLength) dependencyPointerValue;

}

}

}

6.2 Semántica 10

accessUnitStartFlag — cuando vale ‗uno‘, indica que el primer byte de la carga de este paquete SL es la iniciación de una unidad de acceso. Si este elemento de sintaxis se omite de la configuración de la cabecera de paquete SL, su valor por defecto se conoce a partir del paquete SL precedente, según la regla siguiente:

accessUnitStartFlag = (el paquete SL precedente en accessUnitEndFlag=1)?1:0. 15

accessUnitEndFlag — cuando vale ‗uno‘, indica que el ultimo byte de la carga de paquete SL es el último byte de la unidad de acceso en curso. Si este elemento de sintaxis se omite de la configuración de la cabecera de paquete SL, su valor por defecto es solamente conocido después de la recepción del paquete SL según la regla siguiente:

accessUnitEndFlag = (el paquete SL siguiente a accessUnitStartFlag==1)?1:0. 20

Si no están configurados ni AccessUnitStartFlag ni AccessUnitEndFlag en la cabecera del paquete SL, ello indica que cada paquete SL corresponde a una sola unidad de acceso, de donde cada accessUnitStartFlag = accessUnitEndFlag = 1.

Se observará, cuando la cabecera del paquete SL está configurada para utilizar accessUnitStartFlag pero no lo están ni accessUnitEndFlag ni accessUnitLength, no está garantizado 25 que el terminal pueda determinar el final de una unidad de acceso antes de que se haya recibido la siguiente.

OCRflag – cuando vale ‗uno‘, indica que seguirá un objectClockReference. El valor por defecto para OCRflag es cero.

idleFlag – indica que este flujo elemental será inactivo (es decir, con ausencia de datos útiles) 30 para un intervalo de tiempo indeterminado. Este signo se puede utilizar por el decodificador para establecer la distinción entre una ausencia intencionada y una ausencia debida a un error de paquetes SL siguientes.

paddingFlag – indica la presencia de relleno en este paquete SL. El valor por defecto para paddingFlag es cero. 35

paddingBits – indica el modo de datos de relleno a utilizar en este paquete SL. El valor por defecto para paddingBit es cero.

Si paddingFlag se activa y paddingBits vale cero, ello indica que la carga siguiente de este paquete SL consiste solamente en bytes de relleno. accessUnitStartFlag, randomAccessPointFlag y OCRflag no deben omitirse si paddingFlag está activado y paddingBits es cero. 40

Si paddingFlag se activa y paddingBits es superior a cero, ello indica que la carga de este paquete SL es seguida por paddingBits, formados de bits de cero para la alineación de los bytes de la carga.

packetSequenceNumber – si está presente, debe aumentarse continuamente para cada paquete SL como un contador de módulo. Una discontinuidad en el decodificador corresponde a uno o 45

varios paquetes SL que faltan. En este caso, se debe señalar un error a la capa de sincronización. Si este elemento de sintaxis se omite de la configuración de la cabecera de paquete SL, el control de la continuidad de las unidades de flujo por la capa de sincronización no puede realizarse para este flujo elemental.

Duplicación de paquetes SL: los flujos elementales que tienen un campo sequenceNumber 5 en sus cabeceras de paquetes SL deben utilizar la duplicación de los paquetes SL para la recuperación de los errores. Los paquetes SL duplicados deben seguir inmediatamente al original. El packetSequenceNumber de los paquetes SL duplicados debe tener el mismo valor y cada byte del paquete SL original se debe duplicar, con la excepción de un campo objectClockReference, si está presente, que debe codificar un valor válido para el paquete SL duplicado. 10

degPrioFlag — cuando vale ‗uno‘, indica que la degradationPriority está presente en este paquete.

degradationPriority — indica la importancia de la carga de este paquete SL. El streamPriority define la prioridad de base de un ES. degradationPriority define una baja de prioridad para este paquete SL con respecto a la prioridad de base. La prioridad para este paquete SL viene dada por: 15

SL_PacketPriority=streamPriority—degradationPriority

degradationPriority permanece en este valor hasta la próxima ocurrencia. Esta indicación se puede utilizar por el decodificador de flujo elemental así como por el adaptador para un caso de una capa de distribución específica. La proporción de la degradación entre los paquetes SL de diferentes flujos elementales aumenta a medida que disminuye SL_PacketPriority. 20

objectClockReference — contiene una estampilla temporal objeto. El valor temporal OTB se reconstruye a partir de esta estampilla temporal OCR según la fórmula siguiente:

t = (objectClockReference/SL.OCRResolution)+ k*(2SL. OCRLength/SL.OCRResolution)

en donde k es el tiempo que el contador objectClockReference ha cubierto.

objectClockReference está solamente presente en la cabecera del paquete SL si está activado 25 el indicador OCRflag.

Es posible transportar solamente un valor OCR sin carga en el interior de un paquete SL.

A continuación se presenta la semántica de los elementos que sintaxis que están solamente presentes al principio de una unidad de acceso cuando se señala explícitamente por accessUnitStartFlag en el flujo binario: 30

randomAccessPointFlag — cuando vale ‗uno‘, indica que es posible el acceso al contenido de este flujo elemental. randomAccessPointFlag debe únicamente activarse si se activa accessUnitStartFlag. Si este elemento de sintaxis se omite de la configuración de la cabecera de paquetes SL, su valor por defecto es el valor de SLConfigDescriptor.hasRandomAccessUnitsOnlyFlag para este flujo elemental. 35

AU_sequenceNumber – si está presente, se debe aumentar continuamente para cada unidad de acceso como un contador módulo. Una discontinuidad en el decodificador corresponde a una o varias unidades de acceso que faltan. En este caso, se debe señalar un error al usuario de la capa de sincronización. Si este elemento de sintaxis se omite de la configuración de la cabecera de paquete SL, el control de la continuidad de las unidades de flujo, por la capa de sincronización, no se puede ejecutar 40 para este flujo elemental.

Duplicación de las unidades de acceso: las unidades de acceso enviadas utilizando el mismo número de secuencias que la AU inmediatamente precedente deben ser ignoradas. Una tal unidad de acceso duplicada, cuyo original no tenga RAP activado, pero si lo tenga la unidad duplicada, permite la adición de puntos de acceso aleatorio en un flujo emitido, que permite a los clientes entrar en 45 el flujo en puntos definidos, durante su transmisión, mientras que otros clientes reciben ya el flujo.

decodingTimeStampFlag – indica que una estampilla temporal de decodificación está presente en este paquete.

compositionTimeStampFlag – indica que una composición de estampilla temporal está presente en este paquete. 50

accessUnitLengthFlag – indica que la longitud de esta unidad de acceso está presente en este paquete.

instantBitrateFlag – indica que un instantBitrate está presente en este paquete.

decodingTimeStamp – es una estampilla temporal de decodificación según se configura en el SLConfigDescriptor asociado. El tiempo de decodificación td de esta unidad de acceso se reconstruye a 5 partir de esta estampilla temporal de decodificación, según la fórmula:

td=(decodingTimeStamp/SL.timeStampResolution + k* 2SL.timeStampLength/SL.timeStampResolution

en donde k es el tiempo que ha englobado el contador decodingTimeStamp.

Un decodingTimeStamp debe estar únicamente presente si el tiempo del decodificador es diferente de la composición temporal para esta unidad de acceso. 10

compositionTimeStamp – es una composición de estampilla temporal según se configura en el SLConfigDescriptor asociado. La composición temporal tc de la primera unidad de composición resulta del hecho de que esta unidad de acceso está reconstruida a partir de esta composición de estampilla temporal según la fórmula:

td = (compositionTimeStamp/SL.timeStampResolution + 15

k*2SL.timeStampLength/SL.timeStampResolution

en donde k es el tiempo que ha englobado el contador compositionTimeStamp.

accessUnitLength — es la longitud de la unidad de acceso expresada en bytes. Si este elemento de sintaxis no está presente o tiene el valor, la longitud de la unidad de acceso es desconocida.

instantBitrate — es la tasa binaria instantánea en bits por segundo de este flujo elemental hasta 20 que se encuentre el próximo campo instantBitrate.

markerValue — es la valor de un marcador que permite identificar la unidad de acceso. Este marcador se define si existe markerDescriptors.

DependencyPointerValue — es un índice de DTS o de un marcador según se define por el DependencyDescriptor. MarkerDescriptorCount: el número de descriptores de marcadores. 25

DependencyDescriptorCount: el número de descriptores dependientes.

7. Semántica de decodificación

7.1 Mecanismo de referencia hacia delante (modos 0 y 1)

El SLConfigDescriptor asociado a un ES, indica la primera unidad de acceso que permite entrar en el flujo. 30

Si el modo de referencia es DTS, entonces el SLConfigDescriptor debe contener una estampilla decodingTimeStamp.

Si no es así, se utiliza un marcador para señalar cada unidad de acceso. 0 y -1 tienen un significado especial:

//0 significa que seguirá alguna otra unidad de acceso, 35

//-1 significa que no importa qué unidad de acceso pueda utilizarse.

Cada unidad de acceso debe contener un marcador y un puntero de dependencia que permita a cada unidad de acceso indicar la próxima unidad de acceso.

7.2 Mecanismo de referencia hacia atrás (modo 2)

El SLConfigDescriptor definirá n descriptores de tipo DependencyDescriptor, que indicarán las 40 unidades de acceso en el ES al que se refiere ESID.

Cada unidad de acceso del flujo corriente apuntará hacia las unidades de acceso en el ES cuyo identificador es ESID denominado ES_base por medio de los DependencyPointers con referencia a las

unidades de acceso de ES_base (identificado por ESID) a través de sus DTS.

7.3 Modo IPMP (modo 3)

Los punteros DependencyPointers se transmiten al sistema IPMP antes de la decodificación. Estos punteros opacos permiten a los medios IPMP decidir si es posible, o no, decodificar la unidad de acceso. Puede proporcionar una respuesta negativa si no se han recibido las claves o si los derechos no 5 lo permiten. Este puntero de dependencia está vinculado a la unidad de composición después de la decodificación.

Volverá al sistema IPMP antes de la composición, decidiendo, a continuación, los medios IPMP si la unidad puede ser, o no, presentada.

8. Flujo de referencia de reloj 10

Un flujo elemental de streamType = ClockReferenceStream debe declararse por medio del descriptor de objeto. Se utiliza con el objeto de transportar las estampillas temporales de referencia de reloj objeto. Múltiples flujos elementales, en un conjunto de nombres, pueden hacer referencia a un tal flujo ClockReferenceStream por medio del elemento de sintaxis OCR_ES_ID en el SLConfigDescriptor para evitar la transmisión repetida de la información de referencia de reloj. Observemos, sin embargo, 15 que no están permitidas referencias circulares entre los flujos elementales utilizando OCR_ES_ID.

En la capa de sincronización, se realiza un flujo ClockReferenceStream configurando la sintaxis de la cabecera del paquete SL para este flujo empaquetado a nivel SL, de tal manera que solamente los valores OCR de OCRresolution y de OCRlength requeridos estén presentes en la cabecera del paquete SL. 20

No existe ninguna carga de paquete SL presente en un flujo empaquetado–SL de streamType=ClockReferenceStream.

En el DecoderConfigDescriptor para un flujo de referencia de reloj, ObjectTypeIndication debe ponerse en ‗0xFF‘, tiene RandomAccessUnitsOnlyFlag en ‗uno‘ y bufferSizeDB en ‗0‘.

A continuación, se indican los valores recomendados para el SLConfigDescriptor de un flujo de 25 referencia de reloj:

Tabla 3 – Valores de SLConfigDescriptor de los parámetros de SLConfigDescriptor de uno para un flujo de ClockReferenceStream

useAccessUnitStartFlag

0

useAccessUnitEndFlag

0

useRandomAccessPointFlag

0

usePaddingFlag

0

useTimeStampsFlag

0

useIdleFlag

0

durationFlag

0

timeStampResolution

0

timeStampLength

0

AU_length

0

degradationPriorityLength

0

AU_seqNumLength

0

9. Restricciones para flujos elementales que compartan el mismo objeto de base temporal

Cuando es posible compartir un objeto de base temporal entre varios flujos elementales a través de OCR_ES_ID, existen varias restricciones para el acceso a estos flujos elementales y a su tratamiento, como sigue:

Cuando varios flujos elementales comparten un simple objeto de base temporal, los flujos 5 elementales, sin información de referencia de reloj objeto integrada, no se deben utilizar por el terminal aunque sean accesibles, hasta que el flujo elemental que transporta la información de referencia de reloj objeto se haga accesible.

Si un flujo elemental, sin información de referencia de reloj objeto integrada, se hace disponible en el terminal después del flujo elemental que transporta la información de referencia de reloj objeto, 10 debe entregarse en sincronización con los demás flujos. Observemos que ello implica que un tal flujo no debe entregarse desde su principio, en función del valor corriente del objeto de base temporal.

Cuando un flujo elemental que transporta una información de referencia de reloj objeto se hace indisponible o está utilizado por otro lado (por ejemplo, en pausa), todos los demás flujos elementales, que utilizan el mismo objeto de base temporal, deben seguir este método, es decir, hacerse indisponibles 15 o manipularse en el mismo sentido.

Cuando un flujo elemental, sin información de referencia de reloj objeto integrada, se hace indisponible, ello no tiene influencia sobre los demás flujos elementales que comparten el mismo objeto de base temporal.

10. Utilización de las opciones de configuración para las referencias de reloj y los valores de 20 estampillas temporales

10.1 Resolución de la ambigüedad en la recuperación de un objeto de base temporal

Debido a la longitud limitada de los valores objectClockReference, estas estampillas temporales pueden ser ambiguas. El valor temporal OTB se puede reconstruir cada vez que un objectClockReference se transmita en las cabeceras de un paquete SL según la fórmula siguiente: 25

tOTB_reconstructed=(objectClockReference/SL.OCRResolution) + k*(2SL.OCRLength/SL.OCRResolution)

siendo k un valor entero que indica el número de bucles. La base temporal resultante tOTBreconstructed se mide en segundos.

Cuando se adquiere el primer objectClockReference para un flujo elemental, el valor k debe ponerse a ‗uno‘. Para cada ocurrencia siguiente de objectClockReference, el valor k se estima como 30 sigue:

El terminal debe comprender medios para estimar el valor del objeto de base temporal en cada instante.

Cada vez que se recibe un objectClockReference, el valor estimado corriente del OTB TOTB_estimated debe ser objeto de muestreo. Entonces, tOTB_rec(k) se evalúa para diferentes valores de k. El 35 valor k que minimiza el término tOTB_estimated – tOTB_rec(k)| se debe considerar como el valor correcto de tOTB_reconstructed. Este valor se debe utilizar como una nueva aportación al mecanismo de estimación del objeto de base temporal.

La aplicación debe garantizar que este procedimiento proporcione un valor no ambiguo de k seleccionando una longitud y una resolución adecuadas de elemento objectClockReference y una 40 frecuencia suficientemente elevada de los valores de inserción de objectClockReference de los valores de flujo elemental. Las elecciones para estos valores dependen de la giga de entrega para los paquetes SL así como la desviación máxima prevista entre las señales de reloj del terminal transmisor y receptor.

10.2 Resolución de la ambigüedad en la recuperación de la estampilla temporal

Debido a la longitud limitada de los valores de decodingTimeStamp y compositionTimeStamp, 45 estas estampillas temporales pueden llegar a ser ambiguas, como lo demuestra la fórmula siguiente:

tts(m)=(TimeStamp/SL.timeStampResolution)+m* (2SL.timeStampLength/SL.timeStampResolution)

con TimeStamp siendo una decodingTimeStamp o una compositionTimeStamp y siendo m un valor

entero que indica el número de bucles.

El valor correcto ttimestamp de la estampilla temporal se puede estimar como sigue:

Cada vez que se recibe un TimeStamp, el valor estimado corriente del OTB tOTB_estimated debe ser objeto de muestreo.
tts (m) se evalúa para diferentes valores de m. El valor m que minimiza el término tOTB_estimated - tts(m)| se considera como el valor correcto de ttimestamp. 5

La aplicación puede elegir, por separado para cada flujo elemental individual, la longitud y la resolución de las estampillas temporales, con el fin de respetar sus exigencias sobre el posicionamiento no ambiguo de los hechos temporales. Esta elección depende del tiempo máximo durante el cual se puede enviar un paquete SL con un TimeStamp, después del momento indicado por el TimeStamp, así como la precisión exigida al posicionamiento temporal. 10

10.2 Observaciones sobre el uso de las referencias de reloj objeto y de las estampillas temporales

La línea temporal de una base de tiempos objeto permite distinguir dos instantes separados por más de 1/SL.OCRResolution. OCRResolution debe elegirse suficientemente grande para obtener la precisión de la que tiene necesidad la aplicación para sincronizar un conjunto de flujos elementales.

Las estampillas temporales y de composición permiten distinguir dos instantes separados por 15 más de 1/SL.timeStampResolution. timeStampResolution debe elegirse suficientemente grande para obtener la precisión de la que tiene necesidad la aplicación en términos de identificación de las unidades de acceso para un flujo elemental dado.

Un TimeStampResolution más elevado que el OCRResolution no permitirá obtener una mejor discriminación entre los hechos. Si TimeStampResolution es más pequeña que OCRResolution, los 20 hechos operativos para este flujo específico no pueden identificarse con la precisión máxima posible con esta OCRResolution dada.

El parámetro OCRLength se indica en la configuración de la cabecera SL. El 2SL.OCRLength/SL.OCRResolution es el intervalo de tiempo cubierto por el contador objectClockReference antes del bucle. OCRLength debe elegirse suficientemente elevado para respetar las necesidades de la 25 aplicación para un posicionamiento no ambiguo de los hechos temporales para un conjunto de flujos elementales.

Cuando una aplicación conoce el valor k definido más alto, la línea temporal OTB es clara para cada valor temporal. Cuando la aplicación no puede reconstruir el factor k, como por ejemplo en una aplicación que permita el acceso aleatorio sin información complementaria, la línea temporal OTB es 30 ambigua entre módulo 2SL.OCRLength/SL.OCRResolution. De este modo, cada estampilla temporal, que hace referencia a este OTB, es ambigua. Sin embargo, se puede considerar clara en el interior de un entorno de aplicación a través del conocimiento de la giga máxima supuesta y de las limitaciones sobre la duración durante la cual se puede enviar una entidad de acceso antes de su instante de decodificación. 35

Hagamos la observación de que los flujos elementales, que eligen un intervalo de tiempo 2SL.timeStampLength/SL.timeStampResolution superior a 2SL.OCRLength/SL.OCRResolution solamente pueden identificar, de forma no ambigua, los hechos temporales en el más pequeño de los dos intervalos.

En algunos casos, cuando k y m no se pueden estimar de forma correcta, el modelo de almacenamiento intermedio se puede transgredir, lo que trae consigo operaciones y resultados 40 imprevisibles del decodificador.

Por ejemplo, si se considera una aplicación que desea sincronizar los flujos elementales con una precisión de 1 ms, OCRResolution debe elegirse igual o superior a 1000 (el tiempo entre dos impulsos sucesivos del OCR es entonces igual a 1 ms). Supongamos OCRResolution=2000.

La aplicación supone una giga entre el STB y el OTB del 0,1 % (es decir, 1 ms por segundo). 45 Los relojes deben ajustarse, por consiguiente, al menos cada segundo (es decir, en el caso más desfavorable, que los relojes se hubieran desviado en 1 ms, lo que es la limitación de precisión). Supongamos que se envían objectClockReference cada 1 segundo.

La aplicación desea tener una línea temporal OTB clara de 24h sin tener necesidad de reconstruir el factor k. En tal caso, el OCRLength se elige, como consecuencia, lo mismo que 50 2SL.OCRLength/SL.OCRResolution=24h.

Supongamos ahora que la aplicación desea sincronizar los hechos en el interior de un flujo elemental solamente con la precisión de 10 ms. TimeStampResolution debe elegirse igual o superior a 100 (el tiempo entre dos impulsos sucesivos del TimeStamp es entonces igual a 10 ms). Supongamos TimeStampResolution=200.

La aplicación desea ser capaz de enviar las unidades de acceso en un máximo de 1 minuto 5 antes de su tiempo de decodificación o de composición. En ese caso, el timeStampLength se elige como 2SL.

timestampLength/SL.timeStampResolution = 2 minutos.

Claims (17)

1. REIVINDICACIONES

   1.- Procedimiento de transmisión de al menos un flujo de datos multimedia hacia al menos un terminal, estando dichos flujos organizados en unidades de acceso, caracterizado porque al menos algunas de dichas unidades de acceso comprenden al menos un puntero que designa al menos una unidad de acceso, anterior o posterior, de dicho flujo o de otro flujo de datos multimedia, la denominada 5 unidad de dependencia,

   de forma que un tratamiento de dicha unidad de acceso no sea efectuado, en dicho terminal, si no se han recibido dichas unidades de dependencia.
2. 2.- Procedimiento de transmisión según la reivindicación 1, caracterizado porque comprende la transmisión de al menos dos flujos de datos multimedia transmitidos por separado, una unidad de acceso 10 de un primer flujo que apunta hacia al menos una unidad de dependencia de al menos un segundo flujo, comprendiendo dicha unidad de acceso del primer flujo datos de enriquecimiento de los datos contenidos en dichos segundos flujos.
3. 3.- Procedimiento de transmisión según la reivindicación 2, caracterizado porque dichos flujos de datos multimedia corresponden a niveles jerárquicos diferentes de una codificación jerárquica, 15 efectuándose solamente el tratamiento de una unidad de acceso de un nivel jerárquico dado si se han recibido las unidades de acceso de los niveles jerárquicos inferiores correspondientes.
4. 4.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 2 y 3, caracterizado porque dicha unidad de acceso apunta sobre al menos una unidad de dependencia, definiendo una secuencia de unidades de dependencia. 20
5. 5.- Procedimiento de transmisión, según una cualquiera de las reivindicaciones 1 a 4, caracterizado porque al menos uno de dichos punteros permite encontrar al menos una unidad de dependencia que comprende datos que permiten la decodificación y/o la desencriptación de la unidad de acceso considerada.
6. 6.- Procedimiento de transmisión según la reivindicación 5, caracterizado porque dichas 25 unidades de dependencia comprenden datos que permiten a un terminal decidir si los datos de una unidad de acceso considerada se deben decodificar y/o desencriptar y luego visualizarse después de la decodificación.
7. 7.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 6, caracterizado porque al menos uno de dichos punteros apuntan hacia datos susceptibles de conocerse 30 de dicho terminal, de forma que este último pueda decidir sobre su capacidad o su incapacidad para tratar la unidad de acceso correspondiente.
8. 8.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 7, caracterizado porque al menos una de dichas unidades de acceso comprende al menos un puntero que designa al menos una unidad de acceso de dicho flujo o de otro flujo, susceptible de recibirse 35 próximamente.
9. 9.- Procedimiento de transmisión según la reivindicación 8, caracterizado porque dichas unidades de acceso, susceptibles de recibirse próximamente poseen un marcador que permite establecer un vínculo con dichos punteros.
10. 10.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 8 y 9, 40 caracterizado porque los punteros de al menos dos unidades de acceso similares, transmitidas en instantes distintos, apuntan hacia una misma unidad de acceso susceptible de recibirse próximamente.
11. 11.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 10, caracterizado porque pone en práctica un indicador que señala la función de los punteros, entre al menos dos de las funciones pertenecientes al grupo que comprende: 45

    - designación de al menos una unidad de acceso de dependencia antes de ser decodificada para permitir la toma en consideración de la unidad de acceso considerada,

    - designación de al menos una unidad de acceso de dependencia que comprende datos necesarios para la decodificación y/o desencriptación de la unidad de acceso considerada y/o de una referencia a un estado de un sistema de protección; 50

    - designación de al menos una unidad de acceso posterior.
12. 12.- Procedimiento de transmisión según la reivindicación 11, caracterizado porque al menos algunas de dichas unidades de acceso comprenden un descriptor de dependencia, que define dicha función.
13. 13.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 12, caracterizado porque al menos algunas de dichas unidades de acceso comprenden un marcador de 5 dependencia, que permite su identificación en tanto como unidad de dependencia.
14. 14.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 13, caracterizado porque al menos algunas de dichas unidades de acceso comprenden un marcador de identificación de dicha unidad de dependencia en dicho flujo.
15. 15.- Procedimiento de transmisión según una cualquiera de las reivindicaciones 1 a 14, 10 caracterizado porque se pone en práctica al nivel de sincronización, de forma que no sea necesario ningún tratamiento previo de una unidad de acceso.
16. 16.- Flujo de datos multimedia organizado en unidades de acceso transmitidas con independencia entre sí, caracterizado porque al menos algunas de dichas unidades de acceso comprenden al menos un puntero que designa al menos una unidad de acceso, anterior o posterior, de 15 dicho flujo o de otro flujo susceptible de haber sido recibida con anterioridad, en un terminal, la denominada unidad de dependencia.
17. 17.- Terminal adecuado para recibir al menos un flujo de datos multimedia organizado en unidades de acceso transmitidas independientemente entre sí, caracterizado porque al menos algunas de dichas unidades de acceso comprenden al menos un puntero que designa al menos una unidad de 20 acceso, anterior o posterior, de dicho flujo o de otro flujo de datos multimedia susceptible de haber sido recibida con anterioridad, en un terminal, la denominada unidad de dependencia.