DE60123596T2

DE60123596T2 - Verfahren zur Komprimierung einer Baumhierarchie, zugehöriges Signal und Verfahren zur Dekodierung eines Signals

Info

Publication number: DE60123596T2
Application number: DE60123596T
Authority: DE
Inventors: Cyril Concolato; Claude Seyrat; Gregoire Pau; Cedric Thienot; Alexandre Cotarmanac'h
Original assignee: Groupe Des Ecoles De Telecommunications-Etablissement Enst De Bretagne; GROUPE ECOLES TELECOMM; France Telecom SA; Expway SA
Current assignee: Groupe Des Ecoles De Telecommunications-Etablissement Enst De Bretagne; GROUPE ECOLES TELECOMM; Orange SA; Expway SA
Priority date: 2001-07-13
Filing date: 2001-07-13
Publication date: 2007-08-16
Anticipated expiration: 2021-07-14
Also published as: JP2009043267A; ATE341901T1; EP1276324B1; AU2002330359A1; EP1276324A1; WO2003007614A2; BR0211106A; CN1528091A; CA2452639A1; BRPI0211106B1; DE60123596D1; KR20040036897A; BRPI0211106B8; CN100493187C; WO2003007614A3; US20040267710A1; MXPA04000219A; ES2272429T3; JP2004535034A; CA2452639C

Description

