專利名稱：壓縮層次樹的方法、相應(yīng)的信號以及解碼信號的方法
技術(shù)領(lǐng)域：
本發(fā)明的領(lǐng)域是數(shù)據(jù)壓縮。更確切地說，本發(fā)明涉及對基于XML(“擴展標記語言”)的文檔進行壓縮。
本發(fā)明尤其應(yīng)用于以下領(lǐng)域，但并不僅限于這些領(lǐng)域，其中包括-多媒體應(yīng)用；-指數(shù)化(indexation)工具；-元數(shù)據(jù)操作工具；-MPEG-7規(guī)范；-SMIL；-即時電視點播(TV anytime)；-第三代無線電通信(3GPP)。
對XML而言，現(xiàn)有技術(shù)的壓縮技術(shù)方法存在若干缺陷。特別地，這些技術(shù)方法沒有同時支持快速數(shù)據(jù)存取、高壓縮比以及文檔的漸進式構(gòu)造。換句話說，在支持上述特征之一時，通常將會失去其他所有特征。
在現(xiàn)有技術(shù)中，有一種壓縮技術(shù)被稱為BiM(二進制MPEG)。這種技術(shù)提供了一種通過二值化XML文檔結(jié)構(gòu)而對所述文檔進行壓縮的方法，其中所述XML文檔結(jié)構(gòu)即為關(guān)聯(lián)于所述XML文檔的樹形結(jié)構(gòu)的節(jié)點。因此，盡管這種BiM技術(shù)提供了快速數(shù)據(jù)存取、文檔的漸進式構(gòu)造和跳越性(skippability)，然而實施這種BiM技術(shù)所獲取的壓縮比卻依然很低。
本發(fā)明的一個目的是彌補現(xiàn)有技術(shù)的方法的缺陷。
更確切的說，本發(fā)明旨在提供一種用于那些基于XML的文檔的有效壓縮技術(shù)。
而且，本發(fā)明旨在提供一種用于XML的壓縮技術(shù)，這種技術(shù)提供了跳越性、很高的壓縮比以及文檔的漸進式構(gòu)造。
此外，本發(fā)明旨在于有效壓縮MPEG-7的描述符。
本發(fā)明的另一個目的是執(zhí)行一種壓縮XML文檔的方法，所述方法極大提高了BiM類型的技術(shù)所提供的壓縮比，但是這種方法提供的功能則與BiM提供的功能是相同的。
根據(jù)本發(fā)明，本發(fā)明的上述目標以及稍后將會出現(xiàn)的本發(fā)明的其他目標是借助一種用于壓縮一個描述多媒體信號的層次樹的方法來實現(xiàn)的，所述樹包括節(jié)點和葉片(leaf)，這些節(jié)點和葉片可以關(guān)聯(lián)于至少兩種不同類型的內(nèi)容，其中所述方法借助于至少兩種壓縮編碼技術(shù)來對至少某些所述葉片執(zhí)行一個內(nèi)容壓縮，其中將各種所述技術(shù)選擇性地關(guān)聯(lián)于至少一個所述內(nèi)容類型。
根據(jù)本發(fā)明的一個優(yōu)選實施例，這種方法包括一個識別至少一個子樹的步驟，以及一個將其中一種所述壓縮編碼技術(shù)分配給所述子樹的步驟。
很有利的是，這種方法包括一個步驟，其中只為那些內(nèi)容類型關(guān)聯(lián)于所述壓縮編碼技術(shù)的所述子樹葉片執(zhí)行分配給所述子樹的所述壓縮編碼技術(shù)，并且不對所述子樹的其他葉片執(zhí)行任何壓縮編碼。
根據(jù)本發(fā)明的一個很有利的特征，這種方法實施了所述壓縮編碼技術(shù)的一種參量描述。
優(yōu)選地，這種方法還包括一個對所述樹的結(jié)構(gòu)進行壓縮的步驟。
非常有利的是，所述樹是依照MPEG-7標準的BiM(二進制MPEG)類型的。
優(yōu)選地，所述壓縮編碼技術(shù)中的一種技術(shù)執(zhí)行的是線性量化。
非常有利的是，所述壓縮編碼技術(shù)中的一種技術(shù)執(zhí)行的是統(tǒng)計壓縮算法。
優(yōu)選地，所述算法是GZip類型的。
優(yōu)選地，所述算法是為了一組對應(yīng)于至少兩個葉片內(nèi)容的數(shù)據(jù)而被同時執(zhí)行的。
優(yōu)選地，所述樹代表一個XML(擴展表記語言)類型的文檔的結(jié)構(gòu)。
本發(fā)明還涉及一種方法，用于按照壓縮一個層次樹的上述方法來對經(jīng)過壓縮的多媒體信號進行解碼。
非常有利的是，這種方法執(zhí)行的是一個根據(jù)所述信號傳送的編碼上下文信息來刷新當前的解碼上下文的步驟。
優(yōu)選地，所述當前上下文定義了至少一個內(nèi)容類型，所述方法包括一個為某些具有所述內(nèi)容類型的內(nèi)容的葉片執(zhí)行關(guān)聯(lián)于所述內(nèi)容類型的壓縮解碼技術(shù)的步驟。
本發(fā)明還涉及一種信號，所述信號是通過上述壓縮層次樹的方法而產(chǎn)生的。
本發(fā)明的其他特征和優(yōu)點將根據(jù)后續(xù)描述和后續(xù)圖形而變得更為清楚，其中后續(xù)描述是作為純粹的說明性實例而不是限定性實例所給出的-
圖1描述的是編碼上下文的概念；-圖2描述的是一個按照BiM技術(shù)來進行編碼的元素的結(jié)構(gòu)；-圖3描述的是為了壓縮層次樹的葉片內(nèi)容而依照本發(fā)明執(zhí)行的某些步驟。
在詳細描述如何實施本發(fā)明之前，我們首先回顧一下以BiM技術(shù)著稱的現(xiàn)有技術(shù)中的壓縮技術(shù)的主要特征。
為了易于理解本文檔，在附錄9中收集了某些參考文獻并在整個文檔當中對其加以引用。
提供給本文檔的所有附錄都是關(guān)于本發(fā)明的當前描述的一部分。
1.現(xiàn)有技術(shù)引論圖1描述的編碼上下文是解碼比特流時所需要的一組解碼信息。一個編碼上下文可以應(yīng)用到將其定義的節(jié)點的整個子樹。在這個樹的各個節(jié)點可以修改編碼上下文；由此導(dǎo)致創(chuàng)建一個適用于相應(yīng)子樹的新的編碼上下文。
一個上下文可以傳送若干信息，這些信息聲明(edict)了適用于有關(guān)子樹的特征。當前，在BiM子樹編碼格式[1]中，這些特征是子樹/子上下文的跳越性以及子樹/子上下文的多種模式編碼(以便提供反向和前向兼容性特征)。最后，為了節(jié)省帶寬，在各個子樹之中可以僅用上下文機制；這就是上下文凍結(jié)(frozen)模式。
在一個文檔樹的各個子樹中，編碼上下文機制提供了最大限度的靈活性，并且它還允許將可擴展特征插入BiM編碼機制。
現(xiàn)在，我們對BiM中使用的當前的上下文機制進行介紹。
當前的編碼上下文機制定義編碼上下文codingContext(編碼上下文)是解碼器在對比特流進行解碼時需要用到的一組信息，即上下文信息。編碼上下文適用于對其做出定義的節(jié)點以及對應(yīng)于這個節(jié)點的整個子樹。
在文檔內(nèi)部，可以對當前編碼上下文(也就是適合在所描述的規(guī)定節(jié)點使用的上下文)進行修改(也就是對其基礎(chǔ)信息集合進行修改)。對編碼上下文的各種修改將會導(dǎo)致產(chǎn)生一個新的編碼上下文，所述上下文傳送的是經(jīng)過修改的信息集合。在解碼器結(jié)束了對與所述上下文相對應(yīng)的子樹所進行的解碼的時候，預(yù)料將會堆疊所有編碼上下文，以便恢復(fù)這些編碼上下文。
解碼器BiM解碼器包括兩個解碼器-上下文解碼器；這個解碼器專門用于解碼上下文信息。如先前所述，上下文信息并不是這個描述的一部分。它是一組傳送某些外部特征、前向和后向兼容性、快速跳越等等的信息。
-元素解碼器；這個解碼器即為BiM規(guī)則解碼器[1]，它專門用于對元素信息進行解碼。
組塊各個元素編碼為圖2所述的三元組(3-plet)，其中報頭部分包括兩個大小可以為零的組塊-MC是元上下文(metacontext)組塊；-C是上下文組塊；-元素即為元素組塊，它是常規(guī)元素的編碼組塊，參見[1]。
元上下文組塊MC包含了解碼器對后續(xù)組塊C進行解碼所需要的信息。也就是說，組塊MC即為上下文組塊C的上下文組塊。
上下文組塊C包含了能夠改變信息的當前編碼上下文集合，并且解碼器需要使用上下文組塊C來對后續(xù)的元素組塊進行解碼。也就是說，組塊C即為元素組塊的上下文組塊。
信息集合當前的BiM編碼上下文傳送一個信息集合，即上下文信息，所述信息可以劃分在以下兩個主要類別之中-元上下文部分；如果信息包含在這個部分之中，則只會影響到上下文解碼處理-上下文部分；如果信息包含在這個部分，則只會影響到元素的解碼處理當前的信息集合即為以下變量集合
所定義的分類對上述組塊進行精確編碼(元上下文組塊MC與上下文組塊C)。
元上下文組塊定義大小可以為零的元上下文組塊MC包含信息，以便了解解碼器是否需要讀取后續(xù)章節(jié)中描述的下一個上下文組塊C。
所涉及的變量
缺省值freezing_state的缺省值為假；也就是說，依據(jù)缺省值，根上下文(root context)是可以動態(tài)改變的。
傳播規(guī)則在創(chuàng)建一個新的上下文的時候-將這個新的上下文的freezing_state的值設(shè)定為父上下文的freeze_state的值。
動態(tài)修改規(guī)則在描述各個節(jié)點的時候，并且為了創(chuàng)建一個新的上下文-可以將freezing_state的值從假切換到真。
解碼規(guī)則如果freezing_state的值為真，則不將元上下文組塊MC(以及即將出現(xiàn)的上下文組塊C)編碼到比特流中。換句話說，報頭的元上下文組塊MC部分是如下編碼的
上下文組塊(context-chunk)是一個初始設(shè)定為假的局部變量。
如先前章節(jié)所述，修改當前上下文變量意味著創(chuàng)建一個新的上下文。
對上下文解碼處理的影響如果context_chunk的值為真，則解碼器必須讀取后續(xù)的上下文組塊C。
上下文組塊定義上下文組塊C的大小可以為零，它包含了一個能夠動態(tài)改變當前上下文變量的信息集合。由于這些變量將會影響到BiM元素的解碼處理，因此將其稱為編碼屬性。
所涉及的編碼屬性
缺省值如在FCD系統(tǒng)文檔[1]中定義的那樣，變量allows_skip是在比特流開端由4專用比特字段的前兩個比特初始化的。
變量allows_partial_instantiation是在比特流開端由4專用比特字段的第三個比特初始化的。
變量allows_subtyping是在比特流開端由4專用比特字段的第四個比特初始化的。
Schema_mode的缺省值是單一；也就是說，作為缺省情況，根子樹/根上下文是以一種模式來進行編碼的。
傳播規(guī)則在創(chuàng)建新的上下文的時候-將allows_skip的值設(shè)定成它的父上下文的allows_skip的值-將allows_partial_instantiation的值設(shè)定成它的父上下文的值-將allows_subtyping的值設(shè)定成它的父上下文的值-將schema_mode的值設(shè)定成它的缺省值動態(tài)修改規(guī)則在描述各個節(jié)點的時候，并且為了創(chuàng)建一個新的上下文-可以動態(tài)修改allows_skip-不能動態(tài)修改allows_partial_instantiation-不能動態(tài)修改allows_subtyping-可以動態(tài)修改schema_mode解碼規(guī)則只有在給出了元上下文組塊MC并且其先前局部變量context chunk為真的情況下，才會給出上下文組塊C。
當前上下文的動態(tài)修改是結(jié)合一個XML元素來描述的，其中所述元素是以BiM常規(guī)編碼模式編碼的。在這里使用了一個源自BiM模式的全局元素modifyContext(修改上下文)。并且在附錄1中描述了http//www.mpeg7.org/2001/BiMCoding的編碼模式。
在使用上述模式的情況下，必須使用BiM常規(guī)模式來對上下文組塊C進行解碼。
如前所述，修改上下文中的當前編碼屬性意味著創(chuàng)建一個新的上下文。因此，上下文組塊C的存在將會意味著創(chuàng)建一個新的上下文，所述上下文傳送的是經(jīng)過修改的編碼屬性。
如果元素allowsSkip是在元素modifyContext內(nèi)部例示的，則在新的上下文中更新allows_skip的值。
如果元素schema_mode是在元素modifyContext內(nèi)部例示的，則在新的上下文中更新schema_mode的值。
對元素解碼過程的影響在處理跳越特征的時候，allows_skip與schema_mode的值將會影響到元素的解碼過程。在[1]中針對這種行為進行了描述。
schema_mode的值會影響到元素的解碼過程，以便了解是否僅僅使用一種模式還是使用若干種模式來對元素進行編碼。在[1]中描述了這種機制。
allows_partial_instantiation的值是通過向可能的元素子類型中添加partiallyInstantiated類型這樣一個特殊類型來影響元素的解碼處理的。參見[1]。
allows_subtyping的值將會影響到元素的解碼處理，如果元素是多態(tài)(具有xsitype屬性)或聯(lián)合的，那么它還允許元素或?qū)傩跃哂胁煌目赡茴愋?。參見[1]。
2.本發(fā)明的描述2.1.為了提供一個用于葉片壓縮的框架(framework)而對上下文機制進行擴展本發(fā)明建議對當前的BiM上下文機制進行擴展，以便支持一個全新和有趣的特征使用本地壓縮器來壓縮文檔葉片，以便減小最終得到的比特流的大小。
這一部分描述的是如何擴展當前BiM上下文機制來支持本地壓縮器的應(yīng)用。所述機制通常是一組全新的變量即編碼屬性，它們與特定的語義、傳播及編碼規(guī)則相聯(lián)系。因此，這個新的編碼屬性集合將會擴展當前的上下文組塊。
引論在一個子樹中，可以結(jié)合一個或幾個指定的壓縮器來對一個或幾個指定的簡單類型的所有實例進行壓縮。這其中主要定義了壓縮器與一個或幾個簡單類型之間的映射。
此外-在某些情況下，壓縮器可能需要某些外部參數(shù)，-為了在某些子樹而不是別的子樹中使用壓縮器，可以激活/去活所述映射最后，為了激活/去活映射，所述映射應(yīng)該是可引用的，因此，所述映射在一個上下文中必須具有一個唯一標識符。
因此，每一個上下文都可以傳送零個、一個或幾個codecTypeMapper(編解碼類型映射器)；其中codecTypeMapper是一個四元組，它包括一個標識符、一個或幾個簡單類型、一個編解碼器、可選的外部編解碼器參數(shù)以及一個激活狀態(tài)。
定義CodecTypeMapper(編解碼類型映射器)codecTypeMapper是一個四元組(4-plet)，其中包括-一個用作子樹/子上下文中唯一參考密鑰的標識符-所述映射所適用的一個或幾個簡單類型-一個編解碼器-可選的外部編解碼器參數(shù)(依賴于編解碼器)-一個激活狀態(tài)標識符標識符是一個使用單值方式來標識上下文內(nèi)部映射的唯一數(shù)字。而BiM編碼模式則把上下文中的codecTypeMapper的最大數(shù)目限制為32。
簡單類型在一種模式中定義的所有簡單類型可以由各個編解碼器進行先驗編碼，但是各個編解碼器也可以限制這種選擇。舉例來說，如在本文檔中稍后定義的那樣，線性量化器只能與數(shù)字型的簡單類型結(jié)合使用。
簡單類型是通過其名稱及其所屬模式的URL來定義的。為了指向正確的模式，在這里應(yīng)該使用XML模式前綴。BiM編碼模式定義了一種特定類型，以便對這種結(jié)合進行編碼；并且所述類型應(yīng)該編碼為整數(shù)對；其中將第一個整數(shù)限制為已知模式的當前數(shù)目(可以在DecoderConfig(解碼器配置)這個部分[1]中得到該信息)，此外將第二個整數(shù)限制成相應(yīng)模式中存在的全局簡單類型的數(shù)目。
編解碼器代表壓縮器/解壓縮器的編解碼器是一個獲取輸入比特并寫出輸出比特的模塊。所述編解碼器可能需要某些可選的外部參數(shù)。
編解碼器是通過BiM編碼模式中定義的非抽象(non-abstract)編解碼器名稱中的一個名稱來識別的。以上章節(jié)所定義的當前BiM編碼模式并未定義任何非抽象的編解碼器，但是本文檔中的§2.2對其進行了定義。
激活狀態(tài)激活狀態(tài)是一個布爾標志。
語義規(guī)則CodecTypeMapper(編解碼器類型映射器)每個上下文-可以傳送零個、一個或幾個codecTypeMapper-可以定義一個或幾個codecTypeMapper-可以激活或去活一個或幾個現(xiàn)有codecTypeMapper如果codecTypeMapper是在一個上下文中定義的，則它將會保持在其所有子上下文中。
在一個上下文內(nèi)部，不能刪除或修改現(xiàn)有的codecTypeMapper(除了它的激活狀態(tài)之外)。
標識符在一個上下文的所有codecTypeMapper中，一個映射的標識符必須是唯一的。
簡單類型當你在一個codecTypeMapper中將一個或幾個簡單類型關(guān)聯(lián)于一個編解碼器時，編解碼器將會對簡單類型本身以及源自它們的所有簡單類型進行編碼/解碼。
在一個上下文中，與適合與編解碼器結(jié)合使用的簡單類型相比，必須存在至多一個簡單類型。
編解碼器在這里存在兩種類型的編解碼器無記憶編解碼器和上下文編解碼器。
無記憶編解碼器是這樣一種模塊，它總是把相同的輸入字節(jié)編碼成相同的字節(jié)輸出；并且獨立于編解碼器的歷史紀錄。典型的無記憶編解碼器是一個線性量化器。BiM葉片壓縮(參見本文檔的§2.2)就描述了這樣一個編解碼器。
上下文編解碼器是一種使用了輸入自身的先前字節(jié)(由此改變編解碼器上下文)的模塊。這種編解碼器不會為接收到的相同輸入字節(jié)產(chǎn)生相同的輸出字節(jié)。典型的上下文編解碼器是類似Zip的本地編解碼器，在本文檔的§2.2對其中一個進行了描述。
無記憶編解碼器不會在當前的上下文體系中引入任何問題，但是，在具有可跳越子樹的情況下，上下文編解碼器將會引入問題。在這種情況下，為了避免干擾解碼器，在上下文編解碼器已經(jīng)跳過子樹的時候，將會復(fù)位所述上下文編解碼器。
激活狀態(tài)在各個子樹/上下文中，可以激活或去活codecTypeMapper。
這種機制允許在更高級別的文檔樹中定義一個codecTypeMapper，并且僅僅在使用所述codecTypeMapper的子樹中將其激活，而不必重新定義codecTypeMapper。
新的編碼屬性codecTypeMapper在這個部分，我們向上文所述的上下文部分的先前變量集合中添加了一個新的編碼屬性。這種新的編碼屬性命名為codecTypeMapper，它是先前章節(jié)所述的先前codecTypeMapper的一個列表。
所涉及的新的編碼屬性上下文傳送的是codecTypeMapper的一個列表
新的缺省值作為缺省情況，在子樹/子上下文中并不存在codecTypeMapper。
如果在一個上下文內(nèi)部定義一個codecTypeMapper，則必須定義它的標識符、編解碼器以及simple_type的值。如果并未規(guī)定，那么，則缺省地將新定義的codecTypeMapper的激活狀態(tài)設(shè)定為真；也就是說，作為缺省情況，新定義的codecTypeMapper是激活的。
新的傳播規(guī)則規(guī)則1在創(chuàng)建新的上下文的時候，codecTypeMapper列表是它的父上下文的一個副本-標識符的值是復(fù)制的-simple_type的值是復(fù)制的-編解碼器的值是根據(jù)規(guī)則2復(fù)制的-codec_parameter的值是復(fù)制的-activation_state的值是復(fù)制的規(guī)則2編解碼器的值是復(fù)制的，并且如果-父編解碼器的codingProperty[i].codec是一個上下文編解碼器-以及，如果當前上下文是可跳越的那么，預(yù)料解碼器將會通過復(fù)制父編解碼器的實例(不僅僅是它的值)來創(chuàng)建一個新的編解碼器實例，并且將其復(fù)位。
舉例來說，在進入一個可以跳越的節(jié)點的時候，將會對ZLib編解碼器進行復(fù)制，并且重新初始化所述編解碼器。
新的動態(tài)修改規(guī)則在以下描述中可以動態(tài)修改codecTypeMapper的列表-可以定義新的codecTypeMapper-可以動態(tài)修改現(xiàn)有(然后是可引用的)codecTypeMapper的activation_state現(xiàn)有codecTypeMapper是不能刪除的，并且也不能對其組成部分進行動態(tài)修改(除了它的activation_state之外)。
新的解碼規(guī)則同一規(guī)則也應(yīng)用于上下文組塊C的解碼，但是應(yīng)該采用附錄2中描述的新的模式，以便添加新的codecTypeMapper動態(tài)修改功能。
信息部分實例附錄3描述的實例在一個描述中給出了關(guān)于激活線性量化器的定義(參見本文檔的§2.2)。
附錄4描述的實例給出了一個描述中的關(guān)于去活線性量化器的定義。
2.2 BiM葉片壓縮我們現(xiàn)在介紹的是本發(fā)明結(jié)合不同編解碼器來對數(shù)據(jù)進行編碼所實施的機制。更確切地說，我們現(xiàn)在描述兩個實例，其中一個實例使用線性量化編解碼器來對例如浮點值進行壓縮，另一個實例則是使用gzip編解碼器來對例如串值進行壓縮。
這種機制與編碼上下文密切相關(guān)，并且所述機制允許使用幾種其他類型的編解碼器。此外，所述機制還允許恰當處理諸如可跳越子樹這類編碼上下文特征。最后，所述機制允許在不同的編碼上下文中重新使用編解碼器。
引論BiM子樹編碼[1]并沒有對所描述的數(shù)據(jù)葉片進行壓縮。目前，葉片值是相對其類型(IEEE 754浮點型和雙精度型、UTF串、……)而被編碼的。
在很多情況下，使用諸如線性量化或統(tǒng)計壓縮這類經(jīng)典的壓縮技術(shù)有益于改善BiM的壓縮比率，但卻不會丟失其主要特征(流線分析、快速跳越特征、類型解碼)。
本文檔介紹了如何在§2.1中描述的上下文編碼機制內(nèi)部對文檔數(shù)據(jù)葉片進行壓縮，從而得到更好的壓縮比。
2.2.1.線性量化定義在信息源已知并且由此可以控制損耗的時候，線性量化是一種減少比特流中編碼數(shù)字大小的很常見的有損方法。
作為實例，通過使用精確的比特大小量化，取樣音頻信號的包絡(luò)通常是已知的，并且這種技術(shù)可以有效用于描述經(jīng)過編碼的MPEG-7音頻。
如果ν是一個實數(shù)，則可以使用具有nbits個比特的νq來對其進行編碼νq=ν-νminνmax-νmin(2nbits-1)]]>其中-νq是ν經(jīng)過量化和編碼的值-nbits是以比特為單位的必要精度，-νmin是ν可以達到的最小相容值，-νmax是ν可以達到的最大相容值來自v的編碼值是νν‾=νmin+νqνmax-νmin2nbits-1]]>其中ν是ν的解碼近似值與上下文機制相結(jié)合LinearQuantizerCodec(線性量化編解碼器)如在本文檔§2.1所描述的編碼上下文機制中定義的那樣，可以將線性量化用作一個編解碼器。借助于這種機制，可以在所描述的任何子樹中把具有預(yù)期簡單類型的線性量化應(yīng)用于數(shù)字數(shù)據(jù)葉片。
與此類似，與線性量化編解碼器相關(guān)聯(lián)的編碼上下文機制則被用于充當MPEG-4 BIFS[3]中所使用的QuantizationParameter(量化參數(shù))節(jié)點。
關(guān)于適用的簡單類型的限制根據(jù)本文檔§2.1中關(guān)于編解碼器的定義，這個編解碼器是一個無記憶編解碼器，它可以應(yīng)用于各種最基本(atomic)和并非最基本的簡單數(shù)字類型；這些類型的XML模式的原語類型則是float(浮點)、double(雙精度)或decimal(十進制)。
編解碼器的外部參數(shù)線性量化編解碼器需要以下三個強制性參數(shù)-bitSize(比特大小)；即上述變量nbits-minInclusive(最小內(nèi)含值)即上述變量νmin-maxInclusive(最大內(nèi)含值)即上述變量νmax編解碼器的模式定義線性量化編解碼器是一種全新的LinearQuantizerCodecType類型的編解碼器，它基于抽象的CodecType類型(參見§2.1) 并且是由編碼上下文命名空間URL xmlnscc＝http//www.mpeg7.org/2001/BiMCoding中的附錄5中所給出的模式來定義的。
編碼(信息)數(shù)值為ν的數(shù)字數(shù)據(jù)葉片是使用nbits個比特上的無符號整數(shù)νq來編碼的，其中νq=ν-νminνmax-νmin(2nbits-1)]]>解碼在nbits個比特上編碼的無符號整數(shù)νq應(yīng)該解碼為ν，其中ν‾=νmin+νqνmax-νmin2nbits-1]]>實例(信息)附錄6中描述的實例給出了所描述的線性量化器的定義。
2.2.2.統(tǒng)計壓縮如編碼上下文機制(參見§2.1)中定義的那樣，可以將傳統(tǒng)的統(tǒng)計無損壓縮算法用作編解碼器。通過這種機制，可以在所描述的任何子樹中對具有預(yù)期的簡單類型的數(shù)據(jù)葉片進行有效壓縮。
這種編解碼器有益于顯著減少比特流的大小，尤其是在所述描述包含了許多重復(fù)或相似的字符串時。
定義在BiM中可以使用傳統(tǒng)的無損統(tǒng)計壓縮算法(類似Zip或GZip)來壓縮所描述的任何葉片。
但在大多數(shù)情況下，當數(shù)據(jù)葉片是只包含了不到10個字符的很短字符串時，這將會導(dǎo)致產(chǎn)生很差的性能，因此，常見的統(tǒng)計壓縮算法都需要預(yù)先準備一個更大的緩存器。
為了實現(xiàn)最佳壓縮比，在壓縮之前必須把文檔葉片緩存到一個小型緩存器中。在后續(xù)章節(jié)中定義了這種緩存式統(tǒng)計編碼器，這種編碼器依賴于一個基礎(chǔ)的無損統(tǒng)計壓縮算法。
緩存式統(tǒng)計編碼器的定義緩存式統(tǒng)計編碼器依賴于一個基礎(chǔ)統(tǒng)計編碼器，該編碼器包括一般的下列原始方法-initialize_stream()所述方法初始化一個壓縮或解壓縮流，-reset_model()所述方法復(fù)位編碼器的當前統(tǒng)計模型-feed_input_bytes()所述方法獲取輸入的解壓縮字節(jié)并將其放入壓縮流中-flush_output_bytes()所述方法對已被處理的輸入字節(jié)進行壓縮并且發(fā)出相應(yīng)的已壓縮輸出字節(jié)，由此沖洗所述壓縮流-decompress_input_bytes()所述方法獲取規(guī)定數(shù)量的輸入壓縮字節(jié)，并且通過發(fā)出相應(yīng)的解壓縮輸出字節(jié)來對輸入壓縮字節(jié)進行解碼緩存式編解碼器具有大小為bufferSize個字節(jié)的長度以及字節(jié)陣列緩存FIFO結(jié)構(gòu)。
從編碼器一側(cè)來看，bufferSize的值指示的是編碼器在沖洗之前可以處理的輸入字節(jié)數(shù)目。從解碼器一側(cè)來看，bufferSize的值是借助基礎(chǔ)統(tǒng)計編碼器API來解碼所述比特流所需要的以字節(jié)為單位的最小緩存器大小。
緩存器還具有一個變量fillingLevel(填充等級)，它包含了以字節(jié)為單位的緩存器的實際填充等級。
將ZLib API用作統(tǒng)計編碼器在GZip壓縮方案中使用了ZLib公共庫API[4]，所述ZLib公共庫API提供了一種有效和有益的API，以便將統(tǒng)計壓縮應(yīng)用于文檔葉片。
ZLib API是結(jié)合以下映射來滿足先前的一般方法的-initialize_stream()可以與具有效率值參數(shù)Z_DEFAULT_COMPRESSION的Zlib的inflateInit()或deflateInit()函數(shù)相映射。
-reset_model()可以與ZLib的inflateEnd()或deflateEnd()調(diào)用以及后續(xù)的initialize_stream()調(diào)用相映射。
-feed_input_bytes()可以與具有參數(shù)Z_NO_FLUSH的ZLib的deflate()方法相映射。
-flush_utput_bytes()可以與具有參數(shù)Z_SYNC_FLUSH的ZLib的deflate()方法相映射。
-decompress_input_bytes()可以與ZLib的inflate()方法相映射。
如在[4]中定義的那樣，應(yīng)該結(jié)合效率值Z_DEFAULT_COMPRESSION來初始化ZLib緩存式編解碼器，所述效率值在存儲器覆蓋需求與壓縮效率之間提供了很好的折衷。
與上下文機制相結(jié)合ZLibCodec(Zlib編解碼器)這一部分描述的是將先前依靠ZLib API定義的緩存式統(tǒng)計編碼器集成到編碼上下文機制內(nèi)部。
對于適用的簡單類型的限制根據(jù)§2.1中關(guān)于編解碼器的定義，這個編解碼器是一個上下文編解碼器，所述編解碼器可以應(yīng)用于各種基本和非基本的字符串類型。如[1]中所述，ZLibCodec依賴于文檔葉片的基礎(chǔ)原始編碼。舉例來說，int(整數(shù))類型的葉片是以32比特的無符號整數(shù)來編碼的，string(字符串)類型的葉片是以UTF-8編碼來編碼的，float(浮點)和double(雙精度)類型的的葉片則以IEEE754格式來編碼，……。因此，ZLibCodec將會壓縮這些經(jīng)過編碼的葉片。
編解碼器的外部參數(shù)由于基礎(chǔ)ZLib的效率是在Z_DEFAULT_COMPRESSION設(shè)定的，并且從解碼器一側(cè)來看，bufferSize參數(shù)并不是必需的，因此，緩存式ZLib編解碼器不需要任何外部參數(shù)。
編解碼器的模式定義ZLib編解碼器是一個ZLibCodecType類型的全新的編解碼器，它基于抽象的CodecType(參見§2.1)類型，并且在編碼上下文命名空間中，所述編解碼器是由附錄7中描述的模式來定義的。
編碼(信息)在激活/例示編解碼器的時候-假設(shè)FIFO緩存結(jié)構(gòu)是清空的，則將它的fillingLevel(填充等級)設(shè)定為0-將全局變量referencable_chunk初始化為空值(null)referencable_chunk應(yīng)該包含一個可以引用的比特組塊，其中編碼器必須保持所述組塊，這是因為稍后再編碼處理過程中，所述組塊的值是已知的。當這個組塊已知的時候，可以調(diào)用信令函數(shù)signal_reference_chunk_known()。
在調(diào)用flush_output_bytes()的過程中，如[1]中定義的那樣，在寫出組塊自身之前，應(yīng)該首先使用標準的無符號無限整數(shù)4+1編碼來寫出以字節(jié)為單位的各個非零組塊的大小。
相對原始類型而言，輸入葉片是一個原文葉片的編碼值。以字節(jié)為單位的葉片長度是由leaf.length這個字段給出的。舉例來說[1]，字符串葉片是一個UTF-8的代碼，它在以字符串字節(jié)為單位的大小方面是優(yōu)先的(結(jié)合無限整數(shù)編碼[1]來進行編碼)；而雙精度葉片則是對應(yīng)的IEEE 754標準的64比特的值，……。
以下的enconde_leaf函數(shù)能對輸出字節(jié)組塊中的葉片進行編碼
<pre listing-type="program-listing"><![CDATA[ chunk 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 } } }]]></pre>解碼假設(shè)string_fifo是一個字符串FIFO。
以下方法get()和put()分別是從響應(yīng)(resp)中取出一個元素以及將一個來自響應(yīng)的元素放入FIFO。
方法Empty()用信號通知是否所述Fifo為空。
假設(shè)sub即為獲取一個子串的函數(shù)。
假設(shè)concat是級聯(lián)函數(shù)。
假設(shè)getData()是返回char[ ]的函數(shù)，其中所述char[ ]保持的是來自一個葉片的de-gzip數(shù)據(jù)。
假設(shè)split(char[ ]，char sep，F(xiàn)ifo，char[ ]remainder)是分裂一個處于各個分隔符‘sep’的字符陣列并將獨立的字符串元素存入Fifo以及返回剩余元素的方法(也就是不具有‘sep’來將其結(jié)束的最后一個組塊)<pre listing-type="program-listing"><![CDATA[ split(char[ ]data，char sep，F(xiàn)IFO string_fifo，char[ ]remainder) { 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?。絛ata.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)； }]]></pre>在初始化時，string_fifo為空。
在激活/例示編解碼器時-假定FIFO結(jié)構(gòu)是清空的，則將其numberOfLeaves(葉片數(shù)目)設(shè)定為0-將變量first_chunk設(shè)定為真假設(shè)分隔符字節(jié)是0x00。
以下的decode_leaf函數(shù)能夠從比特流中解碼一個經(jīng)過壓縮的葉片String decode_leaf(){if(numberOfLeaves＝＝0){read_and_decompressed_byte()numberOfLeaves＝count_number_of_leave_in_buffer()}else{}}解碼是通過以下操作來定義的1.如果FIFO為空a.解碼那些經(jīng)過編碼的數(shù)據(jù)，b.在一個FIFO中堆疊所有由0x00分離的元素c.如果最后一個字符不是0x00，則臨時保存仍未完成的字符串d.如果“l(fā)ast_element”不是空，則將其插在FIFO中第一元素的開端e.將這一輪中還未完成的字符串放入last_element
f.刪除并返回第一元素2.如果FIFO不為空，則刪除并返回第一元素。
也可以等價描述為“FIFO不為空”以及“在當前葉片中并沒有編碼數(shù)據(jù)”。
實例(信息)附錄8中所給出的描述是使用ZLibCodecType編解碼器的一個實例，所述編解碼器與類型string以及anyURI相映射。
結(jié)果(信息)以下數(shù)字顯示了使用ZLibCodec所產(chǎn)生的性能，從而壓縮所描述的原文葉片(這些原文葉片來源于string(字符串)和anyURI這種XML模式的基本類型)。在編碼過程中使用了一個大小為buffersize＝256個字節(jié)的緩存器。
所用文件是由MPEG-7 MDS子群提供的。
現(xiàn)在我們快速描述一下根據(jù)本發(fā)明而執(zhí)行的對層次樹的葉片內(nèi)容進行壓縮的步驟。
步驟1是將一種壓縮編碼技術(shù)與一種內(nèi)容類型相關(guān)聯(lián)。例如，可以將線性量化與浮點值相關(guān)聯(lián)。
在步驟2，子樹是在對應(yīng)于所考慮的XML文檔結(jié)構(gòu)的層次樹內(nèi)部得到識別的。
步驟3是將一種壓縮編碼技術(shù)分配給所識別的子樹。
然后，步驟4是對是否激活執(zhí)行壓縮編碼技術(shù)的所述編解碼器進行檢查。如果沒有激活，則不壓縮子樹的葉片(5)。
如果激活的話，則本發(fā)明對如下所述的子樹的葉片的內(nèi)容進行壓縮，其中所述子樹葉片的內(nèi)容具有與所述壓縮編碼技術(shù)相關(guān)聯(lián)的內(nèi)容類型。
附錄1<pre listing-type="program-listing"><![CDATA[ ＜schema targetNamespace＝″http//www.mpeg7.org/2001/BiMCoding″ xmlnscc＝″http//www.mpeg7.org/2001/BiMCoding″ xmlns＝″http//www.w3.org/2000/10/XMLSchema″＞ ＜element name＝″modifyContext″＞ ＜complexType＞ ＜sequence＞ ＜element name＝″allowsSkip″ minOccurs＝″0″＞ ?。約impleType＞ ＜restriction base＝″string″＞ ＜enumeration value＝″mandatory″/＞ ＜enumeration value＝″optional″/＞ ＜enumeration value＝″forbidden″/＞ ＜/restriction＞ ?。?simpleType＞ ＜/element＞ ＜element name＝″schemaMode″minOccurs＝″0″＞ ?。約impleType＞ ＜restriction base＝″string″＞ ＜enumeration value＝″mono″/＞ ＜enumeration value＝″multi″/＞ ＜/restriction＞ ?。?simpleType＞ ＜/element＞ ＜/sequence＞ ＜/complexType＞ ＜/element＞＜/schema＞]]></pre>
附錄2<pre listing-type="program-listing"><![CDATA[＜schema targetNamespace＝″http//www.mpeg7.org/2001/BiMCoding″xmlnscc＝″http//www.mpeg7.org/2001/BiMCoding″xmlns＝″http//www.w3.org/2000/10/XMLSchema″＞ ＜element name＝″context″＞ ?。糲omplexType＞ ＜sequence＞ ?。糴lement name＝″allowsSkip″minOccurs＝″0″＞ ＜simpleType＞ ＜restriction base＝″string″＞ ＜enumerationvalue＝″mandatory″/＞ ＜enumerationvalue＝″optional″/＞ ＜enumerationvalue＝″forbidden″/＞ ?。?restriction＞ ＜/simpleType＞ ?。?element＞ ＜element name＝″schemaMode″minOccurs＝″0″＞ ?。約impleType＞ ＜restriction base＝″string″＞ ?。糴numeration value＝″mono″/＞ ?。糴numeration value＝″multi″/＞ ＜/restriction＞ ?。?simpleType＞ /element＞ ?。糴lement name＝″codecTypeMappers″minOccurs＝″0″＞ ＜complexType＞ ?。約equence＞ ＜elementname＝″codecTypeMapper″ type＝″cccodecTypeMapper″ maxOccurs＝″unbounded″/＞ ＜/sequence＞ ?。?complexType＞ ＜/element＞ ?。?sequence＞＜/complexType＞ ＜/element＞ ＜！--a type can be pointed with the help of a XML Schemaprefix，in order to know the schema it is belonging to --＞ ＜simpleType name＝″coupleSchemaTypeType″＞ ?。紃estriction base＝″string″/＞ ＜/simpleType＞＜！--restriction of 32 maximal codecTypeMappers in a context--＞ ＜simpleType name＝″codecIDType″＞ ＜restriction base＝″integer″＞ ?。糾inInclusive＝″0″/＞ ＜maxInclusive＝″31″/＞ ＜/restriction＞ ?。?simpleType＞ ＜complexType name＝″codecTypeMapperType″＞ ＜sequence＞ ?。糴lement name＝″type″type＝″coupleSchemaTypeType″maxOccurs＝″unbounded″/＞ ?。糴lement name＝″codec″type＝″cccodecType″/＞ ＜/sequence＞ ＜attribute name＝″id″use＝″required″type＝″codecIDType″/＞ ＜attribute name＝″state″＞ ＜simpleType＞ ＜restriction base＝″string″＞ ＜enumeration value＝″activated″/＞ ＜enumeration value＝″deactivated″/＞ ＜/restriction＞ ＜/simpleType＞ ＜/attribute＞ ＜/complexType＞ ＜complexType name＝″codecType″abstract＝″true″/＞ ＜/schema＞]]></pre>
附錄3<pre listing-type="program-listing"><![CDATA[＜Example xmlnscc＝″http//www.mpeg7.org/2001/BiMCoding″＞ ＜AudioEnvelope＞ ＜ccmodifyContext＞ ?。糲odingProperties＞ ＜codingProperty id＝″1″＞ ＜type＞audioFloat＜/type＞ ＜codec xsitype＝″LinearQuantifierType″＞ ＜bitSize＞8＜/bitSize＞ ＜minInclusive＞-1.0＜/minInclusive＞ ＜maxInclusive＞1.0＜/maxInclusive＞ ＜/codec＞ ＜/codingProperty＞ ?。?codingProperties＞ ＜/ccmodifyContext＞ ＜Values＞ ＜Raw＞ -0.25411 0.88541 0.2141946 0.3652541 -0.148941 0.88140.145544 -0.847 ＜/Raw＞ ＜/Values＞ ＜/AudioEnvelope＞＜/Example＞]]></pre>
附錄4<pre listing-type="program-listing"><![CDATA[＜Example xmlnscc＝″http//www.mpeg7.org/2001/BiMCoding″＞＜AudioEnvelope＞ ?。糲cmodifyContext＞ ＜codingProperties＞ ＜codingProperty id＝″1″state＝″deactivated″＞ ＜type＞audioFloat＜/type＞ ＜codec xsitype＝″LinearQuantifierType″＞ ?。糱itSize＞8＜/bitSize＞ ＜minInclusive＞-1.0＜/minInclusive＞ ?。糾axInclusive＞1.0＜/maxInclusive＞ ＜/codec＞ ＜/codingProperty＞ ＜/codingProperties＞ ＜/ccmodifyContext＞ ＜Values＞ ?。糝aw＞ ＜！--quantization here--＞ ＜ccmodifyContext＞ ?。糲odingProperties＞ ?。糲odingProperty id＝″1″state＝″activated″/＞ ＜/codingProperties＞ ＜/ccmodifyContext＞ -0.25411 0.88541 0.2141946 0.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＞＜/Example＞]]></pre>
附錄5<pre listing-type="program-listing"><![CDATA[＜complexType name＝″LinearQuantizerCodecType″＞ ＜complexContent＞ ＜extension base＝″ccCodecType″＞ ＜element name＝″bitSize″＞ ?。約impleType＞ ＜restriction base＝″int″＞ ＜minInclusive value＝″1″/＞ ＜maxInclusive value＝″32″/＞ ＜/restriction＞ ＜/simpleType＞ ＜/element＞ ＜element name＝″minInclusive″value＝″float″/＞ ＜element name＝″maxInclusive″value＝″float″/＞ ＜/extension＞ ＜/complexContent＞＜/complexType＞]]></pre>
附錄6<pre listing-type="program-listing"><![CDATA[＜Example xmlnscc＝″http//www.mpeg7.org/2001/BiMCoding″＞ ?。糀udioEnvelope＞ ＜ccmodifyContext＞ ＜codecTypeMappers＞ ＜codecTypeMapper id＝″1″state＝″deactivated″＞ ＜type＞audioFloat＜/type＞ ＜codec xsitype＝″LinearQuantizerCodecType″＞ ＜bitSize＞8＜/bitSize＞ ＜minInclusive＞-1.0＜/minInclusive＞ ＜maxInclusive＞1.0＜/maxInclusive＞ ＜/codec＞ ＜/codecTypeMapper＞ ＜/codecTypeMappers＞ ＜/ccmodifyContext＞ ＜Values＞ ＜Raw＞＜！--quantization here--＞ ＜ccmodifyContext＞ ＜codecTypeMappers＞ ＜codecTypeMapper id＝″1″state＝″activated″/＞ ＜/codecTypeMappers＞ ?。?ccmodifyContext＞ -0.25411 0.88541 0.2141946 0.3652541 -0.148941 0.8814 0.145544 -0.847 ＜/Raw＞ ?。糣ariance＞＞＜！--but no quantization here--＞ 0.1777441 0.2094511 0.349411 0.548444 -0.445445 -0.3654847 0.9541 ＜/Variance＞ ?。?Values＞＜/AudioEnvelope＞＜/Example＞]]></pre>
附錄7<complexType name＝″ZLibCodecType″>
<complexContent>
<extension base＝″ccCodecType″/>
</complexContent></complexType>
附錄8<pre listing-type="program-listing"><![CDATA[＜MdsExampleTest xmlns＝″http//www.mpeg7.org/2001/MPEG-7_Schema″ xmlnscc＝″http//www.mpeg7.org/2001/BiMCoding″ ?。糲cmodifyContext＞ ?。糲odecTypeMappers＞ ?。糲odecTypeMapper id＝″1″＞ ＜type＞string＜/type＞ ?。紅ype＞anyURI＜/type＞ ?。糲odec xsitype＝″ZLibCodecType″/＞ ＜/codecTypeMapper＞ ＜/codecTypeMappers＞ ?。?ccmodifyContext＞ ?。?！-- the termId attributes，Name elements and Definitions elements will be catched by the ZLibCodecType--＞ ＜ClassificationScheme uri＝″urnmpegMPEG7AudioDomainCS″domain＝″/..″＞ ?。糡erm termId＝″1″＞ ?。糔ame xmllang＝″en″＞Source＜/Name＞ ＜Definition xmllang＝″en″＞Type of audio source＜/Definition＞ ?。糡erm termId＝″1.1″＞ ＜Name xmllang＝″en″ ＞Synthetic＜/Name＞ ?。?Term＞ ＜Term termId＝″1.2″＞ ?。糔ame xmllang＝″en″＞Natural＜/Name＞ ?。?Term＞ ＜/Term＞ ?。糡erm termId＝″2″＞ ＜Name xmllang＝″en″＞Acquisition＜/Name＞＜Definition xmllang＝″en″＞Type of Content＜/Definition＞ ?。糡erm termId＝″2.1″＞ ＜Name xmllang＝″en″＞Music＜/Name＞ ?。?Term＞ ＜Term ternId＝″2.2″＞ ?。糔ame xmllang＝″en″＞Speech＜/Name＞ ?。?Term＞ ＜Term termId＝″2.3″＞ ?。糔ame xmllang＝″en″＞Mixed＜/Name＞ ?。?Term＞ ?。糡erm termId＝″2.4″＞ ＜Name xmllang＝″ en″＞Multi-track＜/Name＞ ?。?Term＞＜/Term＞]]></pre>
附錄9參考文獻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 1952available athttp//www.cis.ohio-state.edu/cgi-bin/rfc/rfc 1950.html
權(quán)利要求
1.用于壓縮一個描述多媒體信號的層次樹的方法，所述樹包含節(jié)點和葉片，它們與稱為數(shù)據(jù)類型的至少兩種不同特性的數(shù)據(jù)相關(guān)聯(lián)，其中所述方法借助至少兩種壓縮編碼技術(shù)來為至少一些所述葉片執(zhí)行數(shù)據(jù)壓縮，每一種所述技術(shù)都選擇性地關(guān)聯(lián)于至少一種所述數(shù)據(jù)類型。
2.根據(jù)權(quán)利要求1的方法，包括一個識別至少一個子樹的步驟，以及一個將所述壓縮編碼技術(shù)中的一種技術(shù)分配給所述子樹的步驟。
3.根據(jù)權(quán)利要求2的方法，包括一個只為其數(shù)據(jù)是關(guān)聯(lián)于所述壓縮編碼技術(shù)的類型的所述子樹葉片執(zhí)行分配給所述子樹的所述壓縮編碼技術(shù)的步驟，其中不對所述子樹的其他葉片執(zhí)行任何壓縮編碼。
4.根據(jù)權(quán)利要求1到3中任何一個權(quán)利要求的方法，執(zhí)行的是一種所述壓縮編碼技術(shù)的參量化描述。
5.根據(jù)權(quán)利要求1到4中任何一個權(quán)利要求的方法，還包括一個壓縮所述樹的結(jié)構(gòu)的步驟。
6.根據(jù)權(quán)利要求1到5中任何一個權(quán)利要求的方法，其中所述樹具有依照MPEG 7標準的BiM(二進制MPEG)類型。
7.根據(jù)權(quán)利要求1到6中任何一個權(quán)利要求的方法，其中所述壓縮編碼技術(shù)中的一種執(zhí)行線性量化。
8.根據(jù)權(quán)利要求1到7中任何一個權(quán)利要求的方法，其中所述壓縮編碼技術(shù)中的一種執(zhí)行統(tǒng)計壓縮算法。
9.根據(jù)權(quán)利要求6的方法，其中所述算法是GZip類型的。
10.根據(jù)權(quán)利要求8和9中任何一個權(quán)利要求的方法，其中所述算法是同時為與至少兩個葉片的數(shù)據(jù)相對應(yīng)的數(shù)據(jù)集合而執(zhí)行的。
11.根據(jù)權(quán)利要求1到10中任何一個權(quán)利要求的方法，其中所述樹表示的是XML(擴展標記語言)類型文檔的結(jié)構(gòu)。
12.根據(jù)權(quán)利要求1到11中任何一個權(quán)利要求的方法，還包括一個將至少一個編碼上下文關(guān)聯(lián)于所述子樹的步驟，所述編碼上下文包括允許在解碼所述層次樹時跳越所述子樹的多個信息。
13.根據(jù)權(quán)利要求12的方法，其中所述多個信息包括指示所使用的壓縮編碼技術(shù)的信息；和/或指示是否已經(jīng)壓縮了相應(yīng)子樹的信息；和/或指示是否可以跳越相應(yīng)子樹的信息；和/或指示已經(jīng)修改了所使用的壓縮編碼技術(shù)的至少一個參數(shù)的信息。
14.用于對按照權(quán)利要求1到13中任何一個權(quán)利要求的方法編碼的多媒體信號進行解碼的方法。
15.根據(jù)權(quán)利要求14的方法，執(zhí)行的是一個根據(jù)所述信號傳遞的編碼上下文信息來刷新當前解碼上下文的步驟。
16.根據(jù)權(quán)利要求15的方法，其中所述當前上下文定義了至少一種數(shù)據(jù)類型，所述方法包括一個為包含所述數(shù)據(jù)類型的數(shù)據(jù)的葉片執(zhí)行一種關(guān)聯(lián)于所述數(shù)據(jù)類型的壓縮解碼技術(shù)的步驟。
17.一種信號，所述信號是由權(quán)利要求1到13中任何一個權(quán)利要求的方法所產(chǎn)生的。
全文摘要
本發(fā)明涉及一種用于對一個描述多媒體信號的層次樹進行壓縮的方法，所述樹包括節(jié)點和葉片，它們可以與至少兩種不同的類型相關(guān)聯(lián)。根據(jù)本發(fā)明，所述方法借助至少兩種壓縮編碼技術(shù)來為至少某些所述葉片實施內(nèi)容壓縮，其中每一種所述技術(shù)都選擇性地關(guān)聯(lián)于至少一種所述內(nèi)容類型。
文檔編號H04N7/24GK1528091SQ02814041
公開日2004年9月8日 申請日期2002年7月12日 優(yōu)先權(quán)日2001年7月13日
發(fā)明者西里爾·康克拉托, 克勞德·塞拉特, 格利高里·帕烏, 塞德里克·蒂埃諾, 亞歷山大·科塔瑪納克, 塞拉特, 克 蒂埃諾, 大 科塔瑪納克, 西里爾 康克拉托, 里 帕烏 申請人:法國電信公司, 恩斯特布列塔尼電信大學(xué)集團公司, 捷通公司