Method for compressing a hierarchical tree, corresponding signal and method for decoding a signal

[0001] The field of the invention is that of the compression of data. More precisely, the invention regards the compression of XML-based document (“extended Markup Language”).

[0002] The invention has applications, in particular, but not only, in the following fields:

[0003] multimedia applications;

[0004] indexation tools;

[0005] meta-data manipulation tools;

[0006] the MPEG-7 specification;

[0007] SMIL;

[0008] TV Anytime;

[0009] the third generation of radiocommunications (3GPP).

[0010] Compression techniques of the prior art for XML have several drawbacks. In particular, they do not support at the same time fast access to data, high compression ratios and progressive construction of the document. In other words, most of the time, when one of the above mentioned feature is supported, all other features are missing.

[0011] One of the compression techniques of the prior art is known as BiM (Binary MPEG). Such a technique provides a method for compressing a XML document by binarising the structure of the document, that it to say the nodes of a tree structure associated to the XML document. Hence, the compression ratio achieved by implementing the BiM technique is very poor, although the BiM technique allows a fast access to data, progressive construction of the document and skippability.

[0012] It is an aim of the invention to compensate for the drawbacks of the techniques of the prior art.

[0013] More precisely, the invention aims at providing an efficient compression technique for XML-based documents.

[0014] The invention also aims at providing a compression technique for XML which provides skippability, high compression ratios and progressive construction of the document.

[0015] The invention also aims at compressing efficiently MPEG-7 descriptors.

[0016] Another aim of the invention is to implement a method for compressing an XML document which enhances greatly the compression ratio provided by a technique of the BiM type, but which provides the same functionalities as that provided by BiM.

[0017] The above mentioned aims of the invention, as well as other aims of the invention which will appear later on, are achieved, according to the invention, by means of a method for compressing a hierarchical tree describing a multimedia signal, said tree comprising nodes and leaves, which can be associated to contents of at least two distinct types, wherein said method implements a content compression for at least some of said leaves by means of at least two compression encoding techniques, each of said techniques being selectively associated to at least one of said content types.

[0018] According to a preferred embodiment of the invention, such a method comprises a step of identifying at least one sub-tree and a step of allocating one of said compression encoding techniques to said sub-tree.

[0019] Advantageously, such a method comprises a step of implementing said compression encoding technique allocated to said sub-tree only for the leaves of said sub-tree whose content is of the type associated to said compression encoding technique, and the other leaves of said sub-tree do not undergo any compression encoding.

[0020] According to an advantageous feature of the invention, such a method implements a parametrical description of said compression encoding techniques.

[0021] Preferentially, such a method also comprises a step of compressing the structure of said tree.

[0022] Advantageously, said tree is of the BiM (Binary MPEG) type according to the MPEG7 standard.

[0023] Preferentially one of said compression encoding techniques implements linear quantization.

[0024] Advantageously, one of said compression encoding techniques implements a statistical compression algorithm.

[0025] Preferentially, said algorithm is of the GZip type.

[0026] Advantageously, said algorithm is simultaneously implemented for a set of data corresponding to the content of at least two leaves.

[0027] Preferentially, said tree represents the structure of an XML (Extended markup language) type document.

[0028] The invention also regards a method for decoding a multimedia signal compressed according to the above-mentioned method for compressing a hierarchical tree.

[0029] Advantageously, such a method implements a step of refreshing a present decoding context according to encoding context information conveyed by said signal.

[0030] Preferentially, said present context defines at least one content type, said method comprising a step of implementing a compression decoding technique associated to said content type for the leaves having a content of said content type.

[0031] The invention also regards a signal generated by the above-mentioned method for compressing a hierarchical tree.

[0032] Other features and assets of the invention will appear more clearly in light of the following description, given as a mere illustrative but non restrictive example, and of the following figures:

[0033]
FIG. 1 illustrates the concept of coding context;

[0034]
FIG. 2 describes the structure of an element as coded according to the BiM technique;

[0035]
FIG. 3 illustrates some of the steps implemented according to the invention for compressing the content of the leaves of a hierarchical tree.

[0036] Before describing in details how to implement the invention, we first recall the main features of the compression technique of the prior art, known as the BiM technique.

[0037] To ease the understanding of the document, some references are gathered in annex 9 and referred to throughout the document.