Das Gebiet der Erfindung ist das der Kompression von Daten. Genauer gesagt, die Erfindung bezieht sich auf das Komprimieren von auf XML („eXtended Markup Language") basierenden Dokumenten.
Die Erfindung findet Anwendung insbesondere, aber nicht ausschließlich, in den folgenden Bereichen:

– Multimedia-Anwendungen;
– Indexierungs-Werkzeugen;
– Metadatenmanipulations-Werkzeugen;
– MEPG-7 Spezifikation (siehe vor allem NACK et al. "Everything you wanted to know about MPG-7: Part 2" IEEE Multimedia, IEEE Computer Society, US, Vol. 6, No. 4, Oktober 1999, Seiten 64–73).
– SMIL;
– TV-Anytime;
– der dritten Generation von Funkkommunikationen (3GPP).

Kompressionstechniken des Standes der Technik für XML weisen mehrere Nachteile auf. Insbesondere unterstützen sie nicht gleichzeitig einen schnellen Zugriff auf Daten, hohe Kompressionsraten und einen progressiven Aufbau des Dokuments. Mit anderen Worten, die meiste Zeit, wenn eines der oben genannten Merkmale unterstützt wird, fehlen alle anderen Merkmale.
Eine der Kompressionstechniken des Standes der Technik ist als BiM (Binary MPEG) bekannt und ist vor allem in dem Text von ISO/IEC FCD 15938-1 Information Technology Multimedia Content Description Interface – Part 1 Systems" „ISO/IEC" JTC1/SC 29/WG11 "MPEG" 01/N4001, März 2001, beschrieben. Eine solche Technik stellt ein Verfahren zum Komprimieren eines XML-Dokuments durch Binarisieren der Struktur des Dokuments bereit, dass heißt, der Knoten der mit dem XML-Dokument verknüpften Baumstruktur. Daher ist die beim Ausführen der BiM-Technik erreichte Kompressionsrate sehr schlecht, obwohl die BiM-Technik einen schnellen Zugriff auf Daten, eine progressive Konstruktion des Dokuments und Überspringbarkeit erlaubt. Liefke et al. in „XMILL: An efficient compressor for XML Data", (Sigmod Record, Association for Computing Machinery, New York, US, Vol. 29, No. 2, Juni 2000, Seiten 153–164) haben ebenfalls ein Verfahren zum Komprimieren von Daten in einem XML-Baum beschrieben. Ein Nachteil dieser Technik ist, dass diese es nicht erlaubt, einen Unterbaum zu identifizieren, eine spezifische Kompressionskodiertechnik einem Datentyp des identifizierten Unterbaums zuzuordnen, und diese Kompressionskodiertechnik nur für die Blätter des Unterbaums durchzuführen, deren Daten von dem mit der Kompressionskodiertechnik verknüpften Typ sind.
Es ist eine Aufgabe der Erfindung, die Nachteile der Techniken des Standes zu kompensieren.
Genauer gesagt, die Erfindung zielt auf ein Bereitstellen einer effizienten Kompressionstechnik für auf XML basierende Dokumente ab.
Die Erfindung zielt auch auf ein Bereitstellen einer Kompressionstechnik für XML ab, welche Überspringbarkeit, hohe Kompressionsraten und eine progressive Konstruktion von Dokumenten bereitstellt.
Die Erfindung zielt auch auf ein effizientes Komprimieren von MPEG-7 Deskriptoren ab.
Eine weitere Aufgabe der Erfindung ist es, ein Verfahren zum Komprimieren eines XML-Dokuments zu implementieren, welches die durch eine Technik vom BiM-Typ bereitgestellte Kompressionsrate stark verbessert, welches aber die gleichen Funktionalitäten wie BiM bereitstellt.
Die oben erwähnten Aufgaben der Erfindung und auch weitere Aufgaben der Erfindung, die später erscheinen werden, werden gemäß der Erfindung gelöst mittels eines Verfahrens zum Komprimieren eines ein Multimedia-Signal beschreibenden hierarchischen Baums, wobei der Baum Knoten und Blätter aufweist, welche mit Inhalten zumindest zweier verschiedener Typen verknüpft werden können, wobei das Verfahren eine Inhaltskompression zumindest einiger der Blätter mittels zumindest zweier Kompressionskodiertechniken durchführt, wobei jede der Techniken selektiv mit zumindest einem der Inhaltstypen verknüpft ist.
Gemäß einem bevorzugten Ausführungsbeispiel der Erfindung umfasst ein solches Verfahren einen Schritt des Identifizierens zumindest eines Unterbaums und einen Schritt des Zuordnens einer der Kompressionskodiertechniken zu dem Unterbaum.
Vorteilhafter Weise umfasst ein solches Verfahren einen Schritt des Durchführens der dem Unterbaum zugeordneten Kompressionskodiertechnik nur für diejenigen Blätter des Unterbaums, deren Inhalt von dem mit der Kompressionskodiertechnik verknüpften Typ ist, und die anderen Blätter des Unterbaums werden keiner Kompressionskodierung unterzogen.
Gemäß einem vorteilhaften Merkmal der Erfindung führt ein solches Verfahren eine parametrische Beschreibung der Kompressionskodiertechniken durch.
Vorzugsweise umfasst ein solches Verfahren auch einen Schritt des Komprimierens der Struktur des Baums.
Vorteilhafter Weise ist der Baum vom BiM-Typ gemäß des MPEG7-Standards.
Vorzugsweise führt eine der Kompressionskodiertechniken eine lineare Quantisierung durch.
Vorteilhafter Weise führt eine der Kompressionskodiertechniken einen statistischen Kompressionsalgorithmus aus.
Vorzugsweise ist der Algorithmus vom GZip-Typ.
Vorteilhafter Weise wird der Algorithmus gleichzeitig für eine Gruppe von Daten ausgeführt, die dem Inhalt von zumindest zwei Blättern entsprechen.
Vorzugsweise repräsentiert der Baum die Struktur eines Dokuments vom XML (Extended markup language)-Typ.
Die Erfindung betrifft auch ein Verfahren zum Dekodieren eines Multimediasignals, das gemäß dem oben genannten Verfahren zum Komprimieren eines hierarchischen Baums komprimiert ist.
Vorteilhafter Weise führt ein solches Verfahren einen Schritt des Auffrischens eines vorliegenden Dekodierungskontexts gemäß einer durch das Signal übermittelten Kodierkontextinformation durch.
Vorzugsweise definiert der vorliegende Kontext zumindest einen Inhaltstyp, wobei das Verfahren einen Schritt des Implementierens einer mit dem Inhaltstyp verknüpften Kompressionskodiertechnik für die Blätter, die einen Inhalt des Inhaltstyps aufweisen.
Die Erfindung betrifft auch ein Signal, das durch das oben beschriebene Verfahren zum Komprimieren eines hierarchischen Baums erzeugt ist.
Andere Merkmale und Bestandteile der Erfindung werden deutlicher im Lichte der nachfolgenden Beschreibung, die als ein rein veranschaulichendes aber nicht einschränkendes Beispiel gegeben ist, und der folgenden Figuren erscheinen:
1 veranschaulicht das Konzept eines Kodierkontexts;
2 beschreibt die Struktur eines gemäß der BiM-Technik kodierten Elements;
3 veranschaulicht einige der Schritte, die gemäß der Erfindung zum Komprimieren des Inhalts der Blätter eines hierarchischen Baums durchgeführt werden.
Vor einer detaillierten Beschreibung, wie die Erfindung zu implementieren ist, werden wir zuerst an die Hauptmerkmale der Kompressionstechnik des Standes der Technik, bekannt als die BiM-Technik, erinnern.
Um das Verstehen des Dokuments zu erleichtern, wurden einige Quellenangaben im Anhang 9 erfasst, und es wird überall im Dokument auf diese Bezug genommen.
Alle mit diesem Dokument bereitgestellten Anhänge sind Bestandteile der vorliegenden Beschreibung der Erfindung.
1. Stand der Technik
Einführung
Ein in 1 veranschaulichter Kodierkontext ist eine Gruppe von Dekodierinformationen, die während einer Dekodierung des Bitstroms benötigt wird. Ein Kodierkontext ist auf den gesamten Unterbaum des Knotens, in dem dieser definiert ist, anwendbar. An jedem der Knoten des Baums kann der Kodierkontext modifiziert werden; wobei das zu der Erstellung eines neuen Kodierkontexts führt, der auf den entsprechenden Unterbaum anwendbar ist.
Ein Kontext kann mehrere Informationen führen, die auf den betroffenen Unterbaum anwendbare Merkmale vorschreiben. Gegenwärtig sind diese Merkmale in dem BiM-Unterbaum-Kodierformat [1] Überspringbarkeit eines Unterbaums/Kontexts und Mehrfachschemakodierung eines Unterbaums/Kontexts (um das Rückwärts- und Vorwärts-Kompatibilitätsmerkmal bereitzustellen). Schließlich kann der Kontextmechanismus in jedem Unterbaum deaktiviert werden, um Bandbreite einzusparen; dieses ist der kontexteingefrorene Modus.
Der Kodierkontextmechanismus stellt maximale Flexibilität in jedem Unterbaum eines Dokumentbaums bereit und erlaubt den Einbau erweiterbarer Merkmale, in den BiM-Kodiermechanismus.
Wir präsentieren nun den gegenwärtigen, in BiM verwendeten Kontextmechanismus.
Gegenwärtiger Kodierkontextmechanismus
Definitionen
Kodierkontext (CodingContext)
Ein Kodierkontext (codingContext) ist eine Gruppe von Informationen, die kontextuellen Informationen, die von dem Dekodierer benötigt werden, um den Bitstrom zu dekodieren. Ein codingContext ist auf den Knoten, in dem er definiert worden ist, und auf den gesamten Unterbaum, der diesem Knoten entspricht, anwendbar.
Der gegenwärtige codingContext (d.h. der an einem spezifizierten Knoten einer Beschreibung anwendbarer Kontext) kann innerhalb des Dokuments modifiziert werden (das heißt, eine Modifikation der ihm unterliegenden Gruppe von Informationen). Jede Modifikation eines codingContext führt zu der Erstellung eines neuen codingContext, der die modifizierte Gruppe von Informationen führt. Es wird für alle codingContexts erwartet, das diese gestapelt werden, um diese zurückzuerhalten, wenn der Dekodierer ein Dekodieren eines einem Unterbaum entsprechenden Kontexts abgeschlossen hat.
Dekodierer (Decoder)
Der BiM decoder besteht aus zwei Dekodierern:

– dem Kontextdekodierer; dieser Dekodierer ist dafür bestimmt, die kontextuelle Information zu dekodieren. Wie zuvor erläutert, stellt die kontextuelle Information keinen Bestandteil der Beschreibung dar. Diese ist eine Gruppe von Informationen, die einige externe Merkmale, Rückwärts- und Vorwärts-Kompatibilität, schnelles Überspringen usw. führt.
– dem Elementdekodierer; dieser Dekodierer ist der BiM-Reguläre [1] und ist dafür bestimmt, die Elementinformationen zu dekodieren.

Chunks
Jedes Element einer Beschreibung wird als das in 2 veranschaulichte 3-plett kodiert, wobei der Kopfteil aus zwei Chunks konstituiert ist, deren Größen Null (nil) sein können:

– MC ist der Metakontext-Chunk;
– C ist der Kontext-Chunk;
– Element ist der Element-Chunk, welcher der reguläre Elementkodier-Chunk ist, siehe [1].

Der MC-Metakontext-Chunk enthält die von dem Dekodierer benötigte Information, um den darauffolgenden C-Chunk zu dekodieren. Das heißt, dass der MC-Chunk der Kontext-Chunk des C-Kontext-Chunks ist.
Der C-Kontext-Chunk enthält die Information, die in der Lage ist, die gegenwärtige Kodierkontext-Gruppe von Informationen zu ändern, und die von dem Dekodierer benötigt wird, um den darauffolgenden Element-Chunk zu dekodieren. Das heißt, dass der C-Chunk der Kontext-Chunk des Element-Chunks ist.
Gruppe von Informationen
Der gegenwärtige BiM-Kodierkontext führt eine Gruppe von Informationen, die kontextuellen Informationen, die in die zwei folgenden Hauptklassen unterteilt werden können:

– den Metakontext-Abschnitt, falls die in diesem Abschnitt enthaltene Information nur den Kontextdekodierungsprozess beeinflusst
– den Kontext-Abschnitt, falls die in diesem Abschnitt enthaltene Information nur den Elementdekodierungsprozess beeinflusst

Die gegenwärtige Gruppe von Informationen wird durch die folgende Gruppe von Variablen gebildet:
Die definierten Klassen kodieren exakt die oben beschriebenen Chunks (den MC-Metakontext-Chunk und den C-Kontext-Chunk).
Metakontext-Chunk
Definition
Der MC-Metakontext-Chunk, dessen Größe Null sein kann, enthält Informationen, um zu wissen, ob der Dekodierer den nächsten C-Kontext-Chunk, dem in der drauffolgenden Abschnitt beschreiben ist, lesen muss.
Involvierten Variablen
Vorgegebene Werte
Der vorgegebene Wert von freezing_state ist false; das heißt, dass bei einer Vorgabe der Wurzelkontext dynamisch verändert werden kann.
Ausbreitungsregeln
Bei der Erstellung eines neuen Kontexts:

– wird der Wert von freezing_state auf den Wert von freezing_state seines Vaterkontexts gesetzt.

Dynamische Modifikationsregeln
An jedem Knoten einer Beschreibung und um einen neuen Kontext zu erstellen:

– kann der Wert von freezing_state von dem Wert false auf den Wert true geschaltet werden.

Dekodierungsregeln
Falls der Wert von freezing_state true ist, wird der MC-Metakontext-Chunk (und der anstehende C-Kontext-Chunk) nicht in den Bitstrom reinkodiert. Sonst wird der MC-Metakontext-Chunk-Teil des Kopfs wie folgt kodiert:
Der context_chunk ist eine lokale Variable, die mit false initiiert ist.
Wie in dem voranstehenden Abschnitt angegeben, impliziert die Modifikation der Variablen des aktuellen Kontexts die Erstellung eines neuen Kontexts.
Einfluss auf den Kontextdekodierungsprozess
Falls der Wert von context_chunk true ist, muss der Dekoder den darauffolgenden C-Kontext-Chunk lesen.
Kontext-Chunk
Definition
Der C-Kontext-Chunk, dessen Größe Null sein kann, enthält eine Gruppe von Informationen, die es erlauben, die gegenwärtigen Kontextvariablen dynamisch zu ändern. Diese Variablen werden als Kodiereigenschaften (codingProperties) bezeichnet, da diese den BiM-Element-Dekodierungsprozess beeinflussen.
Involvierte Kodiereigenschaften
Vorgegebene Werte
Die Variable allows_skip wird am Anfang des Bitstroms durch die ersten zwei Bits des speziellen 4-Bit-Bitfelds so initialisiert, wie es in dem FCD-System-Dokument [1] definiert ist.
Die Variable allows_partial_instantiation wird am Anfang des Bitstroms durch die dritten zwei Bits des speziellen 4-Bit-Bitfelds initialisiert.
Die Variable allows_subtyping wird am Anfang des Bitstroms durch die vierten zwei Bits des speziellen 4-Bit-Bitfelds initialisiert.
Der vorgegebene Wert von schema_mode ist mono; das heißt, dass bei einer Vorgabe der Unterbaum/Kontext der Wurzel mit einem Schema kodiert wird.
Ausbreitungsregeln
Bei der Erstellung eines neuen Kontexts:

– der Wert von allows_skip wird auf den Wert von allows_skip seines Vaterkontexts gesetzt
– der Wert von allows_partial_instantiation wird auf den Wert seines Vaterkontexts gesetzt
– der Wert von allows_subtyping wird auf den Wert seines Vaterkontexts gesetzt
– der Wert von schema_mode wird auf seinen vorgegebenen Wert gesetzt

– kann allows_skip dynamisch modifiziert werden
– kann allows_partial_instantiation nicht dynamisch modifiziert werden
– kann allows_subtyping nicht dynamisch modifiziert werden
– kann schema_mode dynamisch modifiziert werden

Dekodierungsregeln
Der C-Kontext-Chunk liegt nur dann vor, falls der MC-Metakontext-Chunk bereits vorliegt und seine vorherige lokale Variable context_chunk den Wert true hat.
Die dynamische Modifikation des gegenwärtigen Kontexts wird mit einem XML-Element beschrieben, das mit dem regulären BiM-Kodierschema kodiert wird. Es wird das globale Element modifyContext aus dem BiM-Schema verwendet. Das http://www.mpeg7.org/2001/BiMCoding-Kodierschema wird im Anhang 1 beschrieben.
Der C-Kontext-Chunk muss mit dem regulären BiM-Schema, mit dem obigen Schema, dekodiert werden.
Wie zuvor dargestellt, impliziert die Modifikation der gegenwärtigen codingProperties in dem Kontext die Erstellung eines neuen Kontexts. Daher impliziert das Vorliegen des C-Kontext-Chunks die Erstellung eines neuen Kontexts, der die modifizierten codingProperties führen wird.
Falls das Element allowsSkip innerhalb des Elements modifyContext instanziiert wird, so wird der Wert von allows_skip in dem neuen Kontext aktualisiert.
Falls das Element schema_mode innerhalb des Elements modifyContext instanziiert wird, so wird der Wert von schema_mode in dem neuen Kontext aktualisiert.
Einfluss auf dem Elementdekodierungsprozess
Die Werte von allows_skip und schema_mode beeinflussen den Elementdekodierungsprozess, wenn das Überspringmerkmal behandelt wird. Dieses Verhalten wird in [1] beschrieben.
Der Wert von schema_mode beeinflusst den Elementdekodierungsprozess, um zu wissen, ob das Element mit nur einem Schema oder mehreren Schemen kodiert ist. Dieser Mechanismus wird in [1] beschrieben.
Der Wert von allows_partial_instantiation beeinflusst den Elementdekodierungsprozess durch Hinzufügen eines speziellen Typs, des partiallyInstantiated-Typs, zu den möglichen Untertypen des Elements. Siehe [1].
Der Wert von allows_subtyping beeinflusst den Elementdekodierungsprozess und erlaubt einem Element oder einem Attribut im Falle eines Element-Polymorphismus (mit dem Attribut von xsi:Typ (xsi:type)) oder einer -Vereinigung, verschiedene mögliche Typen zu haben. Siehe [1].
2. Beschreibung der Erfindung
2.1 Erweiterung des Kontextmechanismus, um ein Rahmenwerk für eine Blattkompression bereitzustellen
Die Erfindung schlägt vor, den gegenwärtigen BiM-Kontextmechanismus zu erweitern, um ein neues und interessantes Merkmal zu unterstützen: das Verwenden von lokalen Kompressoren zum Komprimieren von Blättern eines Dokuments, um die Größe des sich ergebenden Bitstroms zu reduzieren.
Dieser Abschnitt beschreibt, wie der gegenwärtige BiM-Kontextmechanismus zu erweitern ist, um das Verwenden von lokalen Kompressoren zu unterstützen. Das ist typischer Weise eine neue Gruppe von Variablen, codingProperties, die mit spezifischen Semantik-, Ausbreitungs- und Kodier-Regeln verknüpft ist. Daher erweitert diese neue Gruppe der codingProperties den gegenwärtigen Kontext-Chunk.
Einführung
In einem Unterbaum können alle Instanzen eines oder mehrerer spezifizierter einfacher Typen mit einem oder mehreren spezifizierten Kompressoren komprimiert werden. Grundsätzlich definiert dies ein Abbilden zwischen einem Kompressor und einem oder mehreren einfachen Typen.
Außerdem:

– kann in einigen Fällen ein Kompressor einige externe Parameter benötigen
– kann ein Abbilden aktiviert/deaktiviert werden, um einen Kompressor in einigen Unterbäumen zu verwenden, aber nicht in anderen

Schließlich sollte ein Abbilden, um aktiviert/deaktiviert zu werden, verweisbar sein und daher eine eindeutige Identifizierung in einem Kontext aufweisen.
Daher kann jeder Kontext null, einen oder mehrere codecTypeMapper führen; wobei ein codecTypeMapper ein 4-plet ist, das aus einer Identifizierung, einem oder mehreren einfachen Typen, einem Codec, optionalen externen Codec-Parametern und einem Aktivierungszustand besteht.
Definitionen
CodecTypeMapper
Ein codecTypeMapper ist ein 4-plet bestehend aus:

– einer Identifizierung, die als ein eindeutiger Verweis-Schlüssel in einem Unterbaum/Kontext verwendet wird
– einem oder mehreren einfachen Typen, auf die das Abbilden anwendbar ist
– einem Codec
– optionalen externen Codec-Parametern (sind von dem Codec abhängig)
– einem Aktivierungszustand

Identifizierung
Die Identifizierung ist eine eindeutige Nummer, die ein Abbilden innerhalb eines Kontexts auf eine unzweideutige Weise identifiziert. Das BiM-Kodierschema schränkt die maximale Anzahl von codecTypeMappern in einem Kontext auf 32 ein.
Einfacher Typ
Alle in einem Schema definierten einfachen Typen können a priori durch jeden Codec kodiert werden, aber jeder Codec kann diese Auswahl einschränken. Zum Beispiel kann ein linearer Quantisierer, so wie im Dokument nachstehend definiert, nur mit numerischen einfachen Typen verwendet werden.
Ein einfacher Typ wird durch seinen Namen und die URL des zugehörigen Schemas identifiziert. Es sollten Präfixe des XML-Schemas verwendet werden, um auf das korrekte Schema hinzuweisen. Das BiM-Kodierschema definiert einen speziellen Typ, um dieses Paar zu kodieren; dieser Typ sollte als ein Paar von ganzen Zahlen kodiert werden; die erste ganze Zahl ist auf die gegenwärtige Anzahl von bekannten Schemata eingeschränkt (dieser Teil der Information kann in dem DecoderConfig-Teil [1] abgerufen werden) und die zweite ganze Zahl ist auf die Anzahl von globalen einfachen Typen eingeschränkt, die in dem entsprechenden Schema vorliegen.
Codec
Ein codec, was für Kompressor/Dekompressor steht, ist ein Modul, das Eingangsbits aufnimmt und Ausgangsbits schreibt. Es kann einige optionale externe Parameter benötigen.
Ein Codec wird durch einen Namen unter den Namen von nicht-abstrakten, in dem BiM-Kodierschema definierten Codecs identifiziert. Das in dem obigen Abschnitt definierte gegenwärtige BiM-Kodierschema definiert keinen nicht-abstrakten Codec, dieses tut aber der §2.2 des vorliegenden Dokuments.
Aktivierungszustand
Der Aktivierungszustand ist eine boolesche Kennung.
Semantische Regeln
CodecTypeMapper
Jeder Kontext:

– kann null, einen oder mehrere codecTypeMappers führen
– kann einen oder mehrere codecTypeMappers definieren
– kann einen oder mehrere bestehende codecTypeMapper aktivieren oder deaktivieren

Falls ein codecTypeMapper in einem Kontext definiert ist, verbleibt dieser in allen seinen Unterkontexten.
Ein bestehender codecTypeMapper kann innerhalb eines Kontexts weder gelöscht noch modifiziert werden (mit Ausnahme seines Aktivierungszustands).
Identifizierung
Die Identifizierung einer Abbildung muss unter allen codecTypeMappern eines Kontexts eindeutig sein.
Einfacher Typ
Wenn Sie in einem codecTypeMapper einen oder mehrere einfache Typen und einen Codec verknüpfen, so wird der Codec die einfachen Typen selbst und alle von diesen abgeleiteten einfachen Typen kodieren/dekodieren.
In einem Kontext darf höchstens ein einfacher Typ vorhanden sein, der mit einem Codec anwendbar ist.
Codec
Es gibt zwei Typen von Codecs: speicherlose Codecs und kontextuelle Codecs.
Ein speicherloser Codec ist ein Modul, das immer die gleichen Eingangsbytes in die gleichen Ausgangsbytes kodiert; unabhängig von der Historie des Codec. Ein typischer speicherloser Codec ist eine linearer Quantifizierer. Die BiM-Blatt-Kompression (siehe §2.2 des vorliegenden Dokuments) beschreibt einen solchen Codec.
Ein kontextueller Codec ist ein Modul, das die vorherigen, in diesen eingespeisten Bytes verwendet (somit den Kontext des Codec ändernd). Ein solcher Codec erzeugt nicht die gleichen Ausgangsbytes für die gleichen Eingangsbytes, die er empfängt. Ein typischer kontextueller Codec ist ein Zip-ähnlicher lokaler Codec, der im §2.2 des vorliegenden Dokuments beschrieben ist.
Ein speicherloser Codec führt zu keinen Problemen in der gegenwärtigen Kontextarchitektur, was aber ein kontextueller Codec im Falle eines überspringbaren Unterbaums tut. In solchen Fällen wird ein kontextueller Codec zurückgesetzt, um den Dekodierer nicht zu verwirren, wenn dieser vorher den Unterbaum übersprungen hat.
Aktivierungszustand
In jedem Unterbaum/Kontext kann ein codecTypeMapper aktiviert oder deaktiviert sein.
Dieser Mechanismus erlaubt es, einen codecTypeMapper in einer höheren Ebene des Dokumentenbaums zu definieren und diesen nur in den Unterbäumen zu aktivieren, in denen dieser verwendet wird, ohne den codecTypeMapper neu zu definieren.
Eine neue Kodiereigenschaft (codingProperty): codecTypeMapper
In diesem Teil fügen wir eine neue codingProperty zu der vorherigen Gruppe von Variablen des Kontextabschnitts hinzu, die vorher beschrieben wurde. Diese neue codingProperty wird als codecTypeMapper bezeichnet und ist eine Liste der vorherigen codecTypeMapper, die in dem vorherigen Abschnitt beschrieben wurden.
Neu involvierte codingProperty
Der Kontext führt eine Liste von codecTypeMapper:
Neue vorgegebene Werte
Es ist vorgegeben, dass es keinen codecTypeMapper in einem Unterbaum/Kontext gibt.
Falls ein codecTypeMapper innerhalb eines Kontexts definiert ist, müssen seine Identifizierungen, Codec und ein Wert von simple_type definiert sein. Falls diese nicht spezifiziert sind, wird der Zustand der Aktivierung eines neu definierten codecTypeMapper durch Vorgabe auf true gesetzt; das heißt, dass ein neu definierter codecTypeMapper als Vorgabe aktiviert wird.
Neue Ausbreitungsregeln
Regel 1: Bei der Erstellung eines neuen Kontexts ist die codedTypeMapper-Liste die Kopie ihres Vaterkontexts:

– der Wert der Identifizierung wird kopiert
– der Wert von simple_type wird kopiert
– der Codec-Wert wird gemäß der Regel 2 kopiert
– der Werte von codec_parameters werden kopiert
– der activation_state wird kopiert

Regel 2: Der Codec-Wert wird kopiert und
falls:

– der Codec des Vaters codingProperty[i].codec ein kontextueller Codec ist
– und falls der gegenwärtige Kontext überspringbar ist

Dann
wird von dem Dekodierer erwartet, eine neue Instanz des Kodex durch ein Kopieren der Instanz des Codecs des Vaters (nicht nur seines Werts) zu erstellen und diese zurückzusetzen.
Zum Beispiel würde ein ZLib-Codec kopiert und re-initialisiert werden, wenn ein übersprigngbarer Knoten betreten wird.
Neue dynamische Modifikationsregeln
Die Liste von codecTypeMapper kann innerhalb der Beschreibung dynamisch modifiziert werden:

– ein neuer codecTypeMapper kann definiert werden
– der activation_state eines bestehenden (somit verweisbaren) codecTypeMapper kann dynamisch modifiziert werden

Ein bestehender codecTypeMapper kann nicht gelöscht werden und seine Bestandteile können nicht dynamisch modifiziert werden (mit Ausnahme seines activation_state).
Neue Dekodierungsregeln
Die gleichen vorher genannten Regeln werden auf die Dekodierung eines C-Kontext-Chunks angewandt, dabei soll aber das neue, im Anhang 2 beschriebene Schema verwendet werden, um die neue dynamische Modifikationsfunktionalitäten des codecTypeMappers hinzuzufügen.
Informativer Teil
Beispiele
Das im Anhang 3 veranschaulichten Beispiel stellt die Definition eines aktivierten linearen Quantisierers (siehe §2.2 des vorliegenden Dokuments) in einer Beschreibung vor.
Das im Anhang 4 veranschaulichte Beispiel stellt die Definition eines deaktivierten linearen Quantisierers in einer Beschreibung vor.
2.2 BiM-Blattkompression
Wir stellen nun den Mechanismus vor, der durch die Erfindung implementiert wird, um Daten mit verschiedenen Codecs zu kodieren. Genauer gesagt, veranschaulichen wir nun zwei Beispiele, eines, in dem ein linearer Quantisierungs-Codec verwendet wird, um beispielsweise Gleitkommawerte zu komprimieren, und das andere, in dem ein gzip-Codec verwendet wird, um beispielsweise Zeichenkettenwerte zu komprimieren.
Ein solcher Mechanismus ist eng mit dem Kodierkontext verwandt und erlaubt das Verwenden von mehreren anderen Typen des Codecs. Ferner erlaubt er, mit Merkmalen eines Kodierkontexts, zum Beispiel überspringbaren Unterbäumen, richtig zu handeln. Schließlich erlaubt er eine Wiederverwendung von Codecs in verschiedenen Kodierkontexten.
Einführung
Die BiM-Unterbaum-Kodierung [1] komprimiert nicht die Datenblätter einer Beschreibung. Gegenwärtig werden Werte von Blättern in Bezug auf deren Typen (IEEE 754 Floats und Doubles, UFT-Zeichenketten ...) kodiert.
In vielen Fällen kann es sinnvoll sein, einige klassische Kompressionstechniken wie lineare Quantisierung oder statistische Kompression zu verwenden, um die Kompressionsrate von BiM zu verbessern, ohne dabei seine Hauptmerkmale (datenstromlinienweise Syntaxanalyse, Merkmal des schnellen Überspringens, typenbezogene Dekodierung) zu verlieren.
Dieses Dokument stellt vor, wie eine Datenblattkompression eines Dokuments innerhalb des im §2.1 beschriebenen Kontextkodiermechanismus vollbracht werden kann, um bessere Kompressionsraten zu erreichen.
2.2.1 Lineare Quantisierung
Definition
Lineare Quantisierung ist ein üblicher und verlustreicher Weg, um die Größe von kodierten Zahlen in dem Bitstrom zu reduzieren, wenn die Quelle der Information bekannt ist und folglich wenn Verluste gesteuert werden können.
Die Hülle eines abgetasteten Audiosignals, als ein Beispiel, ist oft mit einer präzisen Bitgrößen-Quantisierung bekannt, und diese Technik kann nutzbringend für eine Kodierung von MPEG-7-Audiobeschreibungen verwendet werden.
Falls ν eine ganze Zahl ist, kann diese mit ν_q mit nbits Bits kodiert werden, wobei:
wobei:

– ν_q der quantisierte, kodierte Wert von ν ist
– nbits die benötigte Präzision in Bits ist
– ν_min der minimale einschließende Wert ist, den ν erreichen kann
– ν_max der maximale einschließende Wert ist, den ν erreichen kann

Und der dekodierte Wert von ν ist v, mit:
wobei:

– v der dekodierte, angenäherte Wert von ν ist

Integration mit dem Kontextmechanismus: der LinearQuantizerCodec
Lineare Quantisierung kann als ein Codec, wie in dem im §2.1 des vorliegenden Dokuments beschriebenen Kodierkontextmechanismus definiert, verwendet werden. Mit diesem Mechanismus kann eine lineare Quantisierung auf numerische Datenblätter von einem gewünschten einfachen Typ in jedem Unterbaum einer Beschreibung angewandt werden.
Der auf eine solche Art und Weise verwendete, mit dem linearen Quantisierungs-Codec verknüpfte Kodierkontextmechanismus agiert als der in MPEG-4 BIFS [3] verwendete QuantizationParameter-Knoten.
Einschränkung auf anwendbare einfache Typen
Gemäß der Definition eines Codec im §2.1 des vorliegenden Dokuments ist der Codec ein speicherloser Codec, der auf jeden der einfachen numerischen Typen einer Ordnung oder Nicht-Ordnung angewandt werden kann; dessen primitiver Typ eines XML-Schemas ein Float, Double oder eine dezimale Zahl ist.
Externe Parameter eines Codec
Der lineare Quantisierungs-Codec benötigt die folgenden 3 zwingend notwendigen Parameter:

– bitSize; die oben beschriebene Variable nbits
– minInclusive; die oben beschriebene Variable ν_min
– maxInclusive; die oben beschriebene Variable ν_max

Schemadefinition des Codec
Der lineare Quantisierugs-Codec ist ein neuer Codec vom Typ LinearQuantizerCodecType, der auf dem abstrakten Typ CodecType (siehe §2.1) basiert und das durch das im Anhang 5 vorgestellte Schema definiert ist, in dem Kodierkontext-Namensraum URL xmlns:cc=http://www.mpeg7.org/2001/BiMCoding.
Kodierung (informativ)
Ein numerisches Datenblatt vom Wert ν wird mit der vorzeichenlosen ganzen Zahl ν_q auf nbits Bits kodiert, wobei:
Dekodierung
Die vorzeichenlose ganze Zahl ν_q, die auf nbits Bits kodiert ist, sollte als ν dekodiert werden, wobei:
Beispiel (informativ)
Das im Anhang 6 veranschaulichte Beispiel stellt die Definition eines linearen Quantisierers in einer Beschreibung dar.
2.2.2 Statistische Kompression
Klassische verlustfreie Kompressionsalgorithmen können als Codecs verwendet werden, wie in dem Kodierkontextmechanismus (siehe §2.1) definiert. Mit diesem Mechanismus können Datenblätter eines gewünschten einfachen Typs effizient im beliebigen Unterbaum einer Beschreibung komprimiert werden.
Dieser Codec ist für eine signifikante Reduzierung der Größe des Bitstroms nützlich, insbesondere, wenn die Beschreibung viele sich wiederholende oder ähnliche Zeichenketten enthält.
Definition
Klassische verlustfreie Kompressionsalgorithmen (wie Zip oder GZip) können im BiM verwendet werden, um beliebige Blätter einer Beschreibung zu komprimieren.
In den meisten Fällen jedoch, wenn Datenblätter kurze Zeichenketten sind, die weniger als 10 Zeichen enthalten, führt dieser zu schwachen Leistungen, da ge wöhnliche statistische Kompressionsalgorithmen einen größeren vorausschauenden Puffer benötigen.
Um eine optimale Kompressionsrate zu erreichen, müssen die Blätter eines Dokuments, bevor sie komprimiert werden, in einem kleinen Puffer gepuffert werden. Der nachfolgende Abschnitt definiert einen solchen gepufferten statistischen Kodierer, der auf einen zugrunde liegenden verlustfreien statistischen Kompressionsalgorithmus gestützt ist.
Definitionen eines gepufferten statistischen Kodierers
Ein gepufferter statistischer Kodierer stützt sich auf einem zugrunde liegenden statistischen Kodierer, der die folgenden generischen primitiven Verfahren enthalten sollte:

– initialize_stream(); das einen Komprimier- oder einen Dekomprimier-Strom initialisiert
– reset_model(); das das gegenwärtige statistische Model des Kodierers zurücksetzt
– feed_input_bytes(); das Eingangs-Dekomprimierbytes nimmt und diese in den Komprimierstrom reinsetzt
– flush_output_bytes(); das den Komprimierstrom durch Komprimieren der bereits bearbeiteten Eingangsbytes und durch Aussenden der entsprechenden komprimierten Ausgangsbytes leert
– decompress_input_bytes(); das eine spezifizierte Menge von eingegebenen komprimierten Bytes nimmt und diese durch Aussenden der entsprechenden dekomprimierten Ausgangsbytes dekomprimiert

Ein gepufferter Codec hat eine Länge von bufferSize Bytes, eine Bytearraybuffer-FIFO-Struktur.
Von der Seite eines Kodierers gibt der Wert bufferSize an, wie viele Eingangsbytes der Kodierer vor dem Leeren verarbeiten kann. Von der Seite eines Dekodiers ist dieses die minimale Puffergröße in Bytes, die benötigt wird, um den Bitstrom zu dekodieren, durch die API eines zugrunde liegenden statistischen Kodierers.
Der Puffer hat auch eine Variable fillingLevel, die den tatsächlichen Füllpegel des Puffers in Bytes enthält.
Verwenden der ZLib API als statistischer Kodierer
Die API der öffentlichen ZLib-Bibliothek [4], die in dem GZip-Kompressionsschema verwendet wird, stellt eine effiziente und nützliche API zum Verwenden einer statistischen Kompression auf Blätter eines Dokuments bereit.
Die ZLib API erfüllt die vorherigen generischen Verfahren mit folgender Abbildung aus:

– initialize_stream() kann mit den Zlib-Funktionen inflatelnit() oder deflatelnit() abgebildet werden, mit dem Effizienzwertparameter Z_DEFAULT_COMPRESSION.
– reset_model() kann mit einem Zlib-Aufruf inflateEnd() oder deflateEnd() und einem darauffolgenden Aufruf initialize_stream() abgebildet werden.
– feed_input_bytes() kann mit dem Zlib-Verfahren deflate() mit dem Parameter Z_NO_FLUSH abgebildet werden.
– flush_output_bytes() kann mit dem Zlib-Verfahren deflate() mit dem Parameter Z_SYNC_FLUSH abgebildet werden.
– decompress_input_bytes() kann mit dem Zlib-Verfahren inflate() abgebildet werden.

Der ZLib gepufferte Codec sollte mit dem Effizienzwert Z_DEFAULT_COMPRESSION initialisiert werden, wie in [4] definiert, was einen guten Kompromiss zwischen den Erfordernissen eines Speicher-Footprints und Kompressionseffizient bereitstellt.
Integration mit dem Kontextmechanismus: der ZLibCodec
Dieser Abschnitt beschreibt die Integration des vorherigen gepufferten statistischen Kodierers, der auf der ZLib API stützend innerhalb des Kodierkontextmechanismus definiert ist.
Einschränkung auf anwendbare einfache Typen
Gemäß der Definition eines Codec in §2.1 ist dieser Codec ein kontextueller Codec, der auf jeden Zeichenketten-Typ einer Ordnung oder Nicht-Ordnung angewandt werden kann. Der ZLibCodec ist auf dem zugrunde liegenden primitiven Kodieren von Blättern eines Dokuments, wie in [1] beschrieben, gestützt. Zum Beispiel werden int-Blätter mit einer ganzen vorzeichenlosen 32-Bit-Zahl kodiert, string mit einer UFT-8-Kodierung, float und double werden mit dem IEEE 754-Format kodiert, ... Daher wird der ZlibCodec das kodierte Blatt komprimieren
Externe Codec-Parameter
Der gepufferte ZLib-Codec benötigt keine externen Parameter, da die Effizienz der zugrundeliegenden ZLib auf Z_DEFAULT_COMPRESSION gesetzt ist und da der Parameter bufferSize auf Seite des Dekodierers nicht benötigt wird.
Definition des Schemas des Codec
Der ZLib-Codec ist ein neuer Codec vom Typ ZlibCodecType, der auf dem abstrakten Typ CodecType (siehe §2.1) basiert und durch das im Anhang 7 veranschaulichte Schema definiert ist, im Namensraum des Kodierkontexts.
Kodierung (informativ)
Bei der Aktivierung/Instanziierung des Codec:

– wird angenommen, dass die Struktur eines Puffers eines FIFO klar ist, sein fillingLevel wird auf 0 gesetzt
– wird die globale Variable referencable_chunk auf Null initialisiert

Die referencable_chunk sollte einen verweisbaren Chunk von Bits enthalten, die durch den Kodierer bereitgehalten werden müssen, da ihr Wert später während des Kodier-Prozesses bekannt sein wird. Die Signalisierungsfunktion signal_reference_chunk_known() könnte aufgerufen werden, wenn dieser Chunk bekannt ist.
Die Größe in Bytes eines jeden nicht-nil Chunks sollte während des Aufrufs flush_output_bytes() mit der standardisierten vorzeichenlosen, unbegrenzten ganzzahligen 4 + 1-Kodierung, wie in [1] definiert, vor dem Chunk selbst geschrieben werden.
Ein Eingang leaf ist der kodierte Wert eines textuellen leaf in Bezug auf seinen primitiven Typ. Die Länge des leaf in Bytes ist durch das Feld leaf.length gegeben. Zum Beispiel [1], ein string Blatt ist ein UTF-8-Code, vorausgegangen durch die Größe der Zeichenkette (kodiert mit der unbegrenzten Ganzzahl-Kodierung [1]) in Bytes; ein double-Blatt ist der 64-Bit-Wert des entsprechenden IEEE 754-Standards ...
Die folgende Funktion encode_leaf ist in der Lage, ein leaf in einem Chunk von Ausgangsbytes zu kodieren:
Dekodierung
Sei string_fifo ein Zeichenketten-FIFO.
Die folgenden Verfahren get() bzw. put() nehmen ein Element aus dem bzw. legen ein Element in den FIFO.
Das Verfahren isEmpfy() signalisiert, ob der Fifo leer ist
Sei sub die Funktion, die eine Unterzeichenkette nimmt.
Sei concat die Konkatinierungs-Funktion
Sei getDate() die Funktion, die das char[], das die Daten eines Blatts de-gzip enthält, zurückgibt.
Sei split(char[], char sep, Fifo, char[] remainder) das Verfahren, das ein Feld von Zeichen an jedem Separator ,sep' abspaltet und die abgespalteten Elemente der Zeichenkette in dem Fifo speichert, und den Restbestand zurückgibt (d.h. der letzte Chunk hat keinen ,sep', um diesen abzuschließen)
Bei einer Initialsierung ist string_fifo leer.
Bei der Aktivierung/Instanziierung des Codecs:

