MXPA04000219A - METODO PARA LA COMPRESION DE UN áRBOL JERáRQUICO, SENALES CORRESPONDIENTES Y METODO PARA LA DECODIFICACION DE LA SENAL. - Google Patents

Abstract

La invencion se refiere a un metodo para la compresion de un arbol jerarquico que describe una senal multimedia, dicho arbol comprendiendo nodos y hojas, que pueden estar asociados a contenidos de cuando menos dos distintos tipos. De acuerdo con la invencion, dicho metodo implementa una compresion de contenido para cuando menos algunas de dichas hojas por medio de cuando menos dos tecnicas de codificacion de compresion, cada una de dichas tecnicas estando asociada de manera selectiva a cuando menos uno de dichos tipos de contenido.

Description

MÉTODO PARA LA COMPRESIÓN DE UN ÁRBOL JERÁRQUICO, SEÑALES CORRESPONDIENTES Y MÉTODO PARA LA DECODIFICACIÓN DE LA SEÑAL Campo de la Invención El campo de la invención es aquel de la compresión de información. Más precisamente, la invención tiene que ver con la compresión de documentos basados en XML ( "Lenguaje de Marca Extendido" "eXtended Markup Language").

Antecedentes de la Invención La invención tiene aplicaciones, en particular, pero no únicamente, en los siguientes campos: aplicaciones multimedia; herramientas de indexación; - herramientas de manipulación de meta-datos; - la especificación MPEG-7; - SMIL; - TV todo el tiempo; - La tercera generación de radiocomunicaciones (3GPP). Las metodologías de compresión de la técnica anterior para XML tienen varios inconvenientes. En particular, dichas técnicas no soportan al mismo tiempo el acceso rápido a la información, altas relaciones de compresión y la construcción progresiva del documento. En otras palabras, la mayor parte del tiempo, cuando alguna de las características mencionadas anteriormente es soportada, todas las demás características están faltando. Una de las técnicas de compresión de la técnica anterior se conoce como BiM (MPEG Binario). Tal técnica provee un método para comprimir un documento XML binarizando la estructura del documento, es decir los nodos de una estructura de árbol asociada al documento XML. De aquí que, la relación de compresión lograda por la implementación de la técnica BiM es muy deficiente, no obstante la técnica BiM permite un acceso rápido a los datos, la construcción progresiva del documento y posibilidad de dar saltos.

Objetivos de la Invención. Un objetivo de la invención es el de compensar los inconvenientes de las metodologías de la técnica anterior. Más precisamente, la invención apunta a proporcionar una técnica de compresión eficiente para documentos basados en XML. La invención también apunta a proporcionar una técnica de compresión para XML larcual proporcione posibilidad de dar saltos, altas relaciones de compresión y la construcción progresiva del documento. La invención también apunta a la posibilidad de comprimir eficientemente los descriptores MPEG-7. Otro objetivo de la invención es el de implementar un método para comprimir un documento XML que mejore enormemente la relación de compresión proporcionada por una técnica de tipo BiM, pero que dé las mismas funcionalidades que proporciona la técnica BiM. Los objetivos de la invención que fueron mencionados anteriormente, así como también otras metas de la invención que aparecerán más adelante, se consiguen, de acuerdo con la presente invención, por medio de un método para la compresión de un árbol jerárquico qué describe una señal multimedia, dicho árbol comprende nodos y hojas, las cuales pueden asociarse a contenidos de al menos dos tipos diferentes, en donde dicho método implementa una compresión de contenido para al menos algunas de dichas hojas por medio de al menos dos técnicas de codificación de la compresión, estando cada una de las técmcas mencionadas selectivamente asociada con al menos uno de dichos tipos de contenido. De acuerdo con una modalidad preferida de la invención, tal método consta de un paso de identificar al menos un sub-árbol y de un paso de asignación de una de dichas técnicas de codificación de la compresión a dicho sub-árbol. Ventajosamente, tal método comprende una etapa de implementación de dicha técnica de codificación de la compresión asignada a dicho sub-árbol solamente para las hojas de dicho sub-árbol cuyo contenido es del tipo asociado a dicha técnica de codificación de la compresión, y las otras hojas de dicho sub-árbol no experimentan ninguna codificación de la compresión.

De acuerdo con una característica ventajosa de la presente invención, dicho método implementa una descripción paramétrica de dichas técnicas de codificación de la compresión. Preferentemente, tal método también incluye una etapa de compresión de la estructura de dicho árbol. Ventajosamente, dicho árbol es del tipo BiM (MPEG Binario) de acuerdo con el estándar MPEG7. Preferentemente una de dichas técnicas de codificación de la compresión implementa la cuantización lineal. Ventajosamente, una de dichas técnicas de codificación de la compresión implementa un algoritmo de compresión estadístico. Preferentemente, dicho algoritmo es del tipo GZip. Ventajosamente, dicho algoritmo es simultáneamente implementado para un conjunto de datos correspondientes al contenido de al menos dos hojas. Preferentemente, dicho árbol representa la estructura de un documento tipo XML (Extended Markup Language). La invención también considera un método para decodificar una señal multimedia comprimida de acuerdo con el método mencionado anteriormente para comprimir un árbol jerárquico. Ventajosamente, tal método implementa una etapa de recarga de un contexto de decodificación presente de acuerdo con la información de contexto de codificación transportada por dicha señal. Preferentemente, dicho contexto presente define cuando menos un tipo de contenido, dicho método comprendiendo una etapa de implementación de una técnica de decodificación de la compresión asociada a dicho tipo de contenido para las hojas que tienen un contenido de dicho tipo de contenido. La invención también tiene que ver con una señal generada por el método mencionado anteriormente para comprimir un árbol jerárquico.

Breve Descripción de los Dibujos Otras características y ventajas de la invención aparecerán más claramente a la luz de la siguiente descripción, dada como un mero ejemplo ilustrativo pero no restrictivo, y de las siguientes figuras: La Figura 1 ilustra el concepto de codificación de contexto; La Figura 2 describe la estructura de un elemento codificado según la técnica BiM; La Figura 3 ilustra algunos de los pasos implementados de acuerdo con la invención para comprimir el contenido de las hojas de un árbol jerárquico.