[0038] All the annexes provided with the present document are part of the present description of the invention.

[0039] 1. Prior Art

[0040] Introduction

[0041] A coding context, illustrated in FIG. 1, is a set of decoding information, needed while decoding the bitstream. A coding context is applicable to the whole sub-tree of the node where it is defined. At every nodes of the tree, the coding context can be modified; leading to the creation of a new coding context, applicable to the corresponding sub-tree.

[0042] A context can carry several information which edict features applicable to the concerned sub-tree. Currently, in the BiM sub-tree coding format [1], these features are skippability of a sub-tree/context and multiple schema encoding of a sub-tree/context (in order to provide the backward and forward compatibility feature). At last, the context mechanism can be disabled in every sub-tree in order to save bandwidth; this is the context frozen mode.

[0043] The coding context mechanism provides maximum flexibility in every sub-tree of a document tree and allows extensible features to be plugged into the BiM encoding mechanism.

[0044] We know presents the current context mechanism used in BiM.

[0045] Current Coding Context Mechanism

[0046] Definitions

[0047] CodingContext

[0048] A codingContext is a set of information, the contextual information, needed by the decoder to decode the bitstream. A codingContext is applicable to the node where it has been defined, and the whole sub-tree corresponding to this node.

[0049] The current codingContext, (i.e. the context applicable at a specified node of a description) can be modified within the document (that is to say, a modification of its underlying set of information). Each modification of a codingContext leads to the creation a of new codingContext, which will carry the modified set of information. All codingContexts are expected to be stacked, in order to get them back, when the decoder has finished decoding a sub-tree corresponding context.

[0050] Decoder

[0051] The BiM decoder is composed of two decoders:

[0052] the context decoder; this decoder is dedicated to decode the contextual information. As stated before, the contextual information is not part of the description. This is a set of information which carry some external features, backward and forward compatibility, fast skipping . . .

[0053] the element decoder; this decoder, the BiM regular one [1] is dedicated to decode the element information.

[0054] Chunks

[0055] Each element of a description is coded as the 3-plet illustrated in FIG. 2, where the header part is constituted of two chunks, whom sizes can be nil:

[0056] MC is the metacontext chunk;

[0057] C is the context chunk;

[0058] Element is the element chunk, which is the regular element coding chunk, see [1].

[0059] The MC metacontext chunk contains the information needed by the decoder to decode the following C chunk. That is to say that the MC chunk is the context chunk of the C context chunk.

[0060] The C context chunk contains the information able to change the current coding context set of information, and needed by the decoder to decode the following element chunk. That is to say that the C chunk is the context chunk of the element chunk.

[0061] Set of Information

[0062] The current BiM coding context carries a set of information, the contextual information, which can be divided in the two following main classes:

[0063] the metacontext section; if the information contained in this section, influence only the context decoding process

[0064] the context section; if the information contained in this section, influence only the element decoding process

[0065] The current set of information is the following set of variables:

1ClassVariableValueDescriptionMetacontextfreezing_statebooleanfalse: The contextchanged within this sub-ttrue: The context cachanged anymore in ttree.Contextallows_skip(mandatory,Is skipping feature maoptional,optional or forbiddenforbidden)context?schema_mode(mono,Is the current element comulti)multiple schemas?allows_partial_instantiationbooleanIs partial instantiation allthis context?allows_subtypingbooleanIs subtyping allowedcontext?

[0066] The classes defined are exactly coding the chunks described above (the MC metacontext chunk and the C context chunk).

[0067] Metacontext Chunk

[0068] Definition

[0069] The MC metacontext chunk, which size can be null, contains information to know if the decoder has to read the next C context chunk, described in the following section.

[0070] Variables Involved

2VariableValueDescriptionfreezing_statebooleanfalse: The context can be changedwithin this sub-tree. The MCchunk will be coded into thebitstream.true: The context cannot bechanged anymore in this sub-tree.The MC chunk won't be codedinto the bitstream.

[0071] Default Values

[0072] The default value of freezing_state is false; that is to say that, by default, the root context can be dynamically changed.

[0073] Propagation Rules

[0074] At the creation of a new context:

[0075] the freezing_state value is set to the freezing_state value of its father's context

[0076] Dynamic Modification Rules