– wird erwartet, dass die Struktur von FIFO klar ist, ihre numberOfLeaves wird auf 0 gesetzt
– wird die Variable first_chunk auf true gesetzt

Sei das Byte des Separators 0x00.
Die folgende Funktion decode_leaf ist in der Lage, ein komprimiertes Blatt aus dem Bitstrom zu dekodieren:
Eine Dekodierung ist definiert durch:

1. Falls der FIFO leer ist:
a. dekodiere die kodierten Daten,
b. staple in einem FIFO alle Elemente, die durch 0x00 getrennt sind
c. falls das letzte Zeichen nicht 0x00 ist, speichere die nicht abgeschlossene Zeichenkette temporär.
d. falls „last_element" nicht leer ist, füge es dem Anfang des ersten Elements im FIFO an
e. lege die nicht abgeschlossene Zeichenkette dieser Runde im last_element ab.
f. lösche und gebe das erste Element zurück.
2. Falls der FIFO nicht leer ist, lösche und gebe das erste Element zurück. Das ist äquivalent zu der Aussage: „der FIFO ist nicht leer" und zu der Aussage „es sind keine kodierten Daten in dem gegenwärtigen Blatt vorhanden."

Beispiel (informativ)
Die im Anhang 8 gegebene Beschreibung ist ein Beispiel für die Verwendung des mit den Typen string und anyURI abgebildeten ZlibCodecType-Codecs.
Ergebnisse (informativ)
Die folgenden Figuren zeigen die Leistungen der Verwendung des ZLibCodec, um textuelle Blätter von Beschreibungen (solchen, die von den primitiven Typen string und anyURI eines XML-Schemas abgeleitet wurden) zu komprimieren. Ein Buffer mit bufferSize = 256 Bytes wurde während des Kodierprozesses verwendet.
Die verwendeten Dateien wurden von der MPEG7-MDS-Untergruppe bereitgestellt.
Wir werden nun schnell die gemäß der Erfindung implementierten Schritte zum Komprimieren des Inhalts der Blätter eines hierarchischen Baums beschreiben.
Schritt 1 besteht in einem Verknüpfen einer Kompressionskodiertechnik mit einem Inhaltstyp. So zum Beispiel kann eine lineare Quantisierung mit Gleitkommawerten verknüpft werden.
Im Schritt 2 wird ein Unterbaum innerhalb des hierarchischen Baums entsprechend der Struktur des betrachteten XML-Dokuments identifiziert.
Schritt 3 besteht in einem Zuordnen einer Kompressionskodiertechnik zu dem identifizierten Unterbaum.
Schritt 4 besteht dann in einem Prüfen, ob der Codec, der die Kompressionskodiertechnik durchführt, aktiviert ist oder nicht. Falls nein, wird keine Kompression (5) der Blätter des Unterbaums erreicht.
Falls ja, führt die Erfindung ein Komprimieren des Inhalts der Blätter des Unterbaums durch (6), deren Inhalt von dem mit der Kompressionskodiertechnik verknüpften (1) Inhaltstyp sind.
ANHANG 1
ANHANG 2
ANHANG 3
ANHANG 4
ANHANG 5
ANHANG 6
ANHANG 7
ANHANG 8
ANHANG 9
Quellenangabe