Descripción Detallada de las Modalidades Preferidas Antes de describir en detalle cómo implementar la invención, primero recordamos las principales características de la metodología de compresión de la técnica anterior, conocida como la técnica BiM. Para facilitar la comprensión del documento, algunas referencias son reunidas en el anexo 9 y referenciadas a través de todo el documento. Todos los anexos proporcionados con el documento presente son parte de la presente descripción de la invención. 1. Método anterior Introducción Un contexto de codificación, ilustrado en la Figura 1, es un conjunto de información de decodificación, necesaria durante la decodificación del flujo de bits. Un contexto de codificación es aplicable a todo el sub-árbol del nodo donde está definido. En todos los nodos del árbol, el contexto de codificación puede ser modificado; llevando a la creación de un nuevo contexto de codificación, aplicable al correspondiente sub-árbol. Un contexto puede llevar varia información la cual anuncia características aplicables al sub-árbol concerniente. Actualmente, en el formato de codificación del sub-árbol BiM [1], estas características son la posibilidad de saltar de un sub-árbol/contexto y esquema de codificación múltiple de un sub-árbol/contexto (con el fin de proporcionar la característica de compatibilidad hacia adelante y hacia atrás). Al final, el mecanismo de contexto puede ser deshabilitado en cada sub-árbol con el fin de ahorrar ancho de banda; este es el modo congelado del contexto.

El mecanismo de contexto de codificación proporciona flexibilidad máxima en cada sub-árbol de un árbol documento y permite características extensibles para ser insertadas dentro del mecanismo de codificación BiM. Presentamos ahora el mecanismo de contexto actual usado en BiM. Mecanismo de contexto de codificación actual Definiciones CodingContext Un codingContext es un conjunto de información, la información contextual, necesitada por el decodificador para decodificar el flujo de bits. Un codingContext es aplicable al nodo donde lia sido definido, y la totalidad de sub-árbol correspondiente a este nodo. El actual codingContext, (esto es, el contexto aplicable a un nodo especificado de una descripción) puede ser modificado dentro del documento (es decir, una modificación de su conjunto subyacente de información). Cada modificación de un codingContext lleva a la creación de un nuevo codingContext, el cual llevará el conjunto modificado de información. Se espera que todos los codingContext se vayan apilando, para recuperarlos, cuando el decodificador ha terminado de decodificar un contexto correspondiente a un sub-árbol. Decodificador El decodificador 'BiM está compuesto por dos decodificadores: - el decodificador de contexto; este decodificador está dedicado a decodificar la información contextual. Como se mencionó antes, la información contextual no es parte de la descripción. Este es un conjunto de información el cual lleva algunas características externas, compatibilidad hacia adelante y hacia atrás, saltos rápidos... - el elemento decodificador; este decodificador, el BiM normal [1] está dedicado a decodificar la información del elemento. Bloques Cada elemento de una descripción es codificado como la tripleta ilustrada en la Figura 2, donde la parte del encabezado está constituida por dos bloques, cuyos tamaños pueden ser nulos: - MC es el bloque de metacontexto; - C es el bloque de contexto; - Elemento es el bloque de elemento, el cual es el bloque de codificación del elemento regular, ver [1]. El bloque de metacontexto MC contiene información requerida por el decodificador para decodifícar el bloque C siguiente. Es decir que el bloque MC es el bloque de contexto del bloque de contexto C. El bloque de contexto C contiene la información capaz de cambiar el conjunto de información de contexto de codificación actual, y requerido por el decodificador para decodifícar el siguiente bloque de elemento. Es decir que el bloque C es el bloque de contexto del bloque de elemento. Conjunto de información El actual contexto de codificación BiM lleva un conjunto de información, la información contextual, la cual puede ser dividida en las dos siguientes clases principales: la sección metacontexto; si la información contenida en esta sección, influye sólo en el proceso de decodificación de contexto. - la sección de contexto; si la información contenida en esta sección, influye solamente el proceso de decodificación del elemento El actual conjunto de información es el siguiente conjunto de variables: Clase Variable Valor Descripción Metacontexto freezing_state boleano Falso: el contexto puede ser cambiado dentro de éste sub- árbol. Verdadero: el contexto ya no puede ser cambiado en éste sub-arbol. Contexto allows_skip (obligatorio, ¿La característica de salto es opcional, obligatoria, opcional o prohibido) prohibida en este contexto? schema_mode (mono,multi) ¿El elemento actual está codificado con múltiples esquemas? allows__partial_instantiation boleano ¿La instantaneidad parcial es permitida en este contexto? allows_subtyping boleano ¿Es el subgénero permitido en este contexto? Las clases definidas están codificando exactamente los bloques descritos arriba (el bloque de metacontexto MC y el bloque de contexto C). Bloque de metacontexto Definición El bloque de metacontexto MC, cuyo tamaño puede ser nulo, contiene información para saber si el decodificador tiene que leer el siguiente bloque de contexto C, descrito en la siguiente sección.