[0077] At each node of a description and in order to create a new context:

[0078] freezing_state value can be switched from the value false to the value true

[0079] Decoding Rules

[0080] If the freezing_state value is true, the MC metacontext chunk (and the upcoming C context chunk) is not coded into the bitstream. Otherwise, the MC metacontext chunk part of the header is coded as follows:

3MC ( ) {# of bitsMnem freeze_type1-3vlclbf}

[0081] The context_chunk is a local variable, initialised at false.

4freeze typeImplication110context_chunk = true and freezing_state = true10context_chunk = true111context_chunk = false and freezing_state = true0context_chunk = false

[0082] As stated in the previous section, the modification of the variables of the current context implies the creation of a new context.

[0083] Influence on the Context Decoding Process

[0084] If the context_chunk value is true, the decoder has to read the following C context chunk.

[0085] Context Chunk

[0086] Definition

[0087] The C context chunk, which size can be null, contains a set of information able to dynamically change the current context variables. These variables are called codingProperties because they influence the BiM element decoding process.

[0088] CodingProperties Involved

5codingPropertyValueDescriptionallows_skip(mandatory,Is skipping feature mandatory,optional,optional or forbidden in thisforbidden)context?schema_mode(mono, multi)Is the current element coded withmultiple schemas?allows_partial—booleanIs partial instantiation allowed ininstantiationthis context?allows_subtypingbooleanIs subtyping allowed in thiscontext?

[0089] Default Values

[0090] The allows_skip variable is initialized at the beginning of the bitstream by the first two bits of the special 4 bits bitfield, as defined in the FCD Systems document [1].

[0091] The allows_partial_instantiation variable is initialized at the beginning of the bitstream by the third two bits of the special 4 bits bitfield.

[0092] The allows_subtyping variable is initialized at the beginning of the bitstream by the fourth two bits of the special 4 bits bitfield.

[0093] The default value of schema_mode is mono; that is to say that, by default, the root sub-tree/context is encoded with one schema.

[0094] Propagation Rules

[0095] At the creation of a new context:

[0096] allows_skip value is set to the allows_skip value of its father's context

[0097] allows_partial_instantiation value is set to the value of its fathers context

[0098] allows_subtyping value is set to the value of its father's context

[0099] schema_mode value is set to its default value

[0100] Dynamic Modification Rules

[0101] At each node of a description and in order to create a new context:

[0102] allows_skip can be dynamically modified

[0103] allows_partial_instantiation cannot be dynamically modified

[0104] allows_subtyping cannot be dynamically modified

[0105] schema_mode can be dynamically modified

[0106] Decoding Rules

[0107] The C Context chunk is present only if the MC metacontext chunk is already present and its previous local variable context_chunk is true.

[0108] The dynamic modification of the current context is described with an XML element which is encoded with the BiM regular encoding scheme. The global element modifyContext from the BiM schema is used. The http://www.mpeg7.org/2001/BiCoding coding schema is described in annex 1.

[0109] The C context chunk has to be decoded with the BiM regular scheme, with the above schema.

[0110] As stated before, the modification of the current codingProperties in the context implies the creation of a new context. Therefore, the presence of the C context chunk, implies the creation of a new context, which will carry the modified codingProperties.

[0111] If the allows_skip element is instantiated within the modifyContext element, then the value of allows_skip will be updated in the new context.

[0112] If the schema_mode element is instantiated within the modifyContext element, then the value of schema_mode will be updated in the new context.

[0113] Influence on the Element Decoding Process

[0114] The allows_skip and schema_mode values influence the element decoding process, when dealing with the skipping feature. This behavior is described in [1].

[0115] The schema_mode value influences the element decoding process, in order to know if the element is coded with only one schema or several ones. This mechanism is described in [1].

[0116] The allows_partial_instantiation value influences the element decoding process, by adding one special type partiallyInstantiated type to the possible subtypes of the element. See [1].

[0117] The allows_subtyping value influences the element decoding process, and allows an element or an attribute to have different possible types, in case of element polymorphism (with the xsi:type attribute) or union. See [1].

[0118] 2. Description of the Invention

[0119] 2.1. Extension of the Context Mechanism to Provide a Framework for Leaf Compression

[0120] The invention proposes to extend the current BiM context mechanism in order to support a new and interesting feature: the use of local compressors to compress leaves of a document, in order to reduce the size of the resulting bitstream.

[0121] This section describes how to extend the current BiM context mechanism to support the use of local compressors. This is typically a new set of variables, codingProperties, linked with specific semantic, propagation and coding rules. Therefore, this new set of codingProperties will extend the current context chunk.

[0122] Introduction

[0123] In a sub-tree, all the instances of one or several specified simple type can be compressed with one or several specified compressor. This basically defines a mapping between a compressor and one or several simple types.

[0124] Moreover:

[0125] in some cases, a compressor can need some external parameters

[0126] a mapping can be activated/deactivated, in order to use a compressor in some sub-trees but not in another ones

[0127] At last, in order to be activated/deactivated, a mapping should be referencable and therefore, must have an unique identifier in a context.

[0128] Therefore, each context can carry zero, one or several codecTypeMapper; where a codecTypeMapper is a 4-plet, consisting of an identifier, one or several simple types, a codec, optional external codec parameters and an activation state.

[0129] Definitions

[0130] CodecTypeMapper

[0131] A codecTypeMapper is a 4-plet, consisting of:

[0132] an identifier, used as an unique reference key in a sub-tree/context

[0133] one or several simple types, for which the mapping is applicable

[0134] a codec

[0135] optional external codec parameters (depends of the codec)

[0136] an activation state

[0137] Identifier

[0138] The identifier is an unique number which identify a mapping within a context in an unambiguous way. The BiM coding schema restricts the maximal number of codecTypeMappers in a context to 32.

[0139] Simple Type

[0140] All the simple types defined in a schema could be a priori encoded by every codec but, each codec can restrict this choice. For instance, a linear quantizer, as defined hereafter in the document, can only be used with numerical simple types.

[0141] A simple type is identified by its name, and the by the URL of the schema its belongs. XML Schema prefixes should be used, in order to point to the correct schema. The BiM coding schema defines a special type to encode this couple; this type should be encoded as couple of integers; the first integer is restricted to the current number of schemas known (this piece of information can be fetched in the DecoderConfig part [1]) and the second integer is restricted to the number of global simple types present in the corresponding schema.

[0142] Codec

[0143] A codec, standing for compressor/decompressor, is a module which takes input bits, and writes output bits. It can need some optional external parameters.

[0144] A codec is identified by a name, among the names of non-abstract codecs defined in the BiM coding schema. The current BiM coding schema, defined in a section above, doesn't define any non-abstracts codecs, but §2.2 of the present document does.

[0145] Activation State

[0146] The activation state is a boolean flag.

[0147] Semantic Rules

[0148] CodecTypeMapper

[0149] Each context:

[0150] can carry zero, one or several codecTypeMappers

[0151] can define one or several codecTypeMappers

[0152] can activate or deactivate one or several existing codecTypeMappers

[0153] If a codecTypeMapper is defined in a context, it remains in all its subcontexts.

[0154] An existing codecTypeMapper, within a context, cannot be deleted nor modified (except its activation state).

[0155] Identifier

[0156] The identifier of a mapping must be unique among all the codecTypeMappers of a context.

[0157] Simple Type

[0158] When you associate in a codecTypeMapper one or several simple types and a codec, the codec will encode/decode the simple types themselves and all the simple types which derived from them.

[0159] In a context, there must be at most one simple type than can be applicable with a codec.

[0160] Codec

[0161] There are two types of codecs: memoryless codecs and contextual codecs.

[0162] A memoryless codec is a module which encodes always the same input bytes into the same bytes out; independently of the history of the codec. A typical memoryless codec is a linear quantifier. The BiM leaf compression (see §2.2 of the present document) describes such a codec.

[0163] A contextual codec is a module which uses the previous bytes fed in it, (thus changing the context of the codec). Such a codec doesn't generate the same output bytes for the same input bytes it receives. A typically contextual codec is a Zip-like local codec, one is described in §2.2 of the present document.

[0164] A memoryless codec doesn't induce any problem in the current context architecture but a contextual codec does, in case of skippable sub-tree. In such cases, a contextual codec is reset, in order not to confuse the decoder, when this former has skipped the sub-tree.

[0165] Activation State

[0166] In every sub-tree/context, a codecTypeMapper can be activated or deactivated.

[0167] This mechanism allows to define a codecTypeMapper in a higher level of the document tree, and activate it only in the sub-trees it is used, without redefining the codecTypeMapper.

[0168] A new codingProperty: codecTypeMapper

[0169] In this part, we add a new codingProperty to the previous set of variables of the context section, described before. This new codingProperty is named codecTypeMapper and is a list of the previous codecTypeMapper described in the previous section.

[0170] New codingProperty involved

[0171] The context carries a list of codecTypeMapper:

6CodingPropertiesValueDescriptioncodecTypeMapper[i].identifierintNumerical identifiereference a codingProin a context irunambiguous way.codecTypeMapper[i].simple_type[j]int; intList of 2-plet (Numeindex of a schenumerical index ofa sitype in the currentschecodecTypeMapper[i].codecintNumerical indexof a c in the currentco context schemecodecTypeMapper[i].codec_parametersOptional external cparameters.codecTypeMapper[i].activation_statebooleanState of activationcodingProperty.

[0172] New Default Values

[0173] By default, there is no codecTypeMapper in a sub-tree/context.

[0174] If a codecTypeMapper is defined within a context, its identifier, codec and simple_type value must be defined. If not specified, the state of activation of a newly defined codecTypeMapper is set to true by default; that is to say that a newly defined codecTypeMapper is activated by default.

[0175] New Propagation Rules

[0176] Rule 1: At the creation of a new context, the codecTypeMapper list is the copy of its father's context:

[0177] the identifier value is copied

[0178] the simple_type value is copied

[0179] the codec value is copied according to the rule 2

[0180] the codec_parameters value are copied

[0181] the activation_state is copied

[0182] Rule 2: The codec value is copied and if:

[0183] the father's codec codingProperty[i].codec is a contextual codec

[0184] and if the current context is skippable

[0185] Then,

[0186] the decoder is expected to create a new instance of the codec by copying

[0187] the instance of the father's codec (not only its value), and resetting it.

[0188] For instance, a ZLib codec would be copied and re-initialized when entering a skippable node.

[0189] New Dynamic Modification Rules

[0190] The list of codecTypeMapper can be dynamically modified, within the description:

[0191] a new codecTypeMapper can be defined

[0192] the activation_state of an existing (then referencable) codecTypeMapper can be dynamically modified

[0193] An existing codecTypeMapper cannot be deleted and its members cannot be dynamically modified (except its activation_state).

[0194] New Decoding Rules

[0195] The same previous rules apply to the C context chunk decoding, but the new schema, described in annex 2, should be used, in order to add the new codecTypeMapper dynamic modification functionalities.

[0196] Informative Part

EXAMPLES

[0197] The example, illustrated in annex 3, presents the definition of one activated linear quantifier (see §2.2 of the present document) in a description.

[0198] The example, illustrated in annex 4, presents the definition of one deactivated linear quantifier in a description.

[0199] 2.2 BiM Leaf Compression

[0200] We now present the mechanism implemented by the invention to encode data with different codecs. More precisely, we now illustrate two examples, one where a linear quantization codec is used to compress, for example, floating point values, and the other where a gzip coedc is used to compress, for example, string values.

[0201] Such a mechanism is closely related to the coding context and allows the use of several other types of codecs. Moreover, it allows to deal properly with coding context features, for instance skippable subtrees. Finally it allows re-use of codecs in different coding contexts.

[0202] Introduction

[0203] The BiM sub-tree coding [1] doesn't compress the data leaves of a description. Currently, leaf values are encoded with respect of their types (IEEE 754 floats and doubles, UTF strings . . . ).

[0204] In many cases, it could be useful to use some classical compression techniques like linear quantization or statistical compression to improve the compression ratio of BiM without losing its main features (streamline parsing, fast skipping feature, typed decoding).

[0205] This document presents how data leaves compression of a document can be done within the context coding mechanism described in §2.1, in order to achieve better compression ratios.

[0206] 2.2.1. Linear Quantization

[0207] Definition

[0208] Linear quantization is an usual and lossy way to reduce the size of encoded numbers in the bitstream, when the source of the information is known and therefore, when losses can be controlled.

[0209] As an example, the envelope of a sampled audio signal is often known with a precise bitsize quantization, and this technique could be fruitfully used for coding MPEG-7 audio descriptions.

[0210] If v is a real number, it can be encoded with vq with nbits bits where:

v_{q} = \frac{v - v_{\min}}{v_{\max} - v_{\min}} (2^{nbits} - 1)

[0211] where:

[0212] vq is the quantized, encoded value of v

[0213] nbits is the precision required in bits

[0214] vmin is the minimal inclusive value that v can reach

[0215] vmax is the maximal inclusive value that v can reach

[0216] And the decoded value from v is V, with:

\overline{v} = v_{\min} + v_{q} \frac{v_{\max} - v_{\min}}{2^{nbits} - 1}

[0217] where:

[0218] v is the decoded, approximated value of v

[0219] Integration with the Context Mechanism: the LinearQuantizerCodec

[0220] Linear quantization can be used as a codec, as defined in the coding context mechanism described in §2.1 of the present document. With this mechanism, linear quantization can be applied on numerical data leaves, of a desired simple type, in any sub-tree of a description.

[0221] Used like this, the coding context mechanism, associated with the linear quantization codec, is acting as the QuantizationParameter node, used in MPEG-4 BIFS [3].

[0222] Restriction on Applicable Simple Types

[0223] According to the definition of a codec in §2.1 of the present document, this codec is a memoryless codec, which can be applied on every atomic and non-atomic simple numerical types; whose XML Schema primitive type is float, double or decimal.

[0224] Codec External Parameters

[0225] The linear quantizer codec needs the following 3 mandatory parameters:

[0226] bitsize; the nbits variable described above

[0227] minInclusive; the vmin variable described above

[0228] maxInclusive; the vmax variable described above

[0229] Schema Definition of the Codec

[0230] The linear quantization codec is a new codec of type LinearQuantizerCodecType, based on the abstract CodecType type (see §2.1) and defined by the schema given in annex 5, in the coding context namespace URL xmlns:cc-http://www.mpeg7.org/2001/BiMCoding.

[0231] Encoding (Informative)

[0232] A numerical data leaf of value v is encoded with the unsigned integer vq on nbits bits where

v_{q} = \frac{v - v_{\min}}{v_{\max} - v_{\min}} (2^{nbits} - 1)

[0233] Decoding

[0234] The unsigned integer vq, coded on nbits bits, should be decoded as v where:

\overline{v} = v_{\min} + v_{q} \frac{v_{\max} - v_{\min}}{2^{nbits} - 1}

[0235] Example (Informative)

[0236] The example illustrated in annex 6 presents the definition of a linear quantizer in a description.

[0237] 2.2.2. Statistical Compression

[0238] Classical statistical lossless compression algorithms can be used as codecs, as defined in the coding context mechanism (see §2.1). With this mechanism, data leaves, of a desired simple type, can be compressed efficiently in any sub-tree of a description.

[0239] This codec is useful for significantly reducing the size of the bitstream, especially when the description contains many repetitive or similar strings.

[0240] Definition

[0241] Classical lossless statistical compression algorithms (like Zip or GZip) can be used in BiM to compress any leaves of a description.

[0242] But, in most cases, when data leaves are short strings which contain fewer than 10 characters, this leads to poor performances because usual statistical compression algorithms requires a larger lookahead buffer.

[0243] In order to achieve optimal compression ratio, the leaves of a document have to be buffered into a small buffer before being compressed. The following section defines such a buffered statistical coder, relying on an underlying lossless statistical compression algorithm.

[0244] Definitions of a Buffered Statistical Coder

[0245] A buffered statistical coder relies on an underlying statistical coder which should contain the generic following primitives methods:

[0246] initalize_stream( ); which initializes a compressing or a decompressing stream

[0247] reset_model( ); which resets the current statistical model of the coder

[0248] feed_input_bytes( ); which takes input decompressed bytes and put them in the compressing stream

[0249] flush_output_bytes( ); which flushes the compressing stream by compressing the input bytes already processed and by emitting the corresponding compressed output bytes

[0250] decompress_input_bytes( ); which takes a specified amount of input compressed bytes and decodes them by emitting the corresponding decompressed output bytes

[0251] A buffered codec has a bufferSize bytes length, byte array buffer FIFO structure.

[0252] From the encoder side, the bufferSize value indicates how many input bytes the encoder can process before flushing. From the decoder side, this is the minimal buffer size in bytes, needed to decode the bitstream, through the underlying statistical coder API.

[0253] The buffer has also a fillingLevel variable, which contains the actual filling level, in bytes, of the buffer.

[0254] Using the ZLib API as a Statistical Coder

[0255] The ZLib public library API [4], used in the GZip compression scheme, provides an efficient and useful API for using statistical compression on document leaves.

[0256] The ZLib API fulfils the previous generic methods, with the following mapping:

[0257] initialize_stram( ) can be mapped with the ZLib's inflateInit( ) or deflateInit( ) functions, with the Z_DEFAULT_COMPRESSION efficiency value parameter.

[0258] reset_model( ) can be mapped with an ZLib's inflateEnd( ) or a deflateEnd( ) call and a following initialize_stream( ) call.

[0259] feed_input_bytes( ) can be mapped with the ZLib's deflate( ) method with the Z_NO_FLUSH parameter.

[0260] flush_output_bytes( ) can be mapped with the ZLib's deflate( ) method with the Z_SYNC_FLUSH parameter.

[0261] decompress_input_bytes( ) can be mapped with the ZLib's inflate( ) method.

[0262] The ZLib buffered codec should be initialized with the Z_DEFAULT_COMPRESSION efficiency value, as defined in [4], which provides a good tradeoff between memory footprint requirements and compression efficiency.

[0263] Integration with the Context Mechanism: the ZLibCodec

[0264] This section describes the integration of the previously buffered statistical coder defined, relying on the ZLib API, within the coding context mechanism.

[0265] Restriction on Applicable Simple Types

[0266] According to the definition of a codec in §2.1, this codec is a contextual codec, which can be applied on every atomic and non-atomic string types. The ZLibCodec is relying on the underlying primitive encoding of leaves of a document, as described in [1]. For instance, int leaves are encoded with a 32 bits unsigned integer, string with a UTF-8 encoding, float and double are encoded with the IEEE 754 format, . . . Therefore, the ZLibCodec will compress the encoded leaf

[0267] Codec External Parameters

[0268] The buffered ZLib codec doesn't need any external parameters, as the efficiency of the underlying ZLib is set at Z_DEFAULT_COMPRESSION and as the bufferSize parameter is not needed from the decoder side.

[0269] Schema Definition of the Codec

[0270] The ZLib codec is a new codec of type ZLibCodecType, based on the abstract CodecType (see §2.1) type and defined by the schema illustrated in annex 7, in the coding context namespace.

[0271] Encoding (Informative)

[0272] At the activation/instantiation of the codec:

[0273] the FIFO buffer structure is supposed to be clear, its fillingLevel is set to 0

[0274] the global variable referencable_chunk is initialized to null

[0275] The referencable_chunk should contain a referencable chunk of bits, which must be hold by the encoder, because its value will be known later during the encoding process. The signaling function signal_reference_chunk_known( ) could be called when this chunk is known.

[0276] The size, in bytes, of every non-nil chunk should be write before the chunk itself, during the flush_output_bytes( ) call, with the standard unsigned infinite integer 4+1 coding, as defined in [1].

[0277] An input leaf is the encoded value of a textual leaf, with respect of its primitive type. The length of the leaf, in bytes, is given by the field leaf.length. For instance [1], a string leaf is an UTF-8 code, preceded by the size in bytes of the string (coded with the infinite integer coding [1]); a double leaf is the 64-bits value of the corresponding IEEE 754 standard . . .

[0278] The following encode_leaf function is able to encode a leaf in a chunk of output bytes:

7chunk encode_leaf(chunk leaf) { while (leaf is not empty) { if (fillingLevel + leaf.length < bufferSize) { feed_input_bytes(leaf,leaf.length) fillingLevel = fillingLevel + leaf.length if (referencable_chunk is null) { referencable_chunk = new chunk return referencable_chunk } else { return nil_size_chunk } } else { remaining_bytes = bufferSize − fillingLevel − leaf.length feed_input_bytes(leaf,remaining_bytes) referencable_chunk = flush_output_bytes( ) signal_reference_chunk_known( ) fillingLevel = 0 leaf = leaf.remove_beginning_bytes(remaining_bytes) referencable_chunk = null } }}

[0279] Decoding

[0280] Let string_fifo be a string FIFO.

[0281] The following methods get( ) and put( ) respectively take an element out resp. put an element from resp in the FIFO.

[0282] The method is Empty( ) signals whether the Fifo is empty

[0283] Let sub be the function that takes a substring.

[0284] Let concat be the concatenation function

[0285] Let getData( ) the function that returns the char[ ] holding de-gzip data from a leaf.

[0286] Let split(char[ ], char sep, Fifo, char[ ] remainder) be the method that splits an array of characters at each separator ‘sep’ and stores the separated string elements into the Fifo and returns the remainder (i.e. the last chunk that has no ‘sep’ to finish it)

[0287] split(char[ ] data, char sep, FIFO string_fifo,char[ ] remainder)

8{ if (data==null) return; int BEGIN=0; for (int I=0;I<data.length;I++) { if (data[I]==sep) { char[] str= concat(remainder, sub(data,BEGIN,I)); put(string_fifo, str); BEGIN=I+1; } } if (BEGIN!=data.length) { //there's a remainder. remainder = sub(data,BEGIN,data.length); }}String decode( ){ if (isEmpty(string_fifo) { data = getData( ); split(data,0x00,string_fifo,remainder); } return get(string_fifo);}

[0288] At initialization, string_fifo is empty.

[0289] At the activation/instantiation of the codec:

[0290] the FIFO structure is supposed to be clear, its numberOfLeaves is set to 0

[0291] the variable first_chunk is set to true

[0292] Let the separator byte be 0x00.

[0293] The following decode_leaf function is able to decode a compressed leaf from the bitstream:

9string decode_leaf( ) { if (numberOfLeaves == 0) { read_and_decompressed_byte( ) numberOfLeaves = count_number_of_leave_in_buffer( ) } else { }}

[0294] Decoding is defined by:

[0295] 1. If the FIFO is empty:

[0296] a. decode the coded data,

[0297] b. stack in a FIFO all elements separated by 0x00

[0298] c. if the last character is not 0x00 store the unfinished string temporarily.

[0299] d. if “last_element” is not empty, insert it at the beginning of the first element in FIFO

[0300] e. put the unfinished string of this round in last_element.

[0301] f. remove and return the first element.

[0302] 2. If the FIFO is not empty, then remove and return the first element.

[0303] It is equivalent to say: “the FIFO is not empty” and to say “there is no encoded data in a the current leaf.”

[0304] Example (Informative)

[0305] The description given in annex 8 is an example of the usage of the ZLibCodecType codec, mapped with the string and the anyURI types.

[0306] Results (Informative)

[0307] The following figures show the performances of using the ZLibCodec so as to compress textual leaves of descriptions (those derived from the string and the anyURI XML Schema primitive types). A buffer of bufferSize=256 bytes was used during the encoding process.

[0308] The files used were provided by the MPEG-7 MDS sub-group.

10OriginalBiM with thesizeBiM sizeZLib codec sizeZipped file sizeFilename(bytes)(bytes)(bytes)(bytes)mdsExamplesClause11-12.xml160658225121060217019mdsExamplesClause13-15.xml811331162785389698mdsExamplesClause17.xml142426575832248921444mdsExamplesClause4-7.xml37208653637487623mdsExamplesClause8-10.xml8179208113892416

[0309] We now quickly describe the steps implemented according to the invention for compressing the content of the leaves of a hierarchical tree.

[0310] Step 1 consists in associating a compression encoding technique to a content type. For example, linear quantization can be associated to floating point values.

[0311] In step 2, a sub-tree is identified within the hierarchical tree corresponding to the structure of the considered XML document.

[0312] Step 3 consists in allocating a compression encoding technique to the identified sub-tree.

[0313] Step 4 then consists in checking whether the codec implementing the compression encoding technique is or not activated. If no, no compression (5) of the leaves of the sub-tree is achieved.

[0314] If yes, the invention implements (6) compression of the content of the sub-tree leaves whose content is of the content type associated (1) to the compression encoding technique.

Method for compressing a hierarchical tree, corresponding signal and method for decoding a signal

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

Priority Claims (1)

PCT Information