1 – MPEG-7 Systems FCD, N4001, MPEG Singapore meeting, March 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 verfügbar auf http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1950.html

Claims

Verfahren zum Komprimieren eines ein Multimedia-Signal beschreibenden hierarchischen Baums, wobei der Baum Knoten und Blätter aufweist, welche mit Daten zumindest zweier verschiedener Arten, genannt Datentypen, verknüpft werden können, wobei das Verfahren eine Datenkompression zumindest einiger der Blätter durchführt, und wobei das Verfahren umfasst: – einen Schritt des Identifizierens (2) zumindest eines Unterbaums; – einen Schritt des Zuordnens (3) einer Kompressionskodiertechnik zu dem Unterbaum (den Unterbäumen) für zumindest einen Datentyp; – und einen Schritt des Durchführens (6) der dem Unterbaum zugeordneten Kompressionskodiertechnik, nur für diejenigen Blätter des Unterbaumes deren Daten von dem mit der Kompressionskodiertechnik verknüpften Typ sind, während die anderen Blätter des Unterbaums keiner Kompressionskodierung unterzogen werden.
Verfahren nach Anspruch 1, das ein parametrisches Beschreiben der Kompressionskodiertechniken durchführt.
Verfahren nach einem der Ansprüche 1 und 2, umfassend auch einen Schritt des Komprimierens der Struktur des Baums.
Verfahren nach einem der Ansprüche 1 bis 3, wobei der Baum von dem BiM (Binären MPEG) Typ gemäß dem MPEG7-Standard ist.
Verfahren nach Anspruch 4, wobei die Datentypen einfache Typen gemäß dem MPEG7-Standard sind.
Verfahren nach einem der Ansprüche 1 bis 5, wobei eine der Kompressionskodiertechniken eine lineare Quantisierung durchführt.
Verfahren nach einem der Ansprüche 1 bis 6, wobei eine der Kompressionskodiertechniken einen statistischen Kompressionsalgorithmus durchführt.
Verfahren nach Anspruch 7, wobei der Algorithmus von dem GZip-Typ ist.
Verfahren nach einem der Ansprüche 7 und 8, wobei der Algorithmus gleichzeitig für eine Gruppe von Daten durchgeführt wird, die den Daten zumindest zweier Blätter entsprechen.
Verfahren nach einem der Ansprüche 1 bis 9, wobei der Baum die Struktur eines Dokuments vom XML (Extended markup language)-Typ repräsentiert.
Verfahren nach einem der Ansprüche 1 bis 10, auch umfassend einen Schritt des Verknüpfens zumindest eines Kodierkontexts mit dem Unterbaum, wobei der Kodierkontext Informationsteile aufweist, die es erlauben, den Unterbaum während des Dekodierens des hierarchischen Baums zu überspringen.
Verfahren nach Anspruch 11, wobei die Informationsteile umfassen: – einen Informationsteil, der die verwendete Kompressionskodiertechnik angibt; und/oder – einen Informationsteil, der angibt, ob der entsprechende Unterbaum komprimiert worden ist; und/oder – einen Informationsteil, der angibt, ob der entsprechende Unterbaum überspringbar ist; und/oder – einen Informationsteil, der angibt, dass zumindest ein Parameter der verwendeten Kompressionskodiertechnik modifiziert worden ist.
Verfahren zum Dekodieren eines Multimediasignals, das gemäß dem Verfahren nach einem der Ansprüche 1 bis 12 komprimiert ist.
Verfahren nach Anspruch 13, das einen Schritt des Auffrischens eines vorliegenden Dekodierungskontexts entsprechend einer durch das Signal übermittelten Kodierkontextinformation durchführt.
Verfahren nach Anspruch 14, wobei der vorliegende Kontext zumindest einen Datentyp definiert, wobei das Verfahren einen Schritt des Durchführens einer mit dem Datentyp verknüpften Kompressionskodiertechnik umfasst, für die Blätter, die Daten des Datentyps umfassen.
Signal repräsentativ für einen hierarchischen Baum, der gemäß dem Verfahren nach einem der Ansprüche 1 bis 12 komprimiert ist, wobei der Baum Knoten und Blätter aufweist, die mit Daten zumindest zweier verschiedener Arten, genannt Datentyp, verknüpft werden können, wobei der Baum auch zumindest einen Unterbaum aufweist, dem eine Kompressionskodiertechnik für zumindest einen Datentyp zugeordnet ist, wobei das Signal zumindest ein Feld aufweist, welches enthält: – die Blätter des Unterbaums, deren Daten von dem Datentyp sind, der mit der Kompressionskodiertechnik verknüpft ist, und die dem Kompressionskodieren unterzogen wurden; – die anderen Blätter der Unterbaums, deren Daten nicht von dem Datentyp sind, der mit der Kompressionskodiertechnik verknüpft ist, und die nicht dem Kompressionskodieren unterzogen wurden.
Signal nach Anspruch 16, wobei das Signal auch umfasst: – zumindest ein Feld, das die Kompressionskodiertechnik angibt, welche dem Unterbaum (den Unterbäumen) für den zumindest einen Datentyp zugeordnet ist; – zumindest ein Feld, das den zumindest einen Datentyp angibt, welcher mit der Kompressionskodiertechnik für den Unterbaum (die Unterbäume) verknüpft ist.
Signal nach Anspruch 17, wobei das Signal auch zumindest ein Feld aufweist, das zumindest einen Parameter der Kompressionskodiertechnik angibt, die dem Unterbaum (den Unterbäumen) für zumindest einen der Datentypen zugeordnet ist.