Variables relacionadas Valores implícitos (o por defecto) El valor implícito de freezing_state es falso; es decir que, por defecto, el contexto raíz puede ser dinámicamente cambiado. Reglas de propagación En la creación de un nuevo contexto : - el valor freezing_state es puesto en el valor freezing_state del contexto padre. Reglas de modificación dinámica En cada nodo de una descripción y con el fin de crear un nuevo contexto: - el valor freezing_state puede ser cambiado del valor falso al valor verdadero. Reglas de decodificación Si el valor freezing_state es verdadero, el bloque de metacontexto MC (y el bloque de contexto C próximo) no es codificado en el flujo de bits. De lo contrario, la parte del encabezado del bloque de metacontexto MC se codifica como sigue: MC O { # de bits Mnemónico freeze_type 1-3 vlclbf } El context_chunk es una variable local, inicializada en falso.

Como se estableció en la sección previa, la modificación de las variables del contexto actual implica la creación de un nuevo contexto. Influencia en el proceso de decodificación de contexto Si el valor context_chunk es verdadero, el decodificador tiene que leer el siguiente bloque de contexto C. Bloque de contexto Deñnición El bloque de contexto C, cuyo tamaño puede ser nulo, contiene un conjunto de información capaz de cambiar dinámicamente las variables del contexto actual. Estas variables son llamadas Propiedades de codificación (codingProperties) debido a que influencian el proceso de decodificación del elemento BiM. Propiedades de Codificación implicadas Propiedad de Codificación Valor Descripción Allows_skip (obligatorio, opcional, ¿La caracterísrica de salto es prohibido) obligatoria, opcional o prohibida en este contexto? Schema_mode (mono, multi) ¿El elemento actual está codificado con esquemas múltiples? Allo s_partial_instantiation boleano ¿La instantaneidad parcial es permitida en este contexto? allows_subtyping boleano ¿Se permiten subtipos en este contexto? Valores por omisión La variable allows_skip es inicializada al comienzo del flujo de bits por los dos primeros bits del campo de bits especial de 4 bits, como se define en el documento FCD Systems [1]. La variable allows jartial instantiation se inicializa al principio del flujo de bits por los terceros dos bits del campo de bits especial de 4 bits. La variable allows_subtyping se inicializa al comienzo del flujo de bits por el cuarto par de bits del campo especial de 4 bits. El valor inicial implícito de schema_mode es mono; es decir que, por omisión, el sub-árbol/contexto raíz se codifica con un esquema. Reglas de propagación En la creación de un contexto nuevo: - el valor allows_skip se pone al valor de allows_skip de su contexto padre. - el valor allows_partial_instantiation se fija al valor de su contexto padre. - el valor allows_subt ping se pone al valor de su contexto padre. - el valor schema_mode se pone a su valor por omisión. Reglas de modificación dinámica En cada nodo de una descripción y con el fin de crear un nuevo contexto: - allows_skip puede ser dinámicamente modificado. - allows_partial_instantiation no puede ser dinámicamente modificado. - allows_subtyping no puede ser dinámicamente modificado. - schemajnode puede ser dinámicamente modificado. Reglas de decodificación El bloque de Contexto C está presente sólo si el bloque de metacontexto MC está ya presente y su variable local previa context_chunk es verdadera. La modificación dinámica del contexto actual se describe con un elemento XML el cual está codificado con el esquema de codificación regular BiM. Se utiliza el elemento global modifyContext del esquema BiM. El esquema de codificación http://www.mpeg7.org 2001/BiMCoding se describe en el anexo 1. El bloque de contexto C tiene que ser decodificado con el esquema regular BiM, con el esquema de arriba.

Como se estableció anteriormente, la modificación de las actuales codingProperties en el contexto implica la creación de un nuevo contexto. Por tanto, la presencia del bloque de contexto C, implica la creación de un nuevo contexto, el cual llevará el codingPropierties modificado. Si el elemento allowsSkip es instantaneizado dentro del elemento modifyContext, entonces el valor de allows_skip será actualizado en el nuevo contexto. Si el elemento schema_mode es instantaneizado dentro del elemento modiíyContext, entonces el valor de schema_mode será actualizado en el nuevo contexto.

Influencia en el proceso de decodificación de elemento Los valores allows_skip y schema_mode influencian el proceso de decodificación del elemento, cuando están tratando con la característica de salto. Este comportamiento está descrito en [1]. El valor schema_mode influencia el proceso de decodificación del elemento, con el fin de saber si el elemento está codificado únicamente con un esquema o con varios. Este mecanismo está descrito en [ 1 ] . El valor allows_partial_instantiation influencia el proceso de decodificación del elemento, adicionando un tipo especial de partiallylnstantiated a los subtipos posibles del elemento. Ver [1]. El valor allows_subtyping influencia el proceso de decodificación del elemento, y permite a un elemento o a un atributo tener diferentes tipos posibles, en caso de polimorfismo (con el atributo xsi:type) o unión del elemento. Ver [1]. 2. Descripción de la invención 2.1 Extensión del mecanismo de contexto para proveer una estructura para compresión de hoja La invención propone extender el actual mecanismo de contexto BiM para soportar una nueva e interesante característica: el uso de compresores locales para comprimir hojas de un documento, con el fin de reducir el tamaño del flujo de bits resultante. Esta sección describe cómo extender el actual mecanismo de contexto BiM para soportar el uso de compresores locales. Este es típicamente un conjunto nuevo de variables, codingPropierties, ligadas con una semántica específica, reglas de propagación y codificación. Por tanto, éste nuevo conjunto de codingPropierties extenderá el bloque de contexto actual. Introducción En un sub-árbol, todas las instancias de uno o varios tipos simples especificados pueden ser comprimidas con uno o varios compresores especificados. Básicamente esto define un mapeo entre un compresor y uno o varios tipos simples. Además: - en algunos casos, un compresor puede necesitar algunos parámetros externos. - un mapeo puede ser activado/desactivado, con el fin de usar un compresor en algunos sub-árboles pero no en otros. Al final, con el fin de ser activado/desactivado, un mapeo debe ser referenciable y por lo tanto, debe tener un identificador único en un contexto. Por tanto, cada contexto puede llevar cero, uno o varios codecTypeMapper; donde un codecTypeMapper es una cuádrupla, consistiendo en un identificador, uno o varios tipos simples, un codee, parámetros de codee externos opcionales y un estado de activación. Definiciones CodecTypeMapper Un codecTypeMapper es una cuádrupla, consistiendo en: - un identificador, usado como una clave de referencia única en un sub-árbol/contexto. - uno o varios tipos simples, para los cuales el mapeo es aplicable, un codee - parámetros de codee externos opcionales (depende del codee) - un estado de activación Identificador El identificador es un número único que identifica un mapeo dentro de un contexto de forma no ambigua. El esquema de codificación BiM restringe el número máximo de codecTypeMappers en un contexto a 32. Tipo Simple Todos los tipos simples definidos en un esquema podrían ser codificados a priori por cada codee pero, cada codee puede restringir ésta elección. Por ejemplo, un cuantizador lineal, como se definió aquí en el documento, puede ser usado únicamente con tipos simples numéricos. Un tipo simple es identificado por su nombre, y por el URL del esquema al que pertenece. Los prefijos XML Schema deben ser usados, con el fin de apuntar al esquema correcto. El esquema de codificación BiM define un tipo especial para codificar esta pareja; este tipo debe ser codificado como pareja de enteros; el primer entero es restringido al número actual de esquemas conocidos (esta pieza de información puede buscarse en la parte de DecoderConfig [1]) y el segundo entero está restringido al número de tipos simples globales presentes en el correspondiente esquema. Codee Un codee, es la abreviación de compresor/descompresor, es un módulo que toma bits de entrada y escribe bits de salida. Puede necesitar algunos parámetros externos opcionales. Un codee es identificado por un nombre, entre los nombres de los codees no-abstractos definidos en el esquema de codificación BiM. El actual esquema de codificación BiM, definido en una sección anterior, no define ninguno de los codees no-abstractos, pero §2.2 del presente documento si lo hace. Estado de activación El estado de activación es una bandera boleana. Reglas semánticas CodecTypeMapper Cada contexto: - puede llevar cero, uno o varios codecTypeMappers. - puede definir uno o varios codecTypeMappers. - puede activar o desactivar uno o varios codecTypeMappers existentes Si un CodecTypeMapper es definido en un contexto, permanece en todos sus subcontextos. Un CodecTypeMapper existente, dentro de un contexto, no puede ser borrado ni modificado (excepto su estado de activación). Identificador El identificador de un mapeo debe ser único entre todos los codecTypeMapper de un contexto. Tipo Simple Cuando usted asocia en un codecTypeMapper uno o varios tipos simples y un codee, el codee codificará/decodificará los tipos simples mismos y todos los tipos simples derivados de ellos. En un contexto, debe haber a lo más un tipo simple que pueda ser aplicable con un codee. Codee Hay dos tipos de codees: codees sin memoria y codees contextúales. Un codee sin memoria es un módulo que codifica siempre los mismos bytes de entrada en los mismos bytes de salida; independientemente de la historia del codee. Un típico codee sin memoria es un cuantificador lineal. La compresión de hoja de BiM (ver §2.2 del presente documento) describe dicho codee. Un codee contextual es un módulo que usa los bytes previos alimentados en él, (cambiando entonces el contexto del codee). Tal codee no genera los mismos bytes de salida para los mismos bytes de entrada que recibe. Un codee contextual típicamente es un codee local tipo Zip, uno se describe en §2.2 del presente documento. Un codee sin memoria no induce ningún problema en la arquitectura del actual contexto pero un codee contextual sí, en caso de un sub-árbol capaz de saltarse. En tales casos, un codee contextual es reiniciado, con el fin de no confundir el decodificador, cuando éste anterior ha saltado el sub- árbol. Estado de activación En cada sub-árbol/contexto, un codecTypeMapper puede ser activado o desactivado. Este mecanismo permite definir un codecTypeMapper en un nivel más alto del árbol documento, y lo activa sólo en los sub-árboles en los que es usado, sin redefinir el codecTypeMapper. Un nuevo codingProperty: codecTypeMapper En esta parte, añadimos un nuevo codingProperty al conjunto previo de variables de la sección de contexto, descrita antes. Esta nueva codingProperty es llamada codecTypeMapper y es una lista del anterior codecTypeMapper descrito en la sección previa. Nuevo codingProperty involucrado El contexto lleva una lista de codecTypeMapper: Nuevos valores por omisión Por omisión, no hay codecTypeMapper en un sub-árbol/contexto. Si un codecTypeMapper es definido dentro de un contexto, su identificador, su codee y su valor simple type deben ser definidos. Si no está especificado, el estado de activación de un recién definido codecTypeMapper es puesto en verdadero por omisión; es decir que un codecTypeMapper recién definido es activado por omisión. Nuevas reglas de propagación Regla 1: En la creación de un nuevo contexto, la lista de codecTypeMapper es la copia de su contexto padre: - el valor identificador es copiado. - el valor simple_type es copiado. - el valor codee es copiado de acuerdo a la regla 2. - los valores codecjparameters son copiados. - la activation_state es copiada. Regla 2: El valor codee es copiado y si: - el codee codingPoperty[i]. codee padre es un codee contextual. - y si el contexto actual es susceptible de saltar. Entonces, Se espera que el decodificador cree una nueva instancia del codee copiando la instancia del codee padre (no únicamente su valor), y reiniciándolo. Por ejemplo, un codee ZLib sería copiado y reinicializado cuando entra a un nodo que se puede saltar. Nuevas reglas de modificación dinámicas La lista de codecTypeMapper puede ser modificada dinámicamente, dentro de la descripción: - puede definirse un nuevo codecTypeMapper. - el activation_state de un codecType Mapper existente (por lo tanto referenciable) puede ser modificada dinámicamente. Un codecTypeMapper existente no puede ser borrado y sus miembros no pueden ser dinámicamente modificados (excepto su activation_state). Nuevas reglas de decodificación Las mismas reglas previas se aplican a la decodificación del bloque de contexto C, pero el nuevo esquema, descrito en el anexo 2, debe ser usado, con el fin de añadir las nuevas funcionalidades de modificación dinámicas codecTypeMapper. Parte informativa Ejemplos El ejemplo ilustrado en el anexo 3, presenta la definición de un cuantificador lineal activado (ver §2.2 del presente documento) en una descripción. El ejemplo ilustrado en el anexo 4, presenta la definición de un cuantificador lineal desactivado en una descripción. 2.2 Compresión BiM de Hojas Ahora presentamos el mecanismo implementado por la invención para codificar datos con diferentes codees. Más precisamente, ahora ilustramos dos ejemplos, uno donde un codee de cuantización lineal se usa para comprimir, por ejemplo, valores de punto flotante, y el otro donde un codee gzip es usado para comprimir, por ejemplo, valores de secuencias ordenadas.

Tal mecanismo está cercanamente relacionado al contexto de codificación y permite el uso de varios otros tipos de codees. Además, permite tratar apropiadamente con características de contexto de codificación, por ejemplo sub-árboles que pueden saltarse. Finalmente permite el re-utilizar codees en diferentes contextos de codificación. Introducción. La codificación del sub-árbol BiM [1] no comprime las tojas de datos de una descripción. Actualmente, los valores de hoja se codifican con respecto a sus tipos (IEEE 754 flotantes y dobles, cadenas UTF...). En muchos casos, podría ser útil usar algunas técnicas clásicas de compresión como la cuantización lineal o la compresión estadística para mejorar la relación de compresión de BiM sin perder sus características principales (rápido análisis sintáctico, característica de salto rápido, decodificación tipificada). Este documento presenta cómo la compresión de hojas de datos de un documento puede ser realizada dentro del mecanismo de codificación de contexto descrito en §2.1, con el fin de lograr mejores relaciones de compresión. 2.2.1. Cuantización lineal Definición Cuantización lineal es una manera inusual y con pérdidas de reducir el tamaño de números codificados en el flujo de bits, cuando el origen de la información es conocido y por lo tanto, cuando las pérdidas pueden ser controladas. Como un ejemplo, la envolvente de una señal muestreada de audio es frecuentemente conocida con una cuantización de tamaño de bit preciso, y esta técnica podría ser fructíferamente usada para codificar descripciones de audio MPEG-7. Si v es un número real, puede ser codificado con vq con nbits bits donde: en donde: - vq es el valor cuantizado y codificado de v - nbits es la precisión requerida en bits - vmin es el valor mínimo inclusivo que v puede alcanzar - vmax es el valor máximo inclusivo que v puede alcanzar Y el valor decodificado de v es , con: en donde: - v es el valor aproximado, decodificado de v Integración con el mecanismo de contexto: el LínearQuantizerCodec La cuantización lineal puede ser usada como un codee, como se define en el mecanismo de contexto de codificación descrito en §2.1 del presente documento. Con este mecanismo, la cuantización lineal puede ser aplicada en hojas de datos numéricos, de un tipo simple deseado, en cualquier sub-árbol de una descripción. Usado de esta manera, el mecanismo de contexto de codificación, asociado con el codee de cuantización lineal, está actuando como el nodo QuantízatíonParameter, utilizado en BIFS de MPEG-4 [3]. Restricción sobre tipos simples aplicables De acuerdo a la definición de un codee en §2.1 del presente documento, este codee es un codee sin memoria, el cual puede ser aplicado en todos los tipos numéricos simples atómicos y no atómicos, cuyo tipo primitivo de XML Schema es flotante, doble o decimal. Parámetros externos del codee El codee cuantizador lineal necesita los siguientes 3 parámetros obligatorios: - bitSize; la variable nbits descrita anteriormente. - mininciusive; la variable vmin descrita anteriormente. - maxinclusive; la variable vmax descrita anteriormente Esquema de definición del codee El codee de cuantización lineal es un nuevo codee de tipo LinearQuantízerCodecType, basado en el tipo abstracto CodecT pe (ver §2.1) y definido por el esquema dado en el anexo 5, en el contexto de codificación URL xmlns:cc= http://www.mpeg7.org/2001/BMCoding. Codificación (informativa) Una hoja de datos numéricos de valor v es codificada con el entero sin signo nbits bits donde: Decodificación El entero sin signo vq, codificado en nbits bits, debe ser decodificado"como v donde: - Ejemplo (informativo) El ejemplo ilustrado en el anexo 6 presenta en forma descriptiva la definición de un cuantizador lineal. 2.2.2. Compresión Estadística Los algoritmos de compresión sin pérdida de la estadística clásica pueden usarse como codees, como se define en el mecanismo de contexto de codificación (ver §2.1). Con este mecanismo, las hojas de datos, de un tipo simple deseado, pueden comprimirse eficientemente en cualquier sub-árbol de una descripción. Este codee es útil para reducir significativamente el tamaño del flujo de bits, especialmente cuando la descripción contiene muchos flujos de bits similares o repetitivos.

Definición Los algoritmos de compresión sin pérdida de la estadística clásica (como Zip o GZip) pueden utilizarse en BiM para comprimir cualesquiera hojas de una descripción. Pero, en la mayoría de los casos, cuando las hojas de datos son flujos cortos de bits que contienen menos de 10 caracteres, esto conduce a un pobre rendimiento porque los algoritmos de compresión estadística usuales requieren una memoria de anticipación más grande. Con el fin de lograr una relación de compresión óptima, las hojas de un documento deben ser almacenadas en una memoria pequeña antes de ser comprimidas. La siguiente sección define tal codificador estadístico con almacenamiento, dependiendo de un algoritmo de compresión estadístico subyacente sin pérdida. Definiciones de un codificador estadístico con memoria intermedia. Un codificador estadístico con memoria depende de un codificador estadístico subyacente que debe contener los siguientes métodos primitivos genéricos: - initíalize_stream() ; el cual inicializa la compresión o descompresión de un flujo. - reset_model() ; el cual remida el modelo estadístico actual del codificador. - feed_input_bytes() ; el cual toma los bytes de entrada descomprimidos y los pone en el flujo de compresión. - flush_output_bytes() ; el cual limpia el flujo de compresión comprimiendo los bytes de entrada ya procesados y emitiendo los bytes de salida comprimidos correspondientes. - decompress_input_bytes() ; el cual toma una cantidad especificada de bytes de entrada comprimidos y los decodifica emitiendo los bytes de salida descomprimidos correspondientes . Un codee con almacenamiento intermedio tiene una longitud de bufferSize bytes, un arreglo de bytes en memoria con estructura FIFO. Desde el lado del codificador, el valor bufferSize indica cuántos bytes de entrada puede procesar el codificador antes de efectuar el limpiado. Desde el lado del decodificador, es el tamaño míriimo de la memoria en bytes, necesitado para decodificar el flujo de bits, a través del codificador estadístico subyacente API. La memoria tiene también una variable fillingLevel, la cual contiene el nivel de llenado actual, en bytes, de la memoria. Utilizando el API ZLib como un codificador estadístico. La biblioteca pública API de ZLib [4], utilizada en el esquema de compresión GZip, proporciona un API eficiente y útil para utilizar compresión estadística sobre hojas de documentos. El API de ZLib cumple con los métodos genéricos previos, con el siguiente mapeo: - initialize streamO puede mapearse con las funciones infiateinito o deflateinito de ZLib, con el parámetro de valor de eficiencia Z_DEFAULT_COMPRESSION. - reset_modeio puede ser mapeado con una llamada MateEndO o una deflateEndO de ZLib y una llamada siguiente initialize_stream(). - feed_input_bytesO puede mapearse con el método deflateO de ZLib con el parámetro Z_NO_FLUSH. - flush_output_bytesO puede mapearse con el método deflateO ¿e ZLib con el parámetro Z_SYNC FLUSH. - decompress_input_b te() puede mapearse con el método inflateQ de ZLib.

El codee con memoria ZLib debe inicializarse con el valor de eficiencia Z_DEFAULT_COMPRESSION, como se definió en [4], lo cual proporciona una buena relación entre los requerimientos de impresión de memoria y la eficiencia de compresión. Integración con el mecanismo de contexto: el ZLib codee Esta sección describe la integración del previamente definido codificador estadístico con memoria, dependiendo del API ZLib, dentro del mecanismo de codificación de contexto. Restricción en tipos simples aplicables De acuerdo a la definición de un codee en §2.1, este codee es un codee contextual, que puede aplicarse en todos los tipos de cadenas atómicas y no-atómicas. El ZlibCodec está dependiendo en la codificación primitiva subyacente de hojas de un documento, como se describió en [1]. Por ejemplo, la hojas int son codificadas con un entero sin signo de 32 bits, string con una codificación UTF-8, float y double se codifican con el formato IEEE 754, ... Por tanto, el ZlibCodec comprimirá la hoja codificada. Parámetros externos al codee. El codee con memoria ZLib no necesita ningún parámetro externo, ya que la eficiencia del ZLib subyacente es puesta a Z_DEFAULT_COMPRESSION y ya que el parámetro bufferSize no se necesita del lado decodificador. Esquema de definición del codee. El codee ZLib es un codee nuevo del tipo ZlibCodecT pe, basado en el tipo abstracto CodecT pe (ver §2.1) y definido por el esquema ilustrado en el anexo 7, en el espacio del nombre del contexto de codificación. Codificación (informativo) En la activación/instantaneidad del codee: - la estructura FIFO de la memoria se considera limpia, su fíllingLevel es puesto a 0. - la variable global referencable_chunk se inicializa a nuil La referencable chunk debe contener un bloque de bits referenciable, que el codificador debe mantener, porque su valor será conocido más tarde durante el proceso de codificación. Cuando este bloque de bits sea conocido podría llamarse a la función de señalización signal_reference_chunk_known().

El tamaño, en bytes, de cada bloque no-nulo debe escribirse antes del bloque mismo, durante la llamada flush_output_bytesO, con la codificacación estándar de entero infinito sin signo 4+1, como se definió en [1]. Una leaf de entrada es el valor codificado de una leaf (hoja) textual, con respecto a su tipo primitivo. La longitud de la hoja, en bytes, está dada por el campo leaf.lenght. Por ejemplo [1], una hoja string es un código UTF-8, precedido por el tamaño en bytes del flujo (codificado con la codificación de entero infinito [1]); una hoja doubie es el valor de 64-bits del estándar correspondiente IEEE 754... La siguiente función encodejeaf es capaz de codificar una hoja en un bloque de bytes de salida: chunk encode_leaf(chunk leaf) { while (leaf is not emty) { if (fíllingLevel + leaf.lenght<bufferSize) { feed_input_bytes(leaf,leaf.lenght) fillingLevel = fíllingLevel +leaf.lenght if (referencable_chunk; is nuil) { referencable_chunk = new chunk return referncable_chunk } else { return nü_size_chunk } }else { renraining bytes = bufferSize - fíllingLevel - leaf.lenght feed_input_byte(leaf,rermining_bytes) referencable_chunk = flush_output_bytes) signal_reference_chunk_knownO fíllingLevel = 0 leaf =leaf.remove_begining )ytes(remaining_bytes) referncable_chunk = nuil } } } Decodificación Sea stdng_fífo una cadena FIFO.

Los siguientes métodos get() y put() respectivamente toman un elemento resp. out Ponen un elemento de resp en la FIFO. El método es una señal EmptyO si el Fifo está vacío. Sea sub la función que toma una subcadena. Sea concat la función de concatenación. Sea getDataO Ia función que regresa el char[] reteniendo los datos de-gzip de una hoja. Sea split(char[], char sep, Fifo, char[] remainder) el método que separa un arreglo de caracteres en cada separador 'sep' y almacena los elementos de flujos separados en el Fifo y regresa el resto (por ejemplo el último bloque que no tiene 'sep' para terminarlo). split(char [] data, char sep, FIFO string_ñfo, char[] remainder) { if (data =null) return; int BEGIN=0; for (int I=0;Kdata.lenght;I++) { if (data[I]=sep) { char[] str=concat(reminder, sub(data,BEGIN, I)); put(string_fífo, str); BEGIN=I+1; } } if (BEGIN!=data.lenght) { //there is a reminder. reminder = sub(data, BEGIN, data.lenght); } } String decode() { if (isEmpty(string_fifo) { data= getData(); split(data, OxOO,string_fifo,remainder); } return get(string_fifo); A la inicialización, string_fífo está vacío. En la activación/instantaneidad del codee: - se asume que la estructura FIFO está limpia, su numberOfLeaves está puesto a 0 - la variable first_chunk es puesta a trae Sea el byte separador 0x00. La siguiente función decodejeaf es capaz de decodificar una hoja comprimida del flujo de bits: string decode_leaf 0 { if (numberOfLeaves=0) { read_and_decompressed_byte() numberOfLeaves = count_number_of_leave_in_bufferO } else{ } } La decodificación está definida por: 1. Si el FIFO está vacío : a. decodifica los datos codificados, b apila en un FIFO todos los elementos separados por 0x00 c. si el último carácter no es 0x00 almacena temporalmente la cadena no terminada. d. Si "last_element" no está vacío, lo inserta al inicio del primer elemento en el FIFO e. Pone el flujo no terminado de esta vuelta en last_element. f. Quita y regresa el primer elemento. 2. Si el FIFO no está vacío, entonces quita y regresa el primer elemento. Es equivalente a decir: "el FIFO no está vacío" y "no hay datos codificados en la hoja actual". Ejemplo (informativo) La descripción dada en el anexo 8 es un ejemplo de la utilización del codee ZLibCodecT pe, mapeado con los tipos string y anyURI. Resultados (informativo) Las siguientes figuras muestran los rendimientos al utilizar el ZLibCodec de manera de comprimir hojas de descripción textual (aquellas derivadas de los tipos primitivos del Esquema XML string y anyURI ). Una memoria de buferSize = 256 bytes fue utilizada durante el proceso de codificación. Los archivos utilizados fueron proporcionados por el sub-grupo MDS de MPEG-7 Ahora rápidamente describimos los pasos implementados de acuerdo con la invención para la compresión del contemdo de las hojas de un árbol jerárquico. El paso 1 consiste en asociar una técnica de codificación de compresión a un tipo de contenido. Por ejemplo la cuantización lineal puede asociarse a valores de punto flotante. En el paso 2, un sub-árbol se identifica dentro del árbol jerárquico correspondiendo a la estructura del documento XML considerado. El paso 3 consiste en la asignación de una técnica de codificación de compresión al sub-árbol identificado.

El paso 4 luego consiste en verificar si el codee que implementa la técnica de codificación de compresión está o no activada. Si no, no se logra ninguna compresión (5) de las hojas del sub-árbol. Si sí, la invención implementa (6) compresión del contenido de las hojas del sub-árbol cuyo contenido es del tipo de contenido asociado (1) a la técnica de codificación de compresión.

ANEXO 1 <schema targetNamespace=" xrnlns:cc="http://www.mpeg7.org/2001/BiMCoding" xrrdns=="http://www.w3.org/2000/10/XMLSchema"> <element name="modifyContext"> <complexType> <sequence> <element name="allowsSkip" minOccurs="0"> <simpleType> <restriction base="string"> <enumeration value="mandatory"/> <enumeration value="optional"/> <enumeration value="forbidden"/> </restriction> </simpleType> </element> <element name="schemaMode" minOccurs="0"> <simpleType> <restriction base="string"> <enumeration value="mono"/> <enumeration value="multi"/> </restrictíon> </simpleType> </element> </sequence> </complexType> </element> < schema> ANEXO2 <schema targetNamespace="http://www.mpeg7.org/2001/Bi Coding" xmlns : cc=" http : //www.mpeg7.org/2001/BiMCoding" xmlns="http : //www.w3.org/2000/10/XMLSchema" > <element name="context"> <complexType> <seguence> <element name="allowsSkip" minOccurs="0"> <simpleType> <restriction base="string"> <enumeration value="mandatory"/> <enumeration value="optional"/> <enumeration value="forbidden"/> </restriction> </simpleType> </element> <element name="schemaMode" rninOccurs="0"> <simpleType> <restriction base="string"> <enumeration value="mono"/> <enumeration value="multi"/> </restriction> </simpleType> </element> <element name="codecTypeMappers" minOccurs=" 0"> <complexType> <sequence> <element name="codecTypeMapper" type="cc : codecTypeMapper" maxOccurs="unbounded"/> </sequence> </complexType> </element> </sequence> </complexType> </element> <! — a type can be pointed with the help of a XML Schema prefix, in order to know the schema it is belonging to — > <simpleType name="coupleSchemaTypeType"> <restriction base="string"/> </simpleType> ANEXO 2 (continuación) <! — restrictión of-32 maximál codecTypeMappers -in a context <simpleType name="códécIDType"> <restriction base="integer"> <minInclusive="0"/> <maxInclusive="31"/> </restriction> </simpleType> <complexType name="codecType apperType"> <sequence> <element name="type" type="coupleSchemaTypeType'' . maxOccurs="unbounded"/> <element name="codec" type="cc:codécType"/> </sequence> <attribute name="id" use="required" type="codecIDType"/> <attribute name="state"> <simpleType> <restricbion base="string"> <enümération valué="activated"/> <énumération válue="deactivated"/> </restriction> </simpleType> </attribute> </complexType> <compleJType name="códecType" abstract="tr e"/> </schema> ANEXO 3 <£xample xxnlns:cc="http://www.mpeg7.org/2001/BiMCoding"> <AudioEnvelope> <cc:modifyContext> <codingProperties> <codingProperty id="l"> <type>audioFloat</type> <codec xsi:type="LinearQuantifierType"> <bitSize>8</bitSize> <maxlnclusive>l .0</maxInclusive> </codec> </codingProperty> </codingProperties> </cc: modifyContext> <Values> <Raw> -0.25411 0.88541 0.2141946 0.3652541 -0.148941 0.8814 0.145544 -0.847 </Raw> </Values> </AudioEnvelope> </Example> ANEXO 4 <Example xmlns:cc="http://www.mpeg7.org/2001/BiMCoding,l> <AudioEnvelope> <ec:modifyContext> <codingProperties> <codingProperty id=" 1 " state="deactívated"> <type>aiidioHoat</type> <codec si:lype="LinearQuantifierType"> <bitSize>8</bitSize> <rninlnclusive>-l .0</rainInclusive> <maxlnclusive>1.0</maxlnclusive> </codec> </codingProperty> </codingProperties> </cc: raodifyContexO <Values> <Raw> <!— quantizatíon here — > <cc:modifyContext> <codmgProperties> <codingProperty id="l " state="activated'7> </codingProperties> </cc;modifyContext> -0.25411 0.88541 0.2141946 0.3652541 -0.148941 0.8814 0.145544 -0.847 </Raw> <Variance> > <!-- but no quantizatíon here — > 0.1777441 0.2094511 0.349411 0.548444 -0.445445 -0.3654847 0.9541 </Variance> ANEXO 5 <complexType name="LinearQuantizerCodecType"> <complexContent> <extension base="cc:CodecType"> <element name="bitSize"> <simpleType> <restriction base="int"> <minlnclusive value="l'7> <maxlnclusive value="32"/> </restriction> </simpleType> </element> <element name=,lminlnclusive" value="float"/> <element name="maxlnclusive" value="float'7> </extension> </complexContent> </complexType> ANEXO 6 <Example xmlns:cc="http://www.rnpeg7.org 2001 BiMCoding"> <AudioEnvelope> <cc:modifyContext> <codecTypeMappers> <codecTypeMapper id="l" state="deactivated"> <type>audioFloat</type> <codec xsi:t}'pe="LinearQuantizerCodecType"> <bitSize>8< bitSize> <minlnclusive>- 1 ,0</m nclusive> <maxlnclusive>l .0</maxInclusive> < codec> </codecTypeMapper> </codecTypeMappers> < cc:modifyContext> <Values> <Raw <!— quantization here — > <cc:modifyContext> <codecTypeMappers> <codecTypeMapper id="l" state="activated"/> </codecTypeMappers> < cc:modifyContext> -0.25411 0.88541 0.21419460.3652541 -0.148941 0.88140.145544 -0.847 </Raw> <Variance> > <!— but no quantization here — > 0.1777441 0.2094511 0.349411 0.548444-0.445445 -0.36548470.9541 </Variance> </Values> </AudioEnvelope> </Examples> ANEXO 8 «¿MdsExampleTest xmlns="http://www.mpeg7.org 200 l/MPEG-7_Schema" xmlns:cx^="http://www.mpeg7.org/2001/BiMCodingn <cc:modifyContext> <codecTypeMappers> <codecTypeMapper id=" 1 "> <type string</type> <type>anyURI</lype> <codec xsi:type="ZLibCodecType7> < codecTypeMapper < codecTypeMappers> </cc:modifyContext> <! — the termld attributes, Name elements and Deflnitions elements will be catched by the ZLibCodecType --> <ClassificationScheme uri="urn:mpeg:MPEG7AudioDomainCS" domain= <Term termId="l"> <Name xml:lang="en">Source</Name> <Definition xml:lang="en">Type of audio source</Definition> <Name xml:lang="en">Synthetic</Name> < Term> <Term termId="1.2"> <Name xml:lang="en">Natural< Name> </Terni> </Tetm> <Tenn termld="2"> <Name xml:lang="en">Acqüisition</Name> ANEXO 8 (continuación <Definition xml:lang="en">T pe of Cpntent</Défínitíon ANEXO 9 Referencias 1.- MPEG-7 Systems FCD, N4001 , MPEG Singapore meeting, Marzo de 2001. 3. - ISO/IEC 14496-1, MPEG-4 Systems, N3850. 4. - The Zlib API, http://www.gzip.org zlib/. RFC 1950, RFC 1951, RFC 1952 Disponible en http://www.cis.ohio-state.edu/cgi-bin/rfc/rfcl950.html

Claims (14)

1. Novedad de la Invención 1. Un método para la compresión de un árbol jerárquico describiendo una señal multimedia, dicho árbol comprendiendo nodos y hojas, los cuales pueden asociarse a datos de al menos dos naturalezas distintas, llamadas tipos de datos, en donde dicho método comprende una etapa de activación, para al menos algunas de dichas hojas, una técnica de codificación de compresión específica entre al menos dos técnicas de codificación de compresión disponibles y asociadas el tipo de datos de las hojas correspondientes, como una función del nodo al cual dichas hojas están ligadas.
2. 2. Un método de acuerdo con la reivindicación 1, comprendiendo una etapa de identificación de al menos un sub-árbol y una etapa de asignación de una de dichas técnicas de codificación de compresión a dicho sub-árbol.
3. 3. Un método de acuerdo con la reivindicación 2, comprendiendo una etapa de implementación de dicha técnica de codificación de compresión asignada a dicho sub-árbol únicamente para las hojas de dicho sub-árbol cuyos datos son del tipo asociado a dicha técnica de codificación de compresión, y en donde las otras hojas de dicho sub-árbol no experimentan ninguna codificación de compresión.
4. 4. Un método de acuerdo a cualquiera de las reivindicaciones 1 a 3, implementando una descripción parámetrica de dichas técnicas de codificación de compresión .
5. 5. Un método de acuerdo a cualquiera de las reivindicaciones 1 a 4, comprendiendo también una etapa de compresión de la estructura de dicho árbol.
6. 6. Un método de acuerdo a cualquiera de las reivindicaciones 1 a 5, en donde dicho árbol es de tipo BiM (MPEG Binary) de acuerdo al estándar MPEG7.
7. 7. Un método de acuerdo con cualquiera de las reivindicaciones 1 a 6, en donde una de dichas técnicas de codificación de la compresión implementa cuantización lineal.
8. 8. Un método de acuerdo con cualquiera de las reivindicaciones 1 a 7, en donde una de dichas técnicas de codificación de la compresión implementa un algoritmo de compresión estadística.
9. 9. Un método de acuerdo con la reivindicación 6, en donde dicho algoritmo es del tipo GZip.
10. 10. Un método de acuerdo con cualquiera de las reivindicaciones 8 y 9, en donde dicho algoritmo se implementa simultáneamente para un conjunto de datos correspondiente a los datos de al menos dos hojas. 11. Un método de acuerdo con cualquiera de las reivindicaciones 1 a 10, en done dicho árbol representa la estructura de un documento tipo XML (Extended Markup
11. Language).
12. 12. Un método de acuerdo con cualquiera de las reivindicaciones 1 a 11, comprendiendo también una etapa de asociación de al menos un contexto de codificación para dicho sub-árbol, dicho contexto de codificación incluyendo piezas de información que permiten saltar dicho sub-árbol en tanto se decodifica dicho árbol jerárquico.
13. 13. Un método de acuerdo con la reivindicación 12, en donde dichas piezas de información comprenden: - una pieza de información indicando la técnica de codificación de la compresión utilizada; y/o - una pieza de información indicando si el sub-árbol correspondiente ha sido comprimido; y/o - una pieza de información indicando si es posible saltar el correspondiente sub- árbol; y/o - una pieza de información indicando que al menos un parámetro de la técnica de codificación de la compresión utilizada ha sido modificado. 14. Un método de acuerdo con cualquiera de las reivindicaciones 1 a 13, en donde cada una de dichas técnicas de codificación de compresión está asociada selectivamente a cuando menos uno de dichos tipos de datos. 15. Un método para la decodificación de una señal multimedia comprimida de acuerdo con el método de cualquiera de las reivindicaciones 1 a 14. 16. Un método de acuerdo a la reivindicación 15, implementando una etapa de renovación del contexto de decodificación presente de acuerdo con la información de contexto de la codificación llevada por dicha señal. 17. Un método de acuerdo a la reivindicación 16, en donde dicho contexto presente define al menos un tipo de datos, incluyendo dicho método una etapa de implementación de una técnica de decodifícación de la compresión asociada a dicho tipo de datos para las hojas que comprenden datos de dicho tipo de datos. 18. Una señal generada por el método de cualquiera de las reivindicaciones 1 a
14. 